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

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

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

报表的测试主要分为以下几个方面:界面,安全性,准确性,展示速度(性能)

数据统计方面

1、报表统计数据的正确性;

2、报表统计数据的完整性;

3、报表统计数据的合法性;比如,统计金额字段需求要求有“$”等;

报表格式

1、表头字段表示的正确性;

2、表头字段表示的完整性;

3、表头字段表示的字体,字号,美观程度;

4、各统计字段的显示是否满足需求;比如:数据过长时要求折行还是缩小;

5、页眉和页角的表示;

报表的预览和印刷

1、预览中的显示完整性;

2、多页情况下,第2页的表头显示;

3、能否实现需求要求的特定印刷情况;(比如,印刷使用指定的模板)

4、预览后印刷;

5、不预览,直接印刷

6、需求规定各类打印机的测试;

数据准确性测试,带有报表测试的系统分为两类,一类是业务系统中,带有统计分析功能模块,该模块中包含分析报表,这个系统的主体是业务系统,报表是为**业务的而提供帮助的。

比如说,应年检统计报表,某月应交罚款车辆统计报表,这样的报表数据准确与否,可通过增加、删减、修改相关业务或相关业务的参数,查看统计报表数据变化,检查数据准确性。

另一类是系统只有统计功能,就是我说的数据仓库展现这类,它与业务系统分离,并且经过多层处理,比如数据仓库的数据,经过抽取,清洗,展现前会经过数据挖掘,数据再处理,有些字段在原始数据表中根本就没有。这样的数据准确性测试比较复杂,当然检查出数据错误,修改定位也是很不容易的。

从整个项目节约成本看,逐层测试效果是最好的。完全修改率也是最高的。

首先建立测试数据模型,模拟所有应用表,建立简单易跟踪的数据用例,底层的数据表测试,方法很原始,嘿嘿,通过SQL语句和手工计算,对数据进行比对。对系统中的报表数据准确性测试方法较为灵活,

①系统中报表重叠的进行比对

②对子报表汇总与父报表比对,就是对月报表汇总与年报表比对,日报表汇总与月报表比对,这只是一个方面,可以从维度关系考虑,地域,行政级别、时间,个人等方面下手,进行汇总比对

③这个方法如果延伸点呢,可以将报表间的业务逻辑关系作为比对依据。呵呵,这要看测试人员的需求了解深度个人能力了。插几句不想干的话,做测试工作总让我保持快乐状态,前两天我的一个同事说,公司里一直没有人喜欢做测试工作,这个工作太枯燥。嘿嘿,我当时就说我做了这么多年的测试工作从来没有感觉到枯燥。重复性工作不代表枯燥,编程其实不也是重复嘛,人每天谁不重复昨天的事啊,吃饭,吃这个动作重复一生,有谁觉得麻烦枯燥啦?

④使用SQL和手工计算进行比对。以上是差错方式,接下来讲一下查什么错?哪些地方容易出错

● 原始表使用错误:因为表比较多,又加上没有统一的数据关系对应表,很容易表使用错误,当然这应该是单元测试检查出来的错误。

● 数据处理逻辑错误:这一点容易因为测试人员和开发人员对需求理解有偏差造成争执,所以在需求评审时,对数据处理规则用表达式或伪代码表示清楚。还有就是程序员失误,逻辑编写有偏差,边界值、特殊情况处理不当。

● 数据权限:不同用户对数据有着不同的查看权限。这关系到数据的安全性。

● 数据误差:数据的保留位数,数据是否是处理计算是否是最后一次计算使用了位数保留和四舍五入。

● 由于字典表,数据错误,而造成的数据错误,如,根据性别统计,购买量,表中的男女颠倒,或者没有考虑性别缺失项,用了if else,这样就是把表中缺失该项内容的算成了

else条件里。或者逻辑中应该考虑用户状态,数据状态类似的字段,容易被忽略,测试应该考虑到。

● 最后一项,当数据量相当大的时候,统计应该考虑,切割速度,也就是数据的完整性,由于数据切割的滞后,带来的数据不完整,而造成统计结果不完整。如统计昨天的销售情况,而昨天的数据并没有完全从业务系统数据到数据池,再者月底数据,由于最后一天的数据切割不完整而造成的正月统计数量不准确。

