软件测试文档
什么是软件测试
通过手工和自动化工具对被测对象进行检测，验证实际结果和预期结果之间的差异。
软件测试的原则
1 测试是为了证明软件存在缺陷
2 测试应该尽早介入
3 注意测试缺陷的群集效应80-20
4 杀虫剂现象
5 合法数据和不合法数据和边界值，网络异常和电源断电等
6 回归测试防止出现更多问题
7 妥善保存一切测试文档
软件测试的目的
1 暴露软件中的缺陷和BUG
2 记录软件运行中产生的一些数据，为开发提供改良的数据支持
为什么需要软件测试
1 功能实现且正确执行
2 软件运行的信息数据
如果一个产品开发完成之后发现了很多问题，说明此软件开发过程很可能是有缺陷的，因此，软件测试的目的是保证整个软件开发过程是高质量的。
测试分类
1 单元测试 分单元
2 集成测试 多个单元
3 系统测试 用户角度-功能主体
4 验证测试 α测试-内测 β测试-公测 UAT测试-客户验收使用
系统测试分类
1 功能测试
2 性能测试
3 安全测试
4 兼容性测试
测试方法
1 按照测试对象分类
白盒测试
黑盒测试
灰盒测试
2 按照测试对象是否执行分类
静态测试
动态测试
3 按照测试手段进行分类
手工测试 灵活改变测试操作和环境
自动化测试 1 自己写脚本 2 第三方工具进行测试
软件质量
1 维护性
2 移植性
3 效率性
4 可靠性
5 易用性
6 功能性
软件测试流程
1 需求分析
2 设计用例
3 评审用例
4 配置环境 操作系统+ 服务器+数据库 +软件依赖
5 执行用例
6 回归测试及缺陷跟踪
7 输出测试报告
8 测试结束
软件架构
BS browser浏览器 + server服务器
CS client客户端 + server服务器
1 标准上 BS是在服务器和浏览器都存在的基础上开发
2 效率 BS中负担在服务器上 CS中的客户端会分担，CS效率更高
3 安全 BS数据依靠http协议进行明文输出 不安全
4 升级上 bs更简便
5 开发成本 bs更简单 cs需要客户端 安卓和ios
软件开发模型
瀑布模型
1 需求分析
2 功能设计
3 编写代码
4 功能实现 切入点
5 软件测试 需求变更
6 完成
7 上线维护
是一种线性模型的一种，是其他开发模型的基础
测试的切入点 要留下足够的时间 可能导致测试不充分，上线后才暴露
优点
开发的各个阶段比较清晰
需求调查 适合需求稳定的产品开发
当前一阶段完成后，您只需要去关注后续阶段
可在迭代模型中应用瀑布模型
可以节省大量的时间和金钱
缺点
1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4）瀑布模型的突出缺点是不适应用户需求的变化
瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。
快速原型模型
部分需求 - 原型- 补充 - 运行 外包公司
预先不能明确定义需求的软件系统的开发，更好的满足用户需求并减少由于软件需求不明确带来的项目开发风险。
不适合大型系统的开发，前提要有一个展示性的产品原型，在一定程度上的补充，限制开发人员的创新。
螺旋模型
每次功能都要先进行风险评估，需求设计-测试
很大程度上是一种风险驱动的方法体系，在每个阶段循环前，都进行风险评估。
需要有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，很有必要，多次迭代，增加成本。
软件测试模型
需求分析-概要设计-详细设计-开发-单元测试-集成测试-系统测试-验收测试
优点
清楚标识软件开发的阶段 包含底层测试 和高层测试
采用自顶向下 逐步求精的方式把整个开发过程分成不同的阶段，每个阶段的工作都很明确，便于控制开发过程。
缺点
程序已经完成，错误在测试阶段发现或没有发现，不能及时修改
而且需求经常变化 导致V步骤反复执行，工作量很大。
W模型
开发一个V 测试一个V
用户需求 验收测试设计
需求分析 系统测试设计
概要设计 集成测试设计
详细设计 单元测试设计
编码 单元测试
集成 集成测试
运行 系统测试
交付 验收测试
优点
测试更早的介入，可以发现开发初期的缺陷，降低成本
对每个阶段都进行测试，包括文档，便于控制项目过程
缺点
依赖文档，没有文档的项目无法使用，复杂度很高，实践需要很强的管理
H模型把测试活动完全独立出来，将测试准备和测试执行体现出来
测试准备 - 测试执行
就绪点
其他流程 ----------设计等
v模型适用于中小企业 需求在开始必须明确，不适用变更需求
w模型适用于中大企业 包括文档也需要测试（需求分析文档 概要设计文档 详细设计文档 代码文档）测试和开发同步进行H模型对公司参与人员技能和沟通要求高
测试阶段
单元测试-集成测试-系统测试-验证测试
是否覆盖代码
白盒测试-黑盒测试-灰盒测试
是否运行
静态测试-动态测试
测试手段
人工测试-自动化测试
其他测试
回归测试-冒烟测试
功能测试
一般功能测试-界面测试-易用性测试-安装测试-兼容性测试
性能测试
稳定性测试-负载测试-压力测试-时间性能-空间性能
负载测试 确定在各种工作负载下，系统各项指标变化情况
压力测试:通过确定一个系统的刚好不能接受的性能点。获得系统能够提供的最大服务级别
测试用例
为特定的目的而设计的一组测试输入，执行条件和预期结果，以便测试是否满足某个特定需求。
通过大量的测试用例来检测软件的运行效果，它是指导测试工作进行的依据。
等价类划分法
将不能穷举的测试过程进行合理分类，从而保证设计出来的测试用例具有完整性和代表性。
有数据输入的地方，可以使用等价类划分法。
从大量数据中挑选少量代表数据进行测试
有效等价类：符合需求规格说明书规定的数据用来测试功能是否正确实现
无效等价类：不合理的输入数据集合—用来测试程序是否有强大的异常处理能力（健壮性）
使用最少的测试数据，达到最好的测试质量
边界值分析法
对输入或输出的边界值进行测试的一种黑盒测试方法。
是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
边界点
1、边界是指相对于输入等价类和输出等价类而言，稍高于、稍低于其边界值的一些特定情况。
2、边界点分为上点、内点和离点。
如果是范围[1,100] 需要选择0,1,2,50,99,100,101
如果是个数最多20个 [0,20] 需要测 0,10,20，-1,21
因果图分析法
用画图的方式表达输入条件和输出结果之间的关系。
1 恒等
2 与
3 或
4 非
5 互斥 1个或者不选
6 唯一 必须是1个
7 包含 可以多选 不能不选
8 要求 如果a=1，则要求b必须是1，反之如果a=0时，b的值无所谓
9 屏蔽关系 当a=1时，要求b必须为0；而当a=0时，b的值不一定
判定表法
根据因果来制定判定表
组成部分
1 条件桩:所有条件
2 动作桩: 所有结果
3 条件项: 针对条件桩的取值
4 动作项:针对动作桩的取值
不犯罪，不抽烟是好男人，不喝酒是好男人，只要打媳妇就是坏男人
条件桩 1 不犯罪 1 1 0
2 不抽烟 1 0 1
3 不喝酒 0 1 1
动作桩 好男人 1 1
坏男人 1
场景法
模拟用户操作软件时的场景，主要用于测试系统的业务流程
先关注功能和业务是否正确实现，然后再使用等价类和边界值进行检测。
基本流 正确的业务流程来实现一条操作路径
备选流 模拟一条错误的操作流程
用例场景要从开始到结束便利用例中所有的基本流和备选流。
流程分析法
流程-路径
针对路径使用路径分析的方法设计测试用例
降低测试用例设计难度，只要搞清楚各种流程，就可以设计出高质量的测试用例，而不需要太多测试经验
1 详细了解需求
2 根据需求说明或界面原型，找出业务流程的哥哥页面以及流转关系
3 画出业务流程axure
4 写用例，覆盖所有路径分支
错误推断法
利用经验猜测出出错的可能类型，有针对性列出所有可能的错误和容易发生错误的情况。
多考虑异常，反面，特殊输入，以攻击者的态度对台程序。
正交表
对可选项多种可取值进行均等选取组合，最大概率覆盖测试用例
1 根据控件和取值数选择一个合适的正交表
2 列举取值并编号，生成取值表。
3 把取值表与选择的正交表进行映射
控件数
Ln(取值数 ) 3个控件 5个取值 5的3次幂
混合正交表
当控件的取值数目水平不一致时候，使用allpairs工具生成
1 等价类划分法 划分值
2 边界值分析法 边界值
3错误推断法 经验
4 因果图分析法 关系
5 判定表法 条件和结果
6流程图法 流程路径梳理
7 场景法 主要功能和业务的事件
8 正交表
先关注主要功能和业务流程，业务逻辑是否正确实现，考虑场景法
需要输入数据的地方，考虑等价类划分法+边界值分析法，发现程序错误的能力最强
存在输入条件的组合情况，考虑因果图判定表法
多种参数配置组合情况，正交表排列法
采用错误推断法再追加测试用例。
需求分析
场景法 分析主要功能
输入的 等价类 边界值
输入的 各种组合 因果图判定表
多种参数配置 正交表
错误推断法 经验
软件缺陷
软件产品中存在的问题，用户所需要的功能没有完全实现，没有满足用户的需求
1 未达到需求规格说明书表明的功能
2 出现了需求规格说明书指明不会出现的错误
3 软件功能超出了需求规格说明书指明的范围
4 软件质量不够高
维护性 移植性 效率性 可靠性 易用性 功能性 健壮性等
5 软件未达到软件需求规格说明书未指出但是应该达到的目标
计算器没电了 下次还得能正常使用
6 测试或用户觉得不好
软件缺陷的表现形式
1 功能没有完全实现
2 产品的实际结果和所期望的结果不一致
3 没有达到需求规格说明书所规定的的性能指标等
4 运行出错 断电 运行终端 系统崩溃
5 界面排版重点不突出，格式不统一
6 用户不能接受的其他问题
软件缺陷产生的原因
需求错误
需求记录错误
设计说明错误
代码错误
兼容性错误
时间不充足
缺陷的信息
缺陷id
缺陷标题
缺陷严重程度
缺陷的优先级
缺陷的所属模块
缺陷的详细描述
缺陷提交时间
缺陷的严重程度划分
1 blocker 系统瘫痪 异常退出 计算错误 大部分功能不能使用 死机
2 major 功能点不符合用户需求 数据丢失
3 normal 独立功能 特定调点 断断续续
4 Trivial 细小的错误
优先级划分
紧急
高
中
低
为什么要用索引？
使用索引后减少了存储引擎需要扫描的数据量，加快查询速度
索引可以把随机I/O变为顺序I/O
索引可以帮助我们对所搜结果进行排序以避免使用磁盘临时表