#博学谷IT学习技术支持#
目录
一、前言
HELLO，小伙伴们，又见面了，我又带着满满的干货来了，本周的内容以手工测试理论知识为主。
大家根据理论知识，需要掌握手工测试从前到后的整个过程，之后就是多进行用例的分析设计来提高自身能力了。
OK，废话不多说，直接上干货~~~
二、软件测试分类
按阶段划分
-
单元测试
-
测试：针对单个功能进行测试,如：登录、购物车等
-
开发（更多的理解）：针对代码进行测试（一般由开发负责、或自动化测试协助）
-
-
集成测试
-
组装测试
-
-
系统测试
-
针对系统进行整体性测试
-
软件功能
-
硬件功能
-
-
-
验收测试（用户检验产品是否满足自己预期）
-
α测试：bug比较多、内测版本
-
β测试：bug相对比较少、公测版本
-
γ测试：候选发布版本
-
负责人（甲乙方）：
-
甲方负责
-
乙方协助（在甲方的授权及信任基础上）
-
第三方评测机构
-
-
按是否覆盖源代码划分
-
黑盒测试：输入和输出
-
白盒测试：代码内部实现逻辑
-
灰盒测试
-
测试关注点：输入；输出；代码逻辑
-
按照是否运行
-
静态测试
-
不运行被测试程序
-
测试对象
-
文档
-
代码
-
-
-
动态测试
-
运行测试程序
-
测试对象
-
运行中的程序
-
-
按照是否自动化
-
手工测试（功能测试）
-
自动化测试
-
通过工具或代码代替人进行测试的过程
-
更多
-
冒烟测试
-
开发提交测试版本的接收性测试
-
测试点
-
最基本功能，如用户正常登录
-
最核心的业务流程，如电商购买商品全过程
-
-
-
回归测试
-
测试点
-
bug回归
-
旧功能回归
-
-
-
随机测试
-
探索测试
三、软件开发流程（软件生命周期）
瀑布模型
-
组成
-
需求分析→概要设计→详细设计→编码→软件测试→软件维护
-
-
特点
-
线性模型
-
文档驱动
-
-
优点
-
只需要关注当前进行的阶段
-
-
缺点
-
不响应需求变化
-
-
典型应用场景
-
需求清晰的大型项目，如银行、保险、建筑等
-
四、软件测试模型
V模型
-
组成
-
需求分析→概要设计→详细设计→编码→单元测试→集成测试→系统测试→验收测试
-
-
优点
-
只需要关注当前进行的阶段、文档驱动、线性模型
-
-
缺点
-
不响应需求的变化、不灵活
-
W模型--双V模型
-
绘制
-
开发V：需求分析→概要设计→详细设计→编码→集成→实施→交付
-
测试V：验收测试设计→系统测试设计→集成测试设计→单元测试设计→单元测试→集成测试→系统测试→验收测试
-
-
优点
-
测试贯穿软件开发的全生命周期
-
早参与、早发现、早解决
-
-
缺点
-
技术和管理要求比较高
-
软件质量模型
-
功能性：检查业务功能是否满足需求
-
可靠性：容错能力（恢复正常的时间、能力）
-
易用性：看的懂、会使用等
-
效率性：性能（响应时间、消耗的资源（CPU、内存）等）
-
维护性：为后续功能的开发和维护提供便利
-
移植性：软件需要在不同的软件环境和硬件环境下都能正常的工作
五、软件测试用例
软件测试用例概念
-
概念：一个为了特定的目的（检验开发的代码实现是否满足用户的需求）而设计的文档（包含测试输入、执行条件、预期结果），文档的形式可以时xmind、excel等。
测试用例组成要素
-
ID
-
唯一性
-
项目-模块-001
-
-
模块
-
优先级
-
作用：体现用例执行的先后顺序
-
-
用例标题
-
唯一性
-
见名知意
-
-
预置条件
-
测试步骤
-
尽可能详细
-
-
测试数据
-
预期结果
软件测试用例的作用
-
便于理清测试思路，确保需覆盖测试的功能点无遗漏
-
便于测试工作量的评估
-
便于提前准备测试数据
-
便于把控测试工作进度
-
便于回归测试
-
便于测试工作的组织，提高测试效率，降低测试交接成本
等价类划分法
-
概念：通过科学的方法找到具有共同特征的测试输入的子集，能够从穷举测试中解放（大大减少了测试数量，从而提升测试效率）
-
分类
-
有效等价类：满足需求
-
无效等价类：不满足需求
-
-
设计测试用例的步骤
-
需求分析
-
划分等价类
-
有效
-
无效
-
规则（需求本身）
-
长度
-
类型
-
是否为空（必填项）
-
是否重复
-
-
-
设计用例
-
-
典型应用场景
-
输入框
-
边界值
-
作用：对等价类的补充，统计表明程序最容易出错的地方就是在边界附近。
-
概念：基于边界值 [有效等价类和无效等价类的分界点] 设计测试用例的一种 [黑盒] 方法
-
边界值
-
上点：边界之上的点
-
内点：边界之内的点
-
离点：离边界最近的左右两点
-
-
设计测试用例步骤
-
需求分析
-
划分等价类
-
确定边界
-
上点
-
内点
-
离点
-
-
设计测试用例
-
-
典型应用场景
-
存在边界
-
扩展知识：
-
边界值优化[7点变5点]
判定表
-
概念：存在多个输入条件、多个输出结果，输入和输入之间有组合关系，输入和输出之间有依赖或制约关系。
-
判定表组成：
-
条件桩：所有输入条件
-
动作桩：所有可能的输出结果
-
条件项：单个条件的取值范围，一般都是有效等价类和无效等价类
-
表示方式
-
字符：
-
真/有效等价类/Y
-
假/无效等价类/N
-
-
数字
-
真/有效等价类/1
-
假/无效等价类/0
-
-
-
-
动作项：基于每一种条件的组合，得到确认的结果
-
-
设计测试用例的步骤
-
明确条件桩（找到所有的输入条件）
-
明确动作桩（找到所有的输出结果）
-
对条件桩进行全组合
-
明确每个组合对应的动作桩（基于每一种条件的组合情况，确定本组合下的输出结果）
-
设计测试用例，每行数据对应一条测试用例
-
使用场景：
-
多条件组合情况
-
因果图
-
概念：用图解的方法表示输入的各种组合关系，写出判定表，进而设计测试用例的一种【黑盒】方法。
-
适用范围：适用于分析程序输入条件的各种组合情况，以及输入和输出之间的依赖关系。
-
核心
-
因：条件
-
果：结果
-
-
基本符号
-
恒等（-）：条件成立，结果成立。
-
非（~）：条件成立，结果不成立；条件不成立，结果成立。
-
或（v）：只要有一个条件成立，结果就成立；所有条件都不成立时，结果才不成立。
-
与/且（^）：多个条件必须同时成立，结果成立；只要有一个不成立，结果就不成立。
-
-
设计测试用例的步骤
-
需求分析
-
画出因果图
-
将因果图转换为判定表
-
生成测试用例
-
正交法
核心思想
-
用最小的测试用例获得最大的测试覆盖率
正交表
一种特制的表，一般的正交表标记为： Ln(m的k次方)
说明
-
k代表因素（输入参数）
-
m叫水平（输入参数的取值）
-
n代表测试用例数
-
读法：k因素m水平
基于正交表设计测试用例
-
步骤
-
需求分析
-
确定因素与水平（因素：控件名称；水平：每个控件对应的取值）
-
确定要采用的正交表
-
将正交表中的字母用文字代替
-
设计测试用例（一行就是一条测试用例）
-
基于allpairs设计测试用例
-
步骤
-
需求分析
-
确定因素与水平（因素：控件名称；水平：每个控件对应的取值）
-
将确定的因素与水平复制到txt文件中
-
打开DOS窗口，进入allpairs目录，运行命令：allpairs.exe test.txt > result.txt
-
根据生成的新文件编写测试用例（一行就是一条测试用例）
-
场景法（流程图法）
-
概念：场景法就是模拟用户操作软件时的场景，主要用于测试多个功能之间的组合使用情况。
-
使用测试阶段
-
集成测试
-
系统测试
-
验收测试
-
-
设计测试用例的步骤
-
需求分析
-
绘制流程图
-
设计测试用例（一条流程图就是一条测试用例）
-
-
流程图常用符号
-
开始或结束：椭圆
-
方向或路径：箭头
-
处理或操作：长方形
-
判断：菱形
-
输入或输出：平行四边形
-
错误推测法
-
概念：利用经验或智慧发现程序中可能犯错的地方。
-
使用场景
-
重要功能
-
使用同类型产品
-
任务急、时间紧、资源少
-
测试用例设计方法总结
-
具有输入功能，但输入之间没有组合关系==等价类
-
输入有边界 如长度、类型==边界值
-
多输入、多输出、输入与输入之间存在组合关系、输入与输出之间存在依赖或制约关系==判定表、因果图
-
用最少的测试用例获得最大测试覆盖率时==正交法
-
多个功能的组合测试==场景法、流程图
-
进一步补充测试用例==错误推测法
六、缺陷
缺陷的定义
-
产品实现不满足用户需求
-
测试执行时，实际结果和预期结果不一致
缺陷的判定标准
-
未达到需求说明书指明的功能
-
出现了需求说明书指明不应该出现的错误
-
实现了需求说明书之外的功能
-
未达到需求说明书虽未明确提及但是应该实现的目标（如：性能要求等）
-
用户角度发现的各种问题与错误
缺陷产生的原因及根本原因
-
缺陷产生的原因
-
需求文档存在错误
-
需求变更
-
-
设计存在错误
-
代码错误
-
-
缺陷产生的根本原因
-
需求变更
-
沟通不畅、信息不同步
-
软件复杂
-
进度压力
-
软件缺陷的核心内容
-
标题：描述缺陷的基本信息
-
前置条件：描述缺陷出现依赖的相关基础条件
-
复现步骤：测试用例里面的执行步骤
-
实际结果：执行被测软件过程中，系统给出的结果
-
预期结果：参照需求说明书，在测试用例中设计的预期结果
-
附件：方便开发定位bug的关键信息，包含图片、日志log等
缺陷的基本要素
-
缺陷编号：缺陷的唯一性标志
-
缺陷状态：表示缺陷当前处于哪个阶段
-
模块：根据产品进行划分，如登录、注册
-
严重程度：从技术维度来衡量bug的破坏力
-
优先级：从业务的角度决定bug修改的先后顺序
-
缺陷类别：用于分类整理缺陷
缺陷的状态
-
new：新建
-
open：打开
-
fix：已修复
-
close：关闭
-
reopen：重新打开
-
reject：已拒绝
-
postpone：延期
七、结尾
小伙伴们，以上内容就是手工测试阶段的理论知识了，大家一定记得结合理论进行用例设计，掌握用例设计思维，让自己的测试用例涉及范围更加全面、精准。
好了，今天的分享到这里，期待下次的分享吧！！！
扫一扫
2465
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
