功能测试用例说明书

功能测试用例说明书
功能测试用例说明书

功能测试用例说明书

功能测试用例说明书

作者

发布范围HPTCA-MS 整个生命周期

版本V1.0

发布日期2008-6-12

修订历史记录

发布日期版本说明作者2008-6-12 1.O考勤系统测试用例

目录

1.引言 4

1.1 编写的目的4

1.2 编写范围4

1.3 参考文献4

1.4 术语与缩略语4

2.接口测试用例 4

2.1被测试对象的介绍4

2.2测试范围与目的 4

2.3测试环境与测试辅助工具的描述4

2.4测试驱动程序的设计4

2.5接口测试用例 5

3.功能测试用例 5

3.1被测试对象的介绍5

3.2测试范围与目的 5

3.3测试环境与测试辅助工具的描述5

3.4测试驱动程序的设计5

3.5功能测试用例 5

4.评审意见 6

5.其它需要说明的问题: 6

需求说明书

1.引言

1.1编写的目的

本手册是基于项目已经基本完成,作为项目测试人员对项目功能进行测试。测试各项功能是否达标!

1.2编写范围

功能测试用例编号名称责任人备注AT001登录(包括身份验证,页面跳转)王挺

AT002考勤基本操作(包括上班,下班,请假申请,出差申请)刘红杰

AT003员工考勤信息管理(包括修改密码,段时间考勤信息查询)毛凌波

AT004消息服务(包括收发短信息,网站留言)夏天梁

AT005员工个人信息管理(包括员工信息查询,添加员工,生成富强

AT006Excel 表格)

手动考勤(包括手动上下班,手动请假,手动出差)张耿耿

AT007节假日管理(包括添加节假日,修改节假日)王杰

AT008申请管理(包括请假申请,出差申请)薛纪表

AT009人性化和网站安全周碧文

1.3参考文献

编号资料名称简介作者日期出版单位

01《数据库设计说明书》数据库设计资料薛纪表2008.05.10软件( 4)班 2 组02《需求规格说明书》需求规格资料周碧文2008.05.02软件( 4)班 2 组03《概要设计说明书》概要设计资料王杰2008.05.23软件( 4)班 2 组04《详细设计说明书》详细设计资料周碧文软件( 4)班 2 组https://www.360docs.net/doc/05661992.html,技术支持,解答///

1.4术语与缩略语

术语、缩略语

ST

?

解释系统测试, System Test

?

2.接口测试用例

2.1 被测试对象的介绍

2.2 测试范围与目的

2.3 测试环境与测试辅助工具的描述

2.4 测试驱动程序的设计

2.5 接口测试用例

3.功能测试用例

3.1 被测试对象的介绍

3.2 测试范围与目的

3.3 测试环境与测试辅助工具的描述

3.4 测试驱动程序的设计

3.5 功能测试用例

用例 ID AT001

操作角色员工,管理员

功能 A描述登录(包括身份验证,页面跳转)

用例目的检测系统在合法和不合法的登录下所产生的结果前提条件登录帐号和密码必须通过键盘输入

输入 /动作

【身份验证】正确账户密码和验证码

【身份验证】错误的帐户密码,正确验证码

【身份验证】正确的账户密码,错误验证码

【页面跳转】登录成功选择进入系统

用例 ID AT002

期望的输出 / 响应实际情况

登录成功登录成功

登录失败并且提示验证码错误登录失败并且提示验证码错误登录失败并且提示账户错误登录失败并且提示账户错误根据不同身份跳转到不同的权限页面

操作角色员工

功能 B 描述考勤基本操作(包括上班,下班,请假申请,出差申请)

用例目的检测员工不同情况下上下班的结果前提条件手动操作

输入 /动作

【上班】今天节假日

【上班】昨天非节假日,非请假,非出差情况下有旷工现象情况

【上班】昨天非节假日,非请假,非出差情况下有早退现象

【上班】今天早上迟到

【上班】昨天未出现矿工早退现象,今天未迟到

【下班】未到下班时间

【下班】已到下班时间

【出差申请】提出出差申请

【请假申请】提出请假申请

用例 ID AT003

期望的输出 / 响应实际情况

提示不用上班提示不用上班

提示昨天旷工并且要求提交理由,提交提示昨天旷工并且要求提交理由,提交之后显示欢迎界面。之后显示欢迎界面。

提示昨天早退并且要求提交理由,提交提示昨天早退并且要求提交理由, 提之后显示欢迎界面。交之后显示欢迎界面。

提示今天迟到并且要求提交理由,提交提示今天迟到并且要求提交理由, 提之后显示欢迎界面。交之后显示欢迎界面。

显示欢迎界面。显示欢迎界面。

提示未到时间并且要求选择是否继续,提示未到时间并且要求选择是否继续,提交之后显示下班提示界面。提交之后显示下班提示界面。

显示下班成功界面。显示下班成功界面。

发出出差申请之后等待管理员通过,在发出出差申请之后等待管理员通过,在通过之后在出差时间段内不用上班通过之后在出差时间段内不用上班

发出请假申请之后等待管理员通过,在发出请假申请之后等待管理员通过,在通过之后在请假时间段内不用上班通过之后在请假时间段内不用上班

操作角色员工,管理员

功能 C 描述员工考勤信息管理(包括修改密码,段时间考勤信息查询)用例目的测试密码修改,考勤信息查询的系统处理

前提条件手动操作,需要输入原来密码

输入 /动作

【修改密码】修改密码时原

始密码错误

【修改密码】修改密码时不符合密码规则(密码长度小于 5)【修改密码】修改密码时候新密码确认失败

【修改密码】原始密码正确,

确认密码正确

【考勤查询】根据开始时间

和结束时间查询考勤信息

期望的输出 / 响应实际情况

提示原始密码错误提示原始密码错误

提示密码长度不够提示密码长度不够

提示确认密码和新密码不相同提示确认密码和新密码不相同

提示密码修改成功并且在权限管理表提示密码修改成功并且在权限管理表

中修改登录密码中修改登录密码

能够根据时间段准确查找出这段时间能够根据时间段准确查找出这段时间

