软件测试-测试用例的经典例子

软件测试-测试用例的经典例子
软件测试-测试用例的经典例子

软件测试-测试用例的经典例子

一、等价类划分

问:某程序规定:"输入三个整数 a、 b、 c分别作为三边的边长构成三角形。通过程序判定所构成的三角形的类型,当此三角形为一般三角形、等腰三角形及等边三角形时,分别作计算… "。用等价类划分方法为该程序进行测试用例设计。(三角形问题的复杂之处在于输入与输出之间的关系比较复杂。)

解:

分析题目中给出和隐含的对输入条件的要求:

(1)整数

(2)三个数

(3)非零数

(4)正数

(5)两边之和大于第三边

(6)等腰

(7)等边

如果 a、 b 、 c满足条件( 1 ) ~ ( 4 ),则输出下列四种情况之一:

1)如果不满足条件(5),则程序输出为 " 非三角形 " 。

2)如果三条边相等即满足条件(7),则程序输出为 " 等边三角形" 。

3)如果只有两条边相等、即满足条件(6),则程序输出为 " 等腰

三角形 " 。

4)如果三条边都不相等,则程序输出为 " 一般三角形 " 。

列出等价类表并编号

覆盖有效等价类的测试用例:

a b c覆盖等价类号码

3 4 5(1)--(7)

4 4 5(1)--(7),(8)

4 5 5(1)--(7),(9)

5 4 5(1)--(7),(10)

4 4 4(1)--(7),(11)

覆盖无效等价类的测试用例:

二、边界值分析法

NextDate函数的边界值分析测试用例

在NextDate函数中,隐含规定了变量mouth和变量day的取值范围为1≤mouth≤12和1≤day≤31,并设定变量year的取值范围为

1912≤year≤2050 。

三、错误推测法

测试一个对线性表(比如数组)进行排序的程序,可推测列出以下几项需要特别测试的情况:

I.输入的线性表为空表;

II.表中只含有一个元素;

III.输入表中所有元素已排好序;

IV.输入表已按逆序排好;

V.输入表中部分或全部元素相同。

四、因果图法

有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计。其规格说明如下:若投入5角钱或1元钱的硬币,押下〖橙汁〗或〖啤酒〗的按钮,则相应的饮料就送出来。若售货机没有零钱找,则一个显示〖零钱找完〗的红灯亮,这时在投入1元硬币并押下按钮后,饮料不送出来

而且1元硬币也退出来;若有零钱找,则显示〖零钱找完〗的红灯灭,在送出饮料的同时退还5角硬币。

1)分析这一段说明,列出原因和结果

原因:

1.售货机有零钱找

2.投入1元硬币

3.投入5角硬币

4.押下橙汁按钮

5.押下啤酒按钮

结果:

21.售货机〖零钱找完〗灯亮

22.退还1元硬币

23.退还5角硬币

24.送出橙汁饮料

25.送出啤酒饮料

2)画出因果图,如图所示。所有原因结点列在左边,所有结果结点列在右

边。建立中间结点,表示处理的中间状态。中间结点:

11. 投入1元硬币且押下饮料按钮

12. 押下〖橙汁〗或〖啤酒〗的按钮

13. 应当找5角零钱并且售货机有零钱找

14. 钱已付清

3)转换成判定表:

五、判定表驱动分析方法

问题要求:”……对功率大于50马力的机器、维修记录不全或已运行10年以上的机器,应给予优先的维修处理……” 。这里假定,“维修记录不全”和“优先维修处理”均已在别处有更严格的定义。请建立判定表。

解答:

①确定规则的个数:这里有3个条件,每个条件有两个取值,故应有2*2*2=8种规则。

②列出所有的条件茬和动作桩:

③填入条件项。可从最后1行条件项开始,逐行向上填满。如第三行是:Y N Y N Y N Y N,第二行是:Y Y N N Y Y N N等等。

④填入动作桩和动作顶。这样便得到形如图的初始判定表。

初始判定表⑤化简。合并相似规则后得到图。

软件测试用例设计方法---决策表

决策表,也叫判定表。在所有的功能性测试方法中,基于决策表的测试方法被认为是最严格的,因为决策表具有逻辑严格性。 在一些数据处理问题当中,某些操作的实施以来与多个逻辑条件的组合,既针对不同逻辑条件的组合之,分别执行不同的操作;决策表就是分析和表达多逻辑条件下执行不同操作情况的工具。 1 决策表通常由以下4部分组成: 条件桩(condition stub):列出了问题的所有条件。通常认为列出的条件的次序无关紧要。 动作桩(action stub):列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。 条件项(condition entry):列出针对它所列条件的取值,在所有可能情况下的真假值。作项(action entry):列出在条件项的各种取值情况下应该采取的动作。 2 决策表的生成: (1)确定规则的个数 ?有n个条件的决策表有2n个规则(每个条件取真、假值)。(2)列出所有的条件桩和动作桩 (3)填入条件项 (4)填入动作项,得到初始决策表 (5)简化决策表,合并相似规则

?若表中有两条以上规则具有相同的动作,并且在条件项之间存在极为相似的关系,便可以合并。 ?合并后的条件项用符号“-”表示,说明执行的动作与该条件的取值无关,称为“无关条件”。 举个例子↓↓

3 决策表的优缺点: 决策表最突出的优点是,能够将复杂的问题按照各种可能的情况全部列举出来,简明并避免遗漏。 ? 利用决策表能够设计出完整的测试用例集合。 ? 运用决策表设计测试用例可以将条件理解为输入,将动作理解为输出 4 何种情况下使用? ? 规格说明以决策表形式给出,或较容易转换为决策表;

经典软件测试练习题

