中软就业培训教材_软件测试基础_v1.0.1

中软国际无锡实训基地指定教材

中软软件工程师就培训指定教材

软件测试基础

学生用书

软件测试基础 培训教材 第 2 页 共 110 页

书名： 软件测试基础

内部编号： JYB

版本号：V1.0

编辑单位：中软国际无锡实训基地

地址： 无锡新区新安镇震泽路5号江苏软件外包产业园处子座B 座

邮编： 214028

电话：

网站：

E-mail ：

声明：

软件测试基础 培训教材 第 3 页 共 110 页

目录

第1章

软件测试介绍及如何学习 ....................................................................................... 6 1.1

测试人员应具备素质 ............................................................................................... 6 1.2 测试工作如何进行 (7)

1.2.1 基本情况 (7)

1.2.2 测试计划 (7)

1.2.3 测试用例开发 (8)

1.2.4 Bug 跟踪过程 (9)

1.2.5 Bug 的不同处理方式 (9)

1.3 如何学习此门课 (10)

1.3.1 测试准备工作 (10)

1.3.2 向有经验的测试人员学习 (10)

1.3.3 阅读软件测试的相关书籍 (10)

1.3.4 走读缺陷跟踪库中的问题报告单 (10)

1.3.5 走读相关产品的历史测试用例 (10)

1.3.6 学习产品相关的业务知识 (11)

1.3.7 识别测试需求 (11)

1.3.8 确认需求的优先级 (11)

1.3.9 利用已有的软件 Checklist (11)

1.3.10 测试用例设计及编写 (11)

1.4 如何成为一个好的测试人员 (11)

1.5 外包测试 (13)

1.5.1 什么是软件外包 (13)

1.5.2 什么是软件外包测试 (14)

练习 (15)

第2章 软件测试基础 (16)

2.1 软件测试概念 (16)

2.1.1 软件测试定义 (16)

2.1.2 软件测试术语 (16)

2.2 软件测试目的与局限性 (17)

2.2.1 软件测试目的与原则 (17)

2.2.2 软件测试局限性 (17)

2.2.3 软件测试误区 (18)

2.3 软件测试类型 (18)

2.3.1 静态测试 (19)

2.3.2 动态测试 (21)

2.3.3 白盒测试 (23)

2.3.4 黑盒测试 (24)

2.3.5 基于风险测试 (24)

2.3.6 基于模型测试 (25)

2.3.7 自动化测试与手工测试 (26)

2.3.8 测试步骤 (26)

软件测试基础

培训教材 第 4 页 共 110 页

2.3.9 面向对象测试 (30)

练习 (41)

第3章 软件测试过程 (42)

3.1 软件测试过程概述 (42)

3.1.1 测试过程管理理念 (42)

3.1.2 测试过程管理实践 (43)

3.1.3 测试过程可持续改进 (45)

3.2 软件测试过程模型 (45)

3.3 软件测试过程详细 (48)

3.3.1 测试计划 (48)

3.3.2 测试策略 (48)

3.3.3 测试资源 (49)

3.3.4 测试过程步骤 (49)

练习 (54)

第4章 软件测试技术 (55)

4.1 黑盒测试技术 (55)

4.2 白盒测试技术（单元测试技术） (62)

4.2.1 单元测试任务 (63)

4.2.2 单元测试过程 (64)

4.2.3 白盒测试举例 (65)

4.3 软件测试自动化 (70)

4.3.1 实施软件测试自动化的理由分析 (70)

4.3.2 国内软件测试自动化实施现状分析 (70)

4.3.3 国内软件测试自动化实施不成功原因分析 (71)

4.3.4 正确认识国内未实施软件测试自动化的根源 (71)

4.3.5 软件测试自动化的引入条件 (72)

4.3.6 对企业自身现状的评估分析 (73)

4.3.7 对企业推行自动化测试的风险分析 (74)

4.3.8 自动化测试与手工测试选择标准 (76)

4.4 Web 测试技术 (77)

4.4.1 测试方法 (77)

4.4.2 存在风险及解决方法 (84)

4.4.3 软件缺陷的原则 (85)

练习 (85)

第5章 缺陷管理与工具 (86)

5.1 Bug 编写 (86)

练习 (88)

第6章 附录 (89)

6.1 软件测试计划编写 (89)

6.1.1 简介 (89)

6.1.2 测试参考文档和测试提交文档 (89)

6.1.3 测试进度 (90)

6.1.4 测试资源 (91)

6.1.5 系统风险、优先级 (92)

软件测试基础

培训教材 第 5 页 共 110 页

6.1.6 测试策略 (92)

6.1.7 问题严重度描述 (101)

6.2 测试报告编写指南 (103)

6.2.1 概述 (103)

6.2.2 测试概要 (103)

6.2.3 测试结论与建议 (107)

6.3 测试准则 (108)

软件测试基础 培训教材 第 6 页 共 110 页

第1章 软件测试介绍及如何学习

本章目的是让读者了解软件测试及如何进行软件测试的学习。

1.1 测试人员应具备素质

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

(1) 沟通能力。一名理想的测试者必须能够同测试涉及到的所有人进行沟通，具有与

技术（开发者）和非技术人员（客户，管理人员）的交流能力。既要可以和用户

谈得来，又能同开发人员说得上话，不幸的是这两类人没有共同语言。和用户谈

话的重点必须放在系统可以正确地处理什么和不可以处理什么上。而和开发者谈

