一、显式需求与隐式需求
可以说，用户需求是软件测试的第一纲领，测试活动都应该围绕软件需求展开。我们可以将用户需求分为显式需求和隐式需求。显式需求就是白纸黑字写在需求文档上的，这往往是用户要求直接实现的功能特性；隐式需求是需求文档没有直接提及但是在软件开发、测试等角度需要考虑的。显式需求是硬性要求，是无论如何都要实现的部分，而隐式需求则要视实际情况而定，比如界面友好性、字段检查等，在需求中不一定提及，但是如果客户对质量要求很高的话那在测试的时候需要考虑更多的隐式需求，反之则在保证显式需求的前提下适度的考虑隐式部分。
如下面这个简单的需求片断：
“点击[申请]按钮，在弹出的对话框中用户能够输入电子邮件和用户名并提交申请
(无配图)”
字段 数据类型 数据长度
姓名 字符 30
电子邮件 字符 50
由此我们可以分析出显式需求如下：
1，添加一个按钮，Label 为“申请”
2，点击[申请]按钮打开一个对话框(对话框大小、位置、标题、是否模态化等因素并未说明)。
3，对话框中有两个字段“电子邮件”和“姓名”(摆放位置、字体大小、颜色等未说明)。
4，两个字段的类型都是字符型，且指明了长度（电子邮件格式、姓名可否包含空格、是否要验证必填、输入超长时如何提示等未说明）。
5，对话框中至少有一个按钮“提交”(关闭对话框的方式未提及)。 与之对应的隐式需求包括但不限于如下：
1，对话框的大小、位置要合理（与系统其它部分风格统一），标题参照其它部分或者合理处理。
2，“电子邮件”和“姓名”字段在对话框中位置合理，字体大小颜色等与整个系统风格统一。
3，电子邮件要验证格式，数据超长时冻结文本框（依据系统类似的处理），未输入时提交弹出提示等。
4，需要有合理的关闭对话框方式(如添加“取消”按钮、给对话框右上角添加关闭 功能)。
上面只是一个很简单的例子, 所要表达的意思是，需求往往是并不十分明确的，因为有些时候就连用户自己都不知道他想要怎样，但是站在软件测试者的角度来看，我们并不一定要将所有明确或不明确的需求都实现，但是我们需要清楚眼下的情况，甚至帮助用户完善需求。
在实际软件测试周期中，在需求阶段通常的做法有：
1，对于很明显很直接的用户需求，可以直接转化为测试需求；
2，对于用户需求不明朗的部分，但是又必须弄明白的部分，进行确认；
3，对于用户需求不明朗，但是又无关紧要的部分，可以酌情适当处理（依质量要求转化为不同程度的测试需求）；
4，对于用户明确提出的需求，需求之间存在逻辑或者业务上的冲突时，尽快确认。
当然，实际当中都得视情况而定，有些用户需求确实写得很完善，那可以直接用来
转化为测试需求并体现在测试用例中，也有些需求写得很粗糙，但是出于成本等因素考
虑，他们的质量要求或许并不高，那也可以放宽限度不去深究不明朗的部分。软件测试并不是保证所有被测软件都完美无暇，而是给用户需要的。
二、理解需求忌管中窥豹
用户需求的提出往往是为了实现某一完整的业务流程或功能，在分析理解用户需求时也像写作一样，要先有一个框架在心里，要先把握用户的大概意图、明确整个需求文档(或其它形式需求)的整体意思，在此前提下再去深入的细读每个需求点才会更有利于理解用户的真正需求。
这样做还有一点好处就是在后续的测试设计环节中能减少冗余、优化测试过程。比如如果我们事先就通过大概了解整个需求而得知有几个页面的布局和功能点有很多类似的地方，那我们就可以直接同时考虑这几个相似页面的情况设计公用的测试用例，同时在流程测试上也能相应的设计合适的测试流程。
实际场景中就有些测试人员在拿到需求后，二话不说就逐行往下细读并开始设计测试用例，这样往往就造成对需求理解不到位、不全面，特别是在一些英文需求中，如果不了解大环境就开始设计测试用例，可能就会造成对需求的理解有较大偏差。
三、多站在用户的角度思考
其实任何产品都一样，做得再美好、再精致、质量再高，如果不是用户需要的那都白搭。当然这里可能涉及到一些产品需求方面的东西，这里主要是说对用户已经提出了的需求的把握，既然都有需求了为什么还会不明白用户想要什么呢？这里就有点像是“传话筒”游戏，第一个传话的人就是用户的明确需求，然后经过产品需求人员的理解、落实在需求文档上、测试人员对需求文档的理解，这一轮过后往往是会造成一些偏差的，那作为最终把握质量关的测试人员如果能站在用户的角度多思考，就能一定程序上抵消一些需求传递过程中的偏差，这就有利于设计更加合理的测试用例，并且尽早的发现需求中矛盾的地方，同时对于软件提供者来说会变得不那么被动。
软件测试过程中基本上都要以测试用例做为参考和判断依据，而清楚的理解需求是设计、完善测试用例的前提。当然，需求分析本身就已经可以认为是介入测试了，实际上往往很大一部分缺陷都是在需求阶段暴露出来的，相反，如果因为在分析需求时就已经出现了理解偏差而最终导致所做非所需的质量问题，那就是很不应该的。