内自己的考勤信息(包括总工时,请假内自己的考勤信息(包括总工时,请假次数,旷工次数,出差次数,早退次数,次数,旷工次数,出差次数,早退次数,迟到次数)并且点击详情之后出现详细迟到次数)并且点击详情之后出现详细

考勤资料(拿请假次数来说,详情应该考勤资料(拿请假次数来说,详情应该包括请假开始时间,结束时间等)包括请假开始时间,结束时间等)

管理员可以根据员工号实现某个员工管理员可以根据员工号实现某个员工

的考勤信息的查询的考勤信息的查询

用例 ID AT004

操作角色员工,管理员

功能 D 描述消息服务(包括收发短信息,网站留言)用例目的测试消息服务是否可行

前提条件手动操作

输入 /动作

【短信息】查看收件箱【短消息】发送消息【网站留言】

用例 ID AT005

期望的输出 /响应实际情况

未读收件箱有未读取信件的信件列

未读收件箱有未读取信件的信件列表,历史收件表,历史收件箱有已读取信件的信

箱有已读取信件的信件列表,未读信件可以标识件列表,未读信件可以标识成已读

成已读信件并且转入到已读信件箱

信件并且转入到已读信件箱

发送之后在用收件人的账户登录之

发送之后在用收件人的账户登录之后可以成功收后可以成功收到信件,并且信件处

到信件,并且信件处在未读状态

在未读状态

员工可以对网站进行留言,管理员员工可以对网站进行留言,管理员可以查看到当可以查看到当前网站留言列表。前网站留言列表。

操作角色管理员

功能 E 描述员工个人信息管理(包括员工信息查询,添加员工,生成Excel 表格)用例目的测试员工信息的系统输出

前提条件手动操作

输入 /动作

【员工信息查询】根据

条件(包括员工号,员

工姓名,部门,状态)

查找员工

【添加员工】必要的项没

有填写(包括员工号,姓名,密码,电子邮件,安

全问题,问题答案)【添

加员工】项的格式错误

(包括密码长度小

于5,电子邮件格式

错误)

【添加员工】格式正确,必填项也填写

【生成报表】当前信息

窗口存在数据

用例 ID AT006

期望的输出 /响应实际情况

显示员工的具体信息(包括员工号,显示员工的具体信息(包括员工号,员工密码,员工密码,家庭住址,电话号码等)家庭住址,电话号码等)

提示添加失败,要求补全提示添加失败,要求补全

提示添加失败,要求修改格式提示添加失败,要求修改格式

提示添加成功,并且显示添加后的

提示添加成功,并且显示添加后的员工信息列表

员工信息列表

弹出对话框要求用Excel 工具查看弹出对话框要求用Excel 工具查看电子表格形式电子表格形式并且成功转入并且成功转入

操作角色管理员

功能 F 描述手动考勤(包括手动上下班,手动请假,手动出差)用例目的测试手动考勤操作系统输出

前提条件手动操作

输入 /动作期望的输出 /响应实际情况

【手动上下班】根据员

工姓名和状态选择让其员工状态成功得到修改员工状态成功得到修改

上 /下班

【手动请假申请】填写

该员工在申请阶段无需上班该员工在申请阶段无需上班

请假申请表

【手动请假申请】请假

提示提交失败,要求更正提示提交失败,要求更正

申请表填写格式不正确

【手动出差申请】填写

该员工在申请阶段无需上班该员工在申请阶段无需上班

出差申请表

【手动出差申请】出差

提示提交失败,要求更正提示提交失败,要求更正

申请表填写格式不正确

用例 ID AT007

操作角色管理员

功能 G描述节假日管理(包括添加节假日,修改节假日)

用例目的测试节假日管理的系统输出

前提条件手动操作

输入 /动作期望的输出 / 响应实际情况

【添加节假日】添加节假日并提示添加成功并且在节假日列表中显提示添加成功并且在节假日列表中显且各项格式正确示当前的节假日列表信息示当前的节假日列表信息

【修改节假日】选择已存在的提示修改成功并且在节假日列表中显提示修改成功并且在节假日列表中显节假日并且修改其中细节示当前的节假日列表信息示当前的节假日列表信息

用例 ID AT008

操作角色管理员

功能 H描述申请管理(包括请假申请,出差申请)

用例目的测试申请管理的系统输出

前提条件手动操作

输入 /动作期望的输出 / 响应

请假申请批准之后在员工信息中可以【请假申请】对提出的申请进查找到批准的那名员工的考勤记录多

行批准操作了一条请假记录,并且该名员工请假阶

段不用上班

出差申请批准之后在员工信息中可以【出差申请】对提出的申请进查找到批准的那名员工的考勤记录多

行批准操作了一条出差记录,并且该名员工出差阶

段不用上班

用例 ID AT009

实际情况

请假申请批准之后在员工信息中可以查找到批准的那名员工的考勤记录多

了一条请假记录,并且该名员工请假阶段不用上班

出差申请批准之后在员工信息中可以

查找到批准的那名员工的考勤记录多

了一条出差记录,并且该名员工出差阶段不用上班

操作角色员工,管理员

功能 I 描述人性化和网站安全

用例目的测试安全性和人性性

前提条件手动操作

输入 /动作期望的输出 / 响应实际情况

员工首页提示未读短消息条数并且支员工首页提示未读短消息条数并且支

【人性化】登录成功后进入首持链接到收件箱;管理员首页提示未读持链接到收件箱;管理员首页提示未读短消息条数和员工申请条数(包括请假短消息条数和员工申请条数(包括请假

申请和出差申请)并且支持链接到收件申请和出差申请)并且支持链接到收件

箱和批准申请页面箱和批准申请页面

【人性化】生日当天登录系统提示生日快乐祝福信息提示生日快乐祝福信息

【人性化】节假日当天登录系

首页提示节假日资料和历史首页提示节假日资料和历史

【网站安全】员工在地址栏直

提示权限不够要求重新登录提示权限不够要求重新登录

接访问管理员页的地址

4.评审意见

提示:

测试组长邀请开发人员和同行专家,对《功能测试用例》进行技术评审,参见评审过程。

5.其它需要说明的问题:

功能测试用例说明书

