Test Case Point Analysis-测试点分析
方法简介
测试点通过测量软件测试过程的大小来反映测试活动的复杂度，以此来保证软件达到质量目标。 作为复杂度测量，它需要尽最大努力去反映测试活动的执行，包括测试计划、测试设计、测试执行、测试报告和缺陷跟踪。
测试点分析将测试用例集作为输入来生成测试点。
一个测试用例的复杂度包含四个维度：检查点(checkpoint)、前置条件(precondition)、测试数据(test data)、用例类型(types of test case)。
这个说法是一种有效的假设。
这些维度被分类为两种类型：
- 一种反映测试用例大小，如:checkpoint、precondition、test data。
- 一种将测试点通过不同测试类型的权重(weight)与不同测试类型的复杂度。
方法细节
测量测试用例复杂度
每一个测试用例被设计为一定数量的测试点。这些测试点由一定数量的checkpoint，前置条件的复杂度和用例中用到的测试数据所构成。
checkpoint是测试人员需要在测试中检查目标函数的输出是否与预期结果一致的条件。 一个用例中包含一个或多个检查点。
原则1 ：一个checkpoint被记为一个测试点
Precondition。 测试用例的前置条件指定了测试用例执行的条件。 Precondition和test data一样，主要影响测试执行的成本。 对测试用例而言，一些前置条件会和测试数据构造相关联。
表1：前置条件(Precondition)复杂度等级描述
| Complexity | Description |
|---|---|
| None | 对于执行测试用例而言，前置条件不适用或不重要。 或者，可利用前一条测试用例来继续执行当前测试用例 |
| Low | 执行用例时，一些简单的必要变动。 或者，一些简单的设置步骤。 |
| Medium | 执行用例时，一些明确的准备活动。 比如：一些附加的必要变动。 或者，或一些附加的设置步骤。 |
| High | 执行用例时，需要大量的软硬件配置 |
Test Data。 测试数据用来执行测试用例。 可以产生在测试执行过程中，也可以在测试前通过以前的测试来准备好，或者用测试脚本来生成。 对一组测试用例或者整个系统而言，测试数据可以是通性的，也可以是特性的。 通性的测试数据可以被多组测试用例重复使用。
表2：测试数据(Test Data)复杂度等级描述
| Complexity | Description |
|---|---|
| None | 没有需要的测试数据 |
| Low | 需要一些简单的可以在测试执行过程中产生的数据。 或者，只需要对已有测试数据进行一点点修改。 |
| Medium | 测试数据需要前期刻意准备，并且要保证其完整性、可理解性和一致性。 |
| High | 测试数据需求前期付出相当大的努力去保证其完整性、可理解性和一致性。 使用工具去生成或数据库去存储和管理。 生成测试数据时也可能用到脚本。 |
原则2：每一个前置条件或者测试数据的复杂度都对应一部分测试点。
这种对应方式产生的测试点称为未调整的测试点(unadjusted Test Case Point)
表3：前置条件的测试点分配
| Complexity level | Number of Test Case Point | Standard deviation($\pm \sigma$) |
|---|---|---|
| None | 0 | 0 |
| Low | 1 | 0 |
| Medium | 3 | 0.5 |
| High | 5 | 1 |
表4：测试数据的测试点分配
| Complexity level | Number of Test Case Point | Standard deviation($\pm \sigma$) |
|---|---|---|
| None | 0 | 0 |
| Low | 1 | 0 |
| Medium | 3 | 0.6 |
| High | 6 | 1.3 |
表3和表4的常数来自一份调查，其中调查了18个测试工程师。标准差的值反映了调差结果的偏差。这些估算出来的常数可以更好的反映项目和环境的特征。
通过测试类型调整测试点
表5：各测试类型的权重
| Type of Test | Weight(W) | Standard deviation($\pm \sigma$) | Comments |
|---|---|---|---|
| User interface and functional testing | 1.0 | 0 | 用户图像界面和功能测试是被分析最透彻的基础点 |
| API | 1.22 | 0.32 | 在提供的服务中验证接口的精确度 |
| DataBase | 1.36 | 0.26 | 验证数据库的脚本正确性、数据完整性和数据迁移 |
| Security | 1.39 | 0.28 | 测试系统在黑客攻击、未授权情况下以及不可靠入口的表现 |
| Installation | 1.09 | 0.06 | 测试软件进程完全安装卸载、部分安装卸载和更新安装卸载 |
| Networking | 1.27 | 0.29 | 测试实体与网络间的通信 |
| Algorithm and computation | 1.38 | 0.27 | 验证算法和数值计算在系统中的设计和应用 |
| Usability testing | 1.12 | 0.13 | 测试软件的友好性、易用性，以及系统其它的易用性属性 |
| Performance(manual) | 1.33 | 0.27 | 验证系统是否达到性能要求，假设性能测试是手工执行的 |
| Recovery testing | 1.07 | 0.14 | 恢复测试验证软件从崩溃和其它错误中恢复进程的正确性 |
| Compatibility testing | 1.01 | 0.03 | 测试软件和系统中其它软件是否兼容，比如浏览器、操作系统或硬件 |
最终所有调整测试点(Adjust Test Case Point)的和为:
ATCP=SUM(UTCP*W)
UTCP为UnAdjust Test Case Point
W为Test Case的权重
投入估算
测试活动可以被分成四类：测试计划、测试设计、测试执行和缺陷报告。 在这四类活动中，测试执行和缺陷报告在项目的某个测试用例中会被执行多次。 但是，测量出的测试点规模是分散在这四类活动中的，这样测量的前提是每个活动都被执行一次。 每个测试活动的投入分布允许我们不止一次的来预测测试执行和缺陷报告的执行投入。 每个测试活动投入分布可以通过历史数据来生成。
表6：测试投入分布
| Testing Phase | Description | Percent of Effort | Standard deviation($\pm \sigma$) |
|---|---|---|---|
| Test Planning | 定义了测试范围、测试方法和相关风险。 测试计划同样定义了所需测试资源和初步的测试活动日程表 | 10% | 3% |
| Test Analysis and Design | 处理测试范围和测试目标的细节，评价或澄清测试要求，设计测试用例和准备测试活动必要环境。 这个时期需要去保证测试的各种组合均已覆盖 | 25% | 5% |
| Test Execution | 重复处理测试执行和确认测试计划时期提出的目标，并报告测试结果、缺陷和风险。 这个时期同样包含测试结果分析，比如去检查实际结果和期望结果。 | 47% | 4% |
| Defect Tracking&Reporting | 重复处理跟踪测试活动和缺陷的进度和状态，以及评估当前状态是否达到出口准则和目标 | 18% | 3% |
依据信息和资源的可用性，测试投入可以通过以下简单的方法去预估:
- Productivity Index 生产指数
- Simple Linear Regression Analysis 简单线性回归分析
通过生产指数预估测试投入
Effort = TCP*Productivity Index
The Productivity Index可以通过历史数据来决定
通过简单线性回归分析来预估测试投入
E = A+B*TCP
通过历史数据的代入，可以通过线性拟合求出系数A和B的值。 再将其代入来预估新版本的Effort
总结
软件测试在一个成功软件的开发和维护过程中都扮演着一个重要的角色。 精确预估测试投入是达到目标的一个关键步骤。 为了试图去填补预估软件测试的空白，本文提出了测试点分析的方法，以及该方法如何去计算软件测试活动的规模和投入。 这个分析的输入是测试用例集，输出为每个用例的测试点。
用例作为一个测试人员的产物，需要应用在测试执行活动中。 测试点分析方法一个有力的特性是它可以测量一个用例的复杂度。 这样可以更好的反映测试人员在他们活动中的投入。
另一个优势是通过计取checkpoint的个数，测量前置条件和测试数据的复杂度，决定每个测试用例的类型后，可以很方便的进行应用。
但是，这种方法也有很多限制。
- 限制1：测试点的测量没有经过经验的验证。 需要用到历史项目的测试数据去验证预估软件测试活动投入规模的有效性和可用性。
- 限制2：测试用例中前置条件和测试数据的复杂度范围是否可以正确的反映这些属性真实的复杂度。
日后在该方法上进行改进时需要注意这些限制!!!
网友评论