软件测试与质量控制教程1

1、软件工程软件测试与质量控制教程1-8全集舒文静选取日期在此处键入文档摘要。摘要通常为文档内容的简短概括。在此处键入文档摘要。摘要 通常为文档内容的简短概括。目录软件测试与质量控制 教程 1 3概述 3什么是软件测试 4为什么要做软件测试 4软件测试人员做什么 4软件测试环境 4软件缺陷有哪些 4什么是测试用例 5软件测试分类 5静态测试和动态测试 5黑盒测试和白盒测试 5单元测试、集成测试、系统测试和验收测试 5功能测试和性能测试 6回归测试和冒烟测试 6软件测试分类关系 6软件配置管理 7软件测试管理 7组织管理 7计划管理 8用例管理 9文档管理 10软件测试与质量控制 教程 2 10概述

2、 10测试需求概念 10测试需求分析工作步骤 11小结 11项目说明 11软件测试与质量控制 教程 3 11概述 11测试计划主要内容 12项目说明 13软件测试与质量控制 教程 4 14概述 14黑盒测试方法 14等价类划分法 14划分步骤 14划分方法 15等价类划分法测试用例设计原则 15实例分析 15边界值分析法 16确定边界 17边界值分析法测试用例设计原则 17实例分析 17因果图法 18为什么要用因果图 18因果图符号和概念 19实例分析 20错误推测法 23不同测试方法选择原则 23项目说明 24软件测试与质量控制 教程 5 24概述 24缺陷分类 24缺陷描述 25缺陷处理流

3、程 27项目说明 28软件测试与质量控制 教程 6 29概述 29自动化测试工具分类 29自动化测试工具一览 29WinRunner 功能测试工具 31项目说明 32软件测试与质量控制教程 7 33概述 33代码检查 33白盒测试方法 33逻辑覆盖法 33语句覆盖 34判定覆盖 34条件覆盖 34判定条件覆盖 34条件组合覆盖 34路径覆盖 34各种逻辑覆盖之间关系 34基本路径法 35控制流图 35复合条件分解 36环形复杂度 36基本路径法测试用例设计步骤 37实例分析 37软件测试与质量控制教程 8 39概述 39测试报告主要内容 39项目说明 40软件测试与质量控制 教程 1概述软件测

4、试是 IT 行业的一项职业性活动。对应的工作岗位有软件测试工程师、测 试经理等岗位， 另外软件开发工程师也需要掌握单元测试的有关内容。 软件测试 过程伴随软件开发过程始终。 作为一名职业软件测试人员， 有必要对软件测试的 基础知识有所了解。什么是软件测试软件测试就是发现并指出软件中存在缺陷的过程。 这里所说的软件既包括运行程 序也包括软件设计开发过程中产生的需求、 设计等相关文档以及编码过程中产生 的源程序代码。为什么要做软件测试传统行业都有质量检查环节， 对生产出来的产品进行质量检验， 以确保生产出的 产品是合格的。软件产品的质量检验是通过软件测试来完成的。软件设计开发过程中可能会出现很多问

5、题， 需要通过软件测试手段来发现软件缺 陷，保证软件质量。软件测试人员做什么 软件测试人员的目标就是尽可能早的找出软件缺陷， 并确保其得到修复。 软件测 试人员的主要工作包括制定测试计划、 设计测试用例、 执行测试、 对发现的缺陷 进行跟踪管理、对测试结果进行分析总结等内容。软件测试环境 软件测试环境就是软件运行的平台，包括软件、硬件和网络。硬件主要包括 PC 机、笔记本、服务器、各种PDA终端设备等。软件主要是指软件运行的操作系统， 数据库管理系统，Wet服务器、浏览器等。网络主要针对的是 C/S结构和B/S结 构的软件所使用的网络设备情况 （类型、速度等 ） 。软件缺陷有哪些软件出现的故障

6、我们一般叫软件缺陷， 符合以下 5 条规则的情况都可以称为软件 缺陷：1. 软件未达到产品说明书标明的功能；2. 软件出现了产品说明书指明不会出现的错误；3. 软件功能超出产品说明书指明范围；4. 软件未达到产品说明书虽未指明但应达到的目标；5. 软件测试人员认为软件难以理解、 不易使用、 运行速度缓慢或者最终用户认为不好什么是测试用例测试用例是测试执行的依据，是指在测试执行之前设计的一套详细的测试方案， 包括测试环境、测试步骤、测试数据和期望结果。软件测试分类 人们根据测试目的和测试角度的不同将软件测试分成众多的类别。 我们经常听到 诸如静态测试、动态测试、黑盒测试、白盒测试、单元测试、集成

