测试用例设计

级别: 初级 John Smith , 技术工程师 2005 年 1 月 01 日 本文描述了基于用例进行评估的一个框架。为了使描述更加具体，本文为框架的参数选择了一些值，尽管这些值有待于论证，但它们并不总是错误的。像往常一样，随着数据的搜集，这种估计应该根据实际情况和重新估计的参数值进行测试。这种框架对于不同种类的系统考虑了用例层次、规模和复杂度等思想，并且不再采取细粒度的功能分解。为减轻计算的负担，对于诸如 Estimate Professional 这样的工具，可以构建一个前端，从而提供一种基于用例的规模输入的不同的方法。 问题 直观上看起来似乎根据用例模型的特征，可以对开发工作所需的规模和工作量进行估计。毕竟，用例模型捕获了功能性需求，那么难道不应该有基于等价于功能点的用例吗？这里存在许多困难： 有许多不同的用例规格样式和形式，很难定义一个度量标准，例如，某人可能希望能够度量用例的长度； 用例应该代表外部参与者对于系统的观点，因此，500,000 sloc 系统的用例就与 5,000 sloc 子系统的用例在完全不同的层次上（Cockburn 97 讨论了层次和目标的概念）； 用例可能在复杂性方面不同，编写时是显式的，实现时又是隐式的。 用例应该从参与者的角度来描述行为，但是这可能相当复杂，特别是当系统具有状态时（绝大多数情况是这样的）。所以描述这种行为需要系统的模型

1. 引言 1.1 编写目的 编写此文档的目的主要在于确定整个测试阶段建立测试测试的内容和范围，以供软件测试人员作为软件测试实施的参考。 1.2 项目背景 项目名称：燃烧我的卡路里 项目提出者 /开发者/实施单位：跑酷来了成员小组 项目用户： “约跑”APP 使用者 与其他系统的关系：在安卓系统上独立运行 1.3 缩写说明 无 1.4 术语定义 约跑：按照速度或者性别匹配伙伴并一起跑步； 1.5 参考资料 [1]窦万峰.软件工程与实践[M].北京：机械工业出版社,2018 1.6 版本信息 修改编号 修改日期 修改后版本 修改位置 修改内容概述 1 2019.6.17 1.0 全部 完成第一次编写 2. 任务概述 2.1 测试目标 本测试的覆盖范围： 登录和注册模块 个人信息模块 约跑和 GPS 模块 通过测试，达到以下目标： 测试运行是否稳定 测试已实现的项目是否达到预期要求 测试是否能够运行正常的功能 2.2 测试环境 硬件环境： Android手机，笔记本电脑 软件环境： Android Studio 2.3 需求描述 2.3.1 数据需求 数据名称 名称含义 数据类型 数据长度 说明 Uid 用户名称 Varchar 12 由用户自设 Password 用户密码 Varchar 12 由用户自取 Uphone 用户手机号 Int 11 Usex 用户性别 Varchar 5

一、测试用例： 　　 1、定义： 　　为特定的目的而设计的一组测试输入、执行条件和预期的结果，它是执行的最小实体。 　　简单地说，测试用例就是设计一个场景，使软件程序在这种场景下，必须能够正常运行并且达到程序所设计的执行结果，一个好的测试用例是指很可能找到迄今为止尚未发现的错误的测试。 　　 2、作用： 　　（1）、指导测试的实施 　　（2）、提高测试效率 　　（3）、规划测试数据的准备 　　（4）、评估测试结果的度量基准 　　（5）、分析缺陷的标准 　　 3、特性： 　　（1）、需求覆盖的完整性 　　（2）、有效性 　　（3）、易理解性 　　（4）、清晰性 　　（5）、可复用性 　　（6）、可维护性 　　 4、设计要素： 　　（1）、用例ID （必需项） 　　（2）、用例概述（必需项） 　　（3）、用例优先级（必需项） 　　（4）、前置条件（可选项） 　　（5）、操作步骤（必需项） 　　（6）、测试数据（必需项） 　　（7）、预期结果（必需项） 　　（8）、备注（可选项） 　　（9）、对应BUG_ID（可选项） 　　 5、书写规范： 　　（1）、用例概述：简明扼要对该用例设计的目的进行描述。 　　（2）、用例优先级：功能性的、流程性、业务规则的、接口的用例优先级最高，必须执行。一些页面的用例优先级会相对较低，可选择执行，优先级别需要视需求而定。 　　优先级必须定义

