缺陷预防

摘自《大话软件测试》&《赢在测试2》

首先看一个故事

                                                            扁鹊的医术

魏文王问名医扁鹊说：“你们家兄弟三人，都精于医术，到底哪一位最好呢？”

扁鹊答说：“长兄最好，中兄次之，我最差。”

文王再问：“那么为什么你最出名呢？”

扁鹊答说：“我长兄治病，是治病于病情发作之前，由于一般人不知道他事先能铲除病因，所以他的名气无法传出去，只有我们家的人才知道。我中兄治病，是治病于病情初起之时，一般人以为他只能治轻微的小病，所以他的名气只及于本乡里。而我扁鹊治病，是治病于病情严重之时，一般人都看到我在经脉上穿针管来放血、在皮肤上敷药等大手术，所以以为我的医术高明，名气因此响遍全国。”

从软件工程的角度，缺陷发现的越晚，修复的代价就越大。软件生命早期，在需求阶段就会存在（完整性、正确性）隐患了，此外每一个实现阶段之前，我们都会审核研发工程师的技术文档、技术模型，那都是预防的一种方式。

缺陷预防也称早期测试（EarlyTesting）。我们需要从需求、架构和编码等多方面，提高

早期测试活动的效率，才能做好测试工作。

                                                                如何做缺陷预防

            测试有两个阶段：第一阶段是发现缺陷，只要发现了 bug 就很开心，各种类型的 bug 照单全收；第二阶段是在第一阶段的经验积累的基础上，建立质量保障体系，并为之提供具体的方法论。缺陷预防属于第二阶段。

缺陷预防的三个板块

概括起来说，缺陷预防有三个板块：

1．需求

2．架构设计

3．编码

下面逐一做个介绍。

            在需求方面，例如，结对需求评审是一种很好的需求缺陷的缺陷预防方法。两个人一起评审需求，其中不包括需求的编写者。如果两个人对同一条需求有异议，则表示需求描述存在二义性的缺陷，需要再做改进。两个人结对还有一个好处，就是人少，成本低。

            在架构设计方面，可以从软件架构的非功能性属性倒推软件架构是否能够满足这些属性。设计上不能有双向依赖，而应当是单向依赖，也没有依赖路径的缺失。

        对于编码的缺陷预防方法大家可能比较熟悉，主要是白盒测试技术，有静态的、动态的，有人工的、自动的，有代码扫描或者单元测试等。最好是能够积累编码方面常见缺陷的历史数据和模型，这些数据对于编码的缺陷预防更有指导意义。

                                                                    测试工程师做缺陷预防

            测试工程师在缺陷预防方面能够尽早做些什么呢？

            在需求方面，如果可能测试工程师可以定义需求描述的模板，保障需求文档结构的质量，以及主导和实施结对需求评审。

            在架构设计方面，测试工程师可以尝试着去定义架构文档的质量模板，辅导开发人员使用，开发人员做架构设计的时候可以把它作为一个设计质量标准。应用架构缺陷识别和设计缺陷识别的方法直接发现设计缺陷。

                在代码方面，测试工程师可以提供白盒测试工具和方法的技术支持，以及积累和汇总常见的编码缺陷列表，供开发人员使用。