Automatic case development and case hierarchical structure design based on Appium

Automatic case development and case hierarchical structure design based on Appium

First, create a common base class appiumtestbase for each case, containing the setup and teardown two methods, each of which inherits from the base class at a later time. The code is as follows:

PublicClassAppiumtestbase {Public webdriverwait webwait;Private Androiddriver driver;@BeforePublicvoidSetUp()Throws Exception {File Classpathroot =New File (System.getproperty ("User.dir")); File Appdir =New File (Classpathroot,"Apps"); File app =New File (Appdir, Config.current_bank); Desiredcapabilities capabilities =New Desiredcapabilities (); Capabilities.setcapability ("DeviceName", config.device_name); Capabilities.setcapability (Capabilitytype.browser_name,""); Capabilities.setcapability (Capabilitytype.version,"5.0.1"); Capabilities.setcapability ("PlatformName","Android"); Capabilities.setcapability ("App", App.getabsolutepath ()); Capabilities.setcapability ( "Udid", config.device_name); //ADB devices obtained value Driver = new androiddriver (new URL (" http://127.0.0.1: "+config.appium_port+  "/wd/hub"), capabilities); webwait = new webdriverwait (Driver,10); Drivermanager.init (driver); Drivermanager.initwebwait (webwait); Driver.manage (). Timeouts (). implicitlywait (10, Timeunit.seconds);}  @After public void teardown () throws Exception {driver.quit ();}         

The setup operation consists of importing the app to be tested APK package, setting the parameters required to connect with the Appium server, and initializing the Androiddriver object. For example, to sign in case, it needs to inherit Appiumtestbase, the code is as follows:

Package Com.incito.appiumdemo;Import Org.junit.After;Import Org.junit.Before;Import Org.openqa.selenium.remote.CapabilityType;Import org.openqa.selenium.remote.DesiredCapabilities;Import org.openqa.selenium.support.ui.WebDriverWait;Import Java.io.File;Import Java.net.URL;Import Java.util.concurrent.TimeUnit;Import Io.appium.java_client.android.AndroidDriver;PublicClassAccountLoginExtendsappiumtestbase{/** * Case Number ACCOUNTLOGIN_001 * * * * * * * *@throws ****exception * * @Test public void testaccountlogin () throws Exception {account.*getinstance* (). Gotologinpage (); Account.*getinstance* (). Dologin (); }/** * Case Number accountlogin_002 * **** @throws ****exception */ Span class= "hljs-annotation" > @Test public void testloginout ()  Throws Exception {account.*getinstance* (). Gotogestureloginpage (); Account.*getinstance* (). Dogesturelogin (config.*current_username*); Personal.*getinstance* (). Dologout (); }

In Testaccountlogin case, two steps were taken: Enter the login page and perform a login operation. Both of these steps are encapsulated within the account class. This introduces a layered design framework for automated case, such as:

Paste_image.png

One of the frequently encountered problems in the automation development process is that as the product is continually updated, the UI of the app changes constantly, how automation can cope with such changes, and how to reduce its maintenance costs. Case layered design is mainly based on the consideration of automatic maintainability, maintainability is one of the most important evaluation indexes of function automation, which directly determines whether automation can proceed. If the number of case to a certain extent, if not the packaging, layered design ideas, it is very likely to appear "reaching" problem. is a hierarchical catalog diagram of the standard automation case.

Paste_image.png

The following is an example of a login case to learn more about its hierarchical invocation relationship. Login case in the cases layer of the AccountLogin class, its code above has been shown, back to Testaccountlogin case operation, the second operation is account. getinstance (). Dologin (); That is, log on to the login page, which is encapsulated in the account class of the business layer, with the following code snippet:

public void doLogin(){ LoginUiAction.*getInstance*().enterUsername(Config.*CURRENT_USERNAME*); LoginUiAction.*getInstance*().enterPassword(Config.*CURRENT_PASSWORD*); LoginUiAction.*getInstance*().clickLogin(); HomeUiAction.*getInstance*().clickOnCancelGesture(); Assert.*assertTrue*(LoginUiAction.*getInstance*().isLogin());}

The Dologin () method executes the "Enter user name, enter password, click the login button, determine whether the login is successful" operation, obviously these steps are in the UI layer Loginuiaction class. We'll check loginuiaction again. getinstance ().
What is done in the Enterusername () method, the code snippet is as follows:

//输入用户名public void enterUsername(String username){ WebElement wl = DriverManager.*getInstance*().findElementById(packagename + ":id/login_input_account"); wl.clear(); wl.sendKeys(username);}

Enterusername () method, first locate the user name input box based on the ID, then empty the input box, and then enter the user name, which are the APIs provided in the Appium client. This demonstrates the layered invocation process for login case: Cases->business->ui->api. As long as the business logic is the same, the case maintenance task is placed primarily on the UI layer, and the upper layer does not need to be changed, which can greatly reduce the maintenance cost of the transaction.
In the Dologin () method, there is a "determine the success of the login" operation, the assertion operation is an essential part of the automated test case, the following is the introduction of automated test case writing specifications.

Automated test case writing specifications and precautions

A case generally needs to include the following elements:

• Data preparation
• Specific operation
• Verification Point
• Clear Operation Results

Data preparation refers to the preparation of test accounts, false data, etc., in accordance with the business test students provided by the text case to convert; Verification point refers to the automated operation, the UI before and after the change point, such as login, the first page will appear the user name, total assets, wealth points and other controls, these are verification points Clear operation results are mainly based on case independence considerations, as far as possible to each case is independent, so that some cases fail, and will not affect other cases, of course, this will increase the granularity of cases, cases stability will be affected, the two can be self-balanced.
Here are some considerations for case development:

1. Element positioning
   • ID (preferred)
   • Text
   • control type
   • Coordinate
2. UI action requires a reasonable sleep
3. Case independence
4. Encapsulate common operations
5. Note and case before the procedure

element positioning has ID/text/control type/coordinate four ways, it is recommended to use IDs, because as long as a control still exists, its ID change is very small, if its location changes, case is not maintenance.
Here are a few ways to find the element ID: uiautomatorviewer/hierarchyviewer/source. Uiautomatorviewer and Hierarchyviewer tools in the Android SDK, after configuring the environment variables, directly at the command line to enter commands to open the graphical tool, hierarchyviewer need phone root, It is recommended to use Uiautomatorviewer. If the source of the application to be measured, but also through the source code to find the ID, of course, this way is more painful, but familiar with business and personal growth is beneficial, I started from the source to find the ID.
For some wonderful situation, the element ID/text/control type can not be located, the use of coordinate positioning absolutely so, but not the last resort, as far as possible, because the coordinates are lost compatibility, change a phone, case may fail to execute.
UI operation requires reasonable sleep, often due to network reasons, the UI load takes a certain amount of time, the automation process needs reasonable sleep,sleep time is short, case will fail, long and wasted time. The implicit sleep scheme was introduced in the Appium framework, adding driver.manage () to the initialization code. Timeouts (). implicitlywait (Timeunit. SECONDS), which indicates that each operation waits up to 10s.
Case independence has been described before, encapsulation and annotations are easy to understand, do not explain too much.

Text/Ping An cloud test platform (Jane book author)
Original link: http://www.jianshu.com/p/497f9ed26189
Copyright belongs to the author, please contact the author to obtain authorization, and Mark "book author".

Automatic case development and case hierarchical structure design based on Appium