练习题 选择题 软件调试的目的是?(A) A. 找出错误所在并改正之 B. 排除存在错误的可能性 C. 对错误性质进行分类 D. 统计出错的次数下列叙述中,哪一项是正确的 ...?(D) A.用黑盒法测试时,测试用例是根据程序内部逻辑设计的; B.测试是为了验证该软件已正确地实现了用户的要求; C.对面向对象程序来说,单元测试的最小单元是每条程序语句,即以分号结尾的程序; D.发现错误多的程序模块,残留在模块中的错误也多。 创建一个基于JUNIT的单元测试类,该类必须扩展? (C) A.TestSuite B. Assert C. TestCase D. JFCTestCase 以下对单元测试,不正确 ...的说法是? (C) A.单元测试的主要目的是针对编码过程中可能存在的各种错误; B.单元测试一般是由程序开发人员完成的C.单元测试是一种不需要关注程序结构的测试;D.单元测试属于白盒测试的一种。 测试驱动开发的含义是? (B) A.先写程序后写测试的开发方法 B. 先写测试后写程序,即“测试先行” C. 用单元测试的方法写测试 D. 不需要测试的开发 用JUNIT断言一个方法输出的是指定字符串,应当用的断言方法是? (C) A.assertNotNull( ) B. assertSame() C. assertEquals() D. assertNotEquals() TestCase是junit.framework中的一个? (C) A.方法 B. 接口 C. 类 D. 抽象类 TestSuite是JUNIT中用来? (A) A.集成多个测试用例 B. 做系统测试用的 C. 做自动化测试用的 D. 方法断言 对于测试程序的一些命名规则,以下说法正确 ..的一项是? (C) A.测试类的命名只要符合Java类的命名规则就可以了; B.测试类的命名一般要求以Test打头,后接类名称,如:TestPerson; C.测试类的命名一般要求以Test结尾,前接类名称,如:PersonTest; D.测试类中的方法都是以testXxx()形式出现。 通常,初始化一个被测试对象,会在测试类的? 中进行。(B) A.tearDown() B. setUp() C. 构造方法 D. 任意位置 以下不属于单元测试优点的一项是? (D) A.它是一种验证行为 B. 它是一种设计行为C.它是一种编写文档的行为 D. 它是一种评估行为 从技术角度分,不是一类的测试是? (C) A.黑盒测试 B. 白盒测试 C. 单元测试 D. 灰盒测试 数据驱动测试也称? (C) A.单元测试 B. 白盒测试 C. 黑盒测试 D. 确认测试 逻辑驱动测试也称? (C) A.单元测试 B. 灰盒测试 C. 白盒测试 D. 用户测试

软件测试用例模板

软件测试用例模板

用例编号TestCase_LinkWorks_WorkEvaluate 项目名称LinkWorks 模块名称WorkEvaluate模块 项目承担部门信息部 用例作者 完成日期2015-5-27 评审负责人 审核日期 批准日期 注:本文档由测试组提交,审核由测试组负责人签字,由项目负责人批准。历史版本: 版本/状态作者参与者起止日期备注 V1.1 一、功能测试用例 此功能测试用例对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确,以及业务规则的实施是否恰当。主要测试技术方法为用户通过GUI (图形用户界面)与应用程序交互,对交互的输出或接受进行分析,以此来核实需求功能与实现

功能是否一致。 用例标识LinkWorks_ WorkEvaluate _02 项目 名称 https://www.360docs.net/doc/c619000039.html, 开发人员模块 名称 WorkEvaluate 用例作者参考 信息 工作考核系统界面设计 (2005_03_28).vsd 测试类型设计 日期 2006-9- 27 测试 人员 测试方法黑盒测试 日期 用例描述前置条件 编号权 限 ( 并 列 测试项测 试 类 别 描述/输入/操 作 期望结果真 实 结 果 备 注

关系) 000 01 无列 表 页 面 导航栏导 航 测 试 浏览\点击导 航连接 详细正确 导航页面 所在位置 000 02 添加删 除修改 按钮 添加修改删 除按钮是否 可用 不可用 000 03 接受、 汇报按 钮 1)不是自 己负责的 数据未考 核之前能 否接受\汇 报 不能 2)属于自 己负责的 未接受之 前时候是 否可以接 受 能

软件测试用例实例非常详细

1、兼容性测试在大多数生产环境中,客户机工作站、网络连接和数据库服务器的具体硬件驱动程客户机工作站可能会安装不同的软件例如,应用程序、规格会有所不同。序等而且在任何时候,都可能运行许多不同的软件组合,从而占用不同的资源。测试目的 操作系统系统软件外设应用软件结果配置说明 Window2000(S) 服务器 WindowXp Window2000(P) Window2003 TestCase_LinkWorks_WorkEvaluate 用例编号LinkWorks项目名称WorkEvaluate模块模块名称研发中心-质量管理部项目承担部门 用例作者2005-5-27 完成日期质量管理部本文档使用部门评审负责人审核日期 批准日期 注:本文档由测试组提交,审核由测试组负责人签字,由项目负责人批准。 历史版本: 备注起止日期参与者作者状态/版本 V1.1 1.1. 疲劳强度测试用例

强度测试也是性能测试是的一种,实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足,测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源(如数据库锁或网络带宽)而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。 测试目的 测试说明 用户并发设置添加10连续运行8前提条件小时,输出/响应输入测试需求/动作是否正常运行1 2小时功能4小时6小时8 小时 2小时功能1 4小时6小时 小时8 一、功能测试用例 此功能测试用例对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确,以及业务规则的实施是否恰当。主要测试技术方法为用户通过GUI(图形用户界面)与应用程序交互,对交互的输出或接受进行分析,以此来核实需求功能与实现功能是否一致。

功能测试用例的设计

功能测试用例的设计 LG GROUP system office room 【LGA16H-LGYY-LGUA8Q8-LGA162】

