质量之于产品的重要性不言而喻，在软件开发中，产品在持续迭代时也必须要保证产品的稳定性，不能因为某次版本升级、重新部署等原因导致软件不能正常使用。这就需要诸多测试来保证新增的feature没问题、现有的功能也没有受到影响。作为一个软件开发工程师，在软件的开发周期中必须时刻存在质量保证的意识。
从开发过程中的触及顺序来看，可以大致分类为单元测试（Unit Test，UT）、功能测试、回归测试(regression)、性能测试等。有些公司在应用上线之后还会有再次的功能/回归测试，自动的或人工的，不一而足。下面简单粗暴的介绍一下这几种测试类型，若有勘误，还请指正。
单元测试
一个单元可以是一个方法或者一个小组件， 重点是对该单元来说指定的输入应该能得到给期望的输出。除了保证该最小单元的正确性，单元测试用例有时也可以作为该单元的使用手册，因为在测试用例中该单元依赖的外部条件、传入参数，都必须在测试之前明确。
关键字： 输入、给定条件、输出值。
前端组件的UT（React）: JavaScript Testing utilities for React
后端语言的UT（Go）package testing
推荐阅读：在Go中编写健壮的代码：构建一个不能挂掉的应用，涉及了Golang中的Unit/component test, regression
功能测试
这是从客户/PM 的角度出发，看功能/设计的具体实现情况。比如，在web应用中，对table header中的某一列击排序按钮，（发送请求）出现loading 状态，（返回数据），结束loading状态，展示排列好的顺序。这除了输入数据/事件（点击），输出（按某种规则排好序的数据，展示正常），条件设置（按什么排序），还要关注中间过程（loading 状态）。
关键词： 输入、输出、执行条件、执行过程
回归测试
回归测试就是为了测试新添加的代码不会给现有功能带来影响。对于web应用而言，回归测试通常就像我们/客户操作UI 的使用情况，人工的方式就是拿着鼠标点点点，看页面格式、数据、逻辑是否正确。回归测试因为是要保证现有功能工作正常，所以是端到端的测试（前端到后端，走过完整的数据流）。正因为其端到端的测试特点，测试时需要部署一套完整的环境，后端需要mock数据或者能够返回指定的数据，前端需要有足够的操作行为描述。因为每一种事件也都会触发对应的输出，所以用于回归测试的自动化工具还是挺多的。
在这儿给出一个我之前用过的用于回归测试的工具：Cypress: A complete end-to-end testing experience.。 去年使用它时，它还没开源出来呢，只有工具与文档，还踩了不少坑。😉 公司现在项目中使用的是
Cucumber: a tool supports Behaviour-Driven Development (BDD)，使用平白的语言描述一种行为，case 比较自解释。
关键词： 全量环境部署、后端数据 、足量的前端行为描述case、expected output
性能测试
在软件交付客户使用时，有个关乎性能的指标测试，叫SLA（Service Level Agreement），就是对性能各个指标的约定。对测试点的考虑一般从3个方面考虑：速度、容量/扩展、稳定性。
对性能测试，通常有以下几个共同的测试指标：
- 响应时间(95%,avg)
- 时延
- 错误率
- QPS( query per second)
= PV*0.8/(seconds_one_day * 0.2) - TPS( transactions per second)
- 技术支持是否24小时？
- Resource usage(CPU, memory, bandwidth...)
除此之外，性能测试还会关注： 系统容量（并发量）、健壮性（很多用户同时访问某一功能/集成时能够持续正常工作）等。
与regression 不同，性能测试需要准备大量的数据以支持压力、容量测试，所以测试数据的获取会是首先需要解决的问题。
