软件测试培训

400-111-8989

热门课程:

软件测试培训 > 软件测试教程

测试用例的重要作用

发布：软件测试培训
来源：软件测试教程
时间：2017-02-10 15:09

一般来说，测试编写用例是在需求评审结束，项目立项后，那这个测试用例编写是否必要?当然是必要的!很多测试人员会觉得测试用例的编写是很浪费时间，因为最后提交测试执行时很难按照预先编写的测试用例执行。

测试很难按照预先编写的用例执行，最主要的原因是：在需求评审阶段没做好或者根本就没有做需求评审，造成开发，产品和测试三者之间没有对需求达成一致的理解，也可能需求不完善，不明确，有疑问点等，在编码过程中还在不停的变更需求。

但是这并非是不可控的，至少可以控制在可接受范围内，这里可能又得花费很多时间去聊需求评审的必要性和重要性，明显不是我们现在想要聊的内容。对于研发团队来说，即使有详细的需求评审流程，但是往往测试人员在去编写测试用例时，为了使用例能尽可能的覆盖到更多的测试点，会不停的从各种角度的去理解需求，还是常会发现需求的一些遗漏点，疑问点，然后通过及时的沟通，可以及早的发现问题，减低研发过程的风险，减少用例编写完到最后执行用例期间变动，这样编写用例的过程反而有助于测试理解需求。

编写用例还有很大的好处就是避免盲目的执行测试。用例就像是一本剧本，测试员可以根据剧本的设定能对被测系统做到较为全面的测试。

编写测试用例是必要的，编写测试用例时用例的粒度也是一直有争论的。如果你在一家传统软件公司，那么你拥有充足的时间去设计你的测试用例，那么我建议你的用例能尽可能描述详细，不停的修复、补充、完善。

然而在大多数互联网公司，基本都走敏捷，讲究小步快跑，快速试错，基本上产品迭代非常频繁，给我们测试留下的执行测试的时间就极短，写用例的时间就更短了，这时我们就不得不在某种程度上做个妥协，简化测试用例，不再对每一条用例做详细描述，或者说我们更多的是写测试点。然而这里还是建议遇到比较复杂的流程时，还是能尽可能用例描述详细。测试点不表示不需要考虑各种用户场景，而是尽可能通过一句话能描述出这个场景的概要，这样测试人员在了解需求的前提下通过这么一句话概要就可以清楚知道需要执行那些用例，这对测试员的要求会相对更高点。

用例写多了，总会发现很多功能模块是类似的，例如查询功能，翻页功能，文本框校验，时间控件校验等等，这时可以学学编程思路，某段代码多处用到，那么就提取成一个公共方法，供各个地方调用。同样编写测试用例时，你也可以提取类似的测试用例，形成一个用例库，供相同的功能模块引用。

达内软件测试培训专家建议，在编写用例之前和准备执行测试时，找开发聊聊开发是如何实现这个功能。通过个人的积累发现，跟开发聊实现很容易从开发的设计中你可以把握到测试的注意点，并记录体现在用例中。例如A开发曾经用某种方式做了a功能，出现了某个bug,现在B开发用了同样方式实现，那么极有可能之前的bug这次还会出现。

产品走迭代，测试用例同样也需要迭代。这就关系到测试用例的管理。如果用例走迭代，每个新迭代都居于上个迭代的用例上做增删改。例如假设我通过excel来管理我的用例，那么我每次新迭代开始时，我就复制一份旧的用例，居于复制而来的用例上做修改形成最新版的测试用例，这样我既能保留以前迭代的测试用例(可便于功能回溯)，又可以有一个完整的当前系统的测试用例。

最后，用例评审也是非常必须的，特别是一些经验老道或者业务熟悉的老司机，可以在用例评审上快速的帮忙指出用例的遗漏点，有助于测试人员打开思路，尽可能多的覆盖用户场景，值得注意的是用例评审上遇到不确定的，应立即记录下来，结束后及时找相关人员确认，避免猜测。