如何有的放矢高效测试--新版软件开发云测试管理介绍

一个用户叫好的产品除了优秀的产品设计、精妙的架构设计，还离不开产品质量的把关者和守门人--测试工程师。成熟公司的测试工程师可能就数十人、产品从研发到上市，严格的测试管理耗费数周时间、数十万经费……但国内企业重开发、轻测试，特别是3、5个人的创业团队？谁也不想自己的产品bug百出、闪退频繁、装完即卸载吧？

创业连产品关都闯不过，谈何打开市场呢？ 

软件测试常见问题，你正在深陷其中吗？                                                                            

• 缺乏工具有效规范地管理团队的测试任务、测试进度和产品质量状况 

• 测试资源投入不均衡，个别模块测试投入过多或过少，导致投入产出比不稳定

• 团队使用敏捷和精益开发模式，没有及时把新增或变更的需求和设计通知到测试工程师，导致漏测或误测

• 开发工程师抱怨测试工程师提交的缺陷描写不细致，比如没有复现步骤，导致沟通成本增加

• 缺陷修复后开发工程师没有通知测试工程师，导致缺陷复查不及时

• 测试工程师手工维护测试报告，工作量大并且容易出错

软件开发云测试管理内置最佳测试方法和实践                                                         

如何轻轻松松避开这些坑呢？软件开发云测试管理新版上线，内置了软件测试的最佳方法和实践，帮助团队有效沟通协作，高效高质量完成测试工作，包含：

• 需求驱动的测试管理

• 测试用例和需求、缺陷的追溯管理

• 测试需求变更管理

• 测试覆盖率管理

• 测试进度管理

• 缺陷模板管理

• 自动填写缺陷复现步骤

• 实时测试报表

某母婴电商平台示例介绍测试管理最佳测试方法和实践                                                         

下面以一个简单的电商网站为例介绍如何高效完成测试工作。

某母婴电商平台完成产品立项，开发团队刚刚组建完毕，产品总监带领团队以精益创业的理念小步快跑开发产品，每个迭代交付一个MVP最小可用的产品，然后邀请一些早期用户做内测，收集反馈不断迭代改进。下图是该母婴电商平台产品规划，可以看到很多特性定义粒度仍然很大没有做细化，但同时个别特性已经细化到用户故事的粒度。迭代1交付第一个MVP，仅有4个用户故事，支持用户和商户的手机验证码注册、商户上架简单商品、用户简单搜索商品。测试团队在迭代1的任务就是测试验证开发工程师的交付物符合这4个用户故事定义的功能范围，并且没有明显的缺陷和体验问题。

图 1使用精益MVP方式开发该母婴电商平台产品，迭代1交付4个用户故事

图 2使用精益MVP方式开发该母婴电商平台产品，迭代1交付4个用户故事

需求驱动的测试管理

       需求驱动的测试管理就是以需求为标尺衡量开发工程师的交付结果，验证是否符合需求。优点是测试活动有的放矢，目标明确，测试任务容易拆分。主要实践为基于需求创建测试用例完成测试设计，在软件开发云中有两种方式。

第一种方式，在测试管理追溯视图中基于需求设计测试用例，首先选择迭代1过滤出本迭代的的需求，如用户使用手机号和验证码完成注册，然后在需求下创建3个测试用例，每个用例覆盖一种用户场景

用户管理_用户注册_用户使用正确的手机号和验证码完成注册

用户管理_用户注册_用户使用已经注册的手机号注册，提示已注册

用户管理_用户注册_用户使用格式非法的手机号注册，提示手机号格式不正确

图 3追溯视图下基于需求设计测试用例

       第二种方式，在项目管理中为需求创建测试用例

图 4需求详情中查看、新建测试用例

       方式一是在测试管理中，更适用于测试团队使用。方式二是在项目管理中，更适用于在没有专门测试团队的情况下，开发人员自测试或交叉测试，自己管理测试用例。两种方式效果一样，仅需使用其中一种方式创建，测试管理、项目管理两边均显示需求和用例的关联关系。

测试用例和需求、缺陷的追溯管理

       测试团队的核心工件是测试用例，测试需求是测试的上游工件，缺陷是测试的下游工件。三种工件有效地关联起来可以帮助测试人员快速准确完成测试需求分析、测试用例设计、缺陷管理、缺陷复查，并可以帮助开发人员透明地快速了解缺陷的背景信息。

