当前位置:文档之家› 手机基本功能测试方式

手机基本功能测试方式

手机基本功能测试方式
手机基本功能测试方式

手机基本功能测试

手机基本测试软件测试

关于手机软件测试的工具应用

手机软件测试是否也和以下联系起来:

漫谈人机界面测试

【正文】本文列数了软件黑盒测试过程中,在被测试软件中可能存在的常见软件问题。本文不会详细讨论基本的软件测试思想与常用技术,仅针对在软件黑盒测试过程中若干的问题做描述,并提供个人的参考测试意见与防范意见,希望可以为初学者提供些许帮助。

俗话说“人靠衣裳马靠鞍”,良好的外观往往能够吸引眼球,激发顾客(用户)的购买欲望,最终达成商业利益的实现。软件的设计亦如此,Window XP 在商业上的巨大成功很大一方面来自于它一改往日呆板,以突出“应用”的灰色界面,从“用户体验”角度来设计界面,使界面具有较大的亲和力。就目前的软件设计的发展趋势来说,良好的人机界面设计越来越受到系统分析、设计人员的重视。但是如何对设计的人机界面(包括帮助等)进行测试,给出客观、公正的评价,却鲜见于报端。本文试从共性分析和个性分析的角度,给出一些测试意见和原则,简单且易于上手。起到一个抛砖引玉的目的、以飨读者。

我们知道:“不立规矩无以成方圆”。在软件界面设计强调张扬个性的同时,我们不能忘记软件界面的设计先要讲求规矩-简洁、一致、易用,这是一切软件界面设计和测试的必循之道,是软件人机界面在突出自我时的群体定位。美观、规整的软件人机界面破除新用户

对软件的生疏感,使老用户更易于上手、充分重用已有使用经验,并尽量少犯错误。由此我们在对软件人机界面进行测试时(设计评审阶段和系统测试阶段结合进行),不妨从下列一些角度测试软件的人机界面。

一致性测试

一致性使软件人机界面的一个基本要求。目的是使用户在使用时,很快熟悉软件的操作环境,同时避免对相关软件操作发生理解歧义。这要求我们在进行测试时,需要判断软件的人机界面是否可以作为一个整体而存在。下面是进行一致性测试的一些参考意见:――提示的格式是否一致

――菜单的格式是否一致

――帮助的格式是否一致

――提示、菜单、帮助中的术语是否一致

――各个控件之间的对齐方式是否一致

――输入界面和输出界面在外观、布局、交互方式上是否一致

――命令语言的语法是否一致

――功能类似的相关界面是否在在外观、布局、交互方式上是否一致(比如商品代码检索和商品名称检索)

――存在同一产品族的时候,是否与其他产品在外观、布局、交互方式上是否一致(例:Office产品族)

――同一层次的文字在同一种提示场合(一般情况、突显、警告等)在文字大小、字体、颜色、对齐方式方面是否一致

――多个连续界面依次出现的情况下,界面的外观、操作方式是否一致(当然可能会有例外,比如操作结束的界面)

信息反馈测试

假设系统的使用者是一个初出茅庐的生手,你能指望她(他)在进行操作不出错吗?但这还不是问题的所在,问题的所在在于我们都会犯错误,我们都有自己不了解的东西。如何避免,这要求我们的人机界面有足够的输入检查和错误提示功能。通过信息反馈,用户得到出错提示或是任务完成的赞许之语。但有些不幸的是,我们很多系统都在此方面做的不尽人意。下面是这类测试的一些参考意见:

――系统是否接受客户的正确输入并做出提示(例:鼠标焦点跳转);

手机基本功能测试方式

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

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

功能测试用例说明书

功能测试用例说明书 功能测试用例说明书 作者 发布范围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.doczj.com/doc/073392514.html,技术支持,解答/// 1.4术语与缩略语 术语、缩略语 ST ? 解释系统测试, System Test ?

功能测试用例的设计

功能测试用例的设计 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.反应时间达到规范要求;

手机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. 登陆、添加、删除、查询模块是我们经常遇到的,这些模块的测试点该如何考虑 1)登陆 ①用户名和密码都符合要求(格式上的要求) ②用户名和密码都不符合要求(格式上的要求) ③用户名符合要求,密码不符合要求(格式上的要求) ④密码符合要求,用户名不符合要求(格式上的要求) ⑤用户名或密码为空 ⑥数据库中不存在的用户名,不存在的密码 ⑦数据库中存在的用户名,错误的密码 ⑧数据库中不存在的用户名,存在的密码 ⑨输入的数据前存在空格 ⑩输入正确的用户名密码以后按[enter]是否能登陆 ------------------------------------------------------------------------------------------------------ 2) 添加 ①要添加的数据项均合理,检查数据库中是否添加了相应的数据 ②留出一个必填数据为空

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

