系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。从而我们可以推测系统测试基本上可以理解为功能性测试,很大程度上是黑盒子测试,提到这里我产生了一个疑问,既然是黑盒子测试,那么就跟具体的代码实现没有关系了,测试者就务须关心代码了,真的是这样吗?
我在过一年的工作中,曾有很长段时间参与系统测试,在测试过程中发现,很大部分的规程是可以不了解代码就可以完成相应的功能测试的,而且不了解代码有个好处就是一切从规格说明书或从用户角度出发进行测试,这样就不轻易偏离系统测试的意义,但是在某些场合下却不竟然了,为什么呢?打个比方,假设在新版本中有一项功能的容量发生了变化,而这个容量在实验室里根本就不具备这样的条件,在这种情况下要怎么处理呢?我们就对内部代码进行了分析,发现我们只需要在内部驻留一段模拟代码,从而达到实验室的要求,于是我们的测试成功地完成了,同时也发现这个容量的一个宏根本就没有达到向用户承诺的内容。另外在还有一种情况非常适合做模拟性的系统测试,例如:有两个子系统分别为A、B,而B是从A系统采集数据的,我们测试的是B系统,而有些数据在实验里很难构造出来,而数据是从A系统而来,我们在验证B系统的时候可在A系统驻留相应的测试代码,这样就很容易模拟了实际的数据,也同时确保了B系统所走的流程没有被打断,在这种情况下用这种方式非常有效。
从上面可知,实际上在做系统测试的时候如果了解内部的代码逻辑,对测试有时候可以达到事半功倍的效果,当然系统测试员也要充分认清自己的角色定位,不要过多地关注内部逻辑,而是以用户需求为导向。