与简明测试用例对应的是轻量化的测试环境。原来的测试,动辄都要搭建起被测设备和大大小小的辅助测试环境。CSIT测试用例中,通过等价类的分析,抽象出更小规模的和更有针对性的测试环境,实践中整体硬件需求不足SIT/SVT的一半,在硬件资源分外紧张的项目初期,在这样轻量化的测试环境中开展测试是非常必要而且不得不做的。
由于测试活动介入更早,软件缺陷往往以更小的颗粒度被发现,而不是隐藏到到后面多个缺陷共同形成一个更大的故障,所以CSIT发现的缺陷数量很多。
另外,幵发和测试人员间紧密的配合,一般都能使缺陷得到快速的发现和解决,若要完整地记录缺陷,往往比发现和解决缺陷的时间更长。所以,在开发人员和测试通过直接的沟通,完全了解缺陷内容的前提下,CSIT釆用的是简明的缺陷和故障调查描述,在不同于SIT/SVT的独立的缺陷管理库中,定义简化的缺陷记录流程,以轻量化缺陷的管理。这样既能记录每一个发现的缺陷,又能减轻开发和测试人员文本描述的工作量,实践者都觉得效率远胜于原有SIT/SVT的缺陷记录方法。
5. 4. CSIT的核心測试活动
以某软件特性为例,虚拟团队由一名系统工程师,驱动层/控制层/应用层软件开发工程师各一名,CSIT测试工程师一名组成。CSIT计划阶段,虚拟团队成员之间通过讨论,定义出某软件特性如下表所示,各列的即代表某软件特性的若干子功能。各行分别表示软件的不同层代码,X为底层驱动层代码,Y为中间控制层代码,Z为上层应用层代码。如子功能A由A.X, A.Y和A.Z三部分代码组成,A.X代表子功能A的驱动彳^码,A.Y代表子功能A的控制层代码,A.Z代表子功能A的应用层代码。
一般来说子功能都需要三个软件层都支持,才能完成整个子功能,而且上层的代码往往都以底层的代码为基础。例如,驱动层可以直接控制硬件,但如果控制层也想要硬件动作就必须通过驱动层实现。但也有某些子功能不需要所有三个软件层的支持。NONE说明子功能在某软件层无需代码,如子功能C只需要驱动层代码C.X即可以实现,而子功能D仅需要驱动层和控制层支持,而不需要应用软件。
在原有项目规划的基础上,按照某软件特性的子功能划分,考虑到不同子功能的优先级和复杂程度,进一步细化出软件的第#周发布的交付计划如下。为什么说这个计划是一个好计划?因为这是一个组织成员内部共同制定的,大家都认可和接受的计划。
考虑到上层软件对底层软件的依赖关系,采用自下而上的逐步幵展的CSIT,低一级的CSIT为上一级的准备条件。首先对最底层的驱动层开展CSIT,然后是控制层,最后进行应用层的CSIT。例如,制定子功能A的CSIT计划,需要根据软件进展,可计划至多三轮次的CSIT: A.X, A.X+A.Y, A.X+A.Y+A.Z。当然,如果驱动层和控制层同时交付了,直接测试A.X+A.Y即可。如果各个层次的软件进展协调得更好的话,可以同时几乎交付三个软件层,则对A.X+A.Y+A.Z进行一次CSIT也可以。对于只需要部分软件层支持的子功能,则自然可以计划更少次数的CSIT。
但是不开展单独的CSIT并不意味着忽略各层软件内部的运转机制。而是在很大程度上,能够利用同一个外部激励,测试到各层软件的内部响应。也就是说测试内容并没有减少,但测试效率更高。
另外,CSIT的计划原则只适用于一般规模的子功能,对于功能复杂且不易继续拆分的子功能B,还是优先测试底层软件的健壮性B.X,再持续地集成上层软件(B.X+B.Y),然后(B.X+B.Y+B.Z),开展多次和持续的CSIT。对于有多重依赖关系的复杂子功能H,要提前完成其底层多个代码片段H.X1和H.X2的CSIT,以免影响后面 H.(X1+X2+Y)的 CSIT 进度。
根据某软件特性的子功能交付计划,制定CSIT的第#周交付计划如下表所示。CSIT的计划并并不像传统SIT/SVT的计划是那样一成不变的,而是随着软件开发的进展而动态变化的。例如,在CSIT中发现了软件特性D的严重缺陷而重新设计,导致研发进度整体延迟2周。CSIT也马上做出动态的调整延迟D的CSIT,并提前开展了代码片段E.Y和H1.X的CSIT测试,其他测试进度顺延。对最复杂的软件特性H的延期,CSIT不得不延期开展,进而增加了与SIT并行的时间,同时给SIT发布代码片段延期交付预警。
虽然最终此软件特性并没能完全如期交付给SIT,但部分代码片段的延期并没有阻断整个SIT的开展,对项目进度影响甚微。而且经过CSIT测试过的软件版本,明显更加稳定,大大降低了 SIT/SVT遭遇阻断性缺陷的风险。
5.5 CSIT的其他测试活动
子功能的发布并不是传统意义上的正式发布,而仅仅是在每日构建的基础上,开发人员指定某版本为某子功能的测试版本,测试人员则以此为据幵展CSIT。实践中开发人员发布版本的同时,还会给测试人员做若干子功能演示和测试建议。
