系统测试案例.pptx

系统测试系统测试第八讲第八讲系统测试系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求。系统测试过程制定测试计划（PLAN)按计划完成测试（Do)审核和评审测试文档（Check）维护测试文档（Action）测试计划ANSI/IEEE软件测试文档标准829-1983将测试计划定义为：“一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了测试项、被测特征、测试任务、人员安排，以及任何偶发事件的风险。”备注：ANSI/IEEE(美国国家标准学会/电气和电子工程师协会)测试计划内容确定系统测试类型确定系统测试进度确定系统测试人员确定系统测试环境确定系统测试工具如何做好测试计划明确测试的目标，增强测试计划的实用性坚持“5W1H”规则采用评审和更新机制，保证测试计划满足实际需求分别创建测试计划与测试详细规格、测试用例变更控制系统测试设计针对软件的不同层采用不同的测试方法。用户层应用层功能层子系统层协议层用户层用户界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。用户层测试方法用户支持测试用户手册、使用帮助、支持客户的其他产品技术手册是否正确、是否易于理解、是否人性化。用户界面测试在确保用户界面能够通过测试对象控件或入口得到相应访问的情况下，测试用户界面的风格是否满足用户要求，例如：界面是否美观、界面是否直观、操作是否友好、是否人性化、易操作性是否较好。用户层测试设计可维护性测试可维护性是系统软、硬件实施和维护功能的方便性。目的是降低维护功能对系统正常运行带来的影响。例如：对支持远程维护系统的功能或工具的测试。安全性测试安全性主要包括了两部分：数据的安全性和操作的安全性。核实只有规格规定的数据才可以访问系统，其他不符合规格的数据不能够访问系统；核实只有规格规定的操作权限才可以访问系统，其他不符合规格的操作权限不能够访问系统；应用层测试设计针对产品工程应用或行业应用的测试。重点站在系统应用的角度，模拟实际应用环境对系统的兼容性、可靠性等进行的测试。系统性能测试系统可靠性、稳定性测试系统兼容性测试系统组网测试系统安装升级测试功能层测试设计设计主要针对产品具体功能实现的测试。业务功能的覆盖：关注需求规格定义的功能系统是否都已实现。业务功能的分解：通过对系统进行黑盒分析，分解测试项及每个测试项关注的测试类型。业务功能的组合：主要关注相关联的功能项的组合功能的实现情况。业务功能的冲突：业务功能间存在的功能冲突情况。比如：共享资源访问等。子系统测试设计针对产品内部结构性能的测试。关注子系统内部的性能，模块间接口的瓶颈。单个子系统的性能：应用层关注的是整个系统各种软、硬件、接口配合情况下的整体性能，这里关注单个系统。子系统间的接口瓶颈：例如：子系统间通讯请求包的并发瓶颈。子系统间的相互影响：子系统的工作状态变化对其他子系统的影响。系统测试-性能测试基本概念 性能测试主要检验软件是否达到需求规格说明书中规定的各类性能指标，并满足一些性能相关的约束和限制条件 性能测试包括以下几个方面：评估系统的能力：测试中得到的负荷和响应时间等数据可以被用于验证所计划的模型的能力，并帮助做出决策识别系统中的弱点：受控的负荷可以被增加到一个极端的水平并突破它，从而修复系统的瓶颈或薄弱的地方系统调优：重复运行测试，验证调整系统的活动得到了预期的结果，从而改进性能，检测软件中的问题系统测试-性能测试性能测试的基准大体有以下几方面：响应时间：从应用系统发出请求开始，到客户端接收到最后一个字节数据为止所消耗的时间。合理的响应时间取决于实际的用户需求。并发用户数：一般是指同一时间段内访问系统的用户数量。吞吐量：指单位时间内系统处理的客户请求数量。性能计数器：描述服务器或操作系统性能的一些数据指标，比如Windows系统资源管理器。性能测试执行计划阶段测试阶段分析阶段定义目标并设置期望值收集系统和测试要求定义工作负载选择要收集的性能度量值标出要运行的测试并决定什么时候运行它们决定工具选项和生成负载编写测试计划，设计用户场景并创建测试脚本做准备工作（如建立测试服务器或布置其他设备）运行测试收集数据分析结果改变系统以优化性能设计新的测试系统测试-压力测试压力测试是指摸拟巨大的工作负荷，以查看系统在峰值使用情况下是否可以正常运行。压力测试是通过逐步增加系统负载来测试系统性能的变化，并最终确定在什么负载条件下系统性能处于失效状态，以此来获得系统性能提供的最大服务级别的测试。压力测试特点压力测试是检查系统处于压力情况下的能力表现通过增加并发用户的数量，检测系统的服务能力和水平；通过增加文件记录数来检测数据处理的能力和水平等等压力测试一般通过模拟方法进行通常在系统对内存使用率达到75%以上、CPU使用率达到75%以上，并在此观测系统响应时间、系统有无错误产生。除了对内存和CPU的使用率进行设定外，数据库的连接数量、数据库服务器的CPU利用率也都可以作为压力测试的依据。压力测试一般用于测试系统的稳定性。系统能够在压力环境下稳定运行一段时间，那么该系统在普遍的运行环境下就应该可以达到令人满意的稳定程度。压力测试与性能测试压力测试是用来保证产品发布后系统能否满足用户需求，关注的重点是系统整体；性能测试可以发生在各个测试阶段，即使是在单元层，一个单独模块的性能也可以进行评估。压力测试是通过确定一个系统的瓶颈，来获得系统能提供的最大服务级别的测试。性能测试是检测系统在一定负荷下的表现，是正常能力的表现；而压力测试是极端情况下的系统能力的表现。压力测试方法重复测试：重复测试就是一遍又一遍地执行某个操作或功能，比如重复调用一个Web服务。压力测试的一项任务就是确定在极端情况下一个操作能否正常执行，并且能否持续不断地在每次执行时都正常。这对于推断一个产品是否适用于某种生产情况至关重要，客户通常会重复使用产品。重复测试往往与其它测试手段一并使用。并发测试：并发是同时执行多个操作的行为，即在同一时间执行多个测试线程。例如，在同一个服务器上同时调用许多Web服务。并发测试原则上不一定适用于所有产品（比如无状态服务），但多数软件都具有某个并发行为或多线程行为元素，这一点只能通过执行多个代码测试用例才能得到测试结果。压力测试方法量级增加：压力测试可以重复执行一个操作，但是操作自身也要尽量给产品增加负担。例如一个Web服务允许客户机输入一条消息，测试人员可以通过模拟输入超长消息来使操作进行高强度的使用，即增加这个操作的量级。这个量级的确定总是与应用系统有关，可以通过查找产品的可配置参数来确定量级。随机变化：该手段是指对上述测试手段进行随机组合，以便获得最佳的测试效果。压力测试执行压力测试用例选取可以从以下几个方面考虑：输入待处理事务来检查是否有足够的磁盘空间；创造极端的网络负载；制造系统溢出条件；系统测试-容量测试所谓的容量测试（Volume Testing）是指，采用特定的手段测试系统能够承载处理任务的极限值所从事的测试工作。这里的特定手段是指，测试人员根据实际运行中可能出现极限，制造相对应的任务组合，来激发系统出现极限的情况容量测试的目的是使系统承受超额的数据容量来发现它是否能够正确处理，通过测试，预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），确定系统在其极限值状态下是否还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。容量测试方法进行容量测试的首要任务就是确定被测系统数据量的极限，即容量极限。这些数据可以是数据库所能容纳的最大值，可以是一次处理所能允许的最大数据量等等。系统出现问题，通常是发生在极限数据量产生或临界产生的情况下，这时容易造成磁盘数据的丢失、缓冲区溢出等一些问题容量测试方法图中反映了资源利用率、响应时间与用户负载之间的关系。可以看到，用户负载增加，响应时间也缓慢的增加，而资源利用率几乎是线形增长。这是因为应用做更多的工作，它需要更多的资源。一旦资源利用率接近百分之百时，出现一个有趣的现象，就是响应以指数曲线方式下降，这点在容量评估中被称作为饱和点。饱和点是指所有性能指标都不满足，随后应用发生恐慌的时间点。执行容量评估的目标是保证用户知道这点在哪，并且永远不要出现这种情况。在这种负载发生前，管理者应优化系统或者增加适当额外的硬件。容量测试方法为了确定容量极限，可以进行一些组合条件下的测试，如核实测试对象在以下高容量条件下能否正常运行：链接或模拟了最大（实际或实际允许）数量的客户机。所有客户机在长时间内执行相同的、可能性能不稳定的重要业务功能。已达到最大的数据库大小（实际的或按比例缩放的），而一起同时执行多个查询或报表事务。容量测试当然需要注意，不能简单地说在某一标准配置服务器上运行某软件的容量是多少，选用不同的加载策略可以反映不同状况下的容量。举个简单的例子，网上聊天室软件的容量是多少？在一个聊天室内有1000个用户，和100个聊天室每个聊天室内有10个用户，同样都是1000个用户，在性能表现上可能会出现很大的不同，在服务器端数据输出量、传输量更是截然不同的。在更复杂的系统内，就需要分别为多种情况提供相应的容量数据作为参考。容量测试执行获取测试需求容量需求通常出现在需求规格说明书中的基本性能指标、极限数据量要求和测试环境部分。用例设计方法规范导出法、边界值分析、错误猜测法容量测试执行步骤分析系统的外部数据源，并进行分类；对每类数据源分析可能的容量限制，对于记录类型数据需要分析记录长度限制，记录中每个域长度限制和记录数量限制；对每个类型数据源，构造大容量数据对系统进行测试；分析测试结果，并与期望值比较，确定目前系统的容量瓶颈；对系统进行优化并重复以上四步，直到系统达到期望的容量处理能力。健壮性测试健壮性的两层含义：一是高可靠性，二是从错误中恢复的能力。前者体现了软件系统的质量；后者体现了软件系统的适应性。二者也给测试工作提出了不同的测试要求，前者需要根据符合规格说明的数据选择测试用例，用于检测在正常情况下系统输出的正确性；后者需要在异常数据中选择测试用例，检测非正常情况下的系统行为。健壮性测试健壮性测试可以根据以下方面评价系统的健壮性：通过：系统调用运行输入的参数产生预期的正常结果。灾难性失效：这是系统健壮性测试中最严重的失效，这种失效只有通过系统重新引导才能得到解决。重启失效：一个系统函数的调用没有返回，使得调用它的程序挂起或停止。夭折失效：程序执行时由于异常输入，系统发出错误提示使程序中止。沉寂失效：异常输入时，系统应当发出错误提示，但是测试结果却没有发生异常。干扰失效：指系统异常时返回了错误的提示，但是该错误提示不是期望中的错误。健壮性测试的策略基于错误的策略：确认所有可能的错误源，为每一类错误开发错误注入技术；基于覆盖率的策略：接口覆盖的数量，故障位置覆盖的数量，例外覆盖的数量；基于失效的策略：用例设计故障是否被处理了，例外是否被处理了，一个组件中的失效是否影响另一个组件；试用例设计方法在进行健壮性测试时，常用的用例设计方法主要有三种：故障插入测试，变异测试和错误猜测法。健壮性测试方法通常需要构造一些不合理的输入来引诱软件出错，如输入错误的数据类型，输入定义域之外的数值等。安全性测试安全测试检查系统对非法侵入的防范能力。目的是为了发现软件系统中是否存在安全漏洞。安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。例如想方设法截取或破译口令；专门定做软件破坏系统的保护机制；故意导致系统失败，企图趁恢复之机非法进入；试图通过浏览非保密数据，推导所需信息等等。理论上讲，只要有足够的时间和资源，没有不可进入的系统。系统安全设计的准则是，使非法侵入的代价超过被保护信息的价值，此时非法侵入者已无利可图。安全性测试方法功能验证功能验证是采用软件测试当中的黑盒测试方法，对涉及安全的软件功能，如用户管理模块、权限管理模块、加密系统、认证系统等进行测试，主要是验证上述功能是否有效。漏洞扫描 安全漏洞扫描通常都是借助于特定的漏洞扫描器完成。漏洞扫描器是一种能自动检测远程或本地主机安全性弱点的程序，通过使用漏洞扫描器，系统管理员能够发现所维护信息系统存在的安全漏洞，从而在信息系统网络安全防护过程中做到有的放矢，及时修补漏洞。安全性测试方法模拟攻击试验 对于安全测试来说，模拟攻击试验是一组特殊的黑盒测试案例，通常以模拟攻击来验证软件或信息系统的安全防护能力。安全性目标预防：对有可能被攻击的部分采取必要的保护措施，如密码验证等。跟踪审计：从数据库系统本身、主体和客体三个方面来设置审计选项，审计对数据库对象的访问以及与安全相关的事件。数据库审计员可以分析审计信息、跟踪审计事件、追查责任，并且对系统效率的影响减至最小。监控：能够对针对软件或数据库的实时操作进行监控，并对越权行为或危险行为发出警报信息。保密性和机密性：可防止非授权用户的侵入和机密信息的泄漏。多级安全性：指多级安全关系数据库在单一数据库系统中存储和管理不同敏感性的数据，同时通过自主访问控制和强制访问控制机制保持数据的安全性。匿名性：防止匿名登陆。数据的完整性：防止数据在未被授权情况下不被修改的性质。安全的原则加固最脆弱的连接：进行风险分析并提交报告，加固其薄弱环节。实行深度防护：利用分散的防护策略来管理风险。失败安全：在系统运行失败时有相应的措施保障软件安全。最小优先权：原则是对于一个操作，只赋予所必须的最小的访问权限，而且只分配所必须的最少时间。分割：将系统尽可能分割成小单元，隔离那些有安全特权的代码，将对系统可能的损害减少到最小。简单化：软件设计和实现要尽可能直接,满足安全需求的前提下构筑尽量简单的系统,关键的安全操作都部署在系统不多的关键点（choke points）上。保密性：避免滥用用户的保密信息。安全的原则缓冲区溢出：密码学的应用：信任管理和输入的有效性:口令认证:客户端安全性:安全控制/构架:安全性测试执行危险和威胁分析。执行系统和它的实用环境的风险和威胁分析。以一种它们可以和系统的安全性动作相比较的方式来定义安全性需求和划分优先级。基于威胁分析，为系统定义安全需求，最关键的安全性需求应该得到最大程度的关注。注意，系统最弱的链接也是重要的，安全性需求的定义是一个反复的过程。模拟安全行为。基于划分的安全需求的优先次序，识别形成系统安全动作的功能和它们依赖的优先顺序。执行安全性测试。实用合适的证据收集和测试工具。估计基于证据的安全活动的可能性和影响。合计出一个准确的结果及系统是否满足安全性需求。可靠性测试软件可靠性测试是以计算软件可靠性为目的。通常选取如下：需要长时间运行的软件。如服务器软件和航天、电信、金融服务等领域的软件等。对故障率有特别需求的软件。如驱动程序等。使用频度非常高的底层模块。如驱动程序模块、公用模块等。可靠性测试方法测试用例设计充分。多个组进行独立测试真实环境测试长时间运行测试故障插入测试恢复性测试恢复性测试主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。恢复测试首先要采用各种办法强迫系统失败，然后验证系统是否能尽快恢复。对于自动恢复，需验证重新初始化、检查点、数据恢复和重新启动等机制的正确性；对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内 备份测试是恢复测试的一个补充，也是恢复性测试的一个部分。备份测试的目的是验证系统在软件或者硬件失败时备份数据的能力。恢复性测试设计测试是否存在潜在的灾难，以及它们可能造成的损失？消防训练式的布置灾难场景是一种有效的方法。保护和恢复工作是否为灾难提供了足够的准备？评审人员应该评审测试工作及测试步骤，以便检查对灾难的准备情况。评审人员包括主要事件专家和系统用户。当真正需要时，恢复过程是否能够正常工作？模拟的灾难需要和实际的系统一起被创建以验证恢复过程。用户、供应商应当共同完成测试工作。兼容性测试兼容性测试是指检查软件之间是否能够正确地进行交互和共享信息。对新软件进行软件兼容性测试，需要解决：软件设计要求与何种其它平台和应用软件保持兼容？如果要测试的软件是一个平台，那么设计要求什么应用程序在其上运行？应该遵守何种定义软件之间交互当地标准或者规范？软件使用何种数据与其它平台和软件交互和共享信息？安装性测试软件如要实现其功能（除嵌入式软件外），第一步是安装操作。理想情况下，一个软件的安装程序应当可以较好的与已有系统相兼容，并有相应的提示界面供用户参考，安装完毕并实现其功能。若事先没有正确的安装测试，导致软件安装错误或失败，则软件根本就谈不上正确的执行，因此安装测试就显得相当重要。安装性测试的目的就是要验证系统成功安装的能力，并保证程序安装后能正常运行。因此清晰且简单的安装过程是系统文档中最重要的部分。安装性测试步骤首先，应参照安装手册中的步骤进行安装，主要考虑到安装过程中所有的缺省选项和典型选项的验证。安装前应先备份测试机的注册表。安装有自动安装和手工配置之分，应测试不同的安装组合的正确性，最终使所有组合均能安装成功。安装过程中异常配置或状态情况（继电等）要进行测试。安装测试应该在所有的运行环境上进行验证，如操作系统，数据库，硬件环境，网络环境等。安装性测试步骤至少要在一台笔记本上进行安装测试，台式机和笔记本硬件的差别会造成其安装时出现问题。安装后应执行卸载操作，检测系统是否可以正确完成任务。检测安装该程序是否对其他的应用程序造成影响。如有web服务，应检测会不会引起多个web服务的冲突可用性测试可用性测试是对于用户友好性的测试，指在设计过程中被用来改善易用性的一系列方法。测试人员为用户提供一系列操作场景和任务让他们去完成，这些场景和任务与产品或服务密切相关，通过观察来发现完成过程中出现了什么问题，用户喜欢或不喜欢哪些功能和操作方式，原因是什么，针对问题提出改进建议。典型可用性测试任务操作的成功率；任务操作效率；任务操作前的用户期待；任务操作后的用户评价；用户满意度；各任务出错率；二次操作成功率；二次识别率用户操作过程中各认知纬度（视产品情况而定）。人有了知识，就会具备各种分析能力，明辨是非的能力。所以我们要勤恳读书，广泛阅读，古人说“书中自有黄金屋。”通过阅读科技书籍，我们能丰富知识，培养逻辑思维能力；通过阅读文学作品，我们能提高文学鉴赏水平，培养文学情趣；通过阅读报刊，我们能增长见识，扩大自己的知识面。有许多书籍还能培养我们的道德情操，给我们巨大的精神力量，鼓舞我们前进。