软件测试经验分享

上传人:自*** 文档编号:52517232 上传时间:2018-08-22 格式:PPT 页数:27 大小:394.60KB
返回 下载 相关 举报
软件测试经验分享_第1页
第1页 / 共27页
软件测试经验分享_第2页
第2页 / 共27页
软件测试经验分享_第3页
第3页 / 共27页
软件测试经验分享_第4页
第4页 / 共27页
软件测试经验分享_第5页
第5页 / 共27页
点击查看更多>>
资源描述

《软件测试经验分享》由会员分享,可在线阅读,更多相关《软件测试经验分享(27页珍藏版)》请在金锄头文库上搜索。

1、软件测试经验分享,,1.上份工作的概述,我2012年毕业开始一直是从事测试工作, 对于测试的理解 就是保证产品的质量,按时交付产品。 上一份工作的主要内容是测试一个数据卡 和App 。上网卡它主要是一个usb dongle 。和我们的U 盘形状有点类似 如下图,使用USB作为总线接口,同时也设计有一个保护USB的专用盖帽。它有自动安装功能,将它插到电脑上会自动弹出一个安装的光盘,将软件安装好以后 就可以使用,它主要用在Windows 和Mac上面 。主要的功能就是 拨号上网、发短信、也有一些辅助的功能如 打电话、搜网、设置profile 、流量统计、在线升级、声音的设置等,1.上份工作的概述,

2、我们的app主要是用来控制我们的Y800 的,Y800如下图,Y800设备里插上sim卡然后通过转包转换成wifi 的形式 ,相当于一个移动wifi 设备。最多可以连接10个人。 App 的测试环境包括Android和ios(iPhone 和ipad),手机连上Y800,然后打开app 可以用来 拨号上网 、发短信、设置上网时间、设置使用流量、自动断开、流量提醒。,2.学到的东西-负责测试一个项目的流程,2.1开工 2.2测试组的会议 2.3写Test Plan 2.4写测试设计和测试用例 2.5启动测试 2.6写质量日报 2.7Test Report 2.8测试过程中需要注意的点,2.学到的

3、东西-负责测试一个项目的流程,2.1开工 首先是有软件项目经理组织会议讨论软件的需求 ,参与的人员有开发测试和scm, 需求讨论完成后分工指派开发负责人和测试负责人 ,并将具体的模块分给开发 。开发负责人评估开发时间,确定日期,测试负责人评估测试时间,确定日期。作为一名测试人员从这次会议里我们就知道了: (1)测试需求文档(开会前软件项目经理也会提前发给我们) (2)开发的参与人员,各自负责的模块,等到测试的时候碰到bug 可以直接找他们 (3)测试的时间 。,2.学到的东西-负责测试一个项目的流程,2.2测试组的会议 如果这个项目有我作为测试负责人 ,我就要在开工后及时的组织测试组的会议,比

4、如2013年12月1号开工,我们最好也当天开个会。主要是讨论下测试模块的分配,要在开发的这段时间内把测试用例写好。2.3写Test Plan 开完测试组的会议以后作为测试负责人 就要写个Test plan 的文档 ,文档的内容要包含 编写的目的、模块的分配、写测试设计的时间、 Pre-alpha 、alpha 、beta 版本的时间节点、测试资源的申请 (如数据卡、sim卡)、测试环境、各个版本的发版准则 等2.4写测试设计和测试用例 根据开会讨论后的分配 每个人负责自己的模块 ,要写一下测试设计 和测试用例。 然后发出来互相review,2.学到的东西-负责测试一个项目的流程,2.5启动测试

5、 当开发完成大部分功能以后 就要启动测试 开始daily build(每日构建)每日构建的标准就是这个软件能够安装 重要的功能已经实现。不会crash 可以跑起来。因为我们都是有时间点的 所以可以在测试的头一天把测试邮件给准备好,新的修改点加到项目管理系统里面(项目管理系统是我们添加项目管理项目和提bug的地方)2.6写质量日报 开始daily build 以后我们就开始测试了,作为测试负责人要在每天下班前发送质量日报 给相关的人。 质量日报的内容 主要是描述下现在有多少个P0、P1、P2 的bug ,一共的bug 、今天提交的bug 已经今天closed 和总共close bug 以及bug

