作为一个软件测试人员，需求评审应该做些什么？

Question

如题所述

Answer 1

需求评审对于软件测试人员来说就像是最初的“产品测试”，在理解的基础上发现产品设计上缺陷，其中包括逻辑错误，功能缺失，细节问题等等，这样就会有效的在前期规避很多后期开发中产生的bug，减少了很多后期返工的成本。可偏偏需求评审往往是最不重视的一环，甚至可以说是没有这个环节，追其原因无非因为项目时间紧迫或者觉得没有必要，其实这是本末倒置和得不偿失的。
产品需求作为程序的源头，只有控制好最开始部分，才不会到最后去亡羊补牢。我有过很多血的教训，所以才深深的体会到需求评审的重要性。
说了需求评审的重要性，接着就来谈谈如何进行需求评审，一般还是分为3步：
第一步就是要完全读懂产品需求，这个过程只需要理解而不是去挑刺，因为要明白这个需求的目的是什么，为什么这样做，怎么做等等，只有在理解的基础上才能去发现问题，而不是一知半解的去挑毛病，有些需求设计的是不合理，但也许有其特殊的用意，或者只是没有更好的方案，不能为了挑毛病而去挑。
第二步就是分析和找问题；这就有点类似写测试用例的时候设计测试方案了，把逻辑梳理出来，看看有没有不对或者遗漏的点，整理出来反馈给产品经理。除了考虑有问题的地方，没问题的地方也是需要分析的，比如有些设计非常合理，但会增加代码的复杂度或者不利于后续的扩展和修改，同时也可能会给测试带来成倍的工作量，这些也是需要指出的，因为测试要考虑的东西一定要比产品经理多，用户使用习惯，程序复杂度，与线上系统的兼容性等等，不然直接让产品经理做测试不就好了吗？
第三步就是细节问题的纠正，可以是界面，可以是文字，开发一般都是复制黏贴或者照着样子画葫芦，这些小问题后期其实也可以测试出来的，但其锅不在于开发，早点发现问题早点解决也是好事一件，至少不用提bug走一套bug处理流程了，也算给大家省点工作量，积少成多也是极好的。
当然需求评审能解决的问题也是有限的，一方面计划往往赶不上变化，中间会有部分需求的改动，另外一方面有些深层次的问题只有在测试之后才会发现。但无论如何对于测试来说还是非常有必要的，如果能重视起来不仅仅对项目的效率提高不少，而且也能让后期测试压力减小，何乐而不为呢？

Answer 2

你好，
【1】规划型产品经理
规划产品从0到1，规划方向、目标人群、特性及产品价值。
【2】管理型产品经理

负责产品过程，以结果为导向。为最后产品实现盈利作保证。参与产品设计等。
【3】设计型产品经理
设计产品原型、协调产品PRD文档，协调产品资源等，保证产品迭代节奏，每个版本产品能够如期上线和如期交付
【4】全能型产品经理
能独立完成产品过程中的每一项工作，就好像纽带一样，链接每一个模块
【5】技术型产品经理
现在很多产品都是技术决定的，比如数据算法等软件、还有大多数的复杂APP，都是技术和研发共同努力的结果
【6】运营型产品经理
民间流传这么一句话，懂得运营的产品经理是非常“值钱”的、好产品是运营出来的。能看出这两句话的意思吧，产品运营是多么重要，而懂得运营的产品经理又是多么神一般的存在。
入门产品经理，可以从工具学起，推荐以下这些：

1.脑图工具：百度脑图

2.文档共享：蓝湖、Axure等软件

3.项目管理：jira

可以在网上找每个工具的教程，一边看一边练习

Answer 3

需求评审的参与人员：领导+产品经理+项目经理+开发人员+测试人员+运维人员等
需求评审是一个对软件需求进行确认和评估的一个活动，测试人员虽然不是主角，但要积极的参与。

评审前： 认真的阅读需求说明，业务流程图等资料；整理出测试点，一定要突出业务逻辑

评审过程中：对于需求是否合理，是否可以实现，咱们看着产品和开发人员
讨论即可。
咱们要关注的：
1. 主要关注需求是否具有可测试性，也就是需求是不是存在自相矛盾和二义性。
2. 还要分析目标用户的操作习惯。
3. 对需求存在疑惑，或者理解不是很透彻，一定要问清楚
4. 估算测试过程需要的时间和资源，这也最难把控的。（往往会变化）

评审后，提交工作计划，突出时间节点和产物。
以上内容均来自黑马程序员社区本回答被提问者采纳