软件测试知识帖(101-114)

软件测试知识帖(101-114)

第101帖【2004－9－10】：USE CASE测试

USE CASE 是UML的核心，贯穿了RUP开发方法的整个过程，实际上RUP讲的就是一种USE CASE 驱动的开发方法。我们可以使用Use Case来表示用户的需求，并且Use Case避免了自然语言描述需求的二义性，可以自由的在不同的用户之间传递信息，那么我们在需求测试的时候，重点就落在了如何测试Use Case上了。

测试Use Case的方法有两种：

 1、使用Use Case建模工具，比如Rational Rose，这类工具本身具有检查Use Case的功能，包括语法的正确性，检查是否完整，是否一致等。但是这类工具在检查需求的遗漏或需求本身描述错误方面都比较弱，因此更好的测试方法是使用第二种方法；

 2、使用情景测试（Scenarios Testing）。在情景测试中，使用角色扮演的方法，在该方法中给每个项目组成员分配一个角色，角色可以是用户、系统本身、其他系统，有时是系统维护的实体。然后，小组对Use Case的每一个情景进行走读，扮演如何使用系统。在此过程中，将讨论谁负责什么事情，对每个角色的职责进行记录。让系统分析员扮演用户或客户的角色有助于真正地了解问题领域。另外，在情景测试过程中，让用户充分参与有助于发现一些遗漏或错误的需求。在第十五章中关于构架设计（Architecture Design）的评审方法中也用到了情景测试方法，可以一起进行参考。

第102帖【2004－9－13】：故障插入

故障插入（Fault Seeding）是一个统计的方法，用于评价遗留在一个程序中的故障的数量和种类。首先，故障被插入到一个程序中，然后，程序被测试，并且发现故障的数量被用于估计还没有被发现故障的数量。计算公式如下：

原本错误总数 =（播入的错误总数/发现的播入错误数）×发现的原本错误数

残留错误数 = 原本错误总数 - 发现的原本错误数

故障插入技术在软件可靠性方面应用的比较广泛，尤其在硬件的测试当中。例如一些汽车公司不惜花大价钱进行的汽车碰撞试验，为的就是发现汽车在碰撞过程中的潜在隐患，通过消除、改进这些隐患从而达到更高的性能。借鉴了硬件可靠性测试的方法，在软件测试中引入故障插入技术，其主要目的是为了评价系统的哪些模块，哪些代码是危险模块，危险代码，容易出问题，从而评价系统的容错能力。在该技术中使用了故障加速技术，通过有意的插入故障来调用系统的故障容错能力，从而在一个可控制的环境和期望的时间段内获得完整的测试。它和现有的测试方法相比，最大的不同在于测试开始时的系统状态不同，现有的测试都是从系统的正确状态开始，测试系统如何转入故障状态，而故障注入测试则是从系统的故障状态开始，测试系统在发生故障后的运行规律。

这里要重点指出的是，故障插入不关注为什么出现这样的故障，它关注的是出现了这样的故障后系统如何处理。

故障插入也被用于验证测试用例的有效性。其原理就是为了检查设计的测试用例是否能发现某一类型的故障，

人为在被测系统中引入该类型的故障，如果在测试过程中能发现这个故障的话，则应该也可以测试出系统原来就存在的该类故障。

故障插入技术的一个难点是插入的故障在程序中是否能够代表还没有发现的故障。实际上，由于软件的复杂性，故障的暴露往往和当时的运行环境、执行的路径有很大的关系，能测试出故障插入的故障并不一定总是能测试出被测系统原本存在的该类型故障，所以，在上述的最后一步推论不一定总是成立。但是就从验证测试用例的有效性角度来看，故障插入确实可以作为一种手段。

第103帖【2004－9－14】：功能覆盖率

功能覆盖率（Function Coverage）是属于黑盒测试范畴内的，在实际测试中，涉及到的覆盖率一般都是结构化覆盖率，与黑盒相关的覆盖率比较少。

