功能测试之需求理解
--如何深入的理解需求

1之前看过一些书，大部分书上说的项目的前期准备阶段 所要花费的时间要占80% ，后续的执行工作占 20%的工作量， 那么实际的工作当中，有多少公司能做到这些呢？或许具有相当规模的公司或是软件流程相当规范的企业能做到，大多数企业为了节约成本，增加效益，往往一个测试团队在某个时间段内要测试多个项目，并且要保证产品的质量，给测试人员带来了许多压力，有了压力自然产生一些动力，如何快速有效的参与到项目中，如何快速的理解需求，把握测试重点成了项目团队必先解决的问题，也是保证质量的必然要求。
项目初期，往往是先由业务人员提出业务需求，但业务需求写的都不是很明确，然后需要项目经理、测试经理做一些评审，对业务需求做进一步的验证，再由开发人员重新整理业务文档，编写项目需求，那我们测试人员这个时候做些什么呢？
1、理解业务需求
往往通过业务需求，了解项目中的一些基本术语，不至于以后遇到专业词汇都不理解是什么意思，了解这个项目具体是做什么的，完成一个什么样的业务，哪些的功能最常用、哪些功能是最重点、或是说不允许出错的功能，比如银行项目的账务处理（存钱、转账等）。还有一个重点是了解业务场景，以便测试时，按照这个场景来测，更容易发现问题，也能够发现更深入的问题，毕竟程序完成的功能还是要以业务为中心。
关于业务的理解，还有一个途径，可以通过测试前期的培训，这个时候是提高业务水平、提高个人能力的一个有效的过程，该时间段，可以提出你的各种疑问，由业务人员或是对业务非常精通的人给出你想要的答案，千万不要吝啬，勇于提问，因为与业务深入的人员沟通的机会不多，若你提出了非常深入的问题，我想领导也会对你另眼相看吧，以后的机会大大地。呵呵
2、业务需求出来后，就要出项目需求，那我们最好能够参与到项目需求的评审当中。
项目需求的评审，测试方面往往都是测试经理或是负责人来进行，但如果普通测试人员有机会参加，就要珍惜机会，提出自己的想法和建议，一方面能够对整个项目有个更新的认识，更进一步了解程序实现业务的过程，另一方面，可以学习下测试经理与项目经理的考虑问题的思路，考虑问题的角度，哪些是你怎么也没想到的，这样的评审参加的多了，我想每个人的业务水平和思维方式都应该会有很大的提升吧，也是为以后成为测试经理的角色打下一个坚实的基础。
3、理解项目需求，了解整体项目流程，从整体到局部，从局部到细节。
项目需求下来后，测试经理都会把每个功能模块分配给相应的测试人员，测试人员不要总只了解自己模块的内容，要先从整个项目的业务流程入手，然后再到自己的功能模块，这样的好处是，测试人员了解上下游的交易功能，更加的能够了解业务的实现方法。这里的可以根据自己的理解画一些简易的流程图（自己看懂即可），先画项目整体流程、再画功能模块细节，感觉这样做更有条理些，而且逻辑清晰，更易于以后的测试工作。
4、遇到问题如何解决
需求理解的过程中，往往会遇到各种各样的疑问，那如何解决呢？可以将遇到的疑问全部罗列出来，每5个或是10个问题为一组咨询一下相关的开发人员或是测试人员，否则一个一个的问，相关人员可能会很不耐烦，对你的印象也可能不太好（总是忙的时候，来打扰工作）。若是遇到很棘手的问题，就可以直接咨询你的测试经理，若结果不另你满意的话，测试经理还会继续咨询其他人，直到满意为止。我们就是要有不耻下问的精神，往往你的领导会因为你问的问题而注意到你的，几个项目下来，福利待遇也许好点也说不定咯。
5、狂轰乱炸式深入理解需求
将自己负责的模块，有条有里的整理出来，然后讲解给项目组成员，这样也有利于模块模块之间的整合理解，再由他们提出各种各样的问题，若能很轻松的回答出各种各样的问题，说明对项目的理解已经很到位了，但往往的发现这样的情况并不多，很多的问题都是你之前没有考虑到的，所以问题之后，要对相应的点做上记录，以便后续测试中用到。每个人经过这样的“狂轰乱炸”后，想不了解的深入也不行吧呵呵。
6、了解生活、了解实际业务，我们往往在做项目时，才会考虑结合实际业务的运作形势，有时考虑的还不准确，而往往忽视了我们日常生活中涉及到的一些真正的业务，比如，从沈阳要转账一笔款在北京，还是跨行；术语叫异地跨行转账，那么这笔钱是如何转到北京的呢？
或是超市的POSE，我们刷卡扣钱，那么银行是怎么把钱给超市的呢？日常生活中我们多想想身边的业务的实现方式，到实际工作中应该是非常的得心应手，不管是那个行业线的测试工作，都应该注意身边的生活，从生活中的了解业务要比项目中了解来的更快、更好。或许这样生活也会产生很多的乐趣。
一句话，以业务为中心，从生活中了解业务。
以上只是个人对如何进行需求理解的一些看法，可能有的地方写的很狭隘，有的地方不适合某些公司的运作流程，写这个的目的也是对自己之前的工作进行下整理，另一方面还是希望对某些人有所帮助，希望大家多多交流，共同进步。将测试工作做的更好。同时也祝愿测试工作者都能够愉快的工作、快乐的生活。

