Design and classification of software test cases

---

test case design

1. Test case

Designing a test case can take the following aspects to design

• function test
• interface test
• Performance Testing
• compatibility test
• usability test
• Safety test

Assuming a simple comparison between the water cup test case and the registration and login test case

2. How to design test cases

Design test cases based on requirements: requirements analysis, what functions are required, design test points, design test cases

Assume that the software requirement is: Prompt the user name with 6 to 15 characters.

We can exhaustively enumerate the test cases, starting from 0 to 16, and if the test passes, the function is considered to meet the requirements. But if the length of the name is 6 to 200 characters, how to design the test case? Obviously exhaustive method is not enough.

1) Equivalence class

The idea of ​​the equivalence class is: divide the input into several equivalence classes according to the requirements, select a test case from the equivalence class for testing, and if the test passes, the equivalence class in which the test case is located is considered to be passed.

The equivalence class is partitioned into blocks, using fewer test cases to achieve consistent system test coverage.

Equivalence classes are further divided into valid equivalence classes and invalid equivalence classes

• Effective equivalence class: a collection of data that is valid and meaningful for the requirements
• Invalid equivalence class: A collection of data that is invalid and meaningless for the requirements

Steps to divide test cases according to equivalence classes:

1. Identify valid and invalid equivalence classes
2. Write test cases

Requirements: The length of users is 6~200 characters, how to design test cases.

1. Identify valid and invalid equivalence classes
   • Valid equivalence classes: 6~200
   • Invalid equivalence class: less than 6 greater than 200
2. Write test cases

Or design an invalid equivalence class for passwords with 6 to 20 characters?

• Length design: less than 6 or greater than 20
• By type: numbers, strings, special characters, etc.

2) Boundary value

Boundary value methods are often complementary to equivalence classes

When designing test cases with boundary values, you need to add: boundary value + secondary boundary value

Suppose there is a certain demand: the deadline for the event is May 23 (acEndtime)

The sub-boundary values ​​of the time have to be set to: 00:00:00 and 23:59:58

For example, the sub-boundary values ​​of 1 are: 0 and 2

Minor boundary values ​​for -1: -2 and 0

3) Judgment table method

Applicable scenarios : Different combinations of input conditions correspond to different output results

The decision table method is a logical judgment tool

Suppose there is a demand: the order has been submitted, the total amount of the order is greater than 300 or the order has a red envelope, then the order is considered to be an order with a discount, otherwise it is an order without a discount.

Decision table design test case steps :

1. Find out the input conditions and output conditions

2. Find the relationship between input conditions and output conditions

3. draw a decision table

4. Write test cases based on decision tables

5. To determine the input conditions and output conditions for the above

   • Input conditions: the amount is greater than 300 (A), there is a red envelope (B), the order has been submitted©
   • Input conditions: 1 with discount, 2 without discount

6. Find the relationship between the input condition and the input condition

   AC	BC	ABC	C	A	B	AB 非ABC
   1	1	1	2	2	2	2	2
   

7. draw decision table

4. Write test cases based on decision tables

   • There is a red envelope, the amount is not more than 300, the order has been submitted, and the result is that there is a discount
   • No red envelopes, the amount is greater than 300, and the order has been submitted. The result is a discount
   • There is a red envelope, the amount is greater than 300, the order has been submitted, and the result is a discount
   • There is no red envelope, the amount is not more than 300, the order has been submitted, and the result is no discount
   • If there is no red envelope, the amount is greater than 300, and the order has not been submitted, the result is no discount
   • There is a red envelope, the amount is not more than 300, the order has not been submitted, and the result is no discount
   • If there is a red envelope, the amount is greater than 300, and the order has not been submitted, the result is no discount
   • If there is no red envelope, the amount is not more than 300, and the order has not been submitted, the result is no discount

There is a step called the judgment table method based on the causal diagram, because the causal diagram judgment table is redundant, and the causal diagram is actually meaningless and abstract when designing test cases.

4) Orthogonal method

