如何制定测试计划 测试计划( 三 )


与测试人员相比,测试环境更容易理解 。不同的项目可能使用一个共享的测试环境 , 一个专用的测试环境,或者甚至直接使用一个生产环境 。此外,对于一些已经在容器中部署和发布的项目,测试环境会变得更简单、更轻便 。这部分我会在后面的文章里给你详细解释 。
测试进度,在定义了测试范围、测试策略、测试资源之后,就要考虑具体的测试进度了 。
测试进度主要描述各项测试的开始时间、所需工作量和预计完成时间,并以此为基础建议最终产品的上线时间 。比如构建验收测试的工作量、冒烟测试的工作量、自动化脚本开发的工作量、缺陷修复的验证工作量、多轮回归测试的工作量、每轮回归测试的工作量等 。
在传统的瀑布模型中,测试进度完全取决于开发完成和提交测试版本的时间 。如果延迟了测试版本的开发和提交 , 在不削减测试需求的情况下,产品的整体上线时间也会延迟 。
但是在敏捷模式下,测试活动贯穿整个开发过程,大量的测试工作会与开发工作同时进行 。比如采用行为驱动的开发模式,这样测试进度就不会完全依赖于开发提交可测试版本的时间 。
行为驱动开发通常被称为BDD , 即非程序员可读的测试用例可以用自然语言编写,基于自然语言的步骤描述可以通过StepDef与具体的业务操作关联起来 。最典型的框架被命名为“黄瓜” 。
风险估计,俗话说计划赶不上变化,测试也是如此 。整个测试过程很少有完全按照原测试计划进行的 。
【如何制定测试计划 测试计划】通常,需求变更、开发延迟、发现重大缺陷和人员变动是引入项目测试风险的主要原因 。
对于需求变更,如增加需求、删除需求、修改需求等 。,需要重新分析测试需求,确定变化后的测试范围和资源评估,并及时与项目经理和产品经理沟通测试进度的变化 。测试经理/测试负责人千万不要有咬着牙的想法 , 否则对测试团队或产品本身都没有好处 。
另外,随着测试的发展,你可能会发现前期对测试工作量的估算不够准确 , 你也可能会发现需要增加更多类型的测试 。您可能还会发现,由于要修改的测试架构的严重缺陷,许多测试需要完全回归 , 可能会出现延迟提交测试版本进行开发 , 或者人员变更等各种情况 。
所以在制定测试计划时,你要预估整个测试过程中可能存在的潜在风险,以及这些风险发生时的应对策略 。那么 , 当你真的遇到类似的问题时,你就可以冷静而有条不紊地应对这些挑战 。
摘要
软件测试和软件项目一样,需要一个详细的测试计划 。虽然在敏捷开发模式下 , 软件测试不再局限于厚厚的正式的计划文档,但是测试计划的重要性丝毫没有改变 。
一个成功的测试计划必须清晰地描述五个最重要的方面:测试范围、测试策略、测试资源、测试进度和测试风险估计 。测试范围需要明确“测什么”和“不测什么”;测试策略需要明确“先测试什么”和“如何测试”;测试资源需要明确“谁来测试”和“在哪里测试”;测试进度是需要指定各项测试的开始时间、所需工作量和预计完成时间;风险评估是需要知道如何有效应对各种潜在的变化 。

推荐阅读