web手工测试的经验总结.docVIP

  1. 1、本文档共3页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  5. 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  6. 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  7. 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  8. 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
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个都不同,也许是刚开始接触测试,慢慢的成长!有一个女同事很…..我给她定了个学习系统和业务的计划,人家自己不做反而在那里看开发的代码,问她的时候她也总是没问题,偷懒很严重,如果她不是女生就和老大说不用她了……   介绍下以前公司的测试流程:   ……………………   查看全文请点击下载:/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)关注用户的需求,注重细节,尽可能找出系统中隐藏的缺陷。

文档评论(0)

cuotian + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档