7、测试等名词。 作为一名软件测试人员，我们有必要了解这些软件测试分类的具体内容。静态测试和动态测试 软件测试按照是否需要运行程序可以分为静态测试和动态测试。 静态测试是指不实际运行被测软件， 只是静态地检查程序界面、 文档和源程序代 码中可能存在的错误的过程。 其中代码测试主要测试源代码是否符合相应的标准 和规范；界面测试主要测试软件的实际界面与需求中的说明是否相符； 文档测试 主要测试用户使用手册和需求说明是否真正符合用户的实际需求。动态测试是指实际运行被测软件， 输入相应的测试数据， 检查实际输出结果和预 期结果是否相符的过程。黑盒测试和白盒测试 软件测试按照是否需要了解程序内部结构可以分为

8、黑盒测试和白盒测试。 黑盒测试是指把被测软件当作是一个黑盒子， 测试人员不需要知道盒子里面的结 构，只关心软件的输入数据和输出结果，设计相应测试用例测试软件的过程。 白盒测试是相对黑盒测试来说的。 是指把被测软件当作是一个透明盒子， 测试人 员需要知道被测软件的程序结构，然后设计相应测试用例测试软件的过程。 黑盒测试和白盒测试都有相应的测试用例设计方法，后续我们将进行详细介绍。 单元测试、集成测试、系统测试和验收测试 软件测试按测试阶段可以分为单元测试、集成测试、系统测试和验收测试。 单元测试是指对软件中的最小可测试单元进行检查和验证。 最小可测试单元可以 是函数 （面向过程程序 ） ，也可以

9、是类 （ 面向对象程序 ） ，需要根据实际情况具体 分析。单元测试在编码完成程序编译之后执行， 一般由软件开发人员完成。 单元 测试依据程序的源代码和详细设计文档， 主要采用白盒测试方法， 先检查代码编 写规范性（静态测试） ，然后运行代码， 检查实际运行结果 （动态测试） 。单元测试 一般需要编写测试程序对程序模块进行测试。集成测试是单元测试的下一阶段， 是指将通过测试的单元模块组装成系统或子系 统，再进行测试， 主要测试不同模块的接口部分。 集成测试的目的是检查各个单 元模块集成在一起后是否能正常运行。 集成测试在单元测试完成后执行， 一般由 软件开发人员和软件测试人员共同完成。 集成测试

10、依据单元测试的模块和概要设 计文档，采用白盒和黑盒测试方法。 集成测试可以采用增量和非增量两种方式进 行。增量式集成是指按照一定次序 （自顶至下或自底向上 ）逐步集成程序， 这种测 试方式需要编写测试程序。 非增量式集成是指一次性把所有程序模块集成为一个 完整系统，这种测试方式不需要编写测试程序。系统测试是集成测试的下一阶段，是指将整个软件系统看作一个整体进行测试， 包括功能测试、 性能测试以及软件所运行的软硬件环境兼容性测试等内容。 系统 测试在集成测试完成后执行， 由软件测试人员完成。 系统测试主要依据软件需求 文档，采用黑盒测试方法。 先测试系统的功能是否满足需求， 然后测试系统的性 能

11、是否满足需求，最后测试系统在不同软硬件环境中的兼容性。验收测试在系统测试完成后执行， 测试内容包含系统测试的内容， 另外还包括对 用户文档的测试。验收测试的测试人员以用户为主。功能测试和性能测试软件测试按测试内容可以分为功能测试和性能测试。功能测试是黑盒测试的一个方面，主要检查待测软件的功能是否满足用户的需 求。功能测试可以细分为逻辑功能测试、界面测试、易用性测试、安装测试和兼 容性测试等内容。功能测试可以使用自动化测试工具进行。后续第 13 章将介绍 WinRunner功能测试开发内容。性能测试是黑盒测试的另一个方面， 主要检查待测软件的性能是否满足用户的需 求。性能测试可以细分为一般性能测

12、试、 稳定性测试、 负载测试和压力测试等内 容。性能测试一般使用自动化测试工具进行。回归测试和冒烟测试回归测试和冒烟测试是两个不相干的概念，我们单独描述。 回归测试是指测试过程中对软件的新版本进行测试时， 重复执行上一个版本测试 时的测试用例。回归测试在集成测试阶段进行。冒烟测试是指在对一个软件新版本进行系统大规模的测试之前， 先验证一下软件 的基本功能是否实现，是否具备可测性。冒烟测试一般在系统测试之前进行。 软件测试分类关系 »f5ASr B 1£ A1 111功褻 试试1 试'JIM前面我们对常见的软件测试分类进行了简单介绍。 这么多的测试分类，看上去很 复杂

