浅谈业务质量保障体系的建设

最新推荐文章于 2024-10-31 16:49:53 发布

飘飞雪

最新推荐文章于 2024-10-31 16:49:53 发布

阅读量1.9k

点赞数 2

分类专栏：质量保障文章标签：测试工程师 QA 质量保障

本文链接：https://blog.csdn.net/qq_38783257/article/details/117301780

版权

质量保障专栏收录该内容

13 篇文章 4 订阅

订阅专栏

本文总结了一年的测试经验，探讨了质量保障体系的建设，分为初创、稳定和成熟三个阶段。初创阶段注重快速交付，工程规范和内建质量在后续阶段逐渐建立。质量保障内容包括效率工程、工程规范和内建质量，涉及需求管理、用例管理、缺陷管理等多个方面。文中提出自动化测试、线上监控、代码提交规范等关键实践，并强调了规范落地的重要性。

摘要由CSDN通过智能技术生成

前言

做了也快1年测试了，这边总结一下对业务质量保障体系的建设的一些感悟总结。
首先测试与QA的区别。
测试只是质量保障的手段，交付符合质量的软件才是最终目的，针对不同业务建设不同的质量保障体系才是QA的价值。所以我们不能只满足于做一个tester，而是要以QA的定位对团队做出贡献。
质量保障并不是只是QA的事情，是要靠整个团队的共同努力。

质量保障的内容

质量保障的内容离不开以下三点：

效率工程
工程规范
内建质量

效率工程

测试工具，流水线，devops的建设。所谓质效一体，没有效率，质量就难以获得保障。这边的效率不仅指的是测试效率，也指的是研发效率。如何让每一个程序员专注于业务开发，而不必做那些杂事，比如写了一行代码1分钟，测试部署环境花了10分钟。这是浪费时间的事情，在当前敏捷横行的年代这么做增大了研发的压力，甚至出现延期的风险，质量更得不到保障。这也是各大公司大力推行devops的原因。
测试也是如此，每一迭代有时需要花大量时间做回归，项目周期就会延长，影响交付。这时候自动化测试的价值就出来了。

作为QA需要有一个锐利的眼睛，即发现整个软件研发周期中效率低下的部分，包括需求->研发->测试->发布上线的全流程，并使用技术手段加以提效。

工程规范

俗话说：不成规矩，不成方圆。混乱的项目管理必然增加软件交付后缺陷的数量，让项目有序推进也是质量保障工作的一部分。比如需求管理规范，用例管理编写规范，代码编写规范，每一迭代周期控制等等。这边推荐腾讯tapd，做的特别棒，工程规范一站式管理。其他的禅道什么的也凑合。

内建质量

这边才是真正意义上的测试，包括功能测试，性能测试，高可用测试，混沌测试，变异测试等。

质量保障实践

下面通过效率工程、工作规范、内建质量这3个方面，阐述质量保障在业务中的实际落地情况。

质量保障第初级阶段

当前阶段为项目初创时期，以活下去为目的。这时就需要使用开发主导，实验为先的模式。此时要的不是UI点美观，优秀的性能，快速的做出满足客户需求的功能才是这一阶段的重点。此时项目的重点在于快，重点在于保障版本按期发布，接纳有损发布。代码规范限制研发速度，流程规范只会束缚产品无法快速见用户，只需要轻量的流程保障发布不会出现大纰漏，出现问题能够及时止血，因此对于强制升级功能是核心即可。
这一阶段的基本情况为：

需求管理未规范，word满天飞，管理混乱。
缺陷管理缺失，有问题直接聊天工具沟通，研发人员经常修了那个忘了这个，没有统一的bug反馈渠道。
用例管理全无，测试人员xmind或者excel编写用例。
没有流水线，研发手动部署研发产物。
用户反馈没有统一入口，线上问题不能及时发现

还有一些其他情况，在这一阶段，基本都是纯收工测试，保障新功能以及核心功能的可用性即可，这一阶段就一个字：快！

引用其他文章的话：

