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