测试,不应该只是肤浅的~~

code defect是要靠手测出来的

上一篇 / 下一篇  2007-02-14 09:21:44

很多人都喜欢亲近代码。不错一个会coding的tester发展空间更加大。但是这并不意味着一个会coding的tester就一定是一个好的tester。我想一个好的tester所需具备的条件不仅仅需要有编码技能,更要有开放人员所不及的敏感。这不是今天想到然后说一说就能够实现的。需要长时间的经验积累和培养。但让人感到欣慰的是,越不容易掌握的技能含金量往往越高。

拿微软的测试来说,自动化测试涵盖了80%~90%。到了后期sp1版本测试阶段,基本上就是每天一个新的软件build,然后反复修改自动化测试代码,跑自动化测试。当测试代码的错误率低于既定的百分比后,再针对sp1阶段所发现的code defect(软件缺陷)写新的testcase加入到自动化测试代码库里,再不断的跑测试,出新build,直到产品发布。

那么对于现阶段的tester来说,每天的主要任务就是看自动化测试代码,debugging.虽然在测试脚本里发现的代码错误同样会被当作bug来报入product studio(微软的bug管理系统)。但是它们毕竟是脚本错误。可以提高测试的效率,是不能改善产品本身的质量的。到了sp1阶段除非回归测试发现修改产品代码后的错误(事实上这也就是为什么需要耗费如此大的人力物力来写测试代码的原因,保证每天的新build没有回归错误),通过testcase来发现许多新的产品bug几乎是不现实的。这个时候要发现新的bug惟有通过手动来试。说白了,就是玩转产品。首先需要理解软件的每一个功能和流程。在此基础上针对每一个软件功能提出质疑,做试验。这个时候确实需要天马行空的创造力。所不同的是,软件tester的创新必须要基于一定的规则。对产品理解的越深,就越容易找出问题。


TAG:

 

评分:0

我来说两句

日历

« 2024-03-29  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 7886
  • 日志数: 10
  • 建立时间: 2006-12-15
  • 更新时间: 2009-10-24

RSS订阅

Open Toolbar