CN112527380A - Continuous integration method oriented to embedded high-security software - Google Patents
Continuous integration method oriented to embedded high-security software Download PDFInfo
- Publication number
- CN112527380A CN112527380A CN202011397876.6A CN202011397876A CN112527380A CN 112527380 A CN112527380 A CN 112527380A CN 202011397876 A CN202011397876 A CN 202011397876A CN 112527380 A CN112527380 A CN 112527380A
- Authority
- CN
- China
- Prior art keywords
- test
- development
- code
- pipeline
- branch
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3684—Test management for test design, e.g. generating new test cases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Software Systems (AREA)
- Computer Security & Cryptography (AREA)
- Debugging And Monitoring (AREA)
Abstract
The invention relates to a continuous integration method facing embedded high-safety software, which is characterized in that the continuous integration pipeline design considering the high efficiency and safety of the development of the embedded software comprises a development pipeline and a test pipeline, wherein the development pipeline is executed by developers and comprises environment detection, code construction, code static analysis, code self-test and result feedback, the test pipeline is executed by a third party tester and comprises environment detection, code three-party test and result feedback, and a manual link of code examination is arranged between the development pipeline and the test pipeline. The invention combines the high efficiency and safety of the embedded software research and development through the reasonable continuous integration pipeline design, and the high efficiency is realized by introducing a code static analysis link before the test intervention, so that the problem of exposing through a tool as early as possible is solved, and the safety is realized by strengthening the correctness management of the research and development environment and omnibearing code quality guarantee measures.
Description
Technical Field
The invention belongs to a high-safety software research and development integration method.
Background
In a traditional embedded software development mode, team development members integrate codes after the codes are developed, problems are easy to occur in the integration process, and the problems are difficult to troubleshoot. Continuous integration technology is a software development practice that encourages team developers to integrate their work often, with each integration being verified through automated pipelines (including code building, code testing, etc.), so that integration problems can be discovered and corrected as early as possible, ensuring that a stable version is generated for each integration.
The continuous integration technology is widely applied to the internet industry, and is less applied to the field of embedded software, particularly the field of embedded high-security software. The reason is that the Internet industry usually adopts a test drive development mode, and developers are responsible for code development and test at the same time, so that the design of a continuous integration pipeline is facilitated. While embedded high-security software development emphasizes the independence of testers, developers and testers must belong to different teams. In addition, embedded high-security software development needs to eliminate ambiguity of requirement understanding, and strict regulations are provided for development/test environment, code quality, and test items, so that the existing continuous integration technology cannot be directly applied.
Disclosure of Invention
Object of the Invention
The continuous integration method is suitable for embedded high-safety software, the design of a continuous integration production line emphasizes the consideration of safety factors while ensuring high efficiency, the correctness of a research and development environment is ensured, the ambiguity of requirement understanding is eliminated, and the independence of testers is ensured.
Technical solution of the invention
The implementation of the invention comprises the following steps:
1) establishing a Git distributed version control system, wherein the branch management strategy is as follows: firstly, a Master branch, and a Master version change of a management code; secondly, a Defelop branch and a main development branch manage all the required change codes, and the codes need to be successfully executed by a development pipeline and are examined by expert codes in the field; thirdly, a Test branch and a three-party Test branch store Test cases compiled by third-party testers; and fourthly, the Feature branch and the function branch are established according to the ID which needs to be changed according to the requirements so as to establish the association with the requirement change.
2) A developer acquires a requirement change from a requirement management platform;
3) a developer changes and changes codes according to requirements and writes a self-test case for verifying that the code change operation meets the expectation of the developer;
4) and the developer submits the change codes and the self-test cases to a Feature branch of the Git version management server corresponding to the requirement change.
5) The continuous integration platform manages and executes a continuous integrated development pipeline, and the development pipeline is based on Feature branches of Git and comprises the following steps:
5.1) detecting the correctness of the development environment related to the continuous integrated development pipeline to ensure the correctness of the development environment, wherein a method for detecting the matching of tool versions or directly detecting the latest development tool script from a specific configuration management warehouse can be adopted;
5.2) detecting codes and self-test cases from Feature branches of the Git version management server corresponding to the requirement change;
5.3) executing code construction operation, and stopping the execution of the development pipeline if a warning or an error is reported in the code construction process;
5.4) adopting code checking tools such as cppCheck and the like to carry out static scanning on the codes, and if the codes have problems in scanning, stopping the execution of the development pipeline;
5.5) executing the self-test case, and if the execution of the self-test case reports a warning or an error, stopping the execution of the development pipeline;
5.6) whether the execution of the development pipeline is successful or not, the execution result of the development pipeline needs to be fed back.
6) If each link of the development assembly line of the step 5) is successfully executed, submitting a change code to an expert in the field for manual examination, and if the manual examination fails, recording an examination question sheet on a demand management platform; if the manual examination is passed, merging the Feature branch of the Git version management server corresponding to the requirement change into a Defelop branch;
7) the third party tester compiles a Test case, submits the Test case to a Test branch of a Git version management server, and the Test may comprise unit Test, component Test and configuration item Test according to different safety levels;
8) the persistent integration platform manages and executes a persistent integrated Test pipeline, wherein the Test pipeline is based on a Develop branch and a Test branch of Git, and comprises the following steps:
8.1) detecting the correctness of the test environment related to the continuous integrated test pipeline to ensure the correctness of the test environment, wherein a method for detecting the matching of tool versions or directly detecting the latest test tool script from a specific configuration management warehouse can be adopted;
8.2) according to the safety level requirement, performing unit test, component test and configuration item test;
8.3) whether the test pipeline is executed successfully or not, the execution result of the test pipeline needs to be fed back.
Positive effect
The invention combines the high efficiency and the safety of the embedded software research and development through the reasonable continuous integration pipeline design, and the high efficiency is realized by introducing a code static analysis link before the test intervention, so that the problem of exposing through a tool as early as possible is solved, the safety is realized by strengthening the correctness management of the research and development environment, and all-round code quality assurance measures comprise code static analysis, code self-test, expert code review in the field and third-party test.
Drawings
Fig. 1 is a schematic diagram of a persistent integration method oriented to embedded high-security software.
Detailed Description
The detailed description of the embodiments is given by way of example in fig. 1.
The precondition operation is as follows:
1) creating a Git distributed version control system, a Master version Master branch, a Master development Defelop branch and a third-party Test branch;
2) setting a development pipeline based on a Jenkins continuous integration management platform, wherein the pipeline links comprise development environment detection, code construction, code static analysis, code self-test and result feedback;
3) a test assembly line is arranged on the basis of a Jenkins continuous integrated management platform, and the assembly line links comprise test environment detection, code three-party test and result feedback.
A requirement changing process:
1) system personnel issue a new change requirement and input the new change requirement into a requirement management platform, and the requirement number is assumed to be REQ 001;
2) a software developer receives a new demand with a demand number REQ001 on a demand management platform;
3) a software developer requests to create a Feature-REQ001 functional branch on a Git version management server;
4) a software developer clones a Feature-REQ001 branch from a Git version management server, starts coding according to the REQ001, and writes a self-test case (used for verifying that the written code operation accords with the self expectation of the developer);
5) a software developer submits a change code and a self-test case to a Feature-REQ001 branch on a Git version management server;
6) software developers execute development pipelines based on Feature-REQ001 branches, and assume that all pipeline links are executed successfully without warning or error report;
7) the software developer submits experts in the field to perform code review, the correctness of the developer for understanding the requirements is ensured from the perspective of a third party, and the experts in the field assume that the code submitted by the developer is consistent with the requirements in realization;
8) a software developer initiates a branch merging request, and merges the branch of Feature-REQ001 to a main development branch Defelop branch;
9) third-party testers monitor new combinations of Defelop branches, Develop Test case compiling work according to software security levels, and submit the Test cases to a Test branch after compiling is completed;
10) the third-party tester executes the Test pipeline based on the Develop branch (tested code) and the Test branch (Test case), and creates a question sheet on the demand management platform on the assumption that the Test case of the changed part is executed wrongly;
11) after receiving the question list, the software developer modifies the codes and self-test cases according to the question list, and executes the steps 5-8);
12) third-party testers monitor new combinations of Defelop branches, Develop Test case compiling work according to software security levels, and submit the Test cases to a Test branch after compiling is completed;
13) and (3) executing the Test pipeline by a third-party tester based on the Defelop branch (tested code) and the Test branch (Test case), and assuming that all the Test cases of the changed part are successfully executed, so that the continuous integration task requiring REQ-001 is completed.
Claims (9)
1. A continuous integration method for embedded high-security software is characterized in that the design of a continuous integration assembly line which considers the high efficiency and the security of the development of the embedded software comprises two assembly lines of development and testing, the development assembly line is executed by developers and comprises environment detection, code construction, code static analysis, code self-test and result feedback, the testing assembly line is executed by third-party testers and comprises environment detection, code three-party testing and result feedback, and a manual link of code examination is arranged between the development assembly line and the testing assembly line.
2. A persistent integration method as claimed in claim 1, comprising the step 1) of establishing a Git distributed version control system whose branch management policies are as follows: firstly, a Master branch, and a Master version change of a management code; secondly, a Defelop branch and a main development branch manage all the required change codes, and the codes need to be successfully executed by a development pipeline and are examined by expert codes in the field; thirdly, a Test branch and a three-party Test branch store Test cases compiled by third-party testers; and fourthly, the Feature branch and the function branch are established according to the ID which needs to be changed according to the requirements so as to establish the association with the requirement change.
3. A persistent integration method as claimed in claim 1, comprising step 2) the developer obtaining the changes to the requirements from a requirements management platform.
4. The continuous integration method as claimed in claim 1, comprising the steps of 3) changing the modified code by the developer according to the requirement, and writing a self-test case for verifying that the code change operation meets the expectation of the developer.
5. A method as claimed in claim 1, including step 4) for the developer to submit the change code and self test cases to the Feature branch of the Git version management server corresponding to the change of the requirement.
6. A persistent integration method as claimed in claim 1, comprising the step 5) of the persistent integration platform managing and executing a development pipeline of the persistent integration, the development pipeline based on Feature branch of Git comprising the steps of:
5.1: detecting the correctness of the development environment related to the continuous integrated development assembly line to ensure the correctness of the development environment, and adopting a method of detecting the matching of tool versions or directly detecting the latest development tool script from a specific configuration management warehouse;
5.2: detecting codes and self-test cases from Feature branches of a Git version management server corresponding to the requirement change;
5.3: executing code construction operation, and stopping the execution of the development pipeline if warning or error is reported in the code construction process;
5.4: code inspection tools such as cppCheck are adopted to carry out static scanning on the code, and if the code scans a problem, the execution of a development pipeline is stopped;
5.5: executing the self-test case, and if the self-test case gives out a warning or an error, stopping the execution of the development pipeline;
5.6: whether the execution of the development pipeline is successful or not, the execution result of the development pipeline needs to be fed back.
7. The continuous integration method of claim 1, comprising the steps of 6) if each link of the development pipeline of the step 5) is successfully executed, submitting a change code to an in-field expert for manual review, and if the manual review fails, recording a review question sheet on a requirement management platform; and if the manual examination is passed, merging the Feature branch of the Git version management server corresponding to the requirement change into the Defelop branch.
8. The continuous integration method as claimed in claim 1, comprising the step 7) of the third party testers writing Test cases and submitting the Test cases to the Test branch of the Git version management server, wherein the tests may include unit tests, component tests and configuration item tests according to different security levels.
9. The persistent integration method of claim 1, comprising the step of 8) the persistent integration platform managing and executing a Test pipeline for persistent integration, the Test pipeline based on a Git devilop branch and a Test branch, comprising the steps of:
8.1: detecting the correctness of the test environment related to the continuous integrated test assembly line to ensure the correctness of the test environment, and adopting a method of detecting the matching of tool versions or directly detecting the latest test tool script from a specific configuration management warehouse;
8.2: performing unit testing, component testing and configuration item testing according to the security level requirements;
8.3: whether the test pipeline execution succeeds or not, the test pipeline execution result needs to be fed back.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011397876.6A CN112527380A (en) | 2020-12-04 | 2020-12-04 | Continuous integration method oriented to embedded high-security software |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011397876.6A CN112527380A (en) | 2020-12-04 | 2020-12-04 | Continuous integration method oriented to embedded high-security software |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112527380A true CN112527380A (en) | 2021-03-19 |
Family
ID=74997302
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011397876.6A Pending CN112527380A (en) | 2020-12-04 | 2020-12-04 | Continuous integration method oriented to embedded high-security software |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112527380A (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113282517A (en) * | 2021-07-21 | 2021-08-20 | 支付宝(杭州)信息技术有限公司 | Quality evaluation system of intelligent contract code |
| CN113485913A (en) * | 2021-06-10 | 2021-10-08 | 上海百胜软件股份有限公司 | Branch management method, system, equipment and storage medium |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106293749A (en) * | 2016-08-15 | 2017-01-04 | 云南电网有限责任公司信息中心 | A kind of source code managing and control system based on continuous integrating |
| US20170169370A1 (en) * | 2015-12-14 | 2017-06-15 | Apartsw Consulting Inc. | Continuous integration software development platform and system, and implementation method therefor |
| CN106897223A (en) * | 2017-02-24 | 2017-06-27 | 郑州云海信息技术有限公司 | A kind of software kit delivery method and device based on continuous integrating |
| CN106897226A (en) * | 2017-02-28 | 2017-06-27 | 郑州云海信息技术有限公司 | The method and device of a kind of continuous integrating test |
| CN107678773A (en) * | 2017-09-28 | 2018-02-09 | 郑州云海信息技术有限公司 | A kind of code development based on git and testing process management method |
| CN109684215A (en) * | 2018-12-25 | 2019-04-26 | 中国科学院电子学研究所苏州研究院 | A kind of automated software Quality System Review and iteratively faster method |
| CN109947458A (en) * | 2019-03-22 | 2019-06-28 | 广东电网有限责任公司 | A kind of offline source code security continuous integrating method |
| CN111857722A (en) * | 2020-06-23 | 2020-10-30 | 远光软件股份有限公司 | DevOps quality assurance system and method based on three-library mode |
-
2020
- 2020-12-04 CN CN202011397876.6A patent/CN112527380A/en active Pending
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20170169370A1 (en) * | 2015-12-14 | 2017-06-15 | Apartsw Consulting Inc. | Continuous integration software development platform and system, and implementation method therefor |
| CN106293749A (en) * | 2016-08-15 | 2017-01-04 | 云南电网有限责任公司信息中心 | A kind of source code managing and control system based on continuous integrating |
| CN106897223A (en) * | 2017-02-24 | 2017-06-27 | 郑州云海信息技术有限公司 | A kind of software kit delivery method and device based on continuous integrating |
| CN106897226A (en) * | 2017-02-28 | 2017-06-27 | 郑州云海信息技术有限公司 | The method and device of a kind of continuous integrating test |
| CN107678773A (en) * | 2017-09-28 | 2018-02-09 | 郑州云海信息技术有限公司 | A kind of code development based on git and testing process management method |
| CN109684215A (en) * | 2018-12-25 | 2019-04-26 | 中国科学院电子学研究所苏州研究院 | A kind of automated software Quality System Review and iteratively faster method |
| CN109947458A (en) * | 2019-03-22 | 2019-06-28 | 广东电网有限责任公司 | A kind of offline source code security continuous integrating method |
| CN111857722A (en) * | 2020-06-23 | 2020-10-30 | 远光软件股份有限公司 | DevOps quality assurance system and method based on three-library mode |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113485913A (en) * | 2021-06-10 | 2021-10-08 | 上海百胜软件股份有限公司 | Branch management method, system, equipment and storage medium |
| CN113282517A (en) * | 2021-07-21 | 2021-08-20 | 支付宝(杭州)信息技术有限公司 | Quality evaluation system of intelligent contract code |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Gyimesi et al. | Bugsjs: a benchmark of javascript bugs | |
| Sneha et al. | Research on software testing techniques and software automation testing tools | |
| Rathod et al. | Test orchestration a framework for continuous integration and continuous deployment | |
| CN105117335B (en) | A kind of automatic Verification and regression testing method for software unit | |
| Presler-Marshall et al. | Wait, wait. no, tell me. analyzing selenium configuration effects on test flakiness | |
| CN112527380A (en) | Continuous integration method oriented to embedded high-security software | |
| Ahmad et al. | A Review on Software Testing and Its Methodology | |
| Arrieta et al. | Seeding strategies for multi-objective test case selection: An application on simulation-based testing | |
| Ali et al. | A Comprehensive Study on Automated Testing with The Software Lifecycle | |
| Dalal et al. | Software Testing-Three P'S Paradigm and Limitations | |
| Pinheiro et al. | Introducing Automated Environment Configuration Testing in an Industrial Setting. | |
| Duque-Torres et al. | Bug or not bug? analysing the reasons behind metamorphic relation violations | |
| Küster et al. | Incremental development of model transformation chains using automated testing | |
| Orviz et al. | A set of common software quality assurance baseline criteria for research projects | |
| Andrews | Theory and practice of log file analysis | |
| Alsayed et al. | Improving software quality management: testing, review, inspection and walkthrough | |
| Saarimäki et al. | Does migrate a monolithic system to microservices decreases the technical debt? | |
| Vijayasree et al. | A Review on the Process of Automated Software Testing | |
| Mamatha et al. | A literature review on automated code repair | |
| Rexhepi et al. | Software testing techniques and principles | |
| Elakaş et al. | A Collaborative Perspective for Blockchain & Testing | |
| Lima et al. | Teasy: A domain-specific language to reduce time and facilitate the creation of tests in web applications | |
| Arrieta et al. | Seeding Strategies for Multi-Objective Test Case Selection | |
| Das et al. | Software Reliability Growth as an Offshoot of Verification and Validation Process | |
| Gupta et al. | Possibility of reuse in software testing |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20210319 |