模拟攻击试验是安全性测试方法之一，以下不属于模拟攻击试验的是（）。

测试应用程序的体系结构和设计可以消除很多与设计有关的漏洞，从而提高应用程序的整体安全性。设计时修复漏洞要比在开发后期解决问题更为简单，也更经济，因为开发后期可能要进行大量的重新工程处理。开发时如果考虑一些与目标部署环境相关的设计以及该环境定义的安全策略，可确保应用程序的部署更加平稳和安全。如果应用程序已创建完毕，安全测试可修复漏洞并完善未来的设计。

一个完整的Web安全体系测试可以从部署与基础结构、输入验证、身份验证、授权、配置管理、敏感数据、会话管理、加密、参数操作、异常管理、审核和日志记录等几个方面入手。

安全体系测试

部署与基础结构

检验底层网络和主机基础结构提供给应用程序的安全设置，然后检验运行环境要求的所有限制。此外，考虑部署的拓扑结构以及中间层应用程序服务器、外围区域以及内部防火墙对设计的影响。检验下列问题，确定可能存在的部署和基础结构问题。

. 网络是否提供了安全的通信。

数据在客户端与服务器（或服务器与服务器）之间传输时最易受到攻击。网络负责数据传输的完整性和私密性。如果必须保证数据安全，可使用适当的加密算法。此外，还必须确保网络设备安全。因为这是维护网络完整性所必需的。

. 部署拓扑结构是否包括内部防火墙。

如果内部防火墙将Web服务器与应用程序服务器（或数据库服务器）分隔开来，则需要考虑下列问题，确保设计能适应这种配置。

①下游服务器如何验证Web服务器的身份；

②如果使用域账户和Windows身份验证，防火墙是否打开了必要的端口；

③是否使用分布式事务；

④如果Web服务器使用DTC（Microsoft Distributed Transaction Coordinator）的服务来启动分布式事务，内部防火墙是否为DTC通信打开了必要的端口。

. 部署拓扑结构中是否包括远程应用程序服务器。

如果部署拓扑结构包括了一个物理远程中间层，则需要考虑下列问题。

①是否使用企业服务。如果是，是否已限制了DCOM端口范围，内部防火墙是否打开了这些端口。

②是否使用．NET远程处理。

③远程处理用在受信服务器方案中，网络是否支持IPSec策略。

④ASP.NET承载远程组件是否支持身份验证和授权。

⑤是否使用Web服务，如果是，中间层Web服务如何验证Web应用程序的身份。Web应用程序是否通过在Web服务代理中配置凭据来使Web服务验证Web服务器的身份，如果否，Web服务如何明确调用者。

. 基础结构安全性要求的限制是什么。

设计是否假定主机基础结构安全限制要失效。例如，安全限制可能要求根据所需的服务、协议或账户特权来对设计进行权衡。需要考虑下列问题。

①是否依赖可能不可用的服务或协议。开发和测试环境中可用的服务和协议可能在生产环境中不可用。

②是否依赖敏感的账户特权。设计应尽量使用特权最少的进程、服务和用户账户。

③要执行的操作是否要求可能不被许可的敏感特权。例如，应用程序是否要创建线程级模拟令牌来创建资源访问的服务身份。这项操作要求“作为操作系统的一部分”特权，而该特权不应授予Web服务器进程（因为可能增加进程被利用的风险）。如果需要此功能，设计应对更高级别的特权进行划分，例如，在进程外的企业服务应用程序中。

. 目标环境支持怎样的信任级别。

运行环境的代码访问安全信任级别决定了代码可访问的资源，以及它能执行的特权操作。请检查运行环境支持的信任级别。如果允许Web应用程序以完全信任级别运行，代码将能够访问操作系统安全性许可的任何资源。

如果Web应用程序必须以受限信任级别运行，则代码能访问的资源类型以及能执行的特权操作都将受到一定的限制。在部分信任案例中，设计应对特权代码进行沙盒（sandboxing）处理。此外，还应使用不同的程序集来分隔特权代码。这样，可以对特权代码和应用程序的其余部分单独配置特权代码，然后授予必要的附加代码访问权限。

注意：如果应用程序部署在共享服务器（或应用程序将由宿主公司运行），信任级别通常是个问题。此时，需要检查安全策略，然后确定Web应用程序的信任级别。

输入验证

需要对应用程序验证输入内容的方式进行检验，因为很多Web应用程序攻击都故意使用格式错误的输入。SQL注入、跨站点脚本（XSS）、缓冲区溢出、代码注入以及无数其他拒绝服务和特权提升攻击都可利用输入验证中的漏洞。下表中重点列出了常见的输入验证漏洞。

常见的输入验证漏洞

测试时应考虑下列问题，以帮助发现潜在的输入验证安全问题。

. 如何验证输入。

设计指定的输入验证方法是什么？首先，设计必须展示策略。应用程序应对收到的所有输入进行约束、拒绝和净化。约束输入是最佳的方法，因为针对已知有效类型、模式和范围对数据进行验证，要比通过查找已知坏字符来验证数据简单得多。

测试时应考虑下列问题，帮助识别潜在的漏洞。

①是否清楚入口点。

确保设计标出了应用程序的入口点，以便跟踪各个输入字段的操作。可考虑Web页输入、输入到组件和Web服务，以及从数据库输入。

②是否清楚信任边界。

如果输入是从信任边界内受信源传递的，并非总要验证输入；但如果输入是从不受信任的源传递的，必须验证输入。

③是否验证Web页输入。

不要将最终用户看作受信任的数据源。确保对正常和隐藏的表单字段、查询字符串和cookie都进行验证。

④是否对传递到组件或Web服务的参数进行验证。

如果不进行验证，惟一的安全条件就是数据接收自当前信任边界之内。但是，如果使用深层防御策略，则需要使用多层验证。

⑤是否验证从数据库中检索的数据。

这种形式的输入也应验证，特别是当其他应用程序也写入该数据库时。不要对其他应用程序的数据验证程度进行假设。

⑥是否将方法集中起来。

对于相同类型的输入字段类型，检验使用的是否是相同的验证和筛选库，确保一致地执行验证规则。

⑦是否依赖客户端的验证。

客户端验证可用于降低到服务器的回程数量，但不能依靠它来维护安全性，因为它很容易被忽略。需要在服务器验证所有的输入。

. 如何处理输入。

检查应用程序处理输入的方式，不同类型的处理可能导致不同类型的漏洞。例如，如果在SQL查询中使用输入，应用程序可能易受SQL注入的攻击。

测试中考虑下列问题，帮助发现潜在的漏洞。

