测试开发面经

综合面试问题

为什么想做测试开发这个岗位？

答：在研究生一年级的时候，我学了一门课叫高级软件测试，课上有一句名言我印象特别深刻，过少的测试是犯罪，过多的测试是罪过。

软件测试是一个产品上线前的最后一道防线，控制软件质量，我觉得这是很有意义的一个工作。

如果在测试中发现一个bug，但是开发经理不认为这是一个bug，应该怎么解决？

产生这种有争议的Bug的几个原因有

首先可能是测试人员自己的问题，是否描述该bug不太清晰，使得开发人员难以理解或者产生了歧义，这个时候要修改自己的描述，一定要清晰明了，无歧义，无冗余的步骤 其次可能是需求型的bug，找产品经理沟通清楚该产品的需求，判断是测试人员还是开发人员对该需求判断有误 还有可能是低概率性的Bug，出现了难以复现的bug，这个时候要结合严重性、频繁性、对用户的影响以及产品交付时间与开发共同衡量是否修复该bug，即使是选择暂不修复，也需要将该Bug详细地提交备案。

如何理解测试和测试开发？

测试就是在规定条件下检测产品功能或者程序上的错误，对其是否满足设计要求进行评估。

测试开发需要开发一些自动化测试的平台或者二次开发一些现有的开源工具，最终目的是提升测试效率，但是核心职能仍然是测试。

如果遇到一些低概率性的bug会怎么办？

首先要认真记录引发该bug的情况（当时的测试环境、测试数据、出现问题前的操作），不应该在测试报告中因为出现概率低而忽略这些bug的存在

其次，会根据严重性、频繁性、对用户的影响这三个因素共同做决定，严重性就是判断该bug是否导致严重的后果，比如是不是会让整个程序崩溃？会导致用户信息丢失吗？还是仅仅是无关痛痒的小问题？；频繁性就是指在用户使用的过程中是否会经常碰到该类问题？还是这个bug出现在某些不太常用的功能中；对用户的影响是指是否会影响到全部用户的使用？还是只影响部分用户的使用？（比如说这个bug所在的程序如果只出现在app的旧版本中，那么它对用户的影响就很小）

为什么一直都在实习？

  • 我研一的时候因为课还是比较多的，课余时间没有事情做，就通过操作，挤出时间学习。（时间多）
  • 我的导师比较放养，没有有价值的项目可以给我做。（没项目）
  • 我对互联网行业特别感兴趣，在学校的视野太窄了。（有兴趣）

综上所述，所以我早早的就出来实习了。

测试知识类

软件测试方法分类

黑盒测试

概念：不考虑其内部结构，即具体代码实现，检测软件的各个功能能否得以实现，确认软件功能的正确性，依靠软件说明书来判断测试用例,关注具体的客户需求及软件功能。黑盒测试主要是为了发现：1.是否有不正确的或者遗漏的功能；2.输入是否能输出正确的结果；3.性能上是否满足要求

优点：①较为简单，不需要了解程序内部的代码及实现，与软件内部实现无关；②从用户角度出发，实际考虑用户使用的功能及可能出现的问题

缺点：不可能覆盖所有的代码，覆盖率较低

  • 等价类：输入域的各子集中，各个输入数据对于揭露程序中的错误都是等效的。

  • 等价类划分：将全部输入数据合理划分成若干个等价类，在每一个等价类中取一个数据作为输入条件，就可以用少量代表性测试数据取得较好的测试结果。分为有效等价类（合理、有意义的输入数据构成的集合）和无效等价类

  • 边界值分析法：大量错误是发生在输入输出范围的边界上，选定测试用例时应该选取正好等于、刚刚大于、刚刚小于边界值的值作为测试数据，而不是选取等价类中的任意值，作为对等价类划分的补充

  • 错误猜测法：基于经验和直觉推测，列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据这些情况选择测试用例

  • 因果图法：考虑输入条件之间的相互组合，也考虑输出结果对输入条件的依赖关系。原因即为输入条件或者输入条件的等价类，结果即为输出条件，把因果转换为决策表，为决策表中的每一列设计测试用例。

  • 场景分析法：根据用户场景来模拟用户的操作步骤

  • 大纲法：着眼于需求。将需求转换为大纲的形式，大纲表示为树状结构，在根和叶子节点之间存在唯一路径，大纲为每条路径定义了一个特殊的输入条件集合，用于测试用例。

  • 随机测试法：不考虑任何用例和需求，完全站在用户的角度对产品进行测试

  • 灰盒测试：关注输入输出的准确性，也关注内部的代码，但是没有白盒测试那么详细完整。

