互联网敏捷化开发风格盛行的趋势下，测试地位趋于边缘化，受限于公司和部门的固有风格化，经常和开发人员一起跟着产品经理疲于做折返跑运动。这里不聊开发产品测试那些事，打铁还需自身硬，主要讲下如何从测试和项目整体出发、建立一套稳定有效的质量保障体系。

版本的发布，一般分为以下类型：

本文着重聊下项目类型，比较适用于中、大型互联网公司。

参与角色，常规有：产品、开发、测试、运维、业务验收方。

项目的阶段性活动有以下：

质量保障体系，依赖于合格的流程，而以上这些活动是保障质量的基础。

质量保障体系的核心包括以下几点：

下面逐条解释下每一点的核心价值和策略。

关键词：需求文档、设计文档、测试文档

需求和设计产出方为产品、开发，测试需要做好流程监督，这里重点说下测试文档。

测试文档，从业务领域来说，一般有测试计划、测试用例、业务总结文档。

测试计划，描述测试活动的规划、策略，运筹帷幄，防患于未然。里面重要的几个点，测试范围、测试策略、测试进度、准入准出标准、风险评估。测试范围，内部需要细化到模块，外部是否有依赖方或被依赖方，需要提前告知对方，安排联调。测试策略，人员的安排，每一阶段的测试活动，工具的使用、自动化、性能的介入。测试进度，需要固定的跟踪，如定期同步测试进度，告知风险。可提测的准入标准，测试后期是否符合上线条件的准出标准，业务人员的及时验收、反馈。风险评估，一般是时间规划不足，不能按时交付。

测试用例，是测试执行文档，不建议做迭代维护，可读性差，描述更多的是对业务细则的如何测试，包含边界值、有效等价类等测试方法，过于琐碎，不适合提炼维护。所以，我对测试用例的定义是，当前版本有效。

业务总结文档，是对当前系统业务的描述、汇总，通过该文档，可以一目了然当前系统的基础逻辑。更侧重于从业务逻辑角度描述系统，是测试人员的帮助文档，需要在每次迭代后及时更新，无需去翻看测试用例。熟悉、掌握系统核心业务，是测试人员的一项基础能力。

信息的传递具有时效性，一份需求从产品->项目经理->研发团队->测试团队，如果测试团队在最后测试准备阶段接入，会丢失很多的信息。软件的生命周期如果用W模型来定义，那么每个阶段，测试的活动都是联动的。

所以，每个阶段的产出对应的评审是必不可少的：需求评审、开发设计评审、测试计划评审、测试用例评审。

准入标准，即提测标准，为冒烟测试用例通过，验收人为测试人员，通过率可以酌情而定，比如超过70%的通过率则提测通过，否则打回。冒烟测试用例会维护并分享给开发人员，提测前，开发人员内部自测下，提高沟通效率。

制定提测标准的目的是为了约束开发工作能按时交付，如果测试的周期为10天，开发提测质量较差，导致修复阻塞性问题花费了两三天，这样会影响版本按时上线。出于质量的考虑，项目会顺延上线，每个环节都是螺丝钉，环环相扣，不能顾此失彼。

准出标准，即符合上线的标准，一般参考点有两个：测试报告、业务验收。例如通过率超过95%才能符合上线，遗留缺陷登记P3的数量，是否影响业务功能。业务验收，介入越早越好，可以分批验收。

生产验证，一般是在发布后，使用测试账号在生产进行可测试性验证。生产的发布比较复杂，包括代码的发布、配置变更、DB变更、运维操作、网络层通信等，每个环节的疏忽或误操作，都会影响到本次发布。

版本测试是为了保证当前版本需求的质量，而回归测试时保证整个系统业务的质量，重要性不言而喻。

测试人员的一个盲点，愿意花费大部分时间在了版本测试上，而用少量的时间做回归测试，这个习惯是致命的。需求的改动，是小范围的，影响可能是全局的，对于支付类的业务更是不能有一丝的轻视。

所以，测试团队要重视回归测试，并预留足够的时间比重来做这一块。一定要维护、写好回归用例，从业务影响上设定用例的优先级，这样才能有足够的信心应对每一次的版本发布。

问题复盘，包括潜在风险、已暴露问题。

潜在风险，如排期过短、流程不规范等，需要提前介入，重新评估，避免风险在最后暴露。

已暴露问题，一般为生产问题，需要做团队内部的复盘整理，参与方，包括产品、研发、测试。建议一个月至少一次，总结问题，进而完善质量保障体系。

版本发布成功以后，还需要监控新版本系统的运行健康情况。

这里有个灰度的概念，新版本的更新，可以先开放给少部分用户使用，运行一段时间后，没有问题，再开放给全部用户。

监控包括：数据库监控、应用服务监控、异常日志报警、数据量暴或暴减异常预警。

转载自：http://navo.top/BVBBVf