像用户一样测试：打破知识诅咒 | IDCF
共 3196字，需浏览 7分钟
·
2022-02-17 23:01
来源：圆小豆的美梦工场
作者：于晓南
引子
先来玩个视觉小游戏，请在下图中找到隐藏的五角星。
没找到的朋友，答案在文末。请看完答案再回到这里。
现在我们回看上图，是不是很容易就找到五角星，甚至第一眼就看到它了？
知识诅咒
“有些事知道了，就再也回不去了。”
知识诅咒，指的就是一旦我们自己知道某样东西，就会发现我们很难想象不知道它的时候会是什么样子。我们的知识“诅咒”了我们。对于我们自己来说，同别人分享我们的知识变得很困难，因为我们不易重造听众的心境。
那这件事和测试有什么关系呢？我们看一个典型的测试用例是什么样的：
按照用例执行，假设执行结果符合预期，我们就可以验证系统的注册功能确实是正常的，新用户可以注册并登录。但问题在于，真实的用户并不是这样使用软件的。
下面让我们来看看真实用户是怎么想的（斜体字）、怎么做的：
打开网站，找到注册按钮，点击进入注册页，如①，好像没有必填哎
输入昵称，提示昵称重复，如②，样式真不讲究，差评~
点击注册，提示手机号不正确，如③，手机号必填？随便输一个
输入手机号，没填验证码，点注册，如④，密码忘填了
输入密码，点注册，如⑤，验证码也要填啊，早不说，哎麻烦死了，算了不注册了！
（注：图片来自真实的互联网软件产品，截图日期2020年11月25日）
我们来回顾一下上面这个过程：用户每一步都是按照软件提示做的，但并没有得到想要的结果，在注册过程中负面情绪不断累积，直到最后一根稻草压上来，最终放弃了使用。但用户的需求还在，他会找到注册功能好用的竞争对手的软件，边开心的使用，边在心里暗暗下决心：再也不用那个破网站了。
当测试执行完用例，确认注册功能没问题的时候，用户已经在注册完成前就跑了。究其根本，测试人员在测试时使用的还是“测试心智”，对被测软件的熟悉和了解是内化在心里的，测试时主要发挥的是测试领域的专业技能；而用户在使用软件时，是不会带有“测试心智”的，不会预知软件的表现，注册的过程对新用户来讲是全新的体验。测试人员和真实用户在使用软件上的差异是很明显的，这也是为什么尽管经过大量测试，用户仍然会吐槽软件难用的主要原因。
看看在小猪佩奇里怎么解决这个问题。猪爸爸是跳泥坑届的世界冠军，他对佩奇说：“要想跳好泥坑，秘诀是与泥坑融为一体。要想获得跳泥坑冠军，就要学会像泥坑一样思考！” 所以在准备阶段，猪爸爸并没有一上来就疯狂的练习跳泥坑，而是花大量的时间在思考，到底怎样才能和泥坑融为一体。
测试人员想像用户一样测试，要学会像用户一样思考，打破知识的诅咒，真正带着初心的使用软件。这并不容易，但也是有迹可循的。这也是目前测试领域关注度相对较少的、但却是打造完美软件不可或缺的重要一环。
破局
“愿你出走半生，归来仍是少年。”
怎样像用户一样测试，这道题考的到底是什么？考的是测试人员同理用户的能力，能否做到还原真实用户的使用场景，还原用户在使用产品时的真实心理。
说起来有点玄，但其实思路很简单。第一步就是先了解用户，只有了解用户的所思所想，才能知道用户会怎样使用软件；第二步是弥补测试人员和用户之间的断层。这有两层含义，第一层是让用户跟测试对齐，指导用户更好的使用软件；第二层面是让测试跟用户对齐，指导测试更有同理心。下面我们展开详细的讨论。
第一步：了解用户
明确对象
首先澄清一下测试的目标，测试的终极目标并不是提供零缺陷的软件，而是提供好用的软件，只有软件好用，用户用脚投票时才会投给它。好用是个主观评价，谁来评价很重要。测试人员需要明确软件真实的用户到底是怎样的群体，他们评价软件好用与否的标准是什么。
明显的，软件好用与否取决于很多因素，产品是面向C端、B端还是G端？产品形态是小程序、App还是平台网站？产品的用户和客户评价标准是否一致？这都影响用户和干系人对软件的最终评价。因此，充分的需求背景分析和用户调研不仅仅是产品经理需要考虑的事情，也应该是测试人员关心的范围。
换位思考
在明确对象之后，我们大概率能知道用户群体是谁，他的典型画像是什么样的，这也是我们进行换位思考的基础。还是以登录为例，假设我们目标用户的特征是：高知宝妈、价格不敏感、时间宝贵、愿意为知识和体验付费。这时采用移形换影大法，我就是这位宝妈，我希望注册过程可以尽量简洁，让我能花较少的时间完成，同时也尽量优雅，从界面到操作都浑然天成，注册的过程本身就是一种享受。
有了这个视角，易得出优秀软件的一个通用标准，即：让用户在使用软件时，尽可能感受不到软件的存在，好像世界本应如此，自然而顺畅。具体可参考用户体验三大要素及相关资料：别让我等、别让我想、别让我烦。
频繁沟通
频繁沟通有助于更好的了解用户，建立用户同理心。当我们通过倾听用户获得更多的细节时，就更容易了解用户的所思所想，了解尴尬的现状和切肤的痛点，从而更容易做出满足用户真正需求的决策。
建立一个负担不重的沟通机制是至关重要的，让用户在想沟通时能够随时找到沟通的渠道。另一个重要的点是，要真正的倾听，既不能盲从也不能盲不从，太南了。怎样避免鸡同鸭讲，真正听出用户的弦外之音，我也还在探索。但相信建立意识是艰难的第一步，抬腿迈步ing~
第二步：弥补断层
搭梯子
让用户跟测试对齐，可以通过简明的文字或图形指引，如下图：我们很容易看出，这个流程共7步，当前在第3步。在测试时，需要检验软件功能针对长流程的指引是否完备且准确。
搭梯子的另一种方式是，建立基于业务的用户文档。言外之意是，写出用户能看懂的、贴近用户使用场景的使用手册。哪怕我的功能是提供一个接口，我也不应该仅仅贴出接口文档，而更应该补充该接口的使用场景：在什么情况下使用接口，应该以什么频率调用，最多支持多大的并发量，各字段枚举值所代表的具体业务含义是什么，不同的用户调用接口时的注意事项……
建场景
让测试跟用户对齐，需要给测试补充真实用户的使用场景，可以采用场景法来分析用户的使用场景。还是以注册为例，真实用的使用场景可能是这样：注册→验证账号→登录账号→长时间未操作后重新登录。考虑到这样的场景，我们就不能要求用户在登录以后必须注销，或者下次登录的操作依赖于用户注销的状态。
我在测试工作中就遇到过这样的缺陷：用户登录后长时间未操作，但也未注销，再次登录提示：“登录失败，用户已登录。”还是上面的场景，在邮箱验证账号时，可能由于网络问题，没有收到验证成功的返回，而服务器端其实已经验证通过了，那么用户就会重复发送验证请求，服务器端处理后发现该链接已被验证过，于是返回：“验证失败，验证链接已失效。” 按照程序逻辑讲是没问题的，但以前端用户视角来看，就是验证链接不能用于验证，妥妥的功能缺陷。
比较理想的做法可能是，服务器端如能判断两次验证来自同一设备，直接返回 “已验证通过，正在跳转登录页……”。
还原真实用户的使用场景，有助于测试人员设计出更符合用户特征的测试用例。以后在写测试用例的时候，还可以加上一个用例分类：用户场景测试。
勤观察
测试人员应培养敏锐的观察力，在日常时时观察用户的特质，以及用户在使用软件时的微小反馈。不愁没有用户，我们可以随机从同事中抽取非研发部的伙伴来帮忙快速验证，或者在需求验收时收集并记录大家的反馈。任何一个细节都可能成就一款产品，也可能失去一部分用户。以认真细致著称的测试人员，如能投入更多精力在贴近用户的测试中，这将为软件质量的评价带来非常积极的影响。
结语
“从前一叶障目，现在我看见。”
附：怎么样，找到五角星了吗？它在这里。