13、，实际上只是分类角度有所不同。同一种测试，按照不同角度划分，可以属 于不同的测试分类。下图描述了这些测试分类之间的关系。!L_J了辭 的构 3”r%JS A软件配置管理在一个实际的软件开发项目中，软件开发过程产生的各种产品必须纳入软件配置 管理范围。软件测试人员在测试过程中往往需要对各种开发测试产品（文档、代码等）进行各种配置管理操作，例如从配置库获取配置项，将创建的测试产品添 加到配置库等操作。软件测试管理软件测试管理就是以测试项目为管理对象，通过一个临时性的专门的测试组织， 运用专门的软件测试知识、技能、工具和方法，对测试项目进行计划、组织、执 行和控制，并在时间成本、软件测试质量等方面进

14、行分析和管理活动。软件测试 管理贯穿整个测试项目的生命周期，是对测试项目的全过程进行管理。组织管理测试项目成功完成的关键因素之一就是要有高素质的软件测试人员，并将他们有效地组织起来，分工合作，形成一支精干的队伍，使他们发挥出最大的工作效率。测试的组织与人员管理就是对测试项目相关人员在组织形式、 人员组成与职责方 面所做的规划和安排。组织结构是指用一定的模式对责任、 权威和关系进行安排， 直至通过这种结构发 挥功能。进行软件测试的测试组织结构形式很多， 目前常见的测试组织结构有独立的测试 小组和集成的测试小组两种形式。1. 独立测试小组2. 集成测试小组独立的测试小组，即主要工作是进行测试的小组

15、， 他们专门从事软件的测试工作。 测试组设组长一名， 负责整个测试的计划、 组织工作。 测试组的其他成员由具有 一定的分析、 设计和测试经验的专业人员组成， 人数根据具体情况可多可少， 一 般35人为宜。测试组长与开发组长在项目中的地位是同级、平等的关系。集成测试小组是将测试与基本设计因素组合起来， 构成的测试组织结构。 这是与 独立测试有关的一种集成测试组织形式， 即集成测试小组是由需要向同一个项目 经理汇报工作的测试人员和开发人员组成。计划管理测试计划就是描述所有要完成的测试工作， 包括被测试项目的背景、 目标、范围、 方式、资源、进度安排、测试组织，以及与测试有关的风险等方面。测试计划制

16、定及管理的主要工作内容如下：1. 结合已批准的软件系统测试需求及所使用的测试工具， 测试负责人与项目 经理协商， 逐步确定测试项目的测试目标、 范围、粒度（ 覆盖标准 ） 以及测 试方案 （ 包括各个测试阶段的出入口准则的协商 ） ，在初步估计测试项目规 模及工作量的基础上，协助测试项目开发计划书的可行性；2. 基于项目的系统功能集成方案及系统版本发布计划， 配合项目经理逐步 细化项目计划中的阶段小版本创建和发布里程碑点， 并逐步细化测试方案 及测试规模估计；3. 策划测试实施前准备内容、资源安排 （ 包括人员分配，进度安排等，尤其 要留有合理的测试Bug用例管理时间），细化项目测试计划相关内

17、容；4. 测试负责人必要时还须与项目经理根据项目特性， 确定系统冒烟测试的范 围，粒度以及入口接受标准等内容，细化项目测试方案相关内容；5. 形成系统测试计划书 （ 可包括单元、 集成、系统阶段 ） 并提交评审， 按项目 评审规程执行；6. 当项目开发计划或测试需求发生变更时，按配置管理过程执行。 用例管理 测试用例及管理的工作任务是根据批准的测试需求及方案， 策划测试过程执行依 据，确保测试范围有效并正确。测试用例设计及管理的主要工作内容如下： 用例设计：1. 参与需求评审， 正确理解系统需求并确认需求的可测性， 获取测试项目 需求；2. 根据批准的测试项目需求， 测试目标的逻辑实现和约束，

18、 测试工具及其测 试环境等限制条件， 确定系统的测试中自动和手动测试的范围， 并分别编 写系统测试用例；3. 参与系统设计， 协助验证系统体系结构及其逻辑实现层次的合理性， 功能 模块间的内部及其接口的正确性， 结合系统功能集成方案， 编写集成测试 用例；4. 测试负责人或项目经理需针对系统体系结构设计方案、系统功能集成方 案、系统版本发布计划以及项目开发计划等内容， 组织编写创建脚本和冒 烟测试用例；5. 测试负责人或项目经理负责基于系统的详细设计， 确定单元测试范围和粒 度，有效路径和值域等，组织单元测试中自动和手动测试用例的编写；6. 测试负责人或项目经理负责按测试用例编写要求、 需求跟

