如题。第一次参加，不知道怎么准备，也不知道要做什么，

站再测试的角度，主要还是可测不可测的评审

1、先挑错。看看他们要评审的文档，说法是不是前后一致。
2、如肚皮所说。

就是从测试角度将需求分解为可测的功能点，考虑如何测试这些功能点。
对不可测功能点的解决办法了，可以和项目经理/系统架构师讨论决定。

对不可测的功能点，要加以分析：
1）可以继续拆分成多个可测的用例，说明原来的粒度太大
2）不可测是因为根本不是需求
3）不可测是因为暂时没有测试方法（需求本身没有问题）

一是检查软件需求的正确性、完整性、一致性
二是保证软件需求的可测性

给你具体一点的吧，他们太笼统了。。
需求上往往规定的是1+1，但没说1+1=几
我们比较关注的就是这个结果了
因为功能测试是看结果的~~~~~~~~~
当然我说的只是一方面
还有一些简单的，比如他们说能进行“部分查询”

这就存在不可测试性了，因为不知道具体怎么查，不知道要查什么~~

我说话比较朴素，你应该听的懂，哈

站在测试人员的角色参加需求评审工作，本人认为有以下几个要点：
1、        检测需求是否表达了它本身的意义同，对需求本身进行一次详细的测试；
2、        需求的描述是否准确；
3、        需求的描述是否完整；
4、        站在用户的角色，要对用户的要求进行详尽的分析后对需求进行的评审；5、        以测试员的角色，审查需求的可测性和易测性，即需求是否定义了清晰的测试标准和测试规范；
还有点非常重要的是要进行需求评审前，测试人员应该尽可以详细的先了解项目的需求，并且收集尽可能多的与项目相关的专业知识。

需求测试就是提出文档的中疑问及缺陷吧？

需求评审的时候，基本上是你发问的过程，前提条件是：项目经理已经把提前两天初稿给参与评审的人了。只有这样评审才能真正的达到效果，要不也是走过场。

1、读需求，看你读的懂吗？和你测试小组的人沟通，看有没有不同理解？如果你读不懂或有不同理解，那好，这就是需求明确性和无二义性的问题，请你提出；
2、从测试的角度看你看的每一条需求都可以写出对应的测试用例吗？如果不能对应需求写出测试用例，那好，这是需求可测性的问题，请你提出；
3、总之，你看到需求是你要参照展开测试工作的，所以，从你测试工作的本身考虑就可以了，置于其他方面，你如果没有精力和时间，会有其他角色的人考虑的

还是觉得各位兄弟讲的太概，不具体，有没有实例的文档看看阿！

关注文档化后良好需求的十个特性：
完整性、正确性、一致性、可行性、无二义性、健壮性、必要性、可测试性、可修改性、可跟踪性。

另外，评审前最后将基于产品的项目的业务需求、用户需求和功能需求好好组织、理解、梳理一遍，这样对于整个产品就有了更为全面的了解。

学习

很有帮助。谢谢各位精彩回答 sdlkfj2

先明确那些是可以测试的
对于可以测试的部分,在写测试用例时需要哪些条件?尤其是对那些模棱两可的内容

觉得yiyihui说的那几点都非常正确!

没错，就是L4的答案
主要更加需求分析来测试的！