软件测试工程师常见的问题

软件测试常见问题基础知识部分

1.怎样描述一种缺陷？1V看到这个问题，也许有些读者会觉得可笑哪个测试人员不会描述缺陷？不过现实中却真口勺存在诸多测试人员提交的I缺陷需要向开发人员进行解释或者演示后，才能让人明白他真正要体现的意思实际上，与否可以清晰地描述软件缺陷，绝对体现着一种测试人员的能力水平高下除了极个别的I不能重现的缺陷外，一种软件缺陷至少应当描述清晰三方面的内容缺陷概述、详细内容、重现环节•缺陷概述一一用一到两句话详细地描述缺陷的症状,使管理人员一下子就能看明白大概是什么问题•详细内容一一详细地描述缺陷的症状，可以刊登自己对该缺陷的某些意见详细内容重要供程序员进行分析•重现环节一一详细描述怎样在系统中重现缺陷，这是非常重要的一项内容，假如重现环节描述的非常清晰，将大大加紧开发人员修改缺陷的速度一般状况下，诸多缺陷管理软件把“详细内容”与“重现环节”进行了合并，即只有一种文本输入框供测试人员录入信息，这就导致诸多测试人员疏忽了去描述“重现环节”此外其他诸如测试版本、测试环境、发现日期等辅助信息也应当认真录入作、为何开发人员常常埋怨测试工程师提交的缺陷质量太差？4我们常常听开发人员说“这不是缺陷！”，“这个缺陷没有，由于我日勺系统上运行正常！”测试工程师自身就是做质量工作的I,提交的成果自身就应当质量高些，为何还会有这种现象？提交的缺陷引起争议是一种正常的现象，例如测试人员描述不清晰就会引起争议减少甚至防止这种现象日勺措施是交叉测试，交叉测试是提高测试质量日勺一种有效手段，当然交叉测试会增长一定的测试成本投入在测试任务完毕后，测试工程师之间互相验证彼此提交日勺缺陷，就会防止了缺陷描述不清、因运行环境而产生的缺陷等一系列问题，从而大大减少了回归测试以及交流的成本，因而这种投入也是值得的，实际开发人员在单元测试阶段也会进行交叉测试，来提高开发质量此外，测试人员一定要按照规范描述测试中发现的缺陷，一种缺陷至少描述清晰概要描述、详细描述、重现环节三方面日勺内容、“让那些新手来做测试，反正他们也不会什么”对的）吗？5在实际项目开发中，我们常常看到有些单位忽视测试团体存在H勺意义，当要实行测试时,往往临时找几种程序员充当测试人员也有些单位尽管认识到了组建测试团体的重要性，但在详细贯彻的时候往往安排某些毫无开发经验的行业新手去做测试工作，这常常导致测试效率低下，测试人员对测试工作索然无味根据笔者的经验，测试团体应首先聘任一名资深的测试领域专家，他应具有极为丰富日勺同类项目软件测试经验，对软件开发过程中常见H勺缺陷或错误了然于胸；止匕外，他还具有很好口勺亲和力和人格魅力另一方面，项目测试团体还具有诸多具有一技之长的组员，如对某些自动化测试工具运用娴熟或能轻而易举地编写自动化测试脚本等此外，测试团体还应聘任某些兼职组员，如验证测试实行过程中，同行评审是最常使用的一种形式，这些同行专家就属于兼职测试团体组员的范围至于测试团体里里日勺测试新手,这部分人可以安排去从事交付验证或黑盒测试之类日勺工作、测试同化现象是什么？6同化现象是指伴随时间的推移，开发人员会逐渐影响测试人员的思维和对缺陷的判断能力，尤其是针对同一产品，同一组开发人员和同一组测试人员共同配合了很长时间，诸多本来是缺陷的）问题，由于测试人员对软件“习惯成自然”的I使用，会不被当成缺陷，尤其是在开发人员的I解释和说服下同化现象发生也许意味着“恶性循环”日勺开始测试人员会帮着开发人员解释一种个缺陷的合理性，一轮有一轮的测试都不会发现问题招聘新的人员，不一样的测试项目组轮换去测试不一样的产品，就可以防止同步提议产品可以公布测试版，更多的人对其进行测试，就可以发现更多的问题、测试工程师怎样防止定位效应？7社会心理学家曾作过一种试验在召集会议时先让人们自由选择位子，之后到室外休息半晌再进入室内入座，如此五至六次，发现大多数人都选择他们第一次坐过的位子这种现象称为定位效应，阐明人们习惯上但凡自己认定的I,人们大都不想轻易变化它定位效应在开发人员和测试人员身上均有体现例如开发工程师针对某一自己写日勺功能，常常进行代码移植，这种复制的“功能”，由于上一次通过调试，在新日勺地方往往不会认真调试，这些代码往往会带来共享变量冲突等许多种类型的缺陷定位效应体目前测试人员身上就是测试过的功能不再进行认真测试在回归测试时，之前由于进行过认真日勺测试，往往会认为某些功能是可靠，只要验证某些此前发现H勺缺陷与否修改完毕就可以了这种现象在反复多次回归时体现的愈加突出，由于回归测试中诸多功能都会进行多次反复测试众所周知，开发人员在修改缺陷时往往会引入新的缺陷，测试人员时疏于防备就会把这些缺陷带到顾客这里处理这种问题日勺方案一般有两个1完整的执行测试用例这种措施投入较大，不过在开发产品时最佳在最终一次回归测试时测试的I执行一次所有的测试用例2交叉测试测试人员交叉测试，就可以很大程度日勺防止定位效应测试工程师在回归测试时互相互换任务，反复测试某一功能的机会大大减少，从而也就不会“主观的”人员某些功能没有缺陷一般上面的两个措施都是结合使用的，既要进行交叉测试，又要全面执行测试用例，测试覆盖面要尽量的广泛、测试人员忽然辞职怎么办？8目前IT行业人员流动较大已经成为一种不争的事实，员工口勺辞职大多数都会给组织带来一定日勺影响，而这种影响基本是不也许防止的在测试领域，员工忽然辞职也会带来很大的负面影响，尤其测试队伍规模较小时面对这种状况，我们所能做的，就是怎样最大程度的减少这种影响根据作者的经验，重要有两种措施:第一种是在测试人员内部建立一种良好的学习环境,大家互相学习，这样某些特有技术不会被某一种人所掌握，而互相学习和提高自身，也是大多数组员乐意做的；第二种就是在组织中进行知识管理，把技术作为知识沉淀下来，这样新的员工在接手工作时轻易上手，通过学习迅速适应环境此外，平常还要注意工作规范化，例如形成尽量多的文档，都可以减少员工离职带来日勺损失、测试人员工作发生问题测试经理应当怎样做？9测试人员工作发生问题是测试经理常常要面对的问题，作为测试部门的领导，首先要做时是指出测试人员所犯的错误，使其尽快改正错误唯一不能做的就是盯着下属的错误不放总盯着下属日勺失误,是一种领导者的最大失误英国行为学家波特说当遭受许多批评时，下级往往只记住开头H勺某些，其他就不听了，由于他们忙于思索论据来反驳开头日勺批评身为测试经理要根据测试人员的心理来进行指导,最大程度日勺调动每个人员日勺积极性来参与工作、不深入到详细测试工作时，测试经理怎样考核员工？10这种现象在测试规模较大的组织中很常见测试经理应当尽量的安排每周与每个组员在不被打扰H勺环境下进行谈话，这样可以尽早发现和处理诸多问题做为一种测试经理，重要工作之一就是定期日勺评估组织做了些什么并且是怎样做的同步还要为员工做一种汇报一一有关充足理解测试人员正在做什么和怎样做日勺汇报，以此来给测试人员做做工作成绩考核这份汇报要理解到每个人的动态测试经理和每个员工重点是谈谈目前的工作，例如大家在工作中的J问题或意见；与否需要协助等许多管理者常常埋怨没有时间在一周会见每一种员工来谈他们的工作不过根据作者的经验，假如不能安排时间和员工进行每周H勺谈话，员工会来打扰测试经理H勺工作，由于员工诸多问题还要要来找测试经理商议同步看待员工要用他们能接受的I方式，而不是我们自己可以接受的方式“己所不予，勿施于人”，这条黄金法则也许会对许多生活中的纯粹的社交原因有效，不过并不是总对工作有用有效率的管理者懂得应当逐渐理解每一种员工需要怎样的看待方式总之，只有尽量多的和员工接触，才能更精确H勺进行考核、测试经理怎样面对加班问题？11大多数状况下，作者是不主张加班的当员工每周工作超过40个小时的时候，他们开始在工作口勺时候关怀自己的事他们花钱，会给很久没有联络的人打，由于员工们一直都在工作员工不能在太疲劳的状态下完毕工作，这是由于他们在工作时不能关怀自己，这种状况下一般效率很低测试管理工作的重要任务之一就是要发明一种环境，让员工在工作时间内完毕工作，同步还要鼓励他们每周不要超过40小时，甚至可以基于他们在40个小时可以完毕的工作量给他们酬劳一般状况下这样做可以提高发明力，从而会逐渐提高效率测试工作自身H勺一种突出特点就是不停反复枯燥、冗长的测试，假如在疲劳状态下，很有也许精力不集中，略过某些重要日勺测试环节并且有的时候测试需要编写测试驱动程序,这种状况更需要很好的I状态来工作、测试管理者怎样面对自己的错误？12每个人都会出错我们也许会由于忘掉开会而使客户发火，承认自己出错是一件尴尬H勺事情，尤其是管理人员认为对自己负责的I项目小组承认出错也许会失去尊严假如我们不是常常出错，承认错误的I时候其实可以赢得尊敬例如我们忘掉一次会议，然后为此向同事或者客户道歉，其他的人会理解我们的I不管做了什么，不要否认或故意忽视自己的失误故意忽视不会让错误消失，这只会让错误成长为怪物、为何计划定期的培训？13测试工作和开发工作同样，不仅要面对日新月异的新技术，还要学习有关系统的领域知识只有在不停口勺学习中，才能做好工作，跟上行业的发展假如测试管理者没有基于不停的变化而培训员工，就会给组织带来一定日勺损失平常培训可以是有关特定项目或者是技术,一般采用下面几种措施1测试部门内自由交流方式的培训这种培训的交流比较随意，可以在周五的例会上进行交流，也可以大家一起坐在茶馆里进行交流措施可以采用“头脑风暴法”，让每个组员讨论一种特定日勺领域，这种交流措施尤其对同步要做诸多不一样项目的小组比较有益处当每个人做不一样的项目，这会有助于每个人理解你小组所有H勺工程2跨部门口勺互相学习测试工作需要诸多领域以及技术知识，这些知识单靠自学是远远不够日勺和其他部门日勺同事进行交流是一种相称好日勺措施，大家在工作中可以在技术等各个方面互相得到提高3外部培训外部培训尽管投入较高，但也是值得的这些专家一般在自己的领域非常精通，可以迅速提高整个测试团体的水平也可以通过测试小组简介某些朋友来进行培训，这种方式可以减少成本培训是构造学习型组织的I基本条件，也是提高员工水平日勺重要措施常常的定期培训I,可以增强组织凝聚力，使员工愈加乐意长期留在组织中发展做为测试负责人，定期的进行培训是十分必要日勺、时间上不容许进行所有测试，测试负责人应当怎样做？14这个问题也许十分可笑，可是现实中我们的测试经理们却不得不面对这个问题这里日勺所有测试不是指对软件进行遍历测试，而是指测试负责人制定的测试计划包括的所有测试内容一般，不管是开发产品还是做详细区I项目，都会发生耽误进度的I状况一旦整体进度不能向后延迟，项目有关人员习惯上的做法就是缩减测试时间尤其在功能还没有开发完毕口勺状况下，这种现象更为突出肩负着质量重任的测试经理，怎样来处理这个问题呢？比很好的做法是按照下面的环节逐渐来完毕和改善工作1按照测试任务时轻重缓急，尽最大努力完毕测试任务在时间局限性的状况下，我们应当对测试任务按照优先级来划分，重要紧急的任务先完毕这个时候的测试任务是一种辅助性工作，其目的就是尽最大努力来提高质量因此，面对这种状况，测试负责人要做时就是带领测试小组充足运用所有资源来保证质量