①应用程序是否易受规范化问题的影响。

检查应用程序是否使用基于输入的名称来制定安全决策。例如，应用程序是否接受用户名、文件名或URL。由于名称的表示方法多种多样，以上各项都极易造成规范化错误问题。如果应用程序接受输入作为名称，则应确保对它们进行验证并在处理之前将它们转换为规范的表示法。

②应用程序是否易受SQL注入攻击。

密切注意形成SQL数据库查询的所有输入字段。确保对这些字段的类型、格式、长度和范围进行正确的验证。此外，检查查询的生成方式。如果使用参数化的存储过程，输入参数将被当作文本，而不会当作可执行代码。这是降低风险的一种有效措施。

③应用程序是否易受XSS攻击。

如果在HTML输出流中包括输入字段，可能受到XSS攻击。确保对输入进行验证，并对输出进行编码。密切注意系统对接受一定范围HTML字符的输入字段的处理方法。

身份验证

检查应用程序验证调用者身份的方法，在何处使用身份验证，如何确保凭据在存储中或通过网络传递的安全。身份验证中的漏洞可能导致应用程序易受哄骗攻击、词典攻击、会话劫持等。下表重点列出了常见的身份验证漏洞。

常见的身份验证漏洞

测试中需要考虑下列问题，确定在应用程序进行身份验证的方法中的潜在漏洞。

. 是否区分公共访问和受限访问。

如果应用程序既有不要求身份验证的公共区域，也有要求身份验证的受限区域，检查站点设计区分二者的方法。必须为受限的页和资源使用单独的子文件夹，然后在IIS中将它们配置为要求SSL来确保安全。这种方法允许只在需要的地方使用SSL来确保敏感数据和身法验证cookie的安全性，从而避免了因在整个站点中使用SSL而造成的附加性能负担。

. 是否明确服务账户要求。

设计应明确连接不同资源（包括数据库、目录服务和其他类型的网络资源）的服务账户范围。设计中不能使用单个的、有高度特权的账户（有足够的权限连接多种不同类型的资源）。

①设计是否要求特权最少的账户。

检查设计并准确标识各账户执行特定功能所需的特权，然后在任何情况下都使用特权最少的账户。

②应用程序是否要维护服务账户凭据。

如果是，确保加密这些凭据，然后保存在受限的位置中。例如，保存在有受限访问控制列表（ACL）的注册表项。

. 如何验证调用者身份。

测试时考虑与调用者身份验证相关的下列事项。具体事项由设计中使用的身份验证类型决定。

①是否在网络中传递明文凭据。如果使用表单或基本身份验证（或使用Web服务并在SOAP头中传递凭据），确保使用SSL来保护传输中的凭据。

②是否实现自己的用户存储。如果是，检查用户凭据的存储位置和存储方式。一种常见错误是将明文或加密密码保存在用户存储中。实际上，必须保存密码的哈希值来进行身份验证。

如果根据SQL Server用户存储验证凭据，密切注意用户名和密码的输入。检查是否存在恶意注入的SQL字符。

③是否使用表单身份验证。如果是，除使用SSL保护凭据外，还应使用SSL来保护身份验证cookie。此外，还要检查设计是否使用受限的会话生存期来抵御cookie重播攻击，并确保加密cookie。

. 如何验证数据库的身份。

如果应用程序要连接数据库，检查使用的身份验证机制、打算使用的账户（一个或多个），以及如何在数据库中授权应用程序。

明确下列问题有助于对数据库身份验证进行评价。

①是否使用SQL身份验证。

在理想情况下，设计使用Windows身份验证来连接SQL Server，因为这种方法本身更加安全。如果使用SQL身份验证，检查在网络中和数据库连接字符串中确保凭据安全的方法。

如果网络基础结构不提供IPSec加密通道，确保在数据库中安装服务器证书来提供自动SQL凭据加密。此外，还要检验确保数据库连接字符串安全的方法，因为这些字符串中包含SQL账户的用户名和密码。

②是否使用进程账户。

如果使用应用程序的进程账户并使用Windows身份验证连接SQL服务器，应在设计中使用特权最少的账户。本地ASP.NET账户便是为此提供的，尽管对于本地账户来说，用户需要在数据库服务器上创建一个相同的账户。

如果打算使用域账户，首先确保它是特权最少的账户，然后打开相关的端口来确保所有相关防火墙都支持Windows身份验证。

③是否使用服务账户。

如果设计要求使用多个身份来支持数据库中的高粒度授权，则需要检查保存账户凭据（在理想情况下，这些凭据使用数据保护API（DPAPI）加密并保存在安全注册表项中）的方法，以及使用服务身份的方法。

此外，还要检查使用哪些进程通过该服务账户创建模拟的安全上下文。该操作不应由Microsoft Windows 2000中的ASP.NET应用程序进程来完成，因为它将强制提升进程账户的特权，并授予“作为操作系统的一部分”特权。这种情况必须尽量避免，它将大大增加风险。

④是否考虑使用匿名Internet用户身份。

对于使用表单或Passport身份验证的应用程序而言，可为各个程序配置单独的匿名用户账户。然后，启用模拟并使用匿名身份来访问数据库。该方法适于对同一服务器的不同应用程序进行单独的授权和身份跟踪。

⑤是否使用原始用户身份。

如果设计要求模拟原始调用者，必须考虑该方法是否能提供足够的伸缩性，因为连接池是无效的。另一种备选方法是，通过受信的查询参数在应用程序级流动原始调用者身份。

⑥如何保存数据库连接字符串。

如果数据库连接字符串硬编码，或以明文形式保存在配置文件或COM+目录中，则很容易受到攻击。实际上，应加密它们，然后限制对加密数据的访问。

. 是否强制使用强账户管理措施。

如果应用程序使用Windows身份验证，Windows安全策略将强制使用强密码、受限登录和其他最佳账户管理策略。其他情况，则由应用程序层负责这些措施。测试要考虑与应用程序账户管理相关的下列问题。

①应用程序是否强制使用强密码。

例如，ASP.NET Web页是否使用正则表达式来验证密码复杂性规则。

②是否限制失败登录的次数。

这样做有助于对抗词典攻击。

③是否在故障发生后公开过多的信息。

确保不显示类似“不正确的密码”这样的消息，因为它将告诉恶意用户：用户名是正确的。结果，恶意用户便可集中精力破解密码。

④是否强制定期更改密码。

如果不强制定期更改密码，用户极有可能不更改自己的密码，结果风险更高。

⑤是否能在泄露发生时迅速禁用账户。

