功能测试用例实战详细案例

功能测试用例实战详细案例
功能测试用例实战详细案例

***测试用例

一、功能测试(web端)

此功能测试用例对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确,以及业务规则的实施是否恰当。主要测试技术方法为用户通过GUI(图形用户界面)与应用程序交互,对交互的输出或接受进行分析,以此来核实需求功能与实现功能是否一致。

二、功能测试(app端)

1)昵称长度应在3-18个字节之间或最长7个汉字,

不能为纯数字,

昵称中不能有空格,

是唯一的;

如果输入错误,输入行右

边出现,并且在上

方显示提示文字“昵称输

入错误”,如果是正确的,

就把×改成√,并且背景

色由红色换成绿色;

2)密码长度在6-20位之间(仅支持数字、字母、数

字字母混合等),

密码中不能有空格;

如果输入错误,输入行右

边出现,并且在上

方显示提示文字“密码输

入错误”,如果是正确的,

就把×改成√,并且背景

色由红色换成绿色;

3)跳转到“个人中心”;

机1)输入要找回密码的正确

账号;

如果格式错误,输入行右

边出现,如果是正

确的,就把×改成√,并

且背景色由红色换成绿

色;

间隔60秒;

3)输入正确的验证码;

如果输入错误,输入行右

边出现,如果是正

确的,就把×改成√,并

且背景色由红色换成绿

色;

4)密码长度在6-20位之间

(仅支持数字、字母、数

字字母混合等),

密码中不能有空格;

如果密码格式错误,输入

行右边出现,如果

是正确的,就把×改成

√,并且背景色由红色换

成绿色;;

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

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(图形用户界面)与应用程序交互,对交互的输出或接受进行分析,以此来核实需求功能与实现功能是否一致。

测试用例实例—常见功能测试点

测试用例实例--常见功能测试点 笔者在网上看到了一篇文章,个人认为此文对于“软件常用功能测试点”总结的很好,特此摘录下来和大家一起分享。 1. 登陆、添加、删除、查询模块是我们经常遇到的,这些模块的测试点该如何考虑 1)登陆 ①用户名和密码都符合要求(格式上的要求) ②用户名和密码都不符合要求(格式上的要求) ③用户名符合要求,密码不符合要求(格式上的要求) ④密码符合要求,用户名不符合要求(格式上的要求) ⑤用户名或密码为空 ⑥数据库中不存在的用户名,不存在的密码 ⑦数据库中存在的用户名,错误的密码 ⑧数据库中不存在的用户名,存在的密码 ⑨输入的数据前存在空格 ⑩输入正确的用户名密码以后按[enter]是否能登陆 ------------------------------------------------------------------------------------------------------ 2) 添加 ①要添加的数据项均合理,检查数据库中是否添加了相应的数据 ②留出一个必填数据为空

③按照边界值等价类设计测试用例的原则设计其他输入项的测试用例 ④不符合要求的地方要有错误提示 ⑤是否支持table键 ⑥按enter是否能保存 ⑦若提示不能保存,也要察看数据库里是否多了一条数据 ------------------------------------------------------------------------------------------------------ 3) 删除 ①删除一个数据库中存在的数据,然后查看数据库中是否删除 ②删除一个数据库中并不存在的数据,看是否有错误提示,并且数据库中没有数据被删除 ③输入一个格式错误的数据,看是否有错误提示,并且数据库中没有数据被删除。 ④输入的正确数据前加空格,看是否能正确删除数据 ⑤什么也不输入 ⑥是否支持table键 ⑦是否支持enter键 ------------------------------------------------------------------------------------------------------ 4)查询 精确查询:

白盒与黑盒测试的测试用例设计(20210110002601)

