棒棒哒！

666

在此建议
一、测试人员应对的措施如下：
1、加强自身的需求分析能力：业务体系的熟悉程度、背后技术体系的测试风险，需要不断熟悉梳理业务，学习提升新的测试技术
2、加强需求评审时测试人员的积极性，如何进行良好的需求分析，需求评审中前置测试分析工作，需要规范需求评审过程。--》输出《需求评审会议测试问题清单》
3、严格按测试规范标准去执行测试过程阶段工作：
测试分析 --》需求、系统分析是前提
测试设计 --》用例设计是核心
测试执行 --》自动化测试能力增强
测试度量 --》绩效管理是重心
测试过程 --》过程优化，复盘是催化剂
从测试发现 BUG--》测试验证--》测试预防，前置测试工作，提升自身的测试效能减少研发内耗，以降低 BUG 率。

二、需求评审注意事项
评审前期：--提前熟悉需求
1.在评审需求会议之前，产品应提前一天发出要评审的文档，测试在评审会议开始之前必须要先熟悉需求文档，了解每个功能点是干什么的。
需求评审会中工作：--评估测试风险
2.在需求评审中进行测试方案的选择，--》测试工作量的分析评估
（1）根据需求内容明确测试范围；确定本次需求需要保证的内容，可能影响的原有业务，是否需要其他业务的支持等等。
（2）根据需求类型选择测试方案，比如：需求确认 ---- 功能测试，并发需求 ---- 性能测试，影响范围 ----- 回归测试等。
评审会后 --需求封版及变更控制
3.要对评审过程需要修改的内容进行跟踪、是否结束需求澄清封版工作 --》确定测试范围
在需求评审会议即将结束的时候，需要确认在评过程中存在不一致的地方，是否达成了一致？异议达成一致的方案是否已经确认？
一定要对评审后进行跟踪，避免有头无尾，导致前期工作付诸东流。

参考：总结：如何做好测试需求分析
https://blog.csdn.net/ggf123456789/article/details/39180239
测试人员如何进行需求评审
https://blog.csdn.net/lionking0318/article/details/83988773

前面帖子正文里的复盘，是不是可以进行更深入的根因分析？

需求问题应该已经是问了几个 why 后得到的了，但我理解还可以再继续深入下？需求质量不高，就直接加强需求评审，有点担心会治标不治本。

不如整个需求模板给产品

再怎么分析，也扛不住老板拍脑袋

我已经成功打入产品团队，成为了他们的顾问。

让产品团队过来挖点靠谱的测试过去当产品，产品领导乐意，你的这个问题也能得到中期解决

可以尝试要求产品：不同类型的需求 ，使用不同形式进行描述，具体可以参考一下《阿里巴巴 Java 开发手册嵩山版 2020》，感觉操作性比较强，可以落地。

另外，开发提测用户故事前，进行产品、开发、测试的三方 ShowCase，是一个不错的测试前移实践，效果很明显，目前已经有十几个产品都落地反馈效果明显。

说的很对，有些产品团队就是类似拍脑袋，业务体系没有建立、走一步看一步，提测后需求一直还在补充，要怎么影响他们建立合理的产研体系呢？个人魅力，还是组织架构的优化。。

测试部门归产品管理，技术团队是独立的，好的敏捷工作流也没有推行，一直处于领导引领需求变化，各个人都扎心的工作者，如何采取好的手段策略去影响进行需求精细化管理，如何做到业务有拆分、逻辑有梳理、未来有规划？

用例评审确实能消除三方的需求对齐、澄清逻辑等问题，但是需求变更控制，还是需要流程工具去拦截要求，在权利面前，一线人员是没有驳回余地的。。

我觉得要提前拿到需求，然后对需求发散提问（拉个单子，找产品对需求一一确认，经过两轮，需求质量就高得多），都解决了，再来设计用例和评审，要不原始的需求就不清不楚，后面评审出发现不了太多的隐含的逻辑问题，

我分析需求时，我都是假设这个是私单，我来实现，要是我评估不对，工作量就偏差太多，我报价就不准，我接了就赔钱，带着这 态度去做，没有做不好的，

很好，带着主人翁的心态去面对评审，评审会议效果都不会差，还是得提高需求评审会的结束的要求标准、而不是走马观花、一扫而归，需求评审会就得严卡，解决需求不对齐、澄清的问题，治理需求混乱的本质问题

这个和私单还不大一样。我以前遇到过好几次需求评审完，都确认下来后，产品周会开完，这个需求需要承载更多的业务目标，那需求又产生调整的（嗯嗯，拥抱变化）。所以光靠需求评审卡严，其实很难，总会有我们想象不到的地方产生变化。

既然本质问题是业务节奏快，产品没法把需求想得面面俱到再开干，那我们的解决方案，就是围绕着更深度了解需求，便于按照一致的出发点补足细节来。比如：
1、建立需求初审制度，技术也一起参与了解需求的出发点。需求文档初稿出来后各个技术、测试组长先审，快速明确需求价值、技术可行性。
2、正式需求评审通过后，每天早会产品必须一起参加并同步是否有调整，同步后现场评估技术成本。调整成本超过 1 天影响排期的，一律走需求变更流程，变更排期。
3、需求描述不明或者前后矛盾导致的 bug，测试也会记录并把类型设置为 需求问题 ，让产品澄清。测试报告里会体现这类型问题的数量及严重程度，并在复盘时一起沟通，看大家有什么好招减少或者避免这类问题产生。

不同的组织结构、不同的问题根因，会产生不同的解决方案。所以我前面说复盘只是找到了需求质量差，但没找准根本原因（一般根本原因都和人员能力或者组织结构有关），需求混乱直接就加强需求评审，卡得更严，真的不一定能解决问题，甚至可能激发矛盾。

我是说做私单的这种心态，需求没评估好，就要赔钱 ；都报着，需求不是我的事，出错了也不是我的事，这肯定做不好！ 不是卡严是挖掘出真正的需求，不是说需求不能变，变再走变更，但第一版需求，要讲清里面的业务，以及隐含量的业务逻辑是什么样的，不能等实现时，开发人员，有不同理解。定好了，开始 DIE 代，有变更走变更。

嗯嗯，这个认同。

非常感谢，很全面很周到，技术、流程、人员、组织的问题都需要考虑，需要加深复盘，找到本质问题再想策略去应对问题。

额，收到这个点评感觉有点怪怪的。

想先问下，这个是你团队实际存在的问题，想了解下大家有什么解决方案可以参考呢，还是什么？大家是冲着协助解决问题来的，这样的点评回复，搞不清楚到底对你有没有用。大部分都是类似 “你说的对” ，没有真正有意义的反馈交流，感觉好奇怪。

就是求助遇到这种问题，大家有没有更好的解决方案，而不是走错路，越走越远。

可以把你公司或团队里面，这种问题的具体情况分享下不，以及你们尝试过的方案？你的描述里从来没提到 “我们” 或者 “我”，全是第三人称甚至没有人称 ，总感觉你不是在说自己的问题，而是说别人的问题，或者 yy 出来的问题。

然后你的回复相比感谢和理解并变成后续行动这种认可（比如：感谢分享，确实我们复盘没有找到你提到的根因，后续我们再内部讨论一下，继续深挖为何需求这么混乱），更像是内容点评。我们回复的目的是想帮助你解决你的问题，而不是给你做这些点评的，这些点评我主观感受上，会感觉很怪。