如果账户泄露，是否能方便地禁用账户来防止攻击者继续使用账户。

⑥应用程序是否记录登录企图。

记录失败的登录企图是检测攻击者试图侵入的有效方法。

授权

检查应用程序是如何向用户授权的。还要检验应用程序在数据库中是如何被授权的，以及如何控制系统级资源的访问。授权中的漏洞可能导致信息泄漏、数据篡改及特权提升。使用深层防御策略是一种重要的方法，它可应用于应用程序的授权策略中。下表重点列出了常见的授权漏洞。

常见的授权漏洞

测试中需要考虑下列问题，帮助验证应用程序设计的授权策略。

. 如何向最终用户授权。

应在设计时从两种角度考虑授权。首先，考虑最终用户授权。哪些用户可访问哪些资源，并执行哪些操作。其次，如何防止恶意用户使用应用程序访问系统级资源。考虑下列问题，验证应用程序的授权策略。

①是否使用深层防御策略。

确保设计不依赖于单个网关守卫来加强访问控制。考虑该网关守卫失败（或攻击者设法忽略它）时发生的情况。

②使用了哪些网关守卫。

可能的选择有IISWeb权限、NTFS权限、ASP.NET文件授权（仅适用于Windows身份验证）、URL授权和用户权限请求。如果不使用某个特定类型，需要明确不使用的理由。

③是否使用基于角色的方法。

如果是，如何维护角色列表，维护角色列表所需的管理界面安全性如何。

④角色是否提供足够的特权隔离。

设计是否提供了适当的粒度，使不同用户角色的关联特权得到充分的隔离。避免出现仅为满足特定用户需要而授予角色较高特权的情况。

. 如何在数据库中授权应用程序。

在应用程序中连接数据库的账户必须有受限的能力，只需满足应用程序的要求即可，不要再高了。

应用程序是否使用存储过程来访问数据库呢？建议应用程序使用存储过程来访问数据库，因为一般用户只能授予应用程序登录访问特定存储过程的权限。可以限制登录不在数据库中直接执行创建/读取/更新/删除（CRUD）操作。

. 如何将访问限定于系统级资源。

设计应用程序时，应考虑应用程序在可访问系统级资源方面的限制。只能授予应用程序访问最低限度的资源。这是缓解风险的一种策略，可在应用程序遭受攻击时限制受损程度。考虑下列问题。

①设计是否使用代码访问安全性。

代码访问安全性提供了一种资源约束模型，该模型可防止代码（和Web应用程序）访问特定类型的系统级资源。如果使用代码访问安全性，设计必将受到影响。明确是否在设计规划中包括代码访问安全性，然后通过对特权代码进行隔离和沙盒处理（sandboxing），并将资源访问代码置于自己独立的程序集中，从而进行相应的设计。

②应用程序使用哪些身份。

设计必须明确应用程序使用的所有身份，包括进程身份和所有模拟身份（包括匿名Internet用户账户和服务身份）。此外，设计还要指出这些身份要访问的资源。

在部署时，可对系统级资源配置正确的ACL，确保应用程序的身份只能访问所需的资源。

配置管理

如果应用程序提供了可配置的管理界面，要检查确保管理界面安全的方法。此外，还要检查如何确保敏感配置数据的安全。下表显示了常见的配置管理漏洞。

常见的配置管理漏洞

测试时考虑下列问题，帮助验证应用程序设计在配置管理方面的方法。

. 是否支持远程管理。

如果设计指定了远程管理，必须确保管理界面和配置存储的安全，因为这些操作本身非常敏感，而且通过管理界面访问的数据也很敏感。考虑与远程管理设计相关的下列问题。

①是否使用强身份验证。

必须要求对所有管理界面用户进行身份验证。使用强身份验证，如Windows或客户端证书身份验证。

②是否加密网络通信数据。

使用经过加密的信道，如IPSec或虚拟专用网络（VPN）连接提供的通道。不支持不安全通道中的远程管理。IPSec允许对可用来管理服务器的客户计算机的身份和数量进行限制。

. 是否保证配置存储的安全。

明确应用程序的配置存储，然后检查限制访问这些存储的方法，以及确保存储中数据安全的方法。

①配置存储是否在Web空间中。

对于保存在Web空间文件中的配置数据，其安全性要低于保存在Web空间之外的数据。主机配置错误或未发现的Bug都可能导致攻击者通过HTTP检索，并下载配置文件。

②配置存储中的数据是否安全。

确保在存储中加密关键的配置数据项（如数据库连接字符串、加密密钥和服务账户凭据）。

③如何限制对配置存储的访问。

确保管理界面提供必要的授权，只有经过验证的管理员才可访问并操作这些数据。

. 是否隔离管理员特权。

如果管理界面支持不同的功能（如站点内容更新，服务账户重新配置和数据库连接详细信息），要确认管理界面支持基于角色的授权，从而区分内容开发人员和操作员或系统管理员。例如，不必许可更新静态Web站点的人改变客户的信用额度或重新配置数据库连接字符串。

敏感数据

检查应用程序对存储中、应用程序内存中以及网络中的敏感数据的处理方法。下表显示了与处理敏感数据相关的常见漏洞。

敏感数据处理中的常见漏洞

测试中要考虑下列问题，帮助验证应用程序处理敏感数据的方法。

. 是否存储机密信息。

机密信息包括了应用程序的配置数据，如账户密码和加密密钥。如果可能，明确其他避免保存机密信息的设计方法。如果要处理机密信息，由系统平台处理它们，尽可能不在应用程序中承担这一任务。如果确实要保存机密信息，则要考虑下列问题。

①是否能避免存储机密信息。

如果使用其他的实施技术，是否能避免存储机密信息。例如，如果只需了解用户是否知道密码，则无需存储密码。或者，仅保存单向的密码哈希值。

此外，如果使用Windows身份验证，可通过嵌套凭据来避免存储连接字符串。

②如何存储机密信息。

如果使用加密，如何确保加密密钥的安全。考虑使用系统平台提供的DPAPI加密，这种加密能替用户完成密钥管理。

③在何处保存机密信息。

检查应用程序保存加密数据的方法。要获得尽可能高的安全性，应使用Windows ACL限制对加密数据的访问。确认应用程序不以明文或源代码形式存储机密信息。

如果使用本地安全机构（LSA），检索机密信息的代码必须使用管理员特权才可以运行，这将增加风险。另一种不要求扩展特权的方法是使用DPAPI。

④如何处理机密信息。

检验应用程序访问机密信息的方法，以及它们以明文形式存留在内存中的时间。机密信息通常应根据需要检索，并尽快使用，然后丢弃。

