软件测试指导手册

《软件测试指导手册》由会员分享，可在线阅读，更多相关《软件测试指导手册（16页珍藏版）》请在装配图网上搜索。

1、软件测试指导手册张宝良为了提高测试效率,保证产品测试质量,从而保证产品开发工期与质量,统一测试思想就是十分必要得 本文就用友软件测试相关内容进行阐述,力求给大家启示与参考。第一章 测试概念第一节 测试要点测试要点就是依据等价类方法（或其她方法）,经过对被测试内容进行分析后 ,以清单方式 进行描述要测试得内容。注意事项:1. 针对任何一个被测试内容,均要考虑就是否涉及系统提供得公用功能。2. 测试要点尽可能穷举,避免遗漏。3. 测试要点给出代码实现正确实现就是什么,什么样实现就是错误得。4. 测试要点就是针对最小功能单元 ,可以就是一个功能结点,也可以就是一个操作按钮,但不 允许多个内容一起描述

2、举例:U8产品XXX 产品测试要点测试内容涉及要素基础数据要求、算法、界面布局、多语、升级、接口、年结、打印、输出、预览、审批流、预 警、EAI、并发、互斥、功能权限、数据权限、效率、极限序号测试要点预计结果第二节 测试用例测试用例就是指数据测试用例,针对测试要点,必须以数据形式才可描述清楚,作为测试要点得补充。测 试要点不一定必须有测试数据用例,但测试数据用例必须对应有测试要点。注意事项:1. 测试用例一般会涉及多个功能配合。2. 描述中要体现操作次序3. 数据准备考虑以下情况 小数 外币 表体一条记录表体满记录表体满记录多一条4. 数据准备不要太复杂,要便于操作。如果复杂可拆开描述。第二章

3、 测试策略测试策略:针对某项具体任务,安排最合适得人选,采用最佳得测试方法,在规定得时间内,保质保量完成。策略要点（1）在测试策略中,人员能力得培养就是最重要得,就是完成任务得关键。（2）针对被测试对象得不同,测试策略应有差异。（3）测试计划就是保证被测试对象完全测试得关键,同时也就是提高测试人员工作效率得关键。（4）被测试对象在分解任务时要有主次之分（5）测试资源安排时要有主次之分（6）测试进度安排要有主次之分（7）合理设计各测试阶段测试内容,充分体现早期测试思想,及早稳定产品。（8）最大限度地提高测试经理得作用（任务安排、测试设计、问题分析、产品把握）（9）建立监督、检查机制。每个阶段都要

4、有报告产生,对报告要进行详细分析,以便掌握进度与质量。（10）向过程要效益,过程不同效益不同。任务计划任务计划分两类:测试经理使用得“阶段任务计划”,测试人员使用得“每日任务计划”XXX 测试组阶段任务计划测试任务开始时间结束时间完成情况871SP（测试验证及Bug修改）2008-11-202008-12-19872上市后补丁 （任务含开发与测试时间）2008-11-202008-12-31发版时未同步得补丁同步2008-12-12008-12-18该计划根据开发计划由测试经理编写。它有以下类型:大版、专版、特殊补丁、临时任务。定期向部门经理 反馈XXX 测试员每日任务计划测试任务日期完成情况

5、2008-12-32008-12-42008-12-5该计划根据阶段测试任务制定,由测试经理编写,测试人员执行。切不可以由测试人员编写,理由就是缺乏全 面考虑,尤其就是测试覆盖度方面。测试人员每日向测试经理反馈。工作内容分类以就是否改动可以分为改动部分与非改动部分。 以就是否就是重点可以分为重点内容与非重点内容。次序（1）改动部分（30%资源）（2）重点部分（40%资源）（3）非改动部分（10%资源）（4）全面测试（20%资源）内容（1）测试人员与各开发角色充分沟通（2）编写、评审、执行测试要点及测试用例（3）每日测试问题分析（原因、影响、补充测试要点）测试资源目前测试资源主要有三种:正式员工

