<>1, Basic knowledge of software testing

<>1.1, Purpose of software testing

* Testing is the execution of a program , The purpose is to find errors
* A successful test case is to find errors that have not been found so far
* A successful test is one that finds errors that have not been found so far
* Ensure that the product performs the functions it promises or publishes , And the functions that users can access have clear written instructions .
* Ensure products meet performance and efficiency requirements
* Ensure products are robust and user friendly
<>1.2 Software testing principles

* Early intervention testing
* The test case consists of two parts: the input data and the corresponding expected output results
* Programmers should avoid checking their own programs
* When designing test cases , Include reasonable input conditions and unreasonable input conditions
* Attention deficit is clustered
* Strictly implement the test plan , Eliminate the randomness of the test
* pesticide paradox
* Every test result should be checked comprehensively .
* Safekeeping of test plan , test case , Error statistics and final analysis
<>1.3 Classification of software testing

<>1.3.1 Static test and dynamic test

* Static test : Not actually running the software under test , Check program code only , Errors in the interface or document
* dynamic test : Actually running the tested software , Input the corresponding test data , Check whether the output is consistent with the expected result
* The unique judgment standard of static test and dynamic test : Whether the tested software is running
<>1.3.2 Black box test and white box test

* Black box test : Treat the tested software as a black box , Only input data and output results are concerned Functions and performance commonly used in software
* White box test : hold “ Box ” Open source code and program structure in research software Source code commonly used in software
<>1.4 Software test model

<>1.4.1 V Model

<>1.4.2 W Model

<>1.4.3 H Model

<>1.4.4 X Model

<>1.4.5 Advantages and disadvantages of each model

Model name advantage shortcoming
V Model 1. Existing ground floor test , There are also high-level tests
2. Easy to control the development process , When all phases are over , Software development is over 1. Test intervention too late , When the demand changes , Heavy workload
2. Test after coding ,bug Not easy to find
3. Iteration not supported , Spontaneity and change adjustment
W Model 1. Test throughout the software development life cycle , demand , Design , Code and so on should be tested
2. Earlier involvement in software development , Early detection of defects
3. Test and development are independent , Parallel with development 1. High requirements for requirements and testing technology , Practical difficulties
2. Iteration not supported , Spontaneity and change adjustment
H Model 1. Separate testing from development , Divide the test into test preparation and test execution , Start the test as soon as the trigger point is triggered
2.H Model takes efficiency and flexibility into account , It can be applied to software projects of various scales and types hear nothing of , Cool after the test
X Model hear nothing of , Cool if you get it hear nothing of , Cool after the test
<>1.5 Test case and test environment

* test case = input + output + testing environment
* testing environment = Software + Hardware + network
* 4W :why when who what
*
<>2, Software testing process

<>2.1 Software testing process overview

<>2.1.1 Software testing process

* test plan
* Test design
* Test Development
* Test execution
* Test evaluation
<>2.1.2 Testing by stages

* unit testing : Check and verify the smallest testable unit in the software .
* integration testing : Will have passed The tested unit modules are assembled into a system or subsystem , Retest , Focus on testing the interface parts of different modules .
* Confirmation test : Check whether the implemented software meets the requirements specified in the requirements specification , And whether the software configuration is complete , correct .
* System test : It refers to the whole software system as 1 Test as a whole , Including functions , performance , And the software and hardware environment in which the software runs .
* Acceptance test : Let users test the software , Ensure no new errors are introduced
<>2.2 unit testing

<>2.2.1 Unit test time

* After programmer coding , Unit test after code is compiled
<>2.2.2 Unit tester

* White box test engineer , Developers , When developers test , Cross test shall be carried out
<>2.2.3 Unit test basis

* source program , code , notes
* 《 detailed design 》 file
<>2.2.4 Unit test pass criteria

* Use case for program passing all unit tests
* Statement coverage reaches 100%
* Branch coverage reaches 85%
<>2.2.5 How to conduct unit test

* Unit test mainly adopts white box test , Check whether the code conforms to the plan statically , Run the code dynamically again , Check operation results ( invalid data , Boundary treatment, etc )**
<>2.3 integration testing

<>2.3.1 Integration test time

* theory : After unit test ( Low efficiency )
* actual : Unit test and integration test are carried out synchronously , Test the function of several functions first in unit test , And then integrate and test the interfaces of these functions ( I.e. parameter passing )
<>2.3.2 Integration test personnel

* White box test engineer , Developers , When developers test , Cross test shall be carried out
<>2.3.3 Integration test basis

* Unit test module
* 《 detailed design 》 file
<>2.4 System test

<>2.4.1 Characteristics of system testing

* It takes a lot of time and energy ( The last gateway delivered to the user for acceptance test )
* Loosen and tighten before testing , Heavy testing work in the later stage
<>2.4.2 Basis of system test

* 《 System requirements specification 》 file .
<>2.5 Acceptance test

<>2.5.1 Importance of acceptance tests

* It involves whether the user can sign and pay for the final acceptance .
<>2.5.2 α test

* By user , Tester , open Internal test with participation of developers .
<>2.5.3 β test

* Public test on the back of the inner side , I.e. it is completely handed over to the end user for testing .
<>2.6 Comparison of various tests

Test name Test object Test basis Tester test method Time scale
unit testing The bottom module of software detailed design White box test engineer
Or developers Mainly white box 1
integration testing Interface between software modules Outline design White box test engineer
Or developers Combination of black box and white box 2
System test overall system Requirements specification Black box test engineer Black box test 4
Acceptance test overall system Requirements specification Mainly for users , still
Possible test engineer Black box test 2
<>3, Black box test

<>3.1 Division of equivalent classes