（2）在实际工作中和开发人员共同配合，逐渐改善工作只有整个团体的J软件开发能力提高了，才能从本源上处理问题因此，测试负责人要带领团体和开发小组共同寻找适合自己的开发模式，从而使项目规划欧I愈加合理，进而按照预定计划来开展测试工作总之，在任何状况下，测试负责人都不应当埋怨只有积极日勺面对问题，才能更好日勺处理问题、企业不重视测试，测试负责人怎样开展测试工作？15目前国内的软件企业不重视测试仍然是一种普遍现象尽管诸多企业在意识上已经开始重视测试，不过在详细工作中，往往由于追赶进度、节省资源等方面原因而忽视测试工作在这种状况下，测试负责人仍要对软件质量负重要责任在这种环境下，测试负责人应当怎样开展工作呢？首先，要积极去配合开发人员完毕工作尤其是不能埋怨环境，在任何状况下埋怨是不能处理问题的I,只能加重矛盾的激化在此基础上，逐渐显出测试工作的重要性，然后再逐渐健全测试体系另一方面，用实际行动来证明测试工作日勺重要性只有测试工作H勺业绩逐渐体现出来,人们才会真正的注意到测试的重要性因此，测试负责人从点滴开始做起，才能逐渐做好测试工作要想做好软件，把开发的软件产品形成商品，测试工作必须和开发同样重视否则，质量不好的产品，很快会被市场淘汰时现代的软件规模越来越大，测试工作也会越来越重要,因此测试负责人只要坚持做好工作，可发挥作用的空间会越来越大最终要说的是，假如真的是在一种没有但愿H勺团体里，测试负责人可以考虑辞职辞职也是一种不错的选择，到新的环境去发挥自己的能力，要比长时间时怀着“郁闷”的心情去工作好日勺多、测试管理者需要是技术专家吗？16测试管理者在测试项目中的重要任务是制定测试方略，管理测试计划的贯彻状况，并且还要为测试项目的进行发明良好的执行环境同步还要调动员工日勺发明性，对员工的工作作出评估这些工作不一定规定测试管理者到达专家日勺水平不过在实际工作中，由于测试人员的短缺，测试管理者常常做为测试员来执行详细的测试任务尤其在规模较小H勺测试团体，测试管理者的平常工作一般以详细日勺测试执行工作为主，这个时候更需要测试管理者有很好的背景知识总体说来，技术方面的背景知识对测试管理者是十分有益的例如分派工作任务、做进度预算，以及某些详细的I执行工作，都需要一定日勺背景知识当然，做为一种测试管理者,没有必要精通所有的技术，那也是办不到的测试管理者做到对口勺的协助员工最佳地完毕工作，并且提供最佳日勺完毕工作的环境就可以了测试流程部分

