基于GJB5000A的项目全生命周期软件测试实践与分析*

2017-01-16王诗琹

通信技术 2016年11期

关键词：测试人员开发人员软件测试

王诗琹,李彬,卢叶

（中国电子科技集团公司第三十研究所，四川成都 610041）

基于GJB5000A的项目全生命周期软件测试实践与分析*

王诗琹,李彬,卢叶

（中国电子科技集团公司第三十研究所，四川成都 610041）

软件测试作为检验软件产品质量最有效的方法，已成为软件工程领域中一个非常重要的研究热点。基于GJB5000A三级实施标准，分析软件开发和测试的关系，介绍项目全生命周期的软件测试步骤，提出满足GJB5000A三级标准的软件测试方法，旨在将测试工作与项目开发过程紧密结合，开发与测试工作交替进行，并贯穿于项目开发的全过程，为准备或正在实施GJB5000A三级的项目提供满足军用标准的测试指南。

软件测试；生命周期；质量；软件工程

0 引言

随着国防科学技术快速发展和高新武器装备跨越发展，装备的复杂程度日益增高。武器装备的功能结构和系统集成越来越复杂，技术难度越来越大，质量特性内涵越来越丰富。自2010年11月1日起，由国务院﹑中央军委颁布施行最新的《武器装备质量管理条例》（第582号），对装备质量和管理工作提出了更高的要求。因此，需要运用更科学的质量管理方法和更先进的质量管理手段，提高武器装备质量水平。

然而，产品的质量是“设计”出来的。各军工装备承制单位主要依据军用软件研制能力成熟度模型（Capability Maturity Model for Military Software Development-GJB5000A）来控制和加强软件产品质量。软件测试作为保证产品质量的主要手段，在软件工程化实施过程中尤为重要。

软件测试涉及到项目研制生产的各个阶段。项目成员由于分工不同，对测试的侧重点有所不同。开发人员需重点掌握需求分析阶段﹑软件设计阶段﹑软件实现阶段的测试方法；测试人员需重点掌握单元测试阶段﹑组装测试阶段的测试方法；售后服务人员需重点掌握系统集成阶段﹑用户试用阶段﹑售后维护阶段的测试方法。本文将打破传统的单线测试技术和方法，基于GJB5000A中对测试的相关要求及规定，结合项目全生命周期模型，对软件测试进行全面分析。

1 软件测试与开发过程的关系

传统的软件测试，可以简单描述为如图1所示。开发人员完成任务后，交付给测试人员。这种模式下，测试人员不能及早发现需求阶段的缺陷，且测试工作的开展也已滞后，无法实现对产品质量有效的过程控制和分析，总体进度也可能会由于返工问题而拖延。

图1 传统交付测试

全生命周期软件测试与开发活动的关系，如图2所示。

图2 全生命周期软件测试流程

如图2所示，整个软件生命周期（SDLC）可分为三条角色主线和四个阶段。三条角色主线分别为开发﹑QA﹑测试（文中主要讲解测试）；四个阶段分别为需求阶段﹑开发阶段﹑发布阶段﹑日常运营。

对于产品而言，每次版本迭代都会经历需求﹑开发﹑发布三个阶段，最后推向日常运营。此外，发布阶段并不表示终止。如果发布阶段产生设计变更需求，则将回到需求阶段和开发阶段，完成更改后，再重新发布。这是一个不断迭代的过程。

测试人员贯穿于这四个阶段（每个阶段也有开发人员﹑QA人员对应的活动），主要开展的测试工作归纳如下。

（1）需求阶段

在确定软件开发可行的情况下，设计开发人员将详细分析软件需要实现的各个功能。需求阶段至关重要，将为整个软件开发项目的成功打下基础。同样，需求也是在整个软件开发过程中不断变化和深入的。因此，必须制定需求变更计划来应付这种变化，以保护整个项目的顺利进行。此阶段，测试人员需参与需求分析，挖掘用户描述得较含混的内容，参考经验库，对估算的开发时间提出质疑，而描述也会随着需求的变更变化。

