前言

如果没有好的测试习惯，会造成很多可怕的事情：

• 系统直接死掉，使用人数归零，被迫加班。
• 旧的东西改不动（不敢改）、新的东西加不进去（太复杂），只好花个几年重写。
• 使用者给负评的比例越来越高，却不知道产品哪里坏掉。
• 修这个坏那个，洞永远补不起来，而且每一次都是流程走到很後面甚至是交到使用者手上才知道。
• 还有很多。

所以，身为工程师，我们要尽量完善测试的流程以及涵盖的范围。

测试的种类

软件工程中，测试的种类非常多种，
光是测试的人是否知道 code 的结构或流程就能分为 黑箱测试 与 白箱测试。

也可以用流程来分：单元测试 -> 整合测试 -> UI 测试。

甚至也有直接找使用者来操作，以观察是否容易上手的 可用性测试。

就算把本来好好的程序码改坏了，也有 回归测试。

另外，也有先写测试再开发的 测试驱动开发（TDD）。

不同公司的测试方式

不同规模的公司与合作模式，有着不同的测试方式：

• 小公司：可能不会请测试工程师，专案经理（PM）可能会做简单的 验收测试。
• 大公司：可能会有测试部门专门处理各种大大小小的测试，这种情况下，我们要做的可能就只有上面提过的 单元测试。
• 结案公司：客户除了要产品以外，也会要求测试。
• 商业合作：如果是商业合作，对方经常只有他们内网才有的环境、他们尚未公开的机种，这时候可能就要尽量模拟对方的环境，然後交由对方测试。
• 资安测试：通常是比较大的公司、需要安全性高的 app、用户量大的产品，才会做资安测试，会找外面资安/骇客竞赛得奖的队伍假装骇客，破解产品，这是不同於开发人员与测试工程师的领域。

时程规划

测试是很容易被忽略的一环，
尤其是公司没有测试部门、时程压力大的时候，
所以，我们在产品规划前期的时候，
就必须保留以下时间：

• 写各种测试。
• 交付测试、等待测试的过程。
• 修正测出来的一堆问题。
• 给 UI / UX 设计师做 design review（这是很容易被忽略的一点）。

这些时间不是固定的，而是看专案的大小、功能的复杂度来预估。

大致流程

• 专案经理给出 需求书（PRD） 後，测试工程师按轻重等级列出所有需要测试的项目。
• 开发人员 code freeze 後开始测试。
• 测试完成後，按严重程度开始进行修复，并反复进行修复与测试。
• 工程师与专案经理共同决定修复程度，因为有些问题很难踩到，却很难修复，所以可能会先上线再补。

结语

每一家公司、不同专案，甚至每一项功能的开发，都有不同的测试流程与方法。
测试的情境多得数不完，如何在壮大测试的堡垒时，避免没必要的测试覆盖率、以及保持弹性也是值得思考的。