Thinking [test thinking] to enhance the efficiency of the test tool development

  Aiming to enhance the efficiency of the test unit test tool development, management, maintenance problems exposed some thinking and some improved personal point of view.

EDITORIAL

  Enhance the efficiency of testing tools mentioned in this article does not refer to the department inherent in automated testing tools, testing tools mentioned here refers to a unified testers in his spare time test developed for the desired alternative repetition, tedious, time-consuming manual operations the purpose tools, development is to enhance testing efficiency. Not a testing tool for professional tool development department team.

Testing tools for managing the problems exposed

  In general, the overall quality of internal testing release of test tools for efficiency improvement is not high, the tool features, performance, ease of use, maintainability, quality is not high. Most who develop test tools are usually who used relatively smoothly, tool promotion is not high. Does not really let other testers sector efficiency has been improved. To solve these problems a little simple research coworkers reasons, mainly the following questions.

  1, the tool does not know that you can get from where. This is a test unit issues a management tool. There is no uniform delivery route, the testers do not know what are the current test unit test tools can be used, we do not know where to get to .

  2, the tool will not be used. Testers do not know how to get the tool to use. For some relatively complex functional testing tool does not use instructions, no online help. There are even some tools to develop menus, labels, from the name of the tool is very vague. I do not know why this tool is to the. These are usually usability issues testers do not consider tool in the development of tools lead to other testers difficult to get started. For example, testing tools developers use Python developed a windows platform tools but not compiled into an executable .exe program release, difficult for others to use, you may want to first download the python program, to download the other program depends on a variety of library. Tools such trouble with a lot of people do not want to use. .

  3, the tool does not work well, are prone to problems. Test tool development may only be directed to a specific scene on a specific version of the service does not have the tools to develop lead in implementing promotional tool. In addition, a number of tools to interact too much even when using some dependent on external conditions need to set the program to function properly execute and so on all contribute to good use, no reason people use.

  4, the tool is difficult to maintain (maintainability issues). Tool developers of varying skill, ability level there are differences of degree of compliance with coding standards are not the same. Implementation tools developed linguistic diversity, mainstream development language Python, Java, etc. Fortunately, if the latter is the tool AutoIt, vbs, etc. These relatively less developed language maintenance is very troublesome and even no one maintained. In addition, testers, after all, did not have a good understanding of coding standards, how to write code there, thousands of lines of code comments almost zero, there is no development documentation, particularly difficult to maintain them.

  5, the tool needs to develop freely, publish path is not unified, non-standard tool for publishing format. It is also management issues. There is no unified management tool will be derived from many additional problems. For example, the previously mentioned do not know where to obtain the tool, the tool is no guide book, I have no coding ability but I recognize the need to work in the short board development tools can submit demands to whom. . and many more. . Here, not necessarily to force some of the tools can not be developed, certain tools can be developed. From the overall perspective of the test section, the effort will focus tool to test the efficiency of the Ministry of topN short board to enhance the development is certainly necessary. .

Development of improved tools a few comments

  Exposure to the above questions I spent many products have encountered, not a case. For solving these problems, talk about personal views.

  1, unified management tool. Internal testing tool development norms issued by the Ministry, unified publishing tool path, tool distribution format (tool name + version number, the main function of the tool, the tool of tool maintenance history, tools development IDE, etc.). It recommended the development of mainstream programming languages ​​(Python, Java, etc.), internal emphasis on programming norms.

 2, to develop tools to improve ease of use. First, reduce interaction but convenient interaction. Mainly refers to reduce interaction is not necessary to input the input will be cured or integrated into the software, relies on steps may also be implemented directly in the tool. Facilitate interaction mainly refers to try to provide an interface in the form of windows system using an interactive window. Customary procedures used on the windows of the train is so. For the next linux, command line interaction without problems, but every step of the input prompts described as simple and clear. Try to use up to fool. When the implementation will be considered from this perspective. You do not expect you give people tools need to teach him how to use it. .

 3, increase tool availability. This is a function of the problem. Usually these are personal productivity tools implemented in his spare time to spend time, it requires everything is very difficult, but still try to ensure that the main scene in most cases to run properly, you can output normal expected results. Can not change a test version of the tool on the problem just fine, others may not want to use. For the perfect tool to optimize the next iteration of the can. This is a problem every tool developers should all think about. . You do not expect their release of a tool with others on the problem. . Not good for their image. . right

 4, improve maintainability tool. Do not ask, is add some comments, feel readability of code can be. Function / class division as far as possible and reasonable. At least for six months a year to ensure that their back to see your code can quickly modify to read on the same subject. .

 5, regularly propaganda tool. Regular pick up some useful tools to promote a certain universality. Wine is also deeply afraid of the alley, the development of each tool also want their labor can really let other people benefit, so that their pay be recognized by others.

  6, coding skills exchange. Testers overall coding skills still relatively weak, development tools, mainly concentrated in a small number of people who. This part may be unified together and more personnel exchanges, discuss. Can push some coding basic training course or some basic articles that can help enhance internal testing are interested testers coding capabilities.

summary

   Management and maintenance tool development using exposed a lot of problems, actually doing anything. After all, testers are developed in their spare time. Made out better than not do it well, do things out just a little guidance can continue iterative optimization improvements. It is not desirable to improve awareness, tolerate inefficiency, duplication, tedious manual work to perform, so no good for himself. .

   限于时间,匆匆写完,有些观点可能表达不到位,针对这些问题,有兴趣可以交流。。

Guess you like

Origin www.cnblogs.com/linyfeng/p/11610780.html