Shulou(Shulou.com)06/01 Report--

Frame design illustration:

Preparations for the implementation of the framework:

Installation under Windows with 1.Python version 2.7.11.

two。 The latest version of selenium under the command line (the editor uses version 2.53.0, which is compatible with the latest browser versions such as Firefox, IE, chrome, etc.) pip installation.

3. Eclipse installation for version Version: Mars.1 Release (4.5.1) (editor Python development tools), jdk1.7.

Python development plug-in PyDev 4.5.1 under 4.eclipse (the high version is not necessarily compatible with the current eclipse version and Java version. After the high version is installed successfully, the corresponding PyDev plug-in cannot be found in eclipse).

The MySQL database under 5.Python (the editor uses the data as MySQL) module installs MySQL-python-1.2.4b4.win32-py2.7 (note that the module version and system bits are the same as installing Python).

6.Python decompiler module uncompyle-master installation (may be used).

7.Python can perform packaging module py2exe-0.6.9.win32-py2.7 installation (which may be used).

Feasibility of framework implementation:

1. Easy to extend, similar to the modular installation of Python.

two。 Easy to maintain, upgrade for the latest version of selenium (the latest version of compatible browsers, etc.) only need to execute under the command line: pip install-U selenium.

3. The language is simple and easy to learn. As long as the learning of Python is not too high-end (refactoring, complex polymorphism, etc.), it can be done in a short time.

