测试：IT行业里被轻视的小可怜

你是怎么看待测试的？

做IT的同学们都很熟悉测试这项工作，而真正重视测试这项工作的人并不多，包括我自己做开发多年，对于自己写的代码也很少写单元测试，更不要提TDD测试驱动开发的理论了。记得在第一次接触TDD是在刚毕业时的第一家公司里，那个时候公司的书架上有一本《TDD测试驱动开发》，第一感觉是“”这特么是什么鬼东西，说的这么玄乎！”。经过同桌的解释，我第一次了解了通过写单测来驱动开发这样一种开发模式，记得那会儿还有敏捷开发、极限编程各种词汇，那是2013年。
如今已经是2021年了，不知觉自己成了职场老白兔了，或者老油条也行吧！这么多年，对待测试的态度其实并没有太大改观，只是过往经历中有一些别人说的话让我印象深刻。
那是一家互联网+半国企的企业，记得当时一旦出了生产问题，开发同学总想甩锅给测试，而测试觉得委屈的一匹，但部门领导的一句话让所有人都乖乖听话了，他说“除了问题，开发就是第一责任人”。后来，开发再也不敢甩锅了，但同时每次开发上线都是一身冷汗！
还有就是过往公司里，对那些能测试出版本问题的测试同学，都不禁要竖起大拇指，觉得他们帮了自己，更觉得这哥们不太好忽悠，以后得认真点，哈哈！这当然是玩笑！
最近在搞测试质量提升的事情，也有一些感受，这里分享出来给更多人品评一下，相互多交流，一起进步！
我在《微服务设计》这本书中看到了关于测试很不错的理论工具，一个是Brian Marick的测试四象限，一个是Mike Cohn的测试金字塔。下面就介绍一下。

Brian Marick的测试四象限

这里引用书中原话：

“处于象限底部的是面向技术的测试，即那些首先可以帮助开发人员构建系统的测试。这个象限里的测试大都是可以自动化的，例如性能测试和小范围的单元测试。相对而言，处于象限顶部的测试则是帮助非技术背景的相关人群，了解系统是如何工作的。这种测试包括象限左上角的大范围、端到端的验收测试，还有象限右上角的由用户代表在UAT系统上进行手工验证的探索性测试。”

Mike Cohn的测试金字塔

Mike cohn在原始模型中将自动化测试划分为单元测试、服务测试、和用户界面测试三种。越靠近金字塔顶端，测试覆盖的范围越大，同时对被测后的功能越有信心。缺点是由于需要更长的测试时间运行测试，所以反馈周期会变长，并且当测试失败时更难定位是哪个功能所破坏。越靠近金字塔底部，测试运行时间越快，所以反馈周期也会变短，也更容易定位是哪里出了问题。

• 单元测试：通常只测试一个函数和方法调用，TDD写的测试就属于这一类。在单元测试中我们不会启动服务，并对外部文件和网络连接的使用也很有限。单元测试是帮助我们开发人员的，是面向技术而非面向业务的，我们希望通过它来捕获大部分的缺陷，主要目的是对于功能是否正常给出快速反馈。

• 服务测试：服务测试是绕开用户界面、直接针对服务的测试。在独立的应用程序中，服务测试可能只测试为用户界面提供服务的一些类。对于包含多个服务的系统，一个服务只测试其中一个单独服务的功能。为了把这个单独的服务保留在测试范围内(与其他服务隔离）可能需要给外部依赖服务打桩。服务测试比简单的单元测试覆盖范围更大，因此测试失败时也比一般的单元测试更难定位问题。

• 端到端的测试：端到端测试会覆盖整个系统。

测试的意义在哪里

测试真的能搞定所有bug吗？是人都知道不可能，测试的意义究竟在哪里？前几天一直在思考这个问题，如果不明白这个道理，后果自己脑补。
我觉得，错误不可避免，但可以降低出错的概率，也可以让错误的暴露提前，还可以让错误出现在成本最低的时间和场景中。所以，测试的本质是控制错误，而不是避免错误！

引自：《Scrum 敏捷软件开发》、《敏捷软件测试》、《微服务设计》