免费智能真题库 > 历年试卷 > 系统分析师 > 2015年上半年 系统分析师 下午试卷 论文
  第2题      
  知识点：   确认测试   系统测试   性能测试   安全性   安全性测试   安装测试   测试方法   功能测试   黑盒测试   计算机硬件   界面测试   软件系统   硬件   用户界面   用户界面测试   组装测试

 
论软件系统测试及其应用
软件系统测试是将已经确认的软件与计算机硬件、外设、网络等其他设施结合在一起，进行信息系统的各种组装测试和确认测试，系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不符或与之矛盾的地方，进而完善软件。系统洌试的主要内容包括功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、安装与反安装测试等，其中，最重要的是功能测试和性能测试。功能测试主要采用黑盒测试方法。
 
问题：2.1   1．概要叙述你参与管理和开发的软件项目以及你在其中所担任的主要工作。
2．详细论述软件系统测试中功能测试的主要方法，自动化测试的主要内容和如何选择适合的自动化测试工具。
3．结合你具体参与管理和开发的实际项目，说明你是如何采用软件系统测试方法进行系统测试的，说明具体实施过程以及应用效果。
 
 
 

   知识点讲解    
   · 确认测试    · 系统测试    · 性能测试    · 安全性    · 安全性测试    · 安装测试    · 测试方法    · 功能测试    · 黑盒测试    · 计算机硬件    · 界面测试    · 软件系统    · 硬件    · 用户界面    · 用户界面测试    · 组装测试
 
       确认测试
        确认测试也称为有效性测试，主要包括验证软件的功能、性能及其他特性是否与用户要求（需求）一致。确认测试计划通常是在需求分析阶段完成的。根据用户的参与程度，通常包括以下4种类型。
        （1）内部确认测试：主要由软件开发组织内部按软件需求说明书进行测试。
        （2）Alpha测试：由用户在开发环境下进行测试。
        （3）Beta测试：由用户在实际使用环境下进行测试。
        （4）验收测试：针对软件需求说明书，在交付前以用户为主进行测试。
 
       系统测试
        如果项目不只包含软件，还有硬件和网络等，则要将软件与外部支持的硬件、外设、支持软件、数据等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列集成与确认测试。一般来说，系统测试的主要内容包括功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、安装与反安装测试等。系统测试计划通常在系统分析阶段（需求分析阶段）完成。
 
       性能测试
        性能测试是通过自动化的测试工具模拟多种正常、峰值及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行，统称为负载压力测试。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或不能接收的性能点，来获得系统能提供的最大服务级别的测试。
               性能测试的目的
               性能测试的目的是验证软件系统是否能够达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈，并优化软件，最后达到优化系统的目的。具体来说，包括以下几个方面。
               （1）评估系统的能力：测试中得到的负荷和响应时间数据可以被用于验证所计划的模型的能力，并帮助做出决策。
               （2）识别体系中的弱点：受控的负荷可以被增加到一个极端的水平，并突破它，从而修复体系的瓶颈或薄弱的地方。
               （3）系统调优：重复运行测试，验证调整系统的活动得到了预期的结果，从而改进性能。
               （4）检测软件中的问题：长时间的测试执行可导致程序发生由于内存泄漏等引起的失败，揭示程序中的隐含的问题或冲突。
               （5）验证稳定性和可靠性：在一个生产负荷下执行测试一定的时间是评估系统稳定性和可靠性是否满足要求的唯一方法。
               性能测试的类型
               性能测试类型包括负载测试、强度测试和容量测试等。
               （1）负载测试：负载测试是一种性能测试，指数据在超负荷环境中运行，程序是否能够承担。
               （2）强度测试：强度测试是在系统资源特别低的情况下考查软件系统运行情况。
               （3）容量测试：确定系统可处理的同时在线的最大用户数。
               性能测试的步骤
               由于工程和项目的不同，所选用的度量及评估方法也有不同之处。不过仍然有一些通用的步骤可帮助我们完成一个性能测试项目。其步骤如下：
               （1）制定目标和分析系统。
               （2）选择测试度量的方法。
               （3）学习相关技术和工具。
               （4）制定评估标准。
               （5）设计测试用例。
               （6）运行测试用例。
               （7）分析测试结果。
               负载压力测试
               系统的负载压力测试（负载测试）中的负载是指系统在某种指定软件、硬件及网络环境下承受的流量，例如并发用户数、持续运行时间、数据量等，其中并发用户数是负载压力的重要体现。系统在应用环境下主要承受并发访问用户数、无故障稳定运行时间和大数据量操作等负载压力。
               负载压力测试的目的如下：
               （1）在真实环境下检测系统性能，评估系统性能是否可以满足系统的性能设计要求。
               （2）预见系统负载压力承受力，对系统的预期性能进行评估。
               （3）进行系统瓶颈分析、优化系统。
               在网络应用系统中，负载压力测试应重点关注客户端、网络及服务器（包括应用服务器和数据库服务器）的性能。应获取的关键测试指标如下。
               （1）客户端：并发用户数、响应时间、交易通过率及吞吐量等。
               （2）网络：带宽利用率、网络负载、延迟，以及网络传输和应用错误等。
               （3）服务器：操作系统的CPU占用率、内存使用和硬盘I/O等；数据库服务器的会话执行情况、SQL执行情况、资源争用及死锁等；应用服务器的并发连接数、请求响应时间等。
 
       安全性
        （1）可用性。可用性评价指标及测量，如下表所示。
        
        可用性评价指标及测量
        
        （2）完整性。完整性评价指标及测量，如下表所示。
        
        完整性评价指标及测量
        （3）保密性。保密性评价指标及测量，如下表所示。
        
        保密性评价指标及测量
        
 
       安全性测试
        测试应用程序的体系结构和设计可以消除很多与设计有关的漏洞，从而提高应用程序的整体安全性。设计时修复漏洞要比在开发后期解决问题更为简单，也更经济，因为开发后期可能要进行大量的重新工程处理。开发时如果考虑一些与目标部署环境相关的设计以及该环境定义的安全策略，可确保应用程序的部署更加平稳和安全。如果应用程序已创建完毕，安全测试可修复漏洞并完善未来的设计。
        一个完整的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系统的安全需求。
 
       安装测试
        除了嵌入式软件之外，安装是软件产品实现其功能的第一步。对于一般的应用软件来说，最早体现其易用性的就是软件安装。现在的软件系统越来越庞大，有可能使安装过程变得复杂，安装耗时也会越来越长。没有正确的安装根本就谈不上正确的使用，因此安装测试就显得尤为重要，安装的易用性是安装测试的主要内容。
        安装测试的方法很简单，就是按照用户安装手册安装软件，来评估安装过程的易用性、正确性。那么对于安装测试需要注意一些什么呢，我们认为至少应该从以下几个方面来考虑。
        . 安装手册的评估。在安装前需要检查安装手册或用户文档中的安装说明，一般来说，安装手册需要对安装平台、安装过程需注意的事项以及需手动配置的部分进行详细说明。
        . 安装的自动化程度测试。由于制作安装程序的软件很多，其中很成熟的有Installshield等，很多软件采用了自动安装的方式。但由于部分软件的特殊性，有时必须采用一定的手动配置来完成安装。我们要评估软件安装过程的自动化程度。一般来说，软件的安装程序尽量要做到“全自动化”，即使在不得已的情况下需要进行手动配置，也要采取一些措施，比如选择框方式等，使手动配置变得简便和明确。
        . 安装选项和设置的测试。在安装过程中常常需要对安装的项目进行选择，也可能要设置不同的信息，比如安装路径等。安装测试时需要对不同的选项和设置方案进行测试，验证各种方案是否都能安装成功。
        . 安装过程的中断测试。一个大型的软件有可能需要数小时来进行安装，如果因为断电、文件冲突或读写错误导致安装过程的非正常中断，有可能使已进行的安装工作前功尽弃。一个好的自动化安装程序应该能记忆安装的过程，当恢复安装时，安装程序能自动进行检测，并从“断点”继续安装。
        . 安装顺序测试。对于大多数应用系统，特别是分布式系统，常常需要安装软件系统的不同组成部分。不同的安装顺序常常会导致安装失败，或者会引起一些不可预料的错误，例如，先安装客户端后安装服务器，会导致某些软件的客户端与服务器连接不上。如果《安装手册》中未明确指出安装顺序，则需要测试不同顺序的安装过程。
        . 多环境安装测试。不同的应用环境下安装的情况也是不一样的，我们至少要在标准配置、最低配置和笔记本电脑三种环境中进行安装测试。很多情况下产品声称的最低配置并不符实，所以最低配置环境测试是非常必要的。另外，有些系统级的软件常常在笔记本电脑上安装时发生错误，例如，由于笔记本电脑的高集成度特性，Linux桌面操作系统在笔记本安装时出现硬件兼容性问题。
        . 安装的正确性测试。在上述的安装测试后，都需要进行简单的使用以验证安装的正确性。另外，还要考察对其他应用程序的影响。
        . 修复安装测试与卸载测试。修复安装测试指软件使用后，根据需要添加或删除软件的一些组件或者修复受损的软件。修复安装和卸载也应该是自动化的，通常情况下，安装、修复安装以及卸载是一个完整安装程序中的不同选项。进行修复安装测试时，需检查修复对软件有无不良的影响，例如，修复可能造成系统数据丢失。卸载测试重点检查卸载是否完全，不能完全卸载时有无明确提示信息等。
 
       测试方法
        根据是否执行软件，将软件测试方法分为静态测试和动态测试。动态测试是建立在程序的执行过程中，根据是否要求了解被测对象的内部，分为黑盒测试和白盒测试。
               静态测试和动态测试
                      静态测试
                      静态测试方法包括检查单和静态分析方法，对软件文档的静态测试方法主要是以检查单的形式进行文档审查，而对软件代码的静态测试方法一般采用代码审查、代码走查和静态分析的形式进行。
                      静态分析是一种对代码的机械性和程序化的特性分析方法。一般包括控制流分析、数据流分析、接口分析和表达式分析。
                      代码审查是检查代码和设计的一致性、代码执行标准的情况、代码逻辑表达的正确性、代码结构的合理性以及代码的可读性。代码审查应根据所使用的语言和编码规范确定审查所用的检查单，检查单的设计或采用应经过评审。
                      代码走查是由测试人员组成小组，准备一批有代表性的测试用例，集体扮演计算机的角色，按照程序的逻辑，逐步运行测试用例，查找被测软件缺陷。代码走查应由测试人员集体阅读讨论程序，是用“人脑”执行测试用例并检查程序。
                      对于规模较小、安全性要求很高的代码也可进行形式化证明。静态分析常需要使用软件工具进行。
                      静态测试的特点有：不必设计在计算机上执行的测试用例；可充分发挥人的逻辑思维优势；不需特别条件，容易开展；发现错误的同时也就定位了错误，不需作额外的错误定位工作。
                      动态测试
                      动态测试是建立在程序的执行过程中，根据是否对被测对象内部的了解，分为黑盒测试和白盒测试。
                      黑盒测试是一种按照软件功能说明设计测试数据的技术，不考虑程序内部结构和编码结构，也不需考虑程序的语句及路径，只需了解输入／输出之间的关系，依靠这一关系和软件功能说明确定测试数据，判定测试结果的正确性。黑盒测试又称功能测试、数据驱动测试或基于需求的测试。
                      白盒测试是一种按照程序内部逻辑结构和编码结构设计测试数据的技术，可以看到程序内部结构，并根据内部结构设计测试数据，使程序中的每个语句、每个条件分支、每个控制路径的覆盖情况都在测试中受到检验。白盒测试又称结构测试、逻辑测试或基于程序的测试。
                      动态测试的特点有：实际运行被测程序；必须设计测试用例来运行；测试结果分析工作量大，测试工作费时、费力；投入人员多、设备多，处理数据多，要求有较好的管理和工作规程。
                      在软件动态测试过程中，应采用适当的测试方法，实现测试要求。配置项测试和系统测试一般采用黑盒测试方法；部件测试一般主要采用黑盒测试方法，辅助以白盒测试方法；单元测试一般采用白盒测试方法，辅助以黑盒测试方法。
               黑盒测试
               黑盒测试方法一般采用功能分解、等价类划分、边界值分析、判定表、因果图、随机测试、猜错法和正交试验法等。
                      功能分解
                      功能分解是将需求规格说明中每一个功能加以分解，确保各个功能被全面地测试。功能分解是一种较常用的方法。
                      步骤如下：
                      （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）根据路径可以获得测试输入数据和测试用例。
                      动态数据流异常检查在程序运行时执行，获得的是对数据对象的真实操作序列，克服了静态分析检查的局限，但动态方式检查是沿与测试输入有关的一部分路径进行的，检查的全面性和程序结构覆盖有关。
                      程序变异
                      程序变异是一种错误驱动测试，是为了查出被测软件在做过其他测试后还剩余一些的小错误。本方法应用于测试工具。
                      程序插装
                      程序插装是向被测程序中插入操作以实现测试目的方法。程序插装不应该影响被测程序的运行过程和功能。
                      有很多的工具有程序插装功能。由于数据记录量大，手工进行将是一件很烦琐的事。
                      域测试
                      域测试是要判别程序对输入空间的划分是否正确。该方法限制太多，使用不方便，供有特殊要求的测试使用。
                      符号求值
                      符号求值是允许数值变量取“符号值”以及数值。符号求值可以检查公式的执行结果是否达到程序预期的目的；也可以通过程序的符号执行，产生出程序的路径，用于产生测试数据。符号求值最好使用工具，在公式分支较少时手工推导也是可行的。
 
       功能测试
        Web应用功能测试指Web应用系统的基本功能的测试，其案例的设计方法可参见有关《黑盒测试技术》章节的内容。
        考虑到Web应用本身的特点，其功能测试还要注意以下几个方面。
        . 客户端的选择。
        Web应用客户端软件环境主要包括操作系统和浏览器。除非有特殊要求，测试功能时，我们一般选择比较流行的配置，如选择WindowsXP+IE6.0的简体中文版本。需要注意的是，浏览器的种类和版本有可能影响功能的正确实现。
        . 客户端浏览器的配置。
        一般情况下，开发者不会过多地考虑客户端配置问题，只是将更多的时间用于实现服务端的程序，而用户也往往不会刻意地对所使用的浏览器进行适应性配置。如果测试人员完全按照浏览器的缺省配置测试一个Web应用的功能，有可能会出现较多的因浏览器配置而引起的问题。下面以IE6.0为例进行说明，IE6.0的主要配置界面如下图所示。
        
        IE6.0的主要配置界面
        例如Cookie设置就会影响含有Cookie的Web应用的功能能否成功地实现。其他如脚本设置、安全设置、显示设置等大多数设置都会影响到Web应用功能的实现。
        . 客户端的显示设置。
        大多数人都喜欢使用1024×768像素的显示设置，但并不是所有的Web应用都支持这种设置。不合适的显示设置不但会使Web应用系统的界面显示异常，还可能导致应用功能无法实现。
        . 内容测试。
        由于Web应用带有一定的开放性，尤其是发布于互联网上的网站，其内容是完全开放的，因此在Web系统的功能测试中还要重点测试一个方面，即内容测试。
        内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题，甚至导致法律纠纷；信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用Microsoft Word的“拼音与语法检查”功能；信息的相关性是指，是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中所谓的“相关文章列表”。
        下面介绍两种Web应用功能测试的自动化技术，一个是Web应用链接质量保证技术，另一个是Web应用功能测试技术，下面分别论述。
               Web应用链接质量保证技术
               链接是使用户从一个页面浏览到另一个页面的重要手段，链接的质量决定着功能是否能够成功实现。
               要保证每个链接的质量，需要做好三件事情：
               ①该链接将用户带到它所说明的地方；
               ②被链接页面是存在的；
               ③保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面。
               链接测试非常复杂。比如当网页的结构非常复杂且数量巨大时，链接检查的速度就迫切需要提高。当网络连接总是不稳定的时候，误判的频率增大导致工作量加大，就需要保证工作进度。还有，测试的结果能否清晰地报告出来等，这些需求都提高了测试的复杂度。
               要测试Web应用的链接，可以借助于自动化的Web应用链接测试工具，例如WebCheck、Linkbot、TestPartner等。这些测试工具在测试过程中自动扫描Web应用的所有链接，定位及报告问题。针对应用中存在的各种各样的链接，比如图片、框架（Frame）、插件（Plugin）、背景、样式表（Style Sheet）、脚本、Java Applet等以及支持的连接种类，比如HTTP、FTP、GOPHER、HTTPS等工具都能够支持。另外，对本地的链接和重定向的链接也能很好地支持。例如WebCheck能够定位约50个的问题类型，并且提供19个HTML格式的报告。
               利用自动化测试工具测试Web应用的链接，主要优势体现在以下几个方面。
               . 简单易用；
               . 在实现上采用多线程技术，因此检查速度特别快；
               . 对断开的连接可以再次检查，避免误判；
               . 没有检查连接的数量限制，只受系统资源的约束；
               . 可以分析Web应用的结构；
               . 检查结果可以分类查看，自动生成HTML格式的报告。
               Web应用链接主要测试点如下。
               . 测试内部和外部链接中成功和失败的链接点，以及应用中不被其他链接调用的页面；
               . 测试链接中新网页、老网页、慢网页以及丢失的图象标题标签和属性标签等；
               . 分析Web应用的结构是否合理，包括显示和某个URL相关的链接及按照标题、描述、作者、大小、最后修改时间、类型为URL链接分类等。
               Web应用功能测试技术
               如果开发人员刚创立一个新的Web应用系统。在发布应用系统之前，它必须经过测试以确保一切设定功能都能正常运行，这样的测试任务中，针对同一模块或者同一功能点的测试可能需要重复多次。另外，在一个公司中不同项目的测试可能并行展开，例如人事部门的HR系统、客服部门的CRM系统、物流部门的ERP系统等。这样的现状就会使测试人员面临这样一个问题，即“如何有效地测试不断修改着的一个或多个应用程序”。如果资源有限的话，这个问题就更加棘手。人工测试的工作量太大，况且很多公司负担不起额外的时间来培训新的测试人员。为了解决这个问题，就需要一个能简单操作的测试工具来自动完成功能性测试。
               Mercury Interactive的WinRunner就是一个功能性测试工具。它通过捕获和重放用户对Web应用程序的操作，WinRunner可自动执行功能性测试。下面我们来看一个标准的测试过程，主要步骤包括：创建测试脚本、插入检查点、运行测试以及分析结果。
               . 创建测试脚本。
               创建测试脚本只需记录下一个标准的业务流程，如下一张订单或建立一个新的商家账户。测试人员在GUI上点击鼠标，测试工具记录流程就可建立测试脚本，即使技术知识有限的用户也能生成完整的测试。脚本可以直接编辑来满足各种复杂测试的需求。例如，WinRunner可以将两种测试脚本创建方式结合在一个环境下，来适应测试需求。这两种测试脚本创建方式分别是模拟控件操作和模拟鼠标操作。
               . 插入检查点。
               在记录一个测试的过程的脚本中，测试工程师可插入检查点，测试工具会收集检查点的性能指标。脚本运行时，测试工具在查寻潜在错误的同时，会比较检查点所设定的结果和实际测试结果，对其一一验证。例如，WinRunner允许您使用几种不同类型的检查点，包括文本、GUI、位图和数据库。用一个位图检查点，可以确认一个位图图像，如公司的图标是否出现在指定位置。
               . 运行测试。
               建立起测试脚本，并插入检查点和做一些必要修改后，就可以开始运行测试。当测试工具执行测试时，它会自动操作应用程序，正如一个真实用户根据记录流程执行着每一步的操作。
               . 分析结果。
               一旦测试结束后，就需要分析测试结果。测试工具一般会提供详尽的、易读的报告，这些报告对在测试运行中发生的重要事件进行描述，如出错内容和检查点等。
               一次测试结束后，随着时间推移，开发人员会对应用程序做进一步的修改，并需要另加额外的测试。有了前面利用自动化测试工具进行测试的基础，不必改动测试脚本，就可以重新建一个新的测试，这样大大地节省了时间和资源，充分利用了测试投资。
               功能自动化测试工具还能验证数据库的数值，从而确保交易的准确性。例如，在创建测试脚本时，可以设定哪些数据库表格和记录资料需要检测。在重放时，测试程序就会核对数据库内的实际数值与脚本中设定的数值，在有更新/修改，删除或插入的记录上会使用突出标识以引起注意。
               有时为了彻底全面地测试一个应用程序，需要了解对于不同类型的数据，它是如何运行的。测试工具可以将一个记录下的业务流程转化为一个数据驱动的测试，来反映多个用户各自独特且真实的操作行为。以一个订单输入的流程为例，测试人员或许希望将一些锁定的项目栏，如定单号或客户名转化为可变栏，这样就可以用多套数值来检测应用程序了。数据来源可以采用自动生成表格，也可直接从其他的表格或数据库中导入。数据驱动性测试不仅节省了时间和资源，而且提高了应用程序的测试覆盖率。
               利用自动化测试工具在对脚本进行编辑的时候，可以从列表里选择一个功能函数加到脚本中，以提高测试能力。例如，点击“calendar”，然后从年历功能中的下属目录中选择，如“calendar_select_date()”，工具会提供函数的解释。选定了这个函数后，可以输入参数，再将这个函数插入到测试脚本中。
 
       黑盒测试
        黑盒测试又称为数据驱动测试、基于规格的测试、输入输出测试或者功能测试。黑盒测试基于产品功能规格说明书，从用户角度针对产品特定的功能和特性进行验证活动，确认每个功能是否得到完整实现，用户能否正常使用这些功能。
        黑盒测试在不知道系统或组件内部结构的情况下进行，不考虑内部逻辑结构，着眼于程序外部结构，在软件接口处进行测试。黑盒测试主要具有如下功能：
        （1）检查程序功能能否按需求规格说明书的规定正常使用，测试各个功能是否有遗漏，检测是否满足性能等特性要求。
        （2）检测人机交互是否错误，检测数据结构或外部数据库访问是否错误，程序是否能适当地接收输入数据而产生正确的输出结果，并保持外部信息（如数据库或文件等）的完整性。
        （3）检测程序初始化和终止方面的错误。
        黑盒测试方法主要有等价类划分、边界值分析、决策表、因果图、错误推测和功能图法等测试方法，本节主要介绍等价类划分、边界值分析、决策表和元素分析法与错误推测法。
               等价类划分
               等价类是指某个输入域的子集合。在该子集合中，测试某等价类的代表值就等于对这一类其他值的测试，对于揭露程序的错误是等效的。因此，将输入的全部数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据取得较好的测试结果。
               等价类划分有两种情况，即有效等价类和无效等价类。
               （1）有效等价类。对于程序的规格说明来说，它是由合理的、有意义的输入数据构成的集合，利用它可检验程序是否实现了规格说明中所规定的功能和性能。
               （2）无效等价类。与有效等价类相反，它是由对程序的规格说明无意义、不合理的输入数据构成的集合。
               测试用例的设计不仅接收合理的数据，也能经受意外的不合理数据的考验，这样才能确保软件具有较高的可靠性。
               分析可能的输入情况，按照如下几条规则对等价类进行划分。
               （1）在输入条件规定了取值范围或值的个数的情况下，确立一个有效等价类和两个无效等价类。
               例如，若输入条件规定了x的取值为1～100的整数，则等价类划分有效等价类1≤x≤100，两个无效等价类分别为x<1或x>100。
               （2）按照数值集合划分。在输入条件规定了输入值的集合或者规定了“必须如何”的条件下，确立一个有效等价类和一个无效等价类。
               例如，输入条件规定了x的取值为偶数，则有效等价类为x的值为偶数，无效等价类为x的值不为偶数的整数。
               （3）输入条件是一个布尔量的情况，确定一个有效等价类和一个无效等价类。
               （4）规定输入数据取一组值（假定n个），并且程序要在对每一个输入值分别处理的情况下，确立n个有效等价类和一个无效等价类。
               例如，分房方案中对教授、副教授、讲师、助教分别计分，则有效类为4个；无效类为1个。
               （5）按照限制条件或规则划分。在规定输入数据必须遵守的规则的情况下，确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
               例如，C程序设计语言的语法规定．每个语句应以“；”结束，则其有效类有1个，而无效类有若干个（如以“，”结束、以“：”结束、以空格结束等）。
               （6）在确知已划分的等价类中各元素在程序处理方式不同的情况下，再将该等价类进一步划分为更小的等价类。
               等价类划分后，形成等价类表，见下表。
               
               等价类表样式
               根据等价类表，确定测试用例。首先，为每一个等价类规定唯一编号；其次，设计新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止；最后，设计新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止（通常，程序在执行一个错误后不继续检测其他错误，故每次只测一个无效类）。
               边界值分析
               软件测试实践中，大量的错误往往发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。例如，数组下标、循环控制变量等边界附近往往出现大量错误。因此，作为等价类划分方法的补充，边界值分析方法不是选择等价类的任意元素，而主要是针对各种边界情况设计测试用例。
               常见的边界值一般具有如下情况：
               （1）对16位的整数而言，32767和-32768是边界。
               （2）屏幕上的光标在最左上、最右下位置是边界。
               （3）报表的第一行和最后一行是边界。
               （4）数组元素的第一个和最后一个是边界。
               （5）循环的第0次、第1次和倒数第2次、最后一次是边界。
               边界值分析法应着重测试的情况，一般选取等价类划分的输入和输出的边界正好等于或刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。
               边界值分析方法具有如下原则。
               （1）如果输入条件规定了值的范围，则应选取刚达到范围的边界值，以及刚刚超越边界的值作为测试的输入数据。
               （2）如果输入条件规定了值的个数，则用略低于最小值、最小值、略高于最小值、正常值、略低于最大值、最大值和略高于最大值作为测试数据。
               （3）如果程序规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。
               决策表
               决策表又称为判定表，用于分析多种逻辑条件下执行不同操作的技术。在程序设计发展的初期，决策表是程序编写的辅助工具。决策表可以把复杂的逻辑关系和多种条件的组合情况表达明确，与高级程序设计语言中的if-else、switch-case等分支结构语句类似，它将条件判断与执行的动作联系起来。但与程序语言中的控制语句不同的是，决策表能将多个独立的条件和多个动作联系清晰地表示出来。
               决策表的组成如下。
               （1）条件桩：列出了问题的所有条件。通常认为，列出的条件次序无关紧要。
               （2）动作桩：列出了问题规定可能采取的操作，这些操作的排列顺序没有约束。
               （3）条件项：列出了针对条件桩的取值在所有可能情况下的真假值。
               （4）动作项：列出了在条件项的各种取值的有机关联情况下应该采取的动作。
               规则即任何条件组合的特定取值及其相应要执行的操作。在决策表中，贯穿条件项和动作项的列就是规则。显然，决策表中列出多少个条件取值，也就有多少个规则，条件项和动作项就有多少列。
               所有条件都是逻辑结果的决策表称为有限条件决策表。如果条件有多个值，则对应的决策表就叫做扩展条目决策表。决策表用来设计测试用例，条件解释为输入，动作解释为输出。
               决策表适合以下特征的应用程序：
               （1）if-then-else分支逻辑输出。
               （2）输入变量之间存在逻辑关系。
               （3）涉及输入变量子集的计算。
               （4）输入和输出之间存在因果关系。
               （5）很高的圈复杂度。
               构造决策表的步骤：
               ①确定规则的个数。
               有n个条件的决策表有2n个规则（每个条件取真、假值）。
               ②列出所有的条件桩和动作桩。
               ③填入条件项。
               ④填入动作项，得到初始决策表。
               ⑤简化决策表，合并相似规则。
               元素分析法与错误推测法
               元素分析法主要是对测试对象中的各个元素的属性、范围、特点等进行分析，通过对元素的分析，寻找出测试空间和缺陷空间，设计测试用例的方法。
               元素分析法的基本过程如下：
               （1）找出测试对象中的各个元素。
               （2）分析每个元素的特点和属性，确定测试空间与缺陷空间。
               （3）分析元素的组合情况。
               错误推测法是基于经验和直觉的推测，列举出程序中所有可能错误和容易发生错误的特殊情况，有针对性地设计测试用例。
               经验表明，一段程序中已发现的错误数目和尚未发现的错误数目成正比。程序中容易出错的情况如下所示：当输入数据为零时，或者输入或输出的数目允许变化（例如，被检索的或生成的表的项数），或者输入或输出的数目为0和1的情况（例如，表为空或只有一项）等，都较容易发生错误。又如，在单元测试时曾列出许多在模块中常见的错误，以前产品测试中曾经发现的错误等，这些就是经验的总结。
               错误推测法是根据测试人员的经验来确定测试的范围和程度，主要采用如下技术：
               （1）有关软件的设计方法和实现技术。
               （2）有关前期测试阶段结果的知识。
               （3）根据测试类似或相关系统的经验，了解在以前的这些系统中曾在哪些地方出现过缺陷。
               （4）典型的产生错误的情况，如被零除错误等。
               （5）通用的测试经验规则。
 
       计算机硬件
        基本的计算机硬件系统由运算器、控制器、存储器、输入设备和输出设备5大部件组成，随着网络技术的发展和应用，通信部件也成为计算机系统的基本组件。运算器和控制器及其相关部件已被集成在一起，统称为中央处理单元（Central Processing Unit，CPU）。CPU是硬件系统的核心，用于数据的加工处理，能完成各种算术、逻辑运算及控制功能。
        运算器是对数据进行加工处理的部件，它主要完成算术和逻辑运算。控制器的主要功能是从主存中取出指令并进行分析，以控制计算机的各个部件有条不紊地完成指令的功能。
        存储器是计算机系统中的记忆设备，分为内部存储器（Main Memory，MM，简称内存、主存）和外部存储器（简称外存或辅存）。相对而言，内存速度快、容量小，一般用来临时存储计算机运行时所需的程序、数据及运算结果。外存容量大、速度慢，可用于长期保存信息。寄存器是CPU中的存储器件，用来临时存放少量的数据、运算结果和正在执行的指令。与内存储器相比，寄存器的速度要快得多。
        习惯上将CPU和主存储器的有机组合称为主机。输入／输出（I/O）设备位于主机之外，是计算机系统与外界交换信息的装置。所谓输入和输出，都是相对于主机而言的。输入设备的作用是将信息输入到计算机中，输出设备则将运算结果按照人们所要求的形式输出到外部设备或存储介质上。
 
       界面测试
        有人说，除了一定的技术外，Web系统的好与坏取决于其页面的设计艺术水平。这个话虽有失偏颇，但也从另外一个角度说明了Web系统的界面的重要性。由于Web系统的客户端均采用浏览器，不同用户可能会在浏览器里设置不同的显示方式，因此，我们在作界面测试的时候尽量使用默认的设置。
        在开始进行界面测试以前，我们需要重点调研两个问题：
        . Web应用系统的最终用户群是谁；
        . Web应用界面（大多数等同于网页）的设计策略是什么。
        这两个问题决定了我们评价一个Web应用系统界面采用什么样的标准。尽管不同的Web应用系统的界面千变万化，但其测试方法和评价准则仍有一些共同的内容。以下是界面测试中需要重点关注的。
        . 页面中各元素布局的协调性。
        一个复杂的页面会包含多种元素，如文字、表单、图片、动画、表格、视频等，从美学的角度来看，如果只是把所有的Web应用功能简单地堆砌到页面上，其易用性是很差的。需要评估的协调性包括以下几个方面：
        ①各元素位置的协调性；
        ②各元素颜色的协调性；
        ③各元素大小比例的协调性。
        . 不同页面风格的统一性。
        一个统一的Web系统的不同页面应该从颜色、框架、操作方式等多个方面统一起来。由于Web日益流行，很多人把它看作图形设计作品。人们为了体现出网页设计的丰富多彩，在不同页面使用很多不同风格的图片、特效，初看觉得网页非常艳丽多彩，但忽略了不同网页的协调统一。
        . 用户在界面中操作的便利性。
        网页设计中用得最多的是表格，而用户操作最容易导致界面缺陷的也就是表格，因此要对表格进行操作验证。例如，需要验证表格是否设置正确、用户是否需要向右滚动页面才能看见表格中的内容；每一栏的宽度是否足够宽，表格里的文字是否都有折行；是否有因为某一格的内容太多，而将整行的内容拉长等。
        . 界面动态操作测试。
        主要测试以下几个方面：
        ①屏幕分辨率设置的影响；
        ②浏览窗口最大化/最小化的影响；
        ③选定目标元素的置中与缩放。
 
       软件系统
        网络系统软件包括网络操作系统和网络协议等。网络操作系统是指能够控制和管理网络资源的软件，是由多个系统软件组成，在基本系统上有多种配置和选项可供选择，使得用户可根据不同的需要和设备构成最佳组合的互联网络操作系统。网络协议是保证网络中两台设备之间正确传送数据的约定。
 
       硬件
        硬件是计算机物理设备的总称，也称为硬件设备，通常是电子的、机械的、磁性的或光的元器件或装置，一般分为中央处理器、存储器和输入、输出设备。
 
       用户界面
        用户界面是计算机中实现用户与计算机通信的软件和硬件部分的总称。用户界面也称为用户接口或人机界面。
               控制面板式用户界面
               计算机发展早期，用户通过控制台开关、板键或穿孔纸带向计算机送入命令或数据，而计算机通过指示灯及打印机输出运行情况或结果。这种界面的特点是人去适应计算机，现在看来是十分笨拙的。
               字符用户界面
               字符用户界面是基于字符型的。用户通过键盘或其他输入设备输入字符，由显示器或打印机输出字符。字符用户界面的优点是功能强、灵活性好、屏幕开销少；缺点是操作步骤繁琐，学会操作较费时。
               图形用户界面
               随着文字、图形、声音、图像等多媒体技术的出现，各种图形用户界面应运而生，用户既可使用传统的字符，也可以使用图形、图像和声音同计算机进行交互，操作更为自然、更加方便，多媒体技术进一步推广、发展与完善。现代界面的关键技术是超文本。超文本的"超"体现在它不仅包括文本，还包括图像、音频、视频等多媒体信息，即将文本的概念扩充到超文本，超文本的最大特点是具有指向性。
               新一代用户界面
               多媒体、多通道及智能化是新一代用户界面的技术支持。新的、更加自然的交互技术，将为用户提供更方便的输入技术。计算机将通过多种感知通道来理解用户的意图，实现用户的要求；计算机不仅以二维屏幕向用户输出，而且能以真实感的计算机仿真环境向用户提供真实的体验。
 
       用户界面测试
        用户界面测试主要核实用户与软件之间的交互，验证用户界面中的对象是否按照预期的方式运行，并符合国家或行业的标准。
        界面测试中的部分工作主观性比较强，测试结果往往与测试人员的喜好有关。因此，界面测试的一个缺点就是，测试人员在整个测试过程中身心不可能保持一致，在一定程度上会影响测试结果的准确性。
        用户界面测试可分为整体界面测试和界面中的元素测试。界面中的元素主要包括窗口、菜单、图标、文字、鼠标等。
               界面整体测试
               界面整体测试是指对界面的规范性、一致性、合理性等进行测试和评估。
                      规范性测试
                      软件的界面要尽量符合现行标准和规范，并在应用软件中保持一致。而开发软件时就要充分考虑软件界面的规范性，最好的办法是采取一套行业标准。现在许多行业已有自己的标准，如IBM标准、Microsoft标准、Apple标准。这些标准已经基本包含“菜单条、工具栏、工具箱、状态栏、滚动条、右键快捷菜单”的标准格式，以上标准已经基本完善，对某些行业只需利用已有的成果就可以。
                      对于一些特殊行业，由于系统使用环境和用户使用习惯的特殊性，使用以上标准是远远不够的，还要对自身特殊的需要加以补充。如软件的用户定位包括不同年龄阶段的用户，那么就会有一些用户基本不使用鼠标右键，年龄较大的用户难以看清密集的较小的文字，或用户对计算机系统和网络不够熟悉，或硬件环境一般，甚至比较差，少有配置优良的计算机等等。在这种环境下，用户对计算机的使用一般没有使用倾向，大多更适应手工操作。像这种情况，特殊行业都要有一套自己比较完善的标准和规范。
                      这些标准和规范是经过各种类型的测试与评估，不断总结，经验积累和反反复复设计成果。在界面测试中，测试工程师应该严格遵循这些标准和规范设计界面规范性测试用例。
                      合理性测试
                      界面的合理性是指界面是否与软件功能相融洽，界面的颜色和布局是否协调等。如果界面不能体现软件的功能，那么界面的作用将大打折扣。所以，界面的合理性是界面美的首要因素，它提醒设计者不要片面追求外观漂亮而导致失真或华而不实。
                      合理性差的界面无疑会混淆软件意图，致使用户产生误解。即使它不损害软件功能与性能，也会使用户产生不该有的情绪波动。合理的用户界面是应用程序的一个重要组成部分，也是使软件易用的重要基础。空间使用应当形成一种简洁、有序、易于操作的布局，使信息组织具有艺术性。如果一个界面上有太多或者杂乱无章的控件，会给用户寻找字段或者控件带来不便和困难。
                      测试软件界面的合理性一般通过观察进行，举例如下。
                      . 界面中元素的文字、颜色等信息是否与功能不一致；
                      . 前景与背景色搭配是否合理协调，反差是不是太大；
                      . 界面中的元素大小和布局是否协调；
                      . 窗口的比例是否合适。
                      一致性测试
                      一致性既包括使用标准的控件，也指相同的信息表现方法，如在字体、标签风格、颜色、术语、显示错误信息等方面确保一致。好的软件界面都具有相似的界面外观、布局、交互方式以及信息显示等。界面保持高度一致性，用户可以减少过多的学习和记忆量，从而降低培训和支持成本。
                      此外，软件的界面在不同平台上是否表现一致呢？作为测试人员不要忽略这一点。如颜色、字体，有时有些软件在不同的平台表现得不尽如人意“——”在一个系统上看上去很好，在另一个系统上常常看上去很糟。
                      对于在不同的平台测试软件界面的一致性可以用下面的方法：在不同分辨率下，观察界面的美观程度，分别在800×600，1024×768，1152×864, 1280×768，1280×1024，1200×1600大小的字体下进行测试。一个好的软件要有一个默认的分辨率，而在其他分辨率下也都能运行。
                      作为测试工程师，在测试界面一致性时应该注意以下几点因素。
                      . 布局是否一致，如所有窗口按钮的位置和对齐方式要一致；
                      . 标签和讯息的措辞是否一致，如在提示、菜单和帮助中产生相同的术语；
                      . 界面外观是否一致，如控件的大小、颜色、背景和显示信息等属性要一致，但一些需要艺术处理或有特殊要求的地方除外；
                      . 操作方法是否一致，如双击其中的项，使得某些事件发生，那么双击任何其他列表框中的项，都应该有同样的事件发生；
                      . 颜色的使用是否一致，颜色的前后一致会使整个应用软件有同样的观感；
                      . 快捷键在各个配置项上语义是否保持一致。
                      下表列出了常用的快捷键及其功能。
                      
                      常用的快捷键及功能
                      界面定制性测试
                      对于适用于多层次用户的软件，由于用户熟练程度（外行、初学、熟练）不同、使用频度不同和不同角色，需要不同的操作方式或用户界面。如财务软件中财务总监的界面应提供大量查询功能和更多使用鼠标的操作，而会计、出纳的界面应提供更多的键盘快捷方式和以最少的步骤完成日常凭证制作审核。因此需要对界面的可定制性进行测试，测试中可参考以下几项测试内容。
                      . 界面元素的可定制性。可以允许用户定义工具栏、状态栏是否显示，工具栏显示在界面上的位置，如上方、下方或悬浮等；一些软件还可以定义菜单的位置。随着Windows XP的出现，界面风格的可定制也为软件个性化提供了新的特性。
                      . 工具栏的可定制性。工具栏为用户使用常用的功能提供了方便，但不同用户对“常用”的理解是不同的，因此，应当允许用户自定义工具栏，包括建立新的工具栏，选择要显示的工具栏，定义工具栏上的按钮，制定为工具按钮定义所链接的功能等。
                      . 统计检索的可定制性。检索和统计是用户向系统索取数据最经常用到的功能，检索条件是否灵活、分类统计是否合理、是否允许用户定义检索条件和统计项，需要测试人员在充分了解用户需求和使用习惯的基础上，制定大量案例，通过实际操作来体会。
                      . 报表的可定制性。各种各样的报表是软件对用户输出的重要方式，报表表头包括的项目、表格的行高列宽、表中数据的单位和显示格式超长超宽表的分页方式等如果能够允许用户自定义，则可以使软件生成的报表适用于更广泛的范围，减少用户二次处理表格的工作量，极大地方便用户的使用。
               界面元素测试
                      窗口测试
                      在Windows平台上运行的应用软件，窗口是软件界面的基础，正如操作系统的名字。窗口是显示设备中的一个区域，用于观看对象、对象相关信息以及应用与对象的动作进行交互。窗口有标题栏可以进行打开、关闭、创建、缩放、移动、删除、重叠等操作。
                      现在让我们了解一下窗口的基本组成部分，从外观上讲，一般窗口是由标题、边框、菜单、工作区、滚动条等组成（如下图所示）。虽然软件产品的窗口各种各样，令人眼花缭乱，但基本组成是相同的。
                      
                      Microsoft Word窗口的配置部件示意图
                      下面是一些窗口测试用例设计的参考例子。
                      . 窗口控件的大小、对齐方向、颜色、背景等属性的设置值是否和程序设计规约相一致。
                      . 是否显示相关的下拉菜单、工具条、滚动条、对话框、按钮、图标和其他控制，既能正确显示又能调用。
                      . 若窗口无法显示，所有内容是否能够改变大小、移动和滚动。
                      . 活动窗口是否能够被反显加亮。
                      . 窗口是否正确地关闭。
                      . 多个窗口叠加时窗口的名称是否显示正确。
                      . 窗口的数据是否能够利用鼠标、功能键、方向箭头和键盘操作。
                      . 当窗口被覆盖并重新调用后，窗口是否能够正确再生。
                      . 如果使用多任务，是否所有的窗口被实时更新。
                      . 窗口是否支持最小化和最大化或放大。
                      . 窗口上的控件是否随着窗体的缩放而缩放。
                      . 父窗体支持缩放时，子窗体是否也缩放。
                      . 在一个窗口中按Tab键，移动聚焦是否按顺序移动。Tab的顺序应是先从上至下，再从左至右。
                      . 子窗口位置是否在父窗口的左上角或正中，由于屏幕对角线相交的位置是用户直视的地方，正上方1/4处为易吸引用户注意力的位置，在放置窗口时要注意利用这两个位置。父窗口或主窗口的中心位置应该在对角线焦点附近。
                      . 当多个子窗口弹出时是否依次向右下方偏移，以显示出窗口标题为宜，如下图所示为Microsoft PowerPoint窗口重叠示意图。通常重叠的窗口具有固定大小和位置，新打开的窗口要堆叠在最近打开的窗口上，这些重叠的窗口都带有突出的标签以便选择。
                      . 重要的命令按钮与使用较频繁的按钮是否放在了界面上醒目的位置。因错误使用而引起界面退出或关闭的按钮，放在容易点击的位置。横排开头或结尾，与竖排结尾为容易点击的位置。
                      . 与正在进行的操作无关的按钮应该加以屏蔽（Windows中用灰色显示，没法使用该按钮）。
                      . 按钮的大小要与界面的大小和空间是否协调。避免在空旷的界面上放置很大的按钮。放置完控件后界面不应有很大的空缺位置。
                      . 多窗口的切换响应时间是否过长。如果切换时间过长就会使用户出现意外的焦躁情绪，而响应时间过短有时会造成用户操作节奏加快，从而导致用户操作错误。
                      
                      Microsoft PowerPoint窗口重叠示意图
                      菜单测试
                      菜单对我们来讲是很熟悉的，它是应用程序命令项列表，菜单位置按照功能来组织。菜单按图形方式可以产生丰富多彩的菜单形式，例如条形菜单、水平和垂直的弹出式菜单、下拉菜单、T形菜单等。无论采用哪种方式，仅仅是菜单显示方式不同罢了，菜单的测试方法还是基本一样的。
                      菜单是否易用主要体现在它能否提供线索帮助用户识别，而不用强迫用户去记忆。如果用户只通过简单的培训或偶尔的使用，就可以接受该系统，那么简单和有规则的菜单尤其有效。
                      作为测试工程师，设计菜单界面测试用例主要应从以下几点考虑。
                      . 是否符合需求；
                      . 菜单项的措辞是否准确；
                      . 菜单项的顺序是否合理；
                      . 图形的布局是否一致。
                      菜单界面测试用例设计范例如下表所示。
                      
                      菜单界面测试用例
                      这个测试用例可以适用不同的菜单，上表是针对菜单界面测试所设计的一个测试用例说明。这个测试用例通过测试人员测试，会找出更多的Bugs。
                      图标测试
                      图标实际上属于菜单交互方式，只是它使用图标来代表文本菜单的菜单项。使用图标可以形象、逼真地反映菜单的功能，从而使理解、学习和操作变得更加易用。
                      由于图标是表示实体信息的简洁、抽象的符号，所以在日常生活中被广泛地使用。图标不仅仅作为表示实体的符号，还可以作为可视按钮项，当被选中激活时，可以完成指定的功能。
                      图标测试比较主观，与测试人员的喜好有关。比如，图标基调颜色刺眼，用户登入界面比较难于找到，图标比较抽象，图标范围太广等都属于用户界面测试中的缺陷。
                      形象的图标给人很大的帮助，使人容易理解其内涵。那么图标测试用例要考虑的重点有哪些呢，以下所提供的几点可以作为参考。
                      . 图标是否符合常规的表达习惯。
                      . 不同的目标是否采用不同的图标。
                      . 图标是否具有清晰的轮廓，轮廓清晰的图标可保证图像在不同背景色上都具有较好效果。
                      . 注意图标的尺寸，建议图标的尺寸小一些较好。如工具栏图标非常小，您使用简单的图像，以直观方式显示图像即可清晰地表达图标的含义，而不必使用其他的复杂方式。Windows XP图标有四种尺寸，建议使用以下四种尺寸：48×48像素，32×32像素，24×24像素以及16×16像素。
                      . 建议图标的外形与实际功能相似，应尽量避免抽象。这样的图标可以使用户很轻松、容易地认识此图标。
                      . 在图标上是否加有标注。
                      鼠标测试
                      鼠标问题经常被人们忽略，但我们无时无刻都不能离开它。用户会把鼠标移进、移出窗口，或当光标在窗口中，用户按下、释放鼠标键，鼠标是否准确、灵活，对一个测试人员来说必将提到日程上来。
                      以下所提供的几点可以作为鼠标测试的参考。
                      . 在整个交互式语境中，是否可以识别鼠标操作；
                      . 如果要求多次点击鼠标，是否能够在语境中正确识别；
                      . 如果鼠标有多个按钮，是否能够在语境中正确识别；
                      . 光标、处理指示器和识别指针是否随操作恰当地改变；
                      . 点击选中而不是滑动停留选中；
                      . 支持滑轮（鼠标中间的滚动轮）上下翻动操作；
                      . 对于相同种类的元素采用相同的操作激活；
                      . 用沙漏表示系统忙，用手型表示可以点击；
                      . 鼠标无规则点击时是否会产生无法预料的结果；
                      . 单击鼠标右键是否弹出菜单，取消右键是否隐藏弹出的菜单。
                      文字测试
                      文字在视觉上向用户传达作者的意图和各种信息，如果文字的组合巧妙，在视觉传达的过程中能够给人以美的感受，从而获得良好的心理反应。反之，则使人看后心里不愉快，视觉上难以产生美感，甚至会让用户拒而不看，这样势必难以传达出作者想表现的意图和构想。
                      要达到这一目的必须考虑文字的整体诉求效果，给人以清晰的视觉印象。因此，在测试过程中，测试人员应该注意文字是否繁杂零乱，使人易认、易懂，测试文字主要依靠软件设计标准，观察文字是否有效地传达作者的意图，表达设计的主题和构想意念。
                      文字测试是测试软件中是否拼写正确，是否易懂，不存在二义性，没有语法错误；文字与内容是否有出入等等，包括图片文字。比如，“请输入正确的证件号码”中何谓正确的证件号码。证件可以为身份证、驾驶证，也可为军官证，如果改为“请输入正确的身份证号码”用户就比较容易理解了。
               界面测试典型用例
               现在介绍一个菜单界面测试的模拟，软件人员开发了第一版的软件，如下图所示为菜单测试用例，供测试人员测试，此时测试人员将根据上面章节中提到的测试用例来找出软件的问题。
               
               菜单测试用例
               菜单界面测试用例设计范例如上表所示。
               这个测试用例可以适用不同的菜单，如下表所示是针对菜单界面测试所设计的一个例子。这个测试用例通过测试人员测试，会找出更多的缺陷。
               
               菜单界面用例测试用例
               
 
       组装测试
        组装测试也被称为集成测试。即使所有模块都通过了测试，但在组装之后，仍可能会出现问题：通过模块的数据被丢失；一个模块的功能对其他模块造成有害的影响；各个模块被组合起来后没有达到预期功能；全局数据结构出现问题；另外单个模块的误差可以接受，但模块组合后，可能会出现误差累积，最后达到不能接受的程度，所以需要组装测试。
        通常，组装测试有两种方法：一种是分别测试各个模块，再把这些模块组合起来进行整体测试，这种方法被称为非增量式集成。另一种是把下一个要测试的模块组合到已测试好的模块中，测试完后再将下一个需测试的模块组合进来进行测试，逐步把所有模块组合在一起，并完成测试。该方法被称为增量式集成。非增量式集成可以对模块进行并行测试，能充分利用人力，以加快工程进度。但这种方法容易混乱，出现的错误不容易被查找和定位。增量式测试的范围是一步步扩大的，所以错误容易被定位，而且已测试的模块可在新的条件下进行测试，程序测试得更彻底。
        增量式测试技术有自顶向下的增量方式和自底向上的增量方式两种测试方法。
        （1）自顶向下的增量方式。
        自顶向下的增量方式是模块按程序的控制结构，从上到下的组合方式。再增加测试模块时有先深度后宽度和先宽度后深度两种次序。如下图所示的自顶向下组合示例中，先深度后宽度的方法是把程序结构中的一条主路径上的模块相组合，测试顺序可以是M1→M2→M5→M6→M3→M7→M4。先宽度后深度的方法是把模块按层进行组合，测试顺序是M1→M2→M3→M4→M5→M6→M7。组装过程可分成以下步骤：
        
        自顶向下的组合示例
        .用主模块作为驱动模块，与之直接相连的模块用桩模块代替。
        .根据所选的测试次序，用下一个模块替换所用的桩模块；而新引入模块的直接下属模块用桩模块代替，构成新的测试对象。
        .结合一个模块测试一个模块。为了避免引入新模块产生新问题，需要进行回归测试，即重复部分或全部已经进行过的测试。
        .所有模块是否已经被组合到系统中，并完成测试。如果没有完成测试，则返回到第二步，重复进行；如果完成测试，则停止测试。
        自顶向下的增量方式可以较早地验证控制和判断点，如果出现问题可及时进行纠正。在测试时不需要编写驱动模块，但需要桩模块。另外，如果高层模块对下层模块依赖性很大，需要返回大量信息，在用桩模块代替时，桩模块的编写就相对复杂，必然会增加开销。这时可以用下面介绍的自底向上的增量方式。
        （2）自底向上的增量方式。
        自底向上的增量方式是从最底层的功能模块开始，边组合边测试，从下向上地完成整个程序结构的测试。其步骤可以概括为：
        .将最底层的模块组合成能完成某种特定功能的模块簇，为每个模块簇设计驱动程序，用驱动程序来控制并进行测试。
        .按从下向上的方向，用实际模块替换相对应的驱动程序，组成新的模块簇，再为该模块簇设计驱动程序，用新的驱动程序进行控制和测试。
        .所有模块是否已经被组合到系统中，并完成测试。如果没有完成测试，则返回到第二步，重复进行；如果完成测试，则停止测试。
        自底向上的增量方式可以较早地发现底层关键性模块出现的错误。在测试时不需要缩写桩模块，但需要驱动模块。另外，这种方式对程序中的主要控制错误的发现相对较晚。
        组装测试的方法选择取决于软件的特点和进度安排。在工程中，通常将这两种方法结合起来使用，即对位于软件结构中较上层的使用自顶向下的方法，而对于较底层的使用自底向上的方法。
   题号导航      2015年上半年 系统分析师 下午试卷 论文   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
 
第2题    在手机中做本题