Google软件测试之道

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.执行一系列测试但未增加代码覆盖百分比，则这些案例可能处于同一等价区间

• 分支范围：覆盖软件中所有路径

• 条件范围：测试所有可能条件达到分支覆盖、语句覆盖