第 5 章白盒与黑盒测试的测试用例设计 5.1 覆盖率的概念 覆盖率是用来度量测试完整性的一个手段逻辑覆盖和功能覆盖 覆盖率=(至少被执行一次的item 数)/item 总数 5.2 白盒测试的测试用例设计 5.2.1 逻辑覆盖逻辑覆盖是以程序内部的逻辑结构为基础的测试用例设计技术,属白盒测试。为了衡量测试的覆盖程度,需要建立一些作为测试彻底度的定量衡量标准。目前常用的覆盖标准是:语句覆盖;判定覆盖;条件覆盖;判定/ 条件覆盖;条件组合覆盖;路径覆盖 一、语句覆盖语句覆盖就是设计若干个测试用例,运行所测的程序,使得每一可执行语句至少执行一次。 二、判定覆盖判定覆盖就是设计若干个测试用例,使程序中的每个判断至少出现一次“真值”和一次“假值”,即程序中的每个分支都至少执行一次。 三、条件覆盖条件覆盖是指利用若干个测试用例,使被测试的程序中,对应每个判断中每个条件的所有可能情况均至少执行一次。 四、判定/ 条件覆盖 判定/ 条件覆盖就是设计足够多的测试用例,使得程序中每个判断条件的所有可能的结果至少取到一次,又使每次判断的每个分支至少通过一次。 五、条件组合覆盖 解决上述问题的新标准是条件组合覆盖。条件组合覆盖就是设计足够多的测试用例,使得每个判断的所有可能的条件取值组合至少执行一次。 六、逻辑覆盖举例 [例1]试用逻辑覆盖测试法为采用冒泡排序(bubble sorting )法进行数据排序的C 程序设

计测试用例。 本例是一个对k 个整数进行升序排序的C 程序,采用的算法是冒泡排序。基 本步骤是: (1)从数组中取出第2 个元素; (2)如果新取出的元素大于等于其前邻元素,则转向第(4)步; (3)如果新取出的元素小于其前邻元素,则与其前邻元素交换位置; (4)将新元素与新的前邻元素比较,若仍小于新的前邻元素,则重复第(3)步; (5)取下一个元素。如果数组中元素已取完则结束排序,否则转向第(2)步。 下面将给出本例的C程序。图2则是排序部分的流程图。 main() { int a[11],i,j,k,temp; scanf(“%d”,k); printf(“input numbers: n”); for(i=1;i<=k;i++) scanf(“ %d”,&a[i]);

白盒测试用例设计方法

1白盒测试用例设计方法 1.1白盒测试简介 白盒测试又称结构测试、逻辑驱动测试或基于程序的测试,一般多发生在单元测试阶段。白盒测试方法主要包括逻辑覆盖法,基本路径法,程序插装等。 这里重点介绍一下常用的基本路径法,对于逻辑覆盖简单介绍一下覆盖准则。 1.2基本路径法 在程序控制流图的基础上,通过分析控制构造的环路复杂性,导出独立路径集合,从而设计测试用例,设计出的测试用例要保证在测试中程序的每一个可执行语句至少执行一次。 在介绍基本路径测试方法(又称独立路径测试)之前,先介绍流图符号: 图1 如图1所示,每一个圆,称为流图的节点,代表一个或多个语句,流程图中的处理方框序列和菱形决策框可映射为一个节点,流图中的箭头,称为边或连接,代表控制流,类似于流程图中的箭头。一条边必须终止于一个节点,即使该节点并不代表任何语句,例如,图2中两个处理方框交汇处是一个节点,边和节点限定的范围称为区域。 图2

任何过程设计表示法都可被翻译成流图,下面显示了一段流程图以及相应的流图。 注意,程序设计中遇到复合条件时(逻辑or, and, nor 等),生成的流图变得更为复杂,如(c)流图所示。此时必须为语句IF a OR b 中的每一个a 和b 创建一个独立的节点。

(c)流图 独立路径是指程序中至少引进一个新的处理语句集合,采用流图的术语,即独立路径必须至少包含一条在定义路径之前不曾用到的边。例如图(b)中所示流图的一个独立路径集合为: 路径1:1-11 路径2:1-2-3-4-5-10-1-11 路径3:1-2-3-6-8-9-10-1-11 路径4:1-2-3-6-7-9-10-1-11 上面定义的路径1,2,3 和4 包含了(b)流图的一个基本集,如果能将测试设计为强迫运行这些路径,那么程序中的每一条语句将至少被执行一次,每一个条件执行时都将分别取true 和false(分支覆盖)。应该注意到基本集并不唯一,实际上,给定的过程设计可派生出任意数量的不同基本集。如何才能知道需要寻找多少条路径呢?可以通过如下三种方法之一来计算独立路径的上界: 1. V=E-N+2,E 是流图中边的数量,N 是流图节点数量。 2. V=P+1,P 是流图中判定节点的数量 3. V=R,R 是流图中区域的数量 例如,(b)流图可以采用上述任意一种算法来计算独立路径的数量 1. V=11 条边-9 个节点+2=4 2. V=3 个判定节点+1=4 3. 流图有4 个区域,所以V=4 由此为了覆盖所有程序语句,必须设计至少4 个测试用例使程序运行于这4 条路径。 在采用基本路径测试方法中,获取测试用例可参考以下方式:

最新软件测试用例实例(非常详细)

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

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

测试用例实例

测试用例实例 令狐采学 1、一个好的用例的表述要点,即用例中应当包含的信息 一个优秀的测试用例,应该包含以下信息: 1)软件或项目的名称 2)软件或项目的版本(内部版本号) 3)功能模块名 4)测试用例的简单描述,即该用例执行的目的或方法 5)测试用例的参考信息(便于跟踪和参考) 6)本测试用例与其他测试用例间的依赖关系 7)本用例的前置条件,即执行本用例必须要满足的条件,如对数据库的访问权限 8)用例的编号(ID),如可以是软件名称简写-功能块简写-NO.。9)步骤号、操作步骤描述、测试数据描述 10) 预期结果(这是最重要的)和实际结果(如果有BUG管理工具,这条可以省略) 11)开发人员(必须有)和测试人员(可有可无) 12)测试执行日期 2、实例 该测试案例是以一个B/S结构的登录功能点位被测对象,该测试用例为黑盒测试用例。假设用户使用的浏览器为IE6.0 SP4。 功能描述如下:

1.用户在地址栏输入相应地址,要求显示登录界面; 2.输入用户名和密码,登录,系统自动校验,并给出相应提示信息; 3.如果用户名或者密码任一信息未输入,登录后系统给出相应提示信息; 4.连续3次未通过验证时,自动关闭IE。 表4-1登录界面测试用例

自动取款机取款用例规约和测试用例 取款用例说明: 此用例完成用户利用自动取款机取款的全部流程,分为以下流程:插卡,输入密码,选择金额,取款,取卡等操作。 事件流: 该用例在用户插卡之后启动 1. 系统提示用户插卡; 2. 提示客户输入密码信息; 3. 密码输入完毕后,客户选择“确认”,向系统提交信息; 4. 系统验证客户输入的密码信息,确认正确后,进入选择系统主界面; 5. 用户选择取款选项; 6. 系统进入取款金额界面并提示用户输入金额; 7. 系统验证可以取款并输出钱款; 8. 系统提示用户取卡,操作完成。 基本流: 用户取款。

测试用例范例

讨论用TestDirector管理测试用例 编制时间:2007-03-16 编制部门:测试组 编制人:郭宏元 “测试用例”虽有国标作蓝本,但实际中,一直以来“测试用例”是所有测试人员有争议的地方,此所谓“仁者见仁,智者见智”。而“法无定法,则无定则”,所有的规范与标准都是围绕更适应人们的工作环境而创建。在此,我就我的一些体会在此与大家分享。 一般来说,“测试用例”的编写主要分三大类,贯彻的原则与基本架构如下: 分类: 1、对验证过程的一个记录; 2、展现一个功能; 3、描述一个场景步骤; 原则: 1、有“对象”属性的描述; 2、阐述了某个“对象”的方法或事件。 3、对属性、方法或事件有详细的定义。 基本架构: 1、目的; 2、前提条件; 3、输入步骤(输入动作或数据,预期结果) 以下总结了一些针对测试用例的“编写要点”作出一些较简单的规范。以方便统一测试用例的编写,并保证使用最用效的测试用例来保证测试质量。我们都知道根据详细设计文档编写测试用例的目的不在于验证软件达到的功能,而在于验证软件应该达到的功能,这样可以去除软件开发过程中的随意性。所以下面就明确测试用例的“目的”、“范围”、“原则”是什么?以及采用的方法做了一点描述。 1、目的: 围绕测试名称或满足实现测试功能而进行。 2、范围:

适用于所要测试的质检项目。 3、功能测试用例编写原则 3.1单元测试功能用例的编写目的 单元测试用例的目的在于验证单个模块是否达到了详细设计说明书中规定的功能,由于是单个模块所以无法检验关联性,可能会牵扯到数据库的操作,例如:删除时,需要查看数据库是否完全删除了数据。 3.2集成测试功能用例的编写目的 集成测试功能用例的目的在于验证软件连接时,模块的连接是否正确(及数据的传递是否正确)。.我们的软件中体现出来的是,是否正确调用界面,界面之间显示的数据是否正确,特别是财务、费用、数据方面的。 集成测试用例的编写过程中,经常将功能用例与业务流程混合编写,因为在集成测试时需验证业务流程中的数据正确性,以及界面之间的数据传递的准确无误。 3.3系统测试业务流程用例的编写目的 系统测试业务流程用例的目的在于验证软件最终数据的准确性,我们的软件体现为,手工数据与报表数据的一直性。用例与用例之间有着一定的关系,目的性十分明确。 4、测试用例设计的原则 4.1全面性 指编写的测试用例应该覆盖所有的“概要设计文档”或“需求文档”以及“测试申请文档”中描述的功能。 4.1.1数据库程序基本的增、删、改功能 增、改测试用例重点在于数据合法性、正确性的检验和提示信息的正确性的检验。输入的数据可能有无限种组合,此时可以采用等价类划分和边界值法,下面有较详细的说明。 删除的测试用例比较简单,只有操作没有数据的输入,但是应该在“备注”中注明,删除的限制条件,以及数据库中应该删除的表的情况,有条件限制时,测试用例应该包含各种删除条件,必要时在添加或修改的测试用例后面或中间紧跟删除的测试用例。 4.1.2对于无输入的操作,应该详细描述其具体的操作步骤和结果

软件测试经典案例

软件测试-测试用例的经典例子 一、等价类划分 问:某程序规定:"输入三个整数 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)软件或项目的名称 2)软件或项目的版本(内部版本号) 3)功能模块名 4)测试用例的简单描述,即该用例执行的目的或方法 5)测试用例的参考信息(便于跟踪和参考) 6)本测试用例与其他测试用例间的依赖关系 7)本用例的前置条件,即执行本用例必须要满足的条件,如对数据库的访问权限 8)用例的编号(ID),如可以是软件名称简写-功能块简写-NO.。 9)步骤号、操作步骤描述、测试数据描述 10) 预期结果(这是最重要的)和实际结果(如果有BUG管理工具,这条可以省略)11)开发人员(必须有)和测试人员(可有可无) 12)测试执行日期 2、实例 该测试案例是以一个B/S结构的登录功能点位被测对象,该测试用例为黑盒测试用例。假设用户使用的浏览器为IE6.0 SP4。 功能描述如下: 1.用户在地址栏输入相应地址,要求显示登录界面; 2.输入用户名和密码,登录,系统自动校验,并给出相应提示信息; 3.如果用户名或者密码任一信息未输入,登录后系统给出相应提示信息; 4.连续3次未通过验证时,自动关闭IE。 表4-1登录界面测试用例

自动取款机取款用例规约和测试用例 取款用例说明: 此用例完成用户利用自动取款机取款的全部流程,分为以下流程:插卡,输入密码,选择金额,取款,取卡等操作。 事件流: 该用例在用户插卡之后启动 1. 系统提示用户插卡; 2. 提示客户输入密码信息; 3. 密码输入完毕后,客户选择“确认”,向系统提交信息; 4. 系统验证客户输入的密码信息,确认正确后,进入选择系统主界面; 5. 用户选择取款选项; 6. 系统进入取款金额界面并提示用户输入金额; 7. 系统验证可以取款并输出钱款; 8. 系统提示用户取卡,操作完成。 基本流: 用户取款。 备选流: 1.用户密码错误 2.取款金额不符合要求。 前置条件: 用户必须插入正确的银行卡才能开始执行用例。

测试用例实例

测试用例实例 Corporation standardization office #QS8QHH-HHGX8Q8-GNHHJ8

