软件测试

写在最前面

1 课程目标

• 掌握基础的软件测试理论、测试方法和策略
• 掌握常用工具使用
• 根据需求和设计文档独立编写测试计划、测试方案、测试用例以及测试报告

2 主要内容

• 软件测试基础知识
• 软件测试通用技术
• 软件测试流程
• 黑盒测试
• 白盒测试
• 性能测试
• 软件测试自动化
• 软件测试管理

3 课程安排

学时安排：72课时（理论36+实践36）
教材：清华大学出版社 《软件测试》(第2版) 周元哲 编著

4 课程资源

• 课程内容文档 gitee 课程地址
• 课程思维导图
• 测试相关文档模板
• 测试工具：禅道

第1章 软件测试概论

1.1 软件

1.1.1 软件定义

软件是一系列按照特定顺序组织的计算机数据和指令的集合。
软件 ≠ 程序（代码）
软件包含如下内容：

1. 运行时，能够提供所要求功能和性能的指令或计算机程序。
2. 程序能够处理信息的数据结构。
3. 用于描述程序功能需求、程序如何操作和如何使用的文档。

1.1.2 文档

开发文档

开发文档是描述软件开发过程，包括软件需求、软件设计、软件测试、保证软件质量的一类文档，开发文档也包括软件的详细技术描述、程序逻辑、程序间相互关系、数据格式和存储等。

• 《可行性研究》
• 《项目任务书》
• 《需求规格说明书》
• 《概要设计》
• 《详细设计》
• 《代码规范说明书》
• 《数据字典》
• 《开发计划》

管理文档

从管理的角度规定涉及软件生存的信息：

1. 职责定义
2. 开发过程的每个阶段的进度和进度变更的记录
3. 软件变更情况的记录
4. 相对于开发的判定记录

• 《工作报告》
• 《工作日志》
• 《会议记录》
• 《里程碑报告》
• 《软件项目配置管理计划》
• 《实施方案》

产品文档

为使用和运行软件产品的任何人规定培训和参考信息，促进软件产品的市场流通或提高可接受性。使得那些未参加开发本软件的程序员维护它。

• 《产品手册》
• 《用户指南》
• 《培训手册》
• 《软件支持手册》

1.1.3 软件发展史

1. 程序设计阶段：个体化生产、专用软件、规模小、功能单一、开发者即使用者。（软件 = 程序）
2. 程序系统阶段：多用户人机交互，实时系统和数据库管理系统。
3. 软件工程阶段：以软件的产品化、系列化、工程化和标准化为特征的软件产业发展起来，软件开发有了可以遵循的软件工程化的设计准则、方法和标准。
4. 多层分布结构，面向服务架构

1.1.4 软件项目

软件项目是一种特殊的项目，具有如下特点：

1. 知识密集型，技术含量高
2. 涉及多个专业领域，多种技术综合应用
3. 项目范围和目标的灵活性
4. 风险大，收益大
5. 客户化程度高
6. 过程管理重要

1.2 软件生命周期

1.2.1 需求定义

描述： 定义出本次任务都需要做什么，做成什么样子。
参与者： 产品经理、需求分析师、客户

1.2.2 可行性分析

描述： 由项目组相关成员去研究需求是否可行，能不能做出来。
参与者： 产品经理、架构师、项目经理、开发

1.2.3 需求分析

描述： 需求分析其实是在做需求细化，按照任务说明书中的任务内容和指标具体细化各个点，细化到每个输入框、每个按钮的样式，输入输出等各项值。
参与者： 产品经理、架构师、项目经理、测试/质量管理员(很多公司把这个统称为QA)、开发
输出：《需求规格说明书》

1.2.4 评审

描述： 评审就是做审查，对这个阶段的工作进行审查，看是否偏离或者有遗漏（比如：设计和工厂的各个环节都有相关的审查，审查材料是否合格、设计是否符合规定、按照工人/设计出的材料需求是否足够或者多余等等，这些审查都是评审）；评审一般由相应工作人员来参与。
参与者： 每个阶段的评审一般都是各职能部门内部审核，也可以申请其他相关人员审核，比如需求评审，一般是产品经理、项目经理、测试、开发一起评审；系统设计一般是项目经理、开发评审；测试策略评审一般是测试组内部评审等等

1.2.5 设计

描述： 架构师根据需求确定产品或者项目的场景、特点，选择合适的框架，技术使项目实现最优化。在此基础上将系统进行概要设计，包括系统总体数据结构、数据库结构、模块结构以及它们之间的关系等。开发人员根据概要设计对具体模块进行详细设计，包括接口、参数等。此处设计会形成概要设计文档和详细设计文档。
参与者： 项目经理、架构师、开发、测试

1.2.6 编码

描述： 开发人员根据详细设计文档对系统进行模块化开发，在确定参数和接口的情况下，根据需求对模块内部进行方法级别的设计和编码以及自测，对产品功能进行一一实现。
参与者： 开发

1.2.7 提测

描述： 开发人员完成一个小迭代/小功能，且完成自测(开发编码完成后，一般都会自己检测下)，于是向测试部门发起提测，一般以邮件方式或者任务管理工具的任务流方式向测试部门通知xxx模块/功能可以测试。
参与者： 任务责任人（开发）、测试

1.2.8 测试

• 测试需求
• 测试计划
• 测试设计
• 测试执行
• 回归测试
• 测试评估

1.2.9 部署/发版

描述： 经过前面的各个阶段，产品已经可以出售或者面向大众了。配置管理人员进行封版、版本制作（针对产品来说）/部署上线（针对项目应用来说）。
参与人： 配置管理人员、测试 10. 支持维护
描述： 支持维护类似于我们日常中的售后，主要是对已卖出的产品/已上线的项目进行日常维护。包括纠错性维护和改进性维护两个方面。
参与人： 支持维护人员/售后工程师

