100个变态的软件测试面试题及答案！——看完变态面试官对你竖起大拇指！

雨点打透心脏的1/2处 2024-03-23 17:12 64阅读 0赞

【纯干货！！！】花费了整整3天，整理出来的全网最实用软件测试面试大全，一共30道题目+答案的纯干货，希望大家多多支持，建议 点赞！！收藏！！长文警告，全文共12000+字，涵盖软件测试面试可能遇到的所有问题，希望对大家有帮助，不过大家最好不要硬背，实战大于理论。祝大家面试顺利！

51.一个测试工程师应具备那些素质？  
1、责任心2、沟通能力3、团队合作精神4、耐心、细心、信心5、时时保持怀疑态度，并且有缺陷预防的意识6、具备一定的编程经验  
52、什么是安全性测试  
Web应用系统的安全性测试区域主要有：  
　　(1)现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。  
　　(2)Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内(例如15分钟)没有点击任何页面，是否需要重新登陆才能正常使用。  
　　(3)为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。  
　　(4)当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。  
　　(5)服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。  
53：你所了解的的软件测试类型都有哪些，简单介绍一下。  
按测试策略分类：1、静态与动态测试2、黑盒与白盒测试 3、手工和自动测试 4、冒烟测试 5、回归测试；  
按测试阶段分类：单元测试、集成测试、系统测试；  
其他常见测试方法：1、功能测试 2、性能测试 3、压力测试 4、负载测试 5、易用性测试 6、安装测试 7、界面测试 8、配置测试 9、文档测试 10、兼容性测试 11、安全性测试 12、恢复测试  
54：你认为做好测试计划工作的关键是什么？  
明确测试的目标，增强测试计划的实用性  
编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确  
\*\*  
坚持“5W”规则，明确内容与过程  
“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。  
采用评审和更新机制，保证测试计划满足实际需求  
测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。  
分别创建测试计划与测试详细规格、测试用例  
应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。  
55：您认为做好测试用例设计工作的关键是什么？  
白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果  
黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题  
56：你的测试职业发展目标是什么？  
测试经验越多，测试能力越高。所以我的职业发展是需要时间累积的，一步步向着高级测试工程师奔去。而且我也有初步的职业规划，前3年累积测试经验，不断的更新自己改正自己，做好测试任务。  
57：测试结束的标准是什么？  
从微观上来说，在测试计划中定义，比如系统在一定性能下平稳运行72小时，目前Bug Tracking System中，本版本中没有一般严重的BUG，普通BUG的数量在3以下，BUG修复率90%以上等等参数，然后由开发经理，测试经理，项目经理共同签字认同版本Release。  
如果说宏观的，则是当这个软件彻底的消失以后，测试就结束了。  
58、怎么理解客户端兼容性测试  
**1、平台测试**  
　　市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。 因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。  
**2、浏览器测试**  
　　浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java，、JavaScript、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，JavaScript是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。 测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。  
59、一套完整的测试应该由哪些阶段组成？  
可行性分析、需求分析、概要设计、详细设计、编码、单元测试、集成测试、系统测试、验收测试  
如何提交高质量的缺陷报告单？  
1、 缺陷的概要描述要清晰准确，要使相关开发负责人员能够一目了然问题是什么。  
2、 一个完整的缺陷报告单，必须包含其必要的元素信息，例如：概要描述，缺陷发现人，测试环境，浏览器，缺陷重现步骤，严重等级，指派人，所属功能模块等等，必要元素信息必须描述全面清楚。  
3、 缺陷的重现步骤必须描写清晰明了，使相关开发负责人能够根据重现步骤准确的重现所提交的缺陷，使其定位缺陷的原因所在。  
4、测试数据，测试的数据作为重现缺陷的一个重要元素信息，一定要将测试时所使用的信息给描写清楚准确。让开发人员根据测试所提供的测试数据准确重现缺陷。  
5、附件截图信息，附件或截图信息能让开发人员能够一目了然的清楚问题的所在。