测试用例实例 1、一个好的用例的表述要点,即用例中应当包含的信息 一个优秀的用例,应该包含以下信息: 1)软件或项目的名称 2)软件或项目的版本(内部版本号) 3)功能模块名 4)测试用例的简单描述,即该用例执行的目的或方法 5)测试用例的参考信息(便于跟踪和参考) 6)本测试用例与测试用例间的依赖关系 7)本用例的前置条件,即执行本用例必须要满足的条件,如对的访问权限 8)用例的编号(ID),如可以是软件名称简写-功能块简写-NO.。 9)步骤号、操作步骤描述、测试数据描述 10) 预期结果(这是最重要的)和实际结果(如果有BUG管理工具,这条可以省略)11)开发人员(必须有)和测试人员(可有可无) 12)测试执行日期 2、 该测试案例是以一个B/S结构的登录功能点位被测对象,该测试用例为黑盒测试用例。假设用户使用的浏览器为IE6.0 SP4。 功能描述如下: 1.用户在地址栏输入相应地址,要求显示登录界面; 2.输入用户名和密码,登录,系统自动校验,并给出相应提示信息; 3.如果用户名或者密码任一信息未输入,登录后系统给出相应提示信息; 4.连续3次未通过验证时,自动关闭IE。

取款用例说明: 此用例完成用户利用自动取款机取款的全部流程,分为以下流程:插卡,输入密码,选择金额,取款,取卡等操作。 事件流: 该用例在用户插卡之后启动 1. 系统提示用户插卡; 2. 提示客户输入密码信息; 3. 密码输入完毕后,客户选择“确认”,向系统提交信息;

测试用例的设计步骤

系统测试之功能测试:测试用例的设计步骤 ——从登陆开始说起 一个完整的software testing life cycle包括诸多内容,本文仅从测试用例的编写开始,聊聊测试用例编写的一般步骤,以使编写的测试用例最大程度上满足完备的要求,而又不产生重复而冗余的负担。 测试用例的来源是产品需求,如果足够幸运,我们应当有一份不错的可依赖的Use Case文档,但大部分情况下,Use Case恐怕是不存在,能有一份不错的PRD文档和原型设计图已经是不错的待遇了,如果可能的话,最好还能够有HLD文档,这些已经足够我们开始写详细的测试用例文档(我相信在这之前无法产出详细的测试用例文档①)。也许LLD文档产生之后或者产品的第一个版本发布之后,我们会不断的更新已有的测试用例,但那将是不断的迭代过程,暂不做讨论。 首先让我们先从理论上了解测试用例编写的一般步骤②: 1、确定测试套件(Test Suite):测试套件是功能上的划分,是相似测试场景的组合,而非技术划分。如果技术设计中各模块耦合度较高(强烈推荐解耦,哪怕复制粘贴代码),可能功能上不相干的模块由于代码重用的原因会在bug fix时互相引致错误,实际上回归测试即是为了避免这种情况。但是我们在做功能测试划分模块时,还是要从用户的角度出发,按照用户场景划分测试的“模块”。值得庆幸的是,相似或相关的功能总是倾向于在同一组页面出现,按钮和输入框、选择菜单等内容并不是随机组合的一堆零件。 2、针对每一个测试套件,确定一个或多个基本流程(basic flow)和可选流程(alternative flow),即测试场景(Test Scenario):可以借助scenario matrix来清晰地对可能出现的场景进行排列组合。值得注意的是,一方面Use Case或PRD文档中的描述很有可能并没有完整的写尽所有的场景,测试人员尽可能地挖掘测试场景,既有可能是出于测试本身的需要,也可能是基于开发团队的工作;另一方面,在复杂系统中,测试场景不可能覆盖所有可能的场景,这便需要测试人员采用一定的测试策略③,对SUT (System under Testing)进行“足够(adequate)”的测试,而不是完全的测试。 3、针对每一个测试场景,确定一到多个测试用例(Test Case):仍然可以借助matrix来清晰地规划测试用例,每一个测试用例都有其对应的预置条件④、输入和期望结果。测试用例分为Positive Test Ca se和Negative Test Case两种,分别用来测试产品是否完成应当完成的工作和不执行不应当完成的操作。更详尽地说,测试用例一般包括以下列column:用例编号/测试场景/用例描述/需求对应/用例分类(Positi ve/Negative)/用例类型/用例级别/是否自动化/预置条件/测试步骤/测试数据/预期结果/实际结果/备注/ 4、增加测试数据(Test Data)完成测试用例:测试数据是测试用例中很重要的内容,一个用例可能对应多套测试数据,测试工程师根据某种测试技术⑤,将尽可能的设计较少的测试数据完成“足够”的测试。 任何规范、流程都是为了让工作更加可靠,对于项目工程,天外飞仙灵机一动应当放在合适的位置,而不应当成为规范和流程的反例存在⑥。 现在让我们开始从登陆(PC端网页,如果是PC客户端比如QQ或手机客户端则又不同)开始说起。 不打开任何网站的登陆框,想象一下登陆框的样子。 然后对照一下本文最后的附图,一个优秀的登陆框除了基本的用户名/密码输入框、登陆按钮之外、(不考虑注册、找回密码、第三方登陆、登陆版本、帮助),包含的内容有:输入框文字提示/免登陆选项/输入

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

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

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/0d14135951.html, 开发人员模块 名称 WorkEvaluate 用例参考工作考核系统界面设计

