1.1测试强度
测试强度在有需求文档或者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. 没有达到规格要求说明书上的要求性能指标
[if !supportLists]5. [endif]运行有错的崩溃中断页面混乱
[if !supportLists]6. [endif]数据不正确精度不够不完整或者是格式不统一
[if !supportLists]7. [endif]用户不能接受的问题。如果存取时间过长，页面不美观小广告太多
[if !supportLists]8. [endif]硬件或者软件存在的其他问题
1.5软件缺陷的状态（生命周期）
[if !supportLists]1. [endif]提交--测试人员提交发现的缺陷给开发
[if !supportLists]2. [endif]打开--将缺陷转一个待处理的状态
[if !supportLists]3. [endif]拒绝--开发者不认为这是一个缺陷
[if !supportLists]4. [endif]修复--开发者将缺陷进行修改
[if !supportLists]5. [endif]关闭--测试人将进行回归测试之后认为该缺陷已经解决后
[if !supportLists]6. [endif]推迟--将问题持续到下一个版本中在去解决 但是要记录详细的修复日期或者版本
测试人员新提交的缺陷为新建状态，在确认有效后将缺陷状态改为打开状态，
开发人员修改后已修复状态测试人员需要进行回归测试，如果验证问题已解决将状态改为修复状态如果经过回归测试验证缺陷依然存在将缺陷的状态改为打开状态让开发再次修复。如果开发人认为此缺陷需要延期修复将缺陷的状态改为延期（推迟状态）
延期的时候有项目负责人开发主管测试主管确认才可以延期否则还是打开状态
1.6软件缺陷的严重程度进行划分
[if !supportLists]1. [endif]low --表面性错误
[if !supportLists]2. [endif]Medium --影响到一个对立的功能，仅仅发生在特定条件下 与需求定义的不台一直 断断续续的出现的问题
[if !supportLists]3. [endif]High --功能点没有实现不符合客户的需求 导致丢失数据
[if !supportLists]4. [endif]Veryhigh --频繁死机 大部分功能不能使用
[if !supportLists]5. [endif]Critical --系统瘫痪 异常退出 死循环 严重计算失误
结局缺陷的优先级
[if !supportLists]1. [endif]low --时间和资源允许情况下进行修复
[if !supportLists]2. [endif]Medium --不会延迟发布
[if !supportLists]3. [endif]Highh --必须在发布之前解决
[if !supportLists]4. [endif]Veryhigh --必须解决
[if !supportLists]5. [endif]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
