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

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

需求分析+设计分析

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

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

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

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

3、解惑，对于一个需求文档，很多时候测试做不到百分百的理解的，如果没有完全理解需求的话，在写测试用例的时候很有可能给出错误的测试用例，或者给出一个粗枝大叶的测试用例，这都不是我们想要的。

4、把握测试粒度，以便于正确评估测试工期。例如，一个是给业务人员做的excel上传功能，一个是给系统管理员做的excel上传功能，两者测试粒度是不一样的。业务人员的功能实现必须详尽准确，并要覆盖各种异常处理，而对于项目系统管理员所需的使用上传功能，大部分时候只要保证正常功能OK，不要求易用性，也不要求各种异常情况处理;

5、绘画需求宏图，只有根据需求文档和原型，可以在脑子里画出系统最终实现的各种功能时，才能够说明真正的吃透了这个需求，这时测试用例自然而然就出来了。

添加图片注释，不超过 140 字(可选)

需求分析的第二步，就是需求中业务功能的实现，一般分为两部分：

一是页面实现，页面上每个模块的实现，每个模块中每个字段的实现，这里我会做一个工作量比较大的梳理，就是每个字段的取值逻辑，具体到数据库-数据表-数据字段，这有的时候可能要在开发做完详细设计后才能从开发那获取;

二是功能实现，哪个页面上要做什么样的一个功能，以及统计各种业务场景，以及该功能使用的数据库-数据表-数据字段以及数据的变化过程。

现在很多项目没有设计评审，这也是目前笔者正在项目内推进落实的一个环节。如果说一个比较大的项目既没有设计文档，也没有设计评审，到最后你会发现，真的好坑啊，专坑测试，有木有~，比如多个开发相互合作但是最后发现确实各自为政，到联调时发现一堆问题，很容易出现延期提测或者提测质量不达标，还比如一期实现不考虑二期三期，到二期三期时发现一期实现有问题等等;像这种情况，测试有多苦笔者就不说了，自己体会吧~~

所以如果没有设计评审，我也会坐在开发旁边跟他核对实现方案，包括实现逻辑、配置文件以及使用的数据库-数据表-数据字段，以及数据整体的一个流转过程，也方便书写测试用例。根据经验，这个时候其实就已经可以发现开发的一些逻辑bug或者需求理解不一致导致的问题，开发在提测前就能对这些问题做一个修复。这个时候问题解决成本很低，而且对测试而言是一个很大的提升机会，能够让测试更加熟悉了解该需求并掌握开发的实现逻辑，有助于测试过程中定位bug产生原因。

测试用例

目前传统的测试用例越来越少，大多数都是思维导图方式写下测试点，笔者写测试用例主要包括四个方面：

1、UI：界面测试，需求要求的各个模块各个元素，以及隐含的各个元素的通用测试用例;

2、业务功能点：对业务功能点的拆分，笔者一般会覆盖所有的业务场景，包括正向和反向的测试用例，也就是尽量覆盖到开发的所有代码分支。

4、配置文件：测试熟悉掌握配置文件，一方面是能够方便自己排查问题，一方面是提醒开发无遗漏配置文件上线(个人经验，作用不大但是很重要)。

其实这四个方面也是我需求分析、设计分析的四个方面，需求分析做完了，测试用例呼之欲出了。目前总结线上问题，通用测试用例遗漏比较多，例如项目之前没有考虑过广告主名称双引号问题，通用测试用例没有考虑各种特殊符号测试，当真的有了带双引号的广告主时，现有平台不支持。至于功能点的遗漏一般比较少，除非产品、开发、测试都不熟悉业务，造成功能点遗漏或者影响其他功能。

执行测试

这里笔者主要讲下个人的经验，每个人的想法和做法不尽相同，仅供参考。笔者一般将测试分为四个阶段测试：

第一阶段：冒烟测试，主流程正向测试用例，不要上来就执行你的详细测试用例，这样你会常常受伤。

第二阶段：就是一轮详细测试，一轮详细测试的时候，按照模块，尽量一次执行完该模块下的所有测试用例再更新代码，不要测试过程中开发修改bug后立马就更新代码，这样你回去验证bug的时候可能打断了你原有的测试思路;个人习惯是，每天早晨更新代码，然后模块测试结束后更新代码。

第三阶段：二轮测试，我一般称之为bug回归测试，对一轮发现的bug进行回归测试，以及bug周边相关功能的再次详细测试;

第四阶段：回归测试，对第三阶段发现的bug进行回归测试(一般比较少，改一个bug带三个bug的开发虽然有，不过也不常见)，以及所有功能的再次详细测试。

作者：多测试11

文章链接：https://blog.51cto.com/u_15239049/5201356