王镇雷：之前我写过一篇文章《喂，你设计稿的文案和图片都真实吗？》，讲述的是设计师在能力所及时，应该尽可能将设计稿中的所有内容都换成真实的数据。
所谓真实的数据，包含但不限于文案、图片、价格、品牌等。对于更复杂的需求，数据可能还会包含不同时间段时的产品状态，甚至还有多个产品需求叠加/互斥等复合逻辑。所以，我们在做设计方案时，除了主要场景的界面设计（正常主流程），也有相当多时间花费在特殊场景的处理（异常和分支流）。而随着工作涉及的产品越来越复杂，我越来越觉得除了真实的设计稿之外，真实的产品测试也是同样重要。以下几个场景，是设计师在走查开发还原度、测试产品流程时经常遇到的：
一. 假的文案，假的图片素材
一般来说，文案会随着产品需求一起写在 PRD 文档里，告诉大家在什么时候出现什么内容。然后设计师会从 PRD 文档里原封不动地把这些文案 Copy 到设计稿中（当然不负责的设计师会自己随便编，负责的设计师还会反过来和产品经理一起优化文案）。而这些文案，其实最终还会进入到系统中，正确地展示到用户面前。在测试过程中，经常因为时间关系来不及去校对所有的文案。或者是因为文案场景太多，或者是因为觉得文案后面还会改，所以总是不能看到正确的文案。而当设计师提出问题时，开发也总会说「这个随时可以改的，先不要在意这个点」。真实线上产品，文案也是经常出问题的一点——表意不清、有歧义、时间错乱等等。图片素材也是类似，都需要我们在前期测试中真正去跑一遍。
二. 复合产品分开测试，未集合总测
一个页面里有三个新功能需要上线，最常见的测试方法是把三个功能分开独立测试。如果这三个功能不是完全隔离的，这样分开测风险就非常高。因为我们单独看一个功能好像没问题，但是连动查看其他功能时，可能就不是正常的场景了。此外，即便三个功能是隔离的，我也经常在测试中看到不应该一起出现的功能展示在同一个页面里。而我们可能会给自己找借口：「先别管那个功能，正常情况下它不会出现」。但可能就因为你的一个疏忽，上线时用户也会看到这些不该同时出现的内容。
三. 全链路完整测试
和前一种情况很像，因为公司庞大，所以在测试时经常每个产品线单独测试。比如首页是一个团队、搜索是一个团队、用户中心又是一个团队，测试时大家常常只按着自己范围内的产品表现。而很多产品功能都不会只作用于一个链路，往往都是由多个链路配合实现的。就拿用户买东西来说，势必都要经过首页、搜索、商品详情、下单、购物车等等界面。而在测试时，我点击下单之后没有正常反馈，大家却说是因为购物车那边数据返回还没做好。所以很容易理解：产品的全链路、全场景联合测试是多么重要。
四. 极端异常场景未测试
正常主流程是所有人都会关注、测试的。普通异常流也是大家会留意的。但对于一些非常极端、非常特殊的场景，一来制造这样的情景比较难（技术上，特殊场景的触发条件也同样苛刻），二来觉得这些场景出现概率不高，也就不是那么重要。举个例子，我经常遇到的一个异常情况是「技术接口返回异常」。常见的处理方法是做一个通用的异常弹窗，告诉用户诸如「网络被挤爆了，请稍后再试」。但实际上新功能测试时，还是要验证一下是否所有网络相关的异常情况都配置了这个界面。我就见过按钮点击后毫无反应，或者点击多次出现多次结果的情况发生。再比如，很多产品状态与数值相关：用户的积分、等级，产品本身有数量限制等等。那积分不足、等级不够，产品售罄的状态该如何处理？都是需要设计且测试的。当真实上线真正遇到问题时，要靠这些场景来救命。
五. 与时间相关的产品场景错乱
以电商产品的大促为例，许多场景都是和时间强相关的，比如一个大促活动会在5月5日到5月15日之间进行，那么测试时，界面上所有和时间相关的数据都应该在这个时间内。举个很典型的例子，倒计时类的组件就经常在测试时发现错误，并没有指向目标时间点，甚至展示了过期的时间「距开始」，变成「距结束」。而多个产品各自有自己的生命周期时，测试就会变得更加复杂，错误情况也会更多。
六. 多设备测试
Android 设备在整个移动端的占比高得超乎你的想象（70%+），而我们身边绝大多数设计师和产品经理都在使用 iOS 系统。我已经见过太多次 iOS 上还原度极高的界面放在 Android 中无法直视的场景，还有很多基础功能两边不一致等等。因此，一次负责任的测试，都必须要把多个可能涉及的设备都拿出来检查一次，尽可能使得多端体验一致。
小结：
但越是难以检查和测试的场景，越容易出现问题，也就越有必要在上线之前查看效果。当复杂时间线互相穿梭，也常出现不该有的内容出现在界面上、该生效的组件没有生效的情况。幸运的是，基本我遇到的开发和测试同学都是极其负责的。如果时间充裕、大家精力充足，测试同学一般都会根据真实情况造好测试场景，然后严格对照用例一个一个去展示。但当项目时间紧、业务复杂度高、组织内部流程长的时候，就难以做得十全十美了。这也侧面证明，需求管理和人力资源的分配，同样极其重要。
本文来自公众号：王镇雷
所谓真实的数据，包含但不限于文案、图片、价格、品牌等。对于更复杂的需求，数据可能还会包含不同时间段时的产品状态，甚至还有多个产品需求叠加/互斥等复合逻辑。所以，我们在做设计方案时，除了主要场景的界面设计（正常主流程），也有相当多时间花费在特殊场景的处理（异常和分支流）。而随着工作涉及的产品越来越复杂，我越来越觉得除了真实的设计稿之外，真实的产品测试也是同样重要。以下几个场景，是设计师在走查开发还原度、测试产品流程时经常遇到的：
一. 假的文案，假的图片素材
一般来说，文案会随着产品需求一起写在 PRD 文档里，告诉大家在什么时候出现什么内容。然后设计师会从 PRD 文档里原封不动地把这些文案 Copy 到设计稿中（当然不负责的设计师会自己随便编，负责的设计师还会反过来和产品经理一起优化文案）。而这些文案，其实最终还会进入到系统中，正确地展示到用户面前。在测试过程中，经常因为时间关系来不及去校对所有的文案。或者是因为文案场景太多，或者是因为觉得文案后面还会改，所以总是不能看到正确的文案。而当设计师提出问题时，开发也总会说「这个随时可以改的，先不要在意这个点」。真实线上产品，文案也是经常出问题的一点——表意不清、有歧义、时间错乱等等。图片素材也是类似，都需要我们在前期测试中真正去跑一遍。
二. 复合产品分开测试，未集合总测
一个页面里有三个新功能需要上线，最常见的测试方法是把三个功能分开独立测试。如果这三个功能不是完全隔离的，这样分开测风险就非常高。因为我们单独看一个功能好像没问题，但是连动查看其他功能时，可能就不是正常的场景了。此外，即便三个功能是隔离的，我也经常在测试中看到不应该一起出现的功能展示在同一个页面里。而我们可能会给自己找借口：「先别管那个功能，正常情况下它不会出现」。但可能就因为你的一个疏忽，上线时用户也会看到这些不该同时出现的内容。
三. 全链路完整测试
和前一种情况很像，因为公司庞大，所以在测试时经常每个产品线单独测试。比如首页是一个团队、搜索是一个团队、用户中心又是一个团队，测试时大家常常只按着自己范围内的产品表现。而很多产品功能都不会只作用于一个链路，往往都是由多个链路配合实现的。就拿用户买东西来说，势必都要经过首页、搜索、商品详情、下单、购物车等等界面。而在测试时，我点击下单之后没有正常反馈，大家却说是因为购物车那边数据返回还没做好。所以很容易理解：产品的全链路、全场景联合测试是多么重要。
四. 极端异常场景未测试
正常主流程是所有人都会关注、测试的。普通异常流也是大家会留意的。但对于一些非常极端、非常特殊的场景，一来制造这样的情景比较难（技术上，特殊场景的触发条件也同样苛刻），二来觉得这些场景出现概率不高，也就不是那么重要。举个例子，我经常遇到的一个异常情况是「技术接口返回异常」。常见的处理方法是做一个通用的异常弹窗，告诉用户诸如「网络被挤爆了，请稍后再试」。但实际上新功能测试时，还是要验证一下是否所有网络相关的异常情况都配置了这个界面。我就见过按钮点击后毫无反应，或者点击多次出现多次结果的情况发生。再比如，很多产品状态与数值相关：用户的积分、等级，产品本身有数量限制等等。那积分不足、等级不够，产品售罄的状态该如何处理？都是需要设计且测试的。当真实上线真正遇到问题时，要靠这些场景来救命。
五. 与时间相关的产品场景错乱
以电商产品的大促为例，许多场景都是和时间强相关的，比如一个大促活动会在5月5日到5月15日之间进行，那么测试时，界面上所有和时间相关的数据都应该在这个时间内。举个很典型的例子，倒计时类的组件就经常在测试时发现错误，并没有指向目标时间点，甚至展示了过期的时间「距开始」，变成「距结束」。而多个产品各自有自己的生命周期时，测试就会变得更加复杂，错误情况也会更多。
六. 多设备测试
Android 设备在整个移动端的占比高得超乎你的想象（70%+），而我们身边绝大多数设计师和产品经理都在使用 iOS 系统。我已经见过太多次 iOS 上还原度极高的界面放在 Android 中无法直视的场景，还有很多基础功能两边不一致等等。因此，一次负责任的测试，都必须要把多个可能涉及的设备都拿出来检查一次，尽可能使得多端体验一致。
小结：
但越是难以检查和测试的场景，越容易出现问题，也就越有必要在上线之前查看效果。当复杂时间线互相穿梭，也常出现不该有的内容出现在界面上、该生效的组件没有生效的情况。幸运的是，基本我遇到的开发和测试同学都是极其负责的。如果时间充裕、大家精力充足，测试同学一般都会根据真实情况造好测试场景，然后严格对照用例一个一个去展示。但当项目时间紧、业务复杂度高、组织内部流程长的时候，就难以做得十全十美了。这也侧面证明，需求管理和人力资源的分配，同样极其重要。
本文来自公众号：王镇雷
扫一扫
2473
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