![e6e6e8061a5f4c8b952ef60aa82770f3.webp][]

61、您是否了解以往所工作的企业的软件开发过程？如果了解，请试述一个完整的开发过程需要完成哪些工作？分别由哪些不同的角色来完成这些工作？您在以往的测试工作中都曾经具体从事过哪些工作？其中最擅长哪部分工作？  
开发过程—需求调研（需求人员）、需求分析（需求人员）、概要设计（设计人员）、详细设计(设计人员)、编码（开发人员）  
测试过程—需求评审、系统测试设计、概要设计评审、集成测试设计、详细设计评审、单元测试设计、测试执行  
测试工作的整个过程都做过，擅长做测试设计  
过程决定质量，软件的过程改进正是为了提高软件的质量，将过往的种种经验教训积累起来。  
62、测试用例设计的原则是什么？目前主要的测试用例设计方法有哪些？  
代表性：能够代表并覆盖各种合理的和不合理、合法的和非法的、边界的和越界的、以及极限的输入数据、操作和环境设置等.  
可判定性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果.  
可再现性：即对同样的测试用例，系统的执行结果应当是相同的。  
方法有等价类、边界值、因果图、状态图、正交法、大纲法  
63、面向对象的测试用例设计有几种方法？如何实现？  
给类中的每个构造函数设计一组测试用例  
组合类中的类变量、实例变量  
组合类中的各种方法  
根据前置条件和后置条件设计测试用例  
根据代码设计测试用例  
64、LoadRunner分为哪三个模块？请简述各模块的主要功能。  
Virtual User Generator：用于录制脚步  
Mercury LoadRunner Controller：用于创建、运行和监控场景  
Mercury LoadRunner Analysis：用于分析测试结果  
65、你对测试最大的兴趣在哪里？为什么？  
最大的兴趣就是测试有难度，有挑战性！做测试越久越能感觉到做好测试有多难。曾经在无忧测试网上看到一篇文章，是关于如何做好一名测试工程师。一共罗列了11，12点，有部分是和人的性格有关，有部分需要后天的努力。但除了性格有关的1，2点我没有把握，其他点我都很有信心做好它。  
刚开始进入测试行业时，对测试的认识是从无忧测试网上了解到的一些资料，当时是冲着做测试需要很多技能才能做的好，虽然入门容易，但做好很难，比开发更难，虽然当时我很想做开发（学校专业课我基本上不缺席，因为我喜欢我的专业），但看到测试比开发更难更有挑战性，想做好测试的意志就更坚定了。  
我觉得做测试整个过程中有2点让我觉得很有难度（对我来说，有难度的东西我就非常感兴趣），第一是测试用例的设计，因为测试的精华就在测试用例的设计上了，要在版本出来之前，把用例写好，用什么测试方法写？（也就是测试计划或测试策略），如果你刚测试一个新任务时，你得花一定的时间去消化业务需求和技术基础，业务需求很好理解（多和产品经理和开发人员沟通就能达到目的），而技术基础可就没那么简单了，这需要你自觉的学习能力，比如说网站吧，最基本的技术知识你要知道网站内部是怎么运作的的，后台是怎么响应用户请求的？测试环境如何搭建？这些都需要最早的学好。至少在开始测试之前能做好基本的准备，可能会遇到什么难题？需求细节是不是没有确定好？这些问题都能在设计用例的时候发现。  
第二是发现BUG的时候了，这应该是测试人员最基本的任务了，一般按测试用例开始测试就能发现大部分的bug，还有一部分bug需要测试的过程中更了解所测版本的情况获得更多信息，补充测试用例，测试出bug。还有如何发现bug？这就需要在测试用例有效的情况下，通过细心和耐心去发现bug了，每个用例都有可能发现bug，每个地方都有可能出错，所以测试过程中思维要清晰（测试过程数据流及结果都得看仔细了，bug都在里面发现的）。如何描述bug也很有讲究，bug在什么情况下会产生，如果条件变化一点点，就不会有这个bug，以哪些最少的操作步骤就能重现这个bug，这个bug产生的规律是什么？如果你够厉害的话，可以帮开发人员初步定位问题。  
66、您所熟悉的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……）  
测试类型有：功能测试，性能测试，界面测试。  
**功能测试**在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。  
**性能测试**是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。  
**界面测试**，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。  
　　区别在于，功能测试关注产品的所有功能上，要考虑到每个细节功能，每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注于用户体验上，用户使用该产品的时候是否易用，是否易懂，是否规范（快捷键之类的），是否美观（能否吸引用户的注意力），是否安全（尽量在前台避免用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告）？做某个性能测试的时候，首先它可能是个功能点，首先要保证它的功能是没问题的，然后再考虑该功能点的性能测试  
67、请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。  
\*\*黑盒测试：\*\*已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。  
　　\*\*白盒测试：\*\*已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。  
　　软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误：  
　　1、是否有不正确或遗漏的功能？2、在接口上，输入是否能正确的接受？能否输出正确的结果？3、是否有数据结构错误或外部信息（例如数据文件）访问错误？4、性能上是否能够满足要求？5、是否有初始化或终止性错误？  
　　软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：  
　　1、对程序模块的所有独立的执行路径至少测试一遍。  
　　2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。  
　　3、在循环的边界和运行的界限内执行循环体。  
　　4、测试内部数据结构的有效性，等等。  
　　单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。  
　　单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。  
　　集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。  
　　系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。（常见的联调测试）  
　　系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。  
　　验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。  
验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能性能如同用户所合理期待的那样。  
68、当开发人员说不是BUG时，你如何应付？  
开发人员说不是bug，有2种情况，一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动，3方商量确定好后再看要不要改。二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是BUG的依据是什么？如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。其实有些真的不是bug，我也只是建议的方式写进TD中，如果开发人员不修改也没有大问题。如果确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认。  
69、为什么要在一个团队中开展软件测试工作？  
因为没有经过测试的软件很难在发布之前知道该软件的质量，就好比ISO质量认证一样，测试同样也需要质量的保证，这个时候就需要在团队中开展软件测试的工作。在测试的过程发现软件中存在的问题，及时让开发人员得知并修改问题，在即将发布时，从测试报告中得出软件的质量情况。  
70、web测试和APP测试的区别  
仅仅从功能测试的层面上来讲的话，在流程和功能测试上是没有区别的。那么区别在哪里呢？  
由于载体不一样，所以系统测试和一些细节可能会不一样。  
那么我们就要先来了解，web和app的区别。  
web项目，一般都是b/s架构，基于浏览器的，而app则是c/s的，必须要有客户端。那么在系统测试测试的时候就会产生区别了。  
首先从系统架构来看的话，web测试只要更新了服务器端，客户端就会同步会更新。而且客户端是可以保证每一个用户的客户端完全一致的。但是app端是不能够保证完全一致的，除非用户更新客户端。如果是app下修改了服务端，意味着客户端用户所使用的核心版本都需要进行回归测试一遍。  
接着是性能方面，web页面可能只会关注响应时间，而app则还需要关心流量、电量、CPU、GPU、Memory这些了。至于服务端的性能是没区别，这里就不谈。  
相比较web测试，app更是多了一些专项测试：  
**健壮性测试：**  
一些异常场景的考虑以及弱网络测试。这里的异常场景就是中断，来电，短信，关机，重启等。  
而弱网测试是app测试中必须执行的一项测试。包含弱网和网络切换测试。需要测试弱网所造成的用户体验，重点要考虑回退和刷新是否会造成二次提交。需要测试丢包，延时的处理机制。避免用户的流失。这些在前面的弱网测试那篇已经讲过，这里不再讲了。  
  
