你的位置：论文发表 >> 论文下载 >> 工学论文 >> 电子机械 >> 详细内容在线投稿

特性驱动下软件测试的敏捷实践

浏览80次时间：2022年2月28日 10:28

（210012　南京中兴软件有限责任公司　江苏　南京）

　　【摘　要】敏捷测试是通过正确地确立测试策略，对于质量指标进行不断的检测与修正，以保证客户的有效需求。本文针对系统软件测试过程中的开发与测试问题，引入敏捷流程思想，并将其应用到软件测试中。阐述了敏捷的概念与实践，探讨了系统软件测试技术的提升、测试工作方法的持续改进的相关问题，以期保证系统测试的质量，达到产品高效交付的目的。

　　【关键词】特性驱动；软件测试；敏捷开发；测试技术；交付0 引言

　　软件质量是由多个维度来进行评价的，每个维度都需要采用不同的测试方法，通过不同类型的测试手段达到不同目的，以寻求持续的改进，其最终目标都是要提高产品的质量。信息时代的技术手段层出不穷，产品的需求瞬息万变，交付周期成为企业的核心竞争力之一。轻量级、有序、迭代式的敏捷开发逐步被接受并得到迅速的推广 [1] 。敏捷测试在敏捷开发中占有重要的位置。有别于传统的测试方法，敏捷测试在测试人员角色、职责、流程、方法都有了全新的变化。

　　1.?敏捷测试与传统测试的区别

　　1.1 传统测试的弊端

　　传统的测试方法可以采用瀑布模型来描述，其含义是上一阶段的工作全部完成了以后，进入下一个阶段的工作，就像一个多层级的瀑布，逐级往下，层层流转，直到全部工作结束。每一步工作在转移都有配套的文档，说明全部工作的细节，并以此作为开发标准。

　　这种传统的瀑布模型过度强调了文档的作用，工作流程的线性过程太理想化。前提在于：用户必须能够清晰、完整的描述需求，并且需求必须是持续而稳定的。这种要求在现代软件开发过程中是很难做到的。另外各个阶段的划分完全固定，阶段之间产生大量的文档，增加了无效工作量，由于开发模型是线性的，用户只有等到整个过程的结束阶段才能见到开发成果，故障总在最后环节才被发现，这就显著增加了开发的风险。主要问题表现在以下5个方面。

　　（1）代码走查和集成测试依然是最主要的故障发现手段，这两种手段都需要付出较大的人力、时间、资源成本，且收效不可实时度量，只能在事后进行评估；

　　（2）因为缺乏完善的自动化回归测试，本该自动化完成的事情由手工操作，自动化测试程度低，覆盖不全，功能弱，部分测试受限于工具无法进行自动化回归测试。

　　（3）沟通不畅或误解容易引发缺陷，沟通效率低，过多依赖邮件、文档，缺少面对面沟通，沟通表达不清晰，表达方法不当，容易出现误解和误读。

　　（4）知识无法有效积累共享，文档分散管理，多份文档存在冗余内容，无法实时全部更新，文档完成后束之高阁，无人维护更新，调整维护格式费时费力，对文档输出质量缺乏关注、激励和引导。

　　（5）存在各种浪费，命令式任务安排，没有最大化人员潜力发挥，对创新缺少关注和激励，创造力被压制，能力和经验没有有效沉淀和共享，二次学习较多，团队和个人之见协同失步造成无为等待。

　　1.2敏捷的概念

　　敏捷就是软件开发领域的精益化，相比于传统瀑布式开发模式，包括敏捷测试在内的敏捷开发，其最大特点是高度迭代、周期性、及时而持续地响应客户需求 [2] 。敏捷测试就是对于质量指标进行不断的检测与修正，正确建立测试策略，保证客户的有效需求能得以圆满实现，以确保能够安全、及时地发布最终产品 [3] 。敏捷概念的内涵及表达见图1。

　　由图可见，框架中的最高层次是“思想理念”，包括了价值、团队和适应几个因素。在“理论概况”的层次，主要包括了“敏捷宣言”“敏捷的12条原则”以及敏捷的核心价值观，主要指“沟通、勇气、简单、反馈、尊重”等。“经典实践”层面的内容较为丰富，包含了客户故事、站会、CI、TDD、看板、结对编程、重构，以及Scrum等内容。最基础的层面是“实际应用”包括了不同的敏捷应用项目A、B、C等。

　　图1 敏捷的概念及其层次内容

　　2.?敏捷测试实践

　　敏捷测试不仅是指执行软件测试这一任务的本身，还包含了软件测试的过程和模式，更包括了保证团队交付的产品符合客户需要的质量。敏捷软件测试是遵循敏捷宣言的一种测试实践。