测试用例基本通用模板

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,一组单选按钮不能同时选中,只能选中一个。

手机黑盒测试介绍

手机黑盒测试介绍 手机黑盒测试介绍软件测试 黑盒测试(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

非常全面的手机测试流程(精)

非常全面的手机测试流程目录 1、基本通话 1.1 来电响铃时 1.1.1来电响铃时的接通操作…………………………………………………………… 1.1.2来电响铃结束操作………………………………………………………………… 1.1.3来电响铃过程中有效功能的按键操作(除接通、结束……………………… 1.1.4来电响铃时的无效按键操作……………………………………………………… 1.2 来电通话 1.2.1来电通话中的基本菜单操作(除挂机…………………………………………. 1.2.2通话中的功能键……………………………………………………………………. 1.2.3结束通话……………………………………………………………………………. 1.3 呼叫功能 1.3.1拨号呼出………………………………………………………………………….. 1.3.2结束呼叫响铃…………………………………………………………………….

1.3.3呼叫中的无效操作………………………………………………………………. 1.3.4主叫通话时功能操作……………………………………………………………. 1.3.5 结束主叫通话…………………………………………………………………… 1.4多方通话 1.4.1主叫多方通话……………………………………………………………………. 1.4.2被叫多方通话……………………………………………………………………. 2、通话设置 2.1 翻盖应答………………………………………………………………………………… 2.2 单键拨号………………………………………………………………………………… 2.3自动重拨…………………………………………………………………………………. 2.4 任意键应答……………………………………………………………………………… 2.5 呼叫等待…………………………………………………………………………………

功能测试用例的设计

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

3)因果图 4)将因果图转化为决策表

2. 在线购买,这时需要使用帐号密码登录,登录成功后,进行付钱交易,交易成功后,生成订购单,完成整个购物过程。使用场景法设计上述问题的测试用例。 1)确定基本流,及各项备选流 2)根据基本流和备选流来确定场景 3)对每一个场景生成相应的测试用例

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

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

一、等价类分析法 等价类划分方法针对手机状态大致可以归几个大类: 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. 默认原厂参数设定

测试用例之性能测试用例

测试用例之性能测试用例 注:本文摘自作者正在编写的《Web性能测试实战》一书,曾经在程序员杂志2004年第10期上发表过。 性能测试、压力测试、负载测试、强度测试、稳定性测试、健壮性测试、功能测试、接口测试……,这么多眼花缭乱的测试类型名称,估计很少有人能准确的区分并说出定义来,至于对应的测试用例如何编写和执行,就更不用说了。 如果问测试工程师测试用例如何编写,就象是问程序员如何编写代码得到的答案一样,每个人都会给出不同的编写方法,但实用的测试用例却象优秀的程序一样难以编写。 目前国内,测试工程师却时常要面对“已经延期几倍计划时间的项目”,测试用例如何发挥更大的作用,是一个迫切需要解决的问题。事实上,完全可以把测试用例看成是测试工程师编写的程序:这个“程序”是为了辅助测试工作的进行而开发的,目的是为了发现软件问题,同时“顺便”证明软件功能是否符合要求。 本文针对上面的问题,以设计性能测试用例为示范,讲解在企业实际工作中,如何有效划分测试种类和编写对应的测试用例,使测试工作更加合理、高效率的开展。 1测试种类和阶段 1.1 测试种类 对于测试种类的说法多种多样,最多的能达到30多种测试类型。而实际工作中很多测试是互相包含的。按照企业中实际工作需要,通常主要进行下面几种类型的测试:功能测试、健壮性测试、接口测试、强度测试、压力测试、性能测试、用户界面测试、可靠性测试、安装/反安装测试、文档测试。 下面介绍几种重要的测试种类及其测试的内容: 功能测试:功能测试主要针对产品需求说明书的测试,是验证功能是否否合需求,包括原定功能的检验、是否有冗余功能、遗漏功能。这类测试应由测试员做,这并不意味着程序员在发布前不必检查他们的代码能否工作,他们也需要进行基本功能的测试。 接口测试:程序员对各个模块进行系统联调的测试,包含程序内接口和程序外接口测试。这个测试,在单元测试阶段进行了一部分工作,而大部分都是在集成测试阶段完成的。由开发人员进行。 性能测试:在交替进行负荷和强迫测试时常用的术语。性能测试关注的是系统的整体。它和通常所说的强度、压力/负载测试测试有密切关系。所以压力和强度测试应该与性能测试一同进行。

手机app测试要点总结