报表的界面和输入输出测试

界面分为输入界面和输出界面;统一的界面要求:美观、统一、易操作。

输入界面要求是:

①输入项字段长度不允许超过字段长度;

②输入不符合字段要求的,不允许查询。如money类型,在输入汉字,字母、特殊字符等不允许查询,并有友好的操作提示。

③用户权限范围外的输入,不允许查询。如用户输入不是其权限范围内的客户号,不允许查询,并有友好的操作提示。

对于选项,应不出现可选择的用户权限以外的选项。

对于汉字模糊查询,考虑不常见字,如“?”即汉字因译码问题,造成的汉字存储出现乱码问题。

输出界面要求:

①因为是报表所以应该有打印、打印预览、报表导出等功能。不能因为报表导出丢失数据,不能因为打印缺少了报表表格框

②报表排列方式可调,用户可按任意列升序或降序排列,或者,按某一关键列的一定规则排序

③报表标题明确,不能含糊误导用户

④报表内可关联查询的项,应能特殊显示,如鼠标有箭头变为手掌,子报表格式与父报表格式统一,数据统一。

报表测试根据项目的定义有大有小,有时只是作为软件的一个部分进行测试,有时整个项目都是测试各种报表.但不论如何,报表的作用始终都是将系统中已经存在的数据根据用户的设置计算加工/整理汇总/最终以清晰的格式展示给用户,以便用户进一步做数据分析或统计.

软件中的报表实现一般分为定义报表的所需数据(一般可以通过选择或手工输入条件来缩小数据范围)和定义报表格式两个部分.报表格式除了如国家各行业标准中规定的报表使

用固定格式外,大多是根据企业或用户的需要定制报表.

所以,做报表测试时要注意以下方面:

1.数据的正确

用户使用报表就是期望通过一个简单方便的平台能快速的查找到他所需要的数据.所以在测试报表时首先就要检查报表中的数据是不是用户需要的数据,如果没有加工的数据,是

否保持了原貌; 加工过的数据查看加工的结构是否和手工加工的结果一致.简言之,需要测试以下内容.

数据的来源:来源于哪张表,哪个字段,数据库中的数值与界面数据的对应.如数据库中性别的数据可能是0或1,但界面显示为男或女,这个对应关系是否正确.

数据的范围:是否只显示了报表设置的对应范围;特别要注意边界数据,要清楚报表的需求,是否需要过滤掉被选择的数据.如时间选择为2006-9-27~2007-9-27,那么是否应该包含9-27这天.

数据的对应关系:数据库中的字段是否与报表中的信息对应

数据的格式:小数位,千位符,四舍五入等是否与报表设置一致;单位或税率转换是否正确;组合显示的数据是否合理

数据的排序:排序方式是否与报表设置一致(如果没有设置,是否有一个清晰的默认排序方式,如按字母或数字排序)

流水号:如报表有使用流水号,流水号的生成和格式是否正确.取消操作是否会生成流水号.

明细与合计的一致性:各部分明细或小节是否与最后总和一致

其他

测试这一部分内容需要对业务逻辑相当熟悉,对数据库的设计也要非常了解.必要时可

以通过自己写查询语句查看数据.

有些报表的条件有多有少,但测试方法都是一样.根据条件通过等价类划分和排列组合

设置各种条件组合.千万不要盲目的测试,否则会导致该测的没测,多余的测试做了一堆..一般来说有类别划分的(一般界面表现为下拉框),每个类别都要测试到,如性别中的男,女都要测试.输入的可以用等价类来划分要测试的数据.

2. 格式的正确

数据验证正确后,就需要看看报表的输出格式是否符合要求.可以从以下几方面来检查.

报表的整体风格:报表是否符合规定的或用户设置的格式

报表标题:报表的标题是否是正确的报表名称;如报表中有嵌入的数据(会跟随用户的选择而变化的).需要检查数据是否正确,如XX企业9月份财务报表,这个9月就是用户选择的; 或者XX公司2006-9-27~2007-9-27的网站访问量,这个时间段也是用户选择的.