⑤是否在cookie中存储机密信息。

如果是，应确保cookie是加密的，且不会永久保存在客户计算机中。

. 如何存储敏感数据。

如果存储了敏感的应用程序数据（如客户信用卡详细信息），检查数据保护方法。

①使用怎样的加密算法。

应使用强加密算法来加密。例如，使用较长的密钥（如Triple DES）。

②如何确保加密密钥的安全性。

数据的安全性与加密密钥安全性同等重要。因此，检查确保密钥安全的方法。在理想状况下，使用DPAPI加密密钥并保存在受限位置（如注册表项中）来确保安全。

. 是否在网络中传递敏感数据。

如果通过网络传递敏感数据，应确保通过应用程序加密这些数据，或通过加密的通信链接来传递它们。

. 是否记录敏感数据。

检查应用程序（或主机）是否在明文日志文件中记录用户账户密码这样的敏感数据。通常，必须避免这样做。确保应用程序不在查询字符串中传递敏感数据，因为查询字符串会被记录，并可在客户端浏览器地址栏中直接看到。

会话管理

由于Web应用程序基于无状态的HTTP协议生成，因此会话管理是应用程序级任务。检查应用程序的会话管理方法，因为它将直接影响应用程序的整体安整。下表显示了与会话管理相关的常见漏洞。

常见的会话管理漏洞

测试中需要考虑下列问题，帮助验证应用程序处理敏感数据的方法。

. 如何交换会话标识符。

检查应用程序管理用户会话的会话标识符，以及这些会话标识符的交换方式。考虑下列问题。

①是否通过未加密的通道传递会话标识符。

如果使用会话标识符（如cookie中包含的令牌）跟踪会话状态，检查是否仅通过加密的通道（如SSL）传递标识符或cookie。

②是否加密会话cookie。

如果使用表单身份验证，确保应用程序使用“”元素中的protection="All"属性加密身份验证。建议同时使用SSL和这种方法，以便降低XSS攻击的风险，XSS攻击可设法窃取用户的身份验证cookie。

③是否在查询字符串中传递会话标识符。

确保应用程序不在查询字符串中传递会话标识符。这些字符串可在客户端轻易修改，使用户能作为另一用户访问应用程序，访问其他用户的私有数据，并可能提升特权。

. 是否限制会话生存期。

检查应用程序认为会话标识符有效的时间。应用程序应限制这段时间的长度，以降低会话劫持和重播攻击的威胁。

. 如何确保会话状态存储的安全。

检查应用程序存储会话状态的方法。会话状态可存储在Web应用程序进程、ASP.NET会话状态服务，或SQL Server状态存储中。如果使用远程状态存储，请确保Web服务器到该远程存储的链接使用IPSec或SSL加密，以保护在网络中传输的数据。

加密

如果应用程序使用加密来提供安全性，检查加密的内容以及加密的使用方法。下表显示了与加密有关的常见漏洞。

常见的加密漏洞

测试中需要考虑下列问题，帮助验证应用程序处理敏感数据的方法。

. 为何使用特定的算法。

加密只有在正确使用时才能提供真正的安全保障。不同作业使用不同的算法。算法的程度也非常重要。考虑下列问题，评价所使用的加密算法。

①是否开发自己的加密技术。

不应开发自己的加密技术。众所周知，加密算法和例程的开发非常难，而且很难成功。自定义实施的安全保护一般很弱，基本上不如久经考验的系统平台服务提供的安全措施。

②是否使用合适的密钥大小来应用正确的算法。

检查应用程序使用的算法及使用该算法的目的。较大的密钥可提供较高的安全性，但会影响性能。对于在数据存储中长时间保存的永久数据，较强的加密非常重要。

. 如何确保加密密钥的安全性。

加密数据的安全与密钥的安全同等重要。要破解加密数据，攻击者必须能检索出密钥和密码文本。因此，需要检查设计，确保加密密钥和加密数据的安全。考虑下列评价问题。

①如何确保加密密钥的安全。

如果使用DPAPI，将由系统平台为用户管理密钥。其他情况下，则由应用程序负责密钥管理。检查应用程序确保加密密钥安全的方法。一种较好的方法是，使用DPAPI加密其他加密形式所需的加密密钥。然后，安全地保存加密密钥，例如，将其放在配置了受限ACL的注册表项目下。

②回收密钥的频率如何。

不能滥用密钥。同一密钥使用的时间越长，被发现的可能性就越高。设计是否考虑了怎样回收密钥、回收的频率，以及如何将它们分发并安置在服务器中。

参数操作

检查应用程序使用参数的方法。这些参数包括了在客户端和服务器间传递的表单字段、查询字符串、cookie、HTTP头和视图状态。如果使用像查询字符串这样的参数传递敏感数据（如会话标识符），恶意客户端可轻松使用简单的参数操作逃避服务器端检查。下表显示了常见的参数操作漏洞。

常见的参数操作漏洞

测试中需要考虑下列问题，以帮助确保您的设计不受参数操作攻击影响。

. 是否验证所有的输入参数。

确保应用程序验证所有的输入参数，包括正常和隐藏的表单字段、查询字符串和cookie。

. 是否在参数中传递敏感数据。

如果应用程序在参数（如查询字符串或表单字段）中传递敏感数据，应检查应用程序使用这种方法而不是更安全的方法（传递会话标识符）的原因。例如，在加密的cookie中传递会话标识符。使用这些信息将会话与在服务器状态存储中维护的用户状态相关联。考虑下列评价问题。

①是否加密包含敏感数据的cookie。

如果应用程序使用包含敏感数据的cookie，如用户名或角色列表，确保它是经过加密的。

②是否在查询字符串或表单字段中传递敏感数据。

不能这样做，因为就操作查询字符串或表单字段中的数据而言，没有简便的方法可用。实际操作过程中，应考虑使用加密的会话标识符，然后将敏感数据保存在服务器的会话状态存储中。

③是否保护视图状态。

如果Web页或控件使用视图状态在HTTP请求之间维持状态，确保视图状态经过加密，并使用消息验证代码（MAC）检查其完整性。用户可在计算机级配置该设置，也可按页配置。

. 是否为了安全问题而使用HTTP头数据。

确保Web应用程序不根据HTTP头中的信息制定安全决策，因为攻击者可轻松地操作头数据。不要依赖HTTP引用站点字段的值来检查源于页的请求是否由Web应用程序生成，这将带来漏洞。这种操作本身很不安全，因为引用站点字段可在客户端轻松更改。

异常管理

