《Web测试囧事》——3.2 针对UI设计稿的测试思路

本节书摘来自华章计算机《Web测试囧事》一书中的第3章，第3.2节，作者 黄勇 雷辉 徐潇 杨雪敏，更多章节内容可以访问云栖社区“华章计算机”公众号查看。

3.2　针对UI设计稿的测试思路

设计师做好的UI设计稿为什么还要做测试呢？因为测试可以让我们最直接、最有效地洞察产品在用户行为、界面可能性、用户期望与功能契合度等方面的综合表现。那作为一名测试工程师，在拿到卡中的设计稿后，需要进行哪些方面的测试呢？正好，小蔡刚刚接手一项关于UI设计稿的测试工作，我们一起来看看她会怎么做。

小蔡所在项目组使用的是敏捷开发流程，测试人员参与研发各个环节的讨论，同时提供测试思路，以便项目组其他成员打开思路。一般流程是，当开发人员根据优先级在backlog挑了一张用户故事卡正式编码前，会和项目相关成员，如需求分析（BA）、开发、测试，甚至产品经理和用户体验设计（UX）等一起进行Kick off来确认所有需求细节。这时候就需要测试人员从测试角度提出一些建议来帮助开发人员在后期的编码中进行自测，这些建议包括是否有未覆盖到的异常路径/场景、如何测试这张卡、研发的实现方案可测性如何等。经过讨论，还可以帮助小伙伴们打开脑洞，引出更多更新的想法。

下面就是小蔡关于测试UI设计稿的思路。

思路1 ：页面效果（见图3-2）。

首先，小蔡要检查UX设计师是否给出了字体、字号、行高、图片透明度、边缘空白等具体内容或数值。这是因为在网页开发过程中这些内容或数值对最终显示效果均有一定的影响，所以测试时必须考虑设计稿中是否提供出具体内容和数据，以保证最终的显示效果与设计稿一致。而小蔡目前所在的项目组设计师在使用Zeplin工具进行设计时都能给出一些具体数据，以便测试人员和开发人员进行测试开发。

那除了这些关系到页面效果的细节，还应该关注/测试哪些呢？小蔡左思右想还是没有头绪。于是跑来找老牛讨思路，老牛给她的建议是多关注变化点，例如后台动态变化的数据如何显示在界面中，以及页面是否是Responsive（响应式）页面，如果是的话，还需要看页面元素在不同尺寸的屏幕显示是否正确。

思路2：UI设计图是否适用于具体屏幕尺寸。

小蔡在Kick off卡时还需要观察设计人员是否提供了针对不同设备屏幕的设计图，并且每种设计是否合理，是否方便用户使用。这与小蔡平时工作中勤于使用各种软件是离不开的。通过横向对比各软件的使用体验，小蔡能够针对不同屏幕迅速而准确地提出建议。

小蔡目前所在的项目使用了Responsive页面技术，此技术的一个显著特性是页面会根据客户的浏览器尺寸定制显示页面元素，给用户提供最佳的使用体验。例如平板电脑的屏幕较大，可显示比较多的内容，但会要求功能按钮或者链接方便用户用手去点中。而手机屏较小，同样要求按钮的大小要方便用户用手指可以很容易地去点中，同时可能需要改变一些界面组件的显示位置或大小，删除或增加一些更适宜的组件。所以如果设计师的设计稿只对应宽度600～800px的屏幕，小蔡就需要考虑当屏幕变小或者变大后，界面元素的排列是否方便用户使用。

又如，界面上有100个字符的文本，在浏览器最大化时显示完全正常，但是当浏览器缩小为iPhone 4的宽度后，是否需要进行折行显示？可是折行显示会破坏界面上各组件之间显示的相对位置。那么这100个字符是否需要自动截断或者省略部分内容，如显示为“今天……”吗？ 这些问题都是一些很好的思路，需要小蔡和设计人员讨论如何进行是最优的。

思路3：重点关注后台数据变化动态影响界面显示。

图3-3界面中的文本都是从后台数据库中动态读取的，如果数据库中的字符串非常长，该如何显示呢？例如“CBD商圈”变成长字符串后，是折行还是加省略号？有时在字符串变长后，会和其他文本显示区域重叠，页面也因此会变得不美观。又如“视野宽广”是从数据库读取字符串的，如果这个字符串是空字符串该怎么处理，是留着空白的一列还是这一行从四列变为三列呢？

再比如，图3-4的两个按钮是根据数据库中的数据动态生成的，可能是一个按钮，也可能是多个。如果是多个并且超出屏幕的宽度，需要做折行处理，还是让每行显示多个按钮，这都不可能在初版设计稿中全部体现，因此就需要小蔡根据自己的测试常识与业务人员和设计人员商量了。

事实证明，小蔡拥有的这些针对界面设计稿的测试思路，让她在做kick off卡时能及时提出很多有效建议，极大地帮助团队澄清需求，减少了开发返工，也大大提高了团队工作效率。