寻找用户轨迹的“探索性测试”

国内的大部分公司在做交互设计的时候很大部分都是处于探索阶段,但是因为产品的商业价值很难允许失败,所以很多设计师对于交互设计的结果都很难确定,甚至会因此屈服于商业价值,从而导致了一个恶心循环。

  在上次的D4设计论坛中,针对于口碑网改版的设计方法,UT斯达康的设计经理提到了利用新旧入口的方式来进行用户测试,并提出了使用新界面提供老界面入口的方式进行用户测试。在我们设计产品的时候其实也可以利用产品的特性进行一些“探索性测试”。

  测试大致可以分成几种:一种是验证性的测试,在知道结果的前提下进行验证的测试,一般运用在学科领域的实验室中,更多的是对理论数据计算的结果进行验证;还有一种是探索性的测试,在未知或者并非全部了解的情况下进行探究的测试,主要是针对新产品新事物的一种尝试。探索性测试更多的使用在创业型产业领域中。

  Tidwell,J在《Designing Interfaces》中提到“在设计各种软件界面时,可以给用户留下实验性的通道来让他们探索和尝试,同时别让用户付出任何代价”解释了产品在使用探索性测试的时候应当注意的问题,在兼顾探索性测试的同时要避免给用户带来的阻力。

  在交互设计中,探索性测试可以分为以下几种:

  1、A-B test

  这种方式主要是在不明确产品的目标数据是否能够符合前期目标时所采用的一种模式。主要工作便是将产品的新旧版本平均随机的分配给用户进行使用,利用一至两天的时间进行数据检测,获得横向数据并进行比较可以得出新版本的优缺点以及确定修改的权重比。这种方式主要的优点是可以直接给出横向比较的情况,直观的了解新产品的优缺点,不过它的缺点是只限制于设计师对产品服务端更新优化的权限时刻保留,并不适合散发式单线使用产品(主要是指产品的控制权暴露在用户端并且没有和服务器端进行数据交互)。并且A-B test的模式会牺牲部分用户的使用状态,会给企业的用户使用度有所降低。

  2、新旧饱和测试

  新旧饱和测试主要是指推出新产品,但仍保留原产品的入口,进行用户测试。刚才说过,口碑的改版也是利用这种模式进行,而且还包括了淘宝、Google等网站也经常利用这种测试方法进行探索。它主要的优点是能够在新界面不影响用户的前提下,给用户返回旧界面的通道,减少用户牺牲,并且也尊重了合理撤销的理念。从用户角度出发进行的一些改版往往会不明白用户的使用情况到底如何,从商业角度来看新产品的价值点则是更高的,所以这种测试方式可以大大降低商业风险,并且利用“撤销概念”提高了用户体验。但它的缺点是浪费了产品空间,给服务端带来了数据兼容等后台的压力。

  3、引导性测试

  这种方式是指利用现场演示的方式为用户进行解说,更多是指还未上线前的一种用户测试。这种测试的优点是设计师能够更加贴近用户了解用户的想法。但是这种方式有很多局限性,首先是人员数量上比较少,其次是产品不够成熟,往往会带来很多用户并非真正理解产品,再者就是人工引导会给产品的可视化交互带来一定影响,无法得知用户的交互轨迹。这种测试很多情况下都是用于全新的产品。

  4、发散性测试

  这种方式也是比较传统的方式,主要是设计师不断借鉴其他产品的用户数据进行模拟从而得出测试预估结果,并且通过多种途径为预估结果进行数据监测。例如获得产品的使用量,用户的关注度,投票数等方式来了解真实环境中的用户模型,并更新改进原产品。它的优点是能够逐渐提高产品质量,以及设计师的预估能力。但这种模式主要缺点是周期长,预估能力要求高,二期修改成本大,对于现有阶段的公司来讲虽然用的比较多,但却不是最可取的一种方式。

  这几种测试方式,并非等同于可用性和易用性的用户测试,而是对目标数据的一种产品设计预估测试。虽然目前很多公司对于交互设计还是个探索,但是如果合理利用这几种“探索性测试”的方式来获得更多宝贵数据的话,交互设计的路应该会走的更顺一些。

====================================分割线================================

最新内容请见作者的GitHub页:http://qaseven.github.io/

时间: 2024-09-10 14:46:42

寻找用户轨迹的“探索性测试”的相关文章

探索性测试(四):探索性测试并不是快速测试

快速测试也是一种测试的方法,它既可以照本宣科的进行,亦可以探索的方式进行.尽管一个使用高度探索性方法进行测试的测试员可能会执行很多快速测试,而快速测试也通常是运用探索性测试方法时的重要因素.但是,快速测试和探索性测试并不是一样的. 快速测试是需要少量时间或一点精力去准备和执行的廉价测试.这类测试甚至不需要具备与待测试的应用程序相关的大量知识或相关的业务领域知识,但它们有助于快速地获取新的信息.快速测试不是强调广泛和完整,它的目的是用最低的成本快速揭示信息. 快速测试是了解产品.识别区域风险及薄弱

