功能测试心得多篇文章

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

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

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

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

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

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

三、测试过程

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

四、测试风险评估

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

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

第一篇文章总结：测试用例执行时实行交叉测试方法，A设计的测试用例给B完成，B设计的给A完成，一般是在项目后期进行效果比较好

第二篇文章

测试用例是测试执行的关键，它直接指导如何测试。测试用例的产生源于测试需求，所以在此之前需要把测试需求做好。根据测试需求的分类，在系统功能方面，我把它分成三个集合：界面功能，通用功能，业务功能。任何一个页面的元素都可以分解成这三个集合中的子集或元素。根据这三个集合的特点选择不同的测试用例设计方式。具体的设计可以参考不同的用例模板，对于界面功能，选择简单的模版，甚至列表都可以，因为它们的元素一般都比较独立。通用功能指在很多系统中都会出现的一些常规功能，比如：“上一页”，“返回”，“返回主界面”等，它们有页面的动态变化。在数据库里的反映，就是最多只涉及单个表格的改动，并不引起表与表之间的连锁反应。它所使用的用例模式可采用现在常用的描述法表示。不过对具体系统中的某些功能点还需要具体再考虑。

测试用例设计的重点就是业务功能。对于一个熟练的测试人员来说，界面和通用功能的检查，用例已在他们的心中，并不需要文档指导。业务功能是一个系统的核心，它往往也代表了一个管理软件的价值。业务功能的测试用例模版，我现在比较支持场景法。对主业务流的设计采取全路径的检测，因为他们的节点不是特别多，其它的不再累述。除了对系统正确业务流执行的设计外，还有其它一些设计方法，根据测试人员的不同特点，他们的设计也会有所不同。业务功能的设计在我看来是最能反映出测试设计人员的专业水平。因为它不但需要好的测试技术还需要好的系统相关行业知识。

这种用例分类的想法，是为公共用例库的建立策化。为了方便测试文档管理，培养新人，特别是将熟练的测试人员从重复繁重的文档工作中脱离出来，重点放在如何检查系统上。这种分离是有必要的。此外还有一个特别操作集，源于某些测试人员的非常规操作，范围超出三个集合，但错误对系统的影响很大。这个集合比较小，可以单独管理，用于对系统稳定性的考察。

我有时候觉得系统就跟人一样，没有完美的人，也没有完美的系统，我们只是努力做得更好。

第二篇文章总结：业务测试是功能测试中的重点，比较支持场景法

第三篇文章

万科项目的功能测试已经接近尾声，作为常规项目，与产品化项目存在一定差异，从测试来说，对常规项目与产品化项目所提缺陷的尺度与侧重点也应该是存在差异的，在这一点上，我对自己在万科项目中表现的并不满意。

首先，并未理解常规项目与产品化项目的区别，往往以产品化项目的尺度来要求万科项目在一些方面做出改进。其次，测试过程中没有所谓的侧重点，基本上是广撒网的形式。

那么，作为测试应该如何应对常规项目与产品化项目的差异，并做好功能测试呢？

常规项目

由于是由客户提需求，那么从业务层面上讲，测试人员的业务经验应该是服从于客户的业务需求的，不能作为评判功能是否合理的依据或标准（冻结的业务需求是唯一的标准）。常规项目的测试侧重点则应该放在客户真实的业务场景上，要明白客户如何使用我们的软件，使用软件的哪个功能解决什么样的问题，我们的软件是否真的能很好地为客户解决这些问题？

个人认为常规项目的功能测试安排两轮为好。

第一轮，以主流用户（即客户）的角度测试功能的正确性，在这一轮中，需明确列出客户使用软件的各个业务场景，测试点覆盖所有的业务场景。理论上来说，这一轮发现的问题将会主要集中在跨模块的业务场景中，所以需重点关注跨模块的业务场景。这一轮中发现的问题一般都是功能上的，严重级和优先级都很高，开发和测试需要尽快修复和验证，以保证第二轮功能测试的展开。第一轮的测试效果很大程度上依赖于测试人员对客户需求、真实业务场景的理解和掌握，所以测试人员如何更好地掌握客户的需求和业务场景很关键。

第二轮，以专家用户（即测试人员）的角度对软件的健壮性及容错性进行验证，在这一环节中的侧重点是对异常情况的考虑，例如功能并发、不符合条件的输入、边界值等等。第二轮测试最好能够安排交叉测试，测试人员重点测试自己负责的模块，对其他模块的关注度可适当降低（在工作量上体现），这样的交叉测试的好处是能很轻易地覆盖由于不同人看问题的聚焦点不同而带来的测试盲点。

产品化项目