软件测试——系统架构

第四章系统架构

适当的应用程序的测试需要更多的不仅仅是验证模拟或重新创建用户操作。测试系统通过用户界面,不了解系统的内部结构和组件,通常被称为黑盒测试。就其本身而言,黑盒测试并不是测试的最有效方法。为了设计和实现最有效的策略，为彻底调查正确的应用程序的功能,测试团队必须有一个系统的内部一定程度的知识,比如它主要的体系结构组件。这些知识可以使测试团队设计更好的测试和执行更有效的缺陷诊断。测试一个系统或应用程序通过直接针对系统的各种模块和层被称为灰盒测试。

理解组件和系统架构，测试团队缩小其努力和专注于特定的区域或层存在一个缺陷,增加修正错误的效率。黑盒测试人员是有限的提出效应或症状的一个缺陷,因为这测试人员必须依靠错误消息或其他信息显示的界面,如“报告不能生成”黑盒测试人员也更难以识别错误的遗漏与误判。灰盒测试,另一方面,不仅看到了错误消息通过用户界面还有诊断的工具问题,可以报告缺陷的来源。理解系统架构也允许进行集中测试,针对架构等敏感领域应用程序的数据库服务器或核心计算模块。

同样重要的是,测试团队在编写需求文档的过程,如第一章所讨论的,也必须测试团队审查应用程序的体系结构。这允许团队在项目生命周期的早期识别出潜在的可测试性的问题。例如,如果一个应用程序的体系结构大量使用第三方产品,这可能使系统难以测试和诊断,因为该组织没有控制这些的源代码组件和不能修改它们。测试团队必须确定这些类型的问题在早期以允许开发的一个有效的测试策略他们考虑过于复杂的架构,比如那些利用许多松散连接的现成的产品,也会导致系统的缺陷不能容易被孤立或复制。同样,测试团队需要及早发现这些问题,以便更好的规划。

如果正确实现,系统本身可以简化为一个测试过程，在许多方面，日志和跟踪机制在开发和测试应用程序行为是非常有用的。此外,不同的操作模式,比如调试和发布模式,可以检测和诊断问题与应用程序即使它已经发行了。

第16条：了解架构和基础组件

理解应用程序的体系结构和底层组件允许测试工程师来帮助确定应用程序的各个领域

产生特定的测试结果。这种理解可以让测试人员进行灰盒测试,可以补充黑盒测试的方法。在灰盒测试,测试人员可以确定应用程序的特定部分是失败的。例如,测试工程师能够探测领域的系统更容易失败,因为他们的复杂性,或者仅仅是由于不稳定的“新”的代码。

以下是一些如何全面了解系统的例子架构可以帮助测试工程师:

•提高缺陷报告。在大多数情况下,测试过程是基于多少需求,因此有一个固定的路径通过系统。当一个错误发生时沿着这条道路,包括测试人员的能力相关的信息系统体系结构的缺陷报告对系统的开发人员很有益处。例如,如果一个确定对话框显示失败,测试人员的调查可以确定它是由于一个问题从数据库检索信息,还是这个应用程序无法连接到服务器。

•改善执行探索性测试的能力。一旦测试失败了,测试人员通常必须执行一些集中测试,也许通过修改原始测试场景来确定应用程序的“一个断裂点,”因素,导致系统崩溃。在这练习,架构了解被测系统的测试人员可以很大的帮助,使测试工程师执行和具体的测试——或者更有用或许完全跳过额外的测试,当知识的底层组件提供了足够的信息的问题。例如,如果众所周知,遇到了一个连接的应用程序数据库的问题,没有必要尝试操作不同的数据值。相反,测试人员可以专注于连接问题。

•提高测试精度。灰盒测试旨在锻炼应用程序,尽管用户界面或直接对抗底层组件,而监控内部组件的行为确定测试的成功或失败。灰箱测试因此自然产生缺陷的原因相关的信息。

下面是测试的期间最常见的可能遇到的问题类型:

o 组件遇到某种故障,导致操作被中止。用户界面通常表明一个错误发生。

o 测试执行产生不正确的结果,不同的预期的结果。在系统中,一个组件处理过的数据不正确,导致错误的结果。

o 在执行组件失败,但没有通知用户界面,出现一个错误,这被称为假积极的。例如,数据输入但不存储在数据库中,但是没有错误报告给用户。

o 系统会报告错误,但它确实有处理一切正确的测试产生错误判定。

在第一种情况下,一个错误会导致流产手术,是很重要的显示有用的和描述性的错误消息,但这通常不会发生。例如,如果数据库时发生错误操作,典型的用户界面显示一条加密的消息像“未能完成操作,”为什么没有任何细节。一个更有用的错误信息提供更多的信息,比如,“由于未能完成操作数据库错误。“在内部,应用程序也会有错误日志甚至更多的信息。知识的系统组件允许测试人员使用所有可用的工具,包括日志文件和其他监控机制,更精确地测试这个系统,而不是根据完全在用户界面消息。

有几种方法,测试团队可以理解的体系结构。也许最好的方式是为团队参与架构和设计评审,开发人员提出了建议的体系结构。在另外,测试人员应该鼓励评审架构和设计文档和开发人员的提问。同样重要的是,测试团队审查任何更改每个版本后的架构,以便任何对测试工作可以评估的影响。

第17条：验证系统支持可测试性

大多数大型系统是由许多子系统,进而由代码组成存在一个或多个层和其他支持组件,如数据库和消息队列。用户与边界交互,或者用户界面的系统,然后与其他子系统交互来完成一个任务。子系统、层和组件越多的系统,它可能在测试系统中更加难以隔离问题。

考虑下面的例子。用户界面需要来自用户的输入,利用各层的服务代码在应用程序中,最终输入到数据库中。然后,另一子系统,如报告系统,读取数据和执行一些额外的处理产生一个报告。如果有什么出错在这个过程中,可能由于用户的一个问题数据或并发问题,缺陷的位置很难隔离,并且错误可能很难再现。

当一个应用程序的体系结构第一次被概念化,测试人员应该有机会询问如何遵循输入通过一个系统内的路径。例如,如果某个函数会导致另一个服务器上任务启动,它是对测试人员验证的一种有用的方法，远程任务的确是根据需要启动。如果商议的架构很难跟踪这种交互,那么它可能是必要的考虑的方法,也许使用更可靠,可测试的,体系结构。测试策略必须考虑到这些类型的问题,和可能在某些情况下需要一个集成测试工作，员工从其他方向发展努力,包括第三方组件供应商。

测试团队必须考虑该建议的体系结构的所有方面,以及如何他们可能会或可能不会导致应用程序的有效和高效的测试。例如,尽管第三方组件,比如现成的用户界面

实行控制,可以减少开发时间,大部分的工作在架构上重要的组件,它们的使用可能有负面影响可测试性。除非源代码是开放的,可以修改难以跟随路径，通过第三方组件,它们可能无法提供跟踪或其他诊断信息。如果使用第三方组件提出了应用程序的架构,是很重要的原型实现和验证，有办法监控的控制流。通过该组件，还可以防止使用一些第三方组件测试工具,