测试的责任与感受
来到**将近2年，从一个不懂业务的毛小子到现在能够独立的测试项目，整个历练过程获得了领导和同事的帮助与支持；08年是我与产品部、项目团队共同成长的一年；也是努力奋斗的一年。

奋斗的过程中对如何做好测试工作产生了一些感触和想法。

1、        热爱自己的工作，对工作充满激情；我热爱测试这个职业， 喜欢接触不同的项目、不同的业务，因为这样更有挑战，更锻炼自己，更加富有激情，重复的工作有时候另我很烦躁，但每次重复的意义却是不同，验证的问题或是 思路有所差别，可能会产生一些新的灵感和启发，发现比较深入的问题。新的项目，往往是一个新的起点，业务逻辑、业务知识都要从头学习，这样就培养了我们的 学习能力，如何快速准确的掌握新项目知识也就成了一项挑战，越是挑战，就越会尽力把事情做好。

2、        对自己的角色有充分的认识，定义好自己的角色；作为一个测试工作者，我们是软件质量的保证者，软件投产时不出现问题，是我们的希望，一切都为了这个希望而奋斗；我感觉开发人员是我的直接服务对象，产品是我的间接服务对象；例如，提问题就是直接的服务于开发人员，间接的达到了产品的要求；找出需求不明确的地方，也是方便开发人员来编写程序，以至达到产品的要求，所以服务我的直接客户开发人员、配合好开发人员，是产品质量保证有利因素。

3、        高度的责任心、耐心、细心、自信心；自己认为作为一名测试员不一定技术非常强，有的时候更需要的是责任心、细心和耐心，许多微小的问题，单靠技术是发现不 了的，比如一些光标的跳转，打印凭证冒号的全角和半角等。跟踪问题，对哪个模块有疑问一定要及时咨询，经咨询没有得到准确答复的问题，一定要一问到底，一 直得到合理的结果为止。个人觉得，既然将项目交给我，就表示对我的信任，那么也会报着对客户负责、对项目负责、对交给我的模块负责的心态去工作。

4、        客服浮躁，保持良好平和的心态；记得08年年会时，有过这样一句话来评价中心产品部的员工，“心沉下去，Bug浮上来”，感觉像是玩笑，但也说明了保持平 和心态的重要。有的时候项目多，任务杂，往往将自己弄的很混乱，也很烦躁；甚至不知道从何下手；后与同事请教和学习，根据项目的缓急程度不同，根据项目的 功能点和分给自己的模块来进行分配时间，才解决了浮躁的问题。

5、        深入项目，做好需求理解，把握培训机会；新项目立项后，往往会给我们测试人员进行培训，千万别放过这次机会，培训更加能够让我们了解这个项目，提出各种质疑，基本上能够得到满意的答案。需求理解前期，最后能够了解项目的整体流程，然后慢慢进入到每个模块，再进入到每个模块的细支末节，最后回到整个流程。整个理解过程可以手工画一些流程图（不用标准，自己能够看懂就好，当然要是标准就更好了），这样能够理解的更加深入，印象也会更加深刻。对以后的编写用例或测试都会有很大的帮助。

