首页 > 功能测试心得多篇文章

功能测试心得多篇文章

发布时间：2023-02-04 17:37:41 来源：文档文库

小中大

字号：

手机查看

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

本文来源：https://www.2haoxitong.net/k/doc/7169fcd726fff705cc170a54.html