UI自动化需要知道的那些事儿

lsekfe

什么是自动化测试？

通过代码的方式，实现测试用例的自动运行，评估运行结果，并对测试结果及异常情况进行记录。

为什么进行自动化测试？

纯手工测试会有好多重复性的操作，浪费时间，而且频繁的回归测试，更是耗费时间和人力成本，不仅效率低，而且容易出错。

自动化测试与手工测试优缺点对比

手工测试：

优点：

1、不完全按照用例来测试，有时候在不经意间可能发现以前遗漏的点，能及时补充上；

2、有时候一些误操作，也可能发现隐藏的bug。

3、通过人眼也能发现实际页面跟UI设计图上的微小差异点。

缺点：

1、存在自己主观的因素，可能因为自己的认知错误，导致用例失败，或者bug未被发现。

2、回归测试和增删改查模块的测试，大多是重复性的操作，长时间进行重复性的工作容易造成厌烦心里，容易造成用例执行效率不高。

3、浪费时间及人力成本

自动化测试

优点：

1、不存在主观因素，完全按照设定的测试用例执行，测试结果是客观的

2、执行效率高，完全按照代码执行，不需人工干预，节约人力成本

3、准确记录测试结果，自动统计测试结果

缺点：

1、一些UI上微小的bug不容易测出来

2、执行用例的过程中，如果页面上报了错误，但是还能执行下去，这种bug发现不了。（比如说：新增地址的过程中，在某个输入框录入值得过程中，有个错误提示，但是保存能正常保存，这种bug使用自动化脚本不容易测出来，因为这条自动化用例验证的是能不能保存成功，保存成功了，代码就认为是用例成功了，不管在其过程中有什么异常情况）

什么样的项目或者模块适合进行自动化测试。

1、操作比较单一，重复性高的模块

比如：用户注册、用户登录、新增地址等这种增删改查的模块。这种的模块操作比较单一，结果验证也比较简单，自动化的代码重复利用率高。

举例说明：

比如说新增用户模块，我们只需判断那些数据能新增成功，那些数据不能新增，提示信息是什么，将其写在自动化测试用例中即可。

首先将新增用户这个操作，通过自动化代码写出来（部分代码仅供讲解）

1. def new_user_action(self,name,password,email,phone,address):
   
2.         self.find_Element(*self.name_loc).clear()
   
3.         self.find_Element(*self.name_loc).send_keys(name)
   
4. 
   
5.         self.find_Element(*self.password_loc).clear()
   
6.         self.find_Element(*self.password_loc).send_keys(password)
   
7. 
   
8.         self.find_Element(*self.email_loc).clear()
   
9.         self.find_Element(*self.email_loc).send_keys(email_loc)
   
10. 
    
11.         self.find_Element(*self.phone).clear()
    
12.         self.find_Element(*self.phone).send_keys(phone)
    
13. 
    
14.         self.find_Element(*self.address).clear()
    
15.         self.find_Element(*self.address).send_keys(address)
    
16. 
    
17.         self.find_Element(*self.save_loc).click()
    

复制代码

然后将测试用例落实到每个自动化测试用例中（部分代码仅供讲解）

1. class new_user_test(NewUserUnit.StartEnd):
   
2.     def test_new_user_pass1(self):
   
3.         """所有信息都填写正确"""
   
4.         po=NewUserPage(self.driver)
   
5.         po.new_user_action('test1','test1','test1@163.com','151XXXXXXXX','XX省XX市')
   
6.         self.assertEqual(po.NewUserPass(),'保存成功！')
   
7.         Function.snap_Shot(self.driver,'addSucess1.jpg')
   
8.         po.clickConfirm()
   
9.         sleep(2)
   
10. 
    
11.     def test_new_user_pass2(self):
    
12.         """所有信息都填写正确"""
    
13.         po=NewUserPage(self.driver)
    
14.         po.new_user_action('test2','test2','test2@163.com','152XXXXXXXX','XX省XX市')
    
