The controllable suggestion of software test case for test progress--theory article _ Software test

A project in the process of testing, whether it is the PM or test points are ready to understand the progress of the test, so that the time to control the project. And the test in the process of the test is performed by the test case, then the degree of execution of the use case clearly can intuitively reflect the project in the testing phase of the progress.


Let's start with an analysis of the present situation.


It must be clear that the product line involved in a project is likely to be more than one, and that the method, granularity, and format of the use case design for each product line are different. Of these differences, the granularity of use cases is the most decisive factor for progress. Because of the current situation, each person designed use-case granularity are very different, some students may design more detailed, and some students may design relatively rough, without affecting the implementation of the use cases and other people's understandable, we say these are OK. But the most immediate problem with the issue is that the QC is not objective in its progress. This is obvious, and for the most extreme example, a writes 9 very detailed use cases, B only writes a very rough use case, but the execution degree and a is equivalent. When A's use case is fully executed, the QC is given a 90% progress, but it is clear that the actual progress is made to 50%.


We need to improve the situation.


In the first approach, all use cases are designed to be the most granular, with a granularity of 1.


We know that, if theoretically, each use case is indivisible, that is to say, the granularity of the use cases we design should be equal. If you can do this, the test schedule will be much better controlled. However, this is difficult to do. If everyone's use cases are accurate to the most meticulous degree, for example, the use of not streamlined causal diagram design use cases, then we will be very large number of use cases, which is also not conducive to our control, and in the process of implementation, because the use case is too meticulous, but the operation is a lot of efficiency is also a problem. And, from the present situation, it is impossible for us to go this way. Each person's understanding of the use case and the understanding of the function are not the same, it is impossible to achieve the same granularity.


In addition, there are problems with this approach. The granularity of a use case is 1, and it does not explain how important each use case is. When you submit a bug, the importance of the bug assessment, it is based on this, we believe that the importance of use cases is not the same, because the extension to go, even if the use case granularity of 1, the actual implementation of the progress is still not objective, there are errors. What we need is more accurate data and more responsive to progress.


So we propose a second method.


In introducing the second method, we introduced a concept-weight. I believe everyone is not unfamiliar with this concept, so we do not introduce more. Second, we have a requirement for the design of use cases--no expected results or concerns can occur during the execution of a use case, only in the final step of execution can the expected results or concerns be seen, and if the use case is in the middle, it must be divided into multiple use cases--the largest of which we consider acceptable.


Based on the above two conditions, we carry on the weight analysis to the use case, achieves the progress to be controllable.


The first factor is the project type. Through the analysis, we have roughly identified three types of projects: Upgrade packages, new projects, transformation types (may later be more detailed division). It can be said that, under these three types of projects, we design the use cases of the idea and granularity is not the same, of course, more to add to the individual factors. This is a maximum direction, and this direction, will directly affect our use case weight analysis, that is, the algorithm problem-of course, in various projects under the weight algorithm should be how to calculate, we need to practice to give more scientific basis, at present only give ideas.


The second factor is the use case design approach. The design method of the use case itself has little effect on progress, but because the design method directly affects the coverage of the use case, it indirectly affects the progress. So here we think this factor can be used as a factor to add weights to the computational method. Typically, a use case review or review should not have an incomplete coverage, but in the case of a change in requirements, it may lead to a decrease in use-case coverage. Before the use case is improved, we think that there is a change in progress.


Third, the parameter setting of the use case. This is the most important part, and the setting of the use case parameter directly affects the importance of the use case. On this point, our intention is to set up a series of parameters for use cases, and then the testers to set the values of these parameters, we will set a weight for each value, through these parameters to develop a use case in the project actual occupation of the proportion, so that more scientific response to the test progress. Such a person will ask questions, then the value of these parameters how to set, what the standard, if set improperly, then still can not reflect the progress of the test. But we have to say that this is an attempt, not a process in the formulation of the time to take into account the various issues, this proposal is no exception. And in the course of the trial we will give reference to the use cases, in accordance with their own use cases responsible for the principle, we have reason to believe that we will give the use case of their own design to give a correct, scientific parameters to calculate the most correct weight, I believe no one will oppose this point.


So how to make these parameters. We have initially customized these: use case concerns, the importance of function points represented by use cases, the difficulty of execution of use cases, and the time when the use case is estimated to be performed, by which parameter values are set.


Next, I'll make a model of the recent public utility payment, in which we try to use this method to analyze the use case weights.


(Our analysis of use cases is limited to methods that have not been validated at present, and specific implementation needs to be done through the elaboration and more scientific algorithms.) Here only gives a kind of thinking, for everyone to refer to, did not really give the specification. ）


First of all, this project is a new project, in other words, he has this independent function, even the cashier is also a redevelopment (functional similarity), so I think, this project is almost entirely new in functionality, so we do not need to consider other projects or upgrade package, I think the weight of the calculation method can be used in the simplest, The direct addition is the total weight, which is the progress μ=, where D is the weight of the use case already executed, and D is the weight of all use cases.


Give the weight rule: (weight w)


1, use case attention point, a concern point w++;


2, the use case represents the function point, corresponds with the bug, divides into three levels: affects the process the function w+=3, the project main function w+=2, the project minor function w+=1. (How to define the importance of a feature that needs to be considered.) ）


This article is reproduced from the 51testing Software test network, see more: http://www.51testing.com