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

《软件测试工程师常见的问题.docx》由会员分享，可在线阅读，更多相关《软件测试工程师常见的问题.docx（23页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、软件测试常见问题1.基础知识部分1 V怎样描述一种缺陷？看到这个问题，也许有些读者会觉得可笑：哪个测试人员不会描述缺陷？不过现实中却 真口勺存在诸多测试人员提交的I缺陷需要向开发人员进行解释或者演示后，才能让人明白他真 正要体现的意思。实际上，与否可以清晰地描述软件缺陷，绝对体现着一种测试人员的能力 水平高下。除了极个别的I不能重现的缺陷外，一种软件缺陷至少应当描述清晰三方面的内容：缺陷 概述、详细内容、重现环节。 缺陷概述一一用一到两句话详细地描述缺陷的症状,使管理人员一下子就能看明白大概 是什么问题。 详细内容一一详细地描述缺陷的症状，可以刊登自己对该缺陷的某些意见。详细内容重 要供程序员

2、进行分析。 重现环节一一详细描述怎样在系统中重现缺陷，这是非常重要的一项内容，假如重现环 节描述的非常清晰，将大大加紧开发人员修改缺陷的速度。一般状况下，诸多缺陷管理软件把“详细内容”与“重现环节”进行了合并，即只有一 种文本输入框供测试人员录入信息，这就导致诸多测试人员疏忽了去描述“重现环节”。此外其他诸如测试版本、测试环境、发现日期等辅助信息也应当认真录入。作。4、为何开发人员常常埋怨测试工程师提交的缺陷质量太差？我们常常听开发人员说：“这不是缺陷！”，“这个缺陷没有，由于我日勺系统上运行正常！ ”。 测试工程师自身就是做质量工作的I,提交的成果自身就应当质量高些，为何还会有这种现 象？提

3、交的缺陷引起争议是一种正常的现象，例如测试人员描述不清晰就会引起争议。减少 甚至防止这种现象日勺措施是交叉测试，交叉测试是提高测试质量日勺一种有效手段，当然交叉 测试会增长一定的测试成本投入。在测试任务完毕后，测试工程师之间互相验证彼此提交日勺 缺陷，就会防止了缺陷描述不清、因运行环境而产生的缺陷等一系列问题，从而大大减少了 回归测试以及交流的成本，因而这种投入也是值得的，实际开发人员在单元测试阶段也会进 行交叉测试，来提高开发质量。此外，测试人员一定要按照规范描述测试中发现的缺陷，一种缺陷至少描述清晰概要描 述、详细描述、重现环节三方面日勺内容。5、“让那些新手来做测试，反正他们也不会什么”

4、对的）吗？在实际项目开发中，我们常常看到有些单位忽视测试团体存在H勺意义，当要实行测试时, 往往临时找几种程序员充当测试人员。也有些单位尽管认识到了组建测试团体的重要性，但 在详细贯彻的时候往往安排某些毫无开发经验的行业新手去做测试工作，这常常导致测试效 率低下，测试人员对测试工作索然无味。根据笔者的经验，测试团体应首先聘任一名资深的测试领域专家，他应具有极为丰富日勺 同类项目软件测试经验，对软件开发过程中常见H勺缺陷或错误了然于胸；止匕外，他还具有很 好口勺亲和力和人格魅力。另一方面，项目测试团体还具有诸多具有一技之长的组员，如对某 些自动化测试工具运用娴熟或能轻而易举地编写自动化测试脚本等

5、。此外，测试团体还应聘任某些兼职组员，如验证测试实行过程中，同行评审是最常使用 的一种形式，这些同行专家就属于兼职测试团体组员的范围。至于测试团体里里日勺测试新手, 这部分人可以安排去从事交付验证或黑盒测试之类日勺工作。6、测试同化现象是什么？同化现象是指伴随时间的推移，开发人员会逐渐影响测试人员的思维和对缺陷的判断能 力，尤其是针对同一产品，同一组开发人员和同一组测试人员共同配合了很长时间，诸多本 来是缺陷的）问题，由于测试人员对软件“习惯成自然”的I使用，会不被当成缺陷，尤其是在 开发人员的I解释和说服下。同化现象发生也许意味着“恶性循环”日勺开始：测试人员会帮着 开发人员解释一种个缺陷的

6、合理性，一轮有一轮的测试都不会发现问题。招聘新的人员，不一样的测试项目组轮换去测试不一样的产品，就可以防止。同步提议 产品可以公布测试版，更多的人对其进行测试，就可以发现更多的问题。7、测试工程师怎样防止定位效应？社会心理学家曾作过一种试验：在召集会议时先让人们自由选择位子，之后到室外休息 半晌再进入室内入座，如此五至六次，发现大多数人都选择他们第一次坐过的位子。这种现 象称为定位效应，阐明人们习惯上但凡自己认定的I,人们大都不想轻易变化它。定位效应在开发人员和测试人员身上均有体现。例如开发工程师针对某一自己写日勺功 能，常常进行代码移植，这种复制的“功能”，由于上一次通过调试，在新日勺地方往

