ImageVerifierCode 换一换
格式:DOC , 页数:3 ,大小:29.50KB ,
资源ID:9461856      下载积分:10 金币
验证码下载
登录下载
邮箱/手机:
图形码:
验证码: 获取验证码
温馨提示:
支付成功后,系统会自动生成账号(用户名为邮箱或者手机号,密码是验证码),方便下次登录下载和查询订单;
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝    微信支付   
验证码:   换一换

开通VIP
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【https://www.zixin.com.cn/docdown/9461856.html】到电脑端继续下载(重复下载【60天内】不扣币)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录   QQ登录  

开通VIP折扣优惠下载文档

            查看会员权益                  [ 下载后找不到文档?]

填表反馈(24小时):  下载求助     关注领币    退款申请

开具发票请登录PC端进行申请。


权利声明

1、咨信平台为文档C2C交易模式,即用户上传的文档直接被用户下载,收益归上传人(含作者)所有;本站仅是提供信息存储空间和展示预览,仅对用户上传内容的表现方式做保护处理,对上载内容不做任何修改或编辑。所展示的作品文档包括内容和图片全部来源于网络用户和作者上传投稿,我们不确定上传用户享有完全著作权,根据《信息网络传播权保护条例》,如果侵犯了您的版权、权益或隐私,请联系我们,核实后会尽快下架及时删除,并可随时和客服了解处理情况,尊重保护知识产权我们共同努力。
2、文档的总页数、文档格式和文档大小以系统显示为准(内容中显示的页数不一定正确),网站客服只以系统显示的页数、文件格式、文档大小作为仲裁依据,个别因单元格分列造成显示页码不一将协商解决,平台无法对文档的真实性、完整性、权威性、准确性、专业性及其观点立场做任何保证或承诺,下载前须认真查看,确认无误后再购买,务必慎重购买;若有违法违纪将进行移交司法处理,若涉侵权平台将进行基本处罚并下架。
3、本站所有内容均由用户上传,付费前请自行鉴别,如您付费,意味着您已接受本站规则且自行承担风险,本站不进行额外附加服务,虚拟产品一经售出概不退款(未进行购买下载可退充值款),文档一经付费(服务费)、不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
4、如你看到网页展示的文档有www.zixin.com.cn水印,是因预览和防盗链等技术需要对页面进行转换压缩成图而已,我们并不对上传的文档进行任何编辑或修改,文档下载后都不会有水印标识(原文档上传前个别存留的除外),下载后原文更清晰;试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓;PPT和DOC文档可被视为“模板”,允许上传人保留章节、目录结构的情况下删减部份的内容;PDF文档不管是原文档转换或图片扫描而得,本站不作要求视为允许,下载前可先查看【教您几个在下载文档中可以更好的避免被坑】。
5、本文档所展示的图片、画像、字体、音乐的版权可能需版权方额外授权,请谨慎使用;网站提供的党政主题相关内容(国旗、国徽、党徽--等)目的在于配合国家政策宣传,仅限个人学习分享使用,禁止用于任何广告和商用目的。
6、文档遇到问题,请及时联系平台进行协调解决,联系【微信客服】、【QQ客服】,若有其他问题请点击或扫码反馈【服务填表】;文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“【版权申诉】”,意见反馈和侵权处理邮箱:1219186828@qq.com;也可以拔打客服电话:4009-655-100;投诉/维权电话:18658249818。

注意事项

本文(浅谈在软件开发中的开发与测试.doc)为本站上传会员【仙人****88】主动上传,咨信网仅是提供信息存储空间和展示预览,仅对用户上传内容的表现方式做保护处理,对上载内容不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知咨信网(发送邮件至1219186828@qq.com、拔打电话4009-655-100或【 微信客服】、【 QQ客服】),核实后会尽快下架及时删除,并可随时和客服了解处理情况,尊重保护知识产权我们共同努力。
温馨提示:如果因为网速或其他原因下载失败请重新下载,重复下载【60天内】不扣币。 服务填表

浅谈在软件开发中的开发与测试.doc