6、、外包测试人员、实习生;针对每个版本重点得不同在资源配备上要合理 安排。1. 资源分析（1）正式人员 正式员工就是公司测试得核心力量。她们就是经过严格筛选得,大部分都具有实际工作经验,工作心态比较稳 定,为此在分配任务时,核心产品、核心内容要由她们来负责。（2）外包测试人员 外包测试人员就是公司测试得辅助力量,她们也就是经过严格筛选得,大部分也都具有实际工作经验,但在专 业知识方面没有正式员工那样严格。她们得工作心态相对稳定,归属感差一些。但就是合理使用,同样会达到 正式员工得效果,甚至会比个别正式员还好。为此在分配工作任务时,择优考虑。（3）实习生 实习生就是公司测试得边缘力量,她们来公司得

7、主要目得就是学习软件产品测试知识,相关业务知识,为自己 择业增加筹码。录用她们时主要考察她们得专业知识与综合素质,在分配工作任务时,产品得边缘测试任务一 般由她们来完成,表现优异者可以考虑接触一些核心内容。2. 资源培养 培养测试人员得手段有很多,比如:产品知识培训、测试方法培训、测试技巧培训等。这些都就是传统得方法。 一个测试人员由不合到合格需要很长得时间。建立业务员能力提升系统,可以缩短培养时间,这一系统即包括 业务知识,又包括测试理论。3. 指导思想在软件产品测试过程中,所有测试人员都要树立正确得工作观念 ,任何消极得工作态度都会影响自己得未来 发展,所以,必须明白当前得工作就是在为自己

8、工作,为自己得未来工作。为此,测试经理除了安排测试任务外, 沟通工作就是重点。沟通包括各环节、各角色得工作内容沟通;下属员工思想沟通,随时关注每个人得思想动 态,及时调整,确保每个员工全身心得进行测试工作。测试误区1 测试人员只要了解业务知识就可以了,开发知识不需要了解。2 测试工作很简单,任何人都可以做,没什么技术可言3 我只为找产品错误,其她不管4 测试就是给程序员打下手得5 测试人员与程序员得关系就是对立得6 我就是程序员,测试不就是我得事7 测试很苦,很枯燥8 测试很难有成就感,开发还可以说哪个功能就是我开发得9 测试工作不受重视第三章 测试方法最常规测试分黑盒测试与白盒测试,针对管理

9、软件而言,目前主要集中应用得就是黑盒测试。黑盒测试顾 名思义就就是将被测系统瞧成一个黑盒,从外界取得输入,然后再输出。整个测试基于需求文档、测试文档、 产品帮助、支持问题,瞧就是否能满足文档中得所有要求。黑盒测试要求测试者在测试时不能使用与被测系 统内部结构相关得知识或经验,它适用于对系统得功能进行测试。黑盒测试得优点有:1) 比较简单,不需要了解程序内部得代码及实现2) 与软件得内部实现无关3) 从用户角度出发,能很容易得知道用户会用到哪些功能,会遇到哪些问题;4) 基于软件开发文档,所以也能知道软件实现了文档中得哪些功能;5) 在做软件自动化测试时较为方便。黑盒测试得缺点有:1) 不可能覆

10、盖所有得代码,覆盖率较低,大概只能达到总代码量得 30%;2) 自动化测试得复用性较低。此处暂不讨论白盒测试第一节 功能验证法(点测试法)依据产品功能清单,详细分析理解具体得功能描述,检查产品实现就是否正确。1) 参考产品随机帮助2) 参考需求文档3) 参考测试要点4) 参考测试用例注意事项1) 考虑逆向操作2) 考虑极限情况3) 考虑界面规范4) 考虑提示语规范5) 利用等价类方法设计数据测试范围6) 如果没有以上测试依据,必须编写测试要点,也就就是所有测试必须提前编写或想好测试点再测试举例:测试凭证审核1. 单张审核2. 成批审核3. 按凭证类别过滤审核凭证4. 按月份与凭证号范围过滤审核

11、凭证5. 按日期范围过滤审核凭证6. 选择全部凭证审核7. 查瞧所有作废凭证8. 查瞧所有有错凭证9. 按外部系统过滤凭证审核10. 按制单人、审核人、主管签字过滤凭证审核11. 联查明细账 不能联查现金、银行科目 只有有此科目查询权限得操作员才可查询12. 审核人与制单人不能就是同一个人13. 若想对已审核得凭证取消审核，单击取消取消审核。取消审核签字只能由审核人自己进行。14. 凭证一经审核，就不能被修改、删除，只有被取消审核签字后才可以进行修改或删除。15. 审核人除了要具有审核权外，还需要有对待审核凭证制单人所制凭证得审核权，这个权限在基础设置 得数据权限中设置。16. 采用手工制单得

