外部篇产品测试技能总结.docx

外部篇产品测试技能总结.docx

《外部篇产品测试技能总结.docx》由会员分享，可在线阅读，更多相关《外部篇产品测试技能总结.docx（9页珍藏版）》请在冰豆网上搜索。

外部篇产品测试技能总结

日常产品测试工作方法总结

淘宝-北京用户研究团队如墨

年底了，回顾一下近一年来所参与过的测试方面的工作。

加入淘宝用户研究团队近8个月，或主导或协助各业务线进行各类产品测试项目十余次。

所有这些项目类别不一样，方法不一样，阶段不一样，思路也有所不同。

每次测试都有一些小感悟，零零散散的记录一些，今天整理出一个全面的总结，是对自己的一次梳理和积淀，也供大家借鉴。

对这些测试，我根据自己对其适用阶段，方法的认识进行了大致的类别划分，比如适合于新产品、新概念的从无到有的概念测试，适合于方案优化阶段的方案对比研究，适合于评估产品实现效果的单一页面评估，还有适合于产品开发后期，用于细节完善的产品可用性测试，以及其他日常小测试等。

这样的分类便于自己去归纳和总结，也是根据这样的分类，结合实际项目，对每种方法做了一系列的总结归纳。

一、概念测试——我的idea靠谱吗？

当PD或设计师们在业务领域上产生了一个新点子、新想法，需要进行验证其可行性及价值时，或者当现有的业务线进行了交易流程或产品架构上的大变动时（导致用户可能面对一个与以往习惯不同的新概念），此时需要用研以概念测试的方式介入，辅助其规避风险，避免造成资源浪费或大规模用户流失。

关键词：

新概念，关键任务，用户行为模型，体验底线

项目难点：

下结论需格外谨慎，所得结论都是大问题，涉及对产品概念的否定。

客观中立，坚持原则，一旦得出结论，要以实际情况为准，坚持用户体验底线问题。

测试材料：

可以说明完整流程的低保真产品原型，各相关页面的框架图

方法指导：

1.概念（产品）主功能定位：

每个新概念都是为了满足某类人群一种或几种典型需求，也对应着相应的使用情景及操作任务。

和业务方沟通，明确该产品的主要功能（做什么用的），使用情景（什么时候用，怎么使用），目标人群（哪些人会用），这是准备测试的第一步。

2.典型任务分解：

产品概念对应着具体的典型任务。

这种任务大多时候是综合性的，需要将其按用户的思维按阶段拆解为数个子任务。

随后概念测试的重点将落在被测概念能否支持目标用户完成每个子任务上。

3.梳理测试风险点：

对用户的行为了然于心后，结合概念原型，做任务分析，系统的梳理出需要关注的测试点。

测试点可能包括，新概念流程是否符合心智模型，关键入口或操作能否发现，能否理解，一步任务完成后有无有效反馈和引导，阻碍任务完成的障碍在哪里。

任务梳理过程中，要注意有关注重点。

4.设定测试任务：

根据风险点，准备测试任务。

与可用性测试任务不同的是，概念测试的任务不需要特别具体，产品交互尚未成型，没必要，另外低保真原型也无法支持含有很多细节的测试任务。

这里需要测试的是任务主干，主流程是否合理。

5.测试执行：

概念测试执行的过程中，访谈的成分更重一些。

将更多的注意力放在用户在任务情境下的行为本身上，通过参考原型，结合访谈可以在每个用户测试结束时，在心里生动地构建起用户行为（决策）模型。

在测试过程中，要特别注意阻碍任务的障碍点是什么，属于哪类问题，有多严重，该问题能否妥协，可能的解决方式方法是什么（及时记录下新想法，在后期验证）

备注事项：

概念测试对应的是产品问题。

测试所得结论大多为任务阻碍性的产品结论，产品概念认可度等，可用性问题不是概念测试的关注点；通过概念测试要抓到用户完成任务的行为模式，及影响其决策的关键要素；通过测试把握好概念的症候底线，即不可妥协的关键问题点，否则容易出问题。

二．方案对比研究——这么多方案，哪种更好？

面对同一个问题，有多重实现方案，哪个是较好的？

运营有运营的思考，设计有设计的目标，多种想法不统一时，何去何从？

