软件测试必问必背面试题

01. 请描述如何划分缺陷与错误严重性和优先级别？
给软件缺陷与错误划分 严重性和优先级的通用原则：

• 1.表示软件缺陷所造成的危害和恶劣程度。
• 2.优先级表示修复缺陷的重要程度和次序。

严重性：

• 1.严重：系统崩溃、数据丢失、数据毁坏
• 2.较严重：操作性错误、结果错误、遗漏功能
• 3.一般：小问题、错别字、UI布局、罕见故障
• 4.建议：不影响使用的瑕疵或更好的实现。

优先级：

• 1.最高优先级：立即修复，停止进一步测试。
• 2.次高优先级：在产品发布之前必须修复。
• 3.中等优先级：如果时间允许应该修复。
• 4.最低优先级：可能会修复，但是也可能发布。

02. 一套完整的测试应该由哪些阶段组成？分别阐述一下各个阶段。
一套完整的测试应该由五个阶段组成：

• 1.测试计划：首先根据用户需求报告中关于功能要求和性能指标的规格说明书，定义相应的测试需求报告，即制订黑盒测试的最高标准，以后所有的测试工作都将围绕着测试需求来进行，符合测试需求的应用程序即是合格的，反之即是不合格的；同时，还要适当选择测试内容，合理安排测试人员、测试时间及测试资源等。
• 2.测试设计将测试计划阶段制定的测试需求分解、细化为若干个可执行的测试过程，并为每个测试过程选择适当的测试用例（测试用例选择的好坏将直接影响到测试结果的有效性）。
• 3.测试开发建立可重复使用的自动测试过程。
• 4.测试执行执行测试开发阶段建立的自动测试过程，并对所发现的缺陷进行跟踪管理。测试执行一般由单元测试、组合测试、集成测试、系统联调及回归测试等步骤组成，测试人员应本着科学负责的态度，一步一个脚印地进行测试。
• 5.测试评估结合量化的测试覆盖域及缺陷跟踪报告，对于应用软件的质量和开发团队的工作进度及工作效率进行综合评价。

03. 一条软件缺陷都记录了哪些内容？

• 1.通用UI要统一、准确缺陷报告的UI要与测试的软件UI保持一致，便于查找定位。
• 2.尽量使用业界惯用的表达术语和表达方法使用业界惯用的表达术语和表达方法，保证表达准确，体现专业化。
• 3.每条缺陷报告只包括一个缺陷每条缺陷报告只包括一个缺陷，可以使缺陷修正者迅速定位一个缺陷，集中精力每次只修正一个缺陷。校验者每次只校验一个缺陷是否已经正确修正。
• 4.不可重现的缺陷也要报告首先缺陷报告必须展示重现缺陷的能力。不可重现的缺陷要尽力重现，若尽力之后仍不能重现，仍然要报告此缺陷，但在报告中要注明无法再现，缺陷出现的频率。
• 5.明确指明缺陷类型根据缺陷的现象，总结判断缺陷的类型。例如，即功能缺陷、界面缺陷、数据缺陷，合理化建议这是最常见的缺陷或缺陷类型，其他形式的缺陷或缺陷也从属于其中某种形式。
• 6.明确指明缺陷严重等级和优先等级时刻明确严重等级和优先等级之间的差别。高严重问题可能不值得解决，小装饰性问题可能被当作高优先级。
• 7.描述 (Description) ，简洁、准确，完整，揭示缺陷实质，记录缺陷或缺陷出现的位置描述要准确反映缺陷的本质内容，简短明了。为了便于在软件缺陷管理数据库中寻找制定的测试缺陷，包含缺陷发生时的用户界面（UI）是个良好的习惯。例如记录对话框的标题、菜单、按钮等控件的名称。
• 8.短行之间使用自动数字序号，使用相同的字体、字号、行间距短行之间使用自动数字序号，使用相同的字体、字号、行间距，可以保证各条记录格式一致，做到规范专业。
• 9.每一个步骤尽量只记录一个操作保证简洁、条理井然，容易重复操作步骤。
• 10.确认步骤完整，准确，简短保证快速准确的重复缺陷，“完整”即没有缺漏，“准确”即步骤正确，“简短”即没有多余的步骤。
• 11.根据缺陷，可选择是否进行图象捕捉为了直观的观察缺陷或缺陷现象，通常需要附加缺陷或缺陷出现的界面，以图片的形式作为附件附着在记录的“附件”部分。为了节省空间，又能真实反映缺陷或缺陷本质，可以捕捉缺陷或缺陷产生时的全屏幕，活动窗口和局部区域。为了迅速定位、修正缺陷或缺陷位置，通常要求附加中文对照图。
  附加必要的特殊文档和个人建议和注解如果打开某个特殊的文档而产生的缺陷或缺陷，则必须附加该文档，从而可以迅速再现缺陷或缺陷。有时，为了使缺陷或缺陷修正者进一步明确缺陷或缺陷的表现，可以附加个人的修改建议或注解。
