测试计划与测试用例

测试计划与测试用例（13篇）

1.测试计划与测试用例 篇一

一、测试计划的有效性和全面性

无论做什么工作，都是计划先行，然后按照所制定的计划去执行、跟踪和控制。软件测试也一样，先要制定测试计划，是做好整个测试工作的前提。所以在进行实际测试之前，应制定良好的、切实可行的、有效的测试计划。软件测试计划的目标是提供一个测试框架，不断收集产品特性信息，对测试的不确定性（测试范围、测试风险等）进行分析，将不确定性的内容慢慢转化为确定性的内容，该过程最终使得我们对测试的范围、用例数量、工作量、资源和时间等进行合理的估算，从而对测试策略、方法、人力、日程等做出决定或安排。

1．测试计划的要点

测试规划与软件开发活动同步进行，在需求分析时，就开始测试策划，确定测试需求、目标、资源等。测试计划可以按不同的测试阶段（集成测试、系统测试等）来组织，也可以为每个测试任务或目标(安全性、性能、可靠性等测试)进行考虑。

测试计划主要集中在测试目标、质量标准、测试策略、测试范围、测试用例设计方法、所需资源和日程安排等，其关键是制定有效的测试策略，界定清楚地测试范围，识别出测试中所存在的各种风险并找出风险回避、监控和管理的方法，针对不同的测试目标或阶段确定测试方法，对测试工作量及所需的资源、时间进行合理的估算。所有这些，都是为了两个根本目的：测试的质量和效率。

2．制定测试策略

制定测试策略主要分析测试的目标和质量指标、确定测试的对象和依据，测试的重点和所采用的方法，包括在规定的时间内哪些测试内容要完成，软件产品的特性或质量在哪些方面得到确认。测试策略可以分为：

基于测试技术的测试策略，根据软件系统的技术构成和层次结构，着重考虑如何分层测试、选择哪些测试工具、如何将白盒测试和黑盒测试有机地结合起来等。

基于测试方案的综合测试策略，根据测试的目标和范围，着重考虑如何更好地满足测试需求、如何让功能测试、适用性测试和兼容性测试等进行有机结合、如何充分利用测试资源、如何更有效地完成回归测试等。

为了更好地制定好测试策略，要做到：

全面细致地了解产品的项目信息：应用领域、测试范围、市场需求、产品特点、主要功能和技术架构；

基于模块、功能、系统、版本、性能、配置和安装等各个因素对产品质量的影响，客观地、全面地展开测试计划；

根据软件单元在系统结构的重要性差异和一旦发生故障将给客户造成的损失大小，来确定软件测试的等级、重点和先后次序；

需要在测试用例数和测试覆盖率上进行权衡而获得一个平衡点，以便能使用尽可能少的有效测试用例去发现尽可能多的程序错误。测试不足意味着让用户承担隐藏错误带来的危险；同时反过来看，过度测试则又会浪费许多宝贵的资源或耽误软件产品的发布时间。

3．确定测试范围

测试主要依据 “产品设计规格说明书”、代码所发生的变化及其影响的区域，来确定哪些功能和特性要测试，哪些功能和特性不需要测试。在确定测试范围时，主要考虑的因素有：

优先级最高的需求功能

新增加的功能和编码改动较大的已有功能

容易出现问题的部分功能

过去测试不够充分的地方

经常被用户使用的功能和配置（占20%）

4．所需资源和日程安排

为了合理、准确地安排日程，对测试工作量要进行正确的估计。除了对工作量的估计之外，还要正确评估参与该项目人员的培训时间、适应过程和工作能力等。由于涉及到不同的项目、不同的测试人员、不同的前期介入方式，要对每人每天能够完成的平均测试用例数目做出一个准确的估计确实很困难，但是可以根据以前一些项目测试的经验或历史积累下来的数据进行判断推理，并适当增加10%-20%的余量，估算结果就比较准确了。

在估算的基础上，进行有效的、合理的资源安排。在不同的测试阶段人力资源的需求是不一样的，所以人力资源的计划要有一定的灵活性和动态性，形成有机的动态平衡，保证测试的进度和资源的使用的效率。

5．编制测试计划的技巧

要做好测试计划，测试设计人员要仔细阅读有关资料，包括用户需求规格说明书、设计文档等，全面熟悉系统，并建议注意以下方面：

让所有合适的相关人员参与测试项目的计划制定，特别是在测试计划早期；

测试所需的时间、人力及其它资源的预估，尽量做到客观、准确、留有余地；

测试项目的输入、输出和质量标准，应与各方达成一致；

建立变化处理的流程规则，识别出在整个测试阶段中哪些是内在的、不可避免的变化因素，加以控制。

6．测试项目计划的评审

测试项目的计划不可能一气呵成，而是要经过计划初期、起草、讨论、审查等不同阶段，才能将测试计划制定好。测试计划的评审是完成测试计划关键的一个环节，包括测试组织内部的自我评审、讨论和修改，然后交到评审会进行正式的评审，直至测试计划得到审批。

测试计划的正式评审，项目中的每个人（产品经理、项目经理、开发工程师等）都应当参与。计划的审查是必不可少的，每一个参与者都可能根据其经验及专长提出问题或建议，弥补在测试范围、工作量、风险等各方面的不足，进一步完善测试计划。

二、测试用例在测试活动中的作用：

1.强化测试用例在测试活动中的作用

测试用例在实际中没有起多大作用 , 在实际测试时根本没有按测试用例执行，测试执行后没有把新的测试用例补充到用例库中等等。

为何如此？ 根本原因是对测试用例重要性的认识不够，测试流程不完善，针对测试用例的管理流程更不完善，其实，从三个方面具体来说：

1）测试用例的重要性是毋庸置疑的，它是软件测试全部过程的核心，是测试执行环节的基本依据，如果这个依据不能足够发挥它应起的作用，那是不是说这个依据不明确、依据设计的不合理呢？答案是肯定的！

2）制定了完备有效的测试用例，为什么不按测试用例执行测试呢？首先是因为企业没有严格和良好的机制促使和保证测试执行者这样做；其次是个别测试人员投机取巧心理作祟的表现。

3）测试用例设计得不可能天衣无缝，不可能完全满足软件需求的覆盖要求，测试执行过程里肯定会发现有些 测试路径或数据在用例里没有体现，那么事后该将其补充到用例库里，以方便他人和后续版本的测试；如果没有这样做，那么测试部门负责人和每个测试员都难辞其疚，是该重新坐下来思考一下公司的测试用例管理规范和测试流程了。

2.改进测试用例执行过程

那么究竟如何做，才能尽量避免上述问题呢？

我们不妨从软件开发周期的每个阶段就把这些问题考虑进去，以便从初始就力争将问题缩到最小，将问题扼杀在萌芽阶段。

1）软件需求分析阶段，测试人员从软件生命周期的需求阶段就开始介入。通常测试人员的测试工作开展在开发周期的末尾，如果前期不涉入，如何通晓整个系统的需求和架构而对其充分测试呢？

项目的测试负责人和测试工程师在 需求阶段 的任务有：

a.参与软件需求调研，以测试角度分析需求的可测性，可构思将来对其测试的方法、原则等；更重要的是，对不可测或难以测试性问题要及时与客户或项目经理协调解决。

b.全面了解系统需求，从客户角度考虑软件测试需要达到的验证状态，即何些功能点需重点测试、何些无需，以便将来制定测试计划。

2）软件分析设计阶段：

l 测试人员除制定测试计划书等基本工作外，还有一个相当必要的任务，那就是将系统的可测性落实到书面文档，以备将来编写测试用例。（之所以要这么做，是因为考虑到很多企业编写测试用例直接参考需求规格说明书或者分析流程图，这样跨度大，难度也大，是造成测试用例不完备、覆盖范围小的重要原因）。

l 测试人员更要编写一份《软件功能点测试描述书》，它是软件的详细测试分析文档，其主旨是将系统分析人员的开发分析文档加工成以测试为角度的功能点分析文档，重要的是描述对系统分解后每个功能点逐一的校验描述，包括何种方法测试、何种数据测试、期望测试结果等，这些信息都是描述性的，无须具体数据；它的作用是据此编写测试用例，以及测试执行时的参考依据，基于它直接来源于需求，覆盖当然最全，也最能贴近客户要求。

l 当然该文档不是非要不可，如果有类似的替代文档或有工具可自动实现此功能，则会倍加受推崇！

3）软件开发阶段： 编写测试用例。应该遵守的原则是：

n 首先，从覆盖率来说，测试用例库的用例要达到最大覆盖软件系统的功能点。编写测试用例时，基本上就是将《软件功能点测试描述书》中的每个功能点进行操作上的细化：一是从步骤上描述到达校验点的方式，二是从内容上描述以何种数据校验功能点；如此可实现趋向最大需求覆盖率。

n 其次，从数量来讲，一个多于半年开发周期（指从编码开始直到提交客户的时间段）的软件系统，它的用例数量不要低于 4000 个，甚至更多！（IBM 等大公司测试过程的人士会认为 4000 还是很少的数目。我们试想，对于一个中小型软件系统，如果设计出 5000 个用例，那它的测试覆盖率还怕不高么）！

n 再次，如此众多测试用例的管理问题。是的，最好是需要测试用例管理工具软件。以 word 或 excel 来编写测试用例也可以。）测试用例 格式上一般内容以外的几个要点：

l 制定适合本公司的测试用例模版；

l 是用例模版里要有关键字索引，以方便按关键字分类查找，如测试方法（分手工 / 自动两种）；

l 是测试用例要有 状态跟踪，可根据用例执行状态索引用例（测试通过、测试失败、测试中断等）；

l 是执行失败的用例要 链接到相应的缺陷报告，如有根据缺陷报告检索测试用例的试图更妙，可评估该缺陷影响范围的大小；