公司的一些标志:如logo,名称,地址之类的是否正确

报表的页首与页尾:是否采用了一致的规则.

分页:当输出的内容多时,分页是否正确.翻页功能是否正确

友好性:数据或图表是否清晰,一目了然,数据的展示符合用户的习惯;需要特别提醒的数据(如合计,异常数据)是否突出显示;复杂算法处,用户不明白或容易混淆处是否有注释;一些默认的格式是否让人感觉舒服,如对齐,边界,间隔等

3. 权限的控制

对于有权限控制的系统,报表当然也应该和用户所具有的权限相一致。需要从两方面校验权限的控制。

报表的条件定义:在条件选择区域,有些下拉框中应该不能显示用户权限范围外的数据。如普通文员在使用报表时,报表名称下拉框中是不可以显示管理者才能查看的报表的。有些以输入的文本框有级别的划分时,都应该要测试输入超越权限的数据的相应。

注意这里一定要测试每个条目。

报表内容:报表中的内容不能显示用户本没有权限查看的数据。

4.报表的输出

报表在电脑上生成后,并不是报表的结束。报表一般都需要打印出来他用,如开会或者提交审批之类。所以报表的打印功能也是非常重要的。测试主要分成三部分:

● 打印设置

● 打印预览

● 实际打印效果

除了打印之外,用户有可能需要导出报表做进一步的分析或用于和其他报表的比较。所以也应该提供导出报表的功能。一般可以导出为CSV,Excel,pdf,html,xml格式。

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

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

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

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

测试用例设计思路举例(参考)

ECShop2.7.2用例设计思路举例 说明 用例设计方法的运用非常灵活,没有绝对的套路可言,以下用例设计思路仅供参考。 操作流程举例 参考文档: ?ECShop_2.7.2_简易操作手册V1.0, ?B2C商城ECShop需求规格说明书_2.7.2V1.0 设计思路: 根据操作手册,理清业务逻辑前后关系,再结合SRS文档确定具体的流程细节和分支流程。可以通过画流程的方式梳理流程(流程分析法),下面是部分主流程的案例: ?正向订单流程_余额付款 1)前台页面浏览商品->加入购物车->结算中心->余额付款 2)后台管理中心订单查询->配货->生成发货单->确认生成发货单->去发货->发货 3)前台页面确认收货END ?正向订单流程_货到付款 1)前台页面浏览商品->加入购物车->结算中心->货到付款 2)后台管理中心订单查询->配货->生成发货单->确认生成发货单->去发货 ?逆向订单流程 1)前台页面确认收货->后台管理中心退货->填写退货信息点确定按钮->确认退货 ?商品添加流程_新商品 1)后台管理中心商品管理->新建商品类型/新建商品分类/新建商品品牌->添加新商品(通用信息,详细描述,其他信息,商品属性,商品相册,关联商品,配件,关联 文章) 考虑完所有流程后,再补充考虑部分异常情况,例如:流程中的先后顺序发生变化,或者跳过某个步骤后,系统能否完成后续流程作业。(有些流程是不可能调换顺序或跳过的) Q:流程分析法在设计测试用例的时候会经过很多页面,操作很多字段,这些页面和字段该如何取值呢? A:流程分析法一般考虑页面或字段的有效取值(一般取等价类中最不容易出错的值),测试过程中不关注页面输入域的各种取值情况,特别是错误取值的情况。目的是为了确保流程是可用的。 Q:流程分析法既然不能证明某个页面或字段没有问题,那用此法有何意义呢,为何不直接考虑验证每个页面和模块的各种有效和无效的取值?

系统测试用例设计方法

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

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

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