白盒测试

概念：关注程序代码的具体细节，根据软件内部代码的逻辑结构分析来进行测试。主要是通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件质量。关注代码的实现细节。主要对程序模块的所有独立执行路径至少测试一遍、对所有的逻辑判定，取“真”或“假”的两种情况都要测试一遍，循环边界和运行界限内执行循环体等等

测试用例设计方法：逻辑覆盖、循环覆盖、基本路径覆盖、判定覆盖

优点：增大代码的覆盖率，提高代码的质量，发现代码中隐藏的问题

缺点：系统庞大时测试开销很大，难以测试所有运行路径；测试基于代码，只能验证代码是否正确，而不晓得代码设计是否合理，可能会遗漏某些功能需求

白盒测试的测试用例设计方法都有哪些？

白盒测试用例设计技术可分为逻辑覆盖和路径覆盖，逻辑覆盖又可分为以下几种，从弱到强： 语句覆盖（SC）：设计足够多的测试用例，确保每条语句都被执行过。 判定覆盖（DC）：设计足够多的测试用例，确保每个判定都分别取真值与假值。 条件覆盖（CC）：设计足够多的测试用例，确保每个条件都分别取真值与假值。（一个判定里可能包含多个条件） 判定/条件覆盖（DCC）：设计足够多的测试用例，确保每个判定和条件分别取真值和假值。 条件组合覆盖（CMC）：设计足够多的测试用例，确保覆盖每个判定中的各个条件的所有组合情况。（只考虑同一个判定内的各条件组合情况） 路径覆盖：设计足够多的测试用例，确保每条路径都被执行。如果程序复杂，比如包含循环的情况，路径覆盖的测试用例数将会是个天文数字，无法实现。 可以采用简化了的路径覆盖，即将循环看成是一个判定，只考虑循环被执行和未执行两种情况。

软件测试阶段分类

1.单元测试 针对软件设计最小单位——程序模块进行正确性检测。

检查程序模块的功能、性能、接口等。

多个模块可以平行独立地进行单元测试。需要从程序的内部结构出发设计测试用例。需要读程序和代码，大多数时候可以由开发人员自己完成。

（独立测试小积木块儿）

2.集成测试 在单元测试基础上，将所有程序模块组装起来，进行有序、递增的测试。（把多个程序模块拼接起来测试）

比较多涉及到接口测试

（把小积木块儿逐个拼在一起测试）

3.系统测试 在系统的真实运行环境下，检查完整的程序系统是否可以和硬件、外设、网络和系统软件、支持平台等正确配置、连接。

全方位的，需要考虑与硬件系统、系统软件、其他软件的联系。

（把这个整体拼好的积木放在真实环境下测试）

4.验收测试 是测试的最后一个环节，一般由供求双方共同达成的，模拟用户实际运行的环境，对功能模块全面测试。

有两种测试主体：

α测试：开发人员在开发环境下的测试 β测试：用户在实际运行的环境下进行测试

web测试和app测试的区别

web测试中只要更新了服务器，客户端也会同步更新，保证每个客户的客户端（或者说浏览器）一样；app必须得客户端主动更新，所以app测试中修改了服务器，客户端的所有核心版本都需要进行回归测试 性能方面：web主要看响应速度，app还要看电量、流量、cpu、内存等 兼容方面：web基于浏览器，主要看电脑硬件和电脑系统；app依赖于手机或平板等移动端，关注的系统主要是安卓或者ios，还要关心分辨率、屏幕尺寸 app要多一些专项测试：中断测试、界面操作、安装、卸载、更新等

