引言
本篇整理了我学习
软件测试与方法时的一些笔记。
所用教科书：《软件测试方法和技术（第三版）》 – 朱少民 • 清华大学出版社
(一) 引论
1.为什么要开展软件测试活动
(1) 软件测试是保证软件质量的重要手段，所有软件都会存在或多或少的问题，错误需要测试来发现，同时还需要测试来评估错误密度。
(2) 软件测试是软件质量保证的关键步骤，越早发现错误代价越低。
2.什么是软件测试
软件测试是验证和有效性确认构成的整体。
3.软件测试和开发的关系
测试活动在开发之后，测试与开发同步进行，最后再进行总的测试，没有开发就没有测试，不同的软件开发模型中，测试所处位置不同。
4.软件测试与质量保证的关系
软件测试和软件质量是对立统一的，软件测试既是找bug的，又能保证软件质量。对软件进行充分的测试才能够有效的保证软件质量，对软件产品进行充分测试，找出其中的缺陷。
(二) 软件测试基本概念
1.软件质量的定义
(1) 软件产品满足规定的和隐含的与需求能力有关的全部特征与特性
(2) 软件各种属性的组合程度
(3) 用户对软件产品的综合反映程度
(4) 软件在使用过程中满足用户需求的程度
2.软件缺陷的定义
(1)从产品内部看，软件缺陷是软件产品开发和维护过程中所存在的错误、毛病等各种问题。
(2)从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背
2.1 什么是软件缺陷
(1) 软件未实现产品说明书要求的功能。
(2) 软件出现了产品说明书提到不应该的错误。
(3) 软件实现了产品说明书未提到的功能。
(4) 软件未实现产品说明书未提到但应实现的目标。
(5) 软件难以理解、不易使用、运行缓慢等问题。
2.2 修复.软件缺陷的代价
软件缺陷随着时间的推移所带来的成本越来越大。
3.软件测试的分类
单元测试 -> 集成测试 -> (功能测试) -> 系统测试 -> 验收测试
按测试层次：
(1) 底层测试：单元测试。
(2) 接口层次：集成测试，完成系统内单元之间接口和单元集成为一个完整系统的测试。
(3) 系统测试：负载测试、压力测试、强壮性测试。
(4) 用户层次：验收测试，验收用户是否真正所需要的产品特性，验收测试关注用户环境、用户数据，用户也需要参与测试。
按测试对象：
(1) 单元测试
(2) 程序测试
(3) 系统测试
(4) 文档测试
(5) Web应用测试、客户端测试
(6) 数据库测试、服务器测试
按测试目的：
(1) 功能测试：黑盒和白盒测试
(2) 性能测试
(3) 压力测试
(4) 可靠性测试
(5) 安全性测试
(6) 兼容性测试
(7) 回归测试
按测试阶段：
(1) 需求评审、设计评审
(2) 单元测试
(3) 集成测试
(4) 系统测试
(5) 验收测试：α测、β测
根据系统内部结构和具体实现算法角度分为黑盒测试和白盒测试两类；
根据测试对象在测试过程中是否发生状态变化分为动态测试和静态测试方法；
4.测试计划
(1) 规定测试活动的范围、方法、资源和进度；
(2) 明确正在测试的项目、要测试的特性、要执行的测试任务、每个任务的负责人以及与计划相关的风险。
5.测试用例
有效性、组织性、可复用性、跟踪、测试证实
(1) 测试用例是为了特定目的而设计的测试数据及其相关的测试规程的一个特定集合，或是有效发现软件缺陷的最小测试执行单元。
(2) 测试用例是测试工作的指导，是软件测试的必须遵守的准则，更是软件测试质量稳定的根本保障。
(3) 测试用例是测试执行的基础。
(三) 软件测试方法
1.基于直觉和经验的方法
错误推测法：
基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例。
2.基于输入域的方法(黑盒)
2.1 等价类划分法
等价类的分类：有效等价类、无效等价类。
有效等价类：是有意义的、合理的输入数据，可以检查程序是否实现了规格说明书中所规定的功能和性能。
无效等价类：不妈祖程序输入要求或无效的输入数据构成的集合。
PS：在规定了输入数据必须遵守的规则的情况下，可确定一个有效等价类和若干个无效等价类。
2.2 边界值分析法
边界值分析是一种补充等价类划分的测试用例设计技术。
设计方法：
(1) 确定边界情况(选择等价类边界)。
(2) 选取正好等于、刚刚大于或刚刚小于边界值作为测试数据。
3.基于逻辑覆盖的方法(白盒)
3.3.1 判定覆盖
使得程序中每个判定至少为True或False各一次。
3.3.2 条件覆盖
使得判定中的每个条件获得各种可能的结果。
3.3.3 判定-条件覆盖
同时满足判定覆盖和条件覆盖。即使得程序中每个判定至少为True或False各一次，同时使得判定中的每个条件获得各种可能的结果。
3.3.4 基本路径覆盖
设计所有的测试用例，覆盖程序中所有可能的、独立的执行路径。
V(G) = 区域数目
V(G) = 边界数目 - 节点数目 + 2
V(G) = 判断节点数 + 1
(四) 软件测试流程与规范
W模型
测试过程和开发过程贯穿了软件过程的整个生命周期，它们是相辅相成的关系，有以下的关键点：
(1) 测试过程和开发过程是同时开始，同时结束两者保持同步关系。
(2) 测试过程是对开发过程中的阶段性结果和产品进行验证的过程，两者相互依赖。
前期：测试过程依赖于开发过程。
后期：开发过程更多地依赖于测试过程。
(3) 测试过程和开发过程的工作重点可能不一样，两者有各自的特点，不论在资源和风险管理中，两者都存在差异。
敏捷测试
目标：尽快的交付高质量的软件。
核心(质量内建的三个关键实践)：测试左移、持续测试、测试驱动开发。
敏捷测试是一套解决方案、一类测试操作与管理的框架、一组实践或由一定顺序的测试活动构成的特定的测试流程。是不断修正质量指标、正确建立测试策略，确认客户的有效需求能得以圆满实现和确保整个生产的过程安全的、及时的发布最终产品。
TMM的五个等级
1.初始级
(1) 没有正式的文档化和结构化。
(2) 测试在编码后执行，与调试没有区别。
(3) 测试的目的被理解为证明软件正常工作。
2.定义级
(1) 组织已设定测试方针和目标。
(2) 引入了测试计划过程。
(3) 具有基本的测试技术和方法。
3.集成
(1) 测试过程和软件开发周期集成在一起。
(2) 标准、步骤和方法的文档化。
(3) 相应的监督和控制措施。
4.管理&度量
(1) 测试过程可有效地度量、管理。
5.优化
(1) 测试过程的数据可以用户防止错误。
(2) 注意力集中在优化已建立的过程的发生。
(五) 单元测试与集成测试
1.单元测试的原则
自动化、独立性、可重复
2.单元测试的任务
(1) 单元独立执行路径的测试：检查每一条独立执行路径的测试，保证每条语句至少被执行一次(基本路径测试)
(2) 单元局部数据结构的测试：检查局部数据结构完整性。
(3) 单元接口测试：检查模块接口是否正确。
(4) 单元边界条件的测试：检查临界数据处理的正确性。
(5) 单元容错性测试：预见、预设的各种出错处理是否正确有效。
(6) 内存分析
3.单元测试常用工具
单元测试工具：(xUnit工具家族)Junit、CppUnit、NUnit、HtmlUnit
静态检查工具：CheckStyle、PMD、FindBug
单元性能测试工具：SourceMonitor
4.静态测试
包括：需求评审、互查、走查、设计评审
定义：在不执行软件的条件下有条理地仔细审查软件设计、体系结构和代码，从而找出软件缺陷的过程。有时也称为结构分析。
作用：
(1) 尽早发现软件缺陷，以找出动态黑盒白盒测试难以揭示或发现的软件缺陷。
(2) 为接受该软件的黑盒测试员进行测试设计测试案例提供思路，他们不必了解代码细节，但是根据审查备注，可以确定有问题或者容易存在软件缺陷的特性范围。
问题：认为会减慢软件开发过程。
5.动态测试
5.1 驱动程序
驱动程序/驱动模块(Driver)：用以模拟被测模块的上级模块。
作用：接受测试数据，把相关的数据传送给被测模块，启动被测模块，并打印出相应的结果。
5.2 桩程序
桩程序/桩模块(Stub)：用以模拟被测模块工作过程中所调用的模块。
作用：由被测模块调用，一般只进行很少的数据处理。例如打印入口和返回，以便于检验被测模块与其下级模块的接口。
6.自顶向下和自底向上的集成方法
自顶向下法：类似树的层次遍历，依次结合各个模块。
自底向上法：从“原子”模块开始集成以进行测试。
(六)系统测试
1.性能测试
性能测试就是为了发现系统性能问题或获取系统性能相关指标(如运行速度、响应时间、资源使用率等)
1.1 性能测试指标
系统资源
CPU、内存占用率等。
系统行为
(1) 请求响应时间
客户端向服务器提交一个请求到收到响应之间的间隔时间。
(2) 事务响应时间
事务由一系列请求组成，事务的响应时间就是这些请求完成处理所花费的时间。
(3) 数据吞吐量
单位时间内客户端和服务器之间网络上传输的数据量。
1.2 系统负载及其模式
要素
并发用户并发数量 + 思考时间 + 每次请求发送的数据量 + 负载模式
(1) 在线用户：通过浏览器访问登录Web应用系统后没有退出该应用系统的用户。
(2) 并发用户：严格意义上，这些用户选择在同一时间做同一事情或同一操作；不严格地说，并发用户同时在线并操作系统，但可以是不相同操作。
(3) 用户并发数量：上述并发用户的数量，近似于同时在线的用户数量，但不等于在线用户数。
(4) 思考时间：浏览器在收到响应后到提交下一个请求之间的间隔时间。
负载模式：一次加载、递增加载、高低突变加载、随即加载等方式。
2.软件兼容性测试
是指验证软件之间是否正确地交互和共享信息。
要考虑的问题：
何种平台、何种应用软件、何种标准或规范、何种数据。
3.向前和向后兼容
向后兼容指的是可以使用软件的以前版本。
向前兼容指的是可以使用软件的未来版本。
(七)验收测试
1.进行验收测试的条件，通过标准
验收测试是在软件产品完成了功能测试和系统测试之后、产品发布之前所进行的软件测试活动。
标准：
(1) 完全执行了验收测试计划中的每个测试用例。
(2) 在验收测试中发现的错误已经得到修改并通过了测试或经过评估留到下一版本中修改。
(3) 完成验收测试报告。
2.如何进行产品说明书的验证
测试人员根据产品说明书，逐字逐句地验证产品每一项特征，并在验证结束时提交基于产品规格说明书地验证报告。
3.用户界面测试有哪些要素
(1) 符合标准和规范
(2) 直观性
(3) 一致性
(4) 灵活性
(5) 舒适性
(6) 正确性
(7) 实用性
(八)软件本地化测试
1.定义
1.1 G11N = I18N + L10N
软件全球化 = 软件国际化 + 软件本地化
1.2 软件国际化(Internationlization, I18N)
是在软件设计和文档开发过程中，使得功能和代码设计能处理多种语言和文化传统。创建不要语言版本时，不需要重新设计源程序代码的软件工程方法。
1.3 软件本地化(Localization, L10N)
是将一个软件产品按特定国家/地区或语言市场的需要进行全面定制的过程。
2. I18N与L10N的关系
(1) 国际化是本地化的基础和前提，为本地化做准备，使本地化过程不需要对代码进行改动就能完成。
(2) 本地化是国际化向特定本地语言环境的转换，本地化要适应国际化的规定。
(3) 国际化软件，或在应用软件运行时可以动态切换语言，或在软件启动前或启动时可以设置语言。
(九)测试自动化
1.手工测试和自动化测试的区别
(1) 自动运行的速度更快、执行效率高，是手工无法相比的。
(2) 手工测试会感觉累，但机器不会感觉累，可以不间断工作。
(3) 测试结果准确。
(4) 可靠。人可以撒谎，但机器不会。
(5) 可复用性。一旦完成所用脚本，可多次执行。
(6) 特别能力。当需要模拟大量并发的时候，人工测试显然是不现实的，但机器则可以模拟大量的并发量。
2.测试自动化实现中，关键的技术是什么？
识别用户界面的元素以及捕获键盘、鼠标的输入，将操作过程转换为测试工具可执行的脚本；然后，对脚本进行修改和优化，加入测试的验证点；最后通过测试工具运行测试脚本，将实际输出与期望结果进行比对，确定是否存在差异。
(十) 部署测试环境
1.测试环境的定义
1.1 设计环境
设计环境指编制测试计划、说明、报告及与测试有关的文件所基于的软、硬件设备和支持。
1.2 实施环境
实施环境指对软件系统进行各项测试所基于的软、硬件设备和支持。
1.3 管理环境
管理环境指管理测试资源所基于的软、硬件设备和支持。
2.要素
(1) 软件
操作系统、网络协议和应用程序。
(2) 硬件
网络设备、服务器、测试用机。
(3) 网络环境
相关网络设备、网络系统软件及配置。
(4) 数据准备
测试数据、要尽可能的取得大量真实数据。
(5) 测试工具
自动化及测试管理软件，监控诊断的使用工具等。
(十一)测试执行、缺陷报告与跟踪
1.软件缺陷的生命周期
发现 -> 打开 -> 修复 -> 关闭
“新打开的”：发现 -> 打开
“已修正的”：打开 -> 修复
“已关闭的”：修复 -> 关闭
生命周期的概念是一个物种从诞生到消亡经历了不同的生命阶段，软件缺陷生命周期指的是一个软件缺陷被发现、报告到这个缺陷被修复、验证直到最后关闭的完整过程。
2.软件缺陷的等级
2.1 严重性
分类：
(1) 致命：系统崩溃、数据丢失、数据毁坏、安全性被破坏。
(2) 严重：功能或特性没有实现，主要功能部分丧失，次要功能部分丧失或致命错误声明。
(3) 一般：系统的部分功能没有完全实现，但不影响用户的正常使用。例如：提示信息不太准确；用户界面差；操作时间长等一些问题。
(4) 较小：小问题，对功能几乎没有影响。
2.2 优先级
分类：
(1) 立即修复(P1)：缺陷导致系统几乎不能使用或测试不能继续，需立即修复。
(2) 高优先级(P2)：缺陷严重，影响测试，需优先考虑。
(3) 正常排队(P3)：缺陷正常排队等待修复。
(4) 低优先级(P4)：即使有此缺陷产品也能发布，可在开发人员有时间的时候纠正。
3.如何有效描述软件缺陷
基本原则：
(1) 单一准确：尽量一个报告只针对一个软件缺陷。
(2) 可再现：提供精确步骤，可再现并修复缺陷。
(3) 完整统一：完整前后统一的软件缺陷。
(4) 短小简练：只给出事实和演示软件缺陷必须的细节。
(5) 特点条件；通常情况下软件没有问题，而是在特点条件下出现，所以缺陷描述时不要忽视这些特定条件
(6) 对缺陷跟踪到底：从发现Bug开始，要保证它被正确的报告直至修复的全过程。
(7) 不要评价缺陷。
4.缺陷报告
组成：
一份优秀的缺陷报告记录不仅包括了期望结果、实际结果和必要的附件，还提供必要的数据、测试环境或条件，以及简单的分析。
