鉴于项目组以及整个Team的自动化测试现状,我在我们Team内部的一次Share会议上分享了我对于有效自动化测试策略的一些看法,可能观点相较于其他同事,比较极端,但是我的初衷其实是想给大家敲个警钟,不要小欲则安,浅尝辄止,我们应该保持对自动化,敏捷,以及持续集成的不断追求,在保证质量的同时提高效率。
因此对于什么样的自动化测试才是有效的,我强调首先第一点,我们要确保我们的自动化case对我们的项目有用
相信这一点,绝大多数人都是认同的,但是我这里把它又拎出来是因为,知道是一回事,但是有没有照着做又是另外一回事。要说做自动化,大家都做,都愿意做,但是我们做的真正对我们的项目有用嘛?下面是我罗列的三条标准:
● 要确信你的自动化case是有价值的,可以代替你的手动测试
自动化测试,尤其是功能性,基于User Story的case,多数是对手动case的Cover,也就是说代替手动case的。所以说我们必须确信我们的case是有价值的,可以代替我们去执行相应的手动case。至于什么是有价值的自动化case,我们相信应该是这样的:在一定的环境中执行过了自动化case,我们就相信,在这个环境中,我们没必要再进行同样的手动操作。
至于如何写出有价值的case,当然也有其策略和方法,这里不再提及。
● 在测试环境中的执行才更有价值的
上条说道,在一定的环境中去执行case,那这个一定的环境是什么样的环境呢?这里我的观点可能比较极端,我认为写case的环境,是我们的开发环境,并不是我们理想中的测试环境。
那什么才是测试环境呢?答案就是,我们自己定义的,并且专门用于测试的环境。这个环境的所有情形都是Expected,或者是可枚举的。比如说装什么系统,装什么相关软件,如何跑我们的case,这都应该是定义好的。这样的环境才是测试环境。
也许有人会对我这里定义的测试环境持反对意见,认为这样的环境并不是用户真实使用的环境,我们应该在更复杂的环境中去执行自动化测试,以期找到更多的bug。但是我认为自动化测试的目的就是做Regression Testing,以期有效的功能测试和版本控制。自动化测试并不能代替手动case,它应该是一个增量式的过程,我们不要期望让自动化发现更多的bug,而应该不断的添加,丰富各种自动化case,以及Bug Verification,以解放测试人员,让其更关注于测试本身。
● 能持续集成的运行了,才算我们的自动化测试跑起来了
这条算是锦上添花型的,持续集成是业界非常好的经验总结,不光适用于我们测试,实际上她应该是适用于整个项目的。要想做到持续集成我们有很多的开源工具可以选择,这条是大力提倡的。
第二点,我们要拥抱任何有意义的变化
这一点非常重要,这个是观念上的转变。很多时候,公司,领导花了大价钱,大精力,来让我们做自动化,而且我们也通过现有的,或者是买来的工具,也确实做了自动化。但是更多时候总会因为这样或者那样的原因,啥项目周期短啊,需求总是变动啊,导致我们的case这条挂了,那条跑不起来了,修了再修,最后测试人员也烦了,自然的,自动化case最终也束之高阁,日久生尘。
但是这里我仍然强调,我们要拥抱任何有意义的变化,这是观念上的转变。为了做出更好的产品,需求在变,代码也跟着变,我们的case在变,自动化case又有何理由不变呢?如果因为需求的变动导致我们自动化case挂了,我们应该高兴才是,因为我们的case成功的侦测到了这个变动,它是有价值的。换句话说,如果需求都变了,而我们的case还跑的好好的,那我可就要怀疑你的case到底有没有价值喽?!
拥抱任何有意义的变动,不是说创建稳定性好的自动化case就没有意义了。试想如果因为一个蚁穴,就导致我们的自动化大堤全线崩溃,那自动化的工作量可就如山高,如海深喽,那又谈何敏捷呢?!
第三点,至于如何做自动化,我想说,Just Coding!
虽然测试自动化可能并不如开发那么高深,但是我觉得我们不要自己潜意识当中就把自己限制的死死的,“我就是个测试,我肯定不如开发”,这样的观点是不对的。尤其现在公司推行的Scrum模式,其理想状态是不分DEV和QA的,大家都是敏捷模式的一员,工作甚至也是可以互相交换的。
当然,现阶段无可否认,DEV的开发水平会更高一些,但是对于我们QA,尤其是做开源领域比如Android的测试,做自动化的终极解决方案其实就是阅读产品代码,当我们读懂了开发代码,那写测试case就不是问题了。
Conclusion
所以我最终的的建议就是:Just Coding,Just Do It!只有真正去做了,你才会发现问题,才会想到去解决问题,才会想到要总结一些方法,然后让我们的Case在测试环境中自由的跑起来!
原文转自:http://www.blogjava.net/qileilove/archive/2013/05/16/399340.html