用好WinRunner要从两方面去做：
一是熟悉WinRunner，尤其是要熟悉其 TSL 脚本语言，这一点其实不难，完全可以做到在拿到程序之前就写好测试脚本的。
二就是要有有好的测试用例，一个好的测试用例才是一个成功的测试用例。
那么如何实现在拿到产品之前，就能写好一定的测试脚本呢？？？
一是熟悉WinRunner，尤其是要熟悉其 TSL 脚本语言，这一点其实不难，完全可以做到在拿到程序之前就写好测试脚本的。
二就是要有有好的测试用例，一个好的测试用例才是一个成功的测试用例。
那么如何实现在拿到产品之前，就能写好一定的测试脚本呢？？？
(1) 事先编写TSL测试脚本，不需要知道GUI对象的分布，只需要知道有些什么GUI对象，需要对其进行什么操作等。
(2) 通过录制+少量修改的方式得到的测试脚本只能做比较少的测试工作，通过录制得到脚本是建立在操作的流程正确的基础上的，如果本来就错了的话，录制的脚本即使回放正确，程序仍然是错误的。录制+ 简单的修改不叫自动化测试。
(3) 回归测试是自动化功能测试工具的强项，但并不表示自动化测试工具主要就是做这些地，第五代自动化测试工具已经具备了事务处理的能力，W inRunner 7.0已经支持事务处理，这是录制脚本无法达到的，必须人工编写。
(4) 我们有很多的测试人员抱怨测试收入低、不受重视等等，为什么会这样？我想，除了大环境的原因外，我们也应该从自身来找找原因。我能够发现多少错误？我对业务知识了解有多少？我对测试领域的了解有多深？我能够为公司的质量管理提供多少改进依据？我的测试流程做得有多好？为什么欧美的测试人员受到重视，收入高？除了大环境以外，众多的专家和对质量保证的贡献也是原因之一吧！
(5) 如果希望工作能够非常轻松的话，绝对不要干软件测试这一行！不管是手工测试还是自动化测试，都不是轻松的事，维护测试用例库是应该要做的事情。自动化测试的重点就是前期的测试设计和后期的结果分析，而且前期设计的时间可能是手工测试设计的数倍甚至上十倍，想轻松是不可能的！
(6) 有几种情况不要考虑做自动化测试：
a:易用性测试
b:一次性测试
c:立即测试
d:无预期结果的测试