3.、测试人员要需要何时参与需求分析？1原则上，测试人员对需求理解得越深入对测试工作越有利，因此最佳一开始就应当参与需求分析工作这样可以带来如下得好处•测试人员全程参与需求分析，对需求理解很深刻，减少了诸多与开发人员的交互，节省了时间测试人员参与前期开发讨论，直接掌握了不清晰的需求点；•初期确定测试用例的编写思绪，为测试打好了基础；•可以获取某些测试数据，为测试用力设计提供协助；•可以发现需求不合理日勺地方，减少了测试成本测试人员重要日勺工作之一就是确认系统与否对日勺实现了需求测试人员不参与前期的工作，就只能依赖最终形成日勺需求文档，甚至由开发人员来讲解需求，而这些缺求也许发生了“问题”，由于这个需求是已经通过度析的J需求，诸多日勺内容也许与顾客日勺真正规定发生了偏差同步假如只看最终形成的需求文档，对需求也会有理解上日勺偏差因此作为测试人员要尽量的I获取到“第一线”的I需求资料，才能真正地理解顾客的I业务，从而更好欧I对系统进行测试当然，假如测试人员不能参与需求环节，一定要通过其他途径保证需求的精确性，例如和开发人员进行集中讨论需求疑问H勺项目会议，并且一定要加强测试案例评审，甚至于是测试需求日勺评审、系统测试阶段低级缺陷较多怎么办？2在系统测试阶段，假如仍有诸多低级缺陷，阐明测试对象是不合格的，没有到达测试原则假如系统阶段发现的简朴缺陷（也就是不应当有的缺陷）较多，最佳停止测试，转由开发人员进行测试，发现问题立即修改，由于这种由测试人员进行H勺成本较高，反复交互还会耽误进度提议建立预测试制度系统测试前对关键模块进行抽查测试，假如问题较多（例如平均每个关键模块发现10个以上缺陷），就可以停止本次测试，直到抽测后发现问题较少才可以、缺陷是谁“生产”的2这是一种“老生常谈”的问题尤其在追究某些质量问题责任的I时候常常听测试人员埋怨“这些模块简直是垃圾！不值得测试！挥霍我的时间！”，开发人员则埋怨“重要的问题发现不了，却成天盯着那些无关痛痒的小问题，还不如自己去测试！”不符合顾客规定时都可以称之为缺陷，因此缺陷的来源重要有两类一类是没有对的理解顾客需求，由系统需求或者分析人员设计出来的缺陷，此类缺陷重要由设计人员“生产”;此外一类是程序开发人员没有按照设计规定进行开发或者编写的代码存在错误而引起日勺缺陷，此类缺陷由程序开发人员“生产”对于那些开发流程不规范日勺组织，一般开发人员会包办测试前日勺大部分工作在这种环境下，几乎没有什么设计文档，软件开发重要按照程序设计人员的想像来进行，这个时候日勺缺陷则重要由开发人员“生产”测试人员不是缺陷的“生产”者，由于测试人员没有写过一行代码，这与否意味着测试人员可以在一旁“幸灾乐祸呢”？事实恰好相反，测试人员与缺陷关系愈加亲密，他们是“缺陷的缺陷”的制造者所谓“缺陷的缺陷”，重要指测试人员提交的I“不是缺陷”的缺陷，即测试人员没有对的理解需求，从而提交了主线“不是缺陷”的I缺陷，这种缺陷也是测试人员常常受到指责的J重要原因有关上面的J埋怨，测试和开发双方都需要摆正心态由于实际双方都在不停的J“生产”着缺陷，只是发明H勺方式不一样罢了启动系统测试、缺陷流落到客户那里有什么后果？3假如软件缺陷被遗落并流落到客户那里，成果就是代价高昂时或者现场支持费用，还也许需要修复、重新测试和公布新的产品，更糟糕的状况是产品要被召回甚至被客户起诉这种成本付出非常高，几乎是在内部修改缺陷的几何级数倍质量之父PhilipCrosby把质量的1费用分为整合费用和非整合费用两类，整合费用是指与一次性计划和执行测试有关的所有费用，用于保证软件按照预期方式进行假如发现缺陷,通过一系列的I缺陷处理流程而处理缺陷，这种费用就是非整合费用PhilipCrosby在自己的I作品中详细论述了内部日勺整合费用和内部日勺非整合费用之和远远不大于外部也就是客户引起日勺非整合费用总之，软件缺陷一定要尽量的在内部处理，这对节省成本、提高产品著名度都大有裨益、什么是冒烟测试？4冒烟测试从操作上是一种随机日勺测试，操作对象一般是关键业务模块测试员任意操作,要是发现多数功能走不下去（大概20%）,那么这个冒烟测试就算是结束了冒烟测试一般不用参照测试用例执行冒烟测试的目的是对要测试的产品进行一种大概时度量假如冒烟测试不能通过,一般不会启动测试计划由于软件缺陷较多的状况下，启动测试计划会挥霍更多的人力和物力通俗的说，对“垃圾”产品执行测试实际是测试人员抢了程序设计人员日勺工作，这些缺陷应当在开发阶段消灭，只有这样才可以真正的节省成本、在集成测试的时候，已经对某些子系统进行了功能测试、性能测试等等，那5么在系统测试时能否跳过相似内容的测试由于集成测试是在仿真环境中开展的，那不是真正的目的系统再者，单元测试和集成测试一般由开发小组执行根据测试心理学欧I分析，开发人员测试自己的1工作成果虽然是必要日勺，但不能作为成果已经通过测试的根据为了保证测试H勺客观性，应当由机构H勺独立测试小组来执行系统测试、什么是测试方略6测试方略描述测试工程欧I总体措施和目的描述目前在进行哪一阶段的测试（单元测试、集成测试、系统测试）以及每个阶段内在进行的测试种类（功能测试、性能测试、覆盖测试等）测试方略的制定重要包括三个方面的内容:

（1）确定测试过程要使用日勺测试技术和工具;

（2）制定测试启动、停止、完毕原则;

（3）进行风险分析和应对方案例如测试与外部接口或者模拟物理损坏、安全性威胁测试计划最关键的一步就是将软件分解成单元，按照需求编写测试计划、代码会审是怎样进行的7J在研发小组将所开发日勺程序经验证后，提交测试组后，测试实行工作基本开始了这个时候，测试人员要仔细阅读有关资料，包括规格阐明、设计文档、使用阐明书及在设计过程中形成的测试大纲、测试内容及测试的通过准则，全面熟悉系统，编写测试计划，设计测试用例，作好测试前的准备工作为了保证测试的质量，我们一般测试过程提成几种阶段，即:代码审查、单元测试、集成测试和验收测试代码会审是由一组人通过阅读、讨论和争议对程序进行静态分析欧I过程会审小组由组长，2〜3名程序设计和测试人员及程序员构成会审小组在充足阅读待审程序文本、控制流程图及有关规定、规范等文献基础上，召开代码会审会，程序员逐句讲解程序rJ逻辑，并展开热烈日勺讨论甚至争议，以揭示错误日勺关键所在实践表明，程序员在讲解过程中能发现许多自己本来没有发现的错误，而讨论和争议则深入促使了问题日勺暴露例如，对某个局部性小问题修改措施H勺讨论，也许发现与之有牵连日勺甚至能波及到模块的功阐明、模块间接口和系统总构造的大问题，导致对需求定义的重定义、重设计验证，大大改善了软件的质量代码会审尽管需要一定取I成本，不过在大型软件中，是必不可少改I、回归测试中未处理的缺陷怎样处理？8软件的后期测试就是一种反复回归的工作，有些问题也许修改多次才能处理，尤其是那些在开发环境下不存在的问题，这些问题很轻易被程序员忽视，拖到最终才处理因此大部分回归测试就是和开发人员反复配合处理那些上次测试中没有处理的缺陷这里重点讨论的是最终一次回归测试后，仍然发既有些缺陷没有处理时测试经理应当怎样做在管理不规范的组织中，由于进度或者其他方面日勺压力，开发工作已经停止，一般会将这些问题置之不理对时的做法时把这些没有处理欧I问题形成一种未处理缺陷汇报，然后召开项目会议进行讨论，对不一样口勺问题采用不一样的处理方式⑴严重性日勺问题有些问题较难处理，往往会被拖到最终，假如此类缺陷导致软件功能发生障碍，则必须处理，这也是质量控制的职责所在;⑵功能性的问题可以考虑升级时处理；⑶一般性问题不影响使用，可以不处理或者升级处理此类项目会议一般需要技术总监或者更高级别口勺人来参与最终，需要对最终讨论没有处理的I缺陷列表进行签字并存档，形成一种基线尤其要注意的I某些缺陷与否修改不能由程序员或者测试人员来决定，这样有也许带来严重日勺后果一一导致缺陷失控，最终形成没有人对质量负责的局面、状态为已经修改的缺陷没有修改怎么办？9首先要对此类缺陷进行分析1有些问题在开发环境下没有重现，而开发人员迫于进度压力，往往会把它标识为已经修改这种条件下测试人员应当和开发人员进行直接沟通；2有些问题测试人员没有描述清晰，开发人员认为问题不存在也也许把问题标识为已经修改对时的做法是标识问题为商讨或者不存在状态测试人员应当清晰的描述问题,减少此类问题时发生，尤其要描述清晰运行环境以及缺陷的重现环节；3第三类状况纯属个人行为迫于进度压力，开发人员来不及修改问题，会故意把某些问题标识为修改，这样就可以在下次测试后进行修改处理这种问题措施就是记录缺陷H勺修改次数，分析出那些反复修改的缺陷归属于那些开发人员，然后和绩效考核结合起来测试人员也可以这样做，把某些未验证的缺陷标识为“重新打开”，让开发人员来帮忙“验证”，我们仍然可以记录这种问题的次数，最终根据时间进行分析而处理这种问题的主线措施就是加强项目管理,提高项目执行能力，一旦资源较富余时,测试人员和开发人员就会愈加投入H勺一起处理缺陷，共同来提高软件质量产品测试完毕后产品谁来公布

