软件测试-系统架构

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

・提高测试精度。灰盒测试旨在锻炼应用程序，尽管用户界面或直接对抗底层组件,而监控内部组件的行为确定测试的成功或失败。灰箱测试因此自然产生缺陷的原因相关的信息。下面是测试的期间最常见的可能遇到的问题类型：o组件遇到某种故障，导致操作被中止。用户界面通常表明一个错误发生。o测试执行产生不正确的结果，不同的预期的结果。在系统中，一个组件处理过的数据不正确，导致错误的结果。o在执行组件失败，但没有通知用户界面,出现一个错误，这被称为假积极的。例如，数据输入但不存储在数据库中,但是没有错误报告给用户。o系统会报告错误,但它确实有处理一切正确的测试产生错误判定。在第一种情况下，一个错误会导致流产手术，是很重要的显示有用的和描述性的错误消息，但这通常不会发生。例如，如果数据库时发生错误操作，典型的用户界面显示一条加密的消息像“未能完成操作，”为什么没有任何细节。一个更有用的错误信息提供更多的信息，比如，“由于未能完成操作数据库错误。“在内部，应用程序也会有错误日志甚至更多的信息。知识的系统组件允许测试人员使用所有可用的工具,包括日志文件和其他监控机制，更精确地测试这个系统,而不是根据完全在用户界面消息。有几种方法，测试团队可以理解的体系结构。也许最好的方式是为团队参与架构和设计评审，开发人员提出了建议的体系结构。在另外，测试人员应该鼓励评审架构和设计文档和开发人员的提问。同样重要的是，测试团队审查任何更改每个版本后的架构,以便任何对测试工作可以评估的影响。第17条：验证系统支持可测试性大多数大型系统是由许多子系统，进而由代码组成存在一个或多个层和其他支持组件，如数据库和消息队列。用户与边界交互,或者用户界面的系统，然后与其他子系统交互来完成一个任务。子系统、层和组件越多的系统,它可能在测试系统中更加难以隔离问题。考虑下面的例子。用户界面需要来自用户的输入，利用各层的服务代码在应用程序中，最终输入到数据库中。然后，另一子系统，如报告系统，读取数据和执行一些额外的处理产生一个报告。如果有什么出错在这个过程中，可能由于用户的一个问题数据或并发问题,缺陷的位置很难隔离，并且错误可能很难再现。当一个应用程序的体系结构第一次被概念化,测试人员应该有机会询问如何遵循输入通过一个系统内的路径。例如，如果某个函数会导致另一个服务器上任务启动，它是对测试人员验证的一种有用的方法，远程任务的确是根据需要启动。如果商议的架构很难跟踪这种交互,那么它可能是必要的考虑的方法，也许使用更可靠,可测试的，体系结构。测试策略必须考虑到这些类型的问题，和可能在某些情况下需要一个集成测试工作,员工从其他方向发展努力，包括第三方组件供应商。测试团队必须考虑该建议的体系结构的所有方面，以及如何他们可能会或可能不会导致应用程序的有效和高效的测试。例如，尽管第三方组件,比如现成的用户界面实行控制,可以减少开发时间,大部分的工作在架构上重要的组件，它们的使用可能有负面影响可测试性。除非源代码是开放的，可以修改难以跟随路径，通过第三方组件,它们可能无法提供跟踪或其他诊断信息。如果使用第三方组件提出了应用程序的架构，是很重要的原型实现和验证，有办法监控的控制流。通过该组件，还可以防止使用一些第三方组件测试工具

