SELENIUM2 Python Automated Test Study notes (v)

7.1 Automated Test Cases

Whether it is functional testing, performance testing, and automated testing, you need to write test cases, the quality of test cases accurately reflects the experience of the testers, the ability and deep understanding of the project.

7.1.1 Manual test Cases and automated test cases

The manual test case is for the manual tester, the automated test case is for the automated test framework, the former is the manual test case people to apply manual method of use case resolution, the latter is the application of scripting technology for use case analysis.

The former has a good ability of exception processing, and can be based on test cases, manufacturing a variety of different logic judgments, and manual testing step-by-step tracking, can be detailed positioning problems. The latter is tested exactly as a test case, and can only be found in known steps and scenarios, and often because of network problems or minor changes in functionality that result in exceptions to the use cases, automated execution can also uncover new bugs.

Comparison of manual test cases and automated tests:

Manual Test Cases:

L Good exception handling ability, can be verified by the human logic to verify the function of the current step to achieve the correct or not.

L Manual execution of Use cases has a certain step-jumping nature.

L Manual Test Step-by-step tracking, can be a detailed positioning problem.

L mainly used to detect functional defects.

Automated Test Cases:

The execution object is a script, and any judgment requires an encoding definition.

L Strong correlation between use case steps.

L is mainly used to ensure that the main function of the product is correct and complete and that the testers are freed from tedious and repetitive work.

L Current automated test phase positioning in smoke testing and regression testing.

Automated test Case Selection considerations:

1. Not all manual use cases are converted to automated test cases.

2. Consider the cost of scripting development, and do not select Use cases where the process is too complex. If necessary, consider splitting the process into multiple use cases to implement the script.

3. The selected use case should be built into a scene. For example, a functional module, which is divided into n use cases, uses the same scenario for n use cases. The advantage is that it is easy to build a keyword test model.

4. The selected use case can be purposeful, for example, this part of the use case is a use case for smoke testing, that part is regression testing, of course, there will be overlapping relationships. If the current use case does not meet the requirements, then only modify use cases to adapt to the script and requirements.

5. The selected use case can be a tedious part of what you think is repeated execution, such as field validation, prompting information validation. This section applies regression testing.

6. The selected use case can be the main process, which is partly applicable to smoke testing.

7. Automated testing can also be used to do configuration checks, database checks. These may go beyond manual use cases, but are also part of the extension of use cases. Project leaders can be selectively increased.

8. If you usually need to construct some complex data, or repeat some simple mechanical action, tell the automation script to help you when you are testing manually. Perhaps your efficiency has improved.

7.1.2 Test Type

Static Content Testing is the simplest test for validating the existence of static, non-changing UI elements. For example:

? Each page has its intended page title? This can be used to verify that the link points to an expected page.

? Does the application's home page contain a picture that should be at the top of the page?

? does each page of the site contain a footer area to show the company's contact details, privacy policy, and trademark information?

? are the

You may or may not need to test the content of the page automatically. If your page content is not easily affected by manual content testing is sufficient. Content testing is valuable if, for example, the location of your application files is moved.

Test Link: A common error for a Web site is that a broken link or link points to an invalid page. Link testing involves the point of each link and verifies that the intended page exists. If static links do not change frequently, manual testing is sufficient. However, if your web designer often changes the link, or if the file is redirected at a time, the link test should be automated.

Functional Testing is often the most complex type of test that requires automated testing, but is often the most important. Typical tests are logins, registered website accounts, user account operations, account settings changes, complex data retrieval operations, and more. Functional testing typically corresponds to your application's description of application features or design usage scenarios.

test dynamic elements: typically a page element has a unique identifier that uniquely locates the elements in the page. Typically, a unique identifier is implemented with the ' id ' attribute or ' name ' property of the HTML tag. These identifiers can be static, constant, string constants.

the test of Ajax: Ajax is a technique that supports the dynamic change of user interface elements. Page elements can be changed dynamically, but do not require the browser to reload the page, such as animations, RSS feeds, other real-time data updates, and so on. Ajax has countless ways to update elements on a webpage. But the simplest way to understand Ajax is to think that in an AJAX-driven application, data can be retrieved from the application server and then displayed on the page without reloading the entire page. Only a small portion of the page, or only the element itself, is reloaded.

The following principles should be observed in the process of writing use cases:

1, a script is a complete scene, from the user login operation to the user to exit the system close the browser.

2, a script script only verifies a function point, do not try to log on the system after the user all the functions are verified before exiting the system