基础设施这里更依赖既有的平台和工具来支撑，无暇定制。
流程规范只会束缚产品无法快速见用户，只需要轻量的流程保障发布不会出现大纰漏，出现问题能够及时止血，因此对于强制升级功能是核心即可；
人员管理基本不涉及。整个项目人员12个，人员比较少，沟通问题不凸显，因此未设定各个角色的owner，以及owner对应的职责内容也未形成规范。

质量保障第二阶段

创业成功，项目稳定了，就进入了质量保障第二阶段了，建立工程规范，以自动化手段提高效率。这一阶段要建立需求管理，迭代流程管理，用例管理，缺陷管理等规范，建立统一的用户反馈上报入口机制。在这一阶段，为了让项目平稳运行，靠的是人为规范的约束。

迭代流程管理

定义一个固定的上线时间一周一迭代或者两周一迭代的机制，约束研发，防止乱上线的情况发生。对于目前的项目，其迭代周期如下：
在这里插入图片描述

在此期间固定需求评审或者用例评审时间，复盘时间等，根据不同业务形态灵活调整。

需求管理

此时需要一个统一的平台来管理需求，不能再存在各自线下的主机中了，不利于需求的统一管理以及透明化的建设。主要要做到以下几点：

产品建立需求编写规范，让需求的可读性增加，可以让新同学快速理解需求内容。
将编写的需求按照迭代归档，清晰明了的展现当前迭代的需求。
需求分模块归类，便于回顾查询往期需求。
需求状态的确定，比如需求已录入->需求评审通过->编码完成->测试完成->部署完成等。
状态的流转规范，需要研发测试生产同学自觉流转状态。
需求评审阶段确立，需要相关研发测试同学对需求进行评审，并进行工期评估。
对每个需求本身的价值做一个评估，计算出一个估值并确立优先级。

用例管理

用例不是用完就扔，这是软件测试原则的10个原则之一，对于历史用例需要专门的平台进行统一管理。主要做到以下几点。

用例状态，包括正常、废弃。
用例等级，标记什么是核心模块用例等级就为高。
用例类型，包括功能、接口、性能。
分模块管理，将用例分模块，便于回归。
确立用例编写规范，比如前置、步骤、结果。
用例关联需求。

缺陷管理

缺陷管理也是质量保障重要的一环，对缺陷进行全过程的跟踪也是十分有必要的。

缺陷状态的确立，由测试新建缺陷，研发接受缺陷处理分析给予反馈，定位缺陷类型，流转到测试，测试进行回归后关闭bug
缺陷类型的分类规范确定，利于定位问题原因，复盘，下面是分类的一个参考：

需求优化（体验问题、功能缺失或不满足用户侧需求类的，需要通过需求变更/转需求方式解决问题的）
程序bug（程序编码问题导致的，需要修改代码重新部署来解决问题的）
性能问题（程序基本功能正常使用，但在高并发场景下存在卡顿、异常的情况，需要通过性能优化来解决问题的）
基础设施（使用的公司内部基础服务导致问题的，如网络异常、中间件问题、云服务问题、taf平台问题、sumeru平台问题、stke问题、其它）
线上维护（程序运行使用相关的维护工作导致问题的，如配置、数据库操作、数据更新、部署平台操作等）
运营问题（产品运营过程中计划、人为不当操作、脏数据等原因导致的）
合作方问题（与外部合作方交互且因合作方产品存在问题导致的）
无效问题（无需解决、人为无效操作问题、无法复现归为此类）

缺陷编写规范的确定，经常会存在bug提太多，bug单太潦草导致测试回归的时候不知道自己当时写了什么，有时候研发也看不懂bug单的内容，沟通效率低下，就需要一个bug单编写规范约束测试人员提单，下面是一个参考：
【问题描述】：填写出问题的任务id，情报id，url等信息，简要描述问题现象
【详细步骤】：作业员如何操作出现相关问题
【预期结果】：正常情况下的结果
【实际结果】：当前出现的结果
【附件】：附带截图，视频，方便定位问题
缺陷原因的填写，每个bug都存在其原因，在研发解决问题后督促其填写原因方便复盘。
缺陷关联需求，做到每个缺陷都能到找引起这个缺陷的需求是什么，这样可以不断学习，更利于精准回归工作的开展。