（2）开发阶段

此阶段主要根据需求分析的结果，对整个软件系统进行设计，并将设计结果转换成计算机可运行的程序代码。在软件设计完成后，测试人员需进行严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。整个测试过程分单元测试﹑组装测试以及系统测试三个阶段。测试的方法主要有白盒测试和黑盒测试两种。此阶段，测试人员需提出详细的测试计划，并严格按照测试计划进行测试，以减少测试的随意性；需进行功能要点确认，判断是否满足需求阶段提出的指标；设计测试用例，并对用例进行评审；组织测试探索，发布燃尽图；总结开发缺陷，提出解决方案，并向缺陷经验库作出贡献；通过不断积累，提升开发自测质量；参与集成测试阶段的测试，持续反馈问题。

（3）发布阶段及日常运营

这两个阶段都属于用户使用阶段，是软件生命周期中变化不大但持续时间最长的两个阶段。在软件开发完成并投入使用后，由于用户试用后产生的问题反馈﹑实际使用环境变化等因素，需要对软件进行持续维护和修改。此时，售后服务人员将与测试人员配合。售后人员收集用户反馈的问题和提出的改进建议，测试人员据此编制测试报告﹑缺陷分析统计报告﹑版本问题反馈报告，并向开发人员提出改进建议。开发人员完成设计更改后，测试人员进行回归测试和确认，最后再次进行发布并投入运行。

2 全生命周期软件测试活动

2.1 需求阶段测试

在需求阶段，开发人员进行用户故事分析和评估时，QA人员保证并确认需求活动符合管理过程，管理用户故事评审和需求变更。测试人员的主要实践包括：参与用户故事分析，挖掘故事含混性。

在sprint会议上，对用户故事进行分析，检查功能性需求和非功能性需求是否描述清晰。其中，可以将非功能性需求作为验收要点，如一个用户故事——“客户希望提高响应时间”。测试人员应当协助开发人员消除故事的含混性“提高什么的响应时间和响应时间为多少”。因此，可以建议修改为“客户信息普通查询返回结果的响应时间为5 s内”，说明在“客户信息”模块进行“普通查询”操作，返回结果的时间在5 s内。这个陈述句已经清晰表达，也达到消除含混性的效果。同样，测试人员可以编写提高查询效率的用户故事“客户在信息查询模块进行普通查询，能够在5 s内返回结果”“备注：5 s为非功能性需求，也是验收要点”。

sprint会议上，开发人员根据经验出牌（团队自己定义的规则，用扑克牌）估算时间，当给出最终结果的时候，测试人员应当对其进行质疑。测试人员借鉴历史经验库，分析开发人员在某方面的技能如何﹑该模块曾经产生过何种程度的缺陷﹑修复缺陷的消耗时间是多少等，综合考虑，提出疑问，使开发估算最终的时间尽可能考虑这些因素。当然，测试人员能够质疑的一个前提，是测试人员具备相关开发经验。

可见，在需求阶段，测试人员要发挥作用，减少含混性需求引入到开发阶段，同时要协助开发人员做好时间估算。

2.2 开发阶段测试

在开发阶段，开发人员进行架构评审，功能要点确认，编码开发，单元测试，开发自测，代码评审，Bug Fix；QA人员管理评审活动和文档产物。测试人员的主要实践如下。

2.2.1 功能要点确认

Xmind是一个非常好用的脑图工具，通常在开发人员进行编码前，测试人员会针对需求处理的用户故事，与开发人员进行确认，修正理解偏差，确保需求理解一致。例如，如图3所示，图中的某软件模块脑图用例提出，测试人员与开发人员需共同对测试要点﹑测试用例﹑测试目标﹑风险进行性评估，给出最终的功能要点，并将其作为编码依据，为下一步设计工作做好准备。

图3 脑图用例模板

2.2.2 测试用例设计