白盒测试用例设计方法

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: 现在有一个档案管理系统,容许用户通过输入年月对档案文件进行检索,系统对查询条件年月的输入限定为1990年1月-2049年12月,并规定,日期由6位数字组成,前4位表示年,后2位表示月。 1,根据需求进行分析,找出有哪些输入条件 年份:【1990,2049】 月份:【01,12】 字符长度:6位 字符类型:数字 2,画出等价类 输入条件有效等价类边界值分析无效等价类 年份【1990,2049】(1)上点:1990,2049(12) 离点:1989,2050 内点:2016 <1990 (2)>2049 (3) 月份【01,12】(4)上点:01,12(13) 离点:00,13 内点:11 <01 (5)>12 (6) 字符长度6位(7)上点:6 离点:5,7 内点:6 <6 (8)>6 (9) 字符类型数字(10)非数字(11)3,为每个等价类规定一个唯一编号(如上图) 4,转换成测试用例 转换测试用例的原则: A,设计一个测试用例尽可能多的覆盖多个有效等价类; B,设计一个测试用例必须对应覆盖一个无效等价类。 有效等价类用例: 用例1:201611 (1)(4)(7)(10) 无效等价类用例: 用例2:198911 (2) 用例3:205011 (3) 用例4:201600 (5) 用例5:201613 (6) 用例6:20161 (8) 用例7:2016113 (9) 用例8:20161a/abcedf (11) 根据边界值分析法分析后补充测试用例 用例9:199001 (12) 用例10:204912 (13) 5,转成正式格式用例(用例写作的8大要素) 用例编号D1223232_ST_Search_Date_001 项目搜索功能 标题输入正确的日期格式成功搜索

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

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

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

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

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

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

如何设计和执行测试用例

如何设计和执行测试用例测试需求收集完毕后,开始测试设计。 测试用例是什么?测试用例就是一个文档,描述输入、动作、或者时间和一个期望的结果,其目的是确定应用程序的某个特性是否正常的工作。设计测试用例需要考虑以下问题: 测试用例的基本格式: 软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果,下面逐一介绍。 用例编号:测试用例的编号有一定的规则,比如系统测试用例的编号这样定义规则: PROJECT1-ST-001 ,命名规则是项目名称+测试阶段类型(系统测试阶段)+编号。定义测试用例编号,便于查找测试用例,便于测试用例的跟踪。 测试标题:对测试用例的描述,测试用例标题应该清楚表达测试用例的用途。比如“测试用户登录时输入错误密码时,软件的响应情况”。 重要级别:定义测试用例的优先级别,可以笼统的分为“高”和“低”两个级别。一般来说,如果软件需求的优先级为“高”,那么针对该需求的测试用例优先级也为“高” ;反之亦然, 测试输入:提供测试执行中的各种输入条件。根据需求中的输入条件,确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性,如果软件需求中没有很好的定义需求的输入,那么测试用例设计中会遇到很大的障碍。 操作步骤:提供测试执行过程的步骤。对于复杂的测试用例,测试用

例的输入需要分为几个步骤完成,这部分内容在操作步骤中详细列出。 预期结果:提供测试执行的预期结果,预期结果应该根据软件需求中的输出得出。如果在实际测试过程中,得到的实际测试结果与预期结果不符,那么测试不通过;反之则测试通过。 软件测试用例的设计主要从上述 6 个域考虑,结合相应的软件需求文档,在掌握一定测试用例设计方法的基础上,可以设计出比较全面、合理的测试用例。具体的测试用例设计方法可以参见相关的测试书籍,白盒测试方法和黑盒测试方法在绝大多数的软件测试书籍中都有详细的介绍。 一般来说,每个软件公司的项目可以分为固定的几大类。可以按业务类型划分,比如 ERP 软件、产品数据管理软件、通信软件、地理信息系统软件等等;可以按软件结构来划分,比如 B/S 架构的软件、 C/S 架构的软件、嵌入式软件等等。参考同类别软件的测试用例,会有很大的借鉴意义。如果,公司中有同类别的软件系统,千万别忘记把相关的测试用例拿来参考。如果,系统非常接近,甚至经过对测试用例简单修改就可以应用到当前被测试的软件。“拿来主义”可以极大的开阔测试用例设计思路,也可以节省大量的测试用例设计时间。 加强测试用例的评审: 测试用例设计完毕后,最好能够增加评审过程。 同行评审是 CMM3 级的一个 KPA ,如果因为公司没有通过 CMM3 级,就不开展同行评审是不恰当的。测试用例应该由产品相关的软件测试人员和软件开发人员评审,提交评审意见,然后根据评审意见更新测试用例。如果认真操作这个环节,测试用例中的很多问题都会暴露出来,比如用例设计错

