Modern software engineering Chapter 1 [software testing] exercises and discussions

I. Do not change if there are any mistakes. leap year Problems

1. The correct condition for determining a leap year is

(Year % 400 = 0) | (Year % 4 = 0 & year % 100! = 0). Pay attention to the relationship between the three operators. The conditions for the question code for the remainder of 4 and the remainder of 100 should be the same.

1. Calculation error.

When the number of days entered is the last day of a leap year, after the number of days is reduced to 366, three judgment conditions will be executed from the while, and the number of days will not decrease, and the number of years will not increase, enter the endless loop status. Change days> 366 to days> = 366 or days> 365.

Learn the design method of the test case and divide the test set according to the equivalence class. For example, if a function can return true or false, you must have at least two types of test sets, let it return true or false respectively. If you know the working principle of the program, you can divide the equivalence classes in more detail and design them for each function. design test cases based on the boundary values; check whether the test case overwrites the statement (of course, even if it is completely overwritten, it cannot ensure that the program will not go wrong ).

1. I did not expect a leap year. For the transformation of the Year and date, we need to consider the difference between a year and a year. The leap year worm problem of taxis reminds us not to worry about it and avoid special problems.

2. Invasion of the government is more dangerous than cold

In the development process, different roles cooperate and control each other. You can't go over your behalf, otherwise it will be "more cold ". For example, when testers perform verification tests, they need to perform multi-faceted and multi-platform tests, which far exceeds the capabilities of developers, therefore, the tester must verify and handle bugs that have been fixed.

3. test experience exchange

Not letting go of any possible bugs will lead to many "as design", but it is not an absolute bad thing. Testers do not need to study, find the root cause of the problem, or even try to fix the problem, these are beyond the scope of developers' responsibilities; they ensure the diversity of testing methods; think about problems from the user's perspective; draw a line from the other, and test the problems on similar points; you can switch tests with prior notice and arrangement. Writing stable tests into automatic tests reduces the stress of manual tests.

Iv. Legendary inflection point

The inflection point is that in large and complex projects, testers and developers all use one system to manage bugs. For small, date-driven projects, manual intervention is required, such as delaying some bugs, cutting down some features, and gradually increasing the benchmark of "must be fixed for the minor strong" to take the initiative to make the inflection point happen.

5. Learn and use test tools on multiple platforms

6. 20 major bugs in history (to be continued)

7. Long-history bugs (to be continued)

VIII. Relationship between TPS and number of concurrent users

Transactions per second TPS is a very important indicator to measure system performance. The server performance is measured by TPS, which has little to do with the number of user concurrency.

Considering a single script, the Conversion Relationship between user concurrency Vu and TPS is Rt, which is the time for the script to complete all operations at one time. If there are m transactions in each script and N scripts in total, the total TPS is :. (Note: you have doubts about the conversion relationship)

For new systems, TPS and Vu acquisition can only be evaluated by the business department. For old systems, 10% of the number of online users during peak hours is used as vu, and the number of business transactions completed per unit time is used as TPS.

The maximum TPS of the system is certain (within a certain range), but the number of concurrent users is not certain and can be adjusted. During performance testing, do not set too long time for consideration to exert pressure on the server in the worst case. During load testing, the number of users is usually added according to the gradient pressure. The concurrency of 5000 users in large systems is sufficient, and the concurrency of 1000 users in small and medium systems is sufficient.

Modern software engineering Chapter 1 [software testing] exercises and discussions