测试人员需根据设计方案提出用例ID﹑用例名称﹑测试目的﹑测试级别﹑测试环境﹑前提条件﹑测试步骤﹑预期结果﹑设计人员名单。在设计测试故事点时，可使用DSL（Domain Specific Language）﹑infoq文章（敏捷测试之借力DSL），对测试用例进行描述。这主要包括三个基本要素（Feature﹑Scenario﹑Example）和两个补充要素（xmind﹑Requirement）。

Feature：把测试分类到某个模块，并对这个特性本身的业务目的进行相关描述，引入业务目标，传递业务知识。

Scenario：标明这个Feature的测试场景，可以使用文字描述步骤，或者使用xmind脑图。

Example：引出具体的数据表格，把用到的数据展示出来，避免相同步骤导致测试数据的变化而重复若干遍工作，造成冗余。

Xmind：脑图文件，展示测试故事点。

Requirement：关联需求管理系统中提出的需求id。

2.2.3 用例评审

用例评审需坚持同行评审的原则，主要在测试组内进行，负责该任务的开发人员也会参与。简单来说，就是对测试用例进行查漏补缺的工作。

2.2.4 测试探索

测试人员在进行“功能要点确认”和“用例评审”后，为保证测试场景的覆盖率，需要再进行测试探索。在开发人员完成雏形后，使用探索式测试的策略，对功能基本流程进行有目的的快速走查，挖掘功能不确定的地方和补充测试场景，避免不确定的因素拖延到开发阶段后期，造成返工。其中，功能测试﹑Bug Tracking﹑回归测试﹑系统测试﹑验收测试都是日常测试工作的所需环节。

2.2.5 燃尽图发布

测试人员还有一项重要工作，就是每日发布燃尽图，让团队了解当前进度情况，总结问题所在，寻求耗时超过预期时间任务的解决办法。图6为测试人员记录的某界面软件模块开发任务进度燃尽图。纵轴表示总工时数，横轴表示计划天数，虚线表示计划完成的基准，实线表示实际剩余工时。

由图4可知，某界面软件模块开发任务进度燃尽图的图形特点。

图4 某界面软件模块开发任务进度燃尽图

第一，剩余工时在计划基准上方，代表进度有所延迟，应抓紧进度。发现此类问题，需要分析总结，原则是保证交付时间，对相应任务进行调整，发现任务粒度太大，该拆分的继续拆分；对于重构需要慎重，不要过度深入重构，给测试带来额外工作量，影响整个进度。对于整个版本而言，只有开发﹑测试在承诺的时间内完成任务，才是真正完成，而仅仅开发完成交付算不上成功。

第二，剩余工时与计划基准接近，代表进展良好，继续保持。此时也需要查看在这种进度下，优先级高的任务是否得到时间保证，而不是因为处理完简单任务使燃尽图长得好看。实际中，往往有开发人员喜欢挑任务，把简单易做﹑优先级高的任务先完成。因为这些总在预期内能够完成，所以前期燃尽图的趋势看起来没有问题。因此，要点使跟踪和控制开发中后期的进度。

2.2.6 缺陷经验库

每个团队都存在开发/测试新人和开发/测试老人。当测试人员与开发新人进行需求确认时，还需要进行缺陷经验教训的提醒，两者共同编写缺陷总结报告，供后续开发人员借鉴。

例如，图5为某界面软件的缺陷总结报告。报告中，对界面软件的构造﹑时间控件﹑查询条件﹑发送功能﹑接口﹑账户名﹑页面等功能和性能模块的缺陷进行了分类描述。

图5 某界面软件缺陷总结

2.2.7 提升开发自测质量

测试人员可在开发过程中提供相关检查单（Checklist），帮助开发人员在编码过程中关注开发自测的要点，从而提升质量。例如，表1为某界面软件的测试检查单，测试人员对界面控件﹑下拉框﹑文本输入﹑按钮功能﹑界面布局﹑查询等功能进行检查，并提出改进建议。

2.2.8 持续集成

