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

当我们不确定哪里应该重点测试，或应该做什么样的测试，请分析用户是如何使用我们的产品的。 因为了解这些可以帮助我们改进测试工作。本文探讨了如何利用用户数据来指导优化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%用户的产品体验。

 

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