1.1    测试策略和计划

在制定测试策略时，要基于被测软件的质量目标。质量目标就是测试的需求。它们决定了测试的阶段和质量的目标。要想最优化测试的活动并制定一个切实可行的测试计划，需要将被测软件分解成为一个一个的业务功能。在进行业务功能分解时，要以黑盒的方法来看待被测软件的功能，即独立于软件的实现方法。若想计算测试的效果并且保证测试的活动适合于特定业务的需要，则需要引入风险评估的手段。

1.1.1   需求

测试的必要条件是要确定预期结果或者需求。

为了能更好的了解需求，将需求进行分类是非常有帮助的。

以我们的观点，可以将需求分为功能性需求和质量需求（非功能性需求）。

功能性需求描述了在业务上期望如何使用新的软件系统，且该系统中应该包括哪些功能。

质量需求包括的是软件系统的通用特性，且独立于功能。

1.1.1.1             功能性需求

功能性需求以业务设计图的方式记录于文档中。

为了在TestDirector中将需求作为测试的基础，需要将需求导入到TestDirector中。

相应的业务设计图作为需求的附件存在，并作为将来测试活动的依据。

1.1.1.2             质量需求

质量需求由两部分构成，

一部分是为整个产品或者项目定义的质量目标，

另一部分是每个业务功能的质量需求，

这些业务功能的质量需求取决于风险评估的结果。

1.1.1.2.1       质量目标

1）适应性

组件被修改以适应新需求的难易程度。

2）完整性

组件实现所有需要的能力的程度。

3）正确性

a)        组件在规格分析、设计和实现过程中无错误的程度

b)        组件满足需求或者用户需要与期望的程度

c)        基于给定输入产生相应输出的能力，并且这个过程符合或者满足需求

4）有效性

当组件完成指定任务时，能最少使用所需资源的程度。

5）可维护性

组件被修改以纠正错误，提高性能或其他属性，或者适应被改变了的环境的难易程度

6）模块性

软件系统由离散的组件组成的程度，即改变一个组件时能将对其他组件的影响降至最低。

7）可移植性

软件系统或组件能被转移到其他硬件平台或者软件平台上的难易程度。

8）可靠性

组件在一定的时间内、一定的条件下执行所需完成功能的能力。

9）可用性

用户对软件组件的理解和操作的难易程度。

1.1.1.2.2       业务功能的质量需求

业务功能的质量需求是依据业务的风险进行定义的。

业务风险和技术复杂度的信息存储在测试的需求中。

这两个参数决定了测试的程序和测试的工作量。

另外，针对业务功能分配测试员，并且将测试活动的当前状态落实到纸面上。

只有这样做才能在针对业务功能的整个测试过程中监控测试的状态。

 

1.1.2   测试阶段的定义

依据已经定义的质量目标，我们需要将测试阶段进行合理的划分。

通常情况有以下几个阶段：

1）开发员自测试阶段（不在我们的考虑范围之内）

2）业务功能测试（单元测试）

3）业务流程测试（应用级的集成测试）

4）业务集成测试（端到端的集成测试）

5）性能测试

6）系统集成测试

下面的表中描述了每个测试阶段需要达到的质量目标：

 

业务功能测试和业务流程测试是在软件项目开发过程中完成的。

而业务集成测试和系统集成测试则组合成回归测试，用于软件系统上线前或者发布为产品前来检验软件的质量。

1.1.3   质量门

测试是在不同的阶段中完成的。

划分不同阶段的原因就是将不同的质量目标分配到不同的阶段中，从而能将测试的执行尽可能的提前。

所以，在相邻的测试阶段中设置一个质量门就成为保障成功的关键要素。

下面的图中展示了每两个相邻阶段的质量门是如何设定的：

 

 

下面是对质量门的一种详细定义：

1）在业务功能测试之后

u          业务功能测试的测试用例执行了80%以上

u          业务功能测试的测试用例（A级风险）执行了100%

u          少于5个服务器端错误

u          少于30个中级错误

u          无致命性缺陷

2）在业务流程测试之后

u          业务功能测试通过

u          业务流程执行了100%

u          无业务流程完全失效，所有的错误都可以被修复

u          无致命性缺陷

3）在业务集成测试之后

u          业务流程测试通过

u          业务集成流程执行了100%

u          无致命性缺陷

1.1.4   功能分解

在计划测试活动之前，功能分解应该作为第一个要完成的活动。

进行功能分解时，应该邀请业务方面和需求分析方面的代表共同参加。

通常情况下，要遵从下面的原则：

1)        每个用户情形都是一个业务功能

2)        如果一组用户情形非常相似，那它们应该组合在一起形成一个业务功能

3)        如果一个用户情形非常大或者非常复杂，则应该将其分解为两个或者更多的业务功能

进行功能分解的思路体现在“将测试的单元确定为包含少量功能点的单位”，

这样，每个测试单元的测试用例的数量就会被限制在一定的范围之内。

我们可以将分解的目标设定为每个业务功能只有最多30-40个测试用例。

1.1.5   风险评估

既然质量保证的基本思路是降低缺陷破坏业务的风险，同时为了确保质量保证的资源得到充分的利用，我们需要对每个业务功能进行风险的评估。

还要考虑到的是，我们也要对技术影响进行分析。

这样我们能对完成每个业务功能的测试活动所需的工作量进行估算。

 

1.1.5.1             业务风险分析

业务风险评估需要针对被测软件的所有业务功能。

评估的标准应该在整个业务的范围内是唯一的，才能在企业范围内使不同的评估结果具有可比性。

结果 标准	A 高级风险	B 中级风险	C 低级风险
流程的类型	计算/验证	数据的改变	显示
业务影响	合法性	错误信息	无
使用频度	非常频繁	经常	极少
受影响客户的数量	大量/非常重要	查看(968) 评论(0) 收藏 分享 管理 老徐最近翻译的Mercury“最佳功能测试实践”－第一部分 2007-03-04 16:14:42 1       概述        本测试过程作为功能测试的最佳实践，用于实施不同机构的功能测试工作。它可以作为测试计划工作的基础，应用于每个软件开发的项目。在这个测试过程中描述的活动既可以用于新开发的组件，亦可以用于改进现有的回归测试。 2       测试管理 为了能顺利地获得测试的结果，将测试作为独立管理的过程是非常必要的。测试管理可以分为下面四个领域。 1）测试计划 2）测试执行 3）测试控制 4）测试过程改进 用于支持测试管理各个领域的工具可以采用TestDirector。 查看(1288) 评论(2) 收藏 分享 管理 cloudxu 用户菜单 给我留言 加入好友 发短消息 我的介绍 论坛资料 空间管理 我的栏目 软件性能测试 软件自动化测试 企业测试管理 测试职业发展 软件功能测试 软件测试人生 标题搜索 我的存档 2007年04月 2007年03月 数据统计 访问量: 37554 日志数: 35 建立时间: 2007-03-03 更新时间: 2007-04-12 RSS订阅 清空Cookie - 联系我们 - 51Testing软件测试网 - 交流论坛 - 空间列表 - 站点存档 - 升级自己的空间 Powered by 51Testing © 2003-2021 沪ICP备05003035号 Open Toolbar