质量管理之测试流程两三事

Posted 2021-06-29 软件测试小dao

引言

今天分享一下个人对于质量管理流程的看法，也是基于CMMI，看看这里面有哪些东西可以为我们所用。

从员工（特别是从我们普通测试人员）角度来说，研究CMMI有哪些好处呢？

有“正规的”、“完善的”测试流程和质量管理流程可以借鉴。特别是对一些“项目管理水平低下且流程混乱”的企业工作的同学来说尤为重要。很多企业在面试时都会关注前一家单位的工作流程，研究CMMI能在面试时加分，应聘测试经理大都需要具备质量管理经验。

有大量现成的项目资料可以借鉴。认证CMMI时，咨询老师会提供一些其他单位的项目资料（特别是测试用例），这对于为文档模板犯愁的同学、对疑惑用例该怎么写的同学帮助会比较大。

提升管理能力。管理的本质就是解决问题，研究CMMI后会发现自己解决问题时的思路更开阔，能有效的提升解决问题的能力。

提升职场软实力。比如可以做出既美观又实用的BUG统计报表。

既然有这么多益处，为什么又有那么多人反感CMMI呢？觉得整天写文档，然后写出来以后还没什么实际用处，吃力不讨好？

齐白石有句话“学我者生，像我者死”。流程改造最重要的就是要符合公司的实情，如果因为CMMI里面的流程“科学、规范”就冒然套用，那最后的结果必然不乐观。其实CMMI本身也提倡要根据企业的实情来进行裁剪，换言之，我们要取其精华去其糟粕。

CMMI强调计划、监控、标准、可度量。

计划：“凡事预则立不预则废”，这是普天皆知的道理。但现实是每个人做计划的能力是不一样的。如果想成为一个特别会做计划的人，可以去研究CMMI。

监控：这主要是从管理角度来说的。我曾经有个下属，汇报工作说三天完成了一个新需求的用例编写，但我检查后发现就增加了两条用例。也曾有一个下属，负责一个模块4个月了，我却发现还有大量的主流程相关的bug没有发现。

标准：做事情标准很重要。举个例子，什么算是需求了解清楚了？曾经安排一个下属去参加需求评审，回来跟我说需求了解清楚了。然后我问了几个问题（为什么要修改那个功能？要解决什么问题？怎么修改的？影响范围有哪些？…）却都回答不上来。再比如说测试通过的标准是什么？版本送测的标准是什么？…这些都应该有一些约定。也可能有人说，自己公司编写了很多标准文档，但平时根本用不上，那些文档有用吗？我想说这跟法律一个道理，我们大多数时候也用不到法律，标准的作用是在需要用的时候有据可查。一直用不上，说明你们做的还不错啊（也可能是标准不合理）。

度量：CMMI规定，要有专人（即QA，我们测试人员是QC）负责标准的检查。这样做有有个很明显的好处：减少一些常规问题的扯皮和沟通成本。比如说很多人都经历过需求和设计提供的不明确的问题，这个时候我们测试人员去说人家工作没做好容易招人记恨，不说吧影响自己工作。这个时候QA就能很好的承担起这个职责，督促产品和架构师提供更清晰准确的需求和设计。

总而言之，多吸取CMMI在计划、监控、标准、可度量方面的思想，但不要盲目套用。

CMMI测试流程

下图是CMMI中定义的测试流程：

1 测试计划

CMMI中定义了《总体测试计划》《单元测试计划》《集成集成计划》《系统测试计划》《验收测试计划》。里面的内容虽然不一样，不过都是围绕着5W1H的原则去说。有兴趣的朋友可以看看对应的模块。

2 编制测试需求

有的单位里接到需求后，就开始着手写测试用例。当需求比较复杂时，这样的做法容易带来新问题，比如不利于评审（效果差）。

CMMI中强调的一个文档是《 需求跟踪矩阵》（如下图）：CMMI期望通过制定矩阵跟踪表，达到需求的在详设和编写用例时被完全覆盖。但生产过程中，需求很难在最初就完全明确下来，且会一直变化。

