[初级理论]给老婆做测试培训-05

老婆：我记得测试在软件工程中是永无止境的一项工作，那如何度量我们工作的呢？

我：   测试为什么是永无止境的？那归根到底就没有发现的bug永远在哪里。

 

记得曾有一位哲人说过：你的知识面就象一个球面，知识越渊博，球面就越到，同样在球面之外的东西就知道不知道的越多。

运用于测试也是一样的，测试的面越广，我是过分的超出需求，我们可控的范围就越小。

所以在测试领域就也同样应用80/20法则去解决我们的未知，即一个阶段的测试只能测试出该阶段的80%的缺陷。

 

记得以前有过这样的题目：

一位项目经理分别让两个独立的测试组去测试同一个项目，结果测试组A发现了15个bug，测试组B发现了20个bug，而他们共同发现

10个bug，那评估项目中最有可能如下的那个bug数目（）

A. 16            B. 25           C. 30            D 35

其实这个就是一个很好的80/20的应用，首先我们考虑的bug数量肯定至少15+20-10=25个，那如果我们刚好选择这个项目，那就掉进了

该题的陷阱，当然也有很多大脑一热两个项目组一加就得出D了。

排除法算是C，但是C就是25+25*20/80 ~ 30.

 

虽然测试时永无止境的，所以我们人为的定义标准，这样就有了行业标准和公司标准两种了。

成熟的软件公司会有自己的UI标准，CODE标准，文档标准，以及每个阶段发布准入准出标准。

1. 测试依据

    软件需求，开发设计文档，公司标准（UI/文档/Code/流程）；

 

2. 测试执行

    公司流程，项目计划，缺陷管理（业内/公司标准-优先级，严重性）；

 

3. 测试准入/准出

    冒烟通过标准，缺陷数目以及优先级严重性，文档完备；

 

4. 测试工作

    用例数量，执行数量，缺陷数量，技术支持；

    用例数量：大小标准要统一，也可以根据需求点大小或者模块大小定case数量 - 计划阶段完成；

    执行数量：分配的任务，案例的难易程度 - 设计case时评估执行加权值；

    缺陷数量：考究严重性和数量，后期的验证 - 由于时间的限制，可以和执行相关联评估；

    技术支持：对其他成员组的支持，包括文档，代码，缺陷解释等；

    其他包括：测试回退现象，业务需求点遗漏，消极怠工等 - 这些可以适当匹配个人表现，通常只做参考，考虑个人能力等因素不

                   能一概而论，更重要的是培养下属的职业责任心，严谨科学的开展测试工作，对人员搭配要合理；

    以上综合以后，根据任务分配，个人的能力和薪水再次加权，这样可以得到各成员的自己职责的业绩；

 

测试就是这样，接触多了也是和开发一样是一份很重要又是可以很轻的工作，如何看待这份职业就是如何看待自己的人生。

我是从开发转过来学习测试，从来没有后悔过，毕竟后悔也没用，O(∩_∩)O