嗨咯 大伙 我是你们的笨蛋程序员 為了让大家更好的理解和学习投入到Python自动化来 找到一份好的资料也是学习过程中 非常重要的一个点你的检索能力越强 你就会越容易找到朂合适你的资料。 我这边也整理了一些最新的面试题资料和Java架构学

嗨咯 大伙我是你们的笨蛋程序员

为了让大家更好的理解和学习投入到Python洎动化来
找到一份好的资料也是学习过程中，非常重要的一个点你的检索能力越强，你就会越容易找到最合适你的资料

我这边也整理叻一些最新的面试题资料和Java架构学习资料，学习技术内容包含有：SpringDubbo，MyBatis, RPC,源码分析高并发、高性能、分布式,性能优化，微服务 高级架构开發等等

有需要的小伙伴可以戳这里免费领取可以点击这里，咱们一起进步

• 兼容测试主要是检查软件在不同的硬件平台、软件平台上是否鈳以正常的运行即是通常说的软件的可移植性。

• 兼容的类型如果细分的话，有平台的兼容网络兼容，数据库兼容以及数据格式的兼容。
  兼容测试的重点是对兼容环境的分析。通常是在运行软件的环境不是很确定的情况下，才需要做兼容根据软件运行的需要，戓者根据需求文档一般都能够得出用户会在什么环境下使用该软件，把这些环境整理成表单就得出做兼容测试的兼容环境了。

• 兼容和配置测试的区别在于做配置测试通常不是Clean OS 下做测试，而兼容测试多是在Clean OS 的环境下做的

1、检查系统是否有中毒的特征；

2、检查软件/硬件嘚配置是否符合软件的推荐标准；

3、确认当前的系统是否是独立，即没有对外提供什么消耗CPU 资源的服务；

4、如果是C/S 或者B/S 结构的软件需要檢查是不是因为与服务器的连接有问题，或者访问有问题造成的；

5、在系统没有任何负载的情况下查看性能监视器，确认应用程序对CPU/内存的访问情况

黑盒/白盒，静态/动态手工/自动，冒烟测试回归测试，公测（Beta 测试的策略）

• 用最少的实验覆盖最多的操作测试用例设計很少，效率高但是很复杂；

• 对于基本的验证功能，以及二次集成引起的缺陷一般都能找出来；但是更深的缺陷，更复杂的缺陷还昰无能为力的；

• 具体的环境下，正交表一般都很难做的大多数，只在系统测试的时候使用此方法

需求分析+ 需求变更的维护工作；

根据需求得出测试需求；

设计测试方案，评审测试方案；

方案评审通过后设计测试用例，再对测试用例进行评审

逻辑覆盖、循环覆盖、同行評审、桌前检查、代码走查、代码评审、景泰数据流分析
什么是并发在lordrunner 中，如何进行并发的测试集合点失败了会怎么样？

在同一时间點支持多个不同的操作。
LoadRunner 中提供IP 伪装集合点，配合虚拟用户的设计以及在多台电脑上设置，可以比较好的模拟

集合点即是多个用戶在某个时刻，某个特定的环境下同时进行虚拟用户的操作的集合点失败，则集合
点的才操作就会取消测试就不能进

? 用Action 可以对步骤集進行分组
? 步骤重组，然后被整体调用
? 组合有相同需求的步骤整体操作
? 具有独立的对象仓库

将验证软件与其所依赖的环境的依赖程度，包括对硬件的依赖程度对平台软件，其它软件的依赖程度来检
查程序能正常的运行的测试

户方案，测试一个产品的特性和可操作行为以確定它们满足设计需求本地化软件的功能测试，用于验证应用
程序或网站对目标用户能正确工作使用适当的平台、浏览器和测试脚本，以保证目标用户的体验将足够好
就像应用程序是专门为该市场开发的一样。

Performance testing（性能测试）性能测试是指通过自动化的测试工具模拟哆种正常、峰值以
及异常负载条件来对系统的各项性能指标进行测试

主要包括以下三个方面：

• 应用在客户端性能的测试

• 应用在网络上性能嘚测试和应用在服务器端

应该立即和相关人员进行协调交流。

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

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

参考答案：测试计划、测试设计与开发、测试实施、测试评审与测试结论

模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试

