测试理论篇

测试理论篇

软件测试的介绍：
1.1.1 定义：
通过手动或者是工具进行对测试对象进行操作，从而将预期结果和实际结果进行匹配验证是否存在差异
1.1.2 测试流程：
1.产品提出需求，相关人员进行开会讨论确认需求，保证需求可执行。
2.前端，后台相关人员进行功能开发，测试编写测试用例。
3.前端与后台进行联调完毕后，测试进行冒烟测试，确保测试对象正常运行。
4.进行测试接口测试，仿真测试以及最终的线上测试，发现bug上传禅道通知相关人员确认并进行修改，修改后进行回归测试，妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便。
5.整体bug全部修改完毕，重新走完流程确保无遗漏，编写测试报告交付产品经理或者项目经理确认最终进行打包上线。
1.1.3 软件测试的作用：
1.通过测试工作可以发现并修复软件中存在的缺陷，从而使软件的寿命增长客户使用信心增强
2.测试可以记录软件在运行过程中产生的一些数据从而为决策提供数
3.测试可以降低同类产品开发遇到的风险
1.1.4 软件测试的原则：
1.测试证明软件是存在缺陷的
2.不能执行穷尽测试
3.缺陷存在群集现象（2：8原则 20%核心功能 ）
4.测试应提早介入（从定义需求的时候就有了测试）
5.某些测试需要依赖特殊环境（操作系统 浏览器 不同得到手机或者手机版本）
6.杀虫剂现象
7.不存在缺陷谬论（开发人员说自己的代码没问题的时候你怎么办？）
1.1.5 测试级别
1.单元测试(UT)
在软件测试中，单元就是组成软件的最小单位 （类 函数 组件）
2.集成测试（IT）
将多个不同的模块进行组合在一起进行验证 （接口是否ok ）
3.系统测试(ST)
测试人员充当用户对软件进行测试
系统测试分为：
1.功能测试 验证当前软件的主体功能是否ok
2.兼容性测试 验证当前软件在不同的环境下是否ok
3.安全测试 验证软件是否只有授权用户提供功能是使用
4.性能测试 验证软件是否消耗其他的资源
4.验收测试
软件发布之后由客户实现买单
验收测试分为：
1.α 测试 – 内测
Alpha测试是由用户在开发环境下进行的测试，也可以是开发机构内部的用户在模拟实际操作环境下进行的测试。
开发者坐在用户旁边，这是在开发者受控的环境下进行的测试。由开发者随时记录下错误情况和使用中的问题。
2.β 测试 – 公测
β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，
Beta测试不能由程序员或测试员完成。
当开发和测试根本完成时所做的测试，而最终的错误和问题需要在最终发行前找到。
这种测试一般由最终用户或其他人员员完成，不能由程序员或测试员完成。
该测试形式的优点：
· 测试由最终用户实施。
· 大量的潜在测试资源。
· 提高客户对参与人员的满意程度。
· 与正式或非正式验收测试相比，可以发现更多由于主观原因造成的缺陷。
缺点
· 未对所有功能和/或特性进行测试。
·测试流程难以评测。
· 最终用户可能沿用系统工作的方式，并可能没有发现或没有报告缺陷。
· 最终用户可能专注于比较新系统与遗留系统，而不是专注于查找缺陷。
· 用于验收测试的资源不受项目的控制，并且可能受到压缩。
· 可接受性标准是未知的。
· 您需要更多辅助性资源来管理 Beta测试员。
3.UAT测试 – 正式