进而可能影响到测试工作。调查的可测试性，虽然它只存在于应用程序的架构页可以大大减少测试可能后来会遇到惊。如果测试体系结构的一个或多个方面的影响，不清楚,测试团队应该坚持一个原型，它允许测试人员尝试各种各样的测试技术。从这个练习可以确保反馈应用程序开发的方式可以验证它的质量。第18条：使用日志来增加系统的可测试性最常见的方法之一，提高应用程序的可测试性实现日志记录，或跟踪机制，提供信息组件，包括它们的数据操作，应用程序状态或运行应用程序时遇到的错误。测试工程师可以使用这些信息来跟踪处理流程中执行测试程序，确定错误发生在系统的哪部分。当应用程序执行时，所有组件写日志条目详细说明什么方法（也称为函数），他们正在执行和专业他们操纵对象。条目通常写入磁盘文件或数据库，正确格式进行分析和调试在将来的某个时候，在一个或多个测试过程的执行。在一个复杂的客户端-服务器或网络系统，日志文件可能写在几个机器,所以它是很重要的日志包含足够的信息来确定之间的执行路径机右器。跟踪机制必须足够的信息写入日志是有用的分析和调试，但与其说它创建一个的信息压倒性的和无用的信息，很难分离重要的条目。日志条目只是一个格式化的消息，其中包含关键信息在分析过程中使用。一个格式良好的日志条目包括以下部分信息：・类名和方法名称。这是一个如果函数是函数名没有任何类的成员。这些信息对于确定通过几个组件执行路径非常重要。・主机名和进程ID。这将允许日志条目比较跟踪，如果他们是来自事件在不同的机器上或生成的不同的过程在同一台机器上。・时间戳的条目（毫秒或更好）。一个准确的时间戳在所有条目允许相关的事件，如果他们发生平行或在不同的机器上，这可能会导致他们进入的注销的序列。・消息。最重要的一个部分条目的信息。这是一个描述由开发人员写的，当时发生了什么应用程序。消息也可以遇到一个错误的描述在执行期间，或从一个操作结果代码。其他类型的消息包括持久化实体的记录id或主要的钥匙域对象。这允许通过系统跟踪的对象执行测试过程。通过回顾项目写入日志文件的每一个方法或函数系统中的组件，可以认识到测试的执行过程系统和与数据库中的数据（如适用）操作。在严重故障的情况下，日志记录显示负责任组件。在计算误差的情况下，日志文件中列出的所有组件参与测试的执行过程，和id或密钥使用的所有实体。随着实体数据从数据库，这应该有足够的信息来允许开发人员隔离的错误源代码。下面是一个日志记录的检索客户对象从数据库的示例应用程序：Function:main（main.cpp，line100）Machine:testsrvr（PID=2201）Timestamp:1/10/200220:26:54.721Message:connectingtodatabase[dbserver1，customer_db]

Function:main(main.cpp,line125)Machine:testsrvr(PID=2201)Timestamp:1/10/200220:26:56.153Message:successfullyconnectedtodatabase[dbserverl,customer_db]Function:retrieveCustomer(customer.cppline20)Machine:testsrvr(PID=2201)Timestamp:1/10/200220:26:56.568Message:attemptingtoretrievecustomerrecordforcustomerID[A1000723]Function:retrieveCustomer(customer.cppline25)Machine:testsrvr(PID=2201)Timestamp:1/10/200220:26:57.12Message:ERROR:failedtoretrievecustomerrecord,message[customerrecordforIDA1000723notfound]这个日志文件摘录展示了几个主要方面的应用日志记录可用于有效的测试。显示每个条目的函数名，文件名和运行生成的应用程序源代码的数量的条目。主机和进程ID也记录以及条目时。每一个消息包含有用的信息关于组件的身份参与在活动。例如，数据库服务器是“dbserver1,”数据库“customer_db”，客户ID“A1000723。”从这个日志,很明显，应用程序不能够成功地检索指定的客户记录。在这种情况下，测试人员可以检查数据库dbserver1,使用SQL工具,查询的customer_db数据库客户记录IDA1000723来验证。这一信息将大量缺陷诊断功能添加到测试工作，测试人员可以通过这样的详细信息开发人员作为缺陷报告的一部分。测试人员不仅可以报告“症状”，但也内部应用程序的行为，确定了的原因问题。第19条：验证系统支持调试和发布执行模式虽然软件系统正在建设中，但显然将会很多故障。问题可能随时呈现在开发人员测试,特别是在单元测试和集成测试阶段和正式测试的测试团队。当缺陷被发现时，必须有一种方法来诊断问题,最好是没有任何修改应用程序本身。为了使这个过程高效,应用程序必须支持不同的操作模式，尤其是一个调试模式来帮助开发人员和测试人员诊断问题遇到，释放模式，剥夺了一个优化版本的系统大多数或所有的debugging-related特性。应用程序通常是在发布模式下送到最终用户。根据语言、工具和平台参与应用程序的发展，有几种方法可以调试。・源代码检查。如果问题不是很复杂,一个视觉检查源代码可能不足以确定问题。对于实例，

