web手工测试的经验总结-阿里云开发者社区

开发者社区> 数据库> 正文

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)总结测试过程中发现的问题,做好漏测记录,避免相同的错误发生。







最新内容请见作者的GitHub页:http://qaseven.github.io/

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
数据库
使用钉钉扫一扫加入圈子
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

其他文章