功能覆盖中最常见的是需求覆盖，其含义是通过设计一定的测试用例，要求每个需求点都被测试到。其公式是：

需求覆盖 ＝ （被验证到的需求数量）/（总的需求数量）

在黑盒测试中还有一个覆盖叫接口覆盖（或者称为入口点覆盖），要求通过设计一定的用例使得系统的每个接口被测试到。

由于黑盒测试把被测系统理解为一个黑盒，测试时，输入测试数据，然后判定输出结果是否与期望结果一致。根据这个可以得到输入数据的覆盖情况，即通过设计一定的用例，要求每种数据情况都被测试到。

第104帖【2004－9－15】：面向对象的覆盖率

由于传统的结构化度量没有考虑面向对象的一些特性，如多态，继承和封装等。 传统的结构化覆盖必须被加强，以满足面向对象特性，上下文覆盖就是一种针对面向对象特性而增强的覆盖。

上下文覆盖可以应用到面向对象领域处理诸如多态，继承和封装的特性，同时该方法也可以被扩展用于多线程应用。通过使用这些面向对象的上下文覆盖，结合传统的结构化覆盖的方法就可以保证代码的结构被完整的执行，同时提高我们对被测软件质量的信心。

有三个面向对象上下文覆盖的定义，它们分别是：继承上下文覆盖（Inheritance Context Coverage），该覆盖率用于度量在系统中的多态调用被测试得多好。基于状态的上下文覆盖（State-Based Context Coverage），该覆盖用于改进对带有状态依赖行为的类的测试。已定义用户上下文覆盖（User-Defined Context Coverage），该度量允许上下文覆盖的方法被应用到传统结构化覆盖率无法使用的地方，例如多线程应用。

第105帖【2004－9－16】：软件质量三角

在一个软件企业中，要能够良性的发展，必须关注组织，流程和人三者之间的关系。组织是流程成功实施的保障，好的组织结构能够有效的促进流程的实施；流程对于产品的成功有着关键的作用，一个适合于组织特点和产品特点的流程能够极大的提高产品开发的效率和产品质量，反之则会拖延产品开发进度，并且质量也无法得到保证；对企业来说，人是最宝贵的财富，它们是技术的载体，然而在组织中优秀的员工总是缺乏的，即使你拥有他们，也会有种种限制妨碍他们发挥作用。比如如果他们一周工作50到60小时，你不可能指望他们还能处理太多的挑战性的问题。对于一个软件公司来说，无论是开发人员还是测试人员，都非常关心其今后的发展通道，如果有一条清晰的技术发展线为其指明今后的发展方向的话，这可以大大激励员工的士气和工作积极性，同时还可以为企业积累各方面优秀的人才。另外技术发展的方向应该与现在的开发流程和规范相结合，这样有利于专业技能的提高。

总之，组织，流程和人这三者是一个企业成功的铁三角，理想的情况下它们彼此促进，糟糕的情况下它们彼此制约。

第106帖【2004－9－17】：流程对质量的贡献

从一个软件企业的长远发展来看，如果要提高产品的质量首先应当从流程抓起，规范软件产品的开发过程。这是一个软件企业从小作坊的生产方式向集成化规范化的大公司迈进的必经之路，也是从根本上解决质量问题，提高工作效率的一个关键手段。

软件产品的开发同其它产品（如汽车）的生产有着共同特性，即需要按一定的过程来进行生产。在工业界，流水线生产方式被证明是一种高效的，且能够比较稳定的保证产品质量的一种方式。通过这种方式，不同的人员被安排在流程的不同位置，最终为着一个目标共同努力，这样可以防止人员工作间的内耗，极大的提供工作效率。并且由于其过程来源于成功的实例，因此其最终的产品质量能够满足过程所设定的范围。软件工程在软件的发展过程中吸取了这个经验并把它应用到了软件开发中，这就形成了软件工程过程，简单的说就是开发流程。

