软件测试是软件工程的一个范畴，它作为软件工程的一部分，随着软件生产的产业化运作应运而生。从20世纪70年代开始，随着计算机技术的飞速发展，计算机软件在整个社会系统中的地位也越来越重要，而计算机软件开 发的规模和复杂度也随着其需求和重要度的增加而急速上升。在过去的20年里，对软件测试的最初认识只是“证明程序的正确性”，而后一系列的软件测试理论和方法被逐渐的提出，在1983年由IEEE提出了目前比较认可的软件测试定义，即：“为了检验某个应用系统的过程是否满足规定的需求，并了解预期结果和实际结果之间的差异，而使用手工和/或自动化手段来运行并验证这一过程”。按照这个定义，软件测试的目的是监测和排除缺陷，以确保软件产品在可用性，功能性，可操作性等多方面满足软件需求。

从上世纪90年开始，产业界开始意识到被动的以监测和发现错误为目的的软件测试无法避免软件开发过程中由于软件需求和设计等方面的缺陷所带来的巨大风险，所以在整个产业界开始从软件质量控制（SQC, Software Quality Control）开始转移到软件质量保证（SQA, Software Quality Assurance），从而使软件测试从单纯的缺陷检测和发现覆盖到整个软件开发过程，同时软件测试的流程和软件测试技术也成为了独立研究的方向。我们已经了解到一个典型的软件过程可以分为测试需求分析，测试设计，测试执行，缺陷和配置管理过程等许多个不同的阶段。在软件测试技术方面也已经被细化为单元测试，集成测试，系统测试，用户验收测试等不同的测试技术。

 

随软件测试技术的发展和测试流程管理的需求，实现软件测试自动化的趋势已经不可逆转了。目前，软件测试自动化主要集中在软件测试流程的管理自动化，和动态测试的自动化，如功能测试自动化和性能测试自动化方面，还有是少部分的静态测试，如代码走查，它们常常比较容易从开发过程剥离出来。

 

相比于手工测试，测试自动化的优势是明显的。首先自动化测试可以提高测试效率，使测试人员更加专注于新的测试模块的建立和开发，从而提高测试覆盖率；其次，自动化测试使测试资产的管理数字化，并使测试资产得以在整个测试生命周期内得到复用，这个特点在功能测试和回归测试中尤其具有意义；此外，通过测试流程的自动化管理使机构可以通过流程的关键绩效指标（KPI, Key Performance Indicator）来衡量测试过程的有效性，从而实现了从软件质量保证向软件质量管理（SQM, Software Quality Management）的进化。根据Oppenheimer Funds的调查，在2001年前后的3年中，全球范围内由于采用了测试自动化手段所实现的投资回报率（ROI, Return Of Investment）更高达1500％。

 

      那么，对于一个企业用户来说，什么样的软件测试自动化方案将是他们所最需要的呢？在回答这个问题之前，首先我们必须注意到，作为企业用户，在企业内部通常存在许多不同种类的应用平台，应用开发技术也不尽相同，甚至在一个应用中可能就跨越了多种平台；或由于开发时期的不同，可能导致同一应用的不同版本之间也存在技术差异。同时对于开发工作本身也可能多种形式，由内部团队开发或是开发外包等等。所以软件测试本身对于这些企业的QA和测试部门来说无疑是一个巨大的挑战，他们考虑选择软件测试自动化的最根本出发点就是为了降低这些挑战可能带来的软件产品质量和上线周期等方面的风险。根据笔者和不同企业用户的沟通和交流，他们的自动化需求往往更多的集中在：

n         自动化软件测试管理流程，以达到始终一致的软件质量和可量化的，可衡量的测试过程管理。

n         通过实现测试自动化，以提高测试案例的复用和实现内部标准化，从而提高测试效率。

      但同时，企业用户也将综合考虑测试自动化给当前的企业部门与部门间的合作以及现有的工作流程所带来的冲击，在软件测试自动化过程中也往往选择“进化”（Evolution）方式，而不是“革命”的(Revolution)方式。

     

企业在实现测试自动化过程中，一个有趣的现象是绝大多数的中国企业用户会选择在企业内部（In-House）实现测试自动化，他们希望参与这个自动化的过程，并且更加在乎自己来建立并管理这个自动化流程；他们不仅限于通过软件测试自动化来满足上述需求，而且希望通过自动化过程的实施也到达学习和提高团队测试技能的目的。与此相比，不在少数的欧美企业用户他们可能会选择测试自动化平台托管服务（Hosted Service），或者外包（OutSourcing），离岸（Off-Shore）和派遣（Staffing）等多种方式相结合来实现，对他们来说，更加注重的是软件测试自动化所带来的结果，而非自动化过程本身。

 

      在我们已经了解到的大多数的企业用户对软件测试自动化的需求之后，再来看看他们又是如何对软件测试自动化的方案进行选型的：

n         选择尽可能少的自动化产品覆盖尽可能多的平台，以降低产品投资和团队的学习成本

n         测试流程管理自动化通常被优先考虑，以满足为企业测试团队提供流程管理支持的需求

n         在投资有限的情况下，性能测试自动化产品将优先于功能测试自动化被考虑

n         在考虑产品性价比的同时，产品的支持服务和售后服务的完善性也备受关注

n         趋向于选择主流产品，以便于通过行业间交流甚至网络等方式获得更为广泛的经验和支持

n         对测试自动化方案的可扩展性提出要求，以满足企业不断发展的技术和业务需求

     

下面是一个典型的企业客户实现其软件测试自动化的案例。

 

      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等测试案例文档来完成，测试人员对软件测试自动化的认识仅停留在“记录＋回放”的认识上。

     