4. All browsers are compatible (the editor's other articles include calls to browsers such as IE, chrome, etc.).

The implementation of the framework is described as follows:

Start with a long line:

Before you explain the train of thought, say a few words (the fault can't be changed). Editor colleagues have done a lot of things, and the code they write is very awesome (function, performance, readability, etc.), and the project framework designed is excellent, but as for many project developers, it is difficult to achieve the idea at the beginning of the framework design. do the project implementation according to the initial framework design. In the final analysis, it is due to the failure of the project staff to achieve consistency in thinking, that is, the framework designer fails to convey the frame design idea to the project staff well, and the project staff can not unify the idea. It leads to the possible failure of the later project and various difficulties in the implementation process (project staff A thinks that the sofa can be made according to the framework, but project staff B thinks that the bench can only be designed according to the framework, which is not unified in thought). More things about the design of the framework are not well understood. No matter what they do, the editor always thinks that ideas come first.

Test case code implementation storage module:

Import unittest

From time import sleep

From common.driverElement import driverElement

Class CrmLoginTest (unittest.TestCase):

Def setUp (self):

Self.driverElement=driverElement ()

Self.driver=self.driverElement.webdriverInit ('http://crm.360.cn/login')

Def tearDown (self):

Self.driver.quit ()

Def testName (self):

Self.driverElement.webdriverLogin (self.driver)

Sleep (4)

The code is very simple and defines an implementation class CrmLoginTest of the system login test, which inherits several methods defined by the TestCase interface of the unittest module: setUp, tearDown, testName.

Unittest is similar to Java's TestNg in that it is used for unit testing in their respective languages. It's just a different way of doing it. Specifically looking at the test implementation class inheritance method, setUp is used for the preparation work before the test case execution, including the connection establishment of the database, the prefabrication preparation of the data needed for the use case, and so on. The testName method defines some operations used in the specific implementation of the use case, entering the user name and password of the page, clicking the [login] button on the page, and a series of manual test operations. The tearDown method is used for the end of use case operations such as garbage data collection, database connection disconnection and so on.

In the test implementation class, the execution order of setUp, tearDown, and testName methods is not in the order in which they appear. No matter what the order in which the three methods appear, they all give priority to the execution of setUp, while testName and testName1. Finally, tearDown is executed.

The implementation idea of the test case code storage module is that only test case method (CRMResourcesTest), test case data file (Login.json) and directory (used to mark the different levels to which the test case belongs) are only allowed under this module. The distinction between test case method and test case data file is "an important implementation of the separation of data and script" in the idea of automation. After the data is separated from the script, it is easy to automate the use case maintenance (only need to maintain the json file to achieve the use case maintenance, no need to modify the test script). As more and more automation is done, you will find how important it is to separate data from scripts.

Common logic code encapsulation storage module:

Only the self.driverElement.webdriverLogin method is used in the testName method in the above code, that is, the system login is implemented. For the actual manual test operation, the completion of the login page requires "entering the user name", "entering the password" and "clicking the [login] button" to realize the system login operation. Only "one step" is used here, that is, to log in to the system. If you look at the driverElement.py file under the common logic code encapsulation and storage module, you can see that the webdriverLogin method is as follows:

Def webdriverLogin (self,driver):

Elementaction=ElementActionutil ()

Elementaction.textinput (driver, elementname='js_uname', method='Class', text=self.f.getGlobalFileattrs ('Login.json',' username'), timeout=2) # user name input

Elementaction.textinput (driver, elementname='js_upwd', method='Class', text='123456') # password input

Elementaction.singleclick (driver,elementname='btnsend',method='Id') # Click the [login] button

Print 'System login fullyborn'

As you can see from the above code, the "one step" is actually a package of three steps, which is encapsulated here for the above three steps, because these three steps are used in many use cases. After encapsulation, each test case directly calls the "one step" method to achieve system login, without the need to write three steps in each use case. The code is beautiful, easy to read, and easy to implement. This is the meaning of the "common logic code encapsulation storage module", aiming at the common steps that are repeatedly used in the code. Of course, for the test data used in the encapsulation implementation of the common steps, there are public data files, such as the Login.json file under baseaction, which stores the data used in the common logic code.

GUI page action code storage module:

For details, see the singleclick method in the elementActionUtil.py file under the module:

Def singleclick (self,webdriver,elementname='',method='Id',timeout=2):

'method value:Id,Name,Class,xpath;webdriver value Firefox,Ie'

Element1=waitforElementPresentAction.waitforElementPresentAction (webdriver, elementname, method, timeout)

Element1.click ()

The common logic code encapsulates the elementaction.singleclick steps in the storage module, and its implementation is the above code. The mouse click operation in the actual manual test is not a low-level method in the code implementation, and often requires N multi-operations. To whom, what, and so on. Especially when it comes to the poor network, the manual test knows how long to wait for the click operation, but the automation code has to find ways to complete the intelligent manual operation, and its implementation can be imagined.

Here "GUI page action code storage module", only need to include elementActionUtil.py single file, the document defines a variety of page operations: mouse click action, double-click mouse action, text input action, radio button selection action, check button selection action, page element whether visible, element control exists and so on. The collection of all kinds of page actions, that is, it realizes all kinds of manual implementation needed for page automation.

Underlying code module:

The underlying code module defines the core code used to encapsulate each action step in the common logic code storage module, including the execution time of the action, how to find the element control (similar to human eye recognition), which control to perform identification, and so on. The example code is as follows:

Def waitforElementPresentAction (webdriver,elementname='',method='Id',timeout=2):

'method value:Id,Name,Class,xpath;webdriver value Firefox,Ie,takes a WebDriver instance and timeout in seconds'

Element1=None

End_time = time.time () + timeout

While True:

Try:

If method=='Id':

Element1=webdriver.find_element_by_id (elementname)

Elif method=='Name':

Element1=webdriver.find_element_by_name (elementname)

Elif method=='Class':

Element1=webdriver.find_element_by_class_name (elementname)

Elif method=='Xpath':

Element1=webdriver.find_element_by_xpath (elementname)

If element1:

Return element1

Except Exception:

Pass

If time.time () > end_time:

Why assert False,'NoSuchElementException'+ elementname+' with the method'+ method# is so realized here, please give me a reply.

File operation code storage module:

This module stores various methods of how to read the contents of the test case data file, and at the same time, it also defines the storage format of the test data file, the reading of different suffixes of the data file and other operations. are stored in the "file operation code storage module".

Database code storage module:

This module defines a variety of database operations: add, delete, change, query, build tables, call stored procedures and so on. The significance of this module is that in the process of manual testing, after the completion of the foreground page operation, the automatic code implementation of the correctness verification operation of the background database into the table, and the prefabricated implementation of test data before the test case execution, and so on.

Log file code storage module:

The log file code storage module defines how to realize the log file generation, how to run multiple use cases and suite-level use cases to run the test, and how to analyze the operation of the use case. The use case run output log can be used to check the correctness of the use case. The code writer here has not been implemented yet and will be completed later.

Insufficient framework and need to be optimized:

1. How to implement multiple test cases with a single test method, that is, how to define the data file hierarchy and so on.

two。 How the log file defines the implementation.

3. Single use case test execution, multi-use case test execution (suite test execution) test report output, and so on.

4. Code stupid implementation and so on.

.

Unfinished, finished, to be continued. Maybe.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.