职业经验 你们公司的产品人员在用例评审的时候质疑过你吗
各位 TH 的朋友们，故事背景是这样的：
测试的 APP 很多功能是两年前开发好的，我们的 APP 开发 产品 测试 都是刚刚入职半年内的；
我负责的模块是 APP 客户端的所有功能迭代部分的测试，但是产品在需求交底的时候，通常使用 “除我说明的点外，其他逻辑部分跟老版本一致” 这种备注。
这就导致测试时候特别尴尬，因为所谓的 “老版本一致”，没人说得清楚所谓的老版本的需求是什么。
所以在用例中，我尽可能把需求没涉及到的点详细地提出来，然而导致产品方认为，过于繁琐，“这是常识” 这种话来反驳。
请问伙伴们，你们的需求交底是怎么进行的，遇到过类似的吃力不讨好的情况吗，是如何解决的呢~
我们也有这样的问题。历史包袱太重。需要有人来理。
目前产品迭代到第三期了，没楼主问题那么久远，但是也有很多问题。
目前我采取的策略就是：从需求评审到测试结束，过程中就是不断不断不断不断给需求提 bug，不懂的全给他们提，提到他们不耐烦把需求补清楚为止
我们也有这样的问题，不过我们公司的人还是不错的，跟产品，跟开发打好关系，不明白的需求，找他们问，实在不清楚的需求，找产品重新定套需求，规则！
wangpengfei100
回复
日常还有一个策略：
交付的需求存在大量不清晰的时候，测试评审的时候就会自己列出一个表格，统计所有不清晰的点。
然后发给需求人员，抄送给全项目组的人。
必要时，要进行会议讨论的。
这种模式下，需求评审占了很多时间
产品写的需求极其简陋，导致每个迭代都要花费大量时间在排坑上，结果到最后还是有坑，感觉都没有空闲时间，研究点其他
我们都是质疑产品，设计不合理，细节不清晰
我们从需求宣讲到测试分析，都是在理需求，嗯
工作有 1/3 的时间在怼产品的飘过。有些产品真心沟通困难。
对于 “老版本一致”，这个东西么，如果产品真的非常忙，这个可能需要自己私下里多做一些功课了。
如果不能界定的常识有很多，叫上总监 VP，哪怕 CTO 来界定下。撕逼又没用
多数产品都浆糊，需求写了和没写一样。达标的产品真心不多。建议直接跳过 “这类” 产品找 “原始” 需求方问清楚到底想要啥。
1、自己用思维导图，整理产品的路线
2、比如一些订单的初始状态！什么情况下才是初始状态，状态的变化，是否对应的数据变化，页面上的展现，每种流程都跟产品对清楚，整理好思路。
3、订单审核 - 交易 - 结算 - 结束，这是状态流的，每一种状态，页面展示，列表展示，详情页面展示，文字 - 图标状态的变化，都跟产品一一对应清楚
4、既然状态对应清楚了，那么对应的数据流也需要跟研发对清楚，初始状态会有哪些数据，每一种状态的变化，对应的数据有哪些变化，会影响到那部分的功能，查询的数据显示的结果与状态是否一致
5、这些情况下，都是测试需要分析的，不然到后期测试不到位，就有锅要背了
6、对于产品的一些特殊的要求，可以划分其他的测试方法，比如登录时，产品说需要上传设备号，测试时需要观察日志，数据存储，上传的数据是否正确
对于需求不清晰的点还是得找各方面的人将其确定下来，要不然出问题了得背锅