超全的测试企业面试题

1、你认为做好测试计划工作的关键是什么？

参考答案：
说明:软件测试计划就是在软件测试工作正式实施之前明确测试的对象，并且通过对资源、时间、风险、测试范围和预算等方面的综合分析和规划，保证有效的实施软件测试；

做好测试计划工作的关键 ：目的，管理，规范

1. 明确测试的目标，增强测试计划的实用性
   编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确
   2．坚持“5W”规则，明确内容与过程
   “5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。
   3．采用评审和更新机制，保证测试计划满足实际需求
   测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。
2. 分别创建测试计划与测试详细规格、测试用例
   应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。

2、简述软件系统中用户文档的测试要点

（1）读者群。文档面向的读者定位要明确。对于初级用户、中级用户以及高级用户应该有不同的定位
（2）术语。文档中用到的术语要适用与定位的读者群，用法一致，标准定义与业界规范相吻合。
（3）正确性。测试中需检查所有信息是否真实正确，查找由于过期产品说明书和销售人员夸大事实而导致的错误。检查所有的目录、索引和章节引用是否已更新，尝试链接是否准确，产品支持电话、地址和邮政编码是否正确。
（4）完整性。对照软件界面检查是否有重要的分支没有描述到，甚至是否有整个大模块没有描述到。
（5）一致性。按照文档描述的操作执行后，检查软件返回的结果是否与文档描述的相同。
（6）易用性。对关键步骤以粗体或背景色给用户以提示，合理的页面布局、适量的图表都可以给用户更高的易用性。需要注意的是文档要有助于用户排除错误。不但描述正确操作，也要描述错误处理办法。文档对于用户看到的错误信息应当有更详细的文档解释。
（7）图表与界面截图。检查所有图表与界面截图是否与发行版本相同。
（8）样例与示例。像用户一样载入和使用样例。如果是一段程序，就输入数据并执行它。以每一个模块制作文件，确认它们的正确性。
（9）语言。不出现错别字，不要出现有二义性的说法。特别要注意的是屏幕截图或绘制图形中的文字。
（10）印刷与包装。检查印刷质量；手册厚度与开本是否合适；包装盒的大小是否合适；有没有零碎易丢失的小部件等等。

3、所有的软件缺陷都能修复吗？所有的软件缺陷都要修复吗？
参考答案：
从技术上讲，所有的软件缺陷都是能够修复的，但是没有必要修复所有的软件缺陷。测试人员要做的是能够正确判断什么时候不能追求软件的完美。对于整个项目团队，要做的是对每一个软件缺陷进行取舍，根据风险决定那些缺陷要修复。
发生这种现象的主要原因如下：
没有足够的时间资源。在任何一个项目中，通常情况下开发人员和测试人员都是不够用的，而且在项目中没有预算足够的回归测试时间，再加上修改缺陷可能引入新的缺陷，因此在交付期限的强大压力下，必须放弃某些缺陷的修改。
有些缺陷只是特殊情况下出现，这种缺陷处于商业利益考虑，可以在以后升级中进行修复。
不是缺陷的缺陷。我们经常会碰到某些功能方面的问题被当成缺陷来处理，这类问题可以以后有时间时考虑再处理。

最后要说的是，缺陷是否修改要由软件测试人员、项目经理、程序员共同讨论来决定是否修复，不同角色的人员从不同的角度来思考，以做出正确的决定。

4、对 RUP.CMM,CMMI,XP,PSP.TSP 的认识？
参考答案：软件过程标准：CMMI、PSP、TSP、RUP、软件工程规范国家标准；（AP、XP、ASD 等开发过程思想好像还不能称其为标准）

RUP（Rational Unified Process）是 Rational 公司提出的一套开发过程模型，它是一个面向对象软件工程的通用业务流程。它描述了一系列相关的软件工程流程，它们具有相同的结构，即相同的流程构架。RUP 为在开发组织中分配任务和职责提供了一种规范方法，其目标是确保在可预计的时间安排和预算内开发出满足最终用户需求的高品质的软件。RUP 具有两个轴，一个轴是时间轴，这是动态的。另一个轴是工作流轴，这是静态的。
在时间轴上，RUP 划分了四个阶段：初始阶段、细化阶段、构造阶段和发布阶段。每个阶段都使用了迭代的概念。在工作流轴上，RUP 设计了六个核心工作流程和三个核心支撑工作流程，核心工作流轴包括：业务建模工作流、需求工作流、分析设计工作流、实现工作流、测试工作流和发布工作流。核心支撑工作流包括：环境工作流、项目管理工作流和配置与变更管理工作流。RUP 汇集现代软件开发中多方面的最佳经验，并为适应各种项目及组织的需要提供了灵活的形式。作为一个商业模型，它具有非常详细的过程指导和模板。但是同样由于该模型比较复杂，因此在模型的掌握上需要花费比较大的成本。尤其对项目管理者提出了比较高的要求。

