第三阶段：软件流程框架

　　这个阶段可以说是软件自动化测试炉火纯青的时候了，达到了”天人和一”，经过多年修炼，在这里软件自动化测试和软件开发再次做一个整合，从自动化流程上， 能够达到真正的测试驱动开发，比如coding与unit testing做整合。目前已经达到这个阶段的有微软，IBM等。

　　目前国内软件公司软件自动化测试的实施情况大多处于第一阶段或从第一向第二过渡的阶段。所以我在下面着重谈谈软件自动化测试框架的设计原则和一些风险的规避：

　　1.框架要集中精力解决自动化测试中的问题

　　看起来这是个很简单明了的原则，不是么？自动化测试框架本质是一个软件产品，它旨在满足自动化测试中的必然需求，而不是大包大揽软件工程中所有的问题。我在某个测试网站曾看过一个测试框架的设计原型，真叫人叹为观止，从脚本代码的版本同步管理到bug的提交和存储，都通通塞入框架解决方案之中，包罗万象，无所不能。我虽猜不中这框架的开始，但我能猜到这框架的结局，无非两种情形，要么技术资源不够而流产，要么实施起来太过复杂，自动化成本大大高于产出，总之结局一个字：死。

　　一个经验丰富的自动化测试架构师应该既能够敏锐捕捉到当前自动化测试中的关键问题，又能巧妙利用现有企业资源为我所用，在上面的例子中，可以把脚本版本管理工作交给企业中已有的源码管理系统，比如clearcase，Vss，把bug的存储交给bug管理系统，而框架集中精力解决自动化测试中的无人值守运行，报告生成等问题，总之在框架设计的初期阶段，一个明确切实的实施目标是十分重要的。

　　以AC为例，紧紧以QTP自动化测试为中心，全力解决最实际最关键的问题：

　　1.自动化测试案例的管理

　　a）基于xml的测试组件的定义

　　b）基于xml的被测实例管理

　　2.无人值守的案例执行

　　a）案例关联关系校验，大大缩减自动化测试执行时间

　　b）Case级别Transaction的定义及实现，提供transaction的re-run和超时设定机制，从而减少因测试环境不稳定引起的失败

　　c）Recovery自定义机制，大大提高脚本的健壮性

　　3.基于xml的测试报告和测试日志

　　a）Xml标准，极强的扩展性，提供标准接口，用户可二次开发与手工测试报告进行合并，或直接写入数据库。

　　b）灵活的抓图机制，所有抓图最后生成一个网页，作为测试报告的一部分提交。

　　2. 框架设计中的扩展考虑

　　毫无疑问，自动化测试框架是一个软件，在设计时同样遵循软件设计原则：模块的高内聚和低耦合，这些都是基本原则，不再赘述。需要注意的一点是由于框架作为企业环境的一部分，必然涉及与其他系统的多种接口，比如和case数据库连接实现自动化测试案例自动获取，和mail服务器连接实现邮件实时通知，和 bug数据库连接实现bug的自动提交，因此，在接口设计上要尽量保证扩展性和兼容性。

　　AC采用的数据接口为xml，这有两个显然的好处：

　　1.xml是数据存储的标准规范，可与其他系统保持非常强的兼容性

　　2.xml的utf-8可支持多种字符，不用担心乱码的问题

　　3.框架实现中的数据驱动思想

　　数据驱动在这里有两层意思，第一，框架实现上完全数据驱动，不能存在hard-code的问题，比如被测server信息，测试案例等信息以xml配置文件的形式放在框架外面，要换个server或运行另外一套测试案例，只需更改xml文件即可；第二，框架要提供规范和策略，使得脚本同样必须遵守数据驱动的原则。

　　AC提供excel数据全局加载机制，所有的数据都可以放在外部的excel里，AC会在case运行时加载数据，case则只需调用接口即可获得数据，数据驱动实现十分方便。

　　自动化测试与手工测试流程的整合：

　　我们的企业不是试验的学校，也不是花拳绣腿的作秀场，在企业里做事往往从务实和实际效益出发，以结果为导向，因此，“自动化测试”在我们看来，重点在“测试”，而“自动化”只是一种手段而已。我们更关心测试整体的效果，不是么？

　　下图是自动化测试与手工测试的整合流程，在此流程架构中，自动化测试以smoke test为中心，旨在保证产品版本的稳定性；手工测试以negative test为中心，意在验证产品的功能和健壮性。两种测试互为补充，相得益彰，大大提高了测试整体的效益。