High reliability software test plan
(娥 Project Ground Application System Software Quality Dai Jinlong) [Abstract] With the growing scale and complexity of software systems, more and more software projects clearly propose software reliability requirements. Software companies involving high reliability software are increasingly aware that software testing is by no means aid in these project development, but the most effective way to ensure the quality of software engineering process from software quality control angles. In view of this, this paper uses the Craftgs space project model as an example, and systematically introduces a set of effective software test programs that have certain reference significance and guidance on the test work of similar high-reliability software projects. [Key words] High-reliability software test software verification technology software confirmation technology software test management copyright statement: This paper is copyrighted by Mr. Dai Jinlong. Any substantial reference or reprint is required to indicate copyright matters and consent to the author.
1 Introduction
High reliability software generally refers to a class of software: If there is a fault in the operation of this type of software, there will be a major catastrophic accident or economic losses. Usually aerospace model software, banking system software, medical industry software, communication industry software, etc. are in this category. At present, more and more software companies involve high reliability software projects, how to ensure software quality has become a very important issue for many companies. This article combines a space project ground application system model (named Craftgs this article), focusing on how to ensure the software quality of such products from the perspective of software testing.
2 Introduction to Craftgs Project
Craftgs is a very classic satellite ground application system simulation project. It is divided into 5 subsystems: Data Receiver Subsystem (DAS), Data Preparation Subsystem (DPS), Run Administration (OMS), Data Management Subsystem (DMS), and Data Product Realization (DPRS) subsystem. The overall reliability requirements of Craftgs are 0.95. The reliability indicators allocated by each division system are as follows:
Divided system name
Reliability indicator
DAS
0.99994
DPS
0.99865
Oms
0.99910
DMS
0.99950
DPRS
0.99502
The business logic of Craftgs is Data Package to pass from satellite into DAS. DAS is responsible for unpacking. After unpacking data into OMS and DPS, the OMS detects whether the satellite is working properly and is responsible for satellite flight attitude adjustment; DPS is responsible Modulates the data from DAS, converts to meaningful logical data. The logic data after the DPS processed is incorporated into DMS and DPRS. Among them, DMS is responsible for data backup, data query and data link maintenance; DPRS is responsible for converting DPS-processed logical data slots into data products, and packaged.
Considering the quality of reliability security requirements, the CRAFTGS system is implemented in Java UNIX technology architecture. The architecture guarantees the quality of software products from programming language level and system level. In order to control the quality of the software product development process, the author recommends the following software test schemes.
3 Test Scheme: Software Verification Technology Software Confirmation Technology Software Test Management
The software test scheme of the Craftgs system consists of three parts, namely software verification technology, software confirmation technology and software test management technology. Their connotation and mutual relationships are shown in the following figure:
Craftgs test plan
Test technology level
Test management level
Software verification technology
Demand specification verification
Software test team organizes management
Design Specifications Verification
Code verification
Software test plan management
Delivery verification
Software confirmation technology
unit test
Software defect (error) tracking management
Integration Testing
System test
Software test parts management
Delivery test
Among them, software verification techniques focus on exclude errors in software development documents. The document involved in the verification activity mainly involves the demand specifications, design specifications (including profile design specifications, detailed design specifications, database design specifications), coding specifications, product delivery documents, etc. A series of written materials. The implementation of the current verification technology is largely relying on testers to perform manually. Verify that actual needs, sometimes involve developers and target customers, need to get their necessary understanding and support. The main test methods used by the verification test are: face-to-face questions, document spot checks, informal meetings, peer reviews, etc. Compared to software verification technology, software confirmation technology focuses on excluding errors in program code. The object involved is primarily a code or software finished product of the program part. In the implementation process, the software confirmation test is often divided into four stages according to the scale and test of the test code, namely: unit test (also called class test), integrated test (also called assembly test), system test And delivery test. Confirmation test is basically completed independently of the software tester compared to relevant development documentation. If necessary, the designer can also let the designer lead the test program code to discover the errors, (ie the so-called code review meeting). Some comments believe that in the unit test (or class test) phase, there should be software coding personnel to participate, which can reduce the testers to read code obstacles. In principle, the test theory does not advocate the author of the procedure to check the quality of the procedures written. During the actual implementation, the actual situation is flexible. (If the programming can test this problem, the code review mentioned above is also a good way to deal with this problem.), Software confirmation technology has now partially implemented test tools. Automation, many automated tools on the market can complete the corresponding testing under the auxiliary testers (for example, JUnit tools for Java code unit testing, and Rational Visual Test tools used for GUI tests, etc.).
Software verification technology and software confirmation techniques are all things in the test technology. However, for the guarantee of engineering quality, the lighting of software testing technology is still far less enough, and things on the technical management are required. The birth of software test management technology is to make up for this shortcomings. Different according to the object of management, test management technologies roughly cover software test team organization management, software test plan management, software defects (error) tracking management, and four parts: software test parts management. Below, the author will make a detailed interpretation of the test scheme combined with the Craftgs project.
4 Apply the above test scheme in the Craftgs project
The development of the five sub-system of Craftgs is in an orderly manner under quality control of the Craftgs test team, and the above test scheme is strictly implemented. After evaluation, the system after each division system and final integration reached the reliability indicator assigned in the task book.
4.1 Application Software Verification Technology in the Craftgs Project
Software verification technology applied in the Craftgs project mainly includes demand specifications, design specifications, code verification, and delivery verification. The following will be described below.
The main task of the requirements specification verification is to ensure the functional requirements, business needs, and other requirements (such as non-functional demand, constraint demand, etc.) have been assigned to the demand specifications of the software requirements specification.
Design Specifications Verify that relative demand specifications are verified, it is slightly complex, which includes 3 parts: ie profile design specification verification, detailed design specification verification, and database design specification verification. The main task of the provision of the specification is to ensure that the demand items in the software demand specification have allocated the software modules of the summary design specification and there are no more than a perfect design, and the main task of the verification is to ensure the profile design. The modules in the specification have all been distributed to each software unit description of the detailed design specification and there is no more than the object. Although the database design specification, although the category should belong to the detailed design specifications, the author believes that it is independent of it. Implement verification activities. (Database design and software design have many differences.) Database design specification The key task of verification is to verify that the interface between the database and the external application is correct. If the data operation implementation is clear, the database is clearly designed, the data sheet design Whether it meets 3NF requirements (such as a violation paradigm to explain the detailed reason) and the design of the field (keys) in the data table and the index are efficient and so good. After completing the design specifications, the next step is to be done. The contents of code verification include: Code writing specification review, code review and code static analysis three parts. The code writing specification review is mainly to review the format of the code typography and whether the format of the annotation is in line with the corresponding specification of the development team; the task of code review is mainly verified whether the software unit in the detailed design has been overwritten and implemented correctly, and the code is not Withummerous, code static analysis technology is the main task is to check the definition and use of the variable or reference, whether there is defects or errors in the process design of the program.
After doing code verification, the software system needs to do unit testing, integration testing, and system testing in turn. This part of the content is the software confirming the technical category, which is specifically discussed below. After completing the system test, the software system is facing the issue of delivery, and the delivery verification and delivery test is required before the system is officially handed over to the user. Delivery test technology has a special discussion below, not described, here is mainly to talk about delivery verification techniques. Delivery verification includes installation verification and use verification two parts. Among them, the main task of installation and verification is to ensure that the program can be properly installed on the target machine according to the prompt of the user manual, using the primary task of verification is to ensure that the program can correctly complete a function or transaction processing in accordance with the operation of the prompt of the user manual. These two parts are usually done by testers to verify that the relevant installation and use manual is correct.
4.2 Application Software Confirmation Technology in the Craftgs Project
The software confirmation technology applied in Craftgs includes unit test technology, integrated test technology, system testing technology, and delivery test techniques.
The main task of unit test is to verify that the software unit divided in the detailed design specification is implemented in the form of a program to be implemented in the form of a program. Here, the software unit may be a function (or a method) or may be an abstract data type (such as class, data structure, or template). Unit tests are often referred to as class tests (in object-oriented design) or white box tests (in white boxes). The working principle of the unit test is to construct the pile module and drive module to drive the measured plurality of units, and then, the test person can enter the design of test cases, whether the test unit can process these test cases in accordance with the design requirements, and an abnormal test case The testers should be recorded and feedback to the software development team.
After completing the unit test, the next step is to design specification for the software, verify that the software unit assembled the module to achieve the design target of the module in the module; after the module-level integration is completed, the tester is still There is a conflict within the user system formed by each module, and the modules can work properly. Here, the module may refer to a software component, or it may refer to a certain or a few divisions. It is usually started from integrated testing, starting from integrated testing inside the system, and then tested whether each division system can set a large system that is ultimately implemented. There are also other practices (such as the top-down integration test method, the core system first make integrated tests or daily integration tests, etc.). In short, the change is not from its Zong. Integrated Test To ensure that the internal correctness of the module and the guarantee module can eventually integrate into large systems. Integrated tests are sometimes referred to as assembly tests (in model software) or gray box test (some people think that integrated tests are between white boxes and black boxes). After completing the integrated test, the next step is to do system testing. The main task of the system test is to verify that the software system formed after the integrated test meets the needs items in the software requirements specifications. These requirements include: business needs, functional requirements, non-functional requirements (such as performance, reliability, security, system maintenance) and some constraint requirements (such as development standards, programming languages, communication protocols), etc. Wait. Due to the broad field involved in the demand, this has led to quite atrocity that the corresponding test doors in the system test. Such as: function test, execution path test, reliability test, pressure test, recoverable test, portability test, etc. The most significant feature of these tests is to design various test cases, input and run the complete software system under certain environmental conditions (eg, an analog site or extreme condition), and evaluate whether the software system is evaluated according to the actual performance of the software system operation. Compliance with various requirements of the software requirements. Since this type of test generally does not involve internal code, some people also call the system test to be a black box test.
After completing the system test, the software product has arrived in this stage of delivery. An important part of delivery is to deliver tests, and the goal of delivery test is to ensure the satisfaction of the user delivered. Unlike the tests discussed above, the main participants of the delivery test should be the target customer. The more customers participate, the better. The content of the delivery test generally includes installation test, availability test, Alpha test, beta test, etc. The main task of installation test is whether the test software system can be installed in the simulation environment or actually on site by the target user on the target machine; the main task of the availability test is to test the software system to complete the user's simulation after completing the installation. Task or on-site task; Alpha testing is generally a test of a software system in a black box in a development environment, the purpose of testing the function, usability, reliability of software products from the user's perspective , Performance and support, particularly pay attention to the interface and characteristics of the product; the form of Beta test is generally first used by multiple users of the software in the actual use environment for a period of time, and then various types of failures that appear in use or Defect feedback is responsible for the BETA test, and then transferred to the software developer by the test person in charge, and the developer is responsible for correcting and improving the software system. The purpose of the Beta test is to ensure that software products can be partially or fully corrected to all kinds of bugs or deficiencies that may occur in practical applications prior to delivery.
4.3 Application Software Test Management Technology in Craftgs Project
As mentioned earlier, the test technology solves the methods and technical problems used by the test, however, for a project, it is also required to ensure the orderly development of each test activity. Therefore, in the CRAFTGS project, the problem to be solved by software testing management is how to ensure software testing technology (including software verification technology and software confirmation techniques) can be successfully implemented in software projects in software life and produce expected results.
According to the difference in management objects facing software test management, software test management technology is roughly divided into software test team organization management, software test plan management, software defects (error) tracking management, and software test parts management. The following interpretation: The software test team organizes how often is how the test team should form. In actual project development, we often see some units of ignore the meaning of the test team. When you want to implement test, you often find a few programmers to act as testers; some units understand the importance of forming the test team, but In the specific implementation, there are often some new business new doors who have no development experience to do test work, which often leads to the low test efficiency, and testers have tasted the test work. The test team of the Craftgs project first employs a senior test field expert. He has an extremely abundant space project software test experience. It has a good affinity for the fetching defects or mistakes in the process of software development. In addition, he also has better affinity. And personality charm. Second, the Craftgs project test team also has a lot of members with long-standing technologies, such as the use of certain automated test tools or easily write automated test scripts. In addition, the test team also hired part-time members. For example, in the implementation of the test, peer review is the most common form of use, these peer experts are the scope of part-time test team members. As for the test team in the test team, this part of the person can arrange to work in delivery or black box testing.
Software test plan management is popular in arranging test processes. This part of the content covers several parts of software test planning, software testing technology, testing progress management, and cost management. The test planning work mainly refers to the implementation of planning work before the implementation of specific test activities, such as drafting test outline and test plan; software test technology tailoring work mainly means that the test team should have the test technology to be implemented according to the specific actual number of software projects; Test progress management is mainly referring to the time schedule of the discharge test, and should be adjusted accordingly if there is any change; the content of the test cost management will open the resource requirements involved in the test activity. The Craftgs project test team completed the software test plan management in accordance with the above requirements.
Software Defects (Errors) Tracking management is popular to ensure that the defects (errors) have been developed or processed without introducing new defects (errors). Specifically, when the test team discovers the defects or errors in the document or code through a variety of ways, it is not a test report to step on the grass, but will continue to urge the development team in time to close known defects in time after submitting the report. Or errors (of course, if necessary, if you have to deal with these defects, the error is sorted in sequence so that the development team can easily schedule the sequence of processing. When the development team closed the defects in the test report (errors), the test team also needs to verify that the development team has introduced new errors during the closing process. Usually, this process is called the regression test. Return test If the problem is found, continue to report the development group, cycle according to the above flow until the regression test is finally passed. This part of the work is done in the Craftgs project, which is done using the automated test management tool, (which can be selected on the market has the Harchness Defect Management System (BMS) and Rational ClearQuest, etc.), which is very efficient.
Software test parts management is popular to guide the construction of a wealth library of test teams and conduct skills training for test team members to help them use this wealth library. Here, the wealth library refers to a software test piece. Test Parts (Testware) is an uncommon word, which includes lessons learned, test techniques, test tools, specifications, and some modifications, test techniques, test tools, specifications, and some modifications. Can be extended to a generic test script program. The better the test parts management work, the less the test team can take less detours during the actual test, the more fully intellectual communication and delivery of the team, the repeated development of the test script or specification document can be effectively avoid. Software test parts management work includes two parts, one is construction, the other is training. The construction work is to collect all kinds of test external documents, test tools, test scripts, including conferences, summary reports, technical experience, etc., collecting testing testers. The training work is in the form of a technical lecture, a formal or informal team meeting, issued by learning materials. The Craftgs project team takes into account the long-term development of the test team, which has completed the test parts management, and the skill level of the test team member has a very rapid progress in a short period of time. 5 Conclusion: High reliability software test technology needs more attention
The above author combined with the Craftgs project on the perspective of testing technology and test management on high reliability software test programs a slightly shallow discussion. The author hopes that this paper will make a certain reference and guidance effect on the implementation of software testing techniques for related software companies and software projects. It should be noted that the current software test technology is still a quite unsucked, lacks a systematic approach. Various companies may have certain experience accumulation, may wish to sort out, learn from each other. Here, the discussion of the author has made everything else, but it cannot guarantee that it can be tested into all high-reliability software items. I hope that scholars and technical experts in this field will work together to continue to explore, and gradually improve this topic. references:
[1] Glenford J.MYERS.THE ART OF Software Testing.Newyork: John Wiley Press, 1979.127-170. [2] Bill Hetzel.The Complete Guide to Software Testing.2, NewYork: John Wilely Press, 1988.137-190. [ 3] Edward Kit. Software Testing in The Real World. London: Pearson Education, 1995.45-88. [4] Daniel J.Mosely, Bruce A.POSEY.JUST ENOUGH SOFTWARE TEST Automation, 2002.87-91. [5] Paul C.Jorgensen. Software Testing -a Craftsman's Approach. 2, Florida: CRC Press, 2002.260-296. [6] Xu Sheng, Branch, etc. Hospital, 2003.
