软件“美不美”，UI测试一下就知道

摘要：软件测试的最高层次需求是：UI测试，也就是这个软件“长得好不好看”。

为了让读者更好地理解测试，我们从最基础的概念开始介绍。以一个软件的“轮回”为例，下图展示了一个软件的研发流程。随着软件规模的不断增大，一个软件动辄百万行的代码，想要单靠人工检查或者程序猿的技术本身保证质量已经变得不现实。因此，测试成为软件流程中必不可少的环节。

测试过程中会涉及不同的需求，以Mike Cohn在他的著作《Succeeding with Agile》一书中提出的“测试金字塔”宝图镇楼为例，从下至上对应的测试需求分别为：单元测试，服务测试，用户界面测试。

这个金字塔形象地反应了笔者这些程序猿面临的问题。我们知道马斯洛的需求层次理论，在其著名的“马斯洛需求金字塔”中展示了一个人的不同层次的需求。笔者感觉这两个金字塔有很多相似之处。

个人最基本的需求是生理需求与安全需求，对应测试中就是“单元测试”。如果一个程序中的单元测试都不能保证，其上层的测试就无需谈起。而这部分也是需要花费大量精力去做的事情。每个开发人员在编写“单元测试”，并且完成测试之后，保证自己的服务能够正常运行才会考虑服务测试。就相当于自己吃饱了，安全了，才有力气和意愿去和别人交流。

此时，我们进入到下一个层次“社交需求”，服务之间的通信就像人类之间的“社交”，大家都要遵循一定的规则（程序接口，各种规范），才可以进行顺畅的通信。在日常生活的这个“交流”过程中，难免会出现一些误差，导致错误。然而，软件中出现一点点错误，可能导致不小的麻烦。例如2017年的这个新闻：以色列报纸“哈雷兹”报道说，一名巴勒斯坦男子被以色列警方逮捕，当时他在自己的脸书账号上写了“早上好”，Facebook自动翻译服务错误地用希伯来语翻译为“攻击他们”，用英语翻译为“伤害他们”，Facebook对此表示歉意。

软件测试的最高层次需求是：UI测试，也就是这个软件“长得好不好看”。这里引用一个词语“一想之美”，每个人心中关于美的定义都不相同，那什么样的软件才是“美”的？我们又应该如何测试？（终于凑够了领导要求的字数）。

下面是恰饭时间，不感兴趣的童鞋可以刷其他文章了。

单元测试需要程序猿自己在开发过程中编写，那么服务测试如何实现自动化？

这里华为云提供了云测（CloudTest）的测试平台。

官方介绍：云测（CloudTest）是面向软件开发者提供的一站式云端测试平台，覆盖功能测试、接口测试，融入DevOps敏捷测试理念，帮助您高效管理测试活动，保障产品高质量交付。

功能测试

云测融入全生命周期追溯、团队多角色协作、敏捷测试、需求驱动测试等理念，覆盖测试需求管理、测试任务分配、测试任务执行、测试进度管理、测试覆盖率管理、测试结果管理、缺陷管理、测试报告、测试仪表盘，一站式管理功能和自动化测试，提供适合不同团队规模、流程的自定义能力，帮助多维度评估产品质量，高效管理测试活动，保障产品高质量交付。

接口测试

基于接口URL或Swagger文档快速编排接口测试用例，集成流水线，支持微服务测试、分层自动化测试。测试用例免代码编写，技术门槛低，适合接口开发者、接口消费者、测试人员、业务人员等不同角色使用。一键导入Swagger接口定义自动生成脚本模板，基于脚本模板组装编排、管理接口自动化测试用例。支持HTTP和HTTPS协议，可视化用例编辑界面，丰富的预置检查点、内置变量，支持自定义变量、参数传递、持续自动化测试。

在上面的描述中，我们引入了测试金字塔的概率，介绍了单元测试和服务测试。这里我们唠唠最上面的是UI测试。基于对UI测试的粗浅了解，笔者也将UI测试画了一个金字塔。

最下层的“功能测试”对应的是测试UI界面中的“交互”功能。例如，一个按钮是否能够点击，下拉框是否显示等。如果说UI测试是看一个人是不是好看，功能测试就是说，一个人五官是否齐全，并且能否完成正常的生理功能。一般的测试团队的测试可能包括以下内容：

控件
快捷键
文案
图片
布局

在人工测试时，会对界面中的以上元素进行检查，比如在交互的地方会手动点击，查看交互结果是否正常。这部分工作现在有一些自动化工具可以完成，但是其过程需要包含两个动作：录制和回放。录制指的是测试人员根据测试经理设计的测试用例操作软件，在操作过程中使用自动化工具，将这个操作过程“录制”下来，然后保存用例。而回放是自动化工具提供自动执行“用例”的能力，在需要测试的环境中，回放上一步录制的用例。若回放失败，则认为被测环境出现异常，与录制环境中期望的结果发生差异。导致这种失败的情形多种多样：环境不稳定，网络超时，软件升级等。

