注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

zhangxj105 的博客

 
 
 

日志

 
 
 
 

测试在项目开发中的位置和对其期望  

2012-06-07 15:55:30|  分类: 工作 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

今天开会讨论的主题是讨论测试存在的必要性? 这个问题虽然大家讨论了一些,但是并未有什么特别明显的成果讨论出来.

下午有空,仔细的思索了一下这方面的问题. 回顾下我进公司这几年的测试发展史. 最初由于是互联网公司, 人员规模很少, 代码更新的频率也很快, 测试几乎就是走个过程, 那时的测试基本就是全手工的劳作, 偶尔记得在第一个项目中,看到一个测试同学开发了一个检查各种输入,自动判断输出的工具,觉得很惊讶. 那时候整体工作代码的质量并不高, 但是整个合作的气氛却非常好,测试开发之间的关系是很和谐的.

之后的一年中我休假,回来后公司扩张很严重, 突然发现项目中对于项目质量的要求高了起来, 不仅有上线后的bug要求, 还对测试过程的质量提出要求, 也多了一步测试策略和测试分析的评审,似乎测试更专业起来, 但高要求的测试使得整个项目的整体周期加长, 严重的甚至资源占比达到2:1; 测试为2, 开发工程师为1的情况. 测试资源一度成为瓶颈. 而线上的质量却并未提升多少, 测试和开发的关系非常的对立.

之后为了提升效率,对开发自测的要求提高, 首创了冒烟测试的形式,对于开发的内容进行验收. 随之大力的推行单元测试, 集成测试. 到最近整个测试和开发的占比是1:3,日趋合理.

在这变更史中发现, 测试人员和开发人员一样是项目中不可或缺的项目角色. 因为一个独立的测试组的目标是作为第三方、能够从全局出发、验证和确认软件功能的质量。而开发人员趋向于证明系统是正常工作的。一个好的测试者会倾向于"假设"某些场景的出现,再加上业务用户的测试,则确保系统满足预期目的将变得容易. 测试中除了白盒测试,和黑盒测试外还包含如下的一些测试:

集成测试 - "我需要运行哪些测试来确保新的代码与其关联的代码有效地工作在一起?"

系统测试 - "新的代码在系统层面的功能是够正确,与其他系统工作在一起的流程是否正确?"

回归测试 - "我需要隔多久运行一次回归测试来确保新的代码没有造成非预期的影响?"自动化的回归测试为敏捷开发提供了一张安全网。

用户验收测试 - "TDD不仅需要确保某项功能正确地工作了,还要确保它们对于业务用户来说是可接受的。"

在我们公司中, 测试主要是几种在回归测试和用户验收测试, 用户验收测试中也包含压力测试. 在这样的情况下, 对测试的期望是如何的呢? 做为开发和用户的桥梁, 期望测试能够对测试的业务和场景穷尽和熟悉. 在过去的几年中一直期望开发同学能够建立产品文档,通过开发同学去构建产品文档总是避免不了从系统角度讲述逻辑; 而测试同学在多年的测试用例构建中是能够把握产品的主要脉络, 是最能直接穷尽业务场景的角色.

第二点是测试通过测试专业度提高, 能够为开发输送良好的测试工具和测试平台, 让绝大步数的场景能够自动化测试起来;

第三点对于复杂的,自动化测试无法覆盖的业务,测试能够手工验证使用场景的正确性.

如此测试的职责和意义是重大的.

参考文献: 破解敏捷测试的10大神话http://tech.it168.com/a2009/0629/597/000000597017.shtml

  评论这张
 
阅读(68)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017