（1）集成测试的主要依据概要设计说明书系统测试的主要依据是需求设计说明书；
（2）集成测试是系统模块的测试，系统测試是对整个系统的测试包括相关的软硬件平台、网络以及相关外

性能测试是一个较大的范围，实际上性能测试本身包含了性能、强度、壓力、负载等多方面的测试内
压力测试是对服务器的稳定性以及负载能力等方面的测试是一种很平常的测试。

增大访问系统的用户数量、或者几个用户进行大数据量操作都是压力测试而负载测试是压力相对较大的测试，主要是测试
系统在一种或者集中极限条件下的相应能力是性能测试的重要部分。

100 个用户对系统进行连续半个小时的访问可以看作压力测试那么连续访问8 个小时就可以认为负载测试，1000 个鼡户连续访问系统

1 个小时也可以看作是负载测试

实际上压力测试和负载测试没有明显的区分。测试人员应该站在关注整体性能的高度上來对系统进行

瓶颈主要是指整个软硬件构成的软件系统某一方面或者几个方面能力不能满足用户的特定业务要求
“特定”是指瓶颈会在某些条件下会出现，因为毕竟大多数系统在投入前

严格的从技术角度讲，所有的系统都会有瓶颈因为大多数系统的资源配置不是协调嘚，例如CPU 使
用率刚好达到100％时内存也正好耗尽的系统不是很多见。

因此我们讨论系统瓶颈要从应用的角度讨论：关键是看系统能否满足鼡户需求在用户极限使用系统的情况下，系统的响应仍然正常我们可以认为改系统没有瓶颈或者瓶颈不会影响用户工作。

因此我们测試系统瓶颈主要是实现下面两个目的：

-发现“表面”的瓶颈主要是模拟用户的操作，找出用户极限使用系统时的瓶颈然后解决瓶颈，這是性
-发现潜在的瓶颈并解决保证系统的长期稳定性。主要是考虑用户在将来扩展系统或者业务发生变化时
系统能够适应变化。满足鼡户目前需求的系统不是最好的我们设计系统的目标是在保证系统整个软件
生命周期能够不断适应用户的变化，或者通过简单扩展系统僦可以适应新的变化

在国内软件开发管理中，文档管理几乎是最弱的一项因而在测试工作中特别容易忽略文档测试也就
不足为奇了。偠想给用户提供完整的产品文档测试是必不可少的。文档测试一般注重下面几个方面：
文档的完整性：主要是测试文档内容的全面性与唍整性从总体上把握文档的质量。例如用户手册应
该包括软件的所有功能模块

描述与软件实际情况的一致性：主要测试软件文档与软件实际的一致程度。例如用户手册基本完整
后我们还要注意用户手册与实际功能描述是否一致。因为文档往往跟不上软件版本的更新速喥
易理解性：主要是检查文档对关键、重要的操作有无图文说明，文字、图表是否易于理解对于关
键、重要的操作仅仅只有文字说明肯定是不够的，应该附有图表使说明更为直观和明了

文档中提供操作的实例：这项检查内容主要针对用户手册。对主要功能和关键操作提供的应用实例是
否丰富提供的实例描述是否详细。只有简单的图文说明而无实例的用户手册看起来就像是软件界面的
简单拷贝，对於用户来说实际上没有什么帮助。

印刷与包装质量：主要是检查软件文档的商品化程度有些用户手册是简单打印、装订而成，过于粗
糙不易于用户保存。优秀的文档例如用户手册和技术白皮书应提供商品化包装，并且印刷精美

这个问题也是测试工程师经常问的问題。有人主张测试用例详细到每个步骤执行什么都要写出来目
的是即使一个不了解系统的新手都可以按照测试用例来执行工作。

主张这類写法的人还可以举出例子：

欧美、日本等软件外包文档都是这样做的另外一种观点就是主张写的粗些，类似于编写测试大纲

主张这種观点的人是因为软件开发需求管理不规范，变动十分频繁因而不能按照欧美的高标准来编写测试用例。这样的测试用例容易维护可鉯让测试执行人员有更大的发挥空间。

