在我们已经了解到的大多数的企业用户对软件测试自动化的需求之后，再来看看他们又是如何对软件测试自动化的方案进行选型的：
选择尽可能少的自动化产品覆盖尽可能多的平台，以降低产品投资和团队的学习成本
测试流程管理自动化通常被优先考虑，以满足为企业测试团队提供流程管理支持的需求
在投资有限的情况下，性能测试自动化产品将优先于功能测试自动化被考虑
在考虑产品性价比的同时，产品的支持服务和售后服务的完善性也备受关注
趋向于选择主流产品，以便于通过行业间交流甚至网络等方式获得更为广泛的经验和支持
对测试自动化方案的可扩展性提出要求，以满足企业不断发展的技术和业务需求
下面是一个典型的企业客户实现其软件测试自动化的案例。
公司背景介绍
A公司是一家大型保险公司，拥有近20个城市的分公司，并在其中5个城市建立了IT支持中心。这些IT中心负责所有内部应用系统的开发和运维，同时负责管理IT集成商和第三方应用供应商。平均每年的上线应用数量在20个左右（新业务系统和原有业务系统的主要版本发布）。其开发团队主要分布在2个城市，大约有300名左右，同时20％左右的项目是通过项目开发外包，或直接从第三方采购获得。目前A公司的专职测试团队人数不足30人，而且测试团队的测试人员技能参差不齐，目前测试只是作为项目上线前的一道工序而已。在测试团队内部也几乎没有自动化的手段，主要依靠手工测试；但在和研发部门的沟通等方面，都有明确的邮件往来规范和例会等既定的管理方式。由于已上线应用系统的问题，开发团队必须分出一部分资源去维护和修复上线应用，而同时测试团队的的测试成果和效率却无法和这些应用质量挂钩，也更无从谈起对软件质量的控制。A公司已经决定在软件质量和测试方面进行投入，他们考虑：
1.引进软件测试流程管理的自动化，提高软件测试过程的管理水平，使软件测试和软件开发一样可被评估，被衡量。
2．实现性能测试自动化，所有应用上线之前必须有应用性能风险评估报告和相关部门的确认
3．逐步实现功能测试的自动化，在目前人员配置的情况下，把部分手工测试变成自动化测试，提高测试可信度，降低人为错误。
4． 通过软件测试自动化，管理软件测试中的案例，缺陷，报告等资产，进一步提升软件测试的效率并建立测试基础库。
5． 在规划中，将来的2－3年内使所有的应用系统上线都必须有数字化的测试数据作为依据。
公司应用系统的情况
由于保险公司的业务种类繁多，同时在经过了几十年的经营后，公司内的应用系统从早期的终端方式到现代的J2EE和.NET等应有尽有，龙蛇混杂。IT部门已经建立的3年规划，即在未来的3年时间内将所有终端和C/S方式的应用转换成B/S架构，但当前仍然需要对这些旧应用系统进行维护，以保证业务的顺利进行。对于开发部门来说，目前新应用开发基本上已经以B/S架构为主，主要是基于J2EE架构的Web HTTP应用和部分Window .NET Form的应用。
公司软件测试现状
测试部门目前仅负责系统测试和对用户验证测试进行管理，对于之前的单元测试和集成测试主要由开发团队中划分出的一部分临时测试人员完成。由于缺乏监测手段，测试部门也无法收集和确定集成测试和单元测试的完成情况，在整个软件测试过程中，业务需求是由开发部门通过Rational RequisitePro进行管理，但测试需求目前尚没有提出要求，测试案例主要通过在公司公用的文件服务器中的目录管理方式管理，对测试中缺陷流程等管理主要依靠邮件的流转进行处理。目前90％以上的测试是通过Excel和Word等测试案例文档来完成，测试人员对软件测试自动化的认识仅停留在“记录＋回放”的认识上。
A公司最终采用的软件测试自动化方案
通过多方多轮的评估和论证，以及经过各个厂商的现场演示，甚至包括为期1周左右的实际试用，A公司最终采用了一个以全球业务优化科技（BTO）领导者美科利（Mercury）公司产品为主的软件测试自动化方案，在这个软件测试自动化方案中同时考虑了集成A公司现有的资源和流程，尽量降低解决方案导入的初期门槛，同时根据要求在实施过程中也并非一步到位，而是通过制定的详细的实施计划，分步骤展开实施：
文章来源于领测软件测试网 https://www.ltesting.net/