功能测试用例说明书 功能测试用例说明书 作者 发布范围HPTCA-MS 整个生命周期 版本V1.0 发布日期2008-6-12 修订历史记录

发布日期版本说明作者2008-6-12 1.O考勤系统测试用例 目录 1.引言 4 1.1 编写的目的4 1.2 编写范围4 1.3 参考文献4 1.4 术语与缩略语4 2.接口测试用例 4 2.1被测试对象的介绍4 2.2测试范围与目的 4 2.3测试环境与测试辅助工具的描述4 2.4测试驱动程序的设计4 2.5接口测试用例 5 3.功能测试用例 5 3.1被测试对象的介绍5 3.2测试范围与目的 5 3.3测试环境与测试辅助工具的描述5 3.4测试驱动程序的设计5 3.5功能测试用例 5 4.评审意见 6 5.其它需要说明的问题: 6 需求说明书

1.引言 1.1编写的目的 本手册是基于项目已经基本完成,作为项目测试人员对项目功能进行测试。测试各项功能是否达标! 1.2编写范围 功能测试用例编号名称责任人备注AT001登录(包括身份验证,页面跳转)王挺 AT002考勤基本操作(包括上班,下班,请假申请,出差申请)刘红杰 AT003员工考勤信息管理(包括修改密码,段时间考勤信息查询)毛凌波 AT004消息服务(包括收发短信息,网站留言)夏天梁 AT005员工个人信息管理(包括员工信息查询,添加员工,生成富强 AT006Excel 表格) 手动考勤(包括手动上下班,手动请假,手动出差)张耿耿 AT007节假日管理(包括添加节假日,修改节假日)王杰 AT008申请管理(包括请假申请,出差申请)薛纪表 AT009人性化和网站安全周碧文 1.3参考文献 编号资料名称简介作者日期出版单位 01《数据库设计说明书》数据库设计资料薛纪表2008.05.10软件( 4)班 2 组02《需求规格说明书》需求规格资料周碧文2008.05.02软件( 4)班 2 组03《概要设计说明书》概要设计资料王杰2008.05.23软件( 4)班 2 组04《详细设计说明书》详细设计资料周碧文软件( 4)班 2 组https://www.360docs.net/doc/05661992.html,技术支持,解答/// 1.4术语与缩略语 术语、缩略语 ST ? 解释系统测试, System Test ?

手机基本功能测试方式

手机基本功能测试 手机基本测试软件测试 关于手机软件测试的工具应用 手机软件测试是否也和以下联系起来: 漫谈人机界面测试 【正文】本文列数了软件黑盒测试过程中,在被测试软件中可能存在的常见软件问题。本文不会详细讨论基本的软件测试思想与常用技术,仅针对在软件黑盒测试过程中若干的问题做描述,并提供个人的参考测试意见与防范意见,希望可以为初学者提供些许帮助。 俗话说“人靠衣裳马靠鞍”,良好的外观往往能够吸引眼球,激发顾客(用户)的购买欲望,最终达成商业利益的实现。软件的设计亦如此,Window XP 在商业上的巨大成功很大一方面来自于它一改往日呆板,以突出“应用”的灰色界面,从“用户体验”角度来设计界面,使界面具有较大的亲和力。就目前的软件设计的发展趋势来说,良好的人机界面设计越来越受到系统分析、设计人员的重视。但是如何对设计的人机界面(包括帮助等)进行测试,给出客观、公正的评价,却鲜见于报端。本文试从共性分析和个性分析的角度,给出一些测试意见和原则,简单且易于上手。起到一个抛砖引玉的目的、以飨读者。 我们知道:“不立规矩无以成方圆”。在软件界面设计强调张扬个性的同时,我们不能忘记软件界面的设计先要讲求规矩-简洁、一致、易用,这是一切软件界面设计和测试的必循之道,是软件人机界面在突出自我时的群体定位。美观、规整的软件人机界面破除新用户

对软件的生疏感,使老用户更易于上手、充分重用已有使用经验,并尽量少犯错误。由此我们在对软件人机界面进行测试时(设计评审阶段和系统测试阶段结合进行),不妨从下列一些角度测试软件的人机界面。 一致性测试 一致性使软件人机界面的一个基本要求。目的是使用户在使用时,很快熟悉软件的操作环境,同时避免对相关软件操作发生理解歧义。这要求我们在进行测试时,需要判断软件的人机界面是否可以作为一个整体而存在。下面是进行一致性测试的一些参考意见:――提示的格式是否一致 ――菜单的格式是否一致 ――帮助的格式是否一致 ――提示、菜单、帮助中的术语是否一致 ――各个控件之间的对齐方式是否一致 ――输入界面和输出界面在外观、布局、交互方式上是否一致 ――命令语言的语法是否一致 ――功能类似的相关界面是否在在外观、布局、交互方式上是否一致(比如商品代码检索和商品名称检索) ――存在同一产品族的时候,是否与其他产品在外观、布局、交互方式上是否一致(例:Office产品族)

功能测试用例的设计

功能测试用例的设计 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.在事件触发机制中场景法用得最多。在测试一个软件的时候,先确定基本流也就是测试流程中软件功能按照正确的事件流实现的一条正确流程,接着去确定备选流也就是那些出现故障或缺陷的过程,用备选流加以标注。然后可以采用矩阵或决策表来确定和管理测试用例。

史上最全的手机硬件测试用例

