等价类划分法
是把程序的输入域划分成若干个子集合(等价类)，然后从每个子集合(等价类)中选取少数具有代表性的数据作为测试的输入数据。
在该子集合中，所有的输入数据对于揭露软件中的错误都是等效的。-----减少测试用例数量，提高效率
等价类划分有效等价类(正面，不会报错) 和 无效等价类(负面，抛出错误)。检查错误信息是否正确，是否能够正确指引用户。
等价类划分法用例设计步骤和原则
1) 分析需求，先确定其有效等价类，和无效等价类；
2) 在确立了等价类之后，建立等价类表，列出所有划分出的等价类；
3) 再从划分出的等价类中选择测试用例。
- 设计一个新的测试用例数据，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止；-------减少测试用例的数量，避免重复，提高效率
- 设计一个新的测试用例数据，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止；--------为了确定是哪个因素触发错误，每一种错误都被正确处理。
等价类划分法的应用场景：当测试需要数据量过大，且数据操作可以分类时进行等价类划分。
例子：微信红包，金额区间：[0.01，200]------------设计测试用例
分析：有效等价类：1) [0.01，200] 4)数字 6)小数点后不超过两位
无效等价类：2) >200 3)<0.01 5)非数字(中文、字母、字符) 7)超过两位小数 8)空值 9)负数
边界值分析法--等价类划分法一起使用
定义：边界值分析法是对等价类划分法的一个补充，边界值一般都是从等价类的边缘值去寻找。（跟范围相关的才需要边界值）
原则和步骤：确定边界：应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据-----范围相关
有效等价类的边界 无效等价类的边界
边界值选取方法：
1、两点法：两边边界值
2、三点法：两边边界值+中间值
3、四点法：两边边界值+刚好大于最小值+刚好小于最大值
注意：次边界值：IP地址(0~255)，时间格式(0~23)，2的幂值(256,1024,65535)--------需求没有明说，常识
特殊边界值：0是一个特殊值，负数，空值，空格等。
边界值的作用：人们从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围内部。因此针对各种边界情况设计测试用例，可以查出更多的错误！---------提出更多bug
边界值的应用场景：如果需求规定了取值范围或规定了取值的个数时，可利用边界值进行测试
场景法
通过场景描述的业务流程(业务逻辑)，也包括代码实现逻辑，设计用例来遍历场景(路径)，验证软件系统功能的正确性。（流程图）
如何使用场景法
1、画流程图-----产品需求文档---画好了；------需要测试自己画
矩形：表示步骤（操作、输入、输出结果）
菱形：判断条件------是、否
箭头：流向
2、遍历场景，提取测试用例
- 覆盖正常的路径（冒烟）-------取到钱的路径
- 走每一个分支
- 出错步骤重新回到主流程，建议多走一步正确的步骤-------注意：
场景法举例：
场景一：插入合法银行卡，输入正确的密码，输入正确且充足的金额，ATM足够----取到钱
场景二：插入不合法的卡，退卡提示错误；
场景三：插入合法银行卡，输入密码之后取消-----退卡
场景四：插入合法银行卡，输入错误的密码后不取消，不超过3次-----提示密码错误，重新输入密码
场景五：插入合法银行卡，输入错误的密码后不取消，出错3次-----吞卡
场景六：插入合法银行卡，输入正确的密码后不取消，输入不合法金额-----提示错误，重新输入
场景七：插入合法银行卡，输入正确的密码后不取消，输入合法金额，账户余额不足-----提示错误，重新输入
场景八：插入合法银行卡，输入正确的密码后不取消，输入合法金额，账户余额充足，ATM不足余额-----提示错误，重新输入
错误推测法(反推法)
基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。
它的要素共有三点：经验、知识、直觉。
考虑程序可能触发错误场景----不能正常运行
不单独使用----可以作为其他方法的补充！
案例：某平台登录页面
错误猜测法，首先列出可能导致结果出错的情况(登录失败)。
1、账号密码错误
2、验证(图片、短信)
3、网络问题
4、浏览器兼容性
5、性能弱(并发大量用户)
6、账号黑名单----举报
7、登录失败错误次数----冻结账号
8、服务器异常----无响应
9、第三方登录问题
10、单点登录-----只允许同时在一台设备登录
bug 的定义
软件的Bug，狭义概念是指软件程序的漏洞或缺陷
广义概念除此之外还包括测试工程师或用户所发现和提出的软件可改进的细节(增强性、建议性)、或与需求文档存在差异的功能实现等。
bug的类型------了解
要确定一个bug的类型，需要对项目（或产品）有比较深的理解。这个划分对于开发定位问题影响很小，但对于问题类型的统计比较重要。-----------测试报告
常见的bug类型划分（禅道系统为例，可自定义）：
代码(功能)错误----最常见；优先级偏高
界面优化----UI测试；优先级偏低
设计缺陷----优化建议；需求上就不合理；优先级偏低
按照公司具体规定进行分类。
bug的等级----优先级
1)致命错误---------blocker
- 常规操作引起的系统崩溃、死机、死循环、闪退
- 造成数据泄露的安全性问题，比如恶意攻击造成的账户私密信息泄露
- 涉及金钱计算----公司巨大损失、业务
- 阻断性测试，所有测试工作进行不下去（冒烟测试）-----登录
- 权限问题------爱奇艺资源会员
2)严重错误--------critical
- 重要功能不能实现（聊天没有聊天记录功能）
- 错误的涉及面广，影响到其它重要功能正常实现-------12306购票系统，咨询功能影响购票
- 非常规操作导致的程序崩溃、死机、死循环、闪退
- 外观(界面)难以接受的缺陷
- 密码明文显示；前端处理bug 后端----服务器(数据库验证)--------安全范畴（可能前端隐藏了密码，但是通过抓包工具，看得到明文密码，则是后端bug）
- 偶现的致命性bug
3)一般错误-------major(遇到最多)
不影响产品的运行、不会成为故障起因，但对产品外观和下道工序影响较大的缺陷
- 次要功能不能正常实现
- 操作界面错误(包括数据窗口内列名定义、含义不一致)
- 查询错误、数据错误显示
- 简单的输入限制未放在前端进行控制
- 删除操作未给出提示-------友好型
- 偶现的严重性bug
4)细微错误-----minor（一般不开这种bug）
程序上一些显示上不美观，不符合用户习惯，或者是一些文字的错误----用户体验
- 界面不规范
- 辅助说明描述不清楚
- 提示窗口文字未采用行业术语
- 界面存在文字错误
5)改进建议---------enhancement-------------新需求下一个版本
可以提高产品质量的建议，包括新需求和对需求的改进。
bug 的生命周期(管理流程)-----------重点！！！
bug 的生命周期，就是一个bug被发现到这个bug被关闭的过程。
生命周期中一般缺陷状态：发现---新建(提)
发现bug----确认bug：防止环境问题，操作问题等外因---无效bug（提现专业性）
new新建-----(提bug者，测试老大)指派(开发，开发老大)-----跟进(3天，push推进开发修改)
重复bug(duplicated)：要求开发备注一下重复bug的号(ID)，测试确认---是---加备注，关闭；否---重新激活(repened)----指派开发
不是缺陷(invalid)：by-design (设计如此)，操作失误，需求的理解不一致------争论：1、分析需求，从用户角度出发找到证据---尝试说服开发。2、产品(项目经理)---拍板---是bug---开发修复；不是---测试不纠结，留好证据(邮件截图，备注bug)
无法复现(un-reproduced)：1、开发复现：确认一下测试环境再复现出来---可以帮助开发复现，测试环境调试定位。2)测试和开发环境都无法复现：尝试跟踪3-5个版本(10次+)-----加备注(复现次数，跟踪版本数)----关闭------记录到小本本，研究
不予解决(wontfix)：bug级别低(UI,enhancement bug)：1)说服开发 2)产品确认------备注留证据，关闭
延期(delayed)：1)建议性(feature/enhancement)----下一个版本需求；2)上线之前，影响比较大(性价比)------分析：1)分析这个bug用户影响大小，建议开发修复；2)严重级别-----产品、项目经理最后确认--------不修复，备注(留证据)----不关闭，挂起
已修复(resolved-fixed)：测试验证(bug步骤，结果检查)-----1)verified(已验证)----closed(关闭) 2)仍然存在：reopened(重新激活)
bug的跟踪管理----缺陷管理工具
禅道(zentao)，bugzilla、jira、bugfree、readmine.....
bug的跟踪管理----如何提交bug
bug标题：bug的功能模块+bug的操作+bug的结果
重现步骤：详细写下发现bug的测试过程。能指导开发重新这个bug。附上测试数据
实际结果：粘贴bug截图、日志截图-----直观，证据(有图有真相)
预期结果：写清楚预期结果-----来自测试用例的预期结果
bug类型和严重程度：便于后续测试结果分析，bug的统计
bug测试环境：例如：什么系统，哪个版本等。兼容性问题、难以重现问题
附件：日志文件、文件测试数据。图片、崩溃日志文件等