首先从一段真实经验讲起，这是一段悲凉的经验。数年前的老雇主盯上了一块大蛋糕，欲基于开源项目研发一套平台级此外办理方案。当时抱负崇高，但履历很缺乏，步子迈的大，扯的蛋也很疼。任务紧张怎么办？各人一起来做需求，所以早中期无力构建一套 CI／CD，每当提交接码时，手工(简朴的)验证下即可合入。对付一个千万行代码级别平台来说，内里各种依赖，数百路人马的代码合入一起，功效实在太美。首先几百个 API，假如没有自动化测试，手工验证的效率极其低下，包围率也很是低，质量难以担保；其次，各路人马交错合入，不经意间相互影响了对方的逻辑，竟然多次呈现如接口都对不上的初级错误，甚至连一个可行的开拓测试情况都搭建坚苦，大量的时间淹灭在定位问题和扯皮上。即使恒久高强度通宵，不变的版本依旧迟迟难产，交付日期一拖再拖再再再拖。

固然能领略任务紧张，更大白平台级此外软件研发自己就布满挑战。可是忽视自动化测试(CI)的行为为今后低效疾苦的研发埋下了伏笔，捡了芝麻丢了西瓜。

为什么需要测试

那么为什么需要自动化测试，更详细的说，为什么合入代码前，必然要跑通测试用例，甚至增加测试用例？原因主要有两点：

个中第一点是最重要因素。试想，在一个较大的项目里，你还记得一个月前写的代码吗？你还记得小同伴们提交了什么代码？你知道这一处代码对上下游的影响吗？这时，昆山软件开发，自动化测试的长处就显而易见了，它能在较短的时间内确定本次 commit 对整体逻辑的影响，假如自动化测试用例全部跑过，意味着它影响其它部门业务逻辑的概率就很低。假如说我们在建一座大厦，自动化测试则担保了每一块砖，每一粒沙都是通过质检要求的。

《快速软件开拓》指出：“修改一个 bug 的价钱是在 bug 发生时修改它的价钱的 10 倍。” 本人甚至以为，对付一个较为巨大的系统，价钱远远不止 10 倍。磨刀不误砍柴工，在研发流程中，自动化测试就是一把尖利的宝剑，它在必然水平上高效的担保了合入的代码的靠得住性，它是快速迭代的基本之一，最终晋升了研发效率，担保产物质量。

防火胜于救火，昆山软件开发，我们要通过多种手段只管制止 bug。营造一个循序渐进，有成绩感的开拓状态；制止搞出一坨 shit，人人充当救火队员。

测试的分类

从条理的纬度，可以将测试分为三类

单位测试(Unit Test)是面向函数级此外测试用例，由开拓人员编写，测试某个可能多个函数的成果。单位测试情况应该容易搭建和运行，运行时一般不依赖其它的处事：如数据库，缓存，第三方处事等，所以在发生其它依赖的处所往往需要 mock 框架，如此有利于晋升开拓效率。单位测试注重包围率，凡是环境下，70-80% 阁下的包围率往往满意绝大部门场景。

集成测试(Integration Test)是面向 API 级此外测试用例，由开拓／测试人员编写，测试一个可能多个 API 的成果是否正常，多个组件之间是否相互共同，正常事情。集成测试情况的搭建相比拟力巨大，它大概依赖数据库，缓存，第三方处事等，一般为各人共用。

机能测试(Performance Test)主要用于测试机能，阐明机能瓶颈等，属于高级此外测试雷同。受多种条件影响，差异应用的机能测试方法各有差别，在此不多展开。

凡是环境下，每次 commit 都应该先跑通单位测试和集成测试后才气提交 merge request。每次宣布上线时，必然要确保宣布的版本能通过单位测试和集成测试，某些应用甚至要求跑通机能测试。

什么时候更需要测试

项目标焦点水平

不问可知，越是焦点的项目，越是需要测试用例担保其代码质量。

代码量

整个项目标代码量越大，越需要测试用例来保障其质量。代码量越大，意味着越难以熟谙所有的逻辑，每次 commit 带来的不确定影响越大。小我私家认为，当成果代码在数千行内，自行抉择是否需要测试；当成果代码高出 5000 行时，请补上单位测试，对付有 API 的应用，请增补集成测试。

开拓人员数量

开拓人员数量越多，越需要测试用例。当开拓人员越多时，出格当程度条理不齐时，会极大的增加相同本钱，低落研发效率，增加引入缺陷的机率。所以研发人员越多，越需要一个自动化门槛，滤那些低质量的 commit。

编程语言