一、实验目的 1.用因果图法分析原因结果,并决策表设计测试用例。 2.使用场景法设计测试用例。 二、实验内容 1. 将三角形问题的可能结果扩展为:一般三角形、等腰三角形、等边三角形、直角三角形、等腰直角三角形和非三角形,考虑用因果图法设计测试用例,给出完整步骤。 2. 有一个在线购物的实例,用户进入一个在线购物网站进行购物,选购物品后,进行在线购买,这时需要使用帐号密码登录,登录成功后,进行付钱交易,交易成功后,生成订购单,完成整个购物过程。使用场景法设计上述问题的测试用例。 三、实验环境 Windows XP系统 四、实验步骤和结果 1. 将三角形问题的可能结果扩展为:一般三角形、等腰三角形、等边三角形、直角三角形、等腰直角三角形和非三角形,用因果图法设计测试用例,给出完整步骤。具体如下: 1)输入的三边分别为a,b,c(斜边) 且a

2. 行在线购买,这时需要使用帐号密码登录,登录成功后,进行付钱交易,交易成功后,生成订购单,完成整个购物过程。使用场景法设计上述问题的测试用例。

(注:在下面的矩阵中,V(有效)用于表明这个条件必须是 VALID(有效的)才可执行基本流,而 I(无效)用于表明这种条件下将激活所需备选流,“n/a”(不适用)表 对生成的所有测试用例重新复审,去掉多余的测试用例,测试用例确定后,对每一个测

五、实验结果和讨论 成功使用因果图法、场景法设计了测试用例。 六、总结 1.因果图法的定义是一种利用图解法分析输入的各种组合情况,从而设计测试用例的方法,它适合于检查程序输入条件的各种组合情况。 2.在事件触发机制中场景法用得最多。在测试一个软件的时候,先确定基本流也就是测试流程中软件功能按照正确的事件流实现的一条正确流程,接着去确定备选流也就是那些出现故障或缺陷的过程,用备选流加以标注。然后可以采用矩阵或决策表来确定和管理测试用例。

软件测试案例

案例释疑 案例1-1:终点线前的遗憾 说明: 课堂上讲述该案例,目的是让学员明白软件在现代科学中的地位是非常重要的,丝毫软件缺陷都可能带来严重后果。教师不必全部讲述,需摘略其中重点内容。 内容: 作为长期火星探测战略的一个步骤,美国航宇局于1998年12月11日和1999年1月3日先后将两颗探测器送往火星。其中先行一步的火星气候轨道器(MCO)经过6.65亿公里的飞 行,终于在9月份飞到了火星,但在准备进入 绕火星运行的轨道时,却不慎失手,让关注它 的人们大失所望。令人吃惊的是,此次事故的 原因竟是一个非常低级的失误。 根据对进行入轨机动点火前采集到的跟踪数 据的分析,项目官员认为火星气候轨道器失踪 的原因是导航出了重大错误,致使探测器飞到 了比预定高度低很多的高度。实际上,在因飞 入火星背面而与地面“正常”地失去联络之前, 探测器就已经走上了一条将把它带到距火星 表面最近仅57公里的错误路线。这一高度大大低于技术人员提出的约85~100公里的最小安全距离,与预定的140~150公里高度更是相差甚远。高度太低,探测器有可能在火星的大气中因气动热而被“火葬”,甚至还有可能坠毁在火星表面上。 事故发生后,主管该项目的美国航宇局喷气推进实验室等部门迅速开始了调查工作。初步分析时认定,问题可能出在卫星软件上,还可能是地面系统的问题,人员操作失误的可能性也不能排除。但最后查出的结果却让人难以置信:造成飞行高度太低的原因竟然是公制和英制的转换问题。调查人员在9月30日公布的一份报告中称,探测器制造商洛马公司对探测器的一项关键性操作提供的是英制单位的数据,而美国航宇局喷推实验室的导航人员想当然地以为是公制,未加换算便直接将英制数据输入了采用公制数据的计算机系统内,从而造成了严重的导航错误。 问题出在一个导航软件表上。这个出错的推力器校定表用在确定探测器位置的地面导航软件中。它的作用是把遥测到的推力器点火工作次数转换成提供给探测器的冲量,以消除因推力器点火工作造成的弹道计算中的剩余误差。喷推实验室在编制表时对推力器每次工作的冲量使用的是牛·秒这一公制单位,但由洛马公司提供的数据使用的却是英制的磅·秒,而这样计算出的冲量值只是实际值的22%。三轴稳定的该探测器使用反动轮控制姿态,其推力器每隔大约13~15小时点火一次,以降低轮的转速。这些点火工作每次只会引起几毫米/秒的速度变化,但每周要进行11次以上。起初剩余误差很小时,弹道计算可以很快收敛,但到后来收敛性就比较差了。 出现这种低级错误使有关部门感到很难堪。美国航宇局负责空间科学项目的副局长韦勒称,这已不能简单地说成是错误,这是美国航宇局系统工程工作的失败。 案例1-2:“一·一五”大瘫痪 说明: 课堂上讲述该案例,用于让学员明白软件缺陷的危害及缺陷是不可避免的,任何设计上的漏

软件测试用例文档模板(带实例)

软件测试用例模板(带实例) 工程管理系统案例研究项目功能测试用例 编号:Project_MA_Login_1 编号:Project_MA_Interface_3 项目/软件工程管理系统案例研究项目程序版本 1.0.0 功能模块Login 编制人李虎、彭贝贝、唐姣凤用例编号Project_MA_Login_1编制时间 2005-2-22 相关用例Project_MA_Main_1 、Project_MA_Interface_1 、Project_MA_Priority_1 功能特性系统的初始窗体,并进行用户的合法性验证。 测试目的验证是否输入合法的信息,阻止非法登陆,以保证系统的安全特性预置条件数据库中存储了一些用户信息特殊规程说明 (区分大小写) 参考信息需求说明中关于“登录”的说明测试数据用户名= administrators 密码= 1001(数据库表中有相应的信息)操作步骤 操作描述 数据期望结果 实际结果 测试状态(P/F ) 1 选择用户名称,按“提交”按钮。用 户 名 = administrators ,密码为空显示警告信息“帐号 或密码不能为空!” (符合) P 2 选择用户名称,输入错误密码,按 “提交”按钮。用 户 名 为 administrators ,密码=123 显示警告信息 “帐号 或密码不错误!” (符合) P 3 选择用户名称 ,输入密码,按“提交”按钮。 用 户 名 = administrators ,密码 为=1001 进入系统” (符合) P 测试人员 彭贝贝、李绍霞、 唐姣凤 开发人员杨丽娟负责人李虎(手写)

项目/软件工程管理系统案例研究项目程序版本 1.0.0 功能模块Interface编制人李虎、彭贝贝、唐姣凤用例编号Project_MA_Interface_3编制时间2005 – 2– 21 相关用例Project_MA_Interface_1、Project_MA_Interface_2、Project_MA_Priority_1、Project_MA_DBACCESS_1 功能特性维护界面添加操作 测试目的检查维护窗体界面与设计的符合性。 预置条件能够登录进入到系统特殊规程说明(无) 参考信息系统概要设计说明和详细设计说明 测试数据 操作步骤操作描述数据期望结果实际结果测试状态(P/F)1 …………… 2 3 4 5 6 7 8 9 10 11 12 测试人员彭贝贝、李绍霞、 唐姣凤开发人员杨丽娟负责人李虎(手写)

软件测试用例设计--场景分析方法

·软件测试用例设计--场景分析方法 方法简介 现在的软件几乎都是用事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中,可以比较生动地描绘出事件触发时的情景,有利于测试设计者设计测试用例,同时使测试用例更容易理解和执行。 基本流和备选流:如下图所示,图中经过用例的每条路径都用基本流和备选流来表示,直黑线表示基本流,是经过用例的最简单的路径。备选流用不同的色彩表示,一个备选流可能从基本流开始,在某个特定条件下执行,然后重新加入基本流中(如备选流1和3);也可能起源于另一个备选流(如备选流2),或者终止用例而不再重新加入到某个流(如备选流2和4)。 二.实战演习 1. 例子描述 下图所示是ATM例子的流程示意图。

表3-8 场景设计 注:为方便起见,备选流3和6(场景3和7)内的循环以及循环组合未纳入上表。 3.用例设计 对于这7个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式,其中各行代表各个测试用例,而各 列则代表测试用例的信息。本示例中,对于每个测试用例,存在一个测试用例

ID、条件(或说明)、测试用例中涉及的所有数据元素(作为输入或已经存在于数据库中)以及预期结果。 表3-9 测试用例表 4.数据设计 一旦确定了所有的测试用例,则应对这些用例进行复审和验证以确保其准确且适度,并取消多余或等效的测试用例。

测试用例一经认可,就可以确定实际数据值(在测试用例实施矩阵中)并且设定测试数据,如表3-10所示。 表3-10 测试用例表

软件测试技术类面试题集锦(6)十个经典软件测试面试题

软件测试技术类面试题集锦(6)十个经典 软件测试面试题 问题:软件测试技术类面试题集锦(6)十个经典软件测试面试题回答: 1.什么是软件测试,软件测试的目的 参考答案: 什么是软件测试: ·软件测试就是在受控制的条件下对系统或应用程序进行操作并评价操作结果的过程,所谓控制条件应包括正常条件与非正常条件。 ·软件测试过程中应该故意地去促使错误的发生,也就是事情在不该出现的时候出现或者在应该出现的时候没有出现。从本质上说,软件测试是“探测”,在“探测”中发现软件的毛病。 ·软件测试贯穿于软件定义与开发的整个周期,软件的需求规格说明书,结构设计及程序编码,都属于软件测试的对象。 ·软件测试包含白盒测试与黑盒测试,白盒测试是针对程序代码进行正确性检验的测试工作,黑盒测试独立于程序代码,从用户的角度,通过一定的测试步骤与测试案例,验证软件功能、性能等指标能否满足实际应用需求的测试工作。 软件测试的目的: 软件测试的目的是为了保证软件产品的最终质量,在软件开发的

过程中,对软件产品进行质量控制。一般来说软件测试应由独立的产品评测中心负责,严格按照软件测试流程,制定测试计划、测试方案、测试规范,实施测试,对测试记录进行分析,并根据回归测试情况撰写测试报告。测试是为了证明程序有错,而不能保证程序没有错误。 2.软件测试的风险主要体现在哪里 参考答案: 我们没有对软件进行完全测试,实际就是选择了风险,因为缺陷极有可能存在没有进行测试的部分。举个例子,程序员为了方便,在调试程序时会弹出一些提示信息框,而这些提示只在某种条件下会弹出,碰巧程序发布前这些代码中的一些没有被注释掉。在测试时测试工程师又没有对其进行测试。如果客户碰到它,这将是代价昂贵的缺陷,因为交付后才被客户发现。 因此,我们要尽可能的选择最合适的测试量,把风险降低到最小。 3.测试工具在测试工作中是什么地位 参考答案: 国内的很多测试工程师对测试工具相当迷恋,尤其是一些新手,甚至期望测试工具可以取代手工测试。测试工具在测试工作中起的是辅助作用,一般用来提高测试效率。自动化测试弥补了手工测试的不足,减轻一定的工作量。实际上测试工具是无法替代大多数手工测试的,而一些诸如性能测试等自动化测试也是手工所不能完成的。 对于自动测试技术,应当依据软件的不同情况来分别对待,一般自动技术会应用在引起大量重复性工作的地方、系统的压力点、以及

软件测试经典案例

软件测试-测试用例的经典例子 一、等价类划分 问:某程序规定:"输入三个整数 a、 b、 c分别作为三边的边长构成三角形。通过程序判定所构成的三角形的类型,当此三角形为一般三角形、等腰三角形及等边三角形时,分别作计算… "。用等价类划分方法为该程序进行测试用例设计。(三角形问题的复杂之处在于输入与输出之间的关系比较复杂。) 解: 分析题目中给出和隐含的对输入条件的要求: (1)整数 (2)三个数 (3)非零数 (4)正数 (5)两边之和大于第三边 (6)等腰 (7)等边 如果 a、 b 、 c满足条件( 1 ) ~ ( 4 ),则输出下列四种情况之一: 1)如果不满足条件(5),则程序输出为 " 非三角形 " 。 2)如果三条边相等即满足条件(7),则程序输出为 " 等边三角形 " 。 3)如果只有两条边相等、即满足条件(6),则程序输出为 " 等腰三角形 " 。

