软件测试——系统架构

第四章系统架构适当的应用程序的测试需要更多的不仅仅是验证模拟或重新创建用户操作。

测试系统通过用户界面,不了解系统的内部结构和组件,通常被称为黑盒测试。

就其本身而言,黑盒测试并不是测试的最有效方法。

为了设计和实现最有效的策略，为彻底调查正确的应用程序的功能,测试团队必须有一个系统的内部一定程度的知识,比如它主要的体系结构组件。

这些知识可以使测试团队设计更好的测试和执行更有效的缺陷诊断。

测试一个系统或应用程序通过直接针对系统的各种模块和层被称为灰盒测试。

理解组件和系统架构，测试团队缩小其努力和专注于特定的区域或层存在一个缺陷,增加修正错误的效率。

黑盒测试人员是有限的提出效应或症状的一个缺陷,因为这测试人员必须依靠错误消息或其他信息显示的界面,如“报告不能生成”黑盒测试人员也更难以识别错误的遗漏与误判。

灰盒测试,另一方面,不仅看到了错误消息通过用户界面还有诊断的工具问题,可以报告缺陷的来源。

理解系统架构也允许进行集中测试,针对架构等敏感领域应用程序的数据库服务器或核心计算模块。

同样重要的是,测试团队在编写需求文档的过程,如第一章所讨论的,也必须测试团队审查应用程序的体系结构。

这允许团队在项目生命周期的早期识别出潜在的可测试性的问题。

例如,如果一个应用程序的体系结构大量使用第三方产品,这可能使系统难以测试和诊断,因为该组织没有控制这些的源代码组件和不能修改它们。

测试团队必须确定这些类型的问题在早期以允许开发的一个有效的测试策略他们考虑过于复杂的架构,比如那些利用许多松散连接的现成的产品,也会导致系统的缺陷不能容易被孤立或复制。

同样,测试团队需要及早发现这些问题,以便更好的规划。

如果正确实现,系统本身可以简化为一个测试过程，在许多方面，日志和跟踪机制在开发和测试应用程序行为是非常有用的。

此外,不同的操作模式,比如调试和发布模式,可以检测和诊断问题与应用程序即使它已经发行了。

第16条：了解架构和基础组件理解应用程序的体系结构和底层组件允许测试工程师来帮助确定应用程序的各个领域产生特定的测试结果。

这种理解可以让测试人员进行灰盒测试,可以补充黑盒测试的方法。

在灰盒测试,测试人员可以确定应用程序的特定部分是失败的。

例如,测试工程师能够探测领域的系统更容易失败,因为他们的复杂性,或者仅仅是由于不稳定的“新”的代码。

以下是一些如何全面了解系统的例子架构可以帮助测试工程师:•提高缺陷报告。

在大多数情况下,测试过程是基于多少需求,因此有一个固定的路径通过系统。

当一个错误发生时沿着这条道路,包括测试人员的能力相关的信息系统体系结构的缺陷报告对系统的开发人员很有益处。

例如,如果一个确定对话框显示失败,测试人员的调查可以确定它是由于一个问题从数据库检索信息,还是这个应用程序无法连接到服务器。

•改善执行探索性测试的能力。

一旦测试失败了,测试人员通常必须执行一些集中测试,也许通过修改原始测试场景来确定应用程序的“一个断裂点,”因素,导致系统崩溃。

在这练习,架构了解被测系统的测试人员可以很大的帮助,使测试工程师执行和具体的测试——或者更有用或许完全跳过额外的测试,当知识的底层组件提供了足够的信息的问题。

例如,如果众所周知,遇到了一个连接的应用程序数据库的问题,没有必要尝试操作不同的数据值。

相反,测试人员可以专注于连接问题。

•提高测试精度。

灰盒测试旨在锻炼应用程序,尽管用户界面或直接对抗底层组件,而监控内部组件的行为确定测试的成功或失败。

灰箱测试因此自然产生缺陷的原因相关的信息。

下面是测试的期间最常见的可能遇到的问题类型:o 组件遇到某种故障,导致操作被中止。

用户界面通常表明一个错误发生。

o 测试执行产生不正确的结果,不同的预期的结果。

在系统中,一个组件处理过的数据不正确,导致错误的结果。

o 在执行组件失败,但没有通知用户界面,出现一个错误,这被称为假积极的。

例如,数据输入但不存储在数据库中,但是没有错误报告给用户。

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

在第一种情况下,一个错误会导致流产手术,是很重要的显示有用的和描述性的错误消息,但这通常不会发生。

例如,如果数据库时发生错误操作,典型的用户界面显示一条加密的消息像“未能完成操作,”为什么没有任何细节。

一个更有用的错误信息提供更多的信息,比如,“由于未能完成操作数据库错误。

“在内部,应用程序也会有错误日志甚至更多的信息。

知识的系统组件允许测试人员使用所有可用的工具,包括日志文件和其他监控机制,更精确地测试这个系统,而不是根据完全在用户界面消息。

有几种方法,测试团队可以理解的体系结构。

也许最好的方式是为团队参与架构和设计评审,开发人员提出了建议的体系结构。

在另外,测试人员应该鼓励评审架构和设计文档和开发人员的提问。

同样重要的是,测试团队审查任何更改每个版本后的架构,以便任何对测试工作可以评估的影响。

第17条：验证系统支持可测试性大多数大型系统是由许多子系统,进而由代码组成存在一个或多个层和其他支持组件,如数据库和消息队列。

