My ideal functional testing tool should meet the following basic conditions:
- Simple. Testing is complicated enough. The tester should have focused on identifying system errors. It is not worth the candle to let the testers make great efforts in the test program. The key to simplicity lies in the same operation with browser users. The program code should completely block user-independent details. For example, if there is a button called "Submit" on the webpage, the statement for clicking this button should be no more complicated than getbutton ("Submit"). Click. In short, the programming model of automated tools allows a tester to write the corresponding code while looking at the user's operations. The popular term "automatic testing" should be the domain specific language corresponding to the user's concept model (Conceptual Model ). The more serious consequence is that the tester should not write low-level test code to catch up with the progress and cannot discover system errors.
- Flexible. There is no end to demand. We absolutely need an automation tool that can be scaled at any time to support complex programming. Maybe today we only need to search for a simple string on the web page, so the string function provided by the tool is enough to use, but tomorrow we may have to traverse all the elements on the web page, so we need a powerful HTML Parser. Never tell me that this tool does not support HTML parsing. Unfortunately, many tens of thousands of tools do not support arbitrary HTML parsing. In my opinion, this is no longer a developer's design fault, but also a provocation against the testing personnel level.
- Stable. Originally, the purpose of the test was to discover system errors. As a result, the test staff found a large number of tool problems due to unstable tools, and finally had to spend a lot of time to eliminate system-independent errors. As a result, the friction between developers and testers increases, testers are exhausted, and the tools that make a big investment are shelved. The project is time-consuming and laborious...
- Powerful, with a large number of libraries for use. Although we can develop our own libraries, it is best not to do this time-consuming and laborious work. After all, the core part of the test is not the development of your own database. Not to mention future maintenance costs.
As for automatic record operations and graphical support, all of them are icing on the cake. If the basic requirements are not met, do not. Unfortunately, most commercial tools treat testers AS dummies and focus too much on corner functions such as automatic recording and graphical operations. I used the following tools to automate functional testing of Web applications. None of them satisfied me:
- Mercury InteractiveQuicktest professional. I use V3 and V4. This tool fully supports graphic automatic recording test operations, and supports VBScript programming and custom recording test operations. Known as having a powerful Test Library and graphical custom tools. Unfortunately, this tool has brought endless troubles to our team. The generated code contains a large number of underlying details and is not suitable for modification and maintenance. The code file it generates is bound to its object repository (Object repository is used to store all the objects generated in the automatic record for later playback and comparison of playback results. If you are not careful, the binding may be damaged, resulting in invalid generated files. I understand that mercury's original intention is to use Object repository to simplify automated operations. Unfortunately, this method is completely ineffective. We also found that the playback of quick test professional is often different from the recorded ones, leading to false test failures. In addition, compared with the object repository, the test playback is sensitive to the GUI. Testing fails even if a button is changed. The problem is that in the function test, we really don't care whether a button is in the upper left or lower right corner. All in all, quick test professional does not meet the requirements of 1, 2, and 3, directly reducing this installation space up to GB of software to a tool suitable for small GUI testing.
- SegueSilkperformer. We have used V5 and v6.5. This is a very good performance testing tool. Powerful functions and stable performance. I am proud to have contributed to the performance testing and System Testing of our department. Unfortunately, this tool is not suitable for large-scale and complex web function testing, although it supports functional testing. To use this tool, we have built a huge test database based on it, costing n people years, but it still cannot satisfy many testers. First, the automatic record of silkperformer still exposes a large number of details. For example, we must know whether a button is a simple link or a piece of JavaScript. Secondly, silkperformer uses a strange language called benchmarking Definition Language. This language is a mixture of standard Pascal and C. It integrates the rigidity of standard Pascal and gives up C's flexibility. This language is so flexible that it also provides interfaces for com and JVM to support function expansion. BTW, support for JVM is surprisingly clumsy, such as only static methods, such as only one class... Finally, the BDL of silkperfomer has many restrictions on programming. For example, it does not support full HTML parsing (6.5 is supported at the beginning, but a quite limited configuration method is used ), nor does it support dynamic data structures (do not tell the fixed-length array to be a dynamic data structure, let alone the arrays of different lengths are actually different data types ). By the way, I mentioned that support for BDL regular expressions is a joke? Therefore, silkymmer cannot meet the basic conditions 1, 2, and 4.
- RationalXde tester and robot. The two software also uses Object repository, so it naturally inherits various disadvantages of Object repository. Although rational uses some clever algorithms to make the object repostory flexible and stable, I still have to worry about using the Java framework programming provided by it.
- Httpunit. This is a free open-source function testing framework, close to my ideal. It is basically a browser controlled by code (this should be done with a good functional testing tool), and the operations on the Web page are simple and convenient. Unfortunately, the current version of httpunit only supports limited JavaScript, and has limited support for IE, because it uses Mozilla's HTML kernel and JavaScript Engine. In short, basic condition 4 is not met.
- SAmie,The starting point of Samie is quite good: Use programs to control ie automation. That is to say, Samie uses Perl to simulate the running of a browser. The simulated method is to call the automation interface of IE. The biggest benefit of doing this is that it is relatively easy to meet basic condition 1. Perl and IE can easily meet the following three basic conditions. However, Samie is still under development and a large number of features need to be added. However, this is quite promising software. This is also the basic condition 4 is not met.
Browse todayMagazines, See an article to reduceWatr. Watr is a Web Testing Tool written in ruby. This tool seems good. This tool also calls the interface of IE automation. We can debug the test code on Eclipse, because eclipse integrates Ruby support. It seems to be the beginningTieqishuIt's time. By the way,The first version of this book is free online.