• 12.检查拼写和语法缺陷在提交每条缺陷或缺陷之前，检查拼写和语法，确保内容正确，正确的描述缺陷。
• 13.尽量使用短语和短句，避免复杂句型句式软件缺陷管理数据库的目的是便于定位缺陷，因此，要求客观的描述操作步骤，不需要修饰性的词汇和复杂的句型，增强可读性。

04. 简述一下缺陷的生命周期

• 打开 ：表示问题被提交等待有人处理。
• 重新指派 ：问题被重新指派给某人处理。
• 处理 ：问题在处理中，尚未完成。
• 固定 ：确认此问题存在，但暂时不进行处理。
• 回归 ：对已经修复的问题进行回归确认。
  - reopen: 重新打开
• 关闭 ：问题的最后一个状态。

05. 测试用例设计方法都有哪些？

• 1.等价类划分法顾名思义，等价类划分，就是将测试的范围划分成几个互不相交的子集，他们的并集是全集，从每个子集选出若干个有代表性的值作为测试用例。
• 2.边界值分析法长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。选出的测试用例，应选取正好等于、刚刚大于、刚刚小于边界的值，例如，对于在区间min，max的值，测试用例可以记为min，min+，max，max-。
• 3.错误推测法错误推测法是指：在测试程序时，人们可以根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例的方法。
• 4.判定表法又称为策略表，基于策略表的测试，是功能测试中最严密的测试方法。该方法适合于逻辑判断复杂的场景，通过穷举条件获得结果，对结果再进行优化合并，会得到一个判断清晰的策略表。
• 5 .正交实验法 用语言描述正交实验法会很抽象难懂，简单说，就是在各因素互相独立的情况下，设计出一种特殊的表格，找出能以少数替代全面的测试用例。其中，上面所说的特殊表格就是正交表，是按照一定规则生成的表。虽然说是特殊的表格，实际表现形式跟一般的表格没有什么区别，正交表的主要特征是，“均匀分布，整齐划一”，正是因为“均匀”的，所以才能以少数代替全部。

06. 一个文本框要求输入6位数字密码，且对每个账户每次只允许出现三次输入错误，对此文本框进行测试设计的等价区间有哪些？

• 1.密码为空 登录
• 2.正确输入[输入正确的值] 登录
• 3.错误输入[ 输入错误的值，
  • 输入数据例如：特殊符号、英文字母、汉字及非法字符等一些非正确值；
  • 输入方法例如：不足六位，超出六位，最大输入值） 登录/取消 ]
• 4.连续错误输入三次以上 [查看连续错误输入后的提示信息及结果]
• 5.其他[是否支持剪贴板操作，例如：复制/剪切/粘贴]

07. 您认为在测试人员同开发人员的沟通过程中，如何提高沟通的效率和改善沟通的效果?维持测试人员同开发团队中其他成员良好的人际关系的关键是什么?

• 尽量面对面的沟通，其次是能直接通过电话沟通，如果只能通过Email等非及时沟通工具的话，强调必须对特性的理解深刻以及能表达清楚。
• 运用一些测试管理工具如TestDirector进行管理也是较有效的方法，同时要注意在TestDirector中对BUG有准确的描述。
• 在团队中建立测试人员与开发人员良好沟通中注意以下几点：
  • 一真诚、二是团队精神、三是在专业上有共同语言、四是要对事不对人，工作至上
  • 当然也可以通过直接指出一些小问题，而不是进入BUG Tracking System来增加对方的好感。

08. 什么是测试用例? 什么是测试脚本？ 两者的关系是什么?

• 测试用例: 为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期望结果的一个特定的集合。
• 测试脚本是为了进行自动化测试而编写的脚本。
• 关系：测试脚本的编写必须对应相应的测试用例

09. 简述什么是静态测试、动态测试、黑盒测试、白盒测试、α测试 β测试