检查应用程序处理错误的方法。应前后一致地使用结构化的异常处理。同样，确保应用程序不在发生异常时公开太多信息。下表显示了两大异常管理漏洞。

常见的异常管理漏洞

测试时应考虑下列问题，以确保设计不易受到异常管理安全漏洞的影响。

. 是否使用结构化的异常处理。

检查应用程序如何使用结构化的异常处理。设计应强制在整个应用程序中使用一致的结构化异常处理。这将创建更强大的应用程序，使应用程序不易处在暴露安全漏洞的不一致状态下。

. 是否向客户端公开了太多的信息。

确保恶意用户无法利用错误信息中的细节信息，考虑下列问题。

①是否在服务器中捕获、处理和日志记录异常。

确保应用程序不会将内部异常情况传播到应用程序边界以外。异常应在服务器中捕获并记录日志。如果必要，应向客户端返回常规错误信息。

②是否使用集中的异常管理系统。

在应用程序中一致处理并日志记录异常的最佳方法是，使用正式的异常处理系统。还可将该系统与操作组监视系统性能的监控系统相结合。

③是否定义了一组自定义错误信息。

设计必须明确，应用程序在发生严重错误时使用自定义的错误信息。确保这些消息中不包含任何可能被恶意用户利用的敏感数据。

审核和日志记录

检查应用程序的审核和日志记录方法。除了防止抵赖之外，定期分析日志文件有助于识别入侵迹象。下表显示了常见的审核和日志记录漏洞。

常见的审核和日志记录漏洞

测试中需要考虑下列问题，帮助验证应用程序审核和日志记录的方法。

. 是否明确了要审核的关键活动。

设计必须定义要审核的活动。考虑下列问题：

①是否审核失败的登录尝试。

这允许用户检测入侵和密码破解企图。

②是否审核其他关键操作。

确保审核其他关键事件，包括数据检索、网络通信和管理功能（如启用和禁用日志记录）。

. 是否考虑过如何流动原始调用者身份。

设计必须确保跨多个应用程序层来进行审核活动。为此，原始调用者的身份必须在每个层都可用。

①是否跨应用程序层进行审核。

检验每个层是否都按预期计划对活动进行审核。

②如何同步多个日志。

日志文件是证明个人犯罪行为和解决抵赖问题的法律程序所必需的。通常，在访问资源的时候，如果由访问资源的同一例程生成审核，则审核最具权威性。确认应用程序设计中与日志文件同步相关的问题，然后记录某种形式的请求标识符，确保多个日志文件条目可互相关联，并能关联至同一请求。

③如何流动原始调用者身份。

如果不在操作系统级流动原始调用者身份（例如，由于此方法伸缩性有限），应明确应用程序如何流动原始调用者身份。对于跨层审核，这是必需的（对于授权来说，可能同样必需）。

此外，如果多个用户映射到同一应用程序角色，应确保应用程序记录原始调用者的身份。

. 是否考虑过保护日志文件管理策略。

检查应用程序设计是否考虑到日志文件的备份、存档和分析。日志文件必须定期存档来确保不被充满；如果充满，应开始回收。而且，还要经常分析日志文件来检测入侵迹象。此外，确保执行备份的账户都是特权最少的，确保仅为备份而公开的所有附加信道安全。

应用及传输安全

Web应用系统的安全性从使用的角度可分为应用级的安全与传输级的安全，安全性测试也可从这两个方面入手。

应用级的安全测试的主要目的是查找Web应用系统自身程序设计中存在的安全隐患，主要测试区域如下。

. 注册与登录：现在的Web应用系统基本采用先注册，后登录的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否存在大小写敏感，可以试多少次的限制，是否可以不登录而直接浏览某个页面等。

. 在线超时：Web应用系统是否有超时的限制，也就是说，用户登录后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登录才能正常使用。

. 操作留痕：为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件，是否可追踪。

. 备份与恢复：为了防范系统的意外崩溃造成的数据丢失，备份与恢复手段是一个Web系统的必备的功能。备份与恢复根据Web系统对安全性的要求可以采用多种手段，如数据库增量备份、数据库完全备份、系统完全备份等。出于更高的安全性要求，某些实时系统经常会采用双机热备或多机热备。除了对于这些备份与恢复方式进行验证测试以外，还要评估这种备份与恢复方式是否满足Web系统的安全性需求。

传输级的安全测试是考虑到Web系统的传输的特殊性，重点测试数据经客户端传送到服务器端可能存在的安全漏洞，以及服务器防范非法访问的能力。一般测试项目包括以下几个方面。

. HTTPS和SSL测试：默认的情况下，安全HTTP（Secure HTTP）通过安全套接字SSL（Secure Socket Layer）协议在端口443上使用普通的HTTP。HTTPS使用的公共密钥的加密长度决定的HTTPS的安全级别，但从某种意义上来说，安全性的保证是以损失性能为代价的。除了还要测试加密是否正确，检查信息的完整性和确认HTTPS的安全级别外，还要注意在此安全级别下，其性能是否达到要求。

. 服务器端的脚本漏洞检验：存在于服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。这可以通过设计一些相应的测试案例来进行验证。

. 防火墙测试：防火墙是一种主要用于防护非法访问的路由器，在Web系统中是很常用的一种安全系统。防火墙测试是一个很大很专业的课题，但这里所涉及的只是对防火墙的功能、设置进行测试，以判断是否满足本Web系统的安全需求。

安全性测试方法

功能验证

功能验证是采用软件测试当中的黑盒测试方法，对涉及安全的软件功能，如：用户管理模块、权限管理模块、加密系统、认证系统等进行测试，主要是验证上述功能是否有效，具体方法请参见黑盒测试方法。

漏洞扫描

安全漏洞扫描通常都是借助于特定的漏洞扫描器完成的。漏洞扫描器是一种自动检测远程或本地主机安全性弱点的程序。通过使用漏洞扫描器，系统管理员能够发现所维护信息系统存在的安全漏洞，从而在信息系统网络安全保卫战中做到“有的放矢”，及时修补漏洞。按常规标准，可以将漏洞扫描器分为两种类型：主机漏洞扫描器（Host Scanner）和网络漏洞扫描器（Network Scanner）。主机漏洞扫描器是指在系统本地运行检测系统漏洞的程序，如著名的COPS、Tripewire、Tiger等自由软件。网络漏洞扫描器是指基于网络远程检测目标网络和主机系统漏洞的程序，如Satan、ISS Internet Scanner等。

安全漏洞扫描是可以用于日常安全防护，同时可以作为对软件产品或信息系统进行测试的手段，可以在安全漏洞造成严重危害前，发现漏洞并加以防范。