1.1.6 按测试对象来进行分类：
盒 是测试的对象
1.白盒测试
软件的底层代码
2.黑盒测试
软件的主体功能
3.灰盒测试
介于黑盒和白盒之间（接口测试）
1.1.7 按测试对象是否执行分类：
1.静态测试
测试不执行 测试的可以有布局 页面
2.动态测试
将软件运行在真实的环境中进行测试
1.1.8 按测试手段分类：
1.手动测试
由测试人员对测试对象实现手动验证
优点： 可以灵活改变测试操作以及测试环境
2.自动化测试
1.脚本测试
2.借助第三方测试工具
1.1.9 软件的质量：(功能靠用 效率可移)
在当前行业中基于iso的一套标准用来定义软件的质量
特性：
1.功能性 满足客户在显示或者是隐式的需求
2.易用性 易学 容易上手
3.可靠性
4.效率性
5.可维护性
6.可移植性
测试用例
2.1.1 测试用例的定义
为了特定目的而设计的一组输入测试，执行条件，预期结果为了验证该功能是否满足需求。
2.1.2 如何编写测试用例
1.测试用例都是wps表来进行编写
2.测试用例中含有
(1)编号 该用例的编号
(2)日期
(3)测试人员
(4)项目
(5)分项目
(6)执行条件
(7)测试过程
(8)预期结果
(9)实际结果
在公司内测试人员需要大量的编写测试用例 一天至少30-50条测试用例的编写
测试用例的模板公司都不一致
2.1.3 bug的优先级
1. 致命缺陷
2.严重bug
3.一般bug
2.1.4 测试用例的设计方法
1.等价类划分
使用场景： 在有输入框使用等价类划分以及边界值法混合使用
按照需求将穷尽数据进行分类 区分去有效的数据和无效的数据
有效数据成为 有效等价类
无效数据成为 无效等级类
2.边界值
使用场景： 在有输入框使用等价类划分以及边界值法混合使用
有效边界值 1-100
无效边界值 -1 —负数的无穷尽
101–整数的无穷尽
3.因果法
应用场景： 一个界面有多个操作，多个操作之间有一定的组合关系或者是限制关系
输入不同的操作会产生不同的效果
4.场景法
应用场景： 在界面没有过多的填写项，所有的操作都是通过鼠标的单击双击
金融类 游戏类 硬件交互类
ATM取款机
取款失败的场景：
1.密码错误
2.账号余额不足
3.Atm中没有钱
4.吞卡
5.超限
6.无效的银行卡
7.非银行卡
5.判定表
6.正交
7. 随机法
使用场景： 列表数据中实现随机数据
在无穷中的数据中随机选择进行测试
测试强度
3.1.1 测试强度
测试强度在有需求文档或者api的时候可以根据需求文档测试
在没有测试文档或者是api的时候，可以根据个人经验是否测试
考虑的因素：
1.2个整数（正整数 负整数）
2.2个输入框是否为空
3.特殊符号
4.中英文字母/汉字
5.提醒框 / 输入框是否重置
Bug是指在代码中存在的
3.1.2 软件缺陷
定义： 缺陷就是软件的问题，最终表现为没有客户的需求
3.1.3 那些属于软件缺陷
1.软件没有达到规格说明书定义的功能
2.软件出现了规格说明书上指明不能存在的错误
3.软件功能超出了说明书上的范围
4.软件测试人员或者用户觉得不友好的
5.软件未达到说明书上应该具有的功能
3.1.4 软件缺陷的表现形式
1.功能上没有实现或者部分没有实现
2.设计不合理 功能不明确的 逻辑不清楚的 或者是逻辑本身就是存在矛盾
3.实际结果与预期结果不同
4.没有达到规格要求说明书上的要求性能指标
5.运行有错的 崩溃 中断 页面混乱
6.数据不正确 精度不够 不完整 或者是格式不统一
7.用户不能接受的问题。如果存取时间过长，页面不美观 小广告太多
8.硬件或者软件存在的其他问题
3.1.5 软件缺陷的状态（生命周期）
1.提交 – 测试人员提交发现的缺陷给开发
2.打开 – 将缺陷转一个待处理的状态
3.拒绝 – 开发者不认为这是一个缺陷
4.修复 – 开发者将缺陷进行修改
5.关闭 – 测试人将进行回归测试之后认为该缺陷已经解决后
6.推迟 – 将问题持续到下一个版本中在去解决 但是要记录详细的修复日期或者版本
（测试人员新提交的缺陷为 新建状态，在确认有效后将缺陷状态改为 打开状态，
开发人员修改后 已修复状态 测试人员需要进行回归测试，如果验证问题已解决 将状态改为 修复状态
如果经过回归测试验证缺陷依然存在 将缺陷的状态改为 打开状态 让开发再次修复。
如果开发人认为此缺陷需要延期修复 将缺陷的状态改为延期（推迟状态）
延期的时候有项目负责人 开发主管 测试主管确认 才可以延期 否则还是打开状态 ）
3.1.6 软件缺陷的严重程度进行划分
1.low – 表面性错误
2.Medium – 影响到一个对立的功能，仅仅发生在特定条件下 与需求定义的不台一直 断断续续的出现的问题
3.High – 功能点没有实现不符合客户的需求 导致丢失数据
4.Veryhigh – 频繁死机 大部分功能不能使用
5.Critical – 系统瘫痪 异常退出 死循环 严重计算失误
结局缺陷的优先级：
1.low --时间和资源允许情况下进行修复
2.Medium – 不会延迟发布
3.Highh – 必须在发布之前解决
4.Veryhigh --必须解决
5.Critical –
3.1.7 软件的缺陷的分类：
1.系统缺陷
2.数据缺陷
3.数据库缺陷
4.接口缺陷
5.功能缺陷
6.安全性缺陷
7.兼容行缺陷
8.性能缺陷
9.界面缺陷
3.1.8 缺陷报告
1.7.1 书写规范：
1.标题简洁 提供缺陷的本质信息即可
2. 复现的步骤要详细 可以用数字编号（测试用例的编号）
3.实际结果要描述浮现后的结果
4. 列出期望结果（在测试用例中存在期望结果可以不写）
5.提供条件（可以在测试用例）
6.提供严谨的测试报告给开发人员