基于成熟的测试工具，如持续集成（Jenkins）平台，做到快速构建开发代码，自动单元测试化，来提高开发代码的效率和质量。Jenkins是目前业内最流行的快速持续集成工具之一，其稳定的性能和丰富的扩展性，使很多团队都优先选择它作为项目的主要支持工具。

此平台可灵活定制自动化测试，团队成员通过登陆平台Web界面，按照需求任意选择部署在平台上的自动化测试包﹑目标测试环境﹑测试集和测试用例，提交定制化的自动化执行请求。执行结束后，系统自动发邮件给予通知。此外，不同人员的请求可以实现并行执行；所有的自动化执行历史记录都可以保存在平台上，可以通过Web方式随时查阅；支持丰富的插件，用户可以按照需求进行选择安装和配置，以实现生成执行状态表格，自动部署/更新自动化测试包等高级功能。

负责单元测试﹑集成测试﹑自动化测试（Selenium）的开发人员，都会收到失败构建的邮件。这种方式可确保单元测试﹑集成测试﹑自动化测试的有相关人员同时关注，并共同维护。

测试人员主要需反馈的问题如下：

①Code coverage：团队要求代码覆盖率在80%以上；

②Test success：团队要求测试成功率在100%；

③Duplication：团队要求代码重复率在10%以下；

④Violations：团队要求Major类别的代码规则缺陷在20以下；

⑤开发团队必须保证每个环境的质量目标，才能够保证整个的质量目标。

可见，测试人员与开发人员是协助关系，类似于质量天枰的两边，任何一边的工作没有做好，天枰都将失去平衡。

表1 某界面软件测试checklist

2.3 发布阶段测试

在发布阶段，开发人员需完成线上申请﹑线上部署﹑服务监控等工作；QA人员主要负责管理评审活动和文档产物。测试人员的主要实践如下。

2.3.1 测试报告

完成验收测试，提供测试报告，给出测试数据度量。

例如：

①测试发现缺陷总数：测试过程中产生的去除状态为“无效”“不用改”的缺陷数目；

②测试发现严重缺陷数：测试过程中产生的并去除状态为“无效”“不用改”的﹑且严重性为“Major”和“Critical”的缺陷总数目；

③测试发现缺陷修复数：测试过程中产生的状态为“已关闭”的缺陷数量；

④未解决缺陷数：去除状态为“无效”“不用改”“关闭”的缺陷总数；

⑤缺陷修复率：（测试发现缺陷的修复数）÷（测试发现缺陷总数）×100%；

⑥严重缺陷率：（测试发现严重缺陷数）÷（测试发现缺陷总数）×100%；

⑦严重缺陷修复率：（已修复的严重缺陷数）÷（测试发现严重缺陷数）×100%；

⑧测试需求覆盖率：已测试需求个数÷需求总数×100%。

2.3.2 缺陷统计分析报告

测试人员还需对当前版本的缺陷进行统计分析。缺陷种类分为关键缺陷﹑主要缺陷﹑中等缺陷﹑轻微缺陷，并按软件的功能模块分别进行统计。表2为测试人员给某界面软件提出的缺陷统计表，按9个功能模块进行统计。其中，关键缺陷数0个﹑主要缺陷数5个﹑中等缺陷数10个﹑轻微缺陷数27个，并横向统计出每个单一模块的缺陷总数。

表2 某界面软件缺陷统计表

根据软件缺陷统计表自动生成柱状统计图表，如图6所示，可直观看出此软件的缺陷分布情况，即主要集中在轻微缺陷上。

图6 某界面软件缺陷柱状分布

测试人员需和开发人员共同分析缺陷来源，并按团队统计出关键缺陷﹑主要缺陷﹑中等缺陷﹑轻微缺陷的来源，如表3所示。

表3 某界面软件缺陷来源统计表