3, as far as possible only to do the function of the normal logic verification, do not consider too many reverse logic verification, the reverse logic of a lot of situations (such as hand number in many cases), verification on the one hand is more complex, need to write a large number of scripts, on the other hand, the automation script itself is relatively fragile, many non-normal logic (We try to write the script according to the user's normal use principle)

4, there is no correlation between scripts, that is, each script written is independent, can not rely on or affect other scripts.

5, if the data is modified, the data needs to be restored.

6. Verify only the verification points throughout the script, not every step of the script.

8.1 Generating test Reports using Htmltestrunner

Htmltestrunner is an extension of the UnitTest unit testing framework of the Python standard library. It generates easy-to-use HTML test reports. Htmltestrunner is issued under the BSD license.

The first thing to do is htmltestrunner.py file:

Http://tungwaiyip.info/software/HTMLTestRunner.html

Htmltestrunner.py is a. py file that can be called by placing it in the Python installation directory.

Windows: Put the downloaded files in the ... \python27\lib directory.

The Htmltestrunner package is introduced in Python interactive mode, and if there is no error, the add succeeds.

>>> Importhtmltestrunner

8.1.1 Generating Htmltestrunner test reports

testbaidu.py

#coding =utf-8

Fromselenium Import Webdriver

Importunittest,time

Importhtmltestrunner

Classmytest (unittest. TestCase):

def setUp (self):

Self.driver = Webdriver. Chrome ()

Self.driver.maximize_window ()

Self.driver.implicitly_wait (10)

Self.base_url = "Http://www.baidu.com"

def test_baidu (self):

Driver = Self.driver

Driver.get (Self.base_url + "/")

driver.find_element_by_id ("kw"). Clear ()

driver.find_element_by_id ("kw"). Send_keys ("Htmltestrunner")

driver.find_element_by_id ("su"). Click ()

Defteardown (self):

Self.driver.quit ()

if__name__== "__main__":

Testsuite=unittest. TestSuite ()

Testsuite.addtest (MyTest ("Test_baidu"))

Html= ". \\result.htm"

Fp=file (Html, ' WB ')

Runner=htmltestrunner.htmltestrunner (stream=fp,title=u ' Baidu Search test Report ', Description=u ' use case execution: ')

Runner.run (TestSuite)

Fp.close ()

First, the Htmltestrunner module is imoport in. Defines the storage path for the test report Fiename, which opens the file in read-write mode via file ().

Then call the Htmltestrunner method under the Htmltestrunner module. Stream specifies a test report file; title defines the title of the test report; description is used to define the subtitle of the test report.

The test cases assembled in the test suite are now run through the Htmltestrunner run () method. Finally Fp.close () to close the test report file.

Use the Help () provided by Python to see a description of the classes and methods.

>>> Import Htmltestrunner

>>>help (Htmltestrunner)

Each time before running the test to manually modify the name of the report, if you forget to change the previous report will be overwritten, this is obviously troublesome, then there is no way to make each report name is different and more meaningful, we can add the current time in the report name, This way the report does not overlap and knows more clearly about the time before and after the build.

time.time () gets the current timestamp.

time.ctime () the string form of the current time.

time.localtime () the Struct_time form of the current time .

time.strftime () used to get the current time, you can format the time as a string.

Python Medium Time date formatting symbols:

%a shorthand for the day of the week

%A Full name of the day of the week

%w the day of the Week in decimal (value from 0 to the 6 , Sunday for 0 )

%d The day ordinal of a month in decimal notation

%b shorthand for the month

%B Full name of the month

%m the month in decimal notation

%y decimal Year Without a century (value from 0 to the About )

%Y 10 year with century part

%H Hours of the hour system

%I Hour of the hour system

%p of local AM or PM the equivalent display

%M the number of minutes represented by the 10 o'clock system

%s number of seconds in decimal

%f decimal microseconds, 0 padding on the left

%Z the name of the current time zone

%j The day ordinal of a year in decimal notation

%u the number of weeks in a year ( 00-53 ) Sunday for the beginning of the week

%W the number of weeks in a year ( 00-53 ) Monday for the beginning of the week

%x Local corresponding date representation

%x local corresponding time representation

%%                  % number itself

Get current time: now = Time.strftime ("%y-%m-%d%h_%m_%s")

The current test report is only integrated into a single test file, and our ultimate goal is to integrate it into the table all_test.py file. Open the all_test.py file below and make the following changes: unittest\project\all_test.py

#coding =utf-8

Import UnitTest

Import Htmltestrunner

Import time

Def creatsuite ():

Testunit=unittest. TestSuite ()

Test_dir= "C:\\users\\ewang\\desktop\\python_selenium2\\unittest\\project\\test_case"

Discover=unittest.defaulttestloader.discover (test_dir,pattern= "test*.py", Top_level_dir=none)

For Test_suit in Discover:

For Test_case in Test_suit:

Testunit.addtest (Test_case)

Return Testunit

now = Time.strftime ("%y-%m-%d%h_%m_%s")

filename = '. \\report\\ ' +now+ ' result.html '

fp = file (filename, ' WB ')

Runner=htmltestrunner.htmltestrunner (

STREAM=FP,

Title=u ' Baidu Search test Report ',

Description=u ' use case execution: ')

If __name__== "__main__":

Alltest=creatsuite ()

Runner.run (AllTest)

8.2 Creating a timed task

To "automate" automated testing, let's now create timed tasks that automate the automated test scripts at a specified time. There are many ways to create a timed task, for example, we can write a program to run the all_test.py file at a specified time, or use the system's scheduled task function to run the all_test.py file at a specified time.

SELENIUM2 Python Automated Test Study notes (v)