王 倩，唐兰文，赵明芝

（中汽数据（天津）有限公司，天津 300180）

1.引言

随着现代化硬件与软件结合的高速发展，科技创新型人才不断涌现，社会对科学技术和方法的要求越来越高。尤其是软件业务行业，对于快速变化的用户需求，有技术性和方法性的高效率实现的开发与测试能力也越来越受欢迎。而大多软件公司，仍在普遍推行传统的开发测试流程。在瀑布模型下的一个项目周期短则三个月，长则两三年。现假设项目过于庞大，整个软件生命周期估算需要两三年，那项目风险与人力资源、时间成本的庞大可想而知。而且目前很多项目状况是因需求的频繁变更，且没有完善的测试流程来规定，开发和测试每天都在推翻自己前一天的劳动成果，这种现象无形地不断提升相关人员重复开发和重复测试这个项目模块的厌烦感和无力感，并快速降低了技术人员的成就感。传统的瀑布模型测试流程，主要特点便是灵活性差、测试耗时长，不适用于现今项目状况。为“拥抱变化”，增加项目灵活性，适应新的项目状况需求，推行采用快速迭代、循序渐进的方法进行敏捷测试开发测试势在必行。本文尝试对敏捷测试在软件项目中的研究与应用进行概述。

2.敏捷开发中的敏捷测试

传统的瀑布模型的测试流程是，业务从客户处不断地收集需求内容，提供至需求人员进行编写和细化，再将其产出需求文档发至开发和测试人员后，开发人员和测试人员基于此文档进行需求分析，并组织业务、开发、测试人员三方评审需求。需求评审通过后，开发人员基于定版的需求文档进行代码开发，同时测试人员开始编写测试用例。在测试执行启动之前，三方再次进行一次用例评审，测试人员在评审会上讲述自己编写的测试功能点，业务人员和开发人员一起检查并指出问题。用例评审通过后，才正式进入测试。测试人员接收开发人员提供的部署包，项目部署好后，测试人员进行冒烟测试和首轮测试，结束一轮后将测试结果一并发至开发进行代码修复，再次开启新一轮的测试，直至达到上线标准，测试人员产出测试结项报告，项目测试结束。与传统的瀑布模型测试模式不同，敏捷测试是“拥抱”敏捷开发。在这种模式下，测试与开发成为一个完整团体，测试随着开发而动，贯穿于项目生命周期，而且整个项目周期中开发与测试过程灵活可变。

3.敏捷测试在项目中的应用

3.1 敏捷测试的流程和方法

因为敏捷测试是把一个大项目分为若干个相互联系又可独立运行的小项目，并分别完成。所以敏捷测试流程其实是以瀑布模式流程为基础，在此增加改进而得。敏捷测试流程图如图1：

图 1 敏捷测试流程

3.1.1 项目立项

项目立项过程包括项目建设单位向上级主管部门提交项目建议书，然后投入前对项目进行可行性研究，之后对项目进行评估与论证，最后项目招标与投标，投标人与招标人签订合同。

3.1.2 阶段需求分析

对接客户的业务方通过各种渠道收集到用户需求后，快速整理并向项目成员发布。业务、开发、测试三方召开需求评审会对需求文档进行分析，探讨功能实现的可行性与是否足够细致作为测试依据。

3.1.3 编写/修订迭代测试计划

通过三方需求评审后，测试部门要编写/修订迭代测试计划，具体内容包括各模块的计划开始时间、计划结束时间、对应测试工程师、预计人天等。随后测试人员将完善的计划发给业务方查看，审核无误，便可实行。

3.1.4 编写/修订测试用例

测试部发送至业务方测试计划审核通过后，便可正式进入测试流程。测试工程师基于定版的需求文档编写测试用例。测试用例主要包括三内容：用例标题、步骤和预期。

3.1.5 三方用例评审

测试人员组织业务、开发进行三方用例评审，评审会上测试人员讲述自己每条用例对应的需求功能点。业务和开发检查是否有功能遗漏和步骤预期正确性。如有问题，测试人员将有问题的用例在会后及时修改，并再次发送至业务方审核。多次确认无误后，测试用例存档。

3.1.6 执行测试

