优化频繁变更代码的测试策略与评估

1. 频繁变更代码的测试策略

        Base代码会经常性的新增、调整、修复一些功能。修改的频率可能会高达每日数次。修改过但是未经过测试的代码是危险的，因为它可能包含错误。没有验证过的代码会成为问题和维护问题的温床。因此我们需要定期性的去测试Base代码。

        我们可以肯定地说，未经测试的代码隐藏着潜在的错误，经过测试的代码就意味着它的错误和维护问题更少。但我们不能默认只要经过测试了的代码就一定完全没有问题。可以举个简单的例子：

Uint16 addition(a, b) {

  return a + b;

}

If (3 < addition(3, 4)){

       return true;

}

        上述代码在正常执行时会返回true，但是如果addition函数错误地把加法写成了减法，结果却依然会返回true。

        我们不可能为每个函数编写一个执行它的测试代码，另外如果Base代码中带有测试的代码，有可能会成为定时炸弹。

        因此我们当前的做法主要还是依赖单元测试和集成测试。

2. 测试效果评估与改进点

        我们可以从以下几点得出测试哪些地方做的好哪些地方做的不好。

哪些做得好

1. 影响客户的错误在到达客户之前被识别并修复。

哪些做得不好

1. 团队完成测试的时间晚了一周（并且加班很多）。
2. 找到问题的过程非常痛苦，且可能需要很长时间。
3. 合作伙伴原因和实验室故障破坏了测试结果。
4. 许多较小的错误被较大的错误遮盖。
5. 测试环境有时不稳定。
6. 开发人员必须等到第二天才能知道修复是否有效。

3. 测试的价值

        通常，我们在测试的过程中会遇到很多问题。如果我们遵循着“专注于用户”的原则，我们必须问自己，一个做的不好的测试，如何使用户受益。答案是：

失败的测试并不直接使用户受益。

        如果一个产品能用，那它就能用，无论测试说它能用与否。如果一个产品坏了，那它就是坏的，无论测试说它坏与否。因此，如果失败的测试对用户没有好处，那么什么对用户有好处呢？

修复错误直接使用户受益。

        用户只有在那个意外的行为—错误—消失后才会感到高兴。理想情况下，你有一个可以捕捉到错误的测试（因为如果测试没有发现，用户会发现错误）。但在整个过程中，从开始测试到错误修复，只有在最后一步才增加了价值。

        因此，测试的真正价值在于找出那个错误的点。

        测试过程中，测试人员会反馈告知开发人员功能是否正常。理想的反馈具有几个特性：

1. 它很快。没有开发人员愿意等待几小时或几天来找出他们的更改是否有效。更快的反馈会得到更快的修复。如果反馈足够快，开发人员甚至可能在提交更改之前运行测试。
2. 它是可靠的。没有开发人员愿意花几个小时来调试一个测试，最后发现是因为环境不稳定导致的测试失败。不稳定的测试减少了开发人员对测试的信任。