提Bug，我们是认真的

项目进入测试期，经常有开发晚上加班碰到我问：你怎么也还在加班？潜台词是系统都快上线了，不用画图了，你加班做什么。这个环节UCD都在做什么？今天来聊聊UCD加班测试提bug的那些事。

一、验收测试的目的 

需求-产品的演化过程

产品从零到1经历上图4个阶段，每个阶段都是对上一环节的不断细化，抽象到具象的过程。而原型到真实产品之间存在着各种差距，如数据差异/异常处理/产品跳转链接/点击区域与反馈。所以验收测试重点在做两件事：1.确保真实产品与高保真原型一致性，也就是确保经过层层评审的原型能最终落地，不浪费前人努力。2.可用性测试，验证高保真未能涵盖的内容或针对已有设计提出易学性/有效性/适应性的问题，形成测试问题集，从而优化产品体验。 

测试重点

二、原型与产品一致性检查

比对方法很简单，在页面布局、交互说明（流程、部分响应要求、反馈方式）、视觉标注包括文字颜色、图片、间距等方面检查原型与产品差异性，圈出不符合的问题点提bug。过程中，因开发工期紧张/开发不熟悉规范/不熟悉前端框架等原因，易造成修复不及时/修复过程引起二次bug/优先级降低最后不了了之等问题。分享小心得：

1、推荐用PPT登记问题，针对每个页面截图标注问题并提供解决方案。原因是它比word、图片的标注更灵活，便于处理验收过程中反复或新增的问题。已解决问题标注灰色，未解决问题红色，随时可新增问题。

2、Bug拆分，通常一个菜单我们能测出30-50个大大小小的问题，便于开发快速解决问题，针对bug进行有效拆分可分别按难易程度/修复人/菜单/页面/同类问题拆成一个单。

3、使用UI日报，项目工期紧张UI问题优先级低时，可通过ppt+excel表的方式共同记录问题，Excel表登记：菜单/路径/问题分类/优先级/测试人员/解决情况。通过每日汇报总问题/未解决/已解决问题进度让领导及时掌握风险并评估UI问题重要性。

不管哪种方法手段，跟项目领导/前端开发多沟通，找到共赢的方式是最佳。并在过程中根据现状去调整，比如Bug总是反复就要分析原因，若是基础控件使用场景出错，则可组织UI规范/组件使用培训，促使大家达成认知一致。其他推荐文章：http://www.woshipm.com/ucd/461871.html 

三、可用性测试提升体验

可用性测试原则与方法

这个过程侧重于与真实产品的交互体验，常用评估方法有很多：启发式评估/认知过程走查法/参与式评估。这些方法在应用于原型测试也应用于系统测试。写测试脚本（可理解为场景或任务）—产生问题列表—邀请专家评估是否修复—排定优先级。而实际操作中更多是内化为设计师的能力，通过体验产品提出问题。

---

写在最后，现在大多数产品都特别注重用户体验，不像以前UCD提出问题，项目组还要这推那推的不想解决问题，现在只要你专业并提出专业的问题，基本上都能采纳并尽力去解决问题，当然有时项目实在紧张，优先解决功能类刚性问题也是常理之中。另外在敏捷项目中，交互设计师更多承担类需求的工作，辅助SA做好功能验收也成为设计师的隐性工作之一，特性团队向全流程团队转变，所有人都应为保证项目运行，尽自己所能的去发现问题并解决问题。