回避测试方法论

测试流程

①项目相关人员自行测试

②公司内部测试

③用户内测

④用户公测

评分标准

美观：美观上面不应得低于市面上已经出现的类似产品，并且设计理念要贴近现实，让用户容易理解设计的理念。在美观的同时应当遵循BESD的功减设计方针。

性能：性能上应当保持至少是良好的状态，根据具体的技术的性能标准进行评分。包括但不限于数据库语句平均执行数、执行时间、网页加载时间、网页get请求数等等...

交互：交互上面应当简洁易用，能够让测试者在没有帮助文件或者他人指导下流畅的使用，即使出现问题，也能够在一分钟之内自行找到解决方案。对于交互较为复杂的（如手势、体感等），应当在测试  者使用的第一时间自动给出合理的引导。

人性：测试者在使用的过程中不应得有不舒适的感觉，在整个使用过程中都应当符合人性化理念。同时像在需要设置、搜索等情况下应当提供应当具有比如智能推荐、自动设置等帮助用户更简易的使用。  同时应当符合基本的心理，如按钮放在哪边用户能够更舒适的点击。

质量：在回避测试情况下，重大影响的BUG不应当超过三个，一般影响的BUG不应当超过二十个。同时BUG不能影响测试者的正常使用过程。

难度：难度是根据项目周期、项目功能总数、项目各功能复杂度、资金成本、人力成本进行估算。可以根据难度适当降低或提高质量评分标准。

回避测试

根据RD项目的实际开发和测试经验，提出回避测试方法论。

在公司内部测试中应当采用回避测试方法。回避测试是指与该项目有关的人员回避，由非相关的公司员工进行测试，通过模拟正常用户的使用过程来使得测试更加接近用户真实使用情况。并且根据美观、性能、交互、人性化、质量、难度六个维度进行评分，最高分为5分。如果其中一项的平均分低于4分就应当进行改进，不得进入下一阶段。

回避测试可以有效避免开发人员以自身开发时的逻辑流程进行测试，可以避免思维局限有效发现更多问题、降低用户真实使用过程中的问题数量及减少在正式运营时迭代的代价。

反馈定义

重要BUG：对项目使用过程中造成了重大影响或者使功能失去效用。

普通BUG：对项目使用过程没有重大影响或造成的影响局限于二级或二级以下的功能。

建议：对项目评定的六大方面具有正面影响，可以提升项目在某一方面的表现。

处理状态

尚未处理：项目负责人员尚未查看该问题的状态。

等待处理：该问题进入处理队列的状态。

正在处理：项目负责人、工程师正在修复或新增、改进问题时的状态。

延迟处理：BUG存在但未确定其发生场景、建议有效但有待观察等状态。

挂起处理：该反馈有争议或者BUG无法验证但是用户已出现该BUG。（当更多用户出现相同问题时，该问题应当提升至延迟处理）

取消处理：该建议无效或BUG不存在。