4)如果三条边都不相等,则程序输出为 " 一般三角形 " 。列出等价类表并编号

覆盖有效等价类的测试用例: a b c覆盖等价类号码 3 4 5(1)--(7) 4 4 5(1)--(7),(8) 4 5 5(1)--(7),(9) 5 4 5(1)--(7),(10) 4 4 4(1)--(7),(11)覆盖无效等价类的测试用例: 二、边界值分析法 NextDate函数的边界值分析测试用例

在NextDate函数中,隐含规定了变量mouth和变量day的取值范围为1≤mouth≤12和1≤day≤31,并设定变量year的取值范围为 1912≤year≤2050 。

三、错误推测法 测试一个对线性表(比如数组)进行排序的程序,可推测列出以下几项需要特别测试的情况: I.输入的线性表为空表; II.表中只含有一个元素; III.输入表中所有元素已排好序; IV.输入表已按逆序排好; V.输入表中部分或全部元素相同。 四、因果图法 有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计。其规格说明如下:若投入5角钱或1元钱的硬币,押下〖橙汁〗或〖啤酒〗的按钮,则相应的饮料就送出来。若售货机没有零钱找,则一个显示〖零

报表测试用例设计方法总结

报表测试用例设计方法总结 报表的测试主要分为以下几个方面:界面,安全性,准确性,展示速度(性能) 数据统计方面 1、报表统计数据的正确性; 2、报表统计数据的完整性; 3、报表统计数据的合法性;比如,统计金额字段需求要求有“$”等; 报表格式 1、表头字段表示的正确性; 2、表头字段表示的完整性; 3、表头字段表示的字体,字号,美观程度; 4、各统计字段的显示是否满足需求;比如:数据过长时要求折行还是缩小; 5、页眉和页角的表示; 报表的预览和印刷 1、预览中的显示完整性; 2、多页情况下,第2页的表头显示; 3、能否实现需求要求的特定印刷情况;(比如,印刷使用指定的模板) 4、预览后印刷; 5、不预览,直接印刷 6、需求规定各类打印机的测试; 数据准确性测试,带有报表测试的系统分为两类,一类是业务系统中,带有统计分析功能模块,该模块中包含分析报表,这个系统的主体是业务系统,报表是为**业务的而提供帮助的。 比如说,应年检统计报表,某月应交罚款车辆统计报表,这样的报表数据准确与否,可通过增加、删减、修改相关业务或相关业务的参数,查看统计报表数据变化,检查数据准确性。

