Software Testing Training notes

Unit Testing and continuous integration practices 201409

1.Quality): The degree to which a set of internal features meet the needs; the degree to which a system, component, or process meets the specific needs (customer or user needs or expectations.

Software Quality Management: Determine the quality objectives of a software product, establish plans to achieve these objectives, supervise and adjust the software plans, software work products, activities and quality objectives, to meet the needs and expectations of customers and end users.

Quality Management (QM) is generally mentioned in software enterprises in two aspects: quality control (QC) and quality assurance (QA ).

QC mainly refers to document review, code review, unit testing, integration testing, system testing, and acceptance testing.

Quality assurance (QA) mainly refers to the process review, product audit, and other monitoring of intermediate processes and work product quality to ensure that the final product quality meets the requirements.

In some cases, QC and QA refer to roles. For example, testers are called QC roles, while QA engineers are called QA roles.

In addition to quality control and quality assurance, quality management (QM) also includes determining quality policies, objectives, and responsibilities, quality system construction, quality planning, quality improvement and other activities (EPG (Quality System Construction) work ).

QC processes include: (1) Check of various documents; (2) review of various documents; (3) code review; (4) unit test; (5) integration testing; (6) system testing; (7) Acceptance testing; (8) quasi-production/production testing.

2.Unit Test (UT): Tests the correctness of the program module, the smallest unit of software design. The purpose is to discover possible internal errors in each program module.

If we compare all testing steps to cleaning a machine: (1) system testing is to clear the dust outside the machine; (2) integration testing is to ensure that the joints of each part of the machine are clean; (3) unit testing is to clean the interior of each part.

Objective of unit testing: (1) to reduce the quality cost of enterprises by moving forward the elimination of defects; (2) to discover defects as early as possible, and to save the total project workload; (3) and the essence of quality improvement-eliminate defects as soon as possible.

Four elements of software project management: cost, scope, progress, and quality.

The most important task for a project manager during project management is to balance the four elements of the project.

3.Introduction to unit test methods:

What is a unit? (1) Object-oriented software development: the class (class) method is used as the minimum unit for testing. Taking the internal structure of the method as the focus of testing; (2) Structured Software Development: using modules (functions, processes) as the minimum unit of testing.

Unit Test content: (1) code review (static unit test); (2) unit-oriented black box test (Unit function test); (3) unit-oriented white box testing (unit coverage testing ).

Unit tests are the basic responsibilities of programmers and the basic professional competence of programmers. They must be responsible for their own code. In addition to coding and unit testing (static and dynamic), coding personnel also include integration testing, participation in system test case analysis, and assistance in project management.

4.Planning of Unit Testing: The unit test process should be fully taken into account during project testing and sufficient time should be provided for each process: (1) unit test plan; (2) unit test design; (3) unit test implementation; (4) unit test execution; (5) unit test evaluation. The QA and Project Manager of the above activities should verify the existence of these plans when checking the project plans.

Unit Test Plan: Time Schedule; workload; task allocation; resource arrangement; test tool; end standard (quantitative criteria can be set); risk analysis (such as compressed workload and insufficient skills ); risk Response; output unit test plan documents.

Unit Test Design: test the unit, relationship between the tested Unit and other modules, test policy selection, test case design, and unit test code design; output The unit test case document.

Unit test implementation: Write test cases, write test scripts, test-driven build, Pile Build, output test cases, and output test code and scripts.

Unit test execution: Build a test environment, execute test scripts, record test results, track defects, perform regression tests, and output unit test reports.

5.Unit Test Cropping: It is not recommended to cut down the entire unit test.

Cropping strategy for unit test: (1) range cropping; (2) process cropping.

Unit Test Range pruning. If the test time is not enough, the following sections should be given priority: (1) achieve the most important functions for the project objectives; (2) most common functions for users; (3) functions that have the greatest impact on system security performance; (4) functions that are most related to "money"; (5) functions that are most important to users; (6) the part that can be tested early in the development process; (7) the most complex part of the code; (8) the most hasty part of development; (9) part or related part that causes problems in the previous version or similar projects; (10) part or related part that consumes a large amount of maintenance costs in similar projects; (11), requirements or unclear parts in the design; (12) the parts that developers think are most likely to have problems; (13) the parts that will cause the biggest losses to customers if problems exist; (14) the portion that causes the maximum maintenance cost if any problem occurs; (15) the portion with the highest risk/time ratio.

6.Unit Test tracking and monitoring:

Form of tracking and monitoring: (1) holding weekly project meetings (best practices): completion of the week, plan for the next week (obtain commitment), and risk issues; currently, various qualitative and quantitative indicators are monitored. Progress, workload, scope, quality, risk issues, commitments, Data, key software and hardware resources, personnel participation, etc. (2) Convening of project milestones: results of phase work; whether or not to carry out the work plan in the next stage; monitoring of qualitative and quantitative indicators in the stage; risk issues, etc.; (3) event-driven.

Two major items of project tracking and monitoring: (1) schedule: whether the task ends at the required time; (2) quality target table: whether the task meets the standards for completion.

The new concept of project tracking and monitoring: the combination of quality objectives and progress tracking.

7.TDD test-driven development(1) TDD uses testing as the programming center. It requires that you first write a test case that defines the code function before writing any code, and constantly carry out restructuring and optimization; (2) TDD is not for comprehensive testing, but to improve the development efficiency while ensuring the quality. Test-Driven Development emphasizes that testing should not be a burden, but a method to help reduce the workload.

The basic process of TDD test-driven development: (1) define the functional requirements of an application and record it into a todo list; (2) be familiar with the functional areas of the application, determine the individual functional items or functional requirements to be used; (3) create a test list of verification requirements; (4) define interfaces and classes for functions or requirements; (5) write test code; (6) Run test cases fail; (7) Write/modify product code based on test; (8) run the test until all tests pass; (9) organize and refactor the code and run the test code. (10) Repeat the preceding steps.

TDD is not just a testing technology, but it is not just used to test code. TDD is an object-oriented development method. (1) TDD is an analysis method first. It forces programmers to think carefully about what to do and what not to do, especially exceptions, and write them down in the programming language. This is like a clear formal contract between the programmer's task and the programmer. (2) TDD is a design method. The programmer must clearly define the acceptance criteria of the program before writing its function test. At this time, the programmer does not need to clear how internal implementation is implemented. Programmers only need to consider the class interface and functions. This is not an object-oriented encapsulation design. (3) TDD is a reconstruction and optimization method. We always hope that the code can be beautiful and run efficiently, so we will constantly improve it.

Best practices for test-driven development: (1) simplified: Keep test cases and source code as simple as possible, with business verification as the primary goal; (2) business-oriented: functional testing, test each business scenario to be verified, instead of testing every method of the Code. (3) test isolation: each test class can be run independently and independent from other tests; it can also be executed together without interfering with each other to improve the maintainability of the case. (4) test list: list all required tests before development, this list is constantly maintained during development to avoid forgetting some necessary tests. (5) timely reconstruction: the developed unit test and function code must be constantly reconstructed, improve code readability, maintainability, and reduce redundant code; (6) Reverse Engineering: In some development environments, such as javassse, you can use the reverse engineering capabilities provided by IDE to automatically generate necessary classes and methods from the test code. (7). Code comments: separate documents are not required, in the test class, the business scenario corresponding to each test method, and the input and expected output are described in detail. (8) small steps forward: When the function unit is large To reduce the difficulty, it can be divided into multiple smaller functional units and implemented one by one using TDD.

Compiling TDD test cases: using traditional functional testing technology, centralized functional testing, centralized testing of vulnerable modules. (1) The case should be simulated as much as possible in normal use scenarios, and the white box content should be considered after in-depth testing and testing cases. The difficulty of TDD can be adjusted through the depth of test cases; (2) full functional tests should be conducted to achieve normal values, boundary values, and abnormal values as much as possible; if necessary, the core code, it is best to overwrite white box statements, branches, and paths. However, we also need to consider the situation where the case and code are too similar and difficult to maintain; (3), test cases and test data should be as simple as possible and easy to understand; (4) to avoid too much dependency on other code, simple pile functions can be implemented; (5) if the internal status is very complex or the process should be judged rather than the status, you can verify it by outputting the log string.

TDD is only applicable to functional engineering projects. It is not applicable to some exploratory development with uncertain input and output, such as the development of cryptographic systems, artificial intelligence, and security.

8.White box testing(1) test basis: tests are performed based on the internal structure of the program, such as the statement control structure, inter-module control structure, and internal data structure. (2) Advantages: ability to perform coverage tests on specific parts inside the program; (3) Disadvantages: Unable to test the external characteristics of the program, and unable to test the internal defects of the program that does not implement specification instructions; (4) method example: Statement overwrite, decision overwrite, condition overwrite, decision/condition overwrite, and path overwrite.

Several common white-box logic coverage methods: (1) statement coverage; (2) decision coverage; (3) condition coverage; (4) Decision-condition coverage; (5), path overwrite.

Statement overwrite: During the test, several test cases are designed first, and then the tested program is run so that each executable statement in the program can be executed at least once. The "several" mentioned here are of course the fewer the better. The statement is covered in the tested program. Apart from the function of checking non-executable statements, the risk of inclusion errors in the tested program is not ruled out. Because the program to be tested is not a disordered accumulation of statements, there are indeed many organic links between statements.

Decision coverage: Testing Based on the decision coverage criteria refers to the design of several test cases to run the tested program, so that each of the true branches and false branches in the program will go through at least one time, that is, the true or false values are satisfied.

Conditional coverage: it refers to the design of several test cases. After the tested program is executed, the possible values of each condition in each judgment must be met at least once.

Decision/condition coverage: Design sufficient test cases so that all conditions in the judgment may appear at least once, and each judgment result may also appear at least once.

Path coverage: Testing Based on the path coverage requirement refers to designing enough test cases to cover all possible paths in the program.

It can be seen that all kinds of structure testing methods cannot ensure the correctness of the program, and multiple methods must be combined. We can review the code to supplement the unit test to reduce the difficulty of the unit test.

The test is to select errors as much as possible, rather than to prove that the test object is correct.

9.Black box testing(1) test basis: based on the specifications that you can see, that is, the relationship between the output data of the input data domains and the user interfaces such as commands, information, and reports, in particular, it is used to test functions. (2) advantages: it can be tested from the user's standpoint. (3) Disadvantages: it is not allowed to test specific parts inside the program. If the Specification Description is incorrect, it cannot be implemented. (4) Example of the method: equivalence classification, edge value analysis, and cause/effect analysis.

Equivalence Class: (1) Division of equivalence classes: a typical black box testing method. The internal structure of the program is not taken into account when designing test cases. (2) method: divide the input field of the program into several parts, and then select a few representative data from each part as a test case. Valid and invalid equivalence classes. (3) reason for selection: the number of cases for the exhaustive test is too large to be completed. We were prompted to select part of the many cases as test cases.

Valid equivalence classes refer to a set of meaningful and reasonable input data that describes program specifications. Effective equivalence classes can be used to check whether the program has implemented the specified functions. Valid equivalence classes can be one or multiple.

Invalid equivalence class refers to a set of unreasonable or meaningless input data that describes program specifications. Invalid equivalence classes can be used to test the program's fault tolerance capability. There must be at least one or more invalid equivalence classes.

Principles of equivalence classification: (1) if the input conditions specify the value range or number of values, a valid equivalence class and two invalid equivalence classes can be determined. (2) if the input condition specifies the set of input values or specifies the condition of "what must be done", a valid equivalence class and an invalid equivalence class can be determined. (3) If we know exactly what, if the elements in a divided equivalence class have different processing methods in the program, the equivalence class should be further divided into smaller equivalence classes.

10.Improved unit test(1) unit testing is to test the correctness of software design units, namely large units (Improvement 1. The purpose is to discover possible internal errors in the "Large Unit" module. (2) Professional testers and developers pair each other one by one (improved by 2); (3), black box first, and then assist in white box analysis to supplement the test case (Improvement 3 ).

11.Static unit test: Code Review (Code Review), a process of improving the code quality by reviewing the Code. Code review is commonly known as "static unit test". In other words, you can help that colleague to check the Code he wrote and check the code for him.

Code review requires proper code stability. Because code review may modify code on a large scale, previous unit tests may fail, so they should be placed before unit tests.

The problems found during code review are internal logic problems. The content and effect of the test cannot be replaced by external tests such as system tests and acceptance tests. The lack of code review links leads to less powerful links in quality control.

Select different automated code review tools, such as PMD, findbugs, sourcemonitor, C ++ test, jtest, findbug, and checkstyle.

12.Pair Programming: Two programmers work in front of a computer. One engineer is responsible for typing the code, and the other one is responsible for checking the code of each line in real time. The programmer who operates the keyboard and mouse is called the "driver" and the programmer who is responsible for real-time review and assistance is called the "Pilot ". The navigator must also consider the next work direction, such as possible problems and improvements.

13.Configurationmanagement (cm): A set of standardized management and supervision methods using technical and administrative means, including marking the functional and physical features of configuration items, and documenting them; controlling changes to these features; report the change progress and implementation status, and verify the consistency with the specified requirements.

Configurationitem (CI): a specified entity for configuration management. Includes all components of the software product (technical documents, computer programs, data files, and sub-contractor software components. For example, source code, Execution Code, system environment definition, database definition, parameter file, Compilation Program, Data Conversion Program, and installation program ).

Baseline: describes one or more configuration items and related entities that constitute the configuration items. It is generally formed at the end of each stage of the project or product process, the formation mark is that one or more software configuration items are recognized through verification and validation. Baselines provide a stable foundation for continuous evaluation of configuration items.

Version: a set of configuration items at a specific point or time.

The purpose of configuration management (CM) is to establish and maintain the consistency and integrity of work products in the product life cycle through configuration identification, configuration control, configuration status report, and configuration audit.

Configuration Management libraries: (1) development libraries: development work environments for individual developers only, managed by the developers themselves; (2) configuration libraries: it is used to store and manage work products controlled by changes for the joint use of the project team, team, and related personnel. It is managed by the version administrator. (3) Product Library: used to store and manage software products that have formed a product baseline and can be released. The company has only one product database, which is the only source for releasing software products to customers. (4) build a database: an environment for building products (generating code from source code, the version Administrator is responsible for management and cannot perform changes during the build process. The consistency between source code and Execution Code must be ensured. (5) Test Database: Environment for product testing, the version Administrator is responsible for management, including building a test environment and updating versions in the test environment; (6). Configuration Management Library: the development library, configuration library, build library, Test Library, and product library are collectively referred to as the configuration management library.

14.Product integration: Includes three main activities: planning, integration, and release. Manage interfaces while integrating.

Key elements in the plan: integration scheme, integration sequence, integration environment configuration, and build scheme.

Integration goals: connect the separated components or subsystems produced by module encoding into a unified system.

Interface management goals: ensure the compatibility between interfaces and reduce the possibility of integration failure.

15.Continuous integration (continuousintegration, CI): Is a software development practice, that is, the team development members often integrate their work. Generally, each member is integrated at least once a day, which means that the integration may occur multiple times a day. Each integration is verified through automated build (including compilation, release, and automated testing) to detect integration errors as early as possible.

Continuous integration requires developers to submit their finished work products frequently at least once a day, sometimes multiple times. Each integration performs as fast as possible verification by means of automated build to ensure that changes submitted do not cause new problems. If an exception occurs during the integration process, it should be quickly reported to the relevant personnel.

Build is the process of putting the source code together and verifying that the software can run as a consistent unit; verification activities generally include compilation, testing, review, and deployment.

Value of continuous integration: reduce risks, reduce repetitive processes, generate deployable software anytime and anywhere, enhance project visibility, and build team confidence in developing products; free test expert-compiler.

Continuous integration elements: unified code library; automatic building; automatic testing; each person submits code to the main code library every day; after each code submission, the building is triggered on the continuous integration server; ensure rapid building; simulate Automatic Testing of the production environment; everyone can easily obtain the latest executable applications; everyone is aware of what is happening; automatic deployment.

Continuous integration principle: All developers need to build locally on the local machine and then submit the version control library to ensure that their changes do not cause continuous integration failure; the developer submits code to the version control library at least once a day. The developer must update the code to the local machine at least once a day from the version control library; A dedicated integration server is required to execute the integration build. The build should be performed multiple times every day. Each build should be 100% passed. Each build can generate a release product; building that fails to be repaired has the highest priority.

Continuous integration version 2: only one source code warehouse is maintained; Automatic Build; allow your build to be tested by yourself; each person submits code to mainline every day; every submission should re-build mainline on the integrated computer; maintain quick build; so that everyone can easily obtain the latest executable files; everyone can see the progress; automatic deployment.

Continuous integration of hierarchical management models, including building management, system deployment, automatic testing and analysis reports, throughout the entire process of software development.

Automated building tools: apacheant, phing, and Nant.

Ci)(1) CI requires the development team to integrate development and testing work frequently to detect problems as early as possible and reduce project risks; (2) CI is actually composed of a series of best practices: Version Control and Management of source code, daily building, Smoke Testing, code review, automatic deployment, etc. (3) continuous integration provides fast feedback on product quality to ensure that you have software products that can work at any time.

Benefits of continuous integration: (1) eliminate defects as early as possible to avoid a large number of problems during integration and reduce quality costs; (2) deliver to customers, generate software that can be deployed at any time and anywhere; (3) enable early system testing and early intervention by testers; (4) use a free tester-compiler; (5) ensure a good development environment and improve development efficiency; (6) reduce the cost of project management (especially Version Management) by about 10%; (7), increase project management visibility; (8), reduce project risks.

Agile Development emphasizes UT and CI, and best practices for agile development: (1) incremental iterative development; (2) development mode for customer delivery; (3), priority sorting of requirements (product to-do list); (4) splitting tasks into fine-grained management methods (multi-level project planning); (5) daily standing meetings during project tracking and monitoring (no more than 15 minutes); (6) Publicity of tracking and monitoring (Kanban and burnout chart), to avoid loose and tight before the project; (7) Strengthen unit testing and code review, emphasize test driven development and TDD; (8) introduce continuous integration and other development environments (continuous integration ); (9) guide the customer to actively participate in the development process (the customer is closely involved); (10) When the scale is small, the communication requires no document-driven, follow-up documents; (11) encourage project team members to take the initiative to learn the capabilities of the project's defined processes; (12) continuous process improvement (adaptive, sprint review meeting ).

 

Software Testing Training notes