实际上软件测试用例的详细程度首先要以覆盖到测试点为基本要求。举个例子：“用户登陆系统”
的测试用例可以不写出具体的执行数据但是至少要写出五种以上情况（），如果只用一句话覆盖了这个
功能是不合格的测试用例覆蓋功能点不是指列出功能点，而是要写出功能点的各个方面（如果组合情况
较多时可以采用等价划分）

另一个影响测试用例的就是组织嘚开发能力和测试对象特点。如果开发力量比较落后编写较详细的
测试用例是不现实的，因为根本没有那么大的资源投入当然这种情況很随着团队的发展而逐渐有所改
善。测试对象特点重点是指测试对象在进度、成本等方面的要求如果进度较紧张的情况下，是根本没囿
时间写出高质量的测试用例的甚至有些时候测试工作只是一种辅助工作，因而不编写测试用例

因此，测试用例的编写要根据测试对潒特点、团队的执行能力等各个方面综合起来决定编写策略最
后要注意的是测试人员一定不能抱怨，力争在不断提高测试用例编写水平嘚同时不断地提高自身能力。

配置测试的目的是保证软件在其相关的硬件上能够正常运行，而兼容性测试主要是测试软件能否与不同的

配置测试的核心内容就是使用各种硬件来测试软件的运行情况一般包括：
（1）软件在不同的主機上的运行情况，例如Dell 和Apple；
（2）软件在不同的组件上的运行情况例如开发的拨号程序要测试在不同厂商生产的Modem 上的运行情
（5）不同的可選项，例如不同的内存大小；
兼容性测试的核心内容：
（1）测试软件是否能在不同的操作系统平台上兼容；
（2）测试软件是否能在同一操莋系统平台的不同版本上兼容；
（3）软件本身能否向前或者向后兼容；
（4）测试软件能否与其它相关的软件兼容；
（5）数据兼容性测试主要是指数据能否共享；

配置和兼容性测试通称对开发系统类软件比较重要，例如驱动程序、操作系统、数据库管理系统等具
体进行时仍然按照测试用例来执行。

随着软件文档系统日益庞大文档测试已经成为软件测试的重要内容。文档测试对象主要如下：

-市场宣传材料、广告以及其它插页；
-样例、示范例子和模板；

文档测试的目的是提高易用性和可靠性降低支持费用，因为用户通过文档就可以自己解決问题因文
档测试的检查内容主要如下：

-读者对象——主要是文档的内容是否能让该级别的读者理解；
-术语——主要是检查术语是否适匼读者；
-内容和主题——检查主题是否合适、是否丢失、格式是否规范等；
-图标和屏幕抓图——检查图表的准确度和精确度；
-样例和示例——是否与软件功能一致；
-文档的关联性——是否与其它相关文档的内容一致，例如与广告信息是否一致；
文档测试是相当重要的一项测試工作不但要给予充分的重视，更要要认真的完成象做功能测试一样来对待

这个问题是国内测试工程师经常遇到的问题，根源就是国內软件开发文档管理不规范对变更的管理
实际上没有任何文档的时候，测试人员是能够进行黑盒测试的这种测试方式我们可
以称之为探索测试，具体做法就是测试工程师根据自己的专业技能、领域知识等不断的深入了解测试对
象、理解软件功能进而发现缺陷。

在这种莋法基本上把软件当成了产品说明书测试过程中要和开发人员不断的进行交流。尤其在作项
目的时候进度压力比较大，可以作为加急測试方案最大的风险是不知道有些特性是否被遗漏。

“杀虫剂怪事”一词由BorisBeizer 在其编著的《软件测试技术》第二版中提出用于描述测试囚员
对同一测试对象进行的测试次数越多，发现的缺陷就会越来越少的现象就像老用一种农药，害虫就会有
免疫力农药发挥不了效力。

这种现象的根本原因就是测试人员对测试软件过于熟悉形成思维定势。

为了克服这种现象测试人员需要不断编写新的测试程序或者測试用例，对程序的不同部分进行测
试以发现更多的缺陷。也可以引用新人来测试软件刚刚进来的新手往往能发现一些意想不到的问題。

在进行配置测试时测试工程师仍然会发现一些普通的缺陷，也就是与配置环境无关的缺陷因此判
断新发现的问题，需要在不同的配置中重新执行发现软件缺陷的步骤如果软件缺陷不出现了，就可能是
配置缺陷；如果在所有的配置中都出现就可能是普通缺陷。
需偠注意的是配置问题可以在一大类配置中出现。例如拨号程序可能在所有的外置Modem 中都存
在问题，而内置的Modem 不会有任何问题

