软件测试自动化之路(8)----如何做更好的GUI Automation Testing

1)为什么我们需要UI自动化测试?UI自动化测试的focus应该在哪几个方面?

      测试自动化并不是为了赢得老板的赞赏，或者认为这是一个很潮的技术，不用就会落后，而是为了发现问题，提高产品的质量。做UI自动化测试的主要目的也是基于此的。 除此之外，UI自动化测试还可以从一个最终用户(end user)的角度来发现问题，对大数有UI的系统来说，UI是最理想的集成/系统测试入口，也是最需要测试的地方。 

UI自动化测试应该集中在:

1. UI的文本，图片显示正确性
2. UI的交互逻辑正确性测试
3. UI上的用户行为正确性测试
4. 如果可能，UI的用户体验性测试（这个通常并不适合）

2)什么是GUI自动化测试的难点? 

对比手工UI测试,UI自动化测试有如下的难点:

1. 从UI测试的角度来说，一个非“预期”产生的缺陷很难被自动化测试发现，而手工测试则能轻松的发现这个缺陷;
2. UI本身的变化性，要想达到和手工测试相同的覆盖率，单纯的UI自动化测试往往很难证明自己的投资回报;
3. UI控件元素本身识别的复杂性;
4. UI自动化测试出现问题时，恢复到下一条测试case执行的场景是复杂的。因为出现这种问题的意外，是非“预期”的;
5. UI的测试case，有很多是关于用户交互方面的，而这方面也其一定的复杂性;

 

3)如何做出更好的UI自动化测试？

 

1.  要尽量避免UI自动化测试。这点似乎与我们的初衷有点背道而驰。但细想一下，它还是有一定道理的。其原因是API和功能层级来说更加稳定，所以其自动化和维护的成本都比较低。相比而言，UI自动化测试因为有上述的诸多难点，所以其实施起来比较困难，导致它的开发成本和维护成本都要高出许多。因此，有的公司的自动化测试就有一个721原则，即70%的测试工作集中在底层接口测试和单元测试，20%的测试工作为集成测试，其他10%的测试即为界面测试。
2. 对于UI本身的变化性和UI控件识别的复杂性，利用ID/Name定位元素设定UI Map，与开发团队约定元素的命名规则,在尽可能的情况下，确保UI的可自动化测试性。当业务发生变更时，一个好的模式或者框架来让测试自动化更加便捷，包括要对业务进行分层，关注数据存储和数据驱动，做到测试数据与测试代码的隔离，UI自动化操作与业务测试逻辑的分离。 
3. 对UI自动化出现问题时，不能很好的恢复到下一条case的正确执行场景（我们可以称之为恢复测试场景或batch run）,可以通过组织良好的case，我们写Case的时候倾向于Case之间是没有关联的。我们希望一个Case在执行的时候，它自己能够将初始化和结尾的工作先做好，A Case和B Case不应该有关系，B Case的成功与失败不应该依赖于A Case的成功与失败，一个好的Case应该这样设计。但是有时候A Case做完，我们需要先添加一个用户，然后再删除这个用户，这种情况下，如果没添加就去删除，则是失败的，两者之间存在一种依赖关系。在这种设计的情况下，有一个解决的思路是支持Case间的依赖，你可以定义一个标签去说明某个Case依赖于其他的Case，这样就先执行被依赖的Case，然后再执行这个Case，确保了执行的顺序。