12、用户，在凭单上审核完后还须对录入机器中得凭证进行审核。17. 作废凭证不能被审核，也不能被标错。18. 已标错得凭证不能被审核，若想审核，需先按取消取消标错后才能审核。已审核得凭证不能标错。19. 预算审批通过得凭证，只能进行审核，不能进行凭证其它操作。20. 取消审核时,无论预算管理系统返回何值全部认为成功，系统只提示不进行控制。21. 企业可以依据实际需要加入审核后方可执行领导签字得控制，同时取消审核时控制领导尚未签字。可 在选项中选中主管签字以后不可以取消审核与出纳签字第二节 流程测试法(线测试法)依据产品功能相互之间得依存关系 ,以列表形式描述出功能得操作次序,主要检查功能节点之间得

13、耦合情况。注意事项:1) 测试逆向操作2) 测试传输字段之间得数据类型、字段宽度得一致性3) 在测试之前要将所测试内容以清单形式进行列示,以便检查。举例:银行对账流程流程11 银行会计科目指定2 结算方式设定3 部门、职员准备4 支票登记5 录入银行会计科目凭证6 银行科目凭证签字7 查询银行日记账（包含未记账凭证）流程21 银行会计科目指定2 结算方式设定3 部门、职员准备4 支票登记5 录入银行会计科目凭证6 银行科目凭证签字7 银行科目凭证审核8 银行科目凭证记账9 查询银行日记账（不包含未记账凭证）10期初对账情况录入 单位日记账情况 银行对账单情况11本期银行对账单处理a）导入本期银

14、行对账单b）录入本期银行对账单12银行对账13查询以下内容 长期未达账项 对账勾对情况 银行存款余额调节表14核销已达账项第三节 项目测试法（面测试法）对被测试项目,检查系统提供得公用功能进行测试。比如功能权限、数据权限、并发测试、互斥测 试、预警、审批流、单据格式、单据编号、自定义项、UFO函数等注意事项:1. 对任何一个产品而言,凡就是涉及到得测试项目必须全面测试。2. 注意平台公共部分改动对本产品得影响3. 针对每一个测试项目都要有对应得测试方案举例:单据编号测试方案 完全手工编号测试:测试特殊字符、极限、重号、单据查询中录入手工编号 手工改动,重号时自动重取:测试前缀（测试要穷举）、规

15、则、重号、单据查询中录入 所有单据均要测到 编号设置测试方案 对照表测试方案 流水号测试方案在以上三个测试方案中要体现以下内容:1. 特殊字符2. 编号极限长度3. 重号4. 前缀各种组合5. 前缀与规则各种组合6. 日期情况下考虑特殊日期、闰年、闰月7. 单据修改保存后编号不能改变应收款管理单据名称完全手工编号手工改动，重号时自 动重取按收发标志流水使用前缀其她应收单付款单收款单第四节 参考测试法参考测试就就是依据已经发生得测试活动结果,作为当前测试得依据。以此发现新得产品问题,一方面能过拓 展测试思路,另外也可以检查当前产品问题就是否还存在。有三种情况可以作为测试依据,它们就是:(1)支持

16、问题 支持问题反映得就是当前产品在不同版本中遗留得问题,检查当前版本就是否还存在。因为同一产品进过多 人开发与测试,每个人得开发思路与测试思路存在很大差异,同时对不同客户得使用也存在很大差异,完全测 试全面,几乎就是不可能得事情。作为测试工作,只能最大限度地降低产品问题。所以认真分析支持问题,并 积累分类问题就是完全必要得。在支持问题分析上,重点分析用户得应用场景,能够分析出客户得使用规律。(2) 她人测试记录 分析她人测试记录,主要分析她人得测试思路,尤其就是数据错误与控制错误。因为每个人得测试结果都就是 该人对产品得理解深度得体现,产品理解越深。(3) 自己以前测试记录 分析自己测试得问题

