|
很多组织都会遇到这样的情况：软件已经通过了专业测试人员的测试，但在提交给用户使用后仍然会出现Bug。 即使是微软、谷歌这样的软件公司也逃脱不了“漏测”的现象。 而在我们实施GJB5000的组织里，有些软件不仅进行了内部测试，而且还通过了具备测评实验室资质的测试人员的专业测试，即便这样，它们在外场实验当中依然有可能会暴露问题。 这是测试人员的水平不行吗？ 一个具备软件测评实验室资质的机构，即便有个别人的水平不行，但也肯定会有大把测试能力超强的人。漏测的根源不在于测试人员的水平，而是他们也有自己的局限性。 局限性一：业务领域的局限性 软件测试人员常常会被自己熟悉的业务领域所限制。大多数组织安排一个软件测试人员的工作，通常都会让其固定在某个业务领域中。这样做的好处是他可以对这个领域非常精通，可以提高其测试效率；但坏处却是在他熟悉了这个领域之后，他就会复用自己的测试用例，缺乏创新，导致很难发现之前没有发现的Bug。 局限性二：测试人员精力的局限性 设立专业测试人员的组织，通常都是有大量的软件需要测试。所以，这些测试人员的时间和精力都很紧张。这使得他们更愿意使用自己既往的经验来加快测试的进程，而不愿去抛弃这些经验，投入新的探索测试。 测试人员的这些局限性使得他们发现Bug的效率可能不如一个没有测试经验的路人：比如一个小白用户。 好在我们实施GJB5000的组织还有一个杀手锏，那就是系统联试。 系统联试是在软件完成了自身验证（测试）之后，交付给系统，由系统用户来验证软件在系统中是否满足使用要求。 系统联试过程中，软件的操作由系统用户进行，相比软件开发和测试人员，系统用户对软件没有那么熟悉，他会按照自己的使用习惯来使用软件，因此他也更有可能会发现软件开发和测试人员无法发现的Bug。 当然，如果系统联试仍然让软件开发人员操控软件，这个发现Bug的时机就可能会被浪费。 这正是： 测试也有局限性，漏测很难被避免 系统联试很关键，减少漏测来把关 参考书目：Google软件测试之道，作者：(美)惠特克(Whittaker，J.)，(美)阿尔邦(Arbon，J)，(美)卡罗洛(Carollo，J)，译者：黄利，李中杰，薛明，出版社：人民邮电出版社 |
|
|
