点击进入!

本文笔者将带领大家一同了解单项产品的测试结构，再用一个框架来介绍一下：如何生成多项产品测试？最后，再通过一个示例进一步学习。

作为产品经理，我们不仅负责开展客户研究和记录用户体验，还负责产品的性能和表现，确保产品正常运行虽然变得日益困难但越来越重要。

因此，有关产品新设计功能表现情况的信息已经成为了产品规范记录中不可或缺的一部分。

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

首先，我们应该了解单项产品的测试结构。然后，我将用一个框架来介绍一下：如何生成多项产品测试？之后，我们会一起通过示例进行学习。

那么就让我们开始吧！

案例测试结构

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

案例测试可以模拟用户和产品之间所有的交互方式。它应该包括这一流程的开端，到达终端所走的路径，以及在这一流程中可能出现的预期结果。

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

这样很容易就可以看出：在购物车添加商品时是存在问题的，而在购物车检查用户登录情况上是没有问题的。

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

既然我们已经知道了单项案例测试是什么样的，那么，接下来就让我们思考一下：一种产品新的设计功能都需要哪些相关测试呢？

案例测试的框架

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

如果我们只有少量的案例测试，我们也许无法预料到极端案例中可能出现的结果。但如果我们进行太多的案例测试，我们可能在将大量的时间用来研究一些永远不可能出现的情况，这便是对稀缺资源的一种低效使用。

那么，我们怎么才能知道哪些案例测试是我们真正需要的呢？

我们可以从考虑现有的产品表现开始，考虑一下：我们的产品目前可以做什么？

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

之后，我们应该考虑将来引入新功能后产品的表现；考虑一下你吸引了哪些新的客户流，哪些已有的客户流是经过调整的并且它们是如何相互影响的；还要考虑一下哪些现有的客户流会因为产品的改变而流失。

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

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

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

例如：当你构建新的反馈流程时，你可能并不需要测试付款功能，因为二者是相互独立的。

但是，如果你的反馈选项只有在完成付款之后才会出现的话，你就需要将二者组合共同进行测试了。

示例

我已经模拟创建了一些示例，希望这样可以帮助我们更好地理解案例测试。

我将会过一遍这种假设产品现有设计的表现，并且假设出该产品新的设计功能，之后再细致详尽地一一进行解释。

现有功能的表现

假设我正在研究现有的反馈功能。

目前，这一设计只有两种界面，第一个如下图所示：

人产渠道用来发图的

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

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

但是，如果用户选择“是”，就会跳出来接下来这个界面：

人产渠道用来发图的

就是这样，一种非常简单的设计。

新设计功能的提议

假设根据客户研究，我们得到了如下的反馈。

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

当客户表示并不喜欢这一款产品，或者表示并不会向朋友推荐这款产品时，他们会因为没有办法提供直接的产品反馈而感到无奈。

根据这样一种需求，我的团队就构建出了这样一种新的设计功能。

如果用户表示他们愿意向朋友们推荐这款产品，我们就会弹出如下所示的第三种界面：

人产渠道用来发图的

如果用户表示不喜欢该产品，或者表示他们不会向其他人推荐产品的话，我们则会提供第四种界面，如下所示：

人产渠道用来发图的

要测试这项新的设计功能有多困难呢？

你一定会对答案特别惊讶，因为我们刚才并没有暴露问题的复杂性。

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

案例测试

让我们回过头来考虑最初的设计功能。首先，我需要测试以下这些流程：

当我加入了“分享到社交网站”这项功能之后，我的案例测试可能看起来就成了如下的样子：

这么一来不仅生成了两条新路径，还修改了一条已有的路径。

当我再加入“反馈”功能的时候，我的案例测试就成了如下的样子：

这么一来我又引入了两条新的路径，并且修改了两条已有的路径。

但到目前为止，我们都还没有提到过对“反馈功能”本身进行测试。

例如：如果有人在反馈框中输入了非英文字符该怎么办？如果有人试图提交空白的反馈该怎么办？甚至说如果有人试图在反馈框中输入恶意代码怎么办？

此外，当我们进行测试时，我们不仅要测试设计功能，还要考虑接收到的数据是否储存得当。

我们是否正确接收了用户的反馈？我们是否正确地跟进了用户分享的内容，又是通过哪些渠道呢？如果用户跳过了当前界面，我们是否要深入了解他们究竟跳过的是哪一界面呢？

在此，我还有最后一个想法。每当新界面引入后，我经常看到人们会忽略测试“跳过”这一设计功能。虽然“跳过”功能并不是必须的，但是新流程可能会影响“跳过”这一设计功能的实际作用。

总结

优秀的产品经理不仅要了解用户使用产品时遇到的问题，还要了解因设计功能更改而日益增加的产品系统的复杂性。优秀的产品经理可以从了解产品影响中不断优化产品。

当构建新的产品设计功能时，团队需要将因其而产生的新路径记录和储存下来。然后，确保每条路径都是经过测试的，手动测试还是自动化检测均可。此外，切记要测试之前的设计路径，因为我们经常看到新的设计功能无法返回上一步。

时刻注意设计功能的复杂性，并且编写和记录案例测试可以保证用户对我们的产品有很好的体验！