需求分析、测试方法、测试用例表格设计、测试用例编写评审、测试用例管理
前置知识点：
软件相关概念
数据、程序、文档的结合。操作数据，测试的主体是程序，文档是工作时的可视化，测试用例是文档的一部分
软件测试基础
以满足需求为目的，保证软件质量的手段
测试流程
需求分析、计划制定、用例的编写与执行、对测试结果的分析报告
测试生命周期
测试计划、测试设计、测试开发、测试执行、测试评估
测试常用术语
按照软件测试手段划分：
- 黑盒：把软件比作一个黑色盒子，不知道内部结构，通过外部暴露出来的接口和功能测试；
- 灰盒：把软件比作一个半透明盒子，可以看到内部少部分信息，通过外面暴露的功能和盒子内部的数据进行对比得出测试结论；
- 白盒：把软件比作一个透明盒子，通过观察内部结构，直接推测出软件是否满足用户需求；（难度最高）
专项测试方向：
- 功能：验证软件是否满足用户提出的表面需求；
- 性能：测试软件的工作效率；
- 安全：测试软件是否能够保护用户的信息不被盗取；
测试的测试点划分：
- 兼容性：测试软件在不同平台上的表现；
- 易用性：测试软件是否友好，满足用户的使用习惯；
- UI元素：检测软件的界面的布局显示是否一致、美观等；
测试用例介绍
测试用例是什么（测试时使用的重要文档）
测试工作的核心
一组在测试时输入输出的标准
软件需求的具体对照
测试用例的作用
检验软件是否满足客户需求
体现一个测试人员的工作量
展现测试用例的设计思路
测试用例包含哪些内容
- 用例编号：唯一识别号码，通过下划线连接+其他信息添加详细描述，例如一个登陆模块，可以用login_001的形式
- 用例名称：言简意赅，用最少的文字描述准确
- 测试背景：说明该用例是什么样的用例，属于哪个项目，测试什么内容
- 前置条件：在执行这条测试之前要满足什么条件，比如测试登录功能，需要的前置条件是账号密码是已经注册的
- 优先级：优先级和重要级不一定成正比
- 重要级：
- 测试数据：比如登录功能，账号密码即为测试数据，有些测试用例不需要用键盘输入值，但也有测试数据，鼠标的操作也是一组测试数据
- 测试步骤：测试时应该按照测试步骤的描述第一步第二步第三步依次执行
- 预期结果：每一步操作对应的现象，例如登陆模块，输入账号密码点击登陆，预期结果为登录成功
- 实际结果：执行测试时出现的实际情况，可能和预期结果一致或者不一致
- 备注：描述一下特殊信息
- 其他信息：根据实际情况编写；
测试用例编写流程
需求分析、提取测试点、测试用例编写、测试用例评审
注：（问答）优先级是事件的优先顺序，重要级是事件的轻重缓急；
一份测试用例本应该是不包含实际结果的，只有预期结果，因为实际结果是在执行用例之后才产生的，但是，此时的测试用例可以说是不完整的，测试人员只有将测试实际结果数据填充到每条用例后面，与预期结果进行对比，才知道这条用例是否通过，所以说一份完整的测试用例里面应该需要包含测试实际结果 就好比医院的化验单，必须得知道化验结果中各个指标当前情况（实际结果），以及正常值范围（预期结果）是多少，这时候医生才能诊断你的病情，从而得出结论
准确的说在测试设计阶段，做成测试用例本身是不需要实际结果。但是把测试用例文档化，做成测试用例表，就应该要加入实际结果这一项。目的是为了跟踪测试结果
需求分析与测试点编写
需求分析
- 业务需求：关注系统是否满足业务
- 用户需求：关注系统是否满足用户习惯
- 功能需求：关注系统是否满足功能需求
没有需求怎么办
参考市面上已经上线的同类产品需求模糊怎么办
- 收集整理已有需求
- 和产品经理逐条确认
- 参考同类型产品的实现情况
提取测试点
什么是测试点
测试点即通过需求分析后对得出的需要进行测试的具体内容测试点对测试用例的设计好处
快速、覆盖、 方法、细节
功能模块、测试点编号、测试点描述注：（问答）
一条正规测试用例包括哪些内容
2） 软件或项目的版本（内部版本号）
3） 功能模块名
4） 测试用例的简单描述，即该用例执行的目的或方法
5） 测试用例的参考信息（便于跟踪和参考）
6） 本测试用例与其他测试用例间的依赖关系
7） 本用例的前置条件，即执行本用例必须要满足的条件，如对数据库的访问权限
8） 用例的编号（ID），如可以是 软件名称简写-功能块简写-NO.。
9） 步骤号、操作步骤描述、测试数据描述
10）预期结果（这是最重要的）和实际结果（如果有BUG管理工具，这条可以省略）
11）开发人员（必须有）和测试人员（可有可无）
12）测试执行日期
测试用例编写方法
注意事项
1.根据项目的实际情况设计测试用例表格
2.用例的表格不是固定的，不要生搬硬套
3.根据具体的情况编写
测试用例编写方法（常用设计方法）
等价类划分法：黑盒测试方法
因为测试是无穷尽的，所以需要用等价类划分法选出最具有代表性的数据进行测试
如何选择适当的数据子集，来代表整个测试集
通过降低测试的数目去实现“合理的”覆盖，覆盖了更多的可能性数据，以发现更多的软件缺陷
将程序所有可能的输入数据划分成若干等价类，然后从每个部分中选取最具有代表性的数据当作测试用例进行合理的分类，测试用例由有效等价类和无效等价类组成 测试用例具有完整性和代表性
有效等价类：对于程序规格说明来说，合理的，有意义的输入数据构成的集合，可以检验程序是否符合规格说明预先规定的功能和性能，可以是一个或多个，根据系统的输入划分成若干个部分，然后从每个部分中选取少数有代表性的数据当作数据测试的测试用例，等价类是输入域的集合，符合规范的数据集合
无效等价类：不合理的，没有意义的输入数据集合，通过无效等价类可以检验程序异常的情况，是否不符合规范要求等
边界值分析法：黑盒测试方法
对输入或输出的边界值进行测试的黑盒测试方法，对等价类测试法的一种补充，可以用于快速选出等价类
使用边界值分析法设计测试用例时一般与等价类划分法结合起来但它不是从一个等价类中任意选一个例子作为代表，而是将测试边界情况作为重点目标，选取正好等于、刚刚大于或刚刚小于边界值的测试数据
场景法：
分析用户在使用软件时都会遇到哪些场景
通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果。场景法一般包含基本流和备用流，从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。
猜测法：直觉90%-〉猜测50%，经验90%-〉结果80%。需要依靠测试经验猜测哪些地方容易出现问题，依靠经验分析哪些场景容易被开发忽略从而快速得到测试结果
测试用例评审（所有的文档需求变动 都会进行评审）
- 简单来讲，评审就是对测试用例进行检查
- 评审包括同行评审，小组评审，部门评审，三方评审等
- 不同的评审类型会有不同的角色参与
评审的意义在哪里
1.通过评审可以发现测试用例的不足
2.方便测试人员改进用例
3.达到在测试时提高测试质量的目的评审的流程
改进测试用例-〉评审-〉改进测试用例-〉评审 评审的过程不是一次性的，是一个持续改进的过程。
测试用例管理
为什么要管理用例？
1.测试用例数量巨大
2.测试用例会随着需求变更
3.测试用例需要补充完善
如何管理用例？
1.原始的Excel管理方式 （整理起来比较不方便，只能应用于比较少量的测试用例上）
2.专业的项目管理系统（可以跟踪变更，每一次的执行情况都可以记录，可以对测试出来的bug进行关联）
如何选择管理测试用例的工具
| 管理工具 | 成本 | 可扩展性 | 易用性 | 功能 | |
|---|---|---|---|---|---|
| ALM | 5 | 5 | 4 | 5 | （惠普的一个管理系统，商业版，成本高） |
| 禅道 | 3 | 3 | 3 | 3 | （有免费版和商业版） |
| testlink | 1 | 4 | 2 | 3 | （开源） |
| Bugzilla | 1 | 4 | 2 | 3 | |
| JIRA | 4 | 3 | 2 | 3 |
禅道基本应用
1.专业的研发项目管理软件
2.完整支持敏捷开发流程
3.完整软件生命周期管理
根据慕课网课程：如何写好测试用例 整理。