聊聊自动化测试有效性(2)

　　我们可以期望用自动化测试来暴露所有的问题供使用者抉择，而非用来精确定位每一个问题。即便我们不期望自动化测试发现所有的BUG，但是我们必须要用发现每一个BUG的标准去分析设计和利用我们的自动化测试用例。

　　方法之一：善用手动测试用例库

　　如果有完整或近乎完整的手动测试用例库，在做自动化测试的时候用它来甄别自动化测试范围、做自动化测试需求分析和设计是非常棒的，可达事半功倍之效。因为除了SLA签订的关键功能清单，我们可以分析测试用例库中最近X 个月、Y个版本中被执行的测试用例的频率和比例等等数字，从而很容易得出最有价值做自动化测试的范围，而如有其他因素也可以加入综合评估。这时候，关联或映射手动测试用例和自动化测试脚本可以很容易地衡量自动化测试的覆盖率等相关指标。

　　除此之外，手动测试用例之于自动化测试开发的意义还在于一种特定模式下的自动化测试开发：测试人员按照一种特定的规约编写产品或项目的手动测试用例，随后用一种模型化的转换规则去生成自动化测试脚本，继而再去修改和优化。这种模式的好处是，自动化测试脚本的开发者不需要懂业务知识，只需要按照业务测试人员编写的详尽的测试用例去实施。而不足之处却也十分明显，由于思维方式上的差异，编写测试脚本过程中的沟通成本不会太低，而且对建模水平要求很高。

　　方法之二：搭建适应性强的框架

　　开源测试工具，我们组先后用过Selenium RC、WebDriver、WatiJ这几种工具模式，框架采用JUnit和TestNG，测试调度和CI使用Jenkins管理。做起来最大的感受就是，像WebDriver这种工具，它本质上是为互联网而生;如果要用于我们的企业ERP应用的自动化测试，如果没有做一系列适应性的API和组件封装，测试脚本开发对于大部分同事来说都是件头疼的事情。

　　经过摸索，我们结合PAFA(PingAn Foundation Architecture)架构的前端页面特征做了对象识别、页面加载和处理缓冲、运行监听、数据处理、断言和运行容错、报告、日志以及第三方组件(如 Autoit、Cmd等)兼容的封装操作。这种封装属于Bot-Style，适用于我们基于业务操作驱动的自动化测试用例编写，能够大大地降低我们测试脚本开发的技术成本。虽然它们看起来运行起来效率并不是十分高，但是对于被测应用的响应速度来说已经是数十倍的效率胜出了。至于使用Page Object还是Bot-Style，还请大师们不要吐我的槽，这没什么可争论的，因为这只是面向前端业务操作的页面测试，二者的表现毫无优劣之分，完全在于队员的测试脚本编写风格偏好。

　　附图1：测试中的TestCase样例

　　附图2：测试中的TestApi样例

　　我们正在从瀑布开发模式下逐渐开展持续集成和敏捷转型，不难预见，达到一定成熟度之后我们大部分团队会使用ATDD模式。这种快速开发的基于前端的自动化验证测试虽然在验证测试中所占的比例会越来越小，但它们将依然有用武之地，同时对当下的系统前端的回归测试也可以完全支持。

　　自动化测试框架强大与否主要在于其适应性，所以与其说自动化测试框架是选择出来的，不如说它是被改造出来的。产品比较单一的小公司或者开发框架比较成熟的公司用一个工具、一个框架在一个测试平台下就可以解决一个公司的自动化测试实施的绝大多数问题，而大型企业的应用繁多复杂，很难由一个简单工具或者框架来解决。

　　自动化测试框架，没有自己DIY过的永远都不要相信不造轮子这种说法，因为只有在你做的时候，你才能够更深入地理解你的工具、框架和你的被测应用及其所依赖的开发框架的特征，才会产出更具适应性的测试框架和特征库。

　　方法之三：善用设计与重构

　　无论是前端自动化测试还是单元测试，脚本代码结构的重要性是个老生长谈，因为这关乎测试脚本代码的可读性、维护经济性等问题。由于我们的业务系统的测试案例主要是基于操作流程的业务场景，所以我简单说一下我们在这方面的做法与经验，而单个功能点特性的测试分析也基本与此类同，不再独占篇幅。

　　测试范围与设计

　　大型企业，尤其是金融行业的ERP应用，很多系统实际上都是规则零散、流程复杂，规则引擎应用得并不是很充分。这便是前文所提及的自动化测试分析设计时对输入条件分支和状态机组合的穷举和选择困难的问题的产生原因了。对于这种情况，我们可以借鉴两个基础的测试设计方法：正交覆盖和Pairwise/All-Pairs，其基本原理和用法这里不再赘述。

原文转自：http://www.ltesting.net