面对这个题目，其实我并不想写，因为去网络上搜索“测试用例”为关健字的东东，出来的太多太多，各个凡有关能涉及或不涉及到的测试有关的都会有很多东西出来。如果大家仔细研究一下，其实内容大致差不多，只不过看自己是否能消化而已。

　　在测试几年的过程中，打交道最多的是测试用例，从需求开始到方案，到形成用例，执行过程中与实际的出入，测试完成后用例的修改，维护等，没有一个过程可以说不需要测试用例之说。但我今天还是写了关于测试用例的，不是写如何设计编写，而是如何写“好”。让人看了一目了然，就看有新人拿到这个用例，能对程序有一点点基本的了解，就可以按照用例完完整整的执行下去。

　　在短信回执的测试用例里，我没有修改过的用例是很少的，在组员编写测试用例过程中我总会强调简单明了，其实就是精华。我认为有以下几点要关注：

　　1、对功能的理解。这个是最重要的，也是能反映出每个人对同一功能描述而有不同的理解方式，故一定要深刻理解功能。

　　2、编写用例永远要考虑两面性。事物都是两面的，只有一面的事物那是“怪物”，所以在编写测试用例时先要心中有数。

　　3、确定测试用例的目的。如果不了解为何要写这个用例，那你达到的目的就是按需求或者按任务来完成而已，这样的用例是否适用还有待于商榷；只有了解这个功能的来源，为什么要做这样的功能，希望最后的结果是什么，这些通通考虑清楚了，就不会为了完成任务而去编写出“普通”的测试用例，而是一份优秀合格的测试用例，这样会大大提高工作效率及审核打回的次数。

　　4、测试用例所包含的内容：最基本最简单的测试用例应该包含四项内容，即描述、预置条件、操作步骤、预期结果。一般为更好的管理及维护测试用例，我们会增加测试用例的编号及功能。

　　1）测试用例的描述项，一般人在写的时候根本不去关心这到底有何用，有的甚至为空，更有甚者把需求中的几个字直接复制过来，不管是否通顺与否都放在那里认为就可以了，预置条件可以说是一个总结语，即你要明白这个用例是要验证什么的，因为一个功能有很多用例，你不可能每个描述都是一样的，那这样还不如不要描述。

　　2）预置条件项，任何一个事务都有起源，有始有终才是一个完整的过程，预置条件也可以说是一个基础，基础打好了，一切才能顺利动工。预置条件是为操作步骤服务的，当然有些可能说不需要预置条件，其实任何用例都是有预置条件的，我们说没有预置条件只是隐藏了本身的特点而已。简单来说，发送一条命令测试用例，前期不需要预置条件，但其隐藏的就是有号，且通信正常，还要有MONEY用来发送短信；但实际中我们并不需要写这些预置条件，因为是这是本身特点决定的。

　　3）操作步骤是非常重要的一环，与预期结果是等同的地位。测试用例设计是否高效，由预置条件及操作步骤决定，在操作步骤中，按正常步骤来测试，好像都不会出问题，但真正出问题的就是你想不到的，不是按常规则出牌的才会发现真正有价值的缺陷，所以在设计测试用例时，不要嫌麻烦，认为那一项就好了，别的都应该能检测到，认为写某一项是不必要的，多余的，其实这些想法是错误的，问题就往往出现在你认为这无关功能上。

　　设计操作步骤还依赖于测试经验是否丰富，有些经验丰富的人员设计的测试用例往往会出乎意料，也是在测试阶段最容易发现问题的用例。比如很简单的一个编辑功能，要求其内容不能重复，一般人在写用例的时候都在编辑中去修改成别的名字，而有经验的测试人员会直接编辑一下而不改变内容，一般的程序员是不会考虑到此问题的，如果说出现提示错误一般都是程序逻辑问题。

　　4）预期结果，此项是验证所写用例是结果如何，所以如果没有预期结果，在测试时则无任何可参照的，预期结果与操作步骤的关系相当大，一般来说，不同的操作步骤能生成不同的预期结果，因此在测试测试用例的时候，尽可能的考虑不同的操作步骤，是否会产生同一个结果，所有有时在设定测试用例的时候，根据结果来推断操作步骤，这也应该是设计用例时的一种参照方法。在测试时，预期结果直接导致着测试是否通过。

　　以上仅是我对设计测试用例的一些观点，完全是自己本人的经验总结，而没有去抄写任何书上写的如何设计测试用例的观点，设计测试用例的过程就是对需求的深入了解，也能反映出一个人对需求的理解程度如何，达到一个什么程度，也可能反映出一个是否有较强的总结能力，每次用例设计完，是否较上次有进步等。

　　测试用例作为测试的一个总纲及指导作用，故，对于测试用例的设计是不能马虎，不能省略的一个步骤，产品是否上线，测试用例是否通过起着决定性的作用。

　　设计测试用例一般还包括性能测试用例，但对于性能测试用例，大多情况下，起到一劳永逸的作用。但实际上对于性能测试用例来说，一般只是说并发多少用户，并不会设计具体要如何操作等，所以在此文章中，我就不介绍如何设计好性能测试用例，如果可能，将来再把我的测试想法与经验与大家分享。