7、往不会 认真调试，这些代码往往会带来共享变量冲突等许多种类型的缺陷。定位效应体目前测试人员身上就是测试过的功能不再进行认真测试：在回归测试时，之 前由于进行过认真日勺测试，往往会认为某些功能是可靠，只要验证某些此前发现H勺缺陷与否 修改完毕就可以了。这种现象在反复多次回归时体现的愈加突出，由于回归测试中诸多功能 都会进行多次反复测试。众所周知，开发人员在修改缺陷时往往会引入新的缺陷，测试人员 时疏于防备就会把这些缺陷带到顾客这里。处理这种问题日勺方案一般有两个：(1)完整的执行测试用例：这种措施投入较大，不过在开发产品时最佳在最终一次回 归测试时测试的I执行一次所有的测试用例。(2)交叉测试：

8、测试人员交叉测试，就可以很大程度日勺防止定位效应。测试工程师在 回归测试时互相互换任务，反复测试某一功能的机会大大减少，从而也就不会“主观的”人 员某些功能没有缺陷。一般上面的两个措施都是结合使用的，既要进行交叉测试，又要全面执行测试用例，测 试覆盖面要尽量的广泛。8、测试人员忽然辞职怎么办？目前IT行业人员流动较大已经成为一种不争的事实，员工口勺辞职大多数都会给组织带 来一定日勺影响，而这种影响基本是不也许防止的。在测试领域，员工忽然辞职也会带来很大 的负面影响，尤其测试队伍规模较小时。面对这种状况，我们所能做的，就是怎样最大程度 的减少这种影响。根据作者的经验，重要有两种措施:第一种是在测

9、试人员内部建立一种良好的学习环境, 大家互相学习，这样某些特有技术不会被某一种人所掌握，而互相学习和提高自身，也是大 多数组员乐意做的；第二种就是在组织中进行知识管理，把技术作为知识沉淀下来，这样新 的员工在接手工作时轻易上手，通过学习迅速适应环境。此外，平常还要注意工作规范化，例如形成尽量多的文档，都可以减少员工离职带来日勺 损失。9、测试人员工作发生问题测试经理应当怎样做？测试人员工作发生问题是测试经理常常要面对的问题，作为测试部门的领导，首先要做 时是指出测试人员所犯的错误，使其尽快改正错误。唯一不能做的就是盯着下属的错误不放。总盯着下属日勺失误,是一种领导者的最大失误。 英国行为学家波

10、特说：当遭受许多批评时，下级往往只记住开头H勺某些，其他就不听了，由 于他们忙于思索论据来反驳开头日勺批评。身为测试经理要根据测试人员的心理来进行指导, 最大程度日勺调动每个人员日勺积极性来参与工作。10、不深入到详细测试工作时，测试经理怎样考核员工？这种现象在测试规模较大的组织中很常见。测试经理应当尽量的安排每周与每个组员在 不被打扰H勺环境下进行谈话，这样可以尽早发现和处理诸多问题。做为一种测试经理，重要工作之一就是定期日勺评估组织做了些什么并且是怎样做的。同 步还要为员工做一种汇报一一有关充足理解测试人员正在做什么和怎样做日勺汇报，以此来给 测试人员做做工作成绩考核。这份汇报要理解到每个

11、人的动态。测试经理和每个员工重点是谈谈目前的工作，例如大家在工作中的J问题或意见；与否需 要协助等。许多管理者常常埋怨没有时间在一周会见每一种员工来谈他们的工作。不过根据 作者的经验，假如不能安排时间和员工进行每周H勺谈话，员工会来打扰测试经理H勺工作，由 于员工诸多问题还要要来找测试经理商议。同步看待员工要用他们能接受的I方式，而不是我们自己可以接受的方式。“己所不予， 勿施于人”，这条黄金法则也许会对许多生活中的纯粹的社交原因有效，不过并不是总对工 作有用。有效率的管理者懂得应当逐渐理解每一种员工需要怎样的看待方式。总之，只有尽量多的和员工接触，才能更精确H勺进行考核。11、测试经理怎样面

12、对加班问题？大多数状况下，作者是不主张加班的。当员工每周工作超过40个小时的时候，他们开 始在工作口勺时候关怀自己的事。他们花钱，会给很久没有联络的人打，由于员工们一直 都在工作。员工不能在太疲劳的状态下完毕工作，这是由于他们在工作时不能关怀自己，这 种状况下一般效率很低。测试管理工作的重要任务之一就是要发明一种环境，让员工在工作时间内完毕工作，同 步还要鼓励他们每周不要超过40小时，甚至可以基于他们在40个小时可以完毕的工作量给 他们酬劳。一般状况下这样做可以提高发明力，从而会逐渐提高效率。测试工作自身H勺一种突出特点就是不停反复枯燥、冗长的测试，假如在疲劳状态下，很 有也许精力不集中，略过

