对功能测试的一些思考

　　功能测试可以说是件简单的事情，但是想要做好却并不那么容易。笔者所测的业务是商业化广告相关的CRM系统，整条业务线有18个子系统，很多子系统的流程相当长且繁复，功能逻辑复杂，想要上线后没有漏测着实不容易。不过从我接手以来，有幸还没有发生大的漏测问题。今天笔者就来聊聊自己对于功能测试的一些个人经验和思考。

　　接到需求后，我一般会将需要做的工作分为三部分，分别为：需求分析、测试用例、以及测试执行。当然，有一个很重要的大前提，那就是要足够熟悉你所测的系统。下面就分别来聊聊这三部分。

　　需求分析+设计分析

　　拿到一个需求，第一步应该做的就是需求分析。这个环节很多人不在乎，觉得这不是测试的工作，而是产品应该的工作，测试只是把需求文档简单的直接翻译为了自己的测试用例，当测试过程中发现需求文档不完善的时候说产品没做好等等。但对我个人工作经验来讲，需求分析这一步至关重要，俗话说磨刀不误砍柴工，只有做了详细的需求分析，才能写出有意义的、正确的测试用例，这就是我个人常说的“需求测试”。

　　需求测试的第一步，需要了解做这个需求是为了什么?你可能会怀疑，产品说做就做呗，测试管那么多干嘛?其实了解需求本身的动机在于以下几点：

　　1、有些需求是“一次性”的，对于一次性的需求是否有别的方式来实现，如果有我们则可以不去做无用功。所以需求评审的时候，我们可以提出质疑并给出合理的解决方案，减少“一次性”的工作量;

　　2、更好的理解需求本身，该需求是给什么角色的业务人员使用的，测试可以“站在对方的角度”考虑问题。

　　3、解惑，对于一个需求文档，很多时候测试做不到百分百的理解的，如果没有完全理解需求