相同的信息时，就必须将这些活重新组织以另一种方式表达出来，测试小组的成

员必须能够同等地同用户和开发者沟通。

(2) 移情能力。和系统开发有关的所有人员都处在一种既关心又担心的状态之中。用

户担心将来使用一个不符合自己要求的系统，开发者则担心由于系统要求不正确

而使他不得不重新开发整个系统，管理部门则担心这个系统突然崩溃而使它的声

誉受损。测试者必须和每一类人打交道，因此需要测试小组的成员对他们每个人

都具有足够的理解和同情，具备了这种能力可以将测试人员与相关人员之间的冲

突和对抗减少到最低程度。

(3) 技术能力。总体而言，开发人员对那些不懂技术的人持一种轻视的态度。一旦测

试小组的某个成员作出了一个错误的断定，那么他们的可信度就会立刻被减弱。

一个测试者必须既明白被测软件系统的概念又要会使用工程中的那些工具。要做

到这一点需要有几年以上的编程经验，前期的开发经验可以帮助对软件开发过程

有较深入的理解，从开发人员的角度正确的评价测试者，简化自动测试工具编程

的学习曲线。

(4) 自信心。开发者指责测试者出了错是常有的事，测试者必须对自己的观点有足够

的自信心。如果容许别人对自己指东指西，就不能完成什么更多的事情了。

(5) 外交能力。当你告诉某人他出了错时，就必须使用一些外交方法。机智老练和外

交手法有助于维护与开发人员的协作关系，测试者在告诉开发者他的软件有错误

时，也同样需要一定的外交手腕。如果采取的方法过于强硬，对测试者来说，在

以后和开发部门的合作方面就相当于“赢了战争却输了战役”。

(6) 幽默感。在遇到狡辩的情况下，一个幽默的批评将是很有帮助的。

(7) 很强的记忆力。一个理想的测试者应该有能力将以前曾经遇到过的类似的错误从

软件测试基础

培训教材 第 7 页 共 110 页

记忆深处挖掘出来，这一能力在测试过程中的价值是无法衡量的。因为许多新出

现的问题和我们已经发现的问题相差无几。

(8) 耐心。一些质量保证工作需要难以置信的耐心。有时你需要花费惊人的时间去分

离、识别和分派一个错误。这个工作是那些坐不住的人无法完成的。

(9) 怀疑精神。可以预料，开发者会尽他们最大的努力将所有的错误解释过去。测式

者必须听每个人的说明，但他必须保持怀疑直到他自己看过以后。

(10) 自我督促。干测试工作很容易使你变得懒散。只有那些具有自我督促能力的人才

能够使自己每天正常地工作。

(11) 洞察力。一个好的测试工程师具有“测试是为了破坏”的观点，捕获用户观点的能

力，强烈的质量追求，对细节的关注能力。应用的高风险区的判断能力以便将有

限的测试针对重点环节。

1.2 测试工作如何进行

下面以微软为例对软件测试工作进行了说明。

1.2.1 基本情况

测试在微软公司是一项非常重要的工作，微软公司在此方面的投入是非常巨大的。微软对测试的重视表现在工程开发队伍的人员构成上，微软的项目经理、软件开发人员和测试人员的比例基本是1：3：3或1：4：4，可以看出开发人员与测试人员的比例是1：1。对于测试的重视还表现在最后产品要发布的时候，此产品的所有相关部门都必须签字，而测试人员则具有绝对的否决权。

测试人员中分成两种职位，Software Development Engineer in Test （测试组的软件开发工程师）实际上还是属于开发人员，他们具备编写代码的能力和开发工具软件的经验，侧重于开发自动化测试工具和测试脚本，实现测试的自动化。Software Test Engineer （软件测试工程师）具体负责测试软件产品，主要完成一些手工测试以及安装配置测试。

1.2.2 测试计划

测试计划是测试人员管理测试项目，在软件中寻找Bug 的一种有效的工具。测试计划主要有两个作用，一是评判团队的测试覆盖率以及效率，让测试工作很有条理的逐步展开。二是有利于与项目经理、开发人员进行沟通。有了测试计划之后，他们就能够知道你是如何开展测试工作的，他们也会从中提出很多有益的意见，确保测试工作顺利进行。总之，有了测试计划可以更好的完成测试工作，确保用户的满意度。

测试人员在编写测试计划之前，应获得以下文档：

(1) 程序经理编写的产品功能说明书或产品开发计划；

(2) 程序经理或开发人员提供的开发进度表。

根据产品的特性及开发进度安排，测试人员制定具体的测试计划。测试计划通常包括以下内容：

软件测试基础

培训教材 第 8 页 共 110 页

(1) 测试目标和发布条件：

A. 给出清晰的测试目标描述；

B. 定义产品的发布条件，即在达到何种测试目标的前提下才可以发布产品的某个特

定版本。

(2) 待测产品范围：

A. 软件主要特性/功能说明，即待测软件主要特性的列表；

B. 特性/功能测试一览，应涵盖所有特性、对话框、菜单和错误信息等待测内容，并

列举每个测试范围内要重点考虑的关键功能。

(3) 测试方法描述：

A. 定义测试软件产品时使用的测试方法；

B. 描述每一种特定的测试方法可以覆盖哪些测试范围。

(4) 测试进度表：

A. 定义测试里程碑；

B. 定义当前里程碑的详细测试进度。

(5) 测试资源和相关的程序经理/开发工程师：

A. 定义参与测试的人员；

B. 描述每位测试人员的职责范围；