13、某些重要日勺测试环节。并且有的时候测试需要编写测试驱动程序, 这种状况更需要很好的I状态来工作。12、测试管理者怎样面对自己的错误？每个人都会出错。我们也许会由于忘掉开会而使客户发火，承认自己出错是一件尴尬H勺 事情，尤其是管理人员认为对自己负责的I项目小组承认出错也许会失去尊严。假如我们不是 常常出错，承认错误的I时候其实可以赢得尊敬。例如我们忘掉一次会议，然后为此向同事或 者客户道歉，其他的人会理解我们的I。不管做了什么，不要否认或故意忽视自己的失误。故意忽视不会让错误消失，这只会让 错误成长为怪物。13、为何计划定期的培训？测试工作和开发工作同样，不仅要面对日新月异的新技术，还要学习有关

14、系统的领域知 识。只有在不停口勺学习中，才能做好工作，跟上行业的发展。假如测试管理者没有基于不停 的变化而培训员工，就会给组织带来一定日勺损失。平常培训可以是有关特定项目或者是技术, 一般采用下面几种措施：(1)测试部门内自由交流方式的培训。这种培训的交流比较随意，可以在周五的例会 上进行交流，也可以大家一起坐在茶馆里进行交流。措施可以采用“头脑风暴法”，让每个 组员讨论一种特定日勺领域，这种交流措施尤其对同步要做诸多不一样项目的小组比较有益 处。当每个人做不一样的项目，这会有助于每个人理解你小组所有H勺工程。(2)跨部门口勺互相学习。测试工作需要诸多领域以及技术知识，这些知识单靠自学是 远远

15、不够日勺。和其他部门日勺同事进行交流是一种相称好日勺措施，大家在工作中可以在技术等 各个方面互相得到提高。(3)外部培训。外部培训尽管投入较高，但也是值得的。这些专家一般在自己的领域 非常精通，可以迅速提高整个测试团体的水平。也可以通过测试小组简介某些朋友来进行培 训，这种方式可以减少成本。培训是构造学习型组织的I基本条件，也是提高员工水平日勺重要措施。常常的定期培训I, 可以增强组织凝聚力，使员工愈加乐意长期留在组织中发展。做为测试负责人，定期的进行 培训是十分必要日勺。14、时间上不容许进行所有测试，测试负责人应当怎样做？这个问题也许十分可笑，可是现实中我们的测试经理们却不得不面对这个问题

16、。这里日勺 所有测试不是指对软件进行遍历测试，而是指测试负责人制定的测试计划包括的所有测试内 容。一般，不管是开发产品还是做详细区I项目，都会发生耽误进度的I状况。一旦整体进度不 能向后延迟，项目有关人员习惯上的做法就是缩减测试时间。尤其在功能还没有开发完毕口勺 状况下，这种现象更为突出。肩负着质量重任的测试经理，怎样来处理这个问题呢？比很好的做法是按照下面的环节 逐渐来完毕和改善工作：(1)按照测试任务时轻重缓急，尽最大努力完毕测试任务。在时间局限性的状况下， 我们应当对测试任务按照优先级来划分，重要紧急的任务先完毕。这个时候的测试任务是一 种辅助性工作，其目的就是尽最大努力来提高质量。因此

17、，面对这种状况，测试负责人要做 时就是带领测试小组充足运用所有资源来保证质量。（2）在实际工作中和开发人员共同配合，逐渐改善工作。只有整个团体的J软件开发能 力提高了，才能从本源上处理问题。因此，测试负责人要带领团体和开发小组共同寻找适合 自己的开发模式，从而使项目规划欧I愈加合理，进而按照预定计划来开展测试工作。总之，在任何状况下，测试负责人都不应当埋怨。只有积极日勺面对问题，才能更好日勺处 理问题。15、企业不重视测试，测试负责人怎样开展测试工作？目前国内的软件企业不重视测试仍然是一种普遍现象。尽管诸多企业在意识上已经开始 重视测试，不过在详细工作中，往往由于追赶进度、节省资源等方面原因而

18、忽视测试工作。 在这种状况下，测试负责人仍要对软件质量负重要责任。在这种环境下，测试负责人应当怎 样开展工作呢？首先，要积极去配合开发人员完毕工作。尤其是不能埋怨环境，在任何状况下埋怨是不 能处理问题的I,只能加重矛盾的激化。在此基础上，逐渐显出测试工作的重要性，然后再逐 渐健全测试体系。另一方面，用实际行动来证明测试工作日勺重要性。只有测试工作H勺业绩逐渐体现出来, 人们才会真正的注意到测试的重要性。因此，测试负责人从点滴开始做起，才能逐渐做好测 试工作。要想做好软件，把开发的软件产品形成商品，测试工作必须和开发同样重视。否则，质 量不好的产品，很快会被市场淘汰时。现代的软件规模越来越大，测

