1)学会全面地分析测试结果。当测试结果为fail的时候我们应该追根究底，找到解决问题的方法。
2)在每次测试的时候最大限度的覆盖测试范围，尽管100%的覆盖率也许不可能，但是我们在每次测试的时候试着接近这个目标。
3）为了最大限度的覆盖我们要测试的程序，可以将应用程序划分为小的功能模块。然后针对这些模块写用例，必要的时候可以在讲模块划分为更小的单元。
例如：我们已经将一个web程序做了划分，其中“接收用户信息”是其中的一个模块。为了更方便写用例你可以将这个模块再划分为更小的模块：UI 测试，安全测试，功能测试等等。
像表单测试：我们可以划分为为每一个控件进行测试。例如inputbox我们可以针对字段类型，长度进行测试，反向测试和验证测试 然后像这样最大限度的覆盖其他测试对象。
4）写测试用例的时候我们需要先根据需求写出正向的测试用例，然后在去设计一些反向的测试用例。
5）采取积极的态度。在开始测试的时候我们首先要明确我的目的是找出缺陷和错误而不是想着这个程序没有问题。如果你以找bug的心态去做测试，你肯定会发现很多微妙的bug。
6）在需求和设计阶段去写测试用例。这样可以确保所有的需求将会被测试到。
7)请确保在开发开始编码之前写好测试用例。在开发没有完成之前，我们不能一直等。我们可以思考一下如何发现更多的问题，从而不断去修改我们的测试用例。可以让开发借鉴我们的测试用例，从而提高软件产品的质量，这样也减少了一些返工的时间。
8）如果可能的话尽量去试着定义和分组你的测试用例从而让你的回归测试更加有效。
9）对于需求中提到需要注意返回时间的地方，我们应该对其进行性能测试。性能测试对于很多程序来说是非常重要的一部分。对于手工测试人员，由于缺乏发规模测试数据，使得性能测试常常被忽略掉。针对这一点，我们应该想到相应的解决方案。如果手动制造数据不可行的化，我们可以尝试写一些简单的测试脚本或是找开发的同事帮忙。
10）开发不应该测试自己写的代码。开发人员对将要发布给测试人员的产品进行基本的单元测试已经足够了。对于测试者来说不应因为推进自己的测试进度或其他原因催促开发发布要测试的产品。应该让他们根据自己的时间来决定什么时候发布。然后测试人员根据他们发布的时间，来安排测试进度。这是一个典型的敏捷开发环境。
11)超出需求的测试。应该测试一下程会有哪些不支持一规避风险。
12)在做回归测试的时候可以用借鉴之前的bug分布图，（显示不同模块bug的分布状况）。bug分布图可以预见大多数程序中可能有问题的部分。
13）测试的时候你可以记新的关系，概念。测试的时候可以打开一个text 文件，用来记录。记下测试进度，观察值。。。。。。这些数据可以帮助你写最终测试发布报告。这个习惯可以让你写即清晰有详细的发布报告。
14）通常测试人员或是开发人员在测试的时候会向那些测试版本添加一些测试代码。这是在避免执行实时事务的时候所规定的，例如银行系统。但是要注意的是，当发布的时候一定要把这些测试代码清楚掉。
15） 让开发人员尽量原理测试环境。这样可以避免任何配置在发布的版本或是文档中丢失。有的时候开发人员在测试的环境中做了系统设置，却忘记在部署的步骤中提 及。如果开发人员没有权限在测试环境中做类似的修改，他们将不会在某一时候去修改测试环境，这样丢失的配置将会被我们测试人员顺利的捕捉到。
16）一个好的惯例是让测试人员参与到软件需求和设计阶段。如果这样做的话，软件测试人员可以比较详细地了解软件的测试结果，这样有利于测试的覆盖。如果没有的话，可以向你的领导申请让你的测试组参与到所有决策程序流程的会议。
17）测试组可以同组织中其他team分享测试手法及经验。
18）增加和开发的沟通来增加你对产品的认识。及时进行面对面的交流来避免分歧和误解的发生。但是当你理解了需求或是分歧的时候，请确保通过某种书面的方式记录下来例如邮件。请不要只是口头上相互达成一致。
19）要合理安排高级别的测试任务。你的测试计划可以由高级别到低级别，并以此来安排你的工作。并分析这样安排的所有风险。
20）写出清晰，详细，没有分歧的bug报告。不要只是提供了bug的表面症状，最好也提出这个bug所有的影响 和所有可能的解决方案。
很好。