XXX手机硬件测试列表 1.1.1 LCD测试 1.数量:2pcs以上; 2.测试方法及内容:手机正常开机后,距离30cm,与水平成45o角并在各个方向15o范围内观察LCD工作是否正常。 a. LCD显示是否正常,是否存在斑点、阴影等; b.彩屏LCD各种颜色能否正常显示,分辨率、色素、响应时间等性能指标是否符合要求; c.分别在暗室、荧光(约750Lux)和阳光(大于3500Lux)下测试LCD显示是否正常,各性能指标是否符合要求; d.将电源设置成高(4.2v)、中(3.8v)、低(3.5v)不同电压,LCD显示是否有差异或异常。 3.预期结果: a. LCD显示正常,不存在斑点、阴影等; b.彩屏LCD各种颜色正常显示,分辨率、色素、响应时间等性能指标符合要求(结合项目的具体指标规定); c.在暗室、荧光(约750Lux)和阳光(大于3500Lux)下测试LCD显示均应正常,各项性能符合项目的具体指标要求; d.在高、中、低不同电压下,LCD显示应正常且基本一致。 1.1.2 LCD背光及键盘背光测试 1.数量:2pcs以上; 2.测试方法及内容:手机正常开机后,选择进入手机功能菜单中的相应设置进行测试。 a.测试手机背光及LED能够正常工作; b.分别在暗室、荧光(约750Lux)和阳光(约2000Lux)下测试LED亮度是否正常; c.背光亮度是否符合要求,测试在不同电池电压情况下,背灯的亮度是否具有一致性; d. LED是否能够按照要求打开和关闭。 3.预期结果: a.手机背光及LED工作正常; b.在暗室、荧光(约750Lux)和阳光(约2000Lux)下,LED亮度均应正常; c.背光亮度应符合要求且在不同电池电压情况下,背灯亮度基本一致; d. LED能够按照要求打开和关闭,且亮度正常。 1.1.3 TP触摸屏承重能力测试 4.数量:5pcs以上; 5.测试方法及内容:重压头25kg,静压30秒之后,等待30秒,再重新放置重压头。 6.预期结果: a. 200次重压后样品不出现牛顿环,则为良品; 1.1.4 Camera测试 1.数量:4pcs以上; 2.测试方法及内容:手机正常开机后,选择手机功能菜单进入拍照状态,对标准测试板进行拍照。 a. Camera是否能够正常工作; b. 拍摄的照片效果是否符合规范要求; c. 用标准色板照片色块的对比测试; d. 测试Digital Camera的反应时间; e. 开启闪光灯功能,看闪光灯是否正常工作。 3.预期结果: a. Camera工作正常,能正常开启与关闭; b.照片效果符合规范要求,参考Camera Spec; c.反应时间达到规范要求;

测试用例(新手必看)

测试用例 一、定义 测试用例(Test Case )是指对一项特定的软件产品进行测试任务的描述,体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等,并形成文档。 二、测试用例的分类 根据测试过程中具体涉及到问题类型及测试需求,可将测试用例分为如下: ●功能性测试用例 ●界面测试用例:适用于所有测试阶段中的界面测试 ●数据处理测试用例:适用于所有测试阶段中的数据处理测试 ●操作流程测试用例:适用于所有流程性的测试 ●安装测试用例:适用于所有安装测试 三、测试用例管理 ●编写用例:测试工程师根据需求规约、概要设计、详细设计等文档编写测试用例。 ●用例评审:原则上用例象程序一样,要经过多次的修改才可以通过,实际工作中通常进行一次。 ●用例修改:评审结束后,您需要根据评审意见进行修改,修改后通常不再进行评审。 ●使用用例:执行测试用例,并记录到测试用例执行报告中。 ●用例升级/ 维护:随着软件产品不断修改、升级,对应的用例也需要升级维护。针对同一个项目,可以根据需求的变更不断进行维护;如果是产品,用例的维护更加重要,要达到用例和产品的版本一一对应。 四、测试用例的编制及使用 1 、设计测试用例 每个具体测试用例都将包括下列详细信息:编制人、审定人、编制日期、版本、用例类型、设计说明书编号、用例编号、用例名称、输入说明、期望结果(含判断标准)、环境要求、备注等。 测试用例 编制人 审定人 编制日期 版本 测试用例类型 设计说明书编号 测试用例编号 测试用例名称 输入说明(列出选用的输入项,覆盖正常、异常情况): 期望结果(逐条与输入项对应,列出预期输出): 环境要求(测试要求的软、硬件、网络要求): 备注: ●“测试用例名称”可以是不涉及到具体模块的功能描述,如“日期格式”,“非空检验”等。 ●“输入说明”是功能模块接受的数据或各种操作描述,如“输入非法的日期格式”等。 ●“期望结果”是模块接受输入后应有的正常输出描述,如“提示用户修改”等,期望结果应与输入说明一一对应。 ●测试用例用于指导执行操作,但某些意外操作也可导致程序错误,这些操作称为非预

手机app测试方法

1 APP测试基本流程 1.1流程图 仍然为测试环境

1.2测试周期 测试周期可按项目的开发周期来确定测试时间,一般测试时间为两三周(即15个工作日),根据项目情况以及版本质量可适当缩短或延长测试时间。正式测试前先向主管确认项目排期。 1.3测试资源 测试任务开始前,检查各项测试资源。 --产品功能需求文档; --产品原型图; --产品效果图; --行为统计分析定义文档; --测试设备(ios3.1.3-ios5.0.1;Android1.6-Android4.0;Winphone7.1及以上;Symbian v3/v5/Nokia Belle等); --其他。 1.4日报及产品上线报告 1)测试人员每天需对所测项目发送测试日报。 2)测试日报所包含的内容为: --对当前测试版本质量进行分级; --对较严重的问题进行例举,提示开发人员优先修改; --对版本的整体情况进行评估。 3)产品上线前,测试人员发送产品上线报告。 4)上线报告所包含的内容为: ---对当前版本质量进行分级; ---附上测试报告(功能测试报告、兼容性测试报告、性能测试报告以及app可用性能标准结果); --总结上线版本的基本情况。若有遗留问题必须列出并记录解决方案。 2 App测试点 2.1安全测试 2.1.1软件权限 1)扣费风险:包括发送短信、拨打电话、连接网络等