19、踪矩阵表完成 编写符合性和需求覆盖性、 有效性、 完整性检查， 并参照项目评审规程实 施评审活动；7. 当项目测试需求发生变更时，按配置管理过程执行。 用例管理：1. 测试负责人或项目经理负责进行阶段测试用例的实施、 跟踪及用例统计分 析工作，及时改进测试用例管理活动；2. 测试负责人或项目经理实时或定期根据 Bug 数据、状态和测试用例执行 情况进行分析，以确定是否需要对目前测试的模块新增设计新的测试用 例：a) 对不稳定的模块， 测试负责人负责与项目经理多次讨论确定测试范围、 粒度和执行方案等，并制定测试人员完成新增测试用例的编写；b) 对极其不稳定或未能达到测试入口标准的模块，则要求退回

20、开发部重 新开发；3. 由测试负责人和项目经理负责进行测试用例的完整性和有效性检查后，组织讨论新增测试用例，批准后由测试人员或开发人员执行；文档管理测试文档是对要执行的软件测试及测试的结果进行描述、定义、规定和报告的任何书面或图示信息。由于软件测试是一个很复杂的过程，同时也涉及到软件开发 中其他一些阶段的工作，因此，必须把对软件测试的要求、规划、测试过程等有 关信息和测试的结果，以及对测试结果的分析、评价，以正式的文档形式给出。测试文档对于测试阶段工作的指导与评价作用更是非常明显的。 需要特别指出的 是，在已开发的软件投入运行的维护阶段， 常常还要进行再测试或回归测试， 这 时还会用到测试文档

21、。测试文档的编写是测试管理的一个重要组成部分。根据测试文档所起的不同作用，通常把它分成两类，即前置作业文档和后置作业 文档。测试计划及测试用例的文档属于前置作业文档。 后置作业文档是在测试 完成后提交的，主要包括软件缺陷报告和分析总结报告。软件测试与质量控制教程2概述测试需求分析是软件测试工作的首要工作任务，该项工作任务在项目开发阶段需求 分析基本完成时切入。测试组人员需要参与开发项目的需求评审，确定项目的测试 需求。测试需求分析的工作产品是测试需求文档。测试需求概念确切地讲，所谓的测试需求就是在项目中要测试什么。我们在测试活动中，首先需 要明确测试需求(What)，才能决定怎么测(How)，

22、测试时间(When),需要多少人(Who)， 测试的环境是什么(Where)，测试中需要的技能、工具以及相应的背景知识，测试中 可能遇到的风险等等，以上所有的内容结合起来就构成了测试计划的基本要素。而 测试需求是测试计划的基础与重点。就像软件的需求一样，测试需求根据不同的公司环境，不同的专业水平，不同的要求，详细程度也是不同的。但是，对于一个全 新的项目或者产品，测试需求力求详细明确，以避免测试遗漏与误解。测试需求，简单理解就是测试人员要对哪些点进行测试。测试需求的内容由软件测 试人员根据用户需求说明书和开发设计说明书整理编写。依据软件需求规格说明书 中相关内容，将系统要实现的功能点罗列出来，

23、测试需求就是这些罗列出来的功能 点。测试需求分析工作步骤我们来总结一下测试需求分析的一般步骤：1. 阅读需求规格说明书，找出与指定功能相关的描述内容。2. 列出描述内容中所有直接提及要实现的功能点3. 根据说明书内容，查找是否存在文档中未提及但是需要达到的功能点，有则 列出来4. 将列出的内容整理成测试需求文档小结测试需求分析工作是一个细致活，需要测试人员有足够的耐心和细心，对功能点的 罗列不能太粗，要尽量具体、完整。根据罗列的功能点整理测试需求列表时，一般 来说功能点与测试点是一对一的关系。但是可以根据实际情况进行适当的归纳合并 或整理细化。总的来说测试需求列表不能太笼统，要具体、详细、可测

24、试。这是测 试需求分析工作中要重点注意的。项目说明测试需求分析项目主要教学生理解分析软件需求说明文档，整理获得测试需求，编 写测试需求文档，为制定测试计划做好准备。学生要求完成以下工作任务： 分析ATM 模拟系统软件需求说明书，整理系统的功能测试需求，编写测试需求文档。项目的 工作场景一般是企业的各个项目组或者独立的测试部门。项目目的主要是培养学生 准确获取测试需求的能力。该项目能为测试员、测试工程师、测试经理这些岗位的 相关工作提供帮助。软件测试与质量控制教程3概述 测试计划制定就是根据之前确认的测试需求，确定项目测试阶段的目标和策略，确 保测试工作有序、有效进行。测试计划的制定工作一般由测

