在上面的描述中，我们引入了测试金字塔的概率，介绍了单元测试和服务测试。这里我们唠唠最上面的是UI测试。基于对UI测试的粗浅了解，笔者也将UI测试画了一个金字塔。
最下层的“功能测试”对应的是测试UI界面中的“交互”功能。例如，一个按钮是否能够点击，下拉框是否显示等。如果说UI测试是看一个人是不是好看，功能测试就是说，一个人五官是否齐全，并且能否完成正常的生理功能。一般的测试团队的测试可能包括以下内容：
控件
快捷键
文案
图片
布局
在人工测试时，会对界面中的以上元素进行检查，比如在交互的地方会手动点击，查看交互结果是否正常。这部分工作现在有一些自动化工具可以完成，但是其过程需要包含两个动作：录制和回放。录制指的是测试人员根据测试经理设计的测试用例操作软件，在操作过程中使用自动化工具，将这个操作过程“录制”下来，然后保存用例。而回放是自动化工具提供自动执行“用例”的能力，在需要测试的环境中，回放上一步录制的用例。若回放失败，则认为被测环境出现异常，与录制环境中期望的结果发生差异。导致这种失败的情形多种多样：环境不稳定，网络超时，软件升级等。
一个人仅仅有五官还不够，还需要有基本的生理功能，比如说话是否伶俐，耳朵是否灵敏。对应到UI测试的性能测试中，就是要求一个软件不仅能够完成基本的功能，并且不能出现性能的问题。比如我们开发的打赏功能，若有一个用户发表了一篇热文，短时间有千万人打赏，但是这个小程序因为性能挂掉了，就会导致用户损失很多钱。又比如当用户打开这个小程序，一篇文章的加载却需要超过一分钟，严重影响用户的体验。
在这个看脸的世界，一个人长得漂亮就会带来许多便利。一千个人心中有一千个哈姆雷特，每个人的标准也不一样，那么如何判断一个人是否漂亮呢，就是让不同的评委进行评判。以此类推，评判一个软件是否“好看”，能否经得起各种环境和不同系统的“认证”，就需要对软件进行兼容性测试。在移动端刚开始普及时，许多PC端的网页需要对移动端进行专门的适配，其工作量不亚于重新开发一块应用。虽然现在许多架构支持多终端的自动适配，但是，你永远不知道用户使用的是哪一种设备，在什么环境中使用。因此，对软件进行兼容性测试变得越来越重要。
前段时间流行过一个词“小而美”。有些程序猿也说，我们要做一款“小而美的应用”。这个“美”不仅需要内功够硬，在UI设计中花大量功夫，在测试阶段也需要考虑兼容性问题。说了这么多，那兼容性测试究竟应该怎么做呢？下面我们要做的是对兼容性测试的条件进行“庖丁解牛”式的详细描述。（赶时间的同学可以离开了，下面是大量描述）。
测试环境
环境搭建
环境管理
环境升级
机器维护
对于正在看这篇文章的读者来说，想必手里至少有一个手机或者一台电脑。手机是什么牌子的？手机系统是什么样的？电脑是什么系统的以及屏幕分辨率是多少？这篇文章在这些不同的环境中是否都能够正常显示？要想回答这些问题，在进行兼容性测试时我们的测试人员就需要搭建环境。虽然不能完全包含市面上所有界面的机器型号，但是至少可以覆盖目前主流的设备和系统。假设测试人员现在搭建了至少 1000 种环境，那么如何有效地管理这1000种环境呢？如果其中一个测试环境出现问题了，要怎么进行维护呢？在维护过程中又是如何保证测试业务正常执行？又或者其中一个系统有了最新版本，我们如何进行升级？(后面广告时间可以提供一站式解决方案。)
测试用例
设计用例
编写用例
调试用例
维护用例