软件测试的新模型(3)

　　因此，模型必须允许利用不同来源的综合信息进行个别的测试设计。另外，模型还应该允许在新的信息来源出现后重新进行测试的设计。

　　一个不同的模型

　　让我们来看本文的第二项内容，一个不同的模型。

　　很多时候人们把代码移交给其他人，并且说：“希望你能接受和喜欢它。”这不仅发生在将整个项目放在一张光盘中交给客户的时候，也发生在项目内部。

　　例如，一个小组对另一个小组说：“我们已经完成了为COMM库加入了对XML的支持。源代码现在已经放在master库中，可执行库则已经加入到集成与创建的环境中。XARG小组的工作已经没有什么阻碍了，随时去取吧。”

　　某个程序员检查了bug的修改并且发出邮件：“我已经修改了Bug列表中的那个Bug，很抱歉!”至此，早先受该问题影响的其它代码就可以继续处理了。

　　在这些情况下，人们要把代码移交给其它人，其中有可能会存在一些影响。测试人员需要干预这个过程。在移交之前，测试人员应执行这些代码，发现其中的 bug(影响)，并且提出问题：“你确实要提交这些吗?”由此，移交的内容可能会被延期，直到bug被修复好。

　　尽管你还要做其它的各种测试，这项测试仍然是很基本的测试工作。如果你没有做这样的测试，就不能算是合格的测试人员。

　　我们的测试模型必须包含这一重要的现实需要：针对代码移交的测试。由此，测试模型应提示进行针对每一次代码移交的测试。

　　就让我以支持XML的COMM库作为例子。这里存在着一个小组把代码移交给XARG小组以进行项目的余下部分。那么谁会遭受影响?

　　要将这些支持XML的代码直接进行使用的XARG小组可能会立即受到影响;

　　这可能会在稍后影响到市场人员，他们要在一个行业展示会议上为“合作伙伴发行”版本提供产品演示和宣传，而XML支持是影响他们销售的重要部分;

　　还有，它可能损害采纳我们的产品的合作伙伴。

　　现在我们可以提出一些有趣的关于测试计划的问题了。最简单的可以做的事情是，在移交的时候立即执行XML支持的完整测试。(“完整”的含义是，为此设计尽可能多的测试)但也许一些XML特性并不是XARG小组所需要的，因此可以把它们放在合作伙伴版本封版(下图中的“Partner Release”)的测试中去。这意味着可以把一些XML相关测试放到稍后的移交过程中去。或者基于其它理由，例如在近阶段有其它的测试任务要执行。而 XARG小组则要因XML中的bug修复而延迟一小段时间。

　　我们的测试计划所表示的进度可以通过在开发的时间线上进行注解的方式来表现，如下图所示：

　　(图9：添加在开发计划之上的测试计划)

　　我们应严格地围绕在XML支持的功能交接的时段里进行测试。测试设计和测试支持工作要早于测试执行。而另外的XML测试则要延迟到基于整个项目范围的“代码完成”(图中的“Code Complete”里程碑)，或者要等到全部的子系统被集中在一起，而且整个产品为了行业会议而在经过稳定化处理后创建了版本(图中的“Partner Release”里程碑)。

　　显然，有两项内容没有包含在代码完成里程碑中：

　　还有大量其它的测试工作(包括设计、工具选用)。这些工作可能因为COMM以外的子系统的交接而延期。

　　而且，还有用于完成里程碑中所规定的某些风险的测试，例如，可能还有一组用于运行市场人员的演示Demo脚本的测试，包括她可能在无意中引起的偏离。其目的是要避免这样的情况，即当她站在1000人的观众面前时，她还仅仅是第一次以某种特定的顺序来输入数据。

　　一些首次交接时进行的XML测试需要在代码完成里程碑上再次执行。

　　我的观点是，测试计划是由很多困难的决定所组成，这些决定包括人员组织安排、机器资源配置、测试设计的时间定位、测试支持代码的数量、哪些测试要做自动化，等等。这些决定应根据单独的交接中的内容信息来作出。如果仅有一次交接，那么你可以更顺利一些。测试计划还应继续考虑以下问题：

　　1. 风险分析，谁会因此受到损害，以什么方式?

　　2. 选定一种测试途径来定位特定的风险。

原文转自：http://www.uml.org.cn/Test/test47.htm