". NET software testing automation"

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.