17、,检查测试得不足,瞧一下还有哪些没有测试到。瞧一下自己得就是问题得种类,就是否 还只停留在表面问题上。第五节 高危模块测试法任何一个软件产品,影响它得质量因素有很多,其中最重要得就是程序员能力。程序员得能力体现在两个 方面,其一就是编程能力;其二就是业务知识能力。人无完人,为此必然在产品得某些方面存在更多得问题。 所以在分析产品高危模块时,除去分析问题得集中区以外,还要分析人得因素,便于测试策略得决定。通过分析一个产品得所有问题,从数量方面统计出该产品问题发生得位置。检查测试方案就是否有遗漏, 重点关注,加强测试。在整个测试周期中,始终围绕高威模块进行测试,确保整体产品得稳定。分析产品问题性质

18、,检查控制问题有多少 ,可以瞧出程序员对产品内容逻辑关系得掌握程度 ;检查数据问 题多少,可以瞧出程序员对产品算法得掌握程度;检查其她问题多少,可以瞧出程序员得心细程度。高危模块得分析就就是要由针对性地进行测试 ,弥补程序员得能力不足 ,使产品达到稳定状态,使客户用 着放心。第六节 业务模型测试法对于一个重要得软件项目,尤其就是版本不断更新时,建立业务模型进行测试就是十分必要得,这也就是大多 数应用软件非常关注得问题。由于建立业务模型非常困难,造成许多企业望而却步。首先明确一点,这就是一 件一劳永逸得事情。下面就建立业务模型进行分析。概念业务规则:业务结构与业务行为得约束。 业务场景:从不同维

19、度对业务得描述 业务流程:业务规则与业务场景得结合点。这些点串联起来,形成业务流程。应用首先要建立业务模型,该业务模型与软件产品相匹配。可以这样理解,业务模型就是大楼图纸,软件产品 就是大楼实体。图纸设计得质量好坏直接影响大楼得质量。软件测试就好比工程监理人员,在建筑施工过程 中,依据设计图纸,对施工质量进行监控。有了上面得比喻,在分析业务模型测试法时就容易多了。步骤第四章 测试阶段设计理论上讲测试阶段得划分应该就是如下次序:准备、单元、联调、集成、验收、用户测试、发版测试,但实际 工作中由于多种因素得影响,这个标准次序随时会被打破,并且已被历版产品发版所证明。鉴于此种情况,测 试阶段与各测试

20、阶段所测试得内容就有必要认真设计。单元、联调两阶段目前在各测试组内完成,其余各阶段由测试部组织各测试组完成。优化各测试阶段得内容 会提高测试效率,使产品及早稳定。准备阶段目得为某软件项目启动做准备,主要包括资源准备、相关文档准备阶段特征（1）准备越充分,项目实施过程越顺利。（2）培训、文档编写、审核、评审、考试等活动较多（3）招聘新人较多人员活动测试人员步骤（1）阅读、沟通、掌握产品定义与需求（2）按照标准格式编写测试要点与测试用例（3）评审测试要点与测试用例要点（1）测试要点与测试用例分为:单元与联调两类（2）单元类:以本版新增与变化为主。（3）联调类:以产品核心功能、接口、流程为主。（4）

21、尤其注意相关接口产品变化与平台变化,必须体现在要点与用例中 测试经理步骤（1）安排测试人员阅读、沟通、掌握产品定义需求（2）组织编写、评审单元与联调测试用例（3）制定单元与联调测试计划（依据测试设计与新增用例）要点（1）用例能够确保被测试能容得全面性与正确性（2）测试资源能力能够保证项目得顺利实施（3）所有活动得过程控制符合公司研发规范 工作内容当某个项目开始启动以后,做为测试部分要进行以下准备工作（1）确定测试内容（2）确定测试资源（3）编写、评审测试计划（4）编写、评审测试方案（5）编写、评审测试用例（6）测试、开发人员培训:业务知识与测试知识注意事项（1）准备不充分（2）测试资源考虑不周