• 静态测试是不运行程序本身而寻找程序代码中可能存在的错误或评估程序代码的过程。
• 动态测试是实际运行被测程序，输入相应的测试实例，检查运行结果与预期结果的差异，判定执行结果是否符合要求，从而检验程序的正确性、可靠性和有效性，并分析系统运行效率和健壮性等性能。
• 黑盒测试一般用来确认软件功能的正确性和可操作性,目的是检测软件的各个功能是否能得以实现,把被测试的程序当作一个黑盒,不考虑其内部结构,在知道该程序的输入和输出之间的关系或程序功能的情况下,依靠软件规格说明书来确定测试用例和推断测试结果的正确性。
• 白盒测试根据软件内部的逻辑结构分析来进行测试,是基于代码的测试，测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量，一般黑盒测试由项目经理在程序员开发中来实现。
• α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。
• β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。

10. 软件质量保证体系是什么? 国家标准中与质量保证管理相关的几个标准是什么? 他们的编号和全称是什么?

• SQA由一套软件工程过程和方法组成，以保证(软件的)质量。SQA贯穿整个软件开发过程，(它)应包括需求文档评审、代码控制、代码评审、变更管理、配置管理、版本管理和软件测试。
• 软件质量保证(SQA-Software Quality Assurance)是建立一套有计划，有系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。软件质量保证的目的是使软件过程对于管理人员来说是可见的。它通过对软件产品和活动进行评审和审计来验证软件是合乎标准的。软件质量保证组在项目开始时就一起参与建立计划、标准和过程。这些将使软件项目满足机构方针的要求。

11. 软件产品质量特性是什么?

• 功能性：适应性、准确性、互操作性、依从性、安全性。
• 可靠性：成熟性、容错性、易恢复性。
• 可使用性：易理解性、易学习性、易操作性。
• 效率：在指定的条件下，用软件实现某种功能所需的计算机资源（包括时间）的有效程度。
• 可维护性：易分析性、易变更性、稳定性、易测试性。
• 可移植性： 适应性、易安装性、遵循性、易替换性

12. 软件测试的策略是什么?

• 在一定的软件测试标准、测试规范的指导下，依据测试项目的特定环境约束而规定的软件测试的原则、方式、方法的集合。

13. 软件测试分为几个阶段 各阶段的测试策略和要求是什么?
和开发过程相对应，测试过程会依次经历单元测试、集成测试、系统测试、验收测试
四个主要阶段：

• 单元测试：单元测试是针对软件设计的最小单位––程序模块甚至代码段进行正确性检验的测试工作，通常由开发人员进行。
• 集成测试：集成测试是将模块按照设计要求组装起来进行测试，主要目的是发现与接口有关的问题。由于在产品提交到测试部门前，产品开发小组都要进行联合调试，因此在大部分企业中集成测试是由开发人员来完成的。
• 系统测试：系统测试是在集成测试通过后进行的，目的是充分运行系统，验证各子系统是否都能正常工作并完成设计的要求。它主要由测试部门进行，是测试部门最大最重要的一个测试，对产品的质量有重大的影响。
• 验收测试：验收测试以需求阶段的《需求规格说明书》为验收标准，测试时要求模拟实际用户的运行环境。对于实际项目可以和客户共同进行，对于产品来说就是最后一次的系统测试。测试内容为对功能模块的全面测试，尤其要进行文档测试。

单元测试测试策略：

• 自顶向下的单元测试策略：比孤立单元测试的成本高很多，不是单元测试的一个好的选择。
• 自底向上的单元测试策略：比较合理的单元测试策略，但测试周期较长。
• 孤立单元测试策略：最好的单元测试策略。

集成测试的测试策略：

• 大爆炸集成：适应于一个维护型项目或被测试系统较小
• 自顶向下集成：适应于产品控制结构比较清晰和稳定;高层接口变化较小;底层接口未定义或经常可能被修改;产口控制组件具有较大的技术风险，需要尽早被验证;希望尽早能看到产品的系统功能行为。
• 自底向上集成：适应于底层接口比较稳定;高层接口变化比较频繁;底层组件较早被完成。
  基于进度的集成
• 优点：具有较高的并行度;能够有效缩短项目的开发进度。
• 缺点：桩和驱动工作量较大;有些接口测试不充分;有些测试重复和浪费。

系统测试的测试策略：

• 数据和数据库完整性测试;
• 功能测试;
• 用户界面测试;
• 性能评测;
• 负载测试;
• 强度测试;
• 容量测试;
• 安全性和访问控制测试;
• 故障转移和恢复测试;
• 配置测试;
• 安装测试;
• 加密测试;
• 可用性测试;
• 版本验证测试;
• 文档测试

14. 软件测试各个阶段通常完成什么工作?各个阶段的结果文件是什么?包括什么内容?