19、试工作也会越来越重要, 因此测试负责人只要坚持做好工作，可发挥作用的空间会越来越大。最终要说的是，假如真的是在一种没有但愿H勺团体里，测试负责人可以考虑辞职。辞职 也是一种不错的选择，到新的环境去发挥自己的能力，要比长时间时怀着“郁闷”的心情去 工作好日勺多。16、测试管理者需要是技术专家吗？测试管理者在测试项目中的重要任务是制定测试方略，管理测试计划的贯彻状况，并且 还要为测试项目的进行发明良好的执行环境。同步还要调动员工日勺发明性，对员工的工作作 出评估。这些工作不一定规定测试管理者到达专家日勺水平。不过在实际工作中，由于测试人员的短缺，测试管理者常常做为测试员来执行详细的测 试任务。尤其

20、在规模较小H勺测试团体，测试管理者的平常工作一般以详细日勺测试执行工作为 主，这个时候更需要测试管理者有很好的背景知识。总体说来，技术方面的背景知识对测试管理者是十分有益的。例如：分派工作任务、做 进度预算，以及某些详细的I执行工作，都需要一定日勺背景知识。当然，做为一种测试管理者, 没有必要精通所有的技术，那也是办不到的。测试管理者做到对口勺的协助员工最佳地完毕工 作，并且提供最佳日勺完毕工作的环境就可以了。3.测试流程部分1、测试人员要需要何时参与需求分析？原则上，测试人员对需求理解得越深入对测试工作越有利，因此最佳一开始就应当参与 需求分析工作。这样可以带来如下得好处： 测试人员全程参与

21、需求分析，对需求理解很深刻，减少了诸多与开发人员的交互，节省了时间。测试人员参与前期开发讨论，直接掌握了不清晰的需求点； 初期确定测试用例的编写思绪，为测试打好了基础； 可以获取某些测试数据，为测试用力设计提供协助； 可以发现需求不合理日勺地方，减少了测试成本。测试人员重要日勺工作之一就是确认系统与否对日勺实现了需求。测试人员不参与前期的工 作，就只能依赖最终形成日勺需求文档，甚至由开发人员来讲解需求，而这些缺求也许发生了 “问题”，由于这个需求是已经通过度析的J需求，诸多日勺内容也许与顾客日勺真正规定发生了 偏差。同步假如只看最终形成的需求文档，对需求也会有理解上日勺偏差。因此作为测试人员

22、要尽量的I获取到“第一线”的I需求资料，才能真正地理解顾客的I业务，从而更好欧I对系统进 行测试。当然，假如测试人员不能参与需求环节，一定要通过其他途径保证需求的精确性，例如 和开发人员进行集中讨论需求疑问H勺项目会议，并且一定要加强测试案例评审，甚至于是测 试需求日勺评审。2、系统测试阶段低级缺陷较多怎么办？在系统测试阶段，假如仍有诸多低级缺陷，阐明测试对象是不合格的，没有到达测试原 则。假如系统阶段发现的简朴缺陷（也就是不应当有的缺陷）较多，最佳停止测试，转由开 发人员进行测试，发现问题立即修改，由于这种由测试人员进行H勺成本较高，反复交互还会 耽误进度。提议建立预测试制度：系统测试前对关

23、键模块进行抽查测试，假如问题较多（例如平均 每个关键模块发现10个以上缺陷），就可以停止本次测试，直到抽测后发现问题较少才可以2、缺陷是谁“生产”的?这是一种“老生常谈”的问题。尤其在追究某些质量问题责任的I时候。常常听测试人 员埋怨：“这些模块简直是垃圾！不值得测试！挥霍我的时间！”，开发人员则埋怨：“重 要的问题发现不了，却成天盯着那些无关痛痒的小问题，还不如自己去测试！ ”。不符合顾客规定时都可以称之为缺陷，因此缺陷的来源重要有两类：一类是没有对的 理解顾客需求，由系统需求或者分析人员设计出来的缺陷，此类缺陷重要由设计人员“生产”; 此外一类是程序开发人员没有按照设计规定进行开发或者编写

24、的代码存在错误而引起日勺缺 陷，此类缺陷由程序开发人员“生产”。对于那些开发流程不规范日勺组织，一般开发人员会包办测试前日勺大部分工作。在这种 环境下，几乎没有什么设计文档，软件开发重要按照程序设计人员的想像来进行，这个时候 日勺缺陷则重要由开发人员“生产”。测试人员不是缺陷的“生产”者，由于测试人员没有写过一行代码，这与否意味着测 试人员可以在一旁“幸灾乐祸呢”？事实恰好相反，测试人员与缺陷关系愈加亲密，他们是 “缺陷的缺陷”的制造者。所谓“缺陷的缺陷”，重要指测试人员提交的I “不是缺陷”的缺 陷，即测试人员没有对的理解需求，从而提交了主线“不是缺陷”的I缺陷，这种缺陷也是测 试人员常常受

