Testing - 软件测试知识梳理 - 测试阶段

估算

测试对软件工作量的估算的准确性

测试评估软件系统的状况的准确性

关注点：

不准确的估算

不适当的开发过程

不真实的状态报告

如何知道对工作量的估算是正确的

估算工作量的工具很容易出错

对软件工作量的估算需要策略

五个一般的方法

推测

加入一些约束条件

以一些数据为基础

模拟进行工作

将一些参数模型化

参数模型

回归模型：将现有的参数与已有的历史数据相拟和。

启发式模型：对历史数据进行观察和解释

现象模型：假设软件开发过程可以依据一些更广泛的可适用的过程解释。

模型遵循的共同模式

估算软件的大小

将大小转化成人力的估算，并且作出可能的成本的估算

依据项目的特性进行估算的调整

将整体的估算划分到不同的项目阶段中

估算不包括技巧上面的人力和计算机的运行时间

将以上内容相加

对估算进行检验

检验估算模型的合理性

检验模型是否包含了必须的测试要素

检验模型的正确性

检验估算模型的正确性

重新进行估算:输入是否正确;输入是否合理;对数据的计算是否合理有效

比较延期的估算是否符合项目实际情况

让谨慎的人来作测试验证工作

对软件中的冗余价值估算

影响估算正确与否的因素

软件规模

新设计新代码的比例

复杂程度

设计和编码的困难

使用什么语言

安全性

需求的挥发性

组织因素:项目计划/人员/开发环境/硬件资源/人员利用率/膨胀因素

估算就是估算，不是保证书

追踪测试工作的瓶颈

工作完成点

同配置管理系统紧密的结合

如何使用:模块列表/里程碑/工作完成点

用计算所有工作的完成度来检查系统工作过程。

测试计划

开发测试计划

目标:

详细的描述怎样能成功的完成测试工作，其中应包含必须的资源和实施计划。

可能的不利因素：

没有得到足够的培训

心里准备不足

缺乏测试工具

缺乏管理的标准和支持

缺乏客户和最终使用者的参与

没有足够的时间进行测试

对于独立的测试人员过度信任

版本改变的太快

测试人员处于不受重视的情况中

不能说不

实施过程

听取各方面的意见和建议

标明项目风险:测试要素/联系测试矩阵

建立测试计划

对计划进行评审

建立测试计划

定义测试目标

开发测试矩阵

软件模型

结构特性

批量测试的阶段和用例

为在线系统作概念上的测试脚本

软件测试矩阵

定义测试管理

测试计划的一般性信息

定义测试里程碑

定义管理上的检查点

书写测试计划

评审测试计划

涉及评审的问题

评审测试的开始时间是否会延期

有没有抵触评审的角色

一段时间内是否很难得到工作的检查信息。

更换工具有可能导致他们反感评审工作

评审结果可能会影响对个人的工作评价

对于最终成品的检查

项目的需求规格说明书

软件返工/维护的文档

升级后的技术文档

被更改的源程序

测试计划

用户手册（包括在线帮助）

正式评审中的角色

缓和剂（SQA）

读者

记录者

作者

检测员

正式评审发现的缺陷应包含的信息

起因

类型

分类

级别

评审流程

计划和组织

通篇的讲解（可选）

个人准备

评审会议

修订和反复

需求阶段的测试

测试成本

被设计用来减少测试成本

IBM的数据:大约 60个缺陷/千行;2/3的缺陷产生在需求和设计阶段

在需求和设计阶段发现的缺陷修正的花费最小

修正系统测试阶段发现的缺陷，花费是以上的10倍

发布产品以后，修正缺陷的花费是原来的100倍

生命周期的测试概念

在软件开发过程中持续的进行测试

在尽可能早的阶段点去修正缺陷

需要正式的开发流程来支持

组建测试团队

当开发开始进行的时候，测试就开始进行了

需求阶段的测试

所有的花费都是值得的

大部分缺陷将不会进入到设计&编码阶段

目标

需求正确的表现出了用户的需要

需求已经被定义和文档化了

花费和收益成正比

需求的控制被明确

有合理的流程可遵循

有合理的方法可供选择

准备风险列表

确定风险组

确定风险（风险分析 & 风险检查表）

建立控制目标

确定有足够的控制力度

分析测试要素

需求的设计是否遵循了已定义的方法

提交了已定义的功能说明

定义了系统界面

已经估计了性能标准

容忍度被预先估计

预先定义了权限规则

需求中预先定义了文件完整性

预先定义了需求的变更流程

