生命不息,测试不止!

发布新日志

  • 软件测试的10大原则

    2007-08-27 17:55:56

    软件测试的10大原则

    原则1:测试是一个持续进行的过程,而不是一个阶段。

           现代的测试已经发展成为一个全过程的验证和确认活动,它贯穿于整个开发生命周期的始末。为了获得最大的受益,测试的开发和准备必须在编码之前就开始,同时为了保证最终的质量,必须在开发过程的每个阶段都保证其过程的质量。

    原则2:测试必须被计划、被控制,并且被提供时间和资源。

          测试并不是一个随机的活动,测试必须被计划,并且被安排足够的时间和资源。测试活动应当受到控制,测试的中间产物应当被评审并纳入配置管理。

           一个好的测试计划应当:

    l         在检测主要缺陷方面有一个好的选择

    l         提供绝大部分代码的覆盖率

    l         是灵活的

    l         易于执行、回归和自动化

    l         定义要执行测试的种类

    l         清晰地文档化了期望的结果

    l         当缺陷被发现时,提供缺陷核对

    l         清晰地定义测试的目标

    l         明确测试的策略

    l         清晰定义测试的出口标准

    l         没有冗余

    l         确认风险

    l         文档化测试的需求

    l         定义可交付的测试件

    原则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:测试是开发的朋友,不是开发的敌人

           测试人员和开发人员经常无法有效的一起工作。这一方面是因为双方工作的性质不同(开发的工作是构建系统,而测试的工作是去破坏系统),另一方面也可能是因为管理的原因造成了测试和开发之间的矛盾。不管是什么原因,这个矛盾,对于产品来说不是一件好事。

数据统计

  • 访问量: 2913
  • 日志数: 5
  • 建立时间: 2007-08-26
  • 更新时间: 2007-09-02

RSS订阅

Open Toolbar