• 单元测试阶段：各独立单元模块在与系统地其他部分相隔离的情况下进行测试，单元测试针对每一个程序模块进行正确性校验，检查各个程序模块是否正确地实现了规定的功能。生成单元测试报告，提交缺陷报告。
• 集成测试阶段：集成测试是在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。该阶段生成集成测试报告，提交缺陷报告。
• 系统测试阶段：将通过确认测试的软件，作为整个给予计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行全面的功能覆盖。该阶段需要提交测试总结和缺陷报告。

15. 软件生命周期(SDLC)的六个阶段

• 1、问题的定义及规划
  此阶段是软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。
• 2、需求分析
  在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段，这一阶段做得好，将为整个软件开发项目的成功打下良好的基础。“唯一不变的是变化本身。”，同样需求也是在整个软件开发过程中不断变化和深入的，因此我们必须制定需求变更计划来应付这种变化，以保护整个项目的顺利进行。
• 3、软件设计
  此阶段主要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计，数据库设计等等。软件设计一般分为总体设计和详细设计。好的软件设计将为软件程序编写打下良好的基础。
• 4、程序编码
  此阶段是将软件设计的结果转换成计算机可运行的程序代码。在程序编码中必须要制定统一，符合标准的编写规范。以保证程序的可读性，易维护性，提高程序的运行效率。
• 5、软件测试
  在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。整个测试过程分单元测试、组装测试以及系统测试三个阶段进行。测试的方法主要有白盒测试和黑盒测试两种。在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试，以减少测试的随意性。
• 6、运行维护
  软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后，由于多方面的原因，软件不能继续适应用户的要求。要延续软件的使用寿命，就必须对软件进行维护。软件的维护包括纠错性维护和改进性维护两个方面。

16. 软件生命周期模型
在经历需求、分析、设计、实现、部署后，软件将被使用并进入维护阶段，直到最后由于缺少维护费用而逐渐消亡。这样的一个过程，称为"生命周期模型"（Life Cycle Model）。

• 典型的几种生命周期模型包括瀑布模型、快速原型模型、迭代模型。
  • 瀑布模型的特点（文档是主体），很多的问题在最后才会暴露出来。
  • 迭代模型比瀑布模型问题暴露的要早；
  • 快速原型法比瀑布模型直观。

17. 软件测试概念

• 广义概念：指软件生存周期中所有的检查、评审和确认工作，其中包括了对分析、设计阶段，以及完成开发后维护阶段的各类文档、代码的审查和确认
• 狭义概念：识别软件缺陷的过程，即实际结果与预期结果的不一致

18. 软件测试目的

• 测试的目的就是发现软件中的各种缺陷
• 测试只能证明软件存在缺陷，不能证明软件不存在缺陷
• 测试可以使软件中缺陷降低到一定程度，而不是彻底消灭
• 以较少的用例、时间和人力找出软件中的各种错误和缺陷，以确保软件的质量

19. 软件测试原则

• Good-enough: 一种权衡投入/产出比的原则
• 保证测试的覆盖程度，但穷举测试是不可能的
• 所有的测试都应追溯到用户需求
• 越早测试越好，测试过程与开发过程应是相结合的
• 测试的规模由小而大，从单元测试到系统测试
• 为了尽可能地发现错误，应该由独立的第三方来测试
• 不能为了便于测试擅自修改程序
• 既应该测试软件该做什么也应该测试软件不该做什么

20. 软件测试的的重点
测试用例的设计

• 测试用例的设计是整个软件测试工作的核心
• 测试用例反映对被测对象的质量要求，决定对测试对象的质量评估

测试工作的管理

• 尤其是对包含多个子系统的大型软件系统，其测试工作涉及大量人力和物力，有效的测试工作管理是保证有效测
  试工作的必要前提

测试环境的建立

• 测试环境应该与实际测试环境一致

21. 什么是黑盒测试?

• 又称功能测试或数据驱动测试，是针对软件的功能需求/实现进行测试，通过测试来检测每个功能是否符合需求，不考虑程序内部的逻辑结构
• 黑盒测试方法
  • 功能划分
  • 等价类划分
  • 边界值分析
  • 因果图
  • 错误推测等

22. 什么是白盒测试

• 白盒测试也称结构测试或逻辑驱动测试，必须知道软件内部工作过程，通过测试来检测软件内部是否按照需求、设计正常运行
• 白盒测试的主要方法 是：
  • 语句覆盖方法
  • 分支覆盖方法
  • 逻辑覆盖方法

23. 什么是动态测试

• 动态测试需要在开发/测试环境或实际运行环境中运行软件，并使用测试用例去查找软件缺陷；动态测试包括功能确认与接口测试、覆盖率分析、性能分析、内存分析等

24. 什么是静态测试