安装、卸载、更新：  
　　web测试是基于浏览器的所以不必考虑这些。而app是客户端的，则必须测试安装、更新、卸载。除了常规的安装、更新、卸载还要考虑到异常场景。包括安装时的中断、弱网、安装后删除安装文件，更新的强制更新与非强制更新、增量包更新、断点续传、弱网，卸载后删除app相关的文件等等。  
  
就自动化来讲，web大多用的selenium、webdriver，而app则是appium。  
性能使用的工具web则是LR，app使用Jmeter要多一点\#\# 71、一份测试计划应该包括哪些内容？  
背景、项目简介、目的、测试范围、测试策略、人员分工、资源要求、进度计划、参考文档、常用术语、提交文档、风险分析。  
72、针对于软件的行业背景，你如何理解软件的业务？  
阅读用户手册了解软件的功能和操作流程；看一些业务的专业书籍补充业务知识；如果有用户实际的数据，可以拿实际的数据进行参考；参考以前的用例和BUG报告；在使用软件的过程中多思考；多与产品经理交流。  
74、如何定位测试用例的作用？  
组织性：编写、组织性、功能覆盖、重复性、跟踪、测试确认  
75、软件测试的流程

![d0d615328f0c4b8da07ce71dead0b3c7.webp][]

76、什么是兼容性测试？请举例说明如何利用兼容性测试列表进行测试。  
主要验证软件产品在不同版本之间的兼容性。包括向下兼容和交错兼容，向下兼容是测试软件新版本保留它早期版本功能的情况，交错兼容是验证共同存在的两个相关但不相同的产品之间的兼容性。  
77、对某软件进行测试，发现在WIN98上运行得很慢，怎么判别是该软件存在问题还是其软硬件运行环境存在问题？  
看软件的运行环境要求。如果符合要求则是程序存在问题，若不符合要求则是硬件系统存在问题  
78、需求测试的注意事项有哪些？  
是否使用了公司的模板、文档内容是否符合规范、所有的需求是分级是否清析适当、所有的需求是否具有一致性、需求是否可行（即，该需求组合有解决方案）、需求可否用己知的约束来实现、需求是否足够（即，可以把它送到一个规范的开发组织，并有一个生产出所需要产品的合理的可能性）、所有的其它需求是交叉引用是否正确、用户描述是否清楚、是否用客户的语言来描述需求、每个需求描述是否清楚没有岐义，可以移交给一个独立的组去实现时也能理解、是否所有的需求都是可验证的、是否每条需求都具有独立性，即使发生了变化也不会影响其它需求、性能指标是否明确、非功能性需求是否得到充分表现、是否完整列出适用的标准或协议、标准和协议之间是否存在冲突  
79软件测试的目的：  
1.验证软件需求和功能是否得到完整实现  
2.验证软件是否可以发布  
3.尽可能多的发现软件中的bug  
4.尽可能早的发现软件中的bug  
5.对软件质量做出合理评估  
6.预防下个版本可能出现的问题  
7.预防用户使用可能出现的问题  
8.发现开发过程中的问题和风险  
80、软件测试的原则：  
1、所有测试的标准都是建立在用户需求之上 。  
2、合理控制测试深度与广度，完全测试不可能，测试的投入与产出要均衡。  
3、80-20原则，软件中80%的bug可以在分析、设计与评审阶段就能被发现与修正，16%的缺陷在系统的软件测试中发现，最后剩下的4%是用户长期使用的过程中才能暴露出来。  
4、尽可能早的开展测试，越早发现错误，修改的代价越小。  
5、发现错误较多的程序段，应进行更深入的测试。  
6、软件项目一启动，软件测试也就是开始，而不是等程序写完，才开始进行测试 。  
7、软件开发人员即程序员应当避免测试自己的程序  
8、严格执行测试计划，排除测试的随意性，以避免发生疏漏或者重复无效的工作  
81、主键、外键的作用，索引的优点与不足?  
答：主键：是表中的唯一标示键。作用：保证实体的完整性;加快数据库的操作速度;增加新的表记录时，数据库会自动检索新记录的主键值，不允许该值与其他表中记录的主键重复;数据库会按主键值的顺序显示记录，如果没有设定主键，则按输入的顺序显示记录。  
外键：是主键的从属，表示了两个表之间的联系。作用：使用外键可以避免冗余。  
索引的优点： 1、通过创建唯一性的索引，可以保证表中数据的唯一性; 2、加速数据的检索速度; 3、加快表与表之间的连接; 4、在使用分组与排序数据检索时，可以显著检索分组与排序的时间; 5、在查询的过程中使用优化隐藏器，提供系统性能。  
缺点： 1、创建索引需要时间，且随着数据量的增加而增加; 2、索引需要占用物理空间;  
3、当对表中数据进行修改时，索引也要动态维护，降低了数据的维护速度。  
82、优秀测试人员应具备的技能：  
1）精通业务知识  
2）具备软件编程能力，比如C,C++,JAVA等。  
3）可以用脚本语言编写小测试工具  
4）主流操作系统应用与网络知识，可以搭建测试环境  
5）熟练掌握各种数据库知识  
6）精通软件测试理论与方法  
7）掌握常用测试与开发工具的使用  
8）优秀的文档编写能力  
83、软件测试模型：  
V模型：反映了测试与开发阶段之间一一对应的特点，测试在开发之后，出错后回归测试量大。

