测试用例编写及管理

测试积点老人

前段时间将项目中的测试用例进行了一次大规模的整理，从工作量出发认识到了测试用例书写及管理规范的重要性。规范的测试用例管理可以为后续的测试工作节约不小的工作量。

随着互联网时代的到来，项目迭代的频率越来越快。测试用例的可持续性尤为重要。如何有效的将测试用例进行编写及管理慢慢也成为测试工作者思考及修正的必修课。下面我将针对自己在测试工作中的一些积累及个人认为有助于有效管理测试用例的小技巧整理出来分享给大家。以下内容将会从两个方面进行表述：一，测试用例的编写；二，测试用例的管理。

一，  测试用例的编写

测试用例编写总体分为两个阶段：1，需求分析；2，用例设计。为什么我这里用词是设计而不是编写，下文中会进行进一步的说明

1.需求分析

项目中的需求分析是重要的一环无论是自研还是外包，有的伙伴可能会说：我们公司小，需求完全靠口，文档基本没有。但是需求评审无论文档有无都是可以进行的。只是进行的方式不同，同时要做好文档记录的工作，为项目后续测试工作做好准备，下面我会对不同有无文档进行一个整理

有需求文档：在做需求文档分析的时一般我会从几个方面进行分析：入口，条件，异常，结果，以及需求逻辑。为什么要说到需求逻辑，因为需求也是人设计的那么就一定会有没有考虑到的逻辑，或者说是潜意识的“顺理成章”比如：点击事件触发结果就仅有成功和失败吗？其实还有一种结果位于成功与失败的中间“等待过程”。一般这时间是短暂，短暂到人们忽略它。如果在“等待过程”中我们进行了另一个事件的触发可能就会导致程序的异常。

那我们就用“某某宝”支付类APP中的扫码功能为例进个说明。

• 入口：一般我们会需求进行一个简单的分类。那么我们要考虑的入口就会有：主页面的“扫一扫”和标题栏中“+”号中的扫一扫。
• 条件：简单来说就是“***条件下”“***情况中”条件就有“网络状态”“摄像机状态”“摄像权限状态”等
• 异常：可以理解为逻辑之外，包含非APP本身的条件。异常就有“返回后台”“关闭权限”“电话”“断网”等
• 结果：这里主要指在不同入口及条件下展示的结果不一样，如：关闭摄像机权限-无法打开摄像头，没有摄像头弹框提示“未安装摄像头”等
• 需求逻辑：这个就要对产品有进一步的整理后才能发现，或者说文案中暂时没有逻辑上的问题
  

无需求文档：在没有需求文档的时候，更需要测试者重视对于文档输出。测试时一个伴随开发而进行的持续性的工作，只有了文档的支持在后续的工作中才能有效规范的对自己及团队的工作量进行合理的管控，降低产品测试风险。相对于有文档的需求分析，无文档需要更多的是听与记和集中的头脑风暴。有如下几个有效方式：

• 开会讨论产品逻辑：参与人员最好包含非技术人员，这样才能最大可能的从普通使用者的角度发现产品使用上的“别扭”
• 合理设想异常情况：只有包含了足够的异常情况，产品产能够稳定。但要注意合理
• 并不是“老大”说的就一点是对的：只有不断的怀疑，才能不断的发现。
  

所有的需求分析都一定要有文档进行输出，只有文档才能有效的记录整个需求分析中的点滴，完善自己对于产品的理解。并且文档的输出并不是团队中一个人去完成的，每个人都应该有一份自己的需求文档输出。一是：锻炼团队的文档的输出能力，二是：有效的整合每个人的不同理解与角度，三是：有效的增强会议的严肃性团队的积极性。

文档中的测试点需要进行各级分类，建议使用脑图进行书写，有效且直观。一般一个需求模块为一个文件。等级规划如下：中心》》模块》》分类》单独测试点》》说明，其中可以进行备注及优先级的划分


2.用例设计

