20150914——产品经理与测试

入职5个月，感觉平时工作的很大一部分时间都在和测试工程师进行沟通。每个需求测试前，测试的大哥都会问我这个需求要怎么测；测试过程中，需要和测试确认bug，和开发、测试一起商量一些bug的解决方案，遇到不积极的测试人员还要定时催促；功能上线后，还要和测试商议，如何监测线上的表现，有哪些需要关注的地方。

       所以当今天测试工程师再次问我如何进行测试时，我就觉得不能再这样被动了，必须尝试着降低测试工作的沟通成本。众所周知，PM可以通过写PRD降低与开发工程师的沟通成本，让开发在写代码时有依据可循。那么同样地，我可以写一个测试说明文档。

       或许有的人觉得这个是测试工程师的工作，PM不应该越俎代庖。4个月前我还是这么认为的，但是测试工程师总是有这样那样的理由，说自己不熟悉业务也好，说自己不知道数据存在哪些表里也好，反正最后我都只能自己先琢磨一遍测试方法，然后转述给他。也许有人会质疑我驱动他人的能力，我不置可否，但确实觉得我无法控制一个人对业务的熟悉程度，更无法把控那些比我年长许多的人的工作习惯。

       总结了下测试常问的问题，包括功能使用的具体流程是怎样，需要设计哪些方面的case，是否需要和其他系统联调，数据存取涉及哪些表和字段，以及有哪些注意点等等。当测试人员对业务不是特别清楚，或者逻辑思维不强时，如果PM能帮忙理清这些，定能让测试工作事半功倍。以“计算定制尺寸地毯的重量”这个功能为例，我认为一个简单的测试说明文档需要包括以下内容：

（1）功能描述

       在电商网站上，存在很多支持用户定制尺寸的商品，地毯就是一个典型的例子。重量是运费计算的重要参数之一，由于用户可以输入的尺寸很多，系统不能通过枚举法将所有尺寸的地毯重量记录在数据库中。

       “计算定制尺寸地毯的重量”是指，用户选择了地毯的长度和宽度时，系统能够自动计算这个尺寸地毯的重量，从而精确计算商品的运费。

（2）功能使用流程

       这个需求是偏重业务逻辑的设计，对UI并没有改变，所以对用户来说并没有什么需要学习的，只需按照以往的购物流程下单：

       单品页选择地毯尺寸 》加入购物车 》进入提交订单页面 》……

       走到提交订单页面，新功能体现在显示的运费中。

（3）功能涉及的系统

       该功能只是改变地毯的重量计算逻辑，涉及前端和后端所有的运费计算系统。比如负责网页展示的系统，负责促销时运费预估的商户工具等等。需要通知相关系统的负责人，召集相关的测试人员进行测试和联调，保持各个系统的数据一致性。

（4）测试执行步骤

对于这个功能，我建议测试可以分为三个阶段：

1. 将代码部署在测试环境后，选取同一个商品的同一尺寸，比较测试环境和线上的运费变化；
2. 检查代码是否正确计算地毯重量，比如
   • 重量计算公式为：重量 = 长度 * 宽度 *用料倍数*每平米地毯重量
   • 其中，长度和宽度为用户输入属性，可以参照下单时选取的数值；用料倍数和每平米地毯重量在数据库维护
   • 在计算运费的表里取出该商品的重量，与公式计算得到的重量对比，看是否一致
3. 检查公式是否合理

• • 取一些已知尺寸和重量的商品（比如非用户定制尺寸的地毯），代入公式计算得到一个重量，与商品的实际重量进行对比，看是否有较大偏差；
  • 如果偏差较大，需要对公式或者数据进行调整，必要的时候要跟相关业务人员沟通。

对于步骤（4），按顺序写出测试执行步骤，并准确给出存储相关变量的 数据库/表/字段，可以大大提高测试人员的工作效率，降低沟通成本。建议PM学点SQL，不是说一定要给测试提供SQL语句，而是觉得PM需要亲自对功能进行简单的验证。

以上是我对测试说明文档的一点总结。在测试过程中，还会需要很多其他的困难。比如，测试工程师的工作积极性很低，这个时候就需要定时催促，催促时一定要注意沟通技巧，不能让对方觉得你是在责怪他不敬业。比如RTX问一句，“XX哥，今天有发现新的bug吗？”“现在测试用例覆盖了多少啦，后天上线有没有问题呀？”等等。如果发现的bug很多，那么要及时查找原因，是测试方法不对，还是开发没有很好地理解需求（甚至没有自测），及时陪工程师做出调整，避免浪费时间和资源，无法按时上线。如果发现功能设计有缺陷，那么一定不要试图掩盖，诚实地告诉大家自己当初考虑不周，一起商量改进的方案。

资历太浅，甚至很多时候不能清晰地界定PM和测试的工作分工，欢迎拍砖。