测试用例范例

讨论用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对于无输入的操作,应该详细描述其具体的操作步骤和结果

常见的测试用例设计方法都有哪些

常见的测试用例设计方法都有哪些?请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。 1. 等价类划分 常见的软件测试面试题划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类. 2. 边界值分析法 边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误. 使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据. 3. 错误推测法 基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法. 错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结。还有, 输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例. 4. 因果图方法 前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图(逻辑模型). 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况. 5. 正交表分析法 有时候,可能因为大量的参数的组合而引起测试用例数量上的激增,同时,这些测试用例并没有明显的优先级上的差距,而测试人员又无法完成这么多数量的测试,就可以通过正交表来进行缩减一些用例,从而达到尽量少的用例覆盖尽量大的范围的可能性。 6. 场景分析方法

常见的测试用例设计方法都有哪些

常见的测试用例设计方法都有哪些 常见的测试用例设计方法都有哪些? 请分别以具体的例子来说明这些方 法在测试用例设计工作中的应用。 1. 等价类划分常见的软件测试面试题划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并 合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类. 2. 边界值分析法边界值分析方法是对等价类划 分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入

输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误. 使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据. 3. 错误推测法基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法. 错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结。还有, 输入数据和输出数据为0 的情况。输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例. 4. 因果图方法前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查

用户名密码测试用例编写方法

用户名密码测试用例编 写方法 标准化管理处编码[BBX968T-XBB8968-NNJ668-MM9N]

别小看了这个用户名密码这么简单的输入框。可测试的内容还是很多的,并且引发的问题也有很多种类。下面就说一说他的测试方法。? 一、用户注册 只从用户名和密码角度写了几个要考虑的测试点,如果需求中明确规定了安全问题,Email,出生日期,地址,性别等等一系列的格式和字符要求,那就都要写用例测了~ 以等价类划分和边界值法来分析 1.填写符合要求的数据注册:用户名字和密码都为最大长度(边界值分析,取上点) 2.填写符合要求的数据注册:用户名字和密码都为最小长度(边界值分析,取上点) 3.填写符合要求的数据注册:用户名字和密码都是非最大和最小长度的数据(边界值分析,取内点)

