10.4  如何对并行程序实现缺陷排除

首先，我们应指出测试应当伴随SDLC中每个主要活动，从需求收集活动到软件维护活动。但是，涉及多线程或多处理的程序在测试阶段需要进行更多的工作。因此，需要在测试计划中利用PADL分析和PBS分解。将并行程序的测试目标分解为回答3个基本问题：

(1) 设计模型和PBS能正确并完全地表示解决方案模型吗(假定解决方案模型能够解决最初的问题)？

(2) 实现模型正确地映射到设计模型(PADL的第4层和第5层)和PBS了吗？

(3) 实现模型中所有的并发挑战都得到解决了吗？

传统上，测试并行程序的大部分工作是用在回答第3个问题。这通常发生在命令式、自底向上的并行编程(www.cppentry.com)方法中。然而在声明式方法中，首先需要回答第一个问题。这是最重要的测试。如果这个测试失败，就没有理由去继续执行任何进一步的测试。第8章已经给出了这些模型的简单版本，但是在发布的代码中，这些模型应当包含大量的细节。如果设计模型足够详细准确、PBS是完整的，而且它们都能准确地映射到最初的解决问题中，这样就处于良好的状态中。软件应用程序的可扩缩性或演化的机会是由应用程序架构和并发底层结构所决定的。在回答第一个问题的过程中，我们测试了两者的质量。如果第二个问题的答案是肯定的，那么该应用程序是可靠的。因此，尽管传统上认为对问题3的回答是最重要的，但此时它的重要性要次于问题1和问题2的回答。标准软件工程测试技术被用来回答这些问题。我们只需要使用PADL和PBS来明确表达这3个基本问题。测试将验证应用程序符合PADL和PBS。

为搞清楚上述工作原理，可以查看标准测试阶段前面的处理流程。

10.4.1  问题陈述

回忆第8章中对游戏场景的精化：我的忠实助手已经交给我一个6字符编码。编码中的字符可以重复出现。然而，编码只可包含数字0～9和字符a～z。您的任务是猜测助手给了我什么编码。在游戏中，设定蜂鸣器两分钟后响起。如果您在两分钟内猜到了该编码，那么您就赢了。如果我的忠实助手确定您在15秒的时间间隔中做了超出N次的不正确猜测，那么他会交给我新的编码，并保证该编码位于您已经做过的猜测之中。