1.测试用例包含测试文档和测试数据两部分，在实际操作之前，请先准备好测试数据，即要在界面上录入的数据，原则上是所有在界面上输入的数据都要写进测试数据（excel表）中，并注意归纳整理，每组测试数据都应有相应的测试目的。

　　2.测试数据的准备需要考虑到一定的覆盖率，但100%的覆盖是肯定做不到的。请根据测试用例文档的内容尽量达到最有效的覆盖。

　　3.测试用例并不是一成不变的，应在测试过程中随时更新、补充，不断完善。如果在测试过程中发现原测试用例有不完整甚至是错误的情况，请及时补充或修改。这一点很重要，切记。因为在此时多一分心，将来的测试工作必会少几分力。

　　4.在测试过程中发现的BUG请填写到缺陷管理工具TTP中，特别注意要将BUG情形，重现步骤等描述清楚，不要因偷懒或错别字等原因使得开发人员无法正确理解和无法重现该BUG，甚至造成歧义，以免对开发者和测试者增加许多不必要的工作量。

　　5.做好BUG的跟踪工作。测试工作并不止于发现BUG，而应对每个BUG跟踪到底。BUG自提出之后，就要一直跟踪，敦促相关人员解决。时间太长仍未解决的，要查明原因，并汇报至项目经理处。在TTP中，则体现为所有的BUG最后都要处于“closed”状态。

　　6.做好版本控制。程序源代码的版本控制工作由开发组负责，但测试组也需要管理好测试系统的版本，保持与最新程序同步，以免对不正确的版本进行测试，做无用功。

　　7.做好回归测试。开发人员修改BUG后，测试组要尽快将程序更新至测试环境，并做回归测试。此时除了验证所发现的问题是否被修正外，还要特别注意的是，此项改动是否会对系统的其它部分造成影响，从而产生新的BUG。因为有时候程序员对程序的一个不正确的，哪怕是小小的改动，都可能会对系统带来更多的BUG，而这些BUG往往又是很隐蔽的，所以要特别小心。这一点非常难做到，需要靠测试人员的经验和细心。这里有一个比较好的方法，就是要求开发人员在解决问题的同时，要详细的说明该问题产生的原因，及他对哪些源程序文件做了什么改动，填写到TTP中，越详细越好。根据我们部门以往的测试经验，我觉得这一点做得还很不够，很多程序员并不愿意做过多类似的归纳整理工作。其实这是对大家都有好处的事情，一定要请大家共同配合。

　　8.在测试过程中，如果重复的操作过多，在条件允许的情况下，可考虑使用功能测试工具winrunner,quicktestpro等来简化操作。