Appium+Python+PO design pattern

Table of contents

Foreword:

What are PageObjects?

About the output of the report

Summarize


Foreword:

Appium is an open source tool for automated mobile application testing, Python is an easy-to-learn and powerful programming language, and the PO (Page Object) design pattern is a commonly used design pattern in automated testing.

What are PageObjects?

  • A design pattern belonging to selenium, which is applied to appium (practice shows that it is suitable, because selenium and appium are "born from the same root")
  • My personal understanding of PO is that page elements-page business operation steps-methods-test cases (I know abstraction, you can understand it yourself)

The following figure is my code structure:
Data: test data. In the later stage, prepare to integrate all the test data in the code into excel or xml, and the Data folder is for this purpose
PO: All Pages. Based on the Base page (see the analysis in the figure below to understand PO)
Public: some public methods, such as test report scripts, packaged
Result: test results, including test reports and screenshots
TestCase: test cases are placed here
run_case: test The suite uses HTMLTestRunner.py to output test reports to /Result

What is repackaged in Base is the basic webdriver method and some public methods needed by your own test cases. Other Pages in PO are inherited from Base. The only
difference between appium and selenium is the driver setting

The driver call here, I feel that I haven't written it yet, my requirement is to define the driver only in the Base, specify the port, all test cases share a driver, call it directly in the test case, I have debugged it, and I The level of python is also average, and it has not been changed. I will improve this later.

The method of directly encapsulating the entire business process in the Page will reduce the amount of code in the test case. (Of course, it is also possible to write in the test case)
Briefly explain:

  • Scenario: Login business
  • Inside the Page: a. Enter the user name b. Enter the password c. Click the login button; A. Login method (including abc)
  • In the test case: 1. Directly call the A of the Page; 2. Call the abc of the Page sequentially. These two methods have their own advantages and disadvantages, so choose what you need

For the test case, I use unittest.
This demo does not write assertions, does not log, and does not put test data in external files. These are to be improved later

About the output of the report

Use the test suite to drive HTMLTestRunner to generate test reports, and add a screenshot function.

Summarize

On the whole, the construction of the framework is very simple, but it can be regarded as complete (well, there are still a few, I know). I personally feel that there are still many options for how to build the framework, which design pattern to use, and which tool to use. Similar to the web, keywords, PO, RF... take what you want, everyone, and, in different design modes, the code structure depends on each person's choice.

  As someone who has been here, I also hope that everyone will avoid some detours

Here I will share with you some necessities of the way forward in automated testing, hoping to help you.

(software testing related materials, automated testing related materials, technical questions and answers, etc.)

I believe it can make you better progress!

Click on the small card below

Guess you like

Origin blog.csdn.net/Free355/article/details/131786007