软件测试—系—统架构.docVIP

系统架构 适当的应用程序的测试需要更多的不仅仅是验证模拟或重新创建用户操作。测试系统通过用户界面,不了解系统的内部结构和组件,通常被称为黑盒测试。就其本身而言,黑盒测试并不是测试的最有效方法。为了设计和实现最有效的策略，为彻底调查正确的应用程序的功能,测试团队必须有一个系统的内部一定程度的知识,比如它主要的体系结构组件。这些知识可以使测试团队设计更好的测试和执行更有效的缺陷诊断。测试一个系统或应用程序通过直接针对系统的各种模块和层被称为灰盒测试。 理解组件和系统架构，测试团队缩小其努力和专注于特定的区域或层存在一个缺陷,增加修正错误的效率。黑盒测试人员是有限的提出效应或症状的一个缺陷,因为这测试人员必须依靠错误消息或其他信息显示的界面,如“报告不能生成”黑盒测试人员也更难以识别错误的遗漏与误判。灰盒测试,另一方面,不仅看到了错误消息通过用户界面还有诊断的工具 问题,可以报告缺陷的来源。理解系统架构也允许进行集中测试,针对架构等敏感领域应用程序的数据库服务器或核心计算模块。 同样重要的是,测试团队在编写需求文档的过程,如第一章所讨论的,也必须测试团队审查应用程序的体系结构。这允许团队在项目生命周期的早期识别出潜在的可测试性的问题。例如,如果一个应用程序的体系结构大量使用第三方产品,这可能使系统难以测试和诊断,因为该组织没有控制这些的源代码组件和不能修改它们。测试团队必须确定这些类型的问题在早期以允许开发的一个有效的测试策略他们考虑过于复杂的架构,比如那些利用许多松散连接的现成的产品,也会导致系统的缺陷不能容易被孤立或复制。同样,测试团队需要及早发现这些问题,以便更好的规划。 如果正确实现,系统本身可以简化为一个测试过程，在许多方面，日志和跟踪机制在开发和测试应用程序行为是非常有用的。此外,不同的操作模式,比如调试和发布模式,可以检测和 诊断问题与应用程序即使它已经发行了。 第16条 ：了解架构和基础组件 理解应用程序的体系结构和底层组件允许测试工程师来帮助确定应用程序的各个领域 产生特定的测试结果。这种理解可以让测试人员进行灰盒测试,可以补充黑盒测试的方法。 在灰盒测试,测试人员可以确定应用程序的特定部分是失败的。例如,测试工程师能够探测领域的系统更容易失败,因为他们的复杂性,或者仅仅是由于不稳定的“新”的代码。 以下是一些如何全面了解系统的例子架构可以帮助测试工程师: ? 提高缺陷报告。在大多数情况下,测试过程是基于多少需求,因此有一个固定的路径通过系统。当一个错误发生时沿着这条道路,包括测试人员的能力相关的信息系统体系结构的缺陷报告对系统的开发人员很有益处。例如,如果一个确定对话框显示失败,测试人员的调查可以确定它是由于一个问题从数据库检索信息,还是这个应用程序无法连接到服务器。 ? 改善执行探索性测试的能力。一旦测试失败了,测试人员通常必须执行一些集中测试,也许通过修改原始测试场景来确定应用程序的“一个断裂点,”因素,导致系统崩溃。在这练习,架构了解被测系统的测试人员可以很大的帮助,使测试工程师执行和具体的测试——或者更有用或许完全跳过额外的测试,当知识的底层组件提供了足够的信息的问题。例如,如果众所周知,遇到了一个连接的应用程序数据库的问题,没有必要尝试操作不同的数据值。相反,测试人员可以专注于连接问题。 ? 提高测试精度。灰盒测试旨在锻炼应用程序,尽管用户界面或直接对抗底层组件,而监控内部组件的行为确定测试的成功或失败。灰箱测试因此自然产生缺陷的原因相关的信息。 下面是测试的期间最常见的可能遇到的问题类型: o 组件遇到某种故障,导致操作被中止。用户界面通常表明一个错误发生。 o 测试执行产生不正确的结果,不同的预期的结果。在系统中,一个组件处理过的数据不 正确,导致错误的结果。 o 在执行组件失败,但没有通知用户界面,出现一个错误,这被称为假积极的。例如,数据输入但不存储在数据库中,但是没有错误报告给用户。 o 系统会报告错误,但它确实有处理一切正确的测试产生错误判定。 在第一种情况下,一个错误会导致流产手术,是很重要的显示有用的和描述性的错误消息,但这通常不会发生。例如,如果数据库时发生错误操作,典型的用户界面显示一条加密的消息像“未能完成操作,”为什么没有任何细节。一个更有用的错误信息提供更多的信息,比如,“由于未能完成操作数据库错误。“在内部,应用程序也会有错误日志甚至更多的信息。知识的系统组件允许测试人员使用所有可用的工具,包括日志文件和其他监控机制,更精确地测试这个系统,而不是根据完全在用户界面消息。 有几种方法,测试团队可以理解的体系结构。也许最好的方式是为团队参与架构和设计评审,开发人员