读《Software Engineering at Google》（11）

🤔☕️🤔☕️🤔

• 读《Software Engineering at Google》（11）—— Testing Overview

• 📖：@Google，测试就是编程的一部分（Testing has always been a part of programming）。（🤔：这个章节，这篇文章，劈头就是这么一句话。这是在强调，还是在呼喊，似乎两方面都有，但肯定不像是陈述。这是被遗忘了恶行，还是懒惰成性的恶性，一点无奈的情绪，又一言难尽的感觉。）

  🤔：测，不测，验，不验，到底哪壶开，到底要提哪壶。自从听到一个辨析，关于测试与验证的概念差异，毫不犹豫倒向验证。验证，针对我的实现代码，直接验证是否符合设计，这算白盒型验证，间接验证是否符合需求，这算灰盒验证。至于测试，那是针对我的整体实现，直接测试是否符合需求的功能项，间接测试是否符合环境的适应项，这算黑盒测试。这里有一点要说明，关于白-灰-黑的说法，不是直接来自听到的概念辨析，而是间接来自之前的测试相关说法。之所以如此认可和倒向，主要是被棒喝了一下。如果我作为开发实现方，我居然在黑盒测试自己的实现，是不是有点搞笑，甚至有点可笑。对于自己的实现，无论如何都得白盒级验证，才好意思交付出去。更关键的点在于，既然我是实现，那我总是在依照某个设计进行实现。这里不得不补充一点，关于没有设计的实现，我曾经也以为咋就不可。现在，我极度反感，原因就在于，要么是因为想不清楚就去实现，要么就是实现后懒得补充设计，前者是经验不足，或者因为懒惰，后者就是懒惰，或者不负责任。设计如此重要，原因很简单，就是在设计里，同时会包含 How 和 Why 层面的内容，尤其会侧重 Why 层面的内容，而在代码层面，只会包含 How 层面的内容。对于需要维护和改进的系统，更关注当时怎么想，即更需要 Why 层面的内容，才能对下一步的动作做出更合理的决策。回过来说，所谓验证实现，更本质的就是要回答，现在的实现，是否符合依据的设计。如果偏离设计，然后来个黑盒式测试，这是两头落空，还是紧抓设计验证，更符合理性逻辑。

• 📖：测试的一个重要功能，尤其是自动化测试的一个不可忽视的能力，那就是让适应变化，成为一种能力。

  🤔：测试通过，跟自动化测试通过，差别不仅在于自动化节省人力，更大差别在于自动化让每次的测试变得可靠。可靠测试带来的最大好处，并非当下测试的结果可靠，而是让修改变成一件有底线的能力。不会因为一个不小心的改动，而恰好被不稳定的测试过程给绕过去，结果带来噩梦级的灾难。

    —— By 术子米德 @2022.04.19