设计有效用例

lindongfeng

偶尔瞎写的，看完了，有什么不同的想法，在下面跟个贴子。

设计有效用例
由于测试的执行是依据测试用例而进行的，因此设计测试用例就成为了执行测试的基本切入点。测试用例的设计并不是指单个的测试用例设计，而是针对整个系统的测试用例设计。也就是说测试用例的覆盖度。如果覆盖度不够，就是单个测试用例设计的再好，那么对于整个测试来说也是失败的。对于一个产品来说，它的开发和测试不是一次性的，随着需求的不断变更，以及系统界面和功能的逐渐变化，测试用例也应随其而改变，由此可见测试用例的书写实际上是个迭代的过程。
测试用例的书写一般是在需求分析阶段进行，这段时间的用例形成了最终测试用例的基本框架，在这段时间内的用例主要是验证需求的可实现性，用例中还有很多内容无法填写。用例的可执行性非常差。而在系统交付测试的时候，测试用例进行了第一次的迭代，也就是说对测试用例的框架进行了第一步完善、可执行性明显增强。随着测试的不断深入，测试用例也在不断更新，变得更加详细。当第一轮回归测试开始时，测试用例已经基本覆盖了系统的所有功能。
一般在测试用例中应主要包括以下内容，用例简述、功能描述、测试数据、测试要点、测试步骤和预期结果。而在测试步骤中，每执行一个步骤都会有一个预期结果与这个步骤相对应，如果没有预期结果，那么测试用例就会中断，测试用例将无法继续执行下去。
下面对用例的具体内容做一简要说明
用例简述：简单说明用例执行的功能。
功能描述：描述被测对像将要实现的功能。
测试数据：这部分主要是指输入输出的结果，以及数据存放状态。
测试要点：描述测试中应该注重的主要功能点。
测试步骤：测试执行的操作步骤。
预期结果：与测试步骤一一对应。
能够发现到目前为止没有发现的bug的用例是好的用例，这句话说的不错。但在设计用例的时候不要只为了发现“难于发现的bug”而把用例设计的过于片面，偏移了测试的目的，那这样的用例也是作用不大的。测试是一种“V&V”的活动。
测试需要保证以下两点：
1．        程序做了它应该做的事情；
2．        程序没做它不应该做的事情；
保证这两条，并不是靠单个用例就可以完成的，而是要看整个系统测试用例的覆盖率。
个人认为，测试用例贵在其执行性，如果用例可以使一个没有接触过系统的人，按照用例去执行每一步操作，并且这些操作步骤可以覆盖到系统的每一个功能点和所有的业务流程，那说明这个用例是成功的。
不同的程序都会有共同的特性，由此可以引入通用用例的概念。因为通用用例的创建可以节省用例设计的很多时间，所以我们通常会在写测试用例的时候引用通用用例。但通用用例一定要具有代表性和通用性，就是说通用用例基本可以保证在每个测试用例中都可以使用。例如：在系统中普遍存在文本输入框。在没有通用用例的情况下，每次遇到输入操作，我们都会在里面写下至少三种的输入和输出：正常值－通过、越界值－提示输入范围、非法字符－提示不能包括非法字符。而对于程序有限制的地方还要多出两种情况，重复－提示已经存在、空－提示不能为空。将这些重复性的工作提取出来，就形成了通用用例。
当然通用用例的存在需要测试人员理性的变通。如果程序并没有强制不能为空，按照通用用例不能为空的条件就是BUG但实际上不是。

zrg9399

好贴要跟！！

Nio

楼主提到了用例设计的概念，这是偶一直想要强调的，在测试中有很多同行忽略了用例设计这一环节。

很多人拿到任务想到的就是test plan, test case等，没了test design这一过程，更没了case design。

用例的设计，重点在于设计，而不在用例，在于指导如何编写特定的用例，不在于编写特定的用例。

用例的设计关键在于要对测试用例进行有效的归类、总结——前题是你能写出绝大部分详细的用例。

sy2008

想问一下,在开发还没设计出程序之前,编写出的测试用例还只是大概的类似于大纲之类的吗?一个项目的测试用例的产生是由大概到详细逐步完善的过程吗,这样的过程是怎样逐步细化的呢?谢谢!sdlkfj2

Lero

怎么直接打开会出现内存泄漏问题呢?