6、 的趋势图,2.学到的东西-负责测试一个项目的流程,2.7Test Report 当一个项目完成了一个里程碑要发测试报告 ,比如说我们完成了alpha 版本的测试 就要在完成的那天发下测试报告,让大家知道这个进度,如果在发版本的前一天 还有一些P0 的bug 没有解决,要发邮件提醒开发 。测试报告主要 包括 软件的基本信息、修改点的验证。质量情况,是否满足发版标准、遗留的一些严重问题 和所有bug 的bug 列表。2.8测试过程中需要注意的点 作为测试负责人 要经常和开发和软件项目经理沟通,问一下项目进展的状况,有没有需求变更是自己不知道的,测试的时候碰到一些不概率性的网问题最好保留现场 把开

7、发叫过来看看。发邮件的时候要注意检查下写的内容是否正确 尤其是日期。,3.学到的东西-测试设计和测试用例的编写,软件测试中最重要的因素是设计和生成有效的测试用例。无论软件测试进行的如何具有创造性、如何完全,也不能保证软件中不存在任何错误在测试的过程中我们依赖的就是我们的测试设计和测试用例了。在写测试用例的时候我们一定要看需求文档 ,根据需求来写测试用例,由于测试时间的限制我们就要提高测试的效率,可以使用一些有价值的测试方法如 等价类划分、边界值。错误推断等。我们当时写测试用例相对简单些 ,dashboard产品是我们部门一直在做的,所以可以参考以前的一些case ,然后优化下。当我们在测试过程

8、中碰到一些新的问题市可以写把这些case 加到 我们的测试用例里面 ,app对于我们起步较晚是从2013年8月左右开始做的,不过功能和dashboard有类似的地方,我们就参考以前的测试用例还有上网搜集些资料 ,如去百度文库 和51testing 网站去看下,还有就是互相找些资料分享下去写测试设计 和case。 在我的工作中90%的是黑盒测试,10%的是白盒测试。对于黑盒测试,黑盒测试不需要去关注软件的整体架构及其编码细则,只需要通过构造一些合理的输入(操作),来观察软件的实际结果或现象(输出),从而判定是否存在问题,需求文档是黑盒测试的主要依据。在测试中主要用到的测试方法有 等价类划分、边界

9、值分析、因果图分析、错误测试。对于等价类划分设计测试用例主要有两 个步骤:(1)确定等价类 (2)生成测试用例。 举个例子,一条中文短信可输入67个字 ,那么它的有效等价类就是 167 ,其中1和67就是边界值。当我们测试的时候 1和67之间的数字都是等价的,我们可以挑一个测试就可以了。对于边界值我们要测下1 和67 ,还要测试下无效的等价类,看看有没有对他们做限制 。,3.学到的东西-测试设计和测试用例的编写,因果图是一种形式语音,用自然语言描述的规格说明可以转换为因果图。因果图实际上是一种数字逻辑电路,确定其中的因果关系。举个例子 ,比如我选择2g manual 搜网,注册成功后界面上就应

10、该显示2g ,显示3g就是错的。 还有 比如说我pin码上锁了,这个时候去发短信就应该是失败的,如果还能发送成功就是错误的。 错误猜测主要是一项依赖 于直觉的非正规的过程,其基本思想是列举可能犯得错误或错误易发情况。比如我们测试dashboard的版本时 ,有好几个版本都在mac电脑上都会出现安装后卸载再次安装失败的情况,还有app测试的时候set monthly data plan 不生效 ,或者是发短信短信列表在ios上初始化不出来等问题。对于白盒测试 我主要是测试Y800的硬件,我们对于Y800的测试是用黑盒和白盒相结合的测试方法来测的。一开始我们的app 没有做好就先用python脚本

11、对它测试。测试的时候是在mac电脑上 ,通过wifi 连接Y800,将写好的脚本放到测试框架里面跑。跑完以后结果可以直接在框架里面看到。测试的目的是看看那些API 接口有没有实现。这些API 接口是开发定义的 ,是xml格式的 。一个api 接口是由request 和response 两部分组成的。里面有一些参数,response 里面会有一个判断返回是否正确的参数 errorcode.对于一些简单的case 我们可以直接看errorcode的值来判断case是否跑成功,如果errorcode=0则成功,若等于其它值就失败。我主要负责的是短信模块、较量值以及电池的状态,短信的接口有获得短信列表

