GTA： Google实现ACC模式建模的工具
- Attribute 特质：产品特点
- Component 组件：功能模块
- Capability 能力：操作响应
每一个可测能力都可描述为：组件满足特质的一个能力
GTA可生成风险热图
- 颜色区分测试的优先级或者隐私级别
- 清晰的测试依据
风险热图，案例见《Google软件测试之道》90页
其中：红色高风险能力和特质组件对，要编写一系列测试用例
等价划分：把测试案例组合缩减到仍足以测试软件的控制范围
一、静态黑盒测试
测试产品说明书，在编写软件前查找问题
二、动态黑盒测试
不了解软件如何工作的前提下测试软件
1).数据测试
1.边界条件
- 根据边界选择等价划分包含的数据
- 测试最后一个合法数据和超过边界的非法数据
2.次边界条件
- 边界条件位于软件内部(如输入2的乘方、ASCII表)
3.默认、空白、空值、零值、无的等价空间
4.垃圾数据 (破坏性实验，输入要求以外的数)
2).状态测试
- 选一项，软件改变外观、菜单或某些操作，即改变状态
1.建立状态转换图，包含：
- 软件可能进入的每一种独立状态
- 一种状态转入另一种状态所需的输入或条件及结果
状态转换图例，案例见《软件测试》Ron Patton著 58页
其中：
- 每种状态必须访问一次
- 测试最常用(针对用户)及最不常用分支(针对产品及开发)
- 测试所有错误状态及返回值
- 测试状态随机转换
3).失败状态测试
1.竞争条件：多任务同时访问内存、硬件资源等
2.重复、压迫和重负
- 重复：检测内存是否不足
- 压迫：限制软件的必要条件，在不理想条件下运行(内存小、CPU慢等)，检测软件对外部资源和要求的依赖程度
- 重负：尽量提供条件，最大限度发掘软件能力
4).其他测试
在已找到缺陷的地方再找
三、静态白盒测试
通过正式的审查和检查代码的细节
1).正式审查
- 要素：确定问题、遵守规则、准备、编写报告
- 过程：同事审查-->公开陈述-->检验(最正式)
2).编码标准
3).通用代码审查清单
1.数据引用错误
- 使用未经正确初始化和引用方式的变量、常量、数组、字符串
a.是否引用未初始化变量
b.下标是否为整数且在范围内
c.数组下标从零开始
d.应使用常量的地方用了变量
e.变量是否赋于不同类型值
f.引用的指针是否分配内存
g.一个数据结构是否被多处引用并声明
2.数据声明错误
- 不正确声明或使用变量、常量
a.变量长度、类型是否正确
b.声明时是否正确初始化
c.相似的变量名称
d.声明但未引用过的变量
3.计算错误
a.不同数据类型计算
b.编译器对类型、长度不同变量的转换规则
c.是否有计算溢出
d.除数为0
e.精度丢失
f.计算结果是否超过有意义的范围(概率大于1小于0等)
g.运算的优先级，可否用括号
4.比较错误
- 大于小于等于不等于、真假
a.精度是否影响分数/浮点值的比较
b.求值次序
5.控制流程错误
- 循环等控制结构未按预期工作
6.子程序参数错误
7.输入/输出错误
a.软件是否严格遵守读写专用格式
b.外设不存在、未准备好等错误情况是否处理
c.读写过程存储空间占满
8.其他检查
a.是否使用外语、拓展ASCII字符、统一编码取代ASCII
b.是否要移植到其他编译器和CPU
c.兼容性
四、动态白盒测试(结构测试)
看到软件工作方式根据获取的信息对软件进行测试
- 根据代码功能和实现方式确定哪些要测试
- 在白盒测试前，先建立根据说明书黑盒测试案例
- API测试
- 获取变量及状态访问权以便确定结果与预期是否相符
- 估算测试命中代码量和具体代码，然后调整测试，去掉多余补充遗漏
另：测试--寻找软件缺陷、调试--修复缺陷
1.单元(模块)测试、集成测试
- 底层进行的单元测试集成在一起进行集成测试
a.数据流：跟踪数据，在程序运行期间检查立即值
b.次边界
c.公式和等式
d.错误强制：迫使软件所有错误提示信息显示出来，不是检测错误的代码
2.代码范围分析
-
测试程序的状态以及其中的程序流程
-
方式：利用调试器单步执行程序查看代码或者代码范围分析器
a.找出测试案例没有覆盖的部分则其模块代码从未执行，要额外编写该模块测试案例。
b.执行一系列测试但未增加代码覆盖百分比，则这些案例可能处于同一等价区间 -
分支范围：覆盖软件中所有路径
-
条件范围：测试所有可能条件达到分支覆盖、语句覆盖
网友评论