软件测试管理中需求阶段测试工作的开展
首先，测试用例和测试工作本身是不断完善的，在开发过程的初期，可以认为是需求阶段，或者没有规范需求工作的设计阶段。如果有一个比较明确的需求文档，可以在这个阶段检查完了需求文档以后开始设计测试用例。这里，对于需求文档的检查主要是两个方面：
1.检查需求文档描述的正确性，愚以为测试人员要对于真实的系统所涉及的业务非常熟悉，比如一个简单的财务软件，那么测试人员本身就要对会计工作熟悉，财务制度熟悉，在检查需求文档的时候不要迷信所谓的“都是用户真实的需求”，这里存在两个问题，一是用户是否真的能正确地描述自己的需求，二是需求人员是否真的能正确地理解需求。另外，还有一个用户的嘘气是否符合行业规范的问题，如果不符合，那么是否要确认——这里存在一个隐患，用户可能会在开发的后期突然要求他们自己要走行业规范，让你的需求变动，所以要事先明确好。
2.检查需求文档描述的准确性。主要是考虑文档中是否存在描述的模糊的地方，对于自己不清楚的问题一定要明确。这个时候是要保证需求的可测试性——我得意思是说保证需求是可以完全为测试工作服务的。
那么在检查完了需求之后，就可以开始设计测试用例了，愚以为，在这个阶段因为没有开始设计工作，所以对于测试用例的考虑不能仅仅从界面出发—— 虽然RUP中对于用例的要求有这一项。因而测试用例的设计应该从业务角度出发，从实际业务出发来设计测试用例。当然，在测试用例的描述时，要尽量考虑怎样同应用程序脱离开而仍然具有有效性。
当然，这个阶段所实现的测试用例是不过完善的，只能涵盖某些内容，但是我认为这些用例不仅仅全部都是功能测试用例，而且在整个项目中都将有效。
不过，当缺少需求文档时，那就要发挥测试人员自己的能动性了，要主动的工作，而不是被动的等待。要自己尝试着去熟悉实际业务，要尽量通过自己所能想到的方法来开展工作。相信学过马克思哲学的朋友都知道什么是客观性和主观能动性吧。
当然，在设计阶段和最后的编码阶段，都还可以继续添加、修改或者剔除掉部分测试用例，使之更加完善。
文章来源于领测软件测试网 https://www.ltesting.net/
