Advice for beginners in software automation testing, if you miss it, you will regret it

Most of the main technical manifestations of IT are described in English first. If you want to upgrade to a relatively high level, you must have fluent English reading ability.

In terms of search engines, you should cherish your life, stay away from bidding rankings, be a person with a conscience and not be deceived, and never start with a degree of death and repentance. Google is preferred. Others include Bing Yahoo oscobo, and many QQ groups also have free fanqiang tools . Google searches usually hit the mark, and stackoverlow answers are usually the preferred solution.

Choosing qualified professionals to help is a quick way to improve after mastering the basics of linux, python and testing.

Layers of automated testing

It can be seen from the figure that automation should focus on units and interfaces as much as possible. If you are interested in deepening automated testing and are still struggling with QTP, selenium, etc., it is recommended to look at pytest, pexpect, API testing, unit testing , etc.

screenplay

1-1 Do not use recording and playback in real projects

Most automation tools (especially commercial tools) have a record and playback function, which is simple on the surface and has pitfalls. Recording and playback looks great in advertising videos and presentations. But the recorded script does not use variables, loops and conditions. The names of automatically created programs and functions are usually not intuitive, usually all operations are recorded in a function (which may be large), the execution is unstable, and the maintenance cost is also high.

Applicable points for recording and playback
- learning automation tools
- unreused work
- Controls that are difficult to identify and handle

1-2 Do not use pause

Pause, like in python:


import time

time.sleep(5)

Defining global variables can avoid a lot of code modification, as follows


WAIT_TIME = 5
...
time.sleep(WAIT_TIME)

The above waiting is not conducive to fast execution, and controls that appear sooner also require common waiting. Waiting on an object or an object property is a better choice, like an explicit wait in selenium:


from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

driver = webdriver.Firefox()
driver.get("http://somedomain/url_that_delays_loading")
try:
    element = WebDriverWait(driver, 10).until(
        EC.presence_of_element_located((By.ID, "myDynamicElement"))
    )
finally:
    driver.quit()

Another example is the implicit wait in selenium:


from selenium import webdriver

driver = webdriver.Firefox()
driver.implicitly_wait(10) # seconds
driver.get("http://somedomain/url_that_delays_loading")
myDynamicElement = driver.find_element_by_id("myDynamicElement")

Check for the existence of the object with WebDriverWait at a certain interval (eg once per second), and return true if the object is present. Returns false if the object does not appear within the time specified by the timeout parameter. So, if the control appears within one second, the wait time will be 1 second.

Of course, short-term waiting is sometimes necessary, such as reducing CPU usage, waiting for a short-term state change, and so on.

1-3 exit with timeout in loop

Define the timeout as a constant. For example define two types of short timeout (3 seconds) and long timeout (3 minutes).

1-4 Don't completely equate automated testing with development

While automation requires programming skills, it is usually not a complete development project. Automation is often developed by junior programmers because the job is much simpler and generally an internal requirement. Most design patterns are not needed in 99% of cases. Transactions are not used when working with databases. The amount of test data is generally not very large.

The code should be simple and fast development. Even if you use methods such as behavior-driven development (BDD: behavior-driven development) or keyword-driven testing (KDT: keyword-driven testing), try to keep the code as simple as possible.

1-5 Don't write complicated code

Try to follow the "no more than three levels of nesting" rule when using conditions and conditions.

Code nested more than three levels is very difficult to debug. I would rather repeat the code than nest more than three levels.

1-6 Validate all options for logical conditions


if A and B or C：
# if (A and B) or (C and D)

Be sure to check each condition of these codes (A, B, C in this example) and all possible True and False. Adding parentheses improves readability.

1-7 Using Programming Guidelines

Beginners usually don't pay much attention to any rules on the use of variable and function names. Despite this, almost all languages have so-called coding standards. For example, python's PEP8, google's programming specification.

These standards become mandatory rules in large projects to facilitate mutual understanding of the code.

1-8 Using a Static Code Analyzer

For popular programming languages there are special code analyzers. For example, pylint of Python, jslint of JavaScript language, etc.

In particular, it is more important for dynamically typed languages such as python.

pylint usually has a lot of false positives, but mypy's checks are more practical. Reference: python code analysis and lint .

1-9 random

For example, there are many ways to open the menu, such as shortcut keys, drop-down menus, icons, etc., try to write methods to randomly call various methods. In order to cover various scenarios, but remember to add logging to track errors.

1-10 Do not use coordinates

Try not to use coordinates for non-standard controls, you can use image recognition methods:


Window.Toolbar.Click(135, 15)

Replace with:


toolbar_click_button_by_image(Window.Toolbar, "Button Caption")

1-11 Learning and Using Libraries

for example:


full_name = '{0}\\{1}'.format(file_path, file_name)

It is awkward on linux and can be replaced by:


full_name = os.path.join(file_path, file_name)

Attachment: python automated test development library

1-12 Avoid copying and pasting

The copied code is expensive to maintain, so try to extract it as a public library.

Public Test Repository Example

1-13 Exception caught to a specific class

