本文将带你了解测试技术测试用例设计，希望对大家学测试技术有所帮助。

　　如果你在公司负责评审测试用例，   是否也曾经迷失在几百条测试用例中不能自拔？ 如果你曾经编写过大型功能模块的测试用例， 是否也曾抓住了细节却遗漏掉关键测试点呢？   这里为大家介绍一份测试用例设计模板，   希望在解决这两个问题上能起到抛砖引玉的作用。

　　正文：

　　最近看了一篇贴子，   写的是工作几年自己最满意的工作成果。 于是， 我就在想这些年来在当前这家公司我自己最满意的工作成果是什么呢。 脑海里浮现的第一个选项不是公司里第一个B2B   项目的需求分析，不是在公司第一个敏捷项目里以user   story map + user story 的方式来代替公司传统的需求管理，   而是四年前做测试的时候做的测试用例设计模板。   究其原因，可能是因为这个用例设计模板后来被其它项目使用而且经历了四年仍然沿用至今。当时为什么会想做这样一个用例设计模板呢？   四年前在公司的某个项目里负责测试。测试用例由测试部门的同学写好后交付给需求的同学评审。   在用例评审过程中发现几个问题：

　　1. 当一个功能庞大到有成百条用例需要评审时，   需要花很多时间去阅读用例。

　　2. 评审用例的同学逐条读完十来条测试用例(包含测试目的， 测试步骤，   期望结果)后发现已经忘记了这些用例覆盖了哪些功能点。 注意力被一些细节问题消耗， 如单词拼写错误。

　　3.   测试同学经常和需求人员就类似某些测试用例应该合并还是拆分的问题发生争执。 测试同学认为合并测试效率高， 需求同学认为分开测试用例看起来清晰明了。   测试同学认为需求同学不懂测试瞎指挥， 需求同学认为测试同学偷懒图便利。于是， 我在想能不能在写测试用例之前加上用例设计环节， 然后以评审用例设计取代评审用例描述呢？   一来用例设计没有用例例描述中的那么多细节， 评审起来方便快捷， 评审人员能抓住重点。 二来需求同学没机会看到具体的用例描述，   也就没有机会去干涉用例的具体呈现方式。 而且评审用例的方式由需求人员去阅读一条条的用例改成测试同学组织用例评审会议自己去给大家(需求人员，   同组其它测试人员) 讲用例设计。 由测试同学去讲用例设计的好处有 1.   节省需求同学阅读枯燥的文字的时间

　　2. 强迫测试同学认真对待用例设计。 困为毕竟测试同学要在众人面前去讲清楚自己的设计，   而讲清楚的基本前提是想明白。

　　3. 测试新人可以从在别人的用例设计中学习。 4.   测试同学没有多少机会在众人面前演讲。 用例设计评审正好提供了机会给测试同学锻炼这方面的能力。于是， 有了下面这份用于用例设计评审的用例设计模板文档。   文档包含以下内容：

　　1. 修订版本: 用例设计写完后需要测试部门评审然后需求部门评审，   各部门评审都可能引起修改更新。 有记录，   方便追踪改动。

　　2. 用例设计模版： 文档的核心内容。

　　3.   Checklist。 用于测试人员自查。

　　4. Test Data.   列出测试用例中需要提前准备的测试数据。 比如特殊的产品， 银行卡之类。 有些测试数据需要开发部门准备。 所以测试数据整理到一起， 用例评审时再一起讲解，   便于开发部门理解和准备。

　　5. Test Guide: 列出需要产出的 test guide.   这样在写用例的前期就知道除了测试用例外测试部门还要产出哪些测试文档。 一来可以估计工作量，   二来可能在用例评审会议上找出应该产出却没有计划产出的测试文档。

本文由职坐标整理并发布，希望对同学们有所帮助。了解更多详情请关注职坐标软件测试之测试技术频道！