如何设计测试用例
测试设计开展流程
- 需求文档学习、输出问题确认列表、问题确认与汇总；
- 需求文档评审、开发讲解，测试提问、输出评审结论，归档；
- 制定测试设计计划、制定设计任务分配表；
- 启动设计输出思维导图、思维导图评审，汇总意见、输出修改后的思维导图；
- 评审启动后启动设计、输出测试用例初稿、启动测试用例评审、汇总评审意见、启动更新、第一次更新完成，再评审、汇总形成测试用例、归档，设计完成。
如何多方面考虑测试一个系统
用例设计原则：
- 按照测试类型分析法，按功能、压力、稳定性、性能、安全性、兼容性进行测试类型划分；
- 针对场景分析法，进行基于流程的功能遍历；
- 针对单个点，进行边界值，等价类相关测试点的考虑；
- 考虑流程中的异常操作；
- 考虑环境中可能出现的异常情况，如断开电源，断开网络，网络带宽被占用；
- 考虑其他设备对软件的影响；
- 考虑压力的积累，功能使用的稳定性；
- 考虑性能；
- 考虑存储空间即将满，已经满的情况下的数据处理；
- 考虑安装、卸载、升级、反复安装等实际使用场景中遇到的情况。
存在关联业务的测试点的考虑：
重点关注在当前业务走通的情况下，对其他相关联页面的影响，主要考虑如下几个方面：
- 当前业务正常走通，其他相关模块是否能正常显示对应数据；
- 当前业务执行过程中出现异常情况，对自身及其他模块数据的影响是否正常；
- 考虑积累作用：长时间，重复操作本模块，是否对其他模块的数据处理造成影响，相关模块数据处理是否正常；
- 几个模块共同作用，都发生数据变更，查看彼此间的影响是否正常，数据处理是否正确。
常用测试设计方法：
- 整体把握 【测试类型分析法】
- 单个功能点【测试类型分析法】【测试场景分析法】【模块关联】【等价类边界值分析法】
- 单个界面【测试类型分析法】【模块关联】【表间关联】【等价类边界值分析法】【不同出入口遍历】
- 单个输入框、选择框等【表间关联】【等价类边界值分析法】
测试类型分析法：将一个功能点按照不同的测试类型进行划分，针对每一个测试类型都进行测试点设计的分析方法。
举例说明：功能测试、性能测试、压力测试、可靠性测试、兼容性测试、安全性测试、容错测试；
功能测试常规测试点：
- 正常流程测试
基本流程测试
单个输入框测试【边界值、等价类划分】
多个关联输入框测试
关联表测试
实际使用场景测试
关联模块功能验证
- 异常流程_外部环境异常测试
异常测试_使用过程中断开网络连接
异常测试_使用过程中断开电源重启
异常测试_使用过程中断开启占用资源的进程
异常测试_使用过程中杀死后台管理系统进程
内存占用高的情况下的功能验证
磁盘空间满的情况下的功能验证
- 异常流程_内部逻辑异常测试
填写不符合规范的数据，查看是否能正常处理
不符合关联模块的业务逻辑的操作，查看是否能正常处理
超出使用期限的日期，查看其它功能是否能正常使用
重复操作同一个步骤对系统的影响验证
- 外设影响测试：满配、容量满的情况下的功能验证
性能测试&压力测试&稳定性测试
- 长时间重复某一个功能，查看功能是否使用正常
- 不同时间间隔内进行某一个功能的测试，查看响应时间是否正常
- 在存储空间满，接近满的情况下，查看功能模块的处理是否正常
- 多次开关某一个功能，查看是否正常使用
- 多次插拔硬件，查看功能是否正常
- 长时间待机后进行相关操作，查看基本功能是否正常
- 长时间使用不同功能后进行相关操作，查看基本功能使用是否正常
使用思维导图设计格式的原则
整体把握：使用【测试类型分析法】建立第一级目录。
单类型测试点：
- 首先以小的功能模块进行分级
- 小的功能模块里按照“执行成功”“执行失败”“关联性测试”“异常情况测试”等若干模块
- “执行成功”里面分为“一次执行成功”“多次执行成功”
最后一级描述规则
- 【测试点】+【测试步骤】+隔断符号+【预期结果】
“验证客户名称长度：点击进入客户信息新增界面，输入客户名称允许输入的最大长度，其他信息符合规范，点击保存。------对应客户信息能够正常保存，显示正常。”
严格控制思维导图横向层级：横向分级不宜过多。
最后一级测试描述颗粒度：一个用例永远只关注一个测试点，比如，关注一个输入框的输入内容的时候，就不考虑长度，不考了其他单元框对他的影响；
用例设计原则说明
- 单个功能的用例设计条数需要考虑其重要程度、重要性为高的功能，用例设计就相对完善，相对丰富些，重要性比较低的功能，用例设计的力度就小一些；
- 高优先级的用例多考虑正常流，少考虑异常流；
- 单条用例执行的步骤和预期结果的条数要控制，步骤太多的话，容易引起遗漏，一般不要超过3个步骤；
- 一个用例只有一个测试点
测试思维导图设计步骤
- 用例级别定义说明：
- LEVEL1：最常用操作、测试用例为正向反向的对应用例。40%
- LEVEL2：不太常用操作或者不太常用的比如边界值、冷僻输入的检查、不停点击按钮等类似的操作的对用用例；50%
- LEVEL3：操作方法比较复杂、测试环境比较生僻。且执行起来有较大难度的对应用例 10%
用例执行结果标注说明
- 通过：按照测试用例的操作步骤执行，实际执行结果与预期结果一致
- 失败：按照测试用例的操作步骤执行，实际执行结果与预期结果不一致，出现界面显示异常，处理异常，死机，功能失效等异常情况
- 跳过：由于测试环境或者其他外部条件的限制，导致用例无法执行，或者用例不适用，需要更新用例的情况
- 未实现：软件对应功能未实现，导致对应用例无法执行的情况
- 待确认：不确定测试结果的对错，还需要再确认的情况
用例执行说明
- 执行结果为失败的测试用例，需要提交bug跟踪，执行结果处附上bug ID
- 测试负责人在一轮版本测试完成后，要组织进行测试用例的活动分析，根据分析结果修改用例，保持用例的最新
测试用例更新及维护
- 根据需求输出的测试用例，一般在软件功能交付后，就会存在需求变更导致用例与系统功能实现对不上的情况，需要刷新用例
- 测试用例执行一遍后，发现问题的能力降低，缺陷有了免疫力，需要更新新的内容
- 客观承认测试用例设计的不全面性，只要是设计，就会存在遗漏，通过一段时间的测试加深理解后，可以更好的完善用例
- 对发现的问题进行分析，将之间测试设计遗漏点补充到测试用例中
用例维护的方式
- 根据刷新后的需求说明书，更新用例
- 根据提交给测试的软件版本具体实现，刷新用例
- 根据非通过的用例执行结果，进行分析后，更新用例
- 对版本发现的问题进行分析，找到测试设计的遗漏点，刷新用例
- 软件功能转测试后，出现变更，追加或删除，刷新用例
- 需要掌握深度加深后，发现测试设计遗漏点，刷新用例
用例维护时间
- 一般在全面用例执行后，进行用例的第一次刷新
- 每轮执行后，进行缺陷分析后的用例更新
- 测试执行完成后，规范化刷新后归档
用例维护的方式
- 由项目测试负责人进行用例的刷新的组织，组内人员协助刷新
漏测分析
- 一种质量改进活动，一般发生在第二轮以及之后的版本测试后，由测试负责人发起，其他人员配合开展的一个问题回溯，借以调查每轮问题出现的原因，是新引入，还是漏测，然后根据分析结果，进行相应改进的一种质量提升活动
漏测分析发起人：
由项目测试负责人进行漏测分析
漏测分析流程：
- 由项目测试负责人汇总输出当前版本发现问题列表
- 由本轮提单人员去上个版本验证，填写验证结
- 如果是测试人员遗漏，需对应上一轮的测试人员撰写漏测分析报告，如果是新引入，需要对应开发人员撰写问题引入报告原因
- 由QA组织回溯会议，对相关问题进行回溯，输出会议结论，形成改进意见
- 通知相关领域，相关改进意见的落实
测试过程
测试计划+测试设计+测试实现+测试执行
测试计划：完成系统测试计划
测试设计：完成系统测试方案
测试实现：完成系统测试用例和脚本，系统测试规程、系统测试预测试项
测试执行：执行测试用例，提交测试报告，发现问题提交缺陷
测试设计方法
- 等价类划分法
- 边界值分析法
- 判定表法
- 因果图法
- 状态迁移图法
- 流程分析法
- 正交试验法
- 输入域测试法
- 输出域覆盖法
- 异常分析法
- 错误猜测法
测试用例包括哪些内容
- 用例编号
- 测试点 用例描述 测试步骤 预期结果 环境图 用例级别
- 平台产品 备注 关键配置 用例执行时间 状态 创建人 修改人
