1）学会彻底的分析测试结果。不要忽视了测试结果，最终的测试结果或许是“pass”或“fail”，但诊断导致“fail”的原因会引导你发现这个问题的解决方案。一个不仅仅记录了bugs而且提供了解决方案的测试人员是难能可贵的。
2）学会在每次测试任何应用时将测试覆盖最大化。虽然100%的覆盖或许是不可能的但你应该试着去接近它。
3）为保证最大化的测试覆盖需要将应用分割成更小的功能模块。在这样的单元模块上编写用例，如果可能的话讲这些模块分割成更小的部分。 举个例子：我们假设你将你的网站应用分割成了许多模块，“接收用户信息”是其中之一。你可以将用户信息填写页面分割成更小的部分来编写测试用例：比如叫界面测试、安全测试、用户表单的功能测试等等。在输入框里测试所有的字符类型、字符长度、无效性测试和有效性测试。写出所有这样的测试用例以增大测试覆盖率。
4）当写用例的时候，首先要考虑怎么实现目标功能也就是寻找需求上的有效条件，然后再为无效条件编写用例。这样就能覆盖在应用测试过程中出现的常规和非常规操作。
5）积极思考。要抱着找缺陷的目的去测试，不能一开始就想着应用中没有任何问题。如果你测试的目的就是在找缺陷你就会很自然的发现一些微妙的缺陷。
6）在需求分析和设计阶段编写用例，这样你就能保证所有的需求都是可以进行测试的。
7）让开发在编码之前就能看到你的用例。不要想着等程序发布时测试可以去提报很多缺陷而让你的用例一直在你自己手里。要让开发完整的分析你的用例去开发有质量的程序。这样就能节省返工的时间。
8）如果可能话要明确和组织你用来做回归测试的用例，这会保障手工回归测试能够快速有效的进行。
9）对临界应答时间有要求的应用需要对其进行完全地性能测试。性能测试是许多应用测试的重要组成部分。由于缺乏测试所需的大量数据，性能测试在人工测试中多半会被测试人员忽略掉，所以需要找到测试应用性能方法。如果不能手工添加测试数据，最好写一些基本的脚本来添加性能测试所需的数据，或让开发人员帮你写出来。
10）程序员不应测试他们自己的代码。像我们之前讨论过的，开发人员应该对应用做了充分的基本的单元测试后才能给测试人员发布应用新版本。测试人员不能为了进行测试去催促开发人员快点发布新版。要让他们支配好自己的时间。从领导到项目经理都会知道模块什么时候发布以及能够预估处相应的测试时间。这是敏捷项目的一个典型情形。
11）进行超出需求范围的测试。对应用进行超出需求要求的测试。
12）做回归测试时要运用之前的缺陷概览图（缺陷概览图---不同模块缺陷发现数目与时间的关系图）。这种明了的图表可以很好的预测应用哪些部分最容易出问题。
13）记录下测试过程遇到的术语和概念。在测试应用时也一直开着一个文档，在里面记录测试进度和测试状况。在准备最后的测试报告时就可以利用文档里记录的这些内容。这个好习惯会能帮助你提供完整明了的测试报告和应用发布细节。
14）测试人员或开发人员会对应用代码进行多次修改来适应测试。这是开发或测试过程中必要的一步来避免事务有效执行，比如在银行项目中。要记录下来为适应测试而修改了代码的地方，并且在最终发布的时候确保已经将这些修改的地方从最终客户端的源文件里都改正了。
15）让开发人员远离测试环境。这是在发布或部署文件中检查配置修改是否遗漏的必要步骤。有时开发人员做了一些系统或应用的配置修改，但是却忘了部署。如果开发人员没有权限访问测试环境，他们就不会不小心修改了测试环境，而且那些遗漏的地方可以在相应的地方找到。
16）让测试人员在软件需求分析和设计阶段参与进来是很有用的。这样测试人员可以对软件有可靠的认识来保障较好的测试覆盖率。如果没有让你参与这个研发周期，你要请求你的领导或经理允许你的测试团队参与所有的决策议程。
17）测试团队应该与其他团队及他们所在组织机构分享最佳测试实践、经验。
18）增加与开发人员的交流来知道更多关于产品的知识。只要有可能就进行面对面沟通来迅速解决问题和避免误解。并且把你对需求的理解或解决了某些问题，确保同样也通过书面形式如电子邮件进行沟通。不要任何事都靠语言交流。
19）不要把时间全放在高优先级的任务上。分析所有任务相关的风险，把你的测试任务按优先级先后排好然后做出相应的计划。
20）编写清晰、描述性强、明了的缺陷报告。不要只提供缺陷现象，也要提供缺陷带来的影响以及所有可能的解决方法。
不要忘了测试是一份有创造性和挑战性的工作。它最终取决于你的技能和经验，你会如何应对这个挑战。
希望大家做的： 分享你自己的测试经验、技巧或测试秘诀，这样肯定能让本文更加有趣、实用。
原文出处：http://www.softwaretestinghelp.com/practical-software-testing-tips-to-test-any-application/