6、        测试过程中做到思路明确、条理清晰；准确的把握自己验证的功能模块，把握自己的检查点、有多少路径能走到该验证点，每条路径产生的结果如何，都要有合理的 掌握，不要问题摆在面前，也看不出是问题，这样耗费时间和精力就没意义了。还有遇到的一些问题，在做A项目时，其他同事问B项目的问题，然后直接去处理B 项目的问题，处理完后，A项目不清楚验证到哪个模块了，导致东打一扒，西打一下的情况。后来与同事学习，争取将A项目的验证情况，做个节点（比如验证C功 能，那么争取把该功能验证完成）。然后再回答B项目的问题，这样回来在做A项目时，就知道该验证哪个功能了。

7、        测试数据的准确性，测试数据是测试的基点，有时为了方便，通过手工改数据，来验证问题，有的数据被修改了几十次甚至上百次，当发现问题时，连自己都怀疑自 己的数据，不确信自己的数据是否有问题；为了避免数据不准确的问题，我们做数据时最好通过上游交易来做，这样即使出了问题，要么就是上游交易有问题，要么 就是下游程序有问题，这样造出来的数据很有说服力，我们自身对数据也很有自信，可能也会少一些与开发人员不必要的沟通。

8、        执行测试，验证一些怪异的想法。执行测试过程中，往往会有一些奇怪的想法或是思路，那么千万不要吝啬，一定要通过程序来执行你的想法，在很多情况下，这样 的想法通过程序执行后，都会暴露出一些问题，有的是需求没有考虑周全，有的是开发人员没有考虑到，这样的测试不仅是做的深入而且更有挑战。

9、        及时有效的反馈；测试项目过程中，往往会遇到一些单凭个人能力不能解决，或是能够解决但会浪费大量时间的问题，这就要求我们及时有效的反馈给测试负责人， 一方面测试负责人会对项目全局的把握，另一方面我们的问题也会得到快速的解决（因为负责人会去催项目经理或是开发人员）；记得****项目前期，基本上每 天汇报跑不通的交易，有的问题第二天的新版本就会得到解决。花费10多分钟就能让测试负责人了解你的工作情况，解决你不能解决的问题，又何乐而不为呢？

10、        测试阶段，发现问题不要着急于提交问题记录；发现问题，争取找到问题出现的原因，定位问题，最好能够多做几遍，确认问题能够重现，再提交记录，用事实说话，避免与开发人员不必要的争论。

11、        学习核心的业务知识，提高自身能力；做功能测试对业务知识的了解极其重要，掌握了核心的业务知识，再测试过程中，才能事倍功半。

12、        有效的沟通；沟通无疑是增加团队友谊与增强团队建设的最好方法，不过这也是我最大的弱点，项目过程中，除了必要的沟通外，就很少与项目内成员交流心得，深谈体会。自己的想法和他人的见解，不能有效的融合到一起，导致提高自己和完善自己的速度降低。

13、        融入到团队中，培养自己的全局观、集体观，团队荣誉就是个人荣誉；与其他同事并肩作战，我们每个成员都将心比心，不断提出好的观点、想法、意见，那么我们的项目会测试的更加完美，我们的工作也更加和谐，富有激情。

14、        通过一些方式来缓解压力，消除疲劳；项目多，任务重，必然会产生一些压力，这时可以听听音乐，玩玩游戏，或是大喊几声（没人地方或是海边），将烦恼发泄出 来，或是找个知心朋友抱怨一下，表达下自己的感受，这个抱怨并不是对工作没有信心，只是缓解压力的一种方式。可能还有许多好的方式，一般就用到上面几个， 感觉还可以。

15、        总结不足，总结业务知识，总结测试经理的项目管理方法。不总结可能永远也不知道自己哪方面能力需要提高，业务知识为什么那么快就忘记，再想查询先前的项目知识，不知从何查起。08年好多业务知识都没来的及总结，总是给自己找原因，项目忙，没时间。总能找出原因，却找不到根本。遗憾

