无忧测试论坛《每日一帖》9月份精华帖

来自 http://www.51testing.com 这是论坛版主天网每天提供给测试网友的精神食粮,感谢天网

94 贴【 2004 9 1 】:可靠性测试

可靠性测试是从验证的角度出发,检验系统的可靠性是否达到预期的目标,同时给出当前系统可能的可靠性增长情况。可靠性测试需要从用户角度出发,模拟用户实际使用系统的情况,设计出系统的可操作视图,在这个基础上,根据输入空间的属性及依赖关系导出测试用例,然后在仿真的环境或真实的环境下执行测试用例并记录测试的数据。对可靠性性测试来说,最关键的测试数据包括失效间隔时间,失效修复时间,失效数量,失效级别等。根据获得的测试数据,应用可靠性模型,可以得到系统的失效率及可靠性增长趋势。常用的可靠性模型可以从黑盒(占主要地位)和白盒两个角度出发。黑盒方面的可靠性模型包括了 Musa 基本执行模型, Jelinski-Moranda 的分离富化模型, Goel-Okumoto 的 NHPP 模型,增强的 NHPP 模型以及 Littlewood-Verrall 的贝叶斯判定模型。在白盒方面的可靠性模型包括了 Krishna-murthy 和 Mathur 的基于路径的模型和 Gokhale et al. 的基于状态的模型。业界流行的可靠性模型还有很多种,不同的可靠性模型其依赖的假设条件也不同,适用范围也不同,因此对于一个产品,其所适合使用的可靠性模型需要根据实际出发,尽可能选择与可靠性模型假设条件相近的模型。

95 贴【 2004 9 2 】:需求测试

软件测试 V 模型要求我们在需求阶段就开始制定系统测试的计划,开始考虑系统测试的方法。但这还不是足够的。全面的质量管理要求我们在每个阶段都要进行验证和确认的过程。因此在需求阶段我们还需要对需求本身进行测试。这个测试是必要的,因为在许多失败的项目中, 7 0 % ~ 8 5 % 的返工是由于需求方面的错误所导致的。并且因为需求的缘故而导致大量的返工,造成进度延迟、缺陷的发散,这是一件及其痛苦的事情。因此我们要求在项目的源头(需求)就开始测试。这类测试更多的还只是静态手工方面的测试,当然也有一些自动化的工具,但这些工具会要求我们按照某个固定的格式进行需求的表述(例如形式化的方法),因此在适用性上会受到限制。通过静态手工方法进行需求测试中最常使用的手段是同行评审。

95 贴【 2004 9 4 】:通过评审来测试需求

同行评审是业界公认的最有效的排错手段之一。我们在需求测试过程当中,使用最多的也是同行评审( Peer Review ),尤其是正规检视( Inspection )。正规检视是由 Michael Fagan 在 I B M 制定出来的一种非常严格的评审过程。
    需求评审的参与者当中,必须要有用户或用户代表参与,同时还需要包括项目的管理者,系统工程师和相关开发人员、测试人员、市场人员、维护人员等。在项目开始之初就应当确定不同级别、不同类型的评审必须要有哪些人员的参与,否则,评审可能会遗漏掉某些人员的意见,导致今后不同程度的返工。

96 贴【 2004 9 6 】:好的需求应当具有的特点

一个良好的需求应当具有一下特点:
       完整性。每一项需求都必须将所要实现的功能描述清楚,以使开发人员获得设计和实现这些功能所需的所有必要信息。
        正确性。每一项需求都必须准确地陈述其要开发的功能。
        一致性。一致性是指与其它软件需求或高层(系统,业务)需求不相矛盾。 ?
        可行性。每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。
        无二义性。对所有需求说明的读者都只能有一个明确统一的解释,由于自然语言极易导致二义性,所以尽量把每项需求用简洁明了的用户性的语言表达出来。
        健壮性。需求的说明中是否对可能出现的异常进行了分析,并且对这些异常进行了容错处理。
        必要性。 “ 必要性 ” 可以理解为每项需求都是用来授权你编写文档的 “ 根源 ” 。要使每项需求都能回溯至某项客户的输入,如 Use Case 或别的来源。
        可测试性。每项需求都能通过设计测试用例或其它的验证方法来进行测试。
        可修改性。每项需求只应在 S R S 中出现一次。这样更改时易于保持一致性。另外,使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。
        可跟踪性。应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链,这种可跟踪性要求每项需求以一种结构化的,粒度好( f i n e - g r a i n e d )的方式编写并单独标明,而不是大段大段的叙述。

另外应当对所有的需求分配优先级。如果把所有的需求都看作同样的重要,那么项目管理者在开发或节省预算或调度中就丧失控制自由度