用户与边界交互,或者用户界面的系统,然后与其他子系统交互来完成一个任务。

子系统、层和组件越多的系统,它可能在测试系统中更加难以隔离问题。

考虑下面的例子。

用户界面需要来自用户的输入,利用各层的服务代码在应用程序中,最终输入到数据库中。

然后,另一子系统,如报告系统,读取数据和执行一些额外的处理产生一个报告。

如果有什么出错在这个过程中,可能由于用户的一个问题数据或并发问题,缺陷的位置很难隔离,并且错误可能很难再现。

当一个应用程序的体系结构第一次被概念化,测试人员应该有机会询问如何遵循输入通过一个系统内的路径。

例如,如果某个函数会导致另一个服务器上任务启动,它是对测试人员验证的一种有用的方法，远程任务的确是根据需要启动。

如果商议的架构很难跟踪这种交互,那么它可能是必要的考虑的方法,也许使用更可靠,可测试的,体系结构。

测试策略必须考虑到这些类型的问题,和可能在某些情况下需要一个集成测试工作，员工从其他方向发展努力,包括第三方组件供应商。

测试团队必须考虑该建议的体系结构的所有方面,以及如何他们可能会或可能不会导致应用程序的有效和高效的测试。

例如,尽管第三方组件,比如现成的用户界面实行控制,可以减少开发时间,大部分的工作在架构上重要的组件,它们的使用可能有负面影响可测试性。

除非源代码是开放的,可以修改难以跟随路径，通过第三方组件,它们可能无法提供跟踪或其他诊断信息。

如果使用第三方组件提出了应用程序的架构,是很重要的原型实现和验证，有办法监控的控制流。

通过该组件，还可以防止使用一些第三方组件测试工具,进而可能影响到测试工作。

调查的可测试性，虽然它只存在于应用程序的架构页可以大大减少测试可能后来会遇到惊。

如果测试体系结构的一个或多个方面的影响，不清楚,测试团队应该坚持一个原型,它允许测试人员尝试各种各样的测试技术。

从这个练习可以确保反馈应用程序开发的方式可以验证它的质量。

第18条：使用日志来增加系统的可测试性最常见的方法之一,提高应用程序的可测试性实现日志记录,或跟踪机制,提供信息组件,包括它们的数据操作,应用程序状态或运行应用程序时遇到的错误。

测试工程师可以使用这些信息来跟踪处理流程中执行测试程序,确定错误发生在系统的哪部分。

当应用程序执行时,所有组件写日志条目详细说明什么方法(也称为函数),他们正在执行和专业他们操纵对象。

条目通常写入磁盘文件或数据库,正确格式进行分析和调试在将来的某个时候,在一个或多个测试过程的执行。

在一个复杂的客户端-服务器或网络系统,日志文件可能写在几个机器,所以它是很重要的日志包含足够的信息来确定之间的执行路径机器。

跟踪机制必须足够的信息写入日志是有用的分析和调试,但与其说它创建一个的信息压倒性的和无用的信息,很难分离重要的条目。

日志条目只是一个格式化的消息,其中包含关键信息在分析过程中使用。

一个格式良好的日志条目包括以下部分信息:•类名和方法名称。

这是一个如果函数是函数名没有任何类的成员。

这些信息对于确定通过几个组件执行路径非常重要。

•主机名和进程ID。

这将允许日志条目比较跟踪,如果他们是来自事件在不同的机器上或生成的不同的过程在同一台机器上。

•时间戳的条目(毫秒或更好)。

一个准确的时间戳在所有条目允许相关的事件,如果他们发生平行或在不同的机器上,这可能会导致他们进入的注销的序列。

•消息。

最重要的一个部分条目的信息。

这是一个描述,由开发人员写的,当时发生了什么应用程序。

消息也可以遇到一个错误的描述在执行期间,或从一个操作结果代码。

其他类型的消息包括持久化实体的记录id或主要的钥匙域对象。

这允许通过系统跟踪的对象执行测试过程。

通过回顾项目写入日志文件的每一个方法或函数系统中的组件,可以认识到测试的执行过程系统和与数据库中的数据(如适用)操作。

在严重故障的情况下,日志记录显示负责任组件。

在计算误差的情况下,日志文件中列出的所有组件参与测试的执行过程,和id或密钥使用的所有实体。

随着实体数据从数据库,这应该有足够的信息来允许开发人员隔离的错误源代码。

下面是一个日志记录的检索客户对象从数据库的示例应用程序:Function: main (main.cpp, line 100)Machine: testsrvr (PID=2201)Timestamp: 1/10/2002 20:26:54.721Message: connecting to database [dbserver1,customer_db]Function: main (main.cpp, line 125)Machine: testsrvr (PID=2201)Timestamp: 1/10/2002 20:26:56.153 Message: successfully connected to database [dbserver1, customer_db]Function: retrieveCustomer (customer.cpp line 20)Machine: testsrvr (PID=2201)Timestamp: 1/10/2002 20:26:56.568Message: attempting to retrieve customer recordfor customer ID [A1000723]Function: retrieveCustomer (customer.cpp line 25)Machine: testsrvr (PID=2201)Timestamp: 1/10/2002 20:26:57.12Message: ERROR: failed to retrieve customer record,message [customer record for ID A1000723not found]这个日志文件摘录展示了几个主要方面的应用日志记录,可用于有效的测试。