软件测试的10大原则

yulele

软件测试的10大原则
原则1：测试是一个持续进行的过程，而不是一个阶段。
        现代的测试已经发展成为一个全过程的验证和确认活动，它贯穿于整个开发生命周期的始末。为了获得最大的受益，测试的开发和准备必须在编码之前就开始，同时为了保证最终的质量，必须在开发过程的每个阶段都保证其过程的质量。
原则2：测试必须被计划、被控制，并且被提供时间和资源。
        测试并不是一个随机的活动，测试必须被计划，并且被安排足够的时间和资源。测试活动应当受到控制，测试的中间产物应当被评审并纳入配置管理。
        一个好的测试计划应当：
        在检测主要缺陷方面有一个好的选择
        提供绝大部分代码的覆盖率
        是灵活的
        易于执行、回归和自动化
        定义要执行测试的种类
        清晰地文档化了期望的结果
        当缺陷被发现时，提供缺陷核对
        清晰地定义测试的目标
        明确测试的策略
        清晰定义测试的出口标准
        没有冗余
        确认风险
        文档化测试的需求
        定义可交付的测试件
原则3：测试应当分级别。
测试级别
测试级别        测试活动        测试类别        测试的文档基础        测试责任主体        测试关注点
级别0        结构化检视        非计算机测试（静态测试）        各类文档        检视组        各方面
级别1        单元测试        白盒测试        软件详细设计文档        开发人员        软件单元设计
级别2        配置项集成测试        白盒测试        软件概要设计文档        独立测试组        配置项设计/构架
级别3        配置项资格测试        黑盒测试        软件需求规格说明书        独立测试组        配置项需求
级别4        集成测试        白盒测试        系统的子系统设计文档        独立测试组        系统设计/构架
级别5        系统测试        黑盒测试        系统规格说明书        独立测试组        系统需求
级别6        DT&E测试        黑盒测试        用户手册        独立测试组        用户手册的一致性
级别7        OT&E测试        黑盒测试        可操作性需求文档        可操作性测试组        可操作性需求
级别8        外场测试        黑盒测试        交付计划（场地配置）        外场安装组        场地需求
其中：DT&E——Development Test and Evaluation
      OT&E——Operational Test and Evaluation
原则4：测试应当有重点
尽管测试需要按照一定的级别进行，但资源和时间是有限的，实际上我们不可能无休止地进行测试，因此在有限的时间和资源下如何有重点地进行测试是测试管理者需者需要充分考虑的事情。测试的重点选择需要根据多个方面考虑，包括测试对象的关键程度，可能的风险，质量要求等。这些考虑与经验有关，随着实践经验的增长，判断也会更有效。
原则5：测试不是为了证明程序的正确性，而是为了证明程序不能工作
        正如Mayer所说，测试的目的是证伪而不是证真。事实上，证明程序的正确性是不可能的，一个大型的集成化的软件系统不能被穷尽测试以遍历其每条路径。即使遍历了所有的路径，错误仍有可能隐藏。我们做测试是为了尽可能地发现错误。
原则6：测试是不可能穷尽的，当测试出口条件满足时就可以停止测试
        我们说测试是为了发现错误，一个好的测试是发现以前没有发现的错误。但是这个要求可能会使人走入极端。其实，不同的系统有着不同的质量要求，对于质量要求严格的系统，可以需要进行长时间的、全面的测试，尽可能地挖掘系统中的缺陷。然而对于质量要求不是很严格的系统，系统是允许出现错误的，因此我们通过测试的目的是使系统的缺陷数量降到可接受的范围内。
        我们在测试时应当去寻找那些用户不可接受的错误，而不是漫无目的地去搜索错误。同时我们应当对测试定义合理的出口标准，这是因为测试是没有穷尽的，终归会发现系统的问题，然而我们不能无休止地去寻找这些问题。当条件满足时，我们就应当停止测试。而测试出口条件的设置需要考虑系统的质量要求及系统的资源要求。曾经有人说过：当时间和资源用尽时，测试也停止了。这是没有办法的最好办法。
