测试小故事20：停不下来的需求变化

  “没有需求？你开玩笑呢，怎么做测试？”
  “这是什么需求，都没说清么，怎么判断正语，怎么测试？”
  “这需求在不停的变，我们怎么测试？”
  “为什么需求变了也不通知测试一声，提交的BUG还被拒？”

  有关需求，测试抱怨最多的莫过于需求的不断变化：没有、不明确、变更
  测试工作仍需要继续，如何应对需求变化下的测试工作？

  根源在需求，那么首先解决什么是需求？
  经济学中需求是在一定的时期，一个经济主体对一件商品或服务的效用，通常跟他/她的收入有关。 -- 百度百科
  软件需求是(1)用户解决问题或达到目标所需条件或权能(Capability)。 (2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。 (3)一种反映上面(1)或(2)所述条件或权能的文档说明。它包括功能性需求及非功能性需求，非功能性需求对设计和实现提出了限制，比如性能要求，质量标准，或者设计限制。 -- 百度百科
  好吧好吧，照猫画虎来个简单点的：软件需求就是软件需要者对于软件的要求，通常跟他/她的想法、工作生活环境相关。而软件需求按不同的层次分为：业务需求、用户需求、功能需求、非功能需求
  复杂描述的好处是说的清楚，没有明显的漏洞和缺陷，缺点是需要花时间分析、理解。简单描述的好处是通俗易懂，缺点就是很容易被受众提出一系列的问题，特别是测试者。在不断封堵漏洞的过程中，简单的描述形成了稳定版的复杂描述。
 
  需求定义的关键词： 软件、要求、相关
  测试人员拿到的是什么样的需求，测试需求与什么相关？
  从传统的瀑布模型来看，测试工作位于软件开发的末期（其实现在我数时间还是这样），这也就决定了测试人员拿到的需求多数是二手、三手或是N手需求，信息传递的有效性就决定了，测试的需求本就与真正的需求相去甚远。
  好吧，这么看来，没有需求、变型的需求、变化的需求对于测试来讲就没有太大的差别，只是多与少的问题。

  >> 没有需求/需求不明确
  这个问题让人很纠结的事情，没有需求/需求不明确，有系统，要不要做测试？测试原则告诉我们，测试要对预期结果和实际结果进行对比，以发现问题，需求是确认系统实现是否正确的标准。没有需求怎么判断正误，也就不需要测试。
  一个问题：作为测试，要的是需求本身？还是需求文档？对于大多数测试人员来讲，他们要的只是一份对于需求描述的文档，白纸黑字才安心。
  新的问题：测试人员怎么获取需求，没有文档就拿不到需求吗？转回需求的层次：业务需求、用户需求、功能需求、非功能需求
  又一问题：没有需求项目怎么立的项？设计怎么进行的？开发怎么进行的？。。。。。。
  答案： 想来没有需求文档，测试人员可以看系统、与设计谈、与开发谈、有机会与客户与用户谈，主动去挖掘需求，不就是文档么，我记录我来完善，提交项目人员检查、确认就好。
  估计这样答案会招来一片臭骂：如果测试人员自己写测试需求，是不是不务正业？你有什么机会和资格跟客户、用户谈？你跟设计、开发聊，他们不跟你讲怎么办，听不懂怎么办？
  办法总比问题多，有问题就有办法解决，主动点，事情总能向前推进。
  问题总比办法多，那就洗洗睡吧，不要说什么需求的事，悄悄的。
  

  >> 需求需求变化太快/需求变化不能下达到测试
  这个世界唯一不变的就是变化，哪有十全十美、一叔到位，思维的完善是由浅及深、由无知到了解到掌握的过程，软件作为人脑思维的产特也逃脱不了这个过程，不变才是最可怕的事情。
  客户是上帝，掏了钱的。受人钱财与人消灾，不好伺候也得伺候，所以人家爱怎么变就怎么变。
  人的惰性是十分可怕的，改变人的惰性：要么自己有改变的动力，主动寻求改变；要么就等外界压力到来，被动不得不改变。
  说了一堆遭骂的话，还是要落地具体可行的策略上来，在更新速度越来越快的今天，只发现问题抱怨没什么用，主动比什么都重要。
  客户爱变化，就找行业专家引导他，减少变化，保持主基调的稳定性。
  需求变化太快，那就应对变化，响应的更快一些，构建适应于多变条件下的测试过程、测试方法。
  需求变化不下达，那就提高自我的沟通能力，学会用专家的语言、设计者的方法、开方者的思维与不同的人沟通，当你获得了信认，也许你愁的不是需求能不能及时下达，而是忙于与各方从测试角度沟通需求是否可行。

  这个世界唯一不变的就是变化，拥抱变化吧！
  一句话：再主动点，做好准备，想好策略，应对变异、变种和变化。

--------------------------------------------------------------------------------------------------------------------

  更多观点： 没有需求要不要测试？问题答案显而易见，要测试，只是这样的测试的展开更难控制和把握一些，更多是需要测试人员的积极性和主动性。有明确需求描述和没有明确需求描述，是两种不同的测试类型，因此所采用的策略和方法也就不相同，可以实施的测试类型也有所区别，用来验证系统实现正确性的方法也会大不相同。从给标准到寻找和探索标准，这的确需要测试人员的主动性和对测试的敏感性。初期单无测试和功能性测试没有需求的情况下应该会好做一些，因为功能的标准来自于设计实现，与开发合作的紧密性决定了测试的工作易于展开，而集成测试和系统由于涉及到业务层的需求，因此需要测试人员努力成为一个行业专家、成为业务专家，需要从不同的方面去了解业务流程和客户的实际需要，采用的方法可以是正规的途径，如客户访问、客户调研等；当然还有非正规的需求，如私下的客户聊天，到相同或是相关系统的代签，行业知识的学习等。

  如论何种方式，一但决定要测试，有需求和没有需求已经不再是问题，真正的问题在于采用什么样的策略完成测试。