25、到指责的J重要原因。有关上面的J埋怨，测试和开发双方都需要摆正心态：由于实际双方都在不停的J “生产” 着缺陷，只是发明H勺方式不一样罢了。启动系统测试。3、缺陷流落到客户那里有什么后果？假如软件缺陷被遗落并流落到客户那里，成果就是代价高昂时 或者现场支持费用， 还也许需要修复、重新测试和公布新的产品，更糟糕的状况是产品要被召回甚至被客户起诉。 这种成本付出非常高，几乎是在内部修改缺陷的几何级数倍。质量之父PhilipCrosby把质量的1费用分为整合费用和非整合费用两类，整合费用是指与 一次性计划和执行测试有关的所有费用，用于保证软件按照预期方式进行。假如发现缺陷, 通过一系列的I缺陷处理流

26、程而处理缺陷，这种费用就是非整合费用。PhilipCrosby在自己的I 作品中详细论述了内部日勺整合费用和内部日勺非整合费用之和远远不大于外部也就是客户引 起日勺非整合费用。总之，软件缺陷一定要尽量的在内部处理，这对节省成本、提高产品著名度都大有裨益。4、什么是冒烟测试？冒烟测试从操作上是一种随机日勺测试，操作对象一般是关键业务模块。测试员任意操作, 要是发现多数功能走不下去（大概20%）,那么这个冒烟测试就算是结束了。冒烟测试一般 不用参照测试用例。执行冒烟测试的目的是对要测试的产品进行一种大概时度量。假如冒烟测试不能通过, 一般不会启动测试计划。由于软件缺陷较多的状况下，启动测试计划会挥

27、霍更多的人力和物 力。通俗的说，对“垃圾”产品执行测试实际是测试人员抢了程序设计人员日勺工作，这些缺 陷应当在开发阶段消灭，只有这样才可以真正的节省成本。5、在集成测试的时候，已经对某些子系统进行了功能测试、性能测试等等，那么在系统测试时能否跳过相似内容的测试?由于集成测试是在仿真环境中开展的，那不是真正的目的系统。再者，单元测试和集成 测试一般由开发小组执行。根据测试心理学欧I分析，开发人员测试自己的1工作成果虽然是必 要日勺，但不能作为成果已经通过测试的根据。为了保证测试H勺客观性，应当由机构H勺独立测试小组来执行系统测试。6、什么是测试方略?测试方略描述测试工程欧I总体措施和目的。描述目

28、前在进行哪一阶段的测试（单元测试、 集成测试、系统测试）以及每个阶段内在进行的测试种类（功能测试、性能测试、覆盖测试 等）。测试方略的制定重要包括三个方面的内容:（1）确定测试过程要使用日勺测试技术和工具;（2）制定测试启动、停止、完毕原则;（3）进行风险分析和应对方案。例如测试与外部接口或者模拟物理损坏、安全性威胁。测试计划最关键的一步就是将软件分解成单元，按照需求编写测试计划。7、代码会审是怎样进行的J?在研发小组将所开发日勺程序经验证后，提交测试组后，测试实行工作基本开始了。这个 时候，测试人员要仔细阅读有关资料，包括规格阐明、设计文档、使用阐明书及在设计过程 中形成的测试大纲、测试内容

29、及测试的通过准则，全面熟悉系统，编写测试计划，设计测试 用例，作好测试前的准备工作。为了保证测试的质量，我们一般测试过程提成几种阶段，即: 代码审查、单元测试、集成测试和验收测试。代码会审是由一组人通过阅读、讨论和争议对程序进行静态分析欧I过程。会审小组由组 长，23名程序设计和测试人员及程序员构成。会审小组在充足阅读待审程序文本、控制 流程图及有关规定、规范等文献基础上，召开代码会审会，程序员逐句讲解程序rJ逻辑，并 展开热烈日勺讨论甚至争议，以揭示错误日勺关键所在。实践表明，程序员在讲解过程中能发现 许多自己本来没有发现的错误，而讨论和争议则深入促使了问题日勺暴露。例如，对某个局部 性小问

30、题修改措施H勺讨论，也许发现与之有牵连日勺甚至能波及到模块的功阐明、模块间接口 和系统总构造的大问题，导致对需求定义的重定义、重设计验证，大大改善了软件的质量。代码会审尽管需要一定取I成本，不过在大型软件中，是必不可少改I。8、回归测试中未处理的缺陷怎样处理？软件的后期测试就是一种反复回归的工作，有些问题也许修改多次才能处理，尤其是那 些在开发环境下不存在的问题，这些问题很轻易被程序员忽视，拖到最终才处理。因此大部 分回归测试就是和开发人员反复配合处理那些上次测试中没有处理的缺陷。这里重点讨论的是最终一次回归测试后，仍然发既有些缺陷没有处理时测试经理应当怎 样做。在管理不规范的组织中，由于进度