97 贴【 2004 9 8 】:通过用例设计来测试需求

我们从 V 模型上可以知道,验收测试是以系统需求为基础的,系统测试是以功能测试为基础。每个开发阶段的活动都与相应的测试活动是并行进行的。在需求阶段进行系统(验收)测试计划和设计,除了能指导最终的系统测试和验收测试执行外,其本身也是对需求的一个验证过程。
    通过阅读软件需求规格说明书,通常很难想象在特定环境下的系统行为。以功能需求为基础或者从使用实例派生出来的测试用例可以使项目参与者看清系统的行为。虽然没有在运行系统上执行测试用例,但是设计测试用例的简单动作可以解释需求的许多问题。如果你在部分需求稳定时就开始开发测试用例,那么就可以及早发现问题并以较少的费用解决这些问题。
    设计概念性测试用例可以发现需求的错误、二义性、不可测性、遗漏等方面问题,为了获得最大的效果,要求测试人员能够独立的去对需求进行思维,从一个不同于开发的角度上进行分析,这可能会是一个逆向的思维过程,在这个过程中,测试人员可能会设计出不同于需求的测试用例,而这最终可能会有两个解释:
1 、需求不完整或者需求有错;
2 、遗漏了测试用例或者测试用例本身有错误;
   不管是哪种解释,最终肯定会提高整个系统的质量。但这个质量的获得是通过冗余的人员来完成的,即:开发人员在对系统需求进行进一步分析的时候,有一组独立的测试人员也在对系统需求进行独立的思维,并从中获取测试用例。尽管这两种思维可能会出现重复,但由于思维的方式不同,最终肯定会使得需求变得更清晰和更完善。

98 贴【 2004 9 9 】:需求建模测试

需求的建模包括把需求转换成图形模型或形式化语言模型。需求的图形化分析模型包括数据流图( Data Flow Diagram , DFD )、实体关系图( Entity-Relationship Diagram , ERD )、状态转化图( State-Transition Diagram , STD )、对话图( Dialog Map )和类图( Class Diagram )。这些图形化模型一般都需要借助一定的 CASE ( Computer-Aided Software Engineering )工具。这样就可以借助于自动化分析工具本身提供的检测手段来对需求进行测试,而这类检测主要可以提供描述上的完整性检查,需求项之间的不一致性检查等方面的功能。同时,使用这类自动分析工具有助于获得需求的质量特性,包括:有效性、一致性、可靠性、可存活性、可用性、正确性、可维护性、可测试性、可扩展性、可交互性、可重用性、可携带性等。

99 贴【 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 )的评审方法中也用到了情景测试方法,可以一起进行参考。

100 贴【 2004 9 13 】:故障插入

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

    原本错误总数 = (播入的错误总数 / 发现的播入错误数) × 发现的原本错误数
    残留错误数      = 原本错误总数 - 发现的原本错误数

    故障插入技术在软件可靠性方面应用的比较广泛,尤其在硬件的测试当中。例如一些汽车公司不惜花大价钱进行的汽车碰撞试验,为的就是发现汽车在碰撞过程中的潜在隐患,通过消除、改进这些隐患从而达到更高的性能。
    借鉴了硬件可靠性测试的方法,在软件测试中引入故障插入技术,其主要目的是为了评价系统的哪些模块,哪些代码是危险模块,危险代码,容易出问题,从而评价系统的容错能力。在该技术中使用了故障加速技术,通过有意的插入故障来调用系统的故障容错能力,从而在一个可控制的环境和期望的时间段内获得完整的测试。它和现有的测试方法相比,最大的不同在于测试开始时的系统状态不同,现有的测试都是从系统的正确状态开始,测试系统如何转入故障状态,而故障注入测试则是从系统的故障状态开始,测试系统在发生故障后的运行规律。这里要重点指出的是,故障插入不关注为什么出现这样的故障,它关注的是出现了这样的故障后系统如何处理。
    故障插入也被用于验证测试用例的有效性。其原理就是为了检查设计的测试用例是否能发现某一类型的故障,人为在被测系统中引入该类型的故障,如果在测试过程中能发现这个故障的话,则应该也可以测试出系统原来就存在的该类故障。
    故障插入技术的一个难点是插入的故障在程序中是否能够代表还没有发现的故障。实际上,由于软件的复杂性,故障的暴露往往和当时的运行环境、执行的路径有很大的关系,能测试出故障插入的故障并不一定总是能测试出被测系统原本存在的该类型故障,所以,在上述的最后一步推论不一定总是成立。但是就从验证测试用例的有效性角度来看,故障插入确实可以作为一种手段。

101 贴【 2004 9 14 】:功能覆盖率

