功能测试心得多篇文章.docx

接触 功能测试已经有三年之久，对功能测试也有自己的一些感触和心得，下面就说说功能测试那点事。 　　一、从测试前期 工作开始谈起 　　当接到一个新项目时，首先需要做的就是了解该项目的测试内容，测试范围，项目周期以及项目目前的进度。根据对项目的了解，综合测试资源，制定出项目的测试计划和测试策略。当项目开发的已经比较完整，可以直接进行 系统测试，基本上采取常规测试，系统测试和回归测试进行交替。有些项目，只完成部分模块的开发时，则适合加入集成测试。如果项目时间比较紧张，而资源条件又允许的条件下，也可以进行 敏捷测试。根据项目各自的特点，采取最佳的测试策略。 　　二、关于模块划分和用例编写 　　关于 web测试，大家也都知道，有些功能是基于页面的。当功能和页面相互融合的时候，对于模块的划分就不是那么容易了。如果按页面进行划分，比较容易进行任务的分配，操作起来也比较容易控制。但是，每个页面上会出现重复的或类似的功能，出现问题后，容易产生冗余和重复的bug。如果按照功能去划分，可能需要在每个页面上进行重复操作，并且对于web页面的测试，功能也不是很好区分，不是很明显，并且比较散，可能一个操作会对多个页面产生影响。我的经验是，一般情况下，页面划分优先级高于功能模块划分。当然，具体情况还要具体分析。 　　关于用例如何编写，我想大部分的测试工程师都会比较了解，什么等价类划分，边界值分析法，因果图法，等等，大家只管去网上查吧，介绍的有很多。只要有用例的标题，操作步骤，期望结果，基本上都是可用的。 　　三、测试过程 　　当用例编写完成，项目组进行了用例评审后就可以直接进入测试执行阶段了。（对于如何进行用例评审，曾经尝试过两种方法，一种是每条逐个评价，一种是只评价用例框架。前者耗时太多，后者细节不够，总是无法找到最佳的方式。不知各位看官是否有这方面的经验。）在这个阶段，曾经做过一个关于交叉测试的实验。项目中，有测试工程师A编写完的用例，分配给B来执行，或者，在项目接近收尾的阶段，让团队人员进行互相补充的交叉测试。发现，后者的结果比前者要好。因为前者是将交叉测试放在项目比较靠前的阶段进行，一般情况下，工程师会严格按照 测试用例进行测试，很难有时间去挖掘深层次的缺陷。而后者是将交叉测试安排到项目比较靠后的阶段进行，此时，大部分的缺陷已经被挖掘出，可能在进行测试时，有助于思维的发散。 　　四、测试风险评估 　　在测试整体完成后，需要测试负责人对该项目进行总结，编写测试报告，其中必须要做的功课就是进行风险评估。测试环境和线上的正式环境还是存在不少差异，有些模块在测试环境下可能无法进行完善的测试，比如数据迁移的问题，比如第三方接口的不稳定。对于测试覆盖不到的地方，尽量在此列出，提醒相关人员的注意，将上线后可能出现问题的风险降到最低点。 对于功能测试的流程以及每个阶段如何开展，网上的资料已经很多很多，就不细说了，上面几点是在工作中，觉得值得注意的几点，希望大家可以共同探讨。 第一篇文章总结：测试用例执行时实行交叉测试方法，A设计的测试用例给B完成，B设计的给A完成，一般是在项目后期进行效果比较好 第二篇文章 测试用例是测试执行的关键，它直接指导如何测试。测试用例的产生源于测试需求，所以在此之前需要把测试需求做好。根据测试需求的分类，在系统功能方面，我把它分成三个集合：界面功能，通用功能，业务功能。任何一个页面的元素都可以分解成这三个集合中的子集或元素。根据这三个集合的特点选择不同的测试用例设计方式。具体的设计可以参考不同的用例模板，对于界面功能，选择简单的模版，甚至列表都可以，因为它们的元素一般都比较独立。通用功能指在很多系统中都会出现的一些常规功能，比如：“上一页”，“返回”，“返回主界面”等，它们有页面的动态变化。在 数据库里的反映，就是最多只涉及单个表格的改动，并不引起表与表之间的连锁反应。它所使用的用例模式可采用现在常用的描述法表示。不过对具体系统中的某些功能点还需要具体再考虑。 　　测试用例设计的重点就是业务功能。对于一个熟练的测试人员来说，界面和通用功能的检查，用例已在他们的心中，并不需要文档指导。业务功能是一个系统的核心，它往往也代表了一个管理软件的价值。业务功能的测试用例模版，我现在比较支持场景法。对主业务流的设计采取全路径的检测，因为他们的节点不是特别多，其它的不再累述。除了对系统正确业务流执行的设计外，还有其它一些设计方法，根据测试人员的不同特点，他们的设计也会有所不同。业务功能的设计在我看来是最能反映出测试设计人员的专业水平。因为它不但需要好的测试技术还需要好的系统相关行业知识。 　　这种用例分类的想法，是为公共用例库的建立策化。为了方便测试文档管理，培养新人，特别是将熟练的测试人员从重复繁重的文档 工作中脱离