测测理论

day01:
一：首先软件测试的基本流程：

1.将所有的经理根据客户需求来编写
2.开发根据需求文档来编写代码
测试需要根据需求文档 编写测试计划
3.开发人员实现代码
测试人员编写测试用例
4.编码结束之后由开发人员将代码上传 测试人员需要将代码下载并实现冒烟测试 冒烟测试通过后在实现全面测试（如果发现bug 需要将bug提交给开发人员 开发解决问题之后测试人员需要进行回归测试）
4. 测试人员需要将测试报告以及测试用例整理文档方便项目版本迭代的使用

测试用例的内容点：功能测试（当前所有的功能点通过性测试），界面易用性（是否符合需求），中断测试（APP切换，断网断电，来电信息），性能测试（客户端：耗电量，运行内存，服务器：响应时间，压力测试），安全测试（授权，代码是否会被获取，是否做混淆或者加密），兼容性（不同版本，浏览器，机型），网络（wifi，热点，4G，无网，不同运营网络测试，弱网（延时，丢包））

二：软件测试的基本原则：

1.测试软件存在缺陷。证明测试对象是有缺陷的。

2.测试尽早介入，缺陷发现越早，修复成本越小。

3.不可进行穷尽测试（无意义测试）。

4.缺陷集群性（2/8原则）80%的缺陷发现在20%的模块中。

5.杀虫剂悖论，如果一直使用相同的测试方法或手段，可能无法发现新的bug。

6.测试环境的特殊新，测试活动依赖测试内容，不同的行业，测试活动的开展都有所不同，比如测试技术、测试工具的选择，测试流程都不尽相同，所以软件测试的活动开展依赖于所测试的内容

7.不存在缺陷谬论，软件测试不仅是找出缺陷，同时也需要确认软件是否满足需求。

三：测试级别（按开发阶段）：

1.单元测试(Unit Testing)：针对被测的最小组成单元实施的测试（类，函数，功能模块）

2.集成测试(Integration Testing)：组件间，单元与组件间，单元之间的接口测试，验证接口是否符合设计，接口是否调通。

3.系统测试(System Testing)：充当用户对软件进行测试。

4.验收测试(Acceptance Testing)：线下测试，uat仿真测试，线上真实测试。α测试 = 内测 β测试 = 公测 UAT测试 = 正式版

四：测试分类：

1.功能测试（严重当前功能是否正常运行）（白，黑，灰测试）

2.兼容性测试（验证软件在不同情况下的表现）

3.安全测试（验证安装在系统内的保护机制在实际应用中不被入侵不受因素影响，在发布之前找到问题并解决降低成本）

4.性能测试（通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试）

5.按测试对象分类：
1.白盒：软件内部，底层代码
2.黑盒：软件的主体功能
3.灰盒：既兼顾黑盒又要兼容白盒，（接口测试）
1: 黑盒测试: 定义: 实际使用
(1): 黑盒测试
定义: 基本上就是对功能点进行测试,通过编写测试用例,通过测试用例来覆盖功能点,一般只注重表面现象,对内部业务逻辑不做了解
主要测试: 1: UI效果图实现没有
2: 功能点实现没有
3: 业务逻辑实现没有
(2): 灰盒测试
定义: 介于白盒测试和黑盒测试之间:
灰盒测试不像白盒那样详细、完整，但又比黑盒测试更关注程序的内部逻辑，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。
比如测试登陆: 黑盒测试只需要测试用例覆盖完成没问题,但是灰盒测试我们的通过Charles 功能进行抓包,看提交的数据有没有问题,用户名正确不正确,密码有没有加密,如果加密了,说明开发调用加密的方法了,看看返回的数据正确不正确,除了要测试返回成功状态,还要测试其余通过,通过以后Charles返回数据
(3): 白盒测试
盒测试又俗称结构测试,透明盒测试、逻辑驱动测试或基于代码的测试。

6.测试对象是否执行：
1.静态测试：测试不执行（布局，页面）
2.动态：将软件运行在真实的环境中测试

7测试手段：
1.手动测试;由测试进行手动验证
2.自动化测试：（脚本测试）、（第三方测试工具）

8.软件质量：（功能靠用，效率可移）
1.功能性（满足显示或者隐式需求）、易用性（易学）、可靠性、效率性、可维护性（）、可移植性（在不同平台上使用）

day02：
编写测试用例：

用例编号 九悦-首页-定位
日期
测试人
测试目的 定位
执行条件
测试过程
预期结果
实际结果
bug 等级 致命 严重 一般 低级
1
2
3
4
5
6
7
8
9
1.4测试用例的设计方法
1.等价类划分
使用场景： 在有输入框使用等价类划分以及边界值法混合使用
按照需求将穷尽数据进行分类 区分去有效的数据和无效的数据
有效数据成为 有效等价类

