收藏本站 收藏本站
积木网首页 - 技术学院 - 软件测试 - 网站黄页 - 常用手册 - 站长工具 - 技术社区
软件测试 > 其它测试技术 > 正文

首页 | 领域细分: 游戏测试 安全测试 手机测试 Web测试 | 技术研究: 单元测试 入门教程 用例设计 性能测试 功能测试 | 测试职场: 面试精选 职场发展 面试试题

测试管理: 配置及流程 - 需求管理 - 质量验收 - 缺陷管理 - 其它管理相关 | 开发语言: PHP技巧 - PHP基础 - PHP实例 - PHP错误代码

测试工具: LoadRunner JiRa QuickTestPro RoBot WinRunner TestDirector 其它测试工具 | 数据库: Mysql数据库 Oracle数据库 CSS/DIV基础 HTML基础

如何防止少量的代码修改导致的全用例测试

来源:互联网 日期:2014-09-08 13:52

  一个关于移动的项目,现在做了快两年了,项目越来越大,其中有的表数据加上历史数据都到10亿级别,由于这两年团队成员流动大,导致代码越来臃肿,前期项目代码的管理不善,除了较大的版本,一般的小修小改都不经过代码评审,本地测试通过后,直接hotfix,有时候很顺利,但是偶尔导致较大问题,有时候甚至影响客户使用,导致公司亏损。现在领导发现问题就直接骂工程部,导致现在每当有一点点修改,工程部都要求AQ按照测试用进行全用例测试,测试非常的不易,光是功能测试几乎5个测试人员一天时间,还要兼容几乎所有浏览器(ie6~8,火狐,遨游,TT,360,google,搜狗)。工作量巨大。没办法现在我们的做法如下:

  1、加强代码的版本控制,对每次代码的修改,都直接联系到个人,代码的修改都要写修改说明,包括:修改内容,修改前效果,修改后效果,对其他接口或功能的影响,回滚策略,测试用例

  2、代码评审:代码评审的标准我们也在不断修改完善,过一段时都会对评审标准进行评审。评审前参会人员都会拿到上一步相关人员写的修改说明,会前2小时阅读,会中,有相关人员对代码进行流程讲解,并进行效果演示,评审内容包括,代码评审(是否符合代码评审标准),效果评审(是否达到产品需求效果),用例评审(是否可以覆盖当前修改),回滚评审(出错后是否可以及时的回滚到前一版本)。

  3、总结每期评审结果,必要时间进行讨论,提出问题:包括项目中遇到的难题,和大家对评审的看法,总结经验,并对公认的技术问题进行归类,由对此熟悉的人员(架构师,开发经理,个人)在周一进行技术讲解(我们是每月2次的技术培训,没有公共话题的情况下,如果有人想分享个人经验的话,可提前准备,现在为了鼓励大家,根据培训效果,对培训讲解人是有偿的,奖励多少不公开,会中很活跃,一般不会刻意打断你,除非公共话题,这一点我是比较喜欢,每天都会去翻大量的文章,书籍去了解话题)。

  4、和绩效挂钩,这一点大家都不喜欢啊,不过没办法,领导意思,每次上线都搞得心里惶惶的。

  这些工作我们做了半年,也是有成效,有时候评审会叫上工程部的人来看,工程部也承认我们的工作,也不怎么要求全用例了,但是好多都慢慢形式化,包括评审,主要还是有时候项目特别紧,大家都加班加点干项目,为了上线,项目都改了好几个版本,还没评审一次,结果可想而知。有时候也想过自动化测试,但是离开了人为的控制任然问题多多啊,主要是自动化测试这方便经验不足。

  不知道大家在开发大型项目的过程中,都是如何保证产品质量的,主要是如何在项目比较将紧的情况下防止全用例测试,不要说你们每次修改都全用例测试,都是绿灯才上线,全用例测试对我们来说那简直是要命啦,也不要说刚招聘的一个新人他写的代码你就放心不用测试评审。

  我个人认为是可以避免少量修改导致的全用例测试的,主要的问题就是修改带出来的新问题,如何防止修改老问题带出新问题,个人认为有以下因素导致:人的积极性,人的责任心,人的上进心。人的积极性需要领导层共同解决,如何在紧张的项目下给员工舒适的环境和心情,人的责任心和上进心是就是自己的素养,不管多么没意思的工作你是否愿意去做好,还有就是你是否愿意提高你的技能来防止这些问题。但是这每一点都不是嘴上说说就能做好的。

本周排行

别人正在浏览

强悍的草根IT技术社区,这里应该有您想要的! 友情链接:b2b电子商务
Copyright © 2010 Gimoo.Net. All Rights Rreserved  京ICP备05050695号