• 静态测试不实际运行软件，主要是对软件的编程格式、结构等方面进行评估。静态测试包括代码检查、程序结构分析、代码质量度量等。它可以由人工进行，也可以借助软件工具自动进行

25. 手工测试和自动测试

• a.手工测试缺点在于测试工作量大，重复多，回归测试难以实现
• b.自动测试利用软件测试工具自动实现全部或部分测试工作：管理、设计、执行和报告；节省大量的测试开销，并能够完成一些手工测试无法实现的测试
• 手工完成测试的全部过程无法保证测试的科学性与严密性:
  • 修改的缺陷越多，回归测试越困难
  • 没有人能向决策层提供精确的数据以度量当前的工作进度及工作效率
  • 反复测试带来的倦怠情绪及其他人为因素使得测试标准前后不一
  • 测试花费的时间越长，测试的严格性也就越低
• 自动测试将测试人员从反复、烦杂的测试执行中解放出来，用更多的时间进行测试设计和结果分析
  • 软件测试不可能完全自动化
  • 不能完成所有手工测试任务
  • 无创造性且灵活性差，不能改进测试的有效性
  • 过程中可能会遇到许多意想不到的问题，特别是当软件不稳定时
    测试脚本的维护高

26. 测试流程

• 单元测试
• 集成测试
• 系统测试
• 用户验收测试
• 回归测试

27. 单元测试

• 定义：完成对最小的软件设计单元—模块的验证工作
• 目标是：确保模块被正确地编码
• 使用过程设计描述作为指南，对重要的控制路径进行测试以发现模块内的错误
• 通常情况下是面向白盒的
• 对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试，及早地发现和解决不易显现的错误
• 单元测试的内容
  接口测试
  内部数据结构
  全局数据结构
  边界
  语句覆盖，错误路径

28. 集成测试

• 通过测试发现与模块接口有关的问题
• 目标是把通过了单元测试的模块拿来，构造一个在设计中所描述的程序结构
• 应当避免一次性的集成（除非软件规模很小），而采用增量集成
• 集成测试主要内容
  • API
  • API/参数组合

29. 系统测试

• 根据软件需求规范的要求进行系统测试，确认系统满足需求的要求
• 系统测试人员相当于用户代言人
• 在需求分析阶段要确定软件的可测性，保证有效完成系统测试工作
• 系统测试主要内容
  • 所有功能需求得到满足
  • 所有性能需求得到满足
  • 其他需求（例如安全性、容错性、兼容性等）得到满足

30. 用户验收/确认测试

• Alpha测试：是由用户在开发者的场所来进行的，Alpha测试是在一个受控的环境中进行的
• Beta测试：由软件的最终用户在一个或多个用户场所来进行的，开发者通常不在现场，用户记录测试中遇到的问题并报告给开发者

31. 请说一说黑盒与白盒的测试方法

• 黑盒测试：
  黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。
  “黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，因此不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。
  常用的黑盒测试方法有：等价类划分法；边界值分析法；因果图法；场景法；正交实验设计法；判定表驱动分析法；错误推测法；功能图分析法。
• 白盒测试：
  • 白盒测试也称为结构测试或逻辑驱动测试，是针对被测单元内部是如何进行工作的测试。它根据程序的控制结构设计测试用例，主要用于软件或程序验证。白盒测试法检查程序内部逻辑结构，对所有的逻辑路径进行测试，是一种穷举路径的测试方法，但即使每条路径都测试过了，但仍然有可能存在错误。因为：穷举路径测试无法检查出程序本身是否违反了设计规范，即程序是否是一个错误的程序；穷举路径测试不可能检查出程序因为遗漏路径而出错；穷举路径测试发现不了一些与数据相关的错误。
  • 白盒测试需要遵循的原则有：
    • 1.保证一个模块中的所有独立路径至少被测试一次；
    • 2.所有逻辑值均需要测试真（true）和假（false）；两种情况；
    • 3 检查程序的内部数据结构，保证其结构的有效性；
    • 4.在上下边界及可操作范围内运行所有循环。
  • 常用白盒测试方法：
    • 静态测试：不用运行程序的测试，包括代码检查、静态结构分析、代码质量度量、文档测试等等，它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具（Fxcop）自动进行。
  • 动态测试：需要执行代码，通过运行程序找到问题，包括功能确认与接口测试、覆盖率分析、性能分析、内存分析等。
  • 白盒测试中的逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。六种覆盖标准发现错误的能力呈由弱到强的变化：
    • 1.语句覆盖每条语句至少执行一次。
    • 2.判定覆盖每个判定的每个分支至少执行一次。
    • 3.条件覆盖每个判定的每个条件应取到各种可能的值。
    • 4.判定/条件覆盖同时满足判定覆盖条件覆盖。
    • 5.条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
    • 6.路径覆盖使程序中每一条可能的路径至少执行一次。