不管我们做哪件事情，都有一个循序渐进的过程，从计划到策略到实现。软件流程就是按照这种思维来定义我们的开发过程，它根据不同的产品特点和以往的成功经验，定义了从需求到最终产品交付的一整套流程。流程告诉我们该怎么一步一步去实现产品，可能会有那些风险，如何去避免风险等等。由于流程来源于成功的经验，因此，按照流程进行开发可以使得我们少走弯路，并有效的提高产品质量，提高用户的满意度。

目前流行的流程方法有很多种，如瀑布模型、螺旋模型、RUP模型、IPD流程等，不同的过程模型适合于不同 类型的项目。

第107帖【2004－9－18】：瀑布模型和螺旋模型

瀑布模型是应用最为广泛的一种模型，也是最容易理解和掌握的模型，然而它的缺陷也是显而易见的。遗漏的需求或者不断变更的需求会使得该模型无所适从。对于那些需求比较稳定、容易理解的项目比较合适。

螺旋模型是也是一个经典模型，它关注于发现和降低项目的风险。螺旋型项目从小的规模开始，然后探测风险，制定风险控制计划，接着确定下一步项目是否还要继续，然后进行下一个螺旋的反复。该模型的最大优点就是随着成本的增加，风险程度随之降低。然而螺旋模型的缺点是比较复杂，且需要管理人员有责任心，专注以及有管理方面经验。

第108帖【2004－9－20】：RUP模型

RUP（Rational Unified Process）是Rational公司提出的一套开发过程模型，它是一个面向对象软件工程的通用业务流程。它描述了一系列相关的软件工程流程，它们具有相同的结构，即相同的流程构架。RUP 为在开发组织中分配任务和职责提供了一种规范方法，其目标是确保在可预计的时间安排和预算内开发出满足最终用户需求的高品质的软件。RUP具有两个轴，一个轴是时间轴，这是动态的。另一个轴是工作流轴，这是静态的。在时间轴上，RUP划分了四个阶段：初始阶段、细化阶段、构造阶段和发布阶段。每个阶段都使用了迭代的概念。在工作流轴上，RUP设计了六个核心工作流程和三个核心支撑工作流程，核心工作流轴包括：业务建模工作流、需求工作流、分析设计工作流、实现工作流、测试工作流和发布工作流。核心支撑工作流包括：环境工作流、项目管理工作流和配置与变更管理工作流。RUP 汇集现代软件开发中多方面的最佳经验，并为适应各种项目及组织的需要提供了灵活的形式。作为一个商业模型，它具有非常详细的过程指导和模板。但是同样由于该模型比较复杂，因此在模型的掌握上需要花费比较大的成本。尤其对项目管理者提出了比较高的要求。

第109帖【2004－9－21】：IPD流程

IPD（Integrated Product Development）流程是由IBM提出来的一套集成产品开发流程，非常适合于复杂的大型开发项目，尤其涉及到软硬件结合的项目。IPD从整个产品角度出发，流程综合考虑了从系统工程、研发（硬件、软件、结构工业设计、测试、资料开发等）、制造、财务到市场、采购、技术支援等所有流程。是一个端到端的流程。在IPD流程中总共划分了六个阶段（概念阶段、计划阶段、开发阶段、验证阶段、发布阶段和生命周期阶段），四个个决策评审点（概念阶段决策评审点、计划阶段决策评审点、可获得性决策评审点和生命周期终止决策评审点）以及六个技术评审点。IPD流程是一个阶段性模型，具有瀑布模型的影子。该模型通过使用全面而又复杂的流程来把一个庞大而又复杂的系统进行分解并降低风险。一定程度上，该模型是通过流程成本来提高整个产品的质量并获得市场的占有。由于该流程没有定义如何进行流程回退的机制，因此对于需求经常变动的项目该流程就显得不大适合了。并且对于一些小的项目，也不是非常适合使用该流程。

第110帖【2004－9－22】：流程和技术

流程和成功不是等价的。没有流程就成功就不可能得到保证，但有了流程并不意味着肯定能够成功。这恐怕是很多迷信于流程的人所不能接受的。但这的确是个事实。记得有个做了将近30多年的需求分析专家说过：即使是一个已经达到CMM4级的公司，也完全有可能做不好需求分析。为什么？技术，技术是成功的另外一个必要条件。就好比现在你要从上海到北京去，流程给你指出了最短的路径，技术提供给你最快的交通工具。两者结合就是完美。

