鸟瞰软件测试技术（笔记）

软件测试发展历程：

软件测试，专门的软件测试，第一次定义，成为专门的学科，与开发的融合

软件测试的定义

（1983年电子电气工程师协会）：

软件测试是一门需要经过设计、开发和维护等完整阶段的软件工程

使用人工或自动的手段运行或测试软件的过程，目的是检验软件系统是否满足规定的要求，并找出与预期结果之间的差异

软件测试的组织形式：

按测试人员参与的程度：专职和兼职

按测试人员参与项目的形式：项目型（项目组成员）和职能型（部门委派）

软件开发模式的发展：

常见的软件开发模型：

1.线性模型也叫瀑布模型：需求完全确定，集成风险（缺陷发现晚，大面积返工）

2.渐进式模型：螺旋模型是其中代表，在瀑布的每阶段前引入需求分析和风险管理，测试跟随开发迭代而迭代

增量开发：分块；迭代开发：反复求精；现在的迭代开发是指增量+迭代

3.变换模型：省略编码和测试，代之以自动化的程序变换过程，集中精力于前面的需求分析和建模

两个软件测试标准：

cmmi：

全称：能力成熟度模型集成（软件能力成熟度集成模型）

将软件企业的过程管理能力划分为5个等级：

1. 初始级：软件过程缺乏定义，依赖于几个关键人员
2. 可重复级：能重复早先类似项目的成功经验
3. 已定义级：文档化、标准化的标准软件过程
4. 量化管理级：分析详细度量数据，能在定量范围内预测性能
5. 优化管理级：过程的量化反馈和先进新思想，可从过程中得到反馈信息

ios：

基于pdca循环，要求测试人员需要得到相关授权才能进行测试活动，应得到充分的培训和指导

pdca循坏：

又叫戴明环

p：计划（方针和目标确定，活动计划）

d：执行（具体运行）

c：检查（总结执行结果）

a：行动或处理（总结成功的或失败的经验）

敏捷测试需要更多得考虑以下内容：

1. 更多得采用探索性测试方法
2. 更多得采用上下文驱动的方法
3. 更多的采用敏捷自动化测试原则

敏捷测试认为要持续的测试，不断的回归测试，快速的测试，多借鉴上下文驱动的方法适当采用自动化的方式加快测试的速度

软件质量的定义：

一个实体的所有特性，基于这些特性可以满足明显的或隐含的需求，质量就是实体基于这些特性满足需求的程度

软件质量的3个层次：

1. 符合需求规格：符合开发者明确定义的目标
2. 符合用户显式需求：符合用户明确说明的目标
3. 符合用户实际需求：包括用户明确说明的和隐含的需求

iso 9126软件质量模型：

6个特性，27个子特性

6个特性：功能性、可靠性、易用性、效率、维护性、可移植性

软件质量由组织、流程和技术三方面决定，软件质量活动包括软件质量保证（sqa）（从流程方面保证软件质量）和软件测试（从技术方面保证软件质量）

sqa工作内容：

1. 指导并监督项目按过程实施
2. 对项目进行度量和分析，增加项目可视性
3. 审核工作产品，评价工作产品和过程质量目标的符合度
4. 进行缺陷分析，缺陷预防活动，发现过程的缺陷，提供决策参考，促进过程改进

qa与qc的区别：

1.qa是质量保证，qc是质量控制

2.qc是qa的重要手段

3.qc查找的是产品的错误，qa查找的是过程的错误

qa与qc的共同点：

1. 都是查找错误
2. 目的都是对质量进行管理

软件测试的目的：

1. 证明软件是正确的
2. 为了发现错误，证明软件是错误的

软件测试的两面性：

从测试的目的出发将测试分为两大类：

1. 为了验证程序能正常工作
2. 为了证明程序不能正常工作

大部分软件测试组织在综合运用运用这两类测试方法，体现在：

1. 测试用例的设计分正面和反面的测试用例，分为验证主成功场景的用例和验证扩展场景的测试用例
2. 测试的执行结合严格的测试用例执行过程以及灵活的探索性测试执行
3. 软件测试的中前期主要集中精力发现软件的错误，软件的中后期主要集中精力验证软件的正常使用性得到保障
4. 单元测试主要关注程序做了正确的事情，集成测试和系统测试主要关注程序的错误行为
5. 自动化测试主要专注于验证程序的正确行为，手工测试主要专注于发现软件的错误行为

软件测试应遵循的原则：

1.Good enough原则：

投入和产出要适当权衡，测试不充分是对质量的不负责任，投入过多测试又会造成资源的浪费

