软件测试经验
一、你们以往做系统测试时的测试流程是怎样的?
搭建参考环境 熟悉需求与业务逻辑 1天
写测试计划(评审) 1天
写测试方案 1天
写测试用例 N天
执行 N天
项目总结 1天
二、测试过程中你是否搭建过测试环境?能否描述一下搭的什么环境?如何搭的?
1、环境:Linux(redhat4)、Apache、MySQL、PHP
步骤1:安装linux系统
步骤2:对linux系统做一些配置:设置IP地址,创建用户,创建文件系统
步骤3:上传安装源文件(ftp)
步骤4: 安装Apache (编绎安装)
步骤5:安装mysql(rpm安装)
步骤6: 安装php(编绎安装)
步骤7:部署sugar版本(检查环境和权限,连接数据库,安装实例sugarCRM)
备注:
Linux常用的一些操作:
1、目录操作(mkdir, rm -R, cd, pwd,mv,cp,ls,ls -al, ls -lrt)
2、权限操作(chmod, chgrp, chown)
3、系统管理(shutdown -r now, shutdown -h now, reboot,useradd, su - 用户名)
4、进程与资源管理(ps -aux, free, top, vmstat, iostat)
5、文件查看和编辑(cat,vi,tail,tail -f,more,less )
6、压缩,安装类(rpm -ivh, rpm -e,rpm -qa查询已安装的rpm包,tar xvf,tar cvf,unzip,gunzip,gzip)
7、磁盘(du -ms(ks), df, mount/umount)
8、find, grep,linux日志结构
三、需求分析阶段主要做什么事情?有好的需求是否要做需求管理?如何做好需求管理?
需求分析阶段:分析测试需求,评审需求,可测试性需求
需要做好需求管理,怎么做:做好需求跟踪。
四、如果我们项目中没有需求文档,应该怎么做好测试工作?
1、搭建一个历史版本的环境,以便了解业务流程
2、开发的概设,详设,与需求类似的讨论(会议纪要),用户使用指南,产品介绍
3、与项目组有经验的员工交流
4、参考友商的类似的项目(文档)
5、项目内部组织业务培训
五、测试计划应该包括哪些内容?
描述被测对象,测试的范围,测试组织结构,测试通过/失败的标准,测试挂起和恢复的条件,
测试的任务安排,人员和时间规划,各个任务的输入和输出,输入输出标准,风险和规避措施
六、测试通过的标准是什么?
1、需求100%覆盖;
2、测试用例100%执行并通过;
3、所有缺陷都修改完成并回归测试通过
不严格:
1、需求100%覆盖;
2、中高级用例100%测试并通过,低优先级的用例60%以上测试并通过;
3、遗留的缺陷密度小于0.05/KLOC
七、项目中主要有哪些风险?如何规避?
1、测试过程中人员变动;
2、需求变动频繁;
3、开发延迟转测试;
4、版本上线日期提前;
5、测试人员技能;
6、设备或工具损坏(不能及时到位)
规避:加班,从其它组抽调人员,招聘补充人员;
做好需求跟踪,前期需求分析和需求评审工作做好
提前做好开发进度跟踪,改变测试策略
做好技能培训,以老带新,做好评审
提前准备好备份的方案,测试环境最好提供备份环境,环境需要专人维护,提前约定好工具到位时间
八、如何评估工作量?
1、从测试用例规模上评估工作量
2、从软件的规模上评估工作量
九、测试方案是什么?主要包括哪些内容?
测试方案描述测试对象,测试范围,测试的软硬件环境,测试策略,测试组网结构,测试用例设计方法和标准
测试工具的需求和设计,测试代码的需求和设计;
测试方案属于技术文档,主要解决如何测试的问题
新增(快速,完整),修改,删除,查找,导入,导出 快速新增- 快速新增-快速新增功能
十、能否举例说明你以前的项目是如何测试的?
新增:
快速新增,select子界面
快速新增:等价类,边界值
查询:
单项查询:1、每个单项条件能正确搜索,模糊查找,精确查找,通配符查找
组合查询:1、正交
2、判定表
3、逐项条件填加查询(1、全空 100项;2、增加一个输入条件,使查询结果减少 80 3、再增加一个输入条件,使查询结果在原来基础上减少一直到所有查询条件都输入为止 4、最后改动查询条件,使查询结果为0
修改:
等价类,边界值
删除:
选中一个(第一个,最后一个)
选中多个(连续的,不连续的)
不选
全选
多页(3页以上)
删除时取消
导出:
导入:流程分析法,等价类,边界值
测试用例中应该避免的问题:
1、在写用例的输入数据和步骤描述上,应该和业务比较接近
2、在用例细分的颗粒度上要考虑业务场景,需要把握好细分的度
3、在用例中对于一些无关紧要的输入项,可以用一句话代替;
4、优先级需要分类,大致H级的在20%左右,L级的20%左右,大部分是M级的
5、尽量避免用例与用例之间的依赖性,要体现低藕合度的特点
select子页面的新增:
1、所有的项都输入,能创建成功
2、只填必填项,非必填项为空
3、必填项为空
4、创建同名的
十一、测试执行主要做哪些事情?
开发到转测试时间点,把版本包(开发的安装包,用户安装指南,用户使用指南,维护指南,版本配套表
代码规模,转测试建议)
SVN:创建转测试目录 B011
B012
B013
同时,开发经理会通知测试经理(转测试版本已经放在SVN上面,可以取版本测试),项目经理,SQA都会收到类似邮件
1、测试组长:
转测试版本检查该转的项目版本包和文档是否齐全?是否有问题。
在测试组内分本具体的测试任务(搭环境,各个测试工程师负责测试的模块,分配测试用例)
并给出测试时间安排,交付时间,注意事项等
2、环境管理员:
到SVN上面取版本,搭建测试环境,并将测试环境链接发给所有测试人员
在测试执行过程,维护环境
3、测试工程师:
按照组长分配的任务,执行测试,记录测试结果
提交测试缺陷单
第一轮测试完成,提交测试小结(描述测试对象,测试时间,人力,测试用例执行情况,缺陷情况)
隔几天时间转第二轮测试B012版本测试
用例选择策略(1、优先级高的;2、第一轮未通过,发现缺陷的;3、由于缺陷导致第一轮无法测试,阻塞的用例
4、由于第一轮的缺陷,修改代码,会影响到的模块的用例,第一轮测试已通过的)
输出第二轮测试小结
转第三轮测试,测试执行后输出测试报告(整体三轮测试的总结)
十二、缺陷管理流程是怎样的?
1、提出缺陷单(简要描述,版本号,希望修改日期,严重等级,重现步骤,实际结果,环境,初步定位的结论,截图)NEW
2、主管统一审核缺陷(直接close,重复,非问题),确定是问题,发给开发 assign to 开发
3、开发判断是否缺陷 置为open 修改完成以后置为fixed,指定给测试经理
4、测试经理分配fixed状态的缺陷给测试工程师回归测试 主管分配给测试工程师
5、回归通过 closed,不通过 open状态
十三、如果你提交的问题,开发不认可,你会怎么处理?
1,自己先分析确认一下,是否问题,你的理由是什么,严重级别
如果是无关紧要的问题,而且开发很忙,可以暂时挂起。
如果不是无关紧要的问题,可以和开发当在沟通(把开叫到电脑前,重现问题,说明对系统的影响)j,开发可能接受该问题
如果开发当面沟通不接受,该问题必须修改,则求助测试组长来决策(邮件形式讲清楚这个问题现象,对系统的影响,发送给开发人员,抄送测试经理,开发经理)
十四、测试过程中你有没有发现缺陷,能否举例说明几个印象较深的缺陷?
1、删除的数据,在数据库中没有实际删除掉,只是将一个deleted标志字段置为1
2、新增一个商业机会记录时,会增加多个同样名称的记录(商业机会),记录数与user数量一致;
3、修改客户反馈信息时,如果把客户反馈相关联的客户名称(很重要字段)改成不存在的客户时,可以修改成功。
4、不修改信息时,可以正常导出,但如果将要导出的信息中的assign to 的字段置空,则导出时整个记录为空
5、在创建系统中存在同名的客户信息时,应该要给出提示
6、选择不连续的几个记录删除时,会将选中的第一条和最后一条之间的所有记录都删除
十五、回归测试版本的用例选取的策略是什么?
1、未通过的,未执行,阻塞的
2、由于开发修改了问题而影响到的模块的相关测试用例(前面执行通过的)
3、把优先级高的H级的用例做回归测试
十六、测试报告主要包括哪些内容?
测试报告描述测试对象(从架构,开发语言,功能,前景等角度),测试对象的版本,测试的时间人力安排,测试软硬件环境
测试用例情况(测试用例数量,用例密度,稳定性,执行情况),测试版本质量(缺陷数,严重程度,缺陷密度)
测试结论,遗留问题列表。
十七、你们项目当中有没有做得好的地方?有没有做得不好的地方?好在哪里?不好在哪里?
好的:
测试流程比较清晰,各个阶段交付件也齐全,各个交付件会经过评审并归档;
分工明确,配合协调,组长写测试计划,做数据分析,进度,协调;老员工写方案,写用例;新员工写用例,执行
相互之间沟通很顺畅,开发,测试相互配合比较好
不好的:
用例数写得太少;
开发提供的版本质量太差,低级问题很多;
用例写得不好(数据不好构造)
需求不够明确
十八、BS与CS架构的区别,测试的侧重点分别是什么?
BS是浏览器/服务器架构,CS是客户端/服务器模式
BS:使用方便,不需要安装客户端,只需要有浏览器就可使用;安全性较CS低(用在互联网,客户端与服务器端安全协作性没有CS高
有些安全要求很高的场景需要单独安装插件 ),性能较低
测试侧重点:
浏览器兼容性测试,插件的测试(安装,功能)
服务器的性能测试
CS:安全性较BS高(适用专用网,局域网范围,客户端和服务器端安全协作性高)
性能较BS
测试侧重点:
1、客户端的安装测试,卸载,升级测试,升级回滚
2、客户端的功能测试
十九、什么是兼容性测试?兼容性测试的重点是什么?
二十、提交缺陷单时,应包括哪些内容?
标题,缺陷编号,模块,时间,严重程度,详细描述(问题重现步骤,预期结果与实际结果),附件(截图或日志),问题初步分析
作用:1、记录缺陷,以免遗漏
2、便于测试开发之间的缺陷管理与信息传递
3、缺陷统计与缺陷管理
二十一、如何定义缺陷严重级别?
致命:直接导致软件不能正常使用(挂起,异常退出,死机,核心功能都不能使用)
严重:影响范围,主要功能受影响,(缺陷影响不严重,但是范围很广),影响范围不广,但影响了主要功能
一般:只影响非核心功能的缺陷,影响范围也不大
建议:能正常使用,提示信息,界面因素相关的问题;一些优化建议类的点,其本身不是缺陷
IEEE 国际电子电气工程师协会 International Electronic Electric Engneer
需求的来源:
1、市场调查(调查问卷、用户访谈)
2、竞争对手
3、内部讨论
4、技术的发展
项目级的需求:有固定客户(显性需求、隐性需求)
需求分析:1、通过显性需求挖掘背后的隐性需求
2、将显性需求和隐性需求规格化,并记录下来,形成SRS
规格化:1、定义它的规格和单位 2、性能规格 3、接口的定义 4、可靠性(其它质量特性)
基线化:形成一个标准,给其它的工作提供参考(1、管控 权限管理;2、标识 版本号)
需求分析阶段(测试):1、分析测试需求,提出可测试性需求给开发人员
2、根据质量模型、功能交互、继承性分析等方法分析测试的测试需求
3、参与需求评审(开发、测试、SQA、配置管理员、用户代表)
项目管理是一个模块
项目
子项:新增,修改,删除,导入,导出,查询
1、新增
编号:
测试方法:
测试要点:
1、
2、
修改:
编号
测试方法
测试要点
项目任务
sugarCRM-ST-Accounts-copy
服务器端的兼容性:
linux redhat4
windows 2008 server
客户端:
IE
ff
google
项目实际常用的评审流程:
1、作者邀请评审人员评审作品,将作品发给相应的评审人员
评审的对象,评审完成时间,各个人员评审的重点
2、在评审时间结束前跟踪评审结果,将所有的评审结果汇总;
3、召开评审会议,确认所有的问题
4、作者修改问题
5、将修改后的作品发给所有评审人员,确认问题修改完成
3:00-5:00 评审完成
a%c 可以查找包括a c开头的
ac 可以查找ac开头
%ac
1、SVN管理员到服务器上面取测试版本 F:\项目\sugar\09 项目安装包\sugar\B011
2、环境管理员到SVN上面取版本,搭测试环境(windows系统)
半年(需求分析,概设,详设,代码,自测试)
( 测试需求分析,需求评审,测试计划,测试方案,测试用例,测试执行,UAT测试)
新增需求,更改的需求 =>需求人员,项目经理 规划版本计划(V1.0在开发阶段,V2.0开始规划,可以纳入新的需求)
需求
需求没写,但需要做(从易用性考虑)
个人: 日报 (工作计划,进展,建议,困难,需求助的地方)
周报:主管提交(测试组一周的工作计划和进展,下一周的工作计划,困难与求助)
双周报
月报
晨会,例会
敏捷开发(适合短平快的项目,需求变化快,版本周期短的项目,文档比较少,注重沟通)
大版本->小版本(迭代) 每个迭代的需求通过迭代会议确定 (设计,编码,测试)
用户故事(user story) 对用户故事进行测试
结对编程
预测试(冒烟测试):在大规模开展测试之前,抽取一部分功能进行测试,保证大规模测试可以
顺利进行,如果测试发现版本质量较差,则将版本打回给开发组,修改问题后再测试
从优先级为H级的用例当中抽取一部分来测试
必填项:assign to
1、界面上要打上必填的标签
2、如果新增时assign to 项为空,则不能新增成功,同时界面上给出提示信息
易用性:
GUI:按钮 (一类按钮写一个测试用例)
标题:测试account界面的按钮功能
步骤: 点击 的按钮
预期:select 按钮可以打开xx
clear按
布局:
易操作性:
测试快捷键
测试易用性,重点关注:布局,按钮功能,快捷键,尺寸,颜色
项目进度安排:
1年工作经验: 4000个用例 1000用例(写用例:1-1.5个月;执行(B011:1月 B012:15天; B013:1周 2个月))
需求评审,写计划,方案,用例,执行,评审;
熟悉需求,了解业务流程,评审1周,计划,方案1周 1个月
4-5个月参与到第一个版本
测试升级版本(每两个月出一个新版本:1、新增加功能,优化;修改以前的BUG
出定制版本:不同的客户定制不同的功能,)
需求评审,计划,(方案)用例,执行
第二个项目:
组织架构:研发:开发组,测试组; CRM 5人, SNS:3人 其它:财务管理软件 总人数 10人
40人
50人做研发
销售团队:15 技术支持:6 后勤: 6
等价类,边界值: 不考虑组合,重点考虑输入规则,不是考虑输入和输出关系的
注册,修改,删除,
判定表,因果图,正交:考虑组合,考虑输入和输出关系的,不同的组合产生不同的动作
登陆,查询,配置测试
流程分析法,状态迁移图:
测试流程(事件流)保证每个业务流程是正确(处理一笔业务需要很多步骤,不同的步骤之间有先后关系或依赖关系,有些步骤
有不同的选择,安装测试)
保证框架是对的,但是具体每个步骤的(创建,修改等)需要使用其它方法,如等价类
常规方法(7种)+非常规的方法(异常分析法,错误推测,探索性测试)
电子商务:
后台(卖家):商品管理(上架,修改,删除,导入,导出)
买家:
购物蓝管理:修改购物蓝信息,删除,查看,计算费用
购买管理:流程(选货物->付款->收货->安装->售后)
订单管理
压力测试:让系统长时间,大压力的情况下运行,测试系统的性能表现(响应时间,资源耗用),以及
系统在压力卸除以后的恢复情况(恢复速度,恢复程度)
性能测试:测试系统是否满足性能需求(业界标准)
负载测试:测试系统从较小的压力开始,逐步增加系统压力(并发量),在各个压力场景下的性能表现
(响应时间,资源耗用)
容量测试:测试系统可以容许的最大容量(最大并发量,数据库最大的处理能力,上传文件最大的大小,最大的速度)