从测试本质看质量

点击👆蓝字 关注我们

本文作者｜周小宁

导语

“质量”在软件研发中，是一个不容忽视的维度。在早期的软件研发过程中，质量是测试人员的事情，是一个被认为是理所应当的一件事情。随着敏捷思想的兴起与传播，更多可以提升研发质量的实践被大家所知晓和采纳，从被动的质量评价测试，到主动的缺陷预防，质量内建已经渐渐作为主流的质量思想。

关于质量，不管是各类标准（ISO/IEC/GB），还是质量模型，对于软件质量的定义都大体相同，都可以理解为：软件质量就是“软件能力与显性地和隐性地的使用要求相一致的程度”。其中显性要求就是在合同、客户要求、产品需求文档等成文信息中明确记录的要求，隐性要求则来源于一些惯例、一般做法、不言而喻的要求等。

标准文件中的质量定义：

《GB/ T25000.10—2016 》中关于软件质量的定义 : 在规定条件下使用时，软件产品满足明确和隐含要求的能力。

《ISO/IEC 25000》中将使用软件质量模型，定义质量由八个软件质量特征组成：功能性、性能效率、兼容性、易用性、可靠性、信息安全性、维护性、可移植性。

对于质量的评价，软件研发过程中大部分都采用测试这种手段来进行评价。人们寄希望于通过测试，拿到测试报告证明，软件质量就有了背书，就达到了满足发布的准入要求。这是对测试这种手段寄予了厚望，但常常也因此出现质量有问题就是测试人员背锅的情况。对于测试人员来说，如何推动团队的质量意识，认清质量需要团队共同构建，也成为了现在测试人员必不可少的技能。

《GB 15532-2008计算机软件测试规范》关于计算机软件的测试目的定义是:

a) 验证软件是否满足软件开发合同或项目开发计划、系统/ 子系统设计文档、软件需求规格说明、 软件设计说明和软件产品说明等规定的软件质量要求;

b) 通过测试, 发现软件缺陷;

c) 为软件产品的质量测量和评价提供依据。

最近，阅读了一本周海旭老师的《测试设计思想》一书，颇有感触，对于质量与测试活动有了更深的思考。本文从测试活动本质出发，来聊一下质量内建这回事。

测试的本质：一种比较活动

在《测试设计思想》一书中，从抽象角度概括，测试活动本质，包含四个方面的要素：

• 理想结果

• 现实结果

• 现实结果与理想结果之间的比较活动

• 现实结果与理想结果之间的差异

因此，给出的测试定义是“在理想与现实之间观察求索”的一种活动。

不难发现，在软件研发中，测试本质是一种比较活动，影响这个比较活动本身的是以下三个要素：

• 理想结果：来源于软件系统的使用者的使用要求，但通常更多的事来源于产品经理加工的产品需求文档；

• 现实结果：是经过产品、开发多方角色共同协作，由开发人员主导加工而成的可工作的软件，在测试人员对软件执行测试过程中观察发现得到的现实结果；

• 测试活动本身：测试人员进行的案例设计、选择、评审、执行的活动；

从测试活动角度看，质量可以理解为“理想与现实的相符程度”。现实越接近理想，质量越好，反之，现实与理想相差越大，质量越差。而影响测试活动（判断理想与现实的相符程度）的一个重要因素就是理想结果与现实结果的清晰、准确程度，很明显的是理想结果与现实结果越清晰、准确，对于测试活动的影响就越小。而进行测试活动获得的结果，就是现实结果与理想结果之间的差异，通常又称之为缺陷，当测试活动发现不可接受的缺陷，相符程度则较低，也代表着质量比较差。

术语澄清：

这里的“测试”或“测试活动”是专指在软件研发过程中，测试人员实际进行用例设计、编写、执行测试用例的活动总和， 非广义上测试人员参与的活动。

这里的“质量”（“理想与现实的相符程度”），是进行测试活动的目的或测试活动得出的结论。

为了能够在测试活动的结果中得出符合质量的要求，可想而知，对于影响测试活动的三个因素都需要进行控制和干预，才能做到。不难发现，在实际的软件研发过程中，只有“对比活动”这一因素本身主要是测试人员产出的内容，另外两个因素测试人员都不是主力。因此光靠测试这一角色，是无法实现或得出软件是符合质量要求这样的结果。对于测试人员而言，也需要改变原先只关注“对比活动”这一因素的现状，开始需要对影响测试活动的另外两个要素进行控制与干预。

那么，在软件研发过程中，对理想结果、现实结果这两个要素有哪些明显的影响因子，接下来让我们一起看看。

理想结果的影响因素

理想结果作为测试对比活动中的基线，是一个关键要素，如果基线本身是错误的，那么后续的任何活动都是基于一个错误的基础上进行的，那么可能造成的返工成本可想而知是一个巨大的浪费。

1. 需求的产生与加工过程，涉及关键角色：

产品经理

软件质量的理想结果，来源于软件系统用户的使用要求，但开发与测试人员通常无法直接从用户那直接获取到清晰、明确的使用要求，更常见的是用户一句话需求或者经过产品经理加工过后的产品需求文档。需求的清晰、准确是影响进行质量评价的首要因素，因为需求是后续所有阶段的源头。

产品需求的产生与加工过程是产品经理领域的专业内容，首当其冲的产品经理自然是产品需求质量的第一责任人。除了常见的对需求内容有规范的要求如要有详细的验收条件、实例化需求等方式，测试人员还可以考虑如下实践来提升需求质量：

建议措施1：需求评审