31、或者其他方面日勺压力，开发工作已经停止，一般会 将这些问题置之不理。对时的做法时把这些没有处理欧I问题形成一种未处理缺陷汇报，然后 召开项目会议进行讨论，对不一样口勺问题采用不一样的处理方式：严重性日勺问题：有些问题较难处理，往往会被拖到最终，假如此类缺陷导致软件功能发 生障碍，则必须处理，这也是质量控制的职责所在;功能性的问题：可以考虑升级时处理；一般性问题：不影响使用，可以不处理或者升级处理。此类项目会议一般需要技术总监或者更高级别口勺人来参与。最终，需要对最终讨论没有 处理的I缺陷列表进行签字并存档，形成一种基线。尤其要注意的I某些缺陷与否修改不能由程 序员或者测试人员来决定，这样有也许

32、带来严重日勺后果一一导致缺陷失控，最终形成没有人 对质量负责的局面。9、状态为已经修改的缺陷没有修改怎么办？首先要对此类缺陷进行分析：(1)有些问题在开发环境下没有重现，而开发人员迫于进度压力，往往会把它标识为 已经修改。这种条件下测试人员应当和开发人员进行直接沟通；(2)有些问题测试人员没有描述清晰，开发人员认为问题不存在也也许把问题标识为 已经修改(对时的做法是标识问题为商讨或者不存在状态)。测试人员应当清晰的描述问题, 减少此类问题时发生，尤其要描述清晰运行环境以及缺陷的重现环节；(3)第三类状况纯属个人行为：迫于进度压力，开发人员来不及修改问题，会故意把 某些问题标识为修改，这样就可以

33、在下次测试后进行修改。处理这种问题措施就是记录缺陷 H勺修改次数，分析出那些反复修改的缺陷归属于那些开发人员，然后和绩效考核结合起来。 (测试人员也可以这样做，把某些未验证的缺陷标识为“重新打开”，让开发人员来帮忙“验 证”，我们仍然可以记录这种问题的次数，最终根据时间进行分析。)而处理这种问题的主线措施就是加强项目管理,提高项目执行能力，一旦资源较富余时, 测试人员和开发人员就会愈加投入H勺一起处理缺陷，共同来提高软件质量。10.产品测试完毕后产品谁来公布?诸多时候产品通过最终一次测试后由开发人员来公布，或者由质量管理部来公布，这样 做都是不合适的。开发人员公布产品常常会导致缺陷处理不彻底。

34、一种较常见口勺现象是最终一次回归测试 后，开发人员修改完毕最终几种缺陷直接从开发环境公布产品，节中的案例就是这样的一种 状况，这种条件下实际是缺陷一次测试，由于修改缺陷一般会引入新的缺陷，甚至是严重的I 缺陷。测试人员公布缺陷也是不和流程的，测试人员的职责是汇报软件质量状况。并且测试人 员公布缺陷轻易带来版本管理混乱。对时的做法是产品通过最终一次测试后，把产品和缺陷修改状况存入产品基线库，形成 一种可以公布的版本。这样公布产品的一种前提是每次产品提交测试前都要有一种预备公布 版本，测试或者回归测试后假如有问题需要修改处理，开发人员对该预备版本进行修改。如 此反复多次后，直到最终一次测试，所有缺

35、陷都得到修改或者审核，同步开发人员本次测试 后没有对产品通过任何修改，我们就可以把这个最终一种预备公布版本存入基线库。进行了上面对的的版本控制后，我们可以通过配置管理库进行产品公布管理。对外部公 布产品时，直接从配置管理库中提取就可以了。详细的I内容，读者可以参照配置管理方面欧I 书籍。11、性能测试什么时候开展最为合适？大多数状况下，性能测试在系统测试的最终阶段进行阶段进行。这重要是由于性能测试 是一种综合性的测试，只有在功能测试通过后，谈系统测试才会有较大意义。但下列两类状 况比较特殊，性能测试一般进行日勺较早，几乎伴伴随单元测试同步进行:第一类是系统软件，例如开发操作系统或者数据库，等系

36、统开发完毕后再进行性能日勺唯 一作用就是进行一种综合评估。假如在最终发现性能问题，很有也许推翻整个系统。第二类是对性能规定较高的应用软件。例如银行、电信的系统，对系统的性能要远远高 于一般的办公自动化系统。此类系统软件最终测试时发现性能问题，往往是系统架构或者某 些关键算法、重要功能模块的原因，这个时候会带来较大的改动，甚至也许报废整个系统。对于上面两类软件，性能测试应当贯穿着整个软件开发过程，大体要通过下面几种测试 过程：(1)单元性能测试阶段。上面这两类软件的性能测试最终从单元测试阶段就应当介入, 详细做法就是安排性能测试工程师对某些重要算法进行测试，保证这些算法可以满足性能规 定。这样做