API测试

我们常说的是比较狭义的API，指的是Web service或者Web API。 所以一般API测试指的是：直接测试应用程序编程接口（API），并作为集成测试的一部分来确定它们是否满足功能、可靠性、性能和安全性的期望。

应用程序通常有三层：表示（UI）层、业务逻辑层（API层）和数据层。 API层包含应用程序的业务逻辑——用户如何与应用程序的服务、数据或功能交互的规则。 由于业务逻辑层直接触及数据层和表示层，因此它为QA和开发团队提供了持续测试的最佳场所。虽然传统的测试主要集中在UI上，但是API测试的优势正变得众所周知。

API自动化测试的介绍

接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等

通俗一点就是输入数据，返回数据，不同种类的接口应用层协议可能不一样，传输的数据格式也可能不一样。检查业务逻辑是否满足业务需求，校验字段是否正常你实际结果是否满足预期。

接口就是前段和后端的一个桥梁，那前端的界面要如何展示出来呢，它需要通过接口从服务端去获取。目前很多的项目都是前端和后端分离开发的，前端，后端开发完成，只需要做一个联调就好了，前端没有数据也能够进行开发，我们只需要通过Mock就可以完成了。

接口类型主要包含三种测试：

  • Web接口测试
  • 应用程序接口（API, application programming interface）测试
  • 数据库测试

单元测试的辅助模块?

1.驱动程序：用于模拟主程序的运行

驱动模块的使命就是根据测试用例的设计去调用被测试模块，并且判断被测试模块的返回值是否与测试用例的预期结果相符。

2.桩模块：用于模拟子程序的运行

桩模块的使命除了使得程序能够编译通过之外，还需要模拟返回被代替的模块的各种可能返回值(什么时候返回什么值需要根据测试用例的情况来决定)。

软件测试的基本流程

1.测试需求阶段：阅读软件需求规格说明书，理解需求，分析需求点

2.测试计划阶段：参考软件需求说明书来编写测试计划，内容需包括测试范围、进度安排、人力物力分配、整体测试策略

3.测试设计阶段：编写测试用例，评审测试用例

4.测试执行阶段：搭建环境，执行预测试（即冒烟测试），然后进入正式测试，提交bug，追踪bug，直到软件达到测试需求要求

5.测试评估阶段：给出测试报告，确认产品是否可以上线

软件缺陷的等级应如何划分？

答：虽然有很多公司对这个缺陷的等级划分有不同标准，但是一般都是会遵循以下的原则： 极高：在测试的过程中出现死机，系统崩溃、数据丢失，功能没有实现等此类缺陷的级别； 很高：此类缺陷导致软件系统功能不稳定，或功能实现错误，流程错误等。 中等：校验错误、罕见故障、错别字等不会影响软件系统主流程的功能，但会影响用户易用性等的错误。 较低：对软件系统没影响的一些小问题。

测试结束的标准是什么？

1)软件系统在进行系统测试过程中，发现一、二级缺陷数目达到项目质量管理目标要求，测试暂停返回开发； 2)软件项目在其开发生命周期内出现重大估算和进度偏差，需暂停或终止时，测试应随之暂停或终止，并备份暂停或终止点数据； 3)如有新的需求变更过大，测试活动应暂停，待原测试计划和测试用例修改后，再重新执行测试； 4)若开发暂停，则相应测试也应暂停，并备份暂停点数据； 5)所有功能和性能测试用例100％执行完成； 此外，测试是有成本的，当你2周内才发现2个bug这种情况时，在产品质量要求不是十分严格的情况下，即可以停止测试了。

软件的生命周期

软件的生命周期：计划阶段——>需求分析——>设计阶段——>编码——>测试——>运行和维护

产品的生命周期：导入期——>成长期——>成熟期——>衰退期