32. 软件的生命周期(prdctrm)

• 计划阶段(planning) —>> 需求分析(requirement) -->> 设计阶段(design) -->> 编码(coding) -->> 测试(testing) -->> 运行与维护(running maintrnacne)

33. 请你回答一下单元测试、集成测试、系统测试、验收测试、回归测试这几步中最重要的是哪一步
这些测试步骤分别在软件开发的不同阶段对软件进行测试，我认为对软件完整功能进行测试的系统测试很重要，因为此时单元测试和集成测试已完成，能够对软件所有功能进行功能测试，能够覆盖系统所有联合的部件，是针对整个产品系统进行的测试，能够验证系统是否满足了需求规格的定义，因此我认为系统测试很重要。

34. 请回答集成测试和系统测试的区别，以及它们的应用场景主要是什么？

• 区别：
  • 1、计划和用例编制的先后顺序：从V模型来讲，在需求阶段就要制定系统测试计划和用例，HLD的时候做集成测试计划和用例，有些公司的具体实践不一样，但是顺序肯定是先做系统测试计划用例，再做集成。
  • 2、用例的粒度：系统测试用例相对很接近用户接受测试用例，集成测试用例比系统测试用例更详细，而且对于接口部分要重点写，毕竟要集成各个模块或者子系统。
  • 3、执行测试的顺序：先执行集成测试，待集成测试出的问题修复之后，再做系统测试。
• 应用场景：
  • 集成测试：完成单元测试后，各模块联调测试；集中在各模块的接口是否一致、各模块间的数据流和控制流是否按照设计实现其功能、以及结果的正确性验证等等；可以是整个产品的集成测试，也可以是大模块的集成测试；集成测试主要是针对程序内部结构进行测试，特别是对程序之间的接口进行测试。集成测试对测试人员的编写脚本能力要求比较高。测试方法一般选用黑盒测试和白盒测试相结合。
  • 系统测试：针对整个产品的全面测试，既包含各模块的验证性测试（验证前两个阶段测试的正确性）和功能性（产品提交个用户的功能）测试，又包括对整个产品的健壮性、安全性、可维护性及各种性能参数的测试。系统测试测试软件《需求规格说明书》中提到的功能是否有遗漏，是否正确的实现。做系统测试要严格按照《需求规格说明书》，以它为标准。测试方法一般都使用黑盒测试法。

35. 软件都有多少种分类?
根据功能的不同，电脑软件可以粗略地分成四个层次：

• 1、最贴近电脑硬件的是一些小巧的软件。它们实现一些最基本的功能，通常“固化”在只读存储器芯片中，因此称为固件。
• 2、系统软件包括操作系统和编译器软件等。系统软件和硬件一起提供一个“平台”。它们管理和优化电脑硬件资源的使用。
• 3、支持软件。包括图形用户界面、软件开发工具、软件评测工具、数据库管理系统、中间件等。
• 4、应用软件种类最多，包括办公软件、电子商务软件、通信软件、行业软件，游戏软件等等。

36. 请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。

• 黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。
• 白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。
• 软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误：
  • 1、是否有不正确或遗漏的功能？
  • 2、在接口上，输入是否能正确的接受？能否输出正确的结果？
  • 3、是否有数据结构错误或外部信息（例如数据文件）访问错误？
  • 4、性能上是否能够满足要求？
  • 5、是否有初始化或终止性错误？
• 白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：
  • 1、对程序模块的所有独立的执行路径至少测试一遍。
  • 2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。
  • 3、在循环的边界和运行的界限内执行循环体。
  • 4、测试内部数据结构的有效性，等等。
• 单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。
  • 单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。
• 集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。
• 系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。（常见的联调测试）
• 系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。
• 验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。
  • 验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。

37. 测试计划工作的目的是什么？测试计划工作的内容都包括什么？其中哪些是最重要的？

• 软件测试计划 是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。
• 测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法（最好是能先评审）

38. 您认为做好测试计划工作的关键是什么？

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

39. 您所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。

• 1 等价类划分
  　　等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果。
  　　等价类划分可有两种不同的情况:有效等价类和无效等价类。
• 2 边界值分析法
  　　边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误。
  　　使用边界值分析方法设计测试用例,首先应确定边界情况。通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据。
• 3 错误推测法
  　　基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。
  　　错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.
• 4 因果图方法
  　　前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