l [FS:PAGE] 是测试用例的修改，以及每个测试周期的运行都有 日志记录，以便后期追踪

和新员工参考；）软件测试阶段，测试负责人划分不同的测试阶段（如集成测试、系统测试、回归测试、性能测试等），再划分不同的子测试周期（如前两个星期做 冒烟测试，测试方式是手工 / 自动，测试版本是 **，测试环境是 **，包括服务器端与客户端等；接着做第一模块功能测试；如此顺次。），再为项目组测试人员分配测试用例（通常原则是每个人负责几块区域的测试任务），测试人员则按照详细的用例文档去执行测试，测试失败则提交软件缺陷报告。这里要遵循的几个原则是：

A）有健全且严格的体制保证测试执行者严格按照测试用例执行测试。这并不妨碍测试者创造力的发挥，因为前期用例的设计和编写就是项目全体测试人员智慧的结晶！我们一直苦苦追寻众多测试工程师加班加点辛苦工作的原因，其实大都发生这一阶段；如此实施，即便没有解决根本问题，也会大大提高测试执行效率。

B）如有对测试用例认识模糊或内容遗漏的地方，可暂做记录待后期解决，或经测试负责人与项目其他管理人员同意方可更新用例库。

C）测试负责人每日负责跟踪本测试子周期或阶段的测试用例执行情况，以及每日提交的缺陷报告，根据执行进展状态以及缺陷数量或严重等级与项目高层或其他人员展开交流，商议解决途径，并确定或调整未来时间的测试任务。

D）测试执行者负责执行自己区域的测试用例，还要负责跟踪该区域软件缺陷的修改进展，根据其状态 不断验证软件功 能点。

E）通过缺陷管理工具来 管理软件缺陷 ；这样的集成工具都提供了清晰的报告模版及强大的追踪功能，测试团队的每一成员按照自己的角色和权限访问缺陷管理工具，并不断跟踪软件缺陷的状态。

F）对于自动测试（包括自动化功能测试和性能、压力测试），有一些特殊要点。是自动化测试无须编写测试用例，只要在编写时将用例库里适合或需要自动测试的用例的测试方法（不同工具可能名称不同）设为自动即可，故而到此阶段才提及自动化测试。自动化测试的实施方案有所不同，每款测试工具的使用和测试流程也不同，但都可以从在这一阶段编写测试脚本，并运行自动测试。这里要提的其他几个基本原则是：

l 是选择恰当的测试工具品牌，并要求提供培训；

l 是项目的自动化测试工作有专人负责跟踪，以保证工作质量，他们可不参与日常测试；l 是确定自动化测试成员在项目中的角色，一般自动化测试成员隶属于项目测试负责人，负责人同样跟踪其工作状态；

l 是选择最简单、最重用的测试用例使用自动测试方法；

l 是使用工具厂商提供的测试框架编写脚本，千万别采用单纯录制回放的方式，要开发出健壮且重用性强的测试脚本 ；

l 是有专人更新脚本，也有专人跟踪自动测试结果；

l 一般选择的测试工具品牌和缺陷管理工具品牌是同一厂商，以方便不同类型缺陷的集中管理；

l 是在多人协作开发测试脚本、代码量相对较大情况下，应考虑使用配置管理工具来管理测试脚本。）由于不同公司开发产品的特殊性，也许需要特殊类型的测试，如安全测试、甚至代码级单元测试等，这些内容需要酌情考虑测试用例的编写，以及测试的执行。）软件验收阶段 ：除了提交软件测试评估报告（各种类型测试结果的评估都应有报告）这些基本工作外，对于测试用例，此时要集中时间更新，更新整个测试周期中一切需要更新的内容，以方便未来新版本的测试。即便您开发的是项目软件--提交客户后没有新版本--那也需要后期维护，维护阶段需要重新测试某功能点，然而用例如果不准确，碰巧又是一个

新员工来做，那就死翘翘了！）其他说明：加强测试部门内部人员的培训教育很重要，包括工作技能与个人素质两方面，可通过国内主要的培训机构，也可是购买工具厂商的直接培训。应该说，很多测试新人对于测试用例的书写还存在问题，更别提及测试用例的管理或执行；以此可见，我们的测试工程师需要培训的空间还很大。

3.总结

综上所述，我们得出结论--测试用例在测试中没起到应有的作用，是因为测试用例编写质量不高，覆盖不够，执行不利；测试执行时不遵循测试用例，执行后不更新用例库，是测试部门的整体工作流程不健全、不规范。

2.测试计划与测试用例 篇二

软件测试是软件生命周期中的一个重要阶段。软件测试作为软件质量保障的关键部分,已经变得越来越重要。在进行软件测试时,一般是先确定测试需求,根据测试需求生成相应的测试用例集,在软件被修改后通常还要进行回归测试,以确保修改后的程序不会产生回归错误(即修改了旧的错误同时不会产生新的错误)。对于一个中、大型软件,则会产生相当惊人数量的测试用例,并且在回归测试中需要反复地使用测试用例集。为了提高测试效率,降低测试成本,一个优化的测试用例集是至关重要的,这个优化过程需要贯穿到整个用例的生成和使用过程中。

1 求解测试用例集优化问题的方法初探

测试用例集优化问题包括用例约简和用例排序问题。测试用例约简技术,就是在原始用例集中找到一个较小的测试用例子集,并能够提供与原始测试用例集一样的测试覆盖率[1]。目前已有诸如启发式方法、整数规划[2,3]方法和需求驱动等一系列测试用例集约简方法。这些方法具有不同的特性,适用于不同的测试对象[1,4]。此外,与测试用例集约简问题相关的错误检测效率问题也得到了研究人员的关注,这类问题需要考虑各种因素造成的测试用例重要程度区别,为每个测试用例赋予一个选择优先级,按照优先级次序对测试用例进行排序,使得高优先级的用例先执行,从而达到较高的检错效率和较快的检错速度。

1.1 启发式约简方法

启发式约简方法主要有贪心算法、GRE算法和HGS算法。贪心算法逐次从测试用例集中选择能最多满足测试需求的测试用例,直到所有测试需求都能被满足。该算法的时间复杂度[1]是Ο[mnmin(m,n)]。GRE算法在贪心算法中加入了反复交替必不可少策略和1-1冗余策略,该算法的最坏时间复杂度[5]为Ο[min(m,n)(m+kn2)]。其中:k表示一个测试用例最多能满足的测试需求数量。

HGS算法[1]是Harrold等人提出的一种根据测试用例的重要性进行选择的启发式算法。该算法首先将测试需求r1,r2 ,…,rm分成集合R1,R2,…,Rd(d≤n),其中:Ri(i=1,2,…,d)表示所有正好可以被T中i条测试用例满足的测试需求。显然,满足R1中测试需求的测试用例是必不可少的,一定要加入到约简集中。因此,该算法首先挑出必不可少的测试用例,再考虑R2中未被满足的测试需求,选择测试用例使之尽可能多地满足剩余的测试需求,直到R2中的测试需求全部被满足,然后依次处理R3,R4,…,Rd。其最坏时间复杂度[1]为Ο[m(m+n)d]。

1.2 非启发式约简方法

J.G.Lee,C.G.Chung等人在1999年提出的整数规划方法是启发式算法的重要补充,该方法适用于多种约束条件、适应值函数和测试充分性准则,在理论上可以获得满足测试需求集R的最小测试用例集,但计算复杂程度较高,运算开销呈指数级增长,在实际应用中存在一定的局限性。此外,还有一些智能算法,如遗传算法及混合遗传、粒子群算法等都被用到用例集的约简中[6]。由于遗传算法本身存在局限性,如过早收敛、优化效率低等问题,因此它只能在短时间内找到接近全局最优解的近似解,而不能保证收敛到全局最优解。这个局限性可以通过混合其他算法得到改进。

上述方法各有优劣,任何一个方法都可以获得测试用例集约简问题的近似最优解,但均无法保证获得最优解。

1.3 排序算法

测试用例集的排序就是优先级的排序,关键是优先级的设置。目前关于优先级技术的研究主要集中在根据测试历史计算测试用例的选择优先级。Wong等人最先提出在回归测试选择技术基础上对测试用例集最小化,或者优先级处理,通过判定累计覆盖率[7,8]等问题对测试用例进行排序,但是这种方法考虑的测试历史因素过于单一,为此Elbaum和Rothermel等人基于测试用例执行信息,将测试历史及动态反馈信息用于计算测试用例选择概率[9,10],从语句覆盖、分支覆盖和检错能力等方面提出了改进算法。Kim等人在已有回归测试研究的基础上指出应将回归测试视为一系列有序的行为序列,提出综合考虑各种测试历史的优先级技术[11]。

1.4 评估方法

现在广泛使用的是G.Rothermel等人提出的APFD评估方法。该方法能够有效评估优化测试用例集的平均检错效率。假设测试用例集T含有n个测试用例,待检测的程序含有m个错误,则APFD的定义为:

$\text{A}\text{Ρ}\text{F}\text{D}=1-({\displaystyle \sum _{i=1}^k{\rm T}}F{}_i)/nm+1/2n$

式中:TFi表示T检测到错误i的第一个测试用例在T中的位置。

由等式可知,APFD值介于0和100%之间,并且APFD值越大,其错误检测效率越高。在此基础上S.Elbaum等人还提出了改进的APFDC方法,用于评估当错误严重等级和测试用例开销不同时,给定优化测试用例集的平均错误检测效率。这里将在最后提出测试用例排序改进算法,且应用以上公式验证其优化效果。

2 本文工作

现有的测试用例优化技术有着各自的特点和适用域,都在测试的某个阶段做出了优化,但它们都忽视了测试需求的约简,测试用例的生成,测试用例的约简,以及优先级排序这4个步骤的整体性,应该在测试过程中不断调整用例执行顺序[12],使测试用例集更好地适应当前测试环境。下面就这里关注的测试用例集优化两个方面,讨论测试需求优化和测试用例优先级问题,并提出改进算法。

上述方法都是直接由测试需求生成测试用例的,没有对需求进行预先分析,事实上有些需求之间存在一定关系[13],如果事先充分挖掘,使用测试需求的相关信息,减少待处理的测试需求数量,降低测试需求间的复杂度,便可以有效生成和约简测试用例集[2,14]。用图1简单表示测试需求间的关系。

对于图1所示的测试需求集R={r1 ,r2 ,r3 ,r4 ,r5 },r1 与其他任何需求都不相交,是必不可少的测试需求,必须保留;对于r2 ,r3 ,r4 ,r5 ,由图可以直观地得到满足r2 ∩ r3 的用例一定满足r4 ,r5 ,故精简后的测试需求集为R′={r1 ,r2 ∩r3 }。由此提出如下测试需求的约简算法:

输入:原测试需求集R

输出:精简测试需求集R′

R′=R; //初始化

R''=∅ //初始化

Pair={(ri,rj)|ri,rj∈R(i,j=1,2,…,m,i<j)} //构造测试用例对逐次遍历Pair

For each ri(i=1,2,…,m)

For(j=i+1;j<m;j++)

If(ri∩rj=∅)

R″={ri}∪R″ //ri和其他需求两两独立,是必不可少的需求,必须保留

End if

End for

End for

While(Pair≠∅,从Pair中取出一个元素(ri,rj);

Pair=Pair-{(ri,rj)};

If(ri⊂rj||ri=rj)then

R′=R′-{rj};

Else if(rj⊆ri)then

R′=R′-{ri}; //等价的需求只保存一个;保留被包含的需求

Else If(ri∩rj≠∅&&ri≠rj&&ri,rj不存在包含关系)

R″={ri∩rj }∪R″ //那么保留ri∩ rj

R′=R′-{ri,rj} //相交关系的需求只保留重合部分

End if

End while

R′=R′∪R″ //输出精简后的需求集R′

基于这个思想,所有的测试需求均可精简成为两两独立不相交的关系,再针对R′中的每项测试需求生成测试用例。这样得到的测试用例集是被约简的,并不是优化的。一个优化的用例集必须包括合理的执行次序,使得检错率高的用例先执行。

现有的优先级赋值方法都是基于历史覆盖率和程序员的自身经验,基本上属于一次赋值,不能有效利用测试过程的动态反馈。在此借用黑盒测试的等价类方法对测试用例的排序做出改进。所谓等价分类法,就是把输入数据的可能值划分为若干个等价类,使得每一类的任何一个测试用例都能代表同一等价类中的其他测试用例。也就是说,如果从一个等价类中任意挑选一个测试用例未能发现程序的错误,就可以合理地认为在该例中其他测试用例也不会发现程序错误。文中的改进算法就是基于等价类的思想提出的。由精简后的测试需求生成的测试用例覆盖多个测试需求的可能性大大降低,不失一般性,假定每个测试用例只覆盖一个测试需求。

为了便于叙述,需要给出相关的定义:

在测试用例集T={t1,t2,…,tn}中,如果ti,tj∈T且ti,tj覆盖相同的测试需求,则称ti,tj相似,记作ti~tj;

定义测试用例集T={t1,t2,…,tn}的关联矩阵是n阶布尔方阵,其中方阵的元素ki,j=1,当且仅当ti~tj,否则,ki,j=0;

测试用例集的排序算法为:

输入:由精简测试需求集R′生成的初始测试用例集T

输出:排序后的测试用例集T′

前期准备:由测试用例集构造关联矩阵A(ai,j)

Sort(T) ; //按测试历史测试经验或覆盖率进行初始排序

For each ti (i=1,2,…,n)

(1) If (ti检测出错误)

For (j=i+2;j++;j<=n)

While(ai,j=1)

将tj 优先级设为最高,其余用例优先级加1

End while

End for

(2) If(ti未检测出错误)

将ti优先级设为最低,其余用例优先级加1

For(j=i+2;j++;j<=n)

While(ai,j=1)

将tj优先级设为最低,其余用例优先级加1

End while

End for

3 算法有效性评价

与已有算法相比,新算法综合考虑了测试历史和测试过程中的反馈信息。动态调整剩余用例的优先级,可有效地提高检错效率。同时,因为根据测试历史,这种算法的平均时间复杂度只与测试用例的数量有关,为Ο(n2)(n为测试用例数),与程序的规模无关。因此这种直接调整优先级,一次遍历便得到较优的序列集,排序效率是比较高的。

下面举出具体例子,说明文中提出的测试用例排序算法的优越性。

假设程序P含有10个错误,测试用例集T含有9个测试用例,测试用例集T所检测到的错误情况如表1所示;假设已知T3~T8,T6~T7,显然,顺序执行直到T3才会检测出错误,因此需要调整测试用例的执行顺序。由于T4,T7,T8可以检测出全部的错误,按照测试经验和已有的排序算法,可得到序列如下:T4-T7-T8-T1-T2-T3-T5-T6-T9。显然,这个次序能比顺序执行更早地检测到程序的错误,但并不是最优的。然而应用该文提出的排序算法得到的测试序列为:T7-T8-T3-T4-T5-T6-T9-T1-T2。由上文提到的评估公式得到改进算法的测试用例序列APFD值为0.82,而原测试用例序列APFD值为0.80,根据APFD的值越大其错误检测效率越高的评估标准,改进算法能够有效地提高测试用例的错误识别能力,同时显著提高识别速度。

4 结 语

这里将测试过程视为整体,将测试需求、用例约简,以及优先级技术相互结合,提出了优化策略。与已有算法相比,新算法综合考虑了测试需求之间的关系以及测试用例的关系,因此精简后的需求相互的独立性,使得用例之间的关系更加明确,这种明确性大大简化了用例之间可能存在的复杂联系。另外,新算法是在假设一个测试用例只覆盖一个测试需求的基础上提出的,在实际测试工作中,每个测试用例不仅覆盖一个需求。如何将测试用例覆盖问题加入到优先级技术和约简技术中,同时当测试需求发生变更,如何利用测试需求关系、测试历史等信息优化测试用例,即进行回归测试则是未来工作的重点。

摘要：测试用例集优化技术是软件测试的重要组成部分,对回归测试检测效率影响巨大。针对给定的测试目标,获得精简的测试需求集和测试用例序列集,有助于提高测试用例集优化的效率和效果。首先介绍了测试用例集约简问题的基本概念,对现有的各种约简方法进行分析比较,接着讨论了测试用例的优先级排序问题,最后提出将测试用例约简技术和优先级技术结合起来,提高用例检错效率和缩小用例空间的优化策略,文章还引入等价类和快速排序思想,动态调整测试用例序列,并通过实验证明该改进是行之有效的。

3.回归测试中机器挑选用例方法研究 篇三

【关键词】机器学习；回归测试；测试用例

1.引言

机器学习（Machine Learning， ML）是一门交叉型学科，它涉及到了多个领域，包括：概率与统计学、高等数学、逼近和凸分析等。机器学习人类的学习过程和学习行为，并且加以计算机的模拟或实现。在机器学习过程中，机器本身了获取新的知识或技能。

在机器学习和人工智能的壮大发展的时代背景，对传统的测试工作提出了一些新的挑战。研究通过机器学习的方法，提升传统的测试工作的效率，进一步的提高整个软件开发活动的劳动生产率。

2.软件测试工程的研究综述

软件测试是用于分析是否程序出现错误的过程，测试使用人工操作或者软件自动运行的方式。每个不同的软件有对自身错误的定义方式：通常是软件需求规格中定义了预期结果。

软件测试分类

1、从是否要变异/执行被测试软件分类，分为静态测试和动态测试。如基于代码审查的单元测试，以及相关代码审查工具，都属于静态测试的范畴。

2、从是否要针对软件结构、算法进行覆盖分类，分为白盒测试和黑盒测试。

3、从测试活动在软件开发过程中所处的不同阶段分类，分为单元测试、集成测试、系统测试、验收测试。

我们这里讨论的“回归测试”是属于系统测试的最后一个阶段。

在修改了旧代码后，需要对这部分子都进行测试，以确保这个代码修订没产生新的错误。在大多数情况下，回归测试占测试周期和测试自由的50%。因此，如果能够制定更有效的回归测试用例，将极大的提升整个测试的效率。

回归测试的流程如下：

（1）找出程序中因为新增需求或者故障解决，而被修改的代码

（2）从总的用例库中，去除掉不再合适的测试用例：这部分用例可能是修改没涉及的功能，也可能是一些系统性稳定性的低优先级的测试用例

（3）针对修改的影响部分，增加一部分相关模块的测试用例

（4）搜索出最基本的测试用例，纳入到测试计划：这部分测试用例保证软件不出现意外的基本功能错误

（5）用上述2～4的测试用例集合，形成回归测试的测试范围

3.现有回归测试用例选择方法

对于一个软件开发项目来说，项目的测试组在实施测试的过程中会将所开发的测试用例保存到“测试用例库”中，并对其进行维护和管理。当得到一个软件的基线版本时，用于基线版本测试的所有测试用例就形成了基线测试用例库。在需要进行回归测试的时候，就可以根据所选择的回归测试策略，从基线测试用例库中提取合适的测试用例组成回归测试包，通过运行回归测试包来实现回归测试。保存在基线测试用例库中的测试用例可能是自动测试脚本，也有可能是测试用例的手工实现过程。

针对修改部分的测试是我们希望改进的内容

当前是优秀的高级工程师逐一的查看开发提交的各个修改点，根据自己对相关部分的理解，以及对开发修改点的学习。整理出需要回归的测试点：这种方法的主要问题是：

需要优秀的工程师参与，这位工程师必须同时具备：既了解测试组的全部测试用例库，也需要能够理解开发提供的修订说明。

每一轮测试完成后，就需要人工干预，从而产生下一轮的测试用例

替代人工的方法是，为每一轮测试，执行类型level 0/1/2这样的测试用例等级。这样同样会带来冗余的测试用例执行，拉长了测试进度。

4.机器选择测试用例的方法

用机器来模拟和替代人工的挑选测试用例：是在回归测试中引入智能化方法的先决条件。整体按照如下的流程：

首先进行的是为每一条测试用例，生成不同的特征向量。在这个步骤中，将原始的测试用例转变成为“记录每个词出现的频率”的数学符号。最后生成如下表格：

其中行代表不同的测试用例，列代表不同的词语描述，数字代表不同的词语在不同测试用例中出现的词频。

然后，根据TFIDF算法将测试用例生成的文本特征向量，转换成为最终的文本特征向量。

这样，表一通过TFIDF算法最终转化的向量表示如下：

完成了特征词语的选择后，就要给选出的特征词语赋以权重。比如“测试”一词，在每个测试用例中都有出现，那么这个词虽然词频很高：但是“权重为零”——也就是说这个词对于描述不同测试用例的不同特征，无任何帮助。对于本研究方案而言，我们使用TF*IDF算法，计算出精确的统计量，以描述特征词语对于中文内容的重要性。

最后，将代码变更说明收集起来，计算特征向量。同时将测试用例库中的内容也做成特征向量。逐个的拿代码变更的特征向量，与用例库中的特征向量进行对比：选出与代码变更特征向量相识程度最高的。这个特征向量所代表的测试用例，既为下一轮回归测试的输入。在这个模块中，我们选择KNN算法，KNN算法也叫K最近邻算法。抽取测试用例库中的每个文本，逐一的与被测试的向量进行比较，每个比较完成后相似度被计算出来。下一步：找出K个最相似的测试用例。并在此基础上给每个被选出的测试用例打分，取分值大者作为比较结果。具体计算公式为：

其中：d为待测文本（开发提交的代码变更说明）向量，q为训练集中文本（原始的测试用例描述）向量。

这里给出一个具体实践：

开发提交了一个代码变更说明如下

最后机器推荐的相关性最紧密的四个用例，如下表：

可以看出，这四个被挑出来的点，都是对ACL重定向的测试：并且测试覆盖了物理端口、AP端口、SVI端口三种不同的端口类型。

进一步的，对这部分的测试进行基于代码覆盖率的验证，可以证明机器挑选出的四个测试用例，确实的有测试覆盖到开发修订的代码。

5.结束语

让机器来自主选择回归测试用例，然后将这个方法融入到自动化测试框架中。让自动化测试框架具有一定智能，能够“自主的产生回归测试用例的变化集合”。譬如整个ACL模块测试用例个数达到300，如果全部回归费时费力，而人工参与分析则会打断持续的自动化测试过程。新方法使用四个测试用例，就可以对开发修订提交的代码进行覆盖；这样一方面我们减少了回归测试的测试用例个数，另外一方面开发修订的代码，也被完整的测试了。

参考文献

[1]米歇尔（Mitchell，T.M.）.机器学习.机械工业出版社，2008-03-01

[2]盧苇，彭雅.几种常用文本分类算法性能比较与分析.湖南大学学报（自然科学版）， 2007.

[3]JOACHIMST.A probabilistic analysis of the rocchio algorithm with TFIDF for text categorization Nashville：1997：143-151.

4.测试用例设计步骤 篇四

设计测试案例的时候，需要有清晰的测试思路，对要测试什么，按照什么顺序测试，覆盖哪些需求做到心中有数。测试用例编写者不仅要掌握软件测试的技术和流程，而且要对被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构都有比较透彻的理解。测试用例设计一般包括以下几个步骤：

1、测试需求分析

从软件需求文档中，找出待测试软件/模块的需求，通过自己的分析、理解，整理成为测试需求，清楚被测试对象具有哪些功能。测试需求的特点是：包含软件需求，具有可测试性。测试需求应该在软件需求基础上进行归纳、分类或细分，方便测试用例设计。测试用例中的测试集与测试需求的关系是多对一的关系，即一个或多个测试用例集对应一个测试需求。

2、业务流程分析

软件测试，不单纯是基于功能的黑盒测试，还需要对软件的内部处理逻辑进行测试。为了不遗漏测试点，需要清楚的了解软件产品的业务流程。建议在做复杂的测试用例设计前，先画出软件的业务流程。如果设计文档中已经有业务流程设计，可以从测试角度对现有流程进行补充。如果无法从设计中得到业务流程，测试工程师应通过阅读设计文档，与开发人员交流，最终画出业务流程图。业务流程图可以帮助理解软件的处理逻辑和数据流向，从而指导测试用例的设计。

从业务流程上，应得到以下信息：

A、主流程是什么

B、条件备选流程是什么

C、数据流向是什么

D、关键的判断条件是什么

3、测试用例设计

完成了测试需求分析和软件流程分析后，开始着手设计测试用例。测试用例设计的类型包括功能测试，边界测试，异常测试，性能测试，压力测试等。在用例设计中，除了功能测试用例外，应尽量考虑边界、异常、性能的情况，以便发现更多的隐藏问题。

黑盒测试的测试用例设计方法有：等价类划分、边界值划分、因果图分析和错误猜测，白盒测试的测试用例设计方法有：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、多重条件覆盖。在这里主要讨论黑盒测试。在设计测试用例的时候可以使用软件测试用例设计方法，结合前面的需求分析和软件流程分析进行设计：

功能测试：测试某个功能是否满足需求的定义，功能是否正确，完备。

适合的技术：由业务需求和设计说明导出的功能测试、等价类划分

边界测试：对某个功能的边界情况进行测试。

适合的技术：边界值划分

异常测试：对某些功能来说，其边界情况无法简单的了解或某些操作不完全是正确的但又是

可能发生的，类似这样的情况需要书写相关的异常测试。

适合的技术：由业务需求和设计说明导出的特殊业务流程、错误猜测法、边界值

分析、内部边界值测试。

性能测试：检查系统是否满足在需求中所规定达到的性能，性能主要包括了解程序的内外部

性能因素。内部性能因素包括测试环境的配置，系统资源使用状况；外部因素包

括响应时间，吞吐量等。

适合的技术：业务需求和设计说明导出的测试

压力测试：压力测试又称强度测试，主要是检查系统运行环境在极限情况下软件运行的能力，比如说给一个相当大的负荷或网络流量给应用软件兼容测试：测试软件产品在不

同的平台，不同的工具，相同工具的不同版本下功能的兼容性。

4、测试用例评审

测试用例设计完成后，为了确认测试过程和方法是否正确，是否有遗漏的测试点，需要进行测试用例的评审。

测试用例评审一般是由测试leader安排，参加的人员包括：测试用例设计者、测试leader、项目经理、开发工程师、其它相关开发测试工程师。测试用例评审完毕，测试工程师根据评审结果，对测试用例进行修改，并记录修改日志。

5、测试用例更新完善

5.软件测试用例的设计心得 篇五

在编写一个软件或者模块的测试用例时候，一定要明白这个功能的原始需求，也就是软件的使用者（客户）的需求。理解原始需求后，编写的测试用例才更有目的性。

2、熟悉软件的功能需求（测试点）

这个功能需求是指软件的细化需求点，这个一般在需求文档里面都会体现。这里要做的是把 “粗略”的需求，细化成一个个小需求点。熟悉功能需求后，要知道软件是怎么使用的，这也才能覆盖到各种操作。

总之，测试用例一定要全部覆盖所有的需求点，这是最基本的一点。

3、熟悉软件的实现原理（测试点）

在理解原始需求和软件的功能需求后，根据需求编写的测试用例，基本上都能覆盖得比较全面了。

在此基础上，熟悉软件的实现原理，理解软件的内部处理。

（1）熟悉原理的过程是进一步深入熟悉软件的过程。如果单单是从需求点上面覆盖案例，测试用例只能覆盖“表面”的一层。一些内部的处理流程也许没有覆盖到，而这些没有覆盖到的代码很可能就是一个风险点。

（2）熟悉模块原理后，还有一点就是易于分析软件模块的关联性。一个大型的软件，都是一些小模块的组合而成。软件越是大型，耦合就越大，“互相影响”就会越多，若设计用例单单从模块本身考虑的话，很可能就会对其他模块造成风险。

4、用户场景和网上问题（测试点）

从用户的使用场景考虑，这在一些网络设备比较重要，比如软件后期在一些真实的使用环境中使用。

还要就是从一些网上问题总结出来的，那些地方容易出错，在设计案例的时候需要考虑进去。

5、测试用例的框架

一个测试用例的框架体现了一个测试人员在设计测试用例的整体思路。框架也是从大到小划分下来，可以是：

UI界面，功能，容错，兼容，性能等几大类，每个大类在根据软件的逻辑等进行划分成小类，最后细分到测试点。

6、测试步骤（测试技巧方法）

前面4点都是从测试点的角度考虑，测试用例在完成测试点外，接下来就是测试步骤和测试结果啦。

测试用例可以写的很详细，也可以写的比较简单。这要看公司的要求，有些公司要求测试步骤很细很细，包括测试结果和测试步骤一一对应。

要求测试步骤写的很详细的公司，一般是怕执行人员的执行力不到位，导致没有理解案例的目的，导致漏测。一般出现在新员工对软件系统的不熟悉。如果测试步骤写的很详细的话，会很耗时间，而且过于详细的会限制执行人员的思维。个人认为测试用例的重点在于测试点上。

7、测试用例的一些思路

在设计测试用例中，通常较多使用的是边界值，等价类，通过和不通过测试。下面从单个模块或者单个功能点考虑：（结合一些网上文章的观点）

（1）UI界面：易用性，提示信息，整体布局，按钮图标，色彩，中英文标点错别字。

（2）数据的多样性：有效数据，合法的无效数据（边界值），非法的异常数据，产生错误输出的合法数据组合等各种数据的组合。

（3）操作多样性：添加删除编辑查询，多用户的操作。

（4）容量测试

（5）用户权限：使用权限，各种操作的权限。

（6）升级安装卸载：平滑升级

（7）日志相关（包括调试日志）

（8）软件功能的逻辑划分：功能上划分未能覆盖的代码逻辑，可以添加白盒灰盒用例。

（9）可靠性，容错性

（10）兼容性：浏览器，系统，支撑软件。

（11）安全性

（12）性能（这里的性能是指，单个模块或者子系统的性能）

总之测试用例首先要能覆盖所有功能需求点，然后搞懂软件处理逻辑，可以找开发一起看测试用例，把没有覆盖到的代码流程相应的用例补充，至此，用例基本不会出现基本功能的问题。

6.测试计划与测试用例 篇六

关键词软件测试，测试用例，复用，分词

0 引言

软件测试是在规定的条件下对程序进行操作，以发现程序错误，由此来衡量软件质量，并对其是否能满足设计要求进行评估的过程。作为软件生命周期中的重要环节，其成败直接决定着软件的最终质量。软件测试工作不仅保证了软件质量，而且降低了日后维护成本。随着我国软件产业的蓬勃发展以及对软件质量的重视，软件测试也逐渐受到软件企业的关注，正逐步成为一个新兴的产业。测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，用于测试某个程序路径或核实是否满足某个特定需求。

7.测试计划与测试用例 篇七

关键词：黑盒测试,等价类划分,用例

软件测试是根据软件开发规格说明和程序的内部结构而精心设计一组测试用例,并利用这些测试用例去运行程序,以发现程序中错误的过程.通过软件测试可以暴露软件中存在的错误和缺陷,从而提高软件的可靠性。特别地,随着软件规模和复杂性的不断提高,软件测试成本也不断增加,软件测试技术也越来越得到重视。如何实现用少量测试用例来实现高覆盖率的软件测试呢,基于等价类划分的黑盒测试技术能很好解决这个问题。

1 基于等价类划分的黑盒测试概述

1.1 黑盒测试概述

黑盒测试是使用规格说明,不要求考察程序代码,以用户的视角进行的测试,对于测试者而言,只要求有关被测试产品的功能认识,不一定了解系统内部逻辑,也不一定了解构建该产品所使用的程序设计语言,一般黑盒测试进行的是保证功能与兼容性测试。

1.2 等价类划分概述

等价类划分是一种基于黑盒测试的软件测试技术,用于确定少量能够产生尽可能多的不同输出条件的有代表性的输入值,这种方法可以减少用于测试的输入、输出值的排列组合,从而提高覆盖率,降低测试工作量。

等价类划分试图定义一个测试用例以期发现一类错误,由此减少所需设计测试用例的总数。在等价类的划分集合中,一般要确保两个特性,一是完整性,也就是说划分出来的子集合的并集是整个集合;二是不相交性,也就是说划分出来的子集合是互不相交的一组子集。还需要说明的一点就是,这些等价类中的测试用例会以与同样的方式进行“相同处理”。当我们考虑结构性测试时,将会看到“相同处理”映射到“遍历相同的执行路径”。

2 设计测试用例的步骤

2.1 等价类划分表的设计步骤

首先选择等价类划分的判断准则,根据次准则确定有效等价类,从划分中选择一个样本数据;根据给定需求(或规约)编写出预期结果,确定可能有德特殊值,添加到到用例表中;检查是否所有测试用例均给出了预期结果,如果对任何具体的测试不能给出明确的预期结果,可将其标注出来,并进行及时更正。

2.2 用例设计步骤

在测试用例的设计中,首先要按等价类划分表中的每个等价类确定一个唯一编号,其次是用例要尽可能多的覆盖尚未被覆盖的有效等价类,然后逐一设计仅覆盖一个还未覆盖的无效等价类的测试用例。

3 基于等价类划分的软件测试用例设计

3.1 规约:工资支付系统规约

工资支付系统允许员工以无纸化的方式来登记时间卡信息,并自动根据员工的工作时间和销售总额(对于有提成的员工)来生成用于支付工资的支票。员工可以通过该系统输入时间卡信息和交易订单信息,更改员工首选项(例如支付方式),并生成多种报告。该系统可以在每个员工的个人台式电脑或便携式电脑上运行。出于安全和审计的需要,员工只能访问和编辑自己的时间卡信息和销售订单信息。本文中仅对桌面系统登录验证模块进行测试,其余部分规约略去。

3.2 桌面系统登录事件分析

主事件流:当系统提示员工输入员工编号(ID)和口令(PW)时,用例开始。员工可以扫描卡片再按回车提交员工编号(ID),然后通过键盘输入口令(PW),并回车或点击确认按钮。系统就检查员工的号码和口令(PW)输入是否合法。如果是合法的,系统就显示员工的基本信息和可选操作,然后结束这个用例。

可选事件流:如果员工输入了一个不合法的编号(ID)或口令(PW),系统就显示错误消息,用户可以选择重新输入或取消,重新输入则回到主事件流,若取消则该用例结束。

可选事件流:如果员工输入的编号(ID)已过期或被禁用了,系统就显示提示消息,并记录该次登录事件,该用例结束。

可选事件流:如果员工连续3次输入不合法,则显示警告并锁定屏幕,进入等待管理员解锁用例。

3.3 工资支付系统等价类测试用例设计

3.3.1 工资支付系统员工基本信息表

对编号(ID)和口令(PW)的判断是基于数据库中员工信息的,假定员工基本信息表1如下(此表中只列出编号(ID)、口令(PW)、是否过期三项,其余项信息与本文关系不大,暂且略去)

3.3.2 桌面登录系统问题的等价类划分

在等价类划分中,一般是将程序的输入划分为若干个数据类,从中生成测试用例来实现软件测试。基于输入的等价类划分如表2所示。

3.2.3 桌面系统登录问题的等价类测试用例设计

3.3.4 基于输出域的等价类划分

从被测试程序的输出情况划分等价类(如表4所示),也可以作为等价类划分的标准,在这里就仅作一例证,不在详细说明。通常情况下,基于输出的等价类划分与基于输入的等价类划分结合起来使用,能更好地提高测试的覆盖率。

4 结束语

等价类划分测试是黑盒测试的重要技术之一,对软件功能测试、可靠性测试起关键作用。通过不重复同一个划分中的相同测试,可以最大限度地降低测试的冗余,结合一些专门的测试工具软件,能够实现对软件的进行合理、高效的测试。

参考文献

[1]韩丽媛.黑盒测试及测试工具Rational Robot的应用[J].计算机工程与设计,2006(2).

[2]浦云明,陈黎震.基于划分的等价类测试[J].计算机工程与设计,2009(19).

[3]范明红,汪志华.等价类测试与划分研究[J].计算机技术与发展,2010(7).

8.热工测试计划 篇八

为执行国家质检总局关于做好2011年高耗能特种设备节能工作的实施意见中，关于锅炉设计文件节能审查和锅炉定型产品能效测试工作的要求，对我公司的6t/h，10 t/h链条炉进行能效测试。1.测试时间：

经与省特检院沟通，基本定于7月20-25日左右进行正式测试。争取在7月底前将6t/h，10 t/h链条炉测试完毕。6t/h链条炉用户单位每周二、五停电，故大致定于7月21日（周四）对6t/h链条炉进行测试。最终测试时间和用户确认和特检院确认后确定。2.测试前期调试

为顺利进行测试，根据现场情况，提前一天（7月20日）我公司先行进行调试准备，锅炉测试主要项目有：

1.）给水压力、给水流量、给水温度（给水旁路和给水流量计，给水旁路安装由用户单位协助安装。）

2.）蒸汽压力、蒸汽湿度（需炉水、蒸汽冷凝器，6t/h链条炉只有炉水冷凝器，现场要在主蒸汽管道上开孔安装。因涉及受压部件开孔，蒸汽取样由我公司负责安装，需提供蒸汽取样装置，取样冷却装置以及配套的法兰，阀门等。需要生产部门的配合）

3.）排烟温度、烟气成分。烟温测量由现场解决。调试需要设备需要外借。3.各部门职责：

1.）技术部门：召集测试会议，确定本次测试参加人员；提供测试需要图纸，测试注意事项；给水旁路和蒸汽取样装置的安装示意图。参与锅炉调试，配合特检院的测试工作。2.）销售部门：联系用户，测试需要用煤数量、用汽排放问题，确定测试时间。安排测试用车及和特检院必要的公关。调试需要设备的外借。

3.）用户服务：现场要在主蒸汽管道上开孔安装。因涉及受压部件开孔，蒸汽取样由我公司负责安装，需提供蒸汽取样装置，取样冷却装置以及配套的法兰，阀门等（型号，规格，数量由技术部门提出）。需持证电焊工协助现场焊接。

1—主蒸汽管

2—蒸汽取样管

附图2

注：蒸汽取样管用4分水管引至距地面90厘米处，端口攻好螺纹，以便与蒸汽冷凝器上的4分阀门联接。

注: 实线部分为锅炉厂在试验前现场准备完毕。虚线部分为特检院准备，试验时安装。

附图 1

9.测试计划 篇九

根据本公司生计量设备管理程序要求特制定的本年度维修保养计划。保持计量器具和计量设备的良好状态，以保证使用过程效能，确保生产能够连续稳定的进行。

2. 范围

适用于本厂计量设备、计量器具的控制和管理。

3. 职责

3.1生产部是设备维护保养的主要管理部门。负责厂的计量设备、计量器具的管理。

3.2生产部根据厂量设备、计量器具的实际情况，负责建立管理档案，制订《计量器具计量设备操作规范》，对器具、设备实施全过程的管理。

3.3生产部负责所有的计量器具、设备进行维修、保养及运行操作。

4 工作程序

设备在使用过程中，随着运行工时的增加，各部机构和零件由于受到摩檫、腐蚀、磨损、振动、冲击、碰撞及事故等诸多因素的影响，技术性能逐渐变坏。

4.1保养作业内容

按照保养作业性质可分为：清洁，检查，紧固，润滑，调整，检验和补给作业。检验作业由国家指定的检验部门执行，或由本司专职检验人员负责进行。

1) 清洁、检查、一般由设备操作人员执行。

2) 紧固、调整、润滑作业一般由机修工执行。

3) 电气作业由专业人员执行。

5 保养制度

计量设备和计量器具的保养制度是以预防为主，定运行工时进行保养的原则，分为例行保养，一级保养，二级保养，三级保养，季节性保养。

计量设备和计量器具保养的分级和作业内容是根据实际使用中计量参数情况的变化；设备的结构；使用的条件；环境条件等确定。是根据零件磨损规律，老化规律，把程度相近的项目集中起来，在达到正常磨损，老化将被破坏前进行保养，保持计量器具设备整洁，发现和消除故障隐患，防止设备早期损坏，达到设备维持正常运行的目的。

5.1设备的例行保养

设备的例行保养是各级保养的基础，直接关系到运行安全，能源的消耗，机件的使用寿命。例行保养作业由设备操作人负责执行，其作业中心内容以清洁、补给、安全、检视为主，坚持开工之前、运行中、收工后的三检制度。检查操纵机构、运行机件、安全保护装置的可靠性，维护计量设备和器具的清洁等。

5.1.1 计量设备启动前的工作项目。

1) 清洁设备，清除与生产无关的杂物。

2) 检查各指示仪器，仪表，操作按钮和手柄以及紧急停止按钮是否正常。

3) 检查各部位有无漏水，漏气，漏电的现象。