4.必填项分别为空注册 5.用户名长度大于要求注册1位(边界值分析,取离点) 6.用户名长度小于要求注册1位(边界值分析,取离点) 7.密码长度大于要求注册1位(边界值分析,取离点) 8.密码长度小于要求注册1位(边界值分析,取离点) 9.用户名是不符合要求的字符注册(这个可以划分几个无效的等价类,一般写一两个就行了,如含有空格,#等,看需求是否允许吧~) 10.密码是不符合要求的字符注册(这个可以划分几个无效的等价类,一般写一两个就行了) 11.两次输入密码不一致(如果注册时候要输入两次密码,那么这个是必须的)

12.重新注册存在的用户 13.改变存在的用户的用户名和密码的大小写,来注册。(有的需求是区分大小写,有的不区分) 14.看是否支持tap和enter键等;密码是否可以复制粘贴;密码是否以* 之类的加秘符号显示 备注:边界值的上点、内点和离点大家应该都知道吧,呵呵,这里我就不细说了~~ 二、修改密码 当然具体情况具体分析哈~不能一概而论~ 实际测试中可能只用到其中几条而已,比如银行卡密码的修改,就不用考虑英文和非法字符,更不用考虑那些TAP之类的快捷键。而有的需要根据需求具体分析了,比如连续出错多少次出现的提示,和一些软件修改密码要求一定时间内有一定的修改次数限制等等。

系统测试用例模板

XX项目 系统测试用例说明书

目录 1引言 ........................................................ 1.1编写目的............................................... 1.2背景................................................... 1.3定义................................................... 1.4参考资料............................................... 2功能测试用例................................................. 2.3管理员测试用例......................................... 2.3.1 被测特性........................................ 2.3.2 A1.1添加用户测试用例........................... 测试需求............................................... A1.1.1.................................................

1引言 1.1编写目的 本文档为(在此指出软件名称)的系统测试活动提供范围、方法、资源和进度方面的指导。预期的读者范围包括: ●项目经理 ●测试人员 ●用户 1.2背景 说明: (1)测试计划所从属的软件系统的名称; (2)该开发项目的历史,列出用户和执行此项目测试的计算中心,说明在开始执行本测试计划之前必须完成的各项工作。 1.3定义 1.4参考资料

测试用例总结

测试用例 一、写测试用例时我们可以侧重从需求上看需要完成的功能方面来写(比如说某一标签或某一按钮点击以后会实现的功能以及页面跳转等) 然后在看输入框界面等 二、测试用例设计考虑的方面 完成了测试需求分析和软件流程分析后,开始着手设计测试用例。测试用例设计的类型包括功能测试,边界测试,异常测试,性能测试,压力测试等。在用例设计中,除了功能测试用例外,应尽量考虑边界、异常、性能的情况,以便发现更多的隐藏问题。 (1)功能测试:测试某个功能是否满足需求的定义,功能是否正确,完备。 适合的技术:由业务需求和设计说明导出的功能测试、等价类划分 (2)边界测试:对某个功能的边界情况进行测试。 适合的技术:边界值划分 (3)异常测试:对某些功能来说,其边界情况无法简单的了解或某些操作不完全是正确的但又是可能发生的,类似这样的情况需要书写相关的异常测试。 适合的技术:由业务需求和设计说明导出的特殊业务流程、错误猜测法、边界值分析、内部边界值测试、 (4)性能测试:检查系统是否满足在需求中所规定达到的性能,性能主要包括了解程序的内外部性能因素。内部性能因素包括测试环境的配置,系统资源使用状况;外部因素包括响应时间,吞吐量等。 适合的技术:业务需求和设计说明导出的测试 (5)压力测试:压力测试又称强度测试,主要是检查系统运行环境在极限情况下软件运行的能力,比如说给一个相当大的负荷或网络流量给应用软件兼容测试:测试软件产品在不同的平台,不同的工具,相同工具的不同版本下功能的兼容性。 三、以登陆窗口为例来设计测试用例 我把这个测试用例分为三层结构,表单测试、逻辑判断、业务流程。 第一层,表单测试为最底层(最基础的)。这部分的测试用例是对登陆窗口这个界面的输入框、按钮功能、界面等最基本功能的测试。一般来说登陆用户名和登陆用户密码是输入框的形式体现,那么,我们需要的是针对这两个输入框进行功能的测试。这时,我们只要考虑这个输入框的功能,而不需要考虑业务方面的内容。这样,我们考虑就是这个输入框的长度限制是多少?能否输入特殊字符?能否输入全角字符?当然,登陆窗口还有其他按钮,例如登

手机软件系统测试用例设计举例

一、等价类分析法 等价类划分方法针对手机状态大致可以归几个大类: 1. 按键类(等价法):有效输入和无效输入(有效输入指UM和菜单指示;无效输入指测试菜单功能此时没有定义的按键和用户动作); 2. 外部中断类(等价法):常用、不常用及无效 2.1. 常用:来电和来消息(短信、彩信、push消息);掀合盖;侧键;耳机&FM;情景模式;电量不足 2.2. 不常用:充电;闹钟&记事本&关机时间&整点报时提示;Icon&动画显示;Icon &动画刷新;编辑界面&pop显示框输入为空或满;编辑界面&pop显示框状态输入法默认&字符编码默认;失效SIM卡;大容量等SIM卡兼容;排序;号码识别; 2.3. 无效:“资料读取中…”;“复制中…”;“请稍后再试” 3. 存储器类 3.1. 等价法分类:读或写;不读或不写。 3.2. 因果法分类:先SIM卡后手机;先手机后SIM卡;提示用户选择存储器(对比Nokia)。 3.3. 操作分类:读;写;新增;删除;复制(先删除后新增;先新增后删除) 4. 状态类:正确;错误;变更;用户设定变更 举例一,短消息发送功能: 英文:Default 7-bit alphabet (over 160 characters) 合法等价类:0~160 非法等价类::>160 The quick fox jumps over the lazy brown dog 中文:UCS-2 alphabet (over 70 characters)

合法等价类:0~70 非法等价类::>70 诺基亚(英文):Extended default 7-bit alphabet (over 140 Bytes),智慧短信,可以携带黑白图片。 合法等价类:0~140 非法等价类::>140 在写字板里面输入“联通”二字,保存后,再打开,即出现乱码。 举例二,单个通话实例的拨打与挂断 测试用例标识 测试阶段:系统测试 测试项 单个通话实例的拨打与挂断 测试项属性 A 参照规范 重要级别 高 测试原因 手机在待机状态下,确保手机能正常拨出电话 预置条件 1. 正常信号环境 2. IDLE状态 3. 默认原厂参数设定

测试用例编写的总结

测试用例编写的总结 通过软件测试培训,在大庆浦东软件平台有限公司经过一周的软件测试实训,从对软件测试没有什么经验的我初步掌握了软件测试的方法和技能,收获颇多的心得。下面是为大家收集整理的软件测试培训心得,欢迎大家阅读。 软件测试培训心得篇1 20xx年x月x日。我怀着对提高并实现自我价值的心态,走进深圳走秀网络科技有限公司的大门,开始了自己大学里兼职实习工作。转眼间。6个月的实习时间就要过去了。回想起这段时间的工作过程,我深深的认识到在走秀网实习的选择是绝对正确的,走秀网和公司的同事们对我个人产生的积极影响也是超越我料想之中的。现将这段时间的工作进行如下总结。 首先,要具有良好的学习能力。刚进走秀,带我的老大是哈尔滨人,我跟她很投缘。开始的一个星期,我只是熟悉公司的一些业务和我们前端的测试范围,在熟悉业务的过程中,我发现这些页面上的东西看上去挺简单的,但是要深入了解还是需要很长的一段时间。期间老大叫一个老员工带着我去测试一些之前xiu2.0所遗留的简单的bug。走秀网的测试部还比较大,所以对工作的流程和上线之前的版本控制的非常严格。我们在上线之前,会经过两套环境,功能测试环境和镜像环境,功能测试环境是对需求和功能的一个详细的验证环境,镜像环境是模拟生产环境回归之前我们在功能测

试环境上锁遗留的一些小的bug。因为不知道这些转测试的bug是怎么产生的,所以需要去跟开发人员沟通,开始的时候自己一个人不敢过去开发部,就让老员工(才哥)带着过去,一段时间过后,我开始自己去和开发沟通交流,从发现问题的重现,到催促开发修改和转测试,这一段时间让我深刻体会到沟通时多么重要。 在走秀期间,我们测试部总监还会对我们不定时的培训。教会我们测试的工作流程和每个阶段应该展开的工作范畴。作为测试,必要会使用的缺陷管理工具bugzilla和测试用例管理工具testlink,还给我们培训了,如何使用自动化工具ruby+watir来对一些测试点进行自动化脚本的编写。慢慢的,在对公司的业务了解的比较透的时候,老大就开始让我们自己对一些小需求进行测试,测试的过程中,不仅仅是对页面和表面功能进行测试,还要根据需求文档和页面的显示对数据库表进行查询操作,查看页面的显示和功能是否和数据表里面的一致,还要在后台日志中查看是否有报错。所以,测试并不是像我想象中的那么简单,不是在页面上点来点去就可以测的好的。 实习可以使每一个学生有更多的机会尝试不同的工作,扮演不同的社会角色,逐步完成职业化角色的转化,发现自己真实的潜力和兴趣,以奠定良好的事业基础,也为自我成长丰富了阅历,促进整个社会人才资源的优化配置。作

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

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

软件测试总结

一、软件测试流程 整体流程:测试需求分析,测试计划编写,测试用例编写,测试执行,缺陷记录,回归测试,判断测试结束,测试报告提交。 测试流程依次如下: 1.需求:阅读需求,理解需求,与客户、开发、架构多方交流,深入了解需求。--testing team。一般而言, 需求分析包括软件功能需求分析、测试环境需求分析等 2.测试计划: 根据需求估算测试所需资源(人力、设备等)、所需时间、功能点划分、如何合理分配安排资 源等。---testing leader or testing manager。测试目的、测试环境、测试方法、测试用例、测试工具 3.用例设计:根据测试计划、任务分配、功能点划分,设计合理的测试用例。---testing leader, senior tester 4.执行测试:根据测试用例的详细步骤,执行测试用例。--every tester(主要是初级测试人员) 5.执行结果记录和bug记录:对每个case记录测试的结果,有bug的在测试管理工具中编写bug记录。--every tester(主要是初级测试人员) 6.defect tracking(缺陷跟踪):追踪leader分配给你追踪的bug.直到 bug fixed。--every tester 7.测试报告:通过不断测试、追踪,直到被测软件达到测试需求要求,并没有重大bug. 8.用户体验、软件发布等…… 总结:项目立项后,开始写测试计划,根据需求编写测试需求,根据测试需求编写测试用例,根据测试用例执行测试,把没用通过的测试用例写成测试缺陷报告,进行回归测试,直到测试的结束编写测试总结,这每个步骤都需要审核通过。 二、软件测试方法 1、黑盒测试 概念:完全不考虑程序或软件的内部逻辑结构和处理过程的情况下,根据需求分析编写并执行测试用例,在程序或软件的界面上进行测试。 主要目的:(1)是否有不正确的或者遗漏的功能。(2)能都正确输入和输出结果。(3)是否有数据结构错误或外部信息访问错误。(4)性能上是否满足要求。(5)是否有初始化或终止行错误。 优点:(1)即使程序发生变化,之前的测试用例依然可以使用;(2)测试用例和软件开发可以同时进行,加快了测试和开发的速度。 局限性:(1)难以查找问题的原因和位置;(2)黑盒测试的依据是需求分析,所以无法发现需求分析上的错误。 测试方法: (1)等价类划分 包括有效等价类(符合需求规格说明)和无效等价类(违反需求规格说明)。 a)确定输入取值范围:可以确定一个有效等价类和两个无效等价类 b)确定输入某个值:可以确定一个有效等价类和两个无效等价类