Exceptions usually occur because the program is not thoughtful:


try:
    x = input('Enter the first number: ')
    y = input('Enter the second number: ')
    print x/y
except Exception as e:
    pass

The code above that catches all exceptions and ignores them is usually only used in temporary code. Usually, exception information should also be displayed. for example


import sys
try:
	x = input('Enter the first number: ')
	y = input('Enter the second number: ')
	print x/y
except Exception as e:
	print e
	for  item in sys.exc_info():
		print item

Another example:


import traceback

import cv2
import numpy as np

def raw2jpg(filename, height=480, width=640):
    try:
        img = np.fromfile(filename, dtype=np.uint16)
        img = img.reshape( (height, width) )
        img.astype(np.float)
        img = np.sqrt(img)
        img = img * (255 / img.max())
        #img.astype(np.uint8)
        cv2.imwrite(filename+'.jpg', img)
    except Exception as info:
        print('Error: {}'.format(filename))
        print(info)
        traceback.print_exc()
        return False

    return True

A better way is to catch specific exceptions:


try:
    x = input('Enter the first number: ')
    y = input('Enter the second number: ')
    print x/y
except ZeroDivisionError as e1:
    print("ZeroDivisionError")
except TypeError as e2:
    print("TypeError")

Another exception handling method:


far = 0 if not no_number else far_number/float(no_number)

1-14 Code and data separation

Arrays or lists can be used for small datasets. Big data can use data-driven testing (DDT: data-driven testing). The data source may be a database, Excel or CSV file, etc.

important point:

Open the data file in read mode.
Each column stores only one type of data. In the case of a database,
Used to close with the data source
Do not use blank lines in data files

1-15 Debugging

Simply, you can use print or logging to print some information. More advanced content has

•Breakpoints •Single stepping •View the value of local and global variables •Watch variables and expressions

1-16 Don't write code for the future

Project changes are frequent, and some technical pre-research on automated testing can be done, but generally do not write some code that is only for future use.

1-17 Make code better

Improve readability without compromising performance.

1-18 Test Select Appropriate Language

Easy programming and popularity and library support for the language. Generally speaking, python is currently the language of choice with the highest share of automated testing because it is easy to use, is a glue language (easy to call with other languages), concise syntax, low maintenance cost, and easy to debug. But c# also has a certain market on the windows platform, java, c++, etc. Although python has the highest share, it must be considered that some automated test development may already have ready-made tools such as c++, go, and java.

Try not to use new programming languages. Consulting development can use the same language as development, especially unit testing, which generally uses the same language as development.

It is worth noting that TCL (Tool Command Language) has a certain reputation because of the command automation of expect, and instruments such as testcenter and smartbits did not support mainstream languages such as python. However, TCL's syntax is obscure and its functions are weak, so it is a language that should not be used if it can be used.

References: programming popularity tiobe

1-19 Variables must be initialized before use

This can be checked with mypy in python.

Testing Best Practices

2-1 Do not implement the functions of the application under test

because:

• Calculations and logic may be complex and developed already implemented • Calculations and logic may change • Precision of using floating point numbers may be language dependent.

In white box and gray box testing, it is generally good to know the input and expected results, but not the specific internal implementation process.

Exception: For tests with unclear expected results such as big data and search engine intermediate algorithms, it is often quickly implemented in python, and compared with the results implemented in languages such as C++.

2-2 Independence of testing

2-3 What should not be automated

Mainly based on cost considerations

• Difficult to maintain automation. •Do as much automation of unit testing and interface testing as possible, and less automation of UI layer •Automation with few reuse times

Some necessary tests that cannot be done manually need to be automated even if the cost of automation is high.

2-4 Seek help from developers

Development can be worth learning in terms of specific development, but it is better to decide by yourself in terms of automated testing and solutions. For example, in result verification, developers mostly like to read data directly from the database, but in fact, applications that display database data may also have problems.

2-5 Cloud Test

cloud testing

• To test a desktop application, a session must be opened, whether the OS supports it • Hardware-related testing Cloud testing support is not convenient. • Cloud services for mobile devices are usually more expensive • Automation of web applications is more suitable for execution in the cloud. • The cloud can be considered for mobile phone compatibility testing, but it is better not to use the cloud for functional automation testing.

2-6 Making full use of boundary values and equivalence classes

2-7 Errors and Warnings

Be careful to distinguish between bugs in the automated testing platform or tool and bugs in the application under test.

2-8 Use Appropriate Technology

There are many specific approaches used in test automation: ODT, DDT, KDT, BDD, Page Objects, Model-Based Testing, and many more. For example, for KDT, it is generally necessary to write a part of the test platform, a part of the test library, and a part of the test case.

2-9 Verification of special errors

An ad-hoc test can be written to handle certain bugs.

2-10 Do POC before writing real tests

environment

There are two main types of environments in software test automation. One to create and debug tests and the other to run tests.

3-1 Choose the right set of tools for your needs