模拟攻击试验

对于安全测试来说，模拟攻击试验是一组特殊的黑盒测试案例，我们以模拟攻击来验证软件或信息系统的安全防护能力，下面简要列举在数据处理与数据通信环境中特别关心的几种攻击。在下列各项中，出现了“授权”与“非授权”两个术语。“授权”意指“授予权力”，包含两层意思：这里的权力是指进行某种活动的权力（例如访问数据）；这样的权力被授予某个实体、代理人或进程。于是，授权行为就是履行被授予权力（未被撤销）的那些活动。

. 冒充：就是一个实体假装成一个不同的实体。冒充常与某些别的主动攻击形式一起使用，特别是消息的重演与篡改。例如，截获鉴别序列，并在一个有效的鉴别序列使用过一次后再次使用。特权很少的实体为了得到额外的特权，可能使用冒充成具有这些特权的实体，举例如下。

①口令猜测：一旦黑客识别了一台主机，而且发现了基于NetBIOS、Telnet或NFS服务的可利用的用户账号，并成功地猜测出了口令，就能对机器进行控制。

②缓冲区溢出：由于在很多的服务程序中大意的程序员使用类似于“strcpy()，strcat()”不进行有效位检查的函数，最终可能导致恶意用户编写一小段程序来进一步打开安全缺口，然后将该代码放在缓冲区有效载荷末尾，这样，当发生缓冲区溢出时，返回指针指向恶意代码，执行恶意指令，就可以得到系统的控制权。

. 重演：当一个消息或部分消息为了产生非授权效果而被重复时，出现重演。例如，一个含有鉴别信息的有效消息可能被另一个实体所重演，目的是鉴别它自己（把它当作其他实体）。

. 消息篡改：数据所传送的内容被改变而未被发觉，并导致非授权后果，如下所示。

①DNS高速缓存污染：由于DNS服务器与其他名称服务器交换信息的时候并不进行身份验证，这就使得黑客可以加入不正确的信息，并把用户引向黑客自己的主机。

②伪造电子邮件：由于SMTP并不对邮件发送者的身份进行鉴定，因此黑客可以对内部客户伪造电子邮件，声称是来自某个客户认识并相信的人，并附上可安装的特洛伊木马程序，或者是一个指向恶意网站的链接。

. 服务拒绝：当一个实体不能执行它的正常功能，或它的动作妨碍了别的实体执行它们的正常功能的时候，便发生服务拒绝。这种攻击可能是一般性的，比如一个实体抑制所有的消息，也可能是有具体目标的。例如，一个实体抑制所有流向某一特定目的端的消息，如安全审计服务。这种攻击可以是对通信业务流的抑制，或产生额外的通信业务流。也可能制造出试图破坏网络操作的消息，特别是如果网络具有中继实体，这些中继实体根据从别的中继实体那里接收到的状态报告，来作出路由选择的决定。拒绝服务攻击种类很多，举例如下。

①死亡之ping（Ping of Death）：由于在早期的阶段，路由器对包的最大尺寸都有限制，许多操作系统对TCP/IP栈的实现在ICMP包上都规定为64KB，并且在读取包的标题头之后，要根据该标题头里包含的信息来为有效载荷生成缓冲区。当产生畸形的、声称自己的尺寸超过ICMP上限，也就是加载尺寸超过64K上限的包时，就会出现内存分配错误，导致TCP/IP堆栈崩溃，致使接受方宕机。

②泪滴（Teardrop）：泪滴攻击利用那些在TCP/IP堆栈实现中信任IP碎片中的包的标题头所包含的信息来实现自己的攻击。IP分段含有指示该分段所包含的是原包的哪一段的信息，某些TCP/IP（包括Service Pack 4以前的NT）在收到含有重叠偏移的伪造分段时将崩溃。

③UDP洪水（UDP Flood）：各种各样的假冒攻击利用简单的TCP/IP服务，如Chargen和Echo来传送毫无用处的数据以占满带宽。通过伪造与某一主机的Chargen服务之间的一次的UDP连接，回复地址指向开着Echo服务的一台主机，这样就生成在两台主机之间的足够多的无用数据流，如果数据流足够多，就会导致带宽的服务攻击。

④SYN洪水（SYN Flood）：一些TCP/IP栈的实现，只能等待从有限数量的计算机发来的ACK消息，因为它们只有有限的内存缓冲区用于创建连接，如果这一缓冲区充满了虚假连接的初始信息，该服务器就会对接下来的连接请求停止响应，直到缓冲区里的连接企图超时为止。在一些创建连接不受限制的实现里，SYN洪水也具有类似的影响。

⑤Land攻击：在Land攻击中，一个特别打造的SYN包的原地址和目标地址都被设置成某一个服务器地址，这将导致接受服务器向它自己的地址发送SYN-ACK消息，结果，这个地址又发回ACK消息并创建一个空连接，每一个这样的连接都将保留，直到超时。各种系统对Land攻击的反应不同，许多UNIX实现将崩溃，NT变得极其缓慢（大约持续5分钟）。

⑥Smurf攻击：一个简单的Smurf攻击，通过使用将回复地址设置成受害网络的广播地址的ICMP应答请求（ping）数据包，来淹没受害主机的方式进行，最终导致该网络的所有主机都对此ICMP应答请求作出答复，导致网络阻塞，比“Ping of Death”洪水的流量高出一或两个数量级。更加复杂的Smurf将源地址改为第三方的受害者，最终导致第三方雪崩。

⑦Fraggle攻击：Fraggle攻击对Smurf攻击作了简单的修改，使用的是UDP应答消息，而非ICMP。

⑧电子邮件炸弹：电子邮件炸弹是最古老的匿名攻击之一，通过设置一台机器，不断大量地向同一地址发送电子邮件，攻击者能够耗尽接收者网络的带宽。

⑨畸形消息攻击：各类操作系统上的许多服务都存在此类问题，由于这些服务在处理信息之前没有进行适当正确的错误校验，在收到畸形的信息时可能会崩溃。

. 内部攻击：当系统的合法用户以非故意或非授权方式进行动作时就成为内部攻击。多数已知的计算机犯罪都和使系统安全遭受损害的内部攻击有密切的关系。能用来防止内部攻击的保护方法包括：所有管理数据流进行加密；利用包括使用强口令在内的多级控制机制和集中管理机制来加强系统的控制能力；为分布在不同场所的业务部门划分VLAN，将数据流隔离在特定部门；利用防火墙为进出网络的用户提供认证功能，提供访问控制保护；使用安全日志记录网络管理数据流等。