　　传统瀑布式开发测试模式对文档高度依赖，测试人员只根据原始需求制定测试内容，开发人员也是依据原始需求进行编码，开发与测试之间的交集就是需求文档。需求一旦确定，开发和测试的计划也大致固定。而在敏捷开发模式下，团队成员之间不再只是依赖文档，更多地是通过面对面的沟通，将需求拆分为一个一个的小故事，通过故事卡的形式展现任务内容，随时都有可能根据需要变更计划。

　　2.1 Scrum会议

　　实现敏捷模式的一个重要条件就是有效的沟通，包括团队内部的每日站会、计划会议、回顾会议，以及团队之间和与客户之间的计划会议、启动会议、验收会议和回顾会议等[4]。计划会议输出迭代任务列表和迭代计划，以及团队对达成目标的承诺，通过沟通让团队充分理解工作；每日站会是每天第一个开发活动，目的是分享进展，促进沟通，必要时调整工作计划，更新看板中的任务进度[5]。每次站会以短平快的方式来进行，每次不超过15分钟；回顾会议是迭代中最后一个开放活动，目的在于改进开放过程，通过讨论当前工作方法，流程优劣，提出改进措施，确定下一个迭代改进计划并落实改进。通过头脑风暴，收集建议，投票选择下一个迭代要处理的三条建议。

　　2.2 用户故事

　　用户故事（user story）是从用户的角度对系统的某个功能模块所作的简短描述，在一张小卡片上，记录下项目中的一个小功能及其完成之后将会产生的效果，或者能为客户创造的价值。还要标明这一功能的优先级和预期完成时间。其通用表达方式为：作为（某个角色），我可以（做什么），以完成（什么目的）。

　　2.3看板/状态墙

　　看板是一种典型的可视化管理，展示近期计划与进展，描述开发过程中用户故事的各个阶段以及团队状态。看板的内容包括：待开发、开发中、待测试、测试中、验收中、已验收等，一般分为开发区、风险区、状态图等几个板块。风险区主要展示可能出现的异常情况，并对未能正常开发的部分作出预警。状态图有燃尽图和燃起图。

　　2.4 思维导图

　　思维导图是表达发散性思维的图像思维工具，其特点为：直观、焦点集中、主干发散、层次分明。思维导图聚焦于关键字，将它们表示于并列的时空之中，以发散联想进行推进。发散越多，可能的方法越多，思路就越多，可方便相关人员快速掌握某功能的实现情况，快速开始编码，也可便于测试专家快速查看某个功能的配置，快速编写测试方案。

　　2.5特性移交表

　　贯穿于整个开发流程中的特性移交表是敏捷特性团队和系统测试团队的交接物，将他们连接起来的同时，划清不同团队的工作任务，避免重复劳动，减少浪费。通过记录测试用例在不同阶段的执行信息，完成测试工作的交接和回溯过程。最终直接导入自动化工具系统中，便于对整个版本的测试执行进行数据收集。

　　2.6自动化实现

　　自动化测试用例在不同阶段由不同岗位的人员编写，使用统一平台工具，并部署在同一个测试环境上，可采用讨论/提交规划好的表格、要求团队成员遵守、专人维护的方法来实施，避免出现数据冲突、不能复用、产生垃圾数据的情况。自动化测试用例归档到指定路径指定目录中，每个故事点在指定路径上建立指定目录。

　　2.7 构建知识累积和传递平台

　　敏捷测试是一种特性驱动下开发的测试活动，在不同阶段会有不同的文档产出。从一个项目初始启动开始，TL（Test Leader）编写系统测试方案，制定测试策略和通过准则。在迭代开发中，特性团队依据系统测试方案，输出特性测试规程、特性移交表、自动化用例，再传递到系统测试团队，在特性发布阶段输出新冠的报告和说明书。产品发布时，系统测试报告、性能测试报告、系统遗留问题、版本发布说明、特性说明书、工程指导说明书等一并打包。

　　3.?敏捷测试的项目管理活动

　　敏捷测试的项目管理活动过程如图2所示。活动的过程主要包括初始化项目、特性细化、故事开发、特性发布，以及产品发布等。其中，故事开发和特性发布需要经历反复迭代的过程。项目管理活动过程中的每一步都包含一些具体的内容，在图2的最右一列中都有说明。

　　项目管理活动（制定迭代、需求追踪、一致性等）初始化项目

　　细化特性

　　产品发布

　　·《系统测试方案》

　　-测试策略

　　-通过准则

　　故事开发

　　特性发布

　　·《系统测试方案》

　　·《特性测试规程》