bug的生命周期：发现Bug—>提交Bug—>指派bug—>研发确认bug—>研发修复bug—>回归验证bug—>关闭bug

集成测试和系统测试

1）集成测试是界于单元测试和系统测试之间，起到“桥梁作用”，一般由开发小组采用白盒加黑盒的方式来测试，既验证“设计”，又验证“需求”；

2）系统测试的力度最大，一般由独立测试小组采用黑盒方式来测试，主要测试系统是否符合“需求规格说明书”，系统测试是在经过单位测试和集成测试的阶段测试确认之后，把系统完整地模拟客户环境来进行的测试的。

系统测试是在集成测试完成之后进行的测试，所以它们之间的关系比较紧密。

一般测试用例的设计要点

功能性、性能性、安全性、易用性、界面测试、（网络测试、中断测试）—>app/网站类似的才需要、边界值测试、压力测试

如何理解压力、负载、性能测试？

性能测试是一个较大的范围，实际上性能测试本身包含了性能、强度、压力、负载等多方面的测试内容。

1）压力测试是标准工作环境下，通过不断增加系统负荷，最终测试出该系统能力达到的最大负荷(稳定和峰值)。是对服务器的稳定性以及负载能力等方面的测试，是一种很平常的测试。在增大访问系统的用户数量、或者几个用户进行大数据量操作都是压力测试。 2）而负载测试是压力相对较大的测试，主要是测试系统在一种或者几种极限条件下的响应能力，是性能测试的重要部分；100个用户对系统进行连续半个小时的访问可以看作压力测试，那么连续访问8个小时就可以认为负载测试，1000个用户连续访问系统1个小时也可以看作是负载测试。 3）实际上压力测试和负载测试没很明显的区别，测试人员应该站在关注整体性能的高度上来对系统进行性能测试。

什么是系统瓶颈？

系统瓶颈主要是指整个软硬件构成的软件系统某一方面或者几个方面能力不能满足用户的特定业务要求的一种表现。

举个测试的例子？

拿大家每天都乘搭的升降电梯来说，电梯看起来是一个机械辅助设备，但是它的背后，肯定是有一个电脑控制系统，每栋大厦的电梯都会根据需求进行设计，所以，每个电梯都应该进行独立测试。

  1. 功能测试：假设电梯有20层楼，我们先测试按下每一层楼的按钮，电梯都能停靠，按由上往下或者由下往上的顺序。电梯每次停下与各楼层是否保持平行（部分楼层高度不一样，也是考虑点）。包括报警按钮是否能接通等等。
  2. 压力测试：测试电梯最大负载，直到电梯奔溃，这里还要考虑到重力加速度的问题
  3. 性能测试：测试电梯的装载能力是否满足要求 ，区别于压力测试，如果荷载1000KG，测试999KG，1000KG，1001KG三种情况，考虑重力加速度
  4. 可靠性测试：假设电梯的一个角落站满了200公斤的大胖子，另一个角落都是小朋友，电梯是否会出现倾斜、异常报警等
  5. 安全测试，电梯是否通风。出现急速下坠时紧急制动程序是否能运作。出现停电时报警按钮是否能正常使用。当电梯在上升/降落过程中，按开门按钮，门不能打开。假设电梯从3楼上升到20楼，当电梯匀速上升到5楼，此时6楼有人按电梯，因为速度太快，不应该马上停下来。
  6. 还有很多问题都会在测试过程中发现这就是软件测试的意义，提早发现问题，提升用户体验，排查一切风险。

为什么要设置图形验证码，如12306？

频率：字节实习

本意是为了让用户好辨认，让机器难辨认。但实际上并没有降低破解难度，反而降低了用户体验。图都是低分辨率图片，无需机器学习，用公共的服务如百度搜图等就可以破解，所以图形验证码是不靠谱的。

  • 图片过于复杂、混淆过多、条件太诡异时会挡住大部分正常用户
  • 容易被枚举，题库太弱，不如字符组合可能性多
  • 破解门槛不一定高于字符型Captcha

测试设计题