通过多方多轮的评估和论证，以及经过各个厂商的现场演示，甚至包括为期1周左右的实际试用，A公司最终采用了一个以全球业务优化科技（BTO）领导者美科利（Mercury）公司产品为主的软件测试自动化方案，在这个软件测试自动化方案中同时考虑了集成A公司现有的资源和流程，尽量降低解决方案导入的初期门槛，同时根据要求在实施过程中也并非一步到位，而是通过制定的详细的实施计划，分步骤展开实施：

初期实施阶段：

1．              部署Mercury Quality Center服务器。依照原先的邮件流转过程配置其TestDirector的缺陷管理流程，为每个保险业务的开发小组和测试团队分配相应的用户许可证，首先要求所有正在测试和将要进行测试的项目都必须通过这一缺陷管理流程进行缺陷递交和处理，原有邮件方式取消。并安排和培训一名测试管理工程师负责接受测试流程的改进意见和负责流程优化工作，以逐步完善流程管理自动化。

2．              部署Mercury QuickTest Professional。选择Mercury QTP而非WinRunner和其它产品的考虑主要出于它对新应用平台的广泛支持性，和用户的易学易用性，可以使测试团队比较快的上手使用，并随着为当前的项目建立和运行最初的自动化测试，获得软件测试自动化尝试的信心。但目前对美科利（Mercury）建议的Business Process Testing不作考虑。

中期实施阶段：

1．              通过Mercury集成Rational的需求管理工具RequisitePro，以实现测试需求的管理。并利用现有的Mercury Quality Center平台引入测试案例管理流程，把所有基于Word和Excel的旧有案例，利用美科利（Mercury）提供的转换工具导入到TestDirector中去，从而建立可被参考和追踪的测试案例库。同时由测试部门协调整个执行过程，对测试环境，测试数据，被测系统（SED）的调配实现统一管理，避免可能存在的各部门竞争测试资源的状况。

2．              部署Mercury LoadRunner。从测试团队中分化出专职的性能测试自动化工程师和小组。和业务部门协调，建立A公司应用系统上线性能指标。值得注意的是由于A公司的应用系统的地域分布性，在通过公司内网远程执行LoadRunner测试案例时受到现有网络带宽的限制，很难达到测试成果。尽管美科利（Mercury）公司建议A公司引进美科利（Mercury）的Performance Center平台以实现整合和远程操控，由于公司预算和目前对性能测试的技能尚不足以建立整合平台，A公司最终没有采纳。最后，由于性能测试通常是在业务应用经过了一轮的系统测试以后进行的，A公司决定把性能测试实验室环境集中在一处，并不需要做性能测试的应用发布到该实验室进行统一测试。

3．              对已经开始的功能测试自动化进行优化，从测试小组中筛选出自动化测试专家，负责A公司自动化测试库的建立，进一步提升软件测试自动化的价值。

长期实施阶段：

1．              由于自动化测试管理的进行，测试缺陷和测试案例已被大量收集，过程也正在逐步优化。A公司考虑在Quality Center平台上考虑实现“软件质量门户”的思想，即和公司应用软件质量相关的信息都通过这个平台来得到，相关的流程都可以通过这个平台来实现。其中包括了作为一个质量门户必须提供的针对软件质量管理和软件测试过程中不同人员角色所定义的视图，衡量软件质量和测试流程效率的关键绩效指标（KPI），除测试过程管理以外的服务支持管理（如变更管理，配置管理，发布管理）等。

2．              考虑整合A公司的测试团队和其它分布的非全职测试人员，整合各个团队的测试经验和资源，建立独立的软件质量管理和测试中心。

 

由于不同客户在组织架构，员工素质以及流程管理水平等方面的不同，我们很难用一个实例来说明它的普遍适用性。然而大多数客户完全独立于厂商，独立于技术的软件测试自动化的需求和希望通过软件测试自动化来达到的目的却往往是具有共性的，而这种共性所提供给其它企业客户的借鉴不是他们采用了那个平台，利用了何种技术，而是实现软件测试自动化的过程本身，以及在这个过程中所体现的具有普遍适应性的软件质量管理和软件测试的最佳实践。

 

既然我们谈到了软件质量管理和软件测试最佳实践，很显然这些最佳实践本身并不依附于软件测试自动化的，它更多是来自于比如ITIL（IT Infrastructure Library）框架，或来自于一些标准化，如CMM/CMMi中的关于SQA的KPA（Key Performance Area）。所以，我们说软件测试自动化是一个必然趋势，但对企业来说，它并不意味着是必须马上启动的项目，或者甚至所有企业都必须跟随的唯一道路。

 

首先，一个企业实施测试自动化，绝对不是拍脑袋说干就能干好的，它不仅涉及测试工作本身流程上、组织结构上的调整与改进，甚至也包括需求、设计、开发、维护及配置管理等其他方面的配合。如果对这些必要的因素没有考虑周全的化，必然在实施过程中会处处碰壁，既定的实施方案也无法开展。其次，尽管自动化测试可以降低人工测试的工作量，但并不能完全取代手工测试。100％的自动化测试只是一个理想目标，根据笔者的经验即便一些如SAP, Oracle ERP等测试库规划十分完善的套件，其测试自动化率也不会超过70％。所以一味追求测试自动化只会给企业带来运作成本的急剧上升。再次，比较测试自动化需要企业有相对规模的投入，对企业运作来说，投入回报率将是决定是否实施软件测试自动化的最终指挥棒，笔者建议企业在决定实施软件测试自动化之前，必须要求量化的投资回报分析。此外，软件测试自动化并不就是采购强大的自动化软件测试工具或自动化管理平台，毕竟软件质量的保证不是依靠产品或技术（Technology），而且更多的因素在与高素质的人员（People）和合理有效的流程（Process）。