设计测试用例可以说是测试人员的一项最基本技能 。很多时候当我们接到设计测试用例的任务时 ,往往都是想的该如何更快的完成这项任务 ?而很少去想为什么要完成这项任务? 对于测试用例也是如此,为什么要设计测试用例呢(目的)?其实这个问题是我们做好测试用例的元问题 ,回答好这个问题,你设计出的测试用例就更具有全面性 。
1.什么是测试用例 ? 包含什么要素 ?
首先,让我们来了解一个最基本的问题,什么是测试用例 ? 所谓的测试用例就是针对软件设计的一系列验证项 ,其中每个验证项中都包含了有输入,执行步骤,预期结果等要素 。其目的就是为了验证产品功能是否符合产品需求 。
通常情况下我们会将测试用例存放在一个具体的文档或工具中 ,比如 :excel , xmind ,禅道 或一些其它的测试用例工具中 。
当然它里面包含的要素也会根据文档/工具的不同 ,里面所包含的要素也有所不同 ,但整体上来说差别不大。主要包括基本要素(必备要素)和扩展要素两个部分 。
-
基本要素 :用例编号 ,产品/项目名称,模块 ,测试用例标题 ,前提条件 ,操作步骤 ,预期结果 ,执行结果 。
-
扩展要素 : 输入数据 ,测试用例类型 ,适用阶段以及备注等。
有了这个这些要素 ,即使没有测试用例模板 ,也能很快的构建出来 。当然 ,经常设计测试用例的肯定是对这些了如指掌 。
2.为什么要编写测试用例 ?
那么,回到我们开头的那个问题 ,为什么要编写测试用例 ?它有什么好处 ?能体现在哪里 ? 要想回答这些问题 ,我们可以去找出编写测试用例和不写测试用例它们之间的区别是什么 。从而这个问题的答案 。
首先,设计测试用例的过程是一个高度专注的过程,在此过程中你可能需要借助各种专业的方法、经验以及想象力 ,才可能设计出完备且有效的测试用例集。而这个过程最合适的时机就是找一个尽量没人打扰的时间段进行集中统一设计 。所以把它放在提测前统一设计是最合适的 ,到了执行阶段只负责执行即可。
但是假如这个用例因为其它原因未进行设计呢 ? 那么我们的执行就会变的随机 ,你可以想象一下这样的场景,你一会在想测试点,一会又在执行测试用例 ,一会又在提bug ,甚至还要和同事进行各种的沟通,在这种如此频繁切换场景的情况下,你的测试点还能否保证覆盖度? 其实是一个很大的未知数 。这也是编写测试用例和未编写测试用例的一个最本质区别 。即写测试用例会覆盖度更强 ,而不写测试用例它的随机性会更强,漏测点会更多。
那么,我们所编写的测试用例到底是在覆盖什么 ?很多人会说肯定是在覆盖需求 ,但是我觉得这个答案不够完整 。它应该是:
-
首先,验证每一个功能是否正确,即验证功能的正确性;
-
其次,应该针对每个功能需求进行深入的覆盖,即验证每个功能的深入性 。
-
最后,对需求中的每一个功能进行覆盖,即验证整个系统的全面性
也就是说,我们真正设计测试用例的目的就是为了保证这三个性:正确性、深入性和全面性 。
3.设计时该如何覆盖 ?
所以,一个好的测试用例的特点应该至少包括验证功能的正确性 、验证每个功能的深入性(测试深度)以及验证功能的全面性(测试广度) 。
其中,正确性很好理解 ,这里不在解释,但是深入性和全面性是什么意思呢 ? 或者说在设计测试用例过程中该如何体现呢 ?
先说全面性 ,全面性其实就是指所设计出的测试用例是否包含了全功能的覆盖(功能范围)和全类型的覆盖(类型范围);
而深入性是指针对某个单一功能是否包含了各种方法的覆盖 ,因为归根结底测试用例是由各种方法设计出来的 。
这里面需要说明的是 ,每种测试类型都会有不同的方法 ,掌握方法的多少是决定设计出来的测试用例细粒度的一个主要因素 。这也是为什么我们需要掌握更多的测试方法的原因 。因这个话题太大,我们不在这里说明 。
4.无需求时该如何编写 ?
以上目的是有一个前提条件的 ,就是必须依赖于需求 ,比如说验证产品功能的正确性 ,那么产品的预期结果其实是来源于需求 ,同样其它两个目的也是如此 。但是在现实的工作中,常常会遇到没有需求而编写测试用例的情况 。那么这样的情况下,以上的目的还是否有效呢 ?答案是有的,但需稍作修改 。具体变为 :
-
验证每个功能的正确性 ,依据用户逻辑去判断是否正确 。
-
验证每个功能的深入性 。
-
验证是否覆盖了所有的参考物 ,这里的参考物可以是已实现的系统功能、UI图中的功能,基于这些参考物我们也可以根据经验写出对应的测试用例来 。
通过以上的修改 ,就能兼容有需求和无需求的情况 。测试用例的目的就会变的更加通用。
5.总结
总结一下 ,编写测试用例可以说是一项非常基础的能力 ,我们不仅仅是要知道如何编写测试用例 ? 而且更要知道为什么要编写测试用例 ,也就是知其然也要知其所以然 。在元问题上进行更多的思考,有助于我们提高对事物本质的认识 。
那么,我们编写测试用例的目的是什么呢 ?
-
验证每个功能的正确性 ,依据需求(用户逻辑)去判断 。
-
验证每个功能的深入性 ,从测试方法上去深入 。
-
验证是否覆盖了所有的功能(参考物 ) ,可以从功能的测试类型上考虑全面性 。
知道了测试用例的编写目的 ,也就知道了编写测试用例所要达到的目标 ,从现状作为起点到最终的目标的这个过程就是不断使用不同方法去靠近的一个过程 ,其中两者的差距就是我们提升的空间 。