需求分析---了解熟悉业务，分析需求测试点
- 确认功能(业务功能，辅助功能，数据约束，易用性需求，编辑约束，参数需求，权限需求，性能约束）
- 场景分析（考虑场景调用者和系统内部各个场景之间联系）
- 挖掘隐性需求（常用业务流程以及各分支）
测试计划
1. 编写目的
- 此文档根据项目需求文档，制定测试策略、评估测试风险，确定所需的资源，并对测试的工作量进行估计，进行人员和进度安排，并且列出测试项目的可交付元素。
2. 参考文档
- 详细设计文档，设计原型
3. 测试概要
1. 测试目标
通过测试，达到以下目标：
- 测试已实现的产品是否达到设计的要求，包括：各个功能点是否以实现，业务流程是否正确。
- 产品规定的操作和系统运行稳定。
Bug数和缺陷率控制在可接收的范围之内，遗留BUG一般不超过所有BUG的10%
2. 测试范围
-列出测试最终需要交付的功能模块列表
3. 测试人力资源
4. 测试环境：服务器环境，终端环境，网络环境
5. bug管理工具
4. 测试规范
- 开始测试标准：代码编译通过，软件可以争取安装运行，实现功能与产品设计出人，冒烟测试通过
- 中断测试标准：安装无法正确完成，程序代码编译不通过，系统服务异常，发现阻塞功能的bug
5. bug规范
- 致命，严重，一般，建议
6. 测试策略
- 冒烟测试：依据开发提测时间变动
- 第一轮功能测试：执行测试用例，包括边界值测试，兼容性测试，易用性测试，用户- - 界面测试，安全性测试
- 第二轮功能测试：bug复测及功能验证
- 回归测试：全面回归测试
- 性能测试：需确认具体性能测试方案和工具
- 发布测试
- 测试报告总结
7. 测试风险
- 测试本身（测试时间/测试技术/开发进度延误/难以修复缺陷/其它原因）
8. 测试输出文档
- 测试计划
- 测试用例
- 测试bug单
- 测试报告
测试用例
测试需求分析和业务流程分析
1. 设计方法（重要）
等价类划分法
依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用 例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。
有效等价类：符合规格说明，对程序来说有意义的数据集合。
无效等价类：不符合需求规格说明的。
举个例子：输入5-15个大写字母
（将测试的范围划分成几个互不相交的子集）
有效等价类：5-15个大写字母
无效等价类：小于5或大于15的大写字母、数字、特殊字符、小写字母。
-
原则：
-
确定了输入条件取值范围或值的个数，可以划分出1个有效等价类和2个无效等价类。
例如：输入学生成绩，输入域为[0,100]，有效等价类为[0,100]，无效等价类为(-∞，0)和(100,+∞) -
输入条件规定了输入值的集合，例如条件中规定了“必须如何”的绝对条件，可以确定1个有效等价类和1个对立无效等价类。
例如：规定输入为正整数，有效等价类为所有正整数，无效等价类为所有非正整数 -
输入条件的数据类型为布尔类型，可以确定1个有效等价类和1个无效等价类，有效等价类为true，无效等价类为false。
-
规定了输入数据的一组值，假定n个，程序要对这n组值分别处理，可以划分出n个有效等价类和1个无效等价类。
例如：规定输入数据只能为中文，英文或阿拉伯文，则这三种分别为3个有效等价类，除这3种以外的任何字符集合为1个无效等价类 -
在规定了输入数据必须遵守规则的情况下，可划分出1个遵守规则的有效等价类和若干个从不同角度违反规则的无效等价类。
-
若已划分出的等价类中各元素在程序中的处理方式不同，则应再将该等价类进一步划分为更小的等价类。
边界值分析法
针对输入输出边界值进行测试的一种黑盒测试方法。
通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
举个例子：
（选出的测试用例，应选取正好等于、刚刚大于、刚刚小于边界的值）
1.输入框长度为1-11：取边界值：0，1，2，10，11，12
2.运动员的参赛项目为1-3项：取边界值：0项，1项，2项，3项，4项
注册邮箱的软件需求为例子：
用户名要求长度为6-15位
边界值上的点：5，6，7，14，15，16
在实际的测试过程中，会将等价类和边界值结合起来使用，所以最终确认的用例设计为：5，6，7，10，14，15，16
因果图法
表示输入和输出关系的一种逻辑图.使用场景：当需求有多个输入时候，并且需求的输出和输入相关，我们就用因果图法。
- 恒等：如果原因为真，那么结果必定为真。
- 与：只有两个原因都为真，结果才为真。
- 或：只要有一个原因为真，结果就为真。
- 非：原因为假，结果为真
因果图设计测试用例的步骤：
- 分析所有输入输出的可能
- 找出输入和输出之间的对应关系
- 画出因果图
- 把因果图转为判定表
- 把判定表对应到每一个测试用例
判定表法（适合于逻辑判断复杂的场景，通过穷举条件获得结果，对结果再进行优化合并，会得到一个判断清晰的策略）
场景法
场景法多个功能点组合在一起形成事件流，根据不同的事件触发，形成不同的场景。
银行取款例子：
插卡–>输入密码–>输入取款金额–>取款–>退卡
基本流：没有异常事件发生的条件下的场景
备选流：发生异常情况下的场景
输入错误密码：第一次输错，第二次输对。
第二次、第三次密码都输错，吞卡，账户冻结。
当输入金额大于银行余额，会提示“余额不足”。
取款操作过慢，吞卡。
正交实验法
正交实验设计是研究多因素多水平的一种设计方法。根据正交性，由试验因素的全部水平组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析了解全面试验的情况，找出最优的水平组合。
- 因素（Factor）：在一项试验中，凡欲考察的变量称为因素（变量 ）
- 水平（位级）（Level）：在试验范围内，因素被考察的值称为水平（变量的取值 ）
- 因素数(Factors)：正交表中列的个数，用C代表。
- 水平数(Levels)：任何单个因素能够取得的值的最大个数。
- 行数：L= N（CT）= （水平数 - 1）* 因素数 + 1。
正交法设计测试用例的步骤：（在各因素互相独立的情况下，设计出一种特殊的表格，找出能以少数替代全面的测试用例）
- 有哪些因素（变量）
- 每个因素有哪几个水平（变量的取值）
- 选择一个合适的正交表
- 把变量的值映射到表中
- 把每一行的各因素水平的组合作为一个测试用例
- 加上你认为可疑且没有在表中出现的用例组
以用户用邮箱注册为例子
- 因素：姓名，邮箱，密码，确认密码，验证码
- 水平：填写，不填写
- 表中的因素数=5
表中每个因素的水平数=2(填写或不填写)
正交表的行数：((水平数-1)*因素数）+1
正交表的列数：因素数
功能图法
错误推测法
错误猜测法是经验丰富的测试人员喜欢使用的一种测试方法。错误猜测法只适用于其他测试用例设计法，设计完测试用例之后，进行测试用例的补充。
（在测试程序时，人们可以根据经验或直觉推测程序中可能存在的各种错误）
- 基于经验和直觉，找出程序中你认为可能出现的错误，有针对性地设计测试用例。
- 经验可能来自于在对某项业务的测试较多，也可以来自于售后用户的反馈意见
- 从故障管理库中整理bug。
经验丰富的测试人员喜欢的一种测试方法
基于经验和直觉，找出程序中可能出现的错误，有针对的设计测试用例
案例分析：
还是以注册为例子，重点关注
①姓名中的特殊字符
②密码校验中的大小写
③密码发送是否明文
还有其它测试大纲法和状态迁移法等
2. 测试用例八要素：
-
用例编号，测试项目，测试标题，重要级别，预置条件，测试输入，操作步骤，预期输出
- 用例编号（规则：由字符和数字组成的字符串，具有唯一性，易识别性）
- 测试项目（对应测试用例编号中的测试子项名 系统测试
- 测试标题（体现测试出发点关注点以及测试用例期盼的测试结果）
- 重要级别、优先级别（重要级别一般分为高中低 ）
- 预置条件：测试用例在执行时需要满足一些前提条件，环境的设置
- 测试输入（测试执行中需要加工的外部信息，避免用描述性语言，要具体，根据测试用例具体情况，有手工输入，文件，数据库记录）
- 操作步骤：执行当前用例需要经过的操作步骤，需要明确的给出每一个步骤的描述
- 预期输出：需要判断测试对象是否正常工作
测试执行
1. 测试环境搭建
-
测试环境：硬件环境，软件环境
-
硬件环境：测试必须的服务器，客户端，网络连接设备，以及打印机/扫描仪等辅助硬件设备构成的环境
-
软件环境：被测软件运行的操作系统，数据库以及其它应用软件构成的环境
-
搭建测试环境的准备工作：
- 安装工具：虚拟机
- 虚拟机优点：运行在主机上
2. 执行测试用例
- 根据测试用例优先级来执行测试用例
3. 测试执行流程：
- 冒烟测试-迭代测试（先功能后性能，回归测试）-发布测试
- 注：对应测试产出对应测试报告和bug清单，并将bug提到缺陷管理库里
测试文档
1. 测试报告
- 测试结论（是否达到发布标准，是否可发布）
- 已知风险、未知风险
- 测试时间，测试人员（测试起止时间）
- 测试环境，测试设备（用到哪些测试收集，客户端环境，浏览器）
- 需求大纲（当前这个版本，包含哪些需求点）
- Bug数据分析（从多个维度分析：bug等级分布，遗留bug分析，bug类型分布。模块bug分布，bug激活次数分析）
- 测试总结（从测试角度，对版本存在的问题，提出建议）
2. bug清单报告
- 分析统计bug迭代生命周期
- bug迭代修复情况（折线图）
- 未关闭bug按严重等级或状态统计（扇形图）
另附：
最好配带截屏图片和log日志
bug描述：（重要）
- bug标题（问题描述）
- bug测试环境（所属版本，所属模块）
- bug优先级
- bug类型
- 可重复性（是否好复现）
- 操作步骤（通过对什么样的操作，进行了什么 样的步骤）
- 预期结果
- 实际结果
