测试流程实践与推动二三事

作者：李雪峰

测试规范，是测试工作开展的重要指导和参考内容之一，对于测试工作是否可以顺利开展起着至关重要的作用；目前杭研QA部门的测试规范已经逐渐推出，涵盖测试计划、冒烟测试、测试用例管理以及质量报告等多部分内容，但是规范是死的，人是活的，一般我们在规范和流程之中，更多的是强调了各阶段流程部分的出入口标准，但是具体的推动和效果方面却因人而异，大不相同。 

本文中，将以云主机及云网络的项目为例，选取测试计划、冒烟测试以及质量报告三个部分的测试规范实践过程，来简单分享一下测试在项目执行过程中的推动和效果展示，期望对其他项目能够起到一定的参考和借鉴作用。

一、测试计划

测试计划作为项目测试开始前的测试整体规划，包括测试的整体目标、策略和人力安排、资源使用等多个方面，是指导后续测试工作顺利开展，同时达到与开发进行工作对齐、风险提前识别的重要参考之一。

项目的当前背景和现状：

• 开发测试比接近6:1
• 需求变更比较频繁，新需求插入较多

测试计划开展前的情况：

开发对于测试的工作量和具体时间安排不清晰，测试的产出和具体的策略、方法以及覆盖范围等均不清晰，缺少直观的了解。

在测试人力明显不足，同时需求插入较多的情况下，如何保证测试工作的顺利开展，同时不影响线上的按时交付和线上稳定运行？实践中主要通过如下方式来实现测试计划的落地和变更，来保证测试工作基本上可以按照测试计划进行开展，降低整体的风险。

推动及实施策略：

• 前期与开发的约定：在当前的测试人力配备情况下，前期在项目组内部与开发侧达成一致，测试优先保障线上交付需求以及对线上交付有影响部分的需求的按时交付和验证，其余需求按照优先级进行排序，优先保证高优先级任务的完成；
• 新需求变更的处理策略：按照需求的优先级进行插入，同样有限保障高优先级任务的交付，如果新需求为紧急上线任务或对上线任务有影响的任务，则顺延其他低优先级的任务；
• 为保证变更的有效性和可跟踪性，在迭代的第二周最后一天，可提出一次需求变更申请，通过对当前任务的重新评估，保证任务的按时交付和闭环；
• 测试计划变更以后，及时（当天）对原有计划进行更新，并知会到项目组全体，确保计划的变更不会对上线造成影响
• 开发交付延期的任务，按照前期测试验证时间的评估进行开展，如果开发交付的时间点无法满足测试验证的最小时间要求，则当迭代拒绝任务转测试，延期到下个迭代开展。

开展前后的效果对比：

• 测试计划开展以后，项目中各种角色人员对于测试工作量和测试各阶段的工作开展、工作负荷以及测试重点、测试策略等有了清晰的了解和认识，避免了前期由于信息不对齐而导致的部分问题出现
• 通过对测试计划阶段的整体推动和落实，近半年期间测试的测试需求交付率基本维持在95%以上（一般都在100%），无测试原因而导致的上线延期或无法上线的问题出现。

二、冒烟测试（转测试过程）

冒烟测试，作为开发需求转测试阶段对其提出的基本质量保障要求，主要的目的是避免转测试以后，由于转测试质量较差，导致大量block测试工作正常开展的问题存在，降低类似问题而增加的返工时间，提升整体的工作效率。前期这个问题一向是个老大难问题。愿意自测的开发团队你不用太多的推动，不愿意做的推动也很难，或者你无法判断他有没有做自测。

冒烟测试规范开展前的团队情况：

冒烟测试规范开展之前，团队中的部分需求开发以后，存在部分需求未经开发自测以后直接转到测试这边，导致测试验证中时而由于转测试版本的低级问题太多而返工或者block住，严重影响测试的工作开展，测试效率较低

为了更好的推动冒烟测试工作的开展，提升整体开发的转测试质量，我们在项目开展中主要采用了以下的方法来进行推进：

