8.16软件测试用例分析与设计—范建华.ppt

软件测试用例分析与设计;软件测试用例的设计; 在日常的测试用例设计过程中，存在的问题？ ; 如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。 测试用例是测试工作的指导，是软件测试的必须遵 守的准则，更是软件测试质量稳定的根本保障。 ; 测试用例可以独立进行测试执行的最小单元。 测试内容的一系列情景和每个情景中必须依靠输入和输出，而对软件的正确性进行判断的测试文档，称为测试用例。 测试用例就是将软件测试的行为活动，做一个科学化的组织归纳。 软件测试是有组织性、步骤性和计划性的，为了能将软件测试的行为转换为可管理的、具体量化的模式，需要创建和维护测试用例。 ; 在开始实施测试之前设计好测试用例，避免盲目测试并提高测试效率，减少测试的不完全性； 测试用例的使用令软件测试的实施重点突出、目的明确； 根据测试用例的多少和执行难度，估算测试工作量，便于测试项目的时间和资源管理与跟踪； 减少回归测试的复杂程度，在软件版本更新后只需修正少量的测试用例便可展开测试工作，降低工作强度、缩短项目周期； ; 功能模块的测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断细化其效率也不断攀升； 根据测试用例的操作步骤和执行结果，为分析软件缺陷和程序模块质量提供依据；可以方便地书写软件测试缺陷报告； 可以根据测试用例的执行等级，实施不同级别的测试； 便于大型软件测试项目外包测试指导基础； ;可以最大程度地找出软件隐藏的缺陷 可以最高效率的找出软件缺陷 可以最大程度地满足测试覆盖要求 既不过分复杂、也不能过分简单 使软件缺陷的表现可以清楚的判定 ● 测试用例包含期望的正确的结果 ● 待查的输出结果或文件必须尽量简单明了 不包含重复的测试用例 测试用例内容清晰、格式一致、分类组织 测试用例的简明性， 与易理解性， 达到仅根据测试用例即可完成测试为目的 ;可以设计多少个测试用例？ ;UC?TC1、TC2?TS 判断测试的质量，取决于广度、深度，不取决于频度。 广度：功能需求的覆盖率； 深度：单功能点的测试用例的数量。 深度的级别：A:Main TC (基本流) A1:（备选流） B:additional TC （等价类、边界值） C:supply TC(错误推导法、因果图法) D:AD-HOC 随机测试，固定时长 测试用例深度的设计，取决于功能的优先级、重要度。 ; conception ?Feture?Scenario?UC?code-TC --IT 功能的重要度分为4级：critical、major、minor、Don’t care 。 ;标识功能点中待测的业务实体 业务实体与测试的关系 ● 数据库测试（数据实体图） 读需求规格来完成业务实体的标示 需求规格中的业务实体完整性判断 数据实体：输入、输出 ;标识功能点中待测的业务规则 业务规则与测试的关系？ 业务规则分类标识 狭义的业务规则与广义的业务规则 操作步骤、界面、规则、业务，主要完成细节TC逻辑设计 ;标识功能点中待测的业务流 业务流程中的动作与状态分析 业务流程中动作按照时间列表 读UML图中的活动图完成动作或活动的标示 完成流程用例的设计 ;标识功能点中待测的业务状态 业务状态与业务流程 业务状态定义依据（未发生、发生中、已发生） 业务状态的转换条件标识 完善流程、功能用例的设计，业务状态测试 ;标识功能点中待测的业务角色 读需求规格说明书中的组织结构域业务角色 角色对业务实体以及相关属性操作的行为 角色之间的隶属关系 读业务执行者的关系图 权限测试（用户与数据权限、用户与行为权限、用户与角色权限等） ;标识功能点中待测质量因素 读需求规格说明书的非功能部分 客户对软件系统质量的细节要求标出列表 将与软件系统相关的质量属性标出列表 对软件系统的质量属性进行优先级别的排序 非功能性测试（性能、可靠性、健壮），此部分测试基本都是通过自动化测试完成的（压力、疲劳、容量等）。 ;标识功能点中待测环境因素 读需求规格说明书关于软件系统运维环境的描述部分 标识软件系统运行的相关环境因素 对相关的环境因素给出详细列表 对易变动环境与稳定环境进行标识 生产环境对