系统测试用例设计方法

系统测试用例设计方法 --------------王永安

目录 一、测试用例格式以及写作要点 (3) 二、系统测试用例设计方法 (4) 1、等价类划分法 (5) 2、边界值分析法 (6) 3、判定表法 (7) 4、因果图法 (9) 5、状态迁移图法 (15) 6、流程分析法 (20) 7、正交试验法 (34) 8、错误推测法 (41)

一、测试用例格式以及写作要点 测试用例编号 测试用例编号是由字母和数字组合而成的,用例的编号应该具有唯一性,易识别性。比如可以采用统一的约定,产品编号—ST—系统测试项名—系统测试子项名—编号。这样看到编号就可以知道是做的什么测试,测试的对象是什么。也方便维护。 测试项目 你现在这个测试用例所测的项目名,可以是测试用例所属的大类,被测需求,被测的模块,或者是被测的单元。例如:计算器加法功能。 测试标题 测试标题是对测试用例的简单描述。用概括的语言描述该测试用例的测试点。每个测试用例的标题不能够重复,因为每个测试用例的测试点是不一样的。例如:手机在没有SIM 卡的情况下,拨打119。 重要级别 重要级别分为高中底三等: 高:保证系统基本功能、重要特性、实际使用频率比较高的用例; 中:重要程度介于高和底之间的测试用例; 底:实际使用频率不高、对系统业务功能影响不大的模块或功能的测试用例。 注:一般情况下,重要级别为高的测试用例,一个测试子项里有且尽有一个,大多数都是重要级别为中的测试用例。因为一般我们会进行一个系统测试预测试,如果重要级别为高的太多,则就失去了预测试的实际意义。 预置条件 就是执行当前测试用例的前提条件,如果不满足这些条件,则无法进行测试。 输入 测试用例执行时,需要输入的外部信息。例如某一个文件,数据记录等。 操作步骤 执行当前测试所要经过的操作步骤,需要给出每一步操作的描述,测试人员根据测试用

典型测试用例案例讲解

案例一:三角形判断功能测试 输入三条边,判断能否组成三角形,能组成三角形,继续判断能组成等腰三角形?等边三角形?还是直角三角形? 案例二:用户修改个人信息 要求:电话:11位长数字串 密码:18位以内的字符串(包含18位长) 用户登陆后可以修改个人信息,包含:电话号码、密码。 点击“修改用户信息”控件,系统显示所有用户个人信息: 其中用户名和工号不可修改,不能进行输入。密码分旧密码、新密码、验证新密码, 若需修改密码,系统验证旧密码正确,两个新密码相同,则更新密码,旧密码即失效,其他修改项也生效,并提示“用户信息修改成功”; 若旧密码不正确(旧密码是否正确),则提示“用户密码错”,系统将不修改个人信息;若两个新密码不同(两个新密码是否相同),则提示“新密码与验证新密码不同”,系统将不修改个人信息。 若只修改密码外其他信息(是否修改密码),则不需输入两个新密码,系统只验证旧密码正确,就成功更改个人信息,并提示“用户信息修改成功”;如果系统验证旧密码输入不正确,则提示“用户密码错”。