15.         sleep(4)
    
16.         self.assertEqual(po.NewUserPass(),'保存成功！')
    
17.         Function.snap_Shot(self.driver,'addSuccess2.jpg')
    
18.         po.clickConfirm()
    
19.         sleep(2)
    
20. 
    
21.     def test_new_user_fail1(self):
    
22.         """用户名重复，不能添加"""
    
23.         po = NewUserPage(self.driver)
    
24.         po.new_user_action('test2','test3','test3@163.com','153XXXXXXXX','XX省XX市')
    
25.         sleep(4)
    
26.         self.assertEqual(po.duplicationVerify(), '用户名已存在!')
    
27.         Function.snap_Shot(self.driver, 'addfail1.jpg')
    
28.         po.clickConfirm()
    
29.         sleep(2)
    
30. 
    
31.     def test_new_user_fail1(self):
    
32.         """用户名为空，不能添加"""
    
33.         po = NewUserPage(self.driver)
    
34.         po.new_user_action('','test3','test3@163.com','153XXXXXXXX','XX省XX市')
    
35.         sleep(4)
    
36.         self.assertEqual(po.noneVerify(), '用户名不能为空!')
    
37.         Function.snap_Shot(self.driver, 'addfail1.jpg')
    
38.         po.clickConfirm()
    
39.         sleep(2)
    

复制代码

因为动作的重复性较高，只要修改测试用例即可，添加功能使用共同的代码即可。

1、回归测试

回归测试做的基本上是一些相同的操作，每次在版本更新之前，都要进行回归测试。这种类型的测试，进行自动化之后，每次版本更新都可以使用自动化脚本进行回归测试，代码利用率高，不需要反复和大量的修改，基本上就是一版代码可以多次使用，对提高工作效率很有帮助，又不需要花费大量的时间去维护代码。

2、页面上元素变化比较少的模块

UI自动化测试代码，定位页面按钮、输入框等的位置时，都是使用的元素定位，如果页面元素很少修改或者基本不改，这样就不必频繁修改页面元素定位，代码的维护成本很小。如果前台页面元素频繁修改，执行代码是就会找不到页面元素，导致用例失败，这种的要想用自动化测试，必须在修改页面元素时，同时修改自动化测试代码，才能正常执行。这样的模块，代码修改的频率太高，修改自动化代码也需要花费人力，代码维护成本太大，不建议使用自动化。

什么样的模块不建议使用自动化

业务流程比较复杂的模块

业务流程复杂的模块不适合使用自动化测试。因为业务流程复杂的模块，一般都是一个系统的核心模块，核心模块一般需求变动比较频繁，测试过程中出现的异常情况比较多，使用自动化脚本进行测试的过程中，如果出现的异常情况代码里没有做处理，有可能会影响后续用例的执行，这样还不如手工测试来的方便。

例如：按照订单类型使用优惠券页面。总额满足多少，可以使用类型1的优惠券，总额满多少可以使用类型2的优惠券，满足什么条件，可以使用组合优惠券。。。

这种需求，基本每个操作对应一个用例，每个用例也有不同的验证点，也就是说写一套使用优惠券的代码，只能用在一条用例上，而不能重复使用，这样写自动化的脚本意义就不大了。而且像这种涉及订单和价格的核心模块，需求变动可能比较频繁，在修改代码的过程中，一旦页面元素发生改变，就可能导致整个脚本的失败。代码维护成本较高，建议使用手工测试的方式。而且这种核心模块，如果使用手工测试，可能在测试的过程中，还会发现其他遗漏的测试点，使测试更加完整。如果使用自动化测试，只是按照测试用例来跑脚本，并不会完善测试用例。

与其他系统交互的模块

如果功能模块涉及与其他系统交互，其他系统又不想给你开接口对接这个东西，自动化代码就无法去其他系统验证结果（即使能，可能也需要耗费很多的人力和时间成本；当然不排除某些大牛能快速解决这些问题），这种的不建议使用自动化测试。