这时往往涉及多个方案的评估，最后的目标是从中选优，可能还要取长补短。

关键词：

多方案，大样本态度偏好，方案筛选，方案优化

测试难点：

选择偏好的具体原因定位，这种原因是否可转化为优化设计

测试材料：

多种方案视觉效果图

方法指导：

多方案的对比测试，通常都需要对ABC种方案进行对比评估,其目的是通过大样本量的投票方式决策出用户喜好的版本。

方案版本间有较大差异，在设计、信息表现形式上有明显不同。

做此类测试时，在大致方向上，注意以下几点：

1.数据收集：

具有代表性的选择意见，可以落地的参考意见。

方案对比研究多涉及大众的选择意见，理想化的方式是采用大样本量面对面投票的形式，获取用户倾向比例，更重要的是取得令人信服的倾向选择的具体原因，这种对原因的探究越具体，指导意义越强越好。

再配合眼动数据分析辅助说明结论。

2.突出重点：

这种对两种页面方案进行对比评估时，最重要的是将用户带入到尽可能真实的使用情景中，在开始之前可以简单介绍产品或页面的功能，假定使用场景，以及对比感受的侧重点（比如在目的地版式方案对比中，强调了内容功能一致，版式设计，使用方式的不同是体验的重点）；

3.任务设定：

基于平面效果图的产品试用，在任务的设定上不能像可用性测试那样过于具体，设计适当宽泛又有代表性的任务，让用户可以体验整体，也可以把握重点，知道我们想要他们去对比什么；

4.原因本质：

方案对比研究中，选择了什么不如为什么选择更有意义，因为最后的版本可能是基于现在的调研多个版本揉合的结果。

所以，用户给出选择意向后，要跟踪其作出决策的原因，对选定的方案主要认可哪里？

有什么可以改进的点，不认可的方案差在哪里，如果改进了（可以作出修改的问题上），还会坚持现在的选择吗？

除此之外还要了解用户对两方案认可程度的差异性，对AB两个版本进行打分（主观喜好程度）。

5.撰写报告：

方案对比研究的报告结构可以参考：

主要结论——行为分析——各方案优缺点——summary——细节对比补充。

报告结论的书写，一定要站在用户的角度描述问题，不能过于概括、抽象，脱离具体问题的结论容易被挑战（如，页面的设计缺乏层次感可以还原为用户抓不到页面的重点信息）

备注事项：

∙在测试过程中，往往需要通过用户一次使用两个版本，逐一分别询问对多个方案的单独意见，然后再询问对比意见。

用户在使用完第一个方案后，可能会对第二个方案产生影响。

这是需要执行中注意的，需要用随机和大量样本来保证结果的准确性；版本的选择意见，不是少数人能代表得了的，所以在用户量方面有一定的要求。

∙在原因获取时的访谈方面，没有特别具体的提纲主线，一切以用户的反馈为基础，判别是否为普遍性问题。

值得注意的是，对于原因的定位，一定要具体，具体到可以为产品的提升有指导意义，宽泛的“喜欢”“习惯了”“漂亮”等数据没有价值（当时师兄原话：

想想你的数据可以用来写报告了吗？

）；页面对比评估关注方面不是可用性问题，应该是概念传递、使用行为模式等层面问题的不同。

三、页面评估测试——我实现的效果怎么样？

当概念和想法确定后，需要将概念转化成视觉丰富的产品原型时，可能需要对实现效果做预评估，页面的实现效果能不能达到产品目的，实现的效果如何，这一步有没有体验损耗。

页面评估测试需要结合眼动实验，对眼动结论的依赖程度相对其他测试要更高。

关键词：

页面功能，信息组织结构，注意力分配，信息传达效果

测试难点：

页面评估以页面效果图为测试素材，评估静态体验问题为主。

如果涉及较深的交互测试，可能无法达到目标（更适合做可用性测试）；对相关任务的记忆性、易学性等指标测量在一次性评估内无法解决；没有一个系统的方法，衡量用户感性认知。

方法指导：

其性质是情景模拟+简单的试用+定性访谈。

对单一页面做评估时，测试关注点通常归纳为以下几个方面：

1.相关任务决策模型。

采用情景访谈法，获得用户任务决策最关注的核心因素，通常其结果决定了本页面应该含有哪些核心内容（如参与合买时，最为关注的积累信息）；