25、试经理牵头执行，一般 测试人员只是协助工作。测试计划主要内容(1) 测试环境确保项目测试环境符合测试要求，减少严重影响测试结果的真实性和正确性风险。 包括：硬件环境：指测试必需的服务器、客户端、网络连接设备，以及打印机/扫描仪等辅助硬件设备所构成的环境；软件环境：指被测软件运行时的操作系统、数据库及其他应用软件构成的环境，包 括版本及补丁号。在实际测试中，可遵循下列原则：1) 符合软件运行的最低要求，首先要保证能支撑软件正常运行；2) 选用比较普及的操作系统和软件平台。3) 营造相对简单、独立的测试环境。4) 无毒的环境。利用有效的正版杀毒软件检测测试环境以确保其没有病毒。测试工具：指测试过程

26、使用的所有测试工具、测试管理工具等，包括工具名、版本、 生产厂商、用途。(2) 测试方案对测试阶段进行划分，说明各测试阶段的目标、工作内容、管理方法、采用的样式、 出口标准、停止标准、选取测试用例的原则等。(3) 测试需求列出每一项测试需求名称、内容、目的。(4) 测试优先级说明测试阶段或测试项的优先顺序和测试的重点内容。(5) 测试机构及人员测试机构名称、测试组成员和职责。进度说明各测试阶段活动的详细时间、人员、工作量安排，包括计划、管理、测试、 熟悉环境和工具、准备输入数据、校验输出结果等时间。测试阶测试活动计划开始时间计划开始时间测试人员预计工作量备注段(人天数)(7)问题响应要求问题分

27、类问题严重程度响应时间立即解决程序错误，影响继续测试高度关注问题严重普通排队一般问题低优先级建议性问题(8)测试风险预估序号风险内容描述优先级影像度(1)概率(P)缓解策略(9)测试风险管理说明风险管理的责任人，风险跟踪与管理的周期、方法等。(10)评价说明所选择的测试用例能检查的范围及局限性。说明用来判断测试工作是否能通过的评价尺度，如合理的输出结果的类型，量值范 围等。描述测试完成后应提交的文档。如：测试计划书、测试用例、测试问题报告、测试 分析报告等。项目说明制定测试计划项目主要教学生修改整理已有的测试计划草稿文档，对完成的测试计 划文档进行评审，形成基线，纳入软件配置管理。整个项目分成

28、两个模块完成，模 块一为编写测试计划书，模块二为测试计划评审。要求学生完成以下工作任务：按 要求修改补充已有的测试计划草稿文档内容，为测试计划评审准备评审文档，分角 色参与测试计划评审工作，将评审后的文档形成基线，纳入配置库管理。项目的工 作场景一般是企业的各个项目组或者独立的测试部门。项目目的主要是培养学生对测试过程的整体把握能力，让学生熟悉项目评审环节的各项工作。该项目能为测试 经理、测试员、测试工程师、 SQA和SCM这些岗位的相关工作提供帮助。软件测试与质量控制教程4概述在测试执行之前，测试人员需要设计一套详细的测试方案，测试方案的核心内容就 是测试用例，测试用例是测试执行的最小单位，

29、一般包括测试环境、测试步骤、测 试数据和预期结果几部分的内容。 测试用例设计是软件测试活动最重要的工作之一。根据测试阶段的不同，测试用例设计又分为单元测试用例设计、集成测试用例设计 以及系统测试用例设计等多项内容。本课程主要关注的是集成测试用例设计和系统 测试用例设计中的功能测试用例设计内容。其他测试用例设计内容会放在后续的软 件综合项目开发课程中学习。黑盒测试方法黑盒测试方法用来设计系统测试用例。常用的黑盒测试方法有等价类划分法、边界值分析法、因果图法、决策表法、正交 实验法、错误推测法等等价类划分法我们都知道，最理想的测试方法是穷举测试，即测试所有可能的情况。但是在实际 工作中由于数据量较

30、大或者数据域本身就是无穷的而无法进行穷举测试。这时候我 们一般考虑对输入数据的范围进行有限划分，从每个划分类别中选取一个有代表性 的测试数据进行测试，就等同于对这个划分类别的其他数据进行测试。等价类划分法是一种黑盒测试方法。等价类是指某个输入域的子集，在该子集中， 各个输入数据对于揭露软件中的错误都是等效的。等价类可以分为有效等价类和无 效等价类。其中有效等价类是符合需求规格说明书的合理输入数据集合，无效 等价类是不符合需求规格说明书的无意义的输入数据集合。划分步骤等价类划分可以按以下步骤进行：（1）先考虑输入数据的数据类型（合法类型和非法类型）；再考虑数据范围（合法类型中的有效区间和无效区间

31、）；(3) 用表格方法列举所有的等价类，为每一个等价类编号。划分方法常见的等价类划分方法有以下几种情况：(1) 在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。(2) 在输入条件规定了输入值的集合或者规定了"必须如何"的条件的情况下，可确立一个有效等价类和一个无效等价类。(3) 在输入条件是一个布尔量的情况下，可确定一个有效等价类和一 个无效等价类。(4) 在规定了输入数据的一组值(假定 n个)，并且程序要对每一个 输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。(5) 在规定了输入数据必须遵守的规则的情况下，可确立一个有