C. 给出与测试有关的程序经理/开发工程师的相关信息。

(6) 配置范围和测试工具：

A. 给出测试时使用的所有计算机平台列表；

B. 描述测试覆盖了哪些硬件设备；

C. 测试时使用的主要测试工具。

此外，还应列出测试中可能会面临的风险及测试的依赖性，即测试是否依赖于某个产品或某个团队。比如此项测试依赖性WindowsCE 这个操作系统，而这个系统要明年2月份才能做好，那么此项测试就可能只有在明年5月份才能完成，这样就存在着依赖关系。如果那个团队的开发计划往后推，则此项测试也会被推迟。

1.2.3 测试用例开发

一个好的测试用例就是有一个合理的概率来找到Bug ，不要冗余，要有针对性，一个测试只针对一件事情。特别是功能测试的时候，如果一个测试是测了两项功能，那么如果测试结果失败的话，就不知道到底是哪项功能出了问题。

测试用例开发中主要使用的技术有等价类划分，边界值的分析，Error Guessing

Testing 。

等价类划分是根据输入输出条件，以及自身的一些特性分成两个或更多个子集，来减少所需要测试的用例个数，并且能用很少的测试用例来覆盖很多的情况，减少测试用例的冗余度。在等价类划分中，最基本的划分是一个为合法的类，一个为不合法的类。

边界值的分析是利用了一个规律，即程序最容易发生错误的地方就是在边界值的附近，

软件测试基础 培训教材 第 9 页 共 110 页

它取决于变量的类型，以及变量的取值范围。一般对于有n 个变量时，会有6n+1个测试用例，取值分别是min-1， min ， min+1， normal ， max-1， max ，max+1的组合。边界值的分析的缺点，是对逻辑变量和布尔型变量不起作用，还有可能会忽略掉某些输入的组合。

Error Guessing Testing 完全靠的是经验，所设计的测试用例就是常说的猜测。感觉到软件在某个地方可能出错，就去设计相应的测试用例，这主要是靠实际工作中所积累的经验和知识。其优点是速度快，只要想得到，就能很快设计出测试用例。缺点就是没有系统性，无法知道覆盖率会有多少，很可能会遗漏一些测试领域。

实际上在微软是采用一些专门的软件或工具负责测试用例的管理，有一些测试信息可以被记录下来，比如测试用例的简单描述，在哪些平台执行，是手工测试还是自动测试，运行的频率是每天运行一次，还是每周运行一次。此外还有清晰的测试通过或失败的标准，以及详细记录测试的每个步骤。

1.2.4 Bug 跟踪过程

在软件开发项目中，测试人员的一项最重要使命就是对所有已知Bug 进行有效的跟踪和管理，保证产品中出现的所有问题都可以得到有效的解决。一般地，项目组发现、定位、处理和最终解决一个Bug 的过程包括Bug 报告、Bug 评估和分配、Bug 处理、Bug 关闭等四个阶段：

(1) 测试工程师在测试过程中发现新的Bug 后，应向项目组报告该Bug 的位置、表现、

当前状态等信息。项目组在Bug 数据库中添加该Bug 的记录。

(2) 开发经理对已发现的Bug 进行集中讨论，根据Bug 对软件产品的影响来评估Bug

的优先级，制定Bug 的修正策略。按照Bug 的优先级顺序和开发人员的工作安排，

开发经理将所有需要立即处理的Bug 分配给相应的开发工程师。

(3) 开发工程师根据安排对特定的Bug 进行处理，找出代码中的错误原因，修改代码，

重新生成产品版本。

(4) 开发工程师处理了Bug 之后，测试人员需要对处理后的结果进行验证，经过验证

确认已正确处理的Bug 被标记为关闭（Close ）状态。测试工程师既需要验证Bug

是否已经被修正，也需要确定开发人员有没有在修改代码的同时引入新的Bug 。

1.2.5 Bug 的不同处理方式

在某些情况下，Bug 已处理并不意味着Bug 已经被修正。开发工程师可以推迟Bug 的修正时间，也可以在分析之后告知测试工程师这实际上不是一个真正的Bug 。也就是说，某特定的Bug 经开发工程师处理之后，该Bug 可能包括以下几种状态。

已修正：开发工程师已经修正了相应的程序代码，该Bug 不会出现了。

可推迟：该Bug 的重要程度较低，不会影响当前应提交版本的主要功能，可安排在下一版本中再行处理。

设计问题：该Bug 与程序实现无关，其所表现出来的行为完全符合设计要求，对此应提交给程序经理处理。

无需修正：该Bug 的重要程度非常低，根本不会影响程序的功能，项目组没有必要在

软件测试基础 培训教材 第 10 页 共 110 页

这些Bug 上浪费时间。

1.3 如何学习此门课

1.3.1 测试准备工作

在测试工作伊始，软件测试工程师应该搞清楚软件测试工作的目的是什么。作为一名软件测试新手，如何才能发现所有的 BUG ？如何开始测试工作？即便面对的是一个很小的软件项目，测试需要考虑的问题也是方方面面的，包括硬件环境、操作系统、产品的软件配置环境、产品相关的业务流程、用户的并发容量等等。

1.3.2 向有经验的测试人员学习

如果你进入的是一家运作规范的软件公司，有独立的软件测试部门、规范的软件测试流程、软件测试技术有一定的积累，你可以请求测试经理委派有经验的测试人员作为你工作上的业务导师，由他列出软件测试技术相关书籍目录、软件测试流程相关文档目录、产品业务相关的文档目录，在业务导师的指导下逐步熟悉软件测试的相关工作。

