迁移类测试的一点总结

发表于:2009-11-19 16:15

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:yaoguang    来源:Taobao QA Team

  前一段时间做了个,由于服务器原因不的不迁移应用的日常,想做点小结。有关历史数据迁移,偶记得在前篇已经有人在这里分析了很多,清楚有条的展现了测试中的问题和解决的方案。而自己所接触到得几乎是“功能”的迁移,数据上并没有多好的迁移。

  测试伊始-茫然无从:一个需求不是很明确,PD、开发、测试人员都不了解业务的一次突然行动。伊始,开发提供的一份清单:关于迁移影响的服务器可能影响到得功能点URL地址,没有具体的说明,没有应用的说明。

  紧急措施-漫天撒网:依据清单,对照MM图的业务逻辑狠命得的对照、补漏,发现有很多其它的应用中引用到的模块,清单中没有提及,于是,见一个收一个,一个一个得补充,最终成型一份比较完整的清单。但是不得不说的是,等到TC已经写完了,还有发现有小小遗漏点。因为应用本身的逐渐没落,无人维护,所以在具体的确认过程中总是有点周折,耗费时力。

  测试过程-东碰西撞:挑挑拣拣的测试模式,让自己在组织上磕磕碰碰。整理完清单,虽然已经是对于业务有个明确的框架认识了,只保留有用的部分,其余砍掉了,有时候,就只要去测一个引用小java程序,你去跑下,看看参数是否正确,这几乎完全忽略嵌入到具体应用的展现。某种意义上,这种方式让人很迷茫,因为原本的目的是要验证嵌入应用是否正确的,不是程序本身逻辑和参数,这至少不是功能测试的方式。解决疑惑的方式,就是自已又去和开发确认和搜寻了具体的应用,当然耗费了很多时间。

  测试结束-走出迷宫:一个过程总是有一个结果。测试完成了,迁移结束了,业务也已经深入的了解了,感觉再去看,有种“豁然开朗”的感觉。

  在整个的完成过程一个最深的感触是:业务逻辑-确认需求-总结清单-确认功能。一句话,如果不清楚需求不了解范围,就只能确认总结,再确认再总结,穷尽的不仅仅是自己的疑惑。

100家互联网大公司java笔试题汇总,填问卷领取~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号