案例三:读书选择 1、如果觉得疲倦并且对书的内容感兴趣,同时书中的内容让你糊涂的话,回到本章重读 2、如果觉得疲倦并且对书的内容感兴趣,同时书中的内容不让你糊涂,继续读下去 3、如果觉得疲倦并且对书中的内容不感兴趣,同时书中的内容不让你糊涂,停止阅读,请休息 4、如果觉得疲倦并且对书的内容不感兴趣,并且书中的内容让你糊涂,请停止阅读,休息 5、不疲倦,对书的内容感兴趣,书中的内容不糊涂,继续读下去 6、不疲倦,不感兴趣,书中内容不糊涂,跳到下一章去读 7、不疲倦、不感兴趣、且糊涂跳到下一章去读 8、不疲倦、感兴趣,且糊涂回到本章重读 案例四:PPT打印功能测试 PowerPoint软件打印功能描述如下: 打印范围分:全部、当前幻灯片、给定范围共三种情况; 打印内容分:幻灯片、讲义、备注页、大纲视图共四种方式; 打印颜色/灰度分: 颜色、灰度、黑白共三种设置; 打印效果分:幻灯片加框和幻灯片不加框两种方式。 请利用如下正交表设计用例。 下面正交表共四个因子,其中每个因子三状态:

测试用例八大设计方法和实例

测试用例设计方法 1等价类划分 1.1 理论知识 等价类划分是一种典型的黑盒测试方法。这一方法完全不考虑程序的内部结构,只依据程序的规格说明来设计测试用例。 等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭示程序中的错误都是等效的。 等价类合理地假设:某个等价类的代表值,与该等价类的其他值,对于测试来说是等价的。 因此,可以把全部的输入数据划分成若干的等价类,在每一个等价类中取一个数据来进行测试。这样就能以较少的具有代表性的数据进行测试,而取得较好的测试效果。 等价类划分是把所有可能的输入数据,即程序的输入域划分成若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计方法. 1) 分类: 划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类. 有效等价类:是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能. 无效等价类:与有效等价类的定义恰巧相反. 设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性. 2)划分等价类的方法: 下面给出六条确定等价类的原则: ①在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类. ②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效

测试用例设计技术之----因果图

测试用例设计技术之----因果图 上次讲了因果图法的基本原理,这种方法是有因必有果,正是由于多个原因的不同组合,使得结果也不尽相同。由于组合情况很多,才用因果图法能大大简化测试用例的数量。 我们来看一个例子: 有一个饮料自动售货机(处理单价为5角钱)的控制处理软件,它的软件规格说明如下: 若投入5角钱的硬币,按下“橙汁”或“啤酒”的按钮,则相应的饮料就送出来。若投入1元钱的硬币,同样也是按“橙汁”或“啤酒”的按钮,则自动售货机在送出相应饮料的同时退回5角钱的硬币。 怎么分析这种具有一定实际意义的情况呢? 按照因果图的说法,我们先分析一下,把原因与结果先找出来: 原因是输入条件,在自动售货机里,硬币的投入、按钮的按下,都是输入,这样的话就有以下几个原因: (1)投入5角硬币 (2)投入1元硬币 (3)按下“橙汁”按钮 (4)按下“啤酒”按钮 结果有哪些呢? (1)送出“橙汁”饮料 (2)送出“啤酒”饮料 (3)找5角硬币 按照因果关系,把因果图的雏形画出来: 再加上因果图的约束关系,那么图形就成为以下:

根据最终的因果图生成判定表: 最后把测试用例写出来: 用例编号用例说明输入数据预期结果SHJ-001 (1)投入硬币 (2)按下按钮1元 点击“橙汁”按钮退还5角硬币 送出“橙汁”饮料 SHJ-002 (1)投入硬币 (2)按下按钮1元 点击“啤酒”按钮退还5角硬币 送出“啤酒”饮料 SHJ-003 (1)投入硬币1元给出提示信息SHJ-004 (1)投入硬币

(2)按下按钮5角 点击“橙汁”按钮送出“橙汁”饮料 SHJ-005 (1)投入硬币 (2)按下按钮5角 点击“啤酒”按钮送出“啤酒”饮料 SHJ-006 (1)投入硬币5角给出提示信息 SHJ-007 (1)按下按钮“橙汁”按钮给出提示信息SHJ-008 (1)按下按钮“啤酒”按钮给出提示信息

软件测试案例分析完整版

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

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

手机APP产品测试用例实例与模版

中国电信XXX项目 功能测试用例 撰稿人:XX XXX信息网络有限责任公司 2013年X月XX日

