当前位置:首页 > 天道酬勤 > 正文内容

测试计划的内容(如何确定测试范围)

张世龙2021年12月22日 05:28天道酬勤1160

很多晋升到测试管理层的伙伴们经常抱有的疑问是,除了自己给其他团队成员分配任务以外,其他事情几乎和自己以前的工作没有什么不同。 特别是在团队中没有比自己更有经验的测试者的情况下,完全不知道测试管理会做什么。

简单地说,无论是做测试运行,还是做测试管理,都是一个不断解决问题的职场。 只是,问题的解决方法和水平不同。

软件测试管理和执行的最大区别在于,后者只需要执行前者分配的任务,无论是创建测试设计、运行用例还是提取测试要求点,都可以在规定的时间内完成并交付任务。 测试管理不仅仅是安排别人的任务就可以了,还需要管理者对为测试团队服务的“客户”和“客户”应该完成的服务非常了解。 (这里的“客户”是指服务对象,例如我们测试团队的服务对象是产品经理,测试交付后需要提交给产品经理接受检查,所以如果通过检查就进入下一阶段,否则这样,测试小组必须明确产品经理提出的检查交货标准、交货功能点列表,以及对其他要求的质量特性。 当然,这里的测试团队的服务对象与内部管理有关,根据情况不同会有不同的“顾客”。 (此外,必须明确当前的测试资源。 例如,有些团队包括测试者在内也是不固定的,如果要成为新的项目团队,则会暂时部署其他团队成员。 因此,需要事先了解有多少测试人员可以投入使用,以及部署的硬件和软件等。 其次是分析产品和可能存在的风险。根据以上情况决定测试任务通常可以与技术负责人协商,记述当前库存的资源、各节点按照项目计划书要完成的任务比例等。 另外,虽然需要事先准备测试战略,但测试战略应该是动态的,要根据项目的进展情况随时调整测试战略。

以上是制定测试计划的基本过程,也是基础信息源。

一般来说,如果公司有测试管理工具,建议直接拥有工具更容易理解和管理维护。 也可以使用在线思维导图和文档,就像TAPD自定义测试计划模板一样。

以常用软件测试计划模板为例,说明如何制定测试计划。

这里主要分为部分:

摘要测试资源和工具测试战略测试阶段的开始/结束标准风险和计划质量目标对应的测试流程管理测试范围定义测试时间表(进度、人员配置)测试成果附录-测试的重点

文档简介

一般来说,测试计划的制定目的、

制作目的需要基于文件阅览者进行制作,如果项目是外包性质的,需要考虑是否纳入检查文件。

测试环境

通常包括硬件环境和软件环境。 请参照下图。

测试工具

所有测试过程中使用的工具。 包括用例编写工具、执行测试工具、缺陷管理系统、需求管理系统等。

测试策略及方法

的典型测试策略包括:

尽量在有限的时间内发现尽可能多的缺陷,特别是严重的缺陷。 同步读取测试计划和要求进行用例设计,需要高度符合产品需求,在要求的指导下,设计更有效的用例逐步完善测试用例库。 测试用例在运行中需要不断修订和动态调整。 测试过程得到控制,保证常用用例的设计方法。

等价类的划分法

将所有可能的输入数据(即程序的输入字段)分割为几个部分(子集),从各子集中选择少数有代表性的数据作为测试用例。

边界值分析法

边界值分析方法是对等价类划分方法的补充。 通常,输入和输出相等的边界是应该着重于测试的边界情况。

错误的推测法

如何根据经验和直觉推测程序中可能存在的各种错误并有针对性地设计测试用例。 错误推测方法的基本思路:列举程序中可能存在错误、容易发生错误的所有特殊情况,并根据它们选择Case。

判定表法

判定表是分析和表达在多逻辑条件下进行不同操作的情况的工具。

判定表的优点是,可以按各种可能的情况列举复杂的问题,避免遗漏。 在一些数据处理问题上,一些操作的实施依赖于多个逻辑条件的组合。 也就是说,对不同的逻辑条件组合值执行不同的操作。 判定表适合处理这类问题。

场景分析法

在业务功能测试领域,场景分析法是最普遍和最主要的设计方法。 首先需要充分了解整个业务。 分析应用场景,从用户的角度设计Case,是面向用户的测试用例设计方法。

测试类型定义如下图所示。

定义缺陷的重要性等级

在此不多做说明,但通常是基于行业标准定义的。 但是,对于业务为主的产品,产品管理者和用户代表需要决定缺陷的重要性,主要是根据对用户使用的影响度进行计算的。

开始/结束标准定义

开始标准和结束标准通常按照公司内部的测试流程确定。 例如,测试交付产品经理和检查是否通过,是否符合定义的质量标准。

中断基准

在软件开发过程中,不可避免地会发生意想不到的原因

目中断,这时测试也应按照提前约定好的暂停,一般存在以下情况时:

软件项目需暂停以进行调整时,测试应随之暂停。

软件项目在开发生命周期内出现重大进度偏差,需暂停或终止时,测试应随之暂停或终止。

若开发任务暂停,则相应测试也暂停。

风险与应对计划

一般包含需求风险、时间风险、资源风险等,需要注意的是,每条风险识别都需要有对应的应对计划措施,至少2条。

质量目标

一般包含产品质量目标与测试质量目标

测试质量目标以下可作为参考:

所有的Case已执行过至少一遍所有严重级别及以上的Bug已修复且测试人员验证通过核心功能不允许有中级及以上的Bug一般功能与终端用户不直接使用的功能不允许有中级以上的Bug缺陷趋势呈下降并接近为0在最后的10%时间内没有发现中级以上Bug

测试过程管理

通常包含测试文档的过程管理与缺陷处理的流程、汇报会议、进度日报形式等。

文档的过程管理如管理人员、存储、移交、分享等需要定义好形式,缺陷处理流程可以以缺陷管理系统中定义好的工作流来说明。

测试范围定义

测试范围可以按照项目计划书的里程碑来提前拟定,如哪个阶段需要进行底层框架的性能测试、是否需要完成接口测试、功能测试中包含哪些功能点等等。非测试范围一般说明不在本次范围内的功能点或测试类型,有时因项目进度原因可能临时对某些功能点进行删减,需要同步更新。

测试排期(进度、人员安排)

进度排期可参考以下几个节点进行划分,可以根据特定节点来划分不同的阶段。

人员与任务安排可以根据前期已整理好的可用固定资源与临时资源调配来作好相应调动计划。

测试交付物

一般一个项目结束后需要交付的测试产物有:软件测试方案、测试用例、缺陷报告、项目测试报告、用户操作手册(若由测试团队提供时)

附录-测试关注点

附录中依据需要可以增加多个附录,如相关术语、缩略语的解释、测试需特别关注点等 。

测试关注点一般由技术负责人、所属产品经理及用户代表提供,可以在测试方案中提前明确以提醒测试人员的注意事项。

如增删查改功能点、数据导入、导出及特定输入框功能的测试侧重点

不能破坏数据库数据的关联和完整检查多次使用back键的情况,在有back的地方,back回到原页面,再back重复多次,检查是否出错修改正在使用的数据;多次连续查询正确性导入数据格式要求不应太苛刻,提示明确数据的动态监测是否正确无误对于日期时间型数据,检查格式正确性以及时间日期的合理性。比如开始时间不能晚于结束时间等重复数据处理,尤其是键值的重复##软件测试##软件测试管理##中国软件#(更多详细内容请关注“木蚂蚁”公众号)

扫描二维码推送至手机访问。

版权声明:本文由花开半夏のブログ发布,如需转载请注明出处。

本文链接:https://www.zhangshilong.cn/work/26830.html

分享给朋友:

发表评论

访客

看不清,换一张

◎欢迎参与讨论,请在这里发表您的看法和观点。