37、的好处是把问题尽早处理，可以大大提高整体性能。(2)构成/集成性能测试阶段。这个阶段的性能测试是前面的深入，相称于把系统测试 阶段的组合业务性能测试提前进行，可以把某些性能问题在集成测试阶段发现并处理。(3)系统测试阶段的性能测试。这个阶段的性能测试是一种全面的性能测试，有了前 面日勺基础，这个时候发现日勺问题很愈加轻易处理。总之，性能测试是十分重要并且投入较高的测试，开展性能要根据详细的软件属性以及 其他实际状况来制定测试方略。3、缺陷产生的原因是什么?在上个问题中，已经简介了设计人员、开发人员、测试人员都会“生产”软件缺陷。在 实际工作中，缺陷产生的方式更是层出不穷，原因也是多种多样。例如

38、开发人员去接杯水， 碰巧和此外一种接水日勺同事聊了几句，成果回到工位时忘掉了要在某个判断语句追加此前已 经想好日勺一种判断条件，这无疑会产生一种缺陷。因此很难一下子把缺陷产生的原因所有陈 列出来，下面只是某些引起缺陷的经典原因：（1）开发人员不太理解需求，不清晰应当“做什么”和“不做什么”，常常做不合需 求H勺事情，因此产生了缺陷；（2）软件系统越来越复杂，开发人员不太也许精通所有的技术。假如不能对时地掌握 新口勺技术或者知识，也许会产生缺陷；（3）技术文档普遍编写的I很差，甚至文档自身就有缺陷，导致使用者产生更多的缺陷;（4）软件需求、设计汇报、程序常常发生变更，每次变更都也许产生新日勺缺陷

39、；（5）任何人在编程时都也许出错误，导致程序中有缺陷；（6）技术人员常处在进度的压力之下，不能静心思索也很轻易产生缺陷，尤其是在 Deadline临近之际，频繁日勺加班是开发人员疲于应付进度；（7）诸多开发人员过于自信，喜欢说“没问题”，因此对于某些代码不进行认真的I调 试，这也是某些缺陷产生H勺原因；（8）频繁H勺拷贝代码也会把缺陷随之复制到新的程序中，尤其是复制其他团体组员日勺代码更轻易使某些缺陷隐藏在程序中。4、软件的质量应当由什么人来负责?对于某些开发管理混乱或者测试刚刚起步的组织，产品质量一发生问题，习惯上会归 咎于测试小组，认为测试人员没有测试好产品，因此才产生了那么多的缺陷。对于

40、开发管理规范某些或者测试体系已经建立一定期间口勺组织，假如客户投诉产品质 量问题，则往往开发人员与测试人员会一起接受惩罚。这种处理方式多少会让测试人员心理 稍稍平衡某些。追根溯源，软件发生质量问题实际是项目管理不规范引起的。因此，假如要追究责任 的话，软件质量问题的责任应当由整个团体来承担。只有提高整个团体H勺开发水平，才能提 高质量。此外，也应当认识到软件发现问题是正常的1现象，很少有软件实现了零缺陷。做为企 业领导者，应当详细问题详细分析，不要老是考虑怎样惩罚自己的组员。5、测试能保证质量吗？在软件质量方面，目前多数IT企业重要采用三种措施：技术评审、过程检查、软件测 试。技术评审：技术评

41、审最初是由IBM企业为了提高软件质量和提高程序员工作效率而采 用日勺，重要指对项目计划、软件需求、系统设计等文档进行有效评审日勺过程。技术评审可以 由专家团体构成，也可以由组织内部人员构成,它可以尽量防止设计人员在某些方面发生“闭 门造车”口勺情形。通过技术评审，可以尽早地发现工作成果中的缺陷，并协助开发人员及时消除缺陷， 从而有效地提高产品的质量。过程检查：属于质量工程师（QA）欧I工作范围，重耍检查软件项目的I “工作过程和工 作成果”与否符合已经制定的有关规范。在项目执行过程中，质量保证人员要不停日勺按照项 目计划对项目进行有效的监督和检查。通过过程检查，可以找出明显不符合规范日勺工作过

42、程或者工作成果，及时纠正开发中 的错误。因此，软件测试只是保证质量日勺最常用手段，仅仅通过测试是不可以保证质量的，还 要辅以技术评审、过程检查等手段。6、测试人员与否需要开发技能？在诸多测试网站的论坛上，这个问题都是津津乐道的热门话题。而究其本源，重要是由 于诸多测试人员做不了开发才来做测试，于是其中日勺诸多人便怀着某些“胆怯”心理，与同 行反复探讨这个问题，期望其他人可以肯定“虽然不会开发也能做好测试”日勺观点，以便 在心理上得到某些安慰。与否需要开发技能与测试人员从事的测试工作种类有极大关系，相信诸多人都听过微软 曾经聘任一名家庭主妇来测试Windows操作系统的故事。实际上，假如从事单元

