常见的非功能性需求和应对方式

工作这么几年来，见得最多的场景是 QA 小伙伴满办公室追着开发报 bug，有时候开发会不乐意，“当时可没说要 XXX，要做 XXX。”

好像 QA 小伙伴永远比开发多一点心眼，即使单元测试覆盖率达到 80%，QA 还是变着法都能找出问题。

这其中很大一部分原因都来自于“需求背后的需求”，BA、QA 小伙伴以为你考虑到了，或者默认开发需要考虑到。

比如 CMS 系统中一个新建文章的需求，不太可能写出需要防止表单二次提交的 AC（Acceptance Criteria，验收条件），然而如果没人提出来谁会知道呢？

（最近很火的冰山图）

最终 QA 或者线上的用户会通过报 bug 告诉我们。

我们把这些隐藏在功能需求背后或 BA 默认认为开发需要考虑的需求称为非功能性需求，有时候又叫跨功能需求。

下面就来说说在工作中常见的非功能性需求和应对方式。

一、交互体验相关

Loading 加载状态是最容易被忽略的一个需求，尤其是在现在富客户端开发的模式下，数据的获取都是异步加载的。如果忘了考虑这条需求，在网络条件较好时会出现闪烁的情况，而在网络情况差的条件下又看起来会卡顿和没有响应。

实现统一的 Loading 可以在前端的网络请求库中增加拦截器，不过需要注意使用计数器让多次网络请求中途的 Loading 图标不会间断，否则会有闪烁的问题。

1. 表单的二次提交

有一些 QA 会使用极端的测试方法，例如快速点击按钮多次，如果页面没有进行处理，会触发表单多次提交的问题。即使后端 API 增加限制则可能同时出现成功和失败的提示，会让用户感到更加迷惑。处理这个问题有几种途径：

• 使用蒙层的 Loading 就会自带阻塞用户的操作的效果
• 点击后禁用表单事件或在程序中增加请求中的状态
• 依赖后端配置一次性表单令牌（通常用来防 CRSF）

2. 输出格式化

需求中一般会告诉开发怎么展示数据，但是往往会忘记如何格式化数据。

例如我们想让数字使用千分位分隔或其他显示方式，让数字阅读不那么困难；字符串溢出的处理截取方式；时间的格式化方法，有一些项目会使用“一小时前”，“一天前”或者具体日期等更为人性化的显示方式；图片的输出需要宽度进行缩放，如果是封面图需要非拉伸截取等。

3. 请求用户确认和提示

这两项专业 BA 一般都会考虑到，也会通知 UX 设计对应样式。不过这里面的细节还是值得讨论。

• 如果在一系列操作的中途提示用户确认，需要明确用户点击取消后，应该回退到用户的哪一步操作状态。有很多的 APP 在用户编辑好数据后，点击提交然后系统提示是否继续，如果用户点击取消，页面上的数据会被清除。开发需要和 BA 确认好具体的交互以及提示文案。
• 成功和错误的提示除了文案之外，和 BA 需要确认的还有：是独立的提示页还是返回到来源页面？提示需要自动关闭还是等待页面刷新后关闭？用户可以主动点击关闭吗？

交互体验这部分还有一个需求噩耗就是，保持统一！！！我想这个是交互体验上最为致命又不会写在需求中，但是 QA 往往能从中找到 bug。

二、安全相关

1. 身份校验和权限

URL 上资源可以被枚举和请求的资源没有验证用户权限，这属于致命而低级的安全问题，当然 BA 会默认开发要去做这些。不过现实就是在一些遗留项目中这种例子太多了，例如通过修改 URL 上的资源 ID 甚至 userID 此类参数进而修改其他用户的数据。

几年前，可以发现很多此类漏洞，甚至在我学生时期用某电信运营商的权限漏洞得手了不少付费游戏。如果系统设计了权限管理模块，在开启新功能时也应该和 BA 确认是否纳入权限管理。

2. 表单验证

用户输入的数据如何验证这部分也是经常在需求上忘记体现出来的地方，而且这部分 QA特别容易给出 Bug，数据验证充满了大量的条件边界。

还有一个老生常谈的问题，表单验证应该服务器端还是前端做？

这很显然，后端为了安全必做，前端为了体验选做。

3. SQL 注入和 XSS 攻击

SQL 注入这两年随着成熟的 ORM 框架普遍使用几乎没有了，但是 XSS 可以说还是有很多。

处理 SQL 注入和 XSS 攻击的共同点是不要相信任何用户的输入、任何来源。

在浏览器中用户输入不仅有表单还有 URL，而往往 URL 输入参数很容易被数据校验忽略。

4. 文件上传

文件上传背后的需求有上传文件的类型、大小限制；需要和 BA 确认是否能批量上传，上传前是否需要预览；上传后如何命名，是否需要在上传过程中对图片或视频进行压缩。

这里的安全需求是，不应该上传可执行文件；需要获取文件真实的类型信息而非后缀名。

文件上传的一个陷阱就是使用了客户端来源的文件名作为文件存储的文件名，这是极为不可靠的，在上传后的文件系统中需要使用内建的唯一命名，并通过数据库来记录用户上传的文件名。

三、性能相关

1. 响应时间

说实话，没见过那张卡上有明确的指标那些功能需要在多久之内完成响应。但是如果不在分析业务需求的阶段提出来，响应时间过长肯定通不过 QA 测试。在需求分析阶段的响应时间包含了三个注意点：