Practical Software Testing Guide (Electronic Industry Press)-Reading Notes 2

Today, I took a look at the fault model that guides software testing in Chapter 1. This chapter describes the purpose of software testing, understanding software behavior, understanding the software environment, and understanding software capabilities.
I software testing purpose
There are multiple motivations for software testing. Tests are required to determine whether the organization accepts the product. Compliance tests are required to determine whether a product meets the standards for implementation; usability testing is used to determine whether a product is easy to use. In addition, performance testing, reliability testing, and robustness testing are also available.
Basic Features of these tests:
* Each test requires the tester to follow the product behavior description. The product behavior description can be a written specification, requirement document, product document or user manual, source code or executable code.
* Each test requires the product to run in a real or simulated environment. The running product function distinguishes the test from the code review and review. Code review and review can be performed statically before the product compilation and connection.
* Each test requires that the product functionality be presented in a systematic way. The test results are positive or negative. No matter how many documents you possess, you must intelligently display software functions.
The difference between users and testers is that testers have clear goals.

2. Understanding software behavior
The challenge of testing is to select which tests are to be performed and which do not need to be tested. The best tester should have this kind of intuition and know what makes the software ineffective. This kind of intuition leads them to thoroughly and comprehensively think about test scenarios. Fault Model is the technology that gives them this intuition. For testers, it is important to be able to construct an accurate fault model and use it in testing, make sure that the hidden error is checked.
The fault model that testers need to learn and absorb is based on two basic problems related to the tested software:
* Familiar with software operation environment
* Testers must understand the capabilities of their applications.

3. Understand the software environment
Most users of software systems are not necessarily human users. People cannot directly submit input to software applications. Instead, they use hardware devices to submit input to their device drivers for processing. These inputs are sent to the API layer of the operating system until the API generates events, indicating that the application in the test has received the input. In fact, the application software only receives the input through the OS.
Environment where the application is executed

The operating system kernel provides services for memory, file pointers, and time and date functions. The file system provides data stored in binary or text formats, the UI provides an API set for obtaining input data from the keyboard, mouse, or other devices,
Scenarios in which applications interact with the environment

* Human users (think this concept translation is a bit inappropriate)
There are two interfaces for software: Gui and API
1. submit input through GUI Control
There are two key issues: Testing the data transfer control (data transfer and event transfer) and testing the order of GUI controls
2. submit input via program
The difference between selecting parameter combinations and the order of API calls and selecting GUI controls is the transfer mechanism, that is, testing the API is a program, and testing the GUI is a keyboard.
For the two interfaces, the tester faces the same difficulty. One fundamental problem is that there are too many inputs, input combinations, and input order, and all are applied.
* File system user
For testers, the file is the user, and the content is the input.
* Operating System users
The operating system is the only entity that interacts directly with users. It is the intermediary between all actual users and applications by providing memory

, File processing, heap space, etc., directly interact with applications. This part of the operating system is the kernel.
For example, the Windows Kernel provides 1000 different functions.
The fundamental problem of the system interface is different from that of the human interface. The system input is reactive, and the system input cannot be directly controlled by the tester. Instead, the software responds to the user input.
* Software Users
Like operating system users, external software is used to store data and execute different tasks for an application. For example, an application can perform SQL queries on an external relational database or use APIs for socket programming, execute matrix algebra, process strings, or execute any reusable parts.

4. Understanding Software
There is a metaphor in the book that is very vivid. It compares software testing to fighting. Software testers are very similar to the generals in the battle. They must be familiar with the enemy and know the strength of the enemy (hidden errors in the software ), develop attack policies (software test cases ).