您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件测试技术 > web测试 > 正文

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

发表于:2021-03-21 作者:华为云 来源:CSDN

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

测试过程中会涉及不同的需求,以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。

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

再按照如下步骤进行点击。

即可到达我们的兼容性测试配置页面,选择自己喜欢的手机类型、希望覆盖的测试人群,想要测试的测试对象。记得要先充值。

充钱之后,点击运行就可以去睡觉了。测试结束之后会自动生成一个测试报告,点击测试报告查看结果,齐活儿。