系统集成调试

系统集成调试为什么出乎意料地困难？

• 事实: 软件系统开发过程中出乎意料的困难部分是系统集成测试;
• 两个需要确认的判断: 系统调试花费的时间会比预料的更长; 需要一种完备系统化和可计划的方法来降低困难程度;

为什么要在所有构件能运行之后才开始集成？

• 常见看法: 系统集成调试要求在每个部分都能正常运行之后开始;
• 对立做法一（合在一起尝试）: 认为除了构件单元 bug 还有系统 bug, 越早合拢系统 bug 出现越早;
• 对立做法二（省测试平台）: 用系统各部分相互测试, 避免搭建大量测试辅助平台;
• 对立做法三（文档化的 bug）: 构件缺陷已发现但未修复, 只要测试人员知道后果就可以忽略它们;
• 作者判断: 两种做法都合理但不完全正确; 使用完好的、经过调试的构件, 能比搭建测试平台和进行全面单元测试节省更多时间;
• 反对"文档化 bug"的理由: 调试人员并不了解 bug 引起的所有后果; 对记录 bug 的修复本身会注入未知问题, 使后续系统测试令人困惑;

为什么要搭建充分的测试平台？

• 定义: 辅助测试平台指供调试使用的所有程序和数据, 它们不会整合到最终产品中;
• 规模预期: 测试平台可能有相当于测试对象一半的代码量, 这是合乎情理的;
• 四种形式:

形式	用途
伪构件（dummy component）	只有接口和伪数据或小测试用例, 让未完成模块的位置可以先被测试
微缩文件（miniature file）	只含典型记录但涵盖全部描述的小型文件, 用于验证磁带和磁盘文件格式
伪文件（dummy file）	微缩文件的特例, 实际并不常见
辅助程序（auxiliary program）	测试数据发生器、特殊打印输出、交叉引用表分析等专用工具

变更控制需要哪些受控拷贝？

• 前提: 必须有人负责, 控制和负责各构件单元的变更或版本之间的替换;
• 三个拷贝:
  • 供构件单元测试使用的最终锁定版本;
  • 测试版本的拷贝, 用来进行缺陷修复;
  • 安全版本, 其他人可以在其上修复和扩展自己的模块和子系统;
• 类比来源: 对测试期间的严密控制是硬件调试中一项令人印象深刻的技术, 同样适用于软件;

什么是"紫色线束"手法？

• 硬件场景: System/360 工程模型中发现 bug 后, 立即设计快速修复电路并安装到系统, 使用紫色电线以示区别;
• 完整流程: 把更改记录到日志, 准备正式变更文档, 启动设计自动化流程, 最终在电路图和黄色线路中实现设计调整;
• 软件对应: 对最后成为产品的程序代码, 更需要严密控制和深层次关注;
• 关键因素: 在一个日志中记录所有变更, 并在源代码中显著标记快速补丁与正式修改的区别;
• 正式修改的标准: 完备、经过测试、需要文档化;

为什么要一次只添加一个构件？

• 诱惑: 添加离散构件需要调试伪程序和其他测试平台, 于是被"可能不需要这些额外工作"的乐观主义和惰性诱导;
• 反驳: 必须假设系统中存在许多错误, 并计划一个有序的过程把它们找出来;
• 回归测试要求: 添加新构件后必须用完整的测试用例测试子系统; 原来能在子系统上成功运行的用例必须在现有系统上重新运行;

变更为什么要阶段化？

• 现实: 开发者会不断带来更新、更快、更卓越的构件版本, 替换使用中的构件需要和构件添加一样的系统化测试流程;
• 外部影响: 其他团队把最新集成系统当作调试平台, 测试平台的修改会阻碍他们的工作;
• 处理方式: 变更必须被阶段化并定期发布, 使每个用户拥有稳定的生产周期, 其中穿插测试平台的改变;
• 证据（Lehman 和 Belady）: 变更阶段要么很大且间隔很宽, 要么小而频繁; 小而频繁的阶段很容易变得不稳定;
• 作者实践: 决不会在实践中冒险采用小而频繁的策略;
• 与紫色线束的兼容: 直到下一次定期发布前一直使用快速补丁; 在当前的发布中把已通过测试并文档化的修补整合到系统平台;