32、效等 价类(符合规则)和若干个无效等价类(从不同角度违反规则)。(6) 在确知已划分的等价类中各元素在程序处理中的方式不同的情 况下，则应再将该等价类进一步的划分为更小的等价类。等价类划分法测试用例设计原则用等价类划分法设计测试用例应该遵循以下原则：(1) 设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖地有效 等价类,重复这一步，直到所有的有效等价类都被覆盖为止；(2) 设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步，直到所有的无效等价类都被覆盖为止。实例分析设有一个档案管理系统，要求用户输入以年月表示的日期。假设日期限定在2013年1月2113年12月，并规定日期

33、由6位数字字符组成，前4位表示年，后2位表 示月。现用等价类划分法设计测试用例，来测试程序的"日期检查功能"。(1)划分等价类并编号，等价类划分的结果如表3.1所示。表3.1等价类列表输入条件有效等价类编号无效等价类编号日期的类型及长 度6位数字字符1有非数字字符2少于6位数 字字符3多于6位数字字符4年份范围在20132113之间5小于20136大于21137月份范围在0112之间8等于009大于1210(2)设计测试用例，以便覆盖所有的有效等价类在表中列出了3个有效等价类，编号分别为1、5、8,设计的测试用例如下：表3.2 有效等价类测试用例测试数据期望结果覆盖的有效等

34、价类201309输入有效1、5、8(3)为每一个无效等价类设计一个测试用例，设计结果如下:表3.3 无效等价类测试用例测试数据期望结果覆盖的无效等价类13June无效输入22013无效输入3无效输入4201212无效输入6211401无效输入7201500无效输入9201314无效输入10边界值分析法长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而 不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出 更多的错误。边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界 值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等

35、价类的边 界。确定边界使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类 的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边 界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。常见的边界值有以下几种情况：(1) 对16-bit的整数而言 32767禾口 -32768 是边界。(2) 屏幕上光标在最左上、最右下位置。(3) 报表的第一行和最后一行。(4) 数组元素的第一个和最后一个。(5) 循环的第 0次、第 1次和倒数第2次、最后一次。边界值分析法测试用例设计原则用边界值分析法设计测试用例应遵循以下原则：对于一个含有n个变量的程序，

36、应保留其中一个变量，其余的变量取正常值，被保留的变量取边界和边界附近的值， 对每个变量重复进行上述取值方法，设计测试用例。实例分析NextDate函数包含三个变量：mon th、day和year，函数的输出为输入日期后一天 的日期。例如，输入为2013年9月9日，贝V函数的输出为2013年9月10日。要求 输入变量 mon th、day和year均为整数值，并且满足下列条件：(1) 1 < mon th< 12(2) K day < 311920<year< 2050下面我们用边界值分析法来设计测试用例。在NextDate函数中，规定了变量 mouth和变量day

37、的取值范围为 K mouthw 12和 K dayw 31,并设定变量year的取值范 围为1920W year < 2050。这些就是边界条件。根据这些边界条件设计的测试用例如 表3.4所示。表3.4 NextDate函数边界值测试用例编号mouthdayyear预期输出Testi6151919year超出范围Test261519201920.6.16Test361519211921.6.16Test461519751975.6.16Test561520492049.6.16Test661520502050.6.16Test76152051year超出范围Test86-12001day

38、超出131Test96120012001.6.2Test106220012001.6.3Testll63020012001.7.1Test126312001输入日期超界Test136322001day超出131Test14-1152001Mouth 超出1 12Test1511520012001.1.16Test1621520012001.2.16Test17111520012001.11.16Test18121520012001.12.16Test1913152001Mouth 超出1 12因果图法因果图是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适 合于检查程序输入条

39、件的各种组合情况。为什么要用因果图我们前面介绍的等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考 虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可 能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。但是如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进 行测试用例的设计，这就需要利用因果图。（2）因果图使用上图的简单符号表示因果关系， 用圆圈表示节点，以 直线连接左右节点。左边节点点表示输入状态 （原因），右边节点表示输出状态（结 果）。（3）般

40、用Ci表示原因，ei表示结果，Ci和ei的取值都是0或者 1， 0表示某种状态不出现，1表示某种状态出现。因果图概念（1）关系：原因和结果之间存在如下关系（图3.1）。（a）表示恒等，若Ci=1，则ei=1，否则ei=0 ；（b）表示非，若 Ci=1，贝V ei=0，否则ei=1 ；（c）表示或，若C1或C2或C3是1,则ei是1,否则ei是0,或可以有任意个输入；（d）表示与，若C1且C2是1,则ei是1,否则ei是0,与可以有任意个输入。约束：输入状态（原因）之间或输出状态（结果）之间存在的某种依赖关系（图3.2）。E约束（异）：原因a和b中最多有一个可能为1,即a和b不能同时为1。I约束

