|
文章介绍:
micahel提出了这样一个问题:我们测试人员需要去自己设计很多用例,独立去做测试吗?他认为最好的方式是让别人比如开发人员来做这些工作,或者说是帮助开发人员做好单元测试,这样集成测试和系统测试需要考虑的东西就大大减少了。
skinapi注:
1、我很赞成micahel的观点,测试的工作是一种做事情的方式,其目的都是为了能帮助生产出高质量的软件产品出来,只要能达到这个目的,采用什么方式并不重要。
2、关于单元测试、集成测试、系统测试,比较容易出现的状况是它们完全被孤立开来,其实只有它们三者更好的结合在一起,才能进行效率更高的测试,因为如果都是孤立考虑,肯定会有大量的重复测试出现。所以如果我们能够帮助开发人员做好单元测试,集成测试以及系统测试的工作量将会大大降低,测试的效率也会大大提高。
链接请见:
http://blogs.msdn.com/micahel/ar ... esterHasToTest.aspx
Sometimes the right test to write is no test at all.
One of my features is clipboard support - cut-copy-paste for all of Sparkle. In my initial test case brainstorming session I came up with 450 test cases - and that was just for the mainline path! Adding in edge cases and the other conditions I ignored will easily push me over one thousand test cases.
Even if I had no other features to test and no other work to do, the chances are very low that I can complete that many test cases by the time they are needed. With some judicious triaging I trimmed my mainline tests in half. Oh boy - now I only have five hundred-ish test cases to write rather than a thousand-ish! That's eminently...
Not achievable either.
So what's a tester to do? My job, in perhaps the best way possible: by getting other people to do it.
Dev needs to write many of these tests anyway, to ensure their code is working correctly before they check it in. So I work with them as they write their unit tests. On the Test front, each tester knows best how their areas should respond to a cut/copy/paste. So I pair with them to write those test cases. Which leaves me maybe a few exit scenarios to write, plus of course general banging on clipboard stuff.
So it's not so much whether this tester has to test but rather how many other people this tester can con into helping get to help him! <g/> |
|