有天我饿坏了,下课后狂奔食堂,一进门就猛地撞上校花,
就听她气急败坏说道:“你有病啊?”
我就幽幽地回击:“你有药吗?”
校花更生气了:“你有精神病啊?!”
我不动声色冷冷地说:“你能治吗?”
校花慌了:“你神经病啊!你神经病啊!你神经病啊!”
我再乘胜追击:“你复读机啊!”
四、功能测试
在工作的过程中,接触了敏捷流程,在敏捷的学习过程中,了解到了一些新的概念,比如Story、头脑风暴、产品backlog、迭代backlog、迭代计划会议、每日站立会议、可视化管理、迭代验收、测试驱动开发、极限编程、持续集成、Anatomy、迭代开发、Story分析、Story用例设计、Story实现、Story验收、资料开发、资料设计等等。具体可以查看我的个人博客笔记,记录了在学习敏捷流程过程中的一些笔记,具体有如下三个主要链接点:
敏捷基本概念之总预览
“http://www.51testing.com/index.php?uid-450992-action-viewspace-itemid-248557”
敏捷项目流程之总预览
“http://www.51testing.com/index.php?uid-450992-action-viewspace-itemid-249346”
项目敏捷模版之总预览
“http://www.51testing.com/index.php?uid-450992-action-viewspace-itemid-831635”
下面是我个人在做功能测试时总结的主要步骤:
1、 需求分析:在新的需求下来之后,测试人员与开发、资料、系统架构师等等相关人员一起学习熟悉新的需求并参与作出评审;
2、 系统设计:由系统架构师对整个软件新需求做出系统设计,测试人员参与评审、并对整个概要设计存在疑问的地方进行批注并提出自己的意见和见解;
3、 简单设计:系统架构师完成简单设计以后,开发人员可以根据自己的每个Story或者特性完成一些简单的设计,用来交流,每个简单设计,相关特性或Story的测试人员都必须参加评审并提出自己的意见和见解(在敏捷流程下每个开发PO都对应了一个或多个测试PO,这是多对多的关系,就是说每个功能模块都能找到相应的开发和测试负责人);
4、 测试计划与测试方案:测试计划主要由主管编写,然后测试人员参与评审就可以了;测试方案由系统测试工程师编写,完成之后参与评审(小弟是菜鸟,功能测试的测试计划和测试方案虽然大致模版都知道也晓得知道该写些什么,但是实在是没有在该项目组里实战过,这里简单带过,可以看我写的性能测试方案里)
5、 Story用例设计:用例设计主要是将原始需求、设计需求、概要设计、简单设计的内容进行归纳分析,采用组网分析法、业务流程分析法等分析出测试点,为后续Story用例实现提供一个测试点大纲;
6、 Story用例实现:根据用例设计的结果编写用例,写用例的几大要素大家都知道吧,用例编号、用例标题、重要级别、预置条件、操作步骤、预期结果、所属模块、对应Story;其中有两点给我印象最深,其一就是用例中的文字描述,主管说了一句“中国文化博大精深,用例的措词方面难免存在一些问题,如果你测试过程中发现了,修改一下”,其二就是操作步骤和预期结果中添加check标记,在操作步骤中有些地方设置有检查点就在前面加一个[check1],然后再预期结果里同样写一个[check1],这样就可以很清楚地知道检查点在哪里了。比如:
操作步骤:
A.输入正确的用户名;
B.输入正确的密码;
C.单击登录按钮,[check1]检查是否登录成功。
预期结果:
A.[check1]登录成功。
7、 Story验收:每个Story完成之后,都必须根据Story验收标准进行验收,如果验收的过程中存在问题,可以按照简易流程提单<测试人员直接提给相应的Story的开发人员>并协助开发定位问题,最后输出Story验收结果;
8、 迭代验收:每个迭代完成之后,都需要做一个迭代的综合测试,在测试的过程中需要按标准流程提单<测试人员提单、测试经理审核、开发经理分配、开发人员修改、测试人员回归、关闭等环节>并协助开发定位问题,最终输出迭代验收测试报告;
9、 系统验收:多个迭代版本完成之后(每个迭代中都有多个Story),就可以进行系统验收测试,系统验收的过程中需要按照标准流程提单<测试人员提单、测试经理审核、开发经理分配、开发人员修改、测试人员回归、关闭等环节>并协助开发解决,最后输出系统测试报告以及整体的系统的DI值,如果DI值在指定范围内,那么就可以直接把该软件发布了。
10、 系统发布:系统发布以后,如果在网上出现问题,还必须立即在研发地重现该问题,然后协助开发一起定位解决,为网上打个补丁包或者在下一轮迭代中完成该功能。
功能测试总结:功能测试的过程中,项目组中采用的是敏捷流程,结合用例设计方法中的流程分析法、等价类、边界值、因果图、错误推测法等等,用例设计方法之前就有学习,这次是把他们都应用到实战里面了,理论笔记也记录在个人博客笔记里了:
测试用例设计方法之拥挤设计方法分类
“http://www.51testing.com/index.php?uid-450992-action-viewspace-itemid-248154”
五、兼容性测试
一方面是前端兼容性测试,由于做的是安防行业,做编码器、解码器的厂家比较多,所以我们的视频监控平台必须对接多个厂家,这样才能在市场上立于不败之地(不管客户选什么前段设备,我们的平台都可以对接进来,这样听起来多牛叉的),平台总共最新的兼容性列表里包括了300多型号的摄像机可以对接到我们平台,因为这个原因,我参加过前端兼容性测试(其实兼容性测试的主要工作是由一个MM完成的,她好厉害的,抓包分析、定位解决都能做,所以我只能说我参加过兼容性测试),主要工作就是将多个厂家的多个型号的摄像机对接到我们平台里,验证一些基本功能是否完善,如果存在问题,就询问厂家或者我们这边的指定SDK对接开发人员,协助帮忙定位解决问题。
另外一方面是PC平台兼容性测试,平台采用的是B/S架构的,因此兼容性测试还要包括Windows XP、Windows 7以及IE6、IE8、IE9),测试过WindowsXP+IE6、WindowsXP+IE8、Windows 7+IE8、Windows7+IE9、这几个PC平台是用户用的比较多的,所以当时做兼容性测试的时候测试的较多。
兼容性测试总结:兼容性对接的过程中,主要问题是要测试多个设备、多种平台,就是说有时候平台上的一个功能点,你必须测试N次,因为有N个型号的前端设备要对接过来,而且每个设备都要能够成功正确地对接好,是不是觉得工作很重复很重复呀?(其实好重复呀,我刚开始接手的时候把我都惹火了,差点罢工,嘿嘿,不要被我主管看到这文章,否则我要被批的),兼容性对我来说主要的感觉就是要细心,耐心去做,就可以了。
六、界面测试
界面测试一般是融合在功能测试里面一起做的,如果存在界面上的问题,可以提一个建议性问题单,就可以搞定了,这里不详述了。
七、故障恢复测试
故障恢复测试也是融合在功能测试里面,如果存在故障恢复的问题,可以提个严重或者知名问题单。主要是模拟可能出现的故障,看软件能否手动或者自动恢复到最后正确的某个状态,因为视频监控行业里的有些信息是很重要的(比如说银行金库里的金条被盗走了,而那一段时间的录像刚好没了,那必定是一种非常致命的问题),所以故障恢复是很重要的,必须尽量模拟一切可能出现的故障,然后看软件是否有能力恢复。当时主要测试了如下几种:
A.双盘系统中单盘毁坏的故障(可以恢复)
B.单盘系统中单盘毁坏的故障,是否可以根据关键数据备份恢复回来(可以恢复)
C.RAID5中热备盘毁坏的故障(对RAID组无影响,可恢复)
D.RAID5中除了热备盘以外单个数据盘毁坏的故障(RAID组降级,可读可写,可恢复)
E. RAID5中除了热背叛以外双个数据盘毁坏的故障(RAID组只读,可读无法写,可恢复)
F. RAID6中热备盘毁坏的故障(对RAID组无影响,可恢复)
G.RAID6中除了热备盘以外单个数据盘毁坏的故障(RAID组降级,可读可写,可恢复)
H.RAID6中除了热备盘以外双个数据盘毁坏的故障(RAID组降级,可读可写,可恢复)
I. RAID6中除了热备盘以外三个数据盘毁坏的故障(RAID组只读,可读无法写,可恢复)
J. 断网的故障
K. 断电的故障
除了以上这些故障以外,还有一些其他的一些故障,这里就不罗列了。
零测试