如果你进入的是一个软件测试一片空白的软件企业，可以到国内的软件测试论坛和相关网站上寻找软件测试资源，这种情况下，自学能力和对技术的悟性就至关重要了。

1.3.3 阅读软件测试的相关书籍

现在，中文版的软件测试书籍越来越多，有的是国人自己写的，有的是翻译国外经典之作。可以到 f48261c25fbfc77da269b177 或者 f48261c25fbfc77da269b177 等网络购书的站点查找软件测试相关的书籍。

1.3.4 走读缺陷跟踪库中的问题报告单

缺陷跟踪库中的问题报告单是软件测试工程师工作绩效的集中体现，同时也是软件产品问题的集中体现。一般来说，缺陷报告单中最关键的几个部分包括：第一部分是发现缺陷的环境，包括软件环境、硬件环境等；第二部分是缺陷的基本描述；第三部分是开发人员对缺陷的解决方法。通过对上述缺陷报告单的三个部分作仔细分析，不知不觉你已经吸收了其他软件测试人员的工作经验，并掌握了软件产品常见的基本问题。这是迅速提高软件测试经验的好方法。

1.3.5 走读相关产品的历史测试用例

如果你所在的公司有测试用例管理系统，那么，走读相关产品的软件测试用例是迅速提高测试用例设计水平的一条捷径。走读测试用例也是有技巧的。测试用例写作一般会包括测试用例项和根据测试用例项细化的测试用例，下面举例说明。 “ 测试用户登录的功能 ”

软件测试基础 培训教材 第 11 页 共 110 页

是一个测试项，该测试项的目的是测试用户登录功能是否正确，是否能够完成正常的登录功能，是否能够对非法用户名和密码做异常处理等等。因此，根据该用例项，可以设计出若干个测试用例，大多数情况下，测试用例项和测试用例是一对多的关系。

1.3.6 学习产品相关的业务知识

软件测试人员不仅要掌握软件测试技术相关知识，对产品相关的业务知识也要学习。如果你是一个软件测试技术专家，但是对产品业务知识一无所知，那么也只能测试出来纯粹的软件缺陷，而面对眼前出现的产品业务相关的缺陷，很可能是视而不见，如此这般，软件测试的效果会大打折扣。

1.3.7 识别测试需求

识别测试需求是软件测试的第一步。如果开发人员能够提供完整的需求文档和接口文档，那固然好。可以根据需求文档中描述的每个功能项目的输入、处理过程和输出，来设计测试用例。如果开发人员没有提供软件需求文档，则可用以下几点进行：输入、处理过程、输出、性能要求、运行环境。

1.3.8 确认需求的优先级

确认需求的优先级是很必要的，如果在产品进度比较紧的情况下，测试人员可以考虑优先测试优先级高的需求项，如果进度允许，那么在测试优先级低的需求项，如果进度不允许，那么就放弃测试优先级低的需求项。

1.3.9 利用已有的软件 Checklist

在设计测试用例的时候，不妨到网上去搜索相关的 Checklist ，不过国内外的网站很少有这方面的资料，即便有，也不是特别系统。可以先找一份粗糙的 Checklist ，然后，在设计测试用例的时候不断的去完善它，以作为下次测试用例设计的基础。

1.3.10 测试用例设计及编写

根据产品需求、相关技能知识进行用例设计及编写。

1.4 如何成为一个好的测试人员

1. 工作积极主动

工作态度如何，是评价一个测试人员最主要的方面，一个高水平的测试人员（指纯技术能力）如果没有一个好的工作态度，在测试团队中有时候不但不能对测试工作起到推动作用，有时候还起到阻碍作用，而一个愿意工作的测试人员，哪怕他的技术水平不高，人也不

软件测试基础 培训教材 第 12 页 共 110 页

聪明，但对自己的工作认真负责，你告诉他的事情，他都可以认真去做，这个测试人员也会对测试工作起到很大的促进作用。这也是为什么很多企业愿意让刚参加工作的人员做测试工作的一个主要原因。另外，测试人员对工作是否主动也会很影响一个测试人员的发展，举一个例子，有一个测试人员在自己工作空闲的时候会自己去学习QTP ，提高自己的技术水平，这样在下一个测试的时候，他可以熟练的使用这个测试工具去进行自动化测试，不但提高了工作效率降低了工作强度而且为自己创造了更好的发展机会（因为使用QTP 效果好，被提升为测试组长）。所以说有效的利用工作时间，主动学习对一个人发展是很重要的。另外一个例子也差不多，有一个测试人员，在自己的测试任务异常终止的时候，而其他测试组任务很忙的情况下，主动要求参加其他组的测试工作，先不说他的技术水平如何，这种主动要求工作的态度就让他从其他人中脱颖而出，引起了领导的重视，自然对他的工作会格外注意，而每一次的交流都会让他学到很多新东西。

2. 认真，细心，不怕麻烦