CMM(Capability Maturity Model 能力成熟度模型) 由美国卡内基-梅隆大学的软件工程研究所（简称 SEI）受美国国防部委托，于 1991 年研究制定，初始的主要目的是为了评价美国国防部的软件合同承包组织的能力，后因为在软件企业应用 CMM 模型实施过程改进取得较大的成功，所以在全世界范围内被广泛使用，SEI 同时建立了主任评估师评估制度，CMM 的评估方法为 CBA－IPI。CMM 的本质是软件管理工程的一个部分。它是对于软件组织在定义，实现，度量，控制和改善其软件过程的进程中各个发展阶段的描述。他通过 5 个不断进化的层次来评定软件生产的历史与现状：初始层是混沌的过程；可重复层是经过训练的软件过程；定义层是标准一致的软件过程；管理层是可预测的软件过程；优化层是能持续改善的软件过程。CMM/PSP/TSP 即软件能力成熟度模型/ 个体软件过程/群组软件过程，是 1987 年美国 Carnegie Mellon 大学软件工程研究所(CMU/SEI)以 W.S.Humphrey为首的研究组发表的研究成果"承制方软件工程能力的评估方法"。
CMMI 是 SEI 于 2000 年发布的 CMM 的新版本。CMMI 不但包括了软件开发过程改进，还包含系统集成、软硬件采购等方面的过程改进内容。
CMMI 纠正了 CMM 存在的一些缺点，使其更加适用企业的过程改进实施。CMMI 适用 SCAMPI 评估方法。需要注意的是，SEI 没有废除 CMM 模型，只是停止了 CMM 评估方法：CBA－IPI。现在如要进行 CMM评估，需使用 SCAMPI 方法。但 CMMI 模型最终代替 CMM 模型的趋势不可避免。
XP （极限编程）规定了一组核心价值和方法，可以让软件开发人员发挥他们的专长：编写代码。XP 消除了大多数重量型过程的不必要产物，通过减慢开发速度、耗费开发人员的精力（例如干特图、状态报告，以及多卷需求文档）从目标偏离。
XP 的核心价值：交流、简单、反馈、勇气。

5、你的工作通常能在时限内完成吗.（主要是要了解问这个问题的动机是什么）
参考答案：
在有足够的资源和合理的工作量的情况下，完全可以按时完成，并能比一般人做的更好