性能测试用例模版

测试用例模板 测试用例(Test case) 用例名称 用例编号 重要程度 用例设计人 代码负责人 测试人 测试时间 English version Title Case ID Level Designer Developer Tester Time 测试场景描述(Case scenario) 场景描述 子场景(可选) 子场景1 例如,返回10条记录 子场景2 例如,返回100条记录 测试流程(Testing process) 描述被测试应用场景的商业流程,流程必须在实际测试中发挥良好的导航作用,使不熟悉该系统的使用者能够对商业流程有清晰的了解。 (被测的商业流程应该事先通过检测,以确保功能的顺利运行。应用程序代码在测试阶段应该被冻结) 1. 2. 3. 测试条件和要求(Requirements) 环境要求 硬件要求: WEB服务器- 配置1.2 (详细配置信息见测试计划文档,或附录) 软件要求: 补丁要求: 网络要求:

性能基线和衡量指标(Testing baseline & metrics) 前提(测试结果有效的先决条件) 1. 例如:无内存泄漏;HTTP错误个数为0 2. 数据库数据要求 例如:流水表已有20万条记录 3. 并发连接数要求 4. 测试周期或测试次数 性能基线 1. 例如:每秒钟完成XXX笔交易 2. 3. 监视参数(详情见附录) 1. 例如:Performance Monitor: Private Byte 2. 3. 性能计算方式 1. 例如:数据库交易表增加纪录数/ 总时间(秒) 2. 3. 测试数据和脚本(Testing data, Scripts) 测试数据准备 包括登陆账号组,输入数据;可以事先保存在某个文本文件中 测试数据库 数据库、表、存储过程、视图、用户帐号、相关数据 测试脚本 根据测试工具编写相应脚本或编写手工测试脚本 for Example 1LBrowser 1. Navigate to the home page of the Online Shopping site. 2. Click “Help.” 3. Click “FAQ.” 4. Click “Shopping” on FAQ. 5. Click “Shopping/Our Products” on the main menu. 6. Click “Product Search.”

相关文档
最新文档