主要从功能性、性能性、安全性、易用性、兼容性、网络测试这几个方面来设计，需要考虑问题的角度全面

注意如果是手机端app测试的话需要加上中断测试这项（考虑后台切换、app切换、拔插数据线、来短信/电话/其他app消息）

朋友圈点赞状态

出现频率：字节跳动一面

功能测试：点赞某条朋友圈，验证是否成功。 1.是否可以正常点赞和取消； 2.点赞的人是否在可见分组里； 接口测试：点赞朋友圈，验证朋友是否能收到。 3.点赞状态是否能即时更新显示； 4.点赞状态，共同好友是否可见； 兼容性测试：在不同的终端如ipad，手机点赞朋友圈，验证是否成功 5.不同手机，系统显示界面如何； 性能测试：点赞朋友圈是否在规定的时间显示结果，是否规定时间进行提示。 6.性能检测，网速快慢对其影响； 7.点赞显示的是否正确，一行几个； 8.点赞是否按时间进行排序，头像对应的是否正确； 9.是否能在消息列表中显示点赞人的昵称、备注； 10.可扩展性测试，点赞后是否能发表评论； 11.是否在未登录时可查看被点赞的信息。

微信群发红包

功能 1.在红包钱数，和红包个数的输入框中只能输入数字 2.红包里最多和最少可以输入的钱数 200 0.01 3.拼手气红包最多可以发多少个红包 100 3.1超过最大拼手气红包的个数是否有提醒 4.当红包钱数超过最大范围是不是有对应的提示 5.当发送的红包个数超过最大范围是不是有提示 6.当余额不足时，红包发送失败 7.在红包描述里是否可以输入汉字，英文，符号，表情，纯数字，汉字英语符号， 7.1是否可以输入它们的混合搭配 8.输入红包钱数是不是只能输入数字 9.红包描述里许多能有多少个字符 10个 10.红包描述，金额，红包个数框里是否支持复制粘贴操作 12.红包描述里的表情可以删除 13.发送的红包别人是否可以领取 13.1发的红包自己可不可以领取 2人

  1. 24小时内没有领取的红包是否可以退回到原来的账户 14.1 超过24小时没有领取的红包，是否还可以领取 15.用户是否可以多次抢一个红包 16.发红包的人是否还可以抢红包 多人 17.红包的金额里的小数位数是否有限制 18.可以按返回键，取消发红包
  2. 断网时，无法抢红包 20.可不可以自己选择支付方式 21.余额不足时，会不会自动匹配支付方式 22.在发红包界面能否看到以前的收发红包的记录 23.红包记录里的信息与实际收发红包记录是否匹配 24.支付时可以密码支付也可以指纹支付 25.如果直接输入小数点，那么小数点之前应该有个0 26.支付成功后，退回聊天界面 27.发红包金额和收到的红包金额应该匹配 28.是否可以连续多次发红包 29.输入钱数为0，“塞钱进红包”置灰

性能 1.弱网时抢红包，发红包时间 2.不同网速时抢红包，发红包的时间 3.发红包和收红包成功后的跳转时间 4.收发红包的耗电量 5.退款到账的时间

兼容 1.苹果，安卓是否都可以发送红包 2.电脑端可以抢微信红包

界面 1.发红包界面没有错别字 2.抢完红包界面没有错别字 3.发红包和收红包界面排版合理， 4.发红包和收到红包界面颜色搭配合理

安全 1.对方微信号异地登录，是否会有提醒 2人 2.红包被领取以后，发送红包人的金额会减少，收红包金额会增加 3.发送红包失败，余额和银行卡里的钱数不会少 4.红包发送成功，是否会收到微信支付的通知

易用性(有点重复) 1.红包描述，可以通过语音输入 2.可以指纹支付也可以密码支付

手机app发帖子测试点

请从不同维度设计测试点：用户使用手机app发表一篇帖子，帖子内容包含文字，图片，定位信息等多种富文本数据。

功能点测试 流程测试 交叉测试，来电、短信等app进入后台 内存不足测试 编辑过程中应用切换测试 重复提交测试