2.用户的行为模型。

通过任务设定试用，观察用户是如何执行任务的，其结果可以判断页面信息结构上是否存在问题（特别注意页面多个信息块之间可能存在的关联性，如在目的地详情页测试时，涉及到信息展现顺序是否合理的问题）

3.页面布局页面元素等含义传达，可用性等细节问题。

结合测试，就具体重点元素进行访谈，获取用户对重点元素的理解，接受程度。

4.接受度评价。

另外，如果有必要的情况下，可以辅助满意度，接受程度的主观评价（分主观喜好程度和可用性两方面进行评价），重点不在分数的多少，目的是通过用户分数，复述对页面的意见，以作确认。

四、首页改版测试——特殊的页面评估

首页的意义非常特殊，利益相关方很多，用户、设计、产品、运营，甚至是技术都有各自的目的。

首页的最终相貌绝不是哪一方可以单独决定的，是多方思考综合权衡的结果。

这导致，类目首页改版涉及的东西纷繁复杂，且老用户流失风险很大。

因此，首页改版评估的重点不是对某一方面的测试（如视觉），而是站在全局的角度去思考，去评估各方利弊。

关键词：

权衡，信息优先级，导航，老用户习惯，运营

测试难点：

通过多方利益的权衡，准确把控改版主要风险点；做到以运营的视角审视改版方案风险与价值

测试材料：

主要是当前终极版本效果图，实现必要的动画及交互

方法指导：

在首页上，每一个图标，每一个连接可能是首页元素的百分之一，但对这图标背后的整个业务影响是百分之百。

首页评估的难点是需要照顾到的东西太多，照顾不全，因此难以准确把控主要风险点。

首页改版究竟怎么做，有没有一套完整的测试梳理思路？

总结，可以从以下几方面入手：

1.以评估改版目标的达成效果为思路：

每次改版都必然有其目的，不管是优化部分用户体验，还是为了业务转型做准备，还是旧貌换新颜传递某种设计理念。

有目标就有思路，和产品经理充分沟通，参加prd评审会，抓住目标，评估目标。

（衡量改版效果，决定了被试特征）

2.以首页功能和内容为思路：

就首页的本质来看，可以将其视为功能和内容两部分组成。

功能即导航，内容即所包含的信息。

首先，便捷的导航是首页的使命，对首页导航的评估是重中之重，改版后的首页，导航效果有无改善，可视性、易用性有没有受影响，新式导航的易学性，记忆性如何，这是评估的重点。

另外，快速任务其实是快捷导航的一种，用户习惯通过首页达成的快捷操作有哪些，这些快捷任务，改版后的首页能否在效率上有所提升也是对导航效果评估的一部分；其次，在首页所包含的内容上，根据业务特点，考察用户期望在首页上得到什么样的信息，哪些信息是有价值的，重要度比较高的，首页上的内容是否全面，还是存在信息赘余造成了困扰，对信息内容的关注，其结论可以帮助设计师调整版面布局。

值得一提的是，用户的需要是影响首页信息架构的一方面，但不是唯一因素，业务需要等同样对首页上包含什么有绝对影响（如运营位，产品主推内容等），我们可以提供全面参考，决定权不如留给PD们。

3.以设计效果为思路：

视觉中心区信息与主任务的契合度，首页信息模块的重要度排序，各信息模块间的相互关联或干扰程度，各模块的信息传达效果评估，交互效果对用户的影响。

另外还有一点是我们以前没有特别关注的，对用户情感方面的评估。

4.以运营视角为思路：

正如我之前做的那样，以前评估过于集中在设计视角了，对其他方面的思考不够成熟，尤其是运营的视角。

这可能与我们与运营的接触不够多，了解不够深有关吧。

运营的重点是什么，他们的担心是什么，这些方面在准备测试阶段的关注往往是不够的，通常要在其他渠道才能接触到运营的想法，如邮件、测试后的宣讲沟通会等。

以后需要注意在开始之前就主动了解运营需求。

另外，以运营的视角为思路不只是要考虑到运营方的顾虑及测试需求，还需要用运营的视野来看待改版，例如，新的导航形式在今后的业务扩充上是否存在问题。