1、浅谈在软件开发中的开发与测试 发布时间: 2011-11-08 13:18    作者: softerwarer    来源: 51Testing软件测试网采编   我们知道开发人员与测试人员在某种程度上可以说是冤家对头,因为开发总是认为我做的产品是完美无缺的,没有Bug的,但是测试总是想方设法给你挑刺,因而产生了“矛盾”。很多公司对开发的绩效评估里就有一条是每千行代码产生的Bug量,当然是越少越好了,但是对于测试的绩效评估也有一条平均每天提交的Bug量,所以表明上看起来这种矛盾真的是无法避免的,因为大家都要“混饭”吃的。   但是大家其实心里都很清楚,一个产品不可能没有Bug的,或多或

2、少,或大或小,总是会有Bug存在,不然微软也不会这样经常发布补丁了,连微软这种级别的公司都会Bug,所以对于Bug的存在,我们大可以泰然处之。   虽然可以泰然处之,但是对于Bug我们还是需要很重视,因为既然产生Bug,总是某一方面没有想到或者是想错了,所以我是建议可以通过对Bug分布进行分析,找出哪些地方特别容易出Bug,然后在开发过程中特别注意。对于我们公司而言,之前说过了我们是用TechExcel DevSuite 系统来管理,所以我们在开发中会加入几个强制检查项,比如说是否兼容不同数据库,是否支持不同语言,是否考虑过不同浏览器,开发在完成代码如果不检查这几项的话,是无法把开发任务直接

3、交给测试来测的,这样就可以从某种程度上避免一些Bug的产生。   不过即使避免了总还是会有一些Bug会被找到的,呵呵,没有Bug还要测试干嘛呀?在很多公司里测试人员的数量都大于开发人员的,像微软这种公司,可能是2:1的关系,为什么需要这么多测试呢?   第一方面,当然是他们的产品太大了,太复杂了   第二方面,一个产品的质量光靠开发是不行的,因为开发虽然能把产品做出来,也可能可以用,但是他们可能没法考虑其他一些方面,比如用户体验上,比如压力测试上,比如不同语言下的应用,甚至是不同操作系统下的应用等等,这些方面光靠开发可能没法想全,甚至即使想全了也做了,你能保证在哪些环境就一定不出问题吗,

4、毕竟开发编程总是在一个环境下的编的,他编完即使自己测了一下也不可能把所有环境下都测过的。   第三方面,因为一个产品/一个功能需要在很多外在环境下测试(操作系统,数据库,浏览器,网络),另外一个功能需要测试点又很多(正常输入,非正常输入,临界,压力值等),所以即使是一个功能,需要测试的地方就很多,何况产品大功能多的了。而且,我们知道一个人再强,他能想到的测试点总是有限的,所以我还需要另外的人对一个已经测过的功能点进行再次验证测试 (关于这个方面,由于我们公司是用DevSuite 方案中的 DevTest 工具来管理测试覆盖面的,所以稍微可以减少一些测试人员配置)。另外对于一个开发来讲,由于功

5、能点是他做的,所以别人发现了问题让他修,其实他是可以修起来很快,代码都轻车熟路的,所以如果一个测试配一个开发的话,可能发现的Bug量无法让开发完全忙起来,从领导角度说这个比较浪费成本的。   所以考虑到这些原因,一般大公司就会有很多的测试人员了,当然现在的情况又有不少改变了,随着自动化测试的引入,需要人工的地方会相对减少,所以有不少公司开始减少纯手工测试的活,但是做过开发的人也知道,如果一个产品很复杂,光靠自动化测试是远远不够的,所以呢,我相信手工测试还会在很长时间内存在,至少在我能看到的范围呢,好像还没法用自动化测试来代替。   不过在国内的话,我接触到的大多数软件公司里,对测试人员的配

6、置都不太多,当然我不认为他们是忽视软件质量,他们可能认为功能做出来了,开发直接测一下就好了,测试人员的话只要最后综合跑一下就Ok了。我相信这个是怎么保证软件质量的一种认知的观念问题,我认为这样就可以保证产品质量,你认为那样才可以保证质量,大家各有说法,但是从我们公司的角度来说,我们还是比较看重质量的,可能也跟我们公司背景有关吧,外企,跟国外比较接轨。所以我们公司现在的开发与测试配置是大于1:1的,不过比微软还是差一点。   介绍了一下测试的必要性,再回过头来继续说开发与测试的“矛盾”,其实这个矛盾从本质上来说是由于绩效管理时过分强调了开发人员造成的Bug,而这个“过分强调”又必须是测试人员一

