测试用例

转自：http://www.51testing.com/html/71/n-865171-2.html 可参考：http://www.cnblogs.com/TestWorld/p/5211043.html 待总结.. 一、测试用例的切面设计 　　所谓测试切面设计，其实就是测试用例大项的划分。测试用例划分的经典方法是瀑布模型，也就是从上到下，逐渐细分，大模块包括小模块，小模块包括更小的模块。但仅仅如此是不够的，我们还要从更多的角度切入系统，从不同的角度把系统切分成一块一块的，来进行测试，从而确保测试大项的完整性。 　　1、功能点切面 　　这是最常见的切面，通常我们认为页面上的一个按钮就是一个功能点。然后我们可以根据功能的复杂程度，按每个功能；或一个功能点分多页；或多个功能点合成一页来进行用例的撰写。 　　2、特定切面 　　除此以外，还有一种特定切面的划分方法，也是用例撰写时经常会用到的。所谓的特定切面，就是忽略掉表面上的功能点，而关注测试对象的某一个面。比如我们的内部管理系统提供了销售录入导入、注册录入导入等功能，从菜单划分上对应了七八个功能点。但这些功能处理后台有个共同的处理项就是授权记录的生成，这时我们就可以把“授权记录生成”单独拿出来做一个测试项，而在其它测试项中涉及这一部分的用例就不必再一一撰写。此外象一些界面共通的操作用例单独写成一页，也是一种特定切面

在过去的几周里，我们学习了黑盒测试，今天对黑盒测试进行总结。 黑盒测试： 方法概述： 　　　这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。黑盒测试又叫做功能测试或数据驱动测试。 测试目标： 　　（1）检查程序功能能否按需求规格说明书的规定正常使用，测试各个功能是否有遗漏，检测性能等特性要求是否满足。 　　（2）检测人机交互是否错误，检测数据结构或外部数据库访问是否错误，程序是否能适当地接收输入数据而产生正确的输出结果，并保持外部信息（如数据库或文件）的完整性。 　　（3）检测程序初始化和终止方面的错误。 黑盒测试的方法分为：等价类划分法，边界值分析法，因果图法 由于等价类划分法在前面已经介绍过，在此不再赘述，详见： http://www.cnblogs.com/yueyingky/p/4357729.html 下面介绍边界值分析法： 概念： 　　边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。 使用边界值分析法的原因： 　　无数的测试实践表明，大量的故障往往发生在输入定义域或输出值域的边界上，而不是在其内部。因此，针对各种边界情况设计测试用例，通常会取得很好的测试效果。

一、语句覆盖(Statement coverage) “ 语句覆盖 ”是一个 比较弱的 测试 标准，它的 含义是：选择足够的测试用例， 使得程序中每个语句至少都能被执行一次。 图 6.4 是一个被测试的程序，它的源程序是： PROCEDURE M(VAR A ， B ， X ： REAL) ； BEGIN IF (A>1) AND (B=0) THEN X := X/A ； IF (A=2)OR (X>1) THEN X := X+1； END. 为使程序中每个语句至少执行一次，只需设计一个能通过路径 ace 的例子就可以了，例如选择输入数据为： A=2 ， B=0 ， X=3 就可达到“语句覆盖”标准。 从本例可看出，语句覆盖实际上是很弱的，如果第一个条件语句中的 AND 错误地编写成 OR ，上面的测试用例是不能发现这个错误的；又如第三个条件语句中 X ＞ 1 误写成 X ＞ 0 ， 这个测试用例也不能暴露它，此外，沿着路径 abd 执行时， X 的值应该保持不变，如果这一方面有错误，上述测试数据也不能发现它们。 总之，一般认为“语句覆盖”是很不充分的一种标准。 二、判定覆盖(Decision coverage) 比“语句覆盖”稍强的覆盖标准是“ 判定覆盖 ” ( 或称 branch coverage分支覆盖 ) 标准。 含义 是：执行足够的 测试 用例，

