I'm going to focus on the collection voucher 591q.cn
Test case design of the most basic requirements: functional coverage residence to be tested. This is another basic requirement, however, but do not look just a simple word, to be able to effectively achieve comprehensive coverage, requires a comprehensive understanding of the tested product features, clear test range (in particular, to identify which is not required for testing) It includes basic testing techniques (such as: equivalence partitioning, etc.) and the like. It meets the above requirements are not designed for this test is a good test case out of it? Answer: in theory, but in practice the project is still far. The reason why there is such a theory and practical difference, because in theory stuff is not taken into account, but is forced to consider the actual project - cost. Here's costs include: the cost of the test plan, test execution cost, automated test cases, test automation costs, the cost of test and analysis, and testing to achieve technical limitations, the additional cost of introducing the Bug testing environment, human factors and random factors such as unpredictable .
Due to cost factors involved in the decision in the engineering design principles not only a good test case "overlay function shelter to be tested," this one, here are the other four principles I summed up the work according to their own experience, start a discussion here, I hope you Paizhuan and correction. These principles are especially for those who need to be automated, and the test is to be performed frequently.
1. A single use case covering the minimization principle
This principle is that all these four principles in the "boss", is also the most easily forgotten and ignored in the project, it will more or less affect other several principles. Below is an example to introduce, if a function to test A, which has three subfunctions points A1, A2 and A3, there may be the following two ways to design test cases:
Method 1: The test covers a three functions -Test_A1_A2_A3
Method 2: three separate cases are covered by three functions - Test_A1, Test_A2, Test_A3
The method for smaller-scale projects, but all a little bit of size and quality requirements of the project, method 2 is the better choice because it has the following advantages:
Test cases covering more clearly defined boundaries
Test results point to stronger product issues
Minimum, interference between each test the degree of coupling between the lower the
These advantages can bring immediate benefit, debug test cases, analyze and maintain the lowest cost. Each test case should be as simple as possible, just to verify what you want to verify, not to "hug grass playing Rabbit" incidentally to Han Han Han consequently brought in, this will only increase the burden and risks of the test execution phase. David Astels in his book "Test Driven Development: A Practical Guide" has described, preferably a test case only one Assert statement. In addition, functional coverage points clear and simple test cases, but also easy to generate a new combination of tests in Visual Studio on the introduction of the concept of Ordered Test.
2. The principle of the test case alternative documentation capabilities
Demand usually we will use a Word document or OneNote in the early (Scrum Sprint each of the first two days) to develop a record of products, functional description, as well as any other details that can determine the current information, to be achieved sketched appearance features, to facilitate team communication and refinement, and reached consensus on product features within a team. After this time we assume the function consensus describe as A, along with in-depth product development, product team will have a good understanding of the features updated product features will be more specific and detailed, at the end of an iteration or Sprint when ultimately the function is likely to be a +. This back and forth, constantly listen and absorb user feedback, modify product features, after multiple iterations, originally described as a function of A is likely to eventually become a Z. It is time once again to see the Word documents and OneNote page, but still record is A. The reason for this is because very few people will go to (and able to) keep those documents in order to accurately reflect current product functionality accurately state. I do not want to do, but it is very difficult to note here:! Early Word or OneNote document is still necessary, it can at least ensure that the initial iteration of the team to achieve the functionality consistent and accurate understanding.
Nothing has been able to accurately describe the functionality of the product yet? Answer: Of course, that is the product code and test cases. Product code implements the functions of the product, it must accurately describes the current functionality of the product, but due to a variety of programming techniques, such as: object-oriented, abstract, design patterns, resource files, and so on, making the product code is difficult to simply be able to read understand, often in the know go on the premise of product features read the code, rather than vice versa look at the code to understand the function. Good code will be detailed notes, but the comment here is to interpret and implement the code notes, not a description of the product features. There is a very old blog Reading Code Is Hard, describes how you can make the code more readable some of the writing skills.
Then only test cases, the test should also faithfully reflect the product features, otherwise the test will fail. In the past we just put the test as a test case only, in fact, an understanding of test cases should rise again to another level, it should be able to play a functional product description document. This requires us to write test cases in sufficient detail to have a test case organization conditioning, establish priorities, this alone universal tool Word, Excel or OneNote is far can not be completed, the need for more specialized test case management tool to assist, such as Visual Studio 2010 introduced Microsoft Test Manager.
In addition, for purposes of automated test cases (whether or UI API level), in the preparation of the code should also have another product code writing style, readability and descriptive content should be a key consideration. In the test code, of course, it can be introduced into the excellent design idea of object-oriented design patterns, etc., but must be appropriate to use, often for the encoding process more conducive to the organization, reading and description.
3. Single input costs and the principle of multiple input costs
This principle is not so much a test case judgment, as it is a matter of principle and thinking angle of thinking. Cost is always the primary factor in any decision-making items to be considered, the project is also true test, the entire stage to cost considerations should also be reflected in an objective and comprehensive test design, execution and maintenance of. When you encounter some issues to decision-making dilemma in the test, from a cost point of view to try to analyze it, you may find help in decision-making.
The cost of testing its time span can be divided into: single and multiple input costs input costs. For example: Writing test cases can be seen as a single input costs, because the preparation of test cases is generally carried out (Scrum Sprint start of each stage) in the planning stages of testing, although the latter will have minor changes, but the vast majority are at the design stage to the beginning of the forming substantially; automatic test is true, it is also a one-time investment; test (including: manual and automated test) is performed multiple input costs, because each a reasons for failure (product defect, defect test case, the test should be executed when a new version of Build all the test cases (test execution or by BVT only high priority test cases), test result analysis, debugging test case failed to determine the test cases framework defect or problem led to the failure of random test cases) to verify that the version of the overall quality has reached the specified criteria.
Think of all single and multiple costs to be introduced is to be able, in order to carry out rational distribution of investment and help us make the right decisions at different stages by the impact of different activities on the cost of the test to distinguish between tests, to ensure that the limited can test the premise of the burden of costs, maximize the efficient conduct testing. For example, when we realized, test case design and automation are part of a one-time investment, and execution of test cases is put repeatedly, we should actively think about how we can improve the efficiency of the test execution requires repeated investment, in when one input and multiple activities need to balance the need to give priority to the efficiency of investment activity many times, in fact, there is a lot of work to do.
For example: The first principle - a single use case covering the minimization principle - is a good example, the function test A three-point functions A1, A2 and A3, the surface on this embodiment implemented in the design and use Automation when Test_A1_A2_A3 the simplest, but it will bring a lot of problems in repeated stages:
First of all, such a failure analysis of relatively complex cases, you need to make sure in the end which is a function point caused the test to fail;
Secondly, Automation debugging more complex example, if the problem is A3 function points, you still need to keep through A1 and A2, and A3 to reach, which increases the time and complexity of debugging;
Third, a multi-step manual test adds uncertainty performed manually, by automated multi-step embodiment increases the likelihood of failure of the automatic execution, in particular those based on UI automation use case;
Fourth, (Last but not least) will not point related functions coupled together, reducing the likelihood of early detection of defective products back, which is taboo test work. For example: If an automatic test Test_A1_A2_A3 and follow A1-> A2-> A3 order to be executed, when present Bug A1, the entire test to fail, while A2 and A3 have not been performed to test. If at this time A1 of Bug for some reason take a long time to repair, then Test_A1_A2_A3 always considered failed because of a Bug A1, A2 and A3 and is not covered is always that there are potential risks and vulnerabilities here . When you finally before the product will be released fixes Bug A1 and take for granted that when Test_A1_A2_A3 should pass, A2 and A3 problem will burst out at this time, you have to continue to work overtime to fix the problem A2 and A3. Not alarmist, when the code A2 / A3 and A1 of Bug fixes related, so when you have a lot of design test cases, the problem could be worse ... ... really! :(
In summary, Test_A1_A2_A3 this design, only the one-time reduction in design and automation of investment, increase the burden and risks of testing performed repeatedly put to it is required, it is necessary decision (in fact, this decision is often occur, especially in the design of test cases) or select Test_A1_A2_A3 Test_A1, Test_A2 and Test_A3, be sure to consider the cost of inputs.
4. The principle of the test results of the most simplistic analysis and debugging
This principle is actually on a - single and multiple input costs input costs principles - automated test cases for the expansion and continuation. When writing automated test code, important to consider how to make the analysis of test results and test debugging easier, including: use case logs, debugging assistance information output. Because the execution of test cases belong to multiple inputs, testers should always be to analyze the test results, debug test cases, investment in this part of the activities is considerable. Sometimes, the testing framework to mention some auxiliary functions such as API can help achieve this principle very well. For example: Coded UI Test provides a similar API, see - VS 2010 test function learning (18) - Coded UI Test three must know the function, to better assist debugging based automated test cases Coded UI framework to achieve experience.
To test the theory test work indicates a major way forward, in the actual project also requires us to continue to "activate" the theory, the theory and practice better fit together. In my opinion, regardless of the success or failure of software projects and good and bad for us each participant is invaluable. As caring people, which we appreciate a lot of books I never mentioned things, as long as constantly to observe, understand and summarize, you will have more of their own knowledge, understanding and discovery. There are a lot of people write books praise, United States Code, the beauty of test, in fact, the project is beautiful, just see if you can go look at it more objectively.