40. 请以您以往的实际工作为例,详细的描述一次测试用例设计的完整的过程。

• 就说最近的这次网站功能测试吧
  • 首先：得到相关文档（需求文档和设计文档），理解需求和设计思想后，想好测试策略（测试计划简单点就OK了），考虑到测试环境，测试用例，测试时间等问题。
  • 第二步：设计测试用例，测试策略是：把网站部分的功能点测试完，然后在进行系统测试（另外个模块呢有另一个测试人员负责，可以进行联调测试），网站模块的测试基本是功能测试和界面测试（用户并发的可能性很小，所以不考虑）：这次的网站的输入数据呢是使用数据库中的某张表记录，如果表中某一数据记录中新加进来的（还没有被处理的，有个标志位），网站启动后会立刻去刷那张表，得到多条数据，然后在进行处理。处理过程中，会经历3个步骤，网站才算完成了它的任务。有3个步骤呢，就可以分别对　　这3个步骤进行测试用例的设计,尽量覆盖到各种输入情况（包括数据库中的数据，用户的输入等），得出了差不多50个用例。界面测试，也就是用户看的到的地方，包括发送的邮件和用户填写资料的页面展示。
  • 第三步：搭建测试环境（为什么这个时候考虑测试环境呢？因为我对网站环境已经很熟了，只有有机器能空于下来做该功能测试就可以做了），因为网站本身的环境搭建和其他的系统有点不同，它需要的测试环境比较麻烦，需要web服务器（Apache,tomcat），不过这次需求呢，网站部分只用到了tomcat，所以只要有tomcat即可
  • 第四步：执行测试

41. 为什么要在一个团队中开展软件测试工作？

• 因为没有经过测试的软件很难在发布之前知道该软件的质量，就好比ISO质量认证一样，测试同样也需要质量的保证，这个时候就需要在团队中开展软件测试的工作。
• 在测试的过程发现软件中存在的问题，及时让开发人员得知并修改问题，在即将发布时，从测试报告中得出软件的质量情况。

42. 您所熟悉的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……）

• 测试类型有：功能测试，性能测试，界面测试。

  • 功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。
  • 性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。
  • 界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。

• 区别：

  • 功能测试关注产品的所有功能上，要考虑到每个细节功能，每个可能存在的功能问题。
  • 性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。
  • 界面测试更关注于用户体验上，用户使用该产品的时候是否易用，是否易懂，是否规范（快捷键之类的），是否 美观（能否吸引用户的注意力），是否安全（尽量在前台避免用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告）？
  • 做某个性能测试的时候，首先它可能是个功能点，首先要保证它的功能是没问题的，然后再考虑该功能点的性能测试

43. 您认为做好测试用例设计工作的关键是什么？

• 白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果
• 黑盒测试用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题

44. 你觉得软件测试通过的标准应该是什么样的？

• 缺陷密度值达到客户的要求

45. 你对测试最大的兴趣在哪里？为什么？

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

46. 你的测试职业发展是什么？

• 测试经验越多，测试能力越高。所以我的职业发展是需要时间累积的，一步步向着高级测试工程师奔去。而且我也有初步的职业规划，前3年累积测试经验，按如何做好测试工程师的11，12点要求自己，不断的更新自己改正自己，做好测试任务。

47. 你自认为测试的优势在哪里？

• 优势在于我对测试坚定不移的信心和热情，虽然经验还不够，但测试需要的基本技能我有信心在工作中得以发挥。

48. 你为什么想离开目前的职务？

• 因为公司运作情况并不理想，公司需要调整部门体系，公司考虑到缩减部门人员，所以大批量的裁员（有6，7个），这是我的第一份工作，对公司也有较深的感情，因为在这里我找到了职业理想（就是测试），所以公司需要精简人员，我自愿退出。虽然很舍不得，但我将会有新的发挥能力的舞台。

49. 配置和兼容性测试的区别是什么?

• 配置测试的目的是保证软件在其相关的硬件上能够正常运行，而兼容性测试主要是测试软件能否与不同的软件正确协作。
• 配置测试的核心内容就是使用各种硬件来测试软件的运行情况，一般包括：
  • (1)软件在不同的主机上的运行情况，例如Dell和Apple;
  • (2)软件在不同的组件上的运行情况，例如开发的拨号程序要测试在不同厂商生产的Modem上的运行情况;
  • (3)不同的外设;
  • (4)不同的接口;
  • (5)不同的可选项，例如不同的内存大小;
