Software Testing Basics-01

Target:

1. Definition of software testing;

2.Differences between 7 test categories;

3. Five key items of the quality model;

4. Six steps of the testing process;

5. 8 elements of test template;

Employment direction:

1. Functional testing + interface testing

2. Functional testing + performance testing

3. Functional testing + web automation

1. Introduction to software testing

(1) Definition:

Software:Tools that control the operation of computer hardware.

Software testing:Use technical means to verify whether the software meets requirements. (Purpose: Reduce software errors and control software quality)

(2) Mainstream skills:

1. Functional testing:The test mainly verifies whether the function of the program meets the requirements.

2. Automated testing:Use code or tools instead of manual work to test the project.

3. Interface test: Use code or tools to verify whether the interface in sequencing is accessible normally.

4. Performance test: Simulate multiple people using the software to find server defects.

(3) Model:

1. Quality model:Measuring the dimensions of an excellent software (it can tell us the aspects that should be considered when testing)

Focus: Function, performance, compatibility, ease of use, security Conclusion: Whether testing hardware or software, classification verification should be carried out based on the above points

2. Test the model

2. Test classification

(1) Divided by testing stage (software production process sequence):

Unit testing: testing the program source code (unit: the smallest independent functional code segment)

Integration testing: testing the interface between units (also called interface testing, testing the access addresses between modules)

System test: for the overall system function + compatibility + documentation (instructions, installation documents)

Acceptance testing: internal testing (used by internal personnel of the company, discovering defects and repairing them); public testing (letting users help test)

(2) Divided by code visibility:

Black box testing: The source code is invisible (the UI functions are visible), and it mainly tests the UI functions of the program. (Phase division->System testing)

Gray box testing: seeing part of the code (functions are not visible), mainly testing part of the program code. (Phase division->Integration testing)

White box testing: See all codes (UI functions are not visible), mainly test the program source code. (Phase division->Unit testing)

(3) Summary:

The core of system testing and black box testing is functional testing. Integration testing and gray box testing are also called interface testing. Unit testing and white box testing test the code. Automated testing belongs to functional testing. Performance testing and security testing belong to special testing.

3.Testing process

• Needs analysis (review)

  Prerequisite: Read the requirements document once and record any ambiguities.
  Participants: front-end, back-end, testing, product
  Purpose:
      1. Ensure that all departments have a consistent understanding of their needs
      2. Each role checks and fills gaps in requirements
      3. Understand some functions of the software
  Tip: Requirements analysis stage->The software has not yet been implemented (the project has just been established)

• Test Plan

  Description: Documentation to guide test execution (important)
  What to measure (target, scope)
  Who will do the testing (personnel progress and arrangements)
  How to test (testing tools, testing strategies)

• Use case design

  Description: Documentation that ensures accurate verification of software test point execution.
  1. Analyze needs
  2. Extract test points
  3. Design use cases to cover test points

• Use case execution

  Description: Implement the test

• Defect management

  Submit->Verify->Close

• testing report

  1. Bug analysis and statistics
  2. Problems encountered during testing
  3. Test summary (the advantages and disadvantages of this test)

4.Test cases

Use cases:User use cases.

The role of use cases:1. To prevent missed tests; 2. To measure whether the software passes or not

Use case document writing specifications:

Use case number: project_module_number
Use Case Title: Expected Result (Test Point)
Module/Project: Project or module to which it belongs
Preconditions: What are the prerequisite operations to execute this use case?
Priority: Indicates the importance or influence of the use case P0~P4 (P0 is the highest)
Test steps: describe the test steps
Test data: Operation data, if not available, it can be empty
Expected results: the results expected to be achieved

Template example:

Use case design method:

Target:

1. Able to design test points for exhaustive scenarios 2. Able to design test points for limited boundary rules 3. Able to design test points for multi-condition dependencies 4. Able to design test points for project business

(1) Ability to design test points for exhaustive scenarios (exhaustive: endless)

Equivalence class division method

Key point: Just take one valid equivalence and a single invalid equivalence.
step:
    1. Clarify needs
    2. Determine valid and invalid equivalences
    3. Write use cases based on valid and invalid data
Note: The complete use case should be written together with the equivalence class and boundary value.

Template example:

(2) Be able to design test points for limited boundary rules (use boundary values ​​to solve the problem of boundary digit limit)

Boundary value

step:
    1. Clarify needs
    2. Determine valid and invalid equivalences
    3. Determine the boundary range
    4. Extract data and write use cases

Template case:

(3) Ability to design test points for multi-condition dependencies (using decision tables)

Decision table

step:
    1. Clarify needs
    2. Draw a judgment table
        1) List condition piles and action piles
        2) Fill in the condition items and fully combine the conditions
        3) Determine action items based on the combination of condition items
        4) Simplify and merge similar rules (with the same actions)
    3. Write test cases according to rules
hint:
    1. There are dependencies between multiple conditions, and a decision table is used for test coverage.
    2. Determination tables are generally suitable for conditional dependencies within 4
    3. If there are more than 4 conditions, it is not suitable to cover all conditions, and (orthogonal method) should be used to solve it.

Template example:

(4) Able to design test points (flow chart) for project business

Business use cases are sorted out based on flow charts. You need to understand the flow charts first.

1. Online tool: https://processon.com/diagraming/605880af07912927bd71c388
2. Offline tool: visio
3. Other tools: Excel

Use case execution

The execution result is inconsistent with the expected result of the use case (meaning), which is a defect. (Failure of use case execution is a defect and requires defect management)

defect:

1. Definition:Various problems existing in software are defects, referred to as bugs;

2. Defect standards:

1. Few functions 2. Functional errors 3. Multifunctional 4. Lack of hidden functions 5. Ease of use (from the professional perspective of software testers)

3. Causes of defects:

1. Requirements document 2. Architecture design 3. Coding implementation 4. Environment (hardware, software)

4. Defect life cycle:

1. Regression testing:
    ①Return of regular projects: Two new modules have been added to the project this time. The most basic thing is to test the functions of the new modules and the old modules associated with the new modules.
    ② Non-routine projects (banking, military, aerospace): All new functions must be retested.
2. Regression bug: The defects discovered in the previous version have been developed and repaired and will be re-verified in the next version.

5. Core elements of defects:

6. Defect submission elements:

7.Defect type:

1. Functional errors 2. UI page errors 3. Compatibility 4. Data (database) 5. Ease of use 6. Suggestions 7. Architecture defects

8. Workflow:

Design use case->Execute use case (execute test)->Defect (submit, verify, close) Defect definition: any problem (Bug) Defect standard: multi-function, few functions, errors, lack of hidden functions, ease of use description Defect focus: defect title, preconditions, reproduction steps, expected results, actual results, attachment notes Submit defect information: assignee, defect level, repair priority, type, status (statistical defects)

Defect management:

1.excel sample:

2. Defect tracking process: (Just know the work involved in the testing and development process)

3. Submission notes:

hint:
Interview question: After discovering a defect, what should you do first? -- Make sure the bug is reproducible and it is definitely a bug.
When submitting, check whether the defect already exists.

4. Defect management tools:

1. Project management tools-manage defects (ZenTao, JIRA, TFS)
2. Excel management defects

(1) ZenTao (project management tool)

• Address:User Login - ZenTao

• Features:

  

• Use flowcharts

• Use ZenTao to manage defects

  • Log in

  

  • Create a defect

  

  • close defect

  

5. Defect title expansion: