如何编写测试用例及测试规范.ppt

如何编写测试用例及测试规范培训 什么是测试用例呢？ 测试用例其实就是一个个你测试的想法，你有了这些想法以后， 详细地写下来，就成了测试用例。 什么是测试用例： 测试用例有几个重要的组成部分： （1）简明扼要的标题； （2）详细的步骤； （3）正确的预期结果。 我们还是通过一个例子来说明： 例如：我们在测试记事本的时候，有了一个想法：应当 测试一下这个软件能不能编辑中英文混合输入的内容，如下图 所示。为了准确地实现我们想要测试的思想，我们要把它写下 来，并且写下的内容要让任何人来看都没有歧义。 测试用例：验证记事本程序可以编辑中英文混合的 内容 u 测试步骤： 1. 运行记事本程序； 2. 切换到中文输入法，输入中文“学习编写”； 3. 切换到英文输入法，输入英文TestCase； 4. 保存文件，文件名为testcase.txt； 5. 关闭记事本程序； 6. 双击testcase.txt以打开文件。 u 预期结果： 1. 文件的内容是“学习编写TestCase”，如下图所示。 优先级： 测试用例还有一个优先级的概念，就是用来区分哪些 用例更重要。一般可以分为5个级别，分别用0-4来表示， 数字越小表示越重要。如果项目小，优先级的好处不容易 显现出来。当项目比较大，时间又不宽裕时，可能只能执 行更重要的测试用例，这个时候优先级的重要性就体现出 来了。 大家也看到了，其实写测实用例并不难，但是它仍然容易出一些问题， 例如： （1）含混不清或者与内容不相符的标题。例如，上面的例子，如果用 例叫“验证记事本可以编辑内容”，这个标题就没有准确表达出测试用例 的实际内容。 （2）过于简单的步骤。这是一个容易犯的错误，很多朋友在编写用例 的时候，总是写得很简单，例如上例中的多个步骤可能就会变成惟一的一 步：“输入学习编写TestCase”，如果不是作者本人，其他人来看，肯 定会引起歧义，怎么输入，是用键盘还是用拷贝的方法？那么写测试用例 要详细到什么程度？就是让一个不了解你的工作的人来看，如果他的理解 和你一样，说明你已经表达清楚了。 （3）没有写明预期结果。这是个严重的问题，如果没有预期的结果， 那什么是对的什么又是错的呢？如果对错都分不清楚，做测试的意义又是 什么呢？ （4）多个用例混在一个用例中。这也是刚入门的朋友容易出现的“好 心办坏事”的情况，把测试用例写得特别长，包括了很多内容，这样很容 易引起混淆，不如分开。而且，如果有多个用例混在一起，你的用例标题 怎么写？另外，如果其中有几个用例通过，而另外几个没有通过，这时测 试的结果很难记录，无论是把这个大的用例记录为通过或者不通过都不合 适。 上面列出来的几个问题，大家可以尽量避免。实际上，写测 试用例最难的地方是，如何把测试用例写得全面？这只能靠实践经验 的积累了。你看完这节文章以后，可以拿记事本这个程序来练练，学 着写几个测试用例，“看花容易绣花难”，所以要多试试。 如何执行测试用例： 虽然在上一节中我们讨论了如何编写软件测试用例，但如果你真是一位软 件测试的入门者，你到单位报到后接手的第一项工作很可能是执行软件测试用 例，而不是去编写。你不要因此而郁闷，这样的安排是合理的，因为你毕竟是 个新手，执行软件测试用例是一个迅速熟悉当前测试工作的好机会，而且压力 不大。因为在英语中执行测试用例是run case，所以有些公司把执行测试用例 叫做“跑case”，想来也很形象。这也可以算是一种行话，你可以了解一下。 为方便讨论，我们以上节中的测试用例为例： u 测试用例：验证记事本程序可以编辑中英文混合的内容。 u 测试步骤： 1. 运行记事本程序； 2. 切换到中文输入法，输入中文“学习编写”； 3. 切换到英文输入法，输入英文TestCase； 4. 保存文件，文件名为testcase.txt； 5. 关闭记事本程序； 6. 双击testcase.txt以打开文件。 u 预期结果： 1. 文件的内容是“学习编写TestCase”。 当我们面对这个用例的时候，我们首先要做的是清晰且正确地理解用 例，不带半点含糊。测试的特点就是严谨，你来执行一个测试用例就是要 贯彻用例编写者的测试思想，不能有误解或曲解，不能用自己的主观意志 去代替原来的意思。例如，第一步“运行记事本程序”，你就应当清楚地 知道“记事本”是哪个程序，如果有疑问马上问清楚，否则，如果真的把 测试的产品都弄错了，一切就都白忙了，还浪费了时间。这个例子因为浅 显，所以出现误解的可能性很小，而在实际的工作中，还是会有很多模棱 两可的地方，这个时候我们不能偷懒，要勤学多问。 执行用例不能走样。例如，上例中的第二步，要求输入“学习编写”四个 字，如果你为了省事，拷贝了这几个字，每次都是粘贴过来，快是快了，却违 背了“原著”的意思，这样是不可以的。用例编写者要求用输入法来输入，肯 定是有道理的。如果你发现没有检测“粘贴”的测试用例，可以建议增加，但 不能在执行的时候就偏离了用例的本意。说一个万一的事儿，如果这个软件通 过了你的测试，发布给用户，用户却发现不能输入，只能粘贴，这个责任你能 负得起吗？ 大家可能都知道，做软件测试要细心，这个要求在执行用例的过程中表现 得很明显。我们在执行一个测试用例的时候，不但要注意实际结果是否与预期 结果是一致的，而且在整个过程中都要保持观察。例如上例中，如果第四步执 行保存后，你发现文件名并不是自己输入的testcase.txt，这时你就应当停下 来，因为这就是bug。 我们执行测试用例的目的是什么？就是发现bug，所以，我们在执行测试 用例的过程中，要收集好发现的问题，不能有遗漏。在实际工作中，执行测试 用例的过程一般都是紧张的，工作量很大，并不像我们今天在这里讨论的这么 轻松，因为你要不停地往前赶，所以容易出现一些遗漏的问题。每当发现一个 问题，我们都要做好记录，而不要总以为自己能记得住，好记性不如一个烂笔 头。Bug是最能证明测试工程师工作成绩的东西，好不容易发现了，如果还被 自己遗漏了，岂不令人懊悔？而且，还给产品留下了一个隐患。 测试用例编写规范： u 目的 统一测试用例编写的规范，为测试设计人员提供测试用例编写的指导，提 高编写的测试用例的可读性，可执行性、合理性。为测试执行人员更好执 行测试，提高测试效率，最终提高公司整个产品的质量。 u 使用范围 适用于对产品的业务流程、功能测试用例的编写。 测试用例编写原则： u 系统性 1、对于系统业务流程要能够完整说明整个系统的业务需求、系统由几个子 系统组成以及它们之间的关系； 2、对于模块业务流程要能够说明清楚子系统内部功能、重要功能点以及它 们之间的关系； 测试用例编写原则： u 连贯性 1、对于系统业务流程来说，各个子系统之间是如何连接在一起，如果需要 接口，各个子系统之间是否有正确的接口；如果是依靠页面链接，页面链 接是否正确； 2、对于模块业务流程来说，同级模块以及上下级模块是如何构成一个子系 统，其内部功能接口是否连贯 测试用例编写原则： u 全面性 1、应尽可能覆盖程序的各种路径 2、应尽可能覆盖系统的各个业务 3、应考虑存在跨年、跨月的数据 4、大量数据并发测试的准备 5、系统中各功能、业务的异常情况 测试用例编写原则： u 正确性 1、输入用户实际数据以验证系统是否满足需求规格说明书的需求。 2、测试用例中的测试点应保证至少覆盖需求规格说明书中的各项功能。 测试用例编写原则： u 符合正常业务惯例 1、测试数据应符合用户实际工作业务流程 2、兼顾各种业务变化的可能 3、要符合当前业务行业法律，法规。 测试用例编写原则： u 仿真性 人名、地名、电话号码等应具有模拟功能，符合一般的命名惯例。 测试用例编写原则： u 容错性（健壮性） 程序能够接收正确数据输入并且产生正确（预期）的输出，输入非法数据 （非法类型、不符合要求的数据、溢出数据等），程序应能给出提示并进行相 应处理。 测试用例设计方法： u 等价类划分法： 将所有可能的输入数据（有效的和无效的）划分成若干个等价类。 测试用例设计方法： u 边界值分析法： 指对输入的边界条件进行分析，设计出针对边界值的测试用例。 测试用例设计方法： u 因果图法： 就是利用图解法分析软件输入(原因)和输出条件(结果)之间的关系，以设 计测试用例的方法。因果图法适合于检查程序输入条件的多种情况的组合，并 最终生成判定表，来获得对应的测试用例。 测试用例设计方法： u 功能图法 功能图是描述程序状态变化、转移的过程，因为软件运行或操作的过程可以 看作是其状态不断发生变化的过程。测试用例的设计就是如何覆盖所有软件表 现出来的状态，即在满足输入/输出的一组条件下，软件运行是一系列有次序 的、受控制的状态变化过程。 测试用例设计方法： u 错误推测法 推测法主要依赖经验、直觉来作出简单的判断甚至是猜测，给出可能存在缺陷 的条件、场景等，在找到缺陷后，设计出相应的测试用例。 测试用例设计方法： u 正交实验设计方法 主要步骤是： (1) 对软件需求规格说明中的功能要求进行划分(层层分解与展开)，分解成 具体的、相对独立的基本功能。 (2) 根据基本功能的质量需求，找出影响其功能实现的操作对象和外部因素 ，每个因素的取值可以看作水平，多个取值就存在多个水平。 (3) 确定待测试软件中所有因素及其权值，这是测试用例设计的关键，确保 全面、准确。 权值是依据各因素的影响范围、发生的频率和质量的需求来确定的。 (4) 加权筛选，生成因素分析表。 (5) 利用正交表构造测试数据集，正交表的每一行，就是一条测试用例。考 虑交互作用不可忽略的处理因素和不可混杂的原则，有交互作用的组合优 先安排。 利用正交实验设计方法设计测试用例，可控制生成的测试用例数量，覆盖率高 且测试效率高。 测试用例设计方法： u 接口间测试 测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。 测试用例设计方法： u 数据库测试 依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关 系进行测试。 测试用例设计方法： u 可理解（操作）性 理解和使用该系统的难易程度（界面友好性）。 测试用例设计方法： u 可移植性 在不同操作系统及硬件配置情况下的运行性。 测试用例编写规范： u 测试用例命名规则 以功能模块和业务流程进行命名。 测试用例编写规范： u 用例编号规则：以测试模块名称的第一个字母进行命名（大写），若测试 模块名称比较长时，可进行简写。一般简拼不超过5个字母：如： 测试模块为“用户管理”，功能编号为“YHGL” 测试模块为“行政单位管理”，功能编号为“DWGL” 功能编号规则直接以001、002、003 测试用例编写规范： u 测试用例文档书写内容 1、被测试对象的介绍 2、测试范围与目的 3、测试环境与测试辅助工具的描述 4、功能测试用例主要元素 测试用例编写规范： u 前置/操作描述： 1、前置条件（可选）：系统权限配置或前、后台配置描述（所有进行操作的 前提条件）。 2、操作：测试的操作步骤描述。 u 功能点： 功能点描述。 u 输入数据：前期数据准备。 u 预期结果：描述输入数据后程序应该输出的结果。 u 测试结果：描述本条用例的实际测试情况，并判断实际测试结果与预期结 果的差别。 u Bug编号/Bug简要描述:需要进流程的对应事物流程的编号，及简要说明 u 备注：测试过程中遇到的问题等情况说明。 编写用例注意事项： u 功能检查 1 、功能是否齐全，例如：增加、删除、修改，查询条件是否合理，用户使 用是否方便 2 、功能是否多余 3 、功能是否可以合并 4 、功能是否可以再细分 5 、软件流程与实际业务流程是否一致 6 、软件流程能否顺利完成 7 、各个操作之间的逻辑关系是否清晰 8 、各个流程数据传递是否正确 9 、模块功能是否与需求分析及概要设计相符 10、批量增加、批量修改，增加、修改等录入比较频繁的界面或录入数据量 较多的界面，是否支持全键盘或全鼠标操作，并且使用通用的键实现数据 字段的有序切换 编写用例注意事项： u 面向用户的考虑 1 、操作方便性，如：按键次数是否最少，并不以开发实现技术限制为限制 ，而是以用户使用方便性和应用软件约定和通常的快捷键来实现提出合理 建议 2 、易用性，面对用户的操作是否简单易学 3 、智能化考虑 4 、提示信息是否模糊不清或有误导作用。错误信息是否有用户语言风格的 出错后续处理建议提示 5 、要求用户进行的操作是否多余，能否由系统替代。系统升级后，用户能 否不做任何操作自动进行所有升级的数据、环境等准备工作，包括删除缓 存等动作 6 、能否记忆操作的初始环境，无需用户每次都进行初始化设置 7 、是否不经确认就对系统或数据进行重大修改 8 、能否及时反映或显示用户操作结果 9 、操作是否符合用户习惯，比如：热键 10 、各种选项的可用及禁用是否及时合理 11 、某些相似的操作能否做成通用模块 编写用例注意事项： u 数据处理 输入数据 1 、边界值 2 、大于边界值 3 、小于边界值 4 、最大个数 5 、最大个