[TOC]
基础学习
穷举场景
重点：有效等价和单个无效等价各取一个即可
步骤：
1.明确需求
2.确定有效和无效等价
3.根据有效和无效造数据编写用例
1.正向用例：一条尽可能覆盖多条
2.逆向用例：每一条数据，都是一条单独用例针对：需要有大量数据测试输入，但是没法穷举测试的地方
输入框
下拉列表
单选复选框
典型代表：页面的输入框类测试。- 完整的用例应该是等价类和边界值一块写
边界值分析法
- 选取正好等于，刚好大于，刚好小于边界的值作为测试数据
- 上点：边界上的点(正好等于)
- 离点：距离上点最近的点(刚好大于，刚好小于)
- 内点：范围内的点（区间范围内的数据）
- 重点：开内闭外（开区间选包含的点，必区选不包含的点）
判断表法
提示：
1.多条件之间有依赖关系，使用判定表来进行测试覆盖
2.判定表一般适合4个以内的条件依赖关系
3.如果条件超过四个，就不适合覆盖所有条件，应采用（正交法）来解决错误推荐法
开发模型
瀑布模型
线性顺序进行的软件开发模式
优点
- 强调开发的阶段性；强调早期计划及需求调查；强调产品测试
缺点
- 依赖于早期进行的唯一一次需求调查，不能适应需求的变化
- 由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程
- 风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会
螺旋模型
渐进式开发模型
优点：强调严格的全过程风险管理，强调各开发阶段的质量，提供机会检讨项目是否有价值继续下去
缺点：引入非常严格的风险识别，风险分析喝风险控制，这对风险管理的技能水平提出了很高的要求，需要人员，资金，和时间的投入
增量迭代模型
增量开发能显著降低项目风险，结合软件持续构建机制，构成了当今流行的软件工程最佳实践之一。增量开发模型，鼓励用户反馈，在每个迭代过程中，促使开发小组以一种循环的、可预测的方式驱动产品的开发。因此，在这种开发模式下，每一次的迭代都意味着可能有需求的更改、构建出新的可执行软件版本，意味着测试需要频繁进行，测试人员需要与开发人员更加紧密地协作。
增量通常和迭代混为一谈，但是其实两者是有区别的。增量是逐块建造的概念，例如画一幅人物画，我们可以先画人的头部，再画身体，再画手脚……而迭代是反复求精的概念，同样是画人物画，我们可以采用先画整体轮廓，再勾勒出基本雏形，再细化、着色。
敏捷模型
敏捷开发有很多种方式，其中scrum是比较流行的一种。
scrum里面的角色：scrum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成
- 其中product owner负责整理user story(用户故事)，定义其商业价值，对其进行排序，制定发布计划，对产品负责。
- scrum master 负责召开各种会议，协调项目，为研发团队服务。
- 研发团队则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。
scrum的流程：
- 发布会议：产品经理将会告诉我们我们有哪些需求，制定我们的需求列表。
- 迭代计划会议：把需求一一的列举出来，分解出所有的需求并且将这些需求分给开发人员，划分负责人，初步工时。
- 每日例会：报告一下我们每个负责人所负责的需求都做到哪了，并且这个过程遇到了哪些问题。
- 演示会议：经过一段时间的开发，我们的需求已经全部都做完了，然后我们的负责人需要给用户进行演示这个软件到底该怎么去使用，在这个过程中我们的用户可以提出修改，或者添加需求然后我们再次经历前面一轮。
- 回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改进的效果。
测试模型
软件测试V模型
用户需求——需求分析——概要设计——详细设计——编码——单元测试——集成测试——系统测试——验收测试
优点：明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试和开发过程期间个阶段的对应关系
缺点：仅仅把测试作为再编码之后的一个阶段，未在需求阶段就进入测试，导致发现问题的时间较晚
软件测试W模型
软件测试的生命周期
需求分析——测试计划——测试设计，测试开发——测试执行——测试评估
- 需求分析：阅读需求，理解需求，分析需求点，参与需求评审会议
- 测试计划：主要任务就是编写测试计划，参考软件需求规格说明书，项目总体计划，内容包括测试范围，进度安排，人力物力分配，整体测试策略的制定
- 设计测试：适当的了解设计，搭建测试用例框架，根据需求的设计编写测试用例
- 测试执行：搭建环境准备数据，执行冒烟测试（预测试）然后进入正式测试（系统测试，回归测试，交叉测试，自由测试），bug管理直到测试结束。
- 测试评估: 输出测试报告，确认是否可以上线。
如何描述一个BUG
- 发现问题的版本：开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障。并且版本的标识也有利于统计和分析每个版本的质量。
- 问题出现的环境：环境氛围硬件环境和软件环境，如果是web项目，需要描述浏览器版本，客户机操作系统等，如果是app项目，需要描述机型，分辨率，操作系统版本等。详细的环境描述有利于故障的定位
- 错误重现的步骤：描述问题重现的最短步骤
- 预取行为的描述：要让开发人员知道怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎么样的。如果是依据需求提出的故障，能写明需求的来源是最好的
- 错误行为的描述：描述错误的现象。crash等可以上传log，UI问题可以有截图。
定义BUG的级别
bug的定义每个公司都不一致，一般分为四个等级：
- 崩溃：阻碍开发或测试工作的问题；造成系统崩溃，死机，死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误，死循环，数据库发生死锁，重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦竖线立即中止当前版本测试）
- 严重：系统主要功能部分丧失，数据库保存调用错误，用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试，功能设计与需求严重不符，
测试案例练习
Guduyili
The persistence of an ordinary person