测试术语

管理的灰度

A/B测试终极指南

Multivariate Testing

灰度测试

知识的诅咒

“知识的诅咒”的说法来自《粘住》中实验，具体可以自己搜索一下。我们自己对于自己开发的产品极为熟悉，于是乎想当然认为用户也应当能够理解产品的设计思路、产品的功能使用。

1）问题特征：

a结果没有量化手段；

b只依赖于用户问卷调查；

c没有web analytics系统；

d运营数据不全面，只有核心业务指标（例如交易量），没有用户体验指标

e对结果分析，只选择对发布有利的信息，对其他视而不见

2）解决方案：

a产品设计考虑产品量化指标

b结果分析依据量化指标而不是感觉

发布没有回头路可走

1）问题特征：

a新旧系统用户使用习惯差异太大，没有兼容原有功能

b新旧系统由于功能差异太大，无法并行运行，只能强制升级

c新系统只是实现了旧系统部分功能，用户要完整使用所有功能，要在 在新旧系统切换

d新旧系统数据库数据结构差异太大，无法并行运行

2）解决方案：

前期产品策划重点考虑这些问题，包括：

回滚方案、 新旧系统兼容方案、用户体验的一致性、用户使用习惯的延续性、新旧系统数据模型兼容性

用户参与度不够

1）问题特征：

a指望用户自己去挖掘所有功能。对于一个产品，大部分用户经常只使用部分功能，用户大部分也很懒惰，不会主动去挖掘产品功能

b互动渠道单一

c陷入“知识的诅咒”，不尊重参与用户意见

2）解决方案：

a善待吃螃蟹的样本用户，包括给予参与测试的用户小奖励（例如MS给参与Win7测试用户正版License）、给用户冠以title

b通过邮件、论坛、社区、Blog、Twitter等新媒体与用户形成互动

c提供产品功能向导。在hotmail最近的升级后的功能tip，gmail的tip都有类似的产品功能导向。在产品中会提示类似于：你知道吗，xx还提供xx功能，通过它你可以xx 。