老徐最近翻译的Mercury“最佳功能测试实践”－第三部分
上一篇 / 下一篇 2007-03-04 16:22:17 / 个人分类：软件功能测试
1.1 测试准备
测试的准备是一个独立的、分离的阶段，测试员在这个阶段中基于需求文档准备测试（业务设计图）。
测试的准备要依据标准的方法，并应基于本阶段的工作生成标准化的文档。
1.1.1 业务功能测试
基于风险评估，针对每个业务功能的不同风险级别都应有一个对应的测试过程和方法组合：
1）A级风险
利用等价类和组合进行系统性的测试
完全自动化
2） B级风险
利用等价类进行系统性的测试
完全自动化
3） C级风险
随意性测试
手工执行，在TestDirector中提供文档化的执行过程
对于每个测试过程和方法组合，要提供一个标准的文档进行方法论级的阐述和规定，每个测试人员依据这些标准的测试过程和方法组合进行测试。
在TestDirector中要将测试用例的准备结果作为业务功能的附件。
1.1.2 业务流程测试
业务流程测试是将所有的业务功能组合在一起，使用同一组数据进行工作。
测试员的任务就是要确定每个业务功能的组合是否能连贯的执行。
判断的结果使用矩阵来表示，例如下图：
注：yes（+）；no（-）
业务流程矩阵
1 | 2 | 3 | 4 | 5 | ||
登陆 | 航班 查询 | 航班 预定 | 退出 | 注册 | ||
后功能 前功能 | ||||||
1 | 登陆 | - | + | - | + | + |
2 | 航班查询 | - | + | + | + | - |
3 | 航班预定 | - | + | - | + | - |
4 | 退出 | + | - | - | - | - |
5 | 注册 | + | - | - | - | + |
从上面的表中我们能获得三个业务流程测试案例：
1) 1，2，2，3，2，4，1，1
2) 1，5，4
3) 1，2，3，4
1.1.3 业务集成测试
使用现有的回归测试案例进行业务集成测试。
在第一个阶段，测试案例仅被自动化，而不考虑测试的覆盖率。
在第二阶段，测试案例将被改进，以提高测试的覆盖率。
对于所有的新项目，回归测试应该在业务功能测试阶段和业务流程测试阶段的测试结果的基础上进行建设。
依据业务流程矩阵创建测试案例集，这个测试案例集应该能覆盖被测系统的所有外部接口。
假定我们的被测系统是Mercury的机票预定系统，它的架构图如下：
业务流程矩阵的设计如下图：
在业务集成测试阶段中的测试案例开发 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
1 | 2 | 3 | 4 |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
预定一个航班 | 打印机票 |
相关阅读:
TAG: 软件功能测试 标题搜索日历
数据统计
RSS订阅 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