Taking interface automation testing as an example, some teams insist that java is the best language, and use java to send HTTP requests. What's more, jmeter is used for interface automation testing. It may be an appropriate way to exclude individual scenarios, but the usual HTTP interface test uses requests, and the number of lines of code is usually an order of magnitude less than that of Java, without compiling.

Python is the glue language among mainstream languages, and it works perfectly with other languages. It is usually the preferred language for automated testing, but python may not be applicable everywhere, and other tools and languages are needed to supplement it, but don’t learn too much. Language is also a painful thing.

There are still many training institutions advocating that UI automation is the whole of automated testing. When they say that automation is QTP, they don’t know what Selenium, Testcomplete and the like are, let alone junit, pytest and the like.

3-2 Auto-submit bugs with caution

Misconfigured, wrong test code often leads to test failures.

The test code is sometimes difficult to describe the test steps clearly

Be careful not to file duplicate bugs.

In the absence of full confidence, you can use a semi-automatic method to send emails to testers, and then testers submit bugs.

3-3 Do not use deceitful results

Avoid commenting out problematic parts of the test code or changing expected results so that tests don't fail.

If you really need to disable it, you need to know the proportion of disabled use cases, and then check and modify it regularly later.

3-4 Skilled use of tools

For example, Ctrl + \ in wingide is the shortcut key for commenting code

3-5 Using a version control system

Avoid file loss, facilitate collaboration, use hg, git and the like as soon as possible.

3-6 Avoid custom forms

Originally, the purpose of automation is to get the content of the page to the background as much as possible. You have made it into a formalism in order to please the leaders (attachment: most test leaders in mainland China are not qualified at present) or for some reason. Of course, the data report is another matter.

Parameters can be used in configuration files, etc.

3-7 Automate everything that can be automated

For example: test, code, test environment, virtual machine, SQL query, test data, report, etc.

run, log, verify

4-1 Run the script as often as possible

4-2 Re-execute when the test fails

When an error occurs, the application runs for a long time, or in a specific situation to try to locate the problem.

Generally speaking, the failed tests are recorded first, and then re-executed after all tests are executed.

4-3 Rich log content

The error log contains as much as possible: expected value, actual value, location and operation.

Parameters should be enclosed in quotation marks as much as possible, so as not to treat parameters containing spaces as multiple parameters.

4-4 screenshot

UI tests can take screenshots when necessary, and handle scrolling at the same time.

4-5 Try to avoid comparing images

review

Reviews are a great way to keep code clear and understandable, and mutual review of code is required.

5-1 Let non-automated people understand the code


def test_login(url, user, password, text):
    open_page(url)
    login_as(login=user, password=password)
    verify_page_opened(text)

5-2 Avoid unnecessary optimization

If you need to think carefully before starting to perform any optimization.

Typically unwanted optimizations look like this:

1. The application starts for 3 seconds, then a 5-second test script fills the search field, and there are 5 seconds for the search process, and then the script takes 1 second to read the found data and verify it. 2. Tester starts optimizing read and verify 3. Tester spends a day optimizing and hits target: read and read run in half a second each

In fact, the test engineer's code productivity has doubled, but the result is about a 5% gain in his overall approach. It's not worth spending a day. Generally, it needs to be considered comprehensively, involving scripts, applications under test, environment, execution frequency, etc.

It is recommended that you optimize your tests in two situations:

• If the test runs for a long time and the application under test is idle during the test execution. • If you see obvious problems in the code, correct them.

Pandas big data analysis performance optimization example - read_csv engine and grouping, etc. , here is a necessary optimization example.

5-3 Regularly review other people's code

Regularly review new code from others. You can pair program, or even write and read at the same time.

5-4 Participate in forums and discussions

If you are a beginner in automation and you work in an automation team, you will learn a lot from your colleagues. What if you are the only automation engineer in the company or no one in your department can help you?

Communities such as stackoverflow can often find satisfactory answers to their own questions. At the same time trying to help others can also expand your own perspective.

5-5 Performing Refactoring

Refactoring is the simplification of existing code without changing the functionality and application. Even though the code in test automation is often much simpler in practice, sometimes you still need to refactor.

• You may find that the code you support is too complex. • There may be requests to write new tests, requiring code changes • Refactoring may be required to improve code already written

After refactoring, you can execute all tests to verify, and you can also add necessary unit tests in places such as public libraries.

5-6 Remove low yield tests

• How many times the test was run; • How many actual problems were found by the test; • How often the test required maintenance.

As someone who has been here, I also hope that you will avoid some detours. Here I will share with you some necessities on the way forward for automated testing, hoping to help you. (WEB automated testing, app automated testing, interface automated testing, continuous integration, automated test development, big factory interview questions, resume templates, etc.), I believe it can make you better progress!

Just leave [Automated Test] [Automated Test Communication]: 574737577 (remark ccc) http://qm.qq.com/cgi-bin/qm/qr?_wv=1027&k=ZzkQcmAe85ckaBPtQUptkVckU2U5XpZL&authKey=xMGxie22qtDJbjrdboxCpO7ZJxkuPAviYs6GiR b2B5T9YhJjlUGuFZSfoxQfWlyy&noverify=0&group_code=574737577