12、、发送短信、获得短信发送的状态。短信列表里面短信的状态、删除短信、短信的条数、未读短信的条数。,3.学到的东西-测试设计和测试用例的编写,测试的时候我们一般是有预设条件的,就是说我们知道自己的期望结果,然后如果跑出来的和期望结果不一致 就说明错啦。接口和接口之间还有联系的我们可以在一个case里面调用其它case里面的方法 。只要写的时候按照框架的规范来就行。比如说我要删除短信,就首先要获得短信的列表然后再去删除。 在测试获得短信的发送状态的时候也是,发送的状态收sending、failed、success ,我们就要先调用发短信的接口如下:对于测试电池电量就要注意它的状态是否正确。总的来说白

13、盒测试也是按照我们的测试用例来写case 把他们变成python语音,去实现 用到的方法也是有等价类划分、边界值、压力测试。我觉得白盒测试做压力测试很好做,但是它测试的比较单一,一般都是一个模块一个模块的测试,有些交叉测试的写起来就比较复杂。UI上面的问题也测试不到。,4.学到的东西-系统测试概述,4.1功能测试 4.2健壮性测试 4.3矩阵测试 4.4UI测试 4.5兼容性测试(IOT) 4.6性能测试 4.7临界测试 4.8可靠性测试,4.学到的东西-系统测试概述,4.1功能测试 这是软件测试工作中最核心和最基本的一项测试,该测试的主要内容是检查软件是否符合需求定义,并通过构造正常的操作来

14、检查软件的动作是否正确;在这个测试里,正确性是最最重要的软件质量要素。 软件功能按照可见性可以分为两类:显性功能和隐性功能。隐性功能就好像是地下党员,你在共产党员的花名册里永远找不到他们的名字。 显性功能:指在菜单里可以看得到的功能 隐性功能:指在菜单里看不到的功能 举个例子,电话本的显性功能有增加、编辑、删除、拨打等,这些功能可以在电话本的菜单里面看得到,姓名列表排序则属于一个隐性功能,因为在电话本的菜单里没有这样一个子菜单,但它却是一个实实在在的功能 在实际的测试过程中,显性功能通过菜单遍历可以很容易地进行无遗漏的测试,但是隐性功能却很容易为我们所忽略!一个有效的解决办法是去检查软件的功能

15、定义列表(Feature List),从这个列表里面找出那些隐性的功能。,4.学到的东西-系统测试概述,4.2健壮性测试 这项测试主要是检查软件对异常操作的容错能力,异常操作通常要考虑异常输入操作及异常条件两个方面 小时候看电影发现,日本鬼子往往一枪就over了,八路军打一枪顶多流几滴血,仍然能够冲锋陷阵,这说明八路军的健壮性比日本鬼子的健壮性要强 软件的很多功能的实现是有很多隐含的条件的,在健壮性测试中,要检查当这些条件不满足的时候软件的反应 我们举一个SMS的例子,当我们将一个3000条短信的文件放到数据卡里面然后重启dashboard crash。 橘生淮南为之橘,橘生淮北为之枳,这说明

16、橘的健壮性太差,4.学到的东西-系统测试概述,4.3矩阵测试矩阵测试是使软件处于一个特定的状态,然后构造一个异步事件,检查当这个异步事件发生时软件的性能 根据事件的来源,异步事件可以分为外部事件和内部事件 外部事件举例:SMS到达、来电呼入、非关机状态拔电池等 内部事件举例:低电告警、自动关机等,4.学到的东西-系统测试概述,4.4UI测试 这里主要测试软件的易用性、用户界面的友好性及美学性。 UI测试遵循的原则: 求美原则,检查在UI的布局里,各种要素是否能传达一种美感,布局是否合理,色彩是否合谐,”科技美学化“不是一句挂在墙上印在纸上的口号,而应该成为实实在在的行动 正确性原则 一致性原则,同样的一个功能的UI在不同的情景(scenario)所呈现的方式应该保持一致 普遍性原则,4.学到的东西-系统测试概述,4.5兼容性测试(IOT) 测试dashboard对不同地区SIM卡的兼容能力,这部分尤其在STK中表现的很突出,我们经常可以发现一些异地的SIM卡中的STK菜单中会有乱码,这就是兼容性不好造成的 测试dashboard 在不同的操作系统上是否都可以正常的使用,

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 高等教育 > 大学课件

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号