5.1.2设备运行中的检查。

1) 注意各仪器仪表的工作情况，及各部位有无异常的声响。

2) 运行中注意安全部件是否正常。

3) 遇异常情况要及时向相关部门负责人报告。

5.1.3收工后的作业项目

1) 清洁设备外部，除去污物和杂物。

2)填写设备运行录表。

3) 排除运行中发现的缺陷和故障。

5.2 设备的维修保养

设备的维修保养是合理使用设备的重要环节，必须用强制性的保养制度取代那些随坏随修，以修代保，进行频繁的大拆大卸的做法。

设备的维修保养就是在以预防为主的思想指导下，把设备保养作业项目按其周期长短分别组织在一起，分级定期执行，设备的定期保养分为：一级保养，二级保养，三级保养。

5.2.1一级保养

一级保养是各级技术保养的基础，各级技术管理部门必须十分重视一级保养工作的质量。由专业维修工负责执行。主要作业内容以清洁、润滑、紧固为主，检查操纵、指示用仪器、仪表、安全部位等。

5.2.2二级保养

设备的二级保养以清洁、检查、调整、校验为中心内容。由专业维修人员负责执行。除执行一级保养作业项目，检查安全机件的可靠性，消除隐患，调整易损零部件的配合状况，旋转运动部位的磨损程度，校验指示用仪器仪表和控制用仪器仪表、计量用仪器仪表，延长使用寿命，维护设备的技术性能。

5.2.3三级保养

三级保养以解体清洗、检查、调整为中心内容。清除污垢、结焦，视需要对各部件进行解体、清洗、检查，清除隐患，排除缺陷，对设备进行全面检查，视需要进行除锈、补漆，对电气设备进行检查、试验。

5.2.4季节性保养

本市冬、夏气温相差悬殊，设备的工作条件也发生明显变化。为此，在进入冬夏两季之前，应结合二级保养进行季节性保养作业，以避免因气温变化造成设备性能不良和机件损坏。

5.3 使用过程故障维修

生产过程中若发生机械设备故障，应及时通知质管部联系维修人员维修，并填写“设备维修记录单”。维修后，经使用人检验正常运行后再进行正常工作。

5.4 保养时间安排

10.软件测试中测试用例复用的研究 篇十

(一) 软件复用概述。

软件复用指的是将已有的软件中的有效成分用来构建新的软件, 强化复用的功能。在进行软件复用的过程中, 整个重新构建的软件系统并非零基础, 而是将旧有软件开发知识都调动起来, 从而加快新软件设计的脚步, 这是软件复用最大的优势体现。在实践中, 可以对已有软件进行百分百复用, 也可以针对源代码或相应的测试用例进行复用。

(二) 可复用测试用例的具体特征。

通过对大量测试用例和测试用例复用的各种应用情况进行了分析, 认为可复用测试用例应具有以下特性:通用性、有效性、独立性、标准化和完整性等等, 这些特征对于可复用测试用例而言是充分的也是必要的[1]。上述特性可作为评判一个测试用例是否具有可复用性的准则。

二、探究软件测试用例复用的相关内容

(一) 软件测试中的测试用例。

为了巩固软件研发后的功能符合实际设计需求, 则在软件正式投入使用前需要对软件进行科学化的测试。随着软件设计领域的日益变革, 软件功能也呈现出多样化的特征, 因此, 软件开发的复杂程度也不同以往。在这种情形之下, 软件测试阶段的设计就显得尤为重要, 在进行软件测试的过程中, 需要运用抽象化的软件测试用例来支撑整个测试环节。从概念上来看, 测试用例指的是对软件运行过程中所有可能存在的目标、过程、环境及结果的预测, 通过具体的数据以及文字将其描述出来, 模拟了该软件在实际上线以后的运行情况, 旨在从整个拟运行的过程发现实际问题, 并及时将其解决。在测试的过程中, 测试用例体现出测试方案以及策略的相关内容, 并通过文档的形式将测试的几个步骤和评估过程 (如测试目标评定、测试环境拟运行、测试结果等) 呈现给软件测试技术人员。

(二) 测试用例复用设计的思路。

对于测试用例的设计而言, 要遵循一定的设计原则以及基本的设计思路来展开软件测试用例设计。因为在软件测试的过程结束时, 最终的测试结果受到多重因素的影响, 包括测试的细节、测试前提、测试性能指标等等, 所以, 就要在执行软件测试时, 仔细钻研软件运行环境及其性能等要求, 进而保证软件测试过程的整体质量[2]。基于此, 在实际执行测试时, 选择恰当的实际用例十分关键, 通常选择复用现有的测试用例, 以期提升软件评估过程的效率。但实际上, 有很大一部分软件测评中心仅仅使用了测试用例集合当中的一个模块进行复用, 一方面在提高了软件测试用例服用度, 另一方面也能够保障新型测评系统能够与时俱进, 满足测试系统升级的目标。具体的软件测试中测试用例复用过程如图1所示:

从图1中可以清楚的看到, 软件测试中测试用例复用是一个较为复杂的过程, 需要各个环节的密切配合与协调, 并最终实现测试用例复用的过程, 提升软件测试及其设计的效率。实践证明, 对于专业的软件测试机构来说, 选择合理复用测试用例具备一定的可行性和经济性, 并且设计出来的测试用例能够顺利执行软件测评过程。

结束语

通过研究软件测试中测试用例复用了解到, 软件测试用例设计对于软件测试极为重要。在实践过程中, 软件测试是确保软件质量的可靠手段, 是软件开发过程中必不可少的重要环节。通常情况下, 面向复用的测试用例设计过程, 为测试用例复用提供了实现策略, 保证了软件上线以后的质量符合相关要求。另外, 测试用例的复用对于缩短软件开发周期和降低软件开发成本具有极其重要的意义。在未来, 需要深度探究软件测试中测试用例复用领域, 使其为软件研发提供更加有力的技术支撑, 促进软件行业朝向更为广阔的发展空间迸发。

摘要：随着国内外软件产业的迅猛发展, 有关软件工程领域的研究亦日趋深入, 给软件研发以及产业项目的发展提供了有力的策略支持。本文就软件测试中测试用例复用及其设计的相关内容做以论述, 探讨测试用例的复用对于缩短软件研发周期的影响, 并进一步探究软件开发的相关问题, 以期为软件工程领域的未来拓展提供有益的借鉴。

关键词：软件测试,测试用例复用,研究

参考文献

[1]张志国, 徐冰霖, 秦湘河.面向复用的航天测控软件测试用例建模研究[J].飞行器测控学报, 2011, 06 (06) :49-50.

11.学习计划小测试 篇十一

对下列各题作出“是”、“不一定”或者“否”的回答。

1.你是否经常按时交作业?

2.去上学时，你是否常常把书或其他学习用品遗忘在家里?

3.平常学习新内容时，你是否常常来不及预习?

4.你是否因夜里看电视或看书报，而不按时睡觉?

5.你是否常常在临考前突击复习而平常从不复习?

6.在家学习时，你从不规定好什么时间学什么学科吗?

7.你是否因为看电视或和同学、朋友玩的时间过长而挤掉了学习的时间?

8.学习时，你是否不能努力在规定的时间内完成任务?

9.老师布置的.作业你是否经常忘做?

10.假期中，你是否从不利用休息时间进行学习?

11.学习时，你是否对学习方法从不考虑优点和缺点?

12.你是否不遵守自己制订的学习计划?

13.你是否为了学习而不按时吃饭和睡觉?

14.你是否不能做到在规定时间内拼命学习?