不能不说的是，测试工作是一个烦琐的工作，如果你不是认真、细心，不怕麻烦的人，建议你最好不要进入这个行业，否则，最后难受的肯定是你自己。有那么一句话：细节决定成败，这句话格外适用于测试人员。测试人员的在做测试需求的时候，开发人员人员的写的系统需求报告中的每一个需求点都会在测试需求中成为几个测试需求点（要验证正常情况，异常情况），有时候给人的感觉就象在玩排列组合的游戏，但这个游戏排列组合的情况实在太多了，如果耐心不够，细心不够是很容易遗漏测试需求点的，而这些遗漏的地方往往是问题点（开发人员也容易忘记考虑这些地方，从而产生问题），另外测试工作输入的数据是一个很烦琐的事情举一个例子来说，一个日期合法性测试，很容易总结三、四百个测试数据，你想全部测试工作会是一个什么数量。而更可怕的是，测试不是一次性的工作，经常需要做回归测试，所有烦琐的工作必须不断的重复，而在重复的时候测试人员往往会因为怕麻烦，减少测试用例数，造成测试的不全面。所以说认真、细心、不怕麻烦是一个好的测试必备的素质要求。

3. 学习能力强，善于总结

早期刚接触测试的时候，测试方面的书也几乎没有，这些都对从事测试人员的水平的提高产生了很大的妨碍，但也并不能成为提高自己水平的借口。在QTP 的学习过程中，曾有一个测试人员，学习了3个月，就基本掌握了QTP 的使用，而且还总结了使用QTP 常遇到的问题发表到了51testing 上，很多人都认为他是一个技术大拿，其实他只是一个工作了8个月，学习了3个月的新手。不断的学习新技术，不断总结在实际工作遇到的问题，解决的方法，并进行整理归纳，是一个测试人员提高自己的技术水平的最好的方法。

4. 掌握测试理论

开发工具在变，测试工具在变，被测试的系统在变，一切的东西都在变，那么作为一个测试人员最重要的是学习什么，个人认为是测试理论的学习，举个例子来说，原有个程序员，在工作中接触到了很多和硬件相关的测试，比如手机测试，但不管测试的是什么系统基本理论是不变的，首先都需要开发人员提供比较好的需求文档，概要设计文档，详细设计文档等。需求文档是测试制定测试需求的标准，也是测试判断系统是否存在问题的标准，而概要设计文档，详细设计文档是制作测试用例的依据。划分等价类，边界值测试等是基本测试的方法都需要这些文档的支持。当然每一种不同类型的测试，都有其特殊的地方，比如手机的测试就需要对通讯理论有一定的了解（也就是系统环境），所以说好的测试人员必须掌握测试理论。

5. 人际关系的处理

软件测试基础

培训教材 第 13 页 共 110 页

测试工作是一个问题的爆发点，特别是对于那些开发流程不规范的企业，如何处理好人际关系，是一个好的测试人员需要掌握的技巧，作为一个测试负责人要和开发人员、测试人员、公司领导经常面临短暂的测试时间，不断的回归测试，测试的异常终止，领导的批评，开发人员的指责，测试人员对测试时间、测试环境的抱怨。如何化解矛盾，处理好这些问题是一个衡量测试人员好坏的标准。人际关系处理不好，其实一个主要的问题就是误解，开发人员、公司领导对于测试工作的工作量的误解是产生这些矛盾的一个主要原因，所以作为好的测试人员，除了具备一些常用的人际关系处理技巧以外，还要是一个好的宣传员，不断将测试的方法、理论、工作量对开发人员、上级领导进行宣讲，让他们对测试工作有一个正确的认识，只有这样才能真正处理好测试部门和其他工作人员的人际关系，使测试向一个好的方向发展。

6. 熟悉开发工具和平台

了解开发平台和工具是做单元测试、性能测试等的基础。

7. 掌握测试工具

随着市场变化及软件质量要求越来越高，软件测试自动化也变得越来越重要。大部分软件测试自动化是靠测试工具进行实现。

1.5 外包测试

1.5.1 什么是软件外包

所谓软件外包就是一些发达国家的软件公司将他们的一些非核心的软件项目通过外包的形式交给人力资源成本相对较低的国家的公司开发，以达到降低软件开发成本的目的。众所周知，软件开发的成本中70%是人力资源成本，所以，降低人力资源成本将有效地降低软件开发的成本。

软件外包已经成为发达国家的软件公司降低成本的一种重要的手段。目前，全球软件的销售额为6，000亿美元，而其中软件外包的销售额即达到500～600亿美元。预期到2005年软件外包的销售额将达到1，000亿美元。软件外包的大幅度增长为人力资源成本相对较低的印度和中国带来了新的发展机会。

中国目前已经有不少的公司开始介入软件外包这一领域。目前软件外包产业较为发达的地区有上海、北京、大连以及深圳等城市。以北京为例，有40%的软件企业参与外包项目，软件行业60%～70%的营业额来自外包。在上海和北京，一个软件外包工程师的月薪达到7，000～10，000元人民币，而同样能力的软件工程师在武汉只需要三～四千元人民币。资本的特征是向成本更低的地方流动，所以，近一段时间以来已经有大量的东部软件公司准备迁移到中部地区，目前首选的地区主要是武汉和西安。

软件外包将为中国软件业带来什么呢？不仅仅是经济发展的机会，还有先进的软件开发管理流程，以及严格的软件质量控制体系。通过发展软件外包产业， 我国的软件产业将逐渐地告别手工作坊式的开发时代，进入工程化、规模化的开发领域。

为抓住这一历史性的机遇， 我国政府正全力为这些软件外包公司营造更好的投资环境，政府已经在多个重点城市建立开发区，设立多个全新的软件开发园区，并对于入园的软件企业给予相当优惠的政策条件。但是，仅有政策条件和环境条件是不够的，对软件企业影响最大的是人力资源成本，能否提供多数量多的、成本较低并在质量方面满足需要的软件外