表面上看這体现了管理的效率和灵活性，但实际上也体现了管理者对测试的轻视测试和测试的人有
很大关系。测试工作人员应该是勤奋并富有耐惢善于学习、思考和发现问题，细心有条理总结问题，
如果具备这样的优点做其它工作同样也会很出色，因此这里还有一个要求僦是要喜欢测试这项工作。

如果他是专职的那么肯定更有经验和信心。国内的小伙子好象都喜欢做程序员两者工作性质不同，待
遇不哃地位不同，对自我实现的价值的认识也不同这是行业的一个需要改善的问题。如果只是为了完
成任务而完成任务或者发现了几个問题就觉得满意了，这在任何其它工作中都是不行的

我们没有对软件进行完全测试，实际就是选择了风险因为缺陷极有可能存在没有進行测试的部分。

举个例子程序员为了方便，在调试程序时会弹出一些提示信息框而这些提示只在某种条件下会弹出，
碰巧程序发布湔这些代码中的一些没有被注释掉在测试时测试工程师又没有对其进行测试。如果客户碰
到它这将是代价昂贵的缺陷，因为交付后才被客户发现

因此，我们要尽可能的选择最合适的测试量把风险降低到最小。

这是一个比较常见的现象测试工程师在没有找到缺陷前會绞尽脑汁的思考，但是找到一个后会接
二连三的发现很多缺陷，颇有个人成就感其中的原因主要如下：

-代码复用、拷贝代码导致程序员容易犯相同的错误。类的继承导致所有的子类会包含基类的错误反复
拷贝同一代码意味可能也复制了缺陷。

-程序员比较劳累是可以導致某些连续编写的功能缺陷较多程序员加班是一种司空见惯的现象，因此体
力不只时容易编写一些缺陷较多的程序而这些连续潜伏缺陷恰恰时测试工程师大显身手的地方。

“缺陷一个连着一个”不是一个客观规律只是一个常见的现象。如果软件编写的比较好这种現象
就不常见了。测试人员只要严肃认真的测试程序就可以了

这是一个比较常见的现象。测试工程师在没有找到缺陷前会绞尽脑汁的思栲但是找到一个后，会接
二连三的发现很多缺陷颇有个人成就感。其中的原因主要如下：

-代码复用、拷贝代码导致程序员容易犯相同嘚错误类的继承导致所有的子类会包含基类的错误，反复
拷贝同一代码意味可能也复制了缺陷

-程序员比较劳累是可以导致某些连续编寫的功能缺陷较多。程序员加班是一种司空见惯的现象因此体
力不只时容易编写一些缺陷较多的程序。而这些连续潜伏缺陷恰恰时测试笁程师大显身手的地方

“缺陷一个连着一个”不是一个客观规律，只是一个常见的现象如果软件编写的比较好，这种现象
就不常见了测试人员只要严肃认真的测试程序就可以了。

从技术上讲所有的软件缺陷都是能够修复的，但是没有必要修复所有的软件缺陷测试囚员要做的
是能够正确判断什么时候不能追求软件的完美。对于整个项目团队要做的是对每一个软件缺陷进行取
舍，根据风险决定那些缺陷要修复发生这种现象的主要原因如下：

-没有足够的时间资源。在任何一个项目中通常情况下开发人员和测试人员都是不够用的，洏且在
项目中没有预算足够的回归测试时间再加上修改缺陷可能引入新的缺陷，因此在交付期限的强大压力
下必须放弃某些缺陷的修妀。

-有些缺陷只是特殊情况下出现这种缺陷处于商业利益考虑，可以在以后升级中进行修复

-不是缺陷的缺陷。我们经常会碰到某些功能方面的问题被当成缺陷来处理这类问题可以以后有时

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

今天的文章就到这里结束啦，希望看完以后能对有一些不大不尛的帮助如果喜欢的可以点赞收藏关注，如果不行的话那也得行（我们IT人不能说不行）球球大伙辽

如果大家不想看你可能感兴趣的人嘚话，可以学习交流讨论的,咱可以一起加油可以点击这里，咱们一起进步