软件测试之测试用例设计(ppt-3).pptVIP

测试用例设计 测试体系结构和工程设计 测试系统是指由测试过程、测试件和测试环境创造的测试的组织能力。 一个有能力的测试小组拥有一个好的测试系统就可以为项目提供有效和高效的服务。好的测试系统能帮助测试人员把测试工作重点放在关键质量风险上，并发现、再现、隔离、描述，以及管理被测试软件或硬件中的重要错误，同样也捕捉和分析关键度量。 测试系统的构成 测试系统体系结构原理 欧洲最壮观、最让人印象深刻的伦敦圣保罗教堂，其设计者Christopher Wren先生，他建造的教堂在战火中屹立不倒，该建筑物已有200多年的历史； 当面临紧迫的时间要求和多个项目的压力，我们的测试系统是否会像圣保罗教堂一样能够适应变化，仍能够正常运行呢？ Wren的杰作令人感慨地另一方面就是优雅和简洁。同样当构建测试系统时，我们是否能把握容易理解性、简洁性、易用性呢? 测试件一团混乱是很平常的事情，当创建新的测试系统时，要同时考虑功能和格式。严谨的工程创造功能，而设计决定生成格式。 好的测试系统体系结构意味着有设计良好的测试件和测试环境。 测试人员通常要维护测试系统，特别是测试用例和测试包。 测试系统的基本构件：测试用例 在某种意义上，测试系统中的一切，包括测试过程、测试工具、报告格式、测试环境等，都支持测试用例的执行。 测试用例负责对被测试系统采取行动，由被测试系统提供数据并执行。 行为、数据和期望结果这三个值的集合是测试发生和测试条件创建的三个因素 测试用例的基本格式 用例编号 测试标题 重要级别 测试输入 操作步骤 预期结果 其它测试用例 重用同类型项目的测试用例 利用已有的软件Checklist 利用已有的测试方法 加强测试用例的评审 测试用例执行 搭建软件测试环境， 执行测试用例 测试执行过程应注意的问题 IEEE 829测试用例模版 测试用例规格说明标识符 测试项 描述被测试的特性和条件 输入规格说明 数据名 排序 值（带有容差或生成过程） 状态 时间限制 输出规格说明 数据名 排序 值 状态 时间限制 环境需求 硬件 软件 其他 特殊过程需求 用例之间的依赖关系 功能测试用例 用例来源，即测试的需求 测试用例的主要来源为：系统主要功能描述，需求规格说明书，补充需求，系统关注点。 功能测试用例 用例的组织方式 用例首先应当以功能进行分类，然后按照系统工作方式，依据主工作流程和辅助工作流程进行组织。用例可以进行归纳整理，整理的最小单位为最小不可拆分模块。如：登陆模块，包含的用例可能为密码校验，帐户合法性校验，系统掉线处理等子测试用例，但是可以认为登陆操作是个不可再分的最小测试用例模块，其中包含很多的子测试用例。 争论： 在测试用例的组织过程中，应当将测试用例流程化，按照系统工作流程将所有测试用例分派完毕，达到可对系统检验的目的。 测试用例只组织到最小不可拆分模块，当书写测试方案的时候再组织相应的测试用例。由于在此期间需求或者由于其它因素的变化，可能会造成人力的浪费。 功能测试用例 性能测试用例 由于性能测试与功能测试有很大的区别，所以讨论出的结果可能与预先的设想有一定的区别。 性能测试用例 性能测试的目的：个人认为下面的应该是测试的目的，不是性能测试定义 为了验证系统是否达到用户提出的性能指标，同时发现系统中存在的性能瓶颈，起到优化系统的目的。 性能测试用例 性能测试指标的来源： 用户对各项指标提出的明确需求；如果用户没有提出性能指标则根据用户需求、测试设计人员的经验来设计各项测试指标。（需求+经验） 性能测试用例 主要的性能指标： 服务器的各项指标（CPU、内存占用率等）、后台数据库的各项指标、网络流量、响应时间。 性能测试用例 BUG观点： 1、性能测试就象人在无风情况下跑步（正常情况下的性能指标）； 2、压力测试就象人在微风中跑步（在正常的基础上加大多少百分比压力的性能指标）； 3、负载测试就象人在强风中跑步（不断加压，直到系统崩溃）。 性能测试用例 HTTP观点： 负载测试是正常情况下持续的加压； 压力测试是直接加压达到一个极限值。 大家统一的观点： 性能测试、压力测试、负载测试密不可分，可统称为性能测试。 其他测试用例 性能测试要点： 性能测试是在功能测试完成之后进行。 性能测试计划、方案一般与测试用例统一在一个文档里。 测试环境应尽量与用户环境保持一致。 性能测试一般使用测试工具和测试人员编制测试脚本来完成，性能测试的环境应单独运行尽量避免与其他软件同时使用。 性能测试的重点在于前期数据的设计与后期数据的分析。 性能测试的用例主要涉及到整个系统架构的问题，所以测试用例一旦生成，改动一般不大，所以做性能测试的重复使用率一般比较高。（说明：当系统中出现的某个功能点需要修改，它一般只会影响到功能测试的设计用