Test tool in the eyes of a practical Tester

Test tool in the eyes of a practical Tester

 

Chen nengtech

2007-9-5

 

Excellent testers are developed and need internal skill, external skill and weapon. The cultivation of internal strength, that is, the study of testing theory, has been mentioned in the test theory in the eyes of the practical tester. Here, let's take a look at the 18 weapons. How can our testers make good of them?

 

Dialectical attitude towards testing tools

Testing tools are essential for testers, but they cannot be infatuated with tools.

 

It is necessary because many tests cannot be completed without tools. Pragmatic testers do not waste time entering data in a single piece of data to create 1 million data tables.

 

There will be such testers who are eager to use the tool and think that if you don't use the tool, it seems to be stuck in manual testing, and they feel that they are in a very low stage of testing. They tried to find and try out various new versions of testing tools, so that they could keep up with the test trend.

 

I have been interviewing and reading the resumes of many test applicants. They often like to indicate on their resumes what tools they are familiar with or even proficient in. During the interview, they will also desperately want me to know that they know some tools, for fear that they will not compete with others because they didn't mention this. Let's take a look at the training market, where there is training on testing tools, and people have to think that if testers lose these weapons, they will lag behind the times.

 

True pragmatic testers do not. Their attitude towards testing tools is to ask for and trust them on demand.

 

Large tools

Pragmatic testers also have common weapons, such as performance testing tools and GUI regression testing tools. These tools are generally provided by the dedicated "swordsman" (test tool manufacturer. We need to first "Product swords", then "Practice swords", then "use swords" and "discuss swords ".

 

"Pinjian": it is best to get a trial version of a tool before you actually use it. You have to try it for a while and use it with your own project, do not try it out based on the examples and test programs attached to the tool, because the examples are always available and can pass the test. For example, some tools do not support the new version of the. NET Framework. If your project is developed under the new version of the Framework, it cannot be used even if you buy it.

 

"Jian Jian": before using the tools in the project, we should train the members of the project team. The training should not only be the tool itself, but also the testing theoretical knowledge involved in the tools should be trained in place, for example, for the training of GUI automated testing tools, the Operation Training of real tools may not take several days to complete, but the concept of automated testing is as follows, how to organize automated testing and so on requires more time for training. Otherwise, the "swordsman" may only wave a sword for a performance.

 

"Use a sword": when using a tool, you must pay attention to "do it right away when you do not do it" and make full use of the advantages of the tool, for example, the advantage of GUI testing tools is to quickly overwrite functions, which are mainly used for simple functional checks, such as data comparison and interface property comparison, it should not be used in areas where usability testing and usability testing are not good.

 

"Jian Jian": when using tools in the project, you must also accumulate experience and share your experiences. Some problems encountered during use and solutions should be recorded, in order to be more comfortable in the next use.

 

For pragmatic testers, I do not recommend buying many of these big tools, because pragmatic testers focus on the efficiency of input and output, the "sword" in their hands, especially the "sword" they bought ", to realize its value, we will not bury the sword ". In addition, I do not know if the Hero "has no sword in his hands to win the Sword "? Some gadgets and mini-programs seem useless. It becomes a weapon to win the enemy by the confidence of pragmatic testers!

 

Gadgets

There are countless such gadgets, such as some screen recording tools and resource monitoring tools. These gadgets can even make you super powerful (see arm your test).

 

These gadgets are roughly divided into three categories:

1. Free or shared small software on the Internet

This type of software is designed specifically to solve some problems, such as installwatch, which allows you to know that the files and registry content have changed between the two time points, it is particularly useful during installation and testing.

 

2. built-in operating system or development tool

There are more gadgets of this type. Many of them are under our eyes. The key is whether you want to use them, just like martial arts's master in key moments. For example, perfmon is a system resource monitoring and recording tool provided by the Windows operating system and can be used in performance testing. Windows Task Manager is a program that must be opened during my testing. It helps me discover many problems of software process resident and Memory leakage.

In addition, some development tools also include gadgets that can help you test. For example, Microsoft's development tool will include a tiny tool called Spy ++, which can help you track form events, identifies the control type and name.

Also, I often use the event profiler in SQL Server, because I can use it to know what SQL statements the tested software has submitted to the database, what kind of data operations are performed.

 

3. Script Language

Perl, VBScript, and JScript. For example, the daily build framework of our project is written in JScript, which is very simple and practical and easy to modify, maintain, and expand. Regular Expressions in these scripting languages can also be used for File Analysis and result search.

 

"Sword casting" by yourself"

The project environment is diverse. The tool vendor's testing tool is more comprehensive in terms of supporting many languages, environments, and considerations, but there is always something that is not considered or not supported. At this time, you should come forward and write a small program or a small tool that suits the actual situation of your project.

 

For example, we encounter an environment not supported by LoadRunner, so we cannot use such a good tool, at this time, we can only write a synchronization and coordination program to call multiple processes on different machines to solve the problem.