总之，用运营的思维武装用研的大脑，会拓展视野，然而，用研与运营的鸿沟通常大于与设计的鸿沟。

首页改版是多方利益权衡的结果，感觉上对其测试也是一个从粗到细的梳理思路，尽可能规避主要风险，评估改版目标实现程度。

利用访谈、眼动、试用、任务、量表等多种方式得出结论。

备注事项：

新用户来了，老用户更重要，必须重视老用户的习惯和感受，改版千万不能“辞旧迎新”；评估的是当前，着眼的是未来。

对首页的评估，不能忘了业务的延展性；

五、产品可用性测试——我们可以做的更好

可用性测试一般应用于产品设计后期，邀请符合要求的真实目标用户，按照预先制定的任务书来使用产品或高保真的产品模型，通过观察用户操作过程，从而发现其中的可用性问题。

可用性测试主要集中在发现可用性问题上，比较适用于对现有产品和设计的评估。

可用性测试的方法已经很成熟，而且更加规范化，是其他所有产品测试的变异根基。

关键词：

交互测试，高保真demo，真实任务情景

测试难点：

在观察过程中，敏感的发现可用性问题的质量和数量，是需要依靠观察员的经验和素质的，这点需要长期培养；可用性测试过程中，要选择恰当的，现有条件可以衡量的可用性问题指标，有些指标很难测，有些容易测不一定对本次项目有用。

根据产品特点选择好指标，及测量方法；复杂的产品任务多，需要覆盖的可用性测试点也多，容易导致测试任务臃肿，如何编排任务，如何为测试点排序比较费神。

方法指导：

可用性测试的完整过程和各过程中所需文档都有专业的文献和教材，在测试中，主持人应该注意的哪些事儿，我们也常常讨论。

这里只写下我感触较深的两点。

1.产品任务分析：

像在一次分享上，阿福所说的，每个页面或产品都有它的关键问题，产品是否解决了用户在某种情景下的关键问题，这是产品测试的主线。

在测试准备阶段，尤其新手，需要重视任务分析工作，分析任务的结构，包括任务目标、操作方式和信息流及可能存在的障碍，具体方案可以参考岚英分享的《启发式评估》思考问题的视角。

任务分析，得到一个完整的任务结构表，可以帮助我们理清要点。

2.任务设计：

可用性测试的任务不宜复杂，单一任务目标下，用户体现出来的可用性问题更纯粹。

在设计任务时，不是所有的测试点都一定要做，需要根据重要度，任务结构的差异性等判断哪些确实需要测。

另外，编写测试脚本时，要富有故事感，以用户的使用情景为思考角度，争取多个任务连贯，衔接合理顺畅，这样用户更容易带入情景。

不要只根据我们自己测试点的重要度排序。

备注信息：

传统的可用性测试，周期长，资源消耗大。

因为其适用在产品开发后期阶段，导致发现问题后留给产品修改的余地小。

因此，简化及快速可用性测试在互联网产品研发过程中更加实用一些；

六、其他测试

●体验极限测试

关键词：

用户体验极限，放弃比率

典型案例：

某业务loading时长容忍度测试

方法：

Loading时间在多长的时候，用户会失去耐心？

当时的做法是每5秒为一级，做数个阶梯方案，配合7分量表，让用户一次试用并打分评价。

备注事项：

1.用户试用的方案不能过多，否则产生疲劳影响准确度，且用户配合意愿下降；

2.因方案数量是有限制的，在方案制作时，对变量的确定一定要有可操作性，有实际意义（如等待时间，要考虑目前版本的平均时长是多少，可改变的幅度范围是什么，对于等待时间肯定越短越好，因为有技术成本的原因，我们要找到用户放弃的关键时间点，在用户放弃前，参考现有技术资源去优化）；

3.顺序对用户感知的影响很大，随机处理很重要；

4.结果分析时，找准导致用户开始放弃的点和用户放弃率急剧上升的点；

5.因为是试用结合选择意见，样本的数量要够大才有参考意义，上次做了100人的样本。

●控件对比测试：

交互控件易用性测试

交互控件的对比测试本质上与方案对比测试方法一致，只是测试对象不同，着眼的问题也相对简单一些，控件的易用性、易理解性，及如何更好地根据用户的习惯去优化。