软件测试的需求阶段

软件测试的需求阶段

1，对于很明显很直接的用户需求，可以直接转化为测试需求;

2，对于用户需求不明朗的部分，但是又必须弄明白的部分，进行确认;

3，对于用户需求不明朗，但是又无关紧要的部分，可以酌情适当处理(依质量要求转化为不同程度的测试需求);

4，对于用户明确提出的需求，需求之间存在逻辑或者业务上的冲突时，尽快确认。

当然，实际当中都得视情况而定，有些用户需求确实写得很完善，那可以直接用来转化为测试需求并体现在测试用例中，也有些需求写得很粗糙，但是出于成本等因素考虑，他们的质量要求或许并不高，那也可以放宽限度不去深究不明朗的部分。软件测试并不是保证所有被测软件都完美无暇，而是给用户需要的。

理解需求忌管中窥豹

用户需求的提出往往是为了实现某一完整的业务流程或功能，在分析理解用户需求时也像写作一样，要先有一个框架在心里，要先把握用户的大概意图、明确整个需求文档(或其它形式需求)的整体意思，在此前提下再去深入的细读每个需求点才会更有利于理解用户的真正需求。

这样做还有一点好处就是在后续的测试设计环节中能减少冗余、优化测试过程。比如如果我们事先就通过大概了解整个需求而得知有几个页面的布局和功能点有很多类似的地方，那我们就可以直接同时考虑这几个相似页面的情况设计公用的测试用例，同时在流程测试上也能相应的设计合适的测试流程。

实际场景中就有些测试人员在拿到需求后，二话不说就逐行往下细读并开始设计测试用例，这样往往就造成对需求理解不到位、不全面，特别是在一些英文需求中，如果不了解大环境就开始设计测试用例，可能就会造成对需求的理解有较大偏差。