预先定义了失败的影响

权限定义

需求走查

建立基本规则

选择小组/通报参与者

项目介绍

问题/建议

形成最终报告

设计阶段的测试

设计阶段的测试任务

给测试要素打分

分析测试要素

对设计进行评审

检查修改的部分

交付的产品

输入说明

过程说明

文件说明

输出说明

控制说明

系统流程图

硬件和软件的需求

操作手册说明书

数据保留的策略

分析测试要素涉及的内容

设计了对数据完整性的控制

设计了权限规则

设计了对文件完整性的控制

设计了审计追踪

设计了发生意外情况时的计划

设计了如何达到服务水平的方法

定义了权限流程

定义了完整的方法学

设计了保证需求一致性的方法

进行了易用性的设计

设计是可维护的

设计是简单的

交互界面设计完毕

定义了成功的标准

需要同实际操作者沟通

对设计进行评审

选择评审组成员

对评审组进行培训

通报项目组

分配足够的时间

只对文档化的事实进行评审

和项目组一起进行评审

对评审形成建议

和项目组对建议一起进行评审

准备正式的报告

编码阶段的测试

测试的职责

编码是一个纯技术的工作，几乎不需要用户的参与

项目领导者有参与测试的责任

监督过程的有效性

形成的输出

编码说明书

程序文档

计算机程序列表

可执行的程序

程序流程图

操作介绍

单元测试结果

关注点

完成对数据完整性的控制

定义完毕授权的规则

完成对文件完整性的控制

实现审计追踪

规划出意外情况发生后的处理计划

对系统如何达到预定义的服务水平做了计划

完成了对安全问题的处理流程

编码工作是依据规定的方法完成的

编码与设计相一致（正确性）

编码与设计相一致（易用性）

代码是可维护的

编码与设计相一致（简洁性）

编码与设计相一致（耦合性）

已开发了操作流程

定义出程序成功的标准（性能上）

建议的测试方式

桌面调试

语法上的

结构上的

功能上的

代码互查

建立基本的互查规则

选择互查的team

对成员进行培训

选择互查的方法

提供互查的材料

流程图，源程序，典型的处理流程

对互查进行必要的管理

给出互查结论

提供最终的报告

编码阶段测试需要解决的问题

系统是可维护的吗？

系统说明是否已经完成了？

编码是否按照既有的标准进行，过程是否易于实践？

是否有足够的测试计划用来评估可执行的程序？

是否编制了足够的文档。

测试阶段

在需求，设计，编码阶段多进行一些测试，在系统测试阶段就会少一些问题。

文档

测试阶段的测试计划

测试用例

前期测试的测试结果

第三方测试反馈，例如：计算机操作人员

正式的测试总结报告

测试用例的概念是简单的

建立有效的测试用例是复杂的

设计测试文件

测试用例应当包含合法的和非法的输入

每一个动作只进行一次关键操作

输入测试数据

分析结果

尝试将测试文件违反程序的规则进行输入

典型的测试类型

手册，回归，功能点测试

一致性测试（授权）

功能点测试（完整性）

功能点测试（审计，追踪）

覆盖性的测试（测试的连续性）

压力测试（服务水平）

一致性测试（安全性）

依照预先定义的测试方法

功能点测试（正确性）

支持手册的测试（易用性）

检查（可维护性）

灾难性的测试（可携带性）

功能和回归测试（耦合性）

一致性的测试（性能）

操作性的测试（易用性）

测试总结

测试报告

目标

表示出目前项目的实际状况

明确什么是测试做的工作，什么是不作的工作。

给出系统的操作性能的评价

明确什么时候系统可以进行产品化的工作

关注点

测试报告只有真正需要的时候才有用，需要配合市场和管理

测试的信息是不充分的（对于评价一个项目来说）

测试状况并不能真实的反应个人的状况

测试期间的数据收集

有关测试结果的积累数据

测试任务，测试集合和测试事件的描述

缺陷分析:

由于计划的问题，导致没有发现的缺陷的数据

严重的缺陷

缺陷类型

为什么缺陷没有发现

效果

测试报告

报告目前的软件状态

功能/测试矩阵

功能测试的状态报告，侧重点分析

关于功能的工作时间轴

期望发现 VS 实际发现的缺陷比

没有发现的缺陷和改正的缺陷的差距

按照类型分类，没有改正的缺陷的平均值

缺陷分类报告

测试活动报告

报告汇总

各个阶段的项目测试总结报告

继承性测试报告

系统测试报告

确认测试报告