. 外部攻击：外部攻击可以使用的办法有：搭线（主动的与被动的）、截取辐射、冒充为系统的授权用户，冒充为系统的组成部分、为鉴别或访问控制机制设置旁路等。

. 陷阱门：当系统的实体受到改变，致使一个攻击者能对命令或对预定的事件或事件序列产生非授权的影响时，其结果就称为陷阱门。例如，口令的有效性可能被修改，使得除了其正常效力之外也使攻击者的口令生效。

. 特洛伊木马：对系统而言的特洛伊木马，是指它不但具有自己的授权功能，而且还有非授权功能。一个向非授权信道拷贝消息的中继就是一个特洛伊木马。典型的特洛伊木马有NetBus、BackOrifice和BO2k等。

侦听技术

侦听技术实际上是在数据通信或数据交互过程，对数据进行截取分析的过程。目前最为流行的是网络数据包的捕获技术，通常我们称为Capture，黑客可以利用该项技术实现数据的盗用，而测试人员同样可利用该项技术实现安全测试。

该项技术主要用于对网络加密的验证。

模拟攻击试验

①口令猜测：一旦黑客识别了一台主机，而且发现了基于NetBIOS、Telnet或NFS服务的可利用的用户账号，并成功地猜测出了口令，就能对机器进行控制。

. 消息篡改：数据所传送的内容被改变而未被发觉，并导致非授权后果，如下所示。

⑦Fraggle攻击：Fraggle攻击对Smurf攻击作了简单的修改，使用的是UDP应答消息，而非ICMP。

测试方法

根据是否执行软件，将软件测试方法分为静态测试和动态测试。动态测试是建立在程序的执行过程中，根据是否要求了解被测对象的内部，分为黑盒测试和白盒测试。

静态测试和动态测试

静态测试

静态测试方法包括检查单和静态分析方法，对软件文档的静态测试方法主要是以检查单的形式进行文档审查，而对软件代码的静态测试方法一般采用代码审查、代码走查和静态分析的形式进行。

静态分析是一种对代码的机械性和程序化的特性分析方法。一般包括控制流分析、数据流分析、接口分析和表达式分析。

代码审查是检查代码和设计的一致性、代码执行标准的情况、代码逻辑表达的正确性、代码结构的合理性以及代码的可读性。代码审查应根据所使用的语言和编码规范确定审查所用的检查单，检查单的设计或采用应经过评审。

代码走查是由测试人员组成小组，准备一批有代表性的测试用例，集体扮演计算机的角色，按照程序的逻辑，逐步运行测试用例，查找被测软件缺陷。代码走查应由测试人员集体阅读讨论程序，是用“人脑”执行测试用例并检查程序。

对于规模较小、安全性要求很高的代码也可进行形式化证明。静态分析常需要使用软件工具进行。

静态测试的特点有：不必设计在计算机上执行的测试用例；可充分发挥人的逻辑思维优势；不需特别条件，容易开展；发现错误的同时也就定位了错误，不需作额外的错误定位工作。

动态测试

动态测试是建立在程序的执行过程中，根据是否对被测对象内部的了解，分为黑盒测试和白盒测试。

黑盒测试是一种按照软件功能说明设计测试数据的技术，不考虑程序内部结构和编码结构，也不需考虑程序的语句及路径，只需了解输入／输出之间的关系，依靠这一关系和软件功能说明确定测试数据，判定测试结果的正确性。黑盒测试又称功能测试、数据驱动测试或基于需求的测试。

白盒测试是一种按照程序内部逻辑结构和编码结构设计测试数据的技术，可以看到程序内部结构，并根据内部结构设计测试数据，使程序中的每个语句、每个条件分支、每个控制路径的覆盖情况都在测试中受到检验。白盒测试又称结构测试、逻辑测试或基于程序的测试。

动态测试的特点有：实际运行被测程序；必须设计测试用例来运行；测试结果分析工作量大，测试工作费时、费力；投入人员多、设备多，处理数据多，要求有较好的管理和工作规程。

在软件动态测试过程中，应采用适当的测试方法，实现测试要求。配置项测试和系统测试一般采用黑盒测试方法；部件测试一般主要采用黑盒测试方法，辅助以白盒测试方法；单元测试一般采用白盒测试方法，辅助以黑盒测试方法。

黑盒测试

黑盒测试方法一般采用功能分解、等价类划分、边界值分析、判定表、因果图、随机测试、猜错法和正交试验法等。

功能分解

功能分解是将需求规格说明中每一个功能加以分解，确保各个功能被全面地测试。功能分解是一种较常用的方法。

步骤如下：

（1）使用程序设计中的功能抽象方法把程序分解为功能单元。

（2）使用数据抽象方法产生测试每个功能单元的数据。

功能抽象中程序被看成一种抽象的功能层次，每个层次可标识被测试的功能，层次结构中的某一功能有由其下一层功能定义。按照功能层次进行分解，可以得到众多的最低层次的子功能，以这些子功能为对象，进行测试用例设计。

数据抽象中，数据结构可以由抽象数据类型的层次图来描述，每个抽象数据类型有其取值集。程序的每一个输入和输出量的取值集合用数据抽象来描述。

等价类划分

等价类划分是在分析需求规格说明的基础上，把程序的输入域划分成若干部分，然后在每部分中选取代表性数据形成测试用例。

步骤如下：

（1）划分有效等价类：对规格说明是有意义、合理的输入数据所构成的集合。

（2）划分无效等价类：对规格说明是无意义、不合理的输入数据所构成的集合。

（3）为每一个等价类定义一个唯一的编号。

（4）为每一个等价类设计一组测试用例，确保覆盖相应的等价类。

边界值分析

边界值分析是针对边界值进行测试的。使用等于、小于或大于边界值的数据对程序进行测试的方法就是边界值分析方法。

步骤如下：

（1）通过分析需求规格说明，找出所有可能的边界条件。

（2）对每一个边界条件，给出满足和不满足边界值的输入数据。

（3）设计相应的测试用例。

对满足边界值的输入可以发现计算错误，对不满足的输入可以发现域错误。该方法会为其他测试方法补充一些测试用例，绝大多数测试都会用到本方法。

判定表

判定表由四部分组成：条件桩、条件条目、动作桩、动作条目。任何一个条件组合的取值及其相应要执行的操作构成规则，条目中的每一列是一条规则。

条件引用输入的等价类，动作引用被测软件的主要功能处理部分，规则就是测试用例。

建立并优化判定表，把判定表中每一列表示的情况写成测试用例。