需求评审是一个关键的活动，在需求流转入排期开发之前，测试人员、开发人员一起参与需求的评审、讨论，从各自对用户理解的视角、对系统理解的视角等多维度帮助产品经理完善需求内容。通过这样的方式，可以有效的帮助提升需求的质量。因此，做为测试人员，不仅仅需要了解被测系统，还需要更多的使用用户思维，场景化、系统化的思维去思考需求内容，在进行需求评审时候提供更多的参考，帮助提升需求质量。

2.需求的澄清过程，涉及关键角色：

产品经理、开发人员、测试人员

产品需求产生于产品经理，流向的对象是开发人员和测试人员，通常在研发过程中会进行需求澄清活动。通过产品经理讲述的方式，让开发人员、测试人员理解需求内容。开发人员使用自身理解的理想结果进行设计、编码等开发活动，测试人员使用自身理解的理想结果进行测试分析、设计等测试活动。如果三方角色理解的理想结果不一致，则会造成后续的测试评价基准有偏差，得出的质量评估不可靠的问题。因此如何确保三方人员理解一致，避免出现质量隐患，是需求澄清过程需要关注的内容。

通常，产品经理需要在进行澄清之前，提前发出需求文档以便参会人员提前阅读了解细节，需求文档通常也会要求以结构化的形式展现，包含有明确的验收条件等，可以帮助阅读人员快速理解需求内容。此外，需求的澄清通常不是一次性的活动，而是一个持续性的活动，研发过程中有任何环节对需求有疑问，应该持续沟通，尽早解决。

除了上述的建议以外，测试人员还可以考虑如下实践来预防澄清过程的质量风险：

建议措施2：开发反向澄清

对于经常出现开发人员理解的和理想的需求不一致的情况，可以在研发过程中增加开发反向澄清环节，通常也叫开发反串讲，开卡等。通过让开发人员陈述自己对需求的理解，产品经理、测试人员参与反馈，帮助补充完善理解缺漏、不一致的地方，从而降低开发理解与理想需求的偏差，减少偏差带来的质量隐患。

建议措施3：测试用例评审

对于经常出现测试人员理解和理想的需求不一致的情况，一方面需要加强测试人员对业务、系统了解能力的培养，另一方面可以考虑增加测试用例评审环节。由产品经理、开发人员评审测试人员的测试用例，帮助完善测试用例的覆盖场景、补充遗漏、避免出现不一致的地方，从而降低因测试人员理解偏差带来的质量隐患。

现实结果的影响因子

现实结果来源于测试人员对实际的软件系统进行观察得出来的，而影响软件系统产生现实结果大体会有以下两方面。

3. 开发的设计、编码实现过程，涉及关键角色：

开发人员

软件系统由开发人员一手设计、编码实现而成。当软件实现后，软件的初始质量就已经固定了，因此业界常有句名言说：“优秀的软件质量是免费的，因为它只需要设计和实现一次。”。而设计与编码很大程度上都依赖于开发人员的专业能力，如果团队都是由了解业务、熟悉系统、编码能力超强的开发人员构成，那么潜在的质量隐患就相对比较小。然而实际研发团队不太可能都是由这样的大牛组成，因此有效的过程质量控制在一定程度上可以降低由于不良的设计与代码实现带来的质量风险。

建议措施4：开发设计评审、代码评审

开发设计评审、代码评审都意旨通过同行评审，降低由于开发人员因自身经验不足、考虑不足等因素造成的不良设计与编码，重复造轮子等质量风险，提升开发团队整体的代码可维护性。对于测试人员来说，参与评审能够了解到系统背后的设计逻辑，相对应的能够更好的设计应对的测试策略，提升测试的有效性，不过因此对测试人员的要求也比较高。

4. 集成与环境部署过程，涉及关键角色：

负责集成和部署的角色

软件编码实现后需要通过一系列的集成部署才进入到测试阶段，且通常软件并不是作为一个独立的个体进行测试评价质量的，软件的运行需要有网关、中间件、存储等配套的环境设施才能够运行，因此集成和部署过程的一致性程度和质量高低也是影响软件系统产生理想结果的重要因素。

建议措施5：持续集成与持续部署（CI&CD）

在研发团队中会专门负责集成与部署的角色，通常会由开发人员或者测试人员负责。通过引入标准化、自动化的集成与部署工具，降低由人工操作带来的不一致的隐患，这也是现在常用到的持续集成与持续部署（CI&CD）实践。

持续集成与持续部署（CI&CD）实践并不是简单的引入工具，更多的引入一种快速反馈机制。通过频繁提交，快速进行集成、部署、测试过程，把质量反馈从原来的几天缩短成了小时乃至几分钟。快速的反馈机制，有助于提高团队应对变化的响应能力，尽早发现可能隐藏的问题，减少过程质量风险。

质量建设需要研发团队全员参与

软件研发是各方参与人员进行知识协作的研发活动。其中测试活动的三个因素中，只有“对比活动”这一因素是由测试人员自身控制的，“理想结果”与“现实结果”这两个因素是主要受产品经理、开发人员所影响。研发团队成员需要认识到，测试活动本身并不能提升软件质量，软件质量的提升需要团队全员的参与。

从测试人员角度来看，想要提升软件质量，不仅仅需要做好“对比活动”的工作，也需要更多的对“理想结果”与“现实结果”进行干预和控制，提升团队全员的质量参与意识，来保证软件产出的高质量。前文列举了一些建议措施，读者可以根据自身所在团队的过程质量情况，选取适合自己团队的措施来实施，避免盲目应用。

END

测试敏捷化直播约起来哟～

和本文作者在线聊起来

点分享

点收藏

点在看

点点赞