软件测试体系教程

目录

第一章 软件测试认识概述 ...................................................................................................................... 2 第二章 软件质量与测试 ......................................................................................................................... 7 第三章 测试技术分类 ............................................................................................................................11 第四章 软件测试模型 ............................................................................................................................26 第五章 软件测试流程概述 .....................................................................................................................31 第六章 软件测试流程详述 .....................................................................................................................50 第七章 单元测试 ...................................................................................................................................93 第八章 集成测试 ................................................................................................................................. 103 第九章 确认测试 ................................................................................................................................. 109 第十章 系统测试 ................................................................................................................................. 114 第十一章 回归测试 .............................................................................................................................. 121 第十二章 验收测试 .............................................................................................................................. 125 第十三章 封样测试 .............................................................................................................................. 133 第十四章 本地化测试 .......................................................................................................................... 138 第十五章 安全性测试 .......................................................................................................................... 146 第十六章 嵌入式测试 .......................................................................................................................... 156 第十七章 面向对象测试 ...................................................................................................................... 162 第十八章 OFFICE工具 .......................................................................................................................... 174 第十九章 微软的软件开发过程 ........................................................................................................... 175

1

企业应用软件测试实训课程

第一章 软件测试认识概述

人是测试工作中最有价值也是最重要的资源，没有一个合格的、积极的测试小组，测试就不可能很好地实现。然而，在软件企业中有一种非常普遍习惯，那就是让那些经验最少的新手、没有效率的开发者或不适合干其他工作的人去做测试工作。这绝对是一种目光短浅的行为，对一个系统进行有效的测试所需要的技能和其他能力绝对不比进行软件开发需要的少，事实上，测试人员技术与经验与软件质量和测试工作效率有非常大的关系。

在此，我们对软件测试需要的素质要求，包括技术素质和非技术素质要求。 一、测试人员的技术素质要求

测试人员的技术要求与开发人员相比要更全面，因为测试人员的技术要求不仅仅是软件开发技术与经验，还要包括软件测试技术以及软件工程方面的能力，当然也包括软件应用领域的行业知识。 1）软件开发技术。

做软件测试工作当然要一定程度地掌握所测试软件应用的开发技术。一方面，对开发技术比较了解能使测试人员更有效地发现程序中的BUG，并进行有效地分析，以帮助开发人员更快地进行定位和修改；另一方面，很多测试工作本身需要编码技术，例如：单元测试和集成测试，经常需要构造驱动和桩程序，如果测试人员开发技术水平很低，就根本无法胜任这些测试工作。

另外，软件测试经常需要自主开发测试工具，这些工作都是要求测试人员应该有很强的编程技能才能完成。

2）软件测试技术。

软件测试本身就是一门学问，它是软件测试人员的“独门专业”。只有掌握了软件测试技术，测试工作才能更有效实施和管理；只有掌握了软件测试技术，才能更早、更快、更有效地找出软件中的缺陷；只有掌握了软件测试技术，才能用更科学的方法验证软件是否满足用户需求，才能成为提高软件质量的重要手段之一。

从我们目前的软件测试技术来说，包括业界公认的测试技术（如等价类划分、因果图分析等黑盒测试方法），也包括软件中心自己总结出的一些通用测试方法（如数据库通用测试方法、B/S应用测试方法等），还包括不同类型项目的技术总结。

所以，测试人员除了要掌握和了解测试行业本身需要的测试技术以外，还要针对不同项目的需求掌握一些通用测试方法和技巧，而且要把自己的经验不断总结出来，共享技术与经验，以期使整体技术水平得以迅速提升。

3）软件工程方面能力。

软件测试活动几乎贯穿软件开发全过程，那么就要求测试人员，尤其测试负责人，要对软件工程有较深的认识。现在越来越多的软件公司开始重视研发机构的管理工作，软件工程活动也逐渐开始采用CMM模型等，项目管理也越来越多的被引入到了软件项目中，这就更要求测试人员要对软件研发和测试流程、

2

企业应用软件测试实训课程

规范非常重视，而且还要灵活地采用，使我们的软件测试工作既严格遵从项目计划，又符合软件开发和测试的流程规范。 4）行业知识。

既然我们非常重视用户需求，并把软件质量的重点放在了用户满意的程度上，那么了解用户需求对于测试人员就显得尤为重要。比如对于企业和教育等等这些专署行业上就需要我们了解软件应用领域的行业知识，比如：ERP、CRM等业务流程，教育理论与实现方式等等。 二、测试人员的非技术素质要求

人是测试工作中最有价值也是最重要的资源，没有一个合格的、积极的测试小组，测试就不可能实现。然而，在软件开发产业中有一种非常普遍习惯，那就是让那些经验最少的新手、没有效率的开发者或不适合干其他工作的人去做测试工作。其实对一个系统进行有效的测试所需要的技能绝对不比进行软件开发需要的少。事实上，测试者将获得极其广泛的经验，他们将遇到许多开发者不可能遇到的问题。 ①、沟通能力

一名理想的测试者必须能够同测试涉及到的所有人进行沟通，具有与技术（开发者）和非技术人员（客户，管理人员）的交流能力。既要可以和用户谈得来，又能同开发人员说得上话，不幸的是这两类人没有共同语言。和用户谈话的重点必须放在系统可以正确地处理什么和不可以处理什么上。而和开发者谈相同的信息时，就必须将这些话重新组织以另一种方式表达出来，测试小组的成员必须能够同等地同用户和开发者沟通。 ②、移情能力

和系统开发有关的所有人员都处在一种既关心又担心的状态之中。用户担心将来使用一个不符合自己要求的系统，开发者则担心由于系统要求不正确而使他不得不重新开发整个系统，管理部门则担心这个系统突然崩溃而使它的声誉受损。测试者必须和每一类人打交道，因此需要测试小组的成员对他们每个人都具有足够的理解和同情，具备了这种能力可以将测试人员与相关人员之间的冲突和对抗减少到最低程度。 ③、技术能力

就总体言，开发人员对那些不懂技术的人持一种轻视的态度。一旦测试小组的某个成员作出了一个错误的断定，那么他们的可信度就会立刻被传扬了出去。目前来说，测试人员的技术能力是不够高，但希望开发人员能正确的评价测试者，提供尽量正确详尽的技术说明和技术支持。 ④、自信心

开发者指责测试者出了错是常有的事，测试者必须对自己的观点有足够的自信心。如果容许别人对自己指东指西，就不能完成什么更多的事情了。 ⑤、外交能力

当你告诉某人他出了错时，就必须使用一些外交方法。机智老练和外交手法有助于维护与开发人员的协

3

企业应用软件测试实训课程

作关系，测试者在告诉开发者他的软件有错误时，也同样需要一定的外交手腕。如果采取的方法过于强硬，对测试者来说，在以后和开发部门的合作方面就相当于“赢了战争却输了战役”。 ⑥、幽默感

在遇到狡辩的情况下，一个幽默的批评将是很有帮助的。 ⑦、很强的记忆力

一个理想的测试者应该有能力将以前曾经遇到过的类似的错误从记忆深处挖掘出来，这一能力在测试过程中的价值是无法衡量的。因为许多新出现的问题和我们已经发现的问题相差无几。 ⑧、耐心

一些质量保证工作需要难以置信的耐心。有时你需要花费惊人的时间去分离、识别和分派一个错误。这个工作是那些坐不住的人无法完成的。 ⑨、怀疑精神

可以预料，开发者会尽他们最大的努力将所有的错误解释过去。测式者必须听每个人的说明，但他必须保持怀疑直到他自己看过以后。 ⑩、自我督促

干测试工作很容易使你变得懒散。只有那些具有自我督促能力的人才能够使自己每天正常地工作。 ⑾、洞察力

一个好的测试工程师具有“测试是为了破坏”的观点，捕获用户观点的能力，强烈的质量追求，对细节的关注能力。应用的高风险区的判断能力以便将有限的测试针对重点环节 ⑿、责任心

对于公司特殊的业务，测试人员要有高度的责任感，保守公司、用户的秘密。 三、软件测试的历史

第一个阶段是60年代及其以前，那时软件规模都很小、复杂程度低，软件开发的过程随意。开发人员的Debug过程被认为是唯一的测试活动。

第二个阶段是70年代，这个阶段开发的软件仍然不复杂，但人们已开始思考开发流程问题，并提出“软件工程Software Engineering”的概念。但是这一阶段人们对软件测试的理解仅限于基本的功能验证和Bug搜寻，而且测试活动仅出现在整个软件开发流程的后期，虽然测试由专门的测试人员来承担，但测试人员都是行业和软件专业的入门新手。

第三个阶段是80年代及其以后，软件和IT行业进入了大发展。=软件测试已有了行业标准（IEEE/ANSI ），它再也不是一个一次性的，而且只是开发后期的活动，而是与整个开发流程融合成一体。软件测试已成为一个专业，需要运用专门的方法和手段，需要专门人才和专家来承担。

4

企业应用软件测试实训课程

四、软件测试的定义

广义上讲，测试是指软件产品生存周期内所有的检查、评审和确认活动。如：设计评审、系统测试。 狭义上讲，测试是对软件产品质量的检验和评价。它一方面检查软件产品质量中存在的质量问题，同时对产品质量进行客观的评价。需要通过设计测试用例来运行程序，以发现存在的缺陷。

IEEE在1983年的定义是：使用人工或自动手段来进行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。“软件测试以检验是否满足需求为目标的” 五、软件测试的目的

简单地说，就是替用户受过，测试的最终目的是确保最终交给用户的产品的功能符合用户的需求，把尽可能多的问题在产品交给用户之前发现并改正。在可接受的开销下，提高对软件的信心。 具体地讲，测试一般要达到下列目标：

1）确保产品完成了它所承诺或公布的功能，并且所有用户可以访问到的功能都有明确的书面说明。 2） 确保产品满足性能和效率的要求。 3） 确保产品是健壮的和适应用户环境的。 六、软件测试的理解 一、对测试的误解

1、认为测试工作不如设计和编码那样具有开拓性，也不容易看到进展。 2、以发现软件错误为目标的测试是非建设性的，甚至是破坏性的。 3、测试工作枯燥无味，不能引起人的兴趣。

4、测试的目的是在于证实程序的正确性，测试是为了说明程序是没有问题的。 二、对测试的正确理解： 1、贯穿在整个开发各阶段

2、从心理上讲，软件测试可以看成是摧毁性的而不是建设性的。 3、软件测试是软件开发的一部分 4、软件质量是一个企业开发过程的反映 七、软件测试的原则——GoodEnough

Good-enough原则就是一种权衡投入 / 产出比的原则：不充分的测试是不负责任的；过分的测试是一种资源的浪费，同样也是一种不负责任的表现。我们的操作困难在于：如何界定什么样的测试是不充分的，什么样的测试是过分的。目前状况唯一可用的答案是：制定最低测试通过标准和测试内容，然后具体问题具体分析。

5

企业应用软件测试实训课程

八、测试的规律——木桶原理和80-20原则 1） 木桶原理。

在软件产品生产方面就是全面质量管理(TQM)的概念。产品质量的关键因素是分析、设计和实现，测试应该是融于其中的补充检查手段，其他管理、支持、甚至文化因素也会影响最终产品的质量。应该说，测试是提高产品质量的必要条件，也是提高产品质量最直接、最快捷的手段，但决不是一种根本手段。反过来说，如果将提高产品质量的砝码全部押在测试上，那将是一个恐怖而漫长的灾难。 2） Bug的80-20原则。

一般情况下，在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的Bug，而系统测试又能找出其余Bug中的80%，最后的5%的Bug可能只有在用户的大范围、长时间使用后才会曝露出来。因为测试只能够保证尽可能多地发现错误，无法保证能够发现所有的错误。 传统测试流程遇到的挑战和对策----问题发现得越早，解决的代价就越小。

6

企业应用软件测试实训课程

第二章 软件质量与测试

当今，越来越多的公司都开始真正重视起软件质量问题来，那么软件究竟如何才能保证软件质量呢？下面分别从质量属性、质量目标、人员素质以及公司规范几个方面进行阐述。 一、质量属性

CMM 对质量的定义是：① 一个系统、组件或过程符合特定需求的程度；② 一个系统、组件或过程符合客户或用户的要求或期望的程度。

我们评价一款软件可以从以下一些角度进行：正确性、可靠性、健壮性、美观性、性能、易用性、兼容性、安全性、可移植性、可扩展性等。以下分别阐述： 1． 正确性

正确性是指软件按照需求正确执行任务的能力。 正确性也涵盖了“精确性”方面。 2． 可靠性

可靠性是指在一定的环境下，在给定的时间内，系统能够正常运行的概率。 3．健壮性

健壮性是指在异常或者不利情况下，软件能够正常运行的能力。 4．美观性

美观性主要指软件UI设计的情况，美观性就是从大众化审美以及心理学角度对软件提出的一个要求，这个要综合考虑软件的使用人群特点等。美观性包括软件的颜色搭配，字体使用，排版布局等方面。 5．性能

性能也就是一个软件效率问题，也就是软件特定时间空间环境下系统的响应能力。 6．易用性

易用性是软件能否满足客户容易操作使用程度。 7．兼容性

兼容性指一款软件和其他不同软件通信（或交换信息）的能力。在做兼容性测试方面，首先要保证所做软件能和市场上一些知名品牌产品以及市场占有率比较高的产品的兼容。 8．安全性

安全性是指软件系统防止被非法入侵的能力。 9．可移植性

可移植性指的是软件不经修改或稍加修改就可运行于不同软硬件环境（CPU、OS和编译器）的能力，主要体现为代码的可移植性。

7

企业应用软件测试实训课程

10．扩展性

可扩展性反映软件适应“变化”的能力，如增加新功能等。可扩展性和可移植性一样，主要都是从开发的角度对软件提出的要求。

以上，从一些不同角度来评价一款软件，当然实际评测过程中还要根据嵌入式、B/S架构、C/S架构等不同特点软件来有所侧重，同时还要结合软件使用对象、生命周期等来综合评价。当然，以上各点满足了也不能说明就是一款好软件了，其他比如可维护性、可复用性、可测试性等也是我们要根据实际情况来考虑的因素。

软件组织可以根据自身情况重新定义，但建议满足如下要求： 要包罗根据上述质量定义的软件质量的一切方面； 要以最小的重迭描述质量的特性； 要与既定术语尽可能的靠近；

为了清晰和便于使用,要建立不超过 6～8个特性的一组特性； 要确定供进一步细地的软件产品的属性领域。 二、质量目标

软件公司生产软件的最根本目标是为了让产品赢得市场、赢得顾客，从而获取利润。如果企业连生存的能力都没有了，软件的质量做的再完美也无用。

软件公司开发一款软件，并不是说质量越高越好。质量越高，成本相对会越高，这样企业就可能支持不力，无法生存；或者价格很高，客户无法接受。

在此并不是说软件质量不重要，质量很重要！好和坏从来都是相对的。从用户的角度而言，在能够正常满足使用要求的软件就是好软件；对企业而言，在软件生命周期里，能够软件能够满足用户使用，能给自己带来更多利润的软件就是好软件。 三、人员素质

软件是人做出来的，软件质量的好坏和开发、测试以及有关管理人员都息息相关。在软件开发方面，我们在此不谈，只从测试的角度来谈软件质量保证。

质量保证的人员能力问题是个重要方面，如果连软件中潜在问题都发现不了，想解决问题，做高质量的软件，谈何容易？

测试人员能力是一方面，其他如从事软件测试人员的职业素养也是个重要方面。 四、公司规范

测试人员的能力再强，测出的问题再多，如果这些问题没有解决的情况下匆匆将软件release给客户，软件问题一大堆。这样的测试其实是没有多大的实际意义的。测试的目的是发现问题，解决问题，保证软

8

企业应用软件测试实训课程

件质量。

企业为了生存，也很难把测试方面真正做好，比如有些产品赶在某些节假日上市时有着良好的市场，而过了那一段时期，可能产品就很难卖了。当然，这些就不是测试人员考虑的范围了。

要真正把软件质量保证落到实处，开发、测试以及有管管理人员的的密切配合，一款软件在发行前，一定要经过一番严格的测试，然后对软件进行评估才是！ 五、过程管理

过程管理是针对公司规范的执行情况。

一般公司都有一套完整的产品开发流程、规范，流程各个环节执行的情况是能否开发出一款好软件必要条件。包括文档管理、版本控制、测试管理等很多方面。 六、软件质量问题的原因

1. 软件本身的特点和目前普遍采用的开发模式使得隐藏在软件产品内部的质量缺陷不可能完全避免。 2. 计算机软件是不可见的逻辑实体，不同于任何制造业的其它产品，软件质量难于把握的一个突出因

素是软件需求。 3. 软件复杂性高。

4. 软件开发工作大多仍是智力密集的手工劳动。

5. 软件开发无论采用哪一种模型，开发环节之间，人员之间的协调和衔接都必须保证完全正确。 6. 软件测试方法具有不可克服的弱点，软件质量对人员的依赖不能避免。 7. 技术上解决软件质量问题有着局限性。

8. 对软件质量本身的认识仍处于初期阶段，一些定性的认识尚未量化。

9. 目前利用软件组件或构件实现可复用性，力图提高软件可靠性的作法尚未普及。

10. 想要采用净室开发技术，防止错误或缺陷混入开发过程仍然是开发人员的设想，很难绝对净化软件

开发环境。

11. 软件工程标准化重视不够 。

12. 项目组交流不够、交流上有误解或者根本不进行交流。 13. 程序设计错误、需求变化。 14. 时间压力。

15. 代码文档贫乏或者差劲的文档使得代码维护和修改变的异常艰辛，其结果是带来许多错误。 七、软件质量度量框架

9

企业应用软件测试实训课程

什么是质量度量？

测试团队的一个主要目标是评估并决定质量，但是如何准确地度量质量呢？有许多的方法可以实现，而且根据系统或应用软件的类型和开发项目的特殊性分为很多不同的种类。

度量框架：一种用来组织、选择、沟通、评价软件系统要求的质量属性的辅助决策法。它逐层分解为特性、子特性和度量。

直接度量：一种不依赖于任何其他属性测量的尺度。

预计度量：一种适用于开发阶段的度量，它用来预计软件质量特性的值。

软件质量度量：一个函数，它的输入是软件数据，输出是一个单一数值。它可解释为给定的软件属性对其质量的影响程度。

过程度量：一种用来测量在软件系统开发、实现和维护过程中所使用的方法、技术和工具特性的度量。 产品度量：一种用来测量软件开发过程中间或最终产品特性的度量。

八、软件度量分层

九、基于软件质量的测试

软件产品质量 特性 直接度量 特性 直接度量 特性 直接度量 子特性 子特性 子特性 度量 度量 度量 10

企业应用软件测试实训课程

功能性测试是软件测试工作的最主要的部分，一般包括以下几方面： 安装；功能表现；正确性；一致性。

软件可靠性测试也包括容错性测试，是指运用测试技术和统计技术，对被测软件执行测试和评价，并采集系统运行期间的软件失效数据进行处理，最终评估软件可靠性的过程。

软件可靠性测试的主要目的是测试和验证软件的可靠性，当然实施软件可靠性测试也是对软件其它质量特性测试的一种补充和完善，这样有助于软件产品本身的可靠性增长。 十、案例

1996年欧洲航天局阿丽亚娜5型（Ariane5）火箭发射后40秒钟火箭爆炸，发射基地2名法国士兵当场死亡，耗资产10亿美元，历时9年的航天计划严重受挫，震惊了国际宇航界。事后专家调查分析报告指出，爆炸原因在于惯性导航系统软件技术要求和设计的错误。

第三章 测试技术分类 一、按照策略分类：

有两种：静态测试和动态测试； A）静态测试包括：

1、代码审查（包括代码评审和走查）。

检查代码和设计的一致性；检查代码的标准性、可读性；检查代码逻辑表达的正确性和完整性；检查代码结构的合理性等。（所以测试人员的基本功之一就是要求有代码阅读能力） 2、静态分析。

主要对程序进行控制流分析、数据流分析、接口分析和表达式分析等。 3、文档检查。

主要是对开发阶段产生的需求说明、设计说明等文件及相关规格说明等文档。 B）动态测试包括:

1、功能测试（黑盒、非分析方法）：等价类、因果图、边界、强度等

2、结构测试（白盒、分析方法）：语句测试、分支测试、条件测试、路径测试等。 实际测试工作中的大部分测试形态都属于动态测试 C）手工测试与自动测试

1、手工测试是传统的测试方法，也是现在大多数公司都使用的测试形式。它由测试人员来执行测试用例，然后根据实际的结果去和预期的结果相比较并记录测试结果。

11

企业应用软件测试实训课程

2、成熟的自动测试机制，可以在机器空闲的时候通过“按钮触发”执行夜间测试。自动测试是可重复的，在相同的序列中使用完全相同的输入再次进行测试，是在手工测试中不能保证的。同时，可以提高测试的效率和测试的准确性，优秀的测试脚本还可以在软件测试的各个阶段重复使用。它的使用可以很快、很广泛的查找缺陷，但是它通常只能测试某个已知功能是否仍然可以正确运行。完全替代手工测试是不显示的，而且编写和维护测试脚本工作量也很大。因此在实际测试工作中，手工测试和自动测试是相结合的。 D）冒烟测试

主要是对应用程序关键的功能进行测试，一般来说是在版本下来投入正式测试之前，对一些重点部分功能进行确认，以决定此版本是进入正式测试阶段，还是返回开发租。它不是手动地测试所有已知的缺陷，也不是反复执行所有功能的测试，而是由针对性的通过验证软件中的主要功能是否能够正常运行，来确认是否由必要讲测试人员的工作都转移到对新版本的测试中。 E）回归测试

回归测试就是过一段时间以后再回过头来对以前修复过的缺陷重新进行测试，看该缺陷是否会重新出现。同时要主要对修改的缺陷要检查是否还印发其他新的问题。所以，当软件发生变化是，就必须重新测试现有的功能，见车啊修改是否损害了原有的正常功能。总之就是为了验证修改的正确性及其影响。 二、按照方法分类：

有两种：黑盒测试、白盒测试； 2.1黑盒测试

黑盒测试又称功能测试、数据驱动测试或基于规格说明的测试，这一方法是把测试对象看作一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。通过黑盒测试可以知道应用程序是否符合用户的预期要求，主要适用于集成测试、系统测试、验收测试等。

功能测试是在规定的一段时间内运行软件系统的所有功能，以验证这个软件系统有无严重错误。测试方法包括：等价类划分、边界值分析、因果图、错误推测、ALAC、判定表驱动分析方法、正交实验设计方法、功能图分析方法等。 2.1.1等价类划分

等价类划分是最典型、最常用的黑盒测试方法。采用此方法具体的原因是：由于穷举测试的办法数量太大，以至于无法实际完成，自然促使我们在大量的可能数据中选取其中的一部分作为测试用例。等价类划分就是分步骤地把无限多的测试用例减少到同样有效的小范围的过程。 1）等价类划分的方法

等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干

12

企业应用软件测试实训课程

等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类。

A）有效等价类：是指对程序的需求规格是有意义的、合理的输入数据所构成的集合。在具体问题中，有效等价类可以是一个，也可以是多个。

B）无效等价类：无效等价类指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。一般来讲，无效等价类会有多个，对于输入数据较多的情况，无效等价类要比有效等价类的数量要多。 设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性. 2）确定等价类的原则：

①如果输入条件规定了取值范围或取值的个数，则可确定一个有效等价类和两个无效等价类。例如，程序的规格说明中提到的输入条件包括“…项数可以从1到999…，”则可以取有效等价类“1<项数<999”。无效等价类为“项数<1”及“项数>999”。又如，程序规格说明中提到“…学生允许选修2至4门课…”，有效等价类可取“选课2至4门”，无效等价类为“只选一门或未选课”及“选课超过4门”。 ②输入条件规定了输入值的集合，或是规定了“必须如何”的条件，则可确定一个有效等价类和一个无效等价类。例如，某程序的规格说明中提到的输入条件包括“…统计全国各省、市、自治区的人口…”，则应取“国内省、市、自治区”为有效等价类，“非国内省、市、自治区”为无效等价类。

③如果我们确知，已划分的等价类中各元素在程序中的处理方式是不同的，则应将此等价类进一步划分成更小的等价类。

④ 在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类.

⑤在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类.

⑥在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）.

⑦在确立了等价类后,可建立等价类表,列出所有划分出的等价类:输入条件 有效等价类 无效等价类。等价类表格形式：

输入条件 …………

3）确定测试用例步骤：

①为每个等价类规定一个唯一的编号。

②设计一个测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步，最后使得所有有效等

13

有效等价类 ………… 无效等价类 ………… 企业应用软件测试实训课程

价类均被测试用例所覆盖。

③设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步使所有无效等价类均被覆盖。 看起来等价类划分比较简单，事实也的确如此。但大家要注意：等价类划分的目标是把可能的测试用例组合缩减到仍然足以测试软件的控制范围。因为我们选择了这种不完全测试点方法，就要存在一定的风险，所以测试人员一定要仔细进行等价分类。如果为了减少测试用例的数量，过度进行等价分配，测试遗漏软件缺陷的风险就会增加。对于软件测试新员工，可以请经验丰富的测试工程师审查等价类划分是否合理。

4) 等价类有效法案例设计

明确测试的目标，一般适合用到的范围是，制定被测试的对象是在满足某个条件的区间内的所有数据。 从其中区间数据段中选择任意一个或者两个数据，只要这个数据满足了，那么其他的数据就是满足的。

范例 1 ：在登陆某系统需要验证用户名，要求是长度是最小是 6 位，最长是 14 位，名字中可以包含数字，但是不能以数字开头，可以包含各种符号，不能包含中文。 1 、随意字母组合成一个 12 位的姓名，测试是否可以通过验证。 2 、随意生成一个长度 12 位的姓名，测试是否可以通过验证 3 、测试以任意一个数字打头 12 位的姓名，测试是否可以通过验证 4 、测试姓名长度为 12 位且包含中文情况，测试是否可以通过验证 5 、测试长度不满足条件情况下，是否通过验证 6 、如果长度不满足，是以数字开头的，提示信息验证 7 、如果长度不满足，姓名中包含中文的，提示信息验证……

注：这个可能比较简单，但是说明一个问题：为什么随意生成一个 12 位姓名的 , 其实你选择 8 位姓名长度或者 10 位姓名长度是一样的，所以这种情况下考虑采用等效方法比较合适。

范例 2 ：要求选择 1~12 之间进行调整，手机的背光就会随着数值的变化而变化。总体的是数值越大越暗。

测试案例设计：清晰记忆 1 的情况，然后随意调整一个数值，因为要求是变化了，至于变化成什么样子，变暗到什么程度才正确，没有明确的指标数值，所以只需要记住临街点 1 的情况，然后随意调整一个数据，然后和当前调整后的数据进行比较。

注：没有明确的说明，只是含糊的结果，但是总体的结果是在变化，那么这个时候比较适合使用等效法。 2.1.2边界值分析法

1）边界值分析法是对程序输入输出的边界情况进行测试。

由于大量的错误发生在输入和输出范围的边界上，因此，对各种边界情况设计测试用例，可以查处更多

14

企业应用软件测试实训课程

的错误。边界值分析方法和等价类方法的测试内容，主要为数据的各个输入字段允许输入的正确与否。包括对小于最小范围值、等于最小范围值、正常范围值、等于最大范围值、大于最大范围值、输入数据类型非法、输入是否允许为空、不可更改的显示数据的更改性、不可见字符是否允许输入等的测试。还包括对输出条件的测试，和对数据库、数组、数据列的预定义边界值的测试。

2）边界值分析法设计原则是：

边值可能涉及到的数据类型包括数值、速度、尺寸、字符、地址、位置、数量等；

如果输入条件规定了取值的范围，应选择正好等于边界的值，略小于最小值和/或略大于最大值的值作为测试数据。

如果输入条件规定了值的个数，应选择最小的个数、最大的个数、略小于最小和略大于最大的个数作为测试数据。

输入、输出项若是一个有序的集合，则选择第一个元素和最末元素作为测试数据。

如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例。 分析规格说明,找出其它可能的边界条件.

在做边界值分析时，要考虑具有以下特征：第一个/最后一个；最小值/最大值；开始/完成；超过/在内；空/满；最短/最长；最慢/最快；更早/更迟；最大/最小；最高/最低；相邻/最远。ASCII表 、默认、空白、空值和无；非法、错误、不正确和垃圾处理。

在测试案例执行的过程中，所有调节的数据都需要考虑到边界数值的测试方法，但是需要注意，边界数值的测试不是枚举，只是抽样的方法。 2.1.3因果图法

前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）.因果图方法最终生成的就是判定表.

因果图法适用于输入条件之间关系比较复杂，不同的条件组合会产生若干动作的情况。通过判定表的形式，可以很好地表达多种条件组合产生不止一个动作，其中输入条件就是因，输出条件就是果。 1）使用因果图的好处

多个输入之间的相互组合、相互制约关系；能够帮助我们按一定步骤，高效率地选择测试用例，同时还能为我们指出，程序规格说明描述中存在着什么问题 2）利用因果图导出测试用例需要经过的一般步骤

1.分析程序规格说明的描述中，哪些是原因，哪些是结果。

15

企业应用软件测试实训课程

2.分析程序规格说明的描述中语义的内容，并将其表示成连接各个原因与各个结果的因果图； 3.在因果图上使用若干个特殊的符号标明特定的约束条件； 4.把因果图转换成判定表；

5.把判定表中每一列表示的情况写成测试用例 ；

从因果图生成的测试用例（局部,组合关系下的）包括了所有输入数据的取TRUE与取FALSE的情况,构成的测试用例数目达到最少,且测试用例数目随输入数据数目的增加而线性地增加.

前面因果图方法中已经用到了判定表.判定表（Decision Table）是分析和表达多逻辑条件下执行不同操作的情况下的工具.在程序设计发展的初期,判定表就已被当作编写程序的辅助工具了.由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确. 判定表通常由四个部分组成.

条件桩（Condition Stub）:列出了问题得所有条件.通常认为列出得条件的次序无关紧要. 动作桩（Action Stub）:列出了问题规定可能采取的操作.这些操作的排列顺序没有约束. 条件项（Condition Entry）:列出针对它左列条件的取值.在所有可能情况下的真假值. 动作项（Action Entry）:列出在条件项的各种取值情况下应该采取的动作.

规则:任何一个条件组合的特定取值及其相应要执行的操作.在判定表中贯穿条件项和动作项的一列就是一条规则.显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列. 判定表的建立步骤:（根据软件规格说明）

①确定规则的个数.假如有n个条件.每个条件有两个取值（0,1）,故有 种规则. ②列出所有的条件桩和动作桩. ③填入条件项.

④填入动作项.等到初始判定表. ⑤简化.合并相似规则（相同动作）. 适合使用判定表设计测试用例的条件:

①规格说明以判定表形式给出,或很容易转换成判定表. ②条件的排列顺序不会也不影响执行哪些操作. ③规则的排列顺序不会也不影响执行哪些操作.

④每当某一规则的条件已经满足,并确定要执行的操作后,不必检验别的规则. ⑤如果某一规则得到满足要执行多个操作,这些操作的执行顺序无关紧要.

16

企业应用软件测试实训课程

3）因果图基本符号

4)因果图法案例设计

该方法需要有一定的程序基础，了解程序的架构，就是当问题发生以后，能够有效的补充相关的案例或者筛选相关的案例。因果分析的核心是从自己的理解去分析问题所在的真正原因。 2.1.4错误推测方法

错误推测法: 基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.

错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.

错误推测法，即异常情况测试，也是黑盒测试的一种方法，依靠经验和直觉推测软件中可能存在的各种错误，编写检查这些错误的测试用例。包括业务数据异常测试、系统异常测试、通信异常测试、用户异常测试和界面异常测试。

1、业务数据异常测试，主要包括数据输入输出的一致性测试、不同批次业务合并处理测试和特殊日期处理测试。即测试数据接受方是否拒绝接受被重发和被漏发的数据，发送数据的时候是否可以将未发送的数据一起发送，接受数据的时候是否可以将未接受的数据一起接受，是否可以处理特殊日期前后的业务。

2、通信异常测试，为连接业务路径的时间异常的测试，即连接超时测试、传输超时测试和处理超时测试。方法：在需要传输大量数据的功能进行的过程中，关闭对方系统、或网络通信设备、或中断网络连接。检测应用系统进行数次传输尝试之后是否错误报警。然后将网络线路恢复正常，再次传输数据，查看系统是否能够继续正确传输处理。

3、系统异常测试，为针对任务中断的测试。任务中断，包括打印输出中断、服务进程中断、应用软件

17

企业应用软件测试实训课程

死锁或者中断、并发进程互锁、批量文件大小与报文中文件大小不符等情况。方法：应用程序中打印某种凭证或报表，当打印机开始运作时，关闭打印机或使用命令取消打印作业，从而导致打印中断。重新使用打印功能输出刚才打印的凭证或报表。检测是否允许重新补打。

4、用户异常测试，为针对行为中断的测试。行为中断，包括用户中断和机器中断，例如客户端非正常退出和服务器故障等情况。方法：检测操作员方法，是以该操作员的身份登录应用系统

5、界面异常测试，包括窗口乱码、快捷键异常、光标滚动异常和数据项显示异常等测试。方法：打开应用系统的所有用户界面，观察是否出现由于窗口重叠而造成的乱码，窗口错位等异常现象。 2.1.5 ALAC（Act-Like-A-Customer）测试

ALAC测试测试是一种基于用户使用产品的知识开发出来的测试方法。ALAC测试方法是针对目前庞大而复杂的软件产品来应用的，因为软件愈复杂，存在的缺陷也就愈多，愈难于发现。而测试的执行要求有效性要高，所以要充分考虑用户可能会遇到的错误。采用此方法最大的受益者是用户，测试的计划和测试用例的设计以及测试工作实施都是针对那些客户最容易遇到的错误。

采用ALAC测试方法时，首先要通过数据采集和分析，得出用户剖面，按用户对软件所执行的功能点情况和执行方式开发和执行测试用例。采用ALAC测试方法后，用户可能遇到的缺陷都在测试阶段被发现并得到解决，等用户使用软件时，用户对软件的满意度自然就高，那么我们的软件质量也会非常高。 ALAC测试从严格意义上讲，它并不是一种测试技术，而只是一种根据实际情况而采用的测试策略，体现软件以用户需求为中心，体现软件的质量是以用户的满意度为核心的思想。但是，如何选择用户数据，如何进行分析和设计设计测试用例，是在日常工作中逐渐积累经验的。 2.1.6其他方法

还有一些测试方法为业界所公认，但是实际上使用并不广泛的方法，主要原因是这些方法并不实用或者操作复杂应用性不强。供大家参考，有：正交实验设计法和判定表驱动测试。

在实际的测试过程中，要综合运用多种测试方法。在测试中，有时需要借助其他的功能模块来运行要测试的部分，这样就产生了用于测试的其他功能模块是否正确的问题。这在集成测试中比较突出，为了避免引入新的错误，可以考虑采用增值的测试方法，从一个模块开始，自顶向下或自底向上，用已经通过测试的模块作为将要进行测试的模块产生输入或接收输出，逐步增加新的模块，最终完成整体的集成测试。

在逻辑分析方面，也需要有一定的程序理解能力。从程序逻辑和日常常识去判断问题。逻辑分析法其实就一堆假设的罗列，推论出系列结果的假设，然后将假设反推翻，问题就可以暴露出来。无论那种方法都是通过表现去分析问题的实质的。

范例 1: 我们在做 MP3 播放器快进和快退测试中，要考虑的同步问题，就是我们液晶显示屏上出现的歌词进度，时间进度和我们耳朵听到的进度不同。我们分析一下，为什么出现不同步现象，为什么其他的能同步，就某一个或者某几个不能同步。首先我们了解同步的算法：快进和快退是按照当前歌曲的数据流来计算应该到那里，它是以当前歌曲的数据流为系数，然后进行的一些调整，那么出现不同步的原

18

企业应用软件测试实训课程

因是由于系数不同造成的，所以考虑到同步问题，我们需要找不同格式不同数据流的歌曲，这样问题容易暴露，容易清楚的定位问题的真正原因。

无论采用什么样的测试方法，都不要忘记，测试不是的一项工作，是软件生命周期中的一个阶段，测试的依据必须是当初的需求和设计目标，要避免把对软件的新的想法与测试工作混杂起来，这是目前在进行实际测试工作中最容易出现的问题。 案例：黑盒测试方法应用—用户注册 一．用户注册

只从用户名和密码角度写了几个要考虑的测试点，如果需求中明确规定了安全问题，Email，出生日期，地址，性别等等一系列的格式和字符要求，那就都要写用例了。 以等价类划分和边界值法来分析

1.填写符合要求的数据注册: 用户名字和密码都为最大长度 （边界值分析，取上点） 2.填写符合要求的数据注册 :用户名字和密码都为最小长度 （边界值分析，取上点）

3.填写符合要求的数据注册:用户名字和密码都是非最大和最小长度的数据（边界值分析，取内点） 4.必填项分别为空注册

5.用户名长度大于要求注册1位（边界值分析，取离点） 6.用户名长度小于要求注册1位（边界值分析，取离点） 7.密码长度大于要求注册1位（边界值分析，取离点） 8.密码长度小于要求注册1位（边界值分析，取离点）

9.用户名是不符合要求的字符注册（这个可以划分几个无效的等价类，一般写一两个就行了,如含有空格，#等，看需求是否允许吧~）

10.密码是不符合要求的字符注册（这个可以划分几个无效的等价类，一般写一两个就行了） 11.两次输入密码不一致(如果注册时候要输入两次密码，那么这个是必须的） 12.重新注册存在的用户

13.改变存在的用户的用户名和密码的大小写，来注册。（有的需求是区分大小写，有的不区分） 14.看是否支持tap和enter键等；密码是否可以复制粘贴；密码是否以* 之类的加秘符号显示。 二．修改密码

当然具体情况具体分析，不能一概而论。

实际测试中可能只用到其中几条而已，比如银行卡密码的修改，就不用考虑英文和非法字符，更不用考虑那些ＴＡＰ之类的快捷键。

19

企业应用软件测试实训课程

而有的需要根据需求具体分析了,比如连续出错多少次出现的提示，和一些软件修改密码要求一定时间内有一定的修改次数等等。 1.不输入旧密码，直接改密码 2.输入错误旧密码 3.不输入确认新密码 4.不输入新密码

5.新密码和确认新密码不一致 6.新密码中有空格 7.新密码为空

8.新密码为符合要求的最多字符 9.新密码为符合要求的最少字符

10.新密码为符合要求的非最多和最少字符 11.新密码为最多字符-1 12.新密码为最少字符+1 13.新密码为最多字符+1 14.新密码为最少字符-1

15.新密码为非允许字符（如有的密码要求必须是英文和数字组成，那么要试汉字符号等） 16.看是否支持tap和enter键等；密码是否可以复制粘贴；密码是否以* 之类的加秘符号 17.看密码是否区分大小写，新密码中英文小写，确认密码中英文大写． 18.新密码与旧密码一样能否修改成功．

注册的时候测试了密码长度,修改的时候为什么还要测试？这里举个例子,把密码改成了mimaxiugaih,后来怎么也上不去了.因为资料填写不全无法找回密码.后来在注册过程中发现,注册的时候密码长度最长是10位,这时用了原来的用户名和的密码mimaxiugai就进去了. 这表明,修改密码时候的最大长度和注册及登陆的时候密码最大长度有可能是不一致的. 三、对于权限测试主要包括以下内容

根据需求等相关文档，查看程序设置权限级别是否正确，即每一级别的用户所能执行的功能是否分配正确

测试方法：建立不同权限级的用户进入系统，查看菜单、操作命令有效、无效设置是否正确。 四、对用户名、密码的有效性进行测试

20

企业应用软件测试实训课程

测试方法：最有效的方法是采用等价类划分的方法，其中要考虑： （1）是否区分大小写 （2）是否允许重名

（3）用户名长度测试：有效长度、无效长度 （4）信息有效性测试：特殊字符、正常字符、空字符

（5）口令锁定：即输入口令次数的，据说这是对付远程暴力攻击猜测密码的有效技术

以上是在测试时需要考虑的测试点，因为信息的多样性，所以对权限测试前要设计好测试用例，否则直接测试，肯定会有遗漏地方。

还要考虑程序访问数据库的权限设置，注意在源程序中不要有默认的用户名和密码连接数据库。 对于单个的权限进行测试问题不大。主要的问题还是在于权限的分级与交叉权限，如果按照排列组合进行权限的交叉将会是一个无比庞大的测试用例。关键在于权限组合－－这个价类如何来划分。

在进行权限测试的时候，优先执行和模拟用户日常使用的权限，也就是使用最频繁的操作。考虑哪些权限在使用过程中风险比较大，模拟进行测试。

2.2白盒测试

白盒测试又称结构测试、逻辑驱动测试或基于程序本身的测试，这一方法是把测试对象看作一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。主要是检查程序的内部结构、逻辑、循环和路径。其常用测试用例设计方法有：逻辑覆盖和基本路径测试。根据覆盖测试的目标不同，逻辑覆盖又可分为：语句覆盖，判定覆盖，判定－条件覆盖，条件组合覆盖及路径覆盖等。通过在不同点检查程序的状态，确定实际状态是否与预期的状态一致。白盒测试不关心应用程序的功能要求，而是对软件的过程性细节做细致的检查，它主要用于单元测试、集成测试。

白盒测试的主要方法有程序结构分析和逻辑覆盖两种分析方法。 执行白盒测试时，一般要：

1)对程序模块的所有的执行路径至少测试一次；

2)对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测试一次； 3)在循环的边界和运行界限内执行循环体； 4)测试内部数据结构的有效性，等等。 白盒测试分为动态白盒测试和静态白盒测试。

21

企业应用软件测试实训课程

2.2.1静态白盒测试

利用眼睛，浏览代码，凭借经验，找出代码中的错误或者代码中不符合书写规范的地方。比如，代码规范中规定，函数必须为动宾结构。而黑盒测试发现一个函数定义如下： Function NameGet(){ …. }

这是属于不符合开发规范的错误。 有这样一段代码: if (i<0) & (i>=0) …

这段代码交集为整个数轴，IF语句没有必要 I=0;

while(I>100){ J=J+100; T=J*PI; }

在循环体内没有I的增加,bug产生。 2.2.2 动态白盒测试

利用开发工具中的调式工具进行测试。比如一段代码有4个分支，输入4组不同的测试数据使4组分支都可以走通而且结果必须正确。 看一段代码 if(I<0){ P1 }else{ P2 }

在调试中输入I=-1,P1程序段通过， P2程序段未通过，属于动态黑盒测试的缺陷。

22

企业应用软件测试实训课程

三、按照阶段分类：

包括：单元测试、集成测试、确认测试、系统测试；

单元测试：最微小规模的测试；以测试某个功能或代码块。典型地由程序员而非测试员来做，因为它需要知道内部程序设计和编码的细节知识。这个工作不容易作好，除非应用系统有一个设计很好的体系结构; 还可能需要开发测试驱动器模块或测试套具。

集成测试：一个应用系统的各个部件的联合测试，以决定他们能否在一起共同工作。部件可以是代码块、的应用、网络上的客户端或服务器端程序。这种类型的测试尤其与客户服务器和分布式系统有关。 系统测试：基于系统整体需求说明书的黑盒类测试；应覆盖系统所有联合的部件。 四、按照内容分类：

有以下14种：数据和数据库完整性测试、功能测试、UI测试、性能测试、安全性和访问控制测试故障转移和恢复测试、配置测试、安装测试、多语种测试、文字测试、分辨率测试、发布测试。 4.1. 数据和数据库完整性测试

数据与数据库完整测试是指测试关系型数据库完整性原则以及数据合理性测试。 数据库完整性原即：

A）主码完整性：主码不能为空；

B）外码完整性：外码必须等于对应的主码或者为空。

数据合理性指数据在数据库中的类型，长度，索引等是否建的比较合理。

在项目名称中，数据库和数据库进程应作为一个子系统来进行测试。在测试这些子系统时，不应将测试对象的用户界面用作数据的接口。对于数据库管理系统 (DBMS)，还需要进行深入的研究，以确定可以支持测试的工具和技术。 4.2. 功能测试

功能测试指测试软件各个功能模块是否正确，逻辑是否正确。对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。此类测试基于黑盒技术，该技术通过图形用户界面 (GUI) 与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。功能测试的主要参考为类似于功能说明书之类的文档。 4.3. UI测试

UI测试指测试用户界面的风格是否满足客户要求，文字是否正确，页面美工是否好看，文字，图片组合是否完美，背景是否美观，操作是否友好等等。用户界面 (UI) 测试用于核实用户与软件之间的交互。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外，UI

23

企业应用软件测试实训课程

测试还可确保 UI 中的对象按照预期的方式运行，并符合公司或行业的标准。包括用户友好性，人性化，易操作性测试。UI测试比较主观，与测试人员的喜好有关。 4.4. 性能测试

性能测试主要测试软件测试的性能，包括负载测试，强度测试，数据库容量测试，基准测试以及竞争测试

A）负载测试

负载测试是一种性能测试指数据在超负荷环境中运行，程序是否能够承担。

在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。 B）强度测试

强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况。这类测试往往可以书写系统要求的软硬件水平要求。实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。 C）数据库容量测试

数据库容量测试指通过存储过程往数据库表中插入一定数量的数据，看看相关页面是否能够及时显示数据。数据库容量测试使测试对象处理大量的数据，以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。 D）基准测试

基准测试与已知现有的系统进行比较，主要检验是否与类似的产品具有竞争性的一种测试。如果你要开发一套财务系统软件并且你已经获得用友财务系统的性能等数据，你可以测试你这套系统，看看哪些地方比用友财务系统好，哪些地方差？以便改进自己的系统，也可为产品广告提供数据。 E）竞争测试

软件竞争使用各种资源（数据纪录，内存等），看他与其他相关系统对资源的争夺能力。比如：一台机器上即安装您的财务系统，又安装用友财务系统。当CPU占有率下降后，看看是否能够强过用友财务系统，而是自己的系统能够正常运行？ 4.5. 安全性和访问控制测试

安全性和访问控制测试侧重于安全性的两个关键方面：应用程序级别的安全性，包括对数据或业务功能

24

企业应用软件测试实训课程

的访问系统级别的安全性，包括对系统的登录或远程访问。 A）应用程序级别的安全性

可确保：在预期的安全性情况下，主角只能访问特定的功能或用例，或者只能访问有限的数据。 B）系统级别的安全性

可确保只有具备系统访问权限的用户才能访问应用程序，而且只能通过相应的网关来访问。 4.6. 故障转移和恢复测试

故障转移和恢复测试指当主机软硬件发生灾难时候，备份机器是否能够正常启动，使系统是否可以正常运行，这对于电信，银行等领域的软件是十分重要的。故障转移和恢复测试可确保测试对象能成功完成故障转移，并能从导致意外数据损失或数据完整性破坏的各种硬件、软件或网络故障中恢复。故障转移测试可确保：对于必须持续运行的系统，一旦发生故障，备用系统就将不失时机地“顶替”发生故障的系统，以避免丢失任何数据或事务。恢复测试是一种对抗性的测试过程。在这种测试中，将把应用程序或系统置于极端的条件下（或者是模拟的极端条件下），以产生故障（例如设备输入/输出 (I/O) 故障或无效的数据库指针和关健字）。然后调用恢复进程并监测和检查应用程序和系统，核实应用程序或系统和数据已得到了正确的恢复。一定要注意定时备份。4.7. 配置测试

又叫兼容性测试。配置测试核实测试对象在不同的软件和硬件配置中的运行情况。在大多数生产环境中，客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如，应用程序、驱动程序等而且在任何时候，都可能运行许多不同的软件组合，从而占用不同的资源。（如浏览器版本，操作系统版本等）。下面列出主要配置测试： A）浏览器兼容性

测试软件在不同产商的浏览器下是否能够正确显示与运行；比如测试IE，Natscape浏览器下是否可以运行这套软件？ B）操作系统兼容性

测试软件在不同操作系统下是否能够正确显示与运行；

比如测试WINDOWS98,WINDOWS 2000,WINDOWS XP,LINU, UNIX下是否可以运行这套软件？ C）硬件兼容性

测试与硬件密切相关的软件产品与其他硬件产品的兼容性，比如该软件是少在并口设备中的，测试同时使用其他并口设备，系统是否可以正确使用。比如在INTER,舒龙CPU芯片下系统是否能够正常运行？这样的测试必须建立测试实验室，在各种环境下进行测试。 4.8. 安装测试

安装测试有两个目的。第一个目的是确保该软件在正常情况和异常情况的不同条件下: 例如，进行首次安装、升级、完整的或自定义的安装_都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限

25

企业应用软件测试实训课程

等。第二个目的是核实软件在安装后可立即正常运行。这通常是指运行大量为功能测试制定的测试。安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装，安装代码提供安装一些程序能够运行的基础数据。 4.9. 多语种测试

又称本地化测试，是指为各个地方开发产品的测试，如英文版，中文版等等，包括程序是否能够正常运行，界面是否符合当地习俗，快捷键是否正常起作用等等，特别测试在A语言环境下运行B语言软件（比如在英文win98下试图运行中文版的程序），出现现象是否正常。本地化测试还要考虑： a)当语言从A翻译到B，字符长度变化是否影响页面效果。 b)要考虑同一单词在各个国家的不同意思。 c)要考虑各个国家的民族习惯。 4.10. 文字测试

文字测试测试软件中是否拼写正确，是否易懂，不存在二义性，没有语法错误；文字与内容是否有出入等等，包括图片文字。 4.11. 分辨率测试

测试在不同分辨率下，界面的美观程度,分为800*600，1024*768，1152*8，1280*768，1280*1024，1200*1600大小字体下测试。一个好的软件要有一个极佳的分辨率，而在其他分辨率下也都能可以运行。 4.12. 发布测试

主要在产品发布前对一些附带产品，比如说明书，广告稿等进行测试。

第四章 软件测试模型 1、V模型

26

企业应用软件测试实训课程

V模型最早由Paul Rook在80年代后期提出，旨在改进软件开发的效率和效果。V模型在欧洲尤其是英国被广泛接受，并被认为是瀑布模型的替代品，然而在美国普及程度却并不理想，但是这不妨碍V模型的优势。在现阶段的中国软件开发市场，V模型是一种合适的选择方案。非常明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系。但V模型存在一定的局限性，它仅仅把测试作为在编码之后的一个阶段，是针对程序进行的寻找错误的活动，而忽视了测试活动对需求分析、系统设计等活动的验证和确认的功能。

确认/系统测试报告 需求分析 确认/系统测试 确认/系统测试计划（说明） 集成测试报告 概要设计 集成测试计划（说明） 详细设计 单元测试计划（说明） 编码 W模型由Evolutif公司公司提出，相对于V模型，W模型增加了软件各开发阶段中应同步进行的验证和确认活动。如图所示，W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。但W模型也存在局限性。在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式 开始下一个阶段工作。

集成测试 单元测试报告 单元测试 27

企业应用软件测试实训课程

X模型提出针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的 交接，通过集成最终合成为可执行的程序。前置测试模型体现了开发与测试的结合，要求对每一个交付内容进行测试。这些模型都针对其他模型的缺点提出了一些修 正意见，但本身也可能存在一些不周到的地方。所以在测试过程管理中，正确选取过程模型是一个关键问题。

28

企业应用软件测试实训课程

2、H模型

将测试活动完全出来，形成了一个完全的流程，将测试准备活动和测试执行活动清晰地体现出来。H模型揭示了一个原理：软件测试是一个的流程，贯穿产品整个生命周期，与其他流程并发地进行。H模型指出软件测试要尽早准备，尽早执行。不同的测试活动可以是按照某个次序先后进行的，但也可能是反复的，只要某个测试达到准备就绪点，测试执行活动就可以开展。

3、循环模型

是通常所说的PDCA模式或PDCA循环模型，PDCA循环是提高产品质量，改善企业经营管理的重要方法，是质量保证体系运转的基本方式。

P－（plan）计划：根据项目的进度和客户的需求，以及测试规范和实际情况，制定有效的《测试计划》和《测试说明》，“良好的开始是成功的一半”，有效的测试计划和高质量的测试说明是至关重要的； D－（do）实施：即测试实施过程，要求测试工作既要严格按测试计划执行，又要工作高效，这需要测试人员要有测试过程的记录，并对发现的BUG及时跟踪并推动解决；

C－（check）检查：通过测试结果，找到与预期质量要求之间的差别，为项目开发过程的改进提供充足的数据结果和建议，通过测试人员的《测试报告》来反映出来；另外，也要对测试工作本身进行检查，总结测试过程的经验和教训，通过《测试总结报告》来进行实事求是地总结；

A－（action）改进：测试工作质量的提高和测试人员水平的提升很大程度要来源于实践，这就意味着每次项目测试实践后，需要积累测试经验，并尽量弥补不足。这一点对于我们目前年轻的软件测试行业和测试队伍尤为重要，不重视改进的工作策略终将“不进则退”。

V模型强调了在整个项目开发中需要经历的不同的测试级别，但忽视了测试的对象不应该仅仅是程序。而W模型在这一点上进行了补 充，明确指出应该对需求、设计进行测试。但是V模型和W模型都没有将一个完整的测试过程抽象出来，成为一个的流程，这并不适合当前软件开发中广泛应用 的迭代模型。H模型则明确指出测试的性，也就是说只要测试条件成熟了，就可以开展测试。在测试实践中，我们采用的方法是：以W模型作为框架，及早的、全面的开展测试。同时灵活运用H模型

29

企业应用软件测试实训课程

测试的思想，在达到恰当的就绪点时就应该开展的测试工作，同时将测试工作进行迭代，最终保证完成测试目标。

30

企业应用软件测试实训课程

第五章 软件测试流程概述 一、复习巩固 二、测试流程概述 2.1流程的意义

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

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

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

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

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

测试流程，简单的说就是： 需求定义与分析阶段建立测试计划；

31

企业应用软件测试实训课程

概要设计阶段建立测试计划 ，更新测试计划； 详细设计阶段建立、确定测试计划，更新测试计划； 实现阶段设计开发测试用例、执行测试用例、完成测试计划； 测试阶段执行测试用例、评估测试结果。

开发计划测试需求输计划阶段输入评审设计阶段入评审执行阶段总结阶段输测试说明··出·

2.2.1 测试工作总体流程图

一般而言，软件测试从项目确立时就开始了，前后要经过以下一些主要环节：

需求分析→测试计划→测试设计→测试环境搭建→测试执行→测试记录→缺陷管理→软件评估→RTM. 注：RTM(Release to Manufacturing) Manufacturing是制造的意思。正式在零售商店上架前，是不是需要一段时间来压片，包装、配销呢？所以程序代码必须在正式发行前一段时间就要完成，这个完成的程序代码叫做Final.Code，这次Windows XP开发完成，外国媒体用Windows XP.goes.gold来称呼。程序代码开发完成之后，要将母片送到工厂大量压片，这个版本就叫做RTM版。所以说，RTM版的程序码一定和正式版一样。但是和正式版也有不一样的地方：例如正式版中的OEM不能升级安装，升级版要全新安装的话会检查旧版操作系统光盘等，这些就是RTM和正式版不同的地 方，但是它们的主要程序代码都是一样的。

在进行有关问题阐述前，我们先明确下分工，一般而言，需求分析、测试用例编写、测试环境搭建、测试执行等属于测试开发人员工作范畴，而测试执行以及缺陷提交等属于普通测试人员的工作范畴，测试负责人负责整个测试各个环节的跟踪、实施、管理等。 说明：

1．流程各环节并未包含软件测试过程的全部，如根据实际情况还可以实施一些测试计划评审、用例评审，测试培训等。在软件正式发行后，当遇到一些严重问题时，还需要进行一些后续维护测试等。 2．各环节并不是没联系的，实际工作千变万化，各环节一些交织、重叠在所难免，比如编写测试

32

输出测试计划·输出输出测试状态报告阶段测试报告··测试报告测试总结企业应用软件测试实训课程

用例的同时就可以进行测试环境的搭建工作，当然也可能由于一些需求不清楚而重新进行需求分析等。这就和我们国家提出建设有中国特色的社会主义国家一样，只所以有中国特色，那是因为国情不一样。所以在实际测试过程中也要做到具体问题具体分析，具体解决。

2.2.2 需求阶段测试工作流程图

需求分析（Requirment Analyzing）应该说是软件测试的一个重要环节，测试开发人员对这一环节的理解程度如何将直接影响到接下来有关测试工作的开展。可能有些人认为测试需求分析无关紧要，这种想法是很不对的。需求分析不但重要，而且至关重要！一般而言，需求分析包括软件功能需求分析、测试环境需求分析、测试资源需求分析等。

其中最基本的是软件功能需求分析，测一款软件首先要知道软件能实现哪些功能以及是怎样实现的。比如一款Smartphone包括VoIP、Wi-Fi以及Bluetooth等功能。那我们就应该知道软件是怎样来实现这些功能的，为了实现这些功能需要哪些测试设备以及如何搭建相应测试环境等，否则测试就无从谈起！ 既然谈了需求分析，那么我们根据什么来分析呢？总不能凭空设想吧。

总得说来，做测试需求分析的依据有软件需求文档、软件规格书以及开发人员的设计文档等，相信管理一些规范的公司在软件开发过程中都有这些文档。

33

企业应用软件测试实训课程

注：Software Requirement Specification——软件需求规格说明书

34

企业应用软件测试实训课程

2.2.3 设计&编码阶段测试工作流程图

35

企业应用软件测试实训课程

2.2.4 集成、系统、验收测试阶段工作流程图

36

企业应用软件测试实训课程

2.3 软件测试阶段说明 2.3.1 单元测试

单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。一个软件单元的正确性是相对于该单元的规约而言的。因此，单元测试以被测试单位的规约为基准。单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。 2.3.2 集成测试

集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。它根据集成测试计划，一边将模块或其他软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。集成测试的策略主要有自顶向下和自底向上两种。 2.3.3 系统测试

系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的“先知者问题”。因此，系统测试应该按照测试计划进行，其输入、输出和其他动态运行行为应该与软件规约进行对比。软件系统测试方法很多，主要有功能测试、性能测试、随机测试等等。 2.3.4 验收测试

验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。所不同的是，验收测试常常有软件系统的购买者代表在现场，甚至是在软件安装使用的现场。这是软件在投入使用之前的最后测试。 2.3.5 回归测试

回归测试是在软件维护阶段，对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。这里，修改的正确性有两重含义：一是所作的修改达到了预定目的，如错误得到改正，能够适应新的运行环境等等；二是不影响软件的其他功能的正确性。 2.4 软件测试流程说明

软件测试是一个极为复杂的过程。一个规范化的软件测试过程通常须包括以下基本的测试活动。 ·拟定软件测试计划 ·编制软件测试大纲 ·设计和生成测试用例 ·实施测试

37

企业应用软件测试实训课程

·生成软件问题报告

对整个测试过程进行有效的管理实际上，软件测试过程与整个软件开发过程基本上是平行进行的。测试计划早在需求分析阶段即应开始制定，其它相关工作，包括测试大纲的制定、测试数据的生成、测试工具的选择和开发等也应在测试阶段之前进行。充分的准备工作可以有效地克服测试的盲目性，缩短测试周期，提高测试效率，并且起到测试文档与开发文档互查的作用。

此外，软件测试的实施阶段是由一系列的测试周期(Test Cycle)组成的。在每个测试周期中，软件测试工程师将依据预先编制好的测试大纲和准备好的测试用例，对被测软件进行完整的测试。测试与纠错通常是反复交替进行的。当使用专业测试人员时，测试与纠错甚至是平行进行的，从而压缩总的开发时间。更重要的是，由于专业测试人员丰富的测试经验、所采用的系统化的测试方法、全时的投入，特别是于开发人员的思维，使得他们能够更有效地发现许多单靠开发人员很难发现的错误和问题。

软件测试流程是一个软件企业测试过程的基础，所有的测试工作都应该是根据软件测试流程约定进行的，一般来说一个企业的测试流程应该包括测试计划，测试设计，测试执行，测试总结四个部分。软件测试与软件开发阶段的关系： 需求阶段： 确定测试策略 确定收集了足够的需求 产生功能性的测试用例 设计阶段

确定设计和需求之间的联系 确定进行了足够的设计 产生结构和功能的测试用例 编码阶段

确定和设计之间的联系 确定拥有执行的足够条件 产生结构和功能的测试用例 测试阶段

确定设计了足够的测试用例 测试应用系统已经完成 关键资源已经到位 安装阶段

38

企业应用软件测试实训课程

将测试完成的系统变为产品 维护阶段 修改和重新测试 2.4.1 制定测试计划

“工欲善其事，必先利其器”。专业的测试必须以一个好的测试计划作为基础。尽管测试的每一个步骤都是的，但是必定要有一个起到框架结构作用的测试计划。测试的计划应该作为测试的起始步骤和重要环节。一个测试计划应包括：产品基本情况调研、测试需求说明、测试策略和记录、测试资源配置、计划表、问题跟踪报告、测试计划的评审、结果等等。 1）产品基本情况调研：

这部分应包括产品的一些基本情况介绍，例如：产品的运行平台和应用的领域，产品的特点和主要的功能模块，产品的特点等。对于大的测试项目，还要包括测试的目的和侧重点。 具体的要点有： A）目的：重点描述如何使测试建立在客观的基础上，定义测试的策略，测试的配置， 粗略的估计测试大致需要的周期和最终测试报告递交的时间。

B）变更：说明有可能会导致测试计划变更的事件。包括测试工具改进了，测试的环境改变了，或者是添加了新的功能。

C）技术结构：可以借助画图，将要测试的软件划分成几个组成部分，规划成一个适用于测试的完整的系统，包括数据是如何存储的，如何传递的（数据流图），每一个部分的测试是要达到什么样的目的。每一个部分是怎么实现数据更新的。还有就是常规性的技术要求，比如运行平台、需要什么样的数据库等等。

D）产品规格：就是制造商和产品版本号的说明。

E）测试范围：简单的描述如何搭建测试平台以及测试的潜在的风险。

F）项目信息：说明要测试的项目的相关资料，如：用户文档，产品描述，主要功能的举例说明。

2）测试需求说明：

这一部分要列出所有要测试的功能项。凡是没有出现在这个清单里的功能项都排除在测试的范围之外。万一有一天你在一个没有测试的部分里发现了一个问题，你应该很高兴你有这个记录在案的文档，可以证明你测了什么没测什么。具体要点有：

功能的测试：理论上是测试是要覆盖所有的功能项，例如：在数据库中添加、编辑、删除记录等等，这会是一个浩大的工程，但是有利于测试的完整性。

设计的测试：对于一些用户界面、菜单的结构还有窗体的设计是否合理等的测试。

整体考虑：这部分测试需求要考虑到数据流从软件中的一个模块流到另一个模块的过程中的正确

39

企业应用软件测试实训课程

性。

3）测试的策略和记录：

这是整个测试计划的重点所在，要描述如何公正客观地开展测试，要考虑：模块、功能、整体、系统、版本、压力、性能、配置和安装等各个因素的影响。要尽可能的考虑到细节，越详细越好，并制作测试记录文档的模板，为即将开始的测试做准备，测试记录重要包括的部分具体说明如下： 公正性声明：要对测试的公正性、遵照的标准做一个说明，证明测试是客观的，整体上，软件功能要满足需求，实现正确，和用户文档的描述保持一致。

测试案例：描述测试案例是什么样的，采用了什么工具，工具的来源是什么，如何执行的，用了什么样的数据。测试的记录中要为将来的回归测试留有余地，当然，也要考虑同时安装的别的软件对正在测试的软件会造成的影响。

特殊考虑：有的时候，针对一些外界环境的影响，要对软件进行一些特殊方面的测试。 经验判断：对以往的测试中，经常出现的问题加以考虑。 设想：采取一些发散性的思维，往往能帮助你找的测试的新途径。

4）测试资源配置：

项目资源计划：制定一个项目资源计划，包含的是每一个阶段的任务、所需要的资源，当发生类似到了使用期限或者资源共享的事情的时候，要更新这个计划。

5）计划表：

测试的计划表可以做成一个多个项目通用的形式，根据大致的时间估计来制作，操作流程要以软件测试的常规周期作为参考，也可以是根据什么时候应该测试哪一个模块来制定。

6）问题跟踪报告：

在测试的计划阶段，我们应该明确如何准备去做一个问题报告以及如何去界定一个问题的性质，问题报告要包括问题的发现者和修改者、问题发生的频率、用了什么样的测试案例测出该问题的，以及明确问题产生时的测试环境。

问题描述尽可能是定量的，分门别类的列举，问题有几种：

1、严重问题：严重问题意味着功能不可用，或者是权限方面的失误等等，也可能是某个地方的改变造成了别的地方的问题。

2、一般问题：功能没有按设计要求实现或者是一些界面交互的实现不正确。

3、建议问题：功能运行得不象要求的那么快，或者不符合某些约定俗成的习惯，但不影响系统的性能，界面先是错误，格式不对，含义模糊混淆的提示信息等等。

7）测试计划的评审：

40

企业应用软件测试实训课程

又叫测试规范的评审，在测试真正实施开展之前必须要认真负责的检查一遍，获得整个测试部门人员的认同，包括部门的负责人的同意和签字。

8）结果：

计划并不是到这里就结束了，在最后测试结果的评审中，必须要严格验证计划和实际的执行是不是有偏差，体现在最终报告的内容是否和测试的计划保持一致，然后，就可以开始着手制作下一个测试计划了。

2.4.2 测试设计与开发

根据被测试特性，设计测试用例的结构，确定每一个测试用例的执行方式（手工、自动或半自动）、输入、期待的输出等。

一般而言，测试用例是指为实施一次测试而向被测系统提供的输入数据、操作或各种环境设置。测试用例控制着软件测试的执行过程，它是对测试大纲中每个测试项目的进一步实例化。已有许多著名的论著总结了设计测试用例的各种规则和策略。从工程实践的角度讲有几条基本准则:

1.测试用例的代表性:能够代表各种合理和不合理的、合法的和非法的、边界和越界的，以及极限的输入数据、操作和环境设置等;

2.测试结果的可判定性:即测试执行结果的正确性是可判定的或可评估的; 3.测试结果的可再现性:即对同样的测试用例，系统的执行结果应当是相同的。

测试设计阶段主要是参照各种相关文档对测试进行设计的工作，包括测试需求的分析和测试用例的设计两项工作。测试开发阶段是按照测试设计简单完成的测试需求分析与测试用例设计的方案要求进行实施的过程，该过程包括：测试用例数据的准备，测试工具的开发，测试脚本的开发录制和手工测试的实施等工作。此阶段的工作一直可能持续到软件测试的结束。具体内容请参看测试用例说明。 2.4.3 测试执行

按照测试计划执行测试用例，决定测试用例的通过或失败，如果通过进行测试总结；否则重新运行该测试用例或修改软件设计/编码/文档，然后重新进行测试。执行测试阶段是讲设计与实施两个阶段中设计好的测试方法及测试数据应用与实际软件测试过程中。在该阶段中同时存在对于前两个阶段进行补充的情况。

2.4.4 测试报告、总结与评估

按照评价标准评价测试工作和被测软件，当发现测试工作存在问题时，应该修订测试计划，进行重复测试，直至测试达到规定的要求。

测试评估是在测试结束后对整个测试过程与产品进行评估的过程。评估过程包括对测试工作的总结、缺陷数据的分析及测试过程的评估等。

报告软件测试错误的目的是为了保证修复错误的人员可以重复报告的错误，从而有利于分析错误产生的

41

企业应用软件测试实训课程

原因，定位错误，然后修正之。因此，报告软件测试错误的基本要求是准确、简洁、完整、规范。需要掌握的报告技术归纳如下。

1. 描述 (Description)，简洁、准确，完整，揭示错误实质，记录缺陷或错误出现的位置 。 描述要准确反映错误的本质内容，简短明了。为了便于在软件错误管理数据库中寻找制定的测试错误，包含错误发生时的用户界面（UI）是个良好的习惯。例如记录对话框的标题、菜单、按钮等控件的名称。

2. 明确指明错误类型：布局、翻译、功能、双字节 。

根据错误的现象，总结判断错误的类型。例如，即布局错误、翻译错误、功能错误、双字节错误，这是最常见的缺陷或错误类型，其他形式的缺陷或错误也从属于其中某种形式。 3. 短行之间使用自动数字序号，使用相同的字体、字号、行间距。

短行之间使用自动数字序号，使用相同的字体、字号、行间距，可以保证各条记录格式一致，做到规范专业。

4. UI要加引号，可以单引号，推荐使用双引号 。

UI加引号，可以容易区分UI与普通文本，便于分辨、定位缺陷或错误。 5. 每一个步骤尽量只记录一个操作 。 保证简洁、条理井然，容易重复操作步骤。 6. 确认步骤完整，准确，简短 。

保证快速准确的重复错误，“完整”即没有缺漏，“准确”即步骤正确，“简短”即没有多余的步骤。 7. 根据缺陷或错误类型，选择图象捕捉的方式 。

为了直观的观察缺陷或错误现象，通常需要附加缺陷或错误出现的界面，以位图的形式作为附件附着在记录的“附件”部分。为了节省空间，又能真实反映缺陷或错误本质，可以捕捉缺陷或错误产生时的全屏幕，活动窗口和局部区域。为了迅速定位、修正缺陷或错误位置，通常要求附加中英文对照图。 8. 附加必要的特殊文档和个人建议和注解 。

如果打开某个特殊的文档而产生的缺陷或错误，则必须附加该文档，从而可以迅速再现缺陷或错误。有时，为了使缺陷或错误修正者进一步明确缺陷或错误的表现，可以附加个人的修改建议或注解。 9. 检查拼写和语法错误 。

在提交每条缺陷或错误之前，检查拼写和语法，确保内容正确，正确的描述错误。 10. 尽量使用业界惯用的表达术语和表达方法。

使用业界惯用的表达术语和表达方法，保证表达准确，体现专业化。

42

企业应用软件测试实训课程

11. 通用UI要统一、准确 。

错误报告的UI要与测试的软件UI保持一致，便于查找定位。 12. 尽量使用短语和短句，避免复杂句型句式 。

软件错误管理数据库的目的是便于定位错误，因此，要求客观的描述操作步骤，不需要修饰性的词汇和复杂的句型，增强可读性。 13. 每条错误报告只包括一个错误 。

每条错误报告只包括一个错误，可以使错误修正者迅速定位一个错误，集中精力每次只修正一个错误。校验者每次只校验一个错误是否已经正确修正。

以上概括了报告测试错误的规范要求，随着软件的测试要求不同，测试者经过长期测试，积累了相应的测试经验，将会逐渐养成良好的专业习惯，不断补充新的规范书写要求。此外，经常阅读、学习高级测试工程师的测试错误报告，结合自己以前的测试错误报告进行对比和思考，可以不断提高技巧。 三、RUP中对测试过程的定义

RUP认为在软件开发生命周期中，软件是通过迭代来不断加以完善的。在这种环境中，对于每个作为测试目标的工作版本，测试的生命周期还都必须具有一种迭代方法。对于针对每个工作版本执行的测试，都做出了增补和改进，并累积为一个测试体，用于后续阶段的回归测试。该方法表明它将导致在整个流程中重复进行测试，就像修订软件本身一样。这里没有一成不变的软件规约，也没有一成不变的测试。 该迭代方法非常注重回归测试。迭代 X 中的大多数测试在迭代 X+1 中都用作回归测试。在迭代 X+2 中，将使用迭代 X 和迭代 X+1 中的大多数测试作为回归测试，后续迭代中采用的原则与此相同。因

为相同的测试要重复多次，所以投入一些精力将测试自动化将会获益良多。此外，也有必要有效地自动执行测试，来满足完工期限的要求。

在同一张图中，观察不具有项目其余部分的测试的生命周期。图中展示了不同测试活动在非迭代视图中相互联系的方式：

43

企业应用软件测试实训课程

测试的生命周期必须与迭代方法结合起来，这意味着每个迭代都将具有遵循该模式的测试周期。 执行测试既是新测试的执行，又是使用先前测试的回归测试。

测试的生命周期是软件生命周期的一部分；它们应该同时开始。测试的设计开发过程与正在构建的应用程序一样复杂和艰巨。如果未能尽早开始，测试或者不够完善，或者会导致需要在开发时间表上附加一个长时间的测试和错误修正时间表，这将有违迭代开发的初衷。此外，测试计划和设计活动可以揭示应用程序定义中的故障和缺陷。这些问题越早得以解决，对整个时间表造成的影响就越小。评价过程中发现的问题可以在本次迭代解决，也可以留待下次迭代解决。通过核实已经实施的需求来评测迭代的完全

44

企业应用软件测试实训课程

程度，是评价的主要任务之一。迭代之间始终存在着某种“需求蠕变”，您需要意识到其存在并能够对其加以管理。

四、测试工程师的实际工作流程

测试工程师的工作流程，与公司的整体工作流程，项目的测试要求等因素相关。本文主要讨论测试工程师的一般工作流程。 一、做好测试准备 1)明确测试任务的范围

测试文档通常包括测试目的、测试环境、测试方法、测试用例、测试工具等。测试工程师首先要通读文档，对整个测试要求形成整体认识，明确测试目的，以及测试要求和测试重点，明确软件测试方法和使用的测试工具。 2)明确测试时间

明确测试周期和测试时间进度。如果是多人合作完成一个软件，则要首先明确属于自己的测试内容、根据测试内容和测试周期，估算自己每日应该完成的工作量。此外由于软件测试是群体协作的测试活动，需要明确哪些测试内容要与其他测试工程师协作才能完成。 3)设置测试环境

根据测试文档要求，设置测试需要的软件和硬件环境，包括操作系统，要测试的软件和其他必要的测试工具软件等。所有这些完成后，分别运行，查看是否能正确运行，保证符合测试文档要求的测试环境。 4)学习被测试软件

对于不太熟悉的软件，可以通过阅读软件自身的教程和帮助文件，学习本软件的一般操作方法，也可以参照相关的书籍资料等。另外，向熟悉测试软件的其他同事请教软件使用方法，也是学习软件的一条捷径。对软件使用越熟练，测试过程越顺利，测试效果越理想。 5)确认完全理解测试任务

软件测试最重要的要求就是确实明确了测试任务和要求，这包括正确理解了测试文档，确认可以按照测试进度要求，完成测试。对于测试工具要正确安装，熟练使用。如果有任何不明白之处，向软件测试负责人询问。切忌凭自己的理解和主观推测，自行其事。当然，真正测试中，往往会遇到各种新的小疑难问题，也需要及时向测试负责人请教，以保证测试顺利进行。 二、执行软件测试任务

1)按照测试文档要求，逐项认真测试

根据测试文档测试要求，按照测试步骤，逐项进行。通过运行软件，观察测试结果，与软件需求说明书的内容进行比较，找出软件错误。对于需要调用测试用例的测试，保证正确地调用了测试用例，注意观察和分析测试结果。某些不容易重复的错误，需要反复测试，总结重复该错误所需要的测试步骤，直到

45

企业应用软件测试实训课程

确认可以重复出现为止。

2)记录发现的错误，填写软件问题报告

为了纠正软件中的错误，测试工程师要正确记录发现的错误，将错误再现的步骤写入测试报告中，测试报告是程序测试的重要组成部分，正确书写测试报告是对测试工程师的基本要求。采用软件缺陷数据库管理测试中发现的软件缺陷，每一条错误作为数据库的一条记录，方便记录、修改、查询。 3)填写测试进度表和必要的测试内容记录表

每天将测试内容写入测试进度表文档，可以使测试负责人了解测试进度，控制测试周期内测试的连续性，增强测试过程控制性，保证测试的正常进行。测试记录要准确完整，实事求是，必要时插入测试注释，解释测试中的特殊问题。测试进度表是评价测试质量和工作内容的重要凭证，对于测试后发现的测试错误和失误，可以通过检查测试记录，寻找产生错误的原因。 4) 测试中发现疑难及时请教

测试是一个动态的过程，可能由于自己的错误操作或者测试文档内容的错误，使得测试过程中出现自己不能解释的现象或结果，出现与测试要求不符合的情形，这时可能需要与其他测试者协商或求助，如果问题仍然不能解决，应该及时请教，听取意见和建议，必要时反复讨论直到问题全面解决。 三、全面检查测试结果

1)对照测试文档要求，检查测试内容是否完整

测试完成后，要对照测试文档检查测试是否全部完成，保证没有丢失测试内容。如果某些内容，由于测试环境的要求不满足，或者由于测试时间短没有进行，则要写入测试进度表文档。 2)检验书写的软件问题报告的记录，使之确切、规范

正确书写测试记录是保证迅速定位软件错误，加快改正错误的必要前提。专业规范的软件记录报告是体现公司测试水平和专业实力的外在体现。认真检查书写的每条记录是否符合规范，格式、步骤、内容一一检查，必要时补充或删减。

上述三个阶段，相互联系紧密，其中准备是基础，测试是重点，检查是保证，应该根据测试的软件特点合理安排。

五、项目中的测试工作内容（附加）

从软件的生存周期看，测试往往指对程序的测试，这样做的优点是被测对象明确，测试的可操作性相对较强。但是，由于测试的依据是规格说明书、 设计文档和使用说明书，如果设计有错误，测试的质量就难以保证。即使测试后发现是设计的错误，这时，修改的代价是相当昂贵的。因此，较理想的做法应该是对 软件的开发过程，按软件工程各阶段形成的结果，分别进行严格的审查。

为了确保软件的质量，对开发和测试的过程应进行严格的管理。虽然测试是在实现且经验证后进行的，实际上，测试的准备工作在分析和设计阶段就开始了。

46

企业应用软件测试实训课程

5.1测试的过程及组织

当设计工作完成以后，就应该着手测试的准备工作了，一般来讲，由一位对整个系统设计熟悉的设计人员编写测试大纲，明确测试的内容和测试通过的准则，设计完整合理的测试用例，以便系统实现后进行全面测试。

在实现组将所开发的程序经验证后，提交测试组，由测试负责人组织测试，测试一般可按下列方式组织： (1)首先，测试人员要仔细阅读有关资料，包括规格说明、设计文档、使用说明书及在设计过程中形成的测试大纲、测试内容及测试的通过准则，全面熟悉系统，编写测试计划，设计测试用例，作好测试前的准备工作。

(2)为了保证测试的质量，将测试过程分成几个阶段，即：代码审查、单元测试、集成测试和验收测试。 (3)代码会审：代码会审是由一组人通过阅读、讨论和争议对程序进行静态分析的过程。会审小组由组长，2～3名程序设计和测试人员及程序员组成。会 审小组在充分阅读待审程序文本、控制流程图及有关要求、规范等文件基础上，召开代码会审会，程序员逐句讲解程序的逻辑，并展开热烈的讨论甚至争议，以揭示 错误的关键所在。实践表明，程序员在讲解过程中能发现许多自己原来没有发现的错误，而讨论和争议则进一步促使了问题的暴露。例如，对某个局部性小问题修改 方法的讨论，可能发现与之有牵连的甚至能涉及到模块的功说明、模块间接口和系统总结构的大问题，导致对需求定义的重定义、重设计验证，大大改善了软件的质 量。

(4)单元测试：单元测试集中在检查软件设计的最小单位—模块上，通过测试发现实现该模块的实际功能与定义该模块的功能说明不符合的情况，以及编码 的错误。由于模块规模小、功能单一、逻辑简单，测试人员有可能通过模块说明书和源程序，清楚地了解该模块的I/O条件和模块的逻辑结构，采用结构测试（白 盒法）的用例，尽可能达到彻底测试，然后辅之以功能测试（黑盒法）的用例，使之对任何合理和不合理的输入都能鉴别和响应。高可靠性的模块是组成可靠系统的 坚实基础。

(5)集成测试：集成测试是将模块按照设计要求组装起来同时进行测试，主要目标是发现与接口有关的问题。如数据穿过接口时可能丢失；一个模块与另一 个模块可能有由于疏忽的问题而造成有害影响；把子功能组合起来可能不产生预期的主功能；个别看起来是可以接受的误差可能积累到不能接受的程度；全程数据结 构可能有错误等。

(6)验收测试：验收测试的目的是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系 统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。 经过上述的测试过程对软件进行测试后，软件基本满足开发的要求，测试宣告结束，经验收后，将软件提交用户。 5.2 测试方法的应用

集成测试及其后的测试阶段，一般采用黑盒方法。其策略包括：

47

企业应用软件测试实训课程

(1)用边值分析法和（或）等价分类法提出基本的测试用例； (2)用猜测法补充新的测试用例；

(3)如果在程序的功能说明中含有输入条件的组合，宜在一开始就用因果图法，然后再按以上1、2两步进行。

单元测试的设计策略稍有不同。因为在为模块设计程序用例时，可以直接参考模块的源程序。所以单元测试的策略，总是把白盒法和黑盒法结合运用。具体做法有两种：

a、先仿照上述步骤用黑盒法提出一组基本的测试用例，然后用白盒法作验证。如果发现用黑盒法产生的测试用例未能满足所需的覆盖标准，就用白盒法增补 新的测试用例来满足它们。覆盖的标准应该根据模块的具体情况确定。对可靠性要求较高的模块，通常要满足条件组合覆盖或路径覆盖标准。 b、先用白盒法分析模块的逻辑结构，提出一批测试用例，然后根据模块的功能用黑盒法进行补充。 5.3 测试的人员组织

为了保证软件的开发质量，软件测试应贯穿于软件定义与开发的整个过程。因此，对分析、设计和实现等各阶段所得到的结果，包括需求规格说明、设计规格说明及源程序都应进行软件测试。基于此，测试人员的组织也应是分阶段的。

(1)软件的设计和实现都是基于需求分析规格说明进行的。需求分析规格说明是否完整、正确、清晰是软件开发成败的关键。为了保证需求定义的质量，应对其进行严格的审查。审查小组由下列人员组成： 组长：1人

成员：包括系统分析员，软件开发管理者，软件设计、开发和测试人员和用户

(2)设计评审：软件设计是将软件需求转换成软件表示的过程。主要描绘出系统结构、详细的处理过程和数据库模式。按照需求的规格说明对系统结构的合理性、处理过程的正确性进行评价，同时利用关系数据库的规范化理论对数据库模式进行审查。评审小组由下列人员组成： 组长：1人

成员：包括系统分析员、软件设计人员、测试负责人员各一人。

(3)程序的测试：软件测试。是整个软件开发过程中交付用户使用前的最后阶段，是软件质量保证的关键。软件测试在软件生存周期中横跨两个阶段：通常 在编写出每一个模块之后，就对它进行必要的测试（称为单元测试）。编码与单元测试属于软件生存周期中的同一阶段。该阶段的测试工作，由编程组内部人员进行 交叉测试（避免编程人员测试自己的程序）。这一阶段结束后，进入软件生存周期的测试阶段，对软件系统进行各种综合测试。测试工作由专门的测试组完成，测试 组设组长一名，负责整个测试的计划、组织工作。测试组的其他成员由具有一定的分析、设计和编程经验的专业人员组成，人数根据具体情况可多可少，一般3～5 人为宜。 5.4 软件测试文件

软件测试文件描述要执行的软件测试及测试的结果。由于软件测试是一个很复杂的过程，同时也是设计

48

企业应用软件测试实训课程

软件开发其它一些阶段的工作，对于保证软件的质量和它的运 行有着重要意义，必须把对它们的要求、过程及测试结果以正式的文件形式写出。测试文件的编写是测试工作规范化的一个组成部分。 测试文件不只在测试 阶段才考虑，它在软件开发的需求分析阶段就开始着手，因为测试文件与用户有着密切的关系。在设计阶段的一些设计方案也应在测试文件中得到反映，以利于设计 的检验。测试文件对于测试阶段工作的指导与评价作用更是非常明显的。需要特别指出的是，在已开发的软件投入运行的维护阶段，常常还要进行再测试或回归测 试，这时仍须用到测试文件。

(1)测试文件的类型：根据测试文件所起的作用不同，通常把测试文件分成两类，即测试计划和测试分析报告。测试计划详细规定测试的要求，包括测试的 目的和内容、方法和步骤，以及测试的准则等。由于要测试的内容可能涉及到软件的需求和软件的设计，因此必须及早开始测试计划的编写工作。不应在着手测试 时，才开始考虑测试计划。通常，测试计划的编写从需求分析阶段开始，到软件设计阶段结束时完成。测试报告用来对测试结果的分析说明，经过测试后，证实了软 件具有的能力，以及它的缺陷和，并给出评价的结论性意见，这些意见即是对软件质量的评价，又是决定该软件能否交付用户使用的依据。由于要反映测试工作 的情况，自然要在测试阶段内编写。 (2)测试文件的使用：测试文件的重要性表现在以下几个方面：

a、验证需求的正确性：测试文件中规定了用以验证软件需求的测试条件，研究这些测试条件对弄清用户需求的意图是十分有益的。

b、检验测试资源：测试计划不仅要用文件的形式把测试过程规定下来，还应说明测试工作必不可少的资源，进而检验这些资源是否可以得到，即它的可用性如何。如果某个测试计划已经编写出来，但所需资源仍未落实，那就必须及早解决。

c、明确任务的风险：有了测试计划，就可以弄清楚测试可以做什么，不能做什么。了解测试任务的风险有助于对潜伏的可能出现的问题事先作好思想上和物质上的准备。

d、生成测试用例：测试用例的好坏决定着测试工作的效率，选择合适的测试用例是作好测试工作的关键。在测试文件编制过程中，按规定的要求精心设计测试用例有重要的意义。

e、评价测试结果：测试文件包括测试用例，即若干测试数据及对应的预期测试结果。完成测试后，将测试结果与预期的结果进行比较，便可对已进行的测试提出评价意见。

f、再测试：测试文件规定的和说明的内容对维护阶段由于各种原因的需求进行再测试时，是非常有用的。

g、决定测试的有效性：完成测试后，把测试结果写入文件，这对分析测试的有效性，甚至整个软件的可用性提供了依据。同时还可以证实有关方面的结论。 (3)测试文件的编制

在软件的需求分析阶段，就开始测试文件的编制工作，各种测试文件的编写应按一定的格式进行。

49

企业应用软件测试实训课程

第六章 软件测试流程详述

本章详细介绍测试计划、测试用例、测试执行、测试总结的全部内容。 明确测试人员在工作中的角色和职责。 我们首先来看一下测试人员的纵向结构 1、测试经理

测试经理主要负责测试队伍的内部管理以及与其他外部人员，客户的交流，详细说来主要包括进度管理，风险管理，资金管理，人力资源管理，交流管理等等，测试经理需要具有项目经理的知识和技能。同时测试工作开始前项目经理需要书写《测试计划书》，测试结束需要书写《测试总结报告》。 2、测试文档审核师

测试文档审核师主要负责前置测试，包括在需求期与设计期间产生的文档进行审核，比如《业务建模书》，《需求规格说明书》，《概要设计书》，《详细设计书》等等。审核需要进行书写审核报告。当文档确定后，需要整理文档报告，并且反映介绍给测试设计师。 3、测试设计师

测试设计师主要根据需求期与设计期间产生的文档设计各个测试阶段的测试用例。（往往测试文档审核师，测试设计师可以有相同的一组人来完成） 4、测试工程师

测试工程师按照测试用例，来完成测试工作。 测试人员的横向组成，让我们再来讨论讨论： 1， 需要具有一定开发经验的计算机专业人员

由 于具有一定开发经验的计算机专业人员即懂得计算机的基本理论，又有一定的开发经验。所以对于软件中哪里容易出错，哪里不容易出错他们了如指掌；他们可以分析程序的性能，软件性能差是否是占有内存空间太多，或者是占有CPU时间太多引起的，还是其他原因，他们往往是专家。尤其是进行非功能测试的时候，他们可 以更好的搭建系统测试平台。这种人员应该占测试队伍中一半以上。 2， 需要具有本软件业务经验的人员

测试队伍中需要有这样的人员的目的在 于，这些人员由于对业务非常熟悉，软件质量的前提又是满足用户的需求。专业业务知识是计算机专业人员达不到的，所以这方面人才可以利用它们的业务知识和专 业水平，参与系统需求期间的文档审核，可以发现软件中存在的业务性错误。比如专业用语不准确，业务流程不规范等等，这种人才对于专业性比较强的软件测试工 作尤为重要，比如税务，法律，艺术。。 3， 只需要会操作计算机的人员

由于软件一旦卖出去之后，使用软件的人各种各样，各种各样的人带来各种各样的操作情况，请一大部

50

企业应用软件测试实训课程

分人员在软件测试工作后期进行测试工作是十分重要的，他们往往会发现专业测试人员测试不出的东西和一些希奇古怪的错误。这就是软件测试学中所谓的猴子测试法。

对于一个软件公司来说，并不是说所有的测试队伍都需要这三种人员，实际中可以一组人代替多个角色，但是要遵循以下原则：

1)对于业务不是很专业的软件，具有一定开发经验的计算机专业人员与具有本软件业务经验的人员可以合并；

2)只需要会操作计算机的人员，可以由公司行政人员来充当。 • 测试设计员

􀁹 制定和维护测试计划。 􀁹 设计测试用例及测试过程。 􀁹 评估测试，生成测试分析报告。 • 测试开发员

􀁹 设计测试需要的驱动程序和稳定桩。 • 测试编码员

􀁹 编写测试驱动程序和稳定桩。 􀁹 执行单元测试。 • 测试执行员

􀁹 执行集成测试和系统测试。 􀁹 记录测试结果。 一、复习巩固

1、测试阶段是如何划分的？ 2、测试人员的工作流程简述。 二、测试计划（Test Plan）

定义测试项目的阶段，以便于对项目进行适当的评估与控制。测试计划的依据主要是项目开发计划和测试需求分析结果而制定。测试计划（Test Plan）一般由测试负责人来编写。测试计划应该包括测试用例和条件，测试环境，与任务相关的测试，通过/失败的准则和测试风险评估。测试进度表将识别所有要求有成功的测试成果的任务，活动的进度和资源要求。确定测试计划需要注意以下事项： 1、目的

• 收集和组织测试计划信息，并且创建测试计划。

51

企业应用软件测试实训课程

2、测试计划的时机 • 软件项目计划已确定。 3、输入工件 • 软件项目计划 • 软件需求工件 • （软件构架设计） • （软件详细设计） • （软件集成计划） 4、制定测试计划的步骤 • 确定测试需求 • 制定测试策略 • 建立测试通过准则 • 确定资源和进度 • 评审测试计划 • 更新测试计划 5、输出工件 • 软件测试计划

测试计划内容具体应包含以下一些方面： 2. 1．测试背景 a. 软件项目介绍；

b. 项目涉及人员（如软硬件项目负责人等）介绍以及相应联系方式等。 2. 2．测试依据 a. 软件需求文档； b. 软件规格书； c. 软件设计文档； d. 其他，如参考产品等。 2. 3．测试资源

52

企业应用软件测试实训课程

a. 测试设备需求； b. 测试人员需求； c. 测试环境需求； d. 其他。 2. 4．测试策略

测试策略是关于如何测试系统的正式描述，要求开发针对所有测试级别的测试策略。测试小组分析需求，编写测试策略并且和项目小组一起复审计划。 a. 采取测试方法； b. 搭建哪些测试环境；

c. 采取哪些测试工具以及测试管理工具； d. 对测试人员进行培训等。 2. 5．测试日程 a. 测试需求分析； b. 测试用例编写；

c. 测试实施，根据项目计划，测试分成哪些测试阶段（如单元测试、集成测试、系统测试阶段，α、β测试阶段等），每个阶段的工作重点以及投入资源等。 2. 6．风险和问题 可能的影响和风险： 市场的压力；

测试时间不够，主要是功能冻结后的系统测试的时间可能不够； 测试资源的及时到位（设备和人员）； 测试人员的培训；

开发进度的变化，需求或设计的变更； 开发组的版本控制。 可能的不利因素： 没有得到足够的培训 心里准备不足 缺乏测试工具

53

企业应用软件测试实训课程

缺乏管理的标准和支持 缺乏客户和最终使用者的参与 对于的测试人员过度信任 版本改变的太快

测试人员处于不受重视的情况中 2. 7．其他。

测试计划还要包括测试计划编写的日期、作者等信息，计划越详细越好了。

计划赶不上变化，一份计划做的再好，当实际实施的时候就会发现往往很难按照原有计划开展。如在软件开发过程中资源匮乏、人员流动等都会对测试造成一定的影响。所以，这些就要求测试负责人能够从宏观上来了。 三、测试设计

测试设计主要包括测试用例编写和测试场景设计两方面。一份好的测试用例对测试有很好的指导作用，能够发现很多软件问题。 具体过程：

通过复审发布版本的功能需求和准备能够更好的拆分为测试脚本的业务功能逻辑集合，准备测试场景和用例。测试将定义为测试条件，用于测试的数据和期望的结果（数据库更新，文件输出，报告结果等等）。将可能在应用程序中出现的既普通又异常的情况描绘为测试场景。

项目开发人员将定义单元测试需求和单元测试的场景/用例。在集成和系统测试之前，开发人员同时也负责执行单元测试用例。

在开发人员和客户的协助下，测试小组将开发集成和系统测试的测试场景、用例。验收测试用例将由客户在项目和测试小组的帮助下设计。

通过使用测试脚本执行测试场景。脚本将定义用于执行一个和多个测试场景的一系列步骤。测试脚本通常描绘在一般的系统操作中会出现的事务或过程。测试脚本包括用于测试过程或事务的特定数据。测试脚本将覆盖多个测试场景并且包括运行/执行/周期信息。测试脚本映射需求和用于保证任何测试都是在范围内的追溯矩阵。

在测试之前，捕捉并且基线化测试数据。这些数据将作为单元和系统测试的基础和在可控的环境下执行系统功能。为了以后的对照，一些输出的数据也被基线化。在回归测试时，基线化的数据用于支持以后的系统维护。

为评定应用程序的就绪情况、环境和被测试的数据，应召开测试准备会议。为了指出发本版本的入口标准状态，应创建测试就绪文档。

54

企业应用软件测试实训课程

1、目的

• 为每一个测试需求确定测试用例集，并且确定执行测试用例的测试过程。 2、时机

• 软件需求规格被基线化 3、输入工件 • 软件测试计划 • 软件需求工件 • 软件构架设计 • 软件详细设计 • 界面原型（可选） 4、步骤 • 设计测试用例

对每一个测试需求，确定其需要的测试用例。 对每一个测试用例，确定其输入及预期结果。

确定测试用例的测试环境配置、需要的驱动界面或稳定桩。 编写测试用例文档。 对测试用例进行同行评审。 • 开发测试过程

根据界面原型为每一个测试用例定义详细的测试步骤。 为每一测试步骤定义详细的测试结果验证方法。 为测试用例准备输入数据。 编写测试过程文档。 对测试过程进行同行评审。 在实施测试时对测试过程进行更改。 • 设计驱动程序或稳定桩。

1）设计单元测试和集成测试需要的驱动程序和稳定桩。 5、输出工件

55

企业应用软件测试实训课程

• 测试用例 • 测试过程 3.1 测试用例概述 前言：

软件测试用例是为了有效发现软件缺陷而编写的包含测试目的、测试步骤、期望测试结果的特定集合。正确认识和设计软件测试用例可以提高软件测试的有效性，便于测试质量的度量，增强测试过程的可管理性。

在实际软件项目测试过程中，由于对软件测试用例的作用和设计方法的理解不同，测试人员（特别是刚从事软件测试的新人）对软件测试用例存在不少错误的认识，给实际软件测试带来了负面影响，本文对这些认识误区进行列举和剖析。

误区之一：测试输入数据设计方法等同于测试用例设计方法

现在一些测试书籍和文章中讲到软件测试用例的设计方法，经常有这样的表述：测试用例的设计方法包括：等价类、边界值、因果图、错误推测法、场景设计法等。这种表述是很片面的，这些方法只是软件功能测试用例设计中如何确定测试输入数据的方法，而不是测试用例设计的全部内容。

这种认识的不良影响可能会使不少人认为测试用例设计就是如何确定测试的输入数据，从而掩盖了测试用例设计内容的丰富性和技术的复杂性。

无疑，对于软件功能测试和性能测试，确定测试的输入数据很重要，它决定了测试的有效性和测试的效率。但是，测试用例中输入数据的确定方法只是测试用例设计方法的一个子集，除了确定测试输入数据之外，测试用例的设计还包括如何根据测试需求、设计规格说明等文档确定测试用例的设计策略、设计用例的表示方法和组织管理形式等问题。

在设计测试用例时，需要综合考虑被测软件的功能、特性、组成元素、开发阶段（里程碑）、测试用例组织方法（是否采用测试用例的数据库管理）等内容。具体到设计每个测试用例而言，可以根据被测模块的最小目标，确定测试用例的测试目标；根据用户使用环境确定测试环境；根据被测软件的复杂程度和测试用例执行人员的技能确定测试用例的步骤；根据软件需求文档和设计规格说明确定期望的测试用例执行结果。

误区之二：强调测试用例设计得越详细越好

在确定测试用例设计目标时，一些项目管理人员强调测试用例“越详细越好”。具体表现在两个方面：尽可能设计足够多的设计用例，测试用例的数量阅读越好；测试用例尽可能包括测试执行的详细步骤，达到“任何一个人都可以根据测试用例执行测试”，追求测试用例越详细越好。

这种做法和观点最大的危害就是耗费了很多的测试用例设计时间和资源，可能等到测试用例设计、评审完成后，留给实际执行测试的时间所剩无几了。因为当前软件公司的项目团队在规划测试阶段，分配给测试的时间和人力资源是有限的，而软件项目的成功要坚持“质量、时间、成本”的最佳平衡，没有足

56

企业应用软件测试实训课程

够多的测试执行时间，就无法发现更多的软件缺陷，测试质量更无从谈起了。

编写测试用例的根本目的是有效地找出软件可能存在的缺陷，为了达到这个目的，需要分析被测试软件的特征，运用有效的测试用例设计方法，尽量使用较少的测试用例，同时满足合理的测试需求覆盖，从而达到“少花时间多办事”的效果。

测试用例中的测试步骤需要详细到什么程度，主要取决于测试用例的“最终用户”（即执行这些测试用例的人员），以及测试用例执行人员的技能和产品熟悉程度。如果编写测试用例的人员也是测试用例执行人员，或者测试用例的执行人员深刻了解被测软件，测试用例就没有必要太详细。而如果是测试新人执行测试用例，或者软件测试外包给的第三方公司，那么测试用例的执行步骤最好足够详细。 误区之三：追求测试用例设计“一步到位”

现在软件公司都意识到了测试用例设计的重要性了，但是一些人认为设计测试用例是一次性投入，测试用例设计一次就“万事大吉”了，片面追求测试设计的“一步到位”。

这种认识造成的危害性使设计出的测试用例缺乏实用性，或者误导测试用例执行人员，误报很多不是软件缺陷的“Bug”，这样的测试用例在测试执行过程中“形同虚设”，难免沦为“垃圾文档”的地步。 “唯一不变的是变化”。任何软件项目的开发过程都处于不断变化过程中，用户可能对软件的功能提出新需求，设计规格说明相应地更新，软件代码不断细化。设计软件测试用例与软件开发设计并行进行，必须根据软件设计的变化，对软件测试用例进行内容的调整，数量的增减，增加一些针对软件新增功能的测试用例，删除一些不再适用的测试用例，修改那些模块代码更新了的测试用例。

软件测试用例设计只是测试用例管理的一个过程，除此之外，还要对其进行评审、更新、维护，以便提高测试用例的“新鲜度”，保证“可用性”。因此，软件测试用例也要坚持“与时俱进”的原则。 误区之四：让测试新人设计测试用例

在与测试同行交流的过程中，不少刚参加测试工作的测试新人经常询问的一个问题是：“怎么才能设计好测试用例？”。因为他（她）们以前从来没有设计过测试用例，面对大型的被测试软件感到“老虎吃天，无从下口”。

让测试新人设计测试用例是一种高风险的测试组织方式，它带来的不利后果是设计出的测试用例对软件功能和特性的测试覆盖性不高，编写效率低，审查和修改时间长，可重用性差。

软件测试用例设计是软件测试的中高级技能，不是每个人（尤其是测试新人）都可以编写的，测试用例编写者不仅要掌握软件测试的技术和流程，而且要对被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构都有比较透彻的理解。

因此，实际测试过程中，通常安排经验丰富的测试人员进行测试用例设计，测试新人可以从执行测试用例开始，随着项目进度的不断进展，测试人员的测试技术和对被测软件的不断熟悉，可以积累测试用例的设计经验，编写测试用例。

本章针对上面的问题，主要讲解在企业实际工作中，如何有效划分测试种类和编写对应的测试用例，使

57

企业应用软件测试实训课程

测试工作更加合理、高效率的运行。

本章主要以测试用例的编写和管理为核心，讲述下面内容： 􀁹用例的分类 􀁹用例程度的把握 􀁹用例的执行 􀁹用例的评审

􀁹用例的升级、管理、维护

事实上，完全可以把测试用例看成是测试工程师编写的程序：这个“程序”是为了辅助测试工作的进行而进行，目的是为了发现软件问题，同时“顺便”证明软件功能是否符合要求。 测试用例设计步骤

1、 为测试需求确定测试用例

1）测试需求：来源于需求规格说明书（用例、补充规约），设计规格。在测试计划中明确。 2）测试需求编号：TR_XXXX_XX

3）每一个测试需求至少确定两个测试用例：正面，负面。 2、 为测试用例确定输入输出

1）输入是指在执行该测试用例时，由用户输入的与之交互的对象、字段和特定数据值（或生成的对象状态）。

2）输出即预期结果，是指执行该测试用例完毕后得到的状态或数据。 3）在确定输入和输出参数时，我们采用以下原则：

• 在任何情况下都必须使用边界值分析方法。经验表明用这种方法设计出测试用例发现程序错误的能力最强。

• 必要时用等价类划分方法补充一些测试用例。

• 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，应当再补充足够的测试用例。

• 如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法。 3、编写测试用例

1）测试用例编号为：TC_测试需求标识。 2）测试需求标识：测试计划中的测试需求标识。

58

企业应用软件测试实训课程

3）测试目标状态和测试数据状态：执行此用例前系统应具备的状态。 4）输入(操作)：为各输入数据（操作）的组合。 5）输出(预期结果)：测试用例执行后得到的状态或数据。 4、评审测试用例 1）测试用例检查表

• 是否每一个需求都有其对应的测试用例来验证？ • 是否每一个设计元素都有其对应的测试用例来验证？ • 或事件顺序，它能够产生唯一的测试目标行为？ • 是否每个测试用例都阐述了预期结果？

• 是否每个测试用例（或每组相关的测试用例）都确定了初始的测试目标状态和测试数据状态？ • 测试用例是否包含了所有的单一边界？ • 测试用例是否包含了所有的业务数据流？

• 是否所有的测试用例名称， ID 都与测试工件命名约定一致？ 2）参加人员

• 项目经理、系统分析员、测试设计员、测试员 5、跟踪测试用例

1）需求管理: 需求-〉测试用例 2）测试用例是否覆盖了需求 • 需求-〉测试需求-〉测试用例 3）测试用例执行率、通过率 • 测试用例-〉测试用例执行结果

3.1.1测试种类和阶段 1、测试种类

对于测试种类的说法多种多样，最多的能有30多种测试类型。而实际工作中很多测试是互相包含的。按照企业中实际工作需要，测试主要包含下面的类型：

功能测试：功能测试主要针对产品需求说明书的测试，主要是验证功能是否否合需求，包括原定功能的检验、是否有冗余功能、遗漏功能。这类测试应由测试员做，这并不意味着程序员在发布前不必检查他

59

企业应用软件测试实训课程

们的代码能否工作(自然他能用于测试的各个阶段)。

健壮性测试（容错能力/恢复能力测试）：侧重于程序容错能力的测试。本测试在单元测试阶段和系统测试阶段都要进行。为了执行方便，建议健壮性的大部分测试用例尽量编写在功能测试用例中。 接口测试：程序员对各个模块进行系统联调的测试，包含程序内接口和程序外接口测试。这个测试，在单元测试阶段进行了一部分工作，而大部分都是在集成测试阶段完成的。由开发人员进行。

强度测试 强度测试检查程序对异常情况的抵抗能力。强度测试总是迫使系统在异常的资源配置下运行。 压力测试：对系统不断施加压力的测试，是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。压力测试注重的是外界不断施压，强度测试注重的是极限或者异常情况下系统的测试。

性能测试：在交替进行负荷和强迫测试时常用的术语。性能测试关注的是系统的整体。它和通常所说的强度、压力/负载测试测试有密切关系。所以压力和强度测试应该于性能测试一同进行。

用户界面测试：对系统的界面进行测试，测试用户界面是否友好、是否方便易用、设计是否合理、位置是否正确等一系列界面问题

安全测试：主要是测试系统在没有授权的内部或者外部用户对系统进行攻击或者恶意破坏时如何进行处理，是否仍能保证数据的安全。测试人员可以学习一些黑客技术，来对系统进行攻击。

可靠性测试：这里是比较狭义的可靠性测试，它主要是对系统能否稳定运行进行一个统计，在实际工作中如果没有条件可以不必特意去做。重点做好与之紧密相关的功能测试、健壮性测试就可以了。 安装/反安装测试：安装测试主要检验软件是否可以正确安装，安装文件的各项设置是否有效，安装后能否影响原系统；反安装是逆过程，测试是否删除干净，是否给影响原系统等。

文档测试：主要测试开发过程中针对用户的文档，以需求、用户手册、安装手册等为主，检验文档是否和实际应用存在差别。文档测试不需要编写测试用例。 3.1.2 测试阶段

和开发过程相对应，测试主要按照时间顺序经历单元测试、集成测试、系统测试、验收测试四个阶段。 3.1.3 测试种类、阶段和用例关系

在合适的阶段编写不同的测试用例和执行测试才可以提高效率。为了便于在实际工作中提高效率，同时方便测试用例的编写和执行，可以把上面的提到的测试类型对应的测试用例进行合并。测试用例主要有如下几种：

1、功能测试用例：包含功能测试、健壮性测试、可靠性测试， 2、性能测试用例：包含性能测试、压力测试、强度测试 3、集成测试用例：包含接口测试、健壮性测试、可靠性测试

60

企业应用软件测试实训课程

4、安全测试用例：安全测试用例

5、用户界面测试用例：用户界面测试用例、少量功能测试用例。 6、安装/反安装测试用例：安装/反安装测试用例 测试种类、阶段和用例关系具体的关系如下表所示。 测试阶段 单元测试 集成测试 测试类型 执行人员 模块功能测试，包含部分接口测试、路径测试 开发人员 接口测试、路径测试，含部分功能测试 开发人员，如果测试人员水平较高可以由测试人员执行 系统测试 功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试 测试人员 验收测试 对于实际项目基本同上，并包含文档测试；对于软件产品主要测试相 测试人员，可能包含用户 3.2 用例的编写

测试工作和开发通常一同进行，所以在完成测试计划编写后，就可以进行用例的编写工作。测试工程师根据需求规约、概要设计、详细设计等文档编写测试用例。测试和开发的对应关系如下表： 开发阶段 需求分析结束后 概要设计阶段结束后 详细设计阶段 依据文档 需求文档 概要设计、体系设计 详细设计文档 编写的用例 系统测试对应的用例 集成测试对应的用例 单元测试对应的用例 上面的单元测试在大多数企业工作中，由程序员在开发过程中进行，基本不编写测试用例，因此重点论述集成测试用例的编写。下面按照编写的顺序说明各个测试用例的编写思路和方法。 各个用例的编写参考在文档编写中具体讲解。

对于用例，一个基本的思想就是：“一点多例”，就是针对一个测试点或者功能点，编写多个测试用例，从多个方面进行测试。各个部分的用例编写的都贯穿着这一基本思想。 3.3 用例的设计

1. 参考用户界面设计测试用例

我们在设计测试用例时，一般都是参考UI和需求说明（或其他已知的与程序相关的资料）。由

61

企业应用软件测试实训课程

于编写的是黑盒测试用例，所以对图形用户界面的依赖性很大。因此，在设计测试用例的时候，界面上的所有元素都是测试设计需要考虑的内容。 主要步骤：

列出（每个）界面上所有的元素（你所看到的）；是否有当前界面之外的元素，如果有，需要什么运行条件才显示出来？

标识每个元素的约束（可能需要不断与开发人员沟通） 确认各个元素之间是否存在约束，如果有，列出来

是否要按一定顺序操作？列出所有正常的操作，列出所有反常的操作 测试各种元素的组合

注：此种方法在测试单个功能特性的时候特别有效 2. 参考用例（UseCase）设计测试用例（TestCase）

对于一些用例需求文档编写比较规范的项目，可以依据用例来设计测试用例。 要点：

1）按照Use Case画一个流程图 2）确定所有可能的路径 3）分析、归类发现的路径 4）决定需要测试的路径

5）为每一个选定的路径设计测试用例 说明：每一个“节点”对应用户的一个动作。 应特别注意：应用这种方法设计测试用例的风险—— 用例本身可能是不完整或错误的，例如没有列出所有的备选流 用例编写不规范，例如混淆了用户行为和系统边界

用例中的『前置条件』『后置条件』并不一定能作为测试用例中的『前置条件』『后置条件』 因此，在应用此方法时，应确保所依据的用例是完整的、正确的、良好的。 注：此种方法在设计系统测试用例的时候特别有效. 3. 根据“故障模型”设计测试用例

软件在哪里容易发生故障或失效？一般在4个地方：输入、输出、数据计算以及文件系统接口。

62

企业应用软件测试实训课程

针对输入的测试用例设计（黑盒测试）

有效输入和无效输入的集合、输入的边界、之间有相互约束的输入、多次重复同样的输入或输入序列。针对以上情况设计测试用例。 针对输出的测试用例设计（黑盒测试）

每个输入都有对应的（不同）输出、有效输出和无效输出、改变输出的属性、采用某种手段强制屏幕刷新。针对以上情况设计测试用例。 注：结合输出和输入很容易发现设计不一致的缺陷。 针对数据计算的测试用例设计（灰盒测试） 这个可能需要了解设计上的细节。考虑的要点是： 不同初始条件下应用输入，内部数据与某些输入可能不相容 强制数据结构存储过多（上溢）或过少（下溢）的数据 使用无效操作数和运算符进行计算－程序会不能运算或运算错误 针对文件系统接口的测试用例设计（黑盒＋灰盒测试） 包含2种情况：

A）针对存储文件的介质（主要指磁盘）的测试 介质空间问题、介质不可用（包括损坏、忙和不存在）。 针对以上情况设计测试用例。 B）针对存储文件的测试

无效的文件名/文件格式、使文件不可访问、更改或破坏文件内容、在程序向文件内写入内容时强行中断写入。

注：此种方法在设计随机测试用例的时候特别有效（随机测试RandomTesting不一定要写成文档形式） 4、总之：

软件出错的根本原因： 无错误处理 错误处理不当或错误 缺少验证 验证的方法不正确

63

企业应用软件测试实训课程

逻辑错误（这个最难测试，必须依赖详细的设计）

根据上面的“BUG思想”，在测试时可以发现大多数的软件问题。 3.4 用例管理

您完全可以把测试用例看成程序——测试工程师编写的程序，这个程序也要经过“设计”、“开发”、“测试”、“版本管理”、“发布”、“维护”等一系列操作。

版本管理是用例管理的核心部分，建议采用工具（例如Visual SourceSafe）对用例进行控制。 3.5 用例评审

测试用例应该由产品相关的软件测试人员和软件开发人员评审，提交评审意见，然后根据评审意见更新测试用例。如果认真操作这个环节，测试用例中的很多问题都会暴露出来，比如用例设计错误、用例设计遗漏、用例设计冗余、用例设计不充分等等；如果同行评审不充分，那么，在测试执行的过程中，上述本应在评审阶段发现的测试用例相关问题，会给测试执行带来大麻烦，甚至导致测试执行挂起。

用例评审在比较正规的公司更容易实施，同时您的软件开发团队必须在实际工作中对测试给予足够的重视，才可以把这项工作做好，否则只是走走形式。原则上用例象程序一样，要经过多次的修改才可以通过，实际工作中通常进行一次。

用例修改：评审结束后，您需要根据评审意见进行修改，修改后通常不再进行评审。建议如果您的在时间和人力资源比较充裕的情况下对用例的评审要象您测试开发部门的产品一样，要经过反复的评审和修改，然后正式投入使用，因为每次评审您可能都有新的发现。 有效的用例评审通常由下面两种形式组成：

测试部门外部评审——主要是由开发部、项目实施部、甚至销售人员参加的评审，目的主要是查找测试工程师编写的用例是否缺少内容。建议采用非正式评审的形式进行，因为您很难把开发人员组织在一起，通常他们开发进度通常很大，他们能够抽出时间看您的文档已经是“很给面子了”。当然不统一进行会耽误评审的进度，所以在实际工作中如果时间紧迫可以提前启动测试，待评审完成后进行用例的修改工作。通常测试工作进行一段时间评审就会结束，这个时候测试执行人员可以在工作中对测试用例的内容进行动态的调整，再次执行已经执行过的并且进行修改的部分用例。（如果能够采用正式评审效果肯定更好。）

测试部门内部评审——部门内部同行对测试策略的评审，中心是测试策略和用例编制思路是否正确，以次来保证测试用例的有效性。可以组织正式的评审，由用例的设计人员进行讲解，然后大家共同评审；也可以把文档发给部门的同事进行评审。内部评审有些象开发人员在单元测试中交叉测试。

其中的外部评审最重要，因为开发人员很容易发现您的用例遗漏了什么内容没有编制进去，同

企业应用软件测试实训课程

时还可以发现错误的用例——因为您可能对需求理解存在偏差。用例外部评审可以理解为开发人员在查找您的“程序”的缺陷。

通常情况下先执行内部评审，然后执行外部评审。很多时候，内部评审会被忽略，建议要进行内部评审。这样至少有两个好处：集思广益和提高测试小组输出文档的质量。 3.6 用例使用

在测试用例执行过程中，你会发现每个测试用例都对测试环境有特殊的要求，或者对测试环境有特殊的影响。因此，定义测试用例的执行顺序，对测试的执行效率影响非常大。比如某些异常测试用例会导致服务器频繁重新启动，服务器的每次重新启动都会消耗大量的时间，导致这部分测试用例执行也消耗很多的时间。那么在编排测试用例执行顺序的时候，应该考虑把这部分测试用例放在最后执行，如果在测试进度很紧张的情况下，如果优先执行这部分消耗时间的异常测试用例，那么在测试执行时间过了大半的时候，测试用例执行的进度依然是缓慢的，这会影响到测试人员的心情，进而导致匆忙地测试后面的测试用例，这样测试用例的漏测、误测就不可避免，严重影响了软件测试效果和进度。因而，合理地定义测试用例的执行顺序是很有必要的。

在执行任务时版本控制库取出用例，执行用例时建议您直接在用例上记录测试的结果，这样做给您带来两个好处：首先是下次测试时可以看见上次测试结果，可以起一个提醒的作用，其次您可以统一把发现的缺席输入到数据中，在输入时您可以进行分析，同时避免输入重复的缺陷。每次使用后送入版本控制库，进行版本的管理。 3.7 用例升级/维护

随着软件产品不断修改、升级，对应的用例也需要升级维护。针对同一个项目，可以根据需求的变更不断进行维护；如果是产品，用例的维护更加重要，要达到用例和产品的版本一一对应。

65

企业应用软件测试实训课程

注：一个关于界面UI测试用例资料。

常书写Test Case时需要考虑的检查点: 对于屏幕显示来说包括： 检查显示的布局； 检查域和按钮的顺序； 检查域的尺寸； 检查字体的大小和风格； 检查文本的含义； 检查拼写错误； 检查屏蔽域； 检查只读域； 检查图片； 检查按钮的状态； 检查按钮的尺寸； 检查按钮的图标和名字； 检查是否有重复的图标； 检查指针是否在第一个可输入域； 检查TAB键的次序； 对于域来说包括： 检查可编辑性； 检查域间的移动； 检查分界条件； 检查有效分界符； 检查无效分界符； 检查连续多个有效分界符； 检查仅一个分界符输入； 检查多余空格的截取； 检查只读域和屏蔽域在TAB时的状态； 66

企业应用软件测试实训课程

对于数字域来说包括： 检查正数值； 检查负数值； 检查零值； 检查小数点； 检查特殊字符加数字； 检查字母加数字； 检查ASCII值； 检查重复值； 检查空值； 对于字符域来说包括： 检查仅有字母； 检查仅有数字； 检查字母数字； 检查允许的特殊字符； 检查禁止的特殊字符； 检查包含特殊字符的字母数字； 检查ASCII值； 对于字母域来说包括： 检查字母； 检查数字值； 检查字母数字值； 检查特殊字符； 检查ASCII值； 对于时间域来说包括： 检查字符?和/； 检查其他特殊字符； 67

企业应用软件测试实训课程

检查字母数字值； 检查正确的格式； 检查错误的格式； 检查错误的日期数字； 检查正确的日期数字； 检查日历表； 对于错误信息和警告信息来说： 检查错误信息和警告信息的含义； 检查错误信息和警告信息的一致性； 检查确定位置的错误信息； 检查错误信息后的光标位置； 检查所有异常对应的错误信息； 检查错误信息的格式； 对于普通的检查来说： 检查文本域和字符域输入是否左对齐； 检查数字域输入是否右对齐； 检查标签的切换； 检查重复的名字； 检查可删除的表格； 检查表格的多选； 检查过滤器的逻辑性； 检查多个过滤器的逻辑性； 检查重复的序列号； 检查显示切换； 检查快捷键； 检查工具栏提示； 检查日期域是否居中； 检查选择项的高显； 68

企业应用软件测试实训课程

检查选择符； 检查显示窗口的风格统一性； 对于按键的功能包括： New button： 检查包含next和cancel按键的子窗口的显示； 检查子窗口显示的内容； Add button： 检查包含save和cancel按键的子窗口的显示； Edit button： 检查在未选择项目情况下点击后的警告信息； 检查包update和cancel按键的子窗口的显示； 检查选择的项目是否显示在制定的位置； Copy button： 检查在未选择项目情况下点击后的警告信息； 检查点击后的确认信息； 检查插入后的复制数据； Delete button： 检查在未选择项目情况下点击后的警告信息； 检查点击后的确认信息； 检查删除后的数据； Run button： 检测运行时的参数窗口； 检查执行结果； 检查未选择项目情况下点击后的警告信息； Back button： 检查是否回到上一屏幕； Next button： 检查是否显示下一屏幕； Finish button： 69

企业应用软件测试实训课程

检查数据是否进入数据库； 检查完成屏幕的显示； Cancel button： 检查确认信息； 检查是否有其他键执行同样功能； 检测是否能能够正确处理；

3.8 测试环境搭建

一般来说，软件产品提交测试后，开发人员应该提交一份产品安装指导书，在指导书中详细指明软件产品运行的软硬件环境，比如要求操作系统系统是 Windows 2000 pack4 版本，数据库是 SQL Server 2000 等等，此外，应该给出被测试软件产品的详细安装指导书，包括安装的操作步骤、相关配置文件的配置方法等等。对于复杂的软件产品，尤其是软件项目，如果没有安装指导书作为参考，在搭建测试环境过程中会遇到种种问题。

如果开发人员拒绝提供相关的安装指导书，搭建测试中遇到问题的时候，测试人员可以要求开发人员协助，这时候，一定要把开发人员解决问题的方法记录下来，避免同样的问题再次请教开发人员，这样会招致开发人员的反感，也降低了开发人员对测试人员的认可程度。

不同软件产品对测试环境有着不同的要求。如C/S及B/S架构相关的软件产品，那么对不同操作系统，如Windows系列、unix、linux甚至苹果OS等，这些测试环境都是必须的。而对于一些嵌入式软件，如手机软件，如果我们想测试一下有关功能模块的耗电情况，手机待机时间等，那么我们可能就需要搭建相应的电流测试环境了。当然测试中对于如手机网络等环境都有所要求。

测试环境很重要，符合要求的测试环境能够帮助我们准确的测出软件问题，并且做出正确的判断。 为了测试一款软件，我们可能根据不同的需求点要使用很多不同的测试环境。有些测试环境我们是可以搭建的，有些环境我们无法搭建或者搭建成本很高。不管如何，我们的目标是测试软件问题，保证软件质量。测试环境问题，还是根据具体产品以及开发者的实际情况而采取最经济的方式吧。 四、测试执行

测试过程是对给定测试用例（或测试用例集）的设置、执行和结果评估的详细说明的集合。 1、实施测试的目的

• 创建可重用的测试脚本，并且实施测试驱动程序和稳定桩。 2、实施测试的时机

• 软件单元已实施/工作版本已集成 3、输入工件 • 测试用例

70

企业应用软件测试实训课程

• 测试过程

• 软件单元或工作版本 4、实施测试的步骤

• 开发测试脚本（可选）—根据测试过程创建测试脚本，并且调试测试脚本。 • 编写驱动程序和稳定桩—根据设计编写测试需要的测试驱动程序和稳定桩。 5、输出工件 • 测试脚本（可选）

注：测试脚本是是自动执行测试过程（或部分测试过程）的计算机可读指令。

测试脚本可以被创建（录制）、或使用测试自动化工具自动生成、或用编程语言编程来完成，也可综合前三种方法来完成。 • 测试驱动程序和稳定桩 4.1. 测试执行阶段

从测试的角度而言，测试执行包括一个量和度的问题。也就是测试范围和测试程度的问题。 比如一个版本需要测试哪些方面？每个方面要测试到什么程度？

从管理的角度而言，在有限的时间内，在人员有限甚至短缺的情况下，要考虑如何分工，如何合理地利用资源来开展测试。当然还要考虑以下问题：

1． 当测试人员测试的执行不到位、敷衍了事时该如何解决？ 2． 测试效率问题，怎样提高测试效率？

3． 根据版本的不同特点是只做验证测试还是采取冒烟测试亦或是系统全面测试？ 4． 当测试过程中遇到一些偶然性随机问题该怎样处理？ 5． 当版本中出现很多新问题时该怎样对待？测试停止标准？ 6． ……

总之，测试执行过程中会遇到很多复杂的问题，还是那句话，具体问题具体解决！

测试设计准备完毕后就可以实施测试了。测试执行过程又可以分为以下阶段： 单元测试→集成测试→系统测试→验收测试，其中每个阶段还有回归测试等。 4.1.1 执行单元测试 1、目的

• 验证单元的内部结构以及单元实现的功能。 2、时机

71

企业应用软件测试实训课程

• 软件单元已实施 3、输入工件 • 测试过程 • 测试用例 • 软件单元 4、步骤

• 执行单元测试—按照测试过程手工执行单元测试或运行测试脚本自动执行单元测试。 • 记录单元测试结果—将单元测试结果作详细记录，并将测试结果提交给相关组。 • 回归测试—对修改后的单元执行回归测试 5、输出工件 • 测试结果 4.1.2 执行集成测试 1、目的

• 验证单元之间的接口以及集成工作版本的功能、性能等。 2、时机

• 软件工作版本已集成 3、输入工件 • 测试过程 • 测试用例 • 软件集成工作版本 4、步骤

• 执行集成测试—按照测试过程手工执行集成测试或运行测试脚本自动执行集成测试。 • 记录集成测试结果—将集成测试结果作详细记录，并将测试结果提交给相关组。 • 回归测试—对修改后的工作版本执行回归测试，或者对增量集成后的版本执行回归测试。 5、输出工件 • 测试结果 4.1.3 执行系统测试 1、目的

72

企业应用软件测试实训课程

• 确认软件系统满足软件需求。 2、时机

• 软件系统已集成 3、输入工件 • 测试过程 • 测试用例 4、步骤

• 执行系统测试—按照测试过程手工执行系统测试或运行测试脚本自动执行系统测试。 • 记录系统测试结果—将系统测试结果作详细记录，并将测试结果提交给相关组。 • 回归测试—对修改后的软件系统执行回归测试。 5、输出工件 • 测试结果 4.2. 测试执行依据

已批准的测试文档（测试计划、用例、程序）， 如果适用测试工具，自动化测试软件和编写好的脚本 设计的变更（变更请求） 测试数据

测试和项目组的可用性（项目人员，测试小组） 概要和详细设计文档（需求，软件设计）

通过配置/构建人员能够完全转移到测试环境（单元测试过的代码）的开发环境 测试就绪文档 修订文档； 4.3. 测试执行结果 代码的变更（测试修复项）

作为一种测试的结果（测试文档问题），测试文档没有说明的问题 设计时发现的问题，反馈给开发人员和客户（需求，设计，代码问题） 测试事故的正式记录（问题跟踪）

为向下一级别转移而准备的基线化包（已测试的源代码和对象代码）

73

企业应用软件测试实训课程

测试结果的日志和总结

已批准和带有修订测试交付项的签署文档（已更新的交付项） 4.4. 测试执行过程

在执行阶段中应召开Checkpoint 会议。(如果有需要，)每天应召开Checkpoint 会议处理和讨论测试中的问题，状态和活动。

通过采用系统的手段跟进测试文档来完成测试的执行。当执行测试程序的每一个包时，为了记录程序的执行和测试程序找出的任何缺陷，应该将问题记录到测试执行日志中。测试程序执行后的输出当作测试结果。

为了确定是否可以得到预期的结果，测试结果应该由适当的项目组员评估（，适合于测试的所有级别）。记录并和软件开发经理/程序员讨论所有差异/异常，为了以后的调查和解决应该将它文档化（每个客户可能有不同的记录日志和报告bug/defect的过程，通过Configuration Management (CM)小组校验这些过程）。通过/失败的准则用来确定问题的严重级别，结果记录到测试总结报告中。 根据客户的风险评估来定义在系统测试中发现的问题严重级别并记录到他们选择的跟踪工具中。 基于问题的严重级别有目的的修复并提交到测试环境中。被修改的问题应进行回归测试并将没有问题的修复项转移到新的基线中。在测试完成后，测试组的成员应准备一份总结报告。总结报告要由项目经理，客户，SQA和/或测试组长复审。

在证实达到一个指定的测试级别后，配置经理应根据配置管理计划中的要求整理发布的软件组件并转移到下一个测试级别。软件只有在客户正式验收之后才可以转移到生产环境中。

测试小组复审在测试和更新文档时发现的测试文档问题。一些问题可能是由于技术性和功能性之间不一致或修改所造成的。

在测试执行中需要注意以下几个问题：

1、全方位的观察测试用例执行结果：测试执行过程中，当测试的实际输出结果与测试用例中的预期输出结果一致的时候，是否可以认为测试用例执行成功了？答案是否定的，即便实际测试结果与测试的预期结果一致，也要查看软件产品的操作日志、系统运行日志和系统资源使用情况，来判断测试用例是否执行成功了。全方位观察软件产品的输出可以发现很多隐蔽的问题。

2、加强测试过程记录：测试执行过程中，一定要加强测试过程记录。如果测试执行步骤与测试用例中描述的有差异，一定要记录下来，作为日后更新测试用例的依据；如果软件产品提供了日志功能，比如有软件运行日志、用户操作日志，一定在每个测试用例执行后记录相关的日志文件，作为测试过程记录，一旦日后发现问题，开发人员可以通过这些测试记录方便的定位问题。而不用测试人员重新搭建测试环境，为开发人员重现问题。

3、及时确认发现的问题：测试执行过程中，如果确认发现了软件的缺陷，那么可以毫不犹豫的提交问题报告单。如果发现了可疑问题，又无法定位是否为软件缺陷，那么一定要保留现场，然后知会相关开发人员到现场定位问题。如果开发人员在短时间内可以确认是否为软件缺陷，测试人员给予配合；如果开发人员定位问题需要花费很长的时间，测试人员千万不要因此耽误自己宝贵的测试执

74

企业应用软件测试实训课程

行时间，可以让开发人员记录重新问题的测试环境配置，然后，回到自己的开发环境上重现问题，继续定位问题。

4、与开发人员良好的沟通：测试执行过程中，当你提交了问题报告单，可能被开发人员无情驳回，拒绝修改。这时候，只能对开发人员晓之以理，做到有理、有据，有说服力。首先，要定义软件缺陷的标准原则，这个原则应该是开发人员和测试人员都认可的，如果没有共同认可的原则，那么开发人员与测试人员对问题的争执就不可避免了。此外，测试人员打算说服开发人员之前，考虑是否能够先说服自己，在保证可以说服自己的前提下，再开始与开发人员交流。

5、及时更新测试用例：测试执行过程中，应该注意及时更新测试用例。往往在测试执行过程中，才发现遗漏了一些测试用例，这时候应该及时的补充；往往也会发现有些测试用例在具体的执行过程中根本无法操作，这时候应该删除这部分用例；也会发现若干个冗余的测试用例完全可以由某一个测试用例替代，那么删除冗余的测试用例。 五、测试记录（BUG）

• 测试结果是记录测试期间测试用例的执行情况，记录测试发现的缺陷，并且用来对缺陷进行跟踪。 • 比测试日志包含的信息更多。

在测试过程中，要准确定位Bug。一旦出现异常情况，则在第一次出现时就记录下在何种情况下出现、操作步骤是什么、产生怎样的结果，尽可能简要且详细的描述Bug 产生的过程及情景，然后多测试几次，变化一下输入的情况或者数据，或者变换一下输入的步骤，看是否仍会有类似的情况出现，然后将变化的情况添加到 BugReport中。第一次出现就填写BugReport是为了避免出现不可重现的情况时，无法将Bug重现，导致BugReport描述不清楚，从而 开发人员无法修复该Bug，多测试几次，或者变换一下操作，可以更准确的定位Bug，使得Bug描述的更清楚一些，尽可能在BugReport中给开发人 员提供最精确的步骤和准确的描述，这样可以减少开发人员在重现Bug时跟踪调试的时间。

当客户有BugReport 返回时，仔细阅读BugReport，以及解决方案，一个Bug可能会和很多模块相关，在开始下一轮测试时，要优先测试BugReport中报告的 Bug，同时也要注意相关联的模块的测试以及变动，BugReport的修改极有可能涉及ITP的修改，而且BugReport中也可能会涉及需求变更的 内容，有变更，ITP就要做相应的修改，这些信息都要及时的了解，否则在IT阶段发现，会增加纪录Bug的工作量，且尤其是涉及测试数据的，如果没有及时 更新测试用数据，都会影响IT的执行，如果在执行测试时，再修改ITP，尤其是重新设计测试数据，一定会延长测试的时间，也可能会使得开发人员投入不必要 的精力。

测试记录总的说来包括两方面：由谁提交和BUG描述。

一般而言，BUG都是谁测试谁提交，当然有些公司可能为了保证所提交BUG的质量，还会在提交前进行BUG评估，以确保所提交的BUG的准确性。 在BUG的描述上，至少要包括以下一些方面内容：

序号 标题 预置条件 操作步骤 预期结果 实际结果 注释 严重程度 概率 版本 测试者 测试日期 以上是描述一个bug时通常所要描述的内容，当然在实际提交bug时可以根据实际情况进行补充，

75

企业应用软件测试实训课程

如附上图片、log文件等。

另外，一个版本软件测试完毕，还要根据测试情况出份测试报告，这也是所要经过的一个环节。 5.1 BUG的由来

Bug一词的原意是“臭虫”或“虫子”。但是现在，在电脑系统或程序中，如果隐藏着的一些未被发现的缺陷或问题，人们也叫它“Bug”，这是怎么回事呢？

从电脑诞生之日起，就有了电脑BUG。第一个有记载的bug是美国海军的编程员，编译器的发明者格蕾斯•哈珀（GraceHopper）发现的。哈珀后来成了美国海军的一个将军，领导了著名计算机语言Cobol的开发。

1945年9月9日，下午三点。哈珀中尉正领着她的小组构造一个称为“马克二型”的计算机。这还不是一个完全的电子计算机，它使用了大量的继电器，一种电子机械装置。第二次世界大战还没有结束。哈珀的小组日以继夜地工作。机房是一间第一次世界大战时建造的老建筑。那是一个炎热的夏天，房间没有空调，所有窗户都敞开散热。

突然，马克二型死机了。技术人员试了很多办法，最后定位到第70号继电器出错。哈珀观察这个出错的继电器，发现一只飞蛾躺在中间，已经被继电器打死。她小心地用摄子将蛾子夹出来，用透明胶布帖到“事件记录本”中，并注明“第一个发现虫子的实例。”

从此以后，人们将计算机错误戏称为虫子（bug），而把找寻错误的工作称为（debug）。意即“捉虫子”或“杀虫子”。遗憾的是，在中文里面，至今仍没有与“Bug”准确 对应的词汇，于是只能直接引用“Bug”一词。虽然也有人使用“臭虫”一词替代“Bug”，但容易产生歧义，所以推广不开。 所谓“（Bug）”，是指电脑系统的硬件、系统软件（如 操作系统）或应用软件（如文字处理软件）出错。硬件的出错有两个原因，一是设计错误，一是硬件部件老化失效等。软件的错误全是厂家设计错误。那种说用户执 行了非法操作的提示，是软件厂商不负责的胡说八道。用户可能会执行不正确的操作，比如本来是做加法但按了减法键。这样用户会得到一个不正确的结果，但不会 引起bug发作。软件厂商在设计产品时的一个基本要求，就是不允许用户做非法的操作。只要允许用户做的，都是合法的。用户根本就没有办法知道厂家心里是怎 么想的，哪些操作序列是非法的。

程序中隐藏的功能缺陷或错误。由于现在的软件复杂程度早已超出了一般人能控制的范围，如Win95、Win98这样的较成熟的操作系统也会不定期地公布其中的Bug。如何减少以至消灭程序中的Bug，一直是程序员所极为重视的课题。 5.2 BUG的定义

Bug不仅仅是代码级别的错误，而且可以是在设计和测试阶段发现的缺陷。无论什么时候，任何有助于改善产品质量的提议、任何需要引起注意、值得跟踪的问题、任何可能潜在的错误，都可以而且应该作为一个Bug。所以说，在软件开发流程中，对Bug的管理是至关重要的。科学的做法是由工具来记录、跟踪、管理Bug的后继变化和处理方案。 1、及时的分派和修复bug。

仅有bug的录入是不够的，pm或dev lead应及时根据bug的description和stack trace，把bug分派

76

企业应用软件测试实训课程

给corresponding developer去fix，同时规定一个fix by when的期限。 2、详细的bug description

在这一点上，也对测试人员提出了一定的要求。在测试过程中，光发现软件本身的问题还不够，当错误（有时可能是memory crash, a/v, assert,等），应把call stack也记录下来并写入“bug跟踪系统”。有些bug很难repro，但一个详细的bug description可为bug的fix带来帮助。 5.3 BUG的处理

从管理这个层次上讲，一旦BUG被发现后，最困难的并不是如何去记录，分派人员去解决，并予以追踪。最困难的是决定对某些BUG推迟解决，甚至不予解决。 这样的BUG往往是在产品开发的中后期发现的，而且是由于最初架构设计的缺陷所造成的，解决这样的BUG需要大量的人力和时间，影响面大，可能会引入新的 BUG。对于这样的BUG，PM要与客户端的其他部门和人员联系，比如市场部门，技术支持部门，甚至于早期介入的客户。如果从他们的反馈中，确认这种 BUG对决大多数客户和决大多数的使用(scenarios)没有影响，就要果断决定推迟，或不予解决。

对于这些已决定推迟，或不予解决的BUG，还有一些后续工作非常重要。首先要祥细的记录，以便在下一个版本中解决；其次要让有关技术支持人员深刻理解，准备应对方案。 *****微软的经验*****

在微软，当编码人员在实现某个功能遇到困难的时候，一般地说会经历以下的程序： （1）编码人员自己想方设法去解决，包括向有关同事咨询。 （2）编码人员向本部门的技术带头人请教。 （3）编码人员在项目的例会上提出讨论。

（4）由项目经理组织专家及相关其他部门人员汇诊。 （5）由项目经理听取市场部门和顾客的意见。

一般地说经过（4）和（5）了以后，问题就比较复杂了，不是简单的措施能解决得了。这时有两种可能，一是要实现的功能对顾客影响不大，在这种情况下多半会 取消这个功能（应该说把它留给下一个版本）。这样决定的目的是为了让项目按计划进行，让产品尽快投放市场。市场如战场，尽快的占领并获得应有的利润比技术 完美更重要。另一个可能是要实现的功能对顾客影响很大，没有这个功能产品将失去很大的市场。在这种情况下多半会调整项目计划，集中人力物力攻克这个难关， 在问题没解决的情况下项目的其他部分可能暂缓进行。这样决定的目的是确保不会生产出一个没有市场竞争力的产品。

这两种决定的准确性都是建立在对市场的充分把握和对顾客的充分认识的基础上的。这是中国的软件企业的又一弱点。在中国有多少软件企业像重视项目开发一样重视市场和销售，像重视技术一样重视顾客，售后服务和技术支持？

通常大家发现BUG时会对BUG进行分类，可分类的方式只有一种，就是严重级别,难道没有其它的分法吗。比如我们碰到下面这种情况，测试人员发现有一种功能是必需加入进去的，这时他与程序员说，程序员说没有时间或是不必要，这时这种情况 则会形成两者的扯皮，最终的结果也就不了了之了，这样会戳伤了测试人员的积极性，下次他们再也不会尽心的考虑产品的问题，只要可以运行就可以了。其实这种情况是可以解决的,下面我会提到一个新的软件缺陷分类概念，从而有效的解决

77

企业应用软件测试实训课程

这个问题。

在BUG中不仅仅只是严重极别，更多的则是功能没有做到。说到这里也许大家都理解了，就是需求没有考虑到，可需求不会一次就很完美的，需要大家的共同努力，来不断的完善。那么怎样才能让测试人员提出的好的建议得到有效的执行？这就是我下面想说的。在BUG中还有一种分法，根据BUG内容来分， 主要分为需求Bug与程序Bug，对于这种分法的好处就是明确了Bug处理的责任人。对于程序Bug我们都知道是由相关开发人员进行处理。下面主要讨论一 下需求Bug,需求Bug从名称上来就知道是要交由需求人员进行处理，可怎么处理，怎样在处理的过程中有效的让这些创意得到体现。现在我们都有Bug管理 系统，这时我们的测试人员将需求Bug不是提交给程序员，而是提交给需求分析人员，由他们进行处理，不过这里我想强调的是对需求Bug的定位，如果这个 Bug在软件需求说明书中明确提到了，这时就不可能定位它为需求Bug，它是必需让程序员实现的，称为软件功能缺陷，提交由程序员进行处理。但如果需求说明书没有明确提到的，我们则可以定位为需求Bug，处理的流程如图。 这样处理有以下好处，首先需求Bug再不象以前，没有人进行确认，需求的处理人员本来就是需求人员，由他们确认与跟踪是最好不过的，因为他们对需求有绝对的权威。同时测试人员其实就是最早的用户，他们的需求就是用户的需求，这种方法加强了需求人员与测试人员的沟通，使需求得到有效的补充，从而让产品更加完善。还有测试人员从本质上来说与程序员还是对立的，这里如果为了这样一个不是软件本身问题的问题形成与开发人员的对立，则会

78

企业应用软件测试实训课程

出现赢得战役而丢失整个战争的情况，测试人员协调好与开发人员的关系，让他们更有效的对软件本身的缺陷形成有效的关注是最好的。还有最为关键的一点，测试人员的激情是最重要的，如果他们的想法没有得到体现，这时会渐渐的失去对测试的兴趣，从而软件的质量则会无法得到保证，通过这种方法可以让他们看到自己的建议可以通过对需求人员的反映得到实现，让他们时时觉得自己的想法是可以通过这种方法来有效的推行，这样工作的积极性才会有保障。

不过从实施的角度来说，还是有一定的困难的，首先要让大家改变以前那种凡是Bug就是由开发人员负责的观念，其次需求人员的工作量要加大，不过 广泛的了解需求是他们的本份工作，想来不会很困难，还有必需要有有效的Bug管理工具，比如BugManage、Bugzilla等等，不要出现那种对需求人员说了，可过两天就忘的情况出现，这时需求Bug的生命周期会出现跨越两个软件开发周期，因为有些需求会在下一版实现，这时测试人员需要延长对这些需求Bug的管理。 5.4 BUG关联

微创的BMS系统定义了bug之间的关联，有5种： 依赖关联、重复关联、相关关联、文件关联、附件

依赖关联：一个Bug的解决依赖于其他的Bug，例如，程序员B的Bug只有等到程序员A的Bug解决后才能解决，一个版本中的某个Bug依赖前一个版本 中的Bug，甚至一个产品的Bug依赖于其他产品的Bug。依赖关联的处理确实比较复杂，不过就我个人经验而言一般使用的比例比较小。如果Bug间存在依 赖关系，那么处于被依赖（或者父依赖）的Bug应尽快加以解决。

重复关联：如果其中一个缺陷实际上是另一个缺陷的重复缺陷，就需要在这两个缺陷间建立起重复关联。我们要求测试人员尽量不要File重复的Bug，如果一 旦File了重复的Bug，则在这组重复的Bug间建立“重复关联”，一旦主缺陷解决了，所有的其它重复缺陷（从缺陷）也就都得到了真正的解决。

相关关联：相对于依赖关联和重复关联，相关关联的概念要简单很多。同一个数据库中，当一个缺陷与其它缺陷存在一定的关系，但却并非依赖关系或重复关系时， 就可以为它们建立相关关联。相关关联着的各个缺陷之间，不存在任何的依赖关系，这意味着可以地处理各个缺陷。 重复关联和附件：前者是因为各个test很有可能会登记了重复的bug，后者是因为有时候文字描写不清楚，直接上传一张图片效果可以好很多。当然了，给个文件的链接也是好的。

有些功能更加强大的Bug管理工具甚至将Bug和相应的Test Case关联起来，将Bug与源代码管理中的Change Number (或者文件号)关联起来。当然，一个Bug管理工具最基本的操作就是New, Resolve, Close, Assign以及Query查询。能把这些最基本的操作做好，软件产品的质量已经会有很大的提升了。

5.5 BUG的处理流程

79

企业应用软件测试实训课程

BUG从提出到close所经过的一些流程，其他比如keep No action\\keep spec等一些状态流程都未包含在内，在此仅做示范说明。

5.6 测试工作中的常见问题

下面列出一些显而易见的、容易被项目组忽略的错误，这些错误可能是容易修改的、或是容易避免的，但是对于测试组或用户来说可能却是非常头痛和不方便的。 一、形象类问题：---不专业、用户不信任

1、不符合用户操作习惯。如，快捷键定义不科学、不实用(键位分布不合理、按键太多，甚至没有快捷键)；

2、界面中英文混杂，经常弹出莫名其妙的信息，而且还拼错单词，写错别字； 3、SETUP界面：CopyRight 1994-1996；缺省认为用户使用某种分辨率；

4、说明书或帮助的排版格式不专业：中英文搭配不对、标点符号全角半角部分、没有排版准则； 5、程序名/路径名是程序员的名字、或没有安装程序、或安装程序不完善(丢掉一些必要的模块或文件)

6、界面元素参差不齐，文字不能完全显示，TAB时鼠标乱走。 二、可用性问题：---用户无法使用或不方便使用

\"用户比开发或测试人员在接触界面上要花费更多时间。表面上不重要的方面的影响会变得越来越大，最终甚至会掩盖了产品得有用得方面。\"下面是一些用户界面错误的例子：

1、输入无合法性检查和值域检查，允许用户输入错误的数据类型，并导致不可逆料的后果 2、界面中的信息不能及时更新，不能正确反映数据状态，甚至对用户产生错误的误导。如：数据库中剩余记录个数；参数设置对话框中的预设值

80

企业应用软件测试实训课程

下面是一些低效的用户界面的例子： 1、表达不清或过于模糊的信息提示

2、要求用户输入多余的、本来系统可以自己得到的数据。如：服务是否启动，安装后用户要手动修改某些配置文件。

3、为了达到某个设置或对话框，用户必须做许多冗余操作。如，对话框嵌套层次太多。 4、不能记忆用户的设置或操作习惯，用户每次进入都需要重新操作一次初始环境。 5、使用不完善的功能且不给用户以恰当的提示。 6、不经用户确认就对系统或数据进行重大修改 三、稳定性问题：---影响用户正常工作

1、不可重现的死机，或不断申请但不完全释放资源，系统性能越来越低

2、主系统和子系统使用同样的临界资源而互相不知道。如：使用同样的类名或临时文件名、使用同样的数据库字段名或登录帐号。

3、不能重现的错误，许多与代码中的未初始化变量(在Debug时一般是缺省初始化的)有关，有些与系统不检查异常情况(如内存申请不成功、网络突然中断或长时间没有响应)有关。 四、其他问题

1、文档匮乏：无标准；无新功能使用方法；无版本改动说明。没有说明文档的产品不是一个完整的产品，没有说明或没有正确说明的功能是一个没有完全实现的功能，因为用户无法用得起来。 2、运行时不检查内存、数据库或硬盘空间等。

3、无根据地假设用户环境：硬件/网络环境；有些动态库；安装程序换台机器不正确；假设网络随时都是连通的。

4、提供的版本带病毒，或根本无法安装，或没有加密。

5、提供Debug版本给测试组或测试用户，或项目组与测试组使用不同版本。 6、用户现场开发和修改，没有记录和保留。

7、错误反复出现，改动得不彻底、或版本管理出现混乱。 8、错误越改越多，改动得不彻底、或改动得不小心。 9、版本中部分内容和接口倒退。

10、有些选项永远是灰的；有些选项、菜单项在该灰时还不灰，并且还能状态显示。 11、资源没有和代码分离，不同语言版本间不能平滑转换。 5.7 BUG-Report的编写

81

企业应用软件测试实训课程

优秀的bug report对反映测试小组真实的和可理解的工作质量同测试本身一样都是非常重要的。Bug report的核心是对错误的描述。编写好的bug report是一种好的艺术形式。采用以下的10条技巧可以帮助你的小组提高编写bug report的质量：

1、组织Structure：测试人员应该采用深思熟虑的，小心谨慎的方法执行测试，并且做详尽的记录。这样可以促使他们对测试下的系统有很好的认识。当错误发生的时候，一个有组织的测试人员能够知道最早出现问题的地方。

2、重现Reproduce：测试人员在编写bug report之前必须在检查问题是否可重现。如果错误不可再重现，仍然应该写下来，但是必须说明问题的偶然性。一个好的处理原则就是在编写bug report之前反复尝试3次。

3、隔离Isolate：在尝试编写bug report之前，必须试着隔离错误。可以采用改变一些变量的方法，如系统的配置，它可能可以改变错误的症状。这些信息可以为开发人员着手调试提供思路。 4、归纳Generalize：在测试人员发现了一个已隔离的，可重现的问题后，应该对问题进行归纳。同一个问题是否出现在其他的模块或其他的地方？同一个故障是否有更加严重的问题？

5、对比Compare：如果测试人员以前曾经验证过现在出错的测试用例，那么他就应该检查以前的测试结果以检查相同的条件是否通过以前的测试。如果是的话，那么这个问题就象是一个回归的错误。注意由于同一测试条件有可能出现在多个测试用例中，这个步骤就不仅仅只是检查一个测试用例在以前的多个结果。

6、总结Summarize：在bug report的第一行写上错误的总结是非常关键的。测试人员要花些时间思考已发现的错误对客户有何影响。这不仅仅要求测试人员编写的报告要能够吸引读者，使和管理层的沟通清晰，还要能够帮助设置错误修复的优先级别。

7、精简Condense：在bug report的初稿完成后，测试人员应该反复阅读它，集中剔除那些没有关系的步骤或词语。隐含的或模糊的说明和那些由于对没有任何关系的细节或者那些在重现错误过程中不需要的步骤而消磨报告欢迎程度的无穷唠叨都不是bug report的目标。

8、消除歧义Disambiguate：测试人员在精简空话的同时或其之后随即应该再仔细检查报告是否有会产生误解的地方。测试人员应该尽量避免使用模糊的，会产生歧义的和主观的词语。目标是使用能够表述事实，清楚的，不会产生争执的词语。

9、中立Neutralize：如文中所述，作为坏消息的传递人，和善地提交消息是一个挑战。如同所有的错误总结一样，的bug report在措辞方面应该保持公正。攻击开发人员，指责潜在的错误，企图诙谐或使用挖苦将引起开发人员的憎恶，并且使注意力从“提高产品质量”这个大的目标上转移开了。谨慎的测试人员只用Bug report来描述事实。

10、检查Review：一旦测试人员感觉bug report是他能够编写的最好版本，他应该将报告再给一个或多个同行进行检查。他的同事们也应该给出一些建议，为了澄清问题不断地提问，如果适当的话，甚至可以挑战“错误成灾”的结论。在允许的时间里，测试小组应该尽可能提交最好的bug report。 以上10条技巧可以帮助你和你的小组提交准确简洁的，彻底校订的，精心构思的，高质量的技术文档。测试小组应该集中编写bug report的任务，测试组长和经理应该让测试组成员清楚地认识到编写

82

企业应用软件测试实训课程

优秀的bug report是一项首要的工作任务。 衡量优秀的bug report的质量指标应该包括如下： 1：对管理层来说，是清晰明了的，特别是在概要这一级；

2：对开发部门是有用的，主要是给出能够让开发人员高效地调试问题的相关信息；

3：可以很快的将bug从“Opened”状态转变成“Closed”状态，减少为得到更多的信息从开发人员打回的差的bug report并导致测试人员返工的时间。

改进bug报告的流程是需要花费一些时间的，但是也给予了效果显著的回报。首先，简单的流程改进了测试小组和高层、平行管理层之间的沟通，增强小组的信任度，名望和鼓励管理层给测试投资更多的资源。第二，平稳地递交报告给开发人员促进了测试和开发人员之间积极的关系。第三，更短的bug生命周期是更加有效的，在时间上之前花费在编写优秀bug report上的时间和后期由于返工差的bug report花费的时间相抵消。这些回报帮助开发流程通过有效的沟通和高效率的流程获得更好的产品质量。

5.8 BUG跟踪与管理

BUG跟踪与管理是测试流程中重要的一项内容。BUG由测试人员提出，存在异议时，一般以项目经理判定为准；如果项目经理认为不是BUG，测试人员可以把BUG注销或删除（注销BUG不参与BUG统计）；如果存在严重争议，则建议项目组协商解决或汇报高层解决。

1、BUG的具体属性：

对于每一个bug而言总是有一些具体的属性的，常见属性如下表所示：

bug属性表

属性 BUG状态 说明 具体内容 指在BUG跟踪和管理过程中的包括待分配，待修复、待验证、已解决、遗留、状态标识。 注销6个状态。 包括致命、严重、一般、微小4种。 严重程度 以可能对用户造成的影响程度作为最终的判断依据。 优先级别 指开发人员修改BUG的优先程包括紧急，优先，一般，次要4种。 度，由项目经理在审核BUG时分配。 再现程度 指BUG在特定环境和操作中BUG的重复出现的频率。 包括每次再现、经常再现、很少再现、出现一次。 83

企业应用软件测试实训课程

引入过程 为BUG最初引入的过程或阶段。 包括需求、系统设计、概要设计、详细设计、UI设计、编码、用户文档。 测试阶段划分 2．严重程度

描述现在的测试进展阶段 包括单元测试、集成测试、确认测试、系统测试、Alpha测试，Beta测试，回归测试，封样测试 严重程度为BUG对用户造成的影响程度的属性，它是BUG本身对软件的影响和可能对用户造成的影响的综合体现。BUG分4个严重级别：致命、严重、一般、微小。 判定权限：测试人员。 具体描述如下表所示：

bug严重程度描述表

名称 致命BUG 描述 主要功能直接导致系统死机、蓝屏、挂起或是程序非法退出； 被测系统的主要功能点没有实现； 主要模块/功能不满足需求或设计上的要求； 软件的安全缺陷导致重要数据丢失或损坏，且无法恢复。 严重BUG 次要功能导致系统死机、蓝屏、挂起或是程序非法退出； 被测系统的次要功能点没有实现； 主要功能的执行结果与预期结果差别较大，或是计算结果不正确； 易用性不好，导致用户可能不能正常完成软件的主要功能操作； 程序执行过程过于缓慢； 程序占用过大的系统资源，或是占用资源后不能正常释放； 主要界面有明显的错别字或描述错误。 一般BUG 软件的实际执行过程与预期结果有差异，但不严重； 非正常操作或输入导致系统出错，或执行结果不正确； 系统运行过程中偶尔（出现概率<5%）有出错提示或导致系统运行不正常； 软件交互性不好，对于用户可能造成难于操作、学习和理解； 在用户经常使用的环境中，界面不美观，影响软件品质； 界面、程序或帮助文档中文档或文字描述问题，造成用户难于理解。 84

企业应用软件测试实训课程

微小BUG 软件的实际执行过程与预期结果有较小的差异； 软件不能处理用户可能使用的极端条件下的操作； 界面、程序或帮助文档中文档或文字描述问题，但影响不大。 判定准则： 以可能对用户造成的影响程度为最终的评判依据，每个项目也可以针对项目自身特点把严重程度定义进一步细化。 3．再现程度

再现程度为BUG在指定测试环境中复现的概率，分4种程度：每次再现、经常再现、很少再现、出现一次。

判定权限：测试人员。

bug出现概率表

每次再现 经常再现 很少再现 出现一次 出现概率100%； 出现概率大于20%； 出现概率小于20%； 在整个测试工作中只出现一次。 说明：如果某些软件对出现概率要求严格，可在BUG描述中进一步进行阐述。

4．优先级别

优先级别体现了开发人员修改BUG的优先顺序，分4个级别：尽快修复、必须修复、建议修复、低优先级。具体描述如下表所示： 判定权限：项目经理。

表3-6 bug优先级别描述表

名称 尽快修复 描述 需要开发人员马上修复，并尽快修改完成。 一般指BUG较为严重，并且会对其他工作造成不良影响的情况。 必须修复： 建议修复： 需要开发人员修复，并且要修改完成。 一般指BUG较为严重，但对其他工作影响较小的情况。 开发人员最好要进行修改，但并不一定必须修复。 85

企业应用软件测试实训课程

一般指BUG较为轻微，影响软件品质。 此类BUG若最终不修改，一般要作为遗留BUG。 低优先级： 开发人员可以根据实际情况来决定是否修改。 一般指BUG无关紧要，对项目质量影响非常小。 此类BUG若最终不修改，可以注销或作为遗留BUG。 判定标准：项目经理会把BUG的严重程度与修改负责人实际情况相结合进行制定。 5．BUG状态

BUG状态为在BUG跟踪/管理过程中对BUG的状态标识。有5种状态：待修复（新提交）、待验证、已解决、遗留、注销。

待修（新提交）：指测试人员发现，或者开发人员修改后仍未解决的BUG。 待验证：开发人员已经修改的，测试人员还没有进行验证的BUG。 已解决：经验证后已经修复好的BUG。

遗留：经项目经理确认在本版本中可以不修改的缺陷。

注销：实质上不是程序的最终BUG，但需要保留。例如，所对应需求发生变更或是被取消的BUG，或是由于产生歧义，项目经理建议注销的BUG。 6．引入阶段

BUG引入阶段为最初产生BUG的阶段。分为5种：需求、设计、编码、UI、其他。 7．BUG跟踪流程 具体流程可见下图： BUG跟踪流程图

86

企业应用软件测试实训课程

测试人员 具体流程为：

 测试人员通过执行测试用例，出现问题后判断是否为BUG，如果是则把BUG信息输入到

bug管理系统，此时BUG状态为待修复。

 开发人员通过bug管理系统查看到有新的待修复BUG，则采取相应措施。如果进行程序修

改，则在修改后，选择修改中的“已经修改”，确认后，BUG状态自动变为待验证；如果暂时不作修改，则在BUG回执中说明，此时状态仍为待修复。  如果BUG状态为待验证时，需要测试人员在下一版本后进行验证。如果此BUG确实修复，

则把BUG状态选择为已解决；如果没有修复，且仍需要修改时，测试人员把BUG状态改为未修复。

 如果此BUG最终未修改或未修改成功，或对该BUG存在争议，则有项目经理决定是否遗

留，或是注销。

 测试人员可以自主把待修复BUG改为注销。  （注销的BUG不参与统计。） 5.9 BUG的描述准则

一条优秀的BUG信息，要求测试人员能够：

 尽量要把BUG信息描述清楚而具体，这样能便于程序员更快捷准确地找到问题之所在，即

要解释清楚如何产生的BUG。

87

执行测试用例 测试人员 发现并提交BUG 开发人员 BUG待修复 未修改 BUG遗留或注销 是否修改 项目经理 开发人员 BUG已修改 BUG待验证 测试人员 是否解决 BUG已解决 项目经理 BUG遗留或注销 企业应用软件测试实训课程

           

对BUG进行分析，以最少步骤描述BUG。 描述步骤不能缺失。

描述以事实为准绳，不能带有恶意，提交BUG表时避免“大放厥词”。 每条BUG对应一条BUG表。

必要时，附加附件来帮助阐明BUG。

检查BUG管理系统，看看是否有相似的缺陷现象并加以分析。 如果有时间，要进一步对BUG进行分析。

如果暂时不能复现此BUG，就要尽量回忆自己做过的每一步，加以记录，并且要做及时记录，以免忘记更多。

某一BUG可能是因为前面做的操作导致而延迟发生，所以最好也要记下之前做过的一系列操作。

如果测试操作可能会导致缺陷不能复现，可以策略地使用录制/回放工具。 BUG描述清晰，无二义性。

有时有经验的测试人员凭借直觉就可以发现一些问题，这可称为“错误猜测”。测试人员可以把错误猜测结果也进行说明，但一定要标明是“猜测”的。

对于遗留BUG的描述更为重要，因为项目经理会拿着这些BUG的报告参加封样评审会，而且客户代表和高层经理会特别关注这些BUG的现象和严重级别。所以，对于预计遗留BUG，编写高质量的BUG信息描述能够给相关人员充分的信息，以使其对这些BUG有大概的了解。内容应该包括：

 尽量简短而清晰描述，使相关人员知道该BUG现象如何。

 指明该BUG发生的关键条件，包括测试环境和其它因素。  指明该BUG的严重程度、质量特性等属性。 5.10测试BUG心理学

对于软件中的BUG，不同的人有不同的心理。这里给大家列出来，以方面各个角色之间针对BUG信息的沟通和管理。

对于测试人员，他在发现BUG后可能的心理：

    

我是否要报告这个BUG？

我是否要把很多类似现象的BUG描述为一个还是多个？ 是否要把UI方面的缺陷报告出来？ 对于轻微BUG，我是不是不报告？ 对于BUG的分析，我要花多长时间？

测试人员的对BUG的判断对测试人员自己影响很大，而且会逐渐对测试人员可信赖度产生影响。 测试人员对BUG报告可理解性和对BUG的分析能力对测试人员的可信赖度有潜在的影响力。 另外，对于测试负责人来讲，他可能会想：

   

对于存在异议的BUG，我如何来处理？

如果BUG比较微小，我是否一定坚持要求开发人员修改？ 如果BUG无关紧要，我怎样要求测试小组处理这类问题？ 如果项目经理对BUG也存在异议，该如何处理？

对于开发人员呢？他们的心理可能会是：

 这个BUG是否由我来负责修改？  我是否要修复BUG还是作为遗留？

88

企业应用软件测试实训课程

 BUG很多时，我要先修改哪些BUG？  我会花费多少时间完成这些BUG的修改？ 对于项目经理，他可能更关心：

   

如果软件BUG非常多，我该如何办？

如果某一个模块或者某个开发人员BUG特别多，我该如何调整？ 我是否要批准遗留或延迟修复BUG？ 如果BUG存在争执，我如何处理？

对于高层经理，他可能关心：

 对于项目经理要遗留的BUG我要采取什么态度？

 对于项目经理和测试人员的BUG争执，我该如何处理？ 对于客户方代表（一般是客户方产品经理），他比较关心：



  

5.11 BUG的交流技巧：

从某种意义上讲，开发人员是“创造者”，而测试人员是“破坏者”，那么测试人员与开发人员的BUG沟通存在争执和异议是正常的，那么如果进行有效地沟通呢？我们这里不谈沟通本身的技巧，但对于BUG沟通，的确有其独特的经验和技巧。

首先，双方要愿意以一种坦诚的心态讨论BUG信息，如果开发人员不喜欢测试人员BUG信息的表达方式，那么应该对他们要求改变的建议保持理解。

测试人员进行BUG沟通的目的在于：一方面要迫使开发人员修改BUG，另一方面要策略地驳回开发人员不想修改BUG的各种理由。那么，我们来看看开发人员什么情况下很想修复BUG，什么情况下不想修复BUG，这样测试人员在BUG信息描述时，就有技巧可言了。

在下列情况下，开发人员很想修复BUG： 

     

BUG描述得很严重。

该BUG会影响很多人的工作。 BUG修复起来很容易。

该BUG严重影响软件品质和品牌形象。 该BUG使开发人员或其他人感到难堪。 管理层要求修复。

测试与开发良好的人际关系，开发人员对测试人员的信任感。 我是否要求项目经理修复要遗留的BUG？ 我是否要花时间搞清楚BUG的来龙去脉？

是否要把遗留BUG向用户说明，或以何种方式说明？ 为了要修改待遗留BUG，软件发布延期怎么办？

在下列情况下，开发人员不想修复BUG：     

开发人员不能复现BUG。

需要繁复的步骤导致的BUG。 出现BUG的描述步骤不清楚。 BUG表现描述不清楚。 修复BUG花销大。

企业应用软件测试实训课程

    修复BUG会给整个程序带来一定的风险。 BUG严重级别低。

管理层对该BUG为无所谓的态度。

开发人员对测试人员没有好感，对测试人员不信任。

其他工作:

测试执行工作主要以测试用例执行和BUG跟踪为重点，但是以下工作还是不能忽略的。

1．测试计划与测试说明的变更。由于计划经常会与现实有差异，所以测试计划需要及时调整才能更好地进行测试工作的管理；测试说明更是如此，有时测试用例的变更量会超过最初的测试用例数量。 2．项目组内部的沟通。BUG的沟通上面叙述过了，但项目组在测试阶段的沟通不止是BUG沟通，还包括测试阶段约定（主要指BUG定义约定和测试版本约定），每一测试版本集成的沟通工作，与项目经理预计遗留BUG的沟通等。 3．测试工作检查，包括：



  

六、软件评估

这里评估指软件经过一轮又一轮测试后，确认软件无重大问题或者问题很少的情况下，对准备发给客户的软件进行评估，以确定是否能够发行给客户或投放市场。

软件评估小组一般由项目负责人、营销人员、部门经理等组成，也可能是由客户指定的第三方人员组成。 1、目的

• 对每一次测试结果进行分析评估，在每一个测试阶段提交测试分析报告。 2、时机

• 已生成了测试结果 3、输入工件 • 测试结果 4、步骤

• 分析测试结果—由相关组对每一次测试结果进行分析，并提出变更请求或其他处理意见。 • 分析阶段测试情况

􀁹 对每一个阶段的测试覆盖情况进行评估。 􀁹 对每一个阶段发现的缺陷进行统计分析。

90

测试执行策略与计划是否一致。 有多少需求经过了测试。

哪些需求得到了满足，哪些需求没有通过。 测试工作进度与效率如何。

企业应用软件测试实训课程

􀁹 确定每一个测试阶段是否完成测试。 􀁹 对每一个阶段生成测试分析报告。 5、输出工件 • 测试分析报告 • 变更请求 七、测试总结

测试分析报告是对每一个阶段(单元测试、集成测试、系统测试)的测试结果进行的分析评估（包括缺陷、覆盖率等）。

软件测试执行结束后，测试活动还没有结束。测试结果分析是必不可少的重要环节， “ 编筐编篓，全在收口 ” ，测试结果的分析对下一轮测试工作的开展有很大的借鉴意义。前面的 “ 测试准备工作 ” 中，建议测试人员走读缺陷跟踪库，查阅其他测试人员发现的软件缺陷。测试结束后，也应该分析自己发现的软件缺陷，对发现的缺陷分类，你会发现自己提交的问题只有固定的几个类别；然后，再把一起完成测试执行工作的其他测试人员发现的问题也汇总起来，你会发现，你所提交问题的类别与他们有差异。这很正常，人的思维是有局限性，在测试的过程中，每个测试人员都有自己思考问题的盲区和测试执行的盲区，有效的自我分析和分析其他测试人员，你会发现自己的盲区，有针对性的分析盲区，必定会在下一轮测试用避免盲区。

每个版本有每个版本的测试总结，每个阶段有每个阶段的测试总结，当项目完成后，一般要对整个项目做个回顾总结，看有哪些做的不足的地方，有哪些经验可以对今后的测试工作做借鉴使用，等等。测试总结无严格格式、字数。应该说，测试总结还是很必要的。 八、测试与维护

由于测试的不完全性，当软件正式发布后，客户在使用过程中，难免遇到一些问题，有的甚至是严重性的问题，这就需要修改有关问题，修改后需要再次对软件进行测试、评估、发行。 软件维护的原因具体分为4类：改正性维护，适应性维护，完善性维护和预防性维护。

1、改正性维护：在软件投入运行后,可能会暴露一部分在测试阶段没有发现的错误,为改正这些错误而对软件进行的修改就是改正性维护。

2、适应性维护：由于软件运行的外部环境(软件,硬件)和数据环境等的变化而修改软件使之适应这些变化,就是适应性维护。例如:原先在DOS下开发的软件，现在要使之适用于windows而进行的修改。 3、完善性维护：用户的需求是经常变化的，在软件使用过 程中，用户会对软件提出新的功能和性能要求，为了满足这些新的要求而对软件进行修改，使之功能和性能得到完善。

4、预防性维护：就是采用先进的软件工程方法对需要维护的软件或某部分软件重新进行设计，编码和测试，以提高软件的可维护性和可靠性等，为以后进一步改进软件打下基础．例如：有个软件原先是用结构化的 思想编写的，现在为了提高软件的质量而用面向对象的方法重新设计和编写软件。 此间的工作流程与客服人员的工作交叉较多。经常要给客服、市场甚至是用户进行软件使用的培训，

91

企业应用软件测试实训课程

同时接受他们反馈的问题，其中会因为测试的不充分而暴露出来的问题。测试人员要将这些问题分门别类的给予答复和解释，并且将需要开发人员修改的问题登记入BUG库，督促开发人员修改这些BUG。

九、 软件测试过程中的评审 9.1涉及评审的问题

评审测试的开始时间是否会延期 有没有抵触评审的角色

一段时间内是否很难得到工作的检查信息。 更换工具有可能导致他们反感评审工作 评审结果可能会影响对个人的工作评价 9.2 对于最终成品的检查 项目的需求规格说明书 软件返工/维护的文档 升级后的技术文档 被更改的源程序 测试计划

用户手册（包括在线帮助） 9.3 测试人员在正式评审中的角色 缓和剂（SQA） 读者 记录者 作者 检测员

9.4 正式评审发现的缺陷应包含的信息 起因 类型 分类 级别

92

企业应用软件测试实训课程

9.5 评审流程 计划和组织 通篇的讲解（可选） 个人准备 评审会议 修订和反复

第七章 单元测试 一、单元测试概述

单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。一个软件单元的正确性是相对于该单元的规约而言的。因此，单元测试以被测试单位的规约为基准。单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。

单元—可编译的最小模块。一个单元通常是一个程序员的工作（至少在理论上如此）。如定义所述，单元不包含任何被调用的子模块（面向过程的语言）或者通信模块。

在单元测试中，被调用模块（或者通信模块）被替换成桩模块（stubs），模拟（simulators）模块或者可信任模块。调用模块则被替换成驱动模块，或者可信任的上层模块。程序单元处于隔离的状态。 模块 ：一个单元是一个模块，一个或多个模块集成在一起还是一个模块。

注意：这里用了“一个或多个”，而不是“两个或多个”。 这是因为考虑到那些递归的调用自己的模块。

模块测试 ：如果单元测试中的相关模块没有被替换成桩和模拟模块，那就是模块测试。 两个模块（实际上是一个或多个）在满足下列条件时我们说它们被集成在一起： a. 它们已经被编译，链接和装载到一起。

b. 它们已经通过了在二者之间的接口进行的集成测试。

在具体实现时，单元测试也可能对应的是多个程序文件中的一组函数。单元测试的目的可以归纳为如下几方面：

1)发现被测试模块在接受非预期输入时的健壮性问题; 2)发现被测试模块的效率问题; 3)发现被测试模块的资源使用情况;

因为单元测试需要窥探到被测试模块的内部实现，所以单元测试的主要方法是白盒测试，但同时在

93

企业应用软件测试实训课程

设计测试用例时也需要借鉴黑盒测试的思想和方法。

单元测试也是程序员的一项基本职责，程序员必须对自己所编写的代码保持认真负责的态度，这是也程序员的基本职业素质之一。同时单元测试能力也是程序员的一项基本能力，能力的高低直接影响到程序员的工作效率与软件的质量。

在编码的过程中作单元测试，其花费是最小的，而回报却特别优厚的。在编码的过程中考虑测试问题，得到的将是更优质的代码，因为在这时您对代码应该做些什么了解得最清楚。如果不这样做，而是一直等到某个模块崩溃了，到那时您可能已经忘记了代码是怎样工作的。即使是在强大的工作压力下，还必须重新把它弄清楚，这又要花费许多时间。进一步说，这样做出的更正往往不会那么彻底，可能更脆弱，因为新的理解可能不那么完全。

通常合格的代码应该具备以下性质：正确性、清晰性、规范性、一致性、高效性等（根据优先级别排序）。

1. 正确性是指代码逻辑必须正确，能够实现预期的功能。 2. 清晰性是指代码必须简明、易懂，注释准确没有歧义。

3. 规范性是指代码必须符合企业或部门所定义的共同规范包括命名规则，代码风格等等。 4. 一致性是指代码必须在命名上（如：相同功能的变量尽量采用相同的标示符）、风格上都保持统一。

5. 高效性是指代码不但要满足以上性质，而且需要尽可能降低代码的执行时间。 二、单元测试的目标

单元测试要达到的目标，总体来说就是保证单元内部的处理是正确的、没有遗漏和多余功能。细分而言，单元测试要达到以下几个目标： （1）信息能否正确地流入和流出单元。

（2）在单元工作过程中，其内部数据能否保持其完整性，包括内部数据的形式、内容及相互关系不发 生错误，也包括全局变量在单元中的处理和影响。 （3）在为数据加工而设置的边界处，能否正确工作。 （4）单元的运行能否做到满足特定的逻辑覆盖。 （5）单元中发生了错误，其中的出错处理措施是否有效。

三、单元测试的重要性

单元测试被公认为软件开发过程中的一个关键步骤。它能够简化错误检测过程，将错误被发现的时间提前到代码编写阶段，从而节省开发时间，降低开发成本，同时提高软件质量。

94

企业应用软件测试实训课程

说他能简化代码的错误检测，是因为软件在开发过程中，会渐渐的被一层层包装起来，特别是对于单元测试所面向的对象（函数、过程、代码集）来说，更是被包装在最里层。函数被封装在类中，类的实例又作为对象封装在其他的模块中。这样一来，存在于单元测试对象（函数、过程、代码集）中的问题或者错误，要想在后期的应用测试上被发现出来，那就相当困难了，即使这种错误被发现出来，定位错误的位置也会是一项困难的工作；因为需要支撑更多相关模块的同时运行和调试，就需要构建更为复杂的测试环境，同时层层跟踪，像剥洋葱皮一样去伪存真，最后只有在深入到存在问题的模块（函数、过程、代码集）的内部后，才能把错误的位置确定。这个图显示了一个包含许多对象的应用的测试模型。大椭圆表示应用，小椭圆表示对象，箭头表示用户输入，红星表示潜在的错误。

上述过程明显浪费了我们很多宝贵的时间和精力。单元测试正是在模块被包装起来之前进行测试。如下图：

单独测试一个模块时，由于这个模块已经与其它对象分离，所以一旦发现错误，就能很快地定位到错误的位置。这使得这个测试过程变得容易多了。这种发现模块错误的方法，在改善应用程序质量的同时大量削减开发时间和成本。首先，由于能够

更容易地找到错误，就会减少发现它们的时间和资源。其次，编写完成一个模块后，就能发现和改正其中的错误，以免在以后花费更多时间重新了解和摸索。

众所周知，越迟发现问题，通常就要修改越多的代码。当修改的代码量增加时，两个其它因素也会随之增加：

➢ 修改每一个错误所需的时间和费用。 ➢ 在代码中引入新的错误的机会。

研究证明，随着问题被检测出来的时间的推迟，发现软件错误所需的时间和成本会惊人地增加。请看下面的研究结果：

➢ IBM：根据IBM的一份内部资料指出，确定软件错误的相对成本是：在设计阶段，1.5；编码前，

1；编码中，1.5；测试前，10；测试中，60；交付后，100。[Watts Humphrey]

➢ TRW：确定错误的相对时间：需求分析阶段，1；设计阶段，3-6；编码阶段，10；开发测试阶

段，15-40；接受性测试阶段，30-70；应用运行中，40-1000。[Boehm]

➢ IBM：确定错误的相对时间：设计评审，1；代码检查，20；测试，82。[Remus]

➢ JPL：Bush得出的每个错误的平均成本：编码，US$90-US$120；测试，US$10,000。[Bush] ➢ Freedman and Weinberg：使用设计评审和代码检查手段的项目在测试时发现错误的数量会减少

10倍，测试成本降低50%-8%，包括评审和检查的成本。[Freedman]

在我们日常使用软件时就可以看到，在软件发布到用户手中之后，如果发现问题，需要采用各种方法给用户升级版本，或者安装补丁包。这个成本远远高于代码编写中的测试成本。甚至会丧失商业信誉或者进行违约赔偿，这种间接成本就更难估量了。

95

企业应用软件测试实训课程

三、单元测试的任务

单元测试的对象是软件设计的最小单位——模块。单元测试的依据是详细设计说明。单元测试应对模块内所有重要的控制路径设计测试用例，以便发现模块内部的错误。单元测试由程序员而非测试员来做，因为它需要知道内部程序设计和编码的细节知识。系统内多个模块可以并行地进行测试。 包括：（1） 模块接口测试；（2） 模块局部数据结构测试；（3） 模块边界条件测试；（4） 模块中所有执行通路测试；（5） 模块的各条错误处理通路测试。

模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下，其他测试才有意义。测试接口正确与否应该考虑下列因素： 1 输入的实际参数与形式参数的个数是否相同； 2 输入的实际参数与形式参数的属性是否匹配； 3 输入的实际参数与形式参数的量纲是否一致；

4 调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同； 5 调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配； 6调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致； 7 调用预定义函数时所用参数的个数、属性和次序是否正确； 8 是否存在与当前入口点无关的参数引用； 9 是否修改了只读型参数；

10 对全程变量的定义各模块是否一致； 11是否把某些约束作为参数传递。

如果模块内包括外部输入输出，还应该考虑下列因素： 1 文件属性是否正确；

2 OPEN/CLOSE语句是否正确； 3 格式说明与输入输出语句是否匹配； 4缓冲区大小与记录长度是否匹配； 5文件使用前是否已经打开； 6是否处理了文件尾； 7是否处理了输入/输出错误； 8输出信息中是否有文字性错误；

检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确。局部数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误： 1 不合适或不相容的类型说明； 2变量无初值；

3变量初始化或省缺值有错；

4不正确的变量名（拼错或不正确地截断）； 5出现上溢、下溢和地址异常。

96

企业应用软件测试实训课程

除了局部数据结构外，如果可能，单元测试时还应该查清全局数据对模块的影响。

在模块中应对每一条执行路径进行测试，单元测试的基本任务是保证模块中每条语句至少执行一次。此时设计测试用例是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。此时基本路径测试和循环测试是最常用且最有效的测试技术。计算中常见的错误包括： 1 误解或用错了算符优先级； 2混合类型运算； 3变量初值错； 4精度不够； 5表达式符号错。

比较判断与控制流常常紧密相关，测试用例还应致力于发现下列错误： 1不同数据类型的对象之间进行比较； 2错误地使用逻辑运算符或优先级；

3因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等； 4比较运算或变量出错； 5循环终止条件或不可能出现； 6迭代发散时不能退出； 7错误地修改了循环变量。

一个好的设计应能预见各种出错条件，并预设各种出错处理通路，出错处理通路同样需要认真测试，测试应着重检查下列问题： 1输出的出错信息难以理解；

2记录的错误与实际遇到的错误不相符；

3在程序自定义的出错处理段运行之前，系统已介入； 4异常处理不当；

5错误陈述中未能提供足够的定位出错信息。

边界条件测试是单元测试中最后，也是最重要的一项任务。众的周知，软件经常在边界上失效，采用边界值分析技术，针对边界值及其左、右设计测试用例，很有可能发现新的错误。 四、单元测试过程

一般认为单元测试应紧接在编码之后，当源程序编制完成并通过复审和编译检查，便可开始单元测试。测试用例的设计应与复审工作相结合，根据设计信息选取测试数据，将增大发现上述各类错误的可能性。在确定测试用例的同时，应给出期望结果。

应为测试模块开发一个驱动模块（driver）和（或）若干个桩模块（stub）,驱动模块在大多数场合称为“主程序”，它接收测试数据并将这些数据传递到被测试模块，被测试模块被调用后，“主程序”打印“进入-退出”消息。

驱动模块和桩模块是测试使用的软件，而不是软件产品的组成部分，但它需要一定的开发费用。若驱动和桩模块比较简单，实际开销相对低些。遗憾的是，仅用简单的驱动模块和桩模块不能完成某些模块的测试任务，这些模块的单元测试只能采用下面讨论的综合测试方法。

97

企业应用软件测试实训课程

提高模块的内聚度可简化单元测试，如果每个模块只能完成一个，所需测试用例数目将显著减少，模块中的错误也更容易发现。

单元测试过程分为计划、设计、实现、执行、评估等几个步骤，各步骤的任务如下： 4.1. 计划

单元测试计划需明确如下目标：

（1）明确单元测试的测试对象，确定测试需求及测试通过的标准，明确活动的输出。 （2）明确测试方法和需要运行的工具需求。

（3）对工作量进行估计，确定测试所用资源（包括人力资源和设备资源），创建测试任务的时间表，必要时需将一个单元测试任务分解成更细化的子任务进行明确。 （4）对测试风险进行分析，制定相应的应急措施。 （5）明确测试优先级，制定测试取舍策略。 （6）输出单元测试计划文档。 4.2. 设计

单元测试的设计主要是完成方案和模型的确认，包括如下几方面内容：

（1）测试需求的进一步细化，必要时需追溯到详细设计文档中的单元设计目标。 （2）设计单元测试模型，包括与模型相关的工具的选用。

（3）制定测试方案，包括模型的设计和实现、定义测试规程和用例的实现和组织。 （4）输出单元测试方案文档。 4.3. 实现

单元测试实现主要是针对用例的实现，包括如下几个方面：

（1）参考测试模型和测试方案，制定具体的测试用例，创建可重用的测试脚本。 （2）输出单元用例文档。 4.4. 执行

根据单元测试的方案、用例对单元进行测试，验证测试的结果并记录测试过程中出现的缺陷，主要保留执行过程数据以备问题定位的回归对比。 4.5. 评估

对单元测试的结果进行评估，主要有如下几个方面：

（1）实际测试过程的记录，描述与计划的差异和原因，包括补充或裁剪的测试项目清单。 （2）对测试过程完备性以及被测单元质量的评价，包括用例执行情况清单和汇总分析。

98

企业应用软件测试实训课程

（3）主要从需求覆盖和代码覆盖的角度进行测试完备性的评估。 （4）遗留问题记录和可能的分析。 （5）输出单元测试报告。 五、单元测试方法

单元测试的方法一般分为两类：白盒方法和黑盒方法。

白盒方法通常是分析单元内部结构后通过对单元输入输出的用例构造，达到单元内程序路径的最大覆盖，尽量保证单元内部程序运行路径处理正确，它侧重于单元内部结构的测试，依赖于对单元实施情况的了解。

黑盒方法通过对单元输入输出的用例构造验证单元的特性和行为，侧重于核实单元的可观测行为和功能，并不依赖于对单元实施情况的了解。

单元测试既可以是白盒测试也可以是黑盒测试。白盒测试主要是检查程序的内部结构、逻辑、循环和路径。其常用测试用例设计方法有：逻辑覆盖和基本路径测试。根据覆盖测试的目标不同，逻辑覆盖又可分为：语句覆盖，判定覆盖，判定－条件覆盖，条件组合覆盖及路径覆盖等。白盒测试用例设计还可用到：状态转移测试、数据定义－使用测试、等价类划分、边界值分析等。黑盒测试注重对程序功能方面的要求，它只用到程序的规格说明，没有用到程序的内部结构。其常用测试用例方法有：规范（规格）导出、等价类划分、边界值分析法、错误推测法和因果图分析方法。 进行单元测试必须综合使用上述两个方法，否则，单元测试很可能就是不成功、不完整和不彻底的。 5.1静态分析（Static Analysis）

静态分析主要在编写规范上发现代码的编写问题，从而避免由编写不规范而引发的问题。 1． 进入条件：源代码无错误地通过编译。 2． 分析目标：

表6-1: 静态分析目标

分析对象 数据类型 具体要求 分析代码中使用的数据类型，包括自定义的数据类型，检查源代码中使用的数据类型与设计要求的一致情况。 变量引用 使用变量定义与引用表，检查源代码中变量引用的异常情况，比如变量在赋值前被引用，或变量在赋值后没有被引用。 表达式 分析表达式中的一些错误，比如：括号使用不正确，数组队列下标越界，除数为零，负数开方，浮点数计算的误差。 接口 检查接口中的错误。比如：调用时的实参与形参的一致性。输入/输出接口，软件单元的扇入、扇出（调用关系树）等。模块调用拉了几个下层模块数叫扇出数，模块被99

企业应用软件测试实训课程

几个上层模块调用叫扇入数，一般<7，最大为9，（扇入数*扇出数）*（扇入数*扇出数）=接口复杂度。 循环、递归结构 异常处理 软件单元圈复杂度 软件单元规模 代码注释 5.2动态分析

指在程序的运行过程中检查代码，这个过程是单元测试中最重要的过程，也是用来发现程序错误的主要测试过程。

5.2.1动态分析的环境构建

同集成测试的环境构建类似，为了使被测代码可运行，也要创建两种辅助模块：一种是驱动模块（driver），用以模拟被测模块的上级模块（调用被测试模块）。另一种是桩模块（stub），用以模拟被测环境工作中待测模块所调用的对象，见下图：

图: 桩和驱动示意图

驱动模块的功能是能够建立程序运行环境，同时给被测试模块提供必要的参数输入；桩模块是用来供被测试模块调用的模拟对象，它要保证设计的尽量简单，不能引入错误，并且在被测试模块调用这些桩模块后，可以获得可能的各种返回值，同时回到被测试模块的正常过程中。为便于定位错误，驱动模块和桩模块在设计时都可以加入输出错误信息的功能。错误信息可以有多种方式输出，如控制台信息，log文件，弹出信息对话框等。

下面详细讨论一下这两种辅助模块。为了避免受到编程细节对我们讨论测试理论的影响，我们就使用最简单的C++控制台（Console）程序为例。

桩1 桩2 ... 桩n 被测模块 驱动模块 一个函数的行数大约60-200行 注释大约25%-30%，有头注释。分支处有注释 检查循环或递归结构的退出条件是否一定能够达到，或者在某种情况下是否可能失效 检查是否在可能出现异常的地方进行了异常捕捉 圈复杂度<10 100

企业应用软件测试实训课程

假设有一个C++的待测函数 例一：

// 将指定字符转换为小写

char my_tolower(char c) { }

对于这个函数的测试，我们可以使用控制台程序的main函数作为驱动模块，这样不仅程序可以运行起来，我们还可以在main函数中调用被测函数，使其得到执行：

#include int main(int argc, char* argv[]) { }

我们根据设计阶段对my_tolower函数的设计要求，可以设计各种参数输入情况，反复的运行程序进行测试，检验输出结果，进而判断被测函数是否满足设计要求。针对于输入参数的测试用例设计问题，我们会在下一节动态分析的测试用例设计中详细描述。

上面例子中演示了最简单的输入输出环境，而这仅仅是最基本的情况，实际的工作中遇到的问题，远比这复杂得多。对于被测试模块来说，除参数输入外，还存在很多其他情况的“输入”。比如一个数据库程序的输入，可能是特定数据表中的数据；文件数据、图形图像数据、音频视频输入，都可作为被测模块的“输入参数”；甚至对于多线程程序来说，一个线程同步对象（信号量、事件）也是一种“输入参数”。

总的说来，对被测模块可以起到影响的前提条件，都可以看作是输入参数。我们在单元测试中最重要的工作就是为被测模块创造这个环境，针对这些“输入参数”设计测试用例，并且观察测试结果。 桩模块，就是那些被我们的待测模块调用的对象，我们稍微修改一下上面的my_tolower函数：

char my_tolower(char c) { return 0; // 调用被测函数 printf(“%c\\n”,my_tolower(‘T’)); return (c >= 65 && c <= 90) ? c + 32 : c; 101

企业应用软件测试实训课程

}

return (my_isupper(c)) ? c + 32 : c; 我们在这个函数中调用了另一个函数my_isupper来判断输入的字符是否为大写字符，在这种情况下，要测试my_tolower，就要我们来提供my_isupper的定义，my_isupper就是这个测试环境中的桩。这个桩的设计可以是这样：

bool my_isupper(char c) { }

桩模块的设计要保证简洁和正确，不能引入错误。对于my_isupper函数，就要求对是否为大写的判断必须准确，如果这里判断错误，将直接导致my_tolower的功能出现错误。和my_tolower的测试一样，真正的my_isupper函数，也必须经过这样的测试才能在最后发布的软件中使用。

驱动模块和桩模块的开发工作由于不是包含在和最后的软件产品一起来提交，所以这部分的工作很多时候就成为开发的“累赘”，构件单元测试的测试环境也会耗费一定的开发时间，这也是为什么很多的软件公司的单元测试开展比较少的缘故。 5.2.2动态分析的测试用例设计

上一节介绍了如何构建单元测试环境。构建测试环境的过程就像是为一个化学试验准备试管、天平、过滤等装置，并将他们组装起来的过程。做完这些准备工作，目的是按照计划完成试验，并记录试验结果。

在上一节构建的测试环境的基础上，能否高效（在更短的时间内发现更多问题）的进行下一步的测试工作，设计好的测试用例非常重要。

确定测试用例之所以很重要，原因有以下几方面： （1）测试用例构成了设计和制定测试过程的基础。

（2）测试的“深度”与测试用例的数量成比例。由于每个测试用例反映不同的场景、条件或经由产品的事件流，因而，随着测试用例数量的增加，对产品质量和测试流程也就越有信心。判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这又是以确定、实施和/或执行的测试用例的数量为依据的。

（3）测试工作量与测试用例的数量成比例。根据全面且细化的测试用例，可以更准确地估计测试周期各连续阶段的时间安排。

（5）测试设计和开发的类型以及所需的资源主要都受控于测试用例。

测试用例通常根据它们所关联关系的测试类型或测试需求来分类，而且将随类型和需求进行相应地

102

return c >= 65 && c <= 90; 企业应用软件测试实训课程

改变。最佳方案是为每个测试需求至少编制两个测试用例：

（1）一个测试用例用于证明该需求已经满足，通常称作正面测试用例。

（2）另一个测试用例反映某个无法接受、反常或意外的条件或数据，用于论证只有在所需条件下才能够满足该需求，这个测试用例称作负面测试用例。 第八章 集成测试 一、集成测试的概述

集成测试：是将模块按照设计要求组装起来进行测试，主要目标是发现与接口有关的问题，由于在产品提交到测试部门前，产品开发小组都要进行联合调试，所以大部分企业是由开发人员来完成集成测试的，但也可以到了测试部门后再次进行集成测试。主要测试模块之间数据传输是否正确、模块集成后的功能是否实现、模块接口功能与设计需求是否一致。集成测试紧接在单元测试之后，当单元测试通过后，便可开始配置集成测试环境。集成测试是最关键的一步，如果问题较多就把产品送到测试部，会造成反复测试，从而浪费人力、物力资源，延误了工期。

集成测试是一个应用系统的各个部件的联合测试，以决定他们能否在一起共同工作。部件可以是代码块、的应用、网络上的客户端或服务器端程序。这种类型的测试尤其与客户服务器和分布式系统有关。

时常有这样的情况发生，每个模块都能单独工作，但这些模块集成在一起之后却不能正常工作。主要原因是，模块相互调用时接口会引入许多新问题。集成测试是组装软件的系统测试技术，按设计要求把通过单元测试的各个模块组装在一起之后，进行集成测试以便发现与接口有关的各种错误。 1.1定义

集成测试也叫做组装测试、联合测试、子系统测试或部件测试。它是在单元测试的基础上，将所有模块按照设计要求组装成为系统时的测试活动。集成测试就是探寻导致模块交互错误的模块错误。 系统是由构件组成，软件构件是可以在任何物理范围内定义。根据不同的软件构件（构件在本文和模块的意思是一样的）的定义（即集成测试的粒度的定义）也就确定了集成的范围。如下表：

表： 集成测试粒度定义表

构件（集成的焦点） 系统（集成的范围） 方法 类 典型的构件间的接口（集成故障的位置） 实例变量 类内消息 类 簇 簇 子系统 类间消息 类间消息 包间消息 103

企业应用软件测试实训课程

子系统 系统 进程间通信 远程过程调用 ORB服务 OS服务 1.2集成测试故障：

➢ 配置/版本控制问题。 ➢ 遗漏、重叠或冲突的函数。

➢ 文件或数据库使用不正确的或不一致的数据结构。 ➢ 文件或数据库使用冲突的数据视图/用法。 ➢ 破坏全局存储或数据库的数据完整性。

➢ 由于编码错误或未预料到的运行时绑定导致的错误方法调用。 ➢ 客户发送违反服务器前提条件的消息。 ➢ 客户发送违反服务器的顺序约束的消息。 ➢ 错误的对象和消息的绑定（多态目标）。 ➢ 错误参数或不正确的参数值。

➢ 由不正确的内存管理分配/回收引起的失败。 ➢ 不正确的使用虚拟机、ORB或OS服务。

➢ IUT试图使用目标环境的服务，而该服务对目标环境的指定版本已经过时或不向上兼容。 ➢ IUT试图使用目标环境的新服务，而该目标环境的当前版本不支持该服务。 ➢ 构件之间冲突，例如当进程Y运行时，线程X就会崩溃。

➢ 资源竞争：目标环境不能分配象征性装载所需要的资源，例如：一个用例可能打开6个窗口，但是IUT在打开5个以后就崩溃了。

注：IUT指被测试的代码，也称为被测实现。 1.3集成测试的内容：

➢ 在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失； ➢ 一个模块的功能是否会对另一个模块的功能产生不利的影响； ➢ 各个子功能组合起来，能否达到预期要求的父功能； ➢ 全局数据结构是否有问题；

104

企业应用软件测试实训课程

➢ 单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。

集成测试有时也要构造桩（STUB）和驱动（DRIVER），这里的桩和驱动的概念与单元测试中的桩和驱动的概念是一致的。

在第一章中我们谈到V模型，集成测试在V模型中是和软件开发的概要设计阶段向对应的。概要设计中关于整个系统的体系结构是集成测试的输入基础。体系结构是把一个大的系统组织成可以管理和实现的组件或子系统得架构。如图所示：

产品 子系统1 子系统2 软件模块1

软件模块2 软件模块1 软件模块2 图7-1 系统结构图 软件模块1 软件程序1 软件程序2 单元1

单元2 单元3 单元2 单元4 单元5 图7-2 软件模块结构图

集成测试与概要设计之间具有相互的依赖性。如果概要设计不明确，架构设计不完整，集成测试将无法进行。同样集成测试也能够反映概要设计中的错误，遗漏和二义性问题，包括前期的验证活动和后期的确认测试。 二、集成测试的策略和方法 2.1集成测试的策略

一个产品在开发过程中包括了一个层次的设计和逐步细化的过程，从最初的产品到最小的单元，层次结构基本如7-1，7-2所示。一般而言单元测试是对最底层的叶子节点的测试过程，而确认测试是对产品级别的测试，其中的各个层次都可以作为集成测试的对象。根据测试粒度划分的不同，可以

105

企业应用软件测试实训课程

把集成测试划分为3个等级：

➢ 模块内集成测试 ➢ 子系统内集成测试 ➢ 系统间集成测试

虽然不同的测试粒度所关注的焦点有所差别，但是对于每一个集成测试必须回答三个问题：

➢ 哪些节点是集成测试的重点？

➢ 节点接口应该以什么样的顺序进行检测？ ➢ 应该使用哪种测试设计技术检测每个接口？ 2.2集成测试的方法

集成测试检查这些接口通常有两种不同的方法，非增式测试和增式测试。

①非增式测试：在配备辅助模块的条件下，对所有模块进行个别的单元测试。然后在此基础上，按程序结构图将各模块联接起来，把联接后的程序当作一个整体进行测试。典型的测试方法有大爆炸集成测试。非增式测试的做法是先分散测试，再集中起来一次完成集成测试。如果在模块的接口处存在错误，只会在最后的集成时一下子暴露出来，便于找出问题和修改。其次，非增式测试使用了较少的辅助模块，也就减少了辅助性测试工作。并且一些模块在逐步集成的测试中，得到了较为频繁的考验，因而可能取得较好的测试效果。

②增式测试：它的集成是逐步实现的。主要有两种实施顺序：

自顶向下增式测试表示逐步集成和逐步测试是按结构图自上而下进行的。 自底向上增式测试表示逐步集成和逐步测试是按结构图自下而上进行的。 下面主要介绍两种方法，其他方法只做简单的介绍。 2.2.1自顶向下集成

1． 以主控模块作为测试驱动模块，把对主控模块进行单元测试时引入的所有桩模块用实际模块替代；

2．依据所选的集成策略（深度优先或广度优先），每次只替代一个桩模块；

3． 每集成一个模块立即测试一遍；

4． 只有每组测试完成后，才着手替换下一个桩模块；

5． 为避免引入新错误，须不断地进行回归测试（即全部或部分地重复已做过的测试）。

106

企业应用软件测试实训课程

图：自顶向下集成

从第二步开始，循环执行上述步骤，直至整个程序结构构造完毕。上图中，实线表示已部分完成的结构，若采用深度优先策略，下一步将用模块M7替换桩模块S7，当然M7本身可能又带有桩模块，随后将被对应的实际模块一一替代。

自顶向下集成的优点在于能尽早地对程序的主要控制和决策机制进行检验，因此较早地发现错误。缺点是在测试较高层模块时，低层处理采用桩模块替代，不能反映真实情况，重要数据不能及时回送到上层模块，因此测试并不充分。解决这个问题有几种办法，第一种是把某些测试推迟到用真实模块替代桩模块之后进行，第二种是开发能模拟真实模块的桩模块；第三种是自底向上集成模块。第一种方法又回退为非增量式的集成方法，使错误难于定位和纠正，并且失去了在组装模块时进行一些特定测试的可能性；第二种方法无疑要大大增加开销；第三种方法比较切实可行. 2.2.2自底向上集成

自底向上测试是从“原子”模块（即软件结构最低层的模块）开始组装测试，因测试到较高层模块时，所需的下层模块功能均已具备，所以不再需要桩模块。 自底向上综合测试的步骤分为：

1． 把低层模块组织成实现某个子功能的模块群（cluster）； 2． 开发一个测试驱动模块，控制测试数据的输入和测试结果的输出； 3． 对每个模块群进行测试； 4． 删除测试使用的驱动模块，用较高层模块把模块群组织成为完成更大功能的新模块群。

从第一步开始循环执行上述各步骤，直至整个程序构造完毕。

下图说明了上述过程。首先“原子”模块被分为三个模块群，每个模块群引入一个驱动模块进行测试。因模块群1、模块群2中的模块均隶属于模块Ma因此在驱动模块D1、D2去掉后，模块群1与模块群2直接与Ma接口，这时可对MaD3被去掉后，M3与模块群3直接接口，可对Mb进行集成测试，最后Ma、Mb和 Mc全部集成在一起进行测试。

107

企业应用软件测试实训课程

图：自底向上集成

自底向上集成方法不用桩模块，测试用例的设计亦相对简单，但缺点是程序最后一个模块加入时才具有整体形象。它与自顶向综合测试方法优缺点正好相反。因此，在测试软件系统时，应根据软件的特点和工程的进度，选用适当的测试策略，有时混和使用两种策略更为有效，上层模块用自顶向下的方法，下层模块用自底向上的方法。

由上面的介绍可以看出，自顶向下测试的主要优点在于它可以自然地做到逐步求精，一开始便能让测试者看到系统的雏形。这个系统模型的检验有助于增强程序人员的信心，它的不足是一定要提供桩模块。并且在输入、输出模块接入系统以前，在桩模块中表示测试数据有一定困难。由于桩模块不能模拟数据，如果模块间的数据流不能构成有向的非环状图，一些模块的测试数据难于生成。同时观察和解释测试输出往往也是困难的。另一方面，自底向上测试的优点在于，由于驱动模块模拟了所有调用参数，即使数据流并未构成有向的非环状图，生成测试数据也没有困难。如果关键的模块是在结构图的底部，自底向上测试是有优越性的。自底向上方法的缺点在于，当最后一个模块尚未开始测试时，还没有呈现出被测软件系统的雏形。由于最后一层模块尚未设计完成时，无法开始测试工作，因而设计与测试工作不能交叉进行。 2.2.3其它集成样式

➢ 大爆炸集成：是通过少数测试运行检测整个系统来论证系统的稳定性。大爆炸集成将所有的模块集合在被测系统之中，而不考虑构件之间的相依性或风险。应用一个系统范围的测试包以证明最低限度的可操作性。

➢ 协作集成：通过向被测试系统中加入模块的集合证明稳定性，该集成被要求支持一个特定的协作。协作中包括的模块按照在一个处理线程、一个事件-响应路径或关键性能目标中的隶属关系来选择。如果不存在协作上的顺序约束，系统范围责任的测试包应该使用协作集成或往返场景测试。

➢ 基干集成：结合了自顶向下集成、自底向上集成和大爆炸集成的元素，以验证紧密耦合的子系统之间的互操作性。测试设计问题是首先识别支持应用控制的模块、基干和应用子系统，测试的顺序也是基于这个分析。

➢ 层次集成：层次集成使用增量式的方法验证一个层次体系结构中的稳定性。层次集成结合了自顶向下集成和自底向上集成的元素。测试设计必须识别层次并确定对每个层应用哪种集成方法。

➢ 客户服务器集成：论证客户和服务器之间交互的稳定性。从单独测试客户和服务器开始，然后在范围内使用受控增加直到所有接口被测试。测试方案必须识别客户和服务器。客户/服务器交互可以用任意适合的测试设计样式建模。扩充式用例测试和往返场景测试都适用。对双重星型网络，基本的集成策略是检测客户-服务器对。在三重星型网络中，我们检测客户-服务器和服务器-服务器配置，随后是客户-服务器-服务器配置。

➢ 分布服务集成：论证松散耦合的同等模块之间的交互的稳定性。从单独测试一些结点开始，然后在范围内使用受控增加，直到所有接口被测试。集成测试一个分布式系统关心的是验证远程主机之间的接口是最低限度可操作的。寻找一个测试包，它给一个分布式系统的聚合行为以

108

企业应用软件测试实训课程

充分的可信度，是一个更加困难的问题。

➢ 高频集成：频繁地将新代码和一个已经稳定化的基线集成在一起，以免集成故障不能被发现，以及防止运行的、稳定化的基线的偏差。测试可以使用任意适合的系统范围的测试样式来开发：协作集成、往返场景测试等。 三、集成测试工作 3.2集成测试过程 1）集成测试计划阶段 2）集成测试设计阶段 3）集成测试的执行 4）集成测试的总结 第九章 确认测试

确认测试又叫有效性测试.它的任务是检查软件的功能与性能是否与需求规格说明书中确定的指标相符合。确认测试阶段有两项工作：进行确认测试与软件配置审查；

(1)确认测试一般是在模拟环境下运行黑盒测试方法，由专门测试人员和用户参加的测试； (2)软件配置审查的任务是检查软件的所有文档资料的完整性，正确性。如果发现遗漏和错误，应补充和改正.同时要编排好目录，为以后的软件维护工作奠定基础。 一、确认测试概述

确认测试是软件测试各个阶段中重要的一个测试阶段。在实际工作中我们可能因为各种因素做出裁减某些测试阶段的决定，然而确认测试却是无法被裁减的，原因何在？让我们了解一下关于确认和确认测试的定义。

确认：是指在软件开发过程结束时对软件进行评价，以确定它是否和软件需求相一致的过程。 在软件产品开发完成以后，为了对它在功能、性能、接口以及条件等方面是否满足需求做出切实的评价，需要在开发的初期，在软件需求规格说明书中明确地规定确认的标准。

确认测试：又称为有效性测试。它的任务是验证软件的功能和性能及其他特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明书中已经明确规定。

从定义中可以看出，确认测试的目的是保证开发出来的软件确实符合客户需求，是客户所真实需要的产品。一个软件无论规模大小、难度高低、质量好坏，终归是开发出来完成某种功能，达成客户某种需求的。如果这个目的没有达到，那么这个软件的存在就是毫无意义的。

当我们向客户交付产品时，客户一定会提出这样的问题：这个软件可以完成我要它做的事吗？ 在开发过程中，我们的需求人员已经把客户的需求转化为需求规格说明，然后产生了各种设计文档，在此基础上编码人员完成了编码工作，最后诞生了软件产品。那么这个软件产品是否就是需求规格

109

企业应用软件测试实训课程

说明中描述的东西？是否是客户脑海中的想象的真实表现？我们的确认测试人员将进行确认测试来回答这个问题。

质量工程的意义是：用正确的方法做正确的事。确认测试的意义就是通过测试活动了解这个产品是否是正确的产品。 确认测试的开始与结束： 确认测试作为一个如此重要的测试阶段，我们应当在何时进行呢？

确认/系统测试报告 需求分析 确认/系统测试 确认/系统测试计划（说明） 可以用V模型的示意图清晰的表现这个问题的答案。

图： V模型示意

图

如图所示，确认测试的活动几乎贯穿了软件开发测试的全过程。它开

始于项目初期的需求分析阶段，而终止于项目末期，确认测试的测试执行是在完成了单元测试和集成测试阶段后进行的。这里的测试活动采用的是广义的测试定义，即不单纯指为了发现错误而执行程序的过程本身，而是指从需求分析阶段就开始的一系列复查、评估与检验活动。作为一个确认测试人员，必须在项目初期需求分析阶段就加入项目进行各种活动，开始编写确认测试计划与确认测试说明等文档。

确认测试的核心仍然是软件需求，是围绕着对于需求的一系列验证活动。确认测试工程师需要根据软件需求分析阶段的规格说明设计一批测试用例，并利用这些测试用例去运行程序，以发现程序与需求之间的偏差与错误的过程。其确认测试具体执行的时间点可以说是位于集成测试之后，确认测试实际上是根据需求规格说明书进行的动态黑盒测试。

如果用h模型来表示，确认测试的测试准备活动开始的最早，而测试执行活动却相对很晚。 说明: 测试流程大致分为两类活动，一类是测试准备活动，包括测试需求分析、测试计划、测试用例设计与实现、测试环境准备、培训学习等等，另一类是测试执行活动，包括测试实施、BUG提交与验证等等

二、确认测试策略与方法 2.1确认测试的策略

确认测试的策略需要确认以下内容：

➢ 确认测试的具体内容和优先级分布,也就是测试重点布局；

集成测试报告 概要设计 集成测试计划（说明） 详细设计 单元测试计划（说明） 编码 集成测试 单元测试报告 单元测试 110

企业应用软件测试实训课程

➢ 确认测试采用的测试方法； ➢ 确认测试实施的顺序； ➢ 确认测试环境的应用策略。

确认测试包括哪些活动,产生那些工作产品呢? ➢ 确认测试活动→工作产品清单 ➢ 编写确认测试计划 →确认测试计划

➢ 编写确认测试说明,设计确认测试用例 →确认测试说明(含确认测试用例) ➢ 确认测试说明同行评审 ➢ 准备确认测试环境 ➢ 执行确认测试用例

➢ BUG提交与验证 →确认测试状态报告(可选) ➢ 编写确认测试报告 →确认测试报告 2.2确认测试采用的技术

在确认测试阶段，我们所依据的输入文档是需求规格说明，我们所检查验证的对象也是产品对于需求的满足程度，对于产品内部的逻辑结构和内部特性测试人员是不了解也不关心的。也就是把测试对象看作一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。

因此确认测试采用黑盒测试技术. 主要的测试方法也就是黑盒测试的各种方法. 黑盒测试包括以下一些内容:

➢ 根据需求规格说明，检查是否有不正确或遗漏了的功能？是否忽略了用户的隐含需求？ ➢ 在软件外部接口上，输入能否正确地接受？能否输出正确的结果？ ➢ 是否有数据结构错误或外部信息（例如数据文件）访问错误？ ➢ 性能上是否能够满足要求？

➢ 易用性和其他功能特性是否能够得到满足？

➢ 是否有初始化或终止性缺陷？是否会出现用户不能接受的缺陷？

等价类划分、业务与逻辑分析、边界值分析、特殊数据分析，因果图、ALAC等测试方法是确认测试用例设计中最常见的设计方法。由于在前面的章节中已经做了十分详细的叙述，这里不再做过多重复，而是谈谈实际情况下各种测试方法的应用。

111

企业应用软件测试实训课程

等价类划分是最典型、最常用的黑盒测试方法。当产品中存在包含大量输入数据的输入域,采用测试每个输入数据的穷举测试是不现实的，因此需要在大量的可能数据中选取其中的一部分作为测试用例，即应用等价类划分方法。

等价类划分的方法是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据当作测试用例。具体划分为有效等价类和无效等价类：

有效等价类：是指对程序的需求规格是有意义的、合理的输入数据所构成的集合。在具体问题中，有效等价类可以是一个，也可以是多个。

无效等价类：无效等价类指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。一般来讲，无效等价类会有多个，对于输入数据较多的情况，无效等价类要比有效等价类的数量要多。 例如邮件类软件中的用户注册子窗口，需要输入用户名和密码，这个输入值必须遵循某些规则，比如用户名必须是6-14位字符序列，可以包含数字、英文字母、不包含操作符。针对这个命名规则依据等价类划分技术分解，可以得到一系列有效等价类和无效等价类的用户名与密码的取值，测试了这些取值的处理情况就代表测试了全部可能数据的处理情况。

边界值分析往往与等价类划分同时采用，弥补等价类划分的不足。当输入域是一段数值范围时，等价类划分只需在数值段内取一个值，但是实际上，程序对于位于边缘的数值处理发生错误的可能性更高。此时就需要增加取值，将该范围的边界内及刚刚超出范围的边界外的值，或是分别对最大、最小个数及稍小于最小、稍大于最大个数作为测试用例。

当软件的功能类型是对于各种输入产生相应的输出，采取等价类划分和边界值分析方法的结合来设计测试用例是比较合适的。

当软件包含了复杂的业务流程和逻辑控制的情况下，应当采用业务与逻辑分析设计用例。 如果软件运行流程和逻辑控制规模不是很大，采取因果图的思想来设计用例也是可以的。 因果图法测试用例选择步骤为：

➢ 分析程序规格说明的描述中，那些是原因，那些是结果。原因常常是输入条件或是输入条件的

等价类。而结果是输出条件。

➢ 分析程序规格说明中的描述中语义的内容，并将其表示成连接各个原因与各个结果的“因果图”。 ➢ 由于语法或环境的，有些原因和结果的组合情况是不可能出现的。为表明这些特定的情况，

在因果图上使用若干个特殊的符号标明约束条件。 ➢ 把因果图转换为判定表。

➢ 把判定表中每一列表示的情况写成测试用例。

在确认测试用例设计中，需要根据实际情况灵活选取和采用适当的测试方法，不能僵化和拘泥于理论上的东西，各种测试方法可以组合运用，甚至可以做适当的裁减、简化、和变形。 三、确认测试的其他有关内容

112

企业应用软件测试实训课程

为了在有限的资源下完成最有效率的测试，需要事先通过同行评审等沟通手段决定哪些产品功能点，哪些质量子特性需要测试，优先级如何，此部分由测试说明设计人员根据项目情况编写，其测试优先级和测试点需要项目LEADER，需求人员，开发人员参与评审并确定，测试结果在测试报告中填写。其简单例子如下：

产品功能（可以按需求优先级划分，并且经过项目组LEADER、需求人员评审） 表： 产品功能测试重点分布 测试内容 不需要测试 需要测试 测试结果(测试报告中填写此处) 相关BUG 及附件说明(测试报告中填写此处) 优先 安装与卸载 标准用户安装路径与卸载方式 工厂封装安装方式 自定义安装路径与卸载方式 非法安装操作的可恢复性 表： 质量特性——性能测试重点分布

测试内容 不需要测试 需要测试 优先 大数据量下操作的速度 流行硬件平台下，基本性能能否满足要求 表：质量特性——可靠性测试重点分布

测试内容 不需要测试 优先 其次 优 良 差 需要测试 测试结果 相关BUG 及附件说明   其次 测试结果 优 良 差 相关BUG 及附件说明     其次 优 良 差 113

企业应用软件测试实训课程

用户错误操作屏蔽 错误提示准确性 输入有效性检查 异常情况影响（网络中断/以外掉电等等）     ……（其余部分省略） 第十章 系统测试 一、复习

系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的“先知者问题”。因此，系统测试应该按照测试计划进行，其输入、输出和其他动态运行行为应该与软件规约进行对比。软件系统测试方法很多，主要有功能测试、性能测试、随机测试等等。

回归测试是贯穿于测试各个阶段的测试行为，其目的是检验对软件进行的修改是否正确。这里，修改的正确性有两重含义：一是所作的修改达到了预定目的，如错误得到改正，能够适应新的运行环境等等；二是不影响软件的其他功能的正确性。 二、系统测试

计算机软件是基于计算机系统的一个重要组成部分，软件开发完毕后应与系统中其它成分集成在一起，此时需要进行一系列系统集成和确认测试。对这些测试的详细讨论已超出软件工程的范围，这些测试也不可能仅由软件开发人员完成。在系统测试之前，软件工程师应完成下列工作： （1） 为测试软件系统的输入信息设计出错处理通路； （2） 设计测试用例，模拟错误数据和软件界面可能发生的错误，记录测试结果，为系统测试提供经验和帮助； （3） 参与系统测试的规划和设计，保证软件测试的合理性。系统测试应该由若干个不同测试组成，目的是充分运行系统，验证系统各部件是否都能正常工作并完成所赋予的任务。

系统测试是将经过测试的子系统装配成一个完整系统来测试。由于系统测试的目的是验证最终软件系统满足产品需求并且遵循系统设计，所以当产品需求和系统设计文档完成之后，系统测试小组就可以提前开始制定测试计划和设计测试用例，而不必等到\"实现与测试\"阶段结束。系统测试小组各成员依据《系统测试计划》和指定的模板，设计（撰写）《系统测试用例》。然后系统测试小组各成员依据《系统测试计划》和《系统测试用例》执行系统测试。

系统测试：是在集成测试通过后进行，为验证软件系统是否满足所规定的各个方面的需求而进行的，

114

企业应用软件测试实训课程

以黑盒测试方法为主。目的是充分运行系统，验证各子系统是否都能正常工作并完成设计的要求。主要由测试部门进行，是测试部门最大最重要的一个测试，对产品的质量有重大的影响。尽量在模拟环境中，或在单独的测试环境中进行，条件不具备时，也可以在软件系统运行环境中进行。 主要内容有：功能测试、健壮性测试、性能、恢复测试、效率测试、用户界面测试、安全性测试、压力测试、强度测试、可靠性测试、安装/反安装测试等。这个测试需要编写大量的测试用例，投入大量的资源来完成。 １、恢复测试

恢复测试主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。恢复测试首先要采用各种办法强迫系统失败，然后验证系统是否能尽快恢复。对于自动恢复需验证重新初始化（reinitialization）、检查点(checkpointing mechanisms)、数据恢复(data recovery)和重新启动 (restart)等机制的正确性；对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。 ２、安全测试

安全测试检查系统对非法侵入的防范能力。安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。例如，①想方设法截取或破译口令；②专门定做软件破坏系统的保护机制；③故意导致系统失败，企图趁恢复之机非法进入；④试图通过浏览非保密数据，推导所需信息，等等。理论上讲，只要有足够的时间和资源，没有不可进入的系统。因此系统安全设计的准则是，使非法侵入的代价超过被保护信息的价值。此时非法侵入者已无利可图。 ３、强度测试

强度测试检查程序对异常情况的抵抗能力。强度测试总是迫使系统在异常的资源配置下运行。例如，①当中断的正常频率为每秒一至两个时，运行每秒产生十个中断的测试用例；②定量地增长数据输入率，检查输入子功能的反映能力；③运行需要最大存储空间（或其他资源）的测试用例；④运行可能导致虚存操作系统崩溃或磁盘数据剧烈抖动的测试用例，等等。 ４、性能测试

对于那些实时和嵌入式系统，软件部分即使满足功能要求，也未必能够满足性能要求，虽然从单元测试起，每一测试步骤都包含性能测试，但只有当系统真正集成之后，在真实环境中才能全面、可靠地测试运行性能系统性能测试是为了完成这一任务。性能测试有时与强度测试相结合，经常需要其他软硬件的配套支持。

随着国内软件行业的不断发展，国内软件公司也越来越注重于软件的质量，越来越关注软件的可靠性，因此，做为质量保证的重要手段，软件测试过程的实施与管理成为一个热点，其中系统测试是整个测试活动的一个重要的阶段，系统测试的设计也就成为了关注点之一。

115

企业应用软件测试实训课程

2.1系统测试的概念

系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不相符合或与之矛盾的地方。 2.2系统测试的对象

系统测试的对象不仅仅包括需要测试的产品系统的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。因此，必须将系统中的软件与各种依赖的资源结合起来，在系统实际运行环境下来进行测试。 2.3系统测试的设计

系统测试过程包含了测试计划、测试设计、测试实施、测试执行、测试评估这几个阶段，而整个测试过程中的测试依据主要是产品系统的需求规格说明书、各种规范、标准和协议等。在整个测试过程中，首先需要对需求规格进行充分的分析，分解出各种类型的需求（功能性需求、性能要求、其他需求等），在此基础之上才可以开始测试设计工作，而测试设计又是整个测试过程中非常重要的一个环节，测试设计的输出结果是测试执行活动依赖的执行标准，测试设计的充分性决定了整个系统过程的测试质量。因此，为了保证系统测试质量，必须在测试设计阶段就对系统进行严密的测试设计。这就需要我们在测试设计中，从多方面来综合考虑系统规格的实现情况。通常需要从以下几个层次来进行设计：用户层、应用层、功能层、子系统层、协议层 2.3.1用户层

主要是面向产品最终的使用操作者的测试。这里重点突出的是在操作者角度上，测试系统对用户支持的情况，用户界面的规范性、友好性、可操作性，以及数据的安全性。主要包括： 1、用户支持测试

用户手册、使用帮助、支持客户的其他产品技术手册是否正确、是否易于理解、是否人性化。 2、用户界面测试

在确保用户界面能够通过测试对象控件或入口得到相应访问的情况下，测试用户界面的风格是否满足用户要求，例如：界面是否美观、界面是否直观、操作是否友好、是否人性化、易操作性是否较好。

3、可维护性测试

可维护性是系统软、硬件实施和维护功能的方便性。目的是降低维护功能对系统正常运行带来的影响。例如：对支持远程维护系统的功能或工具的测试。

116

企业应用软件测试实训课程

4、安全性测试

数据的安全性和操作的安全性。核实只有规格规定的数据才可以访问系统，其他不符合规格的数据不能够访问系统；核实只有规格规定的操作权限才可以访问系统，其他不符合规格的操作权限不能够访问系统。 2.3.2 应用层

针对产品工程应用或行业应用的测试。重点站在系统应用的角度，模拟实际应用环境，对系统的兼容性、可靠性、性能等进行的测试。 1、系统性能测试

针对整个系统的测试，包含并发性能测试、负载测试、压力测试、强度测试、破坏性测试。并发性能测试是评估系统交易或业务在渐增式并发情况下处理瓶颈以及能够接收业务的性能过程；强度测试是在资源情况低的情况下，找出因资源不足或资源争用而导致的错误；破坏性测试重点关注超出系统正常负荷N倍情况下，错误出现状态和出现比率以及错误的恢复能力。 2、系统可靠性、稳定性测试

一定负荷的长期使用环境下，系统可靠性、稳定性。 3、系统兼容性测试

系统中软件与各种硬件设备兼容性，与操作系统兼容性、与支撑软件的兼容性。 4、系统组网测试

组网环境下，系统软件对接入设备的支持情况。包括功能实现及群集性能。 5、系统安装升级测试

安装测试的目的是确保该软件在正常和异常的不同情况下进行安装时都能按预期目标来处理。例如，正常情况下，第一次安装或升级、完整的或自定义的安装都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。还有一个目的是核实软件在安装后可立即正常运行。另外对安装手册、安装脚本等也需要关注。 2.3.3 功能层

针对产品具体功能实现的测试。 1、业务功能的覆盖

关注需求规格定义的功能系统是否都已实现。

117

企业应用软件测试实训课程

2、业务功能的分解

通过对系统进行黑盒分析，分解测试项及每个测试项关注的测试类型。 3、业务功能的组合

主要关注相关联的功能项的组合功能的实现情况。 4、业务功能的冲突

业务功能间存在的功能冲突情况。比如：共享资源访问等。 2.3.4 子系统层

针对产品内部结构性能的测试。关注子系统内部的性能，模块间接口的瓶颈。 1、单个子系统的性能

应用层关注的是整个系统各种软、硬件、接口配合情况下的整体性能，这里关注单个系统。 2、子系统间的接口瓶颈

例如：子系统间通讯请求包的并发瓶颈。 3、子系统间的相互影响

子系统的工作状态变化对其他子系统的影响。 2.3.5 协议/指标层

针对系统支持的协议、指标的测试。 1、协议一致性测试 2、协议互通测试 三、系统测试的过程 3.1 适用对象

由开发部提供给测试部的最终系统。 3.2 进入条件

(1) 已经完成集成测试。

(2) 该系统可以运行在真实或仿真的环境下。 3.3 测试内容

118

企业应用软件测试实训课程

测试该系统是否达到了系统需求和功能规格说明中的要求，一般需要进行以下几方面的测试： (1) 功能测试。 (2) 性能测试。 (3) 外部接口测试。 (4) 人机界面测试。 (5) 强度测试。 (6) 冗余测试。 (7) 可靠性测试。 (1) 安全性测试。 (9) 恢复测试。 3.4 具体要求

(1) 由项目负责人决定具体进行那些方面的测试，但至少应该进行功能和性能测试。 (2) 系统测试采用功能测试的方法。 (3) 必须编写正式的系统测试计划。 (4) 系统测试可以在开发环境中进行。 (5) 系统测试组组长应由高级应用专家担任。

(6) 系统测试过程中必须对用户手册进行评价，找出用户手册与实际操作结果的差异。 (7) 系统测试由测试部负责开展，开发小组予以配合。 3.5 实施步骤

(1) 在需求分析阶段开始准备【系统测试计划】，并且在设计阶段加以细化更新，在实现阶段最终确定下来。

(2) 建系统测试环境，完成测试设计和开发，准备测试数据。 (3) 执行系统测试用例，并且详细记录测试结果。 (4) 判定测试用例是否通过。 (5) 提交系统测试报告。

119

企业应用软件测试实训课程

(6) 完成交付测试计划。 3.6 分析评估

根据【概要设计说明书】、【详细设计说明书】、系统测试结果和发现的错误信息，评价系统的设计与实现。 3.7 通过准则

(1) 完全执行了系统测试计划中的每个测试用例。

(2) 在系统测试中发现的错误已经得到修改并且通过了测试。 (3) 完成软件系统测试报告。 (4) 交付测试计划已经完成。 四、系统测试流程

由于系统测试的目的是验证最终软件系统满足产品需求并且遵循系统设计，所以当产品需求和系统设计文档完成之后，系统测试小组就可以提前开始制定测试计划和设计测试用例，而不必等到“实现与测试”阶段结束。这样可以提高系统测试的效率。

系统测试过程中发现的所有缺陷必须用统一的缺陷管理工具来管理，开发人员应当及时消除缺陷

（改错）。

图1 系统测试流程图

项目经理设法组建富有成效的系统测试小组。系统测试小组的成员主要来源于： ·机构的测试小组（如果存在的话）。 ·邀请其它项目的开发人员参与系统测试。 ·本项目的部分开发人员。

120

企业应用软件测试实训课程

·机构的质量保证人员。

1、软件项目立项，软件项目负责人将项目启动情况通报给测试组长，测试组长指定测试工程师对该项目进行系统测试跟进和执行。

2、 测试工程师首先参与前期的需求分析活动、前景评审、业务培训、SRS评审。目的是了解系统业务及范围、了解软件需求及范围，验证需求可测性。并将所有收集到的测试需求汇总并输出到《测试需求管理表》中。

3、 测试工程师根据测试需求定义测试策略，并进行工作量估计。

4、 测试工程师根据测试需求制定测试策略和方法；系统测试工程师参与项目计划和SDP评审，依据项目计划（或周计划）,编制《系统测试计划》。

5、 测试组长周期性地根据事业部项目的测试情况，进行总体测试工作量估计并进行测试任务分派。 6、测试工程师组织《系统测试计划》评审，测试组长根据评审意见审批《系统测试计划》。 7、 测试工程师根据《系统测试计划》中的测试环境要求搭建测试环境。特别技术要求的需要项目组及其它相关职能部门的配合。

8、测试工程师检查测试设计入口条件；根据《用例规约》、《补充规约》、《界面原型》、《词汇表》进行测试用例设计。

9、 测试工程师组织《系统测试用例》评审，测试组长根据评审意见审批《系统测试用例》。 10、 测试工程师定义系统测试用例执行过程，并更新《系统测试用例》。

11、 测试工程师检查测试执行入口条件，从受控库获取测试版本，执行系统测试并记录 测试结果。 12、 系统测试进入产品稳定期，由测试工程师召开缺陷评审会议；测试工程师对整个系统测试过程进行总结和评价，形成《软件缺陷清单》、《系统测试评估摘要》《系统测试总结报告》，并将系统测试过程的文档报送给项目组和测试组长。测试组长每月初或（事件驱动）汇总、整编上月的《产品质量简报》，报送给事业部总经理和项目办。

13、 如果根据系统测试结果，产品得以批准通过，系统测试工程师卸载被测软件，进行环境初始化，系统测试结束，转入验收测试阶段；否则视批示意见进行。 第十一章 回归测试 一、回归测试概念

121

企业应用软件测试实训课程

回归测试：选择性重新测试，目的是检测系统或系统部件在修改时所引起的故障，用以验证上述修改未引起不希望的有害效果，或证明修改后的系统或系统部件仍满足规定的需求。 回归测试的概念可以从多个角度进行理解，基于上面的概念，对其理解做以下分解：

回归测试是对某些已经进行过的测试的一些子集在重新进行一遍测试，以保证上述的改变不会传播无法预料的副作用。

1） 回归测试是指当软件或环境更改后再次对已测试过的软件功能的测试。 2） 回归测试不测试新的功能。

3） 回归测试用于保证旧的Bug没有重新出现。 4） 回归测试用于保证没有引入新的Bug。

5） 回归测试用于保证原有正常功能没有丢失或破坏。 6） 每发生一个变化，相应的就应该进行一次回归测试。 7） 回归测试理论上可以自动执行以便它能反映条件的变化。 8） 回归测试可以用于任何一个阶段。

9） 任何对已测试产品的修改，都应该执行回归测试过程和回归测试用例库。 二、回归测试方法

回归测试首先应创建回归测试过程和测试用例集，以便对修改过的产品进行测试。回归测试用例集总是会执行其中的功能点测试、流程测试，和一部分细化测试中的有效等价类测试； 其次，通过手动或者自动的方法执行回归测试用例集，完成回归测试执行。 最后，对回归测试执行结果进行分析、改进。

如果我们在回归测试执行阶段采用了自动测试的方法，则自动测试的步骤一般要包括以下内容： 1） 制定自动测试计划 2） 选择并获取自动测试工具 3） 学习自动测试工具使用 4） 录制测试脚本前的准备

在测试前需要先确认你的应用程序以及回归测试工具是符合你的测试需求的。

122

企业应用软件测试实训课程

确认你已经知道如何对应用程序进行测试，例如要测那些功能、操作步骤、输入的数据、预期的结果等。

同时你也应该检查一下测试工具的设定，以确保回归测试工具会合适的录制并储存信息。例如，你应该确认一下回归测试工具是以什么模式储存信息的。 1) 录制测试脚本

当你浏览你的网站或是操作你的应用程序时，回归测试工具会录制的操作步骤。每个操作步骤都是使用者在录制时的操作，如在网页上点选一个超级链接 (link)，或是按下窗口上的按钮。 2) 加强测试脚本

在测试脚本中加入检查点，你可以检查网页超级链接、对象属性或是字符串，以验证应用程序的功能是否正确。

将录制的固定值参数以取代，让你使用多组的数据测试你的应用程序。 使用逻辑 (logic) 或是条件 (conditional) 判断式，让你可以进行更复杂的测试。 3) 对测试脚本除错 (debug)

在修改过测试脚本之后，你可能会需要对测试脚本作除错的动作，以确保测试脚本能正常且流畅的执行。

4) 在新版应用程序或网站上执行测试脚本

透过执行测试脚本，回归测试工具会在新版的网站或是应用程序上执行测试，检查应用程序的功能是否正确。 5) 分析测试结果

分析测试执行的结果，找出应用程序的问题所在。 提示：

回归测试的概念虽然相对简单，但是回归测试并不针对单一的测试技术，而且回归测试可能在任何一个测试阶段被执行，因此回归测试的方法远比这里所提到得内容多的多。 三、回归测试工具

目前测试工具种类繁多，其中一大类便是回归测试工具，并且基本上都具有录制回放以及脚本编写功能。其代表公司和代表产品主要包括IBM公司的Rational robot、HP公司的WinRunner和QuickTest Professional以及Segue公司的SilkTest和SilkTest International工具等。

123

企业应用软件测试实训课程

那么在回归测试工具的应用都有哪些好处呢：

➢ 减轻测试劳动强度：测试执行过程中，回归测试占有很大比重，采用工具后可自动执行回归测

试，测试人员主要关注测试结果及测试报告即可，因此可以减轻测试强度。

➢ 提高测试效率：利用工具脚本完成回归测试，不仅可以利用非工作时间，单就执行速度而言也

要高出手动执行的速度，因此可以提高测试效率。回归测试的次数越多，频率越频繁，则提高效率带来的收益越大。当然我们在考虑执行过程效率提高的同时，不应忽略编写测试脚本与维护测试脚本所付出的工作量。

➢ 提供了测试技术维系的手段：由于测试内容已经融入工具的测试脚本中，因此可以在原测试人

员不在的情况下，由其他测试人员通过执行测试脚本，而达到与原测试人员执行回归测试相近的测试效果。

➢ 可以将测试活动提前：回归测试主要应用于功能验证的黑盒测试，这样我们的测试执行通常要

等待测试版本提供后才能进行，但是使用工具后，我们可以在测试版本提供前就展开回归测试脚本的编写工作。

➢ 可以在升级产品中延续测试脚本的使用：回归测试工具通常是通过控件识别的方法记录控件及

其行为的，升级产品中经常会继承之前版本中大量功能。因此很多脚本可以在不修改或简单修改的情况下，就能够重用。

提示：回归测试工具的种类很多，每种工具都由其各自得特点，因此选择适合自己工作的回归测试工具很重要。

124

企业应用软件测试实训课程

第十二章 验收测试 一、 验收测试的概念

Acceptance testing（验收测试），系统开发生命周期方的一个阶段，这时相关的用户和／或测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试，是管理性和防御性控制。

验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。它的测试数据通常是系统测试的测试数据的子集。所不同的是，验收测试常常有软件系统的购买者代表在现场，甚至是在软件安装使用的现场。这是软件在投入使用之前的最后测试。

验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样， 验收测试应检查软件能否按合同要求进行工作，即是否满足软件需求说明书中的确认标准。 二、 验收测试目的

1、验收测试依据软件需求规格说明，验证软件产品是否符合用户需求规格说明的要求。 2、验收测试帮助用户尽可能地发现软件中存留的缺陷，从而为软件进一步改善提供帮助。 三、 验收测试要求 1、《软件需求规格说明书》

2、软件安装介质：如光盘、移动硬盘、纸。保持无病毒。

3、用户文档，包括《用户手册》、《操作手册》《软件安装和维护手册》等 以下材料根据被测软件的需要选择提交:

4、软件运行时必需的相应数据（如代码表，测试所需的初试记录等） 5、软件运行时必需的专用硬件设备软件运行所需要的其他辅助设备 6、《测试计划》中所规定的其他材料。 四、 验收测试标准

验收测试同样需要制订测试计划和过程，测试计划应规定测试的种类和测试进度，测试过程则定义一些特殊的测试用例，旨在说明软件与需求是否一致。无是计划还是过程，都应该着重考虑软件是

125

企业应用软件测试实训课程

否满足合同规定的所有功能和性能，文档资料是否完整、准确人机界面和其他方面（例如，可移植性、兼容性、错误恢复能力和可维护性等）是否令用户满意。 验收测试的结果有两种可能，一种是功能和性能指标满足软件需求说明的要求，用户可以接受；另一种是软件不满足软件需求说明的要求，用户无法接受。项目进行到这个阶段才发现严重错误和偏差一般很难在预定的工期内改正，因此必须与用户协商，寻求一个妥善解决问题的方法。 五、 实施验收测试的常用策略

实施验收测试的常用策略有三种，它们分别是： ➢ 正式验收

➢ 非正式验收或 Alpha 测试 ➢ Beta 测试

所选择的策略通常建立在合同需求、组织和公司标准以及应用领域的基础上。 5.1正式验收测试

正式验收测试是一项管理严格的过程，它通常是系统测试的延续。计划和设计这些测试的周密和详细程度不亚于系统测试。选择的测试用例应该是系统测试中所执行测试用例的子集。不要偏离所选择的测试用例方向，这一点很重要。在很多组织中，正式验收测试是完全自动执行的。

对于系统测试，活动和工件是一样的。在某些组织中，开发组织（或其的测试小组）与最终用户组织的代表一起执行验收测试。在其他组织中，验收测试则完全由最终用户组织执行，或者由最终用户组织选择人员组成一个客观公正的小组来执行。 这种测试形式的优点是：

1) 要测试的功能和特性都是已知的。

2) 测试的细节是已知的并且可以对其进行评测。 3) 这种测试可以自动执行，支持回归测试。 4) 可以对测试过程进行评测和监测。 5) 可接受性标准是已知的。 这种测试形式的 缺点包括：

1) 要求大量的资源和计划。

126

企业应用软件测试实训课程

2) 这些测试可能是系统测试的再次实施。

3) 可能无法发现软件中由于主观原因造成的缺陷，因为只查找了预期要发现的缺陷。 5.2非正式验收测试

在非正式验收测试中，执行测试过程的限定不象正式验收测试中那样严格。在此测试中，确定并记录要研究的功能和业务任务，但没有可以遵循的特定测试用例。测试内容由各测试员决定。这种验收测试方法不象正式验收测试那样组织有序，而且更为主观。大多数情况下，非正式验收测试是由最终用户组织执行的。

事实上，软件开发人员不可能完全预见用户实际使用程序的情况。例如，用户可能错误的理解命令，或提供一些奇怪的数据组合，亦可能对设计者自认明了的输出信息迷惑不解，等等。因此，软件是否真正满足最终用户的要求，应由用户进行一系列“验收测试”。验收测试既可以是非正式的测试，也可以有计划、有系统的测试。有时，验收测试长达数周甚至数月，不断暴露错误，导致开发延期。一个软件产品，可能拥有众多用户，不可能由每个用户验收，此时多采用称为α、β测试的过程，以期发现那些似乎只有最终用户才能发现的问题。

α测试是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的用户操作方式。经过α测试调整的软件产品称为β版本。 这种测试形式的优点是：

1) 要测试的功能和特性都是已知的。 2) 可以对测试过程进行评测和监测。 3) 可接受性标准是已知的。

4) 与正式验收测试相比，可以发现更多由于主观原因造成的缺陷。 这种测试形式的缺点包括：

1) 要求资源、计划和管理资源。 2) 无法控制所使用的测试用例。

3) 最终用户可能沿用系统工作的方式，并可能无法发现缺陷。

4) 最终用户可能专注于比较新系统与遗留系统，而不是专注于查找缺陷。 5) 用于验收测试的资源不受项目的控制，并且可能受到压缩。

127

企业应用软件测试实训课程

5.3 Beta 测试

β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。 一般包括功能、安全可靠性、易用性、可扩充性、兼容性、效率、资源占用率、用户文档八个方面。

Beta测试又称作外部测试，是把即将推出的产品提供给部分最终用户试用，另一方面也作市场用户调研。

很多人都会以为，Beta测试就是邀集外界对软件产品提出设计方面的改进建议或提出程序中的BUG，然后让软件公司对功能做加强或修改。这是完全错误的。Beta测试的目的是确定软件产品是否能在预计的各种硬件平台与操作系统中正常运作。虽然Beta测试的反馈意见很有参考价值，但除非Beta测试中发现产品有重大问题，否则不应对功能再做修改，顶多只是更正错误。所有的建议和反馈都留到下一版时再考虑纳入。

这么做绝不表示忽视用户的意见，相反地，如果你不重视对Beta测试的意见的接受，那你就很可能永远没有办法真正推出新产品。

用户对软件产品的第一个印象往往决定了他对软件的评价。基本上，Beta测试者的反应，也会是大部分用户的反应。销售人员应该把握Beta测试的机会，了解测试者对产品的感受，并采取积极的措施来提高软件产品的形象。

在以上三种验收测试策略中，Beta 测试需要的控制是最少的。在 Beta 测试中，采用的细节多少、数据和方法完全由各测试员决定。各测试员负责创建自己的环境、选择数据，并决定要研究的功能、特性或任务。各测试员负责确定自己对于系统当前状态的接受标准。

Beta 测试由最终用户实施，通常开发（或其他非最终用户）组织对其的管理很少或不进行管理。Beta 测试是所有验收测试策略中最主观的。 这种测试形式的优点是：

1) 测试由最终用户实施。 2) 大量的潜在测试资源。

3) 提高客户对参与人员的满意程度。

4) 与正式或非正式验收测试相比，可以发现更多由于主观原因造成的缺陷。 这种测试形式的缺点包括：

1) 未对所有功能和/或特性进行测试。

128

企业应用软件测试实训课程

2) 测试流程难以评测。

3) 最终用户可能沿用系统工作的方式，并可能没有发现或没有报告缺陷。 4) 最终用户可能专注于比较新系统与遗留系统，而不是专注于查找缺陷。 5) 用于验收测试的资源不受项目的控制，并且可能受到压缩。 6) 可接受性标准是未知的。

7) ·需要更多辅助性资源来管理 Beta 测试员。 六、 验收测试过程

1. 软件需求分析：了解软件功能和性能要求、软硬件环境要求等，并特别要了解软件的质量要求和验收要求。

2. 编制《验收测试计划》和《项目验收准则》：根据软件需求和验收要求编制测试计划，制定需测试的测试项，制定测试策略及验收通过准则，并经过客户参与的计划评审。

3. 测试设计和测试用例设计：根据《验收测试计划》和《项目验收准则》编制测试用例，并经过评审。

4. 测试环境搭建：建立测试的硬件环境、软件环境等。（可在委托客户提供的环境中进行测试） 5. 测试实施：测试并记录测试结果。

6. 测试结果分析：根据验收通过准则分析测试结果，作出验收是否通过及测试评价。 7. 测试报告：根据测试结果编制缺陷报告和验收测试报告，并提交给客户。 七、 验收测试的总体思路

用户验收测试是软件开发结束后，用户对软件产品投入实际应用以前进行的最后一次质量检验活动。它要回答开发的软件产品是否符合预期的各项要求，以及用户能否接受的问题。由于它不只是检验软件某个方面的质量，而是要进行全面的质量检验，并且要决定软件是否合格，因此验收测试是一项严格的正式测试活动。需要根据事先制订的计划，进行软件配置评审、功能测试、性能测试等多方面检测。 7.1软件配置审核

用户验收测试可以分为两个大的部分：软件配置审核和可执行程序测试.

对于一个外包的软件项目而言，软件承包方通常要提供如下相关的软件配置内容：

129

企业应用软件测试实训课程

●可执行程序、源程序、配置脚本、测试程序或脚本。

●主要的开发类文档：《需求分析说明书》、《概要设计说明书》、《详细设计说明书》、《数据库设计说明书》、《测试计划》、《测试报告》、《程序维护手册》、《程序员开发手册》、《用户操作手册》、《项目总结报告》。

●主要的管理类文档：《项目计划书》、《质量控制计划》、《配置管理计划》、《用户培训计划》、《质量总结报告》、《评审报告》、《会议记录》、《开发进度月报》。

在开发类文档中，容易被忽视的文档有《程序维护手册》和《程序员开发手册》。

《程序维护手册》的主要内容包括：系统说明（包括程序说明）、操作环境、维护过程、源代码清单等，编写目的是为将来的维护、修改和再次开发工作提供有用的技术信息。

《程序员开发手册》的主要内容包括：系统目标、开发环境使用说明、测试环境使用说明、编码规范及相应的流程等，实际上就是程序员的培训手册。

不同大小的项目，都必须具备上述的文档内容，只是可以根据实际情况进行重新组织。 对上述的提交物，最好在合同中规定阶段提交的时机，以免发生纠纷。

通常，正式的审核过程分为5个步骤：计划、预备会议（可选）、准备阶段、审核会议和问题追踪。预备会议是对审核内容进行介绍并讨论。准备阶段就是各责任人事先审核并记录发现的问题。审核会议是最终确定工作产品中包含的错误和缺陷。

审核要达到的基本目标是：根据共同制定的审核表，尽可能地发现被审核内容中存在的问题，并最终得到解决。在根据相应的审核表进行文档审核和源代码审核时，还要注意文档与源代码的一致性。 在实际的验收测试执行过程中，常常会发现文档审核是最难的工作，一方面由于市场需求等方面的压力使这项工作常常被弱化或推迟，造成持续时间变长，加大文档审核的难度；另一方面，文档审核中不易把握的地方非常多，每个项目都有一些特别的地方，而且也很难找到可用的参考资料。 7.2可执行程序的测试

在文档审核、源代码审核、配置脚本审核、测试程序或脚本审核都顺利完成，就可以进行验收测试的最后一个步骤——可执行程序的测试，它包括功能、性能等方面的测试，每种测试也都包括目标、启动标准、活动、完成标准和度量等五部分。

要注意的是不能直接使用开发方提供的可执行程序用于测试，而要按照开发方提供的编译步骤，从源代码重新生成可执行程序。

130

企业应用软件测试实训课程

在真正进行用户验收测试之前一般应该已经完成了以下工作（也可以根据实际情况有选择地采用或增加）：

●软件开发已经完成，并全部解决了已知的软件缺陷。 ●验收测试计划已经过评审并批准，并且置于文档控制之下。 ●对软件需求说明书的审查已经完成。 ●对概要设计、详细设计的审查已经完成。 ●对所有关键模块的代码审查已经完成。

●对单元、集成、系统测试计划和报告的审查已经完成。 ●所有的测试脚本已完成，并至少执行过一次，且通过评审。 ●使用配置管理工具且代码置于配置控制之下。 ●软件问题处理流程已经就绪。

●已经制定、评审并批准验收测试完成标准。

具体的测试内容通常可以包括：安装（升级）、启动与关机、功能测试（正例、重要算法、边界、时序、反例、错误处理）、性能测试（正常的负载、容量变化）、压力测试（临界的负载、容量变化）、配置测试、平台测试、安全性测试、恢复测试（在出现掉电、硬件故障或切换、网络故障等情况时，系统是否能够正常运行）、可靠性测试等。

性能测试和压力测试一般情况下是在一起进行，通常还需要辅助工具的支持。在进行性能测试和压力测试时，测试范围必须限定在那些使用频度高的和时间要求苛刻的软件功能子集中。由于开发方已经事先进行过性能测试和压力测试，因此可以直接使用开发方的辅助工具。也可以通过购买或自己开发来获得辅助工具。具体的测试方法可以参考相关的软件工程书籍。

如果执行了所有的测试案例、测试程序或脚本，用户验收测试中发现的所有软件问题都已解决，而且所有的软件配置均已更新和审核，可以反映出软件在用户验收测试中所发生的变化，用户验收测试就完成了。

八、 软件验收阶段的测试项目

软件验收测试尽可能在现场进行实际运行测试，如果受条件，也可以在模拟环境中进行测试，无论何种测试方式，都必须事先制定测试计划规定要做的测试种类，并制定相应的测试步骤和具体的测试用例。

131

企业应用软件测试实训课程

一般软件工程项目验收测试的项目有：文档审查、功能测试、性能测试、安装测试、界面测试、配置测试、加载测试、恢复测试、安全测试等等。凡是需求规格说明书中有要求的，都要进行测试，确认是否满足。 8.1．文档审查

软件项目验收应提供的文档有：项目研制总结报告、项目技术、经济分析报告、软件需求规格说明书、测试总结报告、用户使用操作手册及维护手册等，主要审查文档的完整性、正确性和可理解性，编写是否规范。文档如果不齐全或描述不清甚至错误，将给用户使用带来不必要的麻烦，甚至阻碍软件的升级。 8.2．安装测试

安装测试第一个目的是验证软件在最基本要求的配置情况下安装后能否正常运行?第二个目的是检验软件在非正常条件下安装，非正常条件包括磁盘空间不足、内存不够、缺乏创建目录的等，在这种情况下，安装程序能否给用户足够的提示。 8.3．功能测试

功能测试是按照软件需求规格说明书规定的功能需求，逐项检验软件功能是否正确，有无严重错误。测试时，一般事先准备好测试用例，检验是否得到期望的输出。测试用例至少要包含以下情况：合法数据、边界数据和非法数据。 8.4．性能测试

性能测试是检查系统是否满足需求规格说明书中规定的性能要求，一般主要测试软件的运行速度和对资源的利用率。性能主要表现在以下几个方面：响应时间、吞吐量、辅助存储区(如缓冲区、工作区)的大小，处理精度等。性能测试中很重要的一项是极限测试，因为很多软件系统会在极限状态下崩溃。例如连续不停地向服务器发出请求，测试服务器是否会陷人死锁状态；给系统输人特别大的数据后，检测程序的运信息化应用研究行状况等。 8.5．界面测试

界面测试是检查软件界面所关联的对象是否正确，运行是否正常；界面之间的链接是否合理；界面是否符合相关标准和用户习惯；界面是否美观、友好等。 8.6．加载测试

加载测试是要检查软件在超正常数据量情况下，软件系统的反应。例如在B／S体系结构中，对WEB服务器和数据库服务器的加载测试，通常是利用测试工具软件产生虚拟用户负载，逐步增加虚拟用户数量，并使每个虚拟用户运行相同脚本或不同的脚本，考察软件系统的运行状况。

132

企业应用软件测试实训课程

8.7．配置测试

配置测试是要验证在不同的硬件和软件配置下软件的运行状况，特别是对最大和最小配置要进行测试。其中，软件配置参数有网络内存的大小，不同的操作系统版本和网络软件。系统表格的大小及可使用的规程等。硬件配置参数有节点的数量，主机及外设的配置、数量和类型，网络拓朴结构等。 8.8．恢复测试

恢复测试是通常采用人工干预的手段，模拟硬件故障或故意造成软件出错，考察软件系统的反应，系统能否正常地继续进行工作，并不对系统无故障部分造成任何损害。 8.9．安全性测试

安全性测试对于接人互联网的系统尤为重要，一般着重考察用户权限的。用户登陆的有效性检查，系统认证加密机制的有效性，网络安全保密性能检测，人侵监控、数据备份等。其中，网络安全保密性能检测主要是检测网络是否存在安全性漏洞。入侵监控是一旦发现攻击，能发出警报，并采取相应措施(如阻断、跟踪和反击)，记录入侵过程，为系统恢复和追查攻击的来源提供依据。如果软件工程项目是属涉及国家秘密系统，必须从物理安全，网络运行安全，信息保密安全，安全保密管理等诸多方面进行严格的测试和审查，而且必须由保密部门指定的相关机构进行测试和审查，测试和审查合格后，方准投入运行。 九、 验收测试报告

软件工程项目在进行诸多项目的内容测试之后，必须客观、公正、如实地编写软件验收测试报告，报告中必须说明测试的环境条件、测试的内容及软件符合需求规格说明书中规定的需求情况，对软件中突出的功能、性能及创新性或采用的先进技术，应给予充分肯定，软件中哪些未能满足需求规格说明书的需求也应如实反映，使测试报告真正成为项目评审、鉴定的重要依据。

综上所述，软件工程项目的验收测试，是软件工程中最重要、最关键的环节，无论是软件开发商还是用户，都必须给予足够的重视。 第十三章 封样测试 一、 封样测试的概念

封样是将软件数据复制并存储到载体上，产生母盘，以便用于生产的过程。封样测试是在封样过程中进行的测试工作，目的是保证母盘的完整性、可读性和数据安全性。 二、 封样测试的重要性

133

企业应用软件测试实训课程

封样测试过程有严格的工序要求，所以，封样工作没有什么复杂的技术和方法，但要求测试和操作人员有很强的责任心，不经意间的工作疏忽往往会给产品发布后带来巨大的隐患，也可能造成生产原料的浪费。封样过程中，可能会出现下面常见的情况： 2.1 母盘中有病毒。

母盘就是用于复制其他软件商品的源媒介。母盘中的数据带有计算机病毒或恶意的黑客程序，就会原封不动的将病毒传递给最后发布的商品，这样病毒就会被使用商品的用户得到。一旦病毒程序发作，将对用户造成经济等各方面的影响，还会影响到软件开发企业的形象，说严重一点，下次用户可能再也不敢使用这个公司的产品了。所以，封样负责人一定要保证母盘中没有任何病毒及恶意程序的存在。

2.2 产品中个别文件缺失。

在产品刻录过程中，可能由于极特殊原因发生，导致个别文件刻录失败，而且不易察觉。比如使用软件刻录时，有些特殊属性的文件（如隐藏文件）可能在复制时被遗漏；文件正在被某些程序使用的情况下，复制可能会失败。文件缺失，可导致最终产品不能正常使用，甚至根本不能使用。所以，封样负责人在母盘刻录完成后必须认真检查数据的完整性。 2.3 母盘可读性差。

母盘虽然没有病毒，数据也完整，但又有可能数据读取很困难，导致实际生产时很不顺利，这也是我们所不能接受的，直接的影响会使产品不能及时提供给市场。那么就要求封样负责人要对封样母盘做可读性测试。一般采用低速刻录可以有效提高母盘的可读性。 三、 封样测试过程 3.1 准入条件：

在进行封样测试前，确保该软件产品已经经过确认可以进行封样，即产品通过项目定义的全部测试阶段，实际质量满足项目最初确定的质量目标要求。反过来说，如果没有通过项目定义的全部测试阶段，而进行封样及封样测试，那是没有意义的，这个道理是显而易见的。 3.2 封样测试准备

封样测试前，一般需要做好如下各项准备：

准备好用于将数据写入光盘载体的刻录机，而且刻录机的状况要保证良好；

准备好查杀计算机病毒、恶意程序的查毒环境，一般需要准备至少三种主流的杀毒软件，并且每个软件都保证安装了最新的病毒定义代码。

134

企业应用软件测试实训课程

准备好数据比较环境，用于比较数据复制是否完整。数据比较工具要能够保证数据在二进制级别上的检验；

准备好可读性测试环境，一般是具有数据复制功能的软件，如MS-DOS中的XCopy程序，或者Windows系统中的资源管理器。 3.3 封样测试实施

一般来说，封样的源盘和刻录环境准备好，封样实施工作就开始了。 首先是刻录工作，我们一般有2种刻录方式，刻录机和拷贝机，也可以说是软件刻录和硬件刻录；软件刻录是通过计算机刻录程序控制刻录过程，而硬件刻录是使用特殊硬件设备，通过硬件控制刻录过程。这2种刻录方式其实都可以完成封样刻录，只是测试人员往往习惯用刻录机完成刻录的过程。 封样负责人 集成负责人 软件集成 回归测试 前面我们也提到过了，封样测试主要为了确保封样母盘安全性好（无毒）、完整性好、可读性好，针对这3个目的，我们实际工作中采取3种手段。 用数据比较工具（如WINDIFF）进行源盘和刻录盘之间的比较，以验证母盘数据的完 整性和一致性；注意这种完整性和一致性要保证在二进制数据级别上，即源盘和复制出 来的刻录盘要保证每一个字节都是相同的。 Y 完整性测试 N 测试 结束 Y 封样刻录 N 用至少3种流行的查毒工具，例如NORTON ANTIVIRUS、瑞星、KV3000等。而且这些工具都必须使用当前最新的病毒定义代码；同时，要对软件安装过程实时病毒监控，而且要对安装后的程序也要进行查毒。 用MS-DOS的XCOPY命令（或其他可靠的复制数据方法）从母盘进行拷贝，拷贝完封样 查毒 Y 可读性测试 Y 封样结束 135

N N 企业应用软件测试实训课程

成后再与母盘进行对比，以检查所有数据都能读出。

最后，需要详细记录封样测试的情况，把封样测试结果发布在封样测试报告中，并把封样测试报告与封样盘一起提交审核人员审批，再把生产母盘交付生产部门。 具体测试流程见下图：

可以看出，封样测试中，任何一个环节出现问题，都必须返回到集成阶段重新生成软件发布数据。因为封样测试中发现的问题可能是由前面的过程引入的。比如文件缺失，可能是制作安装包时遗漏的。

另外，对于完整性测试、封样查毒和可读性测试3种工作顺序无严格要求，测试人员完全可以根据实际情况选择执行顺序。 四、 封样测试注意事项 4.1 刻录注意事项

刻录模式一定要采用“MODE1”模式； 刻录速度为1X或2X的低倍速刻录；

封盘一般要使用金盘，即要求刻录盘质量很好； 刻录设置要使用“不可追加数据”设置； 设立卷标时尽量使用英文和数字，不要使用中文。 4.2 查毒注意事项

一旦发现病毒，应该要求集成人员重新在无毒环境重新Build，生成新的程序包，而不是直接杀毒了事；

如果各查毒软件查毒结果不一致时，要求封样负责人要格外重视，通过协调查毒软件厂商，得到一致性结果。这种情况有时是因为病毒定义不一致导致的，比如A厂商的查毒软件认为文件f包含病毒，而B厂商的查毒软件没有发现文件f包含病毒，这可能就是两个厂商的病毒定义不一致；还有的时候，这种情况是因为不同厂商对于“病毒”的界限不同，如有的厂商不把木马程序当作威胁来处理。一般的经验认为，标准应该定位在最严格的尺度上：确定一个文件安全，需要保证文件可以通过每个查毒软件的检测；而确定一个文件不安全，只需要其中一个查毒软件的检测没有通过即可。 4.3 可读性测试注意事项

136

企业应用软件测试实训课程

充分使用XCOPY的参数，具体可直接从DOS中得到帮助。因为母盘中的文件会因为属于系统文件或其他属性而造成简单使用XCOPY命令并不能够把所有文件拷贝出来。

一般不建议使用自行开发的程序进行这项测试。因为象XCopy等程序，是经过长期应用实践检验过的，如果使用自行开发的程序进行检测，可能由于检测程序本身的问题，使本来可以发现的问题被隐藏了起来。

4.4 封样测试报告的内容

封样测试报告中一定仔细记录测试使用环境，包括病毒代码版本、刻录环境等。封样测试报告，可能类似于下面这个表格，仅供参考：

母盘刻录 刻录软件，版本号 刻录速度 刻录模式 是否可追加数据 病毒检查 查毒软件A，版本号，病毒定义版本号 查毒软件A扫描文件数 查毒软件A扫描结果 ... 数据读取测试 复制所有文件使用的时间 是否成功复制所有数据 母盘卷标是否能够正常显示 0

137

企业应用软件测试实训课程

第十四章 本地化测试

如果您计划将应用程序向国际用户分发，那么切记您需要在设计和开发阶段做许多事情。即使您没有这样的计划，当您的计划在应用程序的未来版本中有所变化时，预先所做的较小的工作都会使事情变得相当容易。

过去，术语“本地化”通常是指在应用程序开发人员用原始语言编译了源文件之后另一个团队开始改编源文件以用于另一种语言的过程。例如，原始语言可能是英语，第二种语言可能是德语。然而，这种方法的价格过高并导致版本之间不一致，甚至使某些客户不愿等待几个月购买本地化版本而先购买原始语言版本。一种更有成效和实用的模式是将开发世界通用应用程序的过程分为三个截然不同的部分：全球化、本地化分析和本地化。

全球化是设计和开发适合多种区域性或区域性设置的软件产品的过程。这一过程涉及： 标识必须支持的区域性或区域设置 设计支持这些区域性或区域设置的功能

编写在所支持的任何区域性或区域设置都能正常运行的代码

本地化分析是一个中间过程，用于验证全球化应用程序是否已准备好进行本地化。理想情况下，这仅是一个质量保证阶段。如果在设计和开发应用程序时考虑了本地化，则此阶段主要包括可本地化性测试。否则，在此阶段需要发现并修复源代码中妨碍本地化的错误。本地化分析有助于确保本地化不会给应用程序带来功能上的缺陷。

本地化分析也是准备应用程序的本地化的过程。准备本地化的应用程序有两个概念块：“数据块”和“代码块”。数据块仅包含所有用户界面字符串资源。代码块仅包含适合于所有区域性或区域设置的应用程序代码。

本地化是使已经过本地化分析处理的全球化应用程序适合于某一特定区域性或区域设置的过程。应用程序的本地化过程还要求对时下的软件开发中常用的相关字符集有一个基本了解，并且了解与它们相关的问题。虽然所有计算机都将文本存储为数字（代码），但不同的系统可以（并且确实）使用不同的数字存储相同的文本，这个问题在网络化时代显的尤为重要。

本地化过程是指翻译应用程序用户界面 (UI) 或调整图形，使其适合特定的区域性/区域设置。本地化过程还包括翻译所有与应用程序相关的帮助内容。大多数本地化小组在本地化过程中都使用专门的工具，这些工具可以重复利用重复出现的文本的翻译，以及调整应用程序用户界面元素的大小以适应本地化的文本和图形。 一、本地化测试概述

对于软件本地化测试，本地化提供商主要进行外观测试和本地化语言测试，软件供应商主要进行国际化测试和功能测试。软件在本地化之前，必须先经过软件国际化测试和可本地化性能测试等功能测试，然后再编译本地化版本。软件本地化提供商应该重点处理本地化提供商可以解决和擅长的调整本地化软件用户界面布局和语言翻译等问题，对于测试过程报告的软件硬编码（指直接嵌入在代码中的需要本地化的字符）和软件自身的功能错误只能由软件提供商处理。

138

企业应用软件测试实训课程

由于软件本地化和源语言软件开发一起进行，因此，软件本地化测试通常要测试多个功能不断完善和丰富的本地化版本。这些不同的本地化版本测试的重点和具体测试内容各不相同。一般，第一个本地化版本，重点测试软件外观，即软件用户界面测试，包括界面控件大小和位置，也包括界面本地化的字符内容和样式，而在此阶段，软件联机帮助和其他文档都还没有本地化，不需要测试。软件的功能还不完善，不要过多耗费时间进行功能测试。最后一个本地化测试版本，是测试的最后阶段，要尽量保证全面的测试，包括本地化功能测试，软件程序、联机帮助语言质量测试，安装/卸载测试，并尽快处理发现的软件错误。在第一个和最后一个测试版本之间的中间版本的测试，要保持功能测试和语言测试行结合的测试方法，在稍后的软件界面冻结版本的测试中，重点测试文档本地化质量，包括语言和本地化图像的格式等方面。

关于软件错误和缺陷处理，应该尽量保证在每个版本测试周期内全部解决，以免错误和缺陷逐渐积累而最终没有时间全部处理，从而影响本地化测试质量。为了有效处理测试中的报告的软件错误和缺陷，本地化提供商和软件供应商的测试工程师必须每天检索共享专用的软件测试错误数据库，对属于自己要处理的错误及时处理。对于软件测试错误数据库中任何错误的处理，都要保存详细的处理记录。

从测试理论上将，每个新版本的测试都需要对前面的版本进行回归测试，以保证新软件版本功能的改进不会使以前的错误重现或产生新的错误。为了保证软件的最终质量，至少对最后一个本地化版本的交付测试执行回归测试。 二、本地化缺陷 2.1缺陷类型

按照现阶段对于本地化的研究认识，一般而言，软件本地化的缺陷主要分为两大类：核心缺陷和本地化缺陷。两类缺陷的详细分类如下图所示：

图： 本地化软件缺陷图

139

企业应用软件测试实训课程

2.2缺陷表现特征 2.2.1 用户界面缺陷

控件的文字被截断（Truncation）

对话框中的文本框、按钮、列表框、状态栏中的本地化文字只显示一部分 控件或文字没有对齐（Misaligned） 对话框中的同类控件或本地化文字没有对齐 控件位置重叠（Overlapped） 对话框中的控件彼此重叠 多余的文字（Extra strings）

软件程序的窗口或对话框中的出现多余的文字 丢失的文字（Missed strings）

软件程序的窗口或对话框中的文字部分或全部丢失 不一致的控件布局（Inconsistent layout） 本地化软件的控件布局与源语言软件不一致 丢失的文字（Missed strings）

软件程序的窗口或对话框中的文字部分或全部丢失 文字的字体、字号错误（Incorrect font name and font size） 控件的文字显示不美观，不符合本地化语言的正确字体和字号 多余的空格（Extra space）

本地化文字字符之间存在多余的空格 2.2.2 语言质量缺陷

字符没有本地化（Unlocalized strings）

对话框或软件程序窗口中的应该本地化的文字没有本地化 字符不完整地本地化（Incomplete localized strings）

对话框或软件程序窗口中的应该本地化的文字只有一部分本地化 错误的本地化字符（Error localization）

源语言文字被错误地本地化，或者对政治敏感的文字错误地进行了本地化 不一致的本地化字符（Inconsistent localized string）

140

企业应用软件测试实训课程

相同的文字前后翻译不一致 相同的文字各语言之间不一致

相同的文字软件用户界面与联机帮助文件不一致 过度本地化（Over localization） 不应该本地化的字符进行了本地化

标点符号、版权、商标符号错误（Incorrect punctuation, Copyright） 标点符号、版权和商标的本地化不符合本地化语言的使用习惯 2.2.3 本地化功能缺陷

本地化功能缺陷是本地化软件中的某些功能不起作用，或者功能错误，与源语言功能不一致。 功能不起作用（Not working） 菜单、对话框的按钮、超链接不起作用 功能错误（Error function）

菜单、对话框的按钮、超链接引起程序崩溃

菜单、对话框的按钮、超链接带来与源语言软件不一致的错误结果 超链接没有链接到本地化的网站或页面 软件的功能不符合本地化用户的使用要求

热键和快捷键错误（Error hot keys and short-cut keys） 菜单或对话框中存在重复的热键 本地化软件中缺少热键或快捷键 不一致的热键或快捷键 快捷键或快捷键无效 2.2.4 源语言功能缺陷

源语言功能缺陷是在源语言软件和全部本地化软件上都可以复现的错误。 功能不起作用（Not working） 菜单不起作用 对话框的按钮不起作用 超链接不起作用

控件焦点跳转顺序（Tab键）不正确

141

企业应用软件测试实训课程

文字内容错误（Incorrect strings） 软件的名称或者版本编号错误 英文拼写错误、语法错误 英文用词不恰当等 2.2.5 源语言国际化缺陷

源语言国际化缺陷是在源语言软件设计过程中对软件的本地化能力的处理不足引起的，它只出现在本地化的软件中。

区域设置错误（Error regional setting） 本地化日期格式错误 本地化时间格式错误

本地化数字格式（小数点、千位分隔符）错误 本地化货币单位或格式错误 本地化度量单位错误 本地化纸张大小错误

本地化电话号码和邮政编码错误 双字节字符错误（Error DBCS） 不支持双字节字符的输入 双字节字符显示乱码

不能保存含有双字节字符内容的文件 不能打印双字节字符

尤其是一下几个问题在软件本地化的测试过程中更要关注： ➢ 1）语言翻译问题

语言测试肯定需要检查语言翻译的质量，但只是把语言翻译过来就可以了，而要使翻译过来的文字和图片更有意义，对用户的易用性要好才行。质量不高的翻译，尤其是拙劣的翻译往往会用户产生歧义，甚至反感。

除了语言的翻译外，还需要考虑用户的国家和地理位置，使软件适应特定地域特征，照顾到语言、方言、地区习俗和文化的过程被称为本地化，测试此类软件被称为本地化测试。

虽然翻译只是整个本地化工作的一部分，但是从测试角度看这是重要的一环。最明显的问题是如何测试用其他语言做的产品。那么，软件测试员或者测试小组至少要对所测试的语言基本熟悉，能够驾驭软件，看懂软件显示的文字，输入必要的命令执行测试，必要的时候可以外请语言专家来解决

142

企业应用软件测试实训课程

此问题。

➢ 2）ASCII、DBCS和Unicode

大家知道，ASCII只能表示256种不同的字符——远不足以表示所有语言的全部字符。当开始为不同语言开发软件时，就需要找到克服改度解决方案。在MS－DOS时代常用的，而且今天仍然沿用的一个方法是使用称为代码页的技术。代码页实质上是ASCII表的代用品，每一种语言用一个代码页。

这种算法虽然有点儿笨，毕竟对于少于256个字符的语言还算可以，但是像中文、日文等包含数千个符号的语言就会有问题。某些软件使用称为DBCS（双字节字符集）的系统提供256个以上的字符。用两个字节代替一个字节最多可容纳65535个字符。

代码页和DBCS自许多情况下足够了，但是对付不了某些问题。最重要的是兼容性问题。如果在联想计算机上运行英文字处理程序，读入西班牙文档，很可能显示乱七八糟。没有相应当代码页或者相互之间的转换，字符就不能正确解释，甚至根本认不出来。

解决这个麻烦的方法就是使用Unicode标准。Unicode为每一个字符提供了唯一编号，无论何种平台，无论何种程序，无论何种语言，字符表示都是唯一的。因为Unicode是世界标准，为主要软件公司、硬件生产厂商和其他标准组织支持，所以它变得更加通用。大多数软件应用程序都支持Unicode。 ➢ 3）热键和快捷键

软件的热键和快捷键与对应当功能名称文字是相对的，但是程序转为其他语言时，这些热键和快捷键也要进行更改，以不降低软件的易用性，比如我们经常可以看到的日文键盘。同时，也不能忘记检查这些热键和功能键是否被禁用和使用不正常。 ➢ 4）字符计算

与扩展字符有关的问题是软件对其进行计算时如何解释。最典型的两种文字排序和大小写转换。所以在测试时，要考虑以下排序问题：

测试点软件对文字列表排序或者按字母排列吗？ 都对哪些对象进行排序？

如果能排序，那么以何种方式排序？ 对于汉化的软件，排序是否按笔画排序？

对于大小写问题，原来我们学习转换“技巧”是在字母的ASCII值上加/减32，但这不适用于扩展字符。所以，在测试时也要把此问题考虑到，仔细检查软件是否有对字母和文字计算的其他情况，比如拼写检查。 ➢ 5）阅读方向

我们平时的测试中肯定不会考虑这个问题，因为我们都是从左向右读，包括英文软件，但是，对于阿拉伯文等却是从右向左读。虽然大多数操作系统提供了处理这些语言的内部支持，但即便如此，翻译这样的文本也不是容易的事。利用操作系统的特性来实现需要大量编程工作。从测试的角度看，

143

企业应用软件测试实训课程

要以把它当作全新的产品心态来执行测试，而不能简单地执行。 ➢ 6）图片中的文字

很多图片中有文字，但软件一般只是把它仅当作图片处理，编码人员也容易把他忽视掉。所以，测试人员要检查程序是否做了适当地修改，以反映新的语言。 ➢ 7）文字脱离代码

使文字脱离代码，也就是说所有文本字符串、错误提示信息和其他真正可以翻译的内容都应该存放在与源代码的文件中，应该杜绝在代码中出现这些与语言相关的字符串。

很多本地化人员不是程序员，也却是没有必要是。让程序员修改源代码，并进行语言翻译，既没有把握，也没有必要，因为需要修改的是称为资源文件的简单文本文件，该文件包含软件可以显示的全部信息。当软件运行时，通过查找该文件来引用信息，不管信息的内容是什么。无论信息时英文还是塞内加尔文，都是一样显示。

不过，还有一个问题就是：某些文本信息时动态组合和显示的，而不同的语言会有不同大语法，这样可能会造成信息的凌乱，测试人员在测试前要把需要这些信息收集好，以便测试时重点考虑。 ➢ 8）有边界争议的地图

这一点是特别想提及的一点，边界争议很多时候是很难确定的，我们生活的地球上太多的地方有这种边界冲突，而这种软件一旦处理不妥当是会在本地化的过程中遇到极其严重的问题，显然很多土地的归属权是不能由我们测试工程师来确定的，所以如果你测试的软件涉及到这些方面的问题的话，一定要和你的上级来进行沟通，明确这些问题才好。

软件测试是软件质量保证的关键步骤。其中，对于不同企业的不同类产品、同一企业的不同类产品、或不同企业的同一类产品，实际操作上都会有很大的不同。汉化软件的测试工作更有其特殊性，不同于一般软件的测试。 2.3软件汉化测试 2.3.1测试的目的

1 、确保产品完成了它所承诺或公布的功能，并且所有用户可以访问到的功能都有明确的书面说明 ; 一般测试只需要测试出产品的功能，并测试出是否与书面说明一致就可以的了。而汉化测试则必须先测试出原版中承诺的功能是否都具有，还要测试出汉化后的功能与原版是否相同，并找出原因。 2 、 确保产品满足性能和效率的要求。软件汉化后往往性能和效率都有一定距离，测试除了测试出原版和汉化版的性能和效率外，还要找出原因。

3 、确保产品是健壮的和适应用户环境的。一般原版都是在非中文的环境下运行，汉化后在中文的环境下运行。汉化测试还需测试出在不同环境下不同版本的健壮性和适应性。

当然，软件测试员的目标是一致的：尽可能早、尽可能多的找出软件缺陷，并关闭软件的缺陷。

144

企业应用软件测试实训课程

2.3.2测试的计划

“工欲善其事，必先利其器”。专业的测试必须以一个好的测试计划作为基础。一个测试计划应包括：产品基本情况调研、测试需求说明、测试策略和记录、测试资源配置、计划表、问题跟踪报告、测试计划的评审、结果等等。其中，汉化测试的侧重点与一般测试不同，则重于测试需求说明中的功能和整体测试、测试策略和记录、问题追踪报告等等。 2.3.3测试的方法

软件测试的方法和技术是多种多样的，可以从不同的角度加以分类：从是否需要执行被测软件的角度，可分为静态测试和动态测试；从测试是否针对系统的内部结构和具体实现算法的角度来看，可分为白盒测试和黑盒测试；从软件测试的组成的角度来看，可分为单元测试、综合测试、确认测试、系统测试。

汉化测试一般包含有单元测试、综合测试、确认测试、系统测试等等。 1、单元测试

汉化测试的单元测试可分为两部分：汉化前和汉化后。

汉化前、后的单元测试都必须包括以下任务：（1） 模块接口测试； （2） 模块局部数据结构测试； （3） 模块边界条件测试； （4） 模块中所有执行通路测试； （5） 模块的各条错误处理通路测试。

单元测试过程：主要为取得原版中的单元代码，进行复查、编译的同时进行单元测试。在单元测试中，详细记录整个测试过程：包括方式、边界值、数据等，并考虑用同样的方法在汉化版的测试中会得到的结果。汉化后，利用原版的单元测试的资料进行测试，并以原版所考虑的结果进行对比。如结果出入较大，应增加汉化版的测试任务。 2、综合测试:

时常有这样的情况发生，每个模块都能单独工作，但这些模块集成在一起之后却不能正常工作。主要原因是，模块相互调用时接口会引入许多新问题。例如，数据经过接口可能丢失；一个模块对另一模块可能造成不应有的影响；几个子功能组合起来不能实现主功能；误差不断积累达到不可接受的程度；全局数据结构出现错误，等等。

在单元测试完成后，必须分别在原版和汉化版中进行综合测试。

在原版中，一般采取自顶向下集成。自顶向下集成是构造程序结构的一种增量式方式，它从主控模块开始，按照软件的控制层次结构，以深度优先或广度优先的策略，逐步把各个模块集成在一起。原版用这种方法是因为：自顶向下集成的优点在于能尽早地对程序的主要控制和决策机制进行检验，因此较早地发现错误。在测试较高层模块时，所需的下层模块功能均已具备，所以不再需要桩模块。 在汉化版中，一般采取自底向上集成。自底向上测试是从 \" 原子 \" 模块（即软件结构最低层的模块）开始组装测试，因测试到较高层模块时，所需的下层模块功能均已汉化，所以不再需要桩模块。汉化版用这种方法是因为：测试用例的设计亦相对简单。 3、确认测试：

145

企业应用软件测试实训课程

在综合测试结束后，汉化的主要工作也做完了。这里的确认测试主要是汉化版的测试，并可利用原版中的测试数据等进行汉化版的确认测试。此外，还需要汉化版的特点进行一些额外的确认测试。 确认测试就是检查软件能否按合同要求进行工作，即是否满足软件需求说明书中的确认标准。 实现软件确认要通过一系列墨盒测试，着重考虑软件是否满足合同规定的所有功能和性能，文档资料是否完整、准确人机界面和其他方面（例如，可移植性、兼容性、错误恢复能力和可维护性等）是否令达到汉化前的要求。汉化测试一般用α测试，即是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品（称为 α版本）进行测试，试图发现错误并评估。

确认测试的结果有两种可能，一种是功能和性能指标满足软件汉化前的要求，可以进行汉化；另一种是软件不满足软汉化前的要求，无法汉化，必须退回原版公司重新修改。确认测试是软件汉化前的一项必须的工作。 4、系统测试：

为了节省时间和开支，只需在汉化版中进行系统测试。系统测试应该由若干个不同测试组成，目的是充分运行系统，验证系统各部件是否都能政党工作并完成所赋予的任务。系统测试的任务是：（１）、恢复测试；(２)、安全测试；(３)、强度测试；(４)、 性能测试； (5) 、系统兼容性测试。其中，系统兼容性测试包含：操作系统兼容性、异构数据库兼容性、新旧数据转换、异种数据兼容性、硬件兼容性。

5、汉化测试的其他问题

汉化测试除了要进行上述的测试外，还必须有良好的外语基础，还跟一个人的素质、心理影响有很大的关系。

第十五章 安全性测试

如今计算机安全性属于业界讨论的比较多的问题之一。不可否认这其中有很多的炒作因素但是从另一个侧面也反映了安全性在如今确实提上了重要的议程。在日益加速的电子商业世界里尤其如此，不够安全的软件在某些情况下使人们失去职业，甚至丧失生命；不够安全的软件也能够导致一些公司消亡。

似乎每个人都知道或能够察觉到问题的所在，但知道如何克服的人很少。没有多少资源可用来指导开发人员如何编写安全的代码；而且，许多软件是以难以置信的速度并且是在极大的市场压力下开发的。在这种市场压力下首当其冲受到损害的通常是软件质量（任何种类的质量）。在最好的情况下安全性往往也只是事后的想法，而通常它都被完全遗忘。那不只是悲剧，还会造成灾难。 一、安全性测试概述

软件安全性是指一种由软件开发人员制定的一种策略，这种策略用来描述对于资源的访问规则。 对于不同的人所认识到的软件的安全性的概念都是不一样的，对于开发或者测试工作来说，可以认为软件的安全性就是一种策略，这种测略未授权用户对于资源的访问。比如：我们不允许用户登录系统，但是有些用户却通过某些方法实现了，那么就可以说这个安全策略被破坏了。同样，如果有人对我们的系统发动了拒绝服务攻击，而且成功实现，那么他就破坏了我们的服务或者产品的

146

企业应用软件测试实训课程

可用性策略。

通常许多情况下，我们并没有得到明显的安全策略，因为有些策略是隐蔽的，比如Windows系统的登录问题，在软件测试的过程中，虽然没有人会设计这样的测试用例，但是如果因为某一个软件的使用而影响了用户登录的安全性，那么就可以说这个软件就存在登录安全漏洞。

软件安全性与所谓得信息安全攻击技术是有区别的：并不是所有得信息安全技术都可以应用与软件安全性问题。信息安全技术中得很多内容虽然会威胁到系统的安全，但这些并不是软件开发者需要关注的范围，所以也就谈不上什么软件的安全性。比如：木马技术。通常我们在一些安全性论坛或者一些安全性杂志上可以看到一些相关的安全性资料谈到一些已经发现的软件的安全性漏洞，但是这些资料除了对于我们的在软件开发的过程中有借鉴作用，使得我们尽量避免犯同样的错误以外，对于软件的开发过程作用却不是很大。比如，最近微软有公布了一些IIS的漏洞，可是这些漏洞对于软件的开发者帮助却不一定十分的明显。关注安全性的开发者更应该关心如何避免在自己的软件中产生这些问题，而测试者更应该关注这些问题是如何被发现的。相反，关注信息安全的管理员对于网站公布的漏洞信息却是非常关注的，因为他们需要根据这些信息来迅速的完成补丁系统。 对于另外的一些信息比如：设备、资源等安全性属于软件安全性关注的范围，但是信息安全领域却很少涉及。所以软件安全性与信息安全性的研究范围还是有很大区别的。

通常认为可靠性与安全性是有很大的相关性的，因为两者有很多的相同点。可靠性是一种软件坚固性的度量，这种度量是与维持指定性能水平相关的；安全性也是一种软件坚固性的度量，这种度量是与安全策略相关的。通常来说安全策略从某些侧面上讲也是一种性能水平，所以有人认为安全性应该是可靠性的一个子集。但是我不赞成这个观点，可以认为可靠性是除了安全性以外其他性能的表现情况。

二、安全性测试要考虑的问题 2.1两个常见到安全性错误

软件开发团队一般会犯两个主要的典型错误。

第一个错误是直来直去。应用程序被设计、编码、测试、然后发行给用户，但是开发人员经常忘了考虑它的安全性。或者他们认为已经考虑了，但是他们却做了错误的设计。设计错误的原因是，他们在应用程序中添加了一些安全技术来赶时髦，但是这些技术不能减轻任何实际的安全威胁。安全设计经常是只关闭了一些漏洞，但是没有关闭产生潜在危险的全部漏洞。 第二个错误时事后才考虑给应用程序添加安全。避免出现这种情况的原因如下： 事后添加安全是在已有的功能外包裹上安全，而不是将功能和安全综合起来设计。 事后添加任何功能，包括安全性，其代价都是比较昂贵的。

添加安全可能会影响你已经实现的功能，这种影响的代价也是比较昂贵的。 添加安全可能会改变应用程序的接口，这可能导致依赖当前接口的代码不可运行。

另外，如果软件应用用户人群是非专家用户，那么软件安全设计更加要小心，原因是虽然用户要求安全的环境，但是他们不希望安全是“绊脚石”。对于这样的用户来说，安全应该被隐藏不可见，这

147

企业应用软件测试实训课程

是一个努力实现的目标，也是安全性测试要考虑到的问题。 2.2安全性测试标准

信息产品通用测评准则（CC/ISO 15408）和安全系统工程能力成熟度模型（SSE-CMM）是两个国际上比较通用的软件安全性标准。

信息产品通用测评准则（CC/ISO 15408），简称CC，等同于GB/T 18336 2001：《信息技术安全技术信息技术安全性评估准则》，是评估信息技术产品和系统安全性的基础准则。是在美国、加拿大、欧洲等国家和地区分别自行推出测评准则并具体实践的基础上，通过相互间的总结和互补发展起来的。CC定义了作为评估信息技术产品和系统安全性的基础准则，提出了目前国际上公认的表述信息技术安全性的结构，即把安全要求分为规范产品和系统安全行为的功能要求以及解决如何正确有效的实施这些功能的保证要求。功能和保证要求又以“类--子类--组件”的结构表述，组件作为安全要求的最小构件块，可以用“保护轮廓”、“安全目标”和“包”的构建。

安全系统工程能力成熟度模型（SSE-CMM），起源于美国(NSA) 于1993年4月提出的一个专门应用于系统安全工程的能力成熟模型（CMM）的构思。1996年10月出版了SSE-CMM模型的第一个版本，1997年4月出版了评定方法的第一个版本。

目的是建立和完善一套成熟的、可度量的安全工程过程。该模型定义了一个安全工程过程应有的特征，这些特征是完善的安全工程的根本保证。这个安全工程对于任何工程活动均是清晰定义的、可管理的、可测量的、可控制的并且是有效的。SSE-CMM模型及其评定方法汇集了工业界常见的实施方法，提供了一套业界范围内(包括及产业)的标准度量体系，确保了在处理硬件、软件、系统和组织安全问题的工程实施活动后，能够得到的一个完整意义上的安全结果。SSE-CMM还用于改进安全工程实施的现状，达到提高安全系统、安全产品和安全工程服务的质量和可用性并降低成本的目的。目前，SSE-CMM已经成为西方发达国家、和要害部门组织和实施系统安全工程的通用方法，是系统安全工程领域里的成熟方法体系，在理论研究和具体实践中具有举足轻重的作用。

2.3安全性的目标

软件安全性是一个动态相对性概念，没有任何的软件是百分之百安全的。所以对于最初设置安全性标准的软件制订者应该考虑的是这个软件应该达到怎么样的一个安全度。我们想要保护什么，防范谁？怎么样的一个防范就算是达到了目标？

最常见的安全性目标有以下几个方面预防、跟踪和审计、监控、保密性和机密性、多级安全性、匿名性、认证、完整性。

预防：预防就是说能够预测到软件可能遇到的问题，将问题消灭与未然。但是在软件的开发过程中，关注软件安全性的预防是没有什么实际意义的。

跟踪与审计：并不是所有的问题都是可以预见的，所以当一个系统遇到攻击以后必须能够及时的记录入侵者的实际情况，这就是跟踪和审计。当然很多的操作系统都是用日志来记录这些信息的，而一个很令人遗憾的问题是这些日志经常会被破坏。但是，即使如此跟踪与审计仍然是软件安全性的一个重要组成部分。

148

企业应用软件测试实训课程

监控：是指实时的审核，能够对资源的使用情况进行及时的了解。例如对于网络流量和日志文件的入侵检测就是一种监控系统。而这样作同样有问题——不得不面对大量的信息而“去伪存真”。 保密性和机密性：这包含了两个方面的概念，一个是使用软件的用户的信息不能被软件泄漏，另外的一个方面是软件的一些信息不能够让软件的使用者随意得到。比如：如果一个拨号程序可以获取当前用户所使用的电话号码，如果软件向一些组织透露了这个用户的喜好信息，那么对于这个用户来说是不公平的，相反如果开发这在软件中隐藏的某些信息能够被轻易获取，那么这个软件同样是不安全的。

多级安全性：通常对于安全的需求有不同层次的理念，所以对于信息进行安全多级分类也是必要的，例如：普通、秘密、机密、绝密，从低到高，保密的程序不同。

匿名性：匿名是一把双刃剑，一方面我们有正当的理由支持匿名访问，另一个方面许多的程序有需要对网络中的匿名访问进行跟踪，所以在软件的开发过程中对于匿名性的支持也是开发经理应该及早入手考虑的一个问题，是否支持匿名，支持到一个什么样的程序。 认证：认证非常关键。软件安全性的许多问题都可以归结为软件的认证问题。

完整性：完整性与认证是相似的，但是完整性通常是认证的后续手段。可以认为，完整性是对整个过程的完整认证过程。比如一次TCP/IP的连接过程，认证是指第一次的握手，而完整性是指后续的确认手段。

通常认为保密性与机密性、认证、完整性是软件安全性的三大基本目标。 三、安全性测试设计

安全性测试设计即指安全性测试用例的设计，它包括：需要测试哪个应用程序和应用程序中的哪些组件，对每一个组件做哪些安全假设，每个组件的哪些安全因素需要测试，预期的结果是什么。该过程包括以下几步：

将应用程序分解成基本的组件。 确定组件的接口。

按照潜在的隐患给接口分级。 确定每一个接口使用的数据。

通过注入不合适的数据来发现安全问题。 下图表示了如何有效地分解一个应用程序。

149

企业应用软件测试实训课程

应用程序 组件1 组件2 组件3 接口1 接口2 数据1

数据2 图 ：安全性测试设计

数据3 下面我们具体讨论一个安全性测试设计的每一个方面。 1）分解应用程序。

安全性测试设计的第一步，就是要求确定应用程序的结构。大多数应用程序是由组件组成，例如ASP页面或ASP.NET页面、DLL、EXE，以及对象组件技术，例如COM每一个组件都有的功能。事实上，如果组件不输出任何功能，那么应用程序就不需要包含它了。

为了列出应用程序的组件，测试人员通常可以咨询集成人员。毕竟，他们集成是必须清楚所有需要的功能块。然而，还不完全这样简单：因为应用程序可能会重用操作系统中的组件，或者某些需要的功能是从其他应用程序中继承过来的。虽然测试代码本身非常重要，但没有哪个应用程序是在真空中，不与其他发生关系的。因此，各个分支环境中的安全性也是必须考虑的，需要判断程序使用的外部组件的安全性。 建立应用程序的技术如下所示： 可执行文件，包括DLL和EXE。 服务。

ISAPI应用程序和过路器。 ATL服务组件。

脚本文件，例如命令文件（.BAT和.CMD），VBScirpt、Jscript和Perl。 ASP和ASP.NET页面（ASPX）。 CGI脚本。 HTML页面。 COM组件。

150

企业应用软件测试实训课程

2）确定组件接口。

接下来就要确定每个组件提供的接口。这是很关键的一步，因为试用接口代码是测试人员发现安全类BUG的一种途径。要了解每一个组件所提供的接口，建议测试人员既要仔细查看设计文档，也要多咨询设计和编码人员。接口和传输技术包括： TCP和UDP socket。 无线数据。 NetBIOS。 Mailslot。 DDE。 命名管道。 共享内存。 其他命名对象。 剪贴板。

LPC（Local Procedure Call，本地过程调用）和RPC（Remote Procedure Call，远程过程调用）接口。 COM方法、属性和事件。 EXE和DLL函数。

核心模式组件使用的系统中断和输入/输出控制（IOCTL）。 注册表。 HTTP请求。 SOAP请求。

RAPI（远程API），它由掌上电脑使用。 控制台输入。 命令行参数。 对话框。

数据库访问技术，包括OLE DB核ODBC。

存储转发接口，例如电子邮件使用的SMTP、POP、MAPI，或者是队列技术，例如MSMQ。 环境（环境变量）。 文件。

LDAP源，例如活动目录。

151

企业应用软件测试实训课程

硬件设备，例如使用IrDA（红外线数据连接）的红外线、USB、COM端口、Firewire等。 3）依照隐患的相对大小对接口进行排序。

测试人员需要对所有列出的具有安全隐患的接口进行排序，确定测试先后次序，这样做的道理很明显，隐患大的接口应该做更充分的测试。判断一个接口隐患的大小，可以使用一种简单的记分制。 4）确定每一个接口使用的数据。

主要是确定好每一个接口访问的数据来源是什么。 5）通过注入错误的数据发现安全问题。

通过使用错误注入法，来设计出具体测试过程，这里主要是说扰乱环境，使得处理数据的代码处于不安全的状态。下图所示为干扰应用程序环境的技术。

部分不正确 随机 NULL 错误的类型 长度为零 重放 内容 不同步 注入故障技术数据高音量 内容 的安全措施 大小 应用于再现数据 长 不存在 短 图：干扰应用环境的技术

容器 链接 名称 不访问 不存在 受限访问 存在 具体的技术应用我们这里就不做过多介绍，因为它牵涉很多安全技术本身的问题。 四、安全性测试其他问题

还有几个问题，对于安全性测试很重要，这里还要提及出来。 1）软件的安全目标

在做安全性测试之前，测试人员需要了解安全性需要达到的目标，一般要考虑以下问题： 应用程序的使用者是谁？

对使用者来说，安全意味着什么？对使用者中不同的成员来说，安全是否有不同的含义？不同的顾

152

企业应用软件测试实训课程

客是否有不同的安全需求？

应用程序会在何处运行？是在因特网上运行吗？是在防火墙后面运行吗？是在一个蜂窝电话上运行吗？

你要试图保护什么？

如果你保护的对象受到损害，这对用户意味着什么？ 管理应用程序的人是谁？是用户还是公司的IT管理员？

软件的通信要求是什么？是局域网范围还是城域网或广域网进行通信，或者兼而有之？ 操作系统和环境已经给你提供了哪些可以利用的安全基础服务？ 2）缓冲区溢出

缓冲区溢出一直以来是一个众所周知的安全问题，号称是互联网上的头号公敌。对于缓冲区溢出的影响，其实是非常严重的，大家可以到网上找到很多相关介绍资料。

“出现缓冲区一处这个问题的原因主要是不良的编程习惯。事实上，C语言和C++语言都为程序设计人员提供了很多“搬石头砸自己的脚”的方法，缺乏安全可靠、简便易行的字符串处理后果，还忽略了错误的后果”。（引自《编写安全的代码》一书）

缓冲区溢出包括不同类型，数组索引错误，格式化字符串BUG以及Unicode和ANSI之间缓冲区大小不匹配。具体内容这里也不加以介绍，但作为测试人员在安全性测试时，要把缓冲区溢出作为测试考虑的要点之一。 3）软件安装安全性测试

软件安装过程是有关应用程序安全性方面，最需要检查的因素之一，并且安装错误占据了安全补丁中相当大的比例。另外，很多安装软件没有考虑安全设置的问题。所以，软件安装的安全性测试也是需要测试人员要考虑的问题。

在做安装安全性测试时，测试人员可以参照最低权限原则（只给用户那些他完成工作所必要的权限，而不能给他更多的权限）、使用安全配置编辑器，并且考虑开发人员是否使用了低层的API来提高安全性。

五、十条安全法则

以下是为人家安全领域专家总结出的十条安全法则，供测试人员参考。

如果有一个坏小子能说服你，在你的计算机上运行他的程序，那么这台计算机就不再是你的了。 如果一个坏小子能够警告你计算机上的操作系统，那么这台计算机就不再是你的了。 如果一个坏小子能从物理上，没有地访问你的计算机，那么这台计算机就不再是你的了。 如果你允许一个坏小子给你的Web站点上传程序，那么这个Web站点就不再是你的了。 口令小却胜过任何强壮大安全系统。

153

企业应用软件测试实训课程

一台机器只有当管理员是值得信任的时候，才是安全的。 加密数据只有当解码秘钥是安全的时候，才是安全的。 一个过期的查毒软件也就比根本就没有查毒软件略好一点。 无论是在现实生活中还是在Web上，绝对的匿名是不现实的。 技术不是万能药。

六、案例——使用五个安全测试步骤来保护你的应用程序

你可以不必找一个黑客或者解密高手来测试你程序的安全性，也不需要购买一大堆昂贵的黑客工具。但是，你必须有一套处理过程来发现潜在的问题。如果遵从我下面详细介绍的五个处理步骤，你就可以轻松发现一般的开发缺陷。而且一旦发现了这些缺陷，就可以减轻或消除他们。 步骤一：端口扫描

你需要做的第一件事是在客户端和服务器端进行一次端口扫描，找出那些打开但并不需要的通讯端口。各种服务如FTP、NetBIOS、echo、gotd等使用的端口是引起安全问题的典型因素。对于TCP和UDP端口来说，根据经验通常的做法是：关掉任何程序运行所不需要的服务或。 端口扫描被用来检测目标系统上哪些TCP和UDP端口正在监听，即等待连接。大多数的计算机默认地打开了许多这样的端口，黑客和破解者经常花很多时间对它们的目标进行端口扫描来定位，这是他们开始攻击的前奏。一旦这些端口都被鉴别出来，要使用它们也就不困难了。 端口扫描工具，通常叫端口扫描器，很容易在Internet上找到。其中很多是基于Linux的。例如Namp、Strobe、 Netcat是比较好的一类。我最喜欢的基于Linux的端口扫描器是Nump。也有许多基于Microsoft Windows的端口扫描器，其中我最喜欢的是Ipswitch的WS Ping ProPack。WS Ping ProPack是一个低开销、多用途的网络问题定位工具，它将许多功能包装成简单易用的形式。

有了端口扫描器后，对全部TCP和UDP端口进行一次完整的检查来确定哪些端口是打开的。将监测到的打开的端口与系统运行所需要用到的端口进行比较，关闭所有没有用到的端口。在Microsoft操作系统中关闭端口经常需要重新配置操作系统的服务或者修改注册表设置。UNIX和 Linux系统就简单一些：通常只是将配置文件中的某一行注释掉。 步骤二：检查用户帐户

接下来，需要将目光转移，看看操作系统、任何数据库以及程序自身，特别注意guest用户帐户、默认账户或者简单密码账户以及不需要的用户ID。之所以需要这样做是因为大多数的默认设置留下了许多漏洞，创建了多余的账户，它们可能会被用来危及系统的安全。这种情况在使用数据库系统如Oracle或Web服务器如Microsoft Internet Information Services （IIS）时特别突出。

我曾经通过使用本不该存在或应被禁止的用户ID和密码登陆进入过许多路由其、数据库和应用程序中。例如，若干年前，在测试一个简单的Web应用程序时，我尝试用Guest 账户ID和空密码登陆进系统。很出乎我的意料，程序很爽快地将Guest作为合法用户并允许我登陆。然后我又试了几个其它的账户，如输入用户ID和密码为空/空或管理员/管理员，结果都成功了。

154

企业应用软件测试实训课程

有了这次经验，我总是在软件安装手册的每一章寻找默认的账号和密码。我建立了一份这些默认账号和密码的列表，以确保能够把找到过的都试试。对于程序本身我也这样做，建立一份由程序员创建的测试用户帐户，也把它们试试。

测试这些东西能够帮助发现危害系统的途径，禁用和删除不必须的账户是一种消除找到的缺陷的一种方法。对于通讯端口也有一个相似的方法：禁用任何系统运行所不需要的用户ID。如果某个用户ID不能被禁用，那么至少改变它的默认密码，使其不易被破解。

你会问，怎样才算一个好的密码？它地长度至少为六到八个字符，并含有一个特殊字符。密码必须足够长，以使其不易被破解，但是必须能够容易记住——这是难以两全的。我喜欢使用缩写词或者容易记忆的设备。千万别用任何易猜的单词或习语，这是一个常见的密码失误。同样的，不要使用字典中的单个词语。我记忆最深刻的差密码之一是ROLLTIDE，这是我在阿拉巴马州大学一台被丢弃的机器上发现的（这所大动队的昵称是Crimson Tide）。 步骤三：检查目录许可

检查目录许可 在关闭了无用端口并禁用了多余的账号后，仔细检查一下程序所用到的数据库和服务器目录的权限设置。很多攻击利用了配置失误的权限，这种方法经常被用来攻击Web服务器。 例如，使用CGI脚本的Web站点有时允许写访问。通过它，一个恶意的供给者可以很简单地在CGI二进制目录下放置一个文件。然后他就能够调用这个脚本文件，Web服务器会运行它，典型地在管理员权限下。能够写并执行脚本是非常危险的，要开放这些权限应该格外小心。

FTP给了我对每台机器上真正存放密码文件的访问权限，真是一个巨大的配置失误。由于权限如此设置，我不仅可以下载存放密码的文件，而且可以通过把密码文件中的密码修改后再上传给服务器覆盖源文件而使这些用户“中毒”。当然我将自己授予了root访问权，从而取得了机器的管理员权限。

如果正确地设置了目录权限，我就不能访问被指定给匿名用户使用的FTP目录以外的任何东西。因此，我本不能够得到真正存放密码的文件，更别提将其替换了。当然，如果他们曾经做过任何自己的端口扫描，就像我在步骤一里提到的，那么用这种方法我将哪里也到不了。 步骤四：对数据库也进行和上面同样的设置

文件系统不是唯一因权限设置不当而会受到攻击的对象。大多数的数据库系统有很多安全漏洞。它们的默认权限设置通常不正确，如打开了不必要的端口、创建了很多演示用户。一个著名的例子是Oracle的演示用户Scott，密码为Tiger。加强数据库安全的措施与操作系统一样：关闭任何不需要的端口、删除或禁用多余的用户，并只给一个用户完成其任务所必需的权限。 步骤五：关上后门

你对必须经过几个步骤来测试被应用程序包装得很深的功能感到厌倦了吗？能够建立一个直观的快捷方式吗？其实大家都这么想。问题在于这些快捷方式——也被叫做后门，经常被忽略或遗忘，而有时它们又会不经意地连同应用程序一起被发布。任何严格的安全测试程序都因该包括检查程序代码中不经意留下的后门。

另一个真实的因后门而引发安全问题的例子是Solaris操作系统的早期版本的[Ctrl]K错误。上世纪

155

企业应用软件测试实训课程

90年代早期的Solaris用户只需以一般用户身份登陆并按两次[Ctrl]K就可以获得root权限。 为了寻找后门，必须完整地检查源代码，查找基于非预期参数的条件跳转语句。例如，如果某个程序是通过双击图标而被调用的，那么要确保代码不会因为从命令行用特殊参数调用而跳转到某个管理或模式。 第十六章 嵌入式测试 一、嵌入式系统概述

嵌入式系统（Embedded System）的含义在于结合微处理器或微控制器的系统电路与其专属的软件，来达到系统操作效率的最高比。在后PC时代，家电、玩具、汽车、新一代手机、数码相机、先进的医疗仪器乃至于即将到来的智能型房屋、智能型办公室及其他跟电有关的器材设备中，嵌入式系统这个核心技术必不可少。

从某种意义上来说，通用计算机行业的技术是垄断的。占整个计算机行业90%的PC产业，80%采用Intel的8x86体系结构，芯片基本上出自Intel，AMD，Cyrix等几家公司。在几乎每台计算机必备的操作系统和文字处理器方面，Microsoft的Windows及Word占80-90%，凭借操作系统还可以搭配其它应用程序。因此当代的通用计算机工业的基础被认为是由Wintel(Microsoft和Intel 90年代初建立的联盟)垄断的工业。嵌入式系统则不同，它是一个分散的工业，充满了竞争、机遇与创新，没有哪一个系列的处理器和操作系统能够垄断全部市场。即便在体系结构上存在着主流，但各不相同的应用领域决定了不可能有少数公司、少数产品垄断全部市场。因此嵌入式系统领域的产品和技术，必然是高度分散的，留给各个行业的中小规模高技术公司的创新余地很大。另外，社会上的各个应用领域是在不断向前发展的，要求其中的嵌入式处理器核心也同步发展，这也构成了推动嵌入式工业发展的强大动力。

嵌入式系统工业的基础是以应用为中心的“芯片”设计和面向应用的软件产品开发。 嵌入式系统具有的产品特征：

嵌入式系统是面向用户、面向产品、面向应用的，如果于应用自行发展，则会失去市场。嵌入式处理器的功耗、体积、成本、可靠性、速度、处理能力、电磁兼容性等方面均受到应用要求的制约，这些也是各个半导体厂商之间竞争的热点。

和通用计算机不同，嵌入式系统的硬件和软件都必须高效率地设计，量体裁衣、去除冗余，力争在同样的硅片面积上实现更高的性能，这样才能在具体应用对处理器的选择面前更具有竞争力。嵌入式处理器要针对用户的具体需求，对芯片配置进行裁剪和添加才能达到理想的性能；但同时还受用户订货量的制约。因此不同的处理器面向的用户是不一样的，可能是一般用户，行业用户或单一用户。

嵌入式系统和具体应用有机地结合在一起，它的升级换代也是和具体产品同步进行，因此嵌入式系统产品一旦进入市场，具有较长的生命周期。嵌入式系统中的软件，一般都固化在只读存储器中，而不是以磁盘为载体，可以随意更换，所以嵌入式系统的应用软件生命周期也和嵌入式产品一样长。另外，各个行业的应用系统和产品，和通用计算机软件不同，很少发生突然性的跳跃，嵌入式系统中的软件也因此更强调可继承性和技术衔接性，发展比较稳定。

156

企业应用软件测试实训课程

嵌入式处理器的发展也体现出稳定性，一个体系一般要存在8-10年的时间。一个体系结构及其相关的片上外设、开发工具、库函数、嵌入式应用产品是一套复杂的知识系统，用户和半导体厂商都不会轻易地放弃一种处理器。

由此可知，嵌入式系统是将先进的计算机技术、半导体技术和电子技术与各个行业的具体应用相结合后的产物，是软件与硬件的综合体，这一点就决定了它必然是一个技术密集、资金密集、高度分散、不断创新的知识集成系统。其中硬件的设计包括单片机控制电路的设计、网络功能设计、无线通信功能设计及使用接口等等；嵌入式软件为信息、通信网络或消费性电子产品等中的必备软件，可提升硬件产品的价值。在现今硬件技术大幅进步的情况下，硬件并不强调执行速度，而是功能稳定，反而在软件组织方面，强调的是系统整合及友善的用户界面，随着网络与无线通信技术的广泛应用，未来的软件将由现行的简易视窗与低速通信朝向高带宽通信与多样化的用户界面发展，有着极大的增长空间。 二、嵌入式操作系统

操作系统可以简单解释为补平硬件差异的接口或者说硬件隐藏，让应用程序可以在上面操作，通过由操作系统统一提供出来的系统接口写应用程序，毋须考虑到不同硬件所造成的差异，让程序设计人员能够专注于擅长领域的开发。

嵌入式操作系统是一种实时的、支持嵌入式系统应用的操作系统软件，核心通常要求很小，因为硬件的ROM 容量有限。一般情况下，它可以分成两类：一类是面向控制、通信等领域的实时操作系统，如WindRiver公司的VxWorks、Accelerated Tech.公司的Nucleus系列等；另一类是面向消费电子产品的非实时操作系统，这类产品包括个人数字助理（PDA）、移动电话、机顶盒等，如Windows CE、Palm OS、嵌入式Linux和EPOC等。 几种流行的嵌入式操作系统的比较：

表： 几种嵌入式操作系统比较

嵌入式操作系统 优点 不足 多媒体功能、更强的Internet功能、高度Windows CE 模块化、很好的开发支持环境、与Windows系列兼容。 跨平台、裁剪性好、性能稳定、开放源代Linux 开发速度快、支援软件有限。 非开放导致很难定制、应用程序庞大、非高效节能、版权费、昂贵。 自身过于庞大、开发难度较码、内核小、效率高、免费、无线连接、高、标准未成形。 Palm OS 众多支持软件、市场占有率高、开放系统、授权困难。 有3COM、Sony、IBM等支持、简单实用。 来自欧洲的操作系统，由世界上三大移动电话厂商诺基亚、爱立信、摩托罗拉共同功能以手机为主，并不打算授权。 EPOC 157

企业应用软件测试实训课程

开发，市场潜力很大。 未来竞争焦点 无线网络功能 三、嵌入式系统软件的特征

嵌入式处理器的应用软件是实现嵌入式系统功能的关键，对嵌入式处理器系统软件和应用软件的要求也和通用计算机有所不同。 (1) 软件要求固态化存储

为了提高执行速度和系统可靠性，嵌入式系统中的软件一般都固化在存储器芯片或单片机本身中，而不是存贮于磁盘等载体中。 (2) 软件代码高质量、高可靠性

尽管半导体技术的发展使处理器速度不断提高、片上存储器容量不断增加，但在大多数应用中，存储空间仍然是宝贵的，还存在实时性的要求。为此要求程序编写和编译工具的质量要高，以减少程序二进制代码长度、提高执行速度。 (3) 系统软件(OS)的高实时性是基本要求

在多任务嵌入式系统中，对重要性各不相同的任务进行统筹兼顾的合理调度是保证每个任务及时执行的关键，单纯通过提高处理器速度是无法完成和没有效率的，这种任务调度只能由优化编写的系统软件来完成，因此系统软件的高实时性是基本要求。

(4) 多任务操作系统是知识集成的平台和走向工业标准化道路的基础

通用计算机具有完善的人机接口界面，在上面增加一些开发应用程序和环境即可进行对自身的开发。而嵌入式系统本身不具备自举开发能力，即使设计完成以后用户通常也是不能对其中的程序功能进行修改的，必须有一套开发工具和环境才能进行开发，这些工具和环境一般是基于通用计算机上的软硬件设备以及各种逻辑分析仪、混合信号示波器等。

通用计算机具有完善的操作系统和应用程序接口(API)，是计算机基本组成不可分离的一部分，应用程序的开发以及完成后的软件都在OS平台上面运行，但一般不是实时的。嵌入式系统则不同，应用程序可以没有操作系统直接在芯片上运行；但是为了合理地调度多任务、利用系统资源、系统函数以及和专家库函数接口，用户必须自行选配RTOS开发平台，这样才能保证程序执行的实时性、可靠性，并减少开发时间，保障软件质量。

嵌入式系统的产品可是最大的最多的，在日常电器中，我们的数字式产品，比如电饭锅，微波炉，数字式录音机，播放机，这些产品其实都是需要进行测试的。 四、嵌入式的测试方案

可到www.superst.com上下载CodeTest嵌入式测试系统。

美国AMC公司采用了专利——插桩技术开发出专为嵌入式开发者设计的高性能测试工具CodeTEST，

158

企业应用软件测试实训课程

它可以用于本机测试（native）或在线测试( in-circuit).

CodeTEST系列包括三种嵌入式软件测试和分析工具：CodeTEST Native，CodeTEST Software-In-Circuit和CodeTEST Hardtware –In -Circuit。其中每一种工具代表了嵌入式系统开发的每一个周期的不同开发阶段。我们以标号1、2、3来表示：

在开发阶段1，由于是开发的早期，没有目标硬件，所应采用的开发工具是桌面工具。 在开发阶段2，由于此时已开始，系统的集成工作，硬件开发板已出现。

在开发阶段3，此时项目已处于系统测试或确认阶段，任何疏忽、质量问题和性能缺现都会影响产品的发布、销售和盈利。

CodeTEST系列可以满足你选择适合自己测试类型：纯软件，驻留IDE硬件探头或同时选择以上所有三个测试的类型。

4.1 CodeTEST的突出特点：

性能分析可以实现代码的精确的可视化，从而大大提高提高工作效率，简化软件确认和查找故障的过程，

内存分析可以监视内存的使用，提前查处内存的泄漏，从而节约你宝贵的时间和成本。

代码追踪可以进行三个不同层次的软件运行追踪，甚至是追踪处理器内部的Cache，这样可以更容易的查找问题所在。

高级覆盖工具可以通过确认高隐患的代码段，显示哪些函数、代码块、语句、决策条件和条件以执行过或未执行过，来提高产品的质量。高级覆盖工具完全符合高要求的软件测试标准（如：RCTA/DO-178B，A级标准），可以实现语句覆盖、决策覆盖和可变条件的决策覆盖。 4.2CodeTEST在各开发阶段的应用 1、CodeTEST Native

在早期的开发阶段，采用CodeTEST Native的插桩器可以实现较快的软件测试和分析。虽然此阶段的测试和分析不是实时测试，但这是没有目标硬件连接时的最好的分析和查找问题的最好方法。采用CodeTEST，可以提高软件测试的代码覆盖率、查找和分析内存的泄漏和深度追踪来确保软件的正常运行。

2、CodeTEST Software-In-Circuit

当有硬件连接到测试系统时，我们就可以采用“target hardware”工具了。一般说来，在这一阶段，逻辑分析仪、仿真器和纯软件工具是用来确定系统是否正常工作，但是采用这些工具测试软件往往增加了工程师工作的难度和压力。而采用CodeTEST Software-In-Circuit，通过目标代理（tragrt agent）来测试和分析目标硬件就不需要硬件工具。

CodeTEST Software-In–Circuit插桩器还可以很方便的让你从CodeTEST Native的desktop-stimulated测试跳转到目标硬件的实时测试。跳转后，插桩器、脚本的文件格式和数据不受Native环境影响。而且，就学习Native和CodeTEST Software-In-Circuit的测试方法而言是差不多的。对于大多数在这

159

企业应用软件测试实训课程

两种开发阶段使用过其他的工具的开发者，CodeTEST可以大大节约开发的时间。

虽然CodeTEST Software-In–Circuit工具链不提供外部硬件测试系统的细节情况，但它为硬件的探测的难题提供了解决方案，提供了强大的代码覆盖实时工具、内存分析和软件追踪，而且在真实硬件环境中运行，价格低廉。 3、CodeTEST Hardtware-In-Circuit

当你进入此阶段时，你需要一组能提供监视软件测试深度和精确度的的工具链。带有的Bugs和错误的程序必须修改、升级或更新。

CodeTEST Hardtware-In-Circuit工具链采用外部硬件辅助和相应的通讯系统来实现最大程度的软件实时测试。

与逻辑分析仪和仿真器不同，CodeTEST Hardtware-In-Circuit具有处理目前复杂嵌入式系统的实时测试的能力。CodeTEST外置探测的硬件系统主要包括控制和数据处理器、大容量内存和可编程的升级定时器，因此大型测试的时间精度可在+ /-50ns内。

CodeTEST Hardtware-In-Circuit除了提供测试代码覆盖率、内存分析和追踪分析，它的精确的实时测试能力还可以帮你查出软件性能和质量上的问题所在。 4.3完全的解决方案

CodeTEST家族提供了六大的软件模块：CodeTEST性能分析，CodeTEST 内存分析，CodeTEST代码跟踪，CodeTEST语句覆盖，CodeTEST决策覆盖，CodeTEST可变条件决策覆盖。这些模块你可以自由的选择，来满足你对可视化的要求。 4.4CodeTEST性能

（CodeTEST可以确定调试代码时那一段代码花费较多时间，这样就可以更容易地监控所有程序的执行。）

由于CodeTEST可同时实时监视32，000个函数和1000各任务，因此它可以监控大型程序中每一个子程序的执行。而现有的调试工具通常采用采样技术，因此只能对部分代码和程序进行分析。在每次监视过程中，CodeTEST可以监视所有的应用程序，探测程序执行的瓶颈所在。它不仅可以显示出程序和函数执行最坏情况和最好情况所花的时间，而且还可以显示任务、函数及函数相互调用关系的所有结果。通过性能分析的排序列表，你可以很容易的确定你哪一部分程序需要修改。 4.5CodeTEST内存分析

（CodeTEST内存分析可以动态追踪内存分配，报告内存出错和相应的原始数据。）

CodeTEST内存分析解决了难以追踪动态内存分配问题。它不仅可以报告为程序中每条语句分配多少字节的内存（当程序运行时），而且它还可以鉴别2 0多种内存分配错误。例如，CodeTEST内存分析可以捕捉像“释放空指针（freeing a null pointer）”一样常见的程序错误，报告发生错误的函数和代码行。而相比而言，现有的调试工具需要进行上百次的代码追踪和监视，花数周的的时间才能探测一个程序问题的所在。

160

企业应用软件测试实训课程

4.6CodeTEST代码跟踪

（多追踪窗口观察可以简化程序设计流程，实现程序设计的规范化。）

CodeTEST代码追踪把深度追踪和面向Software的简化运用特点结合起来。该工具可以从三个不同的抽象层次显示程序执行过程：1）高级，显示R TOS事件和函数执行的入口和出口。2）控制流程级，显示在每个函数执行到哪一语句。3）原码级，显示每条执行过的C或C++语句。

CodeTEST具有专为软件工程师设计的触发（trigger）和存贮（storage）功能。你完全可以避开采用其它调试工具复杂的设置，只需根据确定一个任务中R TOS任务和函数等级来选择所需要追踪的软件内容。CodeTEST具有强大的触发功能，包括内存分配错误触发。由于CodeTEST可以记录每一条代码行执行的时间（t imestamp），因此你可以很容易的确定函数中每个循环执行的时间。 如果你想标识出追踪过程中你感兴趣的事件，你还可以在你的代码中插入用户定义的标记（tags）。这些标记和时间记录（timestamp）会在追踪过程中显示出来，而且你可以观察追踪过程中指定变量的值。

4.7CodeTEST-ACT（先进的代码覆盖工具）

（CodeTEST覆盖可以显示程序中覆盖过的函数以及代码的总覆盖率。）

代码覆盖是一种可以确定在一个特定的测试过程中，哪一部分程序执行过，而哪一部分程序未被执行过的技术。

CodeTEST-ACT提供了一种交互式界面，该界面可以在程序运行时显示出程序、函数和源代码的语句覆盖（SC）情况。此外，CodeTEST-ACT 独特之处是它在测试过程中提供了一张可以显示覆盖程度的覆盖率趋势图，该图可以让你确定花多少时间就可以是完成一个特定等级的代码覆盖。这样，一旦覆盖率的峰值一到你就可以终止测试，从而避开了测试中多余的和低效的部分，大大的缩短了测试的时间。

CodeTEST-ACT除了可以显示代码段执行的语句覆盖外，还提供了决策覆盖（DC）和条件决策覆盖（MCDC）的功能。

CodeTEST-ACT可以为不同等级的测试提供清晰的分析报告：CodeTEST SC提供语句覆盖分析和SC报告；CodeTEST DC不仅提供语覆盖分析和SC报告，而且还提供RTCA/DO-178 Level B测试标准所需的决策覆盖分析和DC报告；CodeTEST MCDC不仅包括SCHEDC报告，还提供了进行Level A测试所需的MCDC分析和报告。 4.8查桩器的性能分析

你可以根据程序执行的流程和操作（包括RTOS、函数和程序跳转分支及源程序的组织结构）来决定你对可见性需要程度。而这些需要可以通过对原程序插桩来实现, 而且插桩时插入原程序的语句与编写原代码语言很相近。

以往的解决方案是基于微处理器、总线信息和片内Cache，在总线上提前抓取信号。而CodeTEST可视化解决方案是基于软件插桩器实现的。采用插桩器，你用不着猜测关键的代码在哪，一切一目了然。

161

企业应用软件测试实训课程

CodeTEST自动插桩技术可以无需修改源代码而直接把插桩器插入应用软件中。你可以决定那些代码要插桩，要进行哪些测试。当插桩器在处理器中运行时，它会产生特定的实时可视标签（tags）。打完桩后关闭插桩器，这样就生成插桩版本（on-target）的新程序，而且你完全没必要删除这些可视标签。自动插桩器可以让你很容易地给大量代码插桩，而且它的可增加标签的特点可以在你需要修改bugs或编辑文件时很快的重新插桩。在插桩的标签信息送回主机后，你就可以在程序运行时看到代码执行的精确流程。CodeTEST的解决方案不占用目标板上的处理器，可以于目标板的C ache运行，并且不受内存的影响。目前，在所有的测试工具中，只用CodeTEST插桩技术支持各开发阶段的软件测试和分析。 第十七章 面向对象测试 14.1 面向对象测试技术

面向对象技术在软件工程中的推广使用，使得传统的测试技术和方法受到了极大的冲击。对面向对象技术所引入的新特点，传统的测试技术已经无法有效的进行测试。对面向对象软件的测试，测试策略或方法都需要出现相应的变革或更新。

就此，本文结合传统的测试技术，针对面向对象技术新特性在测试中所引发的问题，提出一种测试模型。首先，以软件工程中面向对象软件开发模式为参考，分别在面向对象分析，面向对象设计，面向对象编程三个阶段，依据各阶段的地位，作用，实现目标，具体阐述测试目的和应该注意的测试点。最后，依照传统的三个测试步骤：单元测试，集成测试，系统测试，借鉴传统测试方法有用的部分，论述如何有效的对面向对象软件进行测试。

面向对象技术是一种全新的软件开发技术，正逐渐代替被广泛使用的面向过程开发方法，被看成是解决软件危机的新兴技术。面向对象技术产生更好的系统结构，更规范的编程风格，极大的优化了数据使用的安全性，提高了程序代码的重用，一些人就此认为面向对象技术开发出的程序无需进行测试。应该看到，尽管面向对象技术的基本思想保证了软件应该有更高的质量，但实际情况却并非如此，因为无论采用什么样的编程技术，编程人员的错误都是不可避免的，而且由于面向对象技术开发的软件代码重用率高，更需要严格测试，避免错误的繁衍。因此，软件测试并没有面向对象编程的兴起而丧失掉它的重要性。

从1982年在美国北卡罗来纳大学召开首次软件测试的正式技术会议至今，软件测试理论迅速发展，并相应出现了各种软件测试方法，使软件测试技术得到极大的提高。然而，一度实践证明行之有效的软件测试对面向对象技术开发的软件多少显得有些力不从心。尤其是面向对象技术所独有的多态，继承，封装等新特点，产生了传统语言设计所不存在的错误可能性，或者使得传统软件测试中的重点不再显得突出，或者使原来测试经验认为和实践证明的次要方面成为了主要问题。例如： 在传统的面向过程程序中，对于函数y=Function(x);你只需要考虑一个函数（Function（））的行为特点，而在面向对象程序中，你不得不同时考虑基类函数（Base::Function（））的行为和继承类函数（Derived::Function（））的行为。

面向对象程序的结构不再是传统的功能模块结构，作为一个整体，原有集成测试所要求的逐步将开发的模块搭建在一起进行测试的方法已成为不可能。而且，面向对象软件抛弃了传统的开发模式，对每个开发阶段都有不同以往的要求和结果,已经不可能用功能细化的观点来检测面向对象分析和

162

企业应用软件测试实训课程

设计的结果。因此，传统的测试模型对面向对象软件已经不再适用。针对面向对象软件的开发特点，应该有一种新的测试模型。

一、面向对象测试模型（Object-Orient Test Model）

面向对象的开发模型突破了传统的瀑布模型，将开发分为面向对象分析（OOA），面向对象设计（OOD），和面向对象编程（OOP）三个阶段。分析阶段产生整个问题空间的抽象描述，在此基础上，进一步归纳出适用于面向对象编程语言的类和类结构，最后形成代码。由于面向对象的特点，采用这种开发模型能有效的将分析设计的文本或图表代码化，不断适应用户需求的变动。针对这种开发模型，结合传统的测试步骤的划分，本文建议一种整个软件开发过程中不断测试的测试模型，使开发阶段的测试与编码完成后的单元测试、集成测试、系统测试成为一个整体。测试模型如下图所示：

图14-1 面向对象测试模型图

其中，OOA Test为面向对象分析的测试； OOD Test为面向对象设计的测试； OOP Test

为面向对象编程的测试；OO Unit Test

为面向对象单元测试；

OO Integrate Test为面向对象集成测试；OO System Test为面向对象系统测试； OOA Test和OOD Test 是对分析结果和设计结果的测试，主要是对分析设计产生的文本进行，是软件开发前期的关键性测试。OOP Test主要针对编程风格和程序代码实现进行测试，其主要的测试内容在面向对象单元测试和面向对象集成测试中体现。面向对象单元测试是对程序内部具体单一的功能模块的测试，如果程序是用C++语言实现，主要就是对类成员函数的测试。面向对象单元测试是进行面向对象集成测试的基础。面向对象集成测试主要对系统内部的相互服务进行测试，如成员函数间的相互作用，类间的消息传递等。面向对象集成测试不但要基于面向对象单元测试，更要参见OOD或OOD Test结果（详见后面的叙述）。面向对象系统测试是基于面向对象集成测试的最后阶段的测试，主要以用户需求为测试标准，需要借鉴OOA或OOA Test结果。

尽管上述各阶段的测试构成一个相互作用的整体，但其测试的主体、方向和方法各有不同，且为叙述的方便，本文接下来将从OOA，OOD，OOP，单元测试，集成测试，系统测试六个方面分别介绍对面向对象软件的测试。

对由OOA，OOP，OOD这三个开发阶段所构成的开发模型、各阶段应该完成的目标以及结果报告

163

企业应用软件测试实训课程

的形式等详细介绍，已经超出本文内容，请参见其他技术参考文档。 二、面向对象分析的测试（OOA Test）

传统的面向过程分析是一个功能分解的过程，是把一个系统看成可以分解的功能的集合。这种传统的功能分解分析法的着眼点在于一个系统需要什么样的信息处理方法和过程，以过程的抽象来对待系统的需要。而面向对象分析（OOA）是“把E-R图和语义网络模型，即信息造型中的概念，与面向对象程序设计语言中的重要概念结合在一起而形成的分析方法”，最后通常是得到问题空间的图表的形式描述。

OOA直接映射问题空间，全面的将问题空间中实现功能的现实抽象化。将问题空间中的实例抽象为对象（不同于C++中的对象概念），用对象的结构反映问题空间的复杂实例和复杂关系，用属性和服务表示实例的特性和行为。对一个系统而言，与传统分析方法产生的结果相反，行为是相对稳定的，结构是相对不稳定的，这更充分反映了现实的特性。OOA的结果是为后面阶段类的选定和实现，类层次结构的组织和实现提供平台。因此，OOA对问题空间分析抽象的不完整，最终会影响软件的功能实现，导致软件开发后期大量可避免的修补工作；而一些冗余的对象或结构会影响类的选定、程序的整体结构或增加程序员不必要的工作量。因此，本文对OOA的测试重点在其完整性和冗余性。 对OOA阶段的测试划分为以下五个方面： 对认定的对象的测试； 对认定的结构的测试； 对认定的主题的测试；

对定义的属性和实例关联的测试； 对定义的服务和消息关联的测试。

对象、结构、主题等在OOA结果中的位置，参见下图：

1

企业应用软件测试实训课程

图14-2 车辆管理系统部分OOA分析结果示意图

对认定的对象的测试

OOA中认定的对象是对问题空间中的结构，其他系统，设备，被记忆的事件，系统涉及的人员等实际实例的抽象。对它的测试可以从如下方面考虑

认定的对象是否全面，是否问题空间中所有涉及到的实例都反映在认定的抽象对象中。

认定的对象是否具有多个属性。只有一个属性的对象通常应看成其他对象的属性，而不是抽象为的对象。

对认定为同一对象的实例是否有共同的，区别于其他实例的共同属性。

对认定为同一对象的实例是否提供或需要相同的服务，如果服务随着不同的实例而变化，认定的对象就需要分解或利用继承性来分类表示。

如果系统没有必要始终保持对象代表的实例的信息，提供或者得到关于它的服务，认定的对象也无必要。

认定的对象的名称应该尽量准确，适用。 对认定的结构的测试。

在Coad方法中，认定的结构指的是多种对象的组织方式，用来反映问题空间中的复杂实例和复杂关系。认定的结构分为两种：分类结构和组装结构。分类结构体现了问题空间中实例的一般与特殊的关系；组装结构体现了问题空间中实例整体与局部的关系。 对认定的分类结构的测试可从如下方面着手：

对于结构中的一种对象，尤其是处于高层的对象，是否在问题空间中含有不同于下一层对象的特殊可能性，即是否能派生出下一层对象。

对于结构中的一种对象，尤其是处于同一低层的对象，是否能抽象出在现实中有意义的更一般的上层对象。

对所有认定的对象，是否能在问题空间内向上层抽象出在现实中有意义的对象。 高层的对象的特性是否完全体现下层的共性。 低层的对象是否有高层特性基础上的特殊性。

对认定的组装结构的测试从如下方面入手：

整体（对象）和部件（对象）的组装关系是否符合现实的关系。 整体（对象）的部件（对象）是否在考虑的问题空间中有实际应用。 整体（对象）中是否遗漏了反映在问题空间中有用的部件（对象）。

165

企业应用软件测试实训课程

部件（对象）是否能够在问题空间中组装新的有现实意义的整体（对象）。 对认定的主题的测试。

主题是在对象和结构的基础上更高一层的抽象，是为了提供OOA分析结果的可见性，如同文章对各部分内容的概要。对主题层的测试应该考虑以下方面：

贯彻George Miller 的“7+2”原则，如果主题个数超过7个，就要求对有较密切属性和服务的主题进行归并。

主题所反映的一组对象和结构是否具有相同和相近的属性和服务。

认定的主题是否是对象和结构更高层的抽象，是否便于理解OOA结果的概貌（尤其是对非技术人员的OOA 结果读者）。

主题间的消息联系（抽象）是否代表了主题所反映的对象和结构之间的所有关联。

对定义的属性和实例关联的测试。

属性是用来描述对象或结构所反映的实例的特性。而实例关联是反映实例集合间的映射关系。对属性和实例关联的测试从如下方面考虑：

定义的属性是否对相应的对象和分类结构的每个现实实例都适用。 定义的属性在现实世界是否与这种实例关系密切。 定义的属性在问题空间是否与这种实例关系密切。 定义的属性是否能够不依赖于其他属性被理解。

定义的属性在分类结构中的位置是否恰当，低层对象的共有属性是否在上层对象属性体现。 在问题空间中每个对象的属性是否定义完整。 定义的实例关联是否符合现实。

在问题空间中实例关联是否定义完整，特别需要注意1-多和多-多的实例关联。

对定义的服务和消息关联的测试。

定义的服务，就是定义的每一种对象和结构在问题空间所要求的行为。由于问题空中实例间必要的通信，在OOA 中相应需要定义消息关联。对定义的服务和消息关联的测试从如下方面进行： 对象和结构在问题空间的不同状态是否定义了相应的服务。 对象或结构所需要的服务是否都定义了相应的消息关联。 定义的消息关联所指引的服务提供是否正确。

沿着消息关联执行的线程是否合理，是否符合现实过程。

166

企业应用软件测试实训课程

定义的服务是否重复，是否定义了能够得到的服务。

三、面向对象设计的测试（OOD Test）

通常的结构化的设计方法，用的“是面向作业的设计方法，它把系统分解以后，提出一组作业，这些作业是以过程实现系统的基础构造，把问题域的分析转化为求解域的设计，分析的结果是设计阶段的输入”。

而面向对象设计（OOD）采用“造型的观点”，以OOA为基础归纳出类，并建立类结构或进一步构造成类库，实现分析结果对问题空间的抽象。OOD 归纳的类，可以是对象简单的延续，可以是不同对象的相同或相似的服务。由此可见，OOD不是在OOA上的另一思维方式的大动干戈，而是OOA的进一步细化和更高层的抽象。所以，OOD与OOA 的界限通常是难以严格区分的。OOD确定类和类结构不仅是满足当前需求分析的要求，更重要的是通过重新组合或加以适当的补充，能方便实现功能的重用和扩增，以不断适应用户的要求。因此，对OOD的测试，本文建议针对功能的实现和重用以及对OOA结果的拓展，从如下三方面考虑： 对认定的类的测试； 对构造的类层次结构的测试； 对类库的支持的测试； 对认定的类的测试。

OOD认定的类可以是OOA中认定的对象，也可以是对象所需要的服务的抽象，对象所具有的属性的抽象。认定的类原则上应该尽量基础性，这样才便于维护和重用。测试认定的类： 是否含盖了OOA中所有认定的对象。 是否能体现OOA中定义的属性。 是否能实现OOA中定义的服务。 是否对应着一个含义明确的数据抽象。 是否尽可能少的依赖其他类。

类中的方法（C++：类的成员函数）是否单用途。

对构造的类层次结构的测试。

为能充分发挥面向对象的继承共享特性，OOD的类层次结构，通常基于OOA中产生的分类结构的原则来组织，着重体现父类和子类间一般性和特殊性。在当前的问题空间，对类层次结构的主要要求是能在解空间构造实现全部功能的结构框架。为此，测试如下方面： 类层次结构是否含盖了所有定义的类。

167

企业应用软件测试实训课程

是否能体现OOA中所定义的实例关联。 是否能实现OOA中所定义的消息关联。 子类是否具有父类没有的新特性。

子类间的共同特性是否完全在父类中得以体现。

对类库支持的测试。

对类库的支持虽然也属于类层次结构的组织问题，但其强调的重点是再次软件开发的重用。由于它并不直接影响当前软件的开发和功能实现，因此，将其单独提出来测试，也可作为对高质量类层次结构的评估。参照[9]中提出的准则，拟订测试点如下：

I.

一组子类中关于某种含义相同或基本相同的操作，是否有相同的接口（包括名字和参数表）。

II. 类中方法（C++：类的成员函数）功能是否较单纯，相应的代码行是否较少（建议不超过

30行）。

III. 类的层次结构是否是深度大，宽度小。

四、面向对象编程的测试（OOP Test）

典型的面向对象程序具有继承、封装和多态的新特性，这使得传统的测试策略必须有所改变。封装是对数据的隐藏，外界只能通过被提供的操作来访问或修改数据，这样降低了数据被任意修改和读写的可能性，降低了传统程序中对数据非法操作的测试。继承是面向对象程序的重要特点，继承使得代码的重用率提高，同时也使错误传播的概率提高。继承使得传统测试遇见了这样一个难题：对继承的代码究竟应该怎样测试？多态使得面向对象程序对外呈现出强大的处理能力，但同时却使得程序内“同一”函数的行为复杂化，测试时不得不考虑不同类型具体执行的代码和产生的行为。 面向对象程序是把功能的实现分布在类中。能正确实现功能的类，通过消息传递来协同实现设计要求的功能。正是这种面向对象程序风格，将出现的错误能精确的确定在某一具体的类。因此，在面向对象编程（OOP）阶段，忽略类功能实现的细则，将测试的目光集中在类功能的实现和相应的面向对象程序风格，主要体现为以下两个方面（假设编程使用C++语言）。 数据成员是否满足数据封装的要求； 类是否实现了要求的功能。 数据成员是否满足数据封装的要求。

数据封装是数据和数据有关的操作的集合。检查数据成员是否满足数据封装的要求，基本原则是数据成员是否被外界（数据成员所属的类或子类以外的调用）直接调用。更直观的说，当改编数据成员的结构时，是否影响了类的对外接口，是否会导致相应外界必须改动。值得注意，有时强制的类型转换会破坏数据的封装特性。例如：

168

企业应用软件测试实训课程

class Hiden { private: int a=1; char *p= \"hiden\"; } class Visible { public: int b=2; char *s= \"visible\"; } ….. ….. Hiden pp; Visible *qq=(Visible *)&pp; 在上面的程序段中，pp的数据成员可以通过qq被随意访问。

类是否实现了要求的功能。

类所实现的功能，都是通过类的成员函数执行。在测试类的功能实现时，应该首先保证类成员函数的正确性。单独的看待类的成员函数，与面向过程程序中的函数或过程没有本质的区别，几乎所有传统的单元测试中所使用的方法，都可在面向对象的单元测试中使用。具体的测试方法在面向对象的单元测试中介绍。类函数成员的正确行为只是类能够实现要求的功能的基础，类成员函数间的作用和类之间的服务调用是单元测试无法确定的。因此，需要进行面向对象的集成测试。具体的测试方法在面向对象的集成测试中介绍。需要着重声明，测试类的功能，不能仅满足于代码能无错运行或被测试类能提供的功能无错，应该以所做的OOD结果为依据，检测类提供的功能是否满足设计的要求，是否有缺陷。必要时（如通过OOD结仍不清楚明确的地方）还应该参照OOA的结果，以之为最终标准。

五、面向对象的单元测试（OO Unit Test）

传统的单元测试是针对程序的函数、过程或完成某一定功能的程序块。沿用单元测试的概念，实际测试类成员函数。一些传统的测试方法在面向对象的单元测试中都可以使用。如等价类划分法，因果图法，边值分析法，逻辑覆盖法，路径分析法，程序插装法等等。单元测试一般建议由程序员完成。

用于单元级测试进行的测试分析（提出相应的测试要求）和测试用例（选择适当的输入，达到测试要求），规模和难度等均远小于后面将介绍的对整个系统的测试分析和测试用例，而且强调对语句应该有100%的执行代码覆盖率。在设计测试用例选择输入数据时，可以基于以下两个假设： 1、如果函数（程序）对某一类输入中的一个数据正确执行，对同类中的其他输入也能正确执行。该

169

企业应用软件测试实训课程

假设的思想可参见等价类划分。

2、如果函数（程序）对某一复杂度的输入正确执行，对更高复杂度的输入也能正确执行。例如需要选择字符串作为输入时，基于本假设，就无须计较于字符串的长度。除非字符串的长度是要求固定的，如IP地址字符串。

在面向对象程序中，类成员函数通常都很小，功能单一，函数的间调用频繁，容易出现一些不宜发现的错误。例如：

· if (-1==write (fid, buffer, amount)) error_out(); 该语句没有全面检查write（）的返回值，无意中断然假设了只有数据被完全写入和没有写入两种情况。当测试也忽略了数据部分写入的情况，就给程序遗留了隐患。

· 按程序的设计，使用函数strrchr()查找最后的匹配字符，但误程序中写成了函数strchr()，使程序功能实现时查找的是第一个匹配字符。

· 程序中将if (strncmp(str1,str2,strlen(str1)))误写成了if (strncmp(str1,str2,strlen(str2)))。如果测试用例中使用的数据str1和str2长度一样，就无法检测出。

因此，在做测试分析和设计测试用例时，应该注意面向对象程序的这个特点，仔细的进行测试分析和设计测试用例，尤其是针对以函数返回值作为条件判断选择，字符串 操作等情况。

面向对象编程的特性使得对成员函数的测试，又不完全等同于传统的函数或过程测试。尤其是继承特性和多态特性，使子类继承或过载的父类成员函数出现了传统测试中未遇见的问题。Brian Marick 给出了二方面的考虑： 继承的成员函数是否都不需要测试？

根据[7]中的论述，对父类中已经测试过的成员函数，两种情况需要在子类中重新测试：a）继承的成员函数在子类中做了改动；b）成员函数调用了改动过的成员函数的部分。例如：假设父类Bass有两个成员函数：Inherited()和Redefined()，子类Derived只对Redefined()做了改动。Derived::Redefined()显然需要重新测试。对于Derived::Inherited()，如果它有调用Redefined()的语句(如：x=x/Redefined()),就需要重新测试，反之，无此必要。 对父类的测试是否能照搬到子类？

沿用上面的假设，Base::Redefined()和Derived::Redefined()已经是不同的成员函数，它们有不同的服务说明和执行。对此，照理应该对 Derived::Redefined()重新测试分析，设计测试用例。但由于面向对象的继承使得两个函数有相似，故只需在 Base::Redefined()的测试要求和测试用例上添加对Derived::Redfined()新的测试要求和增补相应的测试用例。例如： Base::Redefined()含有如下语句

If (value<0) message (\"less\"); 170

企业应用软件测试实训课程

else if (value==0) message (\"equal\"); else message (\"more\"); Derived::Redfined()中定义为

If (value<0) message (\"less\"); else if (value==0) message (\"It is equal\"); else message (\"more\"); if (value==88) message(\"luck\");} 在原有的测试上，对Derived::Redfined()的测试只需做如下改动：将value==0的测试结果期望改动；增加value==88的测试。

多态有几种不同的形式，如参数多态，包含多态，过载多态。包含多态和过载多态在面向对象语言中通常体现在子类与父类的继承关系，对这两种多态的测试参见上述对父类成员函数继承和过载的论述。包含多态虽然使成员函数的参数可有多种类型，但通常只是增加了测试的繁杂。对具有包含多态的成员函数测试时，只需要在原有的测试分析和基础上扩大测试用例中输入数据的类型的考虑。 六、面向对象的集成测试（OO Integrate Test）

传统的集成测试，是由底向上通过集成完成的功能模块进行测试，一般可以在部分程序编译完成的情况下进行。而对于面向对象程序，相互调用的功能是散布在程序的不同类中，类通过消息相互作用申请和提供服务。类的行为与它的状态密切相关，状态不仅仅是体现在类数据成员的值，也许还包括其他类中的状态信息。由此可见，类相互依赖极其紧密，根本无法在编译不完全的程序上对类进行测试。所以，面向对象的集成测试通常需要在整个程序编译完成后进行。此外，面向对象程序具有动态特性，程序的控制流往往无法确定，因此也只能对整个编译后的程序做基于黑盒子的集成测试。

面向对象的集成测试能够检测出相对的单元测试无法检测出的那些类相互作用时才会产生的错误。基于单元测试对成员函数行为正确性的保证，集成测试只关注于系统的结构和内部的相互作用。面向对象的集成测试可以分成两步进行：先进行静态测试，再进行动态测试。

静态测试主要针对程序的结构进行，检测程序结构是否符合设计要求。现在流行的一些测试软件都能提供一种称为“可逆性工程”的功能，即通过原程序得到类关系图和函数功能调用关系图，例如International Software Automation 公司的

Panorama-2 for Windows95、Rational

公司的

Rose C++ Analyzer等，将“可逆性工程”得到的结果与OOD的结果相比较，检测程序结构和实现上是否有缺陷。换句话说，通过这种方法检测OOP是否达到了设计要求。

动态测试设计测试用例时，通常需要上述的功能调用结构图、类关系图或者实体关系图为参考，确

171

企业应用软件测试实训课程

定不需要被重复测试的部分，从而优化测试用例，减少测试工作量，使得进行的测试能够达到一定覆盖标准。测试所要达到的覆盖标准可以是：达到类所有的服务要求或服务提供的一定覆盖率；依据类间传递的消息，达到对所有执行线程的一定 覆盖率；达到类的所有状态的一定覆盖率等。同时也可以考虑使用现有的一些测试工具来得到程序代码执行的覆盖率。 具体设计测试用例，可参考下列步骤：

先选定检测的类，参考OOD分析结果，仔细出类的状态和相应的行为，类或成员函数间传递的消息，输入或输出的界定等。 确定覆盖标准。

利用结构关系图确定待测类的所有关联。

根据程序中类的对象构造测试用例，确认使用什么输入激发类的状态、使用类的服务和期望产生什么行为等。

值得注意，设计测试用例时，不但要设计确认类功能满足的输入，还应该有意识的设计一些被禁止的例子，确认类是否有不合法的行为产生，如发送与类状态不相适应的消息，要求不相适应的服务等。根据具体情况，动态的集成测试，有时也可以通过系统测试完成。 七、面向对象的系统测试（OO System Test）

通过单元测试和集成测试，仅能保证软件开发的功能得以实现。但不能确认在实际运行时，它是否满足用户的需要，是否大量存在实际使用条件下会被诱发产生错误的隐患。为此，对完成开发的软件必须经过规范的系统测试。换个角度说，开发完成的软件仅仅是实际投入使用系统的一个组成部分，需要测试它与系统其他部分配套运行的表现，以保证在系统各部分协调工作的环境下也能正常工作。

系统测试应该尽量搭建与用户实际使用环境相同的测试平台，应该保证被测系统的完整性，对临时没有的系统设备部件，也应有相应的模拟手段。系统测试时，应该参考OOA分析的结果，对应描述的对象、属性和各种服务，检测软件是否能够完全“再现”问题空间。系统测试不仅是检测软件的整体行为表现，从另一个侧面看，也是对软件开发设计的再确认。 这里说的系统测试是对测试步骤的抽象描述。它体现的具体测试内容包括：

功能测试：测试是否满足开发要求，是否能够提供设计所描述的功能，是否用户的需求都得到满足。功能测试是系统测试最常用和必须的测试，通常还会以正式的软件说明书为测试标准。

强度测试：测试系统的能力最高实际限度，即软件在一些超负荷的情况，功能实现情况。如要求软件某一行为的大量重复、输入大量的数据或大数值数据、对数据库大 量复杂的查询等。

性能测试：测试软件的运行性能。这种测试常常与强度测试结合进行，需要事先对被测软件提出性能指标，如传输连接的最长时限、传输的错误率、计算的精度、记录 的精度、响应的时限和恢复时限等。

安全测试：验证安装在系统内的保护机构确实能够对系统进行保护，使之不受各种非常的干扰。安

172

企业应用软件测试实训课程

全测试时需要设计一些测试用例试图突破系统的安全保密措施，检验 系统是否有安全保密的漏洞。

恢复测试：采用人工的干扰使软件出错，中断使用，检测系统的恢复能力，特别是通讯系统。恢复测试时，应该参考性能测试的相关测试指标。

易用性测试：测试用户是否能够满意使用。具体体现为操作是否方便，用户界面是否友好等。 安装/卸载测试（install/uninstall test）等等。

系统测试需要对被测的软件结合需求分析做仔细的测试分析，建立测试用例。

173

企业应用软件测试实训课程

第十八章 OFFICE工具 一、OFFICE的使用介绍 1、WORD的使用 建立样式表；

插入图片，对图片的修改； 2、EXCEL的使用

建立一个工作表单，进行列行的合并拆分； 利用工作表进行章节划分； 3、PowerPoint的使用（附加） 简单的生成图片文字混排； 动态的控制演示流程 二、模版的建立使用 1、格式

测试文档的格式，遵照软件工程规范建立，所有要素全部涵盖。但是在实际工作中，各公司的要求和标准不一样，对文档的格式也有差别。 2、内容

测试文档要求有的内容一定要有，而且用语一定要标准。 3、模版参考

请参考课堂提供的几个模版。

重申测试计划内容；着重讲测试用例的编写，以“用户登陆认证”为例。测试报告要附有图表加以说明。 4、练习

围绕文本文档功能编写测试文档。要求：

编写测试计划。规定本测试计划在2天内，一个人的工作量； 编写测试用例。所有功能要有涉及； 填写BUG或建议。利用TD工具。

导出测试结果，并进行分析，提供分析报告。 5、整个测试项目由学员承担责任人。

174

企业应用软件测试实训课程

第十九章 微软的软件开发过程 一、 开发周期四阶段

微软的产品开发遵循一个完整的开发周期，这个产品开发周期被分为四个阶段：规划阶段、开发阶段、测试阶段（也叫稳定化阶段）和产品发送/出品阶段。

在产品的规划阶段要做三件事：拟定基于客户数据的目标描述、基于目标描述的规格/特性说明和基于规格说明和特性优先级制定的进度表。规划阶段中最重要的事情是让整个产品组的成员对共同的目标形成共同的认同。一座伟大建筑的诞生往往只缘于一位伟大建筑师的不朽贡献，但一个伟大软件的设计却需要成百上千人的智力创造。

第二个阶段是开发阶段，这个阶段也叫主要里程碑阶段。微软的任何一个产品组在这个阶段都将根据特性将项目划分成若干个子项目，每一个子项目的完成就对应于一个里程碑。一般微软中国研发中心会在这个阶段把产品划分成2～3个里程碑。Milestone1（第一个里程碑，简写为M1）内要完成的是核心的特性和功能，或今后需被共享的部件。那些将对产品稳定性形成很大影响的功能，也应该被放到Milestone1。Milestone2可以放比milestone1次要一些、但也是比较重要的特性和功能。Milestone3放的特性和功能对核心特性和功能的依赖性不大，有的甚至可能根据市场的变化重新评估和取舍。总体来说，应根据特性和功能在结构上的重要性来决定它应当被放在M1、M2或M3来做。

在每一个子项目（里程碑）内，进度表应当具体到每一个开发人员，而且进度表中应当加入缓冲时间。在子项目的执行过程中，程序经理（其角色下面详述）负责协调开发过程并更新规格说明，在开发人员编码、优化和调试的同时，测试人员进行Bug测试及报告，直到特性稳定化之后，里程碑才达到。开发阶段有一个微软所有的产品组都会用到的重要里程碑：代码完成（CC：Code Complete）。达到这个里程碑，意味着所有特性的编码任务全部完成，特性的集成测试通过后，除解决Bug以外，不再有新的代码进来。代码完成是明显的界线，标志着产品可以交付测试。至此开发周期进入第三个阶段。

第三个阶段是稳定化阶段，也叫测试阶段，或叫QA阶段。测试人员对软件做各种各样的测试，其中开发和测试工作是始终并存进行的：测试人员发现Bug，开发人员解Bug，测试人员再检测这个Bug是不是解了。如果你是一个程序经理，这个时候去看记录Bug的数据库，会发现一大堆Bug急剧涌现，随着一个个Bug被解，Bug量逐渐递减。当Bug量控制到某一个特定范围内就可以发Beta版，进行外部测试。这个时期程序经理要跟踪监督用户的反馈，开发人员及时解决用户发现的Bug。Beta测试结束之后，再经过一段时间的测试，就会达到零错误版本（ZBR）里程碑，零错误版本里程碑的达到，并不意味着没有Bug或遗漏的功能，而是标志着团队的成品达到了事先规划的品质水平，可以向发布候选（RC）里程碑进军了。值得注意的是，作为RC的产品，应包含出品之前所必须具备的全部文档资料。发布候选（RC）可能会经历RC0、RC1、RC2 等（最佳情况是RC0测试之后没有一点问题，那是最后要发布的那个产品了），但如RC0以后又发现了Bug，并且大家认为这个Bug必须要解，就又出来RC1，Windows 2000就是经过RC3之后才进入产品发送/出品阶段的。 产品有了稳定的版本就进入最后的阶段——产品发送/出品阶段。对于研发队伍来讲，十月怀胎、孩

175

企业应用软件测试实训课程

子终于出世的那一天就是发送投产（RTM——Release To Manufacture）。RTM之后到用户真正拿到这个软件产品之前还要经过我们耳熟能详的产品发布会（Launch Event），当然，这部分工作已经被微软的研发机构移交给市场和销售机构，由产品经理完成相应的产品宣传策划，把产品推向市场。 二、 微软经典团队角色

微软的产品组典型的人员角色有几类（参见图2）。一类是产品经理（Product Management）产品经理的使命是确定获利市场，同客户沟通产品的价值。这个角色相当于对产品的规划以及产品的销售。一类是项目经理（Program Management），他负责整个产品开发过程的协调，是微软各产品组中非常重要的一个角色。

开发（Development）、测试（Testing）在微软也是一些比较特殊的角色。此外还有：用户教育（User Education）和发布经理等角色。

图14-3 微软角色分布 表14-1 微软角色职责表

角色 职责 编写功能规范，协调各角色关系 客户联系的桥梁，进行需求分析 让产品容易使用 保证产品顺利发布 项目经理 产品经理 用户教育 发布经理 尽管微软的产品组角色定位非常清晰，但这些产品组多为横向组织，由多个部门的成员组成。比如

176

企业应用软件测试实训课程

产品管理属于微软的销售机构，而售后支持属于售后服务机构等等。微软不同机构和部门之间的协作性极强，这是保证微软按时完成高质量产品的重要原因之一。

在微软的产品开发周期中，每一个角色在不同的阶段有不同的侧重。在规划阶段，作用比较大的是产品经理和项目经理。开发阶段显然是开发人员的作用比较大，测试人员则在第三个阶段“QA阶段”很重要，但项目经理在这些阶段的作用都很重要。

产品经理对产品影响最大的作用体现在规划阶段。这个阶段的产品规划需做用户问卷调查，用各种各样的研究手段来试图了解用户的需求，并创建目标描述。这个阶段产品管理也收集用户需求，但他主要调查的是市场走向，他关心的是如何与客户沟通产品的价值。产品经理在整个产品开发周期中总是充当一个用户代言人的角色。产品经理在第一阶段和最后阶段发挥作用，产品经理必须设法了解新产品的获利市场所在，并且很好地同客户沟通产品的价值。

相比于产品经理，项目经理与项目经理之后的角色与产品具体开发过程更直接相关。

在微软的产品组中，项目经理的角色很特殊，他是惟一在产品开发周期的前三个阶段都显得非常重要的角色。

项目经理在规划阶段要贯彻和推进目标描述，书写功能/特性规格说明，创建主要的进度表。规格说明是基于产品规划所产生的目标描述来具体定义特性的实现步骤，目标描述文档是基于大量用户的调查报告和各种研究方法得出的用户的需求，定位产品的目标。但这只是给出了一个大方向，项目经理必须把这个大方向细化成若干个具体的特性，这些特性不仅要满足目标功能的要求，而且又必须是程序开发人员能够理解的语言。比如 Word某一版要支持HTML，产品规划只定目标，但项目经理就要把这个目标细化成几个具体的特性。

在第二个阶段，项目经理要管理整个开发工作的进度，检查开发人员的实现是否与规格说明相吻合，而且要使团队目标集中、齐心协力。如果在开发过程中有什么特性的变化，或者某些功能在设计时很好但在实际开发中出现问题，项目经理便要负责其更新规格说明，还要与产品规划、测试人员沟通项目的进展状态，协调开发过程中出现的问题。代码完成里程碑达到之后即开始大规模的测试，项目经理那时的作用就更大了，他要制定和控制每个Bug的优先级，做取舍决定，发送Beta版并收集用户反馈，确保产品按时达到发送候选（RC）。

一句话，项目经理的中心任务是保证软件高质量并按时出品。由于总是要在品质与进度上找到平衡点，项目经理必须精于“引导、驱策、鼓励、要求”团队做出最好的软件和表现出最好的工作效能。 在微软不同的团队里，项目经理所做的事情也有一定的差别。有偏技术性的设计功能的项目经理，他们是团队中的关键人物；有一种程序经理被叫做Release Program Manager，他的主要任务是控制开发流程;还有的程序经理会做一些客户需求调查的工作，定位产品方向。无论如何，程序经理的基本素质首先是要有很好的沟通技巧，具有设身处地为他人着想的本领；其次考虑问题周全，能处理复杂的情况；此外，程序经理要对开发产品所使用的技术很熟悉，对用户需求的理解力也要非常好。比如在具体的开发过程中，测试人员发现Bug越多越好，但开发人员却希望Bug越少越好，项目经理要善于协调二者的矛盾；在产品的开发过程中通常会出现人员突然流动的现象，或者硬件环境出了问题，或者外边竞争对手出现变化，项目经理对这些要反应非常机敏，有能力做出对公司、产品和客户影响最小的果断的取舍和决定。

177

企业应用软件测试实训课程

微软的开发人员无疑是每一个产品组中非常重要的角色。一个头衔是软件设计工程师（SDE——Soft Design Engineer）的开发人员的级别有可能比某一个经理要高很多。在微软，开发人员根据他本身知识和能力的不同分为不同的级别，顶级的开发人员负责整个软件的结构设计，中间有负责某一功能类的结构设计师，最底层的开发人员只完成规定的模块实现。好的结构设计对产品的稳定性、可扩充性非常重要，特别是对一个由多人参与的项目而言更是如此。在产品组中，最厉害的开发人员是整个产品结构的设计师。应该说，微软每一个产品中都有几个核心开发人员来控制整个产品的结构，其他开发人员则在他的领导之下共同完成开发工作。 三、 可用性测试的重要

所有用过微软产品的人会有一种感觉，微软产品非常易用。如何使产品做到易用？微软的办法是通过重视可用性测试（Usability Testing）来实现。可用性测试的使命是通过在产品开发周期的各个阶段加入客户资料和信息来使产品更有用、适用和易用。

在产品开发周期的第一个阶段可用性测试就要展开工作，比如，微软中国研发中心的产品组会把产品的新特性做一个模拟的模型，找用户来试用，产品组的可用性测试人员便会在试用过程中准备录音机、摄像头，把用户的行为摄下来，说的话录下来，按的键记录下来，研究他们对产品的反应，以便把产品设计调整到足够好。

微软中国研发中心中文处理组有一个产品“微软拼音输入法”，其最早的帮助功能是用鼠标右键击活菜单，这是Windows常用的菜单风格，但是通过前期的可用性测试，\\他们发现中国用户习惯了用鼠标左键，很少用右键，这样用户很难找到微软拼音的帮助功能。后来微软中国研发中心把“帮助”放在显示特别明显的地方——输入法状态条上，这样，按左键就能使用帮助功能。

在第二个开发阶段，当开发人员达到M1，能看到产品的最重要的特性时，可用性测试人员要随时反馈设计好不好，如果要有个别的改动，则在M2中将M1的某些功能改动加进来。可用性测试人员要理解用户的工作领域、行为和心理，微软公司总部有很多做可用性测试的人员是心理学方面的专家。用户的感受只有通过可用性测试人员分析、理解成对功能的描述，或者对功能的反馈，才能使产品开发人员能够理解并改进。 四、 里程碑式的开发模式的好处

综观微软对软件开发周期过程的管理，其精髓的做法一是将大项目划分成若干个子项目的里程碑式的开发模式；其次，通过对产品组各人员角色对职责的承诺来控制产品的开发过程，以保证产品的进度和质量。

不管是小软件还是大软件，里程碑的概念在微软所有的软件开发中都会被用到。这也是微软在软件开发上摸索多年凝聚所得。国内软件企业的开发大多是从有一个想法就开始做，不分什么阶段，但往往因为软件功能太多，不同的人负责不同模块，到产品的最后阶段再去集成和测试，大量原来没有预计到的问题都“冒”了出来，这时再去“动”各个部分，时间肯定要推迟。这种模式将导致两个问题:一是质量无法控制，二是时间无法控制。

在微软里程碑式的开发模式下，做同样大的产品，因为按子项目来划分里程碑，每一个子项目都经过一定的稳定化阶段，再进入到第二个子项目的时候，就是基于一个相对稳定的一部分子项目基础之上的行为，这样就将风险或错误的累加分散和降低。以局部的质量控制来保证整体产品的进一步

178

企业应用软件测试实训课程

稳定，能使得质量和进度得以很好的控制。而且，把一个大的项目分散到不同的阶段来完成，可以灵活地去增加或减少一些功能，否则，把增加或减少功能集中到最后集成阶段，而且是在不稳定的环境下来做，困难可想而知。这就是里程碑式的开发模式优秀之处所在。虽然里程碑的做法在成本上比较高——为了协调出大家对里程碑一致的价值观，为了协调出里程碑的衡量准则，如此等等，团队必须付出大量时间和精力，承受比较大的痛苦，但这是惟一能够确保开发成功的方式。 软件企业的创造性和制度要相辅相成。在微软的所有里程碑中，“代码完成”里程碑（code complete milestone），是一个重要的分界线。在代码完成之前，产品组自由发挥创造力，最需要大量的交互和碰撞。代码完成之后，则需严格按照里程碑完成进度。进入测试阶段，微软通常把里程碑分得更细致，比如Beta、零错误版本、发布候选、RTM等等。每个里程碑都不是简单的摆设，而是有严格的规定，快到里程碑的时候开发人员不能做没到里程碑时的修改，为保证软件按进度完成，靠近里程碑时需要“收敛”，而收敛惟一的方法就是少做事情。过了一个里程碑，产品比以前的质量就要好许多。通过一个一个里程碑来收敛，这个项目不会偏离目标很远。从代码完成到RTM是微软软件开发周期中非常重要的过程，这个时候已经完成充分发挥智力的时期，而规范成为更重要的要素。 项目经理经常犯的错误之一，是以为只要雇用软件工程师就行，其他的人都不必要，或是让软件工程师占整个团队很高的比例。他们也许认为开发人员越多，写出来的程序也越多，这是错误的概念。项目的目的是为了完成软件，而不是完成更多的程序代码。在开发团队中，实际有一些工作是不适宜交给软件工程师做的。 五、 测试组不是开发组的助手

似乎没有谁比微软更重视测试的力量。在微软的产品组中，测试组是与产品规划组、产品管理组、开发组和用户教育组等并列的队伍。测试与软件成本的关系是，发现产品中存在的问题越早，开发费用越低，产品质量越高，软件发布后维护费用越低。在微软开发周期的四个阶段中，测试的目的在于保证软件质量，满足设计的要求和客户的需求；系统地揭示出不同类型的错误，并耗费最少时间和最小工作量；降低软件的开发成本和维护成本。

软件开发过程中开发人员很可能因为一些偶发的小事，或某种无关的灵感而不知不觉中偏离了实际的需要，暂时忘记了什么才是产品最该有的功能，把他们拉回原定轨道中的正是测试工程师。测试人员的职责是配合整个项目组保证按照预定的时间表完成达到预定设计目标的产品。测试人员的工作是具有整体性、持续性的软件开发活动中的一环，而不是偶尔拿出来点缀一下。软件产品的质量是由用于测试的资源、产品的功能和项目的时间表来决定的，是三者的平衡。对任何的一个产品组来说，无论是主观，还是客观上，都要重视测试工程师的存在，这是产品质量的重要保证。 六、 软件测试的阶段性

软件开发的过程就像是一支队伍正在急行军，但跑着跑着这支队伍就会“散了架”，设立里程碑的作用就仿佛是到了某一个“点”，大家必须要重新整理步伐，实现同步。就测试组的工作模式而言，测试的阶段划分是与项目的进度相对应的。也就是说，测试人员应当与项目组的其他人员始终保持以相同的步伐“跑步”的状态，与整个项目的每一个里程碑配合，完成相应的测试工作。

把大项目划分成若干子项目的里程碑式的开发模式是微软软件开发管理的精髓做法，在微软的每一个产品开发周期中都有以下几个重要的里程碑：CC（Code complete:代码完成）；Beta测试；RC（Release

179

企业应用软件测试实训课程

Candidate：候选发布）；RTM（Release To Manufacture:投入生产），测试人员和产品组的其他人员一起，共同达到每一个里程碑。一个完整的测试循环应当包括运行所有的测试用例、Beta标准测试、bug校验和解所有的bug、随机测试。好的测试循环能够保证对软件质量有一个全面完整的评价，每个里程碑之前至少要有一个完整的测试循环。

在微软的产品开发周期中，在规划阶段当开发人员在做计划、编进度，进行功能实现的可行性研究，对计划的功能进行反馈时，测试人员应当研究规格说明，编写测试计划；在第二个阶段即开发阶段，当开发人员在编写代码、测试和调试的同时，测试人员应当开始设计测试用例，开发自动测试工具和程序，熟悉必需的环境、工具、软件和硬件，不断地丰富测试用例，直到达到CC（代码完成）里程碑——这个时候的软件可以进行一次整体测试，用户界面可能不完美但能够工作，可能有很多明显的bug。

进入开发周期的第三阶段，测试人员大显身手，展开大规模的测试，比如系统级整体测试，交互性和深层测试。测试之后，测试人员应当对新增的功能说“不”，直至达到Bate测试里程碑。达到这个里程碑，意味着所有的Beta致命问题已经被修正和关闭，所有计划的功能都已经在软件中并能工作，产品稳定，大部分界面还可以，尽管可能只是一部分，但已经有了在线帮助和用户手册，即使是发布了也不会引起负面的影响。

Beta测试的目的是确定产品是否能在预计的各种硬件平台和操作系统中正常运行，虽然Beta测试的反馈意见很有参考价值，但除非存在重大问题，否则不应对功能集再做修改，所有建议和反馈都留在下一版中再考虑纳入。Beta测试之后就要向RC和RTM进军。测试人员要着重测试Beta后的变动。到达RC，意味着软件质量状态为没有活跃的bug（Active bug）；没有悬而未决的事；已经稳定了一段时间，如一周内很少或没有变动，或变动很小。如果RC后的测试没有发现新的需要改的bug，可以达到RTM，随后查病毒，验证光盘，检查内容。

需要注意的是，在整个阶段性的软件测试过程中，质量不仅仅是测试组的责任。一定要防止完全依赖测试组来保证质量的做法，否则结果只能是质量差、进度延迟。采用Zero-Defect策略的好处在于，可以同时保证产品的质量、进度和功能集，尽早发现和修正产品中的bug，始终把产品的状态和bug数量控制在可以管理的范围之内，程序员应该修正所有的优先级为一级（P1）的bug才能写新的代码。

同时测试组应当开发一些好的测试管理工具，比如测试用例管理工具和bug的管理工具等等。测试工程师应当细化测试子区域，重视测试用例的数量和质量，对bug状态的变化要反应迅速。要防止仅以bug多少来评价工程师的工作。 七、 bug的发现和管理

在微软的测试人员看来，那些功能没有实现或与规格说明不一致的问题是bug；不能工作（死机、没反应）的部分是bug；不兼容的部分是bug；边界条件未做处理是bug；界面、消息、提示不够准确是bug；有时把尚未完成的工作也作为一个bug。微软把软件中常见的bug类型归为以下几类： 功能错误； 用户界面错误； 边界值相关错误；

180

企业应用软件测试实训课程

初始化错误； 计算错误； 内存相关错误；

硬件相关错误和文档错误。

测试工程师发现bug之后所采取的措施，首先应当是去想法验证是不是自己的偶然失误造成bug出现，如不是则应立即建立每一个新的bug记录，包括具体的再现步骤、环境、屏幕等；尽可能地分析产生bug的原因；设计合适的优先级和严重级别，要记住，测试人员的目标不是找出更多的bug，而是改进产品的质量；依据bug的优先级和严重级别分派给某一个相应的人，如程序员、项目经理和测试组的负责人等。

测试组应当有一个区域专门放置记录所有bug管理系统，这个管理系统被统称为BMS。其中所有的记录都无法删除，对于每个记录只能一直添加内容，是测试组与项目组所有成员交流与沟通的公用工具。通过与bug mail配合能根据bug的当前状态及时通知bug的当前责任人，有效地跟踪项目的进展，为产品发布提供判断标准，积累测试人员成果。

图14-4 BMS截图

BMS的功能包括： 完整的Bug数据库

整个产品组的记录和控制

强大的查询功能，有效地跟踪项目的状态

181

企业应用软件测试实训课程

所有的记录无法删除，对于每个记录只能一直添加内容 丰富的报表功能，为产品发布提供判断标准 Bug 记录中的有效信息包括 ： 状态 负责人 问题种类 严重级 优先级 修改时间 登记时间 缺陷来源 解决方案 运行环境 缺陷关联 附件 附图 缺陷细节

微软对于Bug 的严重程度的划分：

死机，数据丢失，主要功能组完全丧失，系统悬挂 主要功能丧失，导致严重的问题，或致命的错误声明 次要功能丧失， 不太严重，如提示信息不太准确

微小的问题，对功能几乎没有影响，产品及属性仍可使用. 如有个错别字 Bug状态：

一般来说，bug在数据库中有三种状态：活跃（Active）、被解（Resolved）、关闭（Closed）。 这三个状态在微软通常用“红黄绿”三个颜色来代表。活跃状态指的是测试人员新建一个bug时的状态，必须分派给相应的设计人员、开发人员或者是用户教育人员，表明bug的状态是等待纠正的。被解状态指的是设计人员、开发人员或者用户教育人员修正bug后的状态，必须重新分派给报告bug的测试人员，表明bug已经得到修正，但等待校验。关闭状态指的是测试人员校验完成并关掉之后的状态，表明bug已经得到修正，并完成了校验，但如果同样的问题再次出现后，还可能重新激活成活跃状态，则又开始了另一轮的状态循环。活跃bug数量的变化趋势是，一般在代码完成前很少，

182

企业应用软件测试实训课程

代码完成后增长很快，接近Beta测试时会下降，接近RC时奔向零。因此依据每天新建的bug数量与修正的bug数量相比较和处于活跃状态的bug数量亦可判断产品质量和里程碑的信号。

八、 秘密武器：测试用例和测试计划

概括来看，微软测试的精髓做法是：系统可重用的测试用例；以问题（bug）发现和跟踪为核心的测试活动；的测试人员；基于产品规划、产品设计规格的测试计划；与整个项目配合的基于里程碑的软件测试周期。而基于产品规划、产品设计规格的测试计划和系统可重用的测试用例则是微软的“秘密武器”。

在微软，测试计划是帮助测试人员管理测试项目和发现bug的重要工具，是纲领性文件。测试计划明确了项目的测试任务、测试内容清单，这些内容不能只存在于测试人员的脑海里，而必须被项目经理、开发经理所了解，测试计划必须增强测试任务和测试实施过程的沟通，具有指导性。测试计划还必须提供组织管理测试项目的框架结构，帮助控制进度。

测试计划涉及的范围应当有产品概述、测试策略、测试的方法学、测试区域、测试的配置（软件环境、硬件环境、网络环境）、测试周期（与项目的里程碑配合）、测试资源的规划、风险分析和案例等。测试计划不是一成不变的。虽然测试计划在产品设计阶段就开始被撰写，但在后来的开发过程中会随着项目进度表的改变而改变。

一个好的测试用例有以下几个特征：首先，是最有可能抓住错误的；其次，不是重复的、多余的；第三，一组相似测试用例中最有效的；最后，不要太简单，也不要太复杂。因此，在测试人员设计测试用例时应当遵循以下原则：在人员变化和新项目中能够重用；能够分类； 测试的内容不重复；保存在测试用例的数据库中；在项目进行过程中可不断增强。

设计测试用例时的一些通常考虑“点”是：根据产品规格测试基本功能；设计普通用户的使用方案；设计稀有或特殊的使用方案；与系统其他组成部分的配合（如FAX和上网可能都要用到调制解调器，测试中要考虑对设备的共享）；考虑特殊情况（比如内存和硬件的冲突等）；设计极端情况（比如内存泄漏、破坏性测试等）。 本章小结

对于面向对象来说，一些传统的测试方法某些是适用的，比如等价类划分，边界值分析，但是有些就不太适用了，比如覆盖率，路径分析等等。所以针对面向对象的开发技术，测试是需要创新的。 面向对象的开发根据开发过程可以分为分析阶段，设计阶段，编程，单元测试，集成测试，系统测试几个阶段过程。针对每个阶段都有相应的测试技术。

微软这个软件帝国之所以可以长期的占据这样的一个业界宝座是有他的道理的，通过微软的开发过程可以看到一个管理完善，但是又有很多的创新色彩的微软。相比较国内的一些软件企业，测试工程师在微软有一个很高的地位，这也是体现了微软的为客户着想的思想，而这个很大程度上是微软成功的一个因素。

183