软件测试中如何深入功能测试

软件测试中如何深入功能测试

来淘宝实习3个月，刚开始来直接做功能测试，执行用例。觉得执行功能测试用例没有什么技术含量，做测试还是做接口测试、自动化测试、性能测试才比较有前途。于是研究自动化工具，学习脚本语言ruby。一起来实习的同学看到我整天忙得没闲下来，觉得我学习没有重点，看的资料多，但什么都学得不精，我当时也很困惑，静下来想了很多。

　　首先，我想到的是，什么才是“有技术含量”。一个“有技术含量”的东西就是你能做而别人不能做，或者你能把工作完成的又快又好。如果你的工作任何人随时都能胜任，那就不算有技术含量。从这方面来看，很多人觉得手工完成功能测试没有技术含量不足为奇。因为如果按照用例去执行，根据前置条件，执行步骤，预期结果,即使是一个从来没有做过测试的人也可以很轻松的胜任。但是如果是设计、编写用例，给出一个功能点，是不是每个人都能快速的设计出覆盖率高、复用性能好的测试用例，而且语言简洁，条例清晰。这个答案就不一定了。在我实习期间，第一次做了一个完整的项目，用例总体设计是师傅顾欣， 用例的2/3是师傅完成的。我明显意识到了差距，不懂业务，不熟悉逻辑方法，自己只有努力看需求以及请教师傅和开发的同时，把逻辑搞清楚，把业务弄熟悉。

　　再次，不管什么工作，什么事情，，只要坚持做得深入·，就会有能力的提升。对于测试来说，我认为能力包含技术，还包括技术以外的东西，比如：交流能力、写技术文档的能力。技术方面的，比如如何定位BUG，追踪BUG,就可以做的很深。这个问题，面试的时候，面试官也问过我。在项目中我碰到过这样一个问题：浏览器交叉测试，我用FireFox发现了多行文本在超长字符校验上有问题，但是IE上就没有问题。开始准备直接提交BUG，定位为浏览器差异。后来请教师傅顾欣，她详细校验了空格、回车符在2种浏览器中的计数差别，很快定位到BUG是由于回车符在FF上是记做了2个字符，提交BUG。很明显，第二种做法，BUG修复起来也快，而且开发也愿意配合，自己的能力也能得到提升。测试人员不能一味地只提BUG，有时可能将正确的东西误认为是BUG，也是对开发人员的劳动成果不负责任的否定。的确，一开始反复确认BUG,慢慢细化问题的时候，会很花时间，而且效率并不高，但是有句话不是说“火车刚发明的时候比马还慢”，当你积累了业务经验、熟练运用工具后，你会发现BUG定位越来越快，处理问题越来越顺手，自己的能力也得到了提升。

　　当碰到无法解决的问题时，要积极地和开发商量，不要自己钻牛角尖。在项目中我也碰到过这样的问题，后台设置单选、多选选项的BUG，提交开发，发现是分词方法使用有误，开发修复之后，我询问了他修复使用的方法。我们得承认，在编码方面，开发人员确实比测试人员更专业，他们解决修复BUG的方法值得我们在后面的测试用例设计的时候好好借鉴。但我们也不能妄自菲薄，只有把测试工作做得更专业，才能得到别人的信服。

　　最后，其他能力的锻炼。可以肯定的一点是，测试不是想象，想怎么测，就怎么测，不是你点点鼠标就能完成的一件事。我们总是在开始测试之前，就先把思路整理清楚，锻炼了逻辑思维能力。我们总是在描述BUG的时候，担心开发看不懂，每次以他人的眼光审视自己写的BUG，是否有歧义，是否带有截图，是否有步骤的详细描述，是否简练直白，锻炼了文字描述。我们总是和PD确认需求，和开发确认缺陷，锻炼了沟通能力。可能有人认为这不是一种能力的提升，不能称之为收获。但是如果没有经历这些情景，你是不是会在执行测试用例的时候，发现还有功能点没有写进TC里面，要重新再写再测；你是不是提交BUG之后，开发过来问你，这个BUG是怎么回事；你是不是在需求了解的不是很清楚的时候，把一个不是错误的BUG提交给开发，开发立马把BUG状态改成invalid，等等。

　　任何工作，在BS他之前，先看看自己对他付出了多少。如果你只是简单的学会怎么用自动化或者性能测试的工具，而不去深入了解内涵，也不会有什么能力的提升吧。

　　在经历了淘宝实习期，我更了解测试工作，也坚定自己继续在这个行业发展的目标，所以在刚来迷茫期的时候，我把自己的旺旺签名改成了“一步一步来，不要焦虑”，我喜欢没有焦虑，一步一个脚印的认真生活。

原文转自：http://www.ltesting.net