怎么对产物功用进行案例测试,包管产物功用持重运作?
本文摘要:订阅专栏撤销订阅 「即能Upskill」大众号,深耕职场教育领域238915本文笔者将带领我们一同了解单项产品的测试结构,再用一个框架来介绍一下:怎么生成多项产品测试?终究,再通过一个示例进一步学习。作为产品主管,我们不只负责开展客户研讨和记载用户体验,
订阅专栏撤销订阅 「即能Upskill」大众号,深耕职场教育领域

2389

15

本文笔者将带领我们一同了解单项产品的测试结构,再用一个框架来介绍一下:怎么生成多项产品测试?终究,再通过一个示例进一步学习。

作为产品主管,我们不只负责开展客户研讨和记载用户体验,还负责产品的性能和体现,确保产品正常运转虽然变得日益困难但愈来愈重要。

因此,有关产品新设计功用体现状况的信息现已成了产品规范记载中不可或缺的一部分。

进行案例测试是确保你了解产品预期体现的最佳方法之一。毕竟假如你了解一种产品在多种条件下的体现状况的话,你的产品将会更加稳健。所以,在我们制定产品规范的时分应该怎么考虑案例测试呢?

首要,我们应该了解单项产品的测试结构。然后,我将用一个框架来介绍一下:怎么生成多项产品测试?之后,我们会一同通过示例进行学习。

那么就让我们开始吧!

案例测试结构

案例测试究竟是什么样的呢?为何说它很重要?

案例测试可以模仿用户和产品之间所有的交互方式。它应该包括这一流程的初步,抵达终端所走的途径,以及在这一流程中可能呈现的预期成果。

这样的话,一种在线购物产品的案例测试结构看起来也许会是这样的:

这样很容易就能够看出:在购物车添加商品时是存在问题的,而在购物车查看用户登录状况上是没有问题的。

记载明晰的案例测试,可以确保你的开发团队知道自己在向成功的方向迈进。

既然我们现已知道了单项案例测试是什么样的,那么,接下来就让我们考虑一下:一种产品新的设计功用都需要哪些相关测试呢?

案例测试的框架

单项的案例测试是远远不行的,我们需要考虑用户在使用产品时可能遇到的所有状况并对其进行测试。

假如我们只有少数的案例测试,我们也许无法意料到极端案例中可能呈现的成果。但假如我们进行太多的案例测试,我们可能在将很多的时间用来研讨一些永远不可能呈现的状况,这便是对稀缺资源的一种低效使用。?

那么,我们怎么才干知道哪些案例测试是我们真正需要的呢?

我们可以从考虑现有的产品体现开始,考虑一下:我们的产品现在可以做什么?

我们应该先查询一下产品有无任何案例测试记载在案,假如没有的话,现在便是构建记载和进行案例测试的最佳机遇。

之后,我们应该考虑将来引入新功用后产品的体现;考虑一下你吸引了哪些新的客户流,哪些已有的客户流是通过调整的并且它们是怎么彼此影响的;还要考虑一下哪些现有的客户流会因为产品的改变而流失。

仍是像之前说过的那样,案例测试都应该代表用户和产品之间所有的交互方式。换句话说就是你不该该只进行单向测试,而是对产品和客户之间端到端的流程进行测试。

每当我们构建产品设计功用时,我们需要考虑其依赖性,并且测试已有功用与新功用之间的依赖性关系。

当新建的设计功用独立于其他功用时,我们只需要进行单项测试即可,也就是说不需要将二者一同进行测试。

例如:当你构建新的反馈流程时,你可能其实不需要测试付款功用,因为二者是彼此独立的。

可是,假如你的反馈选项只有在完成付款之后才会呈现的话,你就需要将二者组合一同进行测试了。

我现已模仿创建了一些示例,期望这样可以协助我们更好地舆解案例测试。

我将会过一遍这种假设产品现有设计的体现,并且假设出该产品新的设计功用,之后再详尽翔实地逐个进行解释。

现有功用的体现

假设我正在研讨现有的反馈功用。

现在,这一设计只有两种界面,第一个如下图所示:

用户可以选择“是”和“否”两个选项,当然他们也能够选择跳过这一问题然后回到产品之前的界面上。

假如用户选择“否”,那么他们会被转到产品界面。

可是,假如用户选择“是”,就会跳出来接下来这个界面:

就是这样,一种十分简略的设计。

新设计功用的提议

假设依据客户研讨,我们得到了如下的反馈。

当客户想向朋友引荐这款产品时,他们会因为没有方法迅速分享链接而感到懊丧。

当客户表明其实不喜欢这一款产品,或者表明其实不会向朋友引荐这款产品时,他们会因为没有方法提供直接的产品反馈而感到无法。

依据这样一种需求,我的团队就构建出了这样一种新的设计功用。

假如用户表明他们情愿向朋友们引荐这款产品,我们就会弹出如下所示的第三种界面:

假如用户表明不喜欢该产品,或者表明他们不会向其别人引荐产品的话,我们则会提供第四种界面,如下所示:

要测试这项新的设计功用有多困难呢?

你一定会对答案特别惊奇,因为我们方才并没有暴露问题的杂乱性。

接下来,我们就逐个进行分析。

让我们回过头来考虑最初的设计功用。首要,我需要测试以下这些流程:

当我加入了“分享到社交网站”这项功用之后,我的案例测试可能看起来就成了如下的姿态:

这么一来不只生成了两条新途径,还修正了一条已有的途径。

当我再加入“反馈”功用的时分,我的案例测试就成了如下的姿态:

这么一来我又引入了两条新的途径,并且修正了两条已有的途径。

但到现在为止,我们都还没有提到过对“反馈功用”本身进行测试。

例如:假如有人在反馈框中输入了非英文字符该怎么办?假如有人试图提交空白的反馈该怎么办?乃至说假如有人试图在反馈框中输入歹意代码怎么办?

此外,当我们进行测试时,我们不只要测试设计功用,还要考虑接收到的数据是否贮存妥当。

我们是否正确接收了用户的反馈?我们是否正确地跟进了用户分享的内容,又是通过哪些渠道呢?假如用户跳过了其时界面,我们是否要深化了解他们究竟跳过的是哪一界面呢?

在此,我还有终究一个主见。每当新界面引入后,我常常看到人们会疏忽测试“跳过”这一设计功用。虽然“跳过”功用其实不是有必要的,可是新流程可能会影响“跳过”这一设计功用的实践作用。

优秀的产品主管不只要了解用户使用产品时遇到的问题,还要了解因设计功用更改而日益添加的产品体系的杂乱性。优秀的产品主管可以从了解产品影响中不断优化产品。

当构建新的产品设计功用时,团队需要将因其而发生的新途径记载和贮存下来。然后,确保每条途径都是通过测试的,手动测试仍是主动化检测均可。此外,切记要测试之前的设计途径,因为我们常常看到新的设计功用无法返回上一步。

时刻留意设计功用的杂乱性,并且编写和记载案例测试可以保证用户对我们的产品有很好的体验!

 

原作者:Clement Kao