无效数据成为 无效等级类

2.边界值
使用场景： 在有输入框使用等价类划分以及边界值法混合使用
有效边界值 1-100
无效边界值 -1 —负数的无穷尽
101–整数的无穷尽
3.因果法
应用场景：
一个界面有多个操作，多个操作之间有一定的组合关系或者是限制关系
输入不同的操作会产生不同的效果

4.场景法
应用场景：
在界面没有过多的填写项，所有的操作都是通过鼠标的单击双击
金融类 游戏类 硬件交互类

ATM取款机
取款失败的场景：
1.密码错误
2.账号余额不足
3.Atm中没有钱
4.吞卡
5.超限
6.无效的银行卡
7.非银行卡
5.判定表
6.正交
7. 随机法
使用场景： 列表数据中实现随机数据
在无穷中的数据中随机选择进行测试

day03：

测试强度
测试强度在有需求文档或者api的时候可以根据需求文档测试
在没有测试文档或者是api的时候，可以根据个人经验是否测试

考虑的因素：
1.2个整数（正整数 负整数）
2.2个输入框是否为空
3.特殊符号
4.中英文字母/汉字
5.提醒框 / 输入框是否重置

Bug是指在代码中存在的

1.2软件缺陷
定义： 缺陷就是软件的问题，最终表现为没有客户的需求

1.3哪些属于软件缺陷
1.软件没有达到规格说明书定义的功能
2.软件出现了规格说明书上指明不能存在的错误
3.软件功能超出了说明书上的范围
4.软件测试人员或者用户觉得不友好的
5.软件未达到说明书上应该具有的功能

1.4软件缺陷的表现形式
1.功能上没有实现或者部分没有实现
2.设计不合理 功能不明确的 逻辑不清楚的 或者是逻辑本身就是存在矛盾
3.实际结果与预期结果不同
4.没有达到规格要求说明书上的要求性能指标
5.运行有错的 崩溃 中断 页面混乱
6.数据不正确 精度不够 不完整 或者是格式不统一
7.用户不能接受的问题。如果存取时间过长，页面不美观 小广告太多
8.硬件或者软件存在的其他问题

1.5软件缺陷的状态（生命周期）
1.提交 – 测试人员提交发现的缺陷给开发
2.打开 – 将缺陷转一个待处理的状态
3.拒绝 – 开发者不认为这是一个缺陷
4.修复 – 开发者将缺陷进行修改
5.关闭 – 测试人将进行回归测试之后认为该缺陷已经解决后
6.推迟 – 将问题持续到下一个版本中在去解决 但是要记录详细的修复日期或者版本

测试人员新提交的缺陷为 新建状态，在确认有效后将缺陷状态改为 打开状态，
开发人员修改后 已修复状态 测试人员需要进行回归测试，如果验证问题已解决 将状态改为 修复状态 如果经过回归测试验证缺陷依然存在 将缺陷的状态改为 打开状态 让开发再次修复。如果开发人认为此缺陷需要延期修复 将缺陷的状态改为延期（推迟状态）
延期的时候有项目负责人 开发主管 测试主管确认 才可以延期 否则还是打开状态

1.6软件缺陷的严重程度进行划分
1.low – 表面性错误
2.Medium – 影响到一个对立的功能，仅仅发生在特定条件下 与需求定义的不台一直 断断续续的出现的问题
3.High – 功能点没有实现不符合客户的需求 导致丢失数据
4.Veryhigh – 频繁死机 大部分功能不能使用
5.Critical – 系统瘫痪 异常退出 死循环 严重计算失误

结局缺陷的优先级

1.low --时间和资源允许情况下进行修复
2.Medium – 不会延迟发布
3.Highh – 必须在发布之前解决
4.Veryhigh --必须解决
5.Critical –

1.7 软件的缺陷的分类：
1.系统缺陷
2.数据缺陷
3.数据库缺陷
4.接口缺陷
5.功能缺陷
6.安全性缺陷
7.兼容行缺陷
8.性能缺陷
9.界面缺陷

17缺陷报告
1.7.1 书写规范：
1.标题简洁 提供缺陷的本质信息即可
2. 复现的步骤要详细 可以用数字编号（测试用例的编号）
3.实际结果要描述浮现后的结果
4. 列出期望结果（在测试用例中存在期望结果可以不写）
5.提供条件（可以在测试用例）
6.提供严谨的测试报告给开发人员

缺陷报告的使用以及测试用例的案列
https://blog.csdn.net/weixin_41948075/article/details/89287926