What you should know before using data-driven testing (the ultimate article)

the markdown of Blog Park is excrement!! You can choose to briefly read: www.jianshu.com/p/537156a52250

This week we continue this series, this is the last article. It is recommended that you read the first two articles first.

What you should know before using data-driven testing

You should know before using data-driven testing (ii)

In fact, I used to follow the second article described in the way of writing use cases, writing UI Automation (200+ use cases), also write interface automation use cases (the use case), interface Automation first version is written in PHP, was not used to parameterization, The second version used Python rewrite to use the parameterized to do parameterization, resulting in a significant reduction in the number of test code lines. I don't think it's inappropriate to write interface parameters into a use case. Because the interface test has the initialization action of the data, so, the interface use case is very stable, as long as the use case fails paramilitary is the interface processing logic changes, interface Automation project was I maintained for two years, until later separation. The reason I say this is just to show that my point of view is not at least two demos to summarize.

Until recently, I saw a book on Amazon, "Selenium Framework Design in Data driven testing", a very high evaluation, after a search, a classmate of this book tenth chapter on the example of GitHub.
Github.com/packtpublishing/selenium-framework-design-in-data-driven-testing

The entire book is based on the Java language and is based on the dataprovider of the TestNG Unit Test framework to implement a read JSON data file. Therefore, reading a data file cannot be discussed from the Unit test box, because it does solve most of the problems of writing test cases with code.

In this case, the unit test framework under Python Unittest/pytest also has similar operations, so you can read the data in the file and parameterize it to the test case without the hassle.
Also take the login function as an example, here are the DDT libraries that support unittest.

First create a data file: Test_ddt_file.json

{    "test_login_01":{        "username":"",        "password":"123",        "assert_text": "请输入帐号"    },    "test_login_02":{        "username":"user",        "password":"",        "assert_text": "请输入密码"    },    "test_login_03":{        "username":"error",        "password":"error",        "assert_text": "帐号或密码错误"    },    "test_login_04":{        "username":"admin",        "password":"admin123456",        "assert_text": "admin你好"    }}

To create a test case:

Import unittestfrom Selenium import webdriverfrom DDT import DDT, file_datafrom time import sleep@ddtclass testlogin (Unitt Est. TestCase): @classmethod def setupclass (CLS): Cls.driver = Webdriver. Chrome () Cls.url = "Http://127.0.0.1:8000/" cls.driver.implicitly_wait @classmethod def TEARDOWNCL (CLS): Cls.driver.quit () def user_login (self, username, password): Driver = Self.driver driver. Get (Self.url) driver.find_element_by_id ("Inputusername"). Send_keys (username) driver.find_element_by_id ("Inpu    Tpassword "). Send_keys (password) driver.find_element_by_id (" Login "). Click () @file_data ("./test_ddt_file.json ") def test_login (self, username, password, assert_text): Self.user_login (username, password) if username = = " Admin ": Sleep (2) tips = self.driver.find_element_by_id (" user "). Text Self.assertequal (tips , assert_text) else:tips = Self.driver.find_element_by_id ("Tips"). Text self.assertequal (tips, assert_text) if __name__ = = ' __main__ ': Unittest.main () 

Note the read of the file, just need to specify the path of the data file through the @file_data adorner. can only be convenient to this extent. So is this the perfect one?

First, a test file can only put one type of data.

"test_one": [1, 2, 3],"test_two": "split","test_three": {"three": 3},"test_four": {"four": 4, "five": 5}

The data in this format is certainly not possible, because their data format is inconsistent. So, we have to divide four files to store these four use case data.

Do you want to automate the project only login? Certainly not, the data used for different function points is not the same.

• 1. Search function: Name
• 2. Add address function: Name, address, number of people, date
• 3, sign-in function: mobile phone number
• 4, add guest features: name, mobile phone number, mailbox
• 5 、.....

You need to create a data file for each function point that involves data. If the system has 50 such a function! You need to create 50 data files. When you need to maintain the use case, you need to take two steps, the first step to find the use case code, and then, according to the name of the corresponding data file to add or delete a use case, and then cut to use case code to make it run through ...

……@data(["", "123", "请输入帐号"],      ["user", "", "请输入密码"],      ["error", "error", "帐号或密码错误"],      ["admin", "admin123456", "admin你好"],)def test_login_2(self, username, password, assert_text):    self.user_login(username, password)    if username == "admin":        sleep(2)        tips = self.driver.find_element_by_id("user").text        self.assertEqual(tips, assert_text)    else:        tips = self.driver.find_element_by_id("tips").text        self.assertEqual(tips, assert_text)……

Why not bind data and use cases together, so whether it's an example or a change of data is a straightforward matter.

>  你可能会站出来说，可是用数据文件管理数据，不懂代码也可以写做自动化用例，你连代码都不想看懂的人还想做自动化测试？梁静茹给你的“勇气”？>   你又接着说，如果有一万条数据，不能都把这些数据写代码里对吧！可拉倒吧，一万条数据确定是功能功能转过来的自动化用例？能举例出你所测试的哪个功能是需要手功执行一万条数据的么？不能！就别YY这种需求了。你怕不是和性能测试数据搞混了吧！？>  你又说，如果一条数据很长呢？比如测试文本框的最大字符限制（500或20000），这500个字都写代码里肯定不优雅。好吧！你能举的也就这么个例子了。其实，500字放到数据文件里也优化不到哪儿去。为何不写个for循环生成500个字呢？20000个也是秒秒钟的事呀！

This article is written with some personal emotions in it, because I see those who come up to teach the test novice to read the Excel file, even the use cases are written to Excel file behavior is not agreed.

This thing, do you have QTP professional? QTP's share is not slipping. The open source robot framework has been packaged so well that after that tuyere, it's not tepid yet. Because the business scenario is complex and changeable, front-end development technology updates, will also be forced to reverse the evolution of automation technology. Otherwise, functional testers have been replaced by automated tests.

In order to do a good job of automation, and honest training of their own programming technology, from the design pattern, code architecture, methods to encapsulate several aspects of your Automation test project to do enough flexibility and maintainability.

Do not follow the same day, see other testers casually encapsulated the so-called "test Framework", you are curious to learn two, write two demo, and then lost one side.

Shouldn't you dive into your own testing business, what's good for UI, what's good for interfaces, what's good for writing scripts, or making a system to improve testing efficiency.

The previous article some people said that I as a public number should not be "despise" such unkind words, that here to declare a, bug master all articles only represent his personal views, you do not agree to spray him, and "Test Circle TC" The public number is irrelevant.