软件测试杂记_H(一) .docVIP

目 录  1. 测试组是助力研发软件质量还是拉软件周期后腿？ 2 2. 关于软件项目后期Fix bug的意义之我见 2 3. 只会黑盒测试算专业的软件测试人员吗？ 4 4. PS是什么意思 8 5. 软件测试员----你的路在哪里？ 8 6. 由“游戏测试”引发“手机测试”的一些感想 10 7. 专业测试人员发展的未来 12 8. 软件测试工程师的分类从新手到专家 13 9. 在浏览器地址栏按回车、F5、Ctrl+F5刷新网页的区别 16 10. 从一个测试实验想到的 17 11. 手机测试之详谈 19 12. 软件测试之敏捷的质量 21 13. PRD 23 14. 软件测试随想 23 15. 要想做好软件测试工作，就要学会思考并问为什么 24 16. 浅谈软件测试用例编写及要点 27 17. 什么是探索性软件测试 27 18. 关于接口测试 28 19. 由单元测试看功能自动化软件测试 29 20. 从BUG的“一生”闲谈软件测试工程师面试 31 21. 关于API测试 33 22. 软件开发中的破窗效应 34 23. 软件测试管理之绩效考核 37 24. 软件测试的Bug统计是在浪费时间 39 25. 聊聊自动化软件测试为什么推广难 42 26. 回归测试的策略及方法 43 27. 基于会话的探索性测试管理 45 28. 软件测试人员的核心技术能力，应该是什么？ 46 29. 如何入门软件测试的职位 47 30. 需求的来源 48 测试组是助力研发软件质量还是拉软件周期后腿？ 软件测试团队作为软件研发部门的一个组成部分，一度听到的都是软件测试很重要，要重视软件测试。可在当下现实环境中，你有想过软件测试也会拉后腿？！ 　 　当研发团队中开发人员资源比较紧缺，而任务比较重，项目比较急的情况下，若全部经过测试组，在软件质量保证的同时，必然出现了软件周期延长，项目上线延 迟的问题。倘若测试人员对任务周期安排不恰当，对很早提交的任务进行测试，发现问题让开发人员重新熟悉程序进行解决，又必然占用大量精力和时间。在开发人 员原本就很紧张的情况下，加剧了问题的严重性。 　　这就出现了测试组测与不测的问题。若测试，软件周期太长，影响项目上线和客户使用；若不测，软件质量没保证，影响上线维护和客户使用。这是一个很矛盾的问题。 　　有一个解决方法，任务开发完直接升级到现场，由开发人员和设计人员进行测试验收。这样测试组干嘛？ 　　为什么会出现这种问题呢？ 　　很显然，开发人员紧缺是个很关键的问题，因为开发人员既要开发代码，也要改代码bug，还要支持现场代码版本等问题。所以开发人员可以不充裕，但是不能紧缺。可能目前还存在开发人员技术水平和业务经验的问题，这也影响了开发速度和开发质量。 　　另外，说说测试组吧。曾经测试流程出现过问题，测试组在家里测过的程序升级到现场仍会出现不可用。后来改进流程，程序升级至现场测试环境进行测试，增强程序运行环境真实性和程序版本兼容性。现在面临的上述问题，跟测试组本身也有很大关系。 　　从两方面讲，第一缺乏技术含量。为什么开发人员不能缺，而测试人员可以没有。因为测试人员目前所做的大部分工作可以被开发人员和工程人员所取代，只是不那么全面专业罢了。测试人员没有自己特有的测试技术。有的话可以说是对业务逻辑的测试经验了，但是我仍然认为这不是真正的测试技术。不要怪我讲的这么露骨，我认为这是事实，不用掩饰的。 　 　第二不了解实际需求。尽管工程人员做的测试可能相对没那么全面，但是他们至少比我们更清楚客户的实际需求。他们可以避轻就重的进行测试，这样就可以满足 客户使用的主要功能没有问题，其他小问题慢慢解决了。作为测试人员，要尽可能测试全面，不遗漏任何功能点，因为不清楚客户实际会怎么使用。这种方法和思想 是正确的，只是在项目中客户群体比较小和使用频度不高的情况下，相对花费了不少时间。 关于软件项目后期Fix bug的意义之我见 众所周知：基本上所有的软件项目到后期必不可少的是fix bug，一个软件在交付客户后或交给测试人员测试时都存在一些程序员意想不到的问题。现在有一些成熟的bug跟踪系统，譬如：bugzero，bugzilla， redmine等等。 　　解bug是很头痛的问题，一般是以下原因引起的： 　　（1）设计上的缺陷； 　　（2）写代码时考虑不周全； 　　（3）测试人员无中生有； 　　（4）所依赖的插件，框架本身的缺陷。 　　第一种情况：最棘手，需要修改程序架构，费时又费力，但是不改又不行总不能要客户该需求，按照你的程序来吧。没办法，改吧。 　　第二种情况：还好，看看是那里出来问题，改改代码就可以了，但是改完后需要确认一下会不会对其他模块或功能造成影响。一般如果影响很大的话，那就是模块之间的耦合度太高，不是高质量代码，会越