RUP test process practice
Chen Lei
Key words:
Software Test Process Practical Testing Example RUP
RUP (RATIONAL UNIFIED Process, Ratinaol Unified Process) is a set of software development processes raised by Rational, and the latest version is 2003. The biggest feature of RUP is that it provides a complete set of software development process frameworks, any person or organization can cut this process according to its own needs, and make it a personalized process according to your own needs. The reader can refer to the "RUP2000 Chinese version" circulated on the network.
(Rational and Rational Unified Process) Rational Software Corporation trademark or registered trademark in the US and other countries.)
There is an old saying: Everything is difficult. It is usually what I feel very difficult when you are doing things, but as long as you go to the door, you will get more and more easy, getting more and more smooth. Write articles is also true. However, the beginning of the author said that it does not write articles, but it does not write the beginning of the article. Many of the novels that have been seen in the past, whether romance or martial arts, will take a long space as "primer", or called "wedge", used to give some information about the same novel. Whether a novel can attract readers, this part of this content has also played a lot. However, the author as a technical worker, most of which writes the technical articles, generally, the structure of the article, the structure is going to understand early, only this start, I really don't know how to write. But think about it, since it is not good at this, then try to write the details, easy to understand, try to make readers will not feel the feelings.
Software tests as a separate position or industry, is not a new thing of the software industry, but it is indeed a red fire with some new ideas in the past two years. For example, if the agile development process, test driver development, etc. What - this, from the publications and sales of relevant books, you can see that people engaged in software testing have gradually become more. But because it is just starting, most software companies in China are still in small and medium-sized development teams and even workshop development, it is impossible to provide too many test positions. I want to find some high levels and experienced testers. It is difficult to get difficult. This ultimately leads to a result of most of the domestic test practitioners in the "primary stage".
The author has long been active in a few well-known test forums in China. I found that the problems that everyone hoped to discuss can be divided into two: one is a question for some test work specific operation methods, one is to use for test tools. Overall, more problems are concentrated in the latter. This seems to have become a common problem in the domestic software industry, whether it is development or testing, always hopes to achieve an ideal for all through a tool or language. If you really want the tool to change everything, this wish will always fall. In the former, most of them have entered a small and medium-sized software company that has just begun to pay attention to software testing, and the company's development team may only have one or two newers who know the software test, when the company needs to carry out certain aspects When the test work, the lack of this part of the relevant experience has changed to select help through the network.
The application of the test tool can indeed improve productivity, and for testing tools, it is also unsatisfactory, but in the practice of the author, if you want to improve a team's work efficiency and improve work effect, pay attention to the process and method It's far better than paying attention. Test tool learning, introduction, and use, it is a process that needs to consume a lot of resources, and it is also very critical for the choice of tool selection and introduction of tools. If it is responsible for this work is not an immersion in the software industry for many years There is a rich experience in testing experience and knowing the development process, then the development team will take great risks for this. Even if the test tool is successfully introduced, the efficiency of the tool itself can also be reflected in the short term. Here, the author hopes that the software company that is just or is preparing to form a test team, don't give too much pressure to the friends who have just entered the test industry when considering the construction and test tools of the test process, because these two work is not only software testing It is related to it, and it will also involve project management, development process. Easy to make a decision will only have an adverse effect on future testing work in the team.
In this article, the author does not intend to make any recommendations on the test tools, and will give some experience with the actual reference value on the testing process and test methods on the network.
When should I start?
Does the test case do you have to write? If you write, what extent should you be more easy to maintain in detail?
What kind of test case is a good test case?
Test, such as how to overwrite the test requirements? What is the relationship between test demand and test cases?
How to ensure that the test demand is organized and the design of the test case does not waste too much manpower or other resources?
......
These problems can be described as older, in the forum, on the MSN, or in the email, there will often be a friend asking some questions in this regard. I believe that no matter whether it is a newcomer, or a friend who is engaged in testing has a period of time, it will be considered in the work. Is there a relatively clear answer?
I believe that some friends have been thinking: these problems are not very difficult, and it has been understood in RUP's description of the test process. Software testing must be completed by planning testing, design testing, implementation testing, implementation testing, and evaluation testing. The planned test phase needs to formulate test plan, organize test demand; design testing stage to design test cases and test procedures, to ensure that test cases completely override test requirements; implement the test phase to implement specific automation scripts or manual operations according to test cases The implementation test phase is performed through the automated test tool or manual manual to perform those automation or manual scripts; the final assessment phase must make an objective evaluation of the quality of the software quality and test work. There is also a detailed work guide and document template in RUP!
Yes, these are not wrong, and the description of the software testing process is much more vivid than the text of the author above. However, we can also see that in RUP, more is more focused on the management of the process, or more accurately, RUP is a stable, guiding role in providing us with a big direction. The frame, rather than some specific, involving the operation details. This is also why many friends communicate with the software test in RUP, but once practical applications still find out the reason. The author today hopes that you will discuss it with you, it is precisely some working methods and experiences summed up from actual work when practical RUP testing processes.
For the specification and some basic concepts in the test process, the RUP has been detailed, and the author will not repeat it later. If necessary, readers need to refer to the relevant part of RUP. The contents of this article are:
1. How to determine the scope of the test work and how to organize the test requirements; 2. How to grasp the particle size of the test case when designing test cases;
3. How to balance the availability and maintainability of test cases;
4. How to ensure the effectiveness of the test case and reduce waste of resources in testing;
5. A simple but practical example will show how to apply the author's method to the test process.
Here, I have to declare that the author has worked for three years, whether it is development or testing, work content is always launched around the information management system, and for testing, it has always been limited to manual methods and simple in the system test phase. A black box test is made using some test tool characteristics. Therefore, in the contents described herein, it is inevitable to be affected by the objective environment and the individual experience of the author. Because of this, the author does not guarantee that the methods and views of this article are suitable for all organizations and individual software development processes. Just hope that it will provide you with a thinking to help more people conduct personalized RUP testing process, jointly improve the level of software testing industry.
In addition, the examples used in this article are some of the authorities, if they violate any third-party organization or personal interests, it is a coincidence, please notify the author through the E-mail, the author will release this article again in the future. Corresponding adjustments.
How to determine the range of testing work?
For software products with life cycle, its development and testing is often not one-time, because with the emergence of new needs, and the improvement of the original version, the new version will continue to release (even for Some projects operated by customer customization, produce a number of internal versions during the development process and after the release of the release). With the version iteration, our test work will continue. At each iteration, it may be affected by factors at the beginning of the entire working phase, such as market demand, established distribution time, and the resources caused by concurrency work, so that we have to consider the quality requirements for software quality. Moderate, eventually makes our requirements for testing at each stage or the content involved may be different. This change will eventually affect the determination of test demand.
So how do you determine that each iteration is the range of testing work?
In the practice of the author, the determination of the scope of the test work is usually determined by the determination of software requirements.
However, there is a very practical problem that this is this: software demand continues to change during the development process, sometimes there will be new demands in the later stage, and some needs have discovered the original demand after delivery of the internal test version. There is a defect, and will be reworked again, how can it be determined before the software is finally released? Ah, these are things that let our developers and testers take great headaches. What should I determine in the frequently changed demand? What is our content we have to test at a certain stage? Or what kind of way to improve the problems we mentioned above?
A practical approach is to realize the version of the software requirements.
Since it comes to it, it is inevitable to say some questions. The author has always believed that the software demand is the source and basis for development work and testing in the development of plans, and we will use the work and basis for work, and we only control it on the source to ensure the smooth development of the following work.
If you want the progress and content of a phase, you must consider the version of the software requirements. The "version of the software demand" mentioned here refers to the life cycle of a software product. When a new version is an iteration, it is necessary to determine the need to implement in this version as soon as possible, and The version is compared, which content is added, which content is adjusted. At the beginning of this phase of work, at the beginning of the work, it is clear to all the information that needs to understand software needs. And if there is a constant demand change in the development of this version, it should be based on market strategies, published issues, customer needs, implementation, difficulty level, and impact on existing work. Demand is moderately divided, strictly defining the needs of the current version, while other parts, as a software demand for future versions. If some friends think that the above content is still too theoretical, there is a more practical way to operate. Then you can only say that the changes in the demand, and the change caused by the design of the demand change must be discovered, early discussion, early decision, early adjustment. This may be more important to rely on the active work of the relevant person in charge of the relevant person in charge, rather than relying on a clear way.
Note that a key here is that for software requirements, it also needs to be managed strictly according to the version, or
Manage it with "baseline".
How to organize test requirements?
Once the range of test works in the current phase is determined, we can start considering the finishing of test needs -
It is a clear definition to "test what" at this stage. The test demand is determined to develop a schedule, allocate resources, and how to determine if a phase test work completes to provide a measurable standard. Of course, there are more important points, the test demand that has been determined is the basis for our test case design and considering test coverage.
The first step in the test demand is to "test demand."
Test demand? Yes, I don't know if you think that "testing" in "Test Demand" here is a verb, refers to
It is the inspection of the software requirements itself.
what? Is this not exceeded the scope of testing? Does the tester should only care about whether the implementation of the software is related to the needs? This requires not too high for testers. - This is some different sounds that the author will talk to the test staff in the past.
Here, first of all, a question is to do, what is the work of software testing?
In "Software Test" (Ron Patton [United States], the Chinese version is published by Machinery Press, this book is a classic textbook for test novices), a clear and simple definition: Software Tester The goal is to find software defects, as early as possible and make sure it is fixed.
! Here is to "find software defects" as early as possible. That is "as early as possible." When is it going early?
I don't know what I have for "Software Engineering" this book. In the books of multiple different versions of software engineering at the author, there will be a similar description for software defects: the sooner the defect discovery, the smaller the cost of this defect, design, design, encoding , Test, release, etc., find the cost of repair after defects, 10 times higher than the cost of repairing the previous stage (see the figure below). In this way, the answer to the above question naturally became the "scorpion on the bald": starting from the demand phase! Start with "test demand"!
Note that the author's view is not to cancel the "Demand Review Conference" in the team, and there is no conflict here. What I want to tell is how testers should look at the software needs, but not to take responsibility assumed by the "Review Conference" to themselves. On the forum, I also saw some friends asked: How to test demand? Every time I see such a question, I can't help but feel excited, because I have always discussed the problem of friends in this area, and there are few days. In the actual work of the author, the inspection of the software needs includes two aspects.
First, check the correctness of the software demand, that is, to ensure that the content described in the demand document is true and reliable. When doing this part, don't superstitize the so-called "real needs of users", because we must consider, ask for these needs, is it really correct to describe your needs? Is our demand person really understand the user's needs? Is there anything that is considered to be in business processing in business processing, but not as a demand? Is there some software that they believed that their past use has provided the corresponding function, so we should also provide, but not commented? Regarding this problem, there have been friends to mention different opinions, think so that the requirements for testers are too high - they must be familiar with the work of demand staff, but also to familiarize themselves from the industry's business. But the author is still stubborn, as a tester, or a comprehensive, in-depth understanding of the business involved in the industry's industry, it is not the requirements of a tester just started, but if you want to For an excellent tester, it is inevitable to pay this part.
The second is to ensure the testability of software requirements. For "testability", the concept of the author is: For a software demand or a feature that needs to be implemented, there must be a result of a clear predict, and can verify this clear result by designing a repetitive process. Specifically, it is to ensure that all the needs of all the needs can be used to clearly determine whether to meet the description of the demand document. If a clear method is verified, it is impossible to verify it through a clear method, or it is impossible to predict the results of this demand, and the demand person should be modified or supplemented by the demand document. - We have reason to believe that if the testers cannot produce accurate understanding of demand, then developers are also unable to have an accurate understanding of the same needs. For a defined software demand understanding, it is a major reason that leads to rework during irregular development. If it is considered necessary, it should be confirmed on the "Real Evaluation Conference" to consistently understand the needs of the demand.
Of course, there is a lot of how to improve the quality of software requirements, there is a lot of books on the Internet or published books.
More specific, practical methods, if you are interested, everyone can find a reference. However, if you are a tester, then the above content is still very useful to you. I believe that you will find this approach to the benefits of this approach as long as you try to try at work.
Now the current test work range has been determined that the corresponding version of the software demand has passed the review, we can
This has been tested within the determined range. We can refer to things on your hand, usually there will be software requirements stations (hereinafter referred to as SRS) and use case (hereinafter referred to as UC) - of course, may also be a SRS containing UC. By reading to SRS and UC, we can obtain a basic understanding of the services involved in the software from the description of the document on the characteristics and business processes. For example, the user has to do something when dealing with the actual business, what is the order between multiple services, and the user has special requirements for the service business, and so on. This part of the rules will be the most basic part of our test demand. As for the expression of test demand, the author believes that everyone can design according to their needs, and there is no need to limit the way to the end of the form or use the text mode, just grasp a principle, it is OK: in a test demand, easy Understand natural language, clearly describe a content that needs to be tested. For multiple test content, it should be peeled off as much as possible to ensure that a test requirement only contains a test content.
In addition, everyone may also notice that this stage of the software development process is usually no user interface (hereinafter referred to as UI) available - Although the work description of the demand phase in the RUP includes the portion of the UI design, there are many At this stage, it is still unable to provide a determined UI - means that the test demand we have obtained is completely business, and does not include the UI-based part of the rules, which is the final concrete implementation of the software. Phase independent.
As the development work continues, the development department's architecture design documentation and detailed design document will also be submitted later. At this time, we can supplement existing test requirements based on design documents. Note that we have selected the contents mentioned in the design documentation, which can be used to adjust our test demand for content as those that have been defined in the SRS or UC. The parties do not match the software requirements, you need to discuss with designers and demanders, determine which party as a baseline, decide whether to adjust the software requirements, and then add appropriate or adjustments to test requirements. For example, for some algorithms, it is necessary to consider the calculation formulas defined in the design document, whether to express whether the algorithm described in the software needs is the same meaning? For some constraints or business rules, whether the design document is consistent with the corresponding part of the demand?
Oh, after reading this part of the content, I am afraid some of the friends fainted to the ground, and some friends who have not fainted will also ask for an objection:? ! Do you have any inspection of the design work made by developers? ! Just let us check the demand, now let us check the design, really make us all!
No way, in order to make the software, only the shortcomings of the shortcomings are only, everyone can only have worked hard. Our work should not only limit the defects that exist after the software delivery, and should strive to find the seedlings that appear in software defects early, and try to prevent the emergence of defects.
Although not to say that in all teams should be taken by testers and "test demand" and "test design", testers role in these work is not alternative to other characters in other teams.
The development department completes the code implementation, submits an application for internal testing, and the test person should have been prepared by most of the test cases and test data, and the test department will begin testing. Usually during the test of the test, even if we have prepared a very sufficient test case and test data from the "pass test" and "failed test", there is always some shortcomings of defects. , Or is an existing test demand and test cases that have not been covered. Then, for this part of the defect, it should also be added to the test demand, and the corresponding test case is designed to facilitate the next version iteration. OK, I believe that you should understand my point of view: For a long-term development team or continuously developed products, all of its things are constantly accumulated, and it is concluded. Regardless of the software demand or test demand, it is an iteration in different stages, not only in a version of the development process, and it is also an iterative and accumulated in different versions of the entire life cycle of the product.
About test case
When did you start design a test case?
How to write test cases?
When is it to complete the design work of the test case?
The above can be regarded as the hottest problem in the design of the test case design, and will be reissued by different people every other period of time. Asking questions have a friend who has just entered the test industry, and it has also been re-caught in the confused "old hand" after a period of time. These problems seem simple, but if you want to answer, everyone is satisfied, it is not easy. Such a high difficulty, the author does not dare to have too many expectations, or write your experience, I hope to have some reference value for everyone.
The test case is a collection of test inputs, execution conditions, and expected results developed for specific targets. These specific targets can be: Verify that a specific program path or verify that it meets specific needs. - This is the definition of the test case in RUP. In actual work, the design and selection of test cases is the best way to examine the work ability and experience of testers.
If you have said that the author has launched the test demand in the work, the design work of the test case will become a natural thing. If you start finishing the test demand during the demand phase, then when this part of the test demand is finished, you can start the design of the corresponding test case. With the continuation of development, the corresponding test case should also be added or modified after the test demand is constantly supplemented and adjusted, and the corresponding test case should be added to ensure the validity of the test case. Here, the author should especially emphasize a little: the completion of the test case is not always for all, because the test case is from the test demand, and the source of test demand includes software requirements, system design, detailed design, and even after the software is released, after software All software defects found before the end of the product life cycle. The diversification of the source is destined to test the test demand very much. Once the test demand changes, the test case must be re-maintained.
If you are more familiar with the iterative method of software development, you can use the same method to design the design. The final result is that your team will gradually have more and more comprehensive testing requirements and test case libraries, and more and more testors can put them on the testing process and the choice of test cases.
At least in the practice of the author, although the previous period requires a relatively large amount of investment, over time, without using the automated test tool, the efficiency of each test work is also greatly improved. .
Regarding the method of designing test cases, whether in the published professional test book or online professional test forum, there have been a lot of very good articles to explain, the author does not intend to occupy too many levels re-reference, everyone If you have this, you can easily find these information over the network. Here, the author just wants to comment on the misunderstanding of many beginners. I believe that for any testers, equivalent classification methods and boundary analysis methods are the earliest contact, but also the most basic and easily used test case design method. Many friends also know that the equivalence class is divided into equivalents first, and then use boundary analysis to determine the boundary value required for test. But many friends also mentioned that after working for a while, it was found that there were fewer places where these two methods can be applied, and the two methods really only apply when checking the edit box input type and input length. ? of course not. For some questions raised by friends who have just contacted tests, the author believes that many test books on the market must bear great responsibility. For example, in many books, when taking the test case design, there is no way to use the same example - Windows Calculator program. It is usually telling you that there is a permitted input range for the calculator (such as allowing an integer greater than 0 less than equal to 100), and then requires the corresponding test cases containing legitimate data and illegal data. Of course, it is only such a simple description, we can have a lot of test cases and test data, such as considering the input data type, for the input data type, etc. Consideration, etc. But in our actual work, many times I don't think so too simple software demand description, many times these content is implicit in some algorithms or business rules.
Let's take an example now:
"Double balance declining method is two times as the depreciation rate of the average annual limit method (no deductible value) without considering fixed asset residual value, multiplied by the fact that the value of the initial fixed assets in each period is obtained. A rapid depreciation method of the existence of the existence. The year-on-depreciation rate = 2 ÷ Expected use period × 100% monthly discount rate = year-in-year distribution rate ÷ 12 months reduction = period fixed asset book net value × month discount rate In order to ensure fixed assets When the end of the year, the book net value was equal to the previous two years of the expected net residual value. The fixed asset net value was deducted by the fixed asset net worth expected the average amortization. "
The above content is a method for my country's current financial system on fixed assets depreciation - the specific algorithm of double balance decreasing - You can find this part of this part and some corresponding examples in any accounting book. We don't care about the depreciation of fixed assets. The author wants to know if you have found it after reading the above description. We should at least two years of depreciation for the depreciation of fixed assets when designing test use cases, at least two years and greater than two years. Different types. This should also be considered an equivalent class division method and a boundary analysis method.
In fact, restricting us to better use these test methods for test case design, is not a way to use the application range is not broad enough, but because we cannot analyze these specific algorithms or business rules related to these actual services. It is impossible to excavate deep test needs, then the application of these two methods is limited. This is also the reason why the author repeatedly emphasized to deepen understanding of software needs.
There are also two other ways discussed on the network - the error speculation method and causal graphics are not widely used due to poor reliability and relatively complexity.
How to divide the particle size of the test case?
We are unlikely to include all test needs, because many features and different paths
The combination will make such a test case as a giant typical, completely does not have operability. - Unless your software is really small, it is very simple, but if there is such a software, I am afraid that there is no test and release.
Of course, this is not to go to another extreme, providing one or more test cases for each feature or feature defined in the demand. The key here is to find a suitable degree.
The recommendation of the author is to pay attention to effective functions.
Effective function: In fact, in the actual business involved in the measured application, when the user works in manual conditions, the entire business process has practical meanings. The feature of this feature is when we restore this function separately from the computer software to the user's original manual status, its completion can be used as a sign of a phased end of the user's actual business, rather than once it is independent from this business process. Lost mean. After the service is completed, you can provide the information you need for other users or services.
The key to "effective function" is different here:
1. This feature is to restore to the original manual business process. Our computers and software are to help users solve some of the cumbersome and inefficient problems in the handmade business, and some of the proposed solutions that are faithful to the original working method or slightly changed, not to change all the business processes of the user. Therefore, it should be determined from the perspective of the user's actual business.
2. Is this feature marking a phased end of the user's actual business? And after this business is completed, can the completed business entity delivered to other users or services for completing the following work?
For your convenience, we can take a look at the example below.
Take our common financial software, when adding an accounting voucher, it is usually necessary to fill in the accounting subject. When using your computer to complete the work, we can use the software's functionality, from many options to choose a subject. Or enter the subject via account code. This feature is very likely that as a feature requirement in the software requirements specification specification, then the choice or input of this subject is not a valid function? Let us try to use the above rules to measure it.
First, this feature exists during the user's manual business processing, this function is that the user is completed in its own brain when the user fills in the credentials - the user will choose the appropriate subject as needed. Fill in, this feature saves the additional labor that the user pays when the memory of a large number of accounting accounts. We can think that this feature provides a simple and variant method for the user's original work.
So what does this feature mean for users? We can see from the above description, the user wants the software to provide a full voucher such as a full credential, not just convenient to fill in accounting subjects. Fill in the accounting subject is just a step of adding the credentials, separately extracting this feature without any practical meaning of the user. For users downstream of business processes, it is not only only an information on accounting subjects, but a complete accounting document containing accounting subjects and other accounting information, otherwise it will not be possible. In this way, this feature is not a valid feature, we can describe its most important tests in the test demand, should not be used as a separate test case to appear in our test case. And we really pay attention to test cases should be the actual function of adding accounting credentials.
In addition, we also need to pay attention to how to distinguish between multiple functions of relying on relationships into individual valid features. For example, now there are three functions of A, B, and C, where B function begins to depend on the completion of the A function, and the A function will make different reactions if there is a different completion state, and the B function will make different reactions; C function pair B This is also true. So this time, should we include three mutually dependent features in a test case? This kind of approach is not ok, but we can also judge first, these three functions are valid features (you can use the method mentioned before trying to judge)? If A, B, C are independent valid functions, then we can find that dependency between them can be understood from the above description, which can be understood as a state or data dependence. The latter function is concerned, what kind of "input" is finally provided by the previous feature, not what the previous function has made. In this way, we can completely contain them in several independent test cases, while in the beginning of each test case, different inputs are described as different pre-conditions. Does the test case should contain all the details?
This is a hot problem that heard the most complained in the network: the company demands to carry out test work in accordance with a strict norm, must write all test case documents, and the writing of documents must be specifically concrete, and to refer to the test Test case document is performed. If the test case document writes too simply, it will be dedicated to lazy. However, if the operation steps are described in the document, like the following:
01. Enter "User" in the "User Name".
02. Enter "Password" in the Password entry;
03. Click the "OK" button.
Such a description method seems that the operability seems to be enhanced, and anyone can take this document.
Test staff, check if this function is defective. But we don't forget that during the development process, the existence of changes is inevitable. Once the demand, design, or some details in the application have changed, such as "user name", "operator", "password" becomes "password", "OK" becomes "login", or The data type accepted by the input item changes, then all test cases related to this part of the content need to be modified. Otherwise, we can ensure that these descriptions are the same thing as these descriptions? If we only have such a test case, maybe everything is not a problem, but for a business complex, functionally complete system, if you describe the test case according to this method, you will eventually produce a lot of test case document, or have a single document . Whether it is one, if there is a change similar to the above, the maintenance document will become a hell experience.
This is why this issue that appears in the network, and each appearance will be concerned about the attention of the test peers. So what should this question should be solved? Is the test case not written all the processes? How to include too much trivial details in the reduction in test case document guarantee the operability of test cases? What is the method to improve the efficiency of our maintenance test case document?
The author's suggestion is: Focus on Test Thoughts rather than paying attention to the operation steps.
To understand this problem, we must first understand the role of test cases.
Like the use case, the test case is not used to describe the specific implementation, but focusing on the idea of processing problems - thinking about a clear test content. As a designer of test case, how to understand basic flow and alternative flow? How to analyze and find all the paths that need to be covered and the features that need to be checked? We should describe how we will test in the test case, which we will test, rather than simply record the cumbersome steps on how to operate on the application. Designing test cases as a form that fills in the specific operation steps is the most misunderstanding of people's test cases. There are two ways to write traditional test case documents.
One is to fill out the operational steps: The operation steps will be performed step by step in the software, including all operational items and corresponding values.
The other is to fill in the test matrix: will be operated as a field in the matrix, and one of the matrices is the value of these fields.
On the Internet, the parallel arguments of these two ways will lead everyone to the two extremes: either use A, either B. Everyone ignores a point, for the debate of working methods, essentially the controversy of the tool is not a matter (for example, the VC, BCB earnings). If different methods have their own advantages, we can use the part of the advantage to be used together by the way.
The advantage of the list of operations is to analyze the basic stream and alternative flows clearly describe your test ideas. The test matrix is more suitable for storing test data, especially those that need to be manually given a determined value.
Below, let's take a look at an example, of course, this example is the same.
Demand Name: User login security verification
Demand Description: User login security verification is to ensure that users in all logged in to the system are set by the system administrator in advance in the system. Using the username of the system, or the username is entered correct, but the password is input to the error condition, it is not possible to log in to the system. When the user uses a username or the wrong password that does not exist, the system should give appropriate hints. If the user cannot log in to the system with the correct username and password three times, the system should give the appropriate prompt and exit the current program. If the user logs in to the system using the correct username and password, exit the interface and go to the main interface of the system. For the user login interface and program main interface, refer to the corresponding UI design document.
Test demand:
01. Check if you can log in to the system using the correct username and password;
02. Check if you can use the wrong username or password to log in to the system;
03. Check that the username and password login failure exceeds three times, and will automatically exit the current program.
Test case:
Sequence number operation process description 1 Enter your username. 2 Enter the password. 3 Confirm login.
Serial User Name Password Expected Result 1 Correct User Name The correct password is logged in to the system and go to the system main interface 2 Correct username error password Unable to log in to the system and prompt password error 3 Error's correct password cannot be logged in The system and prompts the username error 4 Error's username error cannot be logged in to the system and exits the current program 5 empty user name ...... ...
This example is not written in accordance with the standard template provided by RUP. Its purpose is to be displayed for everyone, and the test demand and design completed test cases are like a test case. So many details, but everyone can add the corresponding content to the corresponding content according to their own needs when actually writing test case documents. At the same time, you can also fill in the specific data prepaid use in the username and password two fields.
I believe that everyone has already seen that in our example, the test demand is not a one-or-one relationship between the test case. Because a test demand is not necessarily a clear corresponding to a valid function (in fact test demand itself with software requirements and use case It is not necessarily one or one. And our test case is concerned, it should be a valid function. However, you don't have to worry, this situation does not increase your management of test requirements and test cases, and now there are some test tools that are specifically used to maintain software requirements and test demand. And the powerful view features they provide allow you to easily view the coverage of the test case to test requirements. For the test case document in the example, it has been divided into two portions, part of which describes the operation procedure that the test case executor should follow, and a part is the test data that needs to be used in the operation. The reason is that in our practical work, especially when performing functional tests, many times are carried out using the same operation process and different test data. The above method can be used again without repeated operational processes that have been repeated in multiple use cases, and more energy can be placed on the design and preparation of test data. The by-products brought by this are to improve the maintenanceability of test cases.
how? Anyone who is skeptical about the author's point of view? Ok, then let's try to prove.
Our postman wants to rush in five cities, and some emails in each city need to be delivered, he needs to find all the routes that can be taken over 5 cities. This seems not too complicated, using our existing mathematical knowledge, it is easy to get the answer. But for what we want to test, usually contain more complex rules.
For example, we have three text boxes, each text box can only enter an English uppercase letter each time, allowing the input values only including: a, b, c, and when the three text boxes enter different values We don't know what will happen, and we don't know if they will affect each other, so you need to design a test case that can override all input conditions to test it.
Hey, is this very simple? If we want each test case, once the defects can be found in the execution, it can quickly find the cause of defects, then the best way is that each test case only includes different input values with other test examples. So what are the values we entered? Well, for each text box, there are at least A, B, C have declared different values. In addition, we have to consider that when the text box is empty, enter space, enter non-English characters, and input A, B, The case of an English character other than C. So how many test cases do we have in accordance with the above method? The answer is 343. This is just a very simple example. The business rules and features of the software encountered in our work will never be less than this, how many test cases will there be? GOD KNOWS. At least one thing can be sure, we cannot efficiently, there is no error in maintaining 343 test cases when the original business rules change.
However, if you use the methods described above, you only need to re-maintain once, and the maintenance of the test data is also very simple, and does not cause errors that appear during continuous modification The test case itself appears mating.
After transferring the main energy from the Design operation step to the design test data, we will also achieve greater benefits from this method - to improve the overall efficiency of the test work through "reverse test data analysis".
This method of "reverse test data analysis" is to assume that there are multiple mutual dependent functions in the software, and these functions are included in the "dependent chain", and no longer be dependent on other functions.
When we prepare for test data, first start from this "dependent chain" to the end of this "dependency chain", which is analyzed for different inputs to different inputs. Then all inputs are finished, which inputs are output from the previous function output. Thereafter, the same analysis of the function is made, and the all input and output are sorted, but the output of this function should at least contain all the inputs received by the "dependent chain". Continue to circulate in this way until the functionality of the "dependent chain" start end is reached.
I don't know if you have this situation in your work: When testing the functions on the "dependent chain", there is no strict specification test data in the beginning, and the data generated when the previous function test is fundamentally. It is impossible to use well in the following work, but because a large amount of invalid data increases the difficulty of the back function. Eventually to re-prepare test data for each feature. A lot of time, wasted in these repetition and inefficient labor.
Of course, if it is desired to further improve the efficiency of a certain phase test, it is also possible to consider the application of "design testing process". The test process here refers to the order of the execution test cases we set when we perform testing. The reason why this is because the coupling between different functions can be sufficiently utilized, try to check as much as possible, thereby reducing the invalidity or inefficiency of the completed work, and ultimately increases the overall stage Work efficiency. However, this work also requires the operator to be very familiar with all the services involved in the measured system and the relationship between these services.
If you are being bothered by the inefficient problem being tested, it is recommended that you try the above way and hope to help your work.
How to evaluate the test case?
The appearance of this part is entirely because of a discussion of the same as a few friends. At that time, everyone considered the evaluation of a test case, no more than two standards: Can I find software defects that have not been discovered? Can you overwrite all test needs? But later found that these two standards have not been processed for some issues. For example, for a very good software product, the existing software defect is very small, the test case designer prepares a lot of test cases, which has completely covered the test needs, but only some of the test cases are found when executed. Defects, and other use cases have passed smoothly. So do you think that the part of the test case is not good?
For this problem, the author believes whether the test case can find the deficiencies that have not been discovered or the inspection of test needs is used to assess the work capability and experience of test designers, and how to evaluate test cases Surious, there should be other standards. Of course, there may be different standards in different teams, but the following should be suitable for any team.
Easy to use. For one, the test personnel who are familiar with the test, but familiar with the test personnel, should cost
Little time can understand the test ideas expressing in test cases and can perform this test case.
2. Easy maintenance. When certain factors in the development process affect test requirements, authors or other tests of test cases
The county should take a small time to complete the position and maintain the work of all related test cases.
Some questions
I have a friend asked: If the test case is independent, how to ensure the operability of test cases? How to ensure that anyone can take a test case, can you perform a test directly? The author's answer is: try not to let this happen.
First, the author has never approved that let "anyone" can act as a testers, and perform testing in accordance with the test case in hand. Because the comprehensive understanding and familiarity of the test application is the most basic requirement of a tester - familiarity with software requirements in the previous text, it is also emphasized. We cannot predict that a person who is not familiar with the actual business involved in the software and the software, relying on a list of operational steps he is also unfamiliar to perform a test. But there is a little clear, this is like a person without a medical background, just relying on a "intangible" teaching material for the seven-year-old school to check whether the patient has heart disease, the end result is that the patient is borne All risks. Second, the original purpose of the test case is to describe our "test ideas" - "how to test", and whether it can be skilled in the test application, not in the test case, "object" to consider and guarantee It should be stripped as a separate portion. The key to the problem is how to ensure that people get the test cases have sufficient ability and experience to perform tests, which can be used through the company's training, or software operation manuals for software and software. In short, try not to join "anyone" to the test work at will.
About the Author
Network ID: Jackei, long-term active in "Test Age", "China Software Test Community", "51testing", "51CMM", "9CBS" test website and test forum. Editing and contributors of "Test Age Journal" magazine.
The college test personnel, firmly believe that "practice is the only standard for inspection truth". Against academic corruption, fake. I firmly believe in a good tester, first of all, I have to be straightforward, honest, rigorous, patient, and helpful. It is now a software company, engaged in software testing, and is committed to the improvement of testing process improvement and test basic theory.
For content already included in this article, you can contact your author if you need to discuss, you can contact the author using E-mail: jackei_chan@hotmail.com.
