Shulou(Shulou.com)06/01 Report--

How to carry on the test management design of DevOps platform, in view of this problem, this article introduces the corresponding analysis and answer in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

Foreword:

IBM has pointed out that test management helps DevOps facilitate continuous integration and delivery by leveraging data. This article mainly describes how Puyuan DevOps6.0 designs a test management to help users get their high-quality products, and how Puyuan DevOps6.0 test management helps products to be delivered faster.

Table of contents:

1. The help of test management to products

two。 What is test management?

3. Design of Test Management

1. The help of test management to products

As the old saying goes, if you want to do good work, you must first sharpen its tools. For the development team, there is a lot of work to be done, and test management can not only enable products to achieve these effects, but also enable them to surpass themselves and achieve the best. IBM has pointed out that test management helps products facilitate delivery by leveraging data. Test cases and test data can be easily associated and analyzed. These insights are essential to help the development team improve and continue to meet the needs of users.

"functional testing can confirm the behavior of applications, and test data management enables research and development institutions to evaluate changes in the success of test data," IBM said. By comparing the previous and later test data, no matter whether the test passes or not, it will help to analyze the test data results. This approach well deals with many hidden problems, so that the problems of the product can be identified and solved quickly.

Generally speaking, testing has reached the final stage of the software development life cycle, and there is very limited room for enterprises to make major changes while ensuring that everything works properly. Datical pointed out that traditional software development methods usually find defects in the second half of the development cycle, which usually forces organizations to pay a high price to solve these problems and eventually slow down the whole development process. Test management will be the driver of product quality and ensure that products meet the quality standards set by stakeholders and users.

"QA is actually considered to be a very critical component of DevOps, and even DevOps emphasizes that quality assurance is everyone's responsibility," Datical said. But this does not mean that QA professionals no longer have a role to play in the DevOps environment, but rather that, along with everyone else in the organization, QA can and should play a more strategic role and provide comprehensive oversight of quality assurance functions, as well as a stronger and stable testing infrastructure.

As expected, test management enables development and test teams to better collaborate for faster delivery and agile support, and on the other hand, these benefits essentially lead to improved quality across projects.

two。 What is test management?

It was an ordinary afternoon, I was carrying the code as usual, the boss suddenly came and told me that there was such a need, I had no relevant concept at that time, and the boss saw the big confusion in my small eyes. In order to solve my doubts, the product manager held several discussions and explained to me various usage scenarios. I finally understood what to do, which turned out to be test management.

So why does DevOps do test management?

Baidu encyclopedia for the introduction of test management: test management as a system, the composition of the system to identify and manage each process, in order to achieve the set system goals. At the same time, it is necessary to make these processes cooperate and promote each other, so that their overall effect is greater than the sum of the processes. Its main purpose is to find and eliminate product defects as much as possible under the set conditions.

The research results of the American Institute of quality Assurance on software testing show that the earlier the problems in the software are found, the lower the development cost; the cost of modifying software defects after coding is 10 times higher than that before coding; the cost of modifying software defects after product delivery is 10 times higher than that before delivery; the higher the software quality, the lower the maintenance cost after software release.

When you see here, you shouldn't ask why you did it, but you should ask why you don't do it because of the ability of Monkey Sailei.

But the headache comes, how to design to achieve the effect?

3. Design of Test Management

We can split the requirements into three parts: test cases, test plans, and test reports.

1. Test cases

Parse the process and purpose of the requirements, define the results to be achieved, and describe the operation process and expected results, which will be output as test cases. So how to uniformly manage test cases? DevOps's use case base uniformly manages the test cases. It is certainly not enough to do this. We need to classify test cases in more detail. Here, grouping is used to classify test cases of the same type or the same function. Of course, nesting is not prohibited here. Tree grouping can classify test cases as you want.

So does the use case library only operate or manage test cases? Or can you just add, delete, change and check to meet the needs of users? Of course, it is not enough, the user can view the relevant data in the use case library, and the test case will be associated with the execution results of the use case in different test plans, and the results of multiple execution can be analyzed and summarized. In order to trace the defects caused by the execution of the use case, the test cases are also associated with the defects caused by the use case in different test plans, and the status of the associated defects can be paid attention to at any time.