2)隐私泄露风险:包括访问手机信息、访问联系人信息等 3)对App的输入有效性校验、认证、授权、敏感数据存储、数据加密等方面进行检测 4)限制/允许使用手机功能接人互联网 5)限制/允许使用手机发送接受信息功能 6)限制/允许应用程序来注册自动启动应用程序 7)限制或使用本地连接 8)限制/允许使用手机拍照或录音 9)限制/允许使用手机读取用户数据 10) 限制/允许使用手机写人用户数据 11) 检测App的用户授权级别、数据泄漏、非法授权访问等 2.1.2安装与卸载安全性 1)应用程序应能正确安装到设备驱动程序上 2)能够在安装设备驱动程序上找到应用程序的相应图标 3)是否包含数字签名信息 4)JAD文件和JAR包中包含的所有托管属性及其值必需是正确的 5)JAD文件显示的资料内容与应用程序显示的资料内容应一致 6)安装路径应能指定 7)没有用户的允许,应用程序不能预先设定自动启动 8)卸载是否安全,其安装进去的文件是否全部卸载 9)卸载用户使用过程中产生的文件是否有提示 10)其修改的配置信息是否复原 11)卸载是否影响其他软件的功能 12)卸载应该移除所有的文件 2.1.3数据安全性 1)当将密码或其他的敏感数据输人到应用程序时,其不会被储存在设备中,同时密码也不会被解码 2)输人的密码将不以明文形式进行显示 3)密码,信用卡明细,或其他的敏感数据将不被储存在它们预输人的位置上 4)不同的应用程序的个人身份证或密码长度必需至少在4一8个数字长度之间 5)当应用程序处理信用卡明细,或其他的敏感数据时,不以明文形式将数据写到其它单独的文件或者临时文件中。以防止应用程序异常终止而又没有侧除它的临时文件,文件可能遭受人侵者的袭击,然后读取这些数据信息。 6)当将敏感数据输人到应用程序时,其不会被储存在设备中 7)备份应该加密,恢复数据应考虑恢复过程的异常通讯中断等,数据恢复后再使用前应该经过校验 8)应用程序应考虑系统或者虚拟机器产生的用户提示信息或安全替告 9)应用程序不能忽略系统或者虚拟机器产生的用户提示信息或安全警告,更不能在安全警

测试用例规范说明

测试用例规范约定 一、用例设计书写的标准规范 1.用例标题 描述清楚该用例所要达到的测试目的,不是单纯的描述所在模块或; 正确示例: 未登录状态下发布动态能否成功 或 登录状态下只发布文字动态内容能否成功 2.前置条件 用例必须清晰地描述此用例所需的前提条件; 正确示例: 1、用户已登录云转诊APP; 2、用户已进入动态页面; 3.用例步骤 测试用例编写要步骤明确,输入输出要素(输入数据值)清晰,并且无疑义; 输入数据值:指当前用例输入值的具体范围及明确值; 正确示例: 1、点击动态下的(发动态)按钮 2、输入文字:我很享受音乐 3、点击(发送)按钮 4.预期结果 预期结果必须具有可判定性,即测试步骤执行后,结果是可判定的,每一个测试用例的步骤都应有相应的唯一的预期结果,预期结果中不能包含步骤; 正确示例: 发布动态成功,页面跳转至动态页面 错误示例: 1.云转诊APP成功打开 2.显示我的页面 3.打开编辑页面 4.弹出性别选择窗口 5.测试用例集 一条用例内多个用例步骤对应多个预期结果时,禁止使用编号内附加子级编号形式编写测试用例,需要单独表述。测试用例可以使用单条用例或测试用例集的方式编写,单条用例需要把同一情况下的测试用例整合在一条内编写,预期结果与操作步骤相互对应。测试用例集需要操作步骤与预期结果编号相对应,完整的表达操作与结果之间的关系

真实示例如下图所示: 二、用例设计书写的颗粒度描述 要求:验证一个功能点一条用例,没有重复、冗余的测试用例。 功能测试用例需要从用户层面来设计用户使用场景和使用流程。 1.冒烟测试 验证系统正向功能流程通畅及验证系统正向必填项(系统要求验证项)输入值、单选项、下拉框、按钮等符合系统要求; 2.功能测试 用例中需要合理的使用测试用例编写方法设计反向用例、容错性用例、三方交互用例等场景,以确保覆盖业务操作的基本路径和异常路径,以及对其他模块/功能的影响和必填项(系统要求验证项),保证达到系统规定; 3.UI测试 对系统UI页面进行检查,确保UI布局合理、文字统一、易用性(易操作、易理解和易学习)、友好性等达到系统要求(同一页面没有操作整体时,页面检查算一个功能点); 三、用例执行规范 1.出现非Pass的用例必须标记对应的状态,Fail的用例必须提交缺陷; 2.由于某个Bug缺少测试条件导致用例不能执行,标为Block添加备注信息; 3.功能模块没有设计好,或者不适用于本轮测试的用例,标为N/A加备注信息; 四、用例测试执行突发状况处理

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

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

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

测试用例颗粒度说明

测试用例颗粒度说明 1.颗粒度与测试的关系 如果把测试用例设计得很细,照顾到每一个数据输入、每一个条件、每一个环境、每一个路径,那么测试用例的数量将是巨大的,虽然风险很小很小,但是测试效率会很低,并且测试执行没有思考的空间,可能使测试执行人员变得呆板(除非全部测试自动化),不需要创造力、思考。测试用例设计很粗,测试效率可能比较高,测试人员有一个发挥的空间,使测试更有趣,但这依赖于个人的责任感和能力,风险大得多。 2.颗粒度的大小取决与以下三点 1、“重要功能”、“特殊功能”颗粒密集度高,“通用功能”可以试用通用测试粒度,密集度应该可以大致界定。个人认为,假如你非要为了一个字体的样式而写了一大长串的测试用例,那么这个颗粒度就毫无意义了。 2、颗粒度的大小还取决与客户对“产品”的要求。测试有一个难题是测试的精度,或者说颗粒度的定义,不要说一个程序,就算是一个简单的登录都可以写出几乎无穷尽的测试用例,所以你需要指明功能、性能需求,使用环境等,并说明对缺陷容忍的限度。才好依据最终的需求来定义测试的颗粒度,也才好写测试用例,总之,客户的要 求越详细所得到的测试用例越准确。如果客户跟你说这个地方你必须仔仔细细的测试。那么我们在写测试用例的时候。这个颗粒度一定要小了。 3、一般功能颗粒密集度可能会根据项目或是时间来确定。如果时间充裕颗粒度可以适当小。 4、粒度取决于测试的种类,一般用验收测试,是项目测试中颗粒度比较大。系统测试颗粒度相对较小。 3.有效度量测试用例条件: 1、颗粒度可以跟代码行数对应:一般来说代码量越大,内部逻辑就越复杂,出现bug 的的可能性也越高。对应的测试粒度也越小。 2、测试团队内部对粒度达成一致,适当把握颗粒度:明确测试用例编写的颗粒度,大

