该文章同步发布於：我的部落格

测试的种类

既然要介绍 RSpec，就不得不提到测试的种类，根据下图我们可以将测试的种类分成四大类

Unit Tests

专注於测试程序之间每个功能在切碎後程序码，就像 一个 Class / 一个方法 / 一个物件 / 一个模组 等等 ...

每一个小单元被单独做测试，也就是不受到任何干扰或是其他有关系的程序码影响，专注在我们设定的小目标上面，确保他的测试成功。

这时还是非常初期的测试，所以他才会被放在金字塔的底部，代表他是整个测试的基底。

这时候的测试还非常好写，而且很快又很简单，是最快乐的时候！可以一直看到绿灯亮起，觉得人生很美好

Integration Tests

这时候的测试比 Unit Test 稍微复杂了一些，我们需要整合一项稍微完整的功能，记住，这时候的功能也只是整个应用程序的小螺丝而已，可以把刚刚介绍的 Unit Test 想像成制作螺丝的原物料。

这时候的整合测试的目的就在於检验这些原物料到底组装起来能不能变成一个小螺丝，有时候每个 Unit Test 都能够通过，但真正的组装起来却变成一个汉堡，这就和我们一开始的需求有出入了。

这还只是第二层，来确保 Unit Test 的方向没有错，合在一起也能够满足需求！

E2E Tests ( UI Tests )

UI 又称 使用者介面 ( User Interface )

这时候已经是要测试所有功能的整合，以及测试整个系统的运作流畅度和互动效果。

所以这边可以叫做 UI Tests 的原因就在於，我们专注的点在於整个应用程序的使用效果，画面中的互动，操作上的效率等等 ...

撰写 E2E 的测试难度较高，执行的速度也很慢，这次的铁人赛我们还是以 Unit Test 为主，希望专注在基础的测试上面，毕竟要盖成金字塔，也是需要先打地基嘛～

Manual Testing

这时候的应用程序已经开发到一定的完成度，只剩下手动测试的部分！

对於手动测试我想也不需要解释太多！

还是要根据事先完成的测试 SOP 规范，不是乱按一通就是手动测试

来提提优点好了！

• 不需要任何的开发工具，耗时较少
• 大部分的 Bug 都在手动测试阶段被发现
• 人的反馈会比开发工具来的真实有效果！

手动测试基本上是一定会发生的，就算你什麽测试都没有写

因为那出自於人性，你永远会去操作你做出来的作品，而有些 Bug 确实不会被测试框架给捕捉到，他可能很细节，或是使用起来很慢等等

这些很多都是开发工具不会告诉你的，所以这虽然在最上面，但他是非常重要的一个环节！

小结

今天稍微介绍了一下测试的种类，看着图片来阅读文章，应该也能感受到一股积沙成塔的感觉，为了提升应用程序的稳定性，测试是绝对不可少的一环！

但每一个专案的开发时程都不一样，不一定有时间让你遵循这张图片进行测试，这时候我们就要稍微做取舍来决定该使用哪些测试，而测试又该要用在哪个功能上面才能让 Bug 发生时不会无处可找！