对于产品的手机项目(应用软件),主要是进行系统测试。而针对手机应用软件的系统测试,我们通常从如下几个角度开展:功能模块测试,交叉事件测试,压力测试,容量测试,兼容性测试,易用性/用户体验测试等。 1、功能模块测试:首先应分析功能模块的功能项,测试每个功能项是否能够实现对应的功能。一般根据测试用例(Test Case)或软件本身的流程就可以完成基本功能测试(相对简单,故障也较容易发现、解决)。 2、交叉事件测试:又叫事件或冲突测试,是指一个功能正在执行过程中,同时另外一个事件或操作对该过程进行干扰的测试。例如通话过程中接收到短信或闹铃触发,应用软件运行过程中插拔充电器等。执行干扰的冲突事件不能导致应用软件异常、手机死机或花屏等严重问题。另外,还需要注意各交叉事件的优先级别,检验系统是否能依据各事件的优先级别依次进行处理。不能因执行优先级别高的事件而导致优先级较低的事件吊死。 交叉事件测试非常重要,一般能发现应用软件中一些潜在的问题。另外有中英文模式切换的手机要注意中英文模式切换后的功能实现存在的问题(这个主要针对手机应用软件支持语言自适应功能),这一点通常会被测试人员忽略。 3、压力测试:又叫边界值容错测试或极限负载测试。即测试过程中,已经达到某一软件功能的最大容量、边界值或最大的承载极限,仍然对其进行相关操作。例如连续进行短信的接收和发送,超过收件箱和SIM卡所能存储的最大条数,仍然进行短消息的接收或发送,以此来检测软件在超常态条件下的表现,进而评估用户能否接受。 对手机可以施加的压力测试类型主要有: ? 存储压力:由于手机采用的是栈式存储,所以当一个存储块满了之后,如果程序员不做相应处理或者处理不好的话,很容易造成其他存储区被擦除,从而在UI上出现问题(比如其他功能无法正常使用,出现异常)。 ? 边界压力:边界处理一直是程序员最容易忽略的地方。 ? 响应能力压力:有时候某个操作可能处理的时间很长,在处理期间如果测试者再不断地进行其他操作的话,很容易出现问题。 ? 网络流量压力:执行较大数据流量的功能的同时,再进行其他功能操作,使得网络流量始终处于很高的状态(如视频通话时再进行短信等其他功能操作),验证各功能是否依然能正常工作,是否存在因网络流量瓶颈而引起某功能异常。 压力测试用手工测试可能很繁锁,可以考虑自动化测试。遗憾的是,目前还没有较为大量使用的工具,一般都是由开发人员配合开发出的工具,或者高级的测试人员编写出的脚本。

功能测试用例

功能测试用例 1. 等价类划分 常见的软件测试面试题划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类. 2. 边界值分析法 边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误. 使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据. 3. 错误推测法 基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法. 错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易

发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结。还有, 输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例. 4. 因果图方法 前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图(逻辑模型). 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况. 5. 正交表分析法 有时候,可能因为大量的参数的组合而引起测试用例数量上的激增,同时,这些测试用例并没有明显的优先级上的差距,而测试人员又无法完成这么多数量的测试,就可以通过正交表来进行缩减一些用例,从而达到尽量少的用例覆盖尽量大的范围的可能性。 6. 场景分析方法 指根据用户场景来模拟用户的操作步骤,这个比较类似因果图,但是可能执行的深度和可行性更好。

APP测试基本流程以及APP测试要点

1APP 测试基本流程 1.1流程图不符 符合 仍然为测试环境 进入正式环境 Fail Pass 跟进接收版本 App 测试版本 送测规范 UI 测试:核对 rp/效果图 功能测试:核 对需求文档 兼容性测试、 性能压力测试 正式环境下测 试 后台订单统计测试报告里面需体 现出软件质量 分值 回 归 测 试