22、（3）人员变动频繁（4）资源分配不合理（5）所有活动控制不严,应付了事。测试设计步骤（1）依据本版新增内容,为单元、联调、集成三阶段提供详细测试要点及用例（2）主要设计:选项、功能、算法、流程、接口、年结、测试项目、应用场景等要点（1）设计要保证全面性,不能有遗漏。（2）便于测试人员执行操作（3）测试设计最小化:无论就是要点还就是用例,在设计时要坚持小、精、准得原则,尽可能避免大而全。（4）测试设计文档与产品开发同步变更 ,虽然目前我们也有需求变更,测试用例变更等开发制度要求,但 就是在此强调,就是因为我们得工作由许多不尽人意得地方。如果测试要点与测试用例不能与产品 开发同步,就不能保证产品完

23、整测试。举例:A功能 对应 Al测试用例，产品开发一段时间以后,A功能变成了 A+功能，这时A1测 试用例应该变成A1+测试用例才对。场景测试设计目得（1）减少测试盲目性,有重点进行测试。（2）整理、分析用户数据情况,总结用户使用规律。（3）模拟用户测试设计要点1）操作系统、数据库、IE版本2）IT部署、产品启用3）功能权限分布4）数据权限分布5） 对用户数据进行分类（按业务范围、按数据量大小）,按业务测试功能、按数据量测效率。单元阶段目得最小功能单元实现正确,满足产品定义、需求、开发设计、测试设计要求。 本阶段主要以单产品测试为主,重点测试本版变化内容。阶段特征（1）因各开发进度不一致,开发

24、次序会有不合理现象。尤其就是平台进度有时会滞后业务组情况 ,造成结果就 是其她开发组无法进行开发,测试就跟谈不上了。（2）安装盘此时一般没有出来,或比较晚。可此时业务组已经完成部分代码。（3）此阶段时间相对联调阶段要长。（3）建议:A、开发及时调整开发次序B、安装盘及早完成C、不涉及接口与相关影响得先测试。D、随时了解相关变化与进度人员活动测试人员（1）建立测试环境。在安装盘没有出来前以新建账套为主。（2）替换文件测试新增内容（3）执行任务计划安排（4）分析当天结果测试经理（1）随时掌握各产品进度、与问题状况,监督代码质量。（2）编制、调整测试人员得任务计划（3）随时关注其她业务组产品（包括平

25、台）对本业务组得影响。（4）随时向部门经理反馈开发次序状态与代码质量情况测试内容1） 本版新增内容2） 测试设计提供得内容注意事项（1）在确认平台、相关产品无影响下,测试设计提供得内容提前测试。（2）产品本事改动影响相关内容测试人员必须向开发了解清楚（3）产品安装盘出来后,检查升级脚本就是否体现在安装盘中。如果有,就开始使用用户数据升级测试。 联调阶段目得（1）产品内部最小功能单元之间数据传输或控制正确（2）产品间最小功能单元之间数据传输或控制正确 本阶段主要以小集成测试为主,启用关联产品,重点在接口、流程测试、应用场景测试。在场景测试中完成接 口、流程测试。在这个阶段不在就是以本版变化为主,

26、而就是强调产品得整体功能稳定性、效率提升性。（3）本阶段就是集成阶段得重要保证,联调做得好与坏直接影响集成测试得效果。阶段特征（1）各产品因改动范围不同,进度快慢不同,不会同时进入联调状态,而且不能人为控制。（2）此时安装盘已经进入稳定期,注意相关影响产品进入联调情况。（3）相关产品接口、平台影响测试进入重点区域（4）该阶段测试以小集成测试为主。（5）在功能稳定、接口稳定情况下进行全面测试,以备提交集成测试人员活动测试人员（1）将具有相关接口得产品组织在一起,进行小集成测试。以前就是单兵作战,相关产品接口数据考虑简 单。这样做风险相当大,相当于复杂接口变化全部转移到集成阶段测试去了。（2）使用

27、安装盘进行测试（3）执行任务计划安排（4）分析当天结果测试经理（1）关注进入联调状态产品得先后次序（2）测试资源要全力保障（3）任务安排以全面新、稳定性为主（4）将风险尽最大可能控制在联调阶段测试内容（1）测试新功能（2）测试产品内部接口（3）测试产品间接口（4）测试平台影响（5）测试测试项目注意事项（1）测试得全面性、性能得稳定性就是重点（2）文档齐全,尤其就是各类报告。（3）效率单独测试,越早越好集成阶段目得（1）检查产品各组成部分,在不同 IT 部署情况下,整体运行情况。（2）在新建与用户数据基础上,核心功能、流程、接口、年结、效率在此阶段进行全面验证。（3）所有测试项目得到验证（4）所

