通过了解用户如何使用产品来聚焦测试

郑文强 2017-04-13

当我们不确定哪里应该重点测试,或应该做什么样的测试,请分析用户是如何使用我们的产品的。 因为了解这些可以帮助我们改进测试工作。本文探讨了如何利用用户数据来指导优化UI自动化测试和兼容性测试的实例。

实例1:项目A,UI自动化测试

2016年7月,在部门项目A中,我们的后台接口自动化测试已经能基本满足日常工作需要,但是客户端测试仍极大得依赖于手工测试,是时候开始UI自动化测试了。UI自动化测试是相当昂贵的,我们选择了公司内部的一套测试框架,采用团队成员比较熟悉的Python脚本语言来编写用例,测试框架对用例集的管理,用例的执行和维护上有良好的支持,并能低成本的接入公司的集成发布平台。我们花了半年时间,实现了iOS/Android双平台各200+用例数,并做到了每日构建每日测试。

进入2017年,我们面临新的问题:熟语说,攻城容易守城难,如何低成本高收益得将自动化测试持续下去是个难题。我们非常清楚新增加一条自动化用例脚本的时间成本有限,但后期的维护成本不能忽视,同时UI自动化用例数量也不是越多越好。哪里应该自动化?如何确保不会过度自动化?在继续前行之前我们必须回答上述的问题。经过一段时间的思考后,我们决定回到用户这里来寻找答案。

作为一家服务性的公司,产品以服务的方式提供给用户,所以我们一切工作都要以用户价值为依归,公司要求每一位员工,都应该时刻保持对市场及用户需求的敏感,重视用户体验,并从中不断思考与总结,使我们的工作真正围绕“用户价值”这个核心,而不至于闭门造车,孤芳自赏。作为测试人员,更加需要了解用户是如何使用我们的产品的,围绕核心的产品使用场景,来制定我们的测试策略。

我们的产品每新增一个特性,会有对应的上报日志,跟踪用户的操作行为。我们收集了其中有价值的部分,并计算其数量。这些数据会告诉我们,用户最常用的登录方式,最常用的功能,最典型的产品使用场景。也验证了我们的猜测,80%的用户仅仅使用最核心的20%的功能(二八定律),这个信息可以帮助我们重点关注那20%功能的自动化。除了自动化测试,冒烟测试,性能测试等都可以从中受益。

实例2:项目B,兼容性测试

项目B的产品在海外多个国家和地区发布,用户使用产品的环境,受其所在国家软硬件发展的影响,和国内用户环境是不同的。而测试人员在办公室测试产品,尽管无法真实模拟用户的环境,但是仍需要尽量去覆盖,避免问题跑到用户那里,这里很重要的一个测试类型就是兼容性测试。对于Web类型的产品,需要考虑的是浏览器的兼容性测试,我们收集用户所使用浏览器的占比,选择总占比85%的几种浏览器进行测试,对于浏览器版本很低的用户,会提醒其版本过低,建议用户升级以获得更好的产品体验,经过几个月时间,有部分用户升级了浏览器版本。在不增加测试工作量的前提下,用户体验改善了,兼容性测试的覆盖度也进一步提升了 。

上面的策略对于移动平台的兼容性测试是无效的,我们不可能让用户换机,所以我们需要尽可能多地使用我们的用户所使用的机型来进行测试。 这种情况下,对用户机型数据进行分析是非常有用的。我们定期采购最受欢迎的机型进行测试,对于比较受欢迎的机型和长尾的机型,我们借助公司内部的兼容性团队以及各种云测试平台、众测平台去覆盖尽量多的机型。

后台升级版本,测试人员需要测试现网几个客户端版本对后台的兼容性。通过分析客户端版本的占比,我们发现一个版本的用户只有几十个人,总占比不到1%,而其它两个版本的用户数超过99%,因此我们调整了测试策略,对于用户量不到1%的客户端版本仅简单检查基本功能是否可用,大概不超过10分钟的时间,而其它两个版本按照原测试方案进行详尽测试,我们节省了原计划的1/3的测试时间。

我们经常需要根据用户的反馈来优化我们的产品,比如用户反馈使用某个功能很慢,测试人员在办公室测试也确实发现存在问题。传统的测试方案是对比优化前后版本的性能数据,以验证是否真正达到预期。更好的做法是统计现网的用户数据,我们知道测试样本数越少,其准确性是越低的,测试人员在办公室得到的数据是不足以代表整个用户数据的,从技术角度是非常容易被挑战的。但是用户的大数据就不同了,能真实得反应用户的体验。比如优化前60%的用户数据落在表现优秀的区间,优化后80%的用户落在表现优秀的区间,那么显然优化是有明显效果的,提升了 20%用户的产品体验。

用户数据能帮助技术人员有理可依地展开工作,同时也能帮助验证工作成果,期待有更多这块内容的分享出现。

相关推荐