Test Zhou Meng for object-oriented software
(This article is reproduced from Software Engineering Expert Network
Www.21cmm.com)
Users use low quality software, which can produce a variety of problems during operation, which may bring different degrees of serious consequences, and the normal work of the system affects the system, resulting in accidents, loss of life and property. Software testing is the most important means of ensuring software quality. What is software test? 1983 IEEE is defined as: the process of running or determining a system using manual or automatic means, the purpose is to test the difference between the specified needs or figure out the difference between the expected results and the actual results. Modern software development projects are a clear division of the entire software development process into several phases (see discussion of [6]), and solve complex problems. In this way, during the entire development of the software, a number of clear monitoring points can be proposed, as the test criteria for each phase target, thereby increasing the visibility of the development process and the correctness of the development process. Experience has shown that the quality of the software is not only reflected in the correctness of the program, it is closely related to the demand analysis of the previously made. The errors in the software are not necessarily that the programmer is introduced during the coding phase, which is likely to be buried in the programming, even demand analysis. At this time, the corrective correction of the error often cannot be traced back to the initial stage of software development through a simple repair of more errors. This undoubtedly increases the development cost of the software. Therefore, in order to ensure the quality of the software, we should focus on the entire software survival period, especially to the work of the previous development phases. In this way, the concept and implementation of the software test must be expanded, and it should be included in the entire development phase of review, evaluation and detection. As a result, the generalized software test is actually composed of three aspects of confirmation, verification, and testing (Note: This article is not an additional identifier at the back of the Generalized Test ": Confirm: Is the software product that will be developed is correct, Feasible and valuable. For example, whether the software to be developed will meet the requirements of the user, whether it can be properly stable in the future actual use environment, there is hidden dangers. Here is an evaluation of the degree of satisfaction of user needs. Confirmation means ensuring that a software to develop is correct and is a detection of software development concept. Verification: It is the detection software development, whether the result of each step is correct, whether it is consistent with the requirements or desired results of the software development at each stage. Verification means ensuring that the software is the need for software, and the development process is in the correct direction. Test: Uniform with a narrow test concept. It is usually three links to the unit test, integrated test, and system test. At the entire software survival (see division in [6]), confirmation, verification, tests have its focus on the stage. Confirmation is mainly reflected in the planning phase, the demand analysis phase, will also appear in the test phase; the verification is mainly reflected in the design phase and the coding phase; the test is mainly reflected in the coding phase and the test phase. In fact, confirmation, verification, test is complementary. Confirmation will undoubtedly produce standards and test standards, and verification and testing usually helps complete some confirmation, especially in the system test phase. Object-oriented technology is a new software development technology, which is gradually replacing the widely used process development method, which is seen as an emerging technology to solve the software crisis. Object-oriented technology produces a better system structure, more standardized programming style, greatly optimizes the security of data, improves the reuse of program code, some people think that the program-oriented technologies do not need to test. It should be seen that although the basic idea of object-oriented technology guarantees that the software should have higher quality, the actual situation is not the case, because no matter what programmed technology, programmers' mistakes are inevitable, and due to facing The software code reuse rate developed by the object technology is high, and it needs to be strictly tested to avoid the reproduction of errors.
Therefore, the software test does not lose its importance without the rise of object-oriented programming. Since 1982, the formal technical conference of the first software test in North Carolina, North Carolina, has rapidly developed, and various software test methods have improved the software testing technology. However, the effective software test of the effective software test is much better than the heart. In particular, the new features such as object-oriented technology are unique, and there is no error likelihood that the traditional language design does not exist, or the focus in traditional software testing is no longer prominent, or the original test experience. The secondary aspects that believe that the proven to practice has become the main problem. For example, in a traditional process procedure, for the function y = function (x); you only need to consider a function ("Function ()) behavior, and in the object-oriented program, you have to consider the base class function ( Base :: function ()) behavior and inheritance class function (Derived :: function ()). The structure of the object-oriented program is no longer a traditional functional module structure, and as a whole, the original integrated test is gradually built into the development of the module for testing. It has become impossible. Moreover, the object-oriented software abandoned the traditional development model. There are different previous requirements and results for each development phase, which is impossible to use functional refinement to detect the results of object-oriented analysis and design. Therefore, the traditional test model is no longer applicable to object-oriented software. For the development characteristics of object-oriented software, there should be a new test model. I. Object-Orient Test Model is subject to object-oriented development model to the traditional waterfall model, which will be developed into object-oriented analysis (OOD), object-oriented programming (OOP) three phases. The analysis stage produces an abstract description of the entire problem space. On this basis, the class and class structure suitable for object-oriented programming languages are further summarized, and finally the code is formed. Due to the object-oriented characteristics, this development model can be used to effectively analyze the design of text or chart, and constantly adapt to changes in user needs. In response to this development model, combined with the division of the traditional test steps, this paper recommends a test model that is constantly tested throughout the software development process, making the development phase test and the unit test, integrated test, and system testing into a whole. . Test model as follows: 0 Object-oriented Test OOD Test: Object-Oriented Design Test OOP Test: Object-Oriented Programming OO Unit Test: Object-oriented Unit Test OO Integrate Test: Object-Oriented Integration Test OO System Test: Object-oriented System Test OOA Test and Ood Test are testing analytical results and design results, mainly for the text produced by the analysis design, and is a critical test for software development. OOP TEST is primarily tested for programming style and program code, and its main test content is embodied in object-oriented unit testing and object-oriented integration testing. Object-oriented unit testing is a test of a specific single functional module inside the program. If the program is implemented with a C language, it is mainly a test of class member functions. Object-oriented unit testing is based on object-oriented integration testing. Object-oriented integration tests are mainly tested by mutual services within the system, such as interactions between member functions, messaging between inter-class.
Object-oriented integration tests are not only based on object-oriented unit testing, but also to see OOD or OOD TEST results (see later in detail). Object-oriented system testing is based on the final stage of object-oriented integration testing, mainly by user requirements as test standards, need to learn from OOA or OOA Test results. Although the tests of each of the above stages constitute a whole interaction, the subject, direction and method of the test are different, and it is convenient for the narrative, and this paper will follow OOA, OOD, OOP, unit test, integrated test, system Test six aspects of the test introduce the test of the object software. For the development model of the three development phases of OOA, OOP, OOD, the goals and results reports of each stage, and the form of the result report have been exceeded, please refer to [1]. Second, the object-oriented test (OOA Test) is a process analysis of a functional decomposition, which is a collection of features that can be decomposed. This conventional functional decomposition analysis method has an eye in which a system is needed to treat the system to treat the system in the abstraction of the process. Object-oriented analysis (OOA) is "Analytical Methods, which combines the concepts of information styling, ie information in the information model, and combined with important concepts in object design language" (see [1]), Finally, it is usually described in the form of a chart of the problem space. OOA direct mapping problem space, comprehensive implementation of the realistic abstraction of the functionality. Abstract the instance of the problem space as an object (different in C object concept), reflecting the complex instances and complex relationships of the problem space with the structure of the object, and represents the features and behavior of the instance with the attributes and services. For a system, in contrast, the behavior is relatively stable, and the structure is relatively unstable, which is more fully reflected in the real characteristics. The result of OOA is to provide a platform for the selection and implementation of the rear stage class, organization and implementation of class hierarchies. Therefore, OOA analyzes the problem space analysis, eventually affects the functional implementation of the software, causing a large amount of avoidable repair work in the later stage of software development; and some redundant objects or structures will affect the class's selection, the overall structure of the program Or increase the unnecessary workload of programmers. Therefore, this paper focuses on its integrity and redundancy of OOA. Although OOA test is an indivisible system process, for the convenience of the narrative, in view of the OOA implementation steps raised in [2], the test is divided into the following five aspects: ☆ Test of the identified object ☆ Test of the identified structure ☆ Test of the identified topic ☆ Test object, structure, theme, etc. related to the defined service and message, the location of the test object, structure, theme, etc. in OOA results, see the picture below : 1 Test of the identified object: The object determined in OOA is an abstraction of the actual instance of the structure, other systems, devices, memories, and the person involved in the problem space (see [2]). Tests to it can be considered as aspects: 1.1 Whether the identified object is comprehensive, whether all the instances involved in the problem space are reflected in the identified abstract object. 1.2 The identified object has multiple properties. Only one property should usually be seen as other objects, rather than abstract, independent objects. 1.3 Variety of the common attributes of other instances of the instances that are identified as the same object. 1.4 Whether or not the same as the same object is provided or requires the same service, if the service changes with different instances, the identified object needs to decompose or use the inheritance to classify.
1.5 If the system does not necessarily maintain the information representative of the instance of the object, provide or obtain the service about it, the identified object is not necessary. 1.6 The name of the identified object should be as accurate, applicable. 2 Test of the identified structure In the COAD method, the determined structure refers to the organization of multiple objects to reflect complex instances and complex relationships in the problem space. The identified structure is divided into two types: classification structure and assembly structure. The classification structure reflects the general and special relationships of the examples in the problem space, and the assembly structure reflects the overall relationship between the instance and localization of the problem space. 2.1 Tests for the determined classification structure can be adopted from the following aspects: 2.1 For an object in the structure, especially in the high-level object, whether or not there is a special possibility that is different from the next layer object in the problem space, ie Can I derive a downward object. 2.1.2 For an object in the structure, especially in the same low layer, whether it is possible to abstract more generalized upper objects in reality. 2.1.3 For all identified objects, whether it is possible to abstract in the problem space to abstract the high-level object 2.1.4 high-level objects that completely reflect whether there is a high-level characteristic basis for high-level characteristics. Particularity 2.2 Test of the identified assembly structure starts from the following aspects: 2.2.1 Overall (object) and component (object) assembly relationships in accordance with the real relationship. 2.2.2 Overall (object) components (objects) have practical applications in considerations. 2.2.3 Whether it is missing in the overall (object) (object) (object) that is useful in the problem space. 2.2.4 Parts (objects) Can assemble new realistic overall (objects) in the problem space. 3 Test themes for identified themes are more abstractions based on objects and structures, to provide the visibility of OOA analysis results, such as an outline of the contents of each part. Tests for the subject layers should consider the following: 3.1 Implementing the "7 2" principle of George Miller (see [3]), if the number of topics exceeds 7, it is required to return the topics with close properties and services. 3.2 The item reflected by the subject has the same and similar properties and services. 3.3 Determined themes are abstractions of objects and structural higher layers, making it easy to understand OOA results (especially for non-technical OOA results readers). 3.4 Message Connection between the subject (Abstraction) represents all the associations between objects and structures reflected in the subject. 4 Test properties associated with the defined attributes and instances are the characteristics used to describe the instances reflected by the object or structure. The case association is a mapping relationship between the instance collection. Tests associated with properties and instances Consider: 4.1 The defined attributes apply to each real instance of the corresponding object and classification structure. 4.2 Defined attributes is closely related to this instance relationship with this instance. 4.3 Defined attributes is closely related to this instance relationship with this instance. 4.4 Defined attributes can be independently understood from other properties. 4.5 Defined attributes in the classification structure appropriate, whether the common attribute of the low-level object is reflected in the upper object attribute. 4.6 Whether the properties of each object in the problem space are defined. 4.7 Defined instance associations are in line with reality. 4.8 If the instance association is defined in the problem space, it is necessary to pay attention to 1- more and more-multi-instance associations. 5 Test defined services for defined services and messages is the behavior of each object and structure that define the problem space. Due to the necessary communication between the problem air instance, the message association needs to be defined in OOA (see [3]).
Tests for defined services and messages are performed from the following aspects: 5.1 Objects and structures define corresponding services in different status of the problem space. 5.2 The service required by the object or the structure defines the corresponding message association. 5.3 Defined Message Association The service guidelines are provided correctly. 5.4 Whether the thread that is performed along the message is reasonable, whether it meets the reality process. 5.5 The defined service is repeated, and whether the service that can be defined. Third, the object-oriented design method, the usual structured design method, "is a job-oriented design method, which makes system decomposition, put forward a group of jobs, these homework is based on process implementation system , Transform the analysis of the problem domain into the design of the solution domain, the results of the analysis are the input of the design phase "(see [1]). Object-Oriented Design (OOD) uses "viewing view", induction of OOA, and establish a class structure or further constructing a class library to achieve an abstraction of problem space. The class of OODs can be a simple continuation of the object, which can be the same or similar service for different objects. It can be seen that OOD is not a big way of simmering the way to OOA, but the further refinement of OOA and the higher level of abstraction. Therefore, the boundaries of OOD and OOA are usually difficult to distinguish. The OOD determination class and class structure not only meets the requirements of current demand analysis, but more importantly, it can facilitate the reuse and amplification of functions by re-combining or proper supplements, to facilitate the implementation of the user's requirements. Therefore, the test of OOD, this paper recommends the implementation and reuse of functions and expansion of OOA results, from the following three aspects: ☆ Test of the identified class ☆ Test of the class hierarchy of the structure ☆ Support for class library Test 1 Test OOD of the identified class can be an object that is determined in OOA, or an abstraction of the service required by the object, the object of the object. The identified classes should be based on basic as possible, so that it is easy to maintain and reuse. Refer to some guidelines made in [4] [5], the test identified class: 1.1 Whether it covers all identified objects in OOA. 1.2 Can I reflect the properties defined in OOA. 1.3 Can I achieve the services defined in OOA. 1.4 Whether to correspond to a meaningful data abstraction. 1.5 Whether or not to rely on other classes as possible. 1.6 Methods in Class (C : Member Functions of Class) are single-use. 2 Test of the class hierarchy of the structure is to fully utilize object-oriented inheritance sharing features, the class hierarchy of OOD, usually organize based on the principles of classification structure generated in OOA, focusing on the generality of the parent class and sub-class Specialty. For the conceptual differences, please see [1]. In the current problem space, the main requirements for the class hierarchy are structural frames that can implement all functions in the solution space. To this end, the test is tested: 2.1 The class hierarchy contains all the defined classes. 2.2 Whether it can reflect the instance association defined in OOA. 2.3 Whether the message association defined in OOA can be implemented. 2.4 Subcounds have new features that have no parent class. 2.5 The common characteristics between subclass is completely reflected in the parent class. 3 The test of the class library support for the support of the class library, although it is also organized by the class hierarchical structure, but its emphasis is the reuse of software development. Since it does not directly affect the current development and functional implementation of the current software, it is proposed separately, and it can be used as an assessment of high quality class hierarchies. Referring to the criteria proposed in [9], the prepared test point is as follows: 3.1 A group of subclasses regarding the same meaning or substantially the same operation, whether there is the same interface (including the name and parameter table).
3.2 Method (C : Member Function of C : Class) function is relatively simple, whether the corresponding code line is less ([5] is recommended to be no more than 30 lines). Whether the hierarchy of the 3.3 class is large and the width is small. Fourth, object-oriented programming (OOP TEST) typical object-oriented program has a new feature of inheritance, packaging, and polymorphism, which makes traditional test strategies must change. The package is hidden on the data, and the outside world can only access or modify the data by the operation provided, which reduces the possibility of any modification and reading and writing, which reduces the illegal operation of the data in the traditional program. Inheritance is an important feature of object-oriented programs, inherits the reuse rate of code, and also increases the probability of error propagation. Inheriting traditional tests have encountered such a problem: what should I test for the inherited code? (See the object cell test). Polymorphism makes the object-oriented programs exhibited powerful processing power, but at the same time, the behavior of the "same" function in the program is complicated, and the code and behavior of different types of specific implementation have to be considered when testing. Object-oriented program is distributed in the class. Correctly implement the functionality class, through message delivery to achieve the function of design requirements. It is this object-oriented program style that will have an error that can be accurately determined in a particular class. Therefore, in the object-oriented programming (OOP) phase, the rules of the functional implementation are ignored, and the testing gaze focuses on the implementation of class function and the corresponding object-oriented program style, mainly reflected in the following two aspects (assuming programming C language) . ☆ Data members meet the requirements of the data package ☆ Whether the class implements the required function 1 Data members meet the data package of data package is a collection of data related to data. Check if the data member meets the requirements of the data package, the basic principle is whether the data member is directly called directly by the outside world (invocation other than the class or subclass of the data member). More intuitive, when adapted the structure of the data member, whether it affects the external interface of the class, whether it will cause the corresponding outside world to be changed. It is worth noting that sometimes mandatory type conversion will damage the package characteristics of the data. For example: class hiden {private: int a = 1; char * p = "hiden";} class visible {public: int b = 2; char * s = "visible";} ... .. .... Hiden pp; Visible * QQ = (Visible *) & PP; in the above block, PP's data member can be accessed freely through QQ. Category 2 achieves the functions implemented by the required functional classes, are executed by a class of member functions. When the function of the test class is implemented, the correctness of the class member function should be guaranteed. A member function of a separate viewing class, with a function or process in the process procedure, or the process used in almost all traditional unit tests can be used in an object-oriented unit test. Specific test methods are described in the object-oriented unit test. The correct behavior of the class function member is just the basis of the capability of the class, and the role between the class member function and the service call between the class is unable to determine the unit test. Therefore, it is necessary to perform an object-oriented integrated test. Specific test methods are introduced in an object-oriented integrated test. It is necessary to focus on declaration, the function of the test class, cannot be only satisfied with the functionality that the code can be functioning or the function provided by the test class is nothing wrong, should be based on the OOD result, the function provided by the detection class meets the design requirements, Whether there is a defect. If necessary, if it is still unclear with OOD, it should be referred to the results of OOA, in which it is final standard.
V. Object-Oriented Unit Test (Oo Unit Test) The traditional unit test is a function, process, or block of the program, or a certain function. Concept along the unit test, actually test the class member function. Some traditional test methods can be used in object-oriented unit tests. For example, the specific implementation of the method, the path analysis method, the border value analysis method, logical coverage, path analysis, program plug-in method, etc. [6]. Unit test general recommendations are done by programmers. Test analysis (proposes corresponding test requirements) and test cases (select appropriate input, achieving test requirements), scale and difficulty, etc., are far less than later introducing the test analysis and test cases of the entire system And emphasizing that there should be 100% execution code coverage of the statement. When designing the input data, you can perform the following two assumptions: 1. If the function (program) is correctly executed correctly, other inputs in the same type can be executed correctly. This hypothesis can be found in the equivalence classification introduced in [6]. 2. If the function (program) is implemented correctly to a complexity input, the input to higher complexity can also be implemented correctly. For example, you need to select a string as an input, based on this hypothesis, there is no need to measure the length of the string. Unless the length of the string is required to be fixed, such as an IP address string. In object-oriented program, class member functions are usually small, functional single, and functionality are frequent, and there are some errors that should not find. For example: · IF (-1 == Write (Amount) Error_out (); This statement does not fully check the return value of Write (), unintentionally, assuming that only data is completely written and not written two Case. When the test ignores the case where the data is written, there is a hidden danger. · According to the design, use the function strrchr () to find the final matching character, but the function strchr () is written in the error program, so that the first match character is found when the program function is implemented. • IF (Str1, Str2, Str2)) is erroneous (Str1, Str2, Strlet, Strlen (STR2))). If the data STR1 and STR2 used in the test case are the same, it cannot be detected. Therefore, when doing test analysis and design test cases, you should pay attention to this feature of the object-oriented program, carefully test analysis and design test cases, especially for the function return value as the conditional judgment selection, string operation, etc. Object-oriented programming makes testing for member functions, and not completely equivalent to traditional functions or process tests. In particular, inheritance characteristics and polymorphism features, the problem of parent class members inheritance or overload has occurred in traditional tests. In [7], Brian Marick gives two considerations: 1. Do not test if the inherited member function does not need to test? According to the discussion in [7], the members of the members already tested in the parent class need to retest in subclasses: a) Inherited member functions have been changed in subclasses; b) member functions call The part of the changed member function. For example: assuming that the parent class BASS has two member functions: inherited () and redefined (), subclass derived only changes redined (). Derived :: redefined () Obviously requires retest.
For Derived :: inherited (), if it has a statement called Redefined () (such as: x = x / redefined ()), you need to retest, but in turn, there is necessary. 2. Can the test of the parent class be moved to a subclass? The assumption above, Base :: redefined () and derived :: redefined () are already different member functions, which have different service descriptions and execution. In this regard, the following should retest the Derived :: REDEfined () to design test cases. However, due to object-oriented inheritance makes the two functions have similar, just add the new test requirements and supplementary test cases for Derived :: Redfined () test requirements and test cases on Base :: Redefined () test requirements and test cases. For example: base :: redefined () contains the following statement if (value <0) Message ("less"); Else if (value == 0) Message ("equal"); Else Message ("more"); Derived :: Redfined () is defined as if (Value <0) Message ("LESS"); Else IF ("IT IS Equal"); Else {Message ("more"); if (value == 88) Message ("luck");} In the original test, the test to Derived :: redfined () is only required: the test results of value == 0 are expected to be changed; increase the value of value == 88. There are several different forms, such as parameter, including polymorphism, overload polymorphism. Contains polymorphic and overload polymorphisms generally reflect the inheritance relationship between subclasses and parent classes in the object-oriented language, and see the above-mentioned two polymorphisms in the above-mentioned pairing of parent class members function inheritance and overload. Contains polymorphism although the parameters of the member function can have multiple types, it is usually only added to the complexity of the test. When testing with a multi-state function, you only need to expand the type of input data in the test case on the original test analysis. The class test is performed on the class-oriented unit test, and the description of how to generate test cases from the MTSS will be referenced in [10]. 6. Object-oriented integrated test (OO Integrate Test) integration test, is tested by the bottom upward function module, which can generally be performed in the case where part of the program compilation is completed. For object-oriented programs, the mutual calling function is spreading in different classes of the program, and the class is applied and served through the message. The behavior of the class is closely related to its status. The state is not only the value embodied in class data, and may also include status information in other classes. It can be seen that the class is extremely close, and the class cannot be tested on the compiled incomplete program. Therefore, object-oriented integrated testing usually needs to perform after completion of the entire program. In addition, object-oriented programs have dynamic characteristics, and the control flow of the program is often unable to determine, so it can only be used for black box-based integration testing. Object-oriented integrated tests can detect errors when they cannot detect those interactions that cannot be detected relative to independent unit testing. Based on unit testing to the correctness of member function behavior, integrated test focuses only on the structure of the system and the internal interaction. Object-oriented integrated tests can be divided into two steps: advanced row static testing, and perform dynamic testing. Static testing is mainly for the structure of the program, and whether the detection program structure meets the design requirements.
Nowadays, some test software can provide a function called "reversible engineering" that obtains a class relationship diagram and function function call relationship diagram, such as the Panorama-2 for Windows95, Rational Software Automation. Rose C Analyzer et al, compares the results obtained by "Reversible Engineering" with the results of OOD, detecting the program structure and defects. In other words, the OOP has reached the design requirements in this way. Dynamic test design test case, usually requires the above function call structure diagram, class relationship diagram, or entity diagram as a reference, determine that the portion does not need to be repeated, thereby optimizing test cases, reducing test workload, making the test Reach a certain coverage standard. Testing the coverage criteria to be: reaching all the service requirements or services provided by the class; a certain coverage of all execution threads is achieved in accordance with the messages delivered between the class; a certain coverage rate of all the states of the class, etc. . At the same time, you can also consider using existing test tools to get the coverage rate of program code execution. Specific Design Test Examples, refer to the following steps: 1. First select the detected class, refer to the OOD analysis results, carefully out of the status, the information passed between the corresponding behavior, class, or member functions, and definitions of the input or output. 2. Determine the coverage standard. 3. Use the structural relationship diagram to determine all associations to be tested. 4. Construct the test case according to the objects in the program, confirm what input to the state of the input excitation, what behavior is used to use the service and expectations of the class. It is worth noting that when designing the test case, not only the input to design acknowledgment class feature, but also a consciously designed some of the prohibited examples, confirming whether or not there is irregular behavior, such as messages that are not adapted to the class state, Requires non-adaptable services, etc. According to the specific situation, the dynamic integrated test can sometimes be completed through the system test. Seven, object-oriented system test (OO System Test) can only ensure that software development is implemented by unit testing and integration testing. However, it cannot be confirmed whether it meets the needs of the user when actual operation, whether there is a large number of hidden dangers that will be induced under practical use. To this end, the software that is developed must be specified by the software. In order to change the software, the software that is completed is only an integral part of the actual input to the system, and it needs to be tested with the performance of other parts of the system to ensure that it works normally in the environment where the system is coordinated. In the following description of the ZXM10 transceiver system test, it can be seen that other system devices (such as monitoring stations, image meters, E1 access devices, cameras, etc.) How to cooperate with system testing of the sending station. System testing should try to build the same test platform as the user's actual use environment, should ensure the integrity of the measured system, the temporary system equipment components, should also have corresponding analog tools. When the system test, the results of the OOA analysis should be referred to, corresponding to the objects, attributes, and various services described, whether the software can fully "reproduce" problem space. System test is not only the overall behavior performance of the test software, but also from the other side, it is also a repudiation of software development design. The system test here is an abstract description of the test step. It reflects the specific test contents include: • Functional test: Whether the test meets the development requirements, it is possible to provide the functions described in the design, and whether the user's needs are met. Functional testing is the most common and necessary testing of system testing, usually in a formal software manual as test standards. · Strength test: The ability to test the system has the highest actual limit, that is, the software is in some oversight, and the function is implemented.