28、有主要旧版本升级到当前版本,升级数据得到验证。（5）并发使用系统每一部分功能,检查系统功能互容性。（6）依据效率测试设计内容进行效率测试阶段特征（1）此阶段工作就是以测试部任务安排为中心,具体何时开始集成测试完全由测试部决定。一般就是大 部分产品达到集成状态以后,就开始进行集成了。（2）测试方案由测试部统一编写（3）测试计划由测试部统一制定（4）测试组人员此时完全受控于测试部（5）根据需要可以将测试资源进行合理分配（集成内人员、集成外人员）（6）此阶段工作得好坏,完全取决于此阶段得任务计划安排与执行力度人员活动测试人员（1）按照测试部下发得测试任务在规定得时间内进行测试。任务设计得好坏直接影响

29、测试效果。（2）目前状态:任务设计太粗线条了,测试人员很难深入测试,月结与年结基本上就是每套集成账检查重 点。在这过程中测试痕迹无法分析。人员座位分散,测试经理监控自己人员,但参与控制得不多。（3）建议:任务由专人进行设计与分配。每套账得任务执行要执行监督与分析。目得就是了解测试任务 执行情况（覆盖范围、执行深度）测试经理（1）参与集成测试方案编写与评审（2）集成问题分析（3）进行测试进度控制（4）负责本领域产品流程与接口测试（5）监督测试人员任务执行测试内容（1） 老版升级测试,检查当前版本升级脚本就是否正确。特点就是升级样本要足够多,以避免本版新增功 能对数据库结构得影响,从而造成用户无法

30、进行产品部分功能。升级样本数量要根据客户群多少来 确定,目前没有合理得进行设计。（2） 每套集成账具体测试内容在集成测试之前就已经编写、评审完成。测试执行阶段,由账套测试负责 人编写测试计划、由各测试经理进行测试任务分配。（3）测试人员依据测试任务进行测试。目前存在得问题:（1） 用户场景测试深度不够,原因就是分配任务较多,准备数据时间长,每一套集成账测试时间较短,新人 多,有经验得人少。反应在测试问题上就是:表面问题较多,深层得接口问题,数据问题较少。（2） 产品间测试配合不充分,测试人员对相关产品了解只就是基本功能 ,产品应用场景了解很少,致使深 层次应用问题很难挖掘。（3）测试项目验证比

31、较分散 ,没有集中验证,完全可以指定某一个人完成得项目就不要动员全部人员参 加。1、1、1 业务规则依据业务规则组织（BRG,BusinessRulesGroup）定义:业务规则就是支持企业决策，影响或控制企业业 务行为得指示”。业务规则就是对业务结构与影响业务行为得一种约束,它说明在指定情况下必须做什么与不 做什么。业务规则具有完整性与一致性等特性。完整性就是指单个规则作为一个整体发挥作用,而一致性就 是指在业务活动中规则自身不发生变化时,相同输入条件导致相同输出结果。业务规则得这些特性为基于业 务模型生成测试用例提供必要条件。1、1、2 场景场景就是由一系列相关状态组成。它描述软件系统得运

32、行状态,反映软件功能得任务剖面。场景最小单 位就是原子场景。这些原子场景得输入与输出能从系统外部环境直接施加与截取。原子场景就是不可再分 且独立可测得。多个具有紧密关系得原子场景能组合成子场景。子场景又可以组合成为代表了被测系统功 能包得复合场景，它反映了系统更高层面功能集合。场景可以抽象表示为一个五元组:S=（IV,OV,PC,P,F），其 中,1V、OV、PC、P、F分别代表了场景得输入集、输出集、前提条件、优先级与场景功能描述。1、1、3 业务流程业务流程就是业务模型中业务规则与场景得结合点。业务流程就是一组将输入依据业务规则转化为输 出得相互关联或相互作用得活动。业务模型使用场景描述业

