在测试几年的过程中，打交道最多的是测试用例，从需求开始到方案，到形成用例，执行过程中与实际的出入，测试完成后用例的修改，维护等，没有一个过程可以说不需要测试用例之说。但我今天还是写了关于测试用例的，不是写如何设计编写，而是如何写“好”。让人看了一目了然，就看有新人拿到这个用例，能对程序有一点点基本的了解，就可以按照用例完完整整的执行下去。
在短信回执的测试用例里，我没有修改过的用例是很少的，在组员编写测试用例过程中我总会强调简单明了，其实就是精华。我认为有以下几点要关注：
- 1、对功能的理解。这个是最重要的，也是能反映出每个人对同一功能描述而有不同的理解方式，故一定要深刻理解功能。
- 2、编写用例永远要考虑两面性。事物都是两面的，只有一面的事物那是“怪物”，所以在编写测试用例时先要心中有数。
- 3、确定测试用例的目的。如果不了解为何要写这个用例，那你达到的目的就是按需求或者按任务来完成而已，这样的用例是否适用还有待于商榷；只有了解这个功能的来源，为什么要做这样的功能，希望最后的结果是什么，这些通通考虑清楚了，就不会为了完成任务而去编写出“普通”的测试用例，而是一份优秀合格的测试用例，这样会大大提高工作效率及审核打回的次数。
- 4、测试用例所包含的内容：<span style="color:#6600CC;">最基本最简单的测试用例应该包含四项内容，即描述、预置条件、操作步骤、预期结果</span>。一般为更好的管理及维护测试用例，我们会增加测试用例的编号及功能。
1）测试用例的描述项，一般人在写的时候根本不去关心这到底有何用，有的甚至为空，更有甚者把需求中的几个字直接复制过来，不管是否通顺与否都放在那里认为就可以了，描述项可以说是一个总结语，即你要明白这个用例是要验证什么的，因为一个功能有很多用例，你不可能每个描述都是一样的，那这样还不如不要描述。
2）预置条件项，任何一个事务都有起源，有始有终才是一个完整的过程，预置条件也可以说是一个基础，基础打好了，一切才能顺利动工。预置条件是为操作步骤服务的，当然有些可能说不需要预置条件，其实任何用例都是有预置条件的，我们说没有预置条件只是隐藏了本身的特点而已。简单来说，发送一条命令测试用例，前期不需要预置条件，但其隐藏的就是有号，且通信正常，还要有MONEY用来发送短信；但实际中我们并不需要写这些预置条件，因为是这是本身特点决定的。
3）操作步骤是非常重要的一环，与预期结果是等同的地位。测试用例设计是否高效，由预置条件及操作步骤决定，在操作步骤中，按正常步骤来测试，好像都不会出问题，但真正出问题的就是你想不到的，不是按常规则出牌的才会发现真正有价值的缺陷，所以在设计测试用例时，不要嫌麻烦，认为那一项就好了，别的都应该能检测到，认为写某一项是不必要的，多余的，其实这些想法是错误的，问题就往往出现在你认为这无关功能上。
设计操作步骤还依赖于测试经验是否丰富，有些经验丰富的人员设计的测试用例往往会出乎意料，也是在测试阶段最容易发现问题的用例。比如很简单的一个编辑功能，要求其内容不能重复，一般人在写用例的时候都在编辑中去修改成别的名字，而有经验的测试人员会直接编辑一下而不改变内容，一般的程序员是不会考虑到此问题的，如果说出现提示错误一般都是程序逻辑问题。
4）预期结果，此项是验证所写用例是结果如何，所以如果没有预期结果，在测试时则无任何可参照的，预期结果与操作步骤的关系相当大，一般来说，不同的操作步骤能生成不同的预期结果，因此在测试测试用例的时候，尽可能的考虑不同的操作步骤，是否会产生同一个结果，所有有时在设定测试用例的时候，根据结果来推断操作步骤，这也应该是设计用例时的一种参照方法。在测试时，预期结果直接导致着测试是否通过。
测试用例作为测试的一个总纲及指导作用，故，对于测试用例的设计是不能马虎，不能省略的一个步骤，产品是否上线，测试用例是否通过起着决定性的作用。
----------
编写测试用例的策略
测试用例编写策略可以从不同的角度分类。
从测试内容角度可以分为流程用例和功能点用例。其中流程用例指针对业务流程编写的测试用例，通常采用场景法，现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。功能点用例指针对具体功能点编写的测试用例，可以采用等价类划分、边界值法、因果图等方法。
根据测试的策略又可以分为通过测试用例和失败测试用例，通过测试用例主要为了验证需求是否可以实现，一般采用等价类划分等测试方法。失败用例的编写主要为了尽可能多的发现缺陷，一般采用错误推测法、边界值分析法等测试方法。
在具体的项目中，需要灵活的应用不同的测试策略。对于业务流程比较重要的系统，首先要考虑用场景法编写流程用例，要求覆盖所有的基本流和备选流。流程测试用例的完善，可以保证业务流程和业务数据流转正确无误，对软件的质量有了最基本的保障。其次需要编写功能点测试用例，要求覆盖所有的需求，保证需求的各个功能都能正常的实现。对于所有的软件测试，我们首先要考虑通过测试用例，来证明软件可以满足需求。在保证软件可用的基础上，才会使用失败测试用例，来尽可能多的发现缺陷，保证软件的具有一定的容错和安全能力。
在测试用例的编写过程中还需注意其详细程度，覆盖功能点不是指列出功能点，而是要写出功能点的各个方面，如果组合情况较多时可以采用等价类划分的方法。此外，测试用例的编写和组织会受到组织的开发能力和测试对象特点的影响。如果开发力量比较落后，编写较详细的测试用例是不现实的，因为根本没有那么大的资源投入，当然这种情况会随着团队的发展而逐渐有所改善。测试对象特点重点是指测试对象在进度、成本等方面的要求，如果进度较紧张的情况下，是根本没有时间写出高质量的测试用例的，甚至有些时候测试工作只是一种辅助工作，因而不编写测试用例。
总之，在组织和编写测试用例时，需要根据测试对象特点、团队的执行能力等各个方面综合起来决定采用哪种编写策略，以及如何编写测试用例。
测试用例的设计
测试用例目前没有经典的定义，比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。随着中国软件业的日益壮大和逐步走向成熟，软件测试也在不断发展。其中，测试用例的设计和编制是软件测试活动中最重要的，它是测试工作的指导，是软件测试必须遵守的准则，更是软件测试质量稳定的根本保障。
1、测试用例设计原则
设计测试用例时，应遵循以下原则：
1）基于测试需求的原则。应按照测试类别的不同要求设计测试用例。例如，单元测试依据详细设计说明，集成测试依据概要设计说明，配置项测试依据软件需求规格说明，系统测试依据用户需求（系统/子系统设计说明、软件开发计划等）。
2）基于测试方法的原则。应明确所采用的测试用例设计方法，为达到不同的测试充分性要求，应采用相应的测试方法，如等价类划分、边界值分析、猜错法、因果图等。
3） 兼顾测试充分性和效率的原则。测试用例集应兼顾测试的充分性和测试的效率；每个测试用例的内容也应完整，具有可操作性。
4）测试执行的可再现性原则。应保证测试用例执行的可再现性。
2、测试用例要素
每个测试用例应包括以下要素：
1）名称和标识。每个测试用例应有唯一的名称和标识符。
2）测试追踪。说明测试所依据的内容来源，如系统测试依据的是用户需求，配置项测试依据的是软件需求，集成测试和单元测试依据的是软件设计。
3）用例说明。简要描述测试的对象、目的和所采用的测试方法。
4）测试的初始化要求。应考虑下述初始化要求：
● 硬件配置。被测系统的硬件配置情况，包括硬件条件或电气状态。
● 软件配置。被测系统的软件配置情况，包括测试的初始条件。
● 测试配置。测试系统的配置情况，如用于测试的模拟系统和测试工具等的配置情况。
● 参数设置。测试开始前的设置，如标志、第一断点、指针、控制参数和初始化数据等的设置。
● 其他对于测试用例的特殊说明。
5）测试的输入。在测试用例执行中发送给被测对象的所有测试命令、数据和信号等。对于每个测试用例应提供如下内容：
● 每个测试输入的具体内容（如确定的数值、状态或信号等）及其性质（如有效值、无效值、边界值等）。
● 测试输入的来源（例如，测试程序产生、磁盘文件、通过网络接受、人工键盘输入等），以及选择输入所使用的方法（例如，等价类划分、边界值分析、差错推测、因果图、功能图等）。
● 测试输入是真实的还是模拟的。
● 测试输入的时间顺序或事件顺序。