识别庐山真面目——分析需求

　　测试需求的获取，是测试工作迈开的第一步，这在上节做了介绍，接下来是在有了需求后，如何理解它、分析透它，成了问题的关键。也只有解决了这个问题，才能提取出具体的可操作的测试对象出来。

　　1、快速理解需求的捷径：需求宣讲

　　软件需求是软件项目开发的依据，代表着用户的需求，是软件设计及软件测试工作的入口，在整个软件项目开发过程中起着举足轻重的作用。对需求的理解是否到位，在很大程度上影响着开发过程的效率。曾经有个小项目（整个项目时间约两个月），需求不多，在进行需求评审时，包括开发及测试人员都认为理解了需求，但在后来版本测试中才发现，有一个重要需求点，开发人员与测试人员的理解完全不一样，到底谁的理解才是对的呢？双方找来需求讨论，恰恰需求设计人员对这一块的理解也讲不太清楚，写在文档中的描述就更不用说了。也就为此一点，开发整改设计及编码，测试整改测试方案及用例，最后版本的发布推迟了两周。俗话说“吃一堑，长一智”，通过这样的项目事例，我们需反思整个开发过程做得不够的环节，就“开发过程中如何更好地理解软件需求”有以下几方面的最佳实践。

　　需求宣讲的组织：需求基线一旦形成后（即需求完成第一版后），启动内审，通知项目组相关人员事先预审，给出问题反馈的截止时间与内审时间。

　　介绍需求的背景：需求编写人宣讲需求，介绍需求的用户背景。这点很重要，让开发及测试人员能清楚知道用户的用途，实现后的软件是用来做什么的、能满足用户哪些要求、能给公司创造什么样的价值等，使开发及测试人员的工作目标很明确，处处从用户立场考虑。

　　需求宣讲内容：需求宣讲是否需把所有内容都讲一遍？回答是肯定的。正如前面所述，需求的至关重要性，如果需求内容多，可分开多次宣讲。当然讲解时，也要分开重难点，对于大家容易理解的需求（如之前项目做过或众所周知的需求）可以几句话带过。

　　辅助答疑式宣讲：在需求宣讲时，对项目组成员收集到的问题，一一进行解释，回答提问者疑问的同时，也分享给其他同事。

　　有一个事实我们不得不承认，需求不可能详细到面面俱到，总会存在着隐含需求，这种隐含需求的理解会体现出你对需求的掌握程度。对于这种情况怎么办呢？无论对于开发还是测试，如果自己意识到了，但不能确认，把问题记录下来，与需求确认，并要求需求补充明确。

　　需求的设计也不可能是完美无缺的，在测试活动的整个过程中，特别是在设计用例的过程中，测试人员会发现不少有需求定义的Bug，此时把它也录入缺陷库，作为一个缺陷来跟踪管理是一个不错的方法。俗语说“好记性不如烂笔头”，事实证明，只在口头上说的事，需求人员容易忘改需求，使得最后测试用例与需求对应不上，且给后续加入项目人员的工作增添麻烦。后面常会发生“这个地方的需求与实现不同，是以需求还是以实现为准”的局面。

　　2、需求定义也会错并不是谎言

　　需求定义是否存在二义性，一直以来是衡量需求是否明确的一个标准。尽管需求设计人员采用了图、表等图文并茂的方式来表达，但面对有着不同背景的读者群，同样一段话，理解的结果就是不一样。特别是对于一些需要有一定背景知识的需求，不是理解不到位，就是理解错误，这也就有了显式需求与隐式需求的叫法。显式需求指有明确定义的一系列约束软件实现的要求，可以是有给定具体值的数据字典，或有序的业务流程图，或一段介绍业务功能的需求描述等。隐式需求并不是需求设计人员特意隐藏，更多的是由理解人员对某方面专业知识，或对产品的业务了解程度有限导致的。例如：某软件需求中有一句这样的定义“对用户产生的数据，需每天定时备份（默认为每天晚上12：00，用户可设置），并可按需生成书面报告，报告中的数据不存在法规风险”。那么，此句话中的“法规风险”具体是指什么呢？这正是需求背后的需求，也就是隐式需求。

　　隐式需求的识别要求较高，分析需求时，测试人员能否过滤到，直接影响着后续测试工作的有效性与全面性。另外，对显式需求中存在的错误是否能及时发现或意识到也同样重要。下面是一个需求定义中存在缺陷未及时发现的案例。