软件测试基础 培训教材 第 14 页 共 110 页

包工程师是我国能否抓住这一历史机遇的重要条件。

1.5.2 什么是软件外包测试

服务商从开发商那里取得测试项目，分析测试需求，执行具体的测试过程，报告软件缺陷。服务商是软件测试活动的直接执行者。

软件外包测试处理的流程如下图所示：

图 1-1 软件外包测试处理流程

开发商通过电子邮件等方式传递软件测试要求（测试计划、测试缺陷管理和项目交流方式等），外包服务商指定测试项目经理分析和审阅开发上发来的测试要求，如果对测试要求有任何疑问或建议，及时告诉开发商，待开发上给出合理解释后，准备进行具体的测试过程。

服务商在执行测试的过程中，对于新软件测试版本首先进行版本验证测试（ Build Verified Testing - BVT ），并且把 BVT 的结果发送回软件开发商。对于软件的常规测试发

现的软件缺陷，使用软件开发商提供的缺陷跟踪管理系统报告和查询。对于测试周期较长的软件外包测试项目，测试服务商需要每周（甚至每天）向软件开发商提供测试进度和测试结果等测试状态报告。测试状态报告的提交频率可以在项目开始前的准备阶段与客户确认，一般每周结束时报告一次。

软件测试基础

培训教材 第 15 页 共 110 页

为了保证软件外包测试的有效性，测试服务商需要对测试结果进行内部的质量保证（ QA ）过程。如果没有通过内部 QA 测试，则测试服务商的测试人员需要重新或补充测试；如果通过了内部 QA 测试，则可以向软件开发商提交测试结果。

软件开发商的软件开发人员负责每天跟踪和修正测试服务商报告的软件缺陷，然后重新编译出软件新测试版本。开发商的软件编译人员对刚编译的软件版本执行基本功能检查，这个过程称为”冒烟测试 (Smoke Testing) ”。

如果通过了软件冒烟测试，则开发商将新的被测试版本上传到项目开始时约定的文件服务器中，并且使用电子邮件等方式通知测试服务商准备新版本测试。

在软件项目测试后期，理想情况下软件缺陷为 0 ，则进行最终软件版本的测试，最后向开发商提交最终版本的测试结果。

练习

1. 你是如何看等测试的？

2. 如果你是新手，打算从事测试工作，你将如何学习这门课，请列出学习计划。

软件测试基础 培训教材 第 16 页 共 110 页

第2章 软件测试基础

2.1 软件测试概念

2.1.1 软件测试定义

比较常见二种对软件测试定义为：

(1) 软件测试是为了发现错误而执行程序的过程。

(2) 软件测试是根据软件开发阶段的规格说明和程序的内部结构而精心设计的一批测

试用例（即输入数据及预期的输出结果），并利用这些测试用例去运行程序，以发

现错误的过程。

软件测试就是在受控制的条件下对系统或应用程序进行操作并评价操作的结果。也就是说，如果用户面对着应用程序的 A 界面，在使用硬件 B 的时候做 C 操作，那么 D 结果应该出现。所谓受控制的条件应该包括正常条件和非正常条件。应该故意地去促使错误的发生，也就是事情在不该出现的时候出现或者在应该出现的时候没有出现。从本质上说，软件测试是“探测”。

在如何负责质量保障和软件测试的责任方面，各个机构有不同的做法。有时候，由一个小组或者个人来负责。常见的办法是项目组包括了测试人员和开发人员，他们在一起合作工作，由项目负责人来对质量保障进行总负责。这取决于该机构的大小和该机构的商务结构。

2.1.2 软件测试术语

软件质量(SW Quality)：软件的功能和性能满足用户需要的程度。

软件Build ：用于测试的软件中间版本程序。

软件缺陷(SW Defect/bug/error)：软件的功能/性能/界面/文档与软件需求文档和用户的需要不一致的现象。

软件缺陷生命周期(SW defect lifecycle)：报告、确认、修正、验证、关闭。

测试用例(Testcase)：包含输入条件、执行步骤和测试期望的正确结果的文档。

缺陷跟踪系统（DTS ）：管理软件缺陷的整个生命周期的工具。

静态测试与动态测试(Statistic testing and dynamic testing)：不执行/执行程序进行的测试 白盒测试与黑盒测试（White box testing and Black box testing ）：测试软件代码结构的测试，不关心软件代码结构，以软件输入和输出来测试软件功能的测试。

回归测试与冒烟测试（Regression testing and smoke testing ）:在新的软件Build 上验证修正的缺陷是否不再现，在大规模测试前，快速执行的基本功能测试。

软件里程碑（SW Milestone ）：软件项目开发的各个关键过程。

软件测试基础

培训教材 第 17 页 共 110 页

2.2 软件测试目的与局限性

2.2.1 软件测试目的与原则

目的：

(1) 寻找软件的缺陷

(2) 跟踪修正软件缺陷

(3) 验证修正的软件缺陷

原则：

(1) 尽早进行软件测试，早期发现和报告软件缺陷

(2) 全程测试，测试过程贯穿于整个项目的生命周期

(3) 测试独立与开发，开发人员不能测试自己的软件

(4) 软件的缺陷驱动开发（基本代码完成后愈加明显）

2.2.2 软件测试局限性

1. 不可能完全测试一个程序。

完全测试一个程序意味着在测试结束时，再也没有未发现的软件错误。

不可能完全测试一个程序的原因：

(1) 可能的输入范围太大，根本无法穷尽测试

