浅谈黑盒测试培训
说到黑盒测试首先给人一种感觉，黑盒测试不象白盒整天接触代码，甚至给人感觉没有什么技术含量，既然没有技术含量，只要按着测试用例跑不就可以了吗？又谈何培训呢？纵观黑盒测试的全过程，的确只要按着用例去跑就不会出现什么大问题，但是至于发现的BUG质量和数量上，因人而异就会存在不同。因此只按用例去跑在某种程度上来说也是很难保证质量的，必竞在测试的全部过程中，人的因素才是第一位的。既然人的因素决定产品的质量，那么对相关测试人员的培训就显得格外的重要。
说到培训，首先要明确一点，就是要培训的对象是谁?是有经验的测试人员还是没有测试经验的新手或者是刚出校门的实习生；其次是培训的内容是什么？是否有必要进行培训？
至于培训对象，我个人认为对于没有测试经验的测试人员和实习生是最有必要进行培训的，培训的内容相对而言也比较多，培训的难度的也相对较大，由于这一部分的测试人员往往在头脑中没有任何的测试概念，对测试的理解相对而言比较肤浅，因此培训的时间相对较长，有的时候这种培训需要贯窜穿整个项目的过程。
至于培训内容，首先告诉培训对象什么现象算是BUG，什么情况属于正常范围内，同时教给被培训对象发现BUG的方法和技巧。其二，要强调BUG描述中的一些技巧，和在描述过程中经常遇到的一些情况和注意事项，最大限度的避免由于描述问题而导致的无效BUG。
第三，要让被培训对象养成对BUG的自检和测试人员之间互检的习惯，可以将一些无效BUG扼杀在萌芽状态；第四，提高被培训对象整理问题的能力，在实际的测试过程中，由于某一类问题而导致相关大量BUG的产生，测试人员如果能通过手中的BUG来找出相关的问题，那么在项目后期可以通过跟踪问题，来分析哪些BUG已经解开，是否还会复现，借此提高测试的工作效率，同时也便于测试团队的管理，特别是在测试团队人数较多的时候，所起到的效果就比较明显。第五，关于测试用例编写的对培训，特别要强调培训的方式方法，如果按常规的方法，逐条的讲解，或是给出一部分范例去教，剩下的用例让培训人员自己去写，我想其效果肯定不会很好。不可否认在编写用例方面确实需要一些悟性，但是对于大多数人而言，缺乏的就是这种悟性。基于上述原因，倒不如将需求中的所有的业务逻辑整理出来，无论需求中的业务多复杂、功能有多少，但是相关的业务逻辑并不会太多，整理后再进行分类，找出每一类业务逻辑的共性问题加以培训，在培训的时候，只要强调如果遇到某一类问题，怎么处理，怎样去写用例就可以了，至于为什么这样写我觉得没有必要说的过于详细。这种培训方式可以适合任何一个人，而且上手很快，培训时间较短，同时不用考虑对方是否能够真正的理解，只要照做就行了。
在进行培训的时候，一定要注意培训气氛要活跃，让大家说出自己的想法和观点，要增强培训的互动性，尽量避免一个人在上面讲，无数个耳朵在下面听的局面。要明确一点，培训别人的同时也是对自己的一种提高。人只有在宽松的气氛下亲身参与培训，而不是被动的“听”，这样才能记的扎实，才能全身心的投入进去，而且实际的运用过程当中也会更加灵活。另外，在培训语言方面，一定要尽可能的做到通俗易懂，也可以夹杂一些戏谑的成份，总之一句话，要让别人能够深刻的记住。印在被培训者的脑子里。
在培训的时候，负责培训的人员要事先把功课做足，要把培训内容印在脑子里，在具体培训的时候不要拿稿来读。要在被培训者面前体现出一种自信。体现出我今天教给你的东西会让你受益匪浅就足够了。
要时刻记住，项目培训是项目管理的一部分，也是一个团队工作风格的最初模型，要让团队中每一个人都喜欢你的培训，发自内心的愿意接受你的对培训，这才是最成功的培训。对于项目培训而言，没有完美的对培训，但可以得到完美的培训结果。
上述内容，部分来自于项目培训的经验，而部分内容则是对项目培训的一些思考。如有不对的地方还请同行拍砖。 :victory:总结的不错，对于没有经验或实习生的培训，个人认为首先要让他们知道黑盒测试是个什么样的概念，然后是告诉他们测试的乐趣在哪里，提起对测试的兴趣，最后再培训方法！ :handshake谢谢分享 观点很正确，支持啊。 非常好，很实用啊。 写的非常好，借鉴下。
页:
[1]
