什么是可用性测试 可用性测试类型包括哪些

　　很多人都有过这样的经历：一个产品拿到手，不知道怎么用，只好找来说明书，结果发现说明书写得比产品很难懂；走到一扇门前使劲一推，只听咣的一声—这扇门只能往里拉，不能向外推；某次打开洗手间的冷水水龙头，冷不丁被烫了一下。

　　每当遇到这种情况，我们都会忍不住吐槽：这种东西是什么人设计出来的？这哪能用啊！

　　“这哪能用啊”就是对产品“可用性”的声讨。可用性不是品质，而是指产品好不好用、易不易用。所以，我能有时也把可用性称作易用性。

　　互联网时代，虽然人们常说“小步快跑，快速迭代，”但是，如果有谁胆敢拿出一个连基本可用性都没有的产品给用户，直接说“我要开始跑了，”用户会把他“踩死”在起跑线上。

　　所以，“可用性测试”非常重要。可用性测试，就是通过观察有代表性的用户完成产品典型任务，从而界定出可用性问题并解决，让产品使用起来更方便。它是在正式发布产品、用户大规模使用之前，最后一道验证需求的防线。

　　下面万商云集小编就给大家来介绍下什么是可用性测试，希望下面的内容能对你有所帮助

　　第一步，找到有代表性的用户。

　　假设你想对大幅改版的音乐播放App做可用性测试，你的“代表性用户”是谁？他们是用过上一版本App超过3个月，并下载过歌曲的用户。

　　用户是18岁还是30岁，这个问题重要吗？年龄之类的人口统计学特征其实没那么重要，因为对可用性产品更大作用是“用户行为特征。”比如，他们如何使用你的App？用了多久？做过哪些事情？这些信息更重要。

　　那么，要选几个用户才有代表性呢？需要100个吗？并不需要。一般来说，用过5个用户就可以发现明显的可用性问题，因此5～8个用户就足够了。如果调查的用户量超过8个，可获取的新的信息量就很小了。

　　第二步，设计“典型任务”

　　“你听到一首打动你的歌，分享到朋友圈，”或者“你想听某首歌的高清版，需要注册为会员，请完成注册”，又或者“请找到华晨宇的《齐天大圣》”。

　　这些都是典型任务。设计典型任务时要注意：任务不能太多，它们必须是重要的、新版本中容易出现问题的地方；任务必须是用户会遇到的场景，而不是设计师想象中的步骤。

　　第三步，界定出“可用性问题”

　　用户开始做测试时，你就是一个记录员。请记住，不要试图教用户如何使用产品，也不要向用户推销产品，更不要说“请给我们的产品提提意见”。你只需要说：“请体验一下我们的产品”。然后仔细观察和记录用户的使用行为。如果条件允许，可以安装两个摄像头：一个用来记录手机上的操作，另一个用来记录用户的表情。

　　对于手机上的操作，你需要观察用户看了哪里，点了哪里，接着又到了哪里，是不是你预期的路径。

　　对于用户的表情，你需要重点观察用户“思考、皱眉、犹豫、惊讶”等表情。当用户不停皱眉、做出思考状，犹豫着要不要点的时候，说明他对这个操作没有信心。当用户瞪大眼睛，表现得很惊讶时，说明App的反馈让他感到意外。

　　不要着急，不要指导，你只需要忠实地记录。

　　第四步，解决这些问题。

　　可用性测试的最后一步，就是趁着记忆深刻，赶快把测试结果整理出来。

　　“下一步”按钮藏在了屏幕下方，用户不知道要往下划，于是困在这里走不下去了——这是严重问题，必须立即修复。用户习惯在左边找按钮，一开始没找到，后来在右边找到了——这是一般问题，需要尽快修复。用户下载了很多音乐，存储空间满了，但他找不到清除本地音乐的地方——这种情况比较少见，是次要问题，可以延后修复。

　　可用性测试对个人而言也很有启发。可用性测试的底层逻辑是“我会错”的思维。我会错，但是如果能让用户证明我错了，这件事就非常可贵。可用性测试就是用最快、最便宜的方式，证明“我错了”，然后立刻就改。用最便宜、最快的方式纠正错误，是每个自信的人都应该拥有的反向思维。

上面就是关于可用性测试的相关内容，希望上面的内容能帮助到大家理解这个问题。