|
1. 需求为导向原则
毫无疑问,软件测试是以客户需求为导向,只有研发出完全(或基本完全)满足客户需求的产品才能使客户掏银子,那么不是客户所需求的,即便它是个bug
,其等级也不必标得很高,甚至可以不去理会它.也就是说要求测试人员在测试之前一定要弄清楚需求是什么,围绕这个需求design case才能减少无用case
的数量,降低测试成本.(补充: 一般来说,客户的需求都是很抽象的,那么就要求我们测试人员将其细化,这就取决于测试人员个人的素质了,所以平时多积累
提高对产品的认知,才能真正提高测试能力和效率,协助开发人员提高产品的质量)
2. 及早涉入原则
按照软件开发流程,软件测试是流程里最后一步,然而事实上,软件测试人员越早涉入越好,目前好多通过cmm5的研发机构都是如此做的,其道理很简单,测试人员
越早介入,越能了解所开发的产品,从而就越能design比较有效率的case,而且大家也都知道,bug发现的阶段越早,其造成的损失越小,修改成本越低,修改已经release
的并流入市场的版本中的bug的成本,是开发期间发现并改正成本的几个数量级.测试计划可以在需求模型一完成就开始,详细的测试用例定义可以在设计模型被确定后
立即开始。因此,所有测试应该在任何代码被产生前就进行计划和设计。
3. 80/20原则
相信大家都知道这个80/20原则(恕不详叙),事实上,此原则放在软件测试也非常适合,一般来说,导致80%bug的就只有大约20%的真因,所以有时候底层模块一经改正,很多莫名
奇妙的错误就不治而愈,因此,单元测试非常重要,这个需要我们开发人员严格把关.
4. 测不完原则
看到此原则大家不要笑,事实上没有谁能标榜自己能将某软件"完全"测试一遍,特别是像我们手机的MMI测试,完全遍历一遍所设计出来的case有几万万,我都不敢想象了
所以想绝对保证产品质量是不可能的事情,但是我们可以利用等价域等思想大大缩小同一测试目的的case,在一个等价域中挑选出最典型的作为测试数据,那么就可以以
最小的测试成本达到最大可能的覆盖
5. 边界值原则
经过开发人员交到测试人员手中的软件一般都是经过开发人员初步测试过的,那么常规的数据不太可能产生问题,而软件的大多数错误都是聚集在边界上,所以只有测试人员
突破常规所选择的一些数据才有可能测出开发人员没有测出的bug,要知道,计算机的思维方式和人的思维方式是不一样的,有时候你觉得逻辑路径不可能被执行,而事实上,
它可能在正常的基础上被执行。
罗罗嗦嗦说了这么多,希望对大家有所助益,其实每个原则都应该配以几个例子来形象说明下,但限于篇幅(其实是懒得打字了)大家有什么不太明白的地方可以随时和我磋商
也希望各路高手斧正补充!! |
|