测试用例设计和执行是测试工作的核心，也是工作量最大的任务之一。测试用例(Test Case) 目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。测试用例其实就是一个个你测试的想法，你有了这些想法之后，详细地写下来，就成了测试用例。
测试用例编写准备:
1. 从配置管理员处申请软件配置：《需求规格说明书》和《设计说明书》；
2. 根据需求规格说明书和设计说明书，详细理解用户的真正需求，并且对软件所实现的功能已经准确理解，然后着手制订测试用例。
测试用例制定的原则:
- 测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。
2. 测试数据应该选用少量、高效的测试数据进行尽可能完备的测试。
用例覆盖:
- 正确性测试：输入用户实际数据以验证系统是满足需求规格说明书的要求；测试用 例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。
- 容错性（健壮性）测试：程序能够接收正确数据输入并且产生正确（预期）的输出， 输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示 并进行相应处理。把自己想象成一名对产品操作一点也不懂的客户，在进行任意操作。
- 完整（安全）性测试：对未经授权的人使用软件系统或数据的企图，系统能够控制的程度，程序的数据处理能够保持外部信息（数据库或文件）的完整。
- 接口间测试：测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。
- 压力测试：输入10条记录运行各个功能，输入30条记录运行，输入50条记录进行测试。
- 性能：完成预定的功能，系统的运行时间（主要是针对数据库而言）。
- 可理解（操作）性：理解和使用该系统的难易程度（界面友好性）。
- 可移植性：在不同操作系统及硬件配置情况下的运行性。
如何编写测试用例：
测试用例有几个重要的组成部分：简明扼要的标题，详细的步骤，正确的预期结果。 例如：
测试用例：验证记事本程序可以编辑中英文混合的内容
测试步骤：
- 运行记事本程序。
- 切换到中文输入法，输入中文“学习编写”。
- 切换到英文输入法，输入英文TestCase。
- 保存文件，文件名为testcase.txt。
- 关闭记事本程序。
- 双击testcase.txt以打开文件。
预期结果：
文件的内容是“学习编写TestCase”。
测试用例的优先级：
测试用例还有一个优先级的概念，就是用来区分哪些用例更重要。一般可以分为5个级别，分别用0 ~ 4来表示。数字越小表示优先级越高。如果项目小，优先级的好处不容易显现出来。当项目比较大，时间又不宽裕时，可能只能执行更重要的测试用例，这个时候优先级的重要性就体现出来了。
A good test case should include:
如何执行测试用例：
如果你是一位软件测试的入门者，你到单位报到后接手的第一项工作很可能是执行软件测试用例，而不是去编写。你不要因此而郁闷，这样的安排是合理的，因为你毕竟是一个新手，执行测试用例是一个迅速熟悉当前测试工作的好机会，而且压力也不大。因为在英语中执行测试用例是Run test case，所以有些公司把执行测试用例叫做“跑case”，想来也是比较形象的。
我们还以验证记事本程序可以编辑中英文混合的内容为例。当我们面对这个用例的时候，我们首先要做的是清晰且正确地理解用例，不带半点含糊。测试的特点就是严谨，你来执行一个测试用例就是要贯彻用例编写者的测试思想，不能误解或曲解，不能用自己的主观意志去代替原来的意思。例如，第一步“运行记事本程序”，你就应当清楚地知道“记事本”是哪个程序，如果有疑问马上问清楚，否则，如果真的吧测试的产品弄错了，一切就都白忙了，还浪费了时间。这个例子因为浅显，所以出现误解的可能性很小，而在实际的工作中，还是会有很多模棱两可的地方，这个时候我们不能偷懒，要勤学多问。
执行用例不能走样。例如第二步，要求输入“学习编写”四个字，如果你为了省事，拷贝了这几个字，每次都是粘贴过来，快是快乐，却违背了原著的意思，这样式不行的。用例编写者要求用输入法来输入，肯定是有道理的。如果哦你发现没有检测“粘贴”的测试用例，可以建议增加，但不能再执行的时候就偏离了用例的本意。说一个万一的事儿，如果这个软件通过了你的测试，发布给用户，用户却发现不能输入，只能粘贴，这个责任你能负的起吗？
大家可能都知道，做软件测试要细心，这个要求在执行用例的过程中表现得很明显。我们在执行一个测试用例的时候，不但要注意实际结果是否与预期结果是一致的，而且在整个过程中都要保持观察。例如上例中，如果第四步执行保存后，你发现文件名并不是自己输入的testcase.txt，这时你就应当停下来，因为这就是bug。
我们执行测试用例的目的是什么？就是发现bug，所以，我们在执行测试用例的过程中，要收集好发现的问题，不能有泄露。在实际工作中， 执行测试用例的过程一般都是紧张的，工作量很大，并不像我们今天在这里讨论的这么轻松，因为你要不停地往前赶，所以容易出现一些遗漏的问题。每当发现一个问题，我们都要做好记录，而不要总以为自己能记得住，好记性不如烂笔头。Bug是最能证明测试工程师工作成绩的东西，好不容易发现了，如果还被自己遗漏了，岂不令人懊悔？而且，还给产品留下了一个隐患。