15.在家里学习时，你是否经常没有事先准备好和学习有关的用品?

分数分配

每题答“是”得0分，答“不一定”得1分，答“否”得2分。各题得分相加，统计总分。

得分分析

0～10分：学习计划性较差，必须加强学习的计划性。

11～20分：学习计划性一般，需要加强。

12.软件测试工作计划 篇十二

1.1目的

简述本计划的目的，旨在说明各种测试阶段任务、人员分配和时间安排、工作规范等。

测试计划在策略和方法的高度说明如何计划、组织和管理测试项目。测试计划包含足够的信息使测试人员明白项目需要做什么是如何运作的。另外，清晰的文档结构能使任何一个读者在浏览计划的前面几页后，就能对项目有一个大概的认识。测试计划只是测试的一个框架，很多细节需要跟开发人员或其他人员沟通，因此计划不包括测试用例的细节和系统功能的详细信息。在计划目的中需要指明读者对象。

1.2名词解释

列出本计划中使用的专用术语及其定义

列出本计划中使用的全部缩略语全称及其定义

缩写 词或术语	英文解释	中文解释

1.3参考资料

列出本计划各处参考的经过核准的全部文档和主要文献。

1.4测试摘要

这一节主要说明测试计划中重要的和可能有争议的问题。本节的主要目的是将这些信息传递给那些可能不会通读整个测试计划文档的人员(比如经理或开发项目的负责人)。

1.4.1 重点事项

列出测试的重点事项。可以将问题按重要程度和优先级罗列出来，然后在后面的章节中再对这些问题进行详细说明，这样就能让对这些问题有重要影响的人员知道问题的所在

1.4.2 争议事项

简要说明争议事项。

1.4.3 风险评估

通过对技术文档的阅读，对被测系统可能存在的问题：系统设计，数据库设计，响应时间，计费策略，因测试环境不足可能存在的测试缺陷事先评估出来，以指导测试方案，进行有重点的测试.

1.4.4 时间进度

简要说明测试开始时间与发布时间。

1.4.5 测试目标

简要说明测试发布的质量目标：

测试计划中所有测试方法和模块已经执行通过

所有的测试案例已经执行过

所有的重要等级为1/2的Bug已经解决并由测试验证

第2章 项目背景

2.1测试范围

说明本计划涵盖的测试范围，比如功能测试、集成测试、系统测试、验收测试等。通常说明什么是要测试的，什么是不要测试的是非常重要的。明确规定这些问题后，测试人员对该做什么有一个清晰的认识。

(1)简要地列出测试对象中将接受测试或将不接受测试的那些性能和功能。