测试登录页面

1.基本流程功能验证

  • 如果用户未注册，提示请先注册，然后进行登陆
  • 输入正确的用户名和密码能够登陆，进入系统
  • 输入错误的用户名或者密码不能够登陆，不能进入系统

2.页面测试

  • 登陆页面显示是否正常：文字和图片能否正常显示，相应的提示信息是否正确（如系统试运行时间提示等），按钮的设置和排列是否正常，页面是否简洁美观等
  • 页面的默认焦点是否定位在用户名的输入框中
  • 第一次登陆时相应的输入框是否为空
  • 相应的按钮如登陆，重置等，是否置为灰白或者可用；页面的前进和后退按钮，刷新按钮是否可用
  • 快捷键Tab，Esc，Enter等，能否控制使用

3.兼容性测试：不同浏览器，不同操作系统，不同分辨率等下，登陆界面能否正常显示

4.深入测试

  • 用户名是否支持中文？
  • 用户名是否支持特殊字符？
  • 用户名是否有长度限制？
  • 密码是否支持中文？
  • 密码是否支持特殊字符？
  • 密码是否有长度限制？
  • 密码是否支持大小写？
  • 密码为一些简单常用字符串时，是否弹出建议更换密码的友好提示？（123456，111111… ）
  • 密码存储是否已加密？
  • 用户名正确，密码错误，是否提示输入密码错误？
  • 用户名错误，密码正确，是否提示输入用户名错误？
  • 用户名和密码都错误时，是否有相应的提示？
  • 用户未注册时，是否有相应的提示？
  • 用户名密码为空时，是否有相应的提示？
  • 连续输入3次或以上错误密码，用户是否被锁一定时间（例如：15分钟）？时间点内不允许登陆，超出时间点是否可以继续登陆？
  • 用户session过期后，重新登陆是否还能重新返回之前session过期的页面？
  • 用户名和密码输入框是否支持键盘快捷键？如：撤销（Ctrl＋z）、复制（Ctrl＋c）、粘贴（Ctrl＋v）等等。
  • 是否允许同名用户同时登陆进行操作？（考虑web和手机同时登陆）
  • 手机登陆时，是否先判断网络可用？
  • 手机登陆时，是否先判断app存在新版本？
  • 是否支持单点登陆？

5.安全测试

  • 是否使用https技术？
  • 密码在数据库中是否以加密方式存储？
  • 是否存在sql注入风险？
  • 密码是否保存在本地的cookie中？

5.性能测试

  • 单用户登陆系统的响应时间是否符合“3-5-8”原则。（3s之内得到响应，那么给客户的感觉是该系统性能十分优秀；5s之内请求得到响应，用户会感觉还不错；
  • 超过8s甚至更长的时间以后，用户很有可能就失去信心）
  • 用户数在临界点时并发登陆是否还能够符合“3-5-8”原则？

6.压力测试

大量并发用户（超过临界点）登陆，系统的响应时间是多少呢？系统会出现宕机、内存泄露、cpu饱和、用户无法登陆的情况吗？

7.稳定性测试

系统能否处理并发用户数在临界点以内连续登陆3小时、8小时、24小时乃至72小时的场景吗？

一个web页面操作响应过慢，如何定位原因？

  • top、iostat查看cpu、内存及io占用情况
  • 内核、程序参数设置不合理：查看有没有报内核错误，连接数用户打开文件数这些有没有达到上限等等
  • 链路本身慢：是否跨运营商、用户上下行带宽不够、dns解析慢、服务器内网广播风暴什么的
  • 程序设计不合理：是否程序本身算法设计太差，数据库语句太过复杂或者刚上线了什么功能引起的
  • 其它关联的程序引起的：如果要访问数据库，检查一下是否数据库访问慢
  • 是否被攻击了：查看服务器是否被DDos了等等
  • 硬件故障 这个一般直接服务器就挂了，而不是访问慢

做压力测试时，需要在负载机模拟大量用户，如何判断负载机本身不会成为瓶颈？