• 建立约定，并在项目组内部全体人员达成一致；这部分非常重要，建立统一的规则是后续该部分工作可以顺利推进的前提；
• 制定规则：利用部门现有的规范和模板进行转测试工作开展，项目组内之前针对转测试的冒烟用例通过率已达成一致（必须100%），对于冒烟测试未达到100%通过率的需求一律直接打回；
• 结果统计：迭代结束以后，统计当迭代需求的转测试质量，包括每个需求的冒烟测试的次数和转测试的次数（包括转测试次数以及被打回的次数）；
• 原因分析：每个迭代内，针对冒烟测试不通过的全部案例进行回溯分析，梳理具体的问题和转测试不通过的原因，对其进行归类，如开发无验证环境、时间紧张开发未执行到位等情况；
• 改进制定和跟进：首先，在项目迭代结束后，在项目总结会中针对当迭代情况进行展示，包括每个需求的转测试情况和转测试效果，有问题的部分明确标记出来，全员展示；同时，对于有问题的部分的具体原因进行介绍和讨论，并制定具体的改进措施，避免下个迭代类似问题的再次出现。

冒烟规范开展后的效果：

• 开发转测试以后的质量得到明显改善，基本上无blocker测试工作开展类的问题遗漏到测试端，测试效率提升较大
• 在上半年近六个月的时间内，开发整体的转测试质量相对较好，除一次转测试不通过（开发无自测环境，未进行自测，后期已通过讨论暂时借用一套测试环境供开发自验解决）外，其余转测试全部通过，无冒烟测试用例不通过的问题出现。

三、质量报告

质量报告，作为上线前测试对版本的质量评价，是衡量版本质量和上线风险的最重要的参考文档之一；质量报告中，通过对版本测试覆盖和遗留风险以及问题部分的充分分析，提供客观的数据来支撑产品是否可以正常上线，同时也针对版本在迭代过程中的一些问题和待完善点进行总结，并制定对应的改进措施，以保证后续测试工作的顺利开展。

前期项目的情况：（2013年6月前）

• 未明确要求进行质量报告的编写，上线阶段会分析现有遗留问题，但是未以测试作为出口
• 质量报告未按照迭代编写，迭代的质量情况和上线前的测试情况缺少直观的展示，不够清晰
• 线上情况未进行定期总结和梳理，没有直观数据

针对质量报告，在云主机和云网络的项目中主要开展了如下实践：

• 项目组内部宣讲质量报告的重要性，并在组内达成一致，明确质量报告的形式、内容、发布时间等方面情况，组内达成一致；（上线前开展）
• 上线出口确认：明确测试作为上线出口的唯一确认人，质量报告则是直接提供客观数据的输出件，所有上线需求和bug修复必须由测试确认，对于不满足上线需求的部分内容会在质量报告中明确指出；（上线前开展）
• 报告的展示形式：质量报告完成以后，在项目总结会中进行全员展示，针对其中的一些问题和不足点进行讨论，并制定具体的改进措施，测试负责跟进落实；（总结会中开展）
• 线上质量的反馈：质量报告中会单独针对线上已有的实例运行情况进行总结和反馈，如线上最近的运行情况如何，是否有新增问题或风险，线上当前的整体稳定性如何等方面的总结；（质量报告中增加，但是仅单独统计线上运行情况，不作为上线评估的一部分）

执行效果：

• 在上半年近六个月的时间内，出口明确，测试作为是否可以上线的唯一出口，所以上线需求均经过测试确认后上线，无测试评估有风险暂时无法上线的任务单独上线的情况出现
• 线上整体运行情况稳定，无版本问题导致的线上事故出现（仅单独统计线上运行情况，不作为上线评估的一部分）
• 质量报告按迭代完成，定期展示，项目组内部信息一致

写在最后的话：

上述内容是笔者目前在云主机及云网络项目中，针对现有部分测试流程的推动方法以及推动以后的效果介绍，鉴于服务端产品与其他移动端或web端产品的差异性，文中所提的一些推动手段和方法不一定适用于该类项目，仅供参考而已；

实际上，对于测试流程的落实方面，规范的内容还只是冰山一角，更多的工作还是要靠 测试负责人这边具体推动下去，不同的项目中存在的问题也不尽相同，还是需要大家在各自项目中来探索、追寻！路漫漫其修远兮，吾将上下而求索~~

网易云大礼包：https://www.163yun.com/gift

本文来自网易实践者社区，经作者李雪峰授权发布。