互联网敏捷化开发风格盛行的趋势下,测试地位趋于边缘化,受限于公司和部门的固有风格化,经常和开发人员一起跟着产品经理疲于做折返跑运动。这里不聊开发产品测试那些事,打铁还需自身硬,主要讲下如何从测试和项目整体出发、建立一套稳定有效的质量保障体系。
版本的发布,一般分为以下类型:
项目,周期较长,立项到上线在3周以上
迭代,正常小版本迭代,以周为单位
生产问题修复,线上问题紧急处理,即时发版
本文着重聊下项目类型,比较适用于中、大型互联网公司。
参与角色,常规有:产品、开发、测试、运维、业务验收方。
项目的阶段性活动有以下:
立项、需求宣讲
设计、编码、集成
计划、准备策略、执行测试
业务方验收,原则上建议分批验收,问题发现在源头
生产发布、线上验证
业务监控,线上质量的重要保证,把影响控制在小范围内,预先发现并解决
质量保障体系,依赖于合格的流程,而以上这些活动是保障质量的基础。
下面进入本文的重点,衡量质量保障体系好坏的标准,不是里面的内容多么充实、饱满,而在于执行力。落地后,需要整个团队去遵守,形成思维化习惯而落地,在执行的过程中不断去优化,进而继续坚持。
质量保障体系的核心包括以下几点:
文档
评审机制
准入、准出标准
重视回归测试
生产问题定期复盘
生产监控、报警机制
下面逐条解释下每一点的核心价值和策略。
01
文档管理
关键词:需求文档、设计文档、测试文档
需求和设计产出方为产品、开发,测试需要做好流程监督,这里重点说下测试文档。
测试文档,从业务领域来说,一般有测试计划、测试用例、业务总结文档。
测试计划,描述测试活动的规划、策略,运筹帷幄,防患于未然。里面重要的几个点,测试范围、测试策略、测试进度、准入准出标准、风险评估。测试范围,内部需要细化到模块,外部是否有依赖方或被依赖方,需要提前告知对方,安排联调。测试策略,人员的安排,每一阶段的测试活动,工具的使用、自动化、性能的介入。测试进度,需要固定的跟踪,如定期同步测试进度,告知风险。可提测的准入标准,测试后期是否符合上线条件的准出标准,业务人员的及时验收、反馈。风险评估,一般是时间规划不足,不能按时交付。
测试用例,是测试执行文档,不建议做迭代维护,可读性差,描述更多的是对业务细则的如何测试,包含边界值、有效等价类等测试方法,过于琐碎,不适合提炼维护。所以,我对测试用例的定义是,当前版本有效。
业务总结文档,是对当前系统业务的描述、汇总,通过该文档,可以一目了然当前系统的基础逻辑。更侧重于从业务逻辑角度描述系统,是测试人员的帮助文档,需要在每次迭代后及时更新,无需去翻看测试用例。熟悉、掌握系统核心业务,是测试人员的一项基础能力。
02
评审机制
信息的传递具有时效性,一份需求从产品->项目经理->研发团队->测试团队,如果测试团队在最后测试准备阶段接入,会丢失很多的信息。软件的生命周期如果用W模型来定义,那么每个阶段,测试的活动都是联动的。
所以,每个阶段的产出对应的评审是必不可少的:需求评审、开发设计评审、测试计划评审、测试用例评审。
03
准入、准出标准
准入标准,即提测标准,为冒烟测试用例通过,验收人为测试人员,通过率可以酌情而定,比如超过70%的通过率则提测通过,否则打回。冒烟测试用例会维护并分享给开发人员,提测前,开发人员内部自测下,提高沟通效率。
制定提测标准的目的是为了约束开发工作能按时交付,如果测试的周期为10天,开发提测质量较差,导致修复阻塞性问题花费了两三天,这样会影响版本按时上线。出于质量的考虑,项目会顺延上线,每个环节都是螺丝钉,环环相扣,不能顾此失彼。
准出标准,即符合上线的标准,一般参考点有两个:测试报告、业务验收。例如通过率超过95%才能符合上线,遗留缺陷登记P3的数量,是否影响业务功能。业务验收,介入越早越好,可以分批验收。
生产验证,一般是在发布后,使用测试账号在生产进行可测试性验证。生产的发布比较复杂,包括代码的发布、配置变更、DB变更、运维操作、网络层通信等,每个环节的疏忽或误操作,都会影响到本次发布。
04
回归测试
版本测试是为了保证当前版本需求的质量,而回归测试时保证整个系统业务的质量,重要性不言而喻。
测试人员的一个盲点,愿意花费大部分时间在了版本测试上,而用少量的时间做回归测试,这个习惯是致命的。需求的改动,是小范围的,影响可能是全局的,对于支付类的业务更是不能有一丝的轻视。
所以,测试团队要重视回归测试,并预留足够的时间比重来做这一块。一定要维护、写好回归用例,从业务影响上设定用例的优先级,这样才能有足够的信心应对每一次的版本发布。
05
问题复盘
问题复盘,包括潜在风险、已暴露问题。
潜在风险,如排期过短、流程不规范等,需要提前介入,重新评估,避免风险在最后暴露。
已暴露问题,一般为生产问题,需要做团队内部的复盘整理,参与方,包括产品、研发、测试。建议一个月至少一次,总结问题,进而完善质量保障体系。
06
监控报警
版本发布成功以后,还需要监控新版本系统的运行健康情况。
这里有个灰度的概念,新版本的更新,可以先开放给少部分用户使用,运行一段时间后,没有问题,再开放给全部用户。
监控包括:数据库监控、应用服务监控、异常日志报警、数据量暴或暴减异常预警。
转载自:http://navo.top/BVBBVf