​ Equivalent class refers to an input field ( Output field ) Subsets of . In this subset , Each data is equivalent to the program , That is, each data can represent other data of this kind

<>3.1.1 Principle of equivalence class division

* Completeness : The whole set is divided into several disjoint subsets
* No redundancy : Disjoint subsets
<>3.1.2 Effective equivalence class and invalid equivalence class

* Effective equivalence class : For software specifications , It makes sense , Set of reasonable input data , Used to verify pre-defined functions and performance
* Invalid equivalence class : For software specifications , It's meaningless , Set of irrational input data , It can identify the situation of program exception handling
<>3.1.3 The steps of designing test cases by dividing equivalence classes

* Dividing effective equivalence class and invalid equivalence class
* Establishing equivalence class table
* Design test cases , As many covering effective equivalence classes as possible
<>3.1.4 An example of equivalence class design test case

<>3.2 Boundary value analysis

​ A black box test method for testing input or output boundary values , Test cases come from the boundary of equivalence classes

<>3.2.1 Design idea of boundary value method

*
Determine boundary conditions , Focus on testing boundaries

*
The value should be equal to , Just larger or just smaller as test data , Do not select the typical value or any value in the equivalence class

Value of some data :

<>3.2.2 Example of boundary value method

among , Each box is a test of a boundary

<>3.3 Decision table method

In all black box test methods , Based on decision table ( Judgment table ) Is the most stringent , The most logical test method

<>3.3.1 Advantages of decision table

* Simplify complex problems , And avoid omission
* It is very suitable for dealing with multiple logical conditions
<>3.3.2 Composition of decision table

* Conditional pile : List all conditions for the problem
* Condition item : List all possible values for conditions given by condition piles
* Action pile : List possible values specified for all problems
* Action item : List the actions to be taken under conditions

<>3.3.3 Merging of decision tables


In the decision table , If two or more action items are the same , Only one condition item is different ( When the condition pile can go to multiple values , All possible values need to have ) You can merge this item , For merging condition items with different values “-” express , Get the final decision table

​ example :

<>3.3 Figure method for cause

<>3.3.1 Causes of causality diagram

​ Equivalence method , The boundary value method focuses on the input conditions , Various combinations of input conditions are not considered , The mutual restriction between input conditions
, Possible errors after multiple conditions are combined are ignored , And there's a cause and effect diagram ( logical model )

<>3.3.2 The advantages of causality diagram

* Considering various combinations of input conditions and constraints
* Help testers follow certain steps , Efficient development of test cases
* Strictly converting natural language specification to formal language specification , Point out the incompleteness and ambiguity of specification
<>3.3.3 The basic sign of causality

<>3.3.4 Constraint symbols in causality

PS:

* E constraint ( different )(Exclusive Exclusive ):a and b At most one of them may be 1, Namely a and b Cannot be both 1
* I constraint ( or )(In):a,b,c At least one of must be 1, Namely a,b,c Cannot be both 0
* O constraint ( only )(Only):a and b There must be one and only one for 1
* R constraint ( requirement )(Request):a yes 1 Time ,b Must be 1, Namely a by 1 Time ,b Cannot be 0.
* M constraint ( force )(mandatory): If the result a by 1, Then the result b Force to 0
<>3.3.5 An example of causality diagram test

*
Specification of analytical procedure , List the cause and structure

*
Draw a cause and effect diagram

*
Convert cause and effect diagram to decision table

*
Design test cases

<>4, White box test

<>4.1 Logical covering method

<>4.1.1 Statement override (SC)

Execute at least once per statement

example :

<>4.1.2 determine ( branch ) cover (DC)

Not only once per statement , Every possibility of every decision ( True and false ) It's all done once

example :

<>4.1.3 Conditional coverage (CC)

All possible values shall be taken for each condition determined

It's not to say that if the condition coverage is satisfied, the decision coverage must be satisfied , Or if the decision covering is satisfied, the condition covering must be satisfied

example : You can see , Where the path is not completely covered , The decision is not covered

<>4.1.4 Conditional decision coverage (CDC)

At the same time, the decision coverage condition is satisfied

<>4.1.5 Conditional combination coverage (MCC)

Design enough test cases , The combination of all possible conditional values of each decision in the tested program shall be executed at least once .

example :

<>4.1.6 Comparison of various coverage methods

<>4.2 Basic path test

<>4.2.1 Basic path test method

* Draw the control flow chart of the program
* Even if the program's cyclomatic complexity ( Determine the maximum number of test cases )
* Determine the independent path of the program
* Design test case input data and expected output
<>4.2.2 Control flow chart

* node : Nodes are represented by labeled circles , Represents one or more statements , A processing box and a conditional decision box
* Control flow line : Represented by an arc or line with an arrow , Called edge

<>4.2.3 Cyclomatic complexity

Number of basic independent paths used to calculate a program

A method to calculate the cyclomatic complexity

* V(G)=E-N+2,E Is the number of edges in the graph ,N Is the number of nodes in the graph .
* Circle complexity is defined as the number of regions in the control flow graph
* V(G)=P+1,P Is the control flow diagram G Medium decision ( predicate ) Number of nodes .
<>5, performance testing

Don't know how to review , Read a Book

Technology
©2019-2020 Toolsou All rights reserved,
c Language rose advertising code ( Essence )2020 year 7 month 15 day Wechat applet import and include difference Theory and formula derivation of univariate linear regression and multiple linear regression about Bellman-Ford Personal understanding of algorithms use VS2019 “Windows Desktop applications ” Module creation Win32 window The shortest path of maze BFS algorithm (python realization )Python read Excel A column | Transfer deposit json( Essence )2020 year 6 month 26 day C# Class library GUID Help class java Compile time and runtime exceptions in ( Essence )2020 year 6 month 26 day C# Class library Exception handling help class