前言
嗨咯 大伙，我是你们的笨蛋程序员
为了让大家更好的理解和学习投入到Python自动化来
找到一份好的资料也是学习过程中，非常重要的一个点。你的检索能力越强，你就会越容易找到最合适你的资料。
我这边也整理了一些最新的面试题资料和Java架构学习资料，学习技术内容包含有：Spring，Dubbo，MyBatis, RPC,源码分析，高并发、高性能、分布式,性能优化，微服务 高级架构开发等等。
有需要的小伙伴可以戳这里免费领取可以点击这里，咱们一起进步
暗号：CSDN。
一、什么是兼容性测试？兼容性测试侧重哪些方面？
参考答案：
-
兼容测试主要是检查软件在不同的硬件平台、软件平台上是否可以正常的运行，即是通常说的软件的可移植性。
-
兼容的类型，如果细分的话，有平台的兼容，网络兼容，数据库兼容，以及数据格式的兼容。
兼容测试的重点是，对兼容环境的分析。通常，是在运行软件的环境不是很确定的情况下，才需要做兼容。根据软件运行的需要，或者根据需求文档，一般都能够得出用户会在什么环境下使用该软件，把这些环境整理成表单，就得出做兼容测试的兼容环境了。 -
兼容和配置测试的区别在于，做配置测试通常不是Clean OS 下做测试，而兼容测试多是在Clean OS 的环境下做的。
二、我现在有个程序，发现在Windows 上运行得很慢，怎么判别是程序存在问题还是软硬件系统存在问题？
参考答案：
1、检查系统是否有中毒的特征；
2、检查软件/硬件的配置是否符合软件的推荐标准；
3、确认当前的系统是否是独立，即没有对外提供什么消耗CPU 资源的服务；
4、如果是C/S 或者B/S 结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的；
5、在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况。
代码如下（示例）：
三、测试的策略有哪些？
参考答案：
黑盒/白盒，静态/动态，手工/自动，冒烟测试，回归测试，公测（Beta 测试的策略）
四、正交表测试用例设计方法的特点是什么？
参考答案：
-
用最少的实验覆盖最多的操作，测试用例设计很少，效率高，但是很复杂；
-
对于基本的验证功能，以及二次集成引起的缺陷，一般都能找出来；但是更深的缺陷，更复杂的缺陷，还是无能为力的；
-
具体的环境下，正交表一般都很难做的。大多数，只在系统测试的时候使用此方法。
五、描述使用bugzilla 缺陷管理工具对软件缺陷（BUG）跟踪的管理的流程？
参考答案：
就是Bugzilla 的状态转换图。
六、描述测试用例设计的完整过程？
参考答案：
需求分析+ 需求变更的维护工作；
根据需求得出测试需求；
设计测试方案，评审测试方案；
方案评审通过后，设计测试用例，再对测试用例进行评审
七、单元测试的策略有哪些？
参考答案：
逻辑覆盖、循环覆盖、同行评审、桌前检查、代码走查、代码评审、景泰数据流分析
什么是并发？在lordrunner 中，如何进行并发的测试？集合点失败了会怎么样？
参考答案：
在同一时间点，支持多个不同的操作。
LoadRunner 中提供IP 伪装，集合点，配合虚拟用户的设计，以及在多台电脑上设置，可以比较好的模拟
真实的并发。
集合点，即是多个用户在某个时刻，某个特定的环境下同时进行虚拟用户的操作的。集合点失败，则集合
点的才操作就会取消，测试就不能进
八、QTP 中的Action 有什么作用？有几种？
参考答案：
Action 的作用：
用Action 可以对步骤集进行分组
步骤重组，然后被整体调用
拥有自己的sheet
组合有相同需求的步骤，整体操作
具有独立的对象仓库
Action 的种类：
可复用Action
不可复用Action
外部Action
九、你所熟悉的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……）？
参考答案：
Compatibility Testing（兼容性测试），也称“Configuration testing（配置测试）”，兼容性测试是
将验证软件与其所依赖的环境的依赖程度，包括对硬件的依赖程度，对平台软件，其它软件的依赖程度，来检
查程序能正常的运行的测试
Functional testing (功能测试)，也称为behavioral testing（行为测试）或黑盒测试，根据产品特征、操作描述和用
户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试，用于验证应用
程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本，以保证目标用户的体验将足够好，
就像应用程序是专门为该市场开发的一样。
Performance testing（性能测试），性能测试是指通过自动化的测试工具模拟多种正常、峰值以
及异常负载条件来对系统的各项性能指标进行测试
主要包括以下三个方面：
-
应用在客户端性能的测试
-
应用在网络上性能的测试和应用在服务器端
-
性能的测试
十、测试活动中，如果发现需求文档不完善或者不准确，怎么处理？
参考答案：
应该立即和相关人员进行协调交流。
十一、你认为做好测试计划工作的关键是什么？
参考答案：
软件测试计划就是在软件测试工作正式实施之前明确测试的对象，并且通过对资源、时间、风险、测试范
围和预算等方面的综合分析和规划，保证有效的实施软件测试；
做好测试计划工作的关键：目的，管理，规范
十二、一套完整的测试应该由哪些阶段组成？
参考答案：测试计划、测试设计与开发、测试实施、测试评审与测试结论
十三、单元测试的主要内容？
模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试
十四、简述集成测试与系统测试关系？
（1）集成测试的主要依据概要设计说明书，系统测试的主要依据是需求设计说明书；
（2）集成测试是系统模块的测试，系统测试是对整个系统的测试，包括相关的软硬件平台、网络以及相关外
设的测试。
十五、软件系统中除用户文档之外，文档测试还应该关注哪些文档？
参考答案：
开发文档
软件需求说明书
数据库设计说明书
概要设计说明书
详细设计说明书
可行性研究报告
管理文档
项目开发计划
测试计划
测试报告
开发进度月报
开发总结报告
十六、如何理解压力、负载、性能测试测试？
参考答案：
性能测试是一个较大的范围，实际上性能测试本身包含了性能、强度、压力、负载等多方面的测试内
容。
压力测试是对服务器的稳定性以及负载能力等方面的测试，是一种很平常的测试。
增大访问系统的用户数量、或者几个用户进行大数据量操作都是压力测试。而负载测试是压力相对较大的测试，主要是测试
系统在一种或者集中极限条件下的相应能力，是性能测试的重要部分。
100 个用户对系统进行连续半个小时的访问可以看作压力测试，那么连续访问8 个小时就可以认为负载测试，1000 个用户连续访问系统
1 个小时也可以看作是负载测试。
实际上压力测试和负载测试没有明显的区分。测试人员应该站在关注整体性能的高度上来对系统进行
测试。
十七、什么是系统瓶颈？
参考答案：
瓶颈主要是指整个软硬件构成的软件系统某一方面或者几个方面能力不能满足用户的特定业务要求，
“特定”是指瓶颈会在某些条件下会出现，因为毕竟大多数系统在投入前。
严格的从技术角度讲，所有的系统都会有瓶颈，因为大多数系统的资源配置不是协调的，例如CPU 使
用率刚好达到100％时，内存也正好耗尽的系统不是很多见。
因此我们讨论系统瓶颈要从应用的角度讨论：关键是看系统能否满足用户需求。在用户极限使用系统的情况下，系统的响应仍然正常，我们可以认为改系统没有瓶颈或者瓶颈不会影响用户工作。
因此我们测试系统瓶颈主要是实现下面两个目的：
-发现“表面”的瓶颈。主要是模拟用户的操作，找出用户极限使用系统时的瓶颈，然后解决瓶颈，这是性
能测试的基本目标。
-发现潜在的瓶颈并解决，保证系统的长期稳定性。主要是考虑用户在将来扩展系统或者业务发生变化时，
系统能够适应变化。满足用户目前需求的系统不是最好的，我们设计系统的目标是在保证系统整个软件
生命周期能够不断适应用户的变化，或者通过简单扩展系统就可以适应新的变化。
十八、文档测试主要包含什么内容？
参考答案：
在国内软件开发管理中，文档管理几乎是最弱的一项，因而在测试工作中特别容易忽略文档测试也就
不足为奇了。要想给用户提供完整的产品，文档测试是必不可少的。文档测试一般注重下面几个方面：
文档的完整性：主要是测试文档内容的全面性与完整性，从总体上把握文档的质量。例如用户手册应
该包括软件的所有功能模块。
描述与软件实际情况的一致性：主要测试软件文档与软件实际的一致程度。例如用户手册基本完整
后，我们还要注意用户手册与实际功能描述是否一致。因为文档往往跟不上软件版本的更新速度。
易理解性：主要是检查文档对关键、重要的操作有无图文说明，文字、图表是否易于理解。对于关
键、重要的操作仅仅只有文字说明肯定是不够的，应该附有图表使说明更为直观和明了。
文档中提供操作的实例：这项检查内容主要针对用户手册。对主要功能和关键操作提供的应用实例是
否丰富，提供的实例描述是否详细。只有简单的图文说明，而无实例的用户手册看起来就像是软件界面的
简单拷贝，对于用户来说，实际上没有什么帮助。
印刷与包装质量：主要是检查软件文档的商品化程度。有些用户手册是简单打印、装订而成，过于粗
糙，不易于用户保存。优秀的文档例如用户手册和技术白皮书，应提供商品化包装，并且印刷精美。
十九、功能测试用例需要详细到什么程度才是合格的？
参考答案：
这个问题也是测试工程师经常问的问题。有人主张测试用例详细到每个步骤执行什么都要写出来，目
的是即使一个不了解系统的新手都可以按照测试用例来执行工作。
主张这类写法的人还可以举出例子：
欧美、日本等软件外包文档都是这样做的。另外一种观点就是主张写的粗些，类似于编写测试大纲。
主张这种观点的人是因为软件开发需求管理不规范，变动十分频繁，因而不能按照欧美的高标准来编写测试用例。这样的测试用例容易维护，可以让测试执行人员有更大的发挥空间。
实际上，软件测试用例的详细程度首先要以覆盖到测试点为基本要求。举个例子：“用户登陆系统”
的测试用例可以不写出具体的执行数据，但是至少要写出五种以上情况（），如果只用一句话覆盖了这个
功能是不合格的测试用例。覆盖功能点不是指列出功能点，而是要写出功能点的各个方面（如果组合情况
较多时可以采用等价划分）。
另一个影响测试用例的就是组织的开发能力和测试对象特点。如果开发力量比较落后，编写较详细的
测试用例是不现实的，因为根本没有那么大的资源投入，当然这种情况很随着团队的发展而逐渐有所改
善。测试对象特点重点是指测试对象在进度、成本等方面的要求，如果进度较紧张的情况下，是根本没有
时间写出高质量的测试用例的，甚至有些时候测试工作只是一种辅助工作，因而不编写测试用例。
因此，测试用例的编写要根据测试对象特点、团队的执行能力等各个方面综合起来决定编写策略。最
后要注意的是测试人员一定不能抱怨，力争在不断提高测试用例编写水平的同时，不断地提高自身能力。
# 二十、配置和兼容性测试的区别是什么？
参考答案：
配置测试的目的是保证软件在其相关的硬件上能够正常运行，而兼容性测试主要是测试软件能否与不同的
软件正确协作。
配置测试的核心内容就是使用各种硬件来测试软件的运行情况，一般包括：
（1）软件在不同的主机上的运行情况，例如Dell 和Apple；
（2）软件在不同的组件上的运行情况，例如开发的拨号程序要测试在不同厂商生产的Modem 上的运行情
况；
（3）不同的外设；
（4）不同的接口；
（5）不同的可选项，例如不同的内存大小；
兼容性测试的核心内容：
（1）测试软件是否能在不同的操作系统平台上兼容；
（2）测试软件是否能在同一操作系统平台的不同版本上兼容；
（3）软件本身能否向前或者向后兼容；
（4）测试软件能否与其它相关的软件兼容；
（5）数据兼容性测试，主要是指数据能否共享；
配置和兼容性测试通称对开发系统类软件比较重要，例如驱动程序、操作系统、数据库管理系统等。具
体进行时仍然按照测试用例来执行。
二十一、软件文档测试主要包含什么？
参考答案：
随着软件文档系统日益庞大，文档测试已经成为软件测试的重要内容。文档测试对象主要如下：
-包装文字和图形；
-市场宣传材料、广告以及其它插页；
-授权、注册登记表；
-最终用户许可协议；
-安装和设置向导；
-用户手册；
-联机帮助；
-样例、示范例子和模板；
-……
文档测试的目的是提高易用性和可靠性，降低支持费用，因为用户通过文档就可以自己解决问题。因文
档测试的检查内容主要如下：
-读者对象——主要是文档的内容是否能让该级别的读者理解；
-术语——主要是检查术语是否适合读者；
-内容和主题——检查主题是否合适、是否丢失、格式是否规范等；
-图标和屏幕抓图——检查图表的准确度和精确度；
-样例和示例——是否与软件功能一致；
-拼写和语法；
-文档的关联性——是否与其它相关文档的内容一致，例如与广告信息是否一致；
文档测试是相当重要的一项测试工作，不但要给予充分的重视，更要要认真的完成，象做功能测试一样来对待
文档测试。
二十二、没有产品说明书和需求文档地情况下能够进行黑盒测试吗？
参考答案：
这个问题是国内测试工程师经常遇到的问题，根源就是国内软件开发文档管理不规范，对变更的管理
方法就更不合理了。
实际上没有任何文档的时候，测试人员是能够进行黑盒测试的，这种测试方式我们可
以称之为探索测试，具体做法就是测试工程师根据自己的专业技能、领域知识等不断的深入了解测试对
象、理解软件功能，进而发现缺陷。
在这种做法基本上把软件当成了产品说明书，测试过程中要和开发人员不断的进行交流。尤其在作项
目的时候，进度压力比较大，可以作为加急测试方案。最大的风险是不知道有些特性是否被遗漏。
二十三、测试中的“杀虫剂怪事”是指什么？
参考答案：
“杀虫剂怪事”一词由BorisBeizer 在其编著的《软件测试技术》第二版中提出。用于描述测试人员
对同一测试对象进行的测试次数越多，发现的缺陷就会越来越少的现象。就像老用一种农药，害虫就会有
免疫力，农药发挥不了效力。
这种现象的根本原因就是测试人员对测试软件过于熟悉，形成思维定势。
为了克服这种现象，测试人员需要不断编写新的测试程序或者测试用例，对程序的不同部分进行测
试，以发现更多的缺陷。也可以引用新人来测试软件，刚刚进来的新手往往能发现一些意想不到的问题。
二十五、在配置测试中，如何判断发现的缺陷是普通问题还是特定的配置问题？
参考答案：
在进行配置测试时，测试工程师仍然会发现一些普通的缺陷，也就是与配置环境无关的缺陷。因此判
断新发现的问题，需要在不同的配置中重新执行发现软件缺陷的步骤，如果软件缺陷不出现了，就可能是
配置缺陷；如果在所有的配置中都出现，就可能是普通缺陷。
需要注意的是，配置问题可以在一大类配置中出现。例如，拨号程序可能在所有的外置Modem 中都存
在问题，而内置的Modem 不会有任何问题。
二十六、为什么尽量不要让时间有富裕的员工去做一些测试？
参考答案：
表面上看这体现了管理的效率和灵活性，但实际上也体现了管理者对测试的轻视。测试和测试的人有
很大关系。测试工作人员应该是勤奋并富有耐心，善于学习、思考和发现问题，细心有条理，总结问题，
如果具备这样的优点，做其它工作同样也会很出色，因此这里还有一个要求，就是要喜欢测试这项工作。
如果他是专职的，那么肯定更有经验和信心。国内的小伙子好象都喜欢做程序员，两者工作性质不同，待
遇不同，地位不同，对自我实现的价值的认识也不同，这是行业的一个需要改善的问题。如果只是为了完
成任务而完成任务，或者发现了几个问题就觉得满意了，这在任何其它工作中都是不行的。
二十七、软件测试的风险主要体现在哪里？
参考答案：
我们没有对软件进行完全测试，实际就是选择了风险，因为缺陷极有可能存在没有进行测试的部分。
举个例子，程序员为了方便，在调试程序时会弹出一些提示信息框，而这些提示只在某种条件下会弹出，
碰巧程序发布前这些代码中的一些没有被注释掉。在测试时测试工程师又没有对其进行测试。如果客户碰
到它，这将是代价昂贵的缺陷，因为交付后才被客户发现。
因此，我们要尽可能的选择最合适的测试量，把风险降低到最小。
二十八、发现的缺陷越多，说明软件缺陷越多吗？
参考答案：
这是一个比较常见的现象。测试工程师在没有找到缺陷前会绞尽脑汁的思考，但是找到一个后，会接
二连三的发现很多缺陷，颇有个人成就感。其中的原因主要如下：
-代码复用、拷贝代码导致程序员容易犯相同的错误。类的继承导致所有的子类会包含基类的错误，反复
拷贝同一代码意味可能也复制了缺陷。
-程序员比较劳累是可以导致某些连续编写的功能缺陷较多。程序员加班是一种司空见惯的现象，因此体
力不只时容易编写一些缺陷较多的程序。而这些连续潜伏缺陷恰恰时测试工程师大显身手的地方。
“缺陷一个连着一个”不是一个客观规律，只是一个常见的现象。如果软件编写的比较好，这种现象
就不常见了。测试人员只要严肃认真的测试程序就可以了。
二十九、发现的缺陷越多，说明软件缺陷越多吗？
参考答案：
这是一个比较常见的现象。测试工程师在没有找到缺陷前会绞尽脑汁的思考，但是找到一个后，会接
二连三的发现很多缺陷，颇有个人成就感。其中的原因主要如下：
-代码复用、拷贝代码导致程序员容易犯相同的错误。类的继承导致所有的子类会包含基类的错误，反复
拷贝同一代码意味可能也复制了缺陷。
-程序员比较劳累是可以导致某些连续编写的功能缺陷较多。程序员加班是一种司空见惯的现象，因此体
力不只时容易编写一些缺陷较多的程序。而这些连续潜伏缺陷恰恰时测试工程师大显身手的地方。
“缺陷一个连着一个”不是一个客观规律，只是一个常见的现象。如果软件编写的比较好，这种现象
就不常见了。测试人员只要严肃认真的测试程序就可以了。
三十、所有的软件缺陷都能修复吗？所有的软件缺陷都要修复吗？
参考答案：
从技术上讲，所有的软件缺陷都是能够修复的，但是没有必要修复所有的软件缺陷。测试人员要做的
是能够正确判断什么时候不能追求软件的完美。对于整个项目团队，要做的是对每一个软件缺陷进行取
舍，根据风险决定那些缺陷要修复。发生这种现象的主要原因如下：
-没有足够的时间资源。在任何一个项目中，通常情况下开发人员和测试人员都是不够用的，而且在
项目中没有预算足够的回归测试时间，再加上修改缺陷可能引入新的缺陷，因此在交付期限的强大压力
下，必须放弃某些缺陷的修改。
-有些缺陷只是特殊情况下出现，这种缺陷处于商业利益考虑，可以在以后升级中进行修复。
-不是缺陷的缺陷。我们经常会碰到某些功能方面的问题被当成缺陷来处理，这类问题可以以后有时
间时考虑再处理。
最后要说的是，缺陷是否修改要由软件测试人员、项目经理、程序员共同讨论来决定是否修复，不同
角色的人员从不同的角度来思考，以做出正确的决定。
最后！
今天的文章就到这里结束啦，希望看完以后能对有一些不大不小的帮助。如果喜欢的可以点赞收藏关注，如果不行的话，那也得行（我们IT人不能说不行）球球大伙辽
如果大家感兴趣的话，可以学习交流讨论的,咱可以一起加油，可以点击这里，咱们一起进步
转载：https://blog.csdn.net/Windmove3/article/details/111060486