测试用例基本通用模板

1. 登陆、添加、删除、查询模块是我们经常遇到的,这些模块的测试点该如何考虑 1)登陆 ①用户名和密码都符合要求(格式上的要求) ②用户名和密码都不符合要求(格式上的要求) ③用户名符合要求,密码不符合要求(格式上的要求) ④密码符合要求,用户名不符合要求(格式上的要求) ⑤用户名或密码为空 ⑥数据库中不存在的用户名,不存在的密码 ⑦数据库中存在的用户名,错误的密码 ⑧数据库中不存在的用户名,存在的密码 ⑨输入的数据前存在空格 ⑩输入正确的用户名密码以后按[enter]是否能登陆 2) 添加 ①要添加的数据项均合理,检查数据库中是否添加了相应的数据 ②留出一个必填数据为空 ③按照边界值等价类设计测试用例的原则设计其他输入项的测试用例 ④不符合要求的地方要有错误提示 ⑤是否支持table键 ⑥按enter是否能保存 ⑦若提示不能保存,也要察看数据库里是否多了一条数据 3) 删除 ①删除一个数据库中存在的数据,然后查看数据库中是否删除 ②删除一个数据库中并不存在的数据,看书否有错误提示,并且数据库中没有数据被删除 ③输入一个格式错误的数据,看是否有错误提示,并且数据库中没有数据被删除。 ④输入的正确数据前加空格,看是否能正确删除数据 ⑤什么也不输入 ⑥是否指出table键 ⑦是否支持enter键 4)查询 精确查询: ①输入的查询条件为数据库中存在的数据,看是否能正确地查出相应得数据 ②输入正确的查询条件以前加上空格,看是否能正确地查出相应的数据 ③输入格式或范围不符合要求的数据,看是否有错误提示 ④输入数据库中不存在的数据

⑤不输入任何数据 ⑥是否支持table键 ⑦是否支持enter键 模糊查询: 在精确查询的基础上加上以下一点 ①输入一些字符,看是否能查出数据库中所有的相关信息 2.设计功能测试用例 文本框、按钮等控件测试 文本框的测试 如何对文本框进行测试 a,输入正常的字母或数字。 b,输入已存在的文件的名称; c,输入超长字符。例如在“名称”框中输入超过允许边界个数的字符,假设最多255个字符,尝试输入 256个字符,检查程序能否正确处理; d,输入默认值,空白,空格; e,若只允许输入字母,尝试输入数字;反之;尝试输入字母; f,利用复制,粘贴等操作强制输入程序不允许的输入数据; g,输入特殊字符集,例如,NUL及等; h,输入超过文本框长度的字符或文本,检查所输入的内容是否正常显示; i,输入不符合格式的数据,检查程序是否正常校验,如,程序要求输入年月日格式为 yy/mm/dd,实际输入yyyy/mm/dd,程序应该给出错误提示 在测试过程中所用到的测试方法: 1,输入非法数据; 2,输入默认值; 3,输入特殊字符集; 4,输入使缓冲区溢出的数据; 5,输入相同的文件名; 命令按钮控件的测试 a,点击按钮正确响应操作。如,单击确定,正确执行操作;单击取消,退出窗口; b,对非法的输入或操作给出足够的提示说明,如,输入月工作天数为32时,单击”确定“后系统应提示:天数不能大于31; c,对可能造成数据无法恢复的操作必须给出确认信息,给用户放弃选择的机会; 单选按钮控件的测试 a,一组单选按钮不能同时选中,只能选中一个。

软件模块测试用例说明书模板

软件模块测试用例说明书 编制:李洪强 审核: 会签:

批准:

修订记录

目录 1 简介 (5) 1.1 编写目的和范围 (5) 1.2 背景 (5) 1.2.1 术语 (5) 1.2.2 概述 (5) 2 测试环境 (5) 3 测试方法 (5) 3.1 测试框架设计 (5) 3.1.1 架构图 (5) 3.1.2 重要的时序图 (5) 3.1.3 模块接口1 (5) 3.1.4 模块接口2 (6) 3.2 桩模块1设计 (6) 3.2.1 模块功能 (6) 3.2.2 设计类图 (6) 3.2.3 内部时序图 (6) 3.2.4 进程设计 (6) 3.3 桩模块2设计 (6) 3.4 驱动模块1设计 (6) 3.4.1 模块功能 (6) 3.4.2 设计类图 (6) 3.4.3 内部时序图 (6) 3.4.4 进程设计 (6) 3.5 驱动模块2设计 (7) 4 功能测试用例 (7) 4.1 A功能测试用例 (7) 4.1.1 功能描述 (7)

4.1.2 测试目的 (7) 4.1.3 前提条件 (7) 4.1.4 测试输入 (7) 4.1.5 期望结果 (7) 4.2 B功能测试用例 (7) 5 异常测试用例 (7) 5.1 异常测试用例C (7) 5.1.1 测试目的 (7) 5.1.2 前提条件 (7) 5.1.3 测试输入 (7) 5.1.4 期望结果 (7) 5.2 异常测试用例D (8) 6 极限测试用例 (8) 6.1 极限测试用例E (8) 6.1.1 规格描述 (8) 6.1.2 测试目的 (8) 6.1.3 前提条件 (8) 6.1.4 测试输入 (8) 6.1.5 期望结果 (8) 6.2 极限测试用例F (8) 7 遗留问题 (8) 8 参考资料 (8)

如何设计和执行测试用例

如何设计和执行测试用 例 Pleasure Group Office【T985AB-B866SYT-B182C-BS682T-STT18】

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

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

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

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

完整测试用例设计参考

