用户故事 | “不务正业”的自动化测试工具 — UniEAP UTF

东软 UniEAP UTF 是一个自动化测试工具,支持基于 Android、iOS 系统的移动应用自动化测试,同时也支持基于 IE、Firefox、Chrome、Safari 等浏览器的 Web 应用自动化测试。
UniEAP UTF 的核心价值主要是大幅提升测试工作效率、提高测试设备利用率,从而在系统版本发布频繁而且质量要求严格的情况下大幅降低人工测试成本。
但是在过去的一年里,UniEAP UTF 在其本职领域之外,还“不务正业”地应用到了几个其它领域的解决方案中,成功实现“跨界”。
业务自动巡检解决方案

用户故事
去年有个销售在某石化公司遇到一个人员外包需求,客户想要外包一个最初级的人员,每天的工作就是重复地登录二十多个生产系统,把表面的基本功能都点一遍,遇到功能不好用的或者速度特别慢的页面就通知开发团队。
无独有偶,去年还有一个省信息中心的下属部门,专门负责定期巡检各个省直机关及各地市政府部门的门户网站、面向市民的政务系统及手机应用的可用性。
这些工作当时都是靠纯人工的方式去执行,还要把执行结果手动录入相应的 IT 管理系统。工作量大、及时性差、准确性低,效率极其低下。
“UTF”驾到
这些面向公众的系统,基本上都是基于浏览器的 Web 应用或者手机 App。所谓巡检,无非就是基于生产系统定期对主要业务流程进行通过性“测试”。这不正合 UniEAP UTF 的胃口嘛。
引入 UniEAP UTF 之后,把原来纯手工、重复、机械的定期巡检变成了自动化的巡检,不仅极大的提高了工作效率,而且降低了客户投入成本。
目标行业
政府部门、大型企业
典型客户
安庆石化、广东省信息中心

智能设备安全协作云解决方案

用户故事
去年初,遇到一个手机厂商的“在线用户体验测试”项目,里面有个技术难点,导致他们已有的软件外包合作厂商(东软不在其内)都无法承接。到底是什么技术难点呢?原来他们需要让用户在不接触手机的前提下,对手机应用的原型版本进行体验测试,并反馈一些易用性相关的问题,以便他们不断优化自己的用户体验。
为什么要求用户“不能接触手机”呢?主要原因是很多新款应用(甚至操作系统)都是与某新款手机一起发布面世,在该款手机正式对外发售之前,工程样机必须在厂商内部严格保密管理,绝对不能对外提供。
类似的场景去年我们还遇到过一次,这个客户是做智能 POS 机的金融机构,需要支持第三方厂商开发的 App 安装到自己的 POS 机上,但是 POS 机不像手机那么购买方便。因此,App 开发厂商只能基于普通的 Android 手机进行测试,然后直接放到 POS 机中上线,导致上线之前出现很多兼容性问题。
“UTF”驾到
UniEAP UTF 移动自动化测试中有个“云手机”模块,允许测试人员基于浏览器按需申请,并在线通过浏览器操作远程的“云手机”,同时还能对手机进行性能监控。UniEAP UTF 提供这个功能的本意是为了解决企业测试手机管理不规范以及跨部门之间手机无法共享导致的测试人员“拿不到手机”的问题。
面对上述场景,无非就是多了几种因素,导致必须使用“移动设备”的人无法“拿到移动设备”。对 UniEAP UTF 而言并没有本质区别,照单全收!
目标行业
基于 Android 系统的手机或其它智能硬件厂商,比如:智能 POS、医疗 PDA、汽车电子设备(导航、娱乐)等。
典型客户
华为

移动App厂商自动化实施解决方案

用户故事
我去年面试过一个移动 App 开发人员,他说近期工作比较郁闷,几个月一直在客户现场做实施。我很好奇,问他:“你们的 App 是上线质量很差么?怎么会有那么多实施工作呢?”。他道出了如下原委:原来他们的 App 是2B的,用户是某政府机关的工作人员,所谓的“实施”就是指给一批又一批的手机安装他们的 App,安装之后简单测试一下,没有问题,接着装下一个手机。
这种现象并非个案,咱们自己的 SaCa EMM 在某个医院的实施过程中,客户就是一批甩来600个设备,让我们挨个安装(据了解,国内另外一个 EMM 厂商也是这样实施的)。根据评估,一台设备安装应用、启动并进行简单通过性测试,需要20分钟左右时间,这都是实实在在的成本。
此外,在客户现场也会遇到对于特定某型号设备(甚至就是特定某个设备),App 功能就是不好用的情况,怎么办?现在的做法是,让现场协调把设备快递回来,研发团队可能只用半小时就解决了,但是来回快递至少一周。
“UTF”驾到
UniEAP UTF 已有的移动应用自动安装、自动测试及移动设备远程操控的功能,已经具备解决上述问题的整体技术方案。
目标行业
做 2B 业务的移动 App 厂商

相关产品

2019-04-04T15:09:09+00:00