看完Alan Myrvold写的----提高软件测试能力的19条建议，然后对于其中一些建议总结下自己的看法，适合于初学者也适合有经验的测试人员思考。
想想自己做测试快7个年头了，由最初的cs客户端应用程序测试到后台服务器测试再到网页搜索测试，由纯功能测试到自动化一步一步走来，感触很深，但偶尔想起来还是有点空白，那么多经验教训感觉还是应该系统性的总结下整个测试工作，于是有了这篇博客，仅供闲暇无聊打发时间，这几条不分先后顺序，只讲点；
1、想别人之所想。从用户角度考虑问题，把自己当成最终用户，如何使用此软件。这点不用多说，大家应该都能体会到，比如平时所提的建议性bug，大部分来源于用户使用感知；
2、多读bug。有一句"言语"是：熟读bug千百遍，想找bug也不难！其实是很有道理的，从别人的bug中你能捕获到当初别人是怎么想的，怎么就发现了这个bug呢，锻炼自己思考问题的广度；
3、分析自己的bug。追踪自己提交的bug的最终解决方案，开发当时为何会出这个bug，由这个bug会不会联想到其他地方也有可能出这样的问题？如果下次再遇到类似的功能的时候，会不会出现的问题起到一个很好的参考作用；另外经历的问题多了，说不定当你发现问题时候，直接就想到是开发人员程序的哪部分出了问题，一定程度上能节省开发人员的时间，提高解决bug的效率；
4、了解你测试功能的整体架构。不管你测试的是哪一部分的功能，首先你最好去了解下这个功能设计的来源，与其他模块的交互关系，这里举个我经历过的例子：在蓝汛做后台服务器测试的时候，其中一个需求是日志分析然后统计pv量，我测试的程序本质功能是统计完后直接入库就结束了，但是后来出现了一个问题，就是当Pv量是0的时候，他并不影响入库，所以我没考虑，但恰巧有个别的前端部门需要用到这个数据并在页面展示出来，问题来了，他们的代码没有规避除数为0的情况，展示时候就报错了，当然这个应该是他们规避的，但是那边的代码只是维护阶段，新的开发人员并不愿意动老代码，并且改动后也会影响到程序其他功能，工作量太大，最终的解决办法是我们这边程序回滚，去掉为0的数据；
5、需求分析。最好参与整个需求的开始到最终确定，最直接的方式是参加需求讨论会议，因为在会议上你会听到他们讨论为何此需求能实现，实现需要改动哪些代码等等信息，让你更了解整个项目的内部运作，有利于你书写测试点。
6、多沟通。其实多沟通的目的也无非是多了解需求，包括与开发人员和产品人员的沟通，与此同时也可以增加与开发和产品人员的人际关系，这是一门学门，沟通顺畅了，能事半功倍。
7、危机感和学习创新。很多做测试久了的人会有一个想法：我能一直这样做测试吗，一直点点点吗？大家都知道答案是不能，因为你能做到的大部分刚毕业的学生都能做到，那要怎么去提升自己不被时代淘汰呢，那就是从工作本身去思考，你重复的这些劳动是否有办法不这样重复，就是思考如何解放劳动力的问题，那么对测试而言，首先想到的是使用自动化，选择何种自动化方式，需要根本你本身的需求，你可以用脚本自己测试，比如shell,python甚至包括java，你也可以用开源的自动化工具，市面上也很多比如功能测试的QTP，性能测试的loadrunner等等，这些工具的使用的都不要怕，如果你有需求目标，学起来也不难；最后任何职业的人员时刻保持一颗积极学习的心态很重要的，他决定了你到底能走多远！
欢迎讨论！我的qq:395085498,请注明来意,邮箱：dongshiyue1009@163.com
阅读(4794) | 评论(0) | 转发(1) |