如果输入一个url,没有访问到你预期的网站,原因可能是什么？

1.DNS坏掉了,修改自己的ip为8.8.8.8试试

2.网断了

3.服务器拒绝访问

4.请求/响应在网络传输中途被劫走

测试工具题

jenkins用来做什么的？

Jenkins 是一个开源的实现持续集成的软件工具，能实时监控集成中存在的错误，提供详细的日志文件和提醒功能，还能用图表的形式形象地展示项目构建的趋势和稳定性。

持续集成？

持续集成，Continuous integration ，简称CI。所谓**集成测试就是把所有的单元测试跑一遍以及其它一些能自动完成的测试。**只有在本地电脑上通过了集成测试的代码才能上传到git服务器上，保证上传的代码没有问题。

  • 它是一个自动化的周期性的集成测试过程，从检出代码、编译构建、运行测试、结果记录、测试统计等都是自动完成的，无需人工干预；
  • 需要有专门的集成服务器来执行集成构建；
  • 需要有代码托管工具支持；

持续集成的作用

  • 保证团队开发人员提交代码的质量，减轻了软件发布时的压力；
  • 持续集成中的任何一个环节都是自动完成的，无需太多的人工干预，有利于减少重复过程以节省时间、费用和工作量；

持续集成（CI）的流程

该系统的各个组成部分是按如下顺序来发挥作用的：

  • 开发者检入代码到源代码仓库。
  • CI系统会为每一个项目创建了一个单独的工作区。当预设或请求一次新的构建时，它将把源代码仓库的源码存放到对应的工作区。
  • CI系统会在对应的工作区内执行构建过程。
  • （配置如果存在）构建完成后，CI系统会在一个新的构件中执行定义的一套测试。完成后触发通知(Email,RSS等等)给相关的当事人。
  • （配置如果存在）如果构建成功，这个构件会被打包并转移到一个部署目标(如应用服务器)或存储为软件仓库中的一个新版本。软件仓库可以是CI系统的一部分，也可以是一个外部的仓库，诸如一个文件服务器或者像Java.net、SourceForge之类的网站。
  • CI系统通常会根据请求发起相应的操作，诸如即时构建、生成报告，或者检索一些构建好的构件。

什么是Selenium？

1）测试与浏览器的兼容性：测试应用程序能否兼容工作在不同浏览器和操作系统之上。

2）测试系统功能：录制用例自动生成测试脚本，用于回归功能测试或者系统用例说明。

简而言之，Selenium 就是一款可以录制用户操作，帮助 Web 测试人员简化重复劳动的工具。

Selenium实现原理？

Selenium 引入了 Remote Control Server 这样一个代理 Server，JavaScript 脚本注入和与 Server 通讯都通过这个代理 Server 来进行。

之所以引入这个代理 Remote Control Server 是因为“同源策略”的限制，通过这个代理服务器来“欺骗”远程 Server，达到使其以为是从同一个地方 load 代码以正确返回请求数据的效果。

流程说明：

客户端建立与 selenium-RC server 的连接。 Selenium RC Server 启动一个浏览器（或是已经使用中），并注入 JS 代码 将 Selenese 代码传到客户端的 Selenium-Core 中。 Selenium-Core 翻译并解析执行用户录制的操作。 让代理 Server 进行通讯 Remote Control Server 负责跟远程 Web 应用服务器进行通讯。 操作完成，显示结果，并执行下一指令。

Chromedriver怎么驱动的，原理是什么？

WebDriver是一个开源工具，用于在许多浏览器上自动测试webapps。它提供了导航到网页，用户输入，JavaScript执行等功能。ChromeDriver是一个独立的服务，它为 Chromium 实现 WebDriver 的 JsonWireProtocol 协议。

系统测试题

升级http协议到https协议，我们需要测试哪些东西？

