ch05-软件测试用例设计和管理_第1页
ch05-软件测试用例设计和管理_第2页
ch05-软件测试用例设计和管理_第3页
ch05-软件测试用例设计和管理_第4页
ch05-软件测试用例设计和管理_第5页
已阅读5页,还剩52页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

软件测试管理与实践ch05-软件测试用例设计和管理1理解测试用例的概念。掌握测试用例的属性和设计方法。了解测试用例的评审和管理要点。能够根据理论组织编写并管理项目的测试用例。学习目标23什么是测试用例测试用例的设计方法组织编写并评审测试用例测试用例的执行管理测试用例的统计分析测试用例管理工具什么是测试用例15测试用例(TestCase)是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求。其本质是从测试角度对被测对象的功能和各种特性的细节展开。测试用例=输入(数据+步骤)+输出+执行条件(环境等)软件测试用例6输入:包括输入数据以及操作步骤。数据尽量模拟用户输入,操作步骤要清晰简洁。执行条件:指测试用例执行的特定环境和前提条件。预期结果(输出):在指定的输入和执行条件下的预期结果。注意:预期结果并不只是程序的可见行为。测试用例的组成7测试用例举例测试用例实例测试用例编号测试项目测试标题重要级别预置条件输入执行步骤预期输出ZCGL-ST-SRS001-001登录功能测试登录界面文字正确性验证低登录页面正常显示打开登录页面打开登录页面界面显示文字和按钮文字显示正确8将软件测试活动进一步转化为可实施、可管理的行为跟踪测试需求,避免测试遗漏提升测试的复用率(不同人,同一项目,同类项目)测试用例的重要性测试用例的设计方法2测试方法有黑盒测试和白盒测试两大类,每类又有不同的测试用例设计方法。测试用例的设计方法黑盒测试被称为功能测试或数据驱动测试。在测试时,把被测程序视为一个不能打开的黑盒子,在完全不考虑程序内部结构和内部特性的情况下进行。黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表法等。黑盒测试等价类划分法:把所有可能的输入数据,即程序的输入域划分为若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例。边界值分析法:边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充,这种情况下,其测试用例来自等价类的边界。因果图法:一种利用图解法分析输入的各种组合情况,从而设计测试用例的方法,它适合于检查程序输入条件的各种组合情况。黑盒测试用例设计方法(1-3)决策表(判定表)法:决策表法适用于分析和表达多逻辑条件下执行不同操作的情况,它能够将复杂的问题按照各种可能的情况全部列举出来,简明并避免遗漏。因此,利用决策表能够设计出完整的测试用例集合。错误推测法:基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法。黑盒测试用例设计方法(4-5)白盒测试也称结构测试或逻辑驱动测试,是针对被测单元内部是如何进行工作的测试。它根据程序的控制结构设计测试用例,主要用于软件或程序验证。白盒测试又有静态测试和动态测试之分。白盒测试方法静态测试主要是指代码走查和分析。静态方法是指不运行被测程序本身,仅通过分析或检查项目的需求文档、设计文档、源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析来发现错误。静态方法通过程序静态特性的分析,找出欠缺和可疑之处,例如不匹配的参数、不适当的循环嵌套和分支嵌套等。静态测试动态测试主要是对代码的运行测试,包含多种覆盖方法:语句覆盖:要求设计足够多的测试用例,使得程序中每条语句至少被执行一次。判定覆盖(分支覆盖):它要求设计足够多的测试用例,使得程序中每个判定至少有一次为真值,有一次为假值,即:程序中的每个分支至少执行一次。每个判断的取真、取假至少执行一次。条件覆盖:要求设计足够多的测试用例,使得判定中的每个条件获得各种可能的结果,即每个条件至少有一次为真值,有一次为假值。动态测试1判定/条件覆盖:设计足够多的测试用例,使得判定中每个条件的所有可能结果至少出现一次,每个判定本身所有可能结果也至少出现一次。组合覆盖:要求设计足够多的测试用例,使得每个判定中条件结果的所有可能组合至少出现一次。路径覆盖:设计足够的测试用例,覆盖程序中所有可能的路径。动态测试218测试用例具有代表性测试结果具有可判定性测试过程具有可再现性测试用例具有有效性测试用例设计和生成原则3组织编写并评审测试用例测试用例的设计主要根据测试需求,设计出的测试用例要按照规范的模式描述出来。测试用例的设计和编写是测试过程中的重要工作之一根据测试需求编写测试用例测试用例编写编写测试用例,首先要明确测试用例的属性。测试用例的属性有很多,除了最基本的前提条件,测试环境,输入数据,执行步骤,预期结果之外,为了管理方便还包括测试用例的编号、标题、所测需求、执行方式等。不同工具测试用例的属性大同小异,每个团队要根据自己的实际需要确定要使用的测试用例属性。测试用例的属性22根据测试需求编写测试用例涉及测试用例步骤描述的详细程度测试用例的属性提供测试用例编写的模板组织编写测试用例23测试用例的属性编号属性属性描述1用例编号一般为需求编号后紧跟001,002……2标题(测试目的)对测试用例的描述,测试用例标题应该清楚表达测试用例的用途。比如“测试用户登录时输入错误密码时,软件的响应情况”。3预置条件测试的前提条件,比如先用管理员登录。4测试环境测试的软件、硬件以及网络环境。5输入数据描述测试用例的输入数据6执行步骤测试用例的执行步骤7预期结果测试用例的预期结果8附件辅助附件文档,比如要输入的文档、图片等9对应的脚本[可选]测试执行时的脚本10优先级用例的优先级,一般核心功能或基础功能涉及的用例为高优先级11涉及到的需求用例能测试到的需求点12实施类型自动化、手工、半自动化13测试类型UI测试、功能测试、接口测试、性能测试、兼容性测试、文档测试等14参考信息需要参考的需求文档,相关标准等。15创建人测试用例的创建者16创建日期测试用例创建的日期17历史记录测试用例修改的历史记录备注其他说明根据实际情况进行增减测试用例样例1测试用例样例2测试用例的详略把握26在编写测试用例时会面临一个问题,测试用例步骤描述得详细程度要如何把握?理想的情况应该是测试用例详细记录所有的操作步骤,使一个没有接触过系统的人员也能执行该测试用例。测试用例描述的详略28描述过于详细:会大大增加测试用例的编写和维护时间,一旦测试环境、需求、设计或者实现发生了变化,测试用例都需要及时进行更新。过于简单:除了用例的编写者没有人能够看明白并执行。最终目的:只要能交代清楚,达到沟通的目的就可以了。测试用例的详细程度详细粗略29测试用例详细程度举例“作业管理系统”测试需求之作业提交功能:学生用户登录后,可以为自己的“等待提交”状态作业提交答案,提交答案时可以输入文本描述,可以上传附件,附件支持Word,Ppt,Excel,Txt,JPG,Png,Gif格式。