最后，测试人员将缺陷问题反馈给开发人员进行修改，并完成回归测试，按缺陷状态计算出测试度量数据，如表4所示。结果显示，某界面软件的缺陷总数为42，回归测试后已关闭缺陷40个，严重缺陷数全部关闭，缺陷修复率为95%，严重缺陷修复率为100%。

2.3.3 测试进度和问题分析

通过对某界面软件的缺陷统计表﹑来源统计表和缺陷状态表的统计数据综合分析，得出以下结论：从BUG严重级别分布来看，Major级别以上的BUG 占12%，比重不高，说明大部分的主要功能已经实现。其中，在sonar定义级别的缺陷主要集中在代码规范和单元测试覆盖率，说明代码质量有待提高；版本测试的前期时间较充足，后期随着开发提交完成的功能点增多，BUG数量增多，剩余测试时间变得紧张；在版本测试期间，发现测试环境存在1次代码被覆盖﹑2次因开发人员操作失误影响测试执行的情况，故需要QA加强配置管理的监督工作。

可见，测试人员应当持续反馈﹑改进﹑总结每个版本发生的问题（不管是缺陷，还是过程中出现的），并对缺陷进行分析，总结规律，帮助开发人员建立良好习惯，改进代码的质量。

2.4 日常运营阶段测试

日常运营阶段并不表示项目已经进入终止阶段，即使需求﹑开发﹑发布阶段的活动已完成，只要还在为用户提供服务，项目的日常运营活动就将存在。开发人员需要按事件触发时机进行生产故障登记；QA人员要对日常运营活动进行维护和管理。

测试人员的主要实践如下。

第一，版本问题反馈和改进提议。对日常运营发生的问题，总结反馈，提出改进建议，并且跟踪实施。

表4 某界面软件缺陷状态表

第二，生产故障分析。协助开发排查生产故障，避免测试场景的遗漏。

3 结语

软件开发工作，从开发初期的问题定义及规划，到各个阶段任务的有效推动，需做到层层相扣。而软件测试作为软件开发过程中的关键环节，把握着软件的质量，在项目全生命周期中发挥着至关重要的作用。本文提出的全生命周期软件测试实践，强调贯穿每个阶段的测试活动，并严格遵循GJB5000A标准要求，为实施三级标准的项目提供完整的测试流程。但不论是开发还是测试，要理解双方的活动价值，保证每个环节的质量，才能够保证产品的全程质量。

参考文献：

[1] 叶娴.浅谈计算机软件工程化管理[J].电子世界,2014(08):261.

YE Xian.Discussion on Computer Software Engineering Management[J].Electronic World,2014(08):261.

[2] 肖云.浅析计算机软件工程的管理和应用[J].电脑知识与技术,2016(12):88-89.

XIAO Yun.Analysis on the Management and Application of Computer Software Engineering[J].Compu ter Knowledge and Technology,2016(12):88-89.

[3] 何宁.浅谈计算机软件工程化管理[J].信息系统工程,2014(10):58.

HE N ing.D iscussion on Com pu ter So ftware Engineering Management[J].In formation Systems Engineering,2014(10):58.

[4] 中国人民解放军总装备部.军用软件研制能力成熟度模型（GJB5000A）[S].2008.

General Armament Department of the People's Liberation Army.Capability Maturity Model for Military Software Development-GJB5000A[S].2008.

Practice and Analysis of Project Life-Cycle Software Test based on GJB5000A

WANG Shi-qin, LI Bin, LU Ye

(No.30 Institute of CETC, Chengdu Sichuan 610041, China)

As one of the most effective methods for testing the quality of software products, software testing now becomes a very important research focus in the field of software engineering. This paper, based on the implementation of GJB5000A three standards, analyzes the relationship of between software development and testing, describes the software testing procedures of project life-cycle, propose the software testing methods in satisfying GJB5000A three standards. For purpose to closely integrate test and project development process, the development and the testing work are alternately carried out throughout the whole process of project development, thus provide a testing guidance satisfying military standard for preparing to implement or being implemented GJB5000A three-standard projects.

software test; life cycle; quality; software engineering