10.2 测试中必须检查的5个并发挑战
第3章中的一些并发挑战必须在测试阶段进行检查，并在异常处理程序中进行解决。这些挑战是：
(1) 并行执行的两个或多个任务间的不正确的和不充分的通信
(2) 由两个或多个指令或任务的不安全数据更新造成的数据损坏(data corruption)
(3) 当任务和资源之间存在多对一的比例时的资源竞争
(4) 需要并行执行的单元数无法被接受
(5) 在沟通包含多处理和多线程的软件设计时缺少文档或文档不完整
第7章讨论了用于使能并同步并发执行的线程或进程间的通信、数据或设备访问的机制。例如，使用互斥量和信号量控制和防止前面列表中因为挑战2而发生的错误。使用定时互斥量控制和防止前面列表中因为挑战3中的问题而导致的错误。在许多情况下，文档受到的关注和使用的专用资源都很少，但它是软件部署中最重要的组件之一。就像所有其他事情对于并行编程(www.cppentry.com)和多线程一样，文档对于这类应用程序也变得更加关键。测试过程应当验证并确认设计文档与后期制作文档是匹配的。表10-1显示在第7章讨论过的哪些机制可以用来预防控制和预防前面列表中提到的5种挑战。
表10-1
|
信号量类型< xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /> |
描 述 |
|
互斥量信号量 |
用于在代码的临界区中实现互斥现象的机制 |
|
读写锁 |
用来在任务间实现读写访问策略的机制 |
|
条件变量 |
用来在任务间广播某事件已经发生的信号的机制；
当某个任务对事件互斥量加锁后，
它会阻塞，直到接收到广播 |
|
多条件变量 |
除包含多个事件或条件以外，与事件互斥量相同 |
表10-1中列出的是底层机制。幸运的是，使用高级组件库的特性，例如线程构建块(Threading Building Blocks，TBB)或是标准C++(www.cppentry.com)并发编程(www.cppentry.com)库，能够在测试过程当中避开一些麻烦。这些问题需要在第8章中讨论的PADL分析模型的第2层和第3层进行处理。
无论如何，我们首先需要确立一些定义。有一些词汇在测试、错误处理和容错中经常被错误地使用或被过于宽松地使用。表10-2包含本章将用到的术语的基本定义。
表10-2
|
术 语 |
定 义 |
|
缺陷(defect) |
软件或软件需求的任何方面的缺点，
它导致或可能导致发生一次或多次失效 |
|
错误(error) |
软件工程师/程序员做出的不适当的
决策，会导致软件缺陷 |
|
异常处理(exception handling) |
管理异常(程序执行中未预料到的
情况)的机制，会改变程序/软
件的正常地执行流 |
|
失效(failure) |
由故障导致软件元素的操作发生了
不可接受的背离 |
|
故障(fault) |
由于人的错误导致的软件中的缺陷，
在特定条件下运行时导致失效 |
|
容错(fault tolerance) |
使得软件能够在由故障(缺陷)导致的失
效中存活并恢复的特性，这些故障(缺陷)
是由于人的错误引入到软件当中的 |
|
可靠性(reliability) |
在特定条件下的规定时段内，软件执
行要求的功能的能力 |
由于表10-2中的一些术语，如错误、失效、故障，会以很多方式大量使用，因此我们提供了它们在本章中如何使用的简单定义。容错的一种度量方式是软件能够最小化失效的影响的程度。实现容错软件是所有工程师努力的主要目标之一。但是，容错软件同经过反复测试的软件之间的区别经常会被错误理解和模糊。有时，软件验证、软件确认与异常处理的责任和活动经常被错误地交换。为了达到使用C++(www.cppentry.com)异常处理器制帮助完成逻辑容错的软件的目的，必须首先清楚异常处理在事物发展过程中的适用情况。