大型软件的测试往往有不同的团队协作完成, 单测试也会有不同的团队完成, 单元测试,集成测试等等.如此多的问题需要一步一步来解决.

   1. 界定自己的测试范围,获得关于自己任务的准确信息. 例如测试的环境,分配给你的模块,是什么类型的测试.需要在多长的时间内完成.

   2. 寻找所有可以协助你完成测试的资料,如安装文档,功能说明. 如果有相应的培训,认真听讲,及时提出问题. 充分利用这些资料去熟悉软件.

   3. 充分利用自己经验和基本常识去判断软件的工作是否正常. 有的 bug 是由于软件的流程错误引起的. 但是一些很常见的 bug, 例如界面错误, button 不工作,下拉列表不工作, missing object, 等等一些简单的错误是能通过基本常识判断出来的.

   4. 尽量多的去浏览别人发现的 bug, 这样可以减少你报 dupliate bug 的最佳途径. 也可以帮助你节约很多不必要的时间.

   5. 去提炼自己的 bug, 尽量提供足够多的信息, 不要吝啬在提炼 bug 上花更多的时间.

   6. 及时查看信件, 看是不是有关于项目更新的信息. 很多变动都是临时的,例如某个模块先不测,或者有新的 build.

   7. 不要抱怨软件的质量,本来就是一个半成品.

   8. 如果对软件不了解,那就一个 button 一个 buton 的来, 最终用户也是这么用的,只要把最终用户用的地方都测了就好了.

   9. 大体熟悉了软件之后, 可以按照user guide 里的一个 scenario 去跑一下软件,就了解了软件所要完成的功能了.

   10. 从一开始就跟着 schedule 做, 不要拉下. 越到最后事情越多.

   11. Testcase 是用来指导测试的,捎带把见到的 case 没指定的地方也测试一下,可能有好的 bug 发现.

   12. 不要忽略你在测试过程中发现的任何异常情况, bug 可能在这一瞬间被发现了.

   13. 在和别人讲述一个 issue 的时候,自己先弄明白,特别是在开会的时候. 

   14. 抱着帮别人发现问题的心态去做测试,而不是调刺的态度. 我们是在帮开发团队提高软件质量,不是付费用户.

   15. 如果别人对你的 bug 有异议,给他提供更多的信息来阐述你为什么认为这是一个 bug.

   16. 不要人为的制造 bug, 注意你的测试环境, 如果发现的 bug 在别人的系统上没有速查自己的测试环境.

   17. 不要用不符合常理的测试用例, 暴力破坏软件来证明软件的错误.

   18. 遵循项目的书写规范和要求去执行测试.体验一下从不同角度去分析成千上百个 bug 的任务,你就会发现按照指定的规范写 bug 有多么的重要.

   19. 你发现了多少 bug 很重要,但是保证没有 bug 在你的测试范围被丢掉更重要.

   20. 测试无极限, 尽可能多的去发现问题很重要.