易用性测试和探索性测试

近些年来,随着敏捷开发方法和互联网企业的发展,易用性测试和探索性测试被越来越受到关注. 客户也经常提这样的概念或者尝试实践.有些客户可能只做易用性测试,有些客户则关注探索性测试.还很少看到两者都做得.这里简单诠释下两者的相同和不同,如果有不同意的地方,敬请指正. 相同点 1. 易用性测试和探索性测试都是面向业务的测试.所谓面向业务的测试是区别于面向技术的测试,它更多关注用户感受,逻辑是否合理,流程是否正确,功能是否有遗漏等. 2. 两者属于手工测试范畴.虽然有时候用户也可以用工具辅助做探索性,但

初探团队基于session的探索性测试

如果你是一名测试人员,那么不管你对探索性测试的了解是多是少,我肯定你一定用过探索性测试的方法.想想看,你是否曾经这样测试过?不仅仅按照测试案例或者脚本上写什么,就完全使用那一套相同的数据.一模一样的流程,而是根据你执行时的所见,临时有所想和所动,进行一定程度的自由发挥?我想你肯定有过,这就是探索性测试,它将你的测试与纯基于脚本的测试(script. based testing)区分开来.而这种自由发挥,因为是有大致方向和范围的,所以也与完全盲目乱点的猴子测试(monkey testing)不同.

《移动App测试的22条军规》——第23章,第19节对微信App进行自动化测试和探索性测试

23.19 对微信App进行自动化测试和探索性测试 我们在对微信App进行测试时,必然会进行自动化和探索性测试. (1)在编写微信App的自动化测试时,我们还是选用Appium来帮助我们录制对应的脚本:而基于测试金字塔的测试架构设计,我们对于Appium的自动化测试,选择编写"用户登录微信后,在通讯录中添加招商银行公众号"这个用户旅程(如图23.45-图23.55所示). 打开微信App的主界面(如图23.45所示). 打开"Contacts"(通讯录)页面(如图2

自动化测试(AT)与探索性测试(ET)

软件自动化测试 自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程.通常,在设计了测试用例并通过评审之后,由测试人员根据测试用例中描述的规程一步步执行测试,得到实际结果与期望结果的比较.在此过程中,为了节省人力.时间或硬件资源,提高测试效率,便引入了自动化测试的概念. 前提条件 实施自动化测试之前需要对软件开发过程进行分析,以观察其是否适合使用自动化测试.通常需要同时满足以下条件: 1)软件需求变动不频繁 测试脚本的稳定性决定了自动化测试的维护成本.如果软件需求变动过于频繁,测试人员需要

探索性测试揭秘

最近看了不少有关探索性测试的讨论和观点,老实说越看越糊涂.所以忍不住吐槽一下,在这里和大家讨论一下探索性测试.希望对于想学习和尝试探索性测试的朋友有所帮助澄清,或者是更加糊涂,^_^. 探索性测试有很多很多的定义: 百度百科的定义:"同时设计测试和执行测试". 嗯..什么意思? Cem 老人家的正式定义:"a style of software testing that emphasizes the personal freedom and responsibility of

探索性测试的18个总结

1)探索性测试与脚本化测试的主要区别:1)探索性测试将更多更高的认知水平的工作放在测试执行,而脚本化测试则更关注测试设计:2)前者更强调测试活动的并行和相互反馈(学习.设计.执行与结果分析等),而后者的测试活动是相对串行的. 2)脚本化测试的主要优点是:1)尽早发现缺陷:2)不同利益相关者参与评审:3)可重用性:4)测试覆盖率评估. 3)脚本化测试强调测试的尽早介入,如尽早设计测试用例.但是测试人员越早设计测试用例,对测试对象的了解越少,对风险的了解也越少.测试人员对测试对象的了解是一个逐步的过

《移动App测试的22条军规》—App测试综合案例分析23.19节对微信App进行自动化测试和探索性测试

23.19 对微信App进行自动化测试和探索性测试我们在对微信App进行测试时,必然会进行自动化和探索性测试. (1)在编写微信App的自动化测试时,我们还是选用Appium来帮助我们录制对应的脚本:而基于测试金字塔的测试架构设计,我们对于Appium的自动化测试,选择编写"用户登录微信后,在通讯录中添加招商银行公众号"这个用户旅程(如图23.45-图23.55所示). 打开微信App的主界面(如图23.45所示).打开"Contacts"(通讯录)页面(如图23.

基于会话的探索性测试管理

探索性测试是一个特殊的测试过程,它的测试活动和测试内容是动态变化的,更多的是通过测试执行的结果来指导后续的测试活动,花在文档上的时间很少,这也就意味着探索性测试的可管理性不强,对于每个测试人员执行的测试活动的进度和效果很难监控.为了更好地开展探索性测试,Jonathan Bach提出了一种"基于会话的测试管理(Session-basedtest management,缩写为SBTM)"方法,这种方法可以对探索性测试进行更好地管理,把探索性测试的优势更好地发挥出来. 基于会话的测试管理是