1.2测试周期 测试周期可按项目的开发周期来确定测试时间,一般测试时间为两三周(即15个工作日),根据项目情况以及版本质量可适当缩短或延长测试时间。 1.3测试资源 测试任务开始前,检查各项测试资源。 --产品功能需求文档; --产品原型图; --产品效果图; --测试设备; --其他。 1.4日报及产品上线报告 1)测试人员每天需对所测项目发送测试日报。(也就是我这边有邮件通知测试项目的时候一般均属于输出测试日报) 2)测试日报所包含的内容为: \\server\网站软件app等开发\产品测试部\测试知识区域\测试文档类模板\项目测试报告邮件输出模板.doc 4)不同版本测试报告输出 2App测试点 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)没有用户的允许,应用程序不能预先设定自动启动 5)卸载是否安全,其安装进去的文件是否全部卸载 6)卸载用户使用过程中产生的文件是否有提示 7)其修改的配置信息是否复原 8)卸载是否影响其他软件的功能 9)卸载应该移除所有的文件 2.1.3数据安全性 1)当将密码或其他的敏感数据输人到应用程序时,其不会被储存在设备中,同时密码也不会被解码 2)输人的密码将不以明文形式进行显示 3)密码,信用卡明细,或其他的敏感数据将不被储存在它们预输人的位置上 4)不同的应用程序的个人身份证或密码长度必需至少在4一8个数字长度之间 5)当应用程序处理信用卡明细,或其他的敏感数据时,不以明文形式将数据写到其它单独的文件或者临时文件中。以6)防止应用程序异常终止而又没有侧除它的临时文件,文件可能遭受人侵者的袭击,然后读取这些数据信息。 7)当将敏感数据输人到应用程序时,其不会被储存在设备中 8)备份应该加密,恢复数据应考虑恢复过程的异常通通中中等,数据恢复后再使用前应该经过校验 9)应用程序应考虑系统或者虚拟机器产生的用户提示信息或安全替告 10)应用程序不能忽略系统或者虚拟机器产生的用户提示信息或安全警告,更不能在安全警告显示前,,利用显示误导信息欺骗用户,应用程序不应该模拟进行安全警告误导用户11)在数据删除之前,应用程序应当通知用户或者应用程序提供一个“取消”命令的操作12)“取消”命令操作能够按照设计要求实现其功能 13)应用程序应当能够处理当不允许应用软件连接到个人信息管理的情况 14)当进行读或写用户信息操作时,应用程序将会向用户发送一个操作错误的提示信息15)在没有用户明确许可的前提下不损坏侧除个人信息管理应用程序中的任何内容Μ16)应用程序读和写数据正确。 17)应用程序应当有异常保护。 18)如果数据库中重要的数据正要被重写,应及时告知用户 19)能合理地处理出现的错误

Web性能测试用例编写及注意点

Web性能测试用例的编写及注意点 一、WEB 全面性能测试模型 Web 性能测试模型提出的主要依据是:一种类型的性能测试可以在某些条件下转化成为另外一种类型的性能测试,这些类型的性能测试的实施是有着相似之处的; 1. 预期指标的性能测试 系统在需求分析和设计阶段都会提出一些性能指标,完成这些指标的相关的测试是性能测试的首要工作之一,这些指标主要诸于“系统可以支持并发用户200个;”系统响应时间不得超过20秒等,对这种预先承诺的性能要求,需要首先进行测实验证; 2. 独立业务性能测试 独立业务实际是指一些核心业务模块对应的业务,这些模块通常具有功能比较复杂,使用比较频繁,属于核心业务等特点。 用户并发测试是核心业务模块的重点测试内容,并发的主要内容是指模拟一定数量的用户同时使用某一核心的相同或者不同的功能,并且持续一段时间。对相同的功能进行并发测试分为两种类型,一类是在同一时刻进行完全一样的操作。另外一类是在同一时刻使用完全一样的功能。 3. 组合业务性能测试 通常不会所有的用户只使用一个或者几个核心业务模块,一个应用系统的每个功能模块都可能被使用到;所以WEB性能测试既要模拟多用户的相同操作,又要模拟多用户的不同操作;组合业务性能测试是最接近用户实际使用情况的测试,也是性能测试的核心内容。通常按照用户的实际使用人数比例来模拟各个模版的组合并发情况;组合性能测试是最能反映用户使用情况的测试往往和服务器性能测试结合起来,在通过工具模拟用户操作的同时,还通过测试工具的监控功能采集服务器的计数器信息进而全面分析系统瓶颈。 用户并发测试是组合业务性能测试的核心内容。组合并发的突出特点是根据用户使用系统的情况分成不同的用户组进行并发,每组的用户比例要根据实际情况来匹配; 4. 疲劳强度性能测试 疲劳强度测试是指在系统稳定运行的情况下,以一定的负载压力来长时间运行系统的测试,其主要目的是确定系统长时间处理较大业务量时的性能,通过疲劳强度测试基本可以判定系统运行一段时间后是否稳定; 5. 大数据量性能测试 一种是针对某些系统存储,传输,统计查询等业务进行大数据量时的性能测试,主要针对某些特殊的核心业务或者日常比较常用的组合业务的测试; 第二种是极限状态下的数据测试,主要是指系统数据量达到一定程度时,通过性能测试来评估系统的响应情况,测试的对象也是某些核心业务或者常用的组合业务。 第三种大数据量测试结合了前面两种的测试,两种测试同时运行产生较大数据量的系统性能测试; 大数据量测试通常在投产环境下进行,并独立出来和疲劳强度测试放在一起,在整个性能测试的后期进行;大数据量的测试可以理解为特定条件下的核心业务或者组合业务测试; 6. 网络性能测试 主要是为了准确展示带宽,延迟,负载和端口的变化是如何影响用户的响应时间的,在实际的软件工程中 主要是测试应用系统的用户数目与网络带宽的关系。网络测试的任务通常由系统集成人员完成;

相关主题
文本预览
相关文档 最新文档