41、（或）：原因a、b和c中至少有一个必须是1,即a、b和c不能同时为0。O约束（唯一）：原因a和b必须有一个，且仅有一个为1。R约束（要求）：原因a是1时，b必须是1，即不可能a是1时b是0。要求强制图3.2 约束关系实例分析假设有一个中国象棋的软件程序，我们需要测试棋子【马】的走法。下面我们采用 因果图来设计测试用例。(1)首先我们分析一下中国象棋中的走马规则：a) 如果落点在棋盘外，则不移动棋子；b) 如果落点与起点不构成日字型，则不移动棋子；c) 如果落点处有自己方棋子，则不移动棋子；d) 如果在落点方向的邻近交叉点有棋子(绊马腿)，则不移动 棋子；e) 如果不属于a-d条，且落点处无棋子

42、，则移动棋子；f) 如果不属于a-d条，且落点处为对方棋子(非老将)，则移 动棋子并除去对方棋子；g) 如果不属于a-d条，且落点处为对方老将，则移动棋子，并 提示战胜对方，游戏结束。根据分析情况，我们得到以下原因和结果，如表3.5所示表3.5中国象棋走马程序分析编号原因编号结果C1落点在棋盘上el不移动棋子C2落点与起点构成日字e2移动棋子C3洛点方向的邻近交叉点无棋子e3移动棋子，并除去对方棋子C4落点处为自己方棋子e4移动棋子，并提示战胜对方,结束游 戏C5落点处无棋子C6落点处为对方棋子(非老将)C7落点处为对方老将接下来我们画出中国象棋走马规则因果图图3.3 因果图，其中10表示中间

43、节点(3)然后根据因果图得到判断表(分成两个表)表3.6 决策表(1)序号12345678910111213141516原 因C10101010101010101C20011001100110011C30000111100001111C40000000011111111结果100000000100000000el1111111011111111表3.7 决策表序号123456789'0111213141516原 因100101010101010101C50011001100110011C60000111100001111C70000000011111111结果e20010000e300

44、00100e40000001注：1、第2表中部分列被合并表示不可能发生的现象；2、通过中间节点将用例的判定表简化为两个小表。减少工作量。（4）根据判定表写测试用例表表3.8 中国象棋走马测试用例编号输入条件操作步骤期望输岀Test1条件a-d不成立，移动马，落点是对方 老将1、点击自方马；2、点击对方老将。移动棋子并提示战胜 对方。Test2条件a-d不成立，移动马，落点是对方 棋子（非老将）1、点击自方马；2、点击对方棋子。移动棋子并除去对方 棋子。Test3条件a-d不成立，移动马，落点无棋子1、点击自方马；2、点击无棋子的落点。移动棋子。Test4绊马腿，落点为对方老将1、点击自方马；2

45、、点击对方老将。不移动棋子。Test5绊马腿，落点为对方棋子（非老将）1、点击自方马；2、点击对方棋子。不移动棋子。Test6绊马腿，落点无棋子1、点击自方马；2、点击无棋子落点。不移动棋子。错误推测法是指在测试程序时，人们可以根据经验或直觉推测程序中可能存在的各 种错误，从而有针对性地编写检查这些错误的测试用例的方法。错误推测方法的基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊 情况，根据他们选择测试用例。例如，在单元测试时曾列出的许多在模块中常见的 错误。以前产品测试中曾经发现的错误等，这些就是经验的总结。还有，输入数据 和输出数据为0的情况。输入表格为空格或输入表格只有一行。

46、这些都是容易发生 错误的情况。可选择这些情况下的例子作为测试用例。不同测试方法选择原则除了上述几种常用的黑盒测试方法外，还有一些黑盒测试方法，如决策表法、正交 试验法、流程分析法和状态迁移图法等，这里就不一一介绍了。通常，在确定测试方法时，应遵循以下原则：1. 根据程序的重要性和一旦发生故障将造成的损失来确定测试等级和测试重点。2. 认真选择测试策略，以便能尽可能少的使用测试用例，发现尽可能多的程序错误 因为一次完整的软件测试过后，如果程序中遗留的错误过多并且严重，则表明该次 测试是不足的，而测试不足则意味着让用户承担隐藏错误带来的危险，但测试过度 又会带来资源的浪费。因此测试需要找到一个平衡

