First, the definition of test cases
Test case (Test Case), is a set of test inputs for the preparation of a particular goal, execution conditions and expected results, in order to test a program path or to verify whether to meet a particular need.
Second, why write a test case
1, clarify thinking test
Some systems has always been a large and complex project, it is necessary to subdivide the project functions, each function according to the idea written by way of example to organize test system to avoid missing out function points to be tested.
2, clear the test mission
After writing use cases, you can clear the total number of use cases they need to perform in order to estimate the testing effort. And you can clearly know the progress of the actual test execution, statistics and very easy to track our work remaining and return to work.
3, standardized test behavior
Everyone principle for understanding the development and function is different, the same case, each person's level of understanding and extensions are not the same. For newcomers have not tested in terms of experience, but also a clear need for detailed use case specifications to reduce omissions.
Third, how to write use cases
1, the source of test cases
a) analysis of requirements documents
Requirements document is the basis for the preparation of the first test case, the purpose of the needs analysis is generally:
l understand the background of the demand;
l analysis of the reasonableness of the demand;
l clarify the scope of the demand;
l mining implied needs;
b) understand the principles of development
l The implementation framework development;
l clear input output code rule;
l test direction to reduce the deviation;
2, test elements
a) Test Environment
What test system? What hardware and software is required?
b) Test Data
Enter the value of tests performed
c) Test Procedure
Providing step execution of the test. General control is completed in three steps. Otherwise, consider the need for a split embodiment, because each of the test object corresponding to the use case should be a unique.
d) the expected results
Expected results obtained according to the software requirements of the output. So the actual testing process, if the actual test results do not match the expected result, the test will not pass; otherwise the test passes.
e) Example of the title with
Use case title is a description of the subject of the test case, it is necessary to concise, but also be able to clearly express the purpose of the test case
f) use Example No.
Uniqueness, for the test track and maintain the definition of test numbers designated for each use case.
g) was level with
Generally divided into four levels, P0, P1, P2, P3.
3, designed using the method of Example
Combined application needs to say something about a different approach:
a) equivalence partitioning
The input value is divided into valid and invalid equivalence class equivalence class. If the input specifies the input section can be divided into an effective equivalence class, two invalid equivalence class;
b) boundary value
Any test scenario boundary value method can be used for design, can enter numeric type, characters, etc., to be tested comprising the boundary point, the next point, from the point.
c) error reckoning
Error reckoning, that is speculation and errors may often appear to advance the development of use cases, to avoid risks. Experience influence popular designers of error reckoning testing, different testing experience, designed test case difference will be great.
d) Causality FIG method
List all input and output, the input and output sort out cause and effect diagrams and dependencies, do the design according to each dependent. FIG method considers causal combination input, is particularly suitable for the relevant constraints associated with each other and a plurality of input conditions.
e) driving method determination table
Determination table suitable for solving a logical combination of a plurality of conditions, the combination of various logic set out, to avoid missing. Values listed under each condition corresponding to all possible cases, without regard to the order and condition, then action item list results, determination results for each condition. Finally, the rules may be appropriate to simplify and merge.
f) Orthogonal
When the input many conditions, the design method, etc. FIG cause out of the number of use cases are often more surprising, orthogonal method can effectively reduce the number of use cases. Orthogonal core idea is to select a representative point from the test data to a large number of tests to reduce the number of test cases.
g) Method Scene
Process flow chart depicted, and then flow into a control flowchart of FIG designed in accordance with the scene control flow graph, then test cases according to the scene.
Combined with such a demand:
Decision table:
Fourth, how to enhance the ability to write use cases
1, from the large to the small grabbed the first Test Framework
Highly recommended mind mapping tools to quickly sort out clearly to test modules, test point, and structural relationships, make their first, full frame and impression of the content to be tested, mind map can quickly allow developers to take over the test students quickly understand and see bias and omissions in the general direction.
Additional details of the place, combined with recommended several graphical tools, such as flow charts, fishbone diagram and NS chart, as detailed in another article "Software development process commonly used map"
2, and more latitude to think and coverage
Reflections from the interface, functionality, performance, compatibility, abnormal angle, as far as possible a wider and more comprehensive coverage.
3, familiar with the business and system test
Any system has a large business background, such as testing financial APP, to understand the financial services, business processes and logic funds, financial products, to understand what the settlement, account, and pay the difference and the role of several systems. In order to more accurately grasp the written test focused on the use case.
Any system in use, there is a familiar process, the more familiar with the system, the more easy to find features of the system, as well as places prone to errors and exceptions.
4, from the user point of view
From the customer's point of view: what customers need and what customers want, not what the customer wants, that is, customer usage scenarios. This will help us to better mining and thinking implied demand. Can even pull a few colleagues to experience the next product, look at their behavior and operating sequence is like.
5, pay attention to the use case review
Emphasis on the assessment test and review comments, often see the use case design errors and some good case design, you can also see more use cases and test ideas of others, they may say.