![71d9e774e3e444029ddfcbaeb362aafb.png][]

84、性能测试的流程?  
1.测试需求分析2.测试计划制定与评审3.测试用例设计与开发4.测试执行与监控5.分析测试结果6.编写性能测试报告7.测试经验总结  
84、设计用例的方法、依据有那些?  
测试分为白盒测试和黑盒测试，回答时，要注意分开说。白盒测试用例设计有如下方法：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。依据就是代码结构。  
黑盒测试用例设计方法：基于用户需求的测试、等价类划分方法、边界值分析方法、错误推测方法、因果图方法、判定表驱动分析方法、正交实验法、场景法。依据是用户需求规格说明书，详细设计说明书。  
85、集成测试通常都有哪些策略?  
大致说四点即可，当然说全更好。集成测试有十种策略:(1)大爆炸集成(2)自顶向下集成(3)自底向上集成(4)三明治集成(5)分层集成(6)基干集成(7)基于功能的集成(8)基于消息的集成(9)基于风险的集成(10)基于进度的集成.  
86、什么是兼容性测试？兼容性测试侧重哪些方面？  
兼容测试主要是检查软件在不同的硬件平台、软件平台上是否可以正常的运行，即是通常说的软件的可移植性。  
兼容的类型，如果细分的话，有平台的兼容，网络兼容，数据库兼容，以及数据格式的兼容。  
兼容测试的重点是，对兼容环境的分析。通常，是在运行软件的环境不是很确定的情况下，才需要做兼容。根据软件运行的需要，或者根据需求文档，一般都能够得出用户会在什么环境下使用该软件，把这些环境整理成表单，就得出做兼容测试的兼容环境了。  
我现在有个程序，发现在Windows上运行得很慢，怎么判别是程序存在问题还是软硬件系统存在问题？  
1、检查系统是否有中毒的特征；  
2、检查软件/硬件的配置是否符合软件的推荐标准；  
3、确认当前的系统是否是独立，即没有对外提供什么消耗CPU资源的服务；  
4、如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的；  
5、在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况。  
88、简述bug的生命周期?  
1， 有效地记录BUG 2， 使用BUG模板 3， 评价BUG优先级和严重性 4， BUG的生命 5， 维护BUG数据库  
89、缺陷记录应包含的内容?  
缺陷标识、缺陷类型、缺陷严重程度、缺陷产生可能性、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷原因;  
一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？  
1.和BUG对应的软件版本  
2.开发的接口人员，测试人员  
3.BUG的优先级  
4.BUG的严重程度  
5.BUG可能属于的模块  
6.BUG的标题  
7.BUG的描述  
8.BUG的截图  
9.BUG的状态  
10.BUG的错误类型（数据，界面。。。。）

