测试人员在需求阶段应做哪些工作
相信很多人跟我一样有过这样的困惑，那就是在需求阶段我们测试人员应该做些什么？下面就将看过的一篇文章贴出来与大家一块分享。首先，测试用例和测试工作本身是不断完善的，在开发过程的初期，可以认为是需求阶段，或者没有规范需求工作的设计阶段。如果有一个比较明确的需求文档，可以在这个阶段检查完了需求文档以后开始设计测试用例。这里，对于需求文档的检查主要是两个方面：
1.检查需求文档描述的正确性，愚以为测试人员要对于真实的系统所涉及的业务非常熟悉，比如一个简单的财务软件，那么测试人员本身就要对会计工作熟悉，财务制度熟悉，在检查需求
文档的时候不要迷信所谓的“都是用户真实的需求”，这里存在两个问题，一是用户是否真的能正确地描述自己的需求，二是需求人员是否真的能正确地理解需求。另外，还有一个用户的嘘气是否符合行业规范的问题，如果不符
合，那么是否要确认——这里存在一个隐患，用户可能会在开发的后期突然要求他们自己要走行业规范，让你的需求变动，所以要事先明确好。
2.检查需求文档描述的准确性。主要是考虑文档中是否存在描述的模糊的地方，对于自己不清楚的问题一定要明确。这个时候是要保证需求的可测试性——我得意思是说保证需求是可以完全为测试工作服务的。
那么在检查完了需求之后，就可以开始设计测试用例了，愚以为，在这个阶段因为没有开始设计工作，所以对于测试用例的考虑不能仅仅从界面出发——虽然RUP中对于用例的要求有这一项。因而测试用例的设计应该从业务角
度出发，从实际业务出发来设计测试用例。当然，在测试用例的描述时，要尽量考虑怎样同应用程序脱离开而仍然具有有效性。
当然，这个阶段所实现的测试用例是不过完善的，只能涵盖某些内容，但是我认为这些用例不仅仅全部都是功能测试用例，而且在整个项目中都将有效。
不过，当缺少需求文档时，那就要发挥测试人员自己的能动性了，要主动的工作，而不是被动的等待。要自己尝试着去熟悉实际业务，要尽量通过自己所能想到的方法来开展工作。 谢谢分享！ 需求阶段，感觉很多需求还是未确定状态。此时研发人员对需求的要求更实际些
最终成型的需求文档，在大部分还是以研发可以满足为基准
测试人员的需求依据，还是需求文档，在此之前，难道只能做些测试方案？
如何更好的参与需求阶段，还是需要很多人去研究完善 不错！ 不过，当缺少需求文档时，那就要发挥测试人员自己的能动性了，要主动的工作，而不是被动的等待。要自己尝试着去熟悉实际业务，要尽量通过自己所能想到的方法来开展工作。
嗯，一定要主动。 提倡测试工作早介入，我个人觉得从开始调研客户需求测试人员就介入是一种最理想状态，一起和需求调研人员完成需求工作，这个过程测试人人员可以从测试的角度考虑用户所提需求是否可行，开发人员可以从开发的i角度考虑 谢谢分享 不错..谢谢分享... 谢谢，记得刚开始工作时，我们领导就问过我这样的问题，那时就没有一点儿的概念，现在真的感觉知识、经验都是一点儿一点儿累计的，当然还需要不断的了解新的信息。 我们这测试人员同时也负责需求分析，这头一次做，还真得注意这些细节。 学习了 需求文档还应该尽量的可以的详细，规范，尽量的覆盖更多的条件和枝节。
一份好的需求文档，应该从业务，技术上层层覆盖。让软件测试人员拿到手就能够写出良好的测试用例。 sdlkfj2 sdlkfj2
同感
现在我们公司就让我从一开始参与新的项目，去客户现场调研，收集需求分析报告。可是到现在不知道进一步开展工作，测试用例也不知道怎么写？？？？要努力加油啊 注意需求接受的标准，这里到时产生你的测试用例和接受标准 是啊，谢谢分享 不错 谢谢分享thks fenxiang