该方法的使用有以下要求：

（1）需求规格说明以判定表形式给出，或是很容易转换成判定表。

（2）条件的排列顺序不会影响执行哪些操作。

（3）规则的排列顺序不会影响执行哪些操作。

（4）每当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。

（5）如果某一规则的条件的满足，将执行多个操作，这些操作的执行与顺序无关。

因果图

因果图方法是通过画因果图，把用自然语言描述的功能说明转换为判定表，然后为判定表的每一列设计一个测试用例。

步骤如下：

（1）分析需求规格说明，引出原因（输入条件）和结果（输出结果），并给每个原因和结果赋予一个标识符。

（2）分析需求规格说明中语义的内容，并将其表示成连接各个原因和各个结果的“因果图”。

（3）在因果图上标明约束条件。

（4）通过跟踪因果图中的状态条件，把因果图转换成有限项的判定表。

（5）把判定表中每一列表示的情况生成测试用例。

如果需求规格说明中含有输入条件的组合，宜采用本方法。有些软件的因果图可能非常庞大，根据因果图得到的测试用例数目非常多，此时不宜使用本方法。

随机测试

随机测试指测试输入数据是在所有可能输入值中随机选取的。测试人员只需规定输入变量的取值区间，在需要时提供必要的变换机制，使产生的随机数服从预期的概率分布。该方法获得预期输出比较困难，多用于可靠性测试和系统强度测试。

猜错法

猜错法是有经验的测试人员，通过列出可能有的错误和易错情况表，写出测试用例的方法。

正交实验法

正交实验法是从大量的实验点挑出适量的、有代表性的点，应用正交表，合理地安排实验的一种实验设计方法。

利用正交实验法来设计测试用例时，首先要根据被测软件的需求规格说明找出影响功能实现的操作对象和外部因素，把它们当作因子，而把各个因子的取值当作状态，生成二无的因素分析表。然后，利用正交表进行各因子的状态的组合，构造有效的测试输入数据集，并由此建立因果图。这样得出的测试用例的数目将大大减少。

白盒测试

白盒测试方法一般包括控制流测试（语句覆盖测试、分支覆盖测试、条件覆盖测试、修订的条件／判定覆盖MC/DC、条件组合覆盖测试、路径覆盖测试）、数据流测试、程序变异、程序插桩、域测试和符号求值等。

控制流测试

控制流测试依据控制流程图产生测试用例，通过对不同控制结构成分的测试验证程序的控制结构。所谓验证某种控制结构即指使这种控制结构在程序运行中得到执行，也称这一过程为覆盖。以下介绍几种覆盖：

（1）语句覆盖。语句覆盖要求设计适当数量的测试用例，运行被测程序，使得程序中每一条语句至少被遍历，语句覆盖在测试中主要发现错误语句。

（2）分支覆盖。分支覆盖要求设计适当数量的测试用例，运行被测程序，使得程序中每个真值分支和假值分支至少执行一次，分支覆盖也称判定覆盖。

（3）条件覆盖。条件覆盖要求设计适当数量的测试用例，运行被测程序，使得每个判断中的每个条件的可能取值至少满足一次。

（4）修订的条件／判定覆盖（MC/DC——Modified Condition/Decision Coverage）。修订的条件／判定覆盖要求设计适当数量的测试用例，运行被测程序，使得每个判定中的每个条件都曾独立的影响判定的结果至少一次（独立影响意思是在其他的条件不变的情况下，只改变一个条件，就可影响整个判定的值）。

对安全性要求比较高的软件，一般采用此覆盖要求。此覆盖要求在测试用例的效率和数量之间较为平衡。

（5）条件组合覆盖。条件组合覆盖要求设计适当数量的测试用例，运行被测程序，使得每个判断中条件的各种组合至少出现一次，这种方法包含了“分支覆盖”和“条件覆盖”的各种要求。

（6）路径覆盖。路径覆盖要求设计适当数量的测试用例，运行被测程序，使得程序沿所有可能的路径执行，较大程序的路径可能很多，所以在设计测试用例时，要简化循环次数。

以上各种覆盖的控制流测试步骤如下：

（1）将程序流程图转换成控制流图。

（2）经过语法分析求得路径表达式。

（3）生成路径树。

（4）进行路径编码。

（5）经过译码得到执行的路径。

（6）通过路径枚举产生特定路径的测试用例。

控制流图是描述程序控制流的一种图示方式，它由结点和定向边构成。控制流图的结点代表一个基本块，定向边代表控制流的方向。其中要特别注意的是，如果判断中的条件表达式是复合条件，即条件表达式是由一个或多个逻辑运算符连接的逻辑表达式，则需要改变复合条件的判断为一系列单个条件的嵌套的判断。控制流图的基本结构如下图所示。

控制流图基本结构

数据流测试

数据流测试是用控制流程图对变量的定义和引用进行分析，查找出未定义的变量或定义了而未使用的变量，这些变量可能是拼错的变量、变量混淆或丢失了语句。数据流测试一般使用工具进行。

数据流测试通过一定的覆盖准则，检查程序中每个数据对象的每次定义、使用和消除的情况。

数据流测试步骤：

（1）将程序流程图转换成控制流图。

（2）在每个链路上标注对有关变量的数据操作的操作符号或符号序列。

（3）选定数据流测试策略。

（4）根据测试策略得到测试路径。

（5）根据路径可以获得测试输入数据和测试用例。

动态数据流异常检查在程序运行时执行，获得的是对数据对象的真实操作序列，克服了静态分析检查的局限，但动态方式检查是沿与测试输入有关的一部分路径进行的，检查的全面性和程序结构覆盖有关。

程序变异

程序变异是一种错误驱动测试，是为了查出被测软件在做过其他测试后还剩余一些的小错误。本方法应用于测试工具。

程序插装

程序插装是向被测程序中插入操作以实现测试目的方法。程序插装不应该影响被测程序的运行过程和功能。

有很多的工具有程序插装功能。由于数据记录量大，手工进行将是一件很烦琐的事。

域测试

域测试是要判别程序对输入空间的划分是否正确。该方法限制太多，使用不方便，供有特殊要求的测试使用。

符号求值

符号求值是允许数值变量取“符号值”以及数值。符号求值可以检查公式的执行结果是否达到程序预期的目的；也可以通过程序的符号执行，产生出程序的路径，用于产生测试数据。符号求值最好使用工具，在公式分支较少时手工推导也是可行的。

更多复习资料
请登录电脑版软考在线 www.rkpass.cn

京B2-20210865 | 京ICP备2020040059号-5