Discussion on the quality of the evaluation test case
Take away from
Test era
forum
Leveret:
Everyone has their own characteristics when you write test cases, but what kind of test case is a better use case, this is a relatively real phenomenon, there are several questions, you can exchange your own Experience (if you want to communicate friends): How do you design how to verify your needs? Sometimes I don't know how the results are predicted, and the test case should be independent when implementing different stages. Generally, the design of reasonable input, unreasonable input, predictive results, generally commonly used test cases are generally used: equivalent type, boundary value analysis, error speculation, but these are theoretical aspects The concept, we are often doing it in actual design. Everyone should have their own experience when designing test cases. If you want, you can share your point of view out to discuss.
Seanhe:
I feel that there is no good difference in the test case :) At the beginning, I can find the most wrong mistake. I found that the use case of the bug found so far is a good use case, I think it is wrong. Because the test is not a problem, the test case is good and the test case does not refer to a single use case, but the coverage of the use case, a single use case, the coverage of all the use cases is not enough, the test work still failed. Therefore, the key to test is not use case design, but the method of testing, the method of use, and the design of the use case is just natural. Let's talk about how the use case is written, and there will be a lot of unclear unclear, so we can't fill it out, so we should write a default use of the writing is an iterative process. Different content is completed at different stages, and you can do it before execution. .
Leveret:
The coverage of the use case should also be from a single start, and many times, it is found that the use case is basically similar in many input and output, as for the tested range, can we consider the system in the system design phase? What do you think about the starting point? Is it necessary to consider or according to the specified category? However, the iterative process of the writing of the use case you said is compared. We generally test a judicial process before the official start, understand this truth, I think it should be relaxed. For peers of design test cases. Welcome everyone to share your own point of view.
ZHYBING:
The test case is good, mainly to see if the test case meets the requirements of the test content, which satisfies the test case required for the test content is good. It is not good to test the test case required for the test content.
Leveret:
Is the test content reflected in the test plan? Follow you. Is it just to meet the test content? Do you think so?
Jackei:
Some of the views are listed below: 01. How to predict the results in the case of "sometimes do not know the results", personal feeling is more clear, if the demand cannot be clear, or if the demand is not clear, the test case for this requirement The design should be postponed and exchanged with demand personnel in time and accurately define the demand as soon as possible. 02. Generally, the test method considered in the system test phase is a black box test, and how many methods are used for test cases? Personally, the equivalence class can be used to divide the equivalence class first, and then determine the test data using the boundary analysis method, and finally, the error speculation is performed through the past toilet experience or other experience, add part of the use case. For this problem, individuals have negatively viewed a lot of test books on the market, and many of the examples mentioned by many books are used as examples of Windows calculators or other simple numbers - such as input fields. Is 0-100, let you design the use case. Many times we don't have any obvious figures when using case design, these things are implied in business rules. I feel that we now have a lot of initial testing friends such as the ability to analyze business rules, and see Not deep test demand. Of course, these methods are also very limited. 03. For "test cases should be independent when implementing at different stages," I also agree. Personally think that the key should be made to figure out the role of test cases. As the development process, it is a collection of demand for demand, and then the system analyst analyzes the demand, forming a use case or software requirements specifications, and then architectural design, developers complete detailed design and encoding work - - Of course, this is not necessarily constant, but the general task is so much. Similarly, let's take a look at the process of the test work in RUP. Why do you want to distinguish the test design with test implementation and test implementation? Because the test work is now getting more similar, including the test demand, the design of test cases, and implementation of test cases. We now currently operate from human resources or from the company's processes to ensure full according to this specification, but we can clarify the role of test cases from RUP. The use case itself is used to guide the implementation, and the use case implementation can be the automated script or the specific steps of manual operation. Test cases can be fully independently implemented with specific applications, which can be influenced by applications. As for why I will explain it below. 04. For many times, it is basically similar to the design in many input and output. "I think this can consider" reuse "of test cases. In fact, the thunder is also normal. 05. The following will explain some of my individuals for test case design. I am very agreeable to Seanhe's views on testing cases, and we are also thinking about it in reality. The test case will not be designed to be designed, it is a purpose and premise. Personally, the test case is used to guide the implementation of the specific test implementation, including the implementation of the automated script, and the implementation of manual testing steps. For testing cases, the individual's coverage is not the purpose of testing cases, but the requirements for testing work - it is required to meet the results of the stage of test case designers must meet certain requirements. The test case itself cannot guarantee the coverage needs. So, the test needs are said, and it is said that the test demand is determined here. Leveret also asked this question - "As for the tested range of the test range, can we consider the system in the system design phase? Consider the starting point?" Personally think that the test scope is also the determination of test demand. For a product, its development and testing is not one-time. With the iteration of the development version, the test work will continue, and we are different for each version of the test range.
Note that there is a key here, that is, the starting point of the test range - the determination of software requirements. So how do you clarify the demand for software? --version. If the progress and content of the work can be clearly defined, we must first consider the version determination - the version of the software needs is determined. Through the version control of the software requirements, you can clarify the features implemented in each of the different versions of the product, which features will be implemented in later versions. Here, it is mentioned that the concept of the version is also required to be managed. Since a version of the software demand has been determined, then the next development work can be carried out within the scope of this demand version. What is the test demand? Personally think that it is a need for test, and its source has many aspects. 1. In the demand phase, software requirements specifications and use cases for software descriptions, the description of the business rules can sort out our earliest test needs, this part of the test demand will completely come from software requirements, which is one of the current phase test work. basis. But everyone should see that our testing works from now. In this period, we have a very very important job, we will try to check the demand document. Here, the inspection of the demand document is mainly two aspects: (1) Check the correctness of the demand document description, is foolish to testers to be very familiar with the business involved in the real system, such as a simple financial software, then tester It is familiar with the accounting work, the financial system is familiar, do not superstitious the so-called "real needs" when checking the demand document, there are two problems, one is whether the user really describes its needs correctly Second, whether the demand person can really understand the demand correctly. In addition, there is also a user's demand in line with the problem of industry specification. If it does not meet, if there is a confirmation - there is a hidden danger here, the user may suddenly ask them to take industry norms in the later stage of development, let your demand Change, so it is clear in advance. (2) Check the accuracy of the description document description. It is mainly to consider whether there is a blurred place in the document, which must be clear for yourself unclear. At this time, it is necessary to guarantee the testability of the demand - I am proud to say that the guarantee demand can be fully served. The specific point is said to ensure that all software needs can be clearly determined by certain methods. If you have a clear judgment criteria for a certain requirement, you should request a demand person to modify or supplement the needs - a requirement that lacks accurate definitions, we can think that developers cannot accurately implement or implement an error requirement If this problem is found when the application is delivered, the consequences are different from the project. 2. With the development of development, the architecture design and detailed design of the development department will also be submitted later. At this time, we can supplement the original demand according to the design documentation. Note that we have selected the contents mentioned in the design documentation, which can only be used to adjust our test requirements only if the Software Requirements Specifications or Some of the Examples I have defined. In some cases that do not match software requirements, you need to discuss with designers and demanders, determine which one is subject to, then adjust the test demand. This part of the work has already included the design of the design, and we will continue to work hard to find out the sign of defects as soon as possible. 3. After the application is delivered, the test department began to perform the test. At this time, it is likely to find some defects through some methods that we do with the test case designed by the test demand, then this part of the method should also be sorted out in the test demand. OK, I believe that you should understand my point of view. For a sustainable company or sustained product, all of its things are constantly accumulated.
For test requirements, not only in a version of the development process, iterates in different stages, but also has an overlay in different versions of the entire life cycle of the product. Since the test needs are clarified, the test case is considered to become the natural thing that seanhe said. We can perform test case design based on those test needs that have been identified at different phases, and then continue to adjust the test cases after the development process continues to increase or modify the test case. If we come from the entire life cycle of the product, it will find that it is actually not the end of the test work, and the test demand and test case maintenance is over, because the end of a version is the beginning of the next version. From this large-scale, our testing needs and test cases will always be willing forever. Ah, today's mood is better than the original reply, I hope to have some help to all friends. However, it seems that there are some running questions. The topic is "Good and bad" on the evaluation test case. "I still have to give an answer: Individual thinks that the quality of test cases can have several aspects. First, whether it is independent of the specific implementation; second, whether it is more convenient to implement it; third, whether it is easier to maintain. Other aspects, individuals think that it can be seen as some criteria for the "good or bad" work for evaluation test case designers. All of them are personal views for reference only. If friends want to discuss these issues, I can send email to my email: jackei_chan@hotmail.com. Jackei:
I also thought about the factors for evaluating test cases: 01. Easy to use: Is it easy to use, such as if you can take it easy to take a simple look, you know how to test according to the use case; 02. Easy maintenance : Is it convenient to maintain, especially when a requirement or design changes, it can complete maintenance work; 03. Validity: Do you guarantee a relatively long life cycle of the entire product? Can be used repeatedly to ensure effectiveness. Throwing bricks, I hope everyone will continue to add.
