软件由企业交付之际, 业务方常常会问, 这套系统究竟可不可以上线呢, 验收测试不只是技术方面进行验证, 更是商业承诺得以兑现的过程。好多人错误地认为测试完Bug就算是结束了, 实际上却忽略了业务闭环以及用户体验。真正的验收标准, 在于是不是能够满足合同规定的功能清单以及性能指标。要是跳过严谨的流程,后期维护成本会呈指数级上升的。所以, 明确测试边界以及责任归属, 是项目成功的关键前提条件。
开发测试所关注的代码逻辑以及模块功能, 与验收阶段存在着怎样的本质区别呢? 开发测试的目的在于发现缺陷, 其是针对代码逻辑和模块功能展开的；而用户验收测试也就是UAT, 它所关注的是业务场景以及用户需求, 目的是确认价值。开发团队要解决的问题为“系统能不能运行”, 客户所注重的则是“系统好不好用”。这种视角方面出现的差异, 使得双方对于同一个问题的容忍程度不一样。就比如说, 有一个不会对核心数据造成影响的轻微UI错位情况, 开发人员或许会把它当作低级Bug, 然而业务人员却可能觉得这会对品牌形象产生影响。把这一界限梳理清楚, 能够减少数量众多的无效沟通。
怎能够以高效的方式去执行验收测试的流程呢? 第一步是要依据需求规格说明书来制定出详细的验收用例, 以此来确保能够覆盖住所有的关键业务路径。第二步是搭建起接近生产环境的测试数据, 防止去使用过于理想化的样本。第三步是组织真实的用户代表参与到测试当中, 记录下实际操作过程里的痛点以及反馈。在这个过程当中, 务必要建立起缺陷分级的机制, 区分开阻塞性的问题与建议性的优化。只有当所有的P0级缺陷都被修复而且P1级缺陷有着明确的暂缓理由的时候, 才可以签署验收报告。
在验收测试里, 有哪些常见的陷阱是需要去规避的呢? 其中最大的误区在于, 依赖测试团队去代替业务方做出决策。测试工程师虽然擅长找出错误, 然而却不太了解业务方面的细微差别。必须要由最终用户来主导签字才行, 不然上线之后极其容易出现那种“功能是正确了, 但是却没办法使用”的状况。另外, 要是忽视了像并发压力以及数据迁移完整性这样的非功能性指标, 往往就会导致上线之后马上崩溃。建议在验收之前进行预演, 对真实高峰流量进行模拟, 以此来确保系统的稳定性。只有把细节都做到位了, 才能够保障项目平稳地落地。
