软件测试
测试定义
- 使用人工或者自动的手段来运行或者测试某个系统的过程 
- 目的在于检验它是否满足规定的需求(弄清 - 预期结果和- 实际结果的差别)
测试目的
以最小的人力、物力和时间找出软件中潜在的错误和缺陷。
测试的原则
- 证明软件中存在缺陷 
- 不能穷尽测试 
- 测试应该尽早介入 
- 28原则(80%的用户只用到了20%的功能,80%的错误出现在20%的地方) 
- 不存在缺陷谬论(程序一定有缺陷) 
- 妥善保存一切文档 
测试标准
国际标准25010、国内标准GBT18905
测试的基本要求
- 外观界面测试 
- 易用测试 
- 兼容性测试 
- 安全性测试 
- 性能测试 
- 功能测试 
测试的工作流程
- 需求分析(阅读需求文档,分析需求的点,参与需求评审) 
- 测试计划和测试方案(宏观计划和实际方案) 
- 测试用例设计 
- 测试用例执行 
- 评估阶段 测试报告 
开发模式
瀑布模型

优点:
- 为项目提供了按阶段划分的检查点 
- 可在迭代模型中应用瀑布模型 
- 当前阶段完成后,只需要关注后序阶段 
缺点:
- 不适合需求变动多的项目 
- 成品消耗较多时间 
- 灵活性较差 
适合项目类型:学生管理模型、银行系统
增量模型
定义:把瀑布模型的顺序特征和快速原型法的迭代特征相结合,将软件看做一系列相互联系的增量,在开发过程的各次迭代中,每次完成其中的一个增量。

快速原型模型
特点:快速建立起来的可以运行在计算机上运行的程序。
- 克服瀑布模型的缺点,减少由于软件需求不明确带来的开发风险。适合预先不能明确定义需求的软件系统的开发 
- 所选用的开发技术和工具不一定符合主流的发。快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。 

其他模型
螺旋开发模型、迭代开发模型、敏捷开发模型
测试模型
V模型
编码-单元测试,详细设计-集成测试,概要设计-系统测试,需求分析-验收测试
缺点:测试的阶段晚,在编码阶段才开始测试。

W模型
优点:软件测试伴随软件的整个生命周期,在需求分析结束后就可以进行需求分析测试,测试和开发并行独立进行

测试和开发的关系
- 目标相同:制造高质量软件 
- 相辅相成:开发经验对测试有用,测试经验对开发有用 
- 侧重点不同:开发侧重于从无到有,测试偏重于从有到优 
软件测试分类
思维导图模式
测试用例
定义:测试用例又叫做test case,是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果以便测试某个程序路径或核实是否满足某个特定需求。
测试用例的特性:
- 有效性(测试用例能够被使用,且被不同人员使用测试结果一致) 
- 可复用性(良好的测试用例具有重复使用的功能,如回归测试) 
- 易组织性(好的测试用例会分门别类地提供给测试人员参考和使用) 
- 可评估性(从测试管理的角度,测试用例的通过率和软件缺陷的书目是软件产品好坏的测试标准) 
- 可管理性(从测试管理的角度,测试用例的通过率和软件缺陷的书目是软件产品好坏的测试标准) 
测试用例的要素
- 测试用例编号(唯一性,容易识别) 
- 测试项目/模块 
- 前提条件 
- 测试输入 
- 预期输出(从需求文档得到) 
- 操作步骤(描述详细) 
- 测试用例标题 
- 级别 
其他要素:
- 用例的设计者 
- 用例设计日期(方便检查用例的设计进度) 
- 对应开发人员 
- 测试结果(pass,fail,block) 
- 测试类型(功能,性能,压力) 
| 测试用例编号 | 测试项目/模块 | 前提条件 | 测试输入 | 预期输出 | 操作步骤 | 测试用例标题 | 级别 | 
|---|---|---|---|---|---|---|---|
| ST-子项名-01 | 手机登录 | 手机正常使用 | 手机号 | 正常登录 | 输入手机号并确认 | 测试手机能否登录成功 | 重要 | 
测试用例的设计原则
- 明确性(测试结果唯一) 
- 代表性(相似的用例要合并) 
- 简洁性(语句简洁) 
等价类划分法
定义:将不能穷举的测试过程进行合理分类,从而保证设计出来的测试用例具有完整性和代表性
类型划分:
- 有效等价类 
- 无效等价类 
设计测试用例步骤
- 确认需求 
- 确认有效等价类和无效等价类 
- 对每条等价类设计测试用例 
案例(qq登录)
QQ号:6-10位且不以0开头
有效等价类:6位数字,7位数字,8位数字,9位数字,10位数字
无效等价类:6位数字,7位数字,8位数字,9位数字,10位数字(以0开头)
小数、字母、特殊字符、汉字、组合
| 测试用例编号 | 测试项目/模块 | 前提条件 | 测试输入 | 预期输出 | 操作步骤 | 测试用例标题 | 级别 | 
|---|---|---|---|---|---|---|---|
| qq-login-001 | 有效测试qq登录 | 网络正常 | 100001 | qq号正确 | 1.把数据填写到qq号码栏 2.点击登录 | 有效测试qq登录 | 重要/通过 | 
| qq-login-002 | 无效测试qq登录 | 网络正常 | abcdef | qq号错粗 | 1.把数据填写到qq号码栏 2.点击登录 | 无效测试qq登录 | 重要/通过 | 
边界值法
定义:作为等价类划分法的补充,其测试用例来源于等价类的边界。
边界点(上点):输入范围的边界点
离点:离边界点最近的点
内点:输入范围内的任意一个点
因果图法
特点:
- 考虑输入条件的相互制约及组合关系 
- 考虑输出条件对输入条件的依赖关系 
因果图中的符号:
~(非),v(或),^(与)
因果图的约束条件:
- E(互斥)-最多一个可能实现 
- I(包含)-至少一个实现 
- M(屏蔽)-条件成立,结果不成立;条件不成立,结果不一定不成立。 
- O(唯一)-有且只要一个成立 
- R(要求)-一个出现另外一个一定出现 
因果图法的基本步骤
- 找出所有的原因,即输入条件或输入条件的等价类 
- 找出所有的结果,即输出条件 
- 明确输入条件之间的制约关系以及组合关系(哪些可以组合,哪些不可以组合) 
- 明确所有输出条件之间的制约关系以及组合关系(哪些可以同时输出,哪些不可以同时输出) 
- 找出什么样的组合条件会产生哪种输出结果 
- 把因果转换成判定表/决策表 
- 为判定表/决策表的每一列表示的情况设计测试用例 
案例分析
交通一卡通自动充值软件
条件:
- 输入50元 
- 输入100元 
- 选择充值50元 
- 选择充值100元 
{1,3}, {1,4}, {2,3}, {2,4}可以组合;1,2,3,4可以单独出现
结果:
- 完成充值,退卡 
- 提示充值成功 
- 找零 
- 提示错误 
{1,2}必须组合在一起; {1,2,3}可以组合在一起; {3,4}可以组合,4可以单独出现

判定表法
判定表就是因果图的最终产品
正交表法
软件:allpairs
作用:用比较少的案例代表比较多的案例
场景法
定义:通过一系列操作步骤,达成某一个结果,到终点的过程测试
一般用于冒烟测试