此处的执行测试，便是瀑布模型与迭代模型的主要差异所在。一种情况是，开发人员将这一阶段的开发版本提交给测试部进行测试，即可进行下一阶段的开发，测试人员在测试过程中若遇到核心问题，及时联系开发解决，以便不会堵塞后面的功能测试，若是一般问题，测试人员将bug记录好，以便开发人员对该阶段的下一版本及时修改和提交。另一种情况是，开发人员并行工作，同时进行着下一阶段的开发与这一阶段的bug修复工作。这种情况的实现必须要开发人员和测试人员的高度配合。测试版本可能一天一次甚至一天内随时更新部署。尤其是为缩短频繁部署时间，开发人员使用Jenkins和Git实现自动化部署，每次部署最多仅需1分钟。最理想情况下，测试人员边提bug边得到修复，进度大大加快，缩短了项目周期。执行测试中最重要一点是每日站会。由测试人员负责主持，站会上开发人员要讲述自己前一天对哪些部分代码进行了改动，测试人员汇报测试进度，以便团队人员可以清楚项目情况，同时会上大家可以提出项目推进过程中遇到的问题，做到早反馈早解决。

3.2 敏捷测试中的自动化和接口应用

自动化最适合于软件开发中那些单调、重复的工作和需要持续集成、构建与部署的项目。敏捷测试中的“一次构建、多次部署”便可用自动化来实现。比如环境部署可以用项目版本管理工具GIT和持续集成工具Jenkins合作搭建，创建一个触发构建的项目后，后续代码如果有改动，只要push到github或者gitlab等上，在jenkins界面中再次执行构建任务就可以了，耗时最多1分钟。而瀑布模型下的测试，部署时可能会因开发人员提供的部署文档描述不清或测试人员对Tomcat甚至对Linux语句不熟等原因，要耗时1-2天。

测试有时会需要大批量建基础数据，而人为手动新增过于枯燥与大工程量，这里我们可使 用 Selenium IDE 录 制后生成脚本后实现自动化新增。比如下方语句，一个自动添加数据的简单案例，我们优选将录制后的脚本转化为Java脚本到Eclipse中运行。

其实Selenium IDE录制后转化的Java脚本不一定能跑通，所以需要手动修改代码。而且使用Selenium自动化要校验的地方太多，维护脚本成本高，碰到iframe框架也不好实现，而使用开源工具Jmeter接口实现新增，便大不相同了。比如我曾测过的一个情况，页面中没有新增、编辑按钮，所以每次添加数据都需要联系开发人员后台处理，为避免麻烦，我们可使用Jmeter实现新增。从开发人员处获取到此页面的接口后，在Jmeter的Dody Data中输入以下语句：

用Jmeter灌入数据，还要注意某些字段要求的必填、唯一性校验，否则点击Start后运行结果会显示程序异常等失败报错。这里建议测试人员在实际项目中根据自身能力和习惯来选择用哪一种工具实现自动化。

3.3 敏捷测试在项目中应用感想

经过敏捷测试在企业软件项目中的实践验证，迭代测试团队专业素养的基本三要素：一是团队成员的责任心要强。俗话说，众人拾材火焰高。一个项目的最基本的展示来自UI设计工程师、后端工程师、数据库工程师、接口工程师和前端工程师合作产出。如果团队内员工懈怠，团队懒散，乱推责任，即使团队内的员工都是技术大牛，整合出的项目质量也会差强人意。二是团队人员稳定，避免流动性。迭代项目都是分模块开发和提测，彼此模块之间有衔接，而且不停地变更和完善，业务人员有可能未来得及完善文档，往往项目很多细节处，其实只有长期稳定在这项目中的人才能发现，所以迭代必须保证长期跟进参与的开发与测试存在。三是团队合作默契度要高。迭代测试的迭代周期普遍很短，有可能测试几天便上线，所以无法避免一天部署多个版本，提交的bug以小时为单位迅速解决并回归，基本上测试人员当天提bug，开发人员当天标记已解决，又当天便回归了，这个无缝衔接的合作需要随时分配bug的项目管理人调配和迅速修改bug的开发人员以及回归的测试人员的高度配合。

4.结语

经实践证明，与传统的测试模型相比，敏捷测试能更早地发现并清除软件bug，在保证了软件产品质量的同时很大程度上提高了软件产品的生产效率。如今，“敏捷测试”的概念开始加热。对于软件测试人员，如果想要转型，要以成为敏捷测试领域的先行者和实践者为目标，必须找到自身定位，加强内部学习，掌握测试的基础和理论，再谈其他。而对于企业，彼此之间竞争激烈，交付项目时若不满足客户要求，便很难获取同一客户公司下的第二次竞标，因此把握住每一次项目，把每次项目都当成机会，去争取去实现，也是每个参与人员该肩负的责任感。