1 目的 测试用例是测试人员执行测试的基本依据，因此测试用例质量的高低直接影响测试的有效性和效率。为了保证测试执行人员使用最有效的测试用例，使测试工作能有序、合理化的进行，从而提高实施测试时对所测产品、系统或者模块的测试质量，最终提高仁科互动公司产品线的质量。特编写统一测试用例编写规范，为测试设计人员提供测试用例设计编写指导，提高编写用例的可读性、可执行性、合理性。 2 用途 适用于对各业务线测试人员对功能测试用例和接口测试用例的编写。 3 用例设计流程 测试分析： 进行测试用例编写的前提。测试人员根据产品部门提供的PRD、用户故事以及研发部提供的设计文档进行测试需求分析，找出明显的和隐含的需求。有些需求无法从需求文档中获得，可借助概要设计文档或者详细设计文档，或直接从最终的软件产品上获得。 测试设计： 依据测试分析整理并编写出测试用例大纲，并将测试大纲细化为测试用例。测试用例大纲用脑图的形式进行管理，在时间受限的情况下，测试用例评审对象是脑图，详细测试用例会抽取一些作为附加评审对象。参加的人员应包括测试负责人、项目经理、开发人员及其他相关的测试人员。 测试用例完善： 测试用例编写完成之后需不断完善，软件产品新增功能或更新需求后，测试用例必须定期修改更新；在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善；产品上线后客户反馈的软件缺陷

为什么编写测试用例 1. 指导测试工作有序进行，使实施测试的数据有据可依 2. 确保所实现的功能与预期的需求相符合 3. 完善软件不同版本之间的重复性测试 4. 跟踪测试进度，确定测试重点 5. 评估测试结果的度量标准 6. 增强软件的可信任度 7. 分析缺陷的标准 设计测试用例的优缺点 好处： 有效性、完整性、组织性 缺点： 测试用例的设计是费时费力的工作，往往设计测 试用例所花费的时间比执行所花费的时间还长。 测试用例概念： 测试用例其实就是根据需求文档，或者结合软件功能，把自己测试思路有条理的整理出来。 测试用例书写工具： • Word • Excel • 使用工具 • 根据公司具体情况制定模版 大部分公司通过Excel书写测试用例 测试用例书写依据 1.需求说明书 2.项目测试需求功能点 3.所属行业的业务知识掌握程度 4.测试工程师本人的理解程度（个人经验） 注： 必须有需求文档 ， 若没有需求文档 ， 就必须对产品功能熟悉 ，但是两者都必须要对软件业务功能熟悉。 实际工作中，有些公司没有需求文档做参考，这时候就必须要相关人员书写文档，如果不书写文档后期很多测试工作无法开展，甚至会做很多无用功。 测试用例书写目的 为测试设计人员提供测试用例编写的指导，提高编写的测试用例的可读性，可执行性、合理性。为测试执行人员更好执行测试，提高测试效率，最终提高公司整个产品的质量。

评审的内容有以下几个方面： 　　1) 用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。 　　2) 优先极安排是否合理。 　　3) 是否覆盖测试需求上的所有功能点。 　　4) 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法。 　　5) 是否已经删除了冗余的用例。 6) 是否从用户层面来设计用户使用场景和使用流程的测试用例。 　　7) 是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。 其它几个关键认知： 测试用例是动态的，一旦测试环境、输入、输出发生了变化，测试用例都需要相应发生变化。所以复杂的测试用例不便于维护，而过于简单的用例不方便他人阅读也不利于历史追溯（比如有些必要条件没有记录，过一两个月后，再执行这条用例时或许就忘记了无法继续执行下去，如权限和角色组合测试的组合条件），所以应该不断完善用例设计方案，根据项目周期定期进行用例维护安排，大多数文档不是不想去维护而是不知道怎么维护，从而无从下手。测试度量值，测试覆盖表和测试通过或不通过的测试用例清单列表。 测试用例设计的重要性表现为： 1、测试用例量化了测试工作，为测试需求覆盖程度提供了依据，为判定测试执行程度提供了依据，也为测试工作量完成程度提供了依据，测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少

. 测试用例是软件测试的核心 软件测试的重要性是毋庸置疑的。但如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。每个软件产品或软件开发项目都需要有一套优秀的测试方案和测试方法。 影响软件测试的因素很多，例如软件本身的复杂程度、开发人员（包括分析、设计、编程和测试的人）的素质、测试方法和技术的运用等等。因为有些因素是客观存在的，无法避免。有些因素则是波动的、不稳定的，例如开发队伍是流动的，有经验的走了，新人不断补充进来；一个具体的人工作也受情绪等影响，等等。如何保障软件测试质量的稳定？有了测试用例，无论是谁来测试，参照测试用例实施，都能保障测试的质量。可以把人为因素的影响减少到最小。即便最初的测试用例考虑不周全，随着测试的进行和软件版本更新，也将日趋完善。因此测试用例的设计和编制是软件测试活动中最重要的。测试用例是测试工作的指导，是软件测试的必须遵守的准则。更是软件测试质量稳定的根本保障。 2 . 什么叫测试用例 测试用例（Test Case）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件

