Today can be said to be a special day, in the morning to participate in the group testing small partners to make their own presence a lot of feelings, but also to get a ppt a few days after sharing with them. Helpless ~ ~ ~ talk about those things.
Recall just graduated from their own mengmengdongdong, the leadership asked whether performance, will not be automated, I immediately answer is certainly: will! In the end, whether good or bad are all done, but in retrospect to see what they did when they did not appear to take the shot. Empathy in today's debriefing also met a lot of small partners have said this kind of thing let me feel Alexander, but in my heart think still several Daniel didn't come or today this will hang. Meet the basic as follows: A small partner who worked for nearly two years to say what I have done in the past few months what harvest, what I did when I said to the XXX system performance testing, after reviewing the data to evaluate the system is qualified. The XXX function module is tested automatically, and the workload is reduced after each iteration update. So I showed him part of the performance report, automation scripts, etc., after the lead to make comments, which I do not know where to start, in another colleague's encouragement to say a little bit. After the end of the b\c ... Nearly 10 small partners, but in the whole process have a lot of the same problem, this is actually the same as the original, the school recruit a little pit!
Just a few things, automated testing (whether it is the Web or mobile) is not a lot of contact with a random software and then record the last change it is OK, you come out of the automation scripts are reusable? Does it increase the workload or reduce the workload? Do you just feel like you're doing something tall? In fact, these are useless deeds. People who have a certain understanding of automation know that the so-called automation is based on elements, and it is futile to automate in an unstable, iterative block of systems. If you say that you do not even function do not want to do the automation, if you do not even the function of the test hard to write well, then do not want to write a good automated test cases. A while ago and the small partners to share the time they were surprised to say: Automated testing also write test force? At that time I did not know how to answer, a blank face. Very early on, everyone said that the use case executable, others write the use cases you do not understand you will swear, then automated testing, you write automated test cases can not understand the people can't write scripts. In other words, when the computer can not understand the code we write then he will not curse just do not perform the error. So automated test cases are the basis of automated testing (assuming, of course, the stability of the system). For example, how to write a login test case? Small friends are: 1, in the user field input xxxx,2, enter xxxx,3 in the Password field, click the login button, login success. Many small partners are like this, in fact not. The relative standard use case should look like this:
1, open Firefox () Browser 2, in the Open Firefox () browser address bar Enter "Http://www.xxxxxx.com" 3, in the User column ID username Enter the correct user account: Xxxxxxx4, Enter the correct password in the password field with ID Password: xxxxxx5, click "Login" button with login ID 6, user login successful, jump to xxxxx page
Some children say this is too troublesome, in fact, this is not a standard, in fact, we still have a lot of things not written out. For example, should you add an assertion after 6th? Did you log in successfully? The page that jumps after login is not? Is the user information after login right? You have to think about this, and if there is a string of cookies, these are all necessary! The last little friends asked, "is that how we translate the use case into a script?" Surely the answer is no? Do you think such a script is useful? I don't think so! Because this script is not available, there is no maintainability. Why What if I want to change my account login? Constantly changing? What if the element ID is changed? Is this reusable? Share then the little friends angry, then this automation is useless and troublesome. The answer is no, but the way we do it is wrong. According to the translation just now.
From selenium import webdriver#1, open Firefox () Browser Dr = Webdriver. Firefox () #2, enter "http://www.xxxxxx.com" Dr.get (' http://www.xxxxx.cm ') in the Open Firefox () browser address bar #3, Enter the correct user account in the User field with ID Username: xxxxxxxdr.find_element_by_id ("username"). Send_keys ("xxxxxx") #4, Enter the correct password in the password field with ID Password: xxxxxxdr.find_element_by_id ("password"). Send_keys ("xxxxxx") #5, click the login button with ID login dr.find _element_by_id (' login '). Click () #6, the user logged in successfully, jump to xxxxx page assert "xxxx" in Dr.title # ' XXXX ' can also add other assertions in the title
I wrote the last one. The logon test script should look like this:
From selenium import webdriverimport unittestclass testlogin (unittest. TestCase): Login_url = ' http://www.xxxx.com ' dr = Nonedef setUp (self):p rint ' test start ' self.dr = Webdriver. Firefox () def tearDown (self): Self.dr.quit () def test_login (self): username = ' sssss ' password = ' xxxxx ' # You can call the outside self.dr.get (self. Login_url) Self.login (username,password) t = self.dr.find_element_by_id (' login ') #查找元素为login的东西 the self.asserttrue after login ( Username in t.text) #断言passdef login (self,user,pwd): #3, enter the correct user account in the user column with ID username: xxxxxxxself.dr.find_element_by_id ("username"). Send_keys (user) #4, enter the correct password in the password field with ID Password: xxxxxxself.dr.find_element_by_id ("password"). Send_keys ( PWD) #5, click "Login" button self.dr.find_element_by_id (' login ') with login ID. Click () if __name__ = = ' __main__ ': Unittest.main ()
The automated test case for a login is this (completion 95%).
Performance testing requires a lot of things to mention for the time being: developing languages (easy performance scripts), middleware knowledge, server knowledge, database knowledge, network Knowledge These are almost all needed. So this is not simple life, behind the simple said, sleep!
Talk about the things in the work, automation, performance, interface testing!
