测试用例概述教学课件电子教案.pptx

第4章 测试用例概述软件测试技术董皊目录内容第1章 软件测试概述第2章 软件测试流程和过程模型第3章 软件测试计划第5章 高效设计测试用例第6章 软件缺陷报告第7章 软件测试报告第8章 易用性测试第9章 Web测试第10章 测试人员的职业能力和技术支持第4章 测试用例概述4.2测试用例的设计获取需求的测试点测试用例模板测试用例的优先级测试用例的设计原则4.3测试用例的维护4.1测试用例简介什么是软件测试用例？软件测试用例是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略，内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。IEEE Standard 829-1983中定义测试用例为：测试用例是指定输入，预期结果和一组测试项的执行条件的文档。4.1测试用例简介测试用例的作用（1）避免盲目测试，提高测试效率编写测试用例有利于测试的组织。在开始实施测试之前设计好测试用例，可以避免盲目测试，提高测试效率，特别是对于测试人员中的新手，好的测试用例可以帮助他们更好地完成复杂的测试任务，提高测试工作的效率。（2）确保功能需求不被遗漏测试用例是根据功能需求细细推敲而来的并且通过了严格的评审，按照测试用例执行测试，可以使软件测试的实施重点突出、目的明确，确保功能不会被漏测。（3）便于回归测试在项目执行测试期间会有多次回归测试，以保证老的缺陷被成功修复，同时没有引入新的缺陷。如果没有测试用例，凭脑子记住之前的操作步骤是不可能的，这样就无法复原原有的测试过程。（4）为测试的度量提供评估基准测试完毕后需要对测试结果进行评估，并且编制测试报告。判断软件测试是否完成、衡量软件测试质量都需要一些量化的结果。比如测试用例的执行率是多少、成功测试用例的执行率是多少、需要的测试合格率是多少，等等。测试用例可以为这些结果提供量化数据和评估的基准。第4章 测试用例概述4.1测试用例简介4.2.1获取需求的测试点4.2.2测试用例模板4.2.3测试用例的优先级4.2.4测试用例的设计原则4.3测试用例的维护测试用例的设计步骤（1）获取需求的测试点分析系统程序的工作流程，明确各个功能模块的需求，明确测试范围，提取所要测试的具体测试点，为编写测试用例提供依据和思路。（2）设计测试用例模板，设计测试步骤确定一份符合规范的测试用例模板，结合软件需求文档，在掌握一定测试用例设计方法的基础上（测试用例设计方法在第5章中会详细讲解），设计出比较全面、合理的测试用例，并且生成规范的测试用例表。（3）确定测试数据根据测试用例表的内容，复审测试用例，并确定支持这些测试用例的实际值，包括用作输入的测试数据、用作预期结果的数据值、用作支持测试用例所需的其他数据。如果是自动化测试的话，在这里需要写自动化测试脚本。（4）评审测试用例软件测试用例在形成文档后还需要评审、更新之后才能算是有效的测试用例。评审会议一般至少会进行两轮。第一轮一般是测试负责人召集测试人员进行小组内部评审；第二轮是与项目有关的其他部门的人员进行的评审，比如项目经理、产品人员、开发人员等。一方面可以再次确认需求和预期结果，另一方面可以让各方再次就需求达成共识，减少出错的可能性。4.2.1 获取需求的测试点做好测试用例的关键就是，对需求和设计文档的理解，以及对系统的熟悉，所以测试用例的基础是软件需求。软件需求决定了测试点，但测试点却不完全来自于软件需求，测试点的来源有显性的和隐性的两种。需求文档是显性需求，而一些通过测试的原则、行业传统和常识推理出来的需求则属于隐性需求，它们无法从需求文档中直接导出。一份可测试的、完整的和详细的需求说明书是对测试工作最大的帮助。但是在实际工作中，需求的定义通常是不完善的，有的项目甚至根本没有需求文档，虽然这从流程上来说绝对是不规范的，但是确实常常因为项目比较紧张存在不少这种缺胳膊少腿的现象。那作为软件测试人员，该如何在这种情况下突围呢？没有需求文档时，应该怎么做：阅读遗留文档，收集整理已有的需求向有关人员咨询参考同类产品的需求说明书采用探索性测试的解决方案它并不预先设计测试用例或者精确地按照一个计划来执行，它依靠的是测试员的知识水平和创造力。探索性测试可以运用在整个计划、编写用例和执行测试过程中。4.2.2 测试用例模板测试用例模板4.2.3 测试用例的优先级在实际软件测试项目中，经常无法在每一个应用程序的版本上执行全部的测试用例。所以在测试资源和时间都有限的情况下，你必须知道哪些测试用例应该被优先执行，哪些测试用例是在有富裕时间的时候可以被增加执行，这很大程度上是由测试用例的优先级来决定的。制定测试用例优先级的好处：可以优先执行优先级高的测试用例，即使测试时间不足，也能尽量保证测试工作达到了良好的效果；可以根据优先级策略，高效分配测试资源，从而达到成本、质量的平衡；可以为待定的自动化测试做一个好的起点。4.2.3 测试用例的优先级Ross Collard在“Use Case Testing”一文中说：“测试用例的前10%到15%可以发现75%到90%的重要缺陷。”测试用例的优先级别划分在不同的公司会有所差异，以下推荐一种常见的测试用例优先级别的定义4.2.3 测试用例的优先级1-小版本确认测试（Build Verification Tests，BVTs）冒烟测试。这是一组需要有限执行以确认该软件版本是否可以继续测试的测试用例。10%15%。2-高（High）最常被执行的、保证功能稳定、目标的行为和能力正常工作的、能发现重要错误的测试用例的集合。20%30%。3-中（Medium）更全面的验证功能的各个方面，主要指异常测试，如边界、断网、容错和配置测试的测试用例。40%60%。4-低（Low）一组最少被执行的测试用例。如GUI、错误信息、可用性、压力和性能测试。10%15%。4.2.3 测试用例的优先级如何把设计好的测试用例放到对应的级别中去，是另一件比较复杂的事情第一步：按照一定的逻辑把软件测试用例先随意进行分级。（1）把所有功能性验证的测试用例标记为“高”优先级；（2）把所有错误和边界值的测试用例标记为“中”优先级；（3）把所有非功能性的测试用例（如性能和可用性）标记为“低”优先级。第二步：提级或降级（1）把“高”优先级的分为：重要的和不十分重要的。把“不十分重要的”降级为“中”优先级；（2）把“中”优先级的分成两组，把“重要的”升级为“高”优先级。（3）把“低”优先级的分成两组，把“重要的”升级为“中”优先级第三步：识别BVTs测试用例。把“高”优先级的分成两组：严重和重要的，把“严重的”测试用例升级为BVTs优先级。4.2.4 测试用例的设计原则测试用例除了应该符合基本的测试用例编写规范，还要遵守以下几条基本设计原则：（1）测试用例的描述要明确测试用例的描述必须是明确的，比如“用户正确操作，系统正常运行”或者“用户非法操作，系统不能正常运行”这样的描述就是不明确的，什么是正确操作？什么是正常运行？这就必然导致测试人员对测试用例的理解不确定，从而引发测试中的错误发生。除了操作步骤的描述要明确，预期结果的描述也必须是明确唯一的。（2）测试用例的描述要简洁虽然我们要求测试用例的操作步骤要足够详细、准确和清晰，但同时也要保证测试用例的简洁性。冗长和复杂的测试用例可读性太差、不利于测试人员理解和操作，甚至有时候自己设计的测试用例，自己都不想执行。但过于简洁也会容易使人产生误解，所以要做到恰到好处，好好锻炼自己语言组织的基本功吧。（3）测试用例对需求的覆盖采用最小化原则比如说，有一个系统功能模块，有3个子功能，那么我们是用一个测试用例覆盖三个子功能呢？还是用三个单独的测试用例分别覆盖三个子功能呢？对于稍微有点规模的项目，推荐后者。因为一旦发现了缺陷，指向性更强，便于调试。（4）测试用例编写要有条理、逻辑性强测试用例可以按照功能点分类、操作顺序等逻辑顺序编写，而不要一会测试这里，一会测试那里，会让人无所适从。（5）功能覆盖全面、深入，能够发现软件中更多的缺陷除了通过测试外，可以多想一些异常的操作流程进行失败测试，试图破坏软件，查看软件的响应情况。4.3 测试用例的维护在测试过程中，测试用例并不是一成不变的，它需要不断的更新和维护，这是一个不断修改完善的过程。无论事先把测试用例设计的如何好，开始执行测试后，肯定又会考虑编写新的测试用例。原因有三（1）在实际项目中，所有需求和设计文档都存在而且包含所有功能路径和场景说明的情况非常罕见，导致编写测试用例时也会有遗留；（2）有时候系统架构和设计阶段错过的细节，直到执行测试阶段才浮出水面，这时候就需要补充测试用例。（3）软件自身的新增功能以及软件版本的更新，导致测试用例也必须同时更新。缺点：耗时，维护量非常大。常见题目二、多选题（1）测试人员甲对测试用例有如下理解，其中正确的是（）A.测试用例中不要求必须给定明确的预期结果。B.测试用例可以使用管理软件来维护。C.编写测试用例费时费力，且实际意义不大，所以不如把这些时间用来做实际的测试。D.测试用例的最终形态是一份文档。（2）测试人员乙对测试用例有如下理解，其中正确的是（）A.测试用例是不需要更新的。B.对每一个测试项目，测试用例必须严格按照模板以相同的细致程度进行文档化。C.测试用例控制软件测试的执行过程，它是对每个测试需求的进一步实例化。D.自动化测试执行过程中，测试用例也要不断进行跟踪和优化。常见题目三、判断题（1）测试用例有利于测试的组织，可以避免盲目测试，提高测试效率，并为测试报告提供量化数据和评估的基准。（）（2）测试用例设计完毕后要进行评审，根据评审意见进行更新。更新之后就尽量不要再改动，以免影响测试的执行。（）（3）在测试项目中，如果没有明确的需求文档，测试人员可以通过阅读遗留文档、向相关人员咨询、参考竞争对手的产品说明、探索性测试这几种方式获取需求。（）（4）探索性测试本身是一个非常强大的测试技术，它可以加强测试，只通过探索性测试就可以保证重要的测试路径不会被遗漏。（）（5）测试用例文档中的“用例编号”主要是便于检索。（）（6）测试数据可以是数据，也可以是文件或具体操作。（）（7）划分测试用例的优先级，可以为待定的自动化测试做一个好的起点，比如BVTs测试用例。（）（8）测试用例中，应重视测试用例的优先级别的划分：BVTS、高、中、低。严格遵守这四个级别不随意变动。下节更精彩