如果一个不正确的标题栏出现在应用程序窗口，开发人员可以在源代码中寻找的定义窗口的标题栏文本，并相应地改变它。・日志输出。如果应用程序有一个日志记录机制，如前所述第18条，开发人员可以运行应用程序时，重现错误，然后检查生成的日志条目。更好的是,测试人员在缺陷报告提供了一个日志文件摘录。如果摘录包含足够的信息对于开发人员确定问题的原因,这个缺陷可以在源代码中纠正。否则，开发人员可能需要考虑的另一个调试技术。・实时调试。在这个最强大的调试技术，开发人员“高度”调试器应用程序的运行实例，和监视变量和程序流程的调试环境直接与应用程序进行交互。缺陷被执行重建在一个缺陷报告的步骤，应用程序代码检查时运行来确定缺陷的来源。这些技术的使用由开发人员，但是中的信息缺陷报告通常使一种方法明显。例如，如果这个问题是一个简单的整形问题，快速检查通常是所有的源代码必要的。更深层次的、更复杂的问题通常需要实时调试。然而，实时调试并不总是可能的。在C++中，例如，真正的-调试需要时间调试系统的构建。（调试代码还执行许多补充检查，如检查堆栈和堆损毁当系统正在开发中。）正如前面所提到的，开发环境可以“附加”应用程序的调试版本当它运行时，允许开发人员监控代码，同时进行交互与应用程序。因此可能是应用程序的行为和变量彻底检查,有时正确诊断和正确的唯一途径缺陷。此外，应用程序的调试版本问题more-verbose信息遇到的问题对内存和其他低级别的系统功能。例如，当低级错误或意想不到的条件（断言）遇到在应用程序运行时,它通常会显示一个对话框中描述的问题，因为它发生。这样的低级，诊断消息并不意味着终端用户,通常不会被显示通过一个版本构建的系统;相反，如果有一个问题，系统简单的崩溃或表现出不可预知的行为。一旦系统准备好船，需要禁用或删除调试特性。在一些语言中，这包括重建系统。这是必要的因为调试特性，如日志，通常导致较慢的性能和更高的内存使用情况，排气系统资源，如磁盘空间,如果离开了无人值守。此外，过多的日志可以通过可能带来安全风险公开信息系统入侵者。因为它是可能的，当建在一个应用程序可能出现新的缺陷释放模式，它是重要的测试团队意识到构建模式测试。在大多数情况下，只有开发人员应该和调试工作构建,测试团队应该和制定版本发布工作。这将确保发布的软件构建系统的版本,将会送到客户一一接收适当的关注。日志机制也必须考虑发布构建的系统。可以从应用程序中删除的记录机制少，或者,最好是,配置日志记录或根本没有。尽管它似乎所有的日志应该从应用程序的发布版本,可以有相当大的价值留下某种形式的日志吗启用。当一个可配置的日志记录机制是在生产应用程序的版本,仍然可以有效地诊断即使缺陷应用程序已经在使用。缺陷发现的客户可能会重现诊断为日志文件的帮助，不仅仅是一个更可靠的方法试图重现问题依靠用户的输入和错误消息在应用程序的用户界面。应用程序的日志记录机制可以通过使用可配置的配置文件，它指定的日志记录级别。一个简单的日志记录系统将有两个水平，错误和调试信息。在应用程序的代码,将会与每个日志条目相关联，以及配置文件指定的日志级别。一般来说，唯一的错误登录发布模式，而错误和调试语句都是登录调试模式。下面的伪代码演示了在每个