测试用例和需求的追溯管理：上节中谈到的需求驱动的测试管理中实质上就是创建了需求和测试的双向追溯关系，由用例出发可以追溯到需求，由需求出发可以追溯到用例。以该母婴电商平台中测试用例用户管理_用户注册_用户使用正确的手机号和验证码完成注册和需求用户使用手机号和验证码完成注册为例，在多个视图中均可以方便地查看测试用例和需求之间的追溯关系，点击需求或者测试用例查看上下文信息：

图 5用例视图中展示测试用例关联的测试需求，或关联/取消关联需求

图 6测试用例详情中展示关联的测试需求，或关联/取消关联需求

图 7需求中查看、新建测试用例

       测试用例和缺陷的追溯管理：测试人员执行测试用例提交缺陷，系统会自动创建测试用例和缺陷的双向追溯关系，由测试用例可以追溯到缺陷，反之亦然（反向追溯预计12月上线），并且缺陷自动关联为需求的子工作项。

       在该母婴电商平台例子中，测试工程师执行测试用例用户管理_用户注册_用户使用正确的手机号和验证码完成注册，发现获取不到手机验证码，提交了一个缺陷用户管理_用户注册：使用手机号注册新用户收不到验证码。系统自动建立了测试用例、缺陷、需求三者之间的追溯关系，开发人员从缺陷中查看关联的测试用例即可以了解测试上下文信息，快速定位缺陷问题。缺陷自动设置为需求的子工作项，免除手工关联工作，帮助开发团队有序地管理缺陷。

图 8用例视图中展示测试用例的缺陷

图 9用例详情中缺陷列表展示提交的缺陷

图 10缺陷自动关联为需求的子工作项

测试需求变更管理

       测试需求变更管理就是当测试需求发生变更时及时有效地通知受变更影响的干系人（测试用例执行者、测试用例设计者）采取对策。需求变更各式各样，比如需求的规格发生变更、需求的设计发生变更、开发转测时间延期。需求变更按照影响程度大小可以分为不同级别，如果测试需求变更不及时通知测试工程师，就会造成功能漏测或者无效测试，开发工程师和测试工程师之间产生扯皮问题，影响团队士气和效率。比较大规模的团队一般会有专门的变更管理系统，这样的系统在规范化流程的同时也降低了团队组织运作的弹性和敏捷力。

       在软件开发云测试管理中，测试需求变更通过消息通知传播，测试工程师可以根据自己需求按需订阅消息和处理测试需求变更。以该母婴电商平台为例，迭代1接近尾声，测试团队已经完成需求用户使用手机号和验证码完成注册的测试工作，准备发布首版测试报告。此时产品创始人告知美国人Dan希望评估产品原型做天使投资，因此产品总监在迭代1增加了产品增加英文页面的需求，并更改了需求用户使用手机号和验证码完成注册范围，添加了支持境外手机注册的要求。测试团队如何管理需求用户使用手机号和验证码完成注册的范围变更呢？（实际工作中，产品经理根据市场和用户反馈经常提一些临时需求或需求变更）。需求的每次变更操作都会被记录，并发送消息通知。当产品总监更新需求用户使用手机号和验证码完成注册后，在相关测试工程师的视图中，此需求右上角会出现小红点，代表此需求有未处理的变更。

图 11测试管理追溯视图需求更新提醒

       测试工程师点击小红点查看需求用户使用手机号和验证码完成注册的变更历史记录，发现需求新增了支持境外手机注册的要求，采取对策创建新的测试用例覆盖此变更。

图 12点击小红点，自动定位到需求历史记录

          测试工程师可以根据自己的需求打开或者关闭需求更新通知功能。

图 13需求更新提醒开关

测试覆盖率管理

测试覆盖率管理就是管理测试用例覆盖的测试范围。测试覆盖率=测试已覆盖的功能点/所有的功能点*100%。主要实践包括量化管理测试覆盖率，识别测试用例覆盖的需求范围，识别没有覆盖的需求点，新增测试用例增加测试覆盖率，识别对增加测试覆盖率无意义的测试用例。优点是可以帮助测试工程师把测试范围、时间、投入管理在可控范围内，轻松确定哪些功能已经在测试范围内，发现测试用例和测试需求之间的缺口，作为指标帮助衡量测试质量，及早发现缺陷。由此也可以看出需求覆盖率并不是越高越好，需要测试工程师根据情况管理测试范围和测试强度。

