发布时间：2021-7-26 分类： 行业资讯
我之前写了一篇文章《喂，你设计稿的文案和图片都真实吗?》，告诉设计师，设计草案的内容应该用实际数据代替。
所谓的真实数据，包括但不限于文案，图片，价格，品牌等。对于更复杂的要求，数据还可能包含不同时期的产品状态，甚至复合逻辑，如多个产品要求覆盖/相互排斥。
因此，当我们进行设计时，除了主场景（正常主流）的界面设计外，还有相当多的时间花在特殊场景处理（异常和分支流）上。
随着涉及工作的产品变得越来越复杂，我觉得除了真正的设计草案，真正的产品测试同样重要。
设计人员在查看开发，恢复和测试产品流程时经常会遇到以下情况：
一. 假的文案，假的图片素材
一般而言，副本将与产品要求一起写在PRD文档中，告诉每个人何时以及将出现什么。然后设计师将副本从PRD文档复制到设计草稿中（当然，不负责任的设计师将自己编写，负责的设计师将依次与产品经理一起优化副本）。这些文案最终将进入系统并正确显示给用户。
在测试期间，由于时间的原因，校对所有副本通常为时已晚。或者因为文案场景太多，或者您认为副本稍后会更改，您无法始终看到正确的副本。当设计师提出问题时，开发人员总会说“这可以随时改变，不要先关注这一点”。
真正的在线产品，文案也是一个经常出问题的问题— —不清楚，含糊不清，时间混乱等等。图片材料类似，我们都需要在之前的测试中完成它。
二. 复合产品分开测试，未集合总测
页面上有三个需要联机的新功能。最常见的测试方法是独立分离三个功能。如果这三个功能没有完全隔离，那么单独测试的风险非常高。因为我们可以单独看到一个函数，所以似乎没有问题，但是当我们查看其他函数时，它可能不是正常的场景。
此外，即使三个功能是隔离的，我经常在测试中看到不应该一起出现的功能显示在同一页面上。我们可以给自己一个借口：“不要担心这个特征，在正常情况下不会出现。”但也许是因为你的疏忽，用户也会看到这些东西在上线时不应该同时出现。
三. 全链路完整测试
与前一种情况非常相似，因为公司规模庞大，每个产品系列通常在测试期间单独测试。例如，主页是一个团队，搜索是一个团队，用户中心是一个团队，而在测试时，人们通常只根据自己的产品执行。
许多产品功能不仅适用于一个链接，而且通常由多个链接实现。拿用户买东西，必然要经过主页，搜索，产品详情，订单，购物车等界面。在测试中，点击订单后我没有得到正常的反馈，但是每个人都说这是因为从购物车返回的数据还没准备好。
所以很容易理解：产品的全链接，全站点联合测试有多重要。
四. 极端异常场景未测试
正常的主要过程是每个人都会关注和测试。每个人都注意到普通的异常流动。但是对于一些非常极端和非常特殊的场景，创造这种情况更加困难（从技术上讲，特殊场景的触发条件同样要求严格），其次，这些场景的概率不高，不是那么重要。
例如，我经常遇到的一个例外是“技术界面返回异常”。一种常见的方法是创建一个告诉用户的通用弹出窗口，例如“网络被粉碎，请稍后再试”。但实际上，在测试新功能时，仍然需要验证是否使用此接口配置了所有与网络相关的异常。我已经看到单击按钮后没有响应，或者多次发生多次单击。
再举一个例子，许多产品状态与数值有关：用户的积分，等级和产品本身的数量。缺点，水平不够，如何应对产品销售状态？所有这些都需要进行设计和测试。当真正的在线问题确实遇到问题时，有必要依靠这些场景来挽救生命。
五. 与时间相关的产品场景错乱
以电子商务产品的大促销为例。许多场景都与时间有关。例如，将在5月5日到5月15日之间进行大促销。在测试时，所有与时间相关的界面。数据应该在这个时间。
作为典型示例，倒计时类的组件通常在测试期间发现错误，并且不指向目标时间点。他们甚至“从头开始”显示到期时间，并成为“从头到尾”。当多个产品各自有自己的生命周期时，测试变得更复杂，错误情况更多。
六. 多设备测试
Android设备在整个移动端的比例高于您的预期（70％以上），我们周围的大多数设计人员和产品经理都在使用iOS。我见过太多次了。 iOS上高度简化的界面放置在无法在Android中直接查看的场景中。基本功能有许多不一致之处。
因此，在负责任的测试中，有必要取出多个可能的设备并检查一次，以使多端体验尽可能一致。
小结：
但是检查和测试场景越困难，越容易出现问题，就越有必要在上线之前检查效果。当复杂的时间轴相互遍历时，通常情况下，界面上会出现不应存在的内容，并且活动组件不会生效。
幸运的是，我遇到的基础开发和测试学生都非常负责任。如果时间充足且每个人都精力充沛，测试学生通常会根据实际情况创建一个测试场景，然后逐个严格地比较用例。
但是，当项目时间紧张，业务复杂性高，组织内部流程长，难以做好工作。这也证明了需求管理和人力资源分配同样重要。
