Four principles for designing test cases

Today is the first day of 2011, the 2010 is so hurried, tightly Zhang went past. This year come and go, the biggest change is a lot of work together for many years colleagues left, many went to the "more to the power" of the place, hehe! It is normal for the company to come and go, think of the last time I switched to the "more power" place, it was 5 years ago. In short, the present place is quite to the force, good work, for 2011 has greater progress, applause applause!
The most basic requirement of test case design: to cover the function of the dwelling to be tested. This is the basic requirement, but don't look just a simple word, to be able to achieve a comprehensive coverage, need to be tested product features a comprehensive understanding of the test scope (especially to identify which is not required to test), with basic testing technology (such as: equivalence class division, etc.). So is the test case that is designed to satisfy this requirement is a good test case? The answer: In theory, but not in practical engineering. The reason why there is such a difference between theory and practice, is because in theory do not think of Dongdong, and in the actual project is to be considered-the cost. The costs here include: test plan costs, test execution costs, automated test cases, test automation costs, test analysis costs, and additional costs introduced by testing the implementation of technical limitations, testing environment bugs, human factors, and unpredictable random factors.
As a result of the intervention of cost factors, it is decided that the design of the test case principle in engineering is not only the "cover to test the function" of this article, the following is my work experience summed up the other four principles, here, I hope that everyone to take a brick and correct. These principles are especially for test cases that need to be automated and are often executed.
1. Single use case overrides the principle of minimization.
This principle is the "eldest" of all four principles, and is the most easily forgotten and neglected in engineering, and it affects more or less several other principles. As an example, if you want to test a function A, it has three sub function points a1,a2 and A3, you can have the following two ways to design test cases:
Method 1: Overwrite three sub functions with one test case-TEST_A1_A2_A3,
Method 2: Overwrite three sub functions with three separate use cases respectively-TEST_A1,TEST_A2,TEST_A3
Method 1 applies to smaller projects, but with a slightly smaller scale and quality requirement, Method 2 is a better choice because it has the following advantages:
Test case coverage boundaries are defined more clearly
Test results are more directional to product problems
The minimum coupling between test cases and the less interference between them
The direct benefit of these advantages is that test cases have the lowest cost of debugging, analysis, and maintenance. Each test case should be as simple as possible, just verify what you want to verify, and don't "hug the grass and hit the rabbit" and bring it in with you, which will only increase the burden and risk of the test execution phase. David Astels in his book, "Test driven development:a practical Guide," that the best test case has only one assert statement. In addition, the concept of ordered test is introduced in Visual Studio by using test cases that cover a simple and well-defined function point, and are also easy to combine to generate new tests.
2. Test cases Replace product document functional principles.
　　Typically, we outline the features that will be implemented in the early stages of development (scrum, the first two days of each sprint) with Word documents or OneNote records of product requirements, functional descriptions, and any details that are currently available, to facilitate communication and refinement by the team, And within the team to achieve the product functional consensus. Assuming we have reached a consensus at this time, the description of the function for a, as the product development depth, the team will have a new understanding of the function of the product, product features will be more specific refinement, in an iteration or sprint at the end of the final implementation of the function is likely to be a +. So back and forth, listening and absorbing user feedback, modifying product functionality, after multiple iterations, the functionality originally described as a will probably eventually become Z. It's time to go back to the Word document and the OneNote page, but still record a. This is because very few people go (and can) keep updating those documents to accurately reflect the current accuracy of the product's functionality. It's not that you don't want to do it, it's really hard! Here's the note: the early word or OneNote documentation is necessary, at the very least, to ensure that the team has a consistent and accurate understanding of the functionality to be implemented at the beginning of the iteration.