软件测试用例的维护、协同与管理 - YesDev测试专场

何时需要测试用例？

如果是小型、临时的项目，或者只是个人项目或者独自测试的项目，一般不需要耗费时间和精力再额外维护测试用例。

但如果是公司核心的产品，是长期维护迭代的软件，或拥有众多或庞大的用户体量，或每日订单流水极高的系统，维护一份由经验沉淀下来的测试用例，对于保障上线质量，保证版本迭代速度都有强烈的价值和意义。

基础入门：如何维护测试用例？

这里推荐使用YesDev进行测试用例的维护、测试计划的执行和管理。

一个测试用例，可以包括以下基本元素：用例标题、用例描述、测试步骤、用例类型、优先级、用例状态、所属的用例库的模块等。

在YesDev协作工具中，你可以创建多个测试库。每个测试库对应一个产品或某个项目。

你可以单个创建测试用例、复制测试用例，也可以使用Excel批量导入测试用例。

个体互动：产研测高度融合

敏捷开发推崇：个体和互动 高于 流程和工具。

在上市企业和大公司里，每做一个版本的需求，通常会经历三个重要的评审会议，分别是：需求评审、技术评审、测试评审。

这三个会议，可以是正式召开，或是在休闲区进行非正式的沟通，抑或是直接在工单上进行简单的对接。最重要的是，通过当面的沟通，增强大家对将要迭代的需求达成共识，消除团队各成员彼此之间的误解、信息差和发挥集体智慧。

显而易见，需求评审是由产品经理主导，向技术和测试人员讲解需求背景、核心业务逻辑和期望交付的时间；技术评审是由核心技术开发工程师主导，从专业的角度解释和讲明将使用何种技术、怎样的设计思路和系统构架来实现本次的需求；测试评审则是对需求进行人工、黑盒、功能测试的走查，确保测试充分、完整、符合良好的用户体验。

如此下来，在团队内部就可以快速，把要做的需求、技术如何实现、测试如何验收进行共享和同步，有利于后续的项目推进、协作和交付。

进阶：测试计划、执行与报告反馈

测试用例，是静态的测试单元。

要发挥测试用例的价值，需要进行合理的规划，通过测试计划，可以完成指定时间背景下需要实现的功能为测试目标。这是一种计划能力，也是一种团队协作的重要组成部分。

一个测试计划，可以规划多个测试用例。计划的边界范围，取决于项目的要求。如果是全新的项目，则需要分批涵盖新功能的全部测试用例。如果是常规的版本迭代，可以把一级用例（即那些必须要通过回归测试的用例）单独维护成一个测试计划，以便在每次发布上线前进行一轮回归测试。

在具体的测试计划里，要关注两个100，分别有：测试用例要100%测试通过；全部缺陷要100%修复。

开始测试：可以快速对未测试完毕的用例继续进行测试。

在测试过程中，要及时进行测试进度的同步和反馈。如果项目周期较长，或者测试所需要的时间较多，应当在下班前或关键的时间节点，或项目里程碑到来前，或者测试进度不理想有延期风险时，应当通过测试报告向上汇报或在团队内部进行同步，或向客户反馈。YesDev提供了自动生成汇总的测试报告，可以直接发送到邮件。

Bug反射弧：发现-修复-重测

在测试过程中，对于发现的问题，可以进行记录，方便统一跟踪和管理。

例如，项目的全部Bug跟踪：

单个Bug的处理流程，应当遵循：发现-修复-重测 的流程。测试提出问题，开发进行排查修复，最后再回到测试进行重新测试。如果没问题则关闭，否则重开。

开发在修复问题时，应该说明Bug出现的原因以及归因分类；测试人员在重开时应当注明重开的原因。

统计数据下的质量分析

基于前面积累的测试问题，我们可以获得各个维度的质量分析数据。包括但不限于：

    1、按产品统计

    2、按负责人统计

    3、按创建人统计

    4、按项目统计

    5、按需求统计

    6、按优先级统计

    7、按归因统计

    8、按解决时长统计

这些分析数据，对于改进项目质量、提高团队协作默契都有参考指导作用。

协同：关联项目和外部协作

测试计划是测试用例的规划和动态执行结果的汇总。

但是测试计划不是单独存在的，它需要和项目关联和在指定的项目背景下，才更有意义。

你可以把测试计划和项目关联，尤其在外部项目协作时，可以进行专业分工，由外部团队负责功能测试和验收。最后，归总并聚合在同一个项目里。

最后，一个完整的项目示例如下：