背景
最近加入了一个创业公司，“惊喜”的发现，公司的整个测试体系基本为0，处在N年以前的测试用例+纯手点式的测试，迭代质量完全无保障，每次上线都要“碰运气”。在大厂多年，从没有遇到这样的难题，每次上线都是一场考验。
和测试聊起此事，测试小姐姐果断的回复，学不会！
因此打算对“测试”这一专题做一次深入的调研，从理论逐步走向实践，欢迎各位大佬点评指教。
为什么要花时间研究自动化测试？
首先要调研之前，得先明确为什么要做这件事，接口有接口用例测试，前端UI测试复杂而繁琐，做这件事的意义和价值到底是什么呢？
拿我司现状举个栗子：
小厂，创业公司，非互联网企业，人均能力一般，人员流动性大，属于项目类，各个现场紧急定制的需求奇多。
这样的一群人写出来的代码是这样的：
A：使用脚手架一个命令行搭建了个项目框架，并写入了工程结构。
B：XX现场来了个需求，好像要在这里加一段if...else...
C：BB现场又来了个需求，好像要在这里再加一段if...else...
一年后，一个方法里面十几个if...else...，有些甚至好像永远走不进去
D：前辈们都走了，现在好像现场这个bug好像是这段代码的问题，但是怎么进入各个分支呀？
C：别问我，我也不知道，我就跟他们学的加了个if...else...
D删了这个条件，某现场替更新程序后当场亡。
D凭空落了个大事故，转正也成问题了，留下了新增的几个if...else...，走人了。
那这和自动化测试有什么关系呢？
如果有了自动化测试，在D删掉那个if...else...的时候，测试结果就会反馈你一个大大的Fail，提醒你可以通过合理的重构去优化这段代码，而不是一键删除。
使用脚本自动运行测试用例，通常只需要几秒就能给出准确的反馈，同时还能侦听代码变化，自动执行项目中发生了变化的代码对应的测试用例，能够极大提高我们的开发效率，同样测试只需要在保障用户完整通过的情况下，做一些主流成的测试和变更功能的验证即可。
研发人员，再也不用怕一两行代码的改动，引起不可预估的问题，不用担心接受一个“烂尾”项目。
而企业，也不用过度的惧怕人员的流动。
测试自动化的好处在于反馈及时，能够极大地提高前端的开发效率。
测试自动化的收益=迭代次数×全手动执行成本−首次自动化成本−维护次数×维护成本
什么是自动化测试呢？
提起测试，大概每个工程师都了解，既是我们的噩梦，又是我们的救赎。
官方解释就是，
测试，就是在已经开发完成的软件之上采用人工或非人工的方式验证软件是否符合工程预期，是否会造成用户/开发商损失等潜在问题的一种方式。
过去很长一段时间，我们编写的前端代码都是开发手工自测，或是提测后由专门的测试人员手工测试，来保证可预判的操作的准确性。
后来随着测试能力的进步，和现场频繁发现的非操作性问题，又引入了接口测试，也就是单元测试，并加入一些压力测试，来保障系统的稳定性，
手工测试+单元测试当然也是没有问题的，但是当项目功能越来越多，全量的手工测试就会成为一个难以完成的任务，而通过自动化的测试工具，可以更加快速高效且准确定位问题所在。
自动化测试实际上是运行一段测试代码，去验证目标代码是否满足某个期望。
测试的层级和分类
自动化测试分为几个层级，如图的金字塔模型，可能很多人都看到过，对应每个层级也有很多开源成熟的框架：
- 单元测试
单元测试是最容易实现的：代码中多个组件共用的工具类库、多个组件共用的子组件等。
通常情况下，在公共函数/组件中一定要有单元测试来保证代码能够正常工作。单元测试也应该是项目中数量最多、覆盖率最高的。
能进行单元测试的函数/组件，一定是低耦合的，这也从一定程度上保证了我们的代码质量。
常见的测试框架有：unittest, Junit, TestNG, Jest, Mocha, Jasmine.....
- 集成测试
集成测试通常被应用在：耦合度较高的函数/组件、经过二次封装的函数/组件、多个函数/组件组合而成的函数/组件等。
集成测试的目的在于，测试经过单元测试后的各个模块组合在一起是否能正常工作。会对组合之后的代码整体暴露在外接口进行测试，查看组合后的代码工作是否符合预期。
集成测试是安全感较高的测试，能很大程度提升开发者的信心，集成测试用例设计合理且测试都通过能够很大程度保证产品符合预期。
常见的测试框架有：unittest+python+requests, RobertFramework, Jmeter....
- UI测试
UI 测试（UI Test）只是对于前端的测试，是脱离真实后端环境的，仅仅只是将前端放在真实环境中运行，而后端和数据都应该使用 Mock 的。
目前UI测试的自动化程度还是很低的，因此这也是我主要想要研究的一个方面。
这个专题会对各种测试框架进行学习和整理，并通过各个指标的考量来选出最适合项目中使用的框架，并对不满足的部分进行封装改造。
