1. Test mainstream skills

A functional test 、 automated testing 、 The interface test 、 Performance testing

2. Common test classification

By stages ： unit testing 、 Integration testing 、 The system test 、 The acceptance test

By code visibility ： White box testing 、 Grey box testing 、 Black box testing

unit testing ： Test the program source code （ Development ） Fundamentals of software testing ( One ): unit testing - You know (zhihu.com)

Integration testing ： Also known as interface testing , It mainly tests the interface between modules or between systems Introduction to software testing series 10 ： Integration testing - You know (zhihu.com)

The system test ： Comprehensively verify the software （ function 、 compatible 、 file ） Fundamentals of software testing ( 3、 ... and ): The system test - You know (zhihu.com)

The acceptance test ： Use internal test and public test to realize . Internal measurement ： Testing inside the company , Public survey ： Let players test . The acceptance test _ Luca brasi program _ Ting's blog -CSDN Blog _ The acceptance test

White box testing ： Also known as unit testing （ Test the program source code ） Introduction to software testing series 26 ： White box testing - You know (zhihu.com)

Grey box testing ： Also known as interface testing （ Can't see part of the code ） software test Grey box testing _w3cschool

Black box testing ： Also known as functional testing （ Completely invisible program source code , Verify only for functions ） software test —— Black box testing _ 24 string blog -CSDN Blog _ Black box testing

The key points of system testing and black box testing are A functional test

Test and integration test is also called gray box The interface test

Unit testing and white box testing are right Code To test

Automated testing A functional test

Performance testing 、 Safety test attribution Special tests

Expand ： The test strategy

Smoke testing ： Before large-scale testing , Verify the main function of the program , Ensure that the program is testable .

Interview questions ：

         What is the test standard ？ -- Smoke test passed

        What to do before testing ？-- Smoke testing

3. Quality model

Software quality model （ISO/IEC 25010）： The quality model provides the basis for test design Different angles of view And verification direction .

        Functionality 、 Performance efficiency 、 Compatibility 、 Ease of use 、 reliability 、 Information security 、 Maintainability 、 Portability

        Functionality ： Whether the software functions meet the requirements

        Performance efficiency ： The performance meets the actual requirements

        Compatibility ： The software can be compatible with mainstream hardware and software

        Ease of use ： Easy to use

        reliability ： Reliable performance and function application

        Information security ： The degree of security of information during transmission or storage

        Maintainability ： Easy to maintain

        Portability ： With migration and convenience

4. test model

V Model

W Model

W Model advantages ： Testing accompanies the entire product development cycle , The test object is not only the program, but also the requirements 、 Design document , Early test intervention , Find problems early , Reduce repair costs .

W Model shortcomings ： It's complicated to implement , Difficulty , The requirements for test design in the requirements stage and design stage are high .

Development process ： Demand analysis 、 Outline design 、 Detailed design 、 code 、 Integrate 、 The implementation of 、 deliver

Testing process ： System test design 、 Integration test design 、 Unit test design 、 unit testing 、 Integration testing 、 The system test 、 The acceptance test

V Models and W Model _ Tang Tang Tang piong The blog of -CSDN Blog _v Model

5. Software testing process

Demand analysis 、 Plan preparation 、 Use case design 、 Use case execution 、 Defect management 、 Test report

6. The test case

Use cases ： User cases

The test case ： Documents for performing tests （ User cases ）

Consideration point ： Quality model （ function 、 performance 、 compatible 、 Easy to use 、 Security ）

effect ： Prevent missing measurement 、 Standards for conducting tests

Format ： Use case number 、 title 、 project / modular 、 precondition 、 priority 、 testing procedure 、 Test data 、 Expected results

Use case number ： project + modular + Number

title ： Expected results + Operation steps

project / modular ： Project or module

precondition ： To execute this use case 、 What are the pre operations

priority ： Indicates the importance or influence of the use case P0~P4（P0 The highest ）

testing procedure ： Describe the operation steps

Test data ： Operational data , If not, it can be empty

Expected results ： Expected results

7. Division of equivalence class

In all test data , Data sets with some common characteristics are divided .

Equivalence class partition is to divide the input domain of the system into several parts , Then select a small amount of representative data from each part to test . Equivalence classes can be divided into valid equivalence classes and invalid equivalence classes , These two equivalence classes should be considered when designing test cases .

classification ：

         Effective equivalence class ： A collection of data that meets the needs

         Invalid equivalence class ： Data sets that do not meet the requirements

step ：

1. Clear requirements
2. Determine valid and invalid equivalence classes
3. Extract data and write test cases

Use scenarios ：

         Test input for the need for a large amount of data , But there's no exhaustive list of tests ： Input box 、 The drop-down list 、 Radio check box

Typical representative ：

         Page input box class test

8. Boundary value division method

Selection is exactly equal to 、 Just bigger than 、 The value just below the boundary is used as test data

Upper point ： Points on the border （ It's exactly the same as ）

Departure point ： The point closest to the upper point （ Just bigger than 、 Just less than ）

Inside point ： Points in the range （ Interval data ）

Boundary value method design case step ：

1. Clear requirements
2. Determine valid and invalid equivalence classes （ type ）
3. Determine the boundary range value
4. Extract data and write test cases

demand ： Greater than 0 Less than or equal to 30 Characters

1. Clear requirements ： Greater than 0 Less than or equal to 30 Characters
2. Determine valid and invalid equivalence classes ： It works ： Greater than 0 Less than or equal to 30 The characters of . Invalid ： Greater than 0 Less than or equal to 30 The number of
3. Determine the boundary range value ： Upper point ：0、30, Check out ：1、29、31, Inside point ：15 position
4. Extract data and write test cases