另一类是系统只有统计功能,就是我说的数据仓库展现这类,它与业务系统分离,并且经过多层处理,比如数据仓库的数据,经过抽取,清洗,展现前会经过数据挖掘,数据再处理,有些字段在原始数据表中根本就没有。这样的数据准确性测试比较复杂,当然检查出数据错误,修改定位也是很不容易的。 从整个项目节约成本看,逐层测试效果是最好的。完全修改率也是最高的。 首先建立测试数据模型,模拟所有应用表,建立简单易跟踪的数据用例,底层的数据表测试,方法很原始,嘿嘿,通过SQL语句和手工计算,对数据进行比对。对系统中的报表数据准确性测试方法较为灵活, ①系统中报表重叠的进行比对 ②对子报表汇总与父报表比对,就是对月报表汇总与年报表比对,日报表汇总与月报表比对,这只是一个方面,可以从维度关系考虑,地域,行政级别、时间,个人等方面下手,进行汇总比对 ③这个方法如果延伸点呢,可以将报表间的业务逻辑关系作为比对依据。呵呵,这要看测试人员的需求了解深度个人能力了。插几句不想干的话,做测试工作总让我保持快乐状态,前两天我的一个同事说,公司里一直没有人喜欢做测试工作,这个工作太枯燥。嘿嘿,我当时就说我做了这么多年的测试工作从来没有感觉到枯燥。重复性工作不代表枯燥,编程其实不也是重复嘛,人每天谁不重复昨天的事啊,吃饭,吃这个动作重复一生,有谁觉得麻烦枯燥啦? ④使用SQL和手工计算进行比对。以上是差错方式,接下来讲一下查什么错?哪些地方容易出错 ● 原始表使用错误:因为表比较多,又加上没有统一的数据关系对应表,很容易表使用错误,当然这应该是单元测试检查出来的错误。 ● 数据处理逻辑错误:这一点容易因为测试人员和开发人员对需求理解有偏差造成争执,所以在需求评审时,对数据处理规则用表达式或伪代码表示清楚。还有就是程序员失误,逻辑编写有偏差,边界值、特殊情况处理不当。 ● 数据权限:不同用户对数据有着不同的查看权限。这关系到数据的安全性。 ● 数据误差:数据的保留位数,数据是否是处理计算是否是最后一次计算使用了位数保留和四舍五入。 ● 由于字典表,数据错误,而造成的数据错误,如,根据性别统计,购买量,表中的男女颠倒,或者没有考虑性别缺失项,用了if else,这样就是把表中缺失该项内容的算成了

软件测试案例分析

软件测试案例分析 Document number【980KGB-6898YT-769T8CB-246UT-18GG08】

