qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

web手工测试的经验总结

 前言

  本文主要是阐述个人的web手工黑盒测试工作经验

  测试目的

  测试并不仅仅是为了找出错误,通过分析错误产生的原因和错误的分布特征,可以帮助项目管理者(开发人员)发现当前所采用的软件过程的缺陷,以便改进;从而提高软件的质量,更体现了测试的重要性。

  工作经历

  1、工作环境介绍

  09年3月刚入职,也是项目初建阶段,项目组6个人在一个小房间,5台台式机1个人用笔记本(领导);2张桌子比较挤,工作的地方是比较简陋;刚开始熟悉需求,然后是和同事一起部署项目,不过就是看看表结构,学习下怎么把数据入库Oralce数据库,后台Oracle存储过程开发,在前台配置业务指标配置展现,给用户做个什么小需求等等,都是琐碎的事。不过项目初建比较累,加班较多,事情也多,大概到8、9月份才开始正常上下班。 10年过完年大概3月份左右吧,二期的项目要测试(公司给我们项目组划了一片办公地方,挺好的),项目组人手不够,老大让我转测试,问我同不同意,我想了想自己的工作内容比较杂,专注一件事情也是好事,就同意了!开始真正的测试工作。

  然后老大从别个项目组调了一个有测试经理级别的人,过来协助测试,我跟着他学习了一点东西。比如测试用例的撰写,用户验收UAT用例和测试报告的输出。记得他说过做测试要细心,提出的bug要跟踪,注意页面的美观性,按钮、字体大小、字体颜色,风格要保存一致等,虽然他教的少,不过还是挺感谢滴!

  二期项目上线之后,测试工作告一段落,我又恢复了以前的工作,没有了测试工作就做业务需求开发写写Oracle存储过程,前台配置展现,维护下测试环境和线上的环境等等。

  做了测试之后感觉自己挺喜欢这行滴,因为工作的事情比较杂想学不到什么东西,个人想专注测试,2011年动摇了要离职的念头,不过老大找我谈了好几次话,也主动给我加了工资,就留下了,遇到这种老大,挺不容易的,对我们组员很好。

  11年项目三期测试;输出测试策略,按照计划的时候输出相应的文档,比如测试用例的输出,然后全员参加用例评审(开发、测试和PM),会上提出用例的不足或者、与需求不符或者不完善的地方;修改了之后发送PM,通过后执行测试。测试的时候每天晚上邮件反馈当天的工作进度,采用迭代测试的形式测试,测试环境我自己维护,一轮测试完成后,开发把bug修复完成,在提供一个发布包,然后验证,没有新bug产生后,就输出一份系统测试报告和缺陷报告(针对开发人员)。如果客户要求做压力测试,需要输出一个压力测试方案(包括场景、测试模块、测试环境等),当然方案也要评审,评审通过后开始LoadRunner压力测试,测试完成后输出压力测试报告。然后是一个用户验收UAT测试用例的输出。最后上线完成。并输出一个上线总结文件!

  在工作期间带了3个新同事,Ta们3个都不同,也许是刚开始接触测试,慢慢的成长!有一个女同事很…..我给她定了个学习系统和业务的计划,人家自己不做反而在那里看开发的代码,问她的时候她也总是没问题,偷懒很严重,如果她不是女生就和老大说不用她了……

  介绍下以前公司的测试流程:

  ……………………

  查看全文请点击下载:http://www.51testing.com/html/76/n-844176.html

  2.4 数据验证

  1)前后台数据一致 : 前台正确录入信息保存后,后台数据库相对应的表正常记录(与前台输入一致)

  比如:注册一个用户信息提交成功后,用户表users中是否正常保存了当前的录入信息。

  2)存储过程验证:oracle F8编译通过,F8执行后 对应的数据表正常录入数据,无锁表现象(当目标表B表从另外一长表A表取值,当A表数据过大时要借助临时表,避免死锁、耗费资源的现象)

  2.5 根据开发习惯找错误

  1)同一个开发人员开发的模块,在不同的模块犯了错误,其他的模块也有类似的错误

  比如A开发人员 主要负责用户、权限模块,在测试用户模块时发现用户名可以重复,现象用户名重复: 注册了两个相同的帐号,但是用户状态不同,一个是不可用状态,一个是可用状态,但是登录的时候两个都不能登录,提示“帐号不可用”。然后再去验证权限模块,角色名称也可以重复,看似小问题,但对于用户来说可能就是大问题了,因为正常状态的用户不能登录。所以开发人员的习惯也是不能忽视的!

  2.6 LR压力测试

  选择好录制协议,录制脚本,根据需要添加 事物和集合点 ,使用参数化,设置runtime-setting ,在场景执行的时候 注意观察主机CPU和内存使用率。

  个人观点

  1)立项前的需求分析很重要,与开发人员的沟通也很重要;对需求理解程度越深,对开发的思想理解越透彻,撰写的测试用例就越全面,漏测的几率也会减少。

  2)关注用户的需求,注重细节,尽可能找出系统中隐藏的缺陷。

  3)总结测试过程中发现的问题,做好漏测记录,避免相同的错误发生。

  查看全文请点击下载:http://www.51testing.com/html/76/n-844176.html

  本文收录于《51测试天地》电子杂志第二十九期。

  版权声明:本文出自51Testing软件测试网电子杂志——《51测试天地》第二十九期。51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权,未经明确的书面许可,任何人或单位不得对本网站内容复制、转载或进行镜像,否则将追究法律责任。

posted on 2013-04-23 09:58 顺其自然EVO 阅读(388) 评论(0)  编辑  收藏 所属分类: 测试学习专栏


只有注册用户登录后才能发表评论。


网站导航:
 
<2013年4月>
31123456
78910111213
14151617181920
21222324252627
2829301234
567891011

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