7、定要强调的。所以呢,矛盾就开始产生了,开发说,这个不是Bug,或者说我不能重现,还说,你干嘛老是提Bug,是不是对我有啥不满的。久而久之,“矛盾”产生了,激化了,产品质量下降了......   从领导层角度来说,他们当然也希望开发做出来产品是没有Bug的,这样子我连测试人员都不用配了,成本下降很多了。当然,大多数领导也知道这个是不可能的,与其由于产品质量下降造成产品不好卖,还不如配几个测试人员了。配了测试人员,又出现“矛盾”了,我想许多公司的领导已经处理得很好了,不过我还是想简单介绍一下我们公司的处理方案:   1、把产品的销售业绩与开发、测试绑定,也就是说销售得好,奖金就多,当然要销售得

8、好,产品质量也得好,那就得开发与测试相互合作了。现在许多公司其实开发与测试工资与奖金比较固定,不会因为业绩好而增加奖金之类的。我们公司有明确规定,这个产品利润的百分之几是归开发,百分之几归测试,从而从制度上就让开发与测试有了定心丸,去好好把产品质量搞好。   2、在对于各个销售人员的绩效考核上,增加其他考核项,把每千行Bug的产生量权重降低,增加诸如,Bug修复成功率,类似功能再次出现Bug的百分比,与测试人员合作效率等考核项,这样子的话,开发人员就会开始很重视和测试人员的交流,因为他们开始知道跟测试人员的合作好坏决定了他们能拿到的Money。(刚才有人问怎么拿到这些类似Bug 修复成功率这

9、种值,一般好一点的 Bug 管理工具里都能拿到,我们在 DevSuite 系统里自动生成的)   3、当然对测试人员也需要增加一些新的考核项,比如是Bug的描述是否能让开发一次看清楚等。   通过这些措施,开发与测试的效率提高很多,从而使得产品质量也提高很多。哲学上说,矛盾是事物发展的动力,学会利用这种矛盾来让公司健康稳健地发展是每个成功公司需要学会的,我们公司现在来说不能算特别成功,但是我们在这个方向上前进着。   后序:有个朋友评论说:(以下是原话)   软件测试部门是辅助软件开发部门将产品做好!   他们不是对立的关系,而是互相帮助的关系。   现实中,经常看到研发部门看不起

10、测试部门,而测试部门则叫板研发部门,说产品存在如何多的问题。。。   牢记产品是做出来的,不是测试出来!   测试团队一定要摆正自己的位置,是协助研发团队将产品做好,提高产品质量!发现问题,跟踪解决问题!一定不要将与研发人员的关系搞僵!   时刻牢记:大家是一个团队!大家有一个共同的目标:将产品做好!开发与测试应该认识到大家是一个团队,一个整体,只有紧密合作才能把产品做好出来。   其实大方向我还是比较认同的,确实,开发和测试需要紧密合作,发挥团队精神才能把产品做好,这样子产品才能有机会卖好,公司也才能发展,所以这个朋友评论的话,我觉得可以认为是一种理想的开发与测试关系。但是要实现这个理想的关系,光靠这两个部门自身是无法彻底实现的,我们需要在整个公司层面制定合理的制度,从根本上解决问题。假设我给开发的考核中代码质量(也就是每千行出得Bug数)权重很大,而给测试人员考核时每日发现Bug数权重很大,势必会造成开发与测试之间的某种矛盾加剧,其实他们也知道要合作,不能有矛盾,但是自己是出来打工的,你给我提这么多Bug,我钱就会少拿;我不给你提这么多Bug,我钱也少拿。 所以我写这篇文章的目的,其实是怎么让开发与测试达到一个理想的关系,而不是说开发与测试应该达到一个怎么样的关系。 转载地址:

移动网页_全站_页脚广告1

关于我们      便捷服务       自信AI       AI导航        抽奖活动

©2010-2025 宁波自信网络信息技术有限公司  版权所有

客服电话:4009-655-100  投诉/维权电话:18658249818

gongan.png浙公网安备33021202000488号   

icp.png浙ICP备2021020529号-1  |  浙B2-20240490  

关注我们 :微信公众号    抖音    微博    LOFTER 

客服