1、测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果的条件或变量，以便测试某个程序路径或核实是否满足某个特定需求。

　　2、内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。测试用例的输出不仅包括页面展现还应包括，数据库里信息是否正确。

　　3、测试的“深度”与测试用例的数量成比例。由于每个测试用例反映不同的场景、条件或经由产品的事件流，因而，随着测试用例数量的增加，您对产品质量和测试流程也就越有信心。 判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这又是以确定、实施和/或执行的测试用例的数量为依据的。类似下面这样的说明：“95 %的关键测试用例已得以执行和验证”，远比“我们已完成95 %的测试”更有意义。 测试工作量与测试用例的数量成比例。根据全面且细化的测试用例，可以更准确地估计测试周期各连续阶段的时间安排。

　　4、测试设计和开发的类型以及所需的资源主要都受控于测试用例。 测试用例通常根据它们所关联关系的测试类型或测试需求来分类，而且将随类型和需求进行相应地改变。方案是为每个测试需求至少编制两个测试用例： 一个测试用例用于证明该需求已经满足，通常称作正面测试用例；另一个测试用例反映某个无法接受、反常或意外的条件或数据，用于论证只有在所需条件下才能够满足该需求，这个测试用例称作负面测试用例。有了测试用例，无论是谁来测试，参照测试用例实施，都能保障测试的质量。可以把人为因素的影响减少到最小。即便最初的测试用例考虑不周全，随着测试的进行和软件版本更新，也将日趋完善。

　　看了这段才发现测试的时间评估原来是这么评估出来的。还有就是之前sell的测试用例的多和细，确实对于测试帮助很大，之前总觉得测试前期准备很重要，但是没有具体的方案，只感觉要多看多理解需求，现在感觉就是要一点点细化分析需求形成测试用例，让测试用例更广的覆盖需求。如果哪天能像书里说的，说起测试进度时，只需说执行了百分之几的测试用例，而不是说大概测试了本分之多少。

　　5、作为测试实施依据的测试用例，必须要能完整覆盖测试需求，而不应该针对单个的测试用例去评判好坏。

　　6、设计测试用例：测试用例可以分为基本事件、备选事件和异常事件。设计基本事件的用例应该包含所有需要实现的需求功能，覆盖率达100%。备选事件和异常事件要负责和困难的多，因为在设计编码阶段形成的文档对备选事件和异常事件分析描述不够详尽。

　　7、用于功能性测试的测试用例来源于测试目标的用例，应该为每个用例场景编制测试用例。用例场景要通过描述流经用例的路径来确定，这个流经过程要从用例开始到结束遍历其中所有基本流和备选流。

　　8、常用的测试方法。

　　白盒测试是结构测试，所以被测试对象基本上是源程序，以程序的内部逻辑为基础设计测试用例。方法：

　　语句覆盖：设计足够的测试用例，使被测试程序中每个语句至少执行一次。

　　判断覆盖：使得被测程序中每个判定表达式至少获得一次“真”值和“假”值。

　　判定/条件测试：判定表达式的每个条件的所有可能取值至少出现一次，并使每个判定表达式所有可能的结果也至少出现一次。

　　条件组合覆盖：使得每个判定表达式中条件的各种可能的值的组合都至少出现一次。

　　路径覆盖：设计足够的测试用例覆盖被测程序中所有可能的路径。

　　黑盒测试：等价类划分、边界值分析、错误推测、因果图