功能覆盖率( Function Coverage )是属于黑盒测试范畴内的,在实际测试中,涉及到的覆盖率一般都是结构化覆盖率,与黑盒相关的覆盖率比较少。
功能覆盖中最常见的是需求覆盖,其含义是通过设计一定的测试用例,要求每个需求点都被测试到。其公式是

    需求覆盖 = (被验证到的需求数量) / (总的需求数量)

    在黑盒测试中还有一个覆盖叫接口覆盖(或者称为入口点覆盖),要求通过设计一定的用例使得系统的每个接口被测试到。
    由于黑盒测试把被测系统理解为一个黑盒,测试时,输入测试数据,然后判定输出结果是否与期望结果一致。根据这个可以得到输入数据的覆盖情况,即通过设计一定的用例,要求每种数据情况都被测试到。

102 贴【 2004 9 15 】:面向对象的覆盖率

由于传统的结构化度量没有考虑面向对象的一些特性,如多态,继承和封装等。 传统的结构化覆盖必须被加强,以满足面向对象特性,上下文覆盖就是一种针对面向对象特性而增强的覆盖。
    上下文覆盖可以应用到面向对象领域处理诸如多态,继承和封装的特性,同时该方法也可以被扩展用于多线程应用。通过使用这些面向对象的上下文覆盖,结合传统的结构化覆盖的方法就可以保证代码的结构被完整的执行,同时提高我们对被测软件质量的信心。
    有三个面向对象上下文覆盖的定义,它们分别是:继承上下文覆盖( Inheritance Context Coverage ),该覆盖率用于度量在系统中的多态调用被测试得多好。基于状态的上下文覆盖( State-Based Context Coverage ),该覆盖用于改进对带有状态依赖行为的类的测试。已定义用户上下文覆盖( User-Defined Context Coverage ),该度量允许上下文覆盖的方法被应用到传统结构化覆盖率无法使用的地方,例如多线程应用。

103 贴【 2004 9 16 】:软件质量三角

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

104 贴【 2004 9 17 】:流程对质量的贡献

从一个软件企业的长远发展来看,如果要提高产品的质量首先应当从流程抓起,规范软件产品的开发过程。这是一个软件企业从小作坊的生产方式向集成化规范化的大公司迈进的必经之路,也是从根本上解决质量问题,提高工作效率的一个关键手段。
    软件产品的开发同其它产品(如汽车)的生产有着共同特性,即需要按一定的过程来进行生产。在工业界,流水线生产方式被证明是一种高效的,且能够比较稳定的保证产品质量的一种方式。通过这种方式,不同的人员被安排在流程的不同位置,最终为着一个目标共同努力,这样可以防止人员工作间的内耗,极大的提供工作效率。并且由于其过程来源于成功的实例,因此其最终的产品质量能够满足过程所设定的范围。软件工程在软件的发展过程中吸取了这个经验并把它应用到了软件开发中,这就形成了软件工程过程,简单的说就是开发流程。
    不管我们做哪件事情,都有一个循序渐进的过程,从计划到策略到实现。软件流程就是按照这种思维来定义我们的开发过程,它根据不同的产品特点和以往的成功经验,定义了从需求到最终产品交付的一整套流程。流程告诉我们该怎么一步一步去实现产品,可能会有那些风险,如何去避免风险等等。由于流程来源于成功的经验,因此,按照流程进行开发可以使得我们少走弯路,并有效的提高产品质量,提高用户的满意度。
    目前流行的流程方法有很多种,如瀑布模型、螺旋模型、 RUP 模型、 IPD 流程等,不同的过程模型适合于不同类型的项目。

105 贴【 2004 9 18 】:瀑布模型和螺旋模型

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

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

106 贴【 2004 9 20 】: RUP 模型

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

107 贴【 2004 9 21 】: IPD 流程

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

108 贴【 2004 9 22 】:流程和技术

