Classification and selection of test tools
In general, we divide test tools into white box test tools, black box test tools, performance test tools, and test management tools.
a) White box test tool
The white box test tool is generally tested for the code. The defects found in the test can be positioned to the code level. According to the principle of test tool, it can be divided into static test tools and dynamic test tools.
i. Static test tool
The static test tool is directly analyzed by the code. It does not require running code, nor does it require the code compilation link to generate an executable. The static test tool is generally scanning the code to find out where the coding specification is found, and the quality of the code is evaluated according to the quality of the code.
The representative of the static test tool has the Logiscope software of Telelogic, PRQA software in PR.
Ii. Dynamic Test Tool
Different dynamic test tools are different from the static test tool, and the dynamic test tool generally adopts the "inserted" manner, insert some monitoring code to the code generated, the data is used to statistically run data. Its largest difference from static test tools is that the dynamic test tool requires the actual operation of the system.
The representative of the dynamic test tool has a DEVPartner software of Compuware, Rational's Purify series.
b) Black box test tool
Black box test tools apply to black box testing, black box testing tools include functional test tools and performance test tools. The general principle of the black box test tool is to use scripts to record / playback, analog user operation, and then compare the output of the measured system to the predetermined standard results. Black box test tools can greatly reduce the workload of black box testing, which can be tested well during iterative development.
The representative of the black box test tool has Rational's TeamTest, Robot, Compuware's Qacenter, and dedicated to performance testing tools include Radview's WebLoad, Microsoft WebStress.
c) Test Management Tools
Test management tools are used to manage tests. In general, test management tools are managed on test plans, test cases, test implementations, and test management tools also include tracking management of defects.
The representative of the test management tool has the Test Manager, CompureWare, TRACKRECORD, etc. of Rational.
d) Other Test Tools
In addition to the above test tools, there are some special test tools, for example, TestBytes for database testing, ECOSCOPE, which optimizes applicability.
e) selection of test tools
In the face of so many test tools, the choice of tools has become a more important issue. We are advised to weigh and choose from the following aspects when considering choosing tools.
i. function
The function is of course our most concerned, selecting a test tool first is to see the features it provides. Of course, this is not to say that the more functions provided by the test tool will be about, and the applicable is fundamentally in the actual choice. "Money is spent on the blade", which is not a wise behavior for the need for a function of not need. In fact, the basic functions between the currently similar software test tools in the market are different, and the functions provided by various software are also roughly the same, but there are different side focus. For example, it is the Logiscope and PRQA software that are white box test tools, which they provide roughly the same, just in coding rules, coding rules customization, and different code quality standards.
In addition to basic functions, the following functional requirements can also be used as a reference for selecting test tools:
1) Report function; the results of the test tool generation must ultimately explain by people, and those who view the final report is not necessarily familiar with testing, so the test tool can generate the results report, which can provide reports to provide reports the elements of. 2) The integration ability of the test tool; the introduction of the test tool is a long-term process, which should be a continuous process with the test process improvement. Therefore, the integration of test tools is also a factor that must be considered. Here, integration includes two aspects, first, the test tool can be well integrated with development tools; secondly, test tools can be well integrated with other test tools. .
3) Compatibility of operating systems and development tools; if the test tool can cross the platform, whether it is applicable to the company's current development tool, which is also a problem that must be considered when choosing a test tool.
Ii. price
In addition to the function, the price should be the most important factor. Speaking of the question, I often see someone in the forum, say that I have already cracked the XX test tool, I am very disapprove of this attitude. If we can't respect the labor of others as a software from the industry, how can we expect our customers to respect our labor? Moreover, the price of the test tool is not really expensive to unbearable extent, such as Numega's DevPartner a fixed license is more than 20,000 yuan, which is fully affected by a medium company.
Iii. The purpose of testing tools is to test automation, introducing tools to consider continuity and consistency of tools introduced.
Test tools are one of the important steps of testing automation. When introducing / selecting test tools, we must consider the continuity introduced by the test tool. That is, the selection of the test tool must have a full consideration, phased, and gradually introduced test tools.
3, the application of test tools during testing
The previous selection of test tools, the selection of test tools has been described. Here, I also want to say something to their own on the testing process.
The role of the test tool can have already understood and approved, but many companies introduced to test software have not allowed test software to play, and the main reasons have been summarized as three aspects:
a) did not take into account the company's actual situation, blind introduction test tools
First of all, we must clearly, not every test tool is suitable for the current actual situation of the company. I have seen some companies introduce test tools with a beautiful wish, and after half a year, the test tool has become a furnish, which has become the pain of the introduction. The reason is that there is no considering the company's reality, and the test tool can be used to change the company's status quo, resulting in failure.
For example, if the software developed by a company is the software of engineering, the demand and user interface changes in the entire development process, which is not suitable for introducing black box test software because the basic principle of black box test software is Recording / playback, for non-changing demands and interfaces, the workload that may modify and record scripts is also over test, which can not only reduce the workload, but increase the burden of testers.
Our company introduced the test tool (at least from the current point of view), there is a need for our company's application project, and the interface changes are more frequent. We have not introduced black box test tools, mainly relying on white box test tools. Code quality. At present, we introduced test tools include Compuware's DevPartner and Telelogic's Logiscope, which played a role in testing phases and maintenance phases.
b) There is no environment for a good use test tool.
In other words, it is not possible to form a mechanism to make the test tool truly function. For example, the general use of white box test tools is in unit testing phases, and unit test is completed by the developer. If there is no process to standardize the behavior of the developer, the developer is likely to It will consciously do not use test tools to escape the problem. In this case, it is necessary to form a binding mechanism to force the use of the test tool. Use the use of the test tool to clearly define the development process of the company, I think it is a better way. Our current approach is to clearly explain in the development process. In the document submitted in the project milestone, the report must include reports generated by the test tool. The data in the report is the basis for determining whether the project is qualified. According to the actual situation of our company, the test coverage report generated by the DEVPARTNER tool is submitted to the integrated test, and the code quality report generated by the logiscope, and the code coverage of the unit test must reach more than 80%, the code quality evaluation must be in Fair. the above.
c) Training without effective test tools
The user of the test tool must know very well on the test tool, in this regard, effective training is essential. The training of test tools is a long-term process, not to achieve good results through one or two lectures. Moreover, in the process of actual use testing tools, the user of the test tool may still have such problems, which also requires a special person responsible for solving, otherwise, the enthusiasm of the test tool users is a big blow.
When the training of test tools, our company has conducted a series of training and communication, from the "test tools for testing tools" to the high-level "test tools" to use training for test tools for test tools, and then to AC properties "Test Tool Application Exchange Seminar", then "test tool application question and answer" issued regularly, in this regard, the current test tool application has become the basic skills of developers and testers