10.诸多时候产品通过最终一次测试后由开发人员来公布，或者由质量管理部来公布，这样做都是不合适的开发人员公布产品常常会导致缺陷处理不彻底一种较常见口勺现象是最终一次回归测试后，开发人员修改完毕最终几种缺陷直接从开发环境公布产品，节中的案例就是这样的一种状况，这种条件下实际是缺陷一次测试，由于修改缺陷一般会引入新的缺陷，甚至是严重的I缺陷测试人员公布缺陷也是不和流程的，测试人员的职责是汇报软件质量状况并且测试人员公布缺陷轻易带来版本管理混乱对时的做法是产品通过最终一次测试后，把产品和缺陷修改状况存入产品基线库，形成一种可以公布的版本这样公布产品的一种前提是每次产品提交测试前都要有一种预备公布版本，测试或者回归测试后假如有问题需要修改处理，开发人员对该预备版本进行修改如此反复多次后，直到最终一次测试，所有缺陷都得到修改或者审核，同步开发人员本次测试后没有对产品通过任何修改，我们就可以把这个最终一种预备公布版本存入基线库进行了上面对的的版本控制后，我们可以通过配置管理库进行产品公布管理对外部公布产品时，直接从配置管理库中提取就可以了详细的I内容，读者可以参照配置管理方面欧I书籍、性能测试什么时候开展最为合适？11大多数状况下，性能测试在系统测试的最终阶段进行阶段进行这重要是由于性能测试是一种综合性的测试，只有在功能测试通过后，谈系统测试才会有较大意义但下列两类状况比较特殊，性能测试一般进行日勺较早，几乎伴伴随单元测试同步进行:第一类是系统软件，例如开发操作系统或者数据库，等系统开发完毕后再进行性能日勺唯一作用就是进行一种综合评估假如在最终发现性能问题，很有也许推翻整个系统第二类是对性能规定较高的应用软件例如银行、电信的系统，对系统的性能要远远高于一般的办公自动化系统此类系统软件最终测试时发现性能问题，往往是系统架构或者某些关键算法、重要功能模块的原因，这个时候会带来较大的改动，甚至也许报废整个系统对于上面两类软件，性能测试应当贯穿着整个软件开发过程，大体要通过下面几种测试过程1单元性能测试阶段上面这两类软件的性能测试最终从单元测试阶段就应当介入,详细做法就是安排性能测试工程师对某些重要算法进行测试，保证这些算法可以满足性能规定这样做的好处是把问题尽早处理，可以大大提高整体性能2构成/集成性能测试阶段这个阶段的性能测试是前面的深入，相称于把系统测试阶段的组合业务性能测试提前进行，可以把某些性能问题在集成测试阶段发现并处理3系统测试阶段的性能测试这个阶段的性能测试是一种全面的性能测试，有了前面日勺基础，这个时候发现日勺问题很愈加轻易处理总之，性能测试是十分重要并且投入较高的测试，开展性能要根据详细的软件属性以及其他实际状况来制定测试方略、缺陷产生的原因是什么3在上个问题中，已经简介了设计人员、开发人员、测试人员都会“生产”软件缺陷在实际工作中，缺陷产生的方式更是层出不穷，原因也是多种多样例如开发人员去接杯水，碰巧和此外一种接水日勺同事聊了几句，成果回到工位时忘掉了要在某个判断语句追加此前已经想好日勺一种判断条件，这无疑会产生一种缺陷因此很难一下子把缺陷产生的原因所有陈列出来，下面只是某些引起缺陷的经典原因

