标签：测试计划 流程 评审 功能测试 用例 测试用例 测试 bug
功能测试主要流程：测试计划--需求分析--测试用例设计--冒烟测试--测试执行--测试报告--验收测试
一、测试计划
一般来说，拿到SRS之后测试组长会进行测试计划的编写。测试计划的编写主要考虑这几个方面的内容：
首先，明确测试范围。测试的功能模块，以及明确任务的优先级。
其次，人员和时间的安排。需要设计出哪些人员在什么时间做什么事情；本次项目由多少人一起完成；工作的安排，包括工作内容的划分以及阶段职责的划分。而人员时间的划分存在一些客观的影响因素，比如人员规模、技术能力、公司流程、项目时间的长短。
接着，对本次项目的风险分析以及对应的解决方案。这部分需要举例说明具体存在的风险以及对应的解决方案，比如：需求风险、测试用例风险、缺陷风险、代码质量风险、测试环境风险、测试技术风险、回归测试风险、沟通协调风险、人员风险等 。
还有，测试规程、方案的制订。包括文档的规范、测试策略、标准规范。其中文档规范是指：用例的规范、bug的规范；测试策略指测试方法、回归策略；标准规范指bug的等级、bug 的优先级、冒烟通过的标准、回归通过的标准等。
除此之外，测试计划还需要包括测试目的，以及测试计划完成之后需要进行评审。
测试计划评审主要围绕测试目的是否明确、测试需求是否明确、时间安排任务分配是否合理、风险分析是否给出解决方案等方面来进行评审。
二、需求分析
测试计划评审通过之后进入需求分析阶段，这个阶段需要我们熟悉整体的业务流程之后，每个人将自己负责的功能模块进行详细的梳理，梳理出功能点测试点、输出功能矩阵。同时，画出业务流程图。业务流程图包括整体功能流程图和单个模块的流程图。每个人将自己的功能模块都梳理完成之后需要汇总到一起，进行评审，可以采取先内部评审，内部评审通过之后再将开发和产品召集起来一起进行测试需求评审。
测试需求评审主要考察我们对需求的理解是否一致，是否存在隐性需求，功能点是否覆盖完全，测试点的可测试性等等。
三、测试用例设计
需求评审通过之后我们进行测试用例的设计。设计用例的方法有很多，比如：等价类划分法、边值分析法、因果图法、判定表法、状态迁移图法、流程分析法、正交试验法、异常分析法、错误猜测法等等。我们在项目中通常用到的方法主要是等价类划分和边值分析法。当然具体的用例设计方法需要根据实际的业务场景去进行选择。
同时，我们在用例编写的过程中需要注意用例的每一项都应符合我们在测试计划中制定的规范，比如用例的编号、用例的标题需要具有唯一性，用例步骤应该完善、用例优先级的设置需要匹配测试计划中模块的优先级设置。
测试用例的编写原则：系统性、连贯性、全面性、正确性、可操作性。
用例的格式：1.用例编号 2.测试项目/功能模块 3.测试标题 4.优先级 5.前置条件 6.输入 7.操作步骤 8.预期结果 9.执行结果（P/F）
测试用例完成之后同样需要进行评审，在我们项目组，开始评审会议之前我们会对重点用例进行交叉评审，评审人员根据自己发现的问题填写检查表，提出自己的解决建议。针对发现的问题我们修改之后再重新验证，验证通过之后再组织正式的评审会议。测试用例评审主要围绕着：用例的规范、用例覆盖需求是否完全、用例的可执行性、是否删除冗余用例等这些方面进行评审。
四、冒烟测试
测试用例评审通过之后，我们就要开始进行提测之前的准备了，比如需要准备测试数据、或者是开发给到需求变更、SQL变更需要进行阅读。然后在规定的时间内完成冒烟测试。冒烟测试的用例主要是从测试用例中提取主要业务流程、主要功能的一些正向用例来执行。通过的标准至少是主要流程能走通、没有重大问题，或者是跟开发提前制定好冒烟通过的标准（比如用例的通过了90%和功能完成率80%以上。
冒烟测试通过需要回复邮件说明测试结果，如果不通过需要说明不通过的原因以及建议修复的方向同时附上缺陷报告。
五、测试执行
冒烟测试通过之后，进入正式测试执行阶段。这个阶段要做的一个是按照用例优先级由高到低地执行，并且不能轻易跳过用例；二是对于缺陷的跟踪管理。
缺陷管理的工具有很多，我们之前主要用的是禅道。在执行测试的过程中，遇到bug及时、按规范地提交倒缺陷管理工具上，同时按规范填写缺陷报告单，做好优先级、严重等级的划分，方便开发按紧急成都处理和修复缺陷，我们页需要及时跟进，对于修改的bug需要做回归测试。回归测试不仅要考察bug本身的修复，还需考察该bug修复后对于其他模块或者其他流程是否有影响。直到bug状态关闭。
六、测试报告
用例执行完成之后，项目接近尾声。组内需要对项目做总结，组长输出测试报告。
测试报告的编写主要内容包括：项目的基本描述、用例设计的方法、工具的使用。数据统计、测试结论、风险分析等等。其中比较核心的内容主要是数据的统计，比如说用例的执行率、通过率，bug的分布、等级、数量，需求覆盖率等。最重要的是给出测试结论，即测试的结果是通过测试可以上线，还是未通过此次测试需要推迟上线。
测试报告完成需要进行评审，主要围绕测试是否覆盖产品需求上所有功能点，是否给出结论对本次测试做了总结，优先级的安排是否合理分析结果是否正确，是否描述的风险及解决办法等。
七、验收测试
测试报告之后，产品正式上线之前需要进行验收测试。验收测试先是内部测试，通过之后再进行线上公测。验收测试通过的标准是提前跟开发、产品、或者客户代表制定好了的。
标签：测试计划,流程,评审,功能测试,用例,测试用例,测试,bug 来源： https://www.cnblogs.com/Shirleys-Blog/p/15767069.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。