6、你对测试最大的兴趣在哪里？为什么？
参考答案：
最大的兴趣就是测试有难度，有挑战性！做测试越久越能感觉到做好测试有多难。曾经在网上看到一篇文章，是关于如何做好一名测试工程师。一共罗列了 11，12 点，有部分是和人的性格有关，有部分需要后天的努力。但除了性格有关的 1，2 点我没有把握，其他点我都很有信心做好它。刚开始进入测试行业时，对测试的认识是从网上了解到的一些资料，当时是冲着做测试需要很多技能才能做的好，虽然入门容易，但做好很难，比开发更难，虽然当时我很想做开发（学校专业课我基本上不缺席，因为我喜欢我的专业），但看到测试比开发更难更有挑战性，想做好测试的意志就更坚定了。
不到一年半的测试工作中，当时的感动和热情没有减退一点（即使环境问题以及自身经验，技术的不足，做测试的你一定也能理解）。我觉得做测试整个过程中有 2 点让我觉得很有难度（对我来说，有难度的东西我就非常感兴趣），第一是测试用例的设计，因为测试的精华就在测试用例的设计上了，要在版本出来之前，把用例写好，用什么测试方法写？（也就是测试计划或测试策略），如果你刚测试一个新任务时，你得花一定的时间去消化业务需求和技术基础，业务需求很好理解（多和产品经理和开发人员沟通就能达到目的），而技术基础可就没那么简单了，这需要你自觉的学习能力，比如说网站吧，最基本的技术知识你要知道网站内部是怎么运作的的，后台是怎么响应用户请求的？测试环境如何搭建？这些都需要最早的学好。至少在开始测试之前能做好基本的准备，可能会遇到什么难题？需求细节是不是没有确定好？这些问题都能在设计用例的时候发现。第二是发现 BUG 的时候了，这应该是测试人员最基本的任务了，一般按测试用例开始测试就能发现大部分的 bug，还有一部分 bug 需要测试的过程中更了解所测版本的情况获得更多信息，补充测试用例，测试出 bug。
还有如何发现 bug？这就需要在测试用例有效的情况下，通过细心和耐心去发现 bug 了，每个用例都有可能发现bug，每个地方都有可能出错，所以测试过程中思维要清晰（测试过程数据流及结果都得看仔细了，bug 都在里面发现的）。如何描述 bug 也很有讲究，bug 在什么情况下会产生，如果条件变化一点点，就不会有这个 bug，以哪些最少的操作步骤就能重现这个 bug，这个 bug 产生的规律是什么？如果你够厉害的话，可以帮开发人员初
步定位问题。
7、你以前工作时的测试流程是什么？
参考答案：（灵活回答）
公司对测试流程没有规定如何做，但每个测试人员都有自己的一套测试流程。我说下我 1 年来不断改正（自己总结，吸取同行的方法）后的流程吧。需求评审（有开发人员，产品经理，测试人员，项目经理）－>需求确定(出一份确定的需求文档)－>开发设计文档（开发人员在开始写代码前就能输出设计文档）－>想好测试策略，写出测试用例－>发给开发人员和测试经理看看（非正式的评审用例）－>接到测试版本－>执行测试用例（中间可能会补充用例）－>提交 bug（有些 bug 需要开发人员的确定（严重级别的，或突然发现的在测试用例范围之外的，难以重现的），有些可以直接录制进 TD）－>开发人员修改（可以在测试过程中快速的修改）－>回归测试（可能又会发现新问题，再按流程开始跑）。

软件测试行业中的TD是一种测试管理工具，英文全称;Test Director，主要用来管理需求，bug缺陷，测试计划，测试用例，测试报告. 详情请见：参考资料
https://zhidao.baidu.com/question/323576333.html

8、当开发人员说不是 BUG 时，你如何应付？
参考答案：
开发人员说不是 bug，有 2 种情况，一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动，3 方商量确定好后再看要不要改。二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是 BUG 的依据是什么？如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。其实有些真的不是 bug，我也只是建议的方式写进 TD中，如果开发人员不修改也没有大问题。如果确定是 bug 的话，一定要坚持自己的立场，让问题得到最后的确认。

9、你在你所在的公司是怎么开展测试工作的？是如何组织的？
参考答案：分析需求，分解需求→制定测试计划→设计测试用例→执
行测试用例→提交 bug→验证 bug→测试报告→测试总结
具体的可根据自己公司的情况作删减。

10、你认为理想的测试流程是什么样子？
请参考第 9 题答案

11、软件测试活动的生命周期是什么？
参考答案：
定义：软件从产生到报废的生命周期。
生命周期包括：问题的定义及规划（开发方与需求方讨论）、需求分
析、软件设计、软件编码、软件测试（单元测试、集成测试、系统测
试、验收测试）、运营维护阶段。（行业性概念）

12、测试结束的标准是什么？
参考答案：
用例全部测试。覆盖率达到标准。缺陷率达到标准。其他指标达到质量标准

13、什么是测试评估？测试评估的范围是什么？
参考答案：
软件测试评估是指对未正式投入商业化使用的软件进行预先的小规模试验，又称小试。主要是由代码审查和合理性分析组成。

作用如下：

1. 开发人员若得知他们的代码会被测试评估，他们会更加努力工作。
2. 软件测试评估可以改进开发人员的编程技术
3. 软件测试评估有利于导师制度，程序员们会学到更多
4. 软件测试评估可以实现优质文化的传承
5. 软件测试评估可以激发团队凝聚力
   评估的范围很广,例如功能，性能，美观，易用性的，健壮性的，安全性的，兼容性，效率等软件好坏的的衡量指标，可以参考需求
   测试评估的范围：功能，性能，界面，实用性，速度，兼容性，易用性，各模块的完善性等