对软件测试理解 软件测试作为软件质量保证的一种重要方法,近些年来, 软件测试越来越受到产业界、教育界和学术界的重视。软件测试,描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。换句话说,软件测试是一种实际输出与预期输出间的审核或者比较过程。软件测试的经典定义是:在规定的条件下对程序进行操作,以发现程序错误,衡量软件质量,并对其是否能满足设计要求进行评估的过程。 1软件测试的方法 黑盒测试 在黑盒测试(或称功能测试)中,不考虑程序的内部结构和表现,其目的是确定程序的输入与输出是否与其规格一致,力图发现以下几类错误:是否有不正确或遗漏了的功能在接口上,输入能否正确地接受能否正确地输出结果 是否有数据结构错误或外部信息(例如数据文件)访问错误性能上是否能满足要求 是否有初始化或终止性错误 黑盒测试的主要缺点是依赖于规格的正确性(实际情况并非如此)和需要采用所有可能的输入作为测试用例才能保证模块的正确性。 白盒测试 在该方法对软件的过程性细节做细致检查,对程序所有逻辑进行测试。通过在不同点检查程序的状态,确定实际的状态是否与预期的状态一致。测试用例从程序的逻辑中产生。确定程序逻辑覆盖有几条原则,其中之一是语句覆盖,要求程序中的每条语句至少执行一次。这条原则是必要的,但不充分,因为部分错误并不能检测出来。

从上至下测试 从上至下测试从程序的顶点模块开始,然后逐步对较低级的模块进行测试。为了模仿被测试模块的低级模块,需要哑模块或桩子模块。从上至下测试的主要好处就是排除了系统测试和集成,它可以让人们看见系统的早期版本并证明系统的正确性。它的效果之一可以提高程序员的士气。从上至下测试的主要缺点是需要桩子模块,并且在桩子模块中的测试数据直到输入输出模块加入之前不能确定。某些模块的测试数据难以创建,因为桩子模块不能模拟数据流使得模块之间的数据流不能组织成有向无环图。 从下至上测试 从下至上测试策略从程序的最低级模块(不调用别的模块)开始。为了模拟高一级的模块需要驱动模块。当对所有的低一级模块测试完毕才对高一级模块进行测试。从下至上测试方法的优点之一是测试数据的建立不存在困难。尽管数据流不在有向无环图中,但驱动模块模拟所有的调用参数,如果关键模块位于调用模块的底部,则从上至下测试方法更优。从下至上测试的主要缺点是系统的早期版本直到最后模块测试完毕才产生,并且设计和测试一个系统不能重叠进行,因为不可在低级模块设计之前进行测试。 测试用例一般描述

软件测试用例实例(非常详细)汇总

软件测试用例实例(非常详细)汇总

1、兼容性测试 在大多数生产环境中,客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如,应用程序、驱动程序等而且在任何时候,都可能运行许多不同的软件组合,从而占用不同的资源。 测试 目的 配置说明操作系 统 系统 软件 外设应用软件结果 服务器Windo w2000( S) Windo wXp Windo w2000( P) Windo w2003 用例编号TestCase_LinkWorks_W orkEvaluate 项目名称LinkWorks

1.1.

1.2. 疲劳强度测试用例 强度测试也是性能测试是的一种,实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足,测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源(如数据库锁或网络带宽)而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。测试目的 测试说明 前提条件连续运行8小时,设置添加 10用户并发 测试需求输入/ 动作 输出/响应是否正常运行 功能1 2小时 4小时 6小时 8小时功能1 2小时 4小时 6小时

8小时 一、功能测试用例 此功能测试用例对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确,以及业务规则的实施是否恰当。主要测试技术方法为用户通过GUI (图形用户界面)与应用程序交互,对交互的输出或接受进行分析,以此来核实需求功能与实现功能是否一致。 用例标识LinkWorks_ WorkEvaluate _02 项目 名称 https://www.360docs.net/doc/c619000039.html, 开发人员模块 名称 WorkEvaluate 用例参考工作考核系统界面设计

软件测试用例实例[非常详细]

1、兼容性测试 在大多数生产环境中,客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如,应用程序、驱动程序等而且在任何时候,都可能运行许多不 同的软件组合,从而占用不同的资源。 Win dowXp Win dow2000(P) Win dow2003 用例编号TestCase_Li nkWorks_WorkEvaluate 项目名称Li nkWorks 模块名称WorkEvaluate 模块 项目承担部门研发中心-质量管理部 用例作者 完成日期2005-5-27 本文档使用部门质量管理部 评审负责人 审核日期 批准日期 注:本文档由测试组提交,审核由测试组负责人签字,由项目负责人批准。历史版本:版本/状态作者参与者起止日期备注 V1.1 1.1. 疲劳强度测试用例 强度测试也是性能测试是的一种,实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内 存或磁盘空间不足,测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享 资源(如数据库锁或网络带宽)而造成的。强 度测试还可用于确定测试对象能够处理的最大工作量。 测试目的 测试说明

前提条件连续运行8小时,设置添加10用户并发 测试需求输入/动作输出/响应是否正常运行 功能1 2小时 4小时6小时 8小时 2小时 功能1 4小时 6小时8小时 一、功能测试用例 此功能测试用例对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务 规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确,以及业务规则的实施是否恰当。主要测试技术方法为用户通过GUI (图形用户界面)与应用程序交互,对 交互的输出或接受进行分析,以此来核实需求功能与实现功能是否一致。

软件测试案例

软件测试计划 目录 1 前言 (2) 1.1编写目的 (2) 1.2名词解释 (2) 1.3参考资料 (2) 1.4测试摘要 (2) 2 资源需求 (3) 2.1硬件资源 (3) 2.2软件资源 (3) 2.3人力资源 (3) 3 测试详述 (3) 3.1测试范围 (3) 3.2测试目标 (4) 3.3风险和约束 (4) 3.4暂停标准和再启动要求 (4) 3.5测试进度 (4) 4 测试策略 (5) 4.1整体策略 (5) 4.2测试类型 (5) 4.3测试技术 (5) 5 测试提交文档 (6) 6 质量目标 (6) 7 计划审核记录 (6)