逻辑覆盖是以程序内部的逻辑结构为基础的设计测试用例的技术。它属白盒测试。逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。 六种覆盖标准发现错误的能力呈由弱到强的变化： 1.语句覆盖 2.判定覆盖 3.条件覆盖 4.判定/条件覆盖 5.条件组合覆盖 6.路径覆盖 对上述6种覆盖标准的具体介绍： 1.语句覆盖（Statement Coverage）：就是设计若干个测试用例，运行被测程序，使得程序中每一可执行语句至少执行一次。这里的“若干个”，意味着使用测试用例越少越好。语句覆盖在测试中主要发现缺陷或错误语句。 语句覆盖率的公式：语句覆盖率=被评价到的语句数量/可执行语句总数x100% 语句覆盖的缺点：对程序执行逻辑的覆盖很低。 2.判定覆盖（Decision coverage）： 有时也称分支覆盖，就是指设计若干测试用例，运行被测程序，使得每个判定的取真分支和取假分支至少评价一次。 判定覆盖的公式： 判定覆盖率=被评价到的判定分支个数/判定分支的总数X100%。 判定路径覆盖率（DDP）=被评价到的判定路径数量/判定路径的总数X100%。 判定覆盖的缺点：判定覆盖虽然把程序所有分支均覆盖到了，但其主要对整个表达式最终取值进行度量，忽略了表达式内部取值。 3.条件覆盖（Condition Coverage）： 设计足够多的测试用例，运行被测程序

软件当中为什么会引入缺陷？ 只要是人，都会犯错。即使是一个优秀的程序员，也会犯低级性的错误，根据数据统计，即便是优秀的程序员，开发的软件产品中，如果未经过测试，代码中遗留的缺陷至少在每千行代码6个以上。 常见的导致软件中存有缺陷的根源有： 1、缺乏有效的沟通，或者没有进行沟通 2、软件复杂度 3、编程错误 4、不断变更的需求 5、时间的压力 6、缺乏文档的代码 7、软件开发工具 8、人员的自大 缺陷的类型及严重级别 软件错误（software error） 软件缺陷（software defect） 软件故障（software fault） 软件失效（software failure） 软件失效机理可描述为：软件错误->软件缺陷->软件故障->软件失效 软件错误：在整个软件生存周期的每个阶段，都贯穿着人的直接或间接地干预。然而，人难免犯错误，这必然给软件留下不良的痕迹。软件错误是指在软件生存期内的不希望或不可接受的认为错误，其结果是导致软件缺陷的产生。可见，软件错误是一种人为过程，相对于软件本身，是一种外部行为。 软件缺陷：软件缺陷是存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差，如少一个逗号，多一个语句等，其结果是软件运行于某一特定条件时出现软件故障，这时称软件缺陷被激活。 软件故障：软件故障是指软件运行过程中出现的一种不希望或不接受的内部状态。比如

软件需求规格说明书模板 修订历史 版本 说明 编制 批准 批准日期 1.1 初次编写 SEPG 目　录 1. 引言 1 1.1. 背景 1 1.2. 参考资料 1 1.3. 假定和约束 1 1.4. 用户的特点 1 2. 功能需求 1 2.1. 系统范围 1 2.2. 系统体系结构（二层架构的系统可剪裁本小节） 1 2.3. 系统总体流程 2 2.4. 需求分析 2 2.4.1. XXXXXXX(功能需求名称) 2 2.4.1.1. 功能描述 2 2.4.1.2. 业务建模 2 2.4.1.3. 用例描述 3 2.4.1.4. 用户界面 5 2.4.2. XXXXXXX(功能需求名称) 5 3. 非功能需求 5 3.1. 性能要求 5 3.1.1. 精度 5 3.1.2. 时间特性要求 6 3.1.3. 输人输出要求 6 3.2. 数据管理能力要求 6 3.3. 安全保密性要求 6 3.4. 灵活性要求 6 3.5. 其他专门要求 6 4. 运行环境规定 6 4.1. 设备 6 4.2. 支持软件 7 4.3. 接口 7 4.4. 控制 7 5. 需求跟踪 7 6. 签批单 7 1. 引言 1.1. 背景 说明： a．待开发的软件系统的名称； b．本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络； C．该软件系统同其他系统或其他机构的基本的相互来往关系。 1.2.

目　录 1. 引言 1 1.1. 背景 1 1.2. 参考资料 1 1.3. 假定和约束 1 1.4. 用户的特点 1 2. 功能需求 1 2.1. 系统范围 1 2.2. 系统体系结构（二层架构的系统可剪裁本小节） 1 2.3. 系统总体流程 2 2.4. 需求分析 2 2.4.1. XXXXXXX(功能需求名称) 2 2.4.1.1. 功能描述 2 2.4.1.2. 业务建模 2 2.4.1.3. 用例描述 3 2.4.1.4. 用户界面 5 2.4.2. XXXXXXX(功能需求名称) 5 3. 非功能需求 5 3.1. 性能要求 5 3.1.1. 精度 5 3.1.2. 时间特性要求 6 3.1.3. 输人输出要求 6 3.2. 数据管理能力要求 6 3.3. 安全保密性要求 6 3.4. 灵活性要求 6 3.5. 其他专门要求 6 4. 运行环境规定 6 4.1. 设备 6 4.2. 支持软件 7 4.3. 接口 7 4.4. 控制 7 5. 需求跟踪 7 6. 签批单 7 1. 引言 1.1. 背景 说明： a．待开发的软件系统的名称； b．本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络； C．该软件系统同其他系统或其他机构的基本的相互来往关系。 1.2. 参考资料 列出本说明书中引用和参考的资料，如： a．本项目的经核准的 计划任务书 或合同