1.3 软件测试概述

1.3.1 软件测试定义

软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。
IEEE:使用人工或自动手段来运行或测定某个软件系统的过程，其目的在于检测他是否满足规定的需求或弄清预期结果和实际结果的差别。

1.3.2 测试发展历程

1. 1957年之前－调试为主(Debugging Oriented)
   软件规模小，复杂度低，开发人员承担需求分析、设计、开发、测试等所有工作，等同于调试。
2. 1957–1978－证明为主(Demonstration Oriented)
   与调试区分开，这是软件测试史上一个重要的里程碑，主要目是确认软件是满足需求的。
3. 1979–1982－破坏为主(Destruction Oriented)
   1979年，《软件测试的艺术》 (The Art of Software Testing)第一版问世，这本书是测试界的经典之作。书中给出了软件测试的经典定义：

The process of executing a program with the intent of finding errors.
测试是为发现错误而执行程序的过程。

这个观点较之前证明为主的思路，是一个很大的进步。我们不仅要证明软件做了该做的事情，也要保证它没做不该做的事情，这会使测试更加全面，更容易发现问题。

4. 1983–1987－评估为主(Evaluation Oriented)
   软件行业进入了大发展时期，软件趋向大型化、复杂化，质量越来越重要。软件测试的基础理论和实用技术开始形成。提出了在软件生命周期中使用分析、评审、测试来评估产品的理论。
5. 1988–至今－预防为主(Prevention Oriented)
   尽量早的介入并发现这些明显的或隐藏的bug，发现得越早，修复起来的成本越低，产生的风险也越小。

1.3.3 测试与开发的关系

瀑布模型

这是一种经典模型,提供了软件开发的基本框架。
强调开发工作（计划、设计、开发、测试、维护等）各阶段之间的先后顺序，不可以并行操作。
瀑布模型认为，测试是指代码完成后，处于运行维护阶段之前。如果需求和设计上存在缺陷，就会造成大量返工，增加成本。为了更早的发现问题，测试应延伸到需求评审，设计审查活动中，软件生命周期的每个阶段都应包含测试。
优点:

1. 各阶段划分清晰
2. 强调计划与需求分析
3. 适合需求稳定的产品开发

缺点:

1. 单一流程，不可逆
2. 风险显露得晚，纠正机会少
3. 测试只是其中一个阶段，缺乏全过程测试思想

V模型

强调将测试和开发同等重要，对于开发阶段都有与之对应的测试阶段。
优点：
相对于瀑布模型，V模型测试能够尽早的进入到开发阶段。
缺点：
虽然测试尽早的进入到开发阶段，但是真正进行软件测试是在编码之后，这样忽视了测试对需求分析、系统设计的验证，时间效率上也大打折扣。

W模型(双V模型)

明确表示出了测试与开发的并行关系
优点：
W 模型相对于 V 模型来说，测试更早的进入到开发阶段，与开发阶段是并行关系，更早的发现问题，能够及时解决问题，各个阶段分工明确，方便管理。
缺点： W 模型是顺序性的、不可逆的，需求的变更和调整，依旧不方便。

螺旋模型

大型软件项目通常有很多不确定性和风险，如果采用瀑布式线性过程模型，失败风险很大，因此需要采取一种渐进式的演化过程模型。将产品分解成增量版本，每个版本单独测试。

敏捷模型

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。专注于交付对客户有价值的软件（可以工作的)。

强调以人为核心，程序员团队和业务专家之间的紧密联系，频繁交付新的软件版本，紧凑的自我组织型团队，更注重软件开发中人的作用。

在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

《联盟敏捷宣言》

1. 最重要的是通过尽早和不断交付有价值的软件满足客户需要。
2. 我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。
3. 经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。
4. 业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。
5. 围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。
6. 在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。
7. 可以工作的软件是进度的主要度量标准。
8. 敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。
9. 对卓越技术与良好设计的不断追求将有助于提高敏捷性。
10. 简单——尽可能减少工作量的艺术至关重要。
11. 最好的架构、需求和设计都源自自我组织的团队。
12. 每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。

解读：

• 个体和互动高于流程和工具
  以人为本，没有比面对面交流更高效的沟通渠道了，基于互相信任的前提，敏捷提倡自治的全功能团队。 在工作形式上，整个团队平时坐在一起工作，从物理空间上创造了更加便捷面对面的沟通机会。在团队职责上，团队内部具备完成软件交付的角色(能力)，团队所有人对软件的质量负责，开发过程由团队内部把控，业务价值团队内部快速流动，在任何环节都能及时获得反馈。同时，每个角色都更容易从全局视角去思考软件，避免了传统部门墙模式下的视角割裂和协作障碍。

• 工作的软件高于详尽的文档
  为客户交付可工作的软件是我们的核心目标，我们应该尽早交付可进行端到端测试的代码，该目标决定了我们不应该花过多精力在面面俱到的文档上，但这不代表我们要抵制任何文档。实践证明，轻量级的文档策略有助于团队高质量交付可工作的软件。

• 客户合作高于合同谈判
  主动拥抱变化，及时响应，持续交付。

• 响应变化高于遵循计划
  通过高效的协作，获取快速的反馈，从而尽早做出调整，减少浪费

缺点:
由于其项目周期很长，所以很难保证开发的人员不更换，而缺少文档就会造成在交接的过程中出现很大的困难。

1.4 软件缺陷

1.4.1 缺陷定义

IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。

符合下面4个条件之一就是缺陷：