47、点。3. 通常在确定测试策略时，有以下 5条参考原则：(1) 在任何情况下都必须采用边界值分析法。 这种方法设计出的测试用例发现程序错 误的能力最强。(2) 必要时采用等价类划分法补充测试用例。(3) 采用错误推断法再追加测试用例。(4) 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，则应当再补充更多的测试用例。(5) 如果程序的功能说明中含有输入条件的组合情况，则应一开始就选用因果图法。项目说明测试用例设计项目主要教学生运用黑盒测试方法对待测试项目进行功能测试用例设 计，编写测试用例文档，对测试用例进行评审，形成基线，纳入软件配置管理。整 个项目分为四个模块

48、完成，模块一为黑盒测试方法，模块二为功能测试用例设计， 模块三为编写测试用例文档，模块四为测试用例评审。学生要求完成以下工作任务： 运用黑盒测试方法设计 ATM模拟系统的功能测试用例，编写测试用例文档，为测试 用例评审准备评审文档，分角色参与测试用例评审工作，将评审后的文档形成基线， 纳入配置库管理。项目的工作场景一般是企业的各个项目组或者独立的测试部门。 该项目能为测试员、测试工程师、测试经理、SQA和SCM这些岗位的相关工作提供帮助。软件测试与质量控制教程5概述缺陷跟踪管理是软件测试工作的一个重要部分， 软件测试的目的是为了尽早发现 软件系统中的缺陷，因此，对缺陷进行跟踪管理，确保每个被发

49、现的缺陷都能够 及时得到处理是软件测试工作的一项重要内容。缺陷分类软件缺陷分类的原因在于给出 Bug的严重级别，判定修复的优先级。可以按照 Bug的严重级别分类。表4.1缺陷分类表级别说明1类Bug：致命错误(1) 需求说明书中的功能未实现；(2) 由于系统崩溃、死机、非法退出、死循环、 数据库异常、通讯异常、文件操作异常等原因造成功能不能 实现，并且不能通过其他方法实现。2类Bug：严重错(1)重要功能基本能实现，但系统不稳定、会误导致数据破坏丢失、(2)他方法可以实现。run-time error错误等；重要功能不能按正常操作实现，但通过其次要功能不能正常实现；(2)义、含义不一致)；操作

50、界面错误(包括数据窗口内列名定打印内容、格式错误；(4)简单的输入限制未放在前台进行控制；3类Bug： 般错误删除操作未给出提示；数据库表中有过多的空子段；因错误操作迫使程序中断；(8)系统找不到规律的时好时坏；(9)性等约束条件。数据库的表、业务规则、缺省值未加完整最好能改进的：(1)界面不规范；(2)辅助说明描述不清楚；4类Bug：细微错(3)输入输出不规范；误(4)长操作未给用户提示；(5)提示窗口文字未采用行业术语；(6)可输入区域和只读区域没有明显的区分标志。(1)可以作为下一个版本的改进；5类Bug：改进建 议(2)暂不作为修订内容。缺陷描述对缺陷的描述应该包含以下的内容:表4.2

51、 缺陷描述内容说明内容描述 项说明是否 必填可追踪信息缺陷ID唯一的缺陷ID，可以根据该ID追踪缺陷，一 般就是测试用例的编号是缺陷基本信息缺陷 状态缺陷的状态，分为“待分配”、“待修正”、“待验证”、“待评审”、“关闭”是缺陷 标题描述缺陷的标题是缺陷 严重 程度描述缺陷的严重程度，一般分为“致命”、“严 重”、“一般”、“建议”四种是缺陷 紧急 程度描述缺陷的紧急程度，从1-4, 1是优先级最 高的等级，4是优先级最低的等级是缺陷 提交 人缺陷提交人的名字（邮件地址）是缺陷 提交 时间缺陷提交的时间是缺陷 所属 项目/模块缺陷所属的项目和模块，最好能较精确的定位 至模块是缺陷 指定 解决

52、人缺陷指定的解决人，在缺陷“提交”状态为空， 在缺陷“分发”状态下由项目经理指定相关开 发人员修改是缺陷 指定 解决 时间项目经理指定的开发人员修改此缺陷的deadli ne是缺陷 处理 人最终处理缺陷的处理人是缺陷 处理 结果 描述对处理结果的描述，如果对代码进行了修改， 要求在此处体现出修改是缺陷 处理 时间缺陷处理的时间是缺陷 验证 人对被处理缺陷验证的验证人是缺陷 验证 结果 描述对验证结果的描述（通过、不通过）是缺陷 验证 时间对缺陷验证的时间是缺陷详细描述缺陷 详细 描述对缺陷的详细描述；之所以把这项单独列出 来，是因为对缺陷描述的详细程度直接影响开 发人员对缺陷的修改，描述应该尽可能详细。是测试环境说明测试 环境 说明对测试环境的描述是必要的附件必要 的附 件对于某些文字很难表达清楚的缺陷，使用图片 等附件是必要的否缺陷处理流程缺陷处理流程中的角色