(2) 程序中可运行的路径太多，根本无法穷尽测试

(3) 用户界面问题（及相应的设计问题）太复杂，不可能进行完全测试

2. 不可能测试到程序对任何可能输入的响应

对程序必须执行的测试：

(1) 要对所有有效的输入进行测试

(2) 要对所有无效的输入进行测试

(3) 要对所有编辑过的输入进行测试

(4) 要对所有输入时机的变化情况进行测试

3. 不可能测试到程序每一条可能的执行路径

如状态之间变化，状态1至状态6。

4. 无法找出所有设计错误

如规格说明”2+2=5”。

软件测试基础

培训教材 第 18 页 共 110 页

2.2.3 软件测试误区

1. 测试新手对测试的看法：

(1) 认为他们能够充分地测试每一个程序

(2) 通过完全测试，他们能够保证程序正常运行

(3) 认为测试人员的工作任务就是通过进行完全测试，来保证程序的正确性。

2. 在测试过程中需思考问题：

(1) 测试的目的

(2) 测试优劣区别

(3) 做多少测试算足够了

(4) 怎么才能说，何时测试已经足够了

思考与讨论：

软件测试就是敲敲键盘，动动鼠标很容易，谁都能干

软件测试很难，无法保证测试有效性

软件开发完成后进行软件测试

软件发布后如果发现质量问题，那是软件测试人员的错

软件自动测试效率高，将取代软件手工测试

软件测试是测试人员的事情，与程序员无关

项目进度吃紧时少做些测试，时间富裕时多做测试

软件测试是没有前途的工作，只有程序员才是软件高手

2.3 软件测试类型

按照比较的方式，一般把测试分为静态测试与动态测试，白盒测试与黑盒测试，随机测试与穷举测试，自动测试与人工测试；按照测试步骤分为单元测试，集成测试，系统测试，回归测试，验收测试等。

另外，常见的软件测试类型还有：

BVT (Build Verification Test)，BVT 是在所有开发工程师都已经检入自己的代码，项目组编译生成当天的版本之后进行，主要目的是验证最新生成的软件版本在功能上是否完整，主要的软件特性是否正确。如无大的问题，就可以进行相应的功能测试。BVT 优点是时间短，验证了软件的基本功能。缺点是该种测试的覆盖率很低。因为运行时间短，不可能把所有的情况都测试到。

Scenario Tests （基于用户实际应用场景的测试），在做BVT 、功能测试的时候，可能测试主要集中在某个模块，或比较分离的功能上。当用户来使用这个应用程序的时候，各个模块是作为一个整体来使用的，那么在做测试的时候，就需要模仿用户这样一个真实的使用

软件测试基础 培训教材 第 19 页 共 110 页

环境，即用户会有哪些用法，会用这个应用程序做哪些事情，操作会是一个怎样的流程。加了这些测试用例后，再与BVT 、功能测试配合，就能使软件整体都能符合用户使用的要求。Scenario Tests 优点是关注了用户的需求，缺点是有时候难以真正模仿用户真实的使用情况。

Smoke Test ，在测试中发现问题，找到了一个Bug ，然后开发人员会来修复这个Bug 。这时想知道这次修复是否真的解决了程序的Bug ，或者是否会对其它模块造成影响，就需要针对此问题进行专门测试，这个过程就被称为Smoke Test 。在很多情况下，做Smoke Test 是开发人员在试图解决一个问题的时候，造成了其它功能模块一系列的连锁反应，原因可能是只集中考虑了一开始的那个问题，而忽略其它的问题，这就可能引起了新的Bug 。Smoke Test 优点是节省测试时间，防止build 失败。缺点是覆盖率还是比较低。

此外，Application Compatibility Test （兼容性测试），主要目的是为了兼容第三方软件，确保第三方软件能正常运行，用户不受影响。Accessibility Test （软件适用性测试），是确保软件对于某些有残疾的人士也能正常的使用，但优先级比较低。其它的测试还有Functional Test （功能测试）、Security Test （安全性测试）、Stress Test （压力测试）、Performance Test （性能测试）、Regression Test （回归测试）、Setup/Upgrade Test （安装升级测试）等。

2.3.1 静态测试

2.3.1.1 静态测试概念

静态测试包括代码检查、静态结构分析、代码质量度量等。它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具自动进行。

代码检查 代码检查包括代码走查、桌面检查、代码审查等，主要检查代码和设计的一致性，代码对标准的遵循、可读性，代码的逻辑表达的正确性，代码结构的合理性等方面；可以发现违背程序编写标准的问题，程序中不安全、不明确和模糊的部分，找出程序中不可移植部分、违背程序编程风格的问题，包括变量检查、命名和类型审查、程序逻辑审查、程序语法检查和程序结构检查等内容。

在实际使用中，代码检查比动态测试更有效率，能快速找到缺陷，发现30%～70%的逻辑设计和编码缺陷；代码检查看到的是问题本身而非征兆。但是代码检查非常耗费时间，而且代码检查需要知识和经验的积累。代码检查应在编译和动态测试之前进行，在检查前，应准备好需求描述文档、程序设计文档、程序的源代码清单、代码编码标准和代码缺陷检查表等。

静态结构分析 静态结构分析主要是以图形的方式表现程序的内部结构，例如函数调用关系图、函数内部控制流图。其中，函数调用关系图以直观的图形方式描述一个应用程序中各个函数的调用和被调用关系；控制流图显示一个函数的逻辑结构，它由许多节点组成，一个节点代表一条语句或数条语句，连接结点的叫边，边表示节点间的控制流向。

