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