The basis of software testing and noun analysis

First, the quality of software

　　1. Software Quality measurement methods

There are many methods of measuring software quality, which can be further divided into static mass characteristics and dynamic mass characteristics .

　　　　static mass characteristics refer to the actual code and related documentation. Includes structured, maintainable, measurable code, and correct and complete documentation.

　　　　The dynamic mass characteristic refers to the behavior that the software manifests in the use. Includes software reliability, correctness, integrity, consistency, ease of use, and performance.

　　2. Reliability of the Software

Definition one: Software reliability refers to the probability of a software failure-free operation at a given time interval and under a given condition (the probability of the definition refers to the distribution of the program input, which is often referred to as the Operation profile. By definition, the reliability of the software differs depending on the operating profile. ）

Definition II: Software reliability is the probability that the software operates without fault under the expected environmental conditions (this definition is only relevant to the correctness of the software function. Because there is no definition of the Operation section, the entire input field is considered to be evenly distributed. The environment refers to the hardware and software elements required to run the software, including hardware devices. The operating system and other required applications. ）

　　3. Correctness of the software

　　Correctness refers to the correct operation of a software and is usually related to some software documentation. It is a two-dollar metric, and the result is correct or incorrect

Second, testing and commissioning

　　Testing is a process of judging whether the software is running as expected. During the testing process, there may be errors in the software being tested. When the test finds an error, the process of determining the cause of the error and correcting the error is called debugging. Testing and debugging are two activities that are associated with each other.

Iii. measurement of measurement

"Measure" reflects a measurement standard. Includes organization-level metrics, project-level metrics, process-level metrics, and product-level metrics.

Iv. Testing and validation

Program verification is intended to prove the correctness of the program by demonstrating that the program does not contain errors. This is very different from software testing. Software testing is intended to expose errors that exist in the program. In other words, program validation is designed to prove that a program is functioning correctly for all input that satisfies the criteria, and software testing is designed to prove that a program is reliable, because no serious errors are found.

V. Management of defects

Defect management includes: defect prevention, defect detection, defect recording and reporting, defect classification, defect correction, defect prediction , etc.

At present, there are some tools for documenting defects and managing defect information, such as open source tools Bugzilla, Business Tools Fogbugz.

　　Defect Prevention is accomplished through a number of procedures and tools. For example, good coding techniques, unit test plans, and code reviews are important tools for the defect prevention process.

　　defect Detection is based on the failure of observation and discovery in dynamic test and static test, and identifies the defects caused by failure. In the process of discovering defects, it often involves debugging the code being tested.

　　Defect Classification : The identified defects are categorized and recorded in a database. Defect classifications help organizations to statistically defect information, such as defect types, frequency of occurrence, stages in the development cycle, design documentation, and so on, which are then passed on to the organization's process improvement teams, who analyze them to identify areas for improvement in the development process and recommend appropriate improvements to top managers.

　　defect Correction : Once each defect is recorded, it is marked with an "open" state, indicating that it needs to be corrected. There is no need to correct every defect found before the software is released, only those defects that seriously affect the company's business objectives (including the quality objectives) must be resolved before the software is released, and other defects can be resolved later.

　　Defect Prediction : Development organizations often conduct source code analysis to predict how many defects the software will have before it enters the testing phase.

Vi. Static Testing

The most important feature of static testing is that it does not need to execute the software under test. This is in contrast to dynamic testing, which needs to perform one or more software tests. Static testing can uncover flaws in the software at a fairly low cost, including the two semantics and errors in the requirements documentation and other software-related documentation. Static testing and dynamic testing are complementary.

　　Static code analysis tools provide control flow and data flow information that is useful for the review team to understand the code and to identify possible flaws. At present, there are some commercial and open source static analysis tools. IBM Rational's purify and Klockwork Company's klockwork are two commercially available static analysis tools for C and Java programs. Lapse is an open source analysis tool for Java programs.

Static tests include walk -through and review .

　　A walk -through is an informal process that examines all the documentation related to the source program code. For example, a requirement document is checked by a process called demand walk, and the source code is checked by code walk (also called Peer Code Review). Walk-through to generate a detailed report that lists information related to the document being looked up.

　　Review : Censorship is a more formal process than walk-through. The term is often associated with code. Many organizations believe that formal code review is a means of improving code quality at a lower cost than using dynamic testing. Several organizations have claimed that the use of code reviews has greatly improved productivity and software quality.

Code reviews are usually done by a single team, and the review team works according to the review plan. The review plan includes the following elements:

(1) The purpose of the review;

(2) The work product under review, including the source code and relevant documentation that needs to be reviewed;

(3) Review the composition, role and responsibilities of the Group;

(4) Review progress;

(5) Data collection form, which is used by the review team to record the defects found, the rules of coding violations, the time spent on the review work.

The members of the review team are divided into roles such as coordinators, readers, recording staff, programmers, and so on. The coordinator is responsible for the entire review and leads the entire review process. Read the source code by the reader, possibly with the help of a code browser and a large-screen display so that the code can be easily seen by the entire group of people. The recording staff records all the errors found and the issues discussed. Programmers are the actual developers of the code being reviewed, and their primary responsibility in the review is to help other members understand the code. The review process must be friendly and not confrontational.

vii. type of test (Black-box testing and white-box testing are the two most basic test techniques.) All of the following C2-C4 classification tests are either in the black box test category or in the White Box test category.

A classification framework is used to classify a large number of test techniques. The framework contains 5 classification factors for classifying test techniques that are part of the dynamic testing category. Each classification factor is a mapping from a collection of features to a collection of test techniques. Features include the basis of the test design, the problem of determining the test target, the life cycle stage, or the SOFTWARE PRODUCT. Here are 5 classification factors.

　　C1. Basis for test generation

　　　　Black box test:

Definition: In the absence of the tested software source code, according to non-formal or formal definition of requirements document design testing, this form of testing is generally referred to as black-box testing. If the requirements document is non-formalized, ad hoc technology or heuristics can be used, such as equivalence class partitioning and boundary value analysis

(Non-formalization) includes: ad hoc test, boundary value analysis, type Division, classification chart, causality diagram, equivalence class division, partition test, Judgment test, random test, grammar test and so on.

　　　　Model-based or spec-based testing:

Definition: When the requirements are formalized, model-based or specification-based testing can be applied, for example, by using one or more mathematical or graphical notation, such as Z, State diagram, event sequence diagram, to design the test according to formal specifications. This is also a form of black-box testing.

(formalization) Includes: State diagram test, FSM test, pair test, grammar test and so on.

　　　　White box test:

Definition: Refers to the design and evaluation of test cases using source code in test activities. White-Box testing techniques are rarely or almost impossible to isolate, because a test case contains test inputs and expected results, and testers must use the requirements documentation to design test cases. At any time, as long as someone claims they are using a white-box test, there is good reason to believe that they are actually using a combination of white box and black box test technology.

Including: adequacy evaluation, coverage testing, data flow testing, domain testing, mutation testing, path testing, structural testing, test optimization, etc.

　　　　Interface Test (belongs to black box test):

Definition: Test cases are usually generated using the interface of the component.

Includes: interface variation, pair testing, and so on.

　　C2. The software life cycle phase of the test

　　　　Unit Testing (Coding phase): programmers write code early in the coding phase, and before they integrate with other system components, they need to test their own code, a type of test called unit testing. In unit testing, programmers focus on developing units or small components, and the purpose of testing is to make sure that the unit works independently and correctly. Tests that are designed during unit testing are likely not to be used for integration and system testing.

　　　　Integration Testing (Integration phase): When some program units are integrated together, a large component or subsystem is formed, and the programmer needs to test the subsystem for integration. During the integration testing phase, the goal of testing is to ensure that a set of components can work as expected, and at this stage, some integration errors are often found. Tests that are designed in the integrated test phase may also not be used for system testing.

　　　　System Testing (System integration Phase): When the entire system is built, testing it is called a system test. The purpose of the system testing is to ensure that the system has all the desired functionality and can work as required by its requirements specification

　　　　Regression testing (Maintenance phase): software users report errors that often result in additional testing and debugging. Because the software changes are usually very small compared to the entire software, there is no need to test the entire system. In this case, regression testing is usually performed. The goal of regression testing is to ensure that the modified system runs correctly in accordance with its requirements specification. Of course, regression testing can only perform a subset of the entire system test case set. The selected regression test case includes use cases for testing the modified code, and for testing other code that might be affected by the modification.

　　　　beta test (subsequent systems, pre-release): Typically, a carefully selected group of users is tested before a software is formally marketed, and this form of testing is called beta testing.

　　　　Acceptance Test: for software delivered by contract, the contracted customer will conduct acceptance tests before making a final decision whether to purchase/deploy the software.

C3. targets for specific test activities

　　　　Functional testing:

　　　　Security Confidentiality test:

Robustness Test:　　　　 is to test the robustness of a software against an unexpected input. It differs from functional testing because the robustness test case is designed outside of the valid (or expected) input space, whereas in a functional test, the test case is derived from the valid input space.

As an example of a robust test-assuming that a software is required to perform a function on all x>=0 values, there is no provision for what the software should do when x<0. In this case, the robustness test should require that the software be tested against the x<0 scenario. Since demand does not specify the behavior of the software outside of the effective input space, there is a clear understanding of what exactly is robustness testing. In some software, robustness may simply mean that the software displays an error message and exits, while in other cases robustness may mean controlling the aircraft to achieve a safe landing.

Vulnerability Testing:　　　　 Its purpose is to detect the presence of software vulnerabilities to prevent unauthorized users from being able to invade the system under test. such as penetration testing. Vulnerability testing is a form of security confidentiality testing

　　　GUI Test:

Operation Test:

Reliability Test:

Intrusion detection:

stress test: During a stress test, the tester checks the behavior of the software under pressure. The purpose of the test is to find out whether the tested software can continue to operate correctly under the given pressure condition.

Performance test:　　　 is to test the software according to the expected performance requirements. For example, you might check whether a compiler meets the specified performance requirements, such as the number of lines of code compiled per second. Typically, performance requirements are addressed for specific hardware and software configurations.

Load test:　　　　 is to load one or more operations on the software to determine whether the software under test will continue to operate as required under different load conditions. For example, a request from a large number of impersonated users might be loaded on a database server. While the server works fine with only one or two users, there are a variety of ways to fail when the number of users exceeds a certain threshold.

In a sense, load testing is another form of stress testing. However, load tests can be used to pinpoint the performance of the software under test and the correctness of its behavior. The load test is some form of stress test when the test target is to check for functional requirements under load conditions and if the software being tested is running correctly. The load test is some form of performance testing when the test goal is to evaluate when the software performs certain operations under a given condition.

Load testing is also some form of robustness testing, primarily testing for unspecified requirements. For example, it may not be accurate to specify the maximum number of users the software can handle and what the software needs to do when the number of users exceeds a certain threshold, in which case the load test allows the tester to judge the threshold, and once the tested software has exceeded the threshold, it crashes into a state.

　　　　Acceptance Test:

Compatibility test:

Peripheral Configuration test:

Foreign Language testing:

C4. Characteristics of the software products being tested.

　　　　Testing techniques: Characteristics of software products under test

Component testing:　　　　 Application Components

equivalence class partitioning, testing based on a poor state model, and most of the other test generation techniques discussed in this book: Batch processing

　　　　c/S test: client/server

　　　　compiler test: compiler

　　　　Design test: Design

　　　　Coding test: encoding

　　　　Transaction Flow testing: Database system

　　　　oo Testing: OO Software

　　　　OS Test: operating system

　　　　Real-time testing: real-time software

　　　　Requirements Testing: requirements

　　　　Web Service testing: Web Services

C5. Test process Model

　　　Waterfall Test Model: tests are usually performed at the end of the development process, and static and dynamic test activities are not present until the end of the development process.

v Test Model:　　　　 testing activities are clearly defined at each stage of the development process, and design testing can be carried out once the requirements are obtained.

　　　　Spiral Test: It is applied to software increment test, which is proposed for evolution software development. Each software increment is a software prototype that finally forms the software that is presented to the user. It is a test strategy that can be applied to any incremental software development process, especially from the prototype system to the final application system. In the spiral test, the complexity of the test activity increases with the evolution phase of the prototype system.

Agile Testing:　　　　 applied to Agile software development methodologies, such as extreme Programming (XP). Agile testing promotes the following ideas.

(1) To include testing-related activities throughout the development of the project, starting from the requirements analysis phase;

(2) work closely with customers to define requirements in a test-based manner;

(3) Testers and developers collaborate with each other, not their opponents;

(4) Regular testing, a small amount of testing.

Test-driven development:　　　 Define requirements as test cases

Viii. Fundamentals of Software Testing

　　test builds, test evaluations, and test enhancements form the basis of software testing.

　　

The basis of software testing and noun analysis