为该功能设计的一个测试用例可以描述得很详细也可以粗略描述.说明输入步骤输出详细描述文本描述.txt作业答案.doc输入用户名和密码,登录系统;单击左侧导航栏中“我的作业”按钮;选择一个状态为“等待提交”的作业,打开作业所在页面;单击”提交答案”按钮;输入答案文本描述;单击“添加附件”按钮,选择相应Word文档;单击“确定提交”按钮;弹出”作业答案已提交!”作业状态变为“等待批改”作业浏览可以看到提交的答案粗略描述文本描述.txt作业答案.doc选择并打开“等待提交”状态的作业提交作业答案,输入文本描述,并选择Word文件作为附件单击“提交”按钮同上30测试用例详细程度举例“作业管理系统”测试需求之作业提交功能:学生用户登录后,可以为自己的“等待提交”状态作业提交答案,提交答案时可以输入文本描述,可以上传附件,附件支持Word,Ppt,Excel,Txt,JPG,Png,Gif格式。

为该功能设计的一个测试用例可以描述得很详细也可以粗略描述.说明输入步骤输出过简描述文本描述.txt作业答案.doc选择一个作业,输入文本描述,选择答案附件,为作业提交答案.作业答案能够正确提交测试用例的编写模板31编写测试用例可以通过Excel、Word或者专门的测试管理软件测试流程中应该定义测试用例的编写模板以及测试用例编写指南如果团队没有专门的测试流程,则在测试计划中应该约定测试用例的编写模板以确保整个团队的测试用例格式统一。测试用例编写模板33测试用例编写模板1-ALM34测试用例编写模板2-某企业测试用例编写模板3XX系统测试用例用例编号测试模块标题重要级别预置条件输入执行步骤预期输出SRS01-001登录功能登录界面正确性验证低登录页面正常显示打开登录页面打开登录页面界面显示文字和按钮文字显示正确

测试用例的评审36测试用例设计完毕后,最好能够增加评审环节。参与人:需求人员、测试人员、开发人员可能发现:错误、遗漏、冗余、不充分测试用例评审可以参考:《测试用例评审检查单》评审并不容易开展测试用例数量比较多,内容比较细致,评审起来要花费的时间也比较多,以及对评审的重视不够往往不能达到预期的效果只评审核心模块测试用例、将评审时间加入工作计划中只评审测试要点加强测试用例的评审测试用例评审检查单测试用例的组织维护40组织方式应该方便跟踪、分配和管理:按照功能模块组织将属于某模块的功能测试用例、性能测试用例、兼容性测试用例等一起编号、管理。按照测试类型组织将所有功能模块的性能测试、兼容性测试分别编号、管理。实际项目中也可以依靠对测试用例的编号去管理测试用例的管理测试用例完成后不是一成不变,不是一劳永逸需要不断更新和维护,逐步完善:需求发生变化-维护用例与需求之间关系设计发生变化-维护用例与设计之间的关系发现测试遗漏发现设计错误测试用例的更新43假如有一个windows系统上应用的单机版应用软件,让你负责测试该软件的安装卸载,你应该测试哪些内容,写多少测试用例?安装卸载测试思考不是一蹴而就的测试用例的执行管理445建立测试任务,为测试任务指定测试用例集合:设置测试任务的基本信息(开始结束时间、人员)设置任务的汇报周期以及异常处理为任务指定测试用例集管理测试项的状态管理测试执行的日期和时间测试用例的执行管理测试用例的统计分析547可以通过分析统计参数观察测试的效率、合理性:自动化比例功能测试和非功能测试用例比例测试通过率正面和反面测试用例的比例各模块测试用例分布测试用例的分析统计

测试用例的自动化比例

功能测试和非功能测试的比例

测试用例通过率正面测试用例与反面测试用例的比例:通过这一比例可以评估测试用例设计的完备性,如果比例过高则说明反面测试用例可能考虑不充分正面测试用例与反面测试用例的比例各模块测试用例分布:对各功能模块测试用例分布进行统

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论