测试计划与测试策略

2010-04-30  苗志伟 

一、测试策略

测试策略就是如何进行软件测试的计划。

测试策略的目标包括:

  1、取得利益相关者(比如管理部门、开发人员、测试人员、顾客和用户等)的一致性目标;

  2、从开始阶段对期望值进行管理;

  3、确保“开发方向正确”;

  4、确定所有要进行的测试类型。

 

测试策略为测试提供全局分析,并确定或参考:

  1、项目计划、风险和需求;

  2、相关的规则、政策或指示;

  3、所需过程、标准与模板;

  4、支持准则;

  5、利益相关者及其测试目标;

  6、测试资源与评估;

  7、测试层次与阶段;

  8、测试环境;

  9、各阶段的完成标准;

  10、所需的测试文档与检查方法。

 

二、测试计划

软件项目的测试计划是描述测试目的、范围、方法和软件测试的重点等的文档。对于验证软件产品的可接受程度编写测试计划文档是一种有用的方式。详细地测试计划可以帮助测试项目组之外的人了解为什么和怎样验证产品。它非常有用但是测试项目组之外的人却很少去读它。依据特定的项目,在一个测试计划中可能包括下面项目:

  1、标题

  2、软件标识,包括版本/发布版本号

  3、目录;

  4、文档的目的和阅读人群;

  5、测试的对象;

  6、软件产品概述;

  7、相关文档列表,例如需求规格、设计文档和其它测试计划等;

  8、有关的标准和法规;

  9、可追溯的需求;

  10、有关的命名约定和标识约定;

  11、软件项目的相关的所有部门和成员/联系信息/职责;

  12、测试项目组和人员/联系信息/职责;

  13、假设和依赖;

  14、项目风险分析;

  15、测试优先级和重点;

  16、范围和测试限制;

  17、测试描述-根据测试类型、特征、功能、过程、系统、模块等分类;

  18、输入等价类分类描述、边界值分析、错误分类;

  19、测试环境-软、硬件、操作系统、其它需要的软件、数据配置、与其它系统的接口;

  20、测试环境有效性分析-测试环境的不同和产品系统对测试有效性的影响;

  21、测试环境建立和配置问题;

  22、软件移植性考虑;

  23、软件配置管理过程;

  24、测试数据建立需求;

  25、系统日志描述/错误日志/其它的能力和工具,例如屏幕捕获工具、这对于描述bug和报告bug 是很有用的;

  26、讨论任何测试人员用来发现bug或跟踪bug的硬件、软件工具;

  27、测试自动化-采用的理由和描述;

  28、采用的测试工具、包括版本、补丁等;

  29、测试脚本/测试代码维护过程和版本控制;

  30、跟踪和解决-工具和步骤

  31、用于项目的测试度量标准;

  32、报告需求和测试交付产品;

  33、软件入口和出口标准;

  34、初期确定的测试周期和标准;

  35、测试暂停和重启标准;

  36、人员分配;

  37、人员岗前培训;

  38、测试地点/场所;

  39、测试项目组之外可用的资源和他们的作用、职责、交付、联系人和协调等问题;

  40、与所有权相关的级别、分类、安全和许可问题;

  41、公开的一些问题。

605°/6019 人阅读/4 条评论 发表评论

程守标  2010-05-07

请教一下,对于没有需求文档的软件,如何来写测试计划和方案?一个人的测试有必要些测试计划和方案吗?


苗志伟  2010-05-07

程守标: 请教一下,对于没有需求文档的软件,如何来写测试计划和方案?一个人的测试有必要些测试计划和方案吗?
从个人角度,一个人的测试当然计划方案能省则省,但是从项目和公司角度,计划和方案是必要的,一则可以形成项目的知识沉淀,二则更可以通过写计划和方案,指导具体的测试(写的过程会有很多意外收获)。

个人觉得一个没有需求的项目就是对本身的不重视,连需求都没有,拿什么做依据写计划和方案呢?全部裁剪,爱咋地咋地吧!

要是必须写,除非对项目需求有非常深刻的认识,否则写出来的也基本没有意义,用处最多也就是应付应付老板的。


程守标  2010-05-10

苗志伟: 从个人角度,一个人的测试当然计划方案能省则省,但是从项目和公司角度,计划和方案是必要的,一则可以形成项目的知识沉淀,二则更可以通过写计划和方案,指导具体的测试(写的
多谢指导


周文静  2010-05-11

测试暂停和重启标准 这里有没有包括打回,拒测标准呀?如果没有的话,其实可以加上这个.呵呵..个人建议.


登录 后发表评论