![4d3c459f4de74e4c94462ed83eebf5e5.webp][]

91、您所熟悉的软件测试类型都有哪些?请试着分别比较这些不同的测试类型的区别与联系(\*\*\*\*如功能测试、性能测试……)  
易用性测试-界面的友好性，操作方便性等。  
功能测试-系统中功能性需求的满足  
安全性测试-系统是否存在安全隐患和漏洞  
性能测试-系统在大并发下的响应速度和健壮性  
92、 什么是扇入？什么是扇出？  
扇入：被调次数，扇出：调其它模块数目  
什么是桩模块？什么是驱动模块？  
桩模块：被测模块调用模块  
驱动模块：调用被测模块  
93、您认为做好测试计划工作的关键是什么?  
了解项目或系统的业务需求  
和项目经理协调好，了解项目的进度计划安排情况  
94、简述一下缺陷的生命周期？  
提交->确认->分配->修复->验证->关闭  
95、您认为做好测试用例设计工作的关键是什么?  
对业务和软件需求非常清楚，可以根据需求不同选择不同的测试用例设计  
96、您以往的工作中是否曾开展过测试用例的评审工作?如果有，请描述测试用例评审的过程和评审的内容。  
评审计划->预审->评审;  
　　评审内容主要是测试用例对软件需求的覆盖程度，对于相关边界是否考虑，是否针对复杂流程准备多套测试数据，是否有专门针对非功能性需求的测试。  
97、一套完整的测试应该由哪些阶段组成？  
参考答案：测试计划、测试设计与开发、测试实施、测试评审与测试结论  
98、您认为性能测试工作的目的是什么?做好性能测试工作的关键是什么?  
关键是测试脚本的录制，测试时候测试环境的干净。  
99、所有的软件缺陷都能修复吗？所有的软件缺陷都要修复吗？  
从技术上讲，所有的软件缺陷都是能够修复的，但是没有必要修复所有的软件缺陷。测试人员要做的是能够正确判断什么时候不能追求软件的完美。对于整个项目团队，要做的是对每一个软件缺陷进行取舍，根据风险决定那些缺陷要修复。发生这种现象的主要原因如下：  
\-没有足够的时间资源。在任何一个项目中，通常情况下开发人员和测试人员都是不够用的，而且在项目中没有预算足够的回归测试时间，再加上修改缺陷可能引入新的缺陷，因此在交付期限的强大压力下，必须放弃某些缺陷的修改。  
\-有些缺陷只是特殊情况下出现，这种缺陷处于商业利益考虑，可以在以后升级中进行修复。  
\-不是缺陷的缺陷。我们经常会碰到某些功能方面的问题被当成缺陷来处理，这类问题可以以后有时间时考虑再处理。  
最后要说的是，缺陷是否修改要由软件测试人员、项目经理、程序员共同讨论来决定是否修复，不同角色的人员从不同的角度来思考，以做出正确的决定。  
100、.您以往所从事的软件测试工作中，是否使用了一些工具来进行软件缺陷(Bug)的管理?如果有，请结合该工具描述软件缺陷(Bug)跟踪管理的流程。  
QC，也可以使用BugFree等免费工具。

![0347df9e8b7249a282720498e60fd574.png][]

[e6e6e8061a5f4c8b952ef60aa82770f3.webp]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/1cf329c3414e46a1915f703b3b6a4be2.png
[d0d615328f0c4b8da07ce71dead0b3c7.webp]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/ee980c3ac3be41f9b2345735a567286b.png
[71d9e774e3e444029ddfcbaeb362aafb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/941dea60d58240d091cf422d4beb1e3e.png
[4d3c459f4de74e4c94462ed83eebf5e5.webp]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/24b5772f95c1496d85384c66ee6de35f.png
[0347df9e8b7249a282720498e60fd574.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/d4ce651bad234951bfd9c2843e4820dc.png