I have heard of this book and finally borrowed it from the library last week. After reading it, I feel that the first half is good for testers, but the latter part is too inclined to code development and is suitable for white box testing and unit testing. Readers are required to have certain development capabilities as a whole, but testers can also use it as a reference book to learn how developers perform tests.
Terms
Test harness test suite
Test Suite Test Group
Sut (system under test), Aut (application under test), IUT (implementation under test) programs to be tested
Console Application console Program
Excellent
Automated testing technologies are designed to supplement other testing deficiencies, such as manual testing, test-driven development, model-based testing, open-source testing frameworks, and commercial testing frameworks, rather than replacing these tests. 5 Advantages of software testing automation compared with manual testing (Sapes)
1. faster speed)
2. higher accuracy (accuracy)
3. Precision)
4. Efficiency)
5. It is more helpful for testers to improve their skills (skill-building)
The author puts forward the concept of "lightweight automated testing", and believes that lightweight automation is not as steep as open-source testing frameworks and commercial frameworks. Compared with commercial automated testing frameworks, lightweight automated testing is relatively inexpensive and easy to customize. Compared with the open-source testing framework, lightweight Automated Testing won't have too many version updates and bug fixes, making it more stable. The biggest advantage is that it can mobilize the initiative of testers-lightweight automated testing actively encourages the compilation of creative testing programs, commercial frameworks and open-source frameworks often limit the types of tests that only need to be compiled to support a good framework. Its only drawback is that it is not easy to maintain.
Part 1 windows application testing
Chapter 1 API Testing
Application Programming Interface (API) testing automation is the most basic type of software testing automation. In essence, API testing is used to verify the correctness of the individual methods that constitute the software, rather than testing the entire system. API testing is also called unit testing, Module Testing, component testing, and element testing ). Technically speaking, these terms are very different, but in daily applications, you can think they have roughly the same meaning. The idea behind them is that each module in the system must work normally. Otherwise, the system as a whole cannot be correct.
Steps for manually testing an API:
Create a small program,
Copy the class to be tested to the test program,
For some input values of hard-coding,
Run the stub program to obtain the actual output result,
Then, compare the actual results with the expected results with the naked eye,
To determine whether the test is successful.
Steps for automated API testing:
1) files used to store test case data
A-independent from the test suite
B-each row in the file represents a separate test case. The basic fields of each test case are: Test Case ID, method to be tested, test case input, and expected results. Each field is separated by a uniform character, such as ":"
The C-file format can be a text file, XML format, or even an SQL table. For lightweight automated testing programs, text files are the best way to store data for simplicity.
2) read the test case data. Generally, the while loop statement is used to traverse each row of the test case file and read the data. It is best to use relative paths.
3) parse the test case using a method similar to spit, pass the separator as the input, and then store the return value into a character array.
4) convert data to a suitable type
5) Determine whether the test case passes
6) record the test case results and write the test case ID and test results to a simple text file independent of the test program.
7) adding a timestamp to the test case result can add the timestamp to the file name of the test result.
8) summarize the test results through computation. Use a simple integer counter to calculate whether the test case passes.
9) obtain the total time for testing.
10) Verify that the input is null or the expected value is null.
11) handle "method throw exception"
12) handle the case where the input parameter is a Null String
13) write a program to send a warning email when the test case fails.
Chapter 2 reflection-based UI Testing)
Chapter 2 Windows-based UI Testing
Chapter 2 test suite Design Model
Storage of test case data
A-flat storage: plain text files
B-hierarchical: XML file
C-Relational Database: SQL data
The two basic methods for testing and processing data are streaming and buffered. The pseudocode is as follows:
Streaming
Cycle start
Read a single test case from external store
Parses test case data into input values and expected values
Call the component to be tested
Judge test case results
Save test case results to external storage
Loop ends
Buffered
Loop start // 1. Read the test case used
Read a single test case into memory from external storage
Loop ends
Loop start // 2. Run all test cases
Read a single test case from memory
Parses test case data into input values and expected values
Call the component to be tested
Judge test case results
Write test case results into data results in memory
Loop ends
Loop start // 3. Save all test results
Write test case results from memory to external storage
Loop ends
The streaming processing model is simpler than the buffered model, so it is usually the best choice. However, the buffered processing model should be considered below.
1. If the system to be tested involves file input and output, we usually want to minimize file operations in the test suite. This is especially true for performance monitoring.
2. if you need to pre-process test case input (for example, read and filter test case data from different data storage) or delay processing of test case results (for example, in order to aggregate the results of different types of test cases), it is usually more convenient to store data in the memory for ease of processing.
The following sections introduce the specific implementation methods of the following combinations. individuals tend to use text files to store data and use the streaming model because of its simplicity, however, you may also select other options as needed.
1) file storage and use the streaming model
2) file storage and use the buffered Model
3) store data in XML files and use the streaming model
4) store data in XML files and adopt the buffered Model
5) SQL stores data and uses the streaming model
6) SQL stores data and uses the buffered Model
Part 1 web application testing
Chapter 4 request-response test
Chapter 2 tutorial-based Web UI Testing
Chapter 2 underlying web UI Testing
Chapter 2 Web Service Testing
Part 1 Data Testing
Chapter 2 SQL stored procedure Test
Chapter 4 arrangement and combination
Chapter 2 ADO. Net Testing
Chapter 2 XML Testing
As Part 2 and Part 3 do not have much contact with me, I will not introduce it. However, the arrangement and combination in Chapter 10th describes how to generate test data through arrangement and combination.