To use the orthogonal method, you need an orthogonal table:

• Number of Factors: Enter Conditions
• Number of levels: the result corresponding to the input condition (not the output condition)

Properties of an orthogonal table:

1. In each column, different numbers appear an equal number of times
2. Numbers in any two columns are arranged in a complete and balanced manner

Requirements: Fill in user registration information (name, email address, password, confirmation password, verification code)

• Number of factors: name, email, password, confirm password, verification code
• Number of levels: fill in, not fill in

Steps to Design Test Cases by Orthogonal Method

1. Find the number of factors and levels
2. Use the allpartis tool to generate an orthogonal table
3. Write test cases based on orthogonal tables
4. Supplementary test cases

Generate test cases through allpartis

1. Write number of factors and levels to Excel

2. Create a new text file in the allparis directory, copy the factor numbers and level numbers in Excel, paste them directly into the text, and save them directly

Use the alparis command to generate an orthogonal table file

4. finally finished

4. Then write test cases according to the orthogonal table

Note that the orthogonal table generated by using allpairs may be different from the actual orthogonal table file, but it does not affect our design of test cases

• Fill in the name, email address, password, confirmation password and verification code
• Fill in the name, other e-mail address, password, confirm password, verification are not filled
• Do not fill in the name, fill in the email address, do not fill in the password, fill in the confirmation password, do not fill in the verification code
• Do not fill in the name, do not fill in the email address, fill in the password, do not fill in the confirmation password, fill in the verification code
• Fill in the name, fill in the email address, fill in the password, do not fill in the confirmation password, do not fill in the verification code
• Fill in the name, do not fill in the email address, do not fill in the password, fill in to confirm the password, fill in the verification code

5) Scene Design Method

The scenario design method is mainly divided into: basic event flow and multiple alternate event flows

Take ATM withdrawal as an example

The most basic event flow :

1. card
2. enter password
3. Choose the corresponding business
4. Execute the corresponding business
5. cash out

Alternate event stream :

• Password input times?
• Withdrawal amount limit?
• machine malfunction?

Write a test case :

1. basic event flow
   • insert bank card
   • Enter the correct secret
   • Choose withdrawal service
   • Choose less than 5W, and the amount is a multiple of 100
   • Waiting for cash out (withdrawing banknotes)
   • last card
2. alternate event stream
   • Insert the bank card, the first password input is wrong, the second input is correct, the selected amount is less than 5W and is a multiple of 100, wait for the cash to be withdrawn, and finally return the card
   • Insert the bank card, enter the password incorrectly for the first two times, but enter it correctly for the third time, choose to withdraw, select an amount less than 5W and it is a multiple of 100, wait for the money to be withdrawn, and then return the card.
   • and similar test cases...

6) The wrong guess method

This method of designing test cases is actually based on the work experience and accumulation of testers.

3. Test classification

1) Divided by test object

1. interface test

   • Interface testing is also called UI testing, and interface testing refers to UI design diagrams.
   • Non-software interface testing: color, size, material, overall aesthetics
   • Software interface testing: input box, button, text, picture size, color, shape, overall fit, clarity, etc.
   • Verify whether the layout of the entire page is reasonable, and whether the image display meets user needs

2. reliability test

   • Reliability generally refers to the percentage of time that the program normally provides software services to users in the total time

• Reliability $=$ uptime$/$ (Uptime + Abnormal Uptime)$\ast 100$
  • Usability indicators generally require 4 or 5 $9$ , such as$99.99$ or$99.999$
  • Abnormal uptime of a system may be caused by hardware, software, network failures or any other factors that may stop the system from working

3. fault tolerance test

   • Fault-tolerance testing means that the system can handle exceptions and user errors without causing the system to crash, thereby improving the availability of the system
   • For example, input abnormal data or perform some abnormal operations. If the system has good fault tolerance, the system will filter it out internally without causing system errors or crashes.
   • Or through various means, let the software fail forcibly, and then check whether the data of the system is lost, and whether the system and data can be recovered quickly