(2)如果在编写此文档的`过程中作出的某些假设可能会影响测试设计、开发或实施，则列出所有这些假设。

(3)列出可能会影响测试设计、开发或实施的所有风险或意外事件。

(4)列出可能会影响测试设计、开发或实施的所有约束。

提示和技巧：

需要测试和特别注意测试那些部分?

测试是否专么针对与某些问题的解决?

哪些部分不需要测试，为什么?

哪些部分需要推迟测试,为什么?

是否要验证每个模块的稳定性?

测试的优先级和先后顺序

2.2测试目标

系统目标对测试人员了解自己需要做什么是非常重要的。测试项目负责人应积极与系统设计人员或开发人员沟通，以取得相关资料。测试人员必须知道系统是做什么并且帮助项目实现这种目标。在计划中包括系统视图和目标后，要确保所有的测试人员都知道项目和系统的目标。

通常情况下项目计划都是模糊的。模糊的目标必须通过成员的努力转换成可衡量和实现的东西。没有固定的视图和目标，你将无法完成部分任务。而且，你会发现很难将对产品的认识向别人转述。

2.3联系方式

列出项目参与人员的职务、姓名、E-mail 和电话。

职务	姓名	E-Mail	电话
开发工程师
CVS Builder
开发经理
测试负责人
测试人员

2.4风险及约束

列出测试过程中可能存在的一些风险和制约因素，并给出规避方案。如：

由于客观存在的设备、网络等资源原因，使得测试不全面。明确说明哪些资源欠缺，产生什么约束

由于研发模式为现场定制，且上线时间压力大，使得测试不充分。明确说明在此中约束下，测试如何应对

只针对专门的客户群需求的测试。明确说明此约束下的客户群和业务范围。

2.5测试文档

列出测试过程中可能用到的参考文档、相关的设计文档以及保存位置，测试完成后应产生的文档。

2.5.1测试参考文档

文档说明	作者	文档位置（CVS）
需求文档
总体设计
白皮书
使用手册
管理手册
测试文档
API文档

2.5.2测试提交文档

文档说明	作者	文档位置（CVS）
《总体测试计划》
《总体测试方案》（可根据项目情况进行裁剪）
测试用例
《性能测试方案（报告）》
《测试报告》
《Readme》
《产品操作手册(后台)》
《产品操作手册(前台)》
《产品安装维护手册》
《产品错误代码说明文档》

第3章质量目标

描述本阶段测试目标和要求。质量目标应该包括产品的质量目标和测试小组的质量目标。

质量不仅是衡量系统的功能或性能是否正常。对系统来说，在开发过程中尽早建立全面的质量标准与系统的及时发布是一样重要的。质量目标是一个强有力的工具，应该在系统开发过程中尽早建立。一个定义准确的质量目标在以后的产品开发过程中帮助决策。例如，系统是否能够正式发行?在代码完成后，应该修复那些缺陷?在系统完成后那种类型的测试是最合适的?

3.1产品质量目标

可以是产品的质量达到什么样的目标，产品的流程联通性达到什么样的要求。

测试质量目标	确认者（如需说明）
测试已实现的产品是否达到设计的要求，包括：各个功能点是否以实现，业务流程是否正确
产品规定的操作和运行稳定

3.2测试质量目标

评价测试质量的目标可以有：

测试质量目标	确认者（如需说明）
所有的测试案例已经执行过
所有的自动测试脚本已经执行通过
所有的重要等级为1/2的Bug已经解决并由测试验证
每一部分的测试已经被Test Lead确认完成
重要的功能不允许有等级为1/2/3的Bug
一般的功能或与最终使用者不直接联系的功能不允许有等级为1/2的bug,且bug等级为3的问题不得超过1/功能
轻量的功能允许有少量2/3等级的错误
发现错误等级为1/2/3的Bug的速率正在下降并接近0
在最后的三天内没有发现错误等级为1/2/3类的Bug

第4章 资源需求

4.1培训资料

培训需求	培训内容	培训人员	开始时间	完成时间
业务流程
安装配置
工具使用

4.2测试环境

4.2.1硬件测试环境

描述建立测试环境所需要的设备、用途及软件部署计划。

“机型(配置)”：此处说明所需设备的机型要求以及内存、CPU、硬盘大小的最低要求。

“用途及特殊说明”：此设备的用途，如数据库服务器，web服务器，后台开发等;如有特殊约束，如开放外部端口，封闭某端口，进行性能测试等，也写在此列;

“软件及版本”：详细说明每台设备上部署的自开发和第三方软件的名称和版本号，以便系统管理员按照此计划分配测试资源;

“预计空间”：说明第三方软件和应用程序的预计空间;

“环境约束说明”：建立此环境时的特殊约束。如需要开发外部访问端口，需要进行性能测试等。

平台1：SUN
机型（配置）	IP地址	操作系统	用途及特殊说明	软件及版本	预计空间
SUN450	10.1.1.1			oracle8.1.2	2G
平台2：IBM
机型	IP地址	操作系统	用途	第三方软件及版本	预计空间

4.2.2软件测试环境

软件需求	用途

4.3测试工具

此项目将列出测试使用的工具以及用途：

测试工具	用途
自动测试工具

第5章 测试策略

5.1 整体测试策略

本节的目的是说明计划中使用的基本的测试过程。

使用里程碑技术在测试过程中验证每个模块，测试人员在需求阶段参与测试工作，进行需求review、设计review、测试案例设计和测试开发，在系统开发完成之后，正式执行测试。产品达到软件产品质量要求和测试要求后发布，并提交相关的测试文档。

5.2开始/中断/完成标准

说明中断/开始/完成测试的标准。

开始/中断/完成测试	标准说明
开始测试标准	硬件环境可用且软件正确安装完成
中断测试标准	安装无法正确完成或程序的文档有相当多的失误或系统服务异常或发现Block Bug
完成测试标准	完成测试计划中的测试规划并达到程序和测试质量目标,并由Test Lead/R&D Manager确认

5.3测试类型

测试类型	是否采用	说明
功能测试	采用	根据系统需求文档和设计文档，检查产品是否正确实现了功能。
流程测试	采用	按操作流程进行的测试，主要有业务流程、数据流程、逻辑流程、正反流程，检查软件在按流程操作时是否能够正确处理
边界值测试	采用	选择边界数据进行测试，确保系统功能正常，程序无异常。
容错性测试	采用	检查系统的容错能力，错误的数据输入不会对功能和系统产生非正常的影响，且程序对错误的输入有正确的提示信息
异常测试	采用	检查系统能否处理异常
启动停止测试	采用	检查每个模块能否正常启动停止、异常停止后能否正常启动
安装测试	采用	检查系统能否正确安装、配置
易用性测试	采用	检查系统是否易用友好
界面测试	采用	检查界面是否美观合理
接口测试	采用	检查系统能否与外部接口正常工作
配置测试	采用	检查配置是否合理、配置是否正常
安全性和访问控制测试	采用	应用程序级别的安全性：检查Actor只能访问其所属用户类型已被授权访问的那些功能或数据。 系统级别的安全性：检查只有具备系统和应用程序访问权限的Actor才能访问系统和应用程序。
性能测试	采用	提取系统性能数据，检查系统是否满足在需求中所规定达到的性能。
压力测试	采用	检查系统能否承受大压力，测试产品应该能够在高强度条件下正常运行，不会出现任何错误。
兼容性测试	采用	对于 C/S 架构的系统来说，需要考虑客户端支持的系统平台。 对于 B/S 架构的系统来说需要考虑用户端浏览器的版本。
割接/升级测试	采用	进行专门的割接测试或升级测试，提供工程升级割接方案
文挡测试	采用	检查文档是否足够、描述是否合理
回归测试	采用	检查程序修改后有没有引起新的错误、是否能够正常工作以及能否满足系统的需求

5.4 测试技术

测试技术	是否采用	说明
里程碑技术	采用	里程碑的达成标准及验收方法在测试完后制订
自动测试技术	采用	核心业务流程采用自动测试技术
审评测试	采用	对软件产品功能说明文档和设计说明文档进行检查，在需求与设计阶段进行
编写测试用例	采用	在产品编码阶段编写测试用例
单元测试	不采用	由开发人员进行
集成测试	采用	检测模块集成后的系统是否达到需求对业务流程及数据流的处理是否符合标准、系统对业务流处理是否存在逻辑不严谨及错误以及是否存在不合理的标准及要求。
确认测试	采用	在产品发布前，对照feature list 进行基本需求的确认，确认产品是否正确实现了功能。
系统测试	采用	包括性能测试、压力测试和回归测试
验收测试	不采用	由工程实施人员进行

第6章 测试计划

6.1进度计划

在此章节，对各阶段的测试给出里程碑计划，包括阶段、里程碑、资源等。

6.1.1测试时间进度

测试阶段	开始时间	完成时间	测试人员	阶段完成标志
制定测试计划
需求Review
设计Review
设计测试用例
测试开发
测试环境准备
测试实施
功能测试
集成测试
性能测试
系统测试
验收测试
文档编写

6.1.2测试里程碑

里程碑	完成时间	完成标准
测试正式开始		完成可接受性测试和烟雾测试
进行CVS LOCK	进行cvs lock	完成所有里程碑测试和标准测试,测试种类包括确认测试和系统测试,且所有以发现的Bug等级为1/2/3的Bug已修复,近期内无发现新的Bug等级为1/2/3的Bug
产品Release		重复进行主路径测试和进行Bug检查测试,产品处于可交付状态并由测试经理和高级经理确认

6.2测试准备

6.2.1 测试环境准备

准备事项	开始时间	完成时间	测试人员	阶段完成标志
测试环境准备

6.2.2 安装测试

准备事项	开始时间	完成时间	测试人员	阶段完成标志
安装测试

6.2.3 烟雾测试

准备事项	开始时间	完成时间	测试人员	阶段完成标志
烟雾测试

6.3 具体测试实施任务和时间人员安排

测试功能点	开始时间	完成时间	测试人员	说明

13.软件测试用例设计 篇十三

使用人工和自动化手段来测试或运行某个系统的过程,其目的在于检验它是否真的满足规定的需求或者是明确预期结果与实际结果之间的差异。

2 测试用例的定义

测试用例是为特定的目的而设计的一组测试输入、执行条件和逾期结果。测试用例是执行的最小实体。

3 测试用例的特征

(1)最有可能发生的错误;

(2)不是重复的、多余的;

(3)一组相似测试用例最有效的;

(4)不要太复杂;

(5)可复用。

4 测试用例设计的原则

(1)全面性原则。覆盖所需要测试的功能点,要想达到覆盖面比较全,首先要对测试产品全面了解,并且明确测试范围,即明确不需要测试的内容和需要测试的内容。

(2)单个测试用例覆盖最小化的原则。假如要测试一个功能Y,它有三个子功能Y1、Y2和Y3,可以用下面两种方法来设计测试用例。

方法1:用一个测试用例覆盖三个子功能-Test_Y1_Y2_Y3。

方法2:用三个单独的用例分别来覆盖三个子功能-Test_Y1,Test_Y2,Test_Y3。

方法1适用规模较小的工程,但有规模和质量要求的项目,方法2则是更合适的选择,因为它具下面几个优点:测试用例的覆盖边界定义更明确;测试结果对产品问题的明确指向性更强;测试用例间的耦合度最低,彼此之间的干扰也就越低。

以上3个优点带来的直接好处是测试用例的调试、分析和维护成本是最低的。每个测试用例应尽可能简单,只验证所需要验证的内容,否则只会增加测试执行阶段的风险,还会带来彼此之间的干扰。此外,覆盖功能点简单明确的测试用例,便于组合生成新的测试,如在Visual Studio中引入了Ordered Test的概念。

(3)测试用例替代产品文档的功能原则。在开发软件产品的初级阶段通常是用Word文档的形式来记录产品的需求描述、功能描述和功能的具体细节等信息,来描述未来要实现产品的功能,便于团队进行交流,并且在团队内部达成对产品功能和细节的共识。假设在这时达成的共识并描述的功能是B,随着产品开发进程的深入,团队成员对产品的功能有更新的认识,产品功能也会变得更具体细化,在一个迭代或者Sprint结束时最终实现的功能很可能是B+。如此反复,在不断接纳用户的反馈,多个迭代过后,原本被描述为B的功能很可能最终变为了C。这时再去看曾经的Word文档和One Note页面,它们仍然记录的是B。之所以会这样,是因为很少有人会去以及能够去不断更新那些文档,以准确反映出产品功能当前准确的状态。

产品代码和测试用例能够准确描述产品的功能细节。产品代码实现了产品功能,且准确描述了产品的功能,但是,由于各种编程技术,如面向对象、抽象技术、设计模式、资源文件等,使得产品代码本身很难读懂,所以,往往是在知道产品功能的前提下去读代码,而不是反过来看代码来了解功能。目前来看测试用例能如实反映产品功能,测试执行也如实反映了产品功能,否则测试用例就会执行失败。所以,对测试用例的理解应再上升到另一个高度,测试用例能够体现产品描述文档的功能。所以,要求编写的测试用例足够详细、测试用例的组织要有条理,这些单靠Word、Excel或者One Note这样通用的工具是无法实现的,需要使用专业的测试用例管理工具来辅助,例如,Mercury Interactive公司生产的企业级测试管理工具Test Director。

对于自动化测试用例而言,代码在编写上应有别于产品代码编写风格,可读性和描述性应是重点考虑内容。在测试代码中,可以引入面向对象、设计模式等优秀的设计思想,但是一定要适度使用,通常面向过程的编码方式更利于组织、阅读和描述。

5 测试用例的设计方法

5.1 等价类划分法

等价类划分法是把所有可能的输入数据,即程序的输入域划分成若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例。该方法是一种重要的常用的黑盒测试用例设计方法。

在进行测试用例设计时,要同时考虑有效等价类和无效等价类,这样能使软件接受合理的数据,验证合理的功能,也要经受住不合理的意外考验,增强程序的容错能力,确保软件的测试具有更高的可靠性。

有效等价类:是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。

无效等价类:与有效等价类的定义相反,无效等价类指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。对于具体的问题,无效等价类至少应有一个,也可能有多个。

5.2 边界值分析方法

边界值分析方法是对等价类划分方法的补充,也是黑盒测试方法之一,是对等价类分析方法的一种补充。

在测试工作中得出的经验证明,大量错误发生在输入或输出的边界值上,所以,设计各种边界值的测试用例,可以发现更多BUG。

使用边界值分析方法设计测试用例,首先应确定边界情况,通常输入或者输出等价类的边界,着重测试的边界情况,应选取正好等于或者略大于或者略小于便界的值作为测试数据,而不是选择等价类中的典型值或者任意值作为输入数据。

基于边界值分析方法选择测试用例的原则如下:

(1)如果输入条件规定了值的范围,则应取刚达到这个范围边界的值,或者刚刚超过这个范围边界的值作为测试输入数据;

(2)如果输入条件规定了值的个数,则用最大个数、最小个数、比最小个数少一、比最大个数多一的数作为测试数据;

(3)根据规格说明的每个输出条件,使用前面的原则;

(4)根据规格说明的每个输出条件,应用前面的原则;

(5)如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例;

(6)如果程序中使用了一个内部数据结构,则应选择这个内部数据结构的边界上的值作为测试用例;

(7)分析规格说明找出其他可能的边界条件。

5.3 案例

以计算三角形面积的程序为例,运用基本的测试用例设计方法灵活设计测试用例。

某程序需要实现如下功能:输入3个整数D、E、F,输出D、E、F为三边的三角形面积(1<=D、E、F<100),结果保留2位小数。

分析:可以运用等价类和边界值的方法,编写测试用例,具体分析见图1:

根据上面的分析,设计出计算三角形面积测试用例,见表1:

6 结语

影响软件测试的因素很多,如软件的复杂度、团队成员的素质、测试方法、测试技术等。因为某些客观因素存在,有些因素是波动的、不稳定的,会影响测试者的情绪,这种情况下测试用例在软件测试中发挥重要的指导作用。只有理解测试用例的设计原则、设计方法,和具体业务相结合,设计出合理的、高覆盖率、高容错率的测试用例,测试用例才能更好地规范测试执行人员对软件产品进行测试,使软件产品质量得到保障,人们才能使用到高质量的软件产品。

摘要：随着科技的发展,电脑、手机等电子产品的普及,软件的应用越来越普遍,软件测试的重要性得到越来越多的关注。软件产品的测试质量如何保障,重点还是在软件的测试用例设计上,软件测试用例设计的合理性、覆盖率和容错能力,决定了软件产品本身的质量。基于此,介绍了软件测试的基本概念、软件测试用例设计的原则和软件测试用例设计几个基本方法。

关键词：软件测试,测试用例设计,等价类划分法

参考文献

[1]郑人杰.计算机软件测试技术[M].北京:清华大学出版社,1992.