• 兼容性测试的核心内容：
  • (1)测试软件是否能在不同的操作系统平台上兼容;
  • (2)测试软件是否能在同一操作系统平台的不同版本上兼容;
  • (3)软件本身能否向前或者向后兼容;
  • (4)测试软件能否与其它相关的软件兼容;
  • (5)数据兼容性测试，主要是指数据能否共享;
• 配置和兼容性测试通称对开发系统类软件比较重要，例如驱动程序、操作系统、数据库管理系统等。具体进行时仍然按照测试用例来执行。

50. 你找工作时，最重要的考虑因素为何？

• 工作的性质和内容是否能让我发挥所长，并不断成长。

51. 为什么我们应该录取你？

• 您可以由我过去的工作表现所呈现的客观数据，明显地看出我全力以赴的工作态度。

52. 请谈谈你个人的最大特色。

• 我的坚持度很高，事情没有做到一个令人满意的结果，绝不罢手。

53. 你们以前测试的流程是怎样的？

• 测试计划－测试用例设计－测试执行－测试分析报告>
  　　用过哪些测试工具？

54. 为什么选择测试这行？

• 它是一个新兴的行业，有发展潜力，而且很锻炼人，需要掌握更多的技能，比做开发要更难>

55. 为什么值得他们公司雇用？

• 帮助公司提高软件质量和测试部门的技术水平

56. 如果我雇用你，你能给部门带来什么贡献？

• 分享我的测试经验和测试技能，提高测试部门技术水平

57. 如果你接到一个客户抱怨的电话，你确知无法解决他的问题，你会怎么处理
　为什么抱怨？是怎么样的问题？

• 如果是客服问题，提交客服部门解决
• 如果是质量问题，分析原因，下一版本改进

58. 你觉得什么样的人最难相处
自以为是的人

59. 怎样测试兼容性：

• 兼容的话我们公司经常测试的是这几种，一个是系统兼容，浏览器兼容，还有手机兼容，
• 系统的话现在,有win7，win8，win10，
• 浏览器的话经常测试的有谷歌，火狐，IE9,10，
• 手机这边的像Android机型比较多：
  • Android的版本我们这边支持4.0以上，
  • iOS的话，屏幕的尺寸要测试，像6和6p，苹果只有一个系统，我们会测试它的一个版本，我们会把一些主功能，主界面在这些系统或者不同的手机上去操作一遍，看看有没什么问题。

60. 互联网和金融测试的区别?

• 基本的功能要测试，互联网针对的人群比较广泛，
• 兼容方面要多考虑，金融就比如说一个银行柜员系统，一般都是有针对性用户，兼容这一块就不需要太多的测试

61. 会配置环境吗？

• 这个会的，我们公司用的是jenkins，环境是测试经理搭建好的，开发把代码提交到SVN，我们这边在Jenkins上输入项目号，点击编译，完成后就可以进行测试了。

62. 感觉自己跟别人比有什么优势?

• 做为一个合格的测试员，必备的耐心，责任心，和团队意识，每个人都是必备的，如果优势的话，我个人感觉可能比起一些，刚进入测试工作的同事来讲，项目经验多一点，一些流行的工具使用起来比较熟练，具体的真不好说。

63. 接口有做过吗？
这个做过的，我们在开发把接口写出来以后，跟前端联调的这个时间段，我们会做一个接口测试，我之前用的是jmeter，开发会提供一个接口文档，我们根据文档，填写请求地址，报文名，接口类型，字段和值，然后点击执行，在结果树里查看返回结果，是否跟接口文档一致。

64. 性能测试有做过吗?

• 性能测试在上家家公司接触了一点，用的jmeter，脚本是人家写好的，我用jmeter导出脚本，
• 设置一下线程组(并发数)和循环次数（递增用户数），时间，点击执行，查看服务器CPU的使用率，吞吐量，内存磁盘，有没有报错信息等，确认符合相关的性能数据指标，这块也只是简单接触，让我独立完成可能还有点欠缺。

65. Lordrunner三大控件?

• 录制脚本，场景模拟，分析报告

66. 简述bug的几种状态？

• 开启；
• 已修复；
• 驳回；
• 关闭；
• 遗留；
• 重新打开

71. 写出bug报告当中一些必备的内容。
硬件平台和操作系统
测试应用的硬件平台（Platform），通常选择“PC”。
测试应用的操作系统平台（OS）。

• a)版本
  提交缺陷报告时通过该字段标识此缺陷存在于被测试软件的哪个版本。
• b)Bug报告优先级

• c)Bug状态

• d)Bug的编号
• e)发现人
• f)提交人
• g)指定处理人
• h)概述
• i)从属关系
• j)详细描述
• k)严重程度
• l)所属模块
• m)附件
• n)提交日期