功能测试可以说是件简单的事情,但是想要做好却并不那么容易。笔者所测的业务是商业化广告相关的CRM系统,整条业务线有18个子系统,很多子系统的流程相当长且繁复,功能逻辑复杂,想要上线后没有漏测着实不容易。不过从我接手以来,有幸还没有发生大的漏测问题。今天笔者就来聊聊自己对于功能测试的一些个人经验和思考。
接到需求后,我一般会将需要做的工作分为三部分,分别为:需求分析、测试用例、以及测试执行。当然,有一个很重要的大前提,那就是要足够熟悉你所测的系统。下面就分别来聊聊这三部分。
需求分析+设计分析
拿到一个需求,第一步应该做的就是需求分析。这个环节很多人不在乎,觉得这不是测试的工作,而是产品应该的工作,测试只是把需求文档简单的直接翻译为了自己的测试用例,当测试过程中发现需求文档不完善的时候说产品没做好等等。但对我个人工作经验来讲,需求分析这一步至关重要,俗话说磨刀不误砍柴工,只有做了详细的需求分析,才能写出有意义的、正确的测试用例,这就是我个人常说的“需求测试”。
需求测试的第一步,需要了解做这个需求是为了什么?你可能会怀疑,产品说做就做呗,测试管那么多干嘛?其实了解需求本身的动机在于以下几点:
1、有些需求是“一次性”的,对于一次性的需求是否有别的方式来实现,如果有我们则可以不去做无用功。所以需求评审的时候,我们可以提出质疑并给出合理的解决方案,减少“一次性”的工作量;
2、更好的理解需求本身,该需求是给什么角色的业务人员使用的,测试可以“站在对方的角度”考虑问题。
3、解惑,对于一个需求文档,很多时候测试做不到百分百的理解的,如果没有完全理解需求