16、        坚持做好每个项目的测试工作，赢取信任，提高客户满意度；是不是感觉自己很认真的完成了一项工作或是一个项目，却得不到我们领导的认可、得不到客户的认 可，心里上很难接受；这时要给自己找找原因，是不是哪里能做的更加完善、更加合理、却没有去做，自己的能力是不是还达不到他人的要求，或是领导确实没有注 意到你。坚持别气馁，用后续的工作来证明自己的价值，还是用心的、一如既往的做好每个项目的测试工作，不断提高、不断改善，几个项目后，我想会很快的得到 客户的认可，得到领导的赞许。

17、        对比学习，不断提高自身素养与能力；集成阶段，自己测试过的模块通过后，到了综合阶段，为什么还会产生一些问题，为什么在当时测试时（集成测试）没有发 现，为什么其他测试人员发现你模块的问题，而你没有发现。当然我们不是完人，但是我们可以通过他人的问题记录来体会他们的思考方法和思维方式，学习他们对 问题的把握程度。有的时候往往通过综合的问题来举一反三，发现其他模块的问题。感觉学习他人的问题记录既能总结自己不足，又能学习他人的逻辑思维，是快速 提高自身素养与能力的有效方法。

           不能做的最好；只能做的更好。作为一名测试工作者，热爱测试这个行业， 后续的工作会积极的配合项目组完成项目任务，以平和的心态、认真负责的态度来做好项目的测试工作，相信“只要自信就有无穷动力、只要努力就能提高自己，只 要坚持就能体现价值、只要用心就能赢得精彩”

允许转载，转载请留原创地址http://www.51testing.com/index.php?uid-36817-action-viewspace-itemid-107466

功能测试:运用不同的测试手段和方法(等价类划分,边界值法,错误推测法),对软件功能进行测试，验证软件功能是否能够符合业务要求,进而保证产品质量。
  
   我们在验证功能时，往往是从页面开始，主要包括：输入域、选择域、相关按钮控制、打印页面等等，而有的时候往往忽略了整个业务流程，从而影响整个产品的质量。对于功能测试，有几点小建议，就是我们在做功能测试时，先从整个产品的行业知识出发，一切以业务为基础来进行测试，需求理解时， 就要把握整个产品的个业务流程，先做什么，后做什么，明确哪些模块功能是整个业务流程的重中之重。然后细节到每个模块的功能，明确这个模块要实现什么，该设置哪些验证点比较合适，理解需求的同时也要注意软件需求是否有遗漏的地方，因为人无完人，虽然经过几轮的需求评审，也有可能会遗漏一些点。理解完需求之后，进入测试设计阶段，这个阶段是测试工作中非常重要的一个时期，往往需要花费大量的时间，测试设计做的好，我们在执行测试时就相对比较轻松，也容易发现软件的缺陷。比如，在测试整个流程时，执行完一个模块功能后，什么字段该更新，会对下一个流程产生什么样的影响等等，用例设计时，都要非常明确的指出，这样我们会从业务角度来发现问题，不会仅仅局限于页面的缺陷。
   另外，在把握了个业务流程后，也不能放松对页面要素的检验，因为缺陷出现的原因往往是我们在页面下输入异常数据造成的。针对页面各要素，一些典型的用例如下：

   1. 页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。
　 2. 相关性检查：删除/增加/修改一项会不会对其它项产生影响，重复新增记录是否正确；不选择记录删除是否正确。  
   3. 字符串长度检查: 输入超出需求所说明的字符串长度，少于要求的长度，等于要求的长度，是否会报错。　　
   4. 字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错. 　
　 5. 标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确.
  6. 中文字符处理: 在可以输入中文的系统输入中文,看是否会出现乱码或出错.
  7.数据字典检查：查看每个下拉菜单，验证是否正确。
   8.空检验：必输项为空时，是否报错。
   9. 快捷键检查：是否支持常用快捷键，如Ctrl+C Ctrl+V Backspace 等.
还有，在我们测试完每个项目后或是在项目测试期间，都要及时的总结，一方面是把容易出现问题的地方总结出来，思考是什么原因引起的。另一方面，把较难理解的业务知识总结出来，方便日后学习，经常性的总结与思考，我们的测试水平也会更上一层楼的。

总之，在功能测试时，从行业的业务知识为出发，理解业务知识后，针对每个模块功能来测试。并且经常性的总结与学习，这样会使我们的工作更加轻松，也更有效能。

有句话，个人认为不错，我们验证的产品是符合我们的行业业务，而不是业务符合我们的产品。-----一切以业务为中心