流程和成功不是等价的。没有流程就成功就不可能得到保证,但有了流程并不意味着肯定能够成功。这恐怕是很多迷信于流程的人所不能接受的。但这的确是个事实。记得有个做了将近 30 多年的需求分析专家说过:即使是一个已经达到 CMM4 级的公司,也完全有可能做不好需求分析。为什么?技术,技术是成功的另外一个必要条件。就好比现在你要从上海到北京去,流程给你指出了最短的路径,技术提供给你最快的交通工具。两者结合就是完美。
    对于软件开发来说,要保证软件的质量,需要掌握多方面的技术,包括分析技术、设计技术、编码技术和测试技术等等。在国内有一个普遍的非正常现象,就是大家觉得只有编程能力才是玩电脑的真正技能。就好像造一套房子,其它都不重要,只要砖瓦匠有高超的技能就行了。尽管这个比喻会打击很多程序员的自尊心,但这的确是一个事实。我们缺少系统级的工程师,在分析和设计方面的工作做得很不扎实。
    需求是一个项目的灵魂。模棱两可的需求带来不可避免的后果便是返工 — 重做一些你认为已做好的事情。返工会耗费开发总费用的 4 0 % ,而 7 0 % ~ 8 5 % 的重做是由于需求方面的错误所导致的。
    设计是最能体系一个工程师能力的地方。一个好的设计基本上决定了产品的最终质量。设计是把需求转换成系统的一个关键步骤,它需要从自然语言描述的需求中寻找出设计的基础单元,构建出整个系统的构架。关于设计方面的技能涉及面是很广的,包括传统的结构化设计到面向对象设计。
    总之流程很关键,技术也很重要,鱼和熊掌,两者都不能放。

109 贴【 2004 9 23 】: Deming 质量原则一

Deming 质量原则一:要有一个坚定不移的目标
   
    许多公司趋向于解决当前的问题而忽略将来的目标。根据 Deming 的原则: “ 对于一个公司,在没有一个针对未来的计划的前提下,它是不能存在于商业领域中的。 ” ,一个坚定不移的目标需要:创新。如:一个长期的计划,投资于研究和教育,并且不断的改进产品和服务。
    为了应用该原则,一个质量保证组织可以:
    1 、开发一个质量保证计划,提供一个长期的质量方向
    2 、需要软件测试者为每个项目开发并维护一个一致的测试计划
    3 、鼓励质量分析人员和测试人员遵循具有革新的方法来最大化产品的质量
    4 、致力于不断改进质量过程

110 贴【 2004 9 24 】: Deming 质量原则二

Deming 原则二:质量成为信仰

    质量必须成为一个新的信仰,根据 Deiming 的理论: “ 生存的成本和需要花钱购买的商品和服务的质量是成反比的,如:可靠的服务可以降低成本,延迟的服务或错误却会提高成本 ” 。由于延迟的服务和错误,商品和服务的消费被终止了,这降低了它们存在的意义。
    为了应用该原则,一个质量保证组织可以:
    1 、教育开发组织关于质量的价值和需要
    2 、提高质量保证部门的地位,使他们和别的部门同样重要
    3 、纠正对质量部门是 “ 看门狗 ” 的消极看法

111 贴【 2004 9 27 】: Deming 质量原则三

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

    传统的想法认为检查可以排除糟糕的质量。当难于确定在过程中一个缺陷在哪边产生的时候,一个好的方法是关注于我们做的如何,而不应针对最终的产品。质量应当是内在的,而不是依赖于无数的检查获得的。
为了使用该原则,一个质量保证组织可以:
    1 、在整个开发生命周期中,提高并使用技术评审、走读和检视来获取质量。
    2 、在整个组织中灌输质量意识,并把它作为一个切实的,可度量的工作产品
    3 、需要信息技术质量的统计证据

112 贴【 2004 9 28 】: Deming 质量原则五

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

    改进不是一时的努力 —— 管理者有责任不断的提高质量。 “ 把火扑灭 —— 很多公司称之为救火队,并不是改进,寻找失去控制的地方,找到其特殊的原因并改正它,这只是把过程纠正回本来应该的位置。改进的责任是一个无止境的过程 ”
为了应用该原则,一个质量保证组织可以:
    1 、不断的提高质量保证和测试过程
    2 、不要依赖于主管的判断
    3 、使用统计技术,如测试分析和通过主因及效果分析揭示问题根源等方法

113 贴【 2004 9 29 】: Deming 质量原则四

Deming 第四原则:不要纯粹按照价格因素来选择供应商
   
    “ 两个或多个以上的同种商品的供应商可能会导致恶性的竞争,这些竞争除了会损害供应商自身外,并且还可能会损害商品的使用者 ” 。为了最好的服务于公司,购买方可以通过和供应商建立一种长期的忠实的关系,并且与一个专门的供应商建立信任关系。一般可能会通过一系列的标准来衡量哪个供应商更好,但一个更好的方法是积极的使用 Deming 的十四条原则参与到供应商管理当中。
      在软件开发中,可能会需要各种工具和中间件供应商、子合同承包商,而这些商品品或服务的质量会极大的影响最终的产品质量。    
      为了应用该原则,一个质量保证组织可以:
     1 、需要软件产品和服务提供者提供能够证明他们质量的统计数据
     2 、对每一个质量保证工具、测试工具和服务选择一个最好的供应商,并且建立一个与质量计划一致的工作关系
     3 、对子合同承包商,需要建立一致的质量保证计划