测试&测试优先编程

软件测试与测试优先的编程

Testing and Test-First Programming

对应讲义第二节内容

请神，然后怀念衡水的大白纸

• "测试优先“的思想与意义
• 用等价划分与边界值分析方法为模块设计测试用例
• “覆盖度” - 测试用例对代码测试全面程度的度量
• 对各种测试的初步了解

目录

• 软件测试与测试优先的编程
  • 软件测试
    • 静态与动态
  • 测试用例
  • 测试优先编程
  • 单元测试
  • 黑盒测试
  • 白盒测试
  • 代码覆盖度
  • 其余

软件测试

测试：提高软件质量的重要手段 可以确认软件是否可以满足用户的需求（可用） 侧重于系统某一侧面的质量特性

无法确保软件百分百无错——>残留残缺率：每一千行代码的漏洞数目

1-10错误/千行 典型工业软件

0.1-1错误/千行 高质量验证 eg.Java基础库

0.01-0.1错误/千行 最佳安全验证 eg.NASA设备使用的程序

再好的测试也无法证明系统不存在错误

测试目的：破坏，证错，负能量

测试发现错误，调试修正错误。

基础测试类型：单元测试、集成测试、系统测试

（负责范畴及相互关系）

系统测试之后，面向客户，最终的————验收测试

静态与动态

静态测试 vs 动态测试：区别在于是否实际运行软件系统来发现错误。

静态：代码走读、文档评审、程序分析。常用技术有控制流、信息流和数据流，实际操作中用得最多的是对文档进行评审

动态：通过有效的测试用例，对应的输入/输出关系来分析被测程序的运行情况。

测试用例

def: 输入+执行条件+期望结果

优秀的测试用例要：最可能发现错误 不冗余 具备最佳特性 复杂度适中

测试优先编程

测试带动编码，先写用例再编码

一般流程：分析->写下各方法规约spec->按规约写用例->编码->测试->发现漏洞->修复->迭代直至通过

更节约调试时间，随写随运行，检测软件效果

单元测试

• 有效地测试某个程序模块的行为，隔离其他模块进行，易于定位漏洞，是未来重构代码的信心保证。
• 测试用例要覆盖常用的输入组合、边界条件和异常。
• 代码本身要非常简单，如果测试代码太复杂，那么测试代码本身就可能有bug。
• 通过单元测试是程序有漏洞的必要条件。

使用Junit完成自动化的单元测试：assertArrayEquals,assertEquals，assertFalse,assertNotNull,assertNotSame,assertSame,assertTrue,assertThat等。

单元测试编写测试类目录与实际项目源码目录要保持对应关系。

黑盒测试

检查代码功能，不关心实现细节，检查程序是否满足规约（前置后置条件等）

• 等价类划分：每个参数根据要求提取多个维度（长度大于/小于/等于阈值，前几位数据满足格式要求/不满足格式要求...等等），若干个维度做笛卡尔乘积，得到测试输入空间中的全部等价类

• 边界值分析：Boundary Value Analysis，对等价类划分方法进行补充，将边界作为等价类之一进行考量。（如对输入字符串长度限制256，则需要这样划分此等价类维度：最小值0，略高于最小值的值1，任意中间值，略小于最大值的255，最大值256和略高于最大值的257）因为不存在比0更小的长度值了，如果有类似情况还要取略低于最小值的一个测试空间

课内例：

• 两种覆盖策略：笛卡尔积全覆盖（直接组合多个划分维度上的多个取值，每个组合对应一个等价类，一个等价类对应一个用例）和取值最小覆盖（每个维度的每个取值被至少一个测试用例覆盖一次）

  tradeoff:测试完备性/覆盖度与测试时间代价
  
  课内例：
  

白盒测试

考虑内部细节，根据程序执行路径设计测试用例（基本路径法，绘制程序流程图，确保流程图中每条基本路径至少被执行一次）

扩展：

代码覆盖度

已有测试用例对源代码测试的覆盖程度（我的测试用例运行后能调用源代码里多少个类/多少个方法/多少行代码？它们占比多少？）

覆盖分类同白盒测试的扩展内容，一般认为路径覆盖测试效果最优，也最困难（路径数目庞大）。

实操：实现设定覆盖度标准，逐步增加测试用例数目，直至达成标准

其余

自动测试：自动调用被测方法，判定测试结果，计算覆盖度，现代IDE插件基本可实现(Junit、Code Coverage For Java)

≠自动生成测试用例

回归测试：修改程序后重新执行全部测试用例（可自动化过程）

测试优先调试：对调试发现的漏洞及时编写新的测试用例，加入测试类根目录

注意在测试类中记录测试策略：

---

结束