43、测试、集 成测试等较靠近程序代码的工作，无疑需要开发技能，此类工作对测试人员开发技能的规定 甚至会超过程序员；而从事基本的界面测试、顾客功能测试，不会开发不会有大的影响。不过，原则上还是提议测试人员最佳具有一定日勺开发能力，并且是开发能力越强越好, 开发技能对测试工作可以说是“百利而无一害”，例如可以更轻易防止汇报反复H勺缺陷、对 缺陷原因进行更精确的定位等等。同步，由于国内多数企业对测试人员没有分类，要想得到 更多的I发展机会，也应当学会开发，便于从事多种类型的测试工作，除非只从事那些远离代 码区I测试工作。此外，掌握一门开发语言后，进行测试的时候可以站在程序开发的角度进行思索，并且 懂得程

44、序怎样编写，就更轻易发现问题。7、测试的目的是什么？测试日勺目的是为了发现尽量多的I缺陷，这个观念很轻易让人接受，不过却很难贯彻到实 际工作中，由于测试的目曰勺常常被定位为“证明软件没有问题”。软件质量与否优良在投产 后才能有所体现。对的理解测试的目的十分重要。假如认为测试的目的是为了阐明程序中没有缺陷，那么 测试人员就会向这个目的靠拢，因而下意识地设计诸多不易暴露错误的测试示例，这些测试 用例恰恰证明软件实现了预期功能，这样日勺测试是不真实日勺。成功的测试在于发现了迄今尚 未发现的缺陷，测试人员的职责是设计这样的测试用例一一它能有效地揭示潜伏在软件里H勺 缺陷。8、一种软件产品测试结束时没有

45、发现任何新日勺缺陷，这样日勺软件质量一定好吗？测试只能证明缺陷存在，不能证明缺陷不存在。而彻底的、全面日勺测试又难以成为现实, 现实中要考虑时间、费用等限制，不容许无休止地测试。一般日勺测试结束，只是满足一定条 件下的测试结束，最终的“测试”还是交给了顾客。因此，虽然测试结束了，质量也不一定好。例如测试小组在时间紧迫日勺状况下，只测试 了关键模块，这样H勺软件系统质量一般不会好。9、测试中的80-20原则是什么？测试中欧180-20原则是说一般状况下，在分析、设计、实现阶段的复审和测试工作可以 发现和防止80%的Bug,而系统测试又能找出其他Bug中欧I 80%,最终的I 5%欧I Bug也许

46、只 有在顾客日勺大范围、长时间使用后才会暴露出来。由于测试只可以保证尽量多地发现错误, 无法保证可以发现所有的I错误。尚有就是一般状况下80%的缺陷汇集在20%的关键关键业 务模块中。10测试到Zero-bug是测试工作的目日勺和原则吗？一般对于相对复杂的产品或系统来说，Zero-bug是一种理想，Good-enough是我们的原 则。Good-enough原则就是一种权衡投入/产出比日勺原则：不充足的J测试是不负责任区I；过度 的测试是一种资源的挥霍，同样也是一种不负责任的体现。执行测试工作的关键在于：怎样 界定什么样的测试是不充足的，什么样的测试是过度的。处理这一问题的一般措施是制定最 低

47、测试通过原则和测试内容，然后详细问题详细分析。11、一般测试工作要到达什么目的？(1)保证产品完毕了它所承诺或公布的功能。这一目欧I就是软件要符合需求，开发出欧I软 件应当到达所有功能均有明确的书面阐明-在某种意义上与IS09001是同一种思想，测 试的首要目的就是保证所有预定功能是存在并且通过规范日勺测试。当然书面文档时不健全甚至不对时会导致测试效率低下、测试目的不明确和测试范围不 充足，进而导致最终测试欧I作用不能充足发挥、测试效果不理想。因此详细问题一定要详细 分析，一种好的测试负责人尽量来弥补这些文档缺陷。（2）保证产品满足性能和效率的规定。目前日勺顾客对软件的性能方面日勺规定越来越高

48、，使 用起来系统运行效率低（性能低）、或顾客界面不友好、顾客操作不以便（效率低）的产品市场 空间肯定会越来越小。因此通过测试改善性能也是测试工作一种目的I。实际上顾客最关怀的不是软件的技术有多先进、功能有多强大，而是能从这些技术、这 些功能中得到多少好处。也就是说，顾客关怀的是他能从中取出多少，而不是你已经放进去 多少。（3）保证产品是强健的、适应顾客环境的。强健性即稳定性，是产品质量的基本规定，尤 其对于一种用于事务关键或时间关键的工作环境中日勺应用系统。软件只有稳定的运行，才会 不致于中断顾客日勺工作，因此通过强健性测试是软件测试工作的又一种目日勺。2.测试管理部分1、测试负责人要进行严格日勺测试进度跟踪吗？诸多时候，由于人力资源的局限性，测试项目负责人都是在执行测试，这样就使整个项 目缺乏控制，某些问题（例如：有些组员的I缺陷质量不够合格；开发人员修改不及时，系统 某些功能发生严重问题导致部分功能无法测试。）得不到处理，耽误了进度。因此测试负责 任必须全程监控项目，尽量多的掌握信息。一般，测试负责人需要完毕下面这些内容的管理 工作： 测试用例执行状况； 每个测试员提交的缺陷状况