一、显式需求与隐式需求
可以说，用户需求是软件测试的第一纲领，测试活动都应该围绕软件需求展开。我们可以将用户需求分为显式需求和隐式需求。
显式需求就是白纸黑字写在需求文档上的，这往往是用户要求直接实现的功能特性；隐式需求是需求文档没有直接提及但是在软件开发、测试等角度需要考虑的。
显式需求是硬性要求，是无论如何都要实现的部分，而隐式需求则要视实际情况而定，比如界面友好性、字段检查等，在需求中不一定提及，但是如果客户对质量要求很高的话那在测试的时候需要考虑更多的隐式需求，反之则在保证显式需求的前提下适度的考虑隐式部分。
如下面这个简单的需求片断：
"点击[申请]按钮，在弹出的对话框中用户能够输入电子邮件和用户名并提交申请(无配图)"
由此我们可以分析出显式需求如下：
1，添加一个按钮，Label为"申请"
2，点击[申请]按钮打开一个对话框(对话框大小、位置、标题、是否模态化等因素并未说明)。
3，对话框中有两个字段"电子邮件"和"姓名"(摆放位置、字体大小、颜色等未说明)。
4，两个字段的类型都是字符型，且指明了长度（电子邮件格式、姓名可否包含空格、是否要验证必填、输入超长时如何提示等未说明）。
5，对话框中至少有一个按钮"提交"(关闭对话框的方式未提及)。
... ...
查看全文内容，请点击下载：http://www.51testing.com/html/65/n-3704165.html
在实际软件测试周期中，在需求阶段通常的做法有：
1，对于很明显很直接的用户需求，可以直接转化为测试需求；
2，对于用户需求不明朗的部分，但是又必须弄明白的部分，进行确认；
3，对于用户需求不明朗，但是又无关紧要的部分，可以酌情适当处理（依质量要求转化为不同程度的测试需求）；
4，对于用户明确提出的需求，需求之间存在逻辑或者业务上的冲突时，尽快确认。
当然，实际当中都得视情况而定，有些用户需求确实写得很完善，那可以直接用来转化为测试需求并体现在测试用例中，也有些需求写得很粗糙，但是出于成本等因素考虑，他们的质量要求或许并不高，那也可以放宽限度不去深究不明朗的部分。软件测试并不是保证所有被测软件都完美无暇，而是给用户需要的。
二、理解需求忌管中窥豹
用户需求的提出往往是为了实现某一完整的业务流程或功能，在分析理解用户需求时也像写作一样，要先有一个框架在心里，要先把握用户的大概意图、明确整个需求文档(或其它形式需求)的整体意思，在此前提下再去深入的细读每个需求点才会更有利于理解用户的真正需求。
这样做还有一点好处就是在后续的测试设计环节中能减少冗余、优化测试过程。比如如果我们事先就通过大概了解整个需求而得知有几个页面的布局和功能点有很多类似的地方，那我们就可以直接同时考虑这几个相似页面的情况设计公用的测试用例，同时在流程测试上也能相应的设计合适的测试流程。
实际场景中就有些测试人员在拿到需求后，二话不说就逐行往下细读并开始设计测试用例，这样往往就造成对需求理解不到位、不全面，特别是在一些英文需求中，如果不了解大环境就开始设计测试用例，可能就会造成对需求的理解有较大偏差。
... ...
查看全文内容，请点击下载：http://www.51testing.com/html/65/n-3704165.html
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