1. 软件未达到规格说明书中规定的功能。
2. 软件出现了产品说明数中指明的不会出现的错误。
3. 软件功能超出了产品说明书中指明的范围。
4. 软件难于理解，不易使用，运行速度慢，或者最终用户认为软件使用效果不好。

1.4.2 产生原因

1. 软件本身复杂性，产生大量不确定因素。
2. 成本、时间限制，导致流程不够完善，文档缺失，缺乏严谨的评审。
3. 人员本身技能水平、责任心、交流沟通不顺畅。
4. 不全面或者没有复审。

1.4.3 缺陷来源

1.4.4 缺陷类型

1.4.5 缺陷级别

严重性： 表示软件缺陷的恶劣程度，当用户碰到该缺陷时影响的可能性和程度。
优先级： 表示修复缺陷的重要程度和紧迫程度。

严重性

优先级

严重性和优先级对于审查缺陷报告并决定哪些软件缺陷应该修复，以何种顺序修复的人员极为重要。如果一个程序员受命修复10个缺陷，他就应该先从严重性为1 、优先级为1这样的缺陷着手，而不是优先修复简单的，由简到难。

综合使用重要性等级和严重性双标准的优先顺序:

1.4.6 跟踪流程

最优化、最简单的生命周期是：（理想情况）

1. 测试员发现缺陷并记录缺陷报告。
2. 缺陷报告交给程序员，此时缺陷状态是打开。（open state）
3. 程序员修改缺陷，此时缺陷状态是解决。（resolved state）
4. 缺陷报告交还测试员。
5. 测试员确认已修复。
6. 测试员关闭缺陷报告，此时缺陷状态是关闭。（closed state）

一个缺陷很可能会被反复打开→关闭。在日常工作过程中，由于开发修订其他缺陷影响、需求变更等因素缺陷可能会被反复打开→关闭。

1.4.7 缺陷记录内容

1. bug编号：bug的唯一id，以方便尽快找到此bug。
2. bug标题：bug摘要，阐述bug大体内容。
3. bug严重级别，优先级：作为缺陷是否修复以及缺陷修复优先级的决定性因素。
4. bug产生的模块：记录bug所属模块，方便开发定位问题。
5. bug对应的版本：bug对应的软件版本，方便后续的统计归档以及开发定位问题。
6. bug描述：bug的产生环境、详细步骤、期望结果、实际结果。
7. 附件：包括但不仅限于截图、日志、录像、所用到的示例文件以及应用；同样是方便复现解决缺陷的。

以上是上报bug、创建bug必须的，在后续我们还会对bug进行修复、复测等工作，那在为了记录后续工作，bug还应该包含：

1. bug状态：开始、修复中、修复完成、提测、测试中、测试通过/失败、关闭等，后续bug周期中会讲到。
2. bug修订人：bug修订人员。
3. bug复测人：通常是谁报的bug最后返回给谁测试，但是在某些情况下比如bug报告人任务积累太多/不在的情况下也会分给其他人，所以通常会记录bug复测责任人。
4. bug修订说明：由bug修订人来写，说明bug产生原因，修改思路等。
5. bug复测说明：由复测人员来写，说明复测过程，复测结果等。
6. bug备注：备注，以便记录一些额外信息。

1.4.8 缺陷预防

差错：人在理解和解决问题的思维和行为过程中出现的问题，沟通不当，理解错误。（产生根源）
错误：软件内部问题，设计错误、编码错误。（内部原因）
失效：软件系统运行时偏离了用户需求。（外部表现）

1.5 软件测试行业

1.5.1 行业现状

软件系统越来越复杂，一个软件不能够由单独的软件工程师单独编写，而是由团队进行配合，每个人可能只负责一个模块，对于全局没有过多的了解，这时如果运行软件就会容易产生很多的错误。在行业内将这些错误叫做BUG。并且每一个软件工程师都会有思维的死角，自己不容易发现自己编写出来的错误。所以这个时候就需要专门的软件测试工程师用专业的测试方式来检查软件。检查该软件是否符合客户要求的产品设计，是否能够符合大多数用户的使用习惯，如果发现异常状态及时进行处理。软件市场虽然远远没有达到饱和但是各种各样功能的软件也层出不穷竞争激烈，对软件开发的质量要求也是日益增高。

我国软件测试行业起步较晚，发展较慢，直到21世纪初期，我国才逐步开始重视软件测试行业。但近年来，软件行业的快速发展为软件测试行业的发展提供了良好的基础，随着我国软件测试行业的发展，行业内企业向规模化发展将获得规模效应，可以有效降低企业的单位成本;而软件测试技术的不断发展，也将淘汰那些技术实力较弱的企业，促使行业内企业向专业化方向发展。

在软件业较发达的国家，软件测试产业已形成规模，比较发达，软件测试不仅早已成为软件开发的一个重要组成部分，而且在整个软件开发的系统工程中占据着相当大的比重。在微软公司内部，软件测试人员与软件开发人员的比例一般为1.5∶1到2.5∶1左右，即一个开发人员背后，有至少两位测试人员在工作，以保证软件产品的质量1。国外优秀的软件开发机构把40%的工作花在软件测试上，软件测试费用占软件开发总费用的30%至50%，对于一些要求高可靠性、高安全性的软件，测试费用甚至相当于整个软件项目开发所有费用的3至5倍。

从国内软件公司软件测试部门的独立性来看，多数软件企业没有专门的测试技术部门，软件测试程序也不太规范，多数企业也不懂测试，对测试的投入资金过少。大多数是在经过简单的测试之后，就认为是没有问题了，就交于用户了，让用户去“测试”。于是，软件产品在没有经过严格测试的情况下就发布了。对国内消费类软件而言，经常出现一些已经推向市场的产品由于被发现有严重缺陷而导致大量退货的现象。定制的行业软件，常出现一再返工、无限期的修改和维护的现象。