本章介绍UML建模元素 1： Stereotype-也被称为类型、构造型 UML里的元素扩展，简单来说其功能就是在已有的类型上添加一些标记，类似于打个戳，从而生成新的东西。 简单的说加一句话来更加清楚准确描述这个类。 2： Actor（主角、参与者）-是在系统之外与系统交互的某人或某事物，在建模过程中处于核心地位。 参与者和系统之间有一个明确的边界，参与者只能存在于边界之外，边界之内的所有人和事物都不是参与者。 人或物都可以时参与者； 3：如何确定参与者-一定是启动业务的主角 4：业务主角和业务工人 业务主角（business actor）是参与者的一个版型，用于定义业务的主角，不依赖计算机系统。业务主角是与业务系统有着交互的人和事物，用来确定业务范围。 业务范围：项目所涉及的所有客户业务的客观存在；系统范围：软件将要实现对应业务的系统功能。 业务工人被动参与业务 5：参与者和干系人 干系人-是与要建设的这个系统有利益相关的一切人和事 参与者就是干系人代表，对系统提出要求来获得他所代表的涉众的利益。 用户（user），指的是系统的使用者，是参与者的代表，一个用户可以代理多个参与者。 角色（role），指的是参与者的职责，一个角色代表了系统中的一类职责。 6:用例：一种把现实世界的需求捕获下来的方法。用例定义了一组用例实例，其中每个实例都是系统所执行的一系列操作

问题描述： GOJ给C_Shit_Hu，super13，TestN，LOP带来了一个难题：给了a和b，如何知道a ^ b。每个人都反对这个BT问题，所以GOJ使这个问题比开始容易。 这个难题描述: 给了a和b，如何知道a ^ b的最后一位数字。 输入： 有多个测试用例。每个测试用例由两个数字a和b（0 <a，b <= 2 ^ 30）组成 输出： 对于每个测试用例，您应该输出a ^ b的最后一位数字。 输入样例： 7 66 8 800 样本输出： 9 6 注意到检测数字较大,容易造成超时,无法使用常规方法运算 解决方案: #include <stdio.h> #include <string.h> int main(void){ int ans[8]; int index; //答案数组下标 int cnt, n, tmp, i; while(scanf("%d %d", &n, &cnt) != EOF){ //清空答案 index = 0; memset(ans, 0, sizeof(ans)); n %= 10; tmp = n; if(!cnt){ printf("%d\n" ,ans); continue; } //进行答案的输入 while(1){ i = 0; //查重 while(i < index){ if(ans[i++] != tmp){ //未重复

目录 1. 跳过测试用例的执行 1.1. @pytest.mark.skip 装饰器 1.2. pytest.skip 方法 1.3. @pytest.mark.skipif 装饰器 1.4. pytest.importorskip 方法 1.5. 跳过测试类 1.6. 跳过测试模块 1.7. 跳过指定文件或目录 1.8. 总结 2. 标记用例为预期失败的 2.1. 去使能 xfail 标记 3. 结合 pytest.param 方法 往期索引： https://www.cnblogs.com/luizyao/p/11771740.html 实际工作中，测试用例的执行可能会依赖于一些外部条件，例如：只能运行在某个特定的操作系统（ Windows ），或者我们本身期望它们测试失败，例如：被某个已知的 Bug 所阻塞；如果我们能为这些用例提前打上标记，那么 pytest 就相应地预处理它们，并提供一个更加准确的测试报告； 在这种场景下，常用的标记有： skip ：只有当某些条件得到满足时，才执行测试用例，否则跳过整个测试用例的执行；例如，在非 Windows 平台上跳过只支持 Windows 系统的用例； xfail ：因为一个确切的原因，我们知道这个用例会失败；例如，对某个未实现的功能的测试，或者阻塞于某个已知 Bug 的测试； pytest 默认不显示 skip 和 xfail