带着反馈工作，构建安全体系

前言

常用的改动系统的方式：

• 编辑并祈祷，先理解系统，仔细制定修改计划，修改局部，然后修改系统，最后验证修改的正确性
• 覆盖并修改，先建立修改前的安全防护（构建全面的测试覆盖），确保糟糕的改动不会泄漏出去并感染到软件的其他部分，防护建立后，可以安心的修改，并能快速的检测出修改的好坏。

• 通过测试验证正确性
• 通过测试检测变化

软件夹钳：固定住目标软件的大部分行为，只改动那些你真正想要改动的地方。

单元测试

由一组独立的测试构成，其中每个测试针对一个单独的软件组件。这里组件是一个系统的最为“原子”的行为单元。“单元”一般来说指的就是函数,而在面向对象的代码中则指的是类。
测试隔离性
大型测试与单元测试：

大型测试存在问题：

• 错误定位，测试离被测试者越远，就越难确定测试失败
• 执行时间，大型测试需要更长时间来运行。
• 覆盖，当添加新的代码时可能就需要花费可观的工作量来创建检验这段新代码的高层测试。

单元测试优点：
(1)运行快;
(2)能帮助我们定位问题所在。

高层测试

高层测试便是那些覆盖了某个应用中的场景和交互的测试。高层测试可以用来一下子就确定一组类的行为。高层测试也可以理解为特性测试。

测试覆盖

依赖问题： 当一个类直接依赖于某些难以在测试中使用的东西时，这个类就是难以修改和处理的。
需要尽可能的解除依赖。
如果对于某个特定的类来说，不改变它就难以为它编写测试的话，那么转而去测试使用它的那些类往往会简单一些。

遗留代码修改算法

修改步骤：
(1)确定改动点;
(2)找出测试点;
(3)解依赖;
(4)编写测试;
(5)修改、重构。

重点关注：解依赖
依赖存在的问题：

1. 难以在测试用具中实例化目标对象;
2. 难以在测试用具中(调用）运行方法。
   通常在遗留代码中你得先解依赖而后才能将测试安置到位。理想情况下我们为安置测试而进行解依赖的动作本身也应当受到测试的保护