当前国内软件测试行业主要存在以下问题：

1. 软件规模越来越大，功能越来越复杂，如何进行充分而有效的测试成为难题。
2. 面向对象的开发技术越来越普及，但是面向对象的测试技术却刚刚起步。
3. 对于分布式系统整体性能还难以进行很好的测试。
4. 对于实时系统缺乏有效的测试手段。
5. 随着安全问题的日益突出，信息系统的安全性如何进行有效的测试与评估，成为世界性的难题。
6. 测试的自动化程度不高，手工测试过多，自动化测试工具和手工测试人员也缺乏较好的结合。
7. 缺乏软件测试意识、对其重视不够。
8. 在软件开发基本完成后才进行测试，也缺乏软件测试的统一标准。
9. 高校从师资储备到专业设置再到人才培养的机制薄弱。

国内外软件测试差距

1. 测试的理解认识
2. 测试过程的管理
3. 测试工具的使用
4. 测试人员的培养

1.5.2 未来趋势

1. 以软件为代表的计算机行业正在以一种井喷式的趋势发展
2. 人才缺口大
3. 女性员工受到青睐
4. 未来发展空间大
5. 外包为主

1.5.3 软件测试职业发展

1. 技术方向
   • 敏捷测试专家
   • 高级测试开发专家
   • 专项测试专家
   • QA-Ops 专家
2. 管理方向
   • 测试组长
   • 测试经理
   • 项目测试负责人
   • 测试总监
3. 易转型方向
   • 项目经理
   • 产品经理

1.5.4 测试思维方式

1. 逆向思维方式
2. 组合思维方式
3. 全局思维方式
4. 两级思维方式
5. 比较思维方式
6. 发散思维方式

1.6 测试认识的误区

1. 使用了测试工具，就进行了有效的测试
2. 存在太多无法测试的东西
3. 软件开发完成后才进行测试
4. 软件发布后发现质量问题，是测试人员的问题
5. 软件测试很简单，就是点点点，是个人就能做
6. 软件测试没有前途，只有程序员才是软件高手
7. 软件测试是测试人员的事情和程序员无关
8. 项目进度吃紧时少做测试，时间多时多做测试
9. 测试要进行穷尽测试
10. 采样是随机抽取过程
11. 测试和开发是对头
12. 测试少报bug开发就会高兴点，报告也会好看点
13. 自动化测试终会取代手工测试
14. 规范化软件测试是增加项目成本
15. 越多测试越有效
16. 软件测试工作只负责项目上线/产品发布之前的部分

1.7 知识点总结

第2章 软件测试基础知识

2.1 概述

1. 从软件测试的目的来理解
   软件的目的是发现软件中的错误，是为了证明软件有错，而不是无错。是在软件投入运行前，对软件需求分析、设计和编码各个阶段产品的最终检查，是为了保证软件开发产品的正确性、完整性和一致性。
2. 从软件测试的性质来理解 在软件开发过程中，分析、设计和编码都是“建设性的”，唯有测试是“破坏性的”。
3. 从软件开发角度来理解 软件测试以检查产品的内容和功能特性为核心，是软件质量保证的关键步骤，也是成功实现软件开发目标的重要保障。
4. 从软件工程角度来理解
   软件测试是软件工程的一部分，是软件工程过程中的重要阶段。
5. 从软件质量保证角度来理解
   软件测试是软件质量保证的重要措施。

2.2 测试的目的和原则

2.2.1 测试的目的

1. 测试不仅仅是找出错误。通过分析错误产生的原因和错误的发展趋势，可以帮助项目管理者发现当前软件开发过程中的缺陷，以便即时改进。
2. 检测产品是否符合用户要求。
3. 没有发现错误的测试也是有价值的，完整的测试是评定软件质量的一种方法。
4. 提升用户体验。

2.2.2 测试的原则

1. 软件测试是证伪而非证实。
2. 尽早地、不断地进行测试。
3. 重视无效数据和非预期的测试。
4. 应当对每一个测试结果做全面的检查。
5. 测试现场保护和资料归档。
6. 程序员应避免检查自己的程序。
7. 充分注意测试中的集群现象。
8. 用例要定期评审，适时补充修改用例。

2.3 测试分类

2.3.1 按照测试阶段划分

1. 单元测试
2. 集成测试
3. 确认测试
4. 系统测试
5. 验收测试

软件测试阶段对照表:

2.3.2 按照执行状态划分

1. 静态测试
2. 动态测试

2.3.3 按照测试技术划分

1. 白盒测试
2. 黑盒测试
3. 灰盒测试

2.3.4 按照执行主体划分

1. α测试
2. β测试
3. 第三方测试

2.3.5 按照测试内容划分

1. 界面测试
2. 功能测试
3. 安全测试
4. 兼容性测试
5. 易用性测试
6. 性能测试

2.3.6 按照是否手工操作划分

1. 手工测试
2. 自动化测试

2.4 测试用例

2.4.1 简介

测试用例是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。其内容包括：测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，最终形成文档。

简单的认为，测试用例是为某个特定目标而编制的一组测试输入、执行条件和预期结果，用于核实是否满足某个特定的软件需求。

选择测试用例是软件测试员最重要的一项任务，不正确的选择可能导致测试量过大或者过小，甚至测试目标不对。准确评估风险，把无穷尽的可能性减少到可以控制的范围是软件测试成功的诀窍。

2.4.2 测试用例的作用

1. 指导测试的实施
2. 评估测试结果的度量基准
3. 保证软件的可维护性和可复用性
4. 分析缺陷的标准