作为测试的基本功，大家第一时间就会想到：等价类，边界值，流程图等等。如何合理的使用以上方法对测试点进行完整的覆盖。这就是一个设计过程，他是一个需要构图及创作的过程。测试用例用作自己团队及第三方进行测试工作的指导书。

怎么才能让用例看起来简洁明了。咱们首先重视的应该是用例的标题，相信大家每次看新闻的时候第一眼看的也是标题，眼就能知道这个新闻说的是什么是什么类型的。同样测试 用例也是一样，测试标题应该有如下几个组成部分：需求+入口+前提+加操作+其他。              

格式为：“【需求】入口-前提-操作/其他”。如：【登录优化】QQ账号登录-检测到多个QQ登录-点击QQ账号登录/选择第一个

第二就是前提条件：通过编号进行不同类型的备注就好。如：1.有网/网络稳定；2.QQ浏览器；3.同设备中有3个QQ账号登录

第三用例步骤：步骤描述需要清晰，每一步都要“在什么地方怎么操作”让每一个操作描述都是唯一的，以免操作错误对测试结果造成影响

第四预期结果：每个结果都需要对应一个操作步骤，但不是每个步骤都需要结果。我们需要注明的只有我们关心的预期

第五用例等级：等级分类三级“高，中，低”。高：对应基础功能，中：异常操作，低：不变文案及非主要UI

第六点也是设计部分的重点部分“用例分类”：这个包含我们设计用例的的方法，就是前文中提到的：等价类，边界值，流程图等等。一般我们将基础操作流程定为“基础用例”；主流程之外的分支流程为“分支用例”；之后就是基础设计方式“等价类”“边界值”等按照实际情况进行划分；还有就是“异常操作”如切后台，断网，杀进程等，还有一点也是在测试点升级的一个点“探索类”，下面会重点进行一下说明。

为什么要讲探索测试提出来进行强调说明，是因为这不仅是一种测试方法。更多的应该是一种测试的思维技术，它没有繁琐的测试归类及手段。更多的是强调了测试人员的主观性，在碰到问题时及时改变测试策略。下面我也仅对探索测试进行一个整理和归类：

• 探索测试之“乖孩子法”：也就是针对测试点进行覆盖。
• 探索测试之“坏孩纸法”：输入错误内容，错误顺序操作等
• 探索测试之“买一送一法”：如“同一用户操作该内容”和“不同用户操作该内容” 等
• 探索测试之“强迫症法”：反复进行一项操作
• 探索测试之“懒惰法”：什么都不选就确定，什么都不输入就确定等
• 探索测试之“捣蛋法”：环境破坏（网络，操作，外界干扰，小内存设备）数据破坏，权限破坏等
• 探索测试之“反悔法”：正在执行停止它，正在下载停止它，正在查找停止它等
• 探索测试之“极限法”数值调整到最大或最下，网络1Kb，运行几天几夜，低内存下运行
  

测试用例的管理
随着应用程序的不断迭代我们会发现，其实有很多用例是需需要清理的。但是在实际工作中最让人头痛的就是用了的合并了，为了能够在测试工作中减少用例管理工作，一般都会借用一些第三方管理工具进行管理。这里就不对第三方的管理工具进行说明了，下面主要是对管理的思路进行一个整理。

在管理目录中应该是存在两级目录的：1.全量用例管理；2.历史用例管理。在全量用例中我们将用例按照功能模块进行划分；历史用例管理中我们主要对不同版本新编写的用例进行管理（这样是为了保留测试思路及做总结时可以参考的点）

1.新版本用例编写：仅对新需求设计及关联的相关功能模块进行用例的重新书写
2.新版本用例存档：将新的有效用例存档到历史用例管理目录中
3.新版本用例合并：将新版本用例合并到全量用例中，切记几点原则：无效用例清除；重复用例直接进行替换；部修改任何历史用例；涉及多个模块运行重复（命名上进行区别）

在使用第三方工具进行用例管理的同时，建议保留传统表格方式进行用例管理：一般第三方工具都仅对用例执行进行了有效的设计，管理方面都会偏弱。