目录 1.概述 ------------------------------------------------------------------------ 3 1.1编写目的------------------------------------------------------------------- 3 1.2读者对象------------------------------------------------------------------- 3 1.3参考资料------------------------------------------------------------------- 3 2.ANDROID测试用例------------------------------------------------------------- 4 2.1登陆/注册------------------------------------------------------------------ 4 2.2文件上传------------------------------------------------------------------- 4 2.3文件收藏------------------------------------------------------------------- 5 2.4文件删除/还原-------------------------------------------------------------- 5 2.5文件重命名----------------------------------------------------------------- 6 2.6文件移动------------------------------------------------------------------- 6 2.7文件分享------------------------------------------------------------------- 7 2.8图片浏览------------------------------------------------------------------- 8 2.9相册备份------------------------------------------------------------------- 8 2.10私密空间------------------------------------------------------------------ 9 2.11设置---------------------------------------------------------------------- 9 2.12客户端安装/升级---------------------------------------------------------- 10

白盒测试用例设计方法

1.白盒测试用例设计方法 1.1. 白盒测试概述 由于逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。由于我们经常相信某逻辑路径不可能被执行,而事实上,它可能在正常的情况下被执行。由于代码中的笔误是随机且无法杜绝的,因此我们要进行白盒测试。 白盒测试又称结构测试,透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法,盒子指的是被测试的软件,白盒指的是盒子是可视的,你清楚盒子部的东西以及里面是如何运作的。 1.白盒的测试用例需要做到 ?保证一个模块中的所有独立路径至少被使用一次; ?对所有逻辑值均需测试true 和false; ?在上下边界及可操作围运行所有循环; ?检查部数据结构以确保其有效性。 2.白盒测试的目的 通过检查软件部的逻辑结构,对软件中的逻辑路径进行覆盖测试;在程序不同地方设立检查点,检查程序的状态,以确定实际运行状态与预期状态是否一致。 3.白盒测试的特点 依据软件设计说明书进行测试、对程序部细节的严密检验、针对特定条件设计测试用例、对软件的逻辑路径进行覆盖测试。 4.白盒测试的实施步骤 1)测试计划阶段:根据需求说明书,制定测试进度。 2)测试设计阶段:依据程序设计说明书,按照一定规化的方法进行软件结构划分和设计测试用例。 3)测试执行阶段:输入测试用例,得到测试结果。 4)测试总结阶段:对比测试的结果和代码的预期结果,分析错误原因,找到并解决错误。 5.白盒测试的方法

总体上分为静态方法和动态方法两大类。 ?静态分析:是一种不通过执行程序而进行测试的技术。静态分析的关键功能是检查软件的表示和描述是否一致,没有冲突或者没有歧义。 ?动态分析:主要特点是当软件系统在模拟的或真实的环境中执行之前、之中和之后, 对软件系统行为的分析。动态分析包含了程序在受控的环 境下使用特定的期望结果进行正式的运行。它显示了一个系统在检查状 态下是正确还是不正确。在动态分析技术中,最重要的技术是路径和分支 测试。下面要介绍的六种覆盖测试方法属于动态分析方法。 6.白盒测试的优缺点 ?优点:迫使测试人员去仔细思考软件的实现;可以检测代码中的每条分支和路径;揭示隐藏在代码中的错误;对代码的测试比较彻底; 最优化 ?缺点:费用昂贵;无法检测代码中遗漏的路径和数据敏感性错误; 不验证规格的正确性。 1.2. 白盒测试基本技术 1.2.1.控制流图 1.2.1.1.定义 程序流程图是软件开发过程中进行详细设计时,表示模块部逻辑的一个常用的、也非常有效的图示法。程序流程图详细地反映了程序部控制流的处理和转移过程,它一般是进行模块编码的参考依据。在程序流程图中,通常拥有很多种图示元素,例如,“矩形框”表示一个计算处理过程,而“菱形框”表示一个判断条件等。通常测试人员为某个程序模块做白盒测试过程中,在做与路径相关的各种分析的时候,这些非常细节的信息往往是不太重要。因此,为了更清晰突出地显示出程序的控制结构,反映控制流的转移过程,一种简化了的程序流程图便出现了,就是程序的控制流图。在控制流图中一般只有两种简单的图示符号:节点和控制流。

相关文档
最新文档