1、登陆 ①用户名和密码都符合要求(格式上的要求) ②用户名和密码都不符合要求(格式上的要求) ③用户名符合要求,密码不符合要求(格式上的要求) ④密码符合要求,用户名不符合要求(格式上的要求) ⑤用户名或密码为空 ⑥数据库中不存在的用户名,不存在的密码 ⑦数据库中存在的用户名,错误的密码 ⑧数据库中不存在的用户名,存在的密码 ⑨输入的数据前存在空格 ⑩输入正确的用户名密码以后按[enter]是否能登陆 11、是否支持table键? 12、密码是否加密显示? 2、添加 ①要添加的数据项均合理,检查数据库中是否添加了相应的数据 ②留出一个必填数据为空,应该每一个必填项都尝试一次; ③按照边界值等价类设计测试用例的原则设计其他输入项的测试用例 ④不符合要求的地方要有错误提示 ⑤是否支持table键 ⑥按enter是否能保存 ⑦若提示不能保存,也要察看数据库里是否多了一条数据 8、检查取消保存时,也要察看数据库里是否多了一条数据 3、删除 ①删除一个数据库中存在的数据,然后查看数据库中是否删除 ②支持多个同时删除的,要检查删除数据后,数据库中是否被删除; ③什么数据都不选择,直接点删除按钮,检查是否有错误提示; 4、查询 精确查询: ①输入的查询条件为数据库中存在的数据,看是否能正确地查出相应得数据 ②输入正确的查询条件以前加上空格,看是否能正确地查出相应的数据 ③输入格式或范围不符合要求的数据,看是否有错误提示 ④输入数据库中不存在的数据 ⑤不输入任何数据 ⑥是否支持table键 ⑦是否支持enter键 模糊查询: 在精确查询的基础上加上以下一点

①输入一些字符,看是否能查出数据库中所有的相关信息 设计功能和界面测试用例 1.1 文本框、按钮等控件测试 1.1.1 文本框的测试 如何对文本框进行测试 a,输入正常的字母或数字。 b,输入已存在的文件的名称; c,输入超长字符。例如在“名称”框中输入超过允许边界个数的字符,假设最多255个字符,尝试输入 256个字符,检查程序能否正确处理; d,输入默认值,空白,空格; e,若只允许输入字母,尝试输入数字;反之;尝试输入字母; f,利用复制,粘贴等操作强制输入程序不允许的输入数据; g,输入特殊字符集,例如,NUL及\n等; h,输入超过文本框长度的字符或文本,检查所输入的内容是否正常显示; i,输入不符合格式的数据,检查程序是否正常校验,如,程序要求输入年月日格式为yy/mm/dd,实际输入yyyy/mm/dd,程序应该给出错误提示 在测试过程中所用到的测试方法: 1,输入非法数据; 2,输入默认值; 3,输入特殊字符集; 4,输入使缓冲区溢出的数据; 5,输入相同的文件名; 命令按钮控件的测试 测试方法: a,点击按钮正确响应操作。如,单击确定,正确执行操作;单击取消,退出窗口; b,对非法的输入或操作给出足够的提示说明,如,输入月工作天数为32时,单击”确定“后系统应提示:天数不能大于31; c,对可能造成数据无法恢复的操作必须给出确认信息,给用户放弃选择的机会; 单选按钮控件的测试 测试方法: a,一组单选按钮不能同时选中,只能选中一个。 b,逐一执行每个单选按钮的功能。分别选择了“男”“女”后,保存到数据库的数据应该相应的分别为“男”“女”; c,一组执行同一功能的单选按钮在初始状态时必须有一个被默认选中,不能同时为空; 控件文本框的测试 测试方法: a,直接输入数字或用上下箭头控制,如,在“数目”中直接输入10,或者单击向上的箭头,使数目变为10; b,利用上下箭头控制数字的自动循环,如,当最多数字为253时,单击向上箭头,数目自动变为1;反之亦适用;

登录、注册功能的测试用例设计说明

注册、登陆测试用例 一、注册测试用例 测试编号:001 测试目标:验证系统是否对必填项为空时做出正确的响应 测试环境:windows XP 操作系统和浏览器IE6.0 测试步骤: (1):打开浏览器,在浏览器的地址栏中输入“用户注册”页面的URL , 单击 【转到】按钮; (2):在“用户注册”界面什么都没有输入,直接单击【注册】按钮; 期望结果:注册失败,页面重新回到注册页面,并提示“请输入必填项”。 测试编号:002 测试目标:验证系统是否对用户名含义非法字符时做出正确的响应 测试环境:windows XP 操作系统和浏览器IE6.0 测试步骤: (1):打开浏览器,在浏览器的地址栏中输入“用户注册”页面的URL , 单击【转到】按钮; (2):在“用户名”文本框输入“a0755*87”; (3):在“密码”文本框输入:1314; (4):在“确认密码”文本框输入:1314; (5):在“地址”文本框输入:790705390@qq.; (6):单击【注册】按钮; 期望结果:注册失败,页面重新回到注册页面,并提示“用户名含义非法字符”。 测试编号:003

测试目标:验证系统是否对密码不一致时做出正确的响应 测试环境:windows XP操作系统和浏览器IE6.0 测试步骤: (1):打开浏览器,在浏览器的地址栏中输入“用户注册”页面的URL,单击【转到】按钮;(2):在“用户名”文本框输入“a075587”; (3):在“密码”文本框输入:1314; (4):在“确认密码”文本框输入:1315; (5):在“地址”文本框输入:790705390@qq.; (6):单击【注册】按钮; 期望结果:注册失败,页面重新回到注册页面,并提示“两次输入密码不一致”。 测试编号:004 测试目标:验证系统是否对密码含有非法字符时做出正确的响应 测试环境:windows XP操作系统和浏览器IE6.0 测试步骤: (1):打开浏览器,在浏览器的地址栏中输入“用户注册”页面的URL,单击【转到】按钮;(2):在“用户名”文本框输入“a075587”; (3):在“密码”文本框输入:1314*24; (4):在“确认密码”文本框输入:1314*24; (5):在“地址”文本框输入:790705390@qq.; (6):单击【注册】按钮; 期望结果:注册失败,页面重新回到注册页面,并提示“密码含有非法字符”。 测试编号:005 测试目标:验证系统是否对格式不正确时做出正确的响应 测试环境:windows XP操作系统和浏览器IE6.0 测试步骤: (1):打开浏览器,在浏览器的地址栏中输入“用户注册”页面的URL,单击【转到】按钮;(2):在“用户名”文本框输入“a075587”; (3):在“密码”文本框输入:1314; (4):在“确认密码”文本框输入:1314; (5):在“地址”文本框输入:790705390qq.; (6):单击【注册】按钮; 期望结果:注册失败,页面重新回到注册页面,并提示“地址格式有错误”。 测试编号:006 测试目标:验证系统是否对用户名重复时做出正确的响应 测试环境:windows XP操作系统和浏览器IE6.0 测试步骤: (1):打开浏览器,在浏览器的地址栏中输入“用户注册”页面的URL,单击【转到】按钮;(2):在“用户名”文本框输入“a075587”;