2.Pareto（柏拉图）原则：（即80-20原则）

定义：80%的bug在分析、设计、评审阶段就能被发现和修正，剩下20%的80%（即总量的16%）需要系统的软件测试来发现，剩下的5%左右只有在用户的长时间使用过程中才能暴露出来

3.尽可能早开展测试：

越迟发现错误，修复软件需要付出的代价越高

4.在发现比较多错误的地方投入更多的测试：

物以类聚，bug有集中出现的迹象

5.同化效应：

体现在两个方面：

1. 测试人员和开发人员一起工作在一个项目中一段较长的时间后，容易受到开发人员对待软件观点的影响，变得更容易赞同开发人员的观点
2. 测试人员对软件的熟悉程度越高，越容易忽略一些看起来较小的问题

如何避免：

1. 轮换
2. 补充新的测试人员
3. 交叉测试（充分利用不同人员对待软件的不同视角和观点，引入新的测试思维）一组到另一组去

软件测试的五大流派：

1. 分析学派：是所有学派的基础，测试方法必须有一个逻辑数学形式，热衷于计算代码覆盖率，在电信安全等关键的行业应用软件的测试中应用比较广泛
2. 标准学派：测试必须管理起来，鼓励标准的使用（如最佳实践）利用测试对开发进度进行度量，研究出很多跟踪矩阵确保每个需求都被测试到，标准学派的测试需要清晰的边界来界定测试和其他活动，一般应用在企业级的it和政府软件应用行业
3. 质量学派：强调制度，使用测试来判断开发的过程是否被严格遵循了，测试人员监督开发人员遵守规则，充当守门员角色，应用在大机构承受强大压力的组织
4. 上下文驱动学派：注重技能，强调探索性测试，强调同时设计测试和执行测试，快速学习能力，主要应用于商业的、市场驱动的软件项目
5. 敏捷学派：软件是一个动态变化过程，测试来告诉大家开发过程是否完成，测试必须被自动化，强调单元测试，开发人员必须提供自动化框架，应用于it顾问公司、互联网行业、云计算应用

不同学派的测试定义：

分析学派：软件测试是计算机科学和数学的分支

标准学派：软件测试是一个管理的过程

质量学派：软件测试是软件质量保证的分支

上下文驱动学派：软件测试是开发的一个分支

敏捷学派：软件测试是顾客角色的一部分

aep（自动错误预防）：

基本概念：在戴明的质量模型上加入了自动化的元素（戴明提倡质量改进应通过分析错误根源来消除错误原因，但对于软件行业这种手工质量改进方式很难实现，需要花费大量时间和精力，因此需要引入自动化实现方式）

五个步骤：

五大法则：

软件测试阶段：

1. 测试需求的分析和确定
2. 测试计划
3. 测试设计
4. 测试执行
5. 测试记录和缺陷跟踪
6. 回归测试
7. 测试总结和报告

需求规格说明书（衡量质量，原则）：

1.正确性：对照原始需求检查

2.必要性：不能回溯到出处的需求项可能是多余的

3.优先级：恰当划分并标识

4.明确性：不用含糊的词汇

5.可测性：每项需求必须是可检验的

6.完整性：不能遗漏必要或必须的信息

7.一致性：与原始需求一致，内部前后一致

8.可修改性：良好的组织结构使需求易于修改

测试计划是对测试过程的整体设计

测试计划内容：

1. 确定测试范围：明确测试的对象
2. 确定测试策略：包括宏观的测试战略和微观的测试战术

测试战略：测试的先后次序、测试的优先级、测试的覆盖方式、回归测试的原则等

测试战术：测试方法、技巧、工具等

1. 测试资源安排
2. 进度安排
3. 风险及对策

测试设计及测试用例：

等价类划分法：黑盒测试方法，不考虑程序内部结构，只考虑程序输入规格即可，基本所有输入都可以划分为有效等价类和无效等价类

边界值分析法：假设大多数错误发生在各种输入条件的边界上，若在边界附近取值不会发生错误，那其他地方发生错误的概率也很小

等价类+边界值

基本路径分析法：白盒测试，覆盖程序分支路径，但在一些黑盒测试中也能使用

因果图法：1.找出所有输入和输出

1. 找出输入和输出之间的关系
2. 画出因果图
3. 把因果图转换为判定表
4. 把判定表对应到每一个测试用例

场景设计法

错误猜测法

测试用例设计的自动化：

目前主要集中在测试数据的生成方面

测试的执行：

1. 测试用例的合理选择：1）先执行简单的测试用例，再执行复杂的测试用例，先执行优先级高的再执行低的