Optimize ：

        [-99,99]：-100、50、100、-99、99

         Open the inside and close the outside , Consider the interior point in the open interval , Consider the outer point in the closed interval

9. Decision table method

Conditional dependence

The boundary value of equivalence class does not consider each combination between input conditions

Definition ： A tool for expressing multi conditional logical judgment in tabular form

Condition stake ： List all the conditions in the question , The order in which the conditions are listed is irrelevant

Action post ： List possible actions in the problem , There is no constraint on the order of operations

Condition item ： List the values corresponding to the conditions , The true value of all possible situations

Action items ： List the of condition items 、 Action results to be taken under various values

Suppose there is n Conditions , There are two values for each condition , The whole combination has 2 Of n The power rule

step ：

1. Clear requirements
2. Draw a decision table
   1. List condition piles and action piles
   2. Fill in the condition item , Make a full combination of conditions
   3. Determine the action item according to the combination of condition items
   4. simplify 、 Merge similar rules （ Have the same action ）
3. Write test cases according to rules

Use scenarios ：

         There are multiple input conditions , Multiple output results , There is a combination relationship between input conditions , There is a dependency between input conditions and output results （ restriction ） Relationship

         The decision table is generally applicable to the case where the number of condition combinations is small

         There are dependencies between multiple conditions , Use the decision table to test coverage

10. Scene method

What should be measured before getting the project ： Business

flow chart ： Use standard graphics and arrows to express Chengwu or business trend

The function of flow chart to testers ： Be able to understand the flow chart , Design business use cases , When the snowball document information is not all , Can according to demand , Sort out the process

Scenario method can be called flow chart method , Use a flowchart to describe the user's use scenario , Then design test cases by covering the process path .

significance ：

         User use angle ： Users don't usually use a single function , It's a combination of multiple functions

         Tester angle ： The usual test is to test a single function point , It is easy to ignore the combination test of multiple functions

         Smoke test cases ： Is the right path from start to end in the process

11. Error recommendation method

         Infer the possible problems of the system through experience

         scene ：

                 Time is tight and there are a lot of tasks , Find out the error prone modules and focus on testing according to the similar experience of previous projects

         Practice leniency lists the modules with more problems through this method and tests them again .

         If time is tight and the task is big , What do I do ？

         answer ： Important business will be determined according to the product personnel , First, the main business is positively covered , After the coverage, the main modules will be covered according to the time , Forward is in reverse , Go according to the time node , Then work overtime to finish the test point , Then write after the use case .

         When all the project use cases are executed , And BUG All repaired , This method can be used to cover unmeasured tasks for some time before going online .

12.  Defect judgment criteria

Defect definition ： Any problem in the use of software is called software defect , abbreviation bug

Defect judgment criteria ：

         The software does not realize the functions specified in the requirements specification - Less function

         There should be no error in the specification of the software - Function error

         The functions realized by the software are beyond the scope specified in the requirements specification - multi-function

         The software does not realize the requirements that should be realized although not clearly specified in the requirements specification - Implicit function error

         Software is hard to understand , Not easy to use , slow , Bad user experience - Not easy to use

The cause of the defect ：

1. Demand stage ： The requirement description is not easy to understand , Ambiguity 、 Errors, etc
2. design phase ： There are errors or defects in the design documents
3. Encoding phase ： Code error
4. Operation phase ： The failure of software and hardware system itself leads to software defects .

The life cycle of software defects ：

         Requirements specification （ defects ）-> Design （ defects ）-> code （ defects ）-> test -> Fault classification -> Fault isolation -> Trouble shooting （ defects ）

The core of the defect ：

         The title of the defect （ Describe the core problem of the defect ）、 Preset conditions of defects （ The premise of defects ）、 The steps to reproduce defects （ The process of reproducing defects ）、 The expected result of the defect （ The desired result ）、 The actual result of the defect 、 Necessary accessories for defects

         Defect submission elements ： Defect report no 、 severity 、 Defect priority 、Bug type 、 Defect status

         severity ： serious 、 commonly 、 small 、 Suggest （S1-S4）

         Defect priority ：0,（24 Hours ）1（ Before release ）,2

        Bug type ： Code error 、 Compatibility error , Performance issues 、 Design flaws

         Defect status ： newly build , open , close , delay

         Type of defect ： Function error 、 Interface error 、 Compatibility 、 data 、 Ease of use 、 Suggestions for improvement 、 framework

         Workflow ： Design use cases -> Execute use cases （ Perform the test ）-> defects （ Submit 、 verification 、 close ）

         Remove the test point ：1. function （ positive 、 reverse ） 2. Non functional （ Compatibility (5 Big browser kernel ), Layout ： Consistent with the prototype drawing , The picture and text are accurate and consistent with the prototype ）

         Image verification code （ positive ： correct + Not expired 、 reverse ： It's empty 、 Be overdue 、 error ）

         Defect Title Analysis ： What is the role ？（ Let people see what's wrong ） If you let people see ？（ Describe test data + The actual result （ Expected results ）、 Test data description + Expected results （ The actual result ）、 Test data description + The actual result （ demand ））

Defect management process ： Submit 、 verification 、 close

13. Defect management tools

        Excel, ZenTao

         ZenTao ： domestic 、 free 、 Open source 、 Simple 、 Lightweight

         Zen use process ： Manage use cases -> Create use cases -> Review use cases -> Execute use cases

         Management defects -> Defect creation -> Defect tracking -> Defect verification

14. How to start the test after clarifying the requirements

         Analyze requirements 、 Extract test points 、 Design use cases 、 Use case review 、 Execute use cases 、 Defect management 、 Test report