前言
最近项目中涉及了大量的前端页面类测试，如小程序、H5等多个B、C端的测试，故而想把一些心得记录下来，仅供大家参考。这里仅仅对前端测试中涉及的需求层面的问题做简单剖析，希望借此来抛砖引玉。
前端测试的困境
回顾从刚刚入门测试到现在，进行了大量B/C端的页面类测试，包括：机票类页面、促销类页面、视频类页面、招聘类页面、广告运营类等等。测试范围包括：功能、性能、兼容性、易用性、一致性、用户、缓存等等，当然针对页面具体是应用于PC WEB端，还是手机端，亦或是m站，会有不同的侧重点。
记得刚刚入门测试的时候，参加工作不久，有人就提出了：测试绝不是在页面上点点点就可以了。当然，当时的背景不是说页面测试，而是包括后端+前端的整个测试项目，仅仅用“点点点”的方式测试，由于无法很好的把控测试的广度和深度，因而最后的质量会大打折扣。但时至今日，抛开含有后端的项目，仅仅针对前端项目而言，大体的测试过程如下：
- 需求下来后，用例设计及评审
- 根据用例执行测试
- (视情况而定)团队内部/相关用户内部体验
- 操作上线
整个过程显得“轻松而简单”。因而在实际的项目中，这块测试并没有收到足够的重视，甚至全部交由给新人完成测试上线。由于对整个前端测试重视程度不够，上线后往往带来的困境：
- 线上灾难。导致几周甚至更长的工作被完全推翻重来。记得同事曾经经历过的一个项目，研发测试团队经过几周的日夜奋战把页面大改版推上了线，结果大boss看到后不满意，一句话直接回滚了回去。
- 增加质量风险。由于大部分修改不涉及后端，成本相对较低，团队成员往往形不成"防微杜渐"意识，但却给线上无形中带来的质量风险
- 返工。用户反馈不好用，进而通过后续的几次上线，来进行优化/修整。如此反复，造成团队成员疲于奔命与“修修补补”
前端测试的出路
之前的博客质量的层次中简要的把质量分为的硬质量、软质量，对应到整个前端测试上面来同样适用。上面说的的困境问题(返工、质量风险、线上灾难)都不属于产品实现层面的问题，而是属于需求层面的问题，简而言之：产品给出的需求并不十分符合用户真实的需求。 因而，尽管根据产品需求进行实现、测试，等到产品上线后，一样会出现问题。
当然了，需求层面的问题解决需要团队成员的共同努力，但这里想对QA在测试阶段的测试深度说一下自己的思考，期望能减少上述的困境。
针对需求层面的问题，大致可以从以下几个方面入手解决：
- 需求评审阶段的慎重。尽可能让需求改动上传下达，减少需求理解层面的gap，达成需求理解的一致，避免“推翻重来”的发生。
- 上线过程的慎重。可以通过规范回归范围、内部测试、线上验证等方式，规范整个上线过程，避免随意改动后上线。
- 用户体验测试的慎重。在整个硬质量、软质量测试过程中，用户体验方面的测试应该引起足够的重视，以不同的用户角色，模拟用户的不同操作场景来进行，以此来发现需求未明确定义的bug。
用户体验测试的实践
上面分析了用户体验测试对前端测试的重要性，针对其的实施，根据自己的实际操作经验(实际项目中10%+的bug来源于此)，有以下几个方面的建议：
- 用户体验测试需由测试经验丰富的QA来操作，并让团队成员一同参与体验。因为用户体验通常通过探索性测试、随机测试、场景测试等方式展开，需要具体执行人对用户、对易用性、产品交互等有足够的经验。
- 将用户体验设计、产品设计、人性与产品等的思想尽可能同步给具体执行人
- 多多分享“违背用户体验”的bug给开发人员，尽可能将bug扼杀在开发阶段
- 角色扮演。具体执行人将自己扮演成各个用户角色，模拟其需求和心理，进行测试
总结
易用的产品，应该能和其用户进行流畅、愉快的“对话”，因而产品除了提供一种/几种服务外，还要充分顺应人性，才能让用户在使用过程“畅通无阻”，使用后“流连忘返”。人性中存在亘古不变的懒惰、贪婪，因而产品只有顺应了人性才能紧紧地抓住用户。否则，一旦有了违背人性的表现(让用户多做动作、让用户多思考、让用户情绪失落)，便让用户失去兴趣。这便是前端中有关用户体验测试最重要的思想了。