接触功能测试已经有三年之久，对功能测试也有自己的一些感触和心得，下面说说功能测试那点事。

　　一、从测试前期工作开始谈起

　　当接到一个新项目时，首先需要做的是了解该项目的测试内容，测试范围，项目周期以及项目目前的进度。根据对项目的了解，综合测试资源，制定出项目的测试计划和测试策略。当项目开发的已经比较完整，可以直接进行系统测试，基本上采取常规测试，系统测试和回归测试进行交替。有些项目，只完成部分模块的开发时，则适合加入集成测试。如果项目时间比较紧张，而资源条件又允许的条件下，也可以进行敏捷测试。根据项目各自的特点，采取佳的测试策略。

　　二、关于模块划分和用例编写

　　关于web测试，大家也都知道，有些功能是基于页面的。当功能和页面相互融合的时候，对于模块的划分不是那么容易了。如果按页面进行划分，比较容易进行任务的分配，操作起来也比较容易控制。但是，每个页面上会出现重复的或类似的功能，出现问题后，容易产生冗余和重复的bug.如果按照功能去划分，可能需要在每个页面上进行重复操作，并且对于web页面的测试，功能也不是很好区分，不是很明显，并且比较散，可能一个操作会对多个页面产生影响。我的经验是，一般情况下，页面划分优先级高于功能模块划分。当然，具体情况还要具体分析。

　　关于用例如何编写，我想大部分的测试工程师都会比较了解，什么等价类划分，边界值分析法，因果图法，等等，大家只管去网上查吧，介绍的有很多。只要有用例的标题，操作步骤，期望结果，基本上都是可用的。

　　三、测试过程

　　当用例编写完成，项目组进行了用例评审后可以直接进入测试执行阶段了。（对于如何进行用例评审，曾经尝试过两种方法，一种是每条逐个评价，一种是只评价用例框架。前者耗时太多，后者细节不够，总是无法找到佳的方式。不知各位看官是否有这方面的经验。）在这个阶段，曾经做过一个关于交叉测试的实验。项目中，有测试工程师A编写完的用例，分配给B来执行，或者，在项目接近收尾的阶段，让团队人员进行互相补充的交叉测试。发现，后者的结果比前者要好。因为前者是将交叉测试放在项目比较靠前的阶段进行，一般情况下，工程师会严格按照测试用例进行测试，很难有时间去挖掘深层次的缺陷。而后者是将交叉测试安排到项目比较靠后的阶段进行，此时，大部分的缺陷已经被挖掘出，可能在进行测试时，有助于思维的发散。

　　四、测试风险评估

　　在测试整体完成后，需要测试负责人对该项目进行总结，编写测试报告，其中必须要做的功课是进行风险评估。测试环境和线上的正式环境还是存在不少差异，有些模块在测试环境下可能无法进行完善的测试，比如数据迁移的问题，比如第三方接口的不稳定。对于测试覆盖不到的地方，尽量在此列出，提醒相关人员的注意，将上线后可能出现问题的风险降到低点。

　　对于功能测试的流程以及每个阶段如何开展，网上的资料已经很多很多，不细说了，上面几点是在工作中，觉得值得注意的几点，希望大家可以共同探讨。