我们工作中常用的做法是用思维导图把测试点整理出来。虽然虽然在这一环节上多花了时间，但总体时间成本是会下降。

3 编写测试用例

CMMI中将用例分为功能测试用例、非功能测试用例（非功能测试用例包括性能测试用例、压力测试用例、图形界面测试用例、数据库测试用例等）。

我们可以将非功能测试用例整理成为“公共测试用例库”，以后再写用例时，就不用花很多时间去编写比如图形界面相关的用例了。

4 单元测试

单元测试基本上都是开发人员的工作，他们会做一下主流程、格式化、数据验证、异常提交等方面的测试。

很多测试同学听过这句话“程序员应避免测试自己编写的程序”。我发现有一些测试同学对这句话存在误解，认为研发人员由于“定势思维”会想当然的认为自己开发出来的是没有问题的，发现不了问题。其实从我合作过的研发来看，大多数开发对于业务的正常场景、异常场景、需求改动后的影响范围都是大概清楚的，也就是说可以满足送测标准。 而且团队中常常每个开发单独负责一个模块，这意味着他们对其他人的模块去从逻辑上验证是有困难的。

个人对这句话的理解是，互相检查代码，一方面是开发经验丰富的程序员可以帮忙优化实现方法，一方面也是避免程序员忘记备注、或者命名方式方式不规范等问题。

5 集成测试

集成测试在大多数企业、测试团队、项目中都会做。某些情况下，我们也会叫它“冒烟测试”。

经常有面试官会问集成测试做什么工作，跟系统测试有什么区别？这里列一下集成测试的目的和工作内容：

集成测试目的是确保各单元模块组合在一起后能够满足设计要求运行，并确保增量组装的构件正确。它所测试的内容包括单元间的接口以及集成后的功能，对以前的集成进行回归测试。

集成测试主要完成：

对模块和子系统的连接进行测试，确保各程序模块之间无错误连接

验证整个软件系统或子系统的输入/输出处理是否达到设计要求

验证软件系统或子系统（业务方面的）正常处理能力和异常处理能力

验证是否达到产品需求，是否遵循系统设计

集成测试用例

在某些行业比如银行，集成测试用例可能是由开发人员来编写（也是他们执行）。他们会在完成集成测试之后送测，送测的文档中包括《集成（联调）测试用例》、《集成测试报告》《送测说明》。在《集成测试报告》中甚至会添加测试通过的截图。 在送测说明中又会描述本次修改的内容、修改的原因、以及本次修改的影响范围。

6 系统测试

跟集成测试的区别，就是还需要做兼容性测试、性能测试、安全测试、发布测试等等。

7 缺陷管理

缺陷管理的最终目标是最大限度地减少缺陷的出现率，从而提高软件产品的质量。细分为：

从缺陷发生到结束的全生命周期进行跟踪管理，尽可能发现所有的缺陷，确保每个被发现的缺陷都能够被解决；

收集缺陷数据并根据缺陷趋势图识别测试过程的阶段；缺陷趋势图是确定测试过程是否结束的重要依据；

在已收集到的缺陷数据的基础上进行统计分析。总结缺陷出现的原因、类型和规律，采取相应措施避免该类型缺陷再次出现，并在开发过程的早期阶段予以确定，起到缺陷预防的作用，并作为组织的过程财富。

缺陷分析

典型缺陷统计：通过缺陷的数据分析，总结缺陷出现的原因、类型和规律，采取相应措施避免该类型缺陷再次出现，提高产品质量。

线上bug统计：针对线上bug，分析bug原因，记录修改过程，并从测试角度分析为什么会漏测？以前怎么测试的？以后怎么改进测试的方式？

产品缺陷趋势图：统计项目组阶段缺陷的趋势图，用于分析产品的质量。

问题关闭情况图：

O/C图：分析open和closed状态的bug的趋势