白盒测试 白盒测试 把测试对象看作一个打开的盒子，测试人员依据程序内部逻辑结构相关信息，设计或选择测试用例，对程序所有逻辑路径进行测试，通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。 语句覆盖：就是设计若干个测试用例，运行被测程序，使得每一可执行语句至少执行一次。 判断覆盖：使设计的测试用例保证程序中每个判断的每个取值分支至少经历一次。 条件覆盖：是指选择足够的测试用例，使得运行这些测试用例时，判定中每个条件的所有可能结果至少出现一次，但未必能覆盖全部分支。 条件判定覆盖：就是设计足够的测试用例，使得判断中每个条件的所有可能取值至少执行一次，同时每个判断的所有可能判断结果至少执行，即要求各个判断的所有可能的条件取值组合至少执行一次。 条件组合覆盖：在白盒测试法中，选择足够的测试用例，使所有判定中各条件判断结果的所有组合至少出现一次，满足这种覆盖标准成为条件组合覆盖。 补充： （1）语句覆盖在所有的测试方法中是一种最弱的覆盖。 （2）判定覆盖和条件覆盖比语句覆盖强，满足判定/条件覆盖标准的测试用例一定也满足判定覆盖、条件覆盖和语句覆盖。 （3）路径覆盖也是一种比较强的覆盖，但未必考虑判定条件结果的组合，并不能代替条件覆盖和条件组合覆盖。 举例 希望对你有用有用 软件工程考试的的拿走 加油 来源： CSDN 作者： 黑哥，走一遭 链接： https://blog

================================================================================= PO设计模式： 测试对象和测试用例 分离。 用例当中：没有元素定位，没有元素操作。 只有页面的行为调用。 测试对象： 元素定位，页面行为。 TestCases,PageObjects,TestDatas,PageLocators TestCases = PageObjects + TestDatas | PageLocators 分离测试数据： 1）部分数据共用。 2）方便维护。 修改测试数据 3）环境切换：SIT - 预发布() - 生产 管理测试数据？？ 1、excel管理 - 2、配置文件 - 3、yaml 4、python?? 1、命名规范 - 文件命名/页面 XX_page_locs.py 2、业务层级 - 3、 自动化的用例设计原则(前置/步骤/后置 - 测试顺序)： 1）用例尽量保持独立性。 其它的用例成功失败，都不会影响本用例的执行。 1）每一个用例，打开关闭浏览器。环境准备和清理工作。 2）有必然业务： 流程，5个角色。申请人 - 审批1 - 审批2 - 审批3 -审批4 - 1 2）用例尽量简单(太复杂的用例不做自动化)。 - 复杂用例 -拆成多个子用例实现。 3）正常场景。–主流程覆盖。 异常场景

我们应当怎样做需求分析？ 成功的软件项目都是一样的，失败的项目却各有各的问题。不过归根到底还是需求的问题。正是我们在需求分析过程存在的巨大隐患，最终导致了那么多项目的失败。 只有深入地去理解客户的业务，最后做出来的东西必然是客户满意的。当客户提出业务变更的时候，一定不能被客户牵着走。要从业务角度深入的去分析，他为什么提出变更，提得合不合理，我有没有更合理的方案满足这个需求。当我们提出更加合理的方案时，客户是乐于接受的，变更也变得可控了。 客户提出的原始需求往往是不考虑技术实现，基于非计算机管理的操作模式提出来的。但我们作为技术人员，需求分析必须实事求是的、基于技术可以实现的角度去考虑。所以我们必须要基于技术实现去引导客户的需求。 软件项目的需求调研首先必须要进行角色分析，然后对不同的角色分别进行调研。 在敏捷开发过程中，需求分析阶段不可能解决所有的需求问题，因此在设计、开发、测试，直到最终交付客户，这整个过程都应当不停地用开发的成果与客户交流，及时获得反馈。只有这样才能及时纠正需求理解的偏差，保证项目的成功。 我们应当怎样做需求调研？ 首先是双方初步认识，这个时候需要树立良好的职业威信，在交谈中进行详细角色分析，将与会各方代表对号入座，最后从宏观上制订目标与方案。 做好初步认识之后，接下来就要一一去拜访这些对应角色了。需求不是一蹴而就，在这漫长的时间里