1前言 1.1编写目的 说明:对测试计划做一个简单的介绍,说明这个测试计划的功效以及当前项目背景情况介绍。对测试产品(所属行业、系统架构、系统功能等)及其项目目标,以及该文档读者对象、其它相关事项进行一个简要说明。 1.2名词解释 说明:项目中或测试中一些术语的说明,包括使用的专用术语及其定义和缩略语全称及其定 1.3参考资料 说明:包括测试计划引用或参考的文档,查看计划同时需要同查看的相关文档等,这些文档 1.4测试摘要 说明:主要说明测试计划中重要的和可能有争议的问题。主要目的是将这些信息传递给那些可能不会通读整个测试计划文档的人员(比如公司领导、项目经理、产品经理等)。可以考虑以下几块内容。 ●重点事项 列出测试的重点事项。可以将问题按重要程度和优先级罗列出来,然后在后面的章节中再对这些问题进行详细说明,这样就能让对这些问题有重要影响的人员知道问题的所在。 ●争议事项 简要说明争议事项,如与开发人员、项目经理在测试进度,测试策略等方面前期未达成一致的内容。 ●风险评估 通过对技术文档的阅读,对被测系统可能存在的问题:系统设计,数据库设计,响应时间,因测试环境不足可能存在的测试缺陷事先评估出来,以指导测试方案,进行有重点的测试. ●时间进度 简要说明测试开始时间与发布的大致时间或几个大里程碑时间。

软件测试中如何编写单元测试用例(白盒测试)