4. Difference between reliability and fault tolerance?

   • Suppose there is a server cluster with multiple servers
   • Suddenly a service went down, but it did not affect the user's use. This is the performance of the fault tolerance of the cluster
   • Also this down server is unreliable

5. document test

   • Generally speaking, document testing is performed by testers during requirements review.
   • Documentation testing focuses on the correctness, completeness, consistency, and usability of documents

6. compatibility test

   • Browser compatibility (Chrome, Firefox, etc.)
   • Platform compatibility (windows, Linux, Mac)
   • Self-compatibility: browser version (Chrome 100~113), the basic functions of multiple versions are available
   • Other platforms: whether the display function of Android phone/iphone is normal

7. Install and uninstall test

   • Different ways of installing and uninstalling software
   • Install under different systems and versions
   • Whether the install or uninstall can be paused or canceled
   • Is there a prompt when the installation space is insufficient?
   • Whether it can be uninstalled normally and supports other uninstall methods
   • Uninstallation and installation are problems with the system, whether the software can cope normally, such as crashes and power outages.

8. usability test

   • Software needs to be easy to use

9. Safety test

   • SQL injection
   • XSS vulnerability
   • Overreach (vertical overreach, horizontal overreach)

10. Performance Testing

    • resource leak
    • If you forget to close the file, it will cause file resource leakage
    • Resource bottlenecks (CPU, memory, network, thread deadlock, etc.)

11. memory leak test

    • For example, the allocated memory is not reclaimed, or there is a problem with the program writing that leads to memory leaks
    • Can be detected by tools: static scanning tools
    • Manual inspection: look at the code to find

2) Divided by whether to view the code

black box testing

Black box testing regards the code as a black box, and does not care about the internal structure and internal characteristics of the code, but only cares about whether the function of the software meets the requirements of the product specification. Black box testing can also be called data-driven testing or functional testing.

Common black-box testing methods for designing test cases: equivalence class, boundary value, decision table, orthogonal method, scenario method, error guessing method, etc.

white box testing

White-box testing is called outcome testing or logic-driven testing. The white box testing method detects the internal implementation of the program and checks whether the running status of the program meets expectations.

Common white-box testing methods: statement coverage, decision coverage, condition coverage, decision condition coverage, condition combination coverage, path coverage, etc.

gray box testing

Gray box testing is between the two, not only concerned about the internal structure and internal characteristics, but also concerned about whether the function meets the requirements. Gray box testing is often used in integration testing.

Why not just use gray box testing

Gray box testing is not as detailed and complete as white box testing, and black box testing is the test that covers the widest range of product functions. Therefore, gray box testing cannot replace black box testing and white box testing. But black-box testing can remove gray-box testing, but it is not recommended, because doing so requires a large amount of code and requires the design of many, many test cases.

What are the common test methods? Which methods are used more?

There are white-box testing and black-box testing that are common. In the work, it is necessary to combine white-box testing and black-box testing according to the actual situation. Generally speaking, testers use relatively more black-box testing methods.

3) Divided by development stage

unit test

Unit testing is to test the smallest unit of the system (the smallest unit is artificially specified)

Integration Testing

After the unit test is completed, the integration test is performed between the modules and the modules, and the test is performed according to the function

smoke test

The smoke test is performed by testers to check whether the main functions and main processes of the system are normal, and to evaluate whether the software/system has testable conditions/standards. If the smoke test passes, the tester conducts a formal system test. If it fails, the tester can ask the developer to re-fix the code until the smoke test passes, and then start the system test.

System test

After the integration test is completed, the tester prepares the project environment, regards the program as a whole, and conducts a system test on the program/system to ensure that the system functions meet the requirements of the product specification. In fact, smoke testing and regression testing are part of system testing.

Regression Testing

Test the historical versions and historical functions to ensure that the functions meet the requirements.

With more and more functional iterations and more and more versions, regression testing is relatively more difficult, and automated testing is needed for regression testing.

---