原则7：测试是开发的朋友，不是开发的敌人
        测试人员和开发人员经常无法有效的一起工作。这一方面是因为双方工作的性质不同（开发的工作是构建系统，而测试的工作是去破坏系统），另一方面也可能是因为管理的原因造成了测试和开发之间的矛盾。不管是什么原因，这个矛盾，对于产品来说不是一件好事。
        开发和测试作为一个整体都是服务于产品，都要为产品的质量负责。从这一点来讲，开发和测试的利益是一致的。要知道，如果在产品交付使用之前，测试人员遗漏了一个问题，而这个问题最终在用户手上被发现，并产生比较严重的后果时，那么，无论是开发还是测试，最终都逃不了责任。我们要为质量服务，测试的目的是要去寻找错误，最终提高产品的质量，而不是去找开发的茬，只有当双方都认识到这一点时，开发和测试就有共同交流的基础了。测试人员应当是开发人员的朋友，他们帮助开发者寻找遗留在产品中的缺陷，使得开发人员能够生产更好的产品。测试和开发不应当是敌人。
        尽管有很多开发人员和测试人员也认识到了这一点，然而，在实际操作上，总不免产生摩擦，Brian Marick在如何处理这方面矛盾上给出了一些好的建议：
        以一种开发人员希望你在周围的方式定义自己的角色。帮助开发人员在缺陷被别人看到之前排除掉缺陷，这可以降低整个项目的成本
        解释自己和自己的工作，以便在疑惑的时候可以获得开发人员的帮助。降低开发人员对你进行不利判断的概率，并采取一些方式让开发人员相信缺陷报告不应被看成是一种威胁
        缺陷报告的书写应当清晰、无歧义
原则8：测试人员应公正地测试，如实地记录和报告缺陷
        我们说测试是开发的朋友，这并不等于测试就应当处处维护开发人员，替开发人员隐瞒缺陷或纵容缺陷的存在。这是对朋友的误解。我们要知道缺陷的存在最终只会影响到整个产品。在开发过程中，测试人员一直承担着质量把关人员的角色，尤其是测试将会是产品最终交付给用户之前的最后一道关卡。如果测试人员不能站在公正的立场上去执行测试，并如实地记录和报告缺陷，那么最后受伤的不仅仅是开发人员，还会包括测试人员自己。对质量负责，不仅仅是对自己负责，也是对开发负责和对产品负责，这是一种职业操守。
原则9：测试自动化能解决一部分问题，但不是全部
        工具所能发挥的作用依赖于使用工具的人。因此，对工具的过分依赖将降低人的能动性，并最终使测试本身受到损害。适当的使用测试工具能够减轻测试人员的机械性工作，提高工作效率，而滥用工具会降低测试的质量。
原则10：测试不能仅仅包括功能性的验证，还应当包含性能、可靠性、可维护性、安全性等方面的验证
        有的公司产品的测试，其范围仅局限在功能领域内进行测试。这一方面可能有产品进度的压力影响，另一方面则是测试人员对测试的理解还比较局限。从用户角度来讲，其需求除了功能性需求外，还包括非功能性需求，有些非功能需求可能是显性的，而有些则是隐性的。我们在测试时，应当关注所有的需求，在验证功能的同时，还需要验证产品的性能、可靠性、稳定性、可维护性、安全性、可操作性、可安装性等。一个产品的缺陷往往会在其性能的边界上产生，如果我们忽视了这部分的测试，很多缺陷将漏过测试进入到用户手上。

zhizhishao

sdlkfj2

zhizhishao

3q

Cathy_Lu

我很赞成这里边的说法。特别是“测试是开发的朋友，不是开发的敌人”这一条。 如果大家都认同这一点，那么测试员和开发人员的关系就要好处理多了sdlkfj2