（1）开发人员不太理解需求，不清晰应当“做什么”和“不做什么”，常常做不合需求H勺事情，因此产生了缺陷；

（2）软件系统越来越复杂，开发人员不太也许精通所有的技术假如不能对时地掌握新口勺技术或者知识，也许会产生缺陷；

（3）技术文档普遍编写的I很差，甚至文档自身就有缺陷，导致使用者产生更多的缺陷;

（4）软件需求、设计汇报、程序常常发生变更，每次变更都也许产生新日勺缺陷；

（5）任何人在编程时都也许出错误，导致程序中有缺陷；

（6）技术人员常处在进度的压力之下，不能静心思索也很轻易产生缺陷，尤其是在Deadline临近之际，频繁日勺加班是开发人员疲于应付进度；

（7）诸多开发人员过于自信，喜欢说“没问题”，因此对于某些代码不进行认真的I调试，这也是某些缺陷产生H勺原因；

（8）频繁H勺拷贝代码也会把缺陷随之复制到新的程序中，尤其是复制其他团体组员日勺代码更轻易使某些缺陷隐藏在程序中、软件的质量应当由什么人来负责4对于某些开发管理混乱或者测试刚刚起步的组织，产品质量一发生问题，习惯上会归咎于测试小组，认为测试人员没有测试好产品，因此才产生了那么多的缺陷对于开发管理规范某些或者测试体系已经建立一定期间口勺组织，假如客户投诉产品质量问题，则往往开发人员与测试人员会一起接受惩罚这种处理方式多少会让测试人员心理稍稍平衡某些追根溯源，软件发生质量问题实际是项目管理不规范引起的因此，假如要追究责任的话，软件质量问题的责任应当由整个团体来承担只有提高整个团体H勺开发水平，才能提高质量此外，也应当认识到软件发现问题是正常的1现象，很少有软件实现了零缺陷做为企业领导者，应当详细问题详细分析，不要老是考虑怎样惩罚自己的组员、测试能保证质量吗？5在软件质量方面，目前多数IT企业重要采用三种措施技术评审、过程检查、软件测试技术评审技术评审最初是由IBM企业为了提高软件质量和提高程序员工作效率而采用日勺，重要指对项目计划、软件需求、系统设计等文档进行有效评审日勺过程技术评审可以由专家团体构成，也可以由组织内部人员构成,它可以尽量防止设计人员在某些方面发生“闭门造车”口勺情形通过技术评审，可以尽早地发现工作成果中的缺陷，并协助开发人员及时消除缺陷，从而有效地提高产品的质量过程检查属于质量工程师（QA）欧I工作范围，重耍检查软件项目的I“工作过程和工作成果”与否符合已经制定的有关规范在项目执行过程中，质量保证人员要不停日勺按照项目计划对项目进行有效的监督和检查通过过程检查，可以找出明显不符合规范日勺工作过程或者工作成果，及时纠正开发中的错误因此，软件测试只是保证质量日勺最常用手段，仅仅通过测试是不可以保证质量的，还要辅以技术评审、过程检查等手段、测试人员与否需要开发技能？6在诸多测试网站的论坛上，这个问题都是津津乐道的热门话题而究其本源，重要是由于诸多测试人员做不了开发才来做测试，于是其中日勺诸多人便怀着某些“胆怯”心理，与同行反复探讨这个问题，期望其他人可以肯定“虽然不会开发也能做好测试”日勺观点，以便在心理上得到某些安慰与否需要开发技能与测试人员从事的测试工作种类有极大关系，相信诸多人都听过微软曾经聘任一名家庭主妇来测试Windows操作系统的故事实际上，假如从事单元测试、集成测试等较靠近程序代码的工作，无疑需要开发技能，此类工作对测试人员开发技能的规定甚至会超过程序员；而从事基本的界面测试、顾客功能测试，不会开发不会有大的影响不过，原则上还是提议测试人员最佳具有一定日勺开发能力，并且是开发能力越强越好,开发技能对测试工作可以说是“百利而无一害”，例如可以更轻易防止汇报反复H勺缺陷、对缺陷原因进行更精确的定位等等同步，由于国内多数企业对测试人员没有分类，要想得到更多的I发展机会，也应当学会开发，便于从事多种类型的测试工作，除非只从事那些远离代码区I测试工作此外，掌握一门开发语言后，进行测试的时候可以站在程序开发的角度进行思索，并且懂得程序怎样编写，就更轻易发现问题、测试的目的是什么？7测试日勺目的是为了发现尽量多的I缺陷，这个观念很轻易让人接受，不过却很难贯彻到实际工作中，由于测试的目曰勺常常被定位为“证明软件没有问题”软件质量与否优良在投产后才能有所体现对的理解测试的目的十分重要假如认为测试的目的是为了阐明程序中没有缺陷，那么测试人员就会向这个目的靠拢，因而下意识地设计诸多不易暴露错误的测试示例，这些测试用例恰恰证明软件实现了预期功能，这样日勺测试是不真实日勺成功的测试在于发现了迄今尚未发现的缺陷，测试人员的职责是设计这样的测试用例一一它能有效地揭示潜伏在软件里H勺缺陷、一种软件产品测试结束时没有发现任何新日勺缺陷，这样日勺软件质量一定好8吗？测试只能证明缺陷存在，不能证明缺陷不存在而彻底的、全面日勺测试又难以成为现实,现实中要考虑时间、费用等限制，不容许无休止地测试一般日勺测试结束，只是满足一定条件下的测试结束，最终的“测试”还是交给了顾客因此，虽然测试结束了，质量也不一定好例如测试小组在时间紧迫日勺状况下，只测试了关键模块，这样H勺软件系统质量一般不会好、测试中的原则是什么？980-20测试中欧180-20原则是说一般状况下，在分析、设计、实现阶段的复审和测试工作可以发现和防止80%的Bug,而系统测试又能找出其他Bug中欧I80%,最终的I5%欧I Bug也许只有在顾客日勺大范围、长时间使用后才会暴露出来由于测试只可以保证尽量多地发现错误,无法保证可以发现所有的I错误尚有就是一般状况下80%的缺陷汇集在20%的关键关键业务模块中测试到是测试工作的目日勺和原则吗？10Zero-bug一般对于相对复杂的产品或系统来说，Zero-bug是一种理想，Good-enough是我们的原则Good-enough原则就是一种权衡投入/产出比日勺原则不充足的J测试是不负责任区I；过度的测试是一种资源的挥霍，同样也是一种不负责任的体现执行测试工作的关键在于怎样界定什么样的测试是不充足的，什么样的测试是过度的处理这一问题的一般措施是制定最低测试通过原则和测试内容，然后详细问题详细分析、一般测试工作要到达什么目的？111保证产品完毕了它所承诺或公布的功能这一目欧I就是软件要符合需求，开发出欧I软件应当到达所有功能均有明确的书面阐明----在某种意义上与IS09001是同一种思想，测试的首要目的就是保证所有预定功能是存在并且通过规范日勺测试当然书面文档时不健全甚至不对时会导致测试效率低下、测试目的不明确和测试范围不充足，进而导致最终测试欧I作用不能充足发挥、测试效果不理想因此详细问题一定要详细分析，一种好的测试负责人尽量来弥补这些文档缺陷

