Author| Liu Yanqing, Test Manager, Security Evaluation Department, Shanghai Control Security
Forum| Jianyuan Forum Guantong
Introduction: The first part introduces the rail transit signaling system from the aspects of railway system classification and composition, urban rail transit system classification and composition, urban rail transit system functions, and urban rail transit system development; the second part describes the basics of signals The principles and meanings of signal machines, switch machines, track circuits, etc. are explained; the third part analyzes the necessity of safety design, control design, demand analysis and realization of the rail transit system; the fourth part focuses on the interlocking The principle of the system is explained; the fifth part analyzes the management of the rail transit software testing process; this article will start with the rail transit software testing technology.
01
Introduction to the Software Development Process
Essential Activities: Work activities that must be performed to ensure that the development can fulfill the requirements of the task.
Supporting activities: Management activities carried out to ensure that the development process complies with established system requirements.
Other management activities: management activities that need to be implemented in order to ensure the risk, confidentiality, and security of the software development process, work with stakeholders, and continuous improvement of the system.
figure 1
Project planning:
When the undertaker receives the software development task document from the assigning party, the software project shall be established, and the software development plan shall be formulated for the implementation of the activities required by this specification and other activities required by other software requirements in the software development task document. This plan should be consistent with system-level planning, which should be based on software project estimates. Planning includes estimating attributes of work products and tasks, determining required resources, negotiating commitments, generating schedules, identifying and analyzing project risks, and developing plans for measurement, data management, review, and stakeholder coordination.
It may be necessary to iterate these activities in order to develop a software development plan. Provides the basis for implementing and controlling software project activities according to the software development plan, which deal with commitments to the project sponsor. As the project progresses, the software development plan often needs to be revised due to: changes in requirements and commitments, inaccurate estimates, corrective actions, and process changes.
The result is the software development plan that the undertaker is responsible for completing, and the estimate report should be included in the development plan. The software quality assurance plan and the software configuration management plan are generally combined in the software development plan. If necessary, they can be prepared separately, but the reasons should be stated in the software development plan.
Supporting activities:
a) software configuration management;
b) software product evaluation;
c) software quality assurance;
d) corrective action;
e) review;
f) Measurement and analysis.
Other management activities:
a) risk management;
b) keep the activity confidential;
c) sub-contractor management (i.e. sub-contractor management);
d) linkages with independent verification and validation bodies;
e) coordination with relevant developers;
f) Improvement of project processes.
These activities can be applied overlappingly or iteratively and do not have to be performed in the order listed above. For specific software, these activities can be tailored. For the software development process and the tailoring of these activities, each unit organization level should formulate tailoring guidelines, and the project level should be described in the software development plan.
02
Software internal testing
2.1 How to do internal software testing
Why：
The purpose of software testing is to save money and schedule for later modification of software problems.
The first is to confirm whether the quality of the software meets the design requirements. On the one hand, it is to confirm that the software does what it is expected to do; on the other hand, it is to confirm whether the software does things in the correct way; the verification and validation testing portion of the work);
Second, provide quality information and provide quality-related information for the development team;
Third, evaluate software and development.
When：
Software testing is generally carried out after the completion of software implementation, but according to the specific implementation, the best practice is that after the coding of product modules is completed during the software implementation process, timely testing can effectively improve the efficiency of software testing, and integration testing can be combined with software code.
What：
Software testing is to verify and confirm whether the software has completed the established requirements according to the design requirements.
Who：
Unit testing and integration testing are generally verified by software developers, configuration item qualification testing and system qualification testing are generally performed by professional testing teams for software testing, and configuration item qualification testing is performed by the testing organization of the project development team. Qualification testing is generally implemented by the software task issuer.
How：
Unit testing generally requires code review, static analysis, logic testing, functional testing, and boundary testing;
Integration testing generally involves functional testing, interface testing and logic testing;
Configuration item qualification testing generally involves document review, code review, static analysis, functional testing, performance testing, interface testing and margin testing, boundary testing, man-machine interface testing, security testing, recovery testing, and installation testing, etc. ; The system qualification test requirements are basically the same as the types of configuration item qualification tests.
figure 2
2.2 Workflow of testing
Determine the test object and test purpose → clear test basis → determine the entry time → determine the test type and test strategy → standardize the test steps → clarify the technical requirements of the test → establish the end criteria → determine the test work product.
03
Requirements for unit testing techniques
3.1 General requirements
a) An environment for testing software units, such as stub modules and driver modules, should be established;
b) Test the function, performance, interface, etc. of the software unit specified in the software design document item by item;
c) Each characteristic of the software unit shall be covered by at least one normal test case and one abnormal test case;
d) The input of the test case should at least include valid equivalence class values, invalid equivalence class values and boundary data values;
e) Meet the requirement that the statement coverage rate must reach 100%;
f) Satisfy the requirement that branch coverage must reach 100%;
g) Meet the requirements of the output data and its format.
3.2 Unit testing - code review requirements
a) Code review should be the result of manual code reading, and auxiliary tools can be used to assist analysis, but the results of tool scanning should not be used as the result of code review;
b) The content of the code review includes: whether the control flow and data processing of the program code meet the design requirements; whether the programming language of the program code is used correctly, standardized, safe, and reliable; whether the program code meets the relevant requirements of the software reliability and safety design criteria ;
c) Code review should establish a code review list, and refine the code review content according to the language used and software characteristics. The inspection content includes: naming rule inspection, code format inspection, memory usage inspection, expression judgment logic inspection, program readability Checks, program redundancy checks, register usage checks, etc.
Table 1
3.3 Unit Testing - Static Analysis Requirements
Static analysis should specify the name and version of the analysis tool.
The content of static analysis includes: program structure analysis; data structure analysis; control flow analysis; program quality measurement.
The use of static analysis results: provide necessary information for code review, provide necessary information for unit testing; provide program code quality measurement information.
Quality metrics requirements: the average cyclomatic complexity of the module is not greater than 10; the proportion of modules with cyclomatic complexity greater than 20 is not greater than 20%; the maximum cyclomatic complexity of the module is not greater than 80; the total comment rate of the source program is not less than 20% The average size of the module No more than 200 lines.
Carry out control flow analysis, data flow analysis, and expression analysis according to the specific characteristics of software programming languages.
Table 2
3.4 Unit Test - Logic Test
a) Statement coverage (SC) test;
b) branch coverage (DC) test;
The logic test mainly runs the test cases dynamically, counts the running path of the test cases, and calculates the coverage rate.
Statement coverage refers to the coverage percentage of each statement of the software program after running all the designed test cases;
Note: statement coverage = (number of statements executed at least once)/(total number of executable statements)
Branch coverage refers to the percentage of true and false values of judgments that have been satisfied at least once for each judgment in the program after running all the designed test cases.
Note: Branch Coverage = (Number of Judgment Results Evaluated)/(Total Number of Judgment Results)
3.5 Unit Testing - Closing Criteria
a) The software function is consistent with the design specification;
b) The control process is correct;
c) Statement coverage and branch coverage reach the specified coverage;
d) Quality assurance completes compliance checks on whether the internal test documents and procedures meet the requirements of the specification;
e) Configuration items such as unit test documents and codes enter the controlled library management.
04
Summarize
This article introduces the testing technology from the aspects of why to do testing, when is the right time to intervene in testing, and how to do unit testing. Testing is not accomplished overnight, nor is it possible to do a good job of testing this technology after following the theory. It is necessary for testers to combine testing theory, systematically and comprehensively understand the project, dig out the focus of the test itself in many aspects, and combine the reality of the project to dig out the risk points of the project itself.
references:
[1] GB-T 15532-2008 Computer software testing specification.
http://www.doc88.com/p-7394374075165.html
[2] GB T 33783-2017 Guidelines for Software Testing of Programmable Logic Devices.
https://wenku.so.com/d/7e5129fc816015b21f1d0f3c901d307b