2.4.3 测试用例设计准则

1. 有效性
2. 经济性
3. 完备性
4. 可判定性
5. 可再现性

2.4.4 测试用例维护

术语

1. 测试编号：测试用例的编号
2. 测试项：测试的功能点说明
3. 前置条件：该测试用例的前提条件，比如测试wangdachui／dachui12345（用户名／密码）账户是否能正确登录进去，那前提wangdachui／dachui12345已定是注册过的
4. 测试步骤：就是测试的所有操作步骤，最好是每一个步骤应该对应一个期望结果，最少也得一个测试用例对应一个期望结果
5. 期望结果：就是希望得到的结果（正确的结果）
6. 测试结果：实际测试的结果，可选项有：通过、不通过、暂时挂起／锁定（就是暂时不测试）；
7. 对应的bug：当期望结果与实际结果不符时测试不通过，此时需要上报bug（纪录缺陷），bug需要与测试用例对应
8. 测试执行人：实际由谁来执行测试用例；也有任务分配人的选项，就是测试用例分配给哪个测试员来测试
9. 备注：做一些备注或者测试的说明
10. 合法用户：就是已经注册过的用户
11. 非法用户：没有注册过；注册过但是用户名／密码不匹配的；本文特指未注册过的用户

测试用例维护一般分为以下几种情况：

1. 产品特性没变：漏测或者环境变更，这个时候版本没变，测试用例增加和修改均可
2. 原有特性变化：功能变化，只能新增，不能修改，还要兼容老版本
3. 原有功能取消：测试用例在新版本上置为“空”标志或者“无效状态”，对于先前版本有效
4. 新增功能：新增用例，对应新版本标志

2.4.5 测试用例设计误区

1. 测试用例设计等同于测试输入数据设计
2. 测试用例设计越详细越好
3. 追求测试用例设计“一步到位”
4. 将多个测试条件混在一个用例中

2.5 测试停止标准

2.5.1 软件测试停止总体标准

1. 测试超过了预定时间
2. 执行了所有的测试用例，并没有发现故障
3. 使用特定的测试用例设计方法作为判断测试停止的基础
4. 给出测试停止的要求
5. 根据经单位时间内查出故障的数量决定是否停止测试
6. 软件系统经过了单元、集成、系统测试，分别达到停止标准。通过验收测试，得出验收测试结论。
7. 软件项目暂停以进行调整，测试应随之暂停，并备份暂停点数据。或者软件项目开发生命周期内出现重大估算、进度偏差，需暂停或终止时，测试应随之暂停或终止，并备份数据

2.5.2 软件测试各阶段停止标准

单元测试停止标准

1. 单元测试用例已经通过评审
2. 按照单元测试计划完成了所有规定单元测试
3. 达到了测试计划中关于单元测试所规定的覆盖率要求
4. 被测试的单元每千行代码必须发现至少3个错误
5. 软件单元功能与设计一致
6. 单元测试中发现的错误已经得到修改，各级缺陷修复率达到标准

集成测试停止标准

1. 集成测试用例已经通过评审
2. 按照集成测试计划和增量集成策略完成了整个系统的集成测试
3. 达到了测试计划中关于集成测试所规定的覆盖率要求
4. 被测试的集成工作版本每千行代码必须发现至少2个错误
5. 集成工作版本满足设计定义的各项功能、性能要求
6. 在集成测试中发现的错误已经得到修改，各级缺陷修复率达到标准

系统测试停止标准

1. 系统测试用例已经通过评审
2. 按照系统测试计划完成了系统测试
3. 达到了测试计划中关于系统测试所规定的覆盖率要求
4. 被测试的系统每千行代码必须发现至少1个错误
5. 系统测试满足设计需求规格说明书要求
6. 在系统测试中发现的错误已经得到修改，各级缺陷修复率达到标准

2.6 知识点总结

第3章 黑盒测试

3.1 概述

黑盒测试也称功能测试，通过测试来检测每个功能是否都能正常使用。

着眼于程序外部结构，不考虑内部逻辑结构，通过测试检验每个功能是否能正常使用。在程序接口进行测试，只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当的接受输入数据而产生正确的输出信息。

黑盒测试从用户的角度出发，以输入数据与输出数据的对应关系进行测试，数据驱动。

黑盒测试注重测试软件的功能需求，主要视图发现下列几类错误

1. 功能不正确或遗漏
2. 界面错误
3. 数据库访问错误
4. 性能错误
5. 初始化和终值错误

3.2 等价类划分

等价类是指某个输入域的子集合。在该子集合中，测试某等价类的代表值就等于对这类其他值的测试，对于揭露程序的错误是等效的。

要注意的是，在进行等价类划分的过程中，我们不仅要考虑有效等价类划分，也要考虑无效等价类划分。

有效等价类：是指输入完全符合程序规格说明的数据集合。利用有效等价类可以测试程序是否满足规格说明书规定的功能和性能。

无效等价类：和有效等价类相反，是指对程序的规格说明无意义、不合理的输入数据构成的集合。

3.2.1 划分原则

1. 在输入条件规定了取值范围的情况下，可以确立一个有效等价类（在取值范围之内）和两个无效等价类（小于取值范围和大于取值范围）。
2. 在输入条件规定了取回个数的情况下，可以确立一个有效等价类（在取值个数范围之内）和两个无效等价类（小于取值个数和大于取值个数）。
3. 在输入条件规定了输入值的集合的情况下，可以确立一个有效等价类和一个无效等价类。
4. 在输入条件规定了“必须如何”条件的情况下，可以确立一个有效等价类和一个无效等价类。
5. 在输入条件是一个布尔值的情况下，可以确立一个有效等价类和一个无效等价类。
6. 在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的将情况下，可以确立n个有效等价类和一个无效等价类。
7. 在规定了输入数据必须遵守规则的情况下，可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
8. 在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将改等价类进一步划分为更小的等价类。