手机黑盒测试介绍

手机黑盒测试介绍 手机黑盒测试介绍软件测试 黑盒测试(black—box testing)又称功能测试、数据驱动测试或基于规范的测试。用这种方法进行测试时,被测程序被当作看不见内部的黑盒。在完全不考虑程序内部结构和内部特性的情况下,测试者仅依据程序功能的需求规范考虑确定测试用例和推断测试结果的正确性。因此黑盒测试是从用户观点出发的测试,黑盒测试直观的想法就是既然程序被规定做某些事,那我们就看看它是不是在任何情况下都做的对。完整的“任何情况”是无法验证的,为此黑盒测试也有一套产生测试用例的方法,以产生有限的测试用例而覆盖足够多的“任何情况”。由于黑盒测试不需要了解程序内部结构,所以许多高层的测试如确认测试、系统测试、验收测试都采用黑盒测试。 黑盒测试首先是程序通常的功能性测试。要求: 每个软件特性必须被一个测试用例或一个被认可的异常所覆盖。 用数据类型和数据值的最小集测试。 用一系列真实的数据类型和数据值运行,测试超负荷、饱和及其他“最坏情况”的结果; 用假想的数据类型和数据值运行,测试排斥不规则输入的能力; 对影响性能的关键模块,如基本算法、应测试单元性能(包括精度、时间、容量等)。 不仅要考核“程序是否做了该做的?”还要考察“程序是否没做不该做的2”同时还要考察程序在其他一些情况下是否正常。这些情况包括数据类型和数

据值的异常等等。下述几种方法:(a)等价类划分,(b)因果图方法,(c)边值分析法,(d)猜错法,(e)随机数法,就是从更广泛的角度来进行黑盒测试。每一个方法都力图能涵盖更多的“任何情况”,但又各有长处,综合使用这些方法,会得到一个较好的测试用例集。 1.等价类划分 等价类划分是一种典型的黑盒测试方法。等价类是指某个输入域的集合。它表示对揭露程序中的错误来说,集合中的每个输入条件是等效的。因此我们只要在一个集合中选取一个测试数据即可。等价类划分的办法是把程序的输入域划分成若干等价类,然后从每个部分中选取少数代表性数据当作测试用例。这样就可使用少数测试用例检验程序在一大类情况下的反映。 在考虑等价类时,应该注意区别以下两种不同的情况: 有效等价类:有效等价类指的是对程序的规范是有意义的、合理的输入数据所构成的集合。在具体问题中,有效等价类可以是一个,也可以是多个。 无效等价类:无效等价类指对程序的规范是不合理的或无意义的输入数据所构成的集合。对于具体的问题,无效等价类至少应有一个,也可能有多个。 确定等价类有以下几条原则: 如果输入条件规定了取值范围或值的个数,则可确定一个有效等价类和两个无效等价类。例如,程序的规范中提到的输入条包括“……项数可以从1到999……”,则可取有效等价类为“l考项数<999”,无效等价类为“项数999”。 输入条件规定了输入值的集合,或是规定了“必须如何”的条件,则可确定一个有效等价类和一个无效等价类。如某程序涉及标识符,其输入条件规定“标

蓝牙功能测试用例

江苏东大集成电路系统工程技术有限公司 蓝牙功能测试用例 测试内容 设置名称 其他设备可以发现我 蓝牙设置 属性 允许其他设备来连接 新增 修改 删除 载入 电话簿 拨打电话(在已经与蓝牙手机建立连接的前提下) 已接电话列表是否正确(时间,排列顺序等) 删除 删除全部 加入电话本 已接电话 拨打选中电话 (在已经与蓝牙手机建立连接的前提下) 已拨电话列表是否正确(时间,排列顺序等) 删除 删除全部 加入电话本 已拨电话 拨打选中电话 (在已经与蓝牙手机建立连接的前提下) 未接电话列表是否正确(时间,排列顺序等) 删除 删除全部 加入电话本 通话记录 未接电话 拨打选中电话(在已经与蓝牙手机建立连接的前提下)拨打最近的拨出电话 快速连接(与上一次连接的蓝牙设备建立连接) 连接过蓝牙设备列表是否正确 建立连接 断开连接 蓝牙快捷方式 删除蓝牙设备、多个篮牙快速删除不可有死机现象 列表是否正确 活动的连接 断开连接 关闭 关闭蓝牙功能 恢复(从主界面再次进入蓝牙管理器即可恢复) 搜索蓝牙设备 搜索服务 基本功能测试 蓝牙管理器(具体的见 handfree,handset ) 配对(建立,取消)

删除蓝牙设备 建立连接 断开连接 是否能搜索到该蓝牙设备 是否能够建立配对(取消) 搜索该蓝牙设备的服务 是否能够连接(建立,断开) 删除蓝牙设备 拨打电话 挂断电话 通话过程中手机端强制断开链接不能出现系统无声等 异常 接听电话 增加音量,减小音量,静音 通话在免提设备和蓝牙手机之间的切换 杂音 通话质量 回声 handfree Nokia 5200 SonyErisson K510C HP ipAQ hw6500 (PDA phone) 。。。。。。 通话过程中使用输入键盘 是否能搜索到该蓝牙设备 是否能够建立配对(取消) 搜索该蓝牙设备的服务 是否能够连接(建立,断开) 删除蓝牙设备 听音乐正常 蓝牙棒配对进入headhset audio Gateway 能听到电脑上所有声音后,此时将设备挂断或退出,机器功能(如 播放MP3,触摸屏等)是否正常 挂断电话 接听电话 调节音量 杂音 Handset 蓝牙棒, SonyErisson908 通话质量 回声 Form No.:PE40009 Rev.:A