软件测试中如何编写单元测试用例(白盒测试) 测试用例(T est Case)是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求。 测试用例(T est Case)目前没有经典的定义。比较通常的说法是:指对一项特定的软件产品进行测试任务的描述,体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等,并形成文档。 不同类别的软件,测试用例是不同的。不同于诸如系统、工具、控制、游戏软件,管理软件的用户需求更加不统一,变化更大、更快。笔者主要从事企业管理软件的测试。因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。 随着中国软件业的日益壮大和逐步走向成熟,软件测试也在不断发展。从最初的由软件编程人员兼职测试到软件公司组建独立专职测试部门。测试工作也从简单测试演变为包括:编制测试计划、编写测试用例、准备测试数据、编写测试脚本、实施测试、测试评估等多项内容的正规测试。测试方式则由单纯手工测试发展为手工、自动兼之,并有向第三方专业测试公司发展的趋势。 要使最终用户对软件感到满意,最有力的举措就是对最终用户的期望加以明确阐述,以便对这些期望进行核实并确认其有效性。测试用例反映了要核实的需求。然而,核实这些需求可能通过不同的方式并由不同的测试员来实施。例如,执行软件以便验证它的功能和性能,这项操作可能由某个测试员采用自动测试技术来实现;计算机系统的关机步骤可通过手工测试和观察来完成;不过,市场占有率和销售数据(以及产品需求),只能通过评测产品和竞争销售数据来完成。 既然可能无法(或不必负责)核实所有的需求,那么是否能为测试挑选最适合或最关键的需求则关系到项目的成败。选中要核实的需求将是对成本、风险和对该需求进行核实的必要性这三者权衡考虑的结果。 确定测试用例之所以很重要,原因有以下几方面。 测试用例构成了设计和制定测试过程的基础。测试的“深度”与测试用例的数量成比例。由于每个测试用例反映不同的场景、条件或经由产品的事件流,因而,随着测试用例数量的增加,您对产品质量和测试流程也就越有信心。判断测试是否完全的一个主要评测方法是基于需求的覆盖,而这又是以确定、实施和/或执行的测试用例的数量为依据的。类似下面这样的说明:“95 % 的关键测试用例已得以执行和验证”,远比“我们已完成95 % 的测试”更有意义。测试工作量与测试用例的数量成比例。根据全面且细化的测试用例,可以更准确地估计测试周期各连续阶段的时间安排。测试设计和开发的类型以及所需的资源主要都受控于测试用例。测试用例通常根据它们所关联关系的测试类型或测试需求来分类,而且将随类型和需求进行相应地改变。最佳方案是为每个测试需求至少编制两个测试用例:·一个测试用例用于证明该需求已经满足,通常称作正面测试用例;·另一个测试用例反映某个无法接受、反常或意外的条件或数据,用于论证只有在所需条件下才能够满足该需求,这个测试用例称作负面测试用例。 前段时间公司进行有关测试的培训,集成测试,性能测试,压力测试说了很多。由于本人还处于Coder阶段,只是对单元测试有了些了解。写下来怕以后自己忘记了。都是些自己的看法,不一定准确,欢迎高手指教。 一、单元测试的概念 单元通俗的说就是指一个实现简单功能的函数。单元测试就是只用一组特定的输入(测试用

软件测试案例分析完整版

软件测试案例分析 HEN system office room 【HEN16H-HENS2AHENS8Q8-HENH1688】

对软件测试理解 软件测试作为软件质量保证的一种重要方法,近些年来, 软件测试越来越受到产业界、教育界和学术界的重视。软件测试,描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。换句话说,软件测试是一种实际输出与预期输出间的审核或者比较过程。软件测试的经典定义是:在规定的条件下对程序进行操作,以发现程序错误,衡量软件质量,并对其是否能满足设计要求进行评估的过程。 1软件测试的方法 黑盒测试 在黑盒测试(或称功能测试)中,不考虑程序的内部结构和表现,其目的是确定程序的输入与输出是否与其规格一致,力图发现以下几类错误: 是否有不正确或遗漏了的功能?在接口上,输入能否正确地接受?能否正确地输出结果? 是否有数据结构错误或外部信息(例如数据文件)访问错误?性能上是否能满足要求? 是否有初始化或终止性错误? 黑盒测试的主要缺点是依赖于规格的正确性(实际情况并非如此)和需要采用所有可能的输入作为测试用例才能保证模块的正确性。 白盒测试 在该方法对软件的过程性细节做细致检查,对程序所有逻辑进行测试。通过在不同点检查程序的状态,确定实际的状态是否与预期的状态一致。测试用例从程序的逻辑中产生。确定程序逻辑覆盖有几条原则,其中之一是语句覆盖,要求程序中的每条语句至少执行一次。这条原则是必要的,但不充分,因为部分错误并不能检测出来。 从上至下测试 从上至下测试从程序的顶点模块开始,然后逐步对较低级的模块进行测试。为了模仿被测试模块的低级模块,需要哑模块或桩子模块。从上至下测试的主要好处就是排除了系统测试和集成,它可以让人们看见系统的早期版本并证明系统的正确性。它的效果之一可以提高程序员的士气。从上至下测试的主要缺点是需要桩子模块,并

通用测试用例模板

通用软件测试用例模板

用例说明 一、用例编号:每个用例唯一的标识 二、用例类型:用例的优先级(根据BUG的等级划分、用户使用的主次功能划分、根据流程划分如基本流或备选流)。 三、用例名称:填写用例的名称,如删除对象,添加内容,进行查询等。 四、模块名称:该用例属于哪个主要模块 五、测试环境: 硬件环境: 列出为测试本软件所使用硬件的配置,如: a.处理机的型号、内存容量; b.所要求的外存储器、媒体、记录格式、设备的型号和台数、联机/脱机; c.I/O设备(联机/脱机?); d.数据传输设备和转换设备的型号、台数。 软件环境: 说明为测试本软件所使用的软件,如: a.操作系统的名称、版本号; b.开发工具名称和版本号; c.数据库管理系统的名称和版本号; d.使用什么测试软件 e.其他支持软件。 六、测试目标:明确测试后所要实现的基本功能及结果,简要强调下面所有子功能可实现的功能和方法,使测试人员了解测试的意图。写出预期要达到的最好状态。 七、用户需求:写出测试模块所要达到的基本用户需要或者用户所需要的完整功能描述 八、前置条件: 描述该操作的前提条件。如:前面删除的对象有(废弃的对象、被引用对象、处在流程中的对象等)各种情况,该处可以描述其中一种。。 九、后置条件: 描述该操作的先关后续链接 十、特殊说明:用户或者开发者有特殊需求或注意事项,需添加在此项。 十一、用例的测试过程 1步骤:用例中需要测试进行的步骤,如1。 2测试内容:测试内容, 3测试预期结果:未测试前合理的正确的结果。 4操作描述:如:点击“高级查询”进入高级查询的页面,键入“姓名”。 5测试输入数据:如果此处输入姓名或其中几个字如“欧阳菲菲”或“欧阳”,均可记录。 6测试结果:记录输出的结果。正确或者错误均记录。对于一个测试完整功能点都会有一个对应的期望的正确结果。该结果可能是一个输出的数据值,也可能是一个 显示效果结果 7测试完成后功能描述 测试无误后对该子项功能模块的整体详细描述。

软件测试之测试用例设计

软件测试之测试用例设计 软件和其他工程产品的测试设计与产品本身的设计一样具有挑战性,然而由于已经讨论过的一些原因,软件工程师经常将测试作为一种事后的措施,开发一些“感觉上正确”但是缺乏完整保证的测试用例。再回头看看测试目标,我们必须设计出最可能发现最多数量的错误、并耗费最少时间和最小代价的测试。 在过去的20年,出现了大量的测试用例设计方法,为开发人员进行测试提供了系统的方法。更重要的是,方法提供了一种有助于确保完全测试的机制,并提供了揭示软件错误的最高可能性。 能够采用以下两种方法之一对任何工程化产品(以及大多数其他东西)进行测试: (1)若了解产品的特定功能,则构造测试,以证实各功能完全可执行,同时在各功能中寻找错误; (2)若了解产品的内部构造,则构造测试,以确保“所有齿轮吻合”,即内部操作依据规约执行,而且所有的内部构件被充分利用。第一种测试方法被称为黑盒测试,第二种则被称为白盒测试。 如果考虑计算机软件,黑盒测试指在软件界面上进行的测试,虽然设计黑盒测试是为了发现错误,它们却被用来证实软件功能的可操作性;证实能很好地接收输入,并正确地产生输出;以及证实对外部信息完整性(例如:数据文件)的保持。黑盒测试检验系统的一些基本特征,很少涉及软件的内部逻辑结构。 软件的白盒测试依赖对程序细节的严密检验,提供运用特定条件和/与循环集的测试用例,对软件的逻辑路径进行测试,在不同的点检验“程序的状态”以判定预期状态或待验证状态与真实状态是否相符。

一眼看去,可能认为全面的白盒测试将产生“百分之百正确的程序”,需要我们做的只是定义所有的逻辑路径、开发相应的测试用例,并评估结果,简而言之,详尽地生成用例以测试程序逻辑。不幸的是,穷举测试带来了必然的计算问题,即使是很小的程序,可能的逻辑路径数量也非常大,例如,考虑 100行C语言程序,在一些基本的数据声明之后,程序包含两个嵌套循环,根据输入的条件分别执行1到20次,在内部循环中,需要四个if-then-else结构,该程序中大约有1014条可能路径! 为了正确表达这个数值,我们假设开发了一个有魔力的测试处理器(“有魔力”是因为不存在这样的处理器)进行穷举测试。该处理器能在一毫秒内开发一个测试用例、进行运行并评估结果,如果每天运行24小时,每年运行365天,则需要3170年的时间来测试这个程序。不可否认,这将导致大多数开发进度表的混乱,对大型软件系统不可能进行穷举测试。 然而,白盒测试不应该被抛弃,可选择有限数量的重要逻辑路径进行测试,检测重要数据结构的有效性,可以综合黑盒测试和白盒测试的属性提供一种方法,以验证软件界面,并有选择地保证软件内部工作的正确性。

相关文档
最新文档