写点什么

读《Software Engineering at Google》(11)

作者:术子米德
  • 2022 年 4 月 22 日
  • 本文字数:992 字

    阅读完需:约 3 分钟

🤔☕️🤔☕️🤔

  • 读《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

发布于: 刚刚阅读数: 2
用户头像

术子米德

关注

遇见每天的自己,莫忘初心,莫丢念头 2020.03.05 加入

喜欢有的没的,喜欢自言自语式笔记

评论

发布
暂无评论
读《Software Engineering at Google》(11)_架构师成长笔记_术子米德_InfoQ写作社区