软件开发云测试管理提供开箱即用的需求测试覆盖率报表，帮助测试团队管理者实时统计分析测试覆盖率。下图中显示迭代1中需求覆盖率为25%，有3个需求没有测试用例覆盖，1个需求有3个测试用例覆盖，并且已经测试完成。针对没有测试用例的需求，通知测试工程师创建测试用例增加测试覆盖率。在报表中选择某个模块如商品管理可以查看单个模块下的测试覆盖情况。

图 14需求覆盖率报表

测试工程师日常在下列视图中工作，可以查看自己负责的需求的测试覆盖率情况，为需求增加测试用例提升覆盖率。

图 15追溯视图中管理需求覆盖率

测试进度管理

       测试进度管理是使用项目进度管理方法管理测试进度。测试项目分为几个阶段，每个阶段都有关键活动和交付物，测试准备阶段要完成测试需求分析和测试用例的设计工作，测试执行阶段要完成测试用例的执行，开发工程师修复缺陷后，测试工程师还要完成缺陷的复查和关闭。

       软件开发云测试管理报表提供了测试用例完成率报表、测试用例进度报表、需求测试进度报表，帮助测试团队管理者实时管理测试进度。从报表可以看出，迭代1中需求用户使用手机号和验证码完成注册的测试任务已经完成。

图 16测试进度报表

测试工程师日常在下列视图中工作，可以查看管理自己负责的需求的测试进度。

图 17追溯视图中管理测试进度

缺陷模板管理

       软件开发云中内置了缺陷模板，团队可以根据流程定制缺陷模板内容。

自动填写缺陷复现步骤

测试工程师执行测试用例时创建缺陷，系统会自动把测试用例的步骤和预期结果填写到缺陷的复现步骤，开发人员接到缺陷，一目了然知道如何复现缺陷。

自动化的测试度量

自动化的测试度量是指通过自动化技术收集和分析测试活动数据，以报表的形式呈现测试团队活动概况，指导测试团队持续改进测试活动，并自动生成测试报告。自动化的测试度量实践主要包括实时展示测试覆盖率、测试进度、缺陷分布、测试工作量分布、实时测试报告，测试团队管理者和测试工程师的关注点有所不同。自动化的测试度量可以提升测试管理的水平，帮助管理者及时发现测试风险，极大地降低测试统计的工作量。

软件开发云内置了上述自动化的测试度量的最佳实践。以该母婴电商平台为例，测试覆盖率报表帮助及时发现了迭代1中的3个未测需求，避免需求漏测。除了前几节已经介绍的报表能力，测试团队管理者还可以：

• 通过缺陷报表查看总体缺陷分布统计。从下图中可以发现迭代1中测出1个缺陷，为一般级别。

• 通过缺陷报表查看每个模块的缺陷分布情况。从下图中可以发现迭代1中测出用例管理模块的1个缺陷，为一般级别，其他模块未发现缺陷。

• 通过用例通过率报表查看测试整体通过率。从下图中可以发现迭代1中完成了3个用例的测试工作，均为成功。

• 通过成员报表查看每个成员提交的缺陷总数和严重级别分布。从下图中可以发现迭代1中有1名成员提交了1个缺陷。

• 通过成员报表查看每个成员名下的测试用例总数和进度分布。从下图中可以发现迭代1中有1名成员名下有2个测试用例，其中1个用例新建未设计，1个测试用例已测试完成。

• 一键导出Word或者PDF格式的报告。

图 18自动化的测试度量

总结                                                                                                      

最后总结一下，软件开发云测试管理内置了测试管理的最佳方法和实践，提供需求驱动的测试管理、测试用例和需求缺陷的追溯管理、测试需求变更管理、测试覆盖率管理、测试进度管理、缺陷模板管理、自动填写缺陷复现步骤、实时测试报表等能力和特性。希望通过该母婴电商平台演示配合相关的理念介绍能让您在测试管理方面有所收获。和该母婴电商平台一样测试管理产品也使用MVP的方式在不断迭代演进，后续会不断有新特性推出，并增加自动化测试能力，期待您的关注、使用和反馈。 

打响产品第一枪，先过测试关！你的产品行吗？

       软件开发云新版测试管理体验地址：https://devcloud.huaweicloud.com/testman/home