There is another usage scenario to take into account that if a user wants to delete a test case with an existing execution result, this action does not affect the completed and archived test plan that introduced the use case. We can mark the test case as abandoned. Similarly, the use case is also marked into the unexecuted and executed test plans of the use case, allowing testers to decide whether or not to remove the use case according to their specific needs.

2. Test plan

Determine the plans and goals for each test phase, identify the test activities to be completed, assess the time required to complete the activities, schedule and allocate the activities, this process will be output to the test plan.

What are the plans and goals for each test phase? Take a chestnut, such as verifying basic functions, the goal is to make sure that the basic features of the product are available. Identify the test activity to be completed, and then the chestnut thrown above, to verify that the test case to be performed for the basic function is the activity to be completed. The purpose of evaluating time is to control the progress of the execution of the test plan, which can help testers to make better use of and allocate time. Activity scheduling and allocation can provide more detailed management of the execution of the test plan. If it is a plan with a large number of test cases and time constraints, it is impossible to let a test partner do the execution of the entire test plan, so it is necessary to assign tasks according to the time of the test partners.

Lu Xun once said, "A test plan without test cases is not a good test plan."

When creating a test plan, the user selects the desired test case import, and in order to facilitate management and viewing, the test case import will also bring the grouping information of the use case in the use case library. It is important to note that the information to modify the use case in the plan should not affect the test case in the use case base. A good test plan should not only have use cases, but users will also care about the proportion of these use cases in the use case base, that is, the coverage of the use case base. Of course, in addition to this, we must also pay attention to the execution process of the test plan, how many successful execution, how many failed, and how many related tasks have not been solved. These are all issues that users are more concerned about. We need to count these data.

When the test plan starts to execute, it will enter the test execution page, and the tester will execute the test according to the step description of the test case, compare the test result with the expected result described, and record the result of the comparison. If the test function produces bug, the defect task item will be generated directly on the test execution page. If there is the same existing bug task item, the tester can change the status of the corresponding task item.

It is also necessary to control the completion status of the test. If the plan is not fully executed, or if there are unexecuted test cases, the user should change the status of the plan and remind the user. Because the status of the plan "not executed-> executing-> completed-> archived" is irreversible. When the test is executed, the project administrator needs to view the defects generated by the test plan, then we need to view the defect items associated with the test plan. Testers can verify and execute the test cases associated with the resolved defect items, determine whether the defect has been resolved according to the execution results, close the task item and reopen it without resolution.

3. Test report

Run the program according to the test case, compare and analyze the running results with the expected results, record the current test results, record, track and manage product defects, and finally get the test report.

According to the data concerned by users, the design of test report should include test execution report, test result report and associated defect report.

The test execution report should reflect the execution process of the test plan from many aspects. in order to reflect the overall progress of the plan, we need to look at it from three angles: from the perspective of time, the number of days the plan has been executed is compared with the time evaluated; from the point of view of the results, it depends on the number of test cases executed and the number of failures in the plan; from the perspective of associated defects, whether there are any unresolved defects.

The test result report shows the test case execution result data in the unit of plan. Considering that the user will have the need to view the summary data, the design time should provide the summary of test case execution result data in multiple plans.

The data that testers are more concerned about is whether the submitted defects have been changed, and how many defects need to be verified, and the defect report will count these data. The testing partners submit associated defects during the testing process, and the defect report will show the status of the submitted defects in an intuitive bar chart to help the testing partners understand their related workload.

That's it, of course, there are still some deficiencies, such as the lack of examination and approval links, the test report is not comprehensive enough, is the relevance of each module enough? The solution to these problems will be launched in a later version, and what ideas you have can be discussed in the comments section!

Finally, refute the rumor!

"I didn't say that, it was his nonsense."-Lu Xun

This is the answer to the question on how to carry out the test management design of the DevOps platform. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel to learn more about it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.