4．可供选择的方案
方案A: A公司可以采用美科利（Mercury）公司产品为主的软件测试自动化方案。
● 依照原先的邮件流转过程配置TestDirector缺陷管理流程，为每个保险业务的开发小组和测试团队分配相应的用户许可证，取消原有邮件方式。
● 部署Mercury Quick Test Professional，以便完成应用程序相关功能测试。
● 部署Mercury Load-Runner。从测试团队中分化出专职的性能测试自动化工程师和小组，和业务部门协调，建立A公司应用系统上线性能指标，通过LoadRunner给出测试指标。
● 建议A公司成立专门的质量控制部门，对TestDirector中的数据定期进行分析，建立相关质量模型，以便于企业量化管理和过程改进。
方案B: A公司也可以采用IBM Rational产品为主的软件测试自动化方案。
● 采用Rational Test manager来进行整个测试流程的管理，为相关开发和测试小组成员分配相应权限，改变以前通过邮件以及Word、Excel文档管理测试的工作方式。
● 部署Rational Robot，用它来完成功能相关的测试工作以及新版本发布时的冒烟测试。此外，Rational Robot也能较好地完成性能相关测试。统一的操作方式降低了工具的学习周期和培训带来的大笔开销。
● 部署Rational Purify plus，使测试工作前移到开发阶段。由于Purify plus能较好地支持白盒测试，编程人员在编码阶段引入的错误能尽早被检测到，这大幅降低了后期测试的开销。
● 建议A公司成立专门的质量控制部门，对Test manager中的数据定期进行分析，建立相关质量模型，以便于企业量化管理和过程改进。
方案C: A公司也可以采用开源软件为主的软件测试自动化方案。
● 采用Bugzilla来进行Bug跟踪管理，采用Bugzilla Test Runner进行测试用例管理，采用CVS进行测试资源的配置管理。
● 采用MaxQ和WebInject对B/S结构的应用系统进行功能测试。
● 采用DBMonster、Open－STA、LoadSim进行性能相关测试。
● 可采用Xunit架构的开源工具对不同语言的程序单元进行单元测试。
● 建议A公司成立专门的开源软件维护小组，以解决可能会碰到的工具维护工作。
● 建议A公司成立专门的质量控制部门，对Bugzilla、Test Runner、CVS中的数据定期进行分析，建立相关质量模型，以便于企业量化管理和过程改进。
5． 方案评价
由于不同客户在组织架构、员工素质以及流程管理水平等方面的不同，我们很难用一个实例、一两句话来说明不同解决方案的适用性。在上面的例子中，笔者给出了3种可行的方案，具体选择哪一个，需要仔细权衡。这里笔者给出一般性的意见，对于不想受制于某个测试自动化厂家的企业，开源绝对是一个理想的选择。此外，它不需要支付成本，工具的源代码可以随意修改，因而具有较好的灵活性。但开源工具的弊端也是明显的: 缺乏使用培训和技术支持，工具的用户界面一般也较为粗糙。而对于那些比较看重培训和售后支持的企业，笔者建议选择IBM Rational或Mercury或其他厂家的产品。这样虽然需要支付一部分费用，但省去了工具维护所需要的大量工作。至于具体选择哪个厂家的产品为好，笔者尚无结论性意见。相信读者朋友都有一些见仁见智的看法，不妨来信交流。
实施中的注意事项
首先，一个企业实施测试自动化，绝对不是拍脑袋说干就能干好的，它不仅涉及测试工作本身流程上、组织结构上的调整与改进，甚至也包括需求、设计、开发、维护及配置管理等其他方面的配合。如果对这些必要的因素没有考虑周全的话，必然在实施过程中处处碰壁，既定的实施方案也无法开展。其次，尽管自动化测试可以降低人工测试的工作量，但并不能完全取代手工测试。100％的自动化测试只是一个理想目标，根据笔者的经验，即便一些如SAP、Oracle ERP等测试库规划十分完善的套件，其测试自动化率也不会超过70％。所以一味追求测试自动化只会给企业带来运作成本的急剧上升。再次，实施测试自动化需要企业有相对规模的投入，对企业运作来说，投入回报率将是决定是否实施软件测试自动化的最终指挥棒，笔者建议企业在决定实施软件测试自动化之前，必须要做量化的投资回报分析。此外，实施软件测试自动化并不意味着必须采购强大的自动化软件测试工具或自动化管理平台，毕竟软件质量的保证不是依靠产品或技术，更多的因素在于高素质的人员和合理有效的流程。
文章来源于领测软件测试网 https://www.ltesting.net/