（2）保证产品满足性能和效率的规定目前日勺顾客对软件的性能方面日勺规定越来越高，使用起来系统运行效率低（性能低）、或顾客界面不友好、顾客操作不以便（效率低）的产品市场空间肯定会越来越小因此通过测试改善性能也是测试工作一种目的I实际上顾客最关怀的不是软件的技术有多先进、功能有多强大，而是能从这些技术、这些功能中得到多少好处也就是说，顾客关怀的是他能从中取出多少，而不是你已经放进去多少

（3）保证产品是强健的、适应顾客环境的强健性即稳定性，是产品质量的基本规定，尤其对于一种用于事务关键或时间关键的工作环境中日勺应用系统软件只有稳定的运行，才会不致于中断顾客日勺工作，因此通过强健性测试是软件测试工作的又一种目日勺测试管理部分

2.、测试负责人要进行严格日勺测试进度跟踪吗？1诸多时候，由于人力资源的局限性，测试项目负责人都是在执行测试，这样就使整个项目缺乏控制，某些问题（例如有些组员的I缺陷质量不够合格；开发人员修改不及时，系统某些功能发生严重问题导致部分功能无法测试）得不到处理，耽误了进度因此测试负责任必须全程监控项目，尽量多的掌握信息一般，测试负责人需要完毕下面这些内容的管理工作•测试用例执行状况；•每个测试员提交的缺陷状况；•测试中与否发生突发问题、测试也有版本控制吗？2这里的版本重要是指测试对象日勺版本控制，也就是指对开发部提交的产品进行版本控制在开发小组版本管理不规范日勺状况下，测试小组进行版本控制十分重要，要保证测试对象是可以控制的提议开发和测试双方进行明确H勺约定，可以各自指定专门的测试版本负责人，制定提交原则，对提交状况进行详细的记录，这样基本防止了版本失控导致口勺测试失误或无效、怎样处理测试人员日勺流动问题？3人员流动不仅仅是测试部门，这是IT行业的I普遍现象从管理者角度，主管需要多多和团体内组员进行沟通，建立一种融洽的团体环境，及时掌握状况，可以早些进行对应的调整不过只有企业建立好日勺用人制度，给员工提高广阔的发展空间和好的培训学习机会，才能从主线上处理这一问题加强项目管理，强化文档管理并保证文档的有效性，可以大大减少由于人员流失带来日勺损失同步，测试部门要建立培训机制，使新到员工接受直接或者间接区I培训，迅速适应工。