一个人仅仅有五官还不够，还需要有基本的生理功能，比如说话是否伶俐，耳朵是否灵敏。对应到UI测试的性能测试中，就是要求一个软件不仅能够完成基本的功能，并且不能出现性能的问题。比如我们开发的打赏功能，若有一个用户发表了一篇热文，短时间有千万人打赏，但是这个小程序因为性能挂掉了，就会导致用户损失很多钱。又比如当用户打开这个小程序，一篇文章的加载却需要超过一分钟，严重影响用户的体验。

在这个看脸的世界，一个人长得漂亮就会带来许多便利。一千个人心中有一千个哈姆雷特，每个人的标准也不一样，那么如何判断一个人是否漂亮呢，就是让不同的评委进行评判。以此类推，评判一个软件是否“好看”，能否经得起各种环境和不同系统的“认证”，就需要对软件进行兼容性测试。在移动端刚开始普及时，许多PC端的网页需要对移动端进行专门的适配，其工作量不亚于重新开发一块应用。虽然现在许多架构支持多终端的自动适配，但是，你永远不知道用户使用的是哪一种设备，在什么环境中使用。因此，对软件进行兼容性测试变得越来越重要。

前段时间流行过一个词“小而美”。有些程序猿也说，我们要做一款“小而美的应用”。这个“美”不仅需要内功够硬，在UI设计中花大量功夫，在测试阶段也需要考虑兼容性问题。说了这么多，那兼容性测试究竟应该怎么做呢？下面我们要做的是对兼容性测试的条件进行“庖丁解牛”式的详细描述。（赶时间的同学可以离开了，下面是大量描述）。

测试环境

环境搭建
环境管理
环境升级
机器维护

对于正在看这篇文章的读者来说，想必手里至少有一个手机或者一台电脑。手机是什么牌子的？手机系统是什么样的？电脑是什么系统的以及屏幕分辨率是多少？这篇文章在这些不同的环境中是否都能够正常显示？要想回答这些问题，在进行兼容性测试时我们的测试人员就需要搭建环境。虽然不能完全包含市面上所有界面的机器型号，但是至少可以覆盖目前主流的设备和系统。假设测试人员现在搭建了至少 1000 种环境，那么如何有效地管理这1000种环境呢？如果其中一个测试环境出现问题了，要怎么进行维护呢？在维护过程中又是如何保证测试业务正常执行？又或者其中一个系统有了最新版本，我们如何进行升级？(后面广告时间可以提供一站式解决方案。)

测试用例

设计用例
编写用例
调试用例
维护用例

有了测试环境之后需要有测试用例，这里同样也涉及测试用例的设计、编写、调试和维护的过程。根据测试经理或者设计人员给出的功能点，需要对UI中的页面进行测试。细心的同学发现了，这个用例的概念不是功能测试中才有的么？在兼容性测试中同样需要用用例。比如，对于用户登录这一功能，在一些软件中，只有登录之后才能进行各种操作，并且还可能需要验证码。此时需要结合功能测试中的能力，跳转到目标页面，然后对该页面进行兼容性测试。具体来说，是以a环境为基础，对UI界面截图，同时在b环境中对UI界面截图，比较两个不同环境下的截图是否一致。在实际的兼容性测试工作中，涉及的问题远不止以上列举的，比维护用例为例，由于软件升级、环境改变或者是系统不同（ios，android），可能导致以前编写的用例在后续一段时间内失败。这时就会面对一个取舍的问题，维护用例的成本，自动化进行兼容性测试的收益。那还要不要进行自动化的兼容性测试。这就需要业务经理根据自身情况进行抉择。

测试执行

用例管理
执行机调度
测试能力

在执行阶段，我们需要做一件事：对比两张图片，判断是否一致。这一句看似简单的话语，只有做过图像的童鞋才能理解其中的辛酸。现在假设我们可以轻松地完成对比图片的工作，那么接下来，如何在最短时间使用最少的资源去运行最多的用例？这其实是一个多目标优化问题，而且其中的优化目标还可能存在冲突。在解决这些问题之后，欢迎来到下一个坑。

测试报告

报告查看
报告管理
报告修改
报告更新

最后一步的难点在哪呢？要想确定UI中是否存在兼容性问题，自动化能做的只能是根据事先约定的“标准”进行判断，但是由于这些标准大部分都是比较模糊的，因此最终的测试结果往往需要测试人员进行确认。由用户最终确定是否通过兼容性测试。对于一些出现误报的区域，还需要用户进行交互式的处理，在后续执行过程中对这些区域进行特殊处理，这个过程就类似用例的维护。

那说了这么多废话，兼容性测试怎么做？我需要自己买那么多手机，搭建环境，编写管理系统。。。搞这么多工作么？

下面是恰饭时间，不感兴趣的童鞋可以刷其他文章了。

华为云提供了移动应用测试平台MobileAPPTest。

只需要点击上面这个链接，跳转到如下页面，点击“立即体验”