The tangle of software test automation

When people talk about software testing automation, they first think of testing tools, including functional testing tools, performance testing tools, etc. The test tool can perform a variety of different, specific tests, it depends on the test script. Testers implement specific operations and verifications to be performed by test cases by developing test scripts. Once a test tool is selected, the development of test scripts becomes one of the daily work of testers and the most important work of test automation. In other words, the development and maintenance of test scripts are directly related to the success or failure of software test automation, at least it has a huge impact on the input and output of automated testing.

      Test scripts have evolved from recording scripts to structured scripts, data-driven scripts, and keyword-driven scripts. From the historical development process, data-driven scripts and keyword-driven scripts are of great help in improving the development efficiency of automated test scripts, and are also conducive to the maintenance of scripts. The following table can fully illustrate the impact of different types of test scripts on automation benefits.

 

 

Types of automated test scripts

cost

income

net income

record and playback

8.3

11

2.7

data-driven scripting

8.4

18

9.6

Keyword Driven Scripting (Automated Testing Framework)

9.8

15

5.2

Keyword-Driven/Data-Driven Hybrid Structure

11.6

19

7.4

 

Here is an example of a simple keyword-driven script:

Order

object

value

open

/change_address_form.html

 

type

address_field

Betelgeuse state prison

clickAndWait

//input[@name='Submit']

 

verifyTextPresent

Address change successful<

 

 

       It can be seen from this that such business logic is very clear and easy to operate. Moreover, with the birth of keyword-driven scripts, various automated test frameworks have emerged one after another, forming a good script development environment or platform, making the development of automated test scripts more open, visible and hierarchical. Both developing and maintaining scripts become easier and easier, further increasing the efficiency and scope of automated testing overall.

 

       Of course, nothing is perfect and there is another problem. Once the automated testing framework and its tools are completed, the script development work of testers is simple, lacks technical content, and may lack opportunities for programming exercise, which brings a new tangled problem in the implementation of automated testing - the use of keywords Drive the script development mode or use the original scripting language (such as Python, VBScript, or even C++/C#, Java, etc.) development mode? This mainly refers to the automation of Frontend functional testing, involving UI. If it is automated testing of backend or API, it is relatively easy.

       If the development model of keyword-driven script is adopted, personal ability will not be improved. And it felt like there was little value in leaving the company's original script development experience. However, if the original scripting language is used, personal programming ability can be exercised, and these abilities are generally needed in the industry, so the value of the individual can be improved. From this career development perspective, testers are more willing to use native scripting languages ​​rather than keyword-driven scripts, especially for those employees who regard it as personal development, there will be a trade-off consideration.

       From the perspective of the company, more consideration should be given to the input and output of automated testing. There is no doubt that keyword-driven scripts should be selected to ensure the efficiency of automated testing. If the original scripting language is used, the development workload of automated testing will increase, requiring testers and developers to be equipped with a 1:1 ratio, and script maintenance for automated testing will also be a big problem in the future. If you choose a high-level language like C++/C# to write an automated test script, the script becomes complicated, which will bring about the problem of testing/verification of the script itself, forming an endless "recursive loop".

       From a management perspective, executive orders can be taken, unified actions can be taken, and excellent automated testing frameworks and keyword-driven scripts can be fully adopted to ensure a high output-input ratio (ROI). At the same time, overly enforcing a set of programs may be detrimental to employee motivation or initiative, as well as negatively impact productivity.

        From the perspective of the company, we should also care for employees, help employees' career development, and how to create more opportunities for employees to improve their abilities. So, should we fully implement keyword scripting software development, or allow some teams to adopt that relatively primitive script development model? This is a pair of contradictions that need to be balanced and channeled. Some independent projects, short-cycle projects, and local projects can be released and decided by the team itself, while the core global product development and long-cycle projects are unified into the same automation framework that supports keyword-driven scripts.

       

        Welcome to share your different views.


Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325563610&siteId=291194637