2）对于回归测试的测试用例选择则复杂一点

1. 测试的分工和资源利用：合理分工，交叉测试

新老员工搭配，除本组积极寻找其他测试资源，不同项目人员协助测试

1. 测试环境的搭建：包括操作系统、测试机器、测试数据、网络环境、安装包

bvt测试：

也叫编译检查测试，检查源代码是否正确编译成一个新的、完整可用的版本

冒烟测试：

做一些基本的功能测试，随着开发深入不断演进

bvt测试和冒烟测试目的是检查程序是否完整

每日构建是每天定时把所有文件编译、连接组成一个可执行的程序的过程

bug的质量衡量：

录入的bug描述不清晰也是不行的

合格的bug包括哪些内容：

发现问题的版本，问题出现的环境，错误行为的描述，问题重现的步骤，预期行为的描述

bug报告应注意的几个问题：

1. 不要出现错别字
2. 不要把几个bug录入到同一个id
3. 附加必要的截图和文件
4. 录入完bug后自己读一遍

回归测试：

回归是指产品的质量从一个较高的水平回落到一个较低的水平

回归的问题根源是软件系统的内在复杂性（系统复杂性增加，更改产生难以预料的影响的可能性也增加）

回归测试的最大困难是时间紧迫（客观维度）更难的是克服测试人员的疲劳思维（主观维度）

基于风险的回归测试：没有足够的时间，专注于测试那些最高风险的地方

分为两个方面：可能性：可能出错的机会

影响（危害性）：确实出错后会造成的影响程度

典型缺陷的条件：

1. 重复出现、经常出现
2. 能代表某种类型的错误
3. 能通过相对固定的测试方法或手段来发现这些错误

提炼bug模式的一般步骤：

1. 分析缺陷报告，找出经常出现的bug类型
2. 分析bug的根源，找出bug产生的深层次原因
3. 分析找到bug的方法，总结如何才能每次都发现这种类型的bug

常见软件测试技术：

黑盒：软件产品当成一个黑箱，用户不需知道里面具体怎么操作，测试人员只需和用户一样看待软件产品即可，可能存在一定风险，对于安全性要求高的系统不行，会暴露后台数据库信息

白盒：以理解软件内部结构和程序运行方式为基础的软件测试技术

手工测试不可替代的地方：

1.测试用例的设计：测试人员的经验和对错误的猜测能力是工具不可替代的

2.界面和用户体验测试：人类的审美观和心理体验是工具不可模拟的

3.正确性的检查：人们对是非的判断、逻辑推理能力是工具不具备的

单元测试：

是针对软件设计中的最小单位——程序模块，进行正确性检验的测试工作

狭义：编写测试代码来检验被测试代码的正确性

广义：小到一行代码的验证，大到一个功能模块的功能验证，从代码规范性的检查到代码性能和安全性的验证都包含在里面，视单元的范围而定义

windows中任务管理器（ctrl+alt+selete）能够执行的任务：

1. 检查进程驻留
2. 检查内存问题
3. 检查网络使用情况
4. 检查cpu使用情况

用户界面测试原则：

减少用户工作量：

逻辑工作量

1. 知觉
2. 记忆
3. 物理

性能测试的种类：

1. 负载测试：验证系统在正常和峰值负载条件下的行为，疲劳测试是负载测试一个子集，评估和验证系统在一段较长时间内的性能表现
2. 压力测试：评估和验证应用程序被施加超过正常和峰值压力条件下的行为，为了揭露那些只在高负载条件下才出现的bug
3. 容量测试：评估系统在满足性能目标前提下能支持的用户数、事物数等
4. 配置：不同环境对性能的影响程度
5. 并发：多用户并发访问同一应用、模块、数据时是否产生隐藏并发问题
6. 可靠性测试：给系统加载一定的业务压力情况下，让应用持续运行一段时间，测试系统在这种条件下能否稳定运行

常见的安全漏洞：

1. 缓冲区溢出：普遍、危险
2. 整数溢出：常见的忽略编码安全造成（当有一个有符号的整数大于其最大值时，就会变成负数的最小值
3. 命令注入：没有对用户输入参数进行分析和过滤，导致执行了用户输入参数中混入的命令、代码等，从而导致恶意攻击
4. sql注入：命令注入的一种，利用数据库以及sql语言的漏洞
5. xxl-跨站脚本攻击：互联网应用中广泛存在的漏洞，目的是盗走客户端的cookies或任何可用于在web站点确定客户身份信息的其他敏感信息