先说http和https的区别。

  • http协议：是超文本传输协议，被用于在web浏览器和网站服务器之间传递信息。http协议工作是以明文方式发送内容，不提供任何形式的数据加密，而这也是很容易被黑客利用的地方，如果黑客截取了web浏览器和网站服务器之间的传输信息，就可以直接读懂其中的信息，因此http协议不适合传输一些重要的、敏感的信息，比如信用卡密码及支付验证码等。
  • 安全套接字层https协议就是为了解决http协议的这一安全缺陷而出生的，为了数据传输的安全，https在http的基础上加入了ssl协议，ssl依靠证书来验证服务器的身份，为浏览器和服务器之间的通信加密，这样的话即使黑客借去了发送过程中的信息，也无法破解读懂它，我们网站及用户的信息便得到了最大的安全保障。
  • HTTPS和HTTP的区别主要为以下四点： 1、安全协议配置费用，https协议需要到ca申请证书，一般免费证书很少，需要交费; 2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议; 3、http和https使用的是完全不同的连接方式，用的端口不一样，前者是80，后者是443; 4、http的连接很简单，是无状态的;https协议是由ssl+http协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。 简单来说，http协议+安全套=https协议。

1.一些配置未修改，比如文件服务器 2.有一些url是在代码写死的，需要更新 3.部分同事更新有遗漏 4.有些页面是通过类CMS配置的，需要更新域名 5.我方接口与其他第三方机构联调的，需要互相更新 6.我方接口内部与其他系统 或 web客户的数据互传的，可能会影响

如何测试一个多线程安全的日志类库？

使用以下代码测试打印出来的日志序号是否顺序

for(int i = 0; i <= 100; i++){
Thread t = new Thread(new MultithreadingLog("JOB" + i));
t.start();
}

如何测试一个IM（即时通信）系统？

登录 注册 好友管理：增删改好友 消息收发：消息发送接收 安全：本地密码保存加密、消息网络通讯加密

给你一个网站，你如何测试？

首先，查找需求说明、网站设计 等相关文档，分析测试需求。

制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：

功能性测试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试

设计测试用例

功能性测试：

可以包括，但不限于以下几个方面：

链接测试：链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回等。

提交功能的测试。

多媒体元素是否可以正确加载和显示。

多语言支持是否能够正确显示选择的语言等。

界面测试：页面是否风格统一，美观。页面布局是否合理，重点内容和热点内容是否突出

控件是否正常使用。对于必须但为安装的空间，是否提供自动下载并安装的功能。文字检查

性能测试：一般从以下两个方面考虑：压力测试；负载测试；

数据库测试：要具体决定是否需要开展。数据库一般需要考虑连结性，对数据的存取操作，数据内容的验证等方面。

安全性测试：

1 基本的登录功能的检查

2 是否存在溢出错误，导致系统崩溃或者权限泄露

3 相关开发语言的常见安全性问题检查，例如 SQL 注入等。

4 如果需要高级的安全性测试，确定获得专业安全公司的帮助，外包测试，或者获取支持

兼容性测试：根据需求说明的内容，确定支持的平台组合：

浏览器的兼容性；操作系统的兼容性；软件平台的兼容性；数据库的兼容性

开展测试，并记录缺陷。合理的安排调整测试进度，提前获取测试所需的资源，建立管理

体系（例如，需求变更、风险、配置、测试文档、缺陷报告、人力资源等内容）。

定期评审，对测试进行评估和总结，调整测试的内容。

滴滴和12306联合项目之间接口如何测试？

接口不能调用/系统不能访问的解决思路

你如果发现系统接口不能调用了或者系统不能访问了，你将如何解决？思路是什么？让我们总结一下吧！

1.确认被调用接口地址或系统域名是否输入正确

2.域名是否可以正常解析（nslookup）

3.域名对应IP和端口是否可以访问（ping/telnet）

4.确认是否有做变更

5.若有变更，需明确变更内容，根据变更内容进行相应模块排查，确认是否需要清理缓存

6.明确访问链路

7.链路上各个服务是否存在异常(ps/netstat)

8.查看链路上对应服务日志

9.请求是否能够正常到达最末端服务器（tcpdump）