3.2.2 设计测试用例步骤

1. 形成等价类表，每一等价类规定一个唯一编号
2. 设计测试用例，使其尽可能多的覆盖尚未覆盖的有效等价类
3. 设计一个新的测试用例，使其只覆盖一个无效等价类，重复这一步直到所有无效等价类均被覆盖。

3.2.3 等价类举例

我们要测试学习成绩这一输入框（假设总成绩都是100），那么我们就可以如下图划分，有效的成绩是>=0且<=100的，无效的是<0和>100这两部分。

另外图中还有一个无效等价类没有表现出来--非数字字符（比如：英文字母、中文、特殊的符号等单一或者组合，如a、abc、你好、你abc、你=我、\你\a\等;以及他们分别与数字组合,比如：a123、321a、你123、12你、1你2、1\2、1=你等）。

那么根据上述分析，最终设计出来的测试用例如下：

1. 有效等价类1：0~100（包含0和100）之间的任意数，比如：19；
2. 无效等价类1：小于0的负数，比如：-1；
3. 无效等价类2：大于100的数，比如：121；
4. 无效等价类3：其他任意非数字字符，比如：a、你、\；
5. 无效等价类4：空字符

等价类最终必须是分割到最小单位，只有这样才能保障测试覆盖全面。
非数字字符可以是包含英文字符、中文、特殊符号的字符串或者字符，所以其实它又可以分为三个无效等价类，分别是：

1. 无效等价类：包含英文字符的字符串，比如：a、a123、a=、b你a；
2. 无效等价类：包含中文的字符串，比如：你、你12、1你2、你=；
3. 无效等价类：包含特殊字符的字符串，比如：\ 。

3.3 边界值分析

边界值分析法是等价类划分法的补充。顾名思义，边界值分析法是对输入的边界值进行测试。从实践中我们可以发现，人们无论是在生活中还是在工作中往往会忽略边界值的条件，所以在输入或者输出的边界上会发生大量的错误。因此，在测试用例设计中，需要对输入的条件进行分析并且提取其中的边界值条件，通过对这些边界值的测试来查出更多的错误。

常见的边界值：

1. 文本框接受字符个数，比如用户名长度、密码长度等。
2. 报表的第1行和最后1行。
3. 数组元素的第1个和最后1个。
4. 循环的第1次、第2次和倒数第1次、最后1次。

3.3.1 设计原则

1. 如果输入条件规定了值的范围，则应取刚达到这个范围边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。
2. 如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少1、比最大个数多1的数作为测试数据。
3. 如果规格说明书给出的输入域或输出域是有序集合，则应选取集合的第1个元素和最后1个元素作为测试用例。
4. 如果程序中使用了内部数据结构，则应选择内部数据结构边界上的值作为测试用例。
5. 分析规格说明，找出其他可能的边界条件。

3.3.2 两类方法

1. 一般边界值分析 对于含有n个变量的程序，取值为min、min+、normal，max-、max，测试用例数目为4*N+1。

2. 健壮性边界值分析 健壮性边界值测试是边界值分析的一种扩展。变量除了取min、min+、normal、max-、max 5个边界值外，还要考虑略超过最大值(max+)以及略小于最小值(min-)的取值。因此，对于含有n个变量的程序，健壮性边界值分析产生6*n+1个测试用例。

3.3.3 应用举例

延伸上节的例子来说明：学生信息系统中有一个“考试成绩”的输入项，成绩的取值范围是0~100之间的整数，考试成绩及格的分数线是60，优秀的分数线是80。那么这个例子中的边界值数据是哪些呢：

选取的边界值数据应该包括：

-1，0，1，59，60，61，79，80，81，99，100，101

通常情况下，软件测试所包含的边界检验有以下几种类型：数字、字符、位置、质量、大小、速度、方位、尺寸、空间等，而相应地，这些类型的边界值应该在最大/最小，首位/末尾，上/下，最快/最慢，最高/最低，最短/最长，空/满等情况下。

3.3.4 局限性

如果被测程序是多个独立变量的函数，这些变量受物理量的限制，则较适合采用边界值分析。这里的关键是 “独立”的“物理量” 。例如，Date是3个变量(年、月、日)的函数，对其采用边界分析测试用例，就会发现测试用例是不充分的，例如，没强调2月和闰年。其存在问题是因为没有考虑月份、日期和年变量之间存在的依赖关系。由于边界值分析假设变量是完全独立的，因此边界值分析测试用例是对物理量的边界独立导出变量极值，不考虑函数的性质，也不考虑变量的语义含义。 边界值分析对布尔变量和逻辑变量没有多大意义。例如，布尔变量的极值是true和false，但是其余3个值不明确。

3.4 决策表

等价类划分法和边界值分析法只是孤立地考虑各个输人数据的测试效果，没有考虑输入数据的组合及其相互制约关系，而决策表考虑了多种条件的组合情况。决策表又称为判定表，分析多种逻辑条件(if-else、switch-case等)与执行动之间的关系。

决策表由4部分组成：

1. 条件桩：列出了问题的所有条件，通常认为列出的条件次序无关紧要。
2. 动作桩：列出了问题规定可能采取的操作，这些操作的排列顺序没有约束。
3. 条件项：列出针对条件桩的取值，在所有可能情况下的真假值。
4. 动作项：列出在条件项的各种取值情况下应该采取的动作。