对于软件开发来说，要保证软件的质量，需要掌握多方面的技术，包括分析技术、设计技术、编码技术和测试技术等等。在国内有一个普遍的非正常现象，就是大家觉得只有编程能力才是玩电脑的真正技能。就好像造一套房子，其它都不重要，只要砖瓦匠有高超的技能就行了。尽管这个比喻会打击很多程序员的自尊心，但这的确是一个事实。我们缺少系统级的工程师，在分析和设计方面的工作做得很不扎实。

需求是一个项目的灵魂。模棱两可的需求带来不可避免的后果便是返工—重做一些你认为已做好的事情。返工会耗费开发总费用的4 0 %，而7 0 %～8 5 %的重做是由于需求方面的错误所导致的。

设计是最能体系一个工程师能力的地方。一个好的设计基本上决定了产品的最终质量。设计是把需求转换成系统的一个关键步骤，它需要从自然语言描述的需求中寻找出设计的基础单元，构建出整个系统的构架。关于设计方面的技能涉及面是很广的，包括传统的结构化设计到面向对象设计。

总之流程很关键，技术也很重要，鱼和熊掌，两者都不能放。

第111帖【2004－9－23】：Deming质量原则一

Deming质量原则一：要有一个坚定不移的目标

许多公司趋向于解决当前的问题而忽略将来的目标。根据Deming的原则：“对于一个公司，在没有一个针对未来的计划的前提下，它是不能存在于商业领域中的。”，一个坚定不移的目标需要：创新。如：一个长期的计划，投资于研究和教育，并且不断的改进产品和服务。

为了应用该原则，一个质量保证组织可以：

1、开发一个质量保证计划，提供一个长期的质量方向

2、需要软件测试者为每个项目开发并维护一个一致的测试计划

3、鼓励质量分析人员和测试人员遵循具有革新的方法来最大化产品的质量

4、致力于不断改进质量过程

第112帖【2004－9－25】：Deming质量原则二

Deming原则二：质量成为信仰

质量必须成为一个新的信仰，根据Deiming的理论：“生存的成本和需要花钱购买的商品和服务的质量是成反比的，如：可靠的服务可以降低成本，延迟的服务或错误却会提高成本”。由于延迟的服务和错误，商品和服务的消费被终止了，这降低了它们存在的意义。

为了应用该原则，一个质量保证组织可以：

1、教育开发组织关于质量的价值和需要

2、提高质量保证部门的地位，使他们和别的部门同样重要

3、纠正对质量部门是“看门狗”的消极看法

第113帖【2004－9－27】：Deming质量原则三

Deming质量原则三：不要依赖于海量的检查

传统的想法认为检查可以排除糟糕的质量。当难于确定在过程中一个缺陷在哪边产生的时候，一个好的方法是关注于我们做的如何，而不应针对最终的产品。质量应当是内在的，而不是依赖于无数的检查获得的。

为了使用该原则，一个质量保证组织可以：

1、在整个开发生命周期中，提高并使用技术评审、走读和检视来获取质量。

2、在整个组织中灌输质量意识，并把它作为一个切实的，可度量的工作产品

3、需要信息技术质量的统计证据

第114帖【2004－9－28】：Deming质量原则五

Deming第五原则：产品和服务系统稳定的长期的提高

改进不是一时的努力——管理者有责任不断的提高质量。“把火扑灭——很多公司称之为救火队，并不是改进，寻找失去控制的地方，找到其特殊的原因并改正它，这只是把过程纠正回本来应该的位置。改进的责任是一个无止境的过程。”

为了应用该原则，一个质量保证组织可以：

1、不断的提高质量保证和测试过程

2、不要依赖于主管的判断

3、使用统计技术，如测试分析和通过主因及效果分析揭示问题根源等方法