测试用例怎么写_？怎么有效的设计测试用例呢？（上部）

编写测试用例，永远是刚进入软件测试行业的小朋友最头疼的事情，用例文档的编写，最是体现个人逻辑思维和测试素质，一份优质的用例文档，绝对会让其他的测试小伙伴对你刮目相看，也会让你在测试用例评审会议中闪闪发光。

那么，问题来了，一份优质的用例文档，应该是什么样的呢？

---------------------------------

★首先，你需要有一个有效存储测试用例的工具，有的公司是保存在项目管理工具中，例如禅道等等，也有的公司是直接用excel表格来保存的，不用拘泥在这种地方，无论在何处，测试用例永远包含了以下这些要素：

测试用例的编号：关于编号，不同的公司或项目可能有自己的风格，但是他们都具有一个共同的特点，就是编号都有自解释性和唯一性，像身份证号码一样，一看就知道你的大体信息，用例编号也是这样，一个用例的编号应该长成下面这样：

产品编号_阶段_测试项名_测试子项名_XXX(具体用例序号)

阶段包括了单元(UT)、集成(IT)、系统(ST)、验收(UAT)四个。

测试的项目名称：这里填写测试用例编号中的测试子项目名即可。

测试用例的标题：从测试出发点、关注点、测试预期来体现就好了，要求清晰简洁，最好也有唯一性。

例如：在广告banner区域使用左滑的手势来浏览下一张广告图片。

再例如：在购物车商品数量栏中填写超出整型范围的数据来提交商品信息验证数字类型的边界值。

让别人知道你这条用例是要做什么，以及怎么去做。

测试用例优先级：优先级我们一般分成VH、H、M、L四个等级，也就是非常高、高、中、低四个等级，分级标准是根据这个功能的用户使用频率密度以及模块失效之后的影响程度来综合定义的。

VH ---- 基本流程并且失效后会影响用户使用流程

V ---- 基本流程，或者失效后会影响用户使用流程

M ---- 分支流程和异常流程

L ---- 使用频率不高，对业务流程影响较小的功能

测试用例的前置条件：前置条件就是指，现在要做的这件事，需要先准备些什么，就像古代人要结个婚，需要先纳彩、问名、纳吉、纳征、请期、迎亲，最后才能洞房一个意思...

例如，你现在要写一个购买商品时商品数量不足的测试场景，那么前置条件就是，在后台将这个商品上架，并且设置数量少于你的购买数量。

再例如，你要做某个商品的优惠折扣计算测试，前置条件就是添加一个优惠活动，并且将测试商品添加进去，设置好规则等等。

测试的操作步骤：操作步骤一定要写的完整和清晰，基本上每一个步骤都是动宾短语的结构

例如：点击取消按钮、点击促销价复选框、在商品名称输入框一栏输入商品的名称、点击商品列表超链接、选择商品分类下拉框中商品的分类

测试用例的输入数据：每个操作步骤中对应的输入、选择等等，都会有个与之对应的数据，我们往往将操作和数据分离开来，数据只是作为测试操作步骤中的一个样式。

预期结果：这个点非常重要！很多人在写预期结果的时候考虑不够全面，导致了比较多没有关注到的隐藏问题。

在预期结果中，至少要从前台提示和界面展示、以及后台的数据变更两个方面来考虑。

假如你现在测试购物的流程，点击结算付完款之后，页面提示你购物成功，你就放心了吗？

你还需要去数据库的几张相关联的表中，检查这个订单的状态、商品数据以及购买时间、单价、总价、付款方式、快递方式、优惠情况等等信息；检查商品表中商品数据减少了没；检查用户的购物积分等；检查用户买完这单他的用户等级升级了没有等等很多很多的东西。

实际结果：一般包括了测试通过、测试失败、未测试三项。

其它的一些用例文档元素还可以包括：测试人、测试时间、测试版本、测试环境、备注等。

---------------------------------

那么，如果有效的编写测试用例的内容呢？怎样更好的运用测试用例的设计方法呢？

请关注下一期：《あれ？怎么有效的设计测试用例呢？(下部)》