规则：任何条件组合的特定取值及其相应要执行的操作。在决策表中贯穿条件项和动作项的列就是规则。显然，决策表中列出多少条件取值，也就有多少规则，条件项和动作项就有多少列。

所有条件都是逻辑结果(即真/假、是/否、0/1)的决策表称为有限条件决策表。如果条件有多个值，则对应的决策表叫做扩展条目决策表。决策表设计测试用例，条件解释为输入，动作解释为输出。

决策表适合以下特征的应用程序:

1. if-then-else分支逻辑突出。
2. 输入变量之间存在逻辑关系。
3. 涉及输入变量子集的计算。
4. 输入和输出之间存在因果关系。
5. 很高的圈复杂度。

3.4.1 应用举例

决策表(判定表)设计测试用例的具体步骤如下:

1. 确定规则的个数。假如有n个条件，每个条件有两个取值(0，1)，故有2种规则。
2. 列出所有的条件桩和动作桩。
3. 填入条件项。
4. 填入动作项，得到初始判定表。
5. 简化，合并相似规则（相同动作）。 简化就是合并多条具有相同的动作的规则，并且其条件项之间存在极为相似的关系。

需求：输入三边值，判定是哪种三角形：非三角形、不等边三角形、等腰三角形、等边三角形

1. 绘制初始三角形判定决策表
2. 优化1的产出
3. 设计测试用例

条件桩：

• abc能构成三角形
  • a+b>c
  • a+c>b
  • b+c>a
• a=b？
• a=c?
• b=c?

动作桩：

• 非三角形
• 不等边三角形
• 等腰三角形
• 等边三角形

决策表：

测试用例：

3.4.2 优点和缺点

决策表把复杂问题的各种可能情况一一列出，易于理解。但是，决策表不能表达重复执行动作的缺点。

使用判定表设计测试用例的条件如下：

1. 规格说明以判定表形式给出，或很容易转换成判定表。
2. 条件的排列顺序不会也不影响执行哪些操作。
3. 规则的排列顺序不会也不影响执行哪些操作。
4. 每当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。
5. 如果某一规则得到满足要执行多个操作，这些操作的执行顺序无关紧要。

这5个必要条件使得操作的执行完全依赖于条件的组合。对于不满足条件的判定表，可增加其他的测试用例。

3.5 因果图

前面我们介绍的等价类划分法和边界值分析法都没有考虑到输入情况的组合。这样虽然各种输入条件可能出错的情况已经看到了，但是多个输入情况组合起来可能出错的情况却被忽视了

地铁自动充值机充值

假设自动充值机每次只能投入面值50或者面值100的人民币，投入钱后会有充值50和充值100两个选项

等价类划分法和边界值分析法可能不会测试到投入面值50的人民币，然后点击充值100这种异常情况；因此，当程序的输入条件有多个的话，就需要用到因果图法来设计测试用例了。

因果图利用图解法分析输入的各种组合情况，适合描述多种输入条件的组合、相应产生多不动作的方法。因果图法最终生成的是判定表。

3.5.1 基本术语

1. 原因结果图： 原因——结果图使用了简单的逻辑符号，以直线连接左右结点，左结点表示输入状态(原因)，右结点表示输出状态(结果)。

• “恒等”：若原因出现，则结果出现；若原因不出现，则结果不出现。
• “非”：若原因出现，则结果不出现；若原因不出现，则结果出现。
• “或”：若几个原因中有一个出现，则结果出现；若几个原因都不出现，则结果不出现。
• “与”：若几个原因都出现，结果才出现；若其中有一个原因不出现，则结果不出现。

2. 约束图： 输入输出状态相互之间存在的某些依赖关系，称为约束。

• E(互斥)：原因不会同时成立，最多1个成立,可以都不成立
• I(包含)：原因中至少一个成立,不能同时为0
• O(唯一)：原因中有且只有一个成立
• R(要求)：原因中a出现，b必须出现,a=1则b=1,a=0的话，b随便。QQ登录的例子a为自动登录，b是记住密码
• M(屏蔽)：a为1时，b必须是0,a=1,则b=0，如果a=0，b随便

3.5.2 设计因果图测试用例步骤

1. 分析软件规格说明，哪些是原因(即输入条件或输入条件的等价类)，哪些是结果(即输出条件)，给每个原因和结果赋予标识符。
2. 分析原因与结果之间、原因与原因之间对应的逻辑关系，用因果图表示。
3. 由于语法或环境限制，有些原因与原因之间、原因与结果之间的组合情况不可能出现，在因果图上用一些记号表明这些特殊情况的约束或限制条件，把因果图转换为判定表。
4. 从判定表的每一列产生出测试用例。

对于逻辑结构复杂软件，先用因果图进行图形分析，再用判定表进行统计，最后设计测试用例。当然，对于比较简单的测试对象，可以忽略因果图，直接使用决策表。

3.5.3 应用举例

需求：第一列字符必须是A或者B，第二列为数字，才允许进行文件修改。如果第一列字符不正确，输出提示L，第二列不是数字，输出提示M,采用因果图设计测试用例

原因：

1. 第一列是A
2. 第一列是B
3. 第二列是数字

结果：

1. 修改文件
2. 输出提示L
3. 输出提示M

因果图：

决策表：

测试用例：

3.5.4 优点和缺点

优点:

1. 考虑多个输入之间的相互组合、相互制约的关系
2. 指出需求规格说明书中存在的不完整性和二义性
3. 帮助测试人员按照一定的步骤高效的开发测试用例

缺点:

1. 作为输入条件的原因和输出结果之间的因果关系，很难从规格说明书得到
2. 此方法得到的用例数量规模大

3.6 场景法