代码质量度量 ISO/IEC 9126国际标准所定义的软件质量包括六个方面：功能性、可靠性、易用性、效率、可维护性和可移植性。软件的质量是软件属性的各种标准度量的组合。

针对软件的可维护性，目前业界主要存在三种度量参数：Line 复杂度、Halstead 复杂度和McCabe 复杂度。其中Line 复杂度以代码的行数作为计算的基准。Halstead 以程序中使用到的运算符与运算元数量作为计数目标（直接测量指标），然后可以据以计算出程序容量、工作量等。McCabe 复杂度一般称为圈复杂度(Cyclomatic complexity)，它将软件的流

软件测试基础 培训教材 第 20 页 共 110 页

程图转化为有向图，然后以图论来衡量软件的质量。McCabe 复杂度包括圈复杂度、基本复杂度、模块设计复杂度、设计复杂度和集成复杂度。

2.3.1.2 静态测试要点

(1) 同一程序内的代码书写是否为同一风格

(2) 代码布局是否合理、美观

(3) 程序中函数、子程序块分界是否明显

(4) 注释是否符合既定格式

(5) 注释是否正确反映代码的功能

(6) 变量定义是否正确（长度、类型、存储类型）

(7) 是否引用了未初始化变量

(8) 数组和字符串的下标是否为整数

(9) 的数组和字符串的下标是否在范围内（不”越界”）

(10) 进行数组的检索及其它操作中，是否会出现”漏掉一个这种情况”

(11) 是否在应该使用常量的地方使用了变量（例：数组范围检查）

(12) 是否为变量赋予不同类型的值的情况下，赋值是否符合数据类型的转换规则

(13) 变量的命名是否相似

(14) 是否存在声明过，但从未引用或者只引用过一次的变量

(15) 在特定模块中所有的变量是否都显式声明过

(16) 非（15）的情况下，是否可以理解为该变量具有更高的共享级别

(17) 是否为引用的指针分配内存

(18) 数据结构在函数和子程序中的引用是否明确定义了其结构

(19) 计算中是否使用了不同数据类型的变量

(20) 计算中是否使用了不同的数据类型相同但长度不同的变量

(21) 赋值的目的变量是否小于赋值表达式的值

(22) 数值计算是否会出现溢出（向上）的情况

(23) 数值计算是否会出现溢出（向下）的情况

(24) 除数是否可能为零

(25) 某些计算是否会丢失计算精度

(26) 变量的值是否超过有意义的值

(27) 计算式的求值的顺序是否容易让人感到混乱

(28) 比较是否正确

(29) 是否存在分数和浮点数的比较

(30) 如果（29），精度问题是否会影响比较

(31) 每一个逻辑表达式是否都得到了正确表达

软件测试基础

培训教材 第 21 页 共 110 页

(32) 逻辑表达式的操作数是否均为逻辑值

(33) 程序中的Begin…End 和Do…While 等语句中，End 是否对应

(34) 程序、模块、子程序和循环是否能够终止

(35) 是否存在永不执行的循环

(36) 是否存在多循环一次或少循环一次的情况

(37) 循环变量是否在循环内被错误地修改

(38) 多分支选择中，索引变量是否能超过可能的分支数

(39) 如果（38），该情况是否能够得到正确处理

(40) 子程序接受的参数类型、大小、次序是否和调用模块相匹配

(41) 全局变量定义和用法在各个模块中是否一致

(42) 是否修改了只作为输入用的参数

(43) 常量是否被做为形式参数进行传递

2.3.2 动态测试

2.3.2.1 动态测试概念

动态测试包括功能测试与接口测试、覆盖率分析、性能分析、内存分析等。

功能与接口测试： 这部分的测试包括各个单元功能的正确执行、单元间的接口，包括：单元接口、局部数据结构、重要的执行路径、错误处理的路径和影响上述几点的边界条件等内容。

覆盖率分析： 覆盖率分析主要对代码的执行路径覆盖范围进行评估，语句覆盖、判定覆盖、条件覆盖、条件/判定覆盖、修正条件/判定覆盖、基本路径覆盖都是从不同要求出发，为设计测试用例提出依据的。

性能分析： 代码运行缓慢是开发过程中一个重要问题。一个应用程序运行速度较慢，程序员不容易找到是在哪里出现了问题?如果不能解决应用程序的性能问题，将降低并极大地影响应用程序的质量，于是查找和修改性能瓶颈成为调整整个代码性能的关键。目前性能分析工具大致分为纯软件的测试工具、纯硬件的测试工具（如逻辑分析仪和仿真器等）和软硬件结合的测试工具三类。

内存分析： 内存泄漏会导致系统运行的崩溃，尤其对于嵌入式系统这种资源比较匮乏、应用非常广泛，而且往往又处于重要部位的，将可能导致无法预料的重大损失。通过测量内存使用情况，我们可以了解程序内存分配的真实情况，发现对内存的不正常使用，在问题出现前发现征兆，在系统崩溃前发现内存泄露错误；发现内存分配错误，并精确显示发生错误时的上下文情况，指出发生错误的原由。

连接方式： 在嵌入式软件测试中，测试系统Host 与被测试系统Target 的连接有两种方式：直接连接和通过仿真器连接。直接连接是Host 与Target 通过串口、并口或网口直接连接。

本文来源：https://www.bwwdw.com/article/90hl.html