如何玩转基于风险的测试

此文已由作者谢蕾授权网易云社区发布。

欢迎访问网易云社区，了解更多网易技术产品运营经验。

看到标题，很多同学可能会认为本文倡导“立即进入追踪极端”的测试，其实不然，基于风险的测试需要QA与产品、开发等项目角色有更多的切磋。我们还是遵守事物发展规律，从头说起。源起各项目的商业化发展，所有项目开发过程都转向敏捷，QA作为其中一员必然加入敏捷大军，顺势转变工作方式。基于风险的测试可以简单理解为问题驱动。那么如何发现问题呢？答案就是“测试向前”，这也是敏捷测试的核心，适用于所有类型的项目。

我们云计算项目多年来一直遵循scrum的项目模式（这里不对scrum进行介绍，可以问谷歌），迭代周期固定，发布时间固定，面向企业用户，质量一直是悬挂在头顶上的利剑。今年，随着产品策划团队在团队的不断壮大，需求越来越多，项目流程必须做出改变，QA不能再等待开发通知迭代计划和测试任务，而是要积极推动需求评审，围绕需求的可行性、正确性和影响进行充分讨论，这时QA是对系统总体业务了解最多的角色，能够分析出很多新需求对系统的影响，为需求的完整性提供建议。如果，此时预估到新需求会影响老功能，那么QA会对这个需求重点分析，完成详细测试分析。综述，在需求澄清和确认环节，产出物是需求文档和测试分析文档(基于需求)，测试分析文档除了进行功能点梳理，重要的是挖掘潜在风险。通过需求评审后，项目进入交互设计、开发设计、开发编码、再次测试分析、测试用例设计、开发冒烟等环节，每个环节我们都指定质量负责人，owner制让大家更有责任感，环环相扣的质量追踪，最大程度的降低在测试过程中爆发新问题的可能性。受六道网测试体系的启发，我们制定了七层质量保障体系，目前正在网易蜂巢（云计算基础服务）大团队推行：

经过大家层层的质量把关，在项目后期正式转交给QA测试时，主流程走通基本没有问题。在产品化、商业化的今天，大家都努力追求产品的快速迭代，测试执行周期越来越短，如何利用有限的时间，保障系统的健壮性成为QA工作的重头戏。具体做法：

一、我们不断完善测试基础部件：万物都遵循从简单到复杂的发展过程，(手工或自动化)测试也是一样，一定是从简单入手，逐步增加深入和复杂程度。我们推荐持续集成的实施，尽可能的将可以自动化测试的功能用自动化覆盖，并把这些测试交给开发同学以便他们在开发过程中随时验证（当然，最好还要有单元测试护驾）。另外我们的项目特别重视接口测试，而接口测试又特别依赖接口定义文档，如果能在提测前给出接口定义文档，那么QA就会在上线前完成接口测试自动化开发。我们从api主流程测试入手，逐步完善api测试，包括并发、边界值、异常等。测试执行从纯手工变成全自动化，测试效率提升N个档。

二、我们在制定测试策略的时候，特别关注服务故障恢复能力、特别关注多方合作的功能、特别关注应用服务异常、特别关注大并发、大压力的场景。《启发式基于风险的测试》一书中给出了一个比较实用的经典的基于测试风险的分析表，仅参考：http://qualtech.newsweaver.ie/startester/18wsevk2e6v1nkk3ly7um2

有时，用被害妄想症的思维去测试。比较理想的测试覆盖如下图所示，项目组成员可以通力合作，根据系统特征打出一套漂亮的测试组合拳。

三、将异常注入、稳定性等测试平台化。通常，这类型的测试需要测试人员对被测系统和业务逻辑有很深入的清晰的了解，同时，需要掌握专业的测试工具，很多同学望而生畏（如，学习成本，测试效率）。因此，为了提高系统异常、稳定性测试的效率，降低测试门槛，我们逐步开发了TaaS平台，将故障注入、异常、稳定性测试服务平台化，测试场景持久化。

四、质量评估，QA随时根据测试情况进行质量评估，针对发现的问题进行风险分析，必要时与产品、开发一起讨论问题的严重程度和解决方案，提供客观的测试数据和质量评价，让项目组成员对上线内容的质量有清晰的认识，这一工作也会持续指导下个迭代的工作内容或重点。

五、上线后持续跟踪用户使用情况，根据用户使用场景反补测试场景，精确测试重点。常用的做法有url打点、全链路监控（log分析）、引流测试等，但对一些产品，这些方法还不够，我们推荐QA走近用户，与用户进行交流访谈，了解其使用姿势，挖掘需求，帮助QA更好的成为产品第一道用户。

六、故障或线上bug回顾总结，这其实是问题驱动的典型案例。我们不害怕出现线上问题，重要的是正式问题，解决问题，举一反三，避免重复出现类似的问题。

七、全民验收，在时间紧任务重的情况下，发动更多的人进行测试是一个很好的方法。如组织bugbash，众测等，都能降低上线后的质量风险。

当然，迭代过程中，我们还会遇到很多情况，如需求变更，任务优先级变更，设计变更等等，没有关系，不要慌，relax，冷静为什么要分析变更，变更后需要哪些角色做出响应，哪些工作需要做出调整，迅速响应变更也是敏捷里面比较倡导的方面，积极应对这些变更，时刻保持风险意识，化繁为简。

最后，提一下基于风险的测试用例设计。QA工作的直观产出就是测试用例，也是应用文档的核心，我们要求测试用例分层、分级、覆盖全面，不断维护更新，在基于风险的用例设计过程中，我们用例编写必须细致，全面覆盖业务场景，并加大执行力度。测试用例的质量是不单是QA工作的门面，更是帮助项目组成员更好理解和保障质量的必要物件。毋庸置疑，测试用例的owner是QA，我们会根据需求和架构设计进行用例设计，如，先进行功能用例设计，再进行接口用例设计，最后进行端到端场景用例设计。通常，开发编码与测试用例编写齐头并进，QA要尽可能早的提供测试用例并组织评审。QA根据需求或功能的重要性，发起平台在线用例评审或组织会议的用例评审，让开发同学更好的了解测试和需求理解是否一致的同时，也希望开发同学能提供一些测试建议，更好的保障测试覆盖的全面性。只有产品、开发同学一起参与的用例评审才是有效的评审，才能更好的保障测试用例的质量，三方协作的力量不可小觑。

总而言之，“测试向前”很好的将问题提前发现、曝光，并降低风险或得以彻底解决。风险分析已经成为敏捷开发的一部分，高风险的故事会受到更多的关注和讨论，团队在制定迭代计划和发布时，也会根据风险考虑事项的优先级和发布方式等。测试更应如此，因为我们没有时间面面俱到的测试，所以需要利用风险分析评估需要做哪些测试才恰到好处。而这里的“测试”不是狭义的测试，不单单是QA人员的工作，而是人人都是质量保障者，人人都参与项目构建过程。每个产品虽然所处环境不同，但目标都是高质量的为用户提供服务，这就需要QA同学牵头做好质量保障体系，采用敏捷式的测试思维，调动团队整体参与。切记“产品质量不是测试出来的”。

网易云计算基础服务深度整合了 IaaS、PaaS 及容器技术，提供弹性计算、DevOps 工具链及微服务基础设施等服务，帮助企业解决 IT、架构及运维等问题，使企业更聚焦于业务，是新一代的云计算平台，点击可免费试用。

网易云免费体验馆，0成本体验20+款云产品！ 

更多网易技术、产品、运营经验分享请点击。

相关文章：
【推荐】 【RabbitMQ学习记录】- 消息队列存储机制源码分析