通过尝尽该描述的业务流程（业务逻辑）,设计用例来遍历场景（路径）,验证系统功能的正确性。 场景法重点是测试流程，因此每个流程用一个用例验证即可，流程测试没问题不代表系统功能没问题，还需要单步进行测试，结合前面的方法。

流程图：

• 矩形：步骤
• 菱形：判断条件
• 箭头：流向

3.6.1 ATM取款流程图

3.6.2 ATM取款场景设计

3.6.3 测试用例

3.7 错误推测法

3.7.1 概念

错误推测法是利用经验和直觉推测出出错的可能类型，列举出程序中所有可能的错误和容易发生错误情况的清单，根据清单设计测试用例。所谓凭经验，是指人们对过去所作测试结果的分析，对所揭示缺陷的规律性直觉的推测来发现缺陷。

该方法强调的是对被测试软件的需求理解以及设计实现的细节把握，当然还有个人的能力。那么显而易见地，这个方法的缺点就是太过依赖个人能力，难以系统化。因此，这个方法一般是作为测试用例设计的补充，而不是单独用来设计测试用例。在回归测试中应用较多。

错误推测法一般采用如下技术:

1. 有关软件设计方法和实现技术。
2. 有关前期测试阶段结果的知识。
3. 测试类似或相关系统的经验，了解以前这些系统曾在哪些地方出现缺陷。
4. 典型的产生错误的知识，如被零除错误。

3.7.2 优点和缺点

优点：

1. 不用设计等价类的测试用例，将多个等价类的测试合成一个随机测试，可以以较少代码实现测试代码的编写。
2. 当等价类设计不确切或不完全时，测试会产生遗漏，而使用错误推测法则是按照概率进行等价类覆盖。不论存在多少个等价类，只要随机数据个数足够，就能保证各个等价类被覆盖的概率足够高，能够有效弥补等价类分法设计不充分的缺陷。
3. 采用错误推测法进行测试，每次执行测试时，测试的样本数据可能都不相同，执行次数愈多，错误暴露的概率愈大。

缺点：

1. 错误推测法中的随机数据很难覆盖到边界值，无法保证测试的充分性。
2. 错误推测法进行自动化测试的难度较大。有些程序很难用程序来自动验证，这使得程序结果的验证工作难度变大。
3. 当等价类的范围较小，这些范围较小的等价类被覆盖的概率也是很小的，错误推测法难以测试到。
4. 随机测试不可以代替常规的功能或非功能测试，因为其随意性大，没有一套完整严格的方法且并非有章可循的测试技术。

3.7.3 常见错误

1. 页面规范相关部分（跟公司甚至项目需求有关系）

• 命名、注释、字体、颜色、缩进等
• 文本框长度/范围限制
• 支持的浏览器、操作系统、jdk等做兼容性测试

2. 常识性问题

• 密码用密文
• 手机号码是11位，且是特定三位数开头
• 文本框自动忽略前后空格
• 支持模糊查询

3. 常见的异常测试情况

• 输入框不输入任何内容（为空）或者输入空格的情况
• 输入框输入非法字符
• 用户注销后，是否仍然能操作；再登录是否能成功
• 断电重连后是否能继续使用且信息未丢失

4. 功能相关的常见异常问题

• C++软件的内存泄漏、内存分配
• web程序的session失效问题
• JavaScript字符转义

3.8 综合策略

黑盒测试方法有等价类划分、边界值分析、决策表、因果图、场景法、错误推测法等，每种测试方法都有其各自的特点和适用场合。
软件测试专家Myers给出了黑盒测试方法中各种测试方法的使用策略:

1. 在任何情况下都必须使用边界值分析方法。经验表明，用这种方法设计的测试用例发现程序错误的能力最强。
2. 必要时使用等价类划分方法补充一些测试用例。
3. 用错误推测法再追加一些测试用例。
4. 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例。
5. 如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法。

对于功能性测试技术，可以根据如下条件进行选择:

1. 如果变量是独立的，则可以用定义域测试和等价类测试。
2. 如果变量不是独立的，可采用决策表测试。
3. 如果为单缺陷假设，则可采用边界值分析和健壮性测试。
4. 如果为多缺陷假设，可采用最坏情况测试、健壮最坏情况测试和决策表测试。
5. 如果程序包含大量例外处理，可采用健壮性测试和决策表测试。
6. 如果变量引用的是逻辑量，可采用等价类测试用例和决策表测试。

第4章 白盒测试

4.1 概述

4.2 静态测试

4.3 逻辑覆盖

4.4 路径分析

4.5 控制结构测试

4.6 数据流测试

4.7 程序插桩

4.8 测试方法综述

4.9 知识点总结

第5章 性能测试

5.1 基本概念

5.2 性能测试分类

5.2.1 负载测试

5.2.2 压力测试

5.2.3 可靠性测试

5.2.4 数据库测试

5.2.5 安全性测试

5.2.6 兼容性测试

5.2.7 可用性测试

5.3 性能测试步骤

5.4 Web测试

5.5知识点总结

第6章 软件测试流程

6.1 软件测试流程概述

6.2 测试需求

6.3 测试计划

6.4 测试设计

6.5 测试执行

6.5.1 单元测试

6.5.2 集成测试

6.5.3 系统测试

6.5.4 验收测试

6.5.5 α测试

6.5.6 β测试

6.6 回归测试

6.7 测试评估

6.8 知识点总结

第7章 软件测试自动化

7.1 自动化测试和手工测试

7.2 测试成熟度模型

7.3 自动化测试体系

7.4 测试工具介绍

7.5 知识点总结

第8章 软件测试管理

8.1 软件测试管理概述

8.2 测试过程改进

8.3 人力资源

8.4 知识点总结