2022年测试指导手册 2.pdf

软件测试指导手册张宝良为了提高测试效率，保证产品测试质量，从而保证产品开发工期与质量，统一测试思想是十分必要的。本文就用友软件测试相关内容进行阐述，力求给大家启示与参考。第一章测试概念第一节测试要点测试要点是依据等价类方法（或其他方法） ，经过对被测试内容进行分析后，以清单方式进行描述要测试的内容。注意事项：1.针对任何一个被测试内容，均要考虑是否涉及系统提供的公用功能。2.测试要点尽可能穷举，避免遗漏。3.测试要点给出代码实现正确实现是什么，什么样实现是错误的。4.测试要点是针对最小功能单元，可以是一个功能结点，也可以是一个操作按钮，但不允许多个内容一起描述举例： U8 产品XXX 产品测试要点测试内容涉及要素基础数据要求、算法、界面布局、多语、升级、接口、年结、打印、输出、预览、审批流、预警、 EAI、并发、互斥、功能权限、数据权限、效率、极限序号测试要点预计结果第二节测试用例测试用例是指数据测试用例，针对测试要点，必须以数据形式才可描述清楚，作为测试要点的补充。测试要点不一定必须有测试数据用例，但测试数据用例必须对应有测试要点。注意事项：1.测试用例一般会涉及多个功能配合。2.描述中要体现操作次序3.数据准备考虑以下情况小数名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 1 页，共 17 页 - - - - - - - - - 外币表体一条记录表体满记录表体满记录多一条4.数据准备不要太复杂，要便于操作。如果复杂可拆开描述。第二章测试策略测试策略：针对某项具体任务，安排最合适的人选，采用最佳的测试方法，在规定的时间内，保质保量完成。策略要点（1）在测试策略中，人员能力的培养是最重要的，是完成任务的关键。（2）针对被测试对象的不同，测试策略应有差异。（3）测试计划是保证被测试对象完全测试的关键，同时也是提高测试人员工作效率的关键。（4）被测试对象在分解任务时要有主次之分（5）测试资源安排时要有主次之分（6）测试进度安排要有主次之分（7）合理设计各测试阶段测试内容，充分体现早期测试思想，及早稳定产品。（8）最大限度地提高测试经理的作用（任务安排、测试设计、问题分析、产品把握）（9）建立监督、检查机制。每个阶段都要有报告产生，对报告要进行详细分析，以便掌握进度和质量。（10）向过程要效益，过程不同效益不同。任务计划任务计划分两类：测试经理使用的“阶段任务计划”，测试人员使用的“每日任务计划”XXX 测试组阶段任务计划测试任务开始时间结束时间完成情况871SP（测试验证及Bug 修改）2008-11-20 2008-12-19 872 上市后补丁（任务含开发和测试时间）2008-11-20 2008-12-31 发版时未同步的补丁同步2008-12-1 2008-12-18 该计划根据开发计划由测试经理编写。它有以下类型：大版、专版、特殊补丁、临时任务。定期向部门经理反馈XXX 测试员每日任务计划测试任务日期完成情况2008-12-3 2008-12-4 2008-12-5 名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 2 页，共 17 页 - - - - - - - - - 该计划根据阶段测试任务制定，由测试经理编写，测试人员执行。切不可以由测试人员编写，理由是缺乏全面考虑，尤其是测试覆盖度方面。测试人员每日向测试经理反馈。工作内容分类以是否改动可以分为改动部分和非改动部分。以是否是重点可以分为重点内容和非重点内容。次序（1）改动部分（ 30%资源）（2）重点部分（ 40%资源）（3）非改动部分（ 10%资源）（4）全面测试（ 20%资源）内容（1）测试人员与各开发角色充分沟通（2）编写、评审、执行测试要点及测试用例（3）每日测试问题分析（原因、影响、补充测试要点）测试资源目前测试资源主要有三种：正式员工、外包测试人员、实习生；针对每个版本重点的不同在资源配备上要合理安排。1资源分析（1）正式人员正式员工是公司测试的核心力量。他们是经过严格筛选的，大部分都具有实际工作经验，工作心态比较稳定，为此在分配任务时，核心产品、核心内容要由他们来负责。（2）外包测试人员外包测试人员是公司测试的辅助力量，他们也是经过严格筛选的，大部分也都具有实际工作经验，但在专业知识方面没有正式员工那样严格。他们的工作心态相对稳定，归属感差一些。但是合理使用，同样会达到正式员工的效果，甚至会比个别正式员还好。为此在分配工作任务时，择优考虑。（3）实习生实习生是公司测试的边缘力量，他们来公司的主要目的是学习软件产品测试知识，相关业务知识，为自己择业增加筹码。录用他们时主要考察他们的专业知识与综合素质，在分配工作任务时，产品的边缘测试任务一般由他们来完成，表现优异者可以考虑接触一些核心内容。2资源培养培养测试人员的手段有很多，比如：产品知识培训、测试方法培训、测试技巧培训等。这些都是传统的方名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 3 页，共 17 页 - - - - - - - - - 法。一个测试人员由不合到合格需要很长的时间。建立业务员能力提升系统，可以缩短培养时间，这一系统即包括业务知识，又包括测试理论。3指导思想在软件产品测试过程中，所有测试人员都要树立正确的工作观念，任何消极的工作态度都会影响自己的未来发展，所以，必须明白当前的工作是在为自己工作，为自己的未来工作。为此，测试经理除了安排测试任务外，沟通工作是重点。沟通包括各环节、各角色的工作内容沟通；下属员工思想沟通，随时关注每个人的思想动态，及时调整，确保每个员工全身心的进行测试工作。测试误区1 测试人员只要了解业务知识就可以了，开发知识不需要了解。2 测试工作很简单，任何人都可以做，没什么技术可言3 我只为找产品错误，其他不管4 测试是给程序员打下手的5 测试人员与程序员的关系是对立的6 我是程序员，测试不是我的事7 测试很苦，很枯燥8 测试很难有成就感，开发还可以说哪个功能是我开发的。9 测试工作不受重视第三章测试方法最常规测试分黑盒测试与白盒测试，针对管理软件而言，目前主要集中应用的是黑盒测试。黑盒测试顾名思义就是将被测系统看成一个黑盒，从外界取得输入，然后再输出。整个测试基于需求文档、测试文档、产品帮助、支持问题，看是否能满足文档中的所有要求。黑盒测试要求测试者在测试时不能使用与被测系统内部结构相关的知识或经验，它适用于对系统的功能进行测试。黑盒测试的优点有：1） 比较简单，不需要了解程序内部的代码及实现2） 与软件的内部实现无关3） 从用户角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题；4） 基于软件开发文档，所以也能知道软件实现了文档中的哪些功能；5） 在做软件自动化测试时较为方便。黑盒测试的缺点有：1)不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的30%；2)自动化测试的复用性较低。此处暂不讨论白盒测试第一节功能验证法（点测试法）依据产品功能清单，详细分析理解具体的功能描述，检查产品实现是否正确。1） 参考产品随机帮助名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 4 页，共 17 页 - - - - - - - - - 2） 参考需求文档3） 参考测试要点4） 参考测试用例注意事项1） 考虑逆向操作2） 考虑极限情况3） 考虑界面规范4） 考虑提示语规范5） 利用等价类方法设计数据测试范围6） 如果没有以上测试依据，必须编写测试要点，也就是所有测试必须提前编写或想好测试点再测试举例：测试凭证审核1.单张审核2.成批审核3.按凭证类别过滤审核凭证4.按月份和凭证号范围过滤审核凭证5.按日期范围过滤审核凭证6.选择全部凭证审核7.查看所有作废凭证8.查看所有有错凭证9.按外部系统过滤凭证审核10.按制单人、审核人、主管签字过滤凭证审核11.联查明细账不能联查现金、银行科目只有有此科目查询权限的操作员才可查询12.审核人和制单人不能是同一个人13.若想对已审核的凭证取消审核，单击取消取消审核。取消审核签字只能由审核人自己进行。14.凭证一经审核，就不能被修改、删除，只有被取消审核签字后才可以进行修改或删除。15.审核人除了要具有审核权外，还需要有对待审核凭证制单人所制凭证的审核权，这个权限在基础设置的 数据权限 中设置。16.采用手工制单的用户，在凭单上审核完后还须对录入机器中的凭证进行审核。17.作废凭证不能被审核，也不能被标错。18.已标错的凭证不能被审核，若想审核， 需先按 取消 取消标错后才能审核。已审核的凭证不能标错。19.预算审批通过的凭证，只能进行审核，不能进行凭证其它操作。20.取消审核时，无论预算管理系统返回何值全部认为成功，系统只提示不进行控制。21.企业可以依据实际需要加入审核后方可执行领导签字的控制，同时取消审核时控制领导尚未签字。可在选项 中选中 主管签字以后不可以取消审核和出纳签字名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 5 页，共 17 页 - - - - - - - - - 第二节流程测试法（线测试法）依据产品功能相互之间的依存关系，以列表形式描述出功能的操作次序，主要检查功能节点之间的耦合情况。注意事项：1） 测试逆向操作2） 测试传输字段之间的数据类型、字段宽度的一致性3） 在测试之前要将所测试内容以清单形式进行列示，以便检查。举例：银行对账流程流程 1 1 银行会计科目指定2 结算方式设定3 部门、职员准备4 支票登记5 录入银行会计科目凭证6 银行科目凭证签字7 查询银行日记账（包含未记账凭证）流程 2 1 银行会计科目指定2 结算方式设定3 部门、职员准备4 支票登记5 录入银行会计科目凭证6 银行科目凭证签字7 银行科目凭证审核8 银行科目凭证记账9 查询银行日记账（不包含未记账凭证）10期初对账情况录入单位日记账情况银行对账单情况11本期银行对账单处理a)导入本期银行对账单b)录入本期银行对账单12银行对账13查询以下内容长期未达账项对账勾对情况银行存款余额调节表14核销已达账项名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 6 页，共 17 页 - - - - - - - - - 第三节项目测试法（面测试法）对被测试项目，检查系统提供的公用功能进行测试。比如功能权限、数据权限、并发测试、互斥测试、预警、审批流、单据格式、单据编号、自定义项、UFO 函数等注意事项：1.对任何一个产品而言，凡是涉及到得测试项目必须全面测试。2.注意平台公共部分改动对本产品的影响3.针对每一个测试项目都要有对应的测试方案举例：单据编号测试方案完全手工编号测试：测试特殊字符、极限、重号、单据查询中录入手工编号手工改动，重号时自动重取：测试前缀（测试要穷举）、规则、重号、单据查询中录入所有单据均要测到编号设置测试方案对照表测试方案流水号测试方案在以上三个测试方案中要体现以下内容：1.特殊字符2.编号极限长度3.重号4.前缀各种组合5.前缀与规则各种组合6.日期情况下考虑特殊日期、闰年、闰月7.单据修改保存后编号不能改变应收款管理单据名称完全手工编号手工改动 ,重号时自动重取按收发标志流水使用前缀其他应收单付款单收款单第四节参考测试法参考测试就是依据已经发生的测试活动结果，作为当前测试的依据。以此发现新的产品问题，一方面能过拓展测试思路，另外也可以检查当前产品问题是否还存在。有三种情况可以作为测试依据，它们是：（1）支持问题支持问题反映的是当前产品在不同版本中遗留的问题，检查当前版本是否还存在。因为同一产品进过多人开发和测试，每个人的开发思路与测试思路存在很大差异，同时对不同客户的使用也存在很大差异，完全测试全面，几乎是不可能的事情。作为测试工作，只能最大限度地降低产品问题。所以认真分析支持问题，并积累分类问题是完全必要的。在支持问题分析上，重点分析用户的应用场景，能够分析出客户的使用规律。（2）他人测试记录分析他人测试记录，主要分析他人的测试思路，尤其是数据错误和控制错误。因为每个人的测试结果都是名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 7 页，共 17 页 - - - - - - - - - 该人对产品的理解深度的体现，产品理解越深。（3）自己以前测试记录分析自己测试的问题，检查测试的不足，看一下还有哪些没有测试到。看一下自己的是问题的种类，是否还只停留在表面问题上。第五节高危模块测试法任何一个软件产品，影响它的质量因素有很多，其中最重要的是程序员能力。程序员的能力体现在两个方面，其一是编程能力；其二是业务知识能力。人无完人，为此必然在产品的某些方面存在更多的问题。所以在分析产品高危模块时，除去分析问题的集中区以外，还要分析人的因素，便于测试策略的决定。通过分析一个产品的所有问题，从数量方面统计出该产品问题发生的位置。检查测试方案是否有遗漏，重点关注，加强测试。在整个测试周期中，始终围绕高威模块进行测试，确保整体产品的稳定。分析产品问题性质，检查控制问题有多少，可以看出程序员对产品内容逻辑关系的掌握程度；检查数据问题多少，可以看出程序员对产品算法的掌握程度；检查其他问题多少，可以看出程序员的心细程度。高危模块的分析就是要由针对性地进行测试，弥补程序员的能力不足，使产品达到稳定状态，使客户用着放心。第六节业务模型测试法对于一个重要的软件项目，尤其是版本不断更新时，建立业务模型进行测试是十分必要的，这也是大多数应用软件非常关注的问题。由于建立业务模型非常困难，造成许多企业望而却步。首先明确一点，这是一件一劳永逸的事情。下面就建立业务模型进行分析。概念业务规则：业务结构和业务行为的约束。业务场景：从不同维度对业务的描述业务流程：业务规则与业务场景的结合点。这些点串联起来，形成业务流程。应用首先要建立业务模型，该业务模型与软件产品相匹配。可以这样理解，业务模型是大楼图纸，软件产品是大楼实体。图纸设计的质量好坏直接影响大楼的质量。软件测试就好比工程监理人员，在建筑施工过程中，依据设计图纸，对施工质量进行监控。有了上面的比喻，在分析业务模型测试法时就容易多了。步骤名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 8 页，共 17 页 - - - - - - - - - 第四章测试阶段设计理论上讲测试阶段的划分应该是如下次序：准备、单元、联调、集成、验收、用户测试、发版测试，但实际工作中由于多种因素的影响，这个标准次序随时会被打破，并且已被历版产品发版所证明。鉴于此种情况，测试阶段和各测试阶段所测试的内容就有必要认真设计。单元、联调两阶段目前在各测试组内完成，其余各阶段由测试部组织各测试组完成。优化各测试阶段的内容会提高测试效率，使产品及早稳定。准备阶段目的为某软件项目启动做准备，主要包括资源准备、相关文档准备阶段特征（1）准备越充分，项目实施过程越顺利。（2）培训、文档编写、审核、评审、考试等活动较多（3）招聘新人较多人员活动测试人员步骤（1）阅读、沟通、掌握产品定义与需求（2）按照标准格式编写测试要点与测试用例（3）评审测试要点与测试用例要点（1）测试要点与测试用例分为：单元和联调两类（2）单元类：以本版新增和变化为主。（3）联调类：以产品核心功能、接口、流程为主。（4）尤其注意相关接口产品变化和平台变化，必须体现在要点和用例中。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 9 页，共 17 页 - - - - - - - - - 测试经理步骤（1）安排测试人员阅读、沟通、掌握产品定义需求（2）组织编写、评审单元与联调测试用例（3）制定单元与联调测试计划（依据测试设计与新增用例）要点（1）用例能够确保被测试能容的全面性与正确性（2）测试资源能力能够保证项目的顺利实施（3）所有活动的过程控制符合公司研发规范工作内容当某个项目开始启动以后，做为测试部分要进行以下准备工作（1）确定测试内容（2）确定测试资源（3）编写、评审测试计划（4）编写、评审测试方案（5）编写、评审测试用例（6）测试、开发人员培训：业务知识与测试知识注意事项（1）准备不充分（2）测试资源考虑不周（3）人员变动频繁（4）资源分配不合理（5）所有活动控制不严，应付了事。测试设计步骤（1）依据本版新增内容，为单元、联调、集成三阶段提供详细测试要点及用例名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 10 页，共 17 页 - - - - - - - - - （2）主要设计：选项、功能、算法、流程、接口、年结、测试项目、应用场景等要点（1）设计要保证全面性，不能有遗漏。（2）便于测试人员执行操作（3）测试设计最小化：无论是要点还是用例，在设计时要坚持小、精、准的原则，尽可能避免大而全。（4）测试设计文档与产品开发同步变更，虽然目前我们也有需求变更，测试用例变更等开发制度要求，但是在此强调，是因为我们的工作由许多不尽人意的地方。如果测试要点与测试用例不能与产品开发同步，就不能保证产品完整测试。举例：A 功能对应A1 测试用例，产品开发一段时间以后，A 功能变成了A+ 功能，这时A1 测试用例应该变成A1+测试用例才对。场景测试设计目的（1）减少测试盲目性，有重点进行测试。（2）整理、分析用户数据情况，总结用户使用规律。（3）模拟用户测试设计要点（1）操作系统、数据库、IE 版本（2）IT 部署、产品启用（3）功能权限分布（4）数据权限分布（5）对用户数据进行分类（按业务范围、按数据量大小），按业务测试功能、按数据量测效率。单元阶段目的最小功能单元实现正确，满足产品定义、需求、开发设计、测试设计要求。本阶段主要以单产品测试为主，重点测试本版变化内容。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 11 页，共 17 页 - - - - - - - - - 阶段特征（1）因各开发进度不一致，开发次序会有不合理现象。尤其是平台进度有时会滞后业务组情况，造成结果是其他开发组无法进行开发，测试就跟谈不上了。（2）安装盘此时一般没有出来，或比较晚。可此时业务组已经完成部分代码。（3）此阶段时间相对联调阶段要长。（3）建议：A.开发及时调整开发次序B.安装盘及早完成C.不涉及接口与相关影响的先测试。D.随时了解相关变化与进度人员活动测试人员（1）建立测试环境。在安装盘没有出来前以新建账套为主。（2）替换文件测试新增内容（3）执行任务计划安排（4）分析当天结果测试经理（1）随时掌握各产品进度、与问题状况，监督代码质量。（2）编制、调整测试人员的任务计划（3）随时关注其他业务组产品（包括平台）对本业务组的影响。（4）随时向部门经理反馈开发次序状态与代码质量情况测试内容（1）本版新增内容（2）测试设计提供的内容注意事项（1）在确认平台、相关产品无影响下，测试设计提供的内容提前测试。（2）产品本事改动影响相关内容测试人员必须向开发了解清楚（3）产品安装盘出来后，检查升级脚本是否体现在安装盘中。如果有，就开始使用用户数据升级测试。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 12 页，共 17 页 - - - - - - - - - 联调阶段目的（1）产品内部最小功能单元之间数据传输或控制正确（2）产品间最小功能单元之间数据传输或控制正确本阶段主要以小集成测试为主，启用关联产品，重点在接口、流程测试、应用场景测试。在场景测试中完成接口、流程测试。在这个阶段不在是以本版变化为主，而是强调产品的整体功能稳定性、效率提升性。（3）本阶段是集成阶段的重要保证，联调做的好与坏直接影响集成测试的效果。阶段特征（1）各产品因改动范围不同，进度快慢不同，不会同时进入联调状态，而且不能人为控制。（2）此时安装盘已经进入稳定期，注意相关影响产品进入联调情况。（3）相关产品接口、平台影响测试进入重点区域（4）该阶段测试以小集成测试为主。（5）在功能稳定、接口稳定情况下进行全面测试，以备提交集成测试人员活动测试人员（1）将具有相关接口的产品组织在一起，进行小集成测试。以前是单兵作战，相关产品接口数据考虑简单。这样做风险相当大，相当于复杂接口变化全部转移到集成阶段测试去了。（2）使用安装盘进行测试（3）执行任务计划安排（4）分析当天结果测试经理（1）关注进入联调状态产品的先后次序（2）测试资源要全力保障（3）任务安排以全面新、稳定性为主（4）将风险尽最大可能控制在联调阶段测试内容（1）测试新功能（2）测试产品内部接口（3）测试产品间接口（4）测试平台影响名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 13 页，共 17 页 - - - - - - - - - （5）测试测试项目注意事项（1）测试的全面性、性能的稳定性是重点（2）文档齐全，尤其是各类报告。（3）效率单独测试，越早越好集成阶段目的（1）检查产品各组成部分，在不同IT 部署情况下，整体运行情况。（2）在新建和用户数据基础上，核心功能、流程、接口、年结、效率在此阶段进行全面验证。（3）所有测试项目得到验证（4）所有主要旧版本升级到当前版本，升级数据得到验证。（5）并发使用系统每一部分功能，检查系统功能互容性。（6）依据效率测试设计内容进行效率测试阶段特征（1）此阶段工作是以测试部任务安排为中心，具体何时开始集成测试完全由测试部决定。一般是大部分产品达到集成状态以后，就开始进行集成了。（2）测试方案由测试部统一编写（3）测试计划由测试部统一制定（4）测试组人员此时完全受控于测试部（5）根据需要可以将测试资源进行合理分配（集成内人员、集成外人员）（6）此阶段工作的好坏，完全取决于此阶段的任务计划安排和执行力度人员活动测试人员（1）按照测试部下发的测试任务在规定的时间内进行测试。任务设计的好坏直接影响测试效果。（2）目前状态：任务设计太粗线条了，测试人员很难深入测试，月结和年结基本上是每套集成账检查重点。在这过程中测试痕迹无法分析。人员座位分散，测试经理监控自己人员，但参与控制的不多。（3）建议：任务由专人进行设计和分配。每套账的任务执行要执行监督和分析。目的是了解测试任务执行情况（覆盖范围、执行深度）名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 14 页，共 17 页 - - - - - - - - - 测试经理（1）参与集成测试方案编写与评审（2）集成问题分析（3）进行测试进度控制（4）负责本领域产品流程和接口测试（5）监督测试人员任务执行测试内容（1）老版升级测试，检查当前版本升级脚本是否正确。特点是升级样本要足够多，以避免本版新增功能对数据库结构的影响，从而造成用户无法进行产品部分功能。升级样本数量要根据客户群多少来确定，目前没有合理的进行设计。（2）每套集成账具体测试内容在集成测试之前就已经编写、评审完成。测试执行阶段，由账套测试负责人编写测试计划、由各测试经理进行测试任务分配。（3）测试人员依据测试任务进行测试。目前存在的问题：（1）用户场景测试深度不够，原因是分配任务较多，准备数据时间长，每一套集成账测试时间较短，新人多，有经验的人少。反应在测试问题上是：表面问题较多，深层的接口问题，数据问题较少。（2）产品间测试配合不充分，测试人员对相关产品了解只是基本功能，产品应用场景了解很少，致使深层次应用问题很难挖掘。（3）测试项目验证比较分散，没有集中验证，完全可以指定某一个人完成的项目就不要动员全部人员参加。1.1.1 业务规则依据业务规则组织(BRG ，BusinessRulesGroup)定义：“ 业务规则是支持企业决策，影响或控制企业业务行为的指示 ” 。业务规则是对业务结构和影响业务行为的一种约束，它说明在指定情况下必须做什么和不做什么。业务规则具有完整性与一致性等特性。完整性是指单个规则作为一个整体发挥作用，而一致性是指在业务活动中规则自身不发生变化时，相同输入条件导致相同输出结果。业务规则的这些特性为基于业务模型生成测试用例提供必要条件。1.1.2 场景场景是由一系列相关状态组成。它描述软件系统的运行状态，反映软件功能的任务剖面。场景最小单位是原子场景。这些原子场景的输入与输出能从系统外部环境直接施加和截取。原子场景是不可再分且独立可测的。多个具有紧密关系的原子场景能组合成子场景。子场景又可以组合成为代表了被测系统功能包的复合场景，它反映了系统更高层面功能集合。场景可以抽象表示为一个五元组：S=(IV ，OV ，PC，P，F)，其中， IV、OV、 PC、P、F 分别代表了场景的输入集、输出集、前提条件、优先级与场景功能描述。1.1.3 业务流程名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 15 页，共 17 页 - - - - - - - - - 业务流程是业务模型中业务规则与场景的结合点。业务流程是一组将输入依据业务规则转化为输出的相互关联或相互作用的活动。业务模型使用场景描述业务流程，说明软件系统如何解决用户业务问题。业务流程是从用户角度对系统的动态描述。场景是从开发人员角度对系统静态分析，使用静态场景描述动态业务流程，必须补充场景转移关系。场景转移关系包括“ 顺序 ” 、“ 循环 ” 、“ 判断 ” 与“ 并发 ” 。1.2 基于业务模型的软件测试过程软件测试过程一般有计划、设计与开发、实施、评估4 个阶段，业务模型可以完全融合到软件测试过程中，并贯穿整个软件测试过程。1.3 测试用例的生成在业务模型的业务流程与测试用例集的测试用例之间建立联系，根据业务流程要素确定测试用例要素：根据业务流程标识确定测试用例标识符。根据业务流程步骤确定测试用例步骤。根据业务流程关系场景的前提条件确定测试用例前提条件。根据业务流程关系场景的输入集合确定测试用例输入集合。根据业务流程关系场景的输出集合确定测试用例输出集合。业务流程一般包含多个场景，场景之间转移关系也较复杂，这些复杂性不利于测试用例生成。因此，在生成测试用例前，需要根据简化原则简化业务流程的描述与场景转移关系。业务流程简化原则包括：原则 1：子图分解原则。将一个业务流程分解为若干个子流程，分解前后的流程是等价的。原则2：循环活动简化原则。对于可多次重复的活动，规定活动重复的最大次数，以避免发生死循环。原则3：并发活动简化原则。如果两个并发活动之间相互独立，可任选一个执行顺序，以串行方式执行活动；如果并发活动在条件满足时，必须同时执行，则将活动合并。原则4：场景简化原则。对较大系统进行分析时，会造成一个测试场景过于庞大，因此，可划分出系统的子场景。这些简化原则，将复杂的业务流程转化为只包含顺序关系场景的业务流程，提高了测试用例的质量。1.4 测试用例执行顺序的确定当测试资源有限时，不仅要考虑测试用例是否覆盖所有被测功能，更要制定合理测试用例执行顺序，降低 “ 测试逃逸 ” 风险。测试用例执行顺序可以通过业务模型的场景优先级确定。场景优先级的获得有静态分析与动态调整两种方法。静态分析是在建立业务模型时，通过软件失效模式和影响分析(SFMEA ，softwarefailuremodeandeffectsanalysis)为场景静态分配优先级；动态调整是在软件测试过程中，根据软件质量特征再次进行SFMEA 分析，动态调整场景优先级。测试用例可以通过与业务流程之间的联系，以及SMF 获得场景优先级，为确定测试用例执行顺序提供有力依据。2、实例应用名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 16 页，共 17 页 - - - - - - - - - 某信息采集系统在试用过程中，用户反馈由于信息录入员提交的信息有误，系统中经常存在一些无效信息。为避免该问题，用户提出增加“ 提交审核 ” 业务，即信息录入员提交的信息经管理员审核通过后，才可进入信息采集系统。该项目开发采用敏捷方法，业务模型在项目需求获取阶段已建立。为尽快响应用户需求，软件开发设计与测试设计同时开始，测试人员使用业务模型驱动测试活动，并贯穿整个测试过程。2.1 测试计划阶段2.1.1 业务规则该阶段主要修改内容是向信息录入业务规则添加子规则信息审核。2.1.2 场景增加信息审核场景。2.2 测试设计与开发阶段略2.3 测试实施阶段根据场景优先级可以计算出测试用例的优先级TOP 值(在关系场景中， 单个场景优先级最高值)与 AVG值(所有关系场景的平均值)等值。2.4 测试评估阶段在测试评审阶段，根据业务模型判断软件测试风险，评估软件质量。最后，根据测试结果，对业务模型的场景优先级进行动态调整。例如：由于测试用例TCF11 通过测试， 则可调低该测试用例关系场景的优先级3、结束语本文在对相关基本概念进行说明的基础上，提出了基于业务模型的测试过程，并重点阐述了测试用例生成及其执行顺序的确定方法。最后，将研究成果应用于实际软件系统的测试实践，证明了本方法的有效性和正确性。在下一步研究中，将业务模型与自动化测试结合，设计一个基于业务模型的测试管理系统。随着软件工程的发展，软件行业对测试越来越重视，只有不断的探索、实践新的软件测试理论与方法，才能高效率完成测试任务，保证测试工作的有效性与可信性。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 17 页，共 17 页 - - - - - - - - -