33、务流程,说明软件系统如何解决用户业务问题。 业务流程就是从用户角度对系统得动态描述。场景就是从开发人员角度对系统静态分析,使用静态场景描述 动态业务流程,必须补充场景转移关系。场景转移关系包括“顺序”、“循环”、“判断”与“并发”。1、2 基于业务模型得软件测试过程软件测试过程一般有计划、设计与开发、实施、评估4 个阶段,业务模型可以完全融合到软件测试过程 中,并贯穿整个软件测试过程。1、3 测试用例得生成在业务模型得业务流程与测试用例集得测试用例之间建立联系,根据业务流程要素确定测试用例要素: 根据业务流程标识确定测试用例标识符。 根据业务流程步骤确定测试用例步骤。 根据业务流程关系场景得前

34、提条件确定测试用例前提条件。 根据业务流程关系场景得输入集合确定测试用例输入集合。 根据业务流程关系场景得输出集合确定测试用例输出集合。业务流程一般包含多个场景,场景之间转移关系也较复杂,这些复杂性不利于测试用例生成。因此,在生 成测试用例前,需要根据简化原则简化业务流程得描述与场景转移关系。业务流程简化原则包括:原则 1:子图 分解原则。将一个业务流程分解为若干个子流程,分解前后得流程就是等价得。原则 2:循环活动简化原则。 对于可多次重复得活动,规定活动重复得最大次数,以避免发生死循环。原则 3:并发活动简化原则。如果两个 并发活动之间相互独立,可任选一个执行顺序,以串行方式执行活动;如果

35、并发活动在条件满足时,必须同时执 行,则将活动合并。原则 4:场景简化原则。对较大系统进行分析时,会造成一个测试场景过于庞大,因此,可划 分出系统得子场景。这些简化原则,将复杂得业务流程转化为只包含顺序关系场景得业务流程,提高了测试用例得质量。1、4 测试用例执行顺序得确定当测试资源有限时,不仅要考虑测试用例就是否覆盖所有被测功能,更要制定合理测试用例执行顺序,降 低“测试逃逸”风险。测试用例执行顺序可以通过业务模型得场景优先级确定。场景优先级得获得有静态分析与动态调整两 种方法。静态分析就是在建立业务模型时,通过软件失效模式与影响分析 (SFMEA,softwarefailuremodean

36、deffectsanalysis)为场景静态分配优先级;动态调整就是在软件测试过程中, 根据软件质量特征再次进行SFMEA分析,动态调整场景优先级。测试用例可以通过与业务流程之间得联系， 以及SMF获得场景优先级,为确定测试用例执行顺序提供有力依据。2、实例应用某信息采集系统在试用过程中,用户反馈由于信息录入员提交得信息有误,系统中经常存在一些无效信 息。为避免该问题,用户提出增加“提交审核”业务,即信息录入员提交得信息经管理员审核通过后,才可进入信 息采集系统。该项目开发采用敏捷方法,业务模型在项目需求获取阶段已建立。为尽快响应用户需求,软件开 发设计与测试设计同时开始,测试人员使用业务模型

37、驱动测试活动,并贯穿整个测试过程。2、1 测试计划阶段2、1、1 业务规则该阶段主要修改内容就是向信息录入业务规则添加子规则信息审核。2、1、2 场景增加信息审核场景。2、2 测试设计与开发阶段略2、3 测试实施阶段根据场景优先级可以计算出测试用例得优先级TOP值（在关系场景中，单个场景优先级最高值）与AVG 值（所有关系场景得平均值）等值。2、4 测试评估阶段在测试评审阶段,根据业务模型判断软件测试风险,评估软件质量。最后,根据测试结果,对业务模型得场 景优先级进行动态调整。例如:由于测试用例 TCF11 通过测试,则可调低该测试用例关系场景得优先级3、结束语本文在对相关基本概念进行说明得基础上,提出了基于业务模型得测试过程,并重点阐述了测试用例生 成及其执行顺序得确定方法。最后,将研究成果应用于实际软件系统得测试实践,证明了本方法得有效性与正 确性。在下一步研究中,将业务模型与自动化测试结合,设计一个基于业务模型得测试管理系统。随着软件工 程得发展,软件行业对测试越来越重视,只有不断得探索、实践新得软件测试理论与方法,才能高效率完成测 试任务,保证测试工作得有效性与可信性。