web手工测试的经验总结

前言

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

　　测试目的

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

　　工作经历

　　1、工作环境介绍

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

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

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

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

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

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

　　介绍下以前公司的测试流程&＃xff1a;

　　……………………

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

　　2.4 数据验证

　　1&＃xff09;前后台数据一致 &＃xff1a; 前台正确录入信息保存后&＃xff0c;后台数据库相对应的表正常记录&＃xff08;与前台输入一致&＃xff09;

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

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

　　2.5 根据开发习惯找错误

　　1&＃xff09;同一个开发人员开发的模块&＃xff0c;在不同的模块犯了错误&＃xff0c;其他的模块也有类似的错误

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

　　2.6 LR压力测试

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

　　个人观点

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

　　2&＃xff09;关注用户的需求&＃xff0c;注重细节&＃xff0c;尽可能找出系统中隐藏的缺陷。

　　3&＃xff09;总结测试过程中发现的问题&＃xff0c;做好漏测记录&＃xff0c;避免相同的错误发生。

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