100道

1.web端和app端测试的相同点和不同点的是？

答：

相同点：

1）设计测试用例时，依然都是依据边界值分析法、等价类划分等；

2）多数采用黑盒的测试方法，来验证业务功能是否得到正确的应用；

3）需要检查界面的布局、风格和按钮等是否简洁美观、是否统一等；

4）测试页面载入和翻页的速度、登录时长、内存是否溢出等；

5）测试应用系统的稳定性等。

不同点：

1. 系统架构：web端系统，更新服务器，不需要更新客户端；APP如果更新了服务端，客户端也要更新并测试；
2. 兼容性。Web端要考虑不同的浏览器内核进行测试（IE、chrome、Firefox），APP的兼容性要考虑选择主流的机型，不同的分辨率、尺寸， 以及不同的操作系统；
3. App要考虑交叉事件测试，安装，卸载，前后台切换测试；
4. App还要考虑界面操作，如：横竖屏切换，多点触控，事件触发区域。

2.los和Android测试的侧重点是？

答：

• android运行基于虚拟机，ios则是沙盒机制
• android是真后台，ios是伪后台，所以安卓才会卡
• 分辨率：iOS 覆盖的分辨率和系统是有限的。
• 兼容性：Android 比较碎片化，覆盖的机型版本比iOS 更多android有各种定制rom，手机型号太多。
• 权限：安卓还要特别考虑权限，6.0是分水岭
• 应用安装渠道：安卓比较多

3.如何测试一个app的登录场景？

答：

●登录用户名和密码错误时，界面有提示信息

●用户主动退出登录后，下次启动APP时，应该进入登录界面

●对于支持自动登录的APP，数据交换时，是否能自动登录成功且数据库操作无误

●密码更改后，登录时是否做到了有效数据的校验

●对于未登录时一些页面的操作，是否做了控制

●切换账号登录，检验登录的信息是否做到及时更新

●对于多个端都进行操作时，确保数据库操作无误，且每个端可以及时看到数据的更新

●对于一些软件，支持一个账号只允许登录一台机器，这时，需要检查账号登录多个手机时，是否将原用户剔除，且能够给出提示信息

● APP切换到后台时，再次切换到前台的测试，如登录时，有电话打进来

●对于IOS与android不同设备登录同一个账号时，对个人信息等数据进行操作后，确保数据数库操作无误，且IOS与android设备看到的数据都是最新的。

4.Push消息测试如何测试？

答：

push消息针对不同的用户群体：

全部用户    部分用户    特定用户

1、push消息能否按照正确的业务流程进行推送

2、push消息针对特定的用户时，后台检测是否推送正确给特定用户

3、当用户离线时，能否接收到push消息

4、当用户离线3天时，能否接收到最早之前的消息

5、当用户选择不接收消息推送时，那么是否还有消息推送

5.app的闪退通常是什么原因造成的？

答：

   1.缓存垃圾过多

       由于安卓系统的特性,如果长时间不清理垃圾文件.会导致越来越卡.也会出现闪退情况.

  2. 运行的程序过多,导致内存不足

  3.应用版本兼容问题

         如果应用版本太低，会导致不兼容，造成闪退。此外，有些新版本在调试中，也会造成应用闪退。

          解决方法：如果是版本太旧，更新为新版本即可；如果是新版本闪退，可能是应用在改版调试，可卸载后安装旧版。

 4.. 检查APP中访问网络的地方，组件中的ImageView是否可以正常的下载并显示到app 页面上。   

  5.检查APP的sdk和手机的系统是否兼容。

 6.在一些特定情况下的闪退,比如播放视频,在Android5.0 升级到Android6.0的时候,有些系统API老版本有,新版本没有,到时回去对象的时候失败,报空,系统就会出现闪退问题.

6.常见的接口协议是什么？

答：

1、HTTP  超文本传输协议

2、HTTPS  安全超文本传输协议

3、FTP  文件传输协议( Xshell的文件拖拽)

4、TCP 网络控制协议

5、IP  互联网协议

6、UDP  用户数据协议

7.常见的接口方式是什么？

答：

1、Get 向特定资源发出请求（请求指定页面信息，并返回实体主体）
2、Post 向指定资源提交数据进行处理请求（提交表单、上传文件），又可能导致新的资源的建立或原有资源的修改
3、Put 向指定资源位置上上传其最新内容（从客户端向服务器传送的数据取代指定文档的内容）
4、Head 与服务器索与get请求一致的相应，响应体不会返回，获取包含在小消息头中的原信息（与get请求类似，返回的响应中没有具体内容，用于获取报头）
5、Delete 请求服务器删除request-URL所标示的资源（请求服务器删除页面）
6、opions 返回服务器针对特定资源所支持的HTML请求方法 或web服务器发送测试服务器功能（允许客户端查看服务器性能）

8.常见的状态码是什么以及都有什么意思请解释说明？

答：

 200 OK    表示从客户端发来的请求在服务器端被正常处理了。

3XX 重定向

301   永久性重定向。 该状态码表示请求的资源已被分配了新的 URI， 以后应使用资源现在所指的 URI。 

302   临时性重定向。 

303   该状态码表示由于请求对应的资源存在着另一个 URI， 应使用 GET方法定向获取请求的资源

304   该状态码表示客户端发送附带条件的请求时， 服务器端允许请求访问资源， 但未满足条件的情况。 304 状态码返回时， 不包含任何响应的主体部分。

4XX 客户端错误

4XX 的响应结果表明客户端是发生错误的原因所在

400   该状态码表示请求报文中存在语法错误。 当错误发生时， 需修改请求的内容后再次发送请求。 另外， 浏览器会像 200 OK 一样对待该状态码。

401   该状态码表示发送的请求需要有通过 HTTP 认证（BASIC 认证、DIGEST 认证） 的认证信息。

403   该状态码表明对请求资源的访问被服务器拒绝了。 服务器端没有必要给出拒绝的详细理由， 但如果想作说明的话， 可以在实体的主体部分对原因进行描述， 这样就能让用户看到了。

404   该状态码表明服务器上无法找到请求的资源。 除此之外， 也可以在服务器端拒绝请求且不想说明理由时使用。

5XX 服务器错误

5XX 的响应结果表明服务器本身发生错误。

500  该状态码表明服务器端在执行请求时发生了错误。 也有可能是 Web应用存在的 bug 或某些临时的故障

503  该状态码表明服务器暂时处于超负载或正在进行停机维护， 现在无法处理请求。 如果事先得知解除以上状况需要的时间， 最好写入RetryAfter 首部字段再返回给客户端。

9.接口测试的原理是什么？

答：是模拟客户端向服务器发送报文请求,服务器接收请求报文后对相应的报文做处理并向客户端返回应答,客户端接收应答的一个过程。

10.后天接口测试了一遍前端也测试了一遍是不是重复测试？

答：

不是，接口测试和app测试的活动有部分重复的内容，主要集中在业务功能测试方面。除此之外，针对各自特性的测试都不一样，需要分别进行有针对性的测试，才能确保整个产品的质量。

11.接口测试的流程？

答：

①仔细阅读 “接口说明/设计文档”。将每个接口当成被测功能点来理解。接口也有功能、性能、安全等测试。

②设计接口测试方案，比如确定要使用的接口测试工具。

③设计接口测试用例(和功能测试设计用例的方法一样，运用等价类、边界值、正交试验法等黑盒测试方法)。但需要注意的是，接口测试不仅要关注请求参数的测试覆盖，还要对每个返回值进行覆盖。就是说，对请求覆盖测试后没有覆盖到的返回值，要构造相应的请求来验证这部分返回值是可以正常出现的。

④将设计好的接口测试用例转移到接口测试工具中。

⑤在工具中实施接口测试。

⑥收集测试结果（如有缺陷也要提交）,提交测试报告。

12. get/post的区别？

答：

一、功能不同

1、get是从服务器上获取du数据。zhi

2、post是向服dao务器传送数据。 

二、获取值不同

1、对于get方式，服务器端用Request.QueryString获取变量的值。

2、对于post方式，服务器端用Request.Form获取提交的数据。 

三、传送数据量不同

1、get传送的数据量较小，不能大于2KB。

2、post传送的数据量较大，一般被默认为不受限制。但理论上，IIS4中最大量为80KB，IIS5中为100KB。 

四、安全性不同

1、get安全性非常低。

2、post安全性较高。 

13如何编写接口测试用例？

答：分析接口文档，提取测试点

测试用例：同时对输入、业务逻辑、输出进行考虑时，肯定会存在用例的冗余，在最大限度覆盖业务功能和规则下，选取最优用例集合。同时，需要考虑异常数据和场景。

在没有特殊要求的情况下，至少需要考虑以下内容：
1）、业务功能覆盖是否完整
2）、业务规则覆盖是否完整
3）、参数验证是否达到要求（边界、业务规则）
4）、接口异常场景覆盖是否完整

如果接口需求还包含性能或者安全要求，还要对接口进行性能测试和安全测试，就需要考虑：性能指标是否满足要求、安全指标是否满足要求。

 

14.性能测试都包含了哪些？

答：

负载测试- 核实在保持配置不变的情况下，测试对象在不同操作条件（如不同用户数、事务数等）下性能行为的可接受性。

强度测试- 核实测试对象性能行为在异常或极端条件（如资源减少或用户数过多）之下的可接受性。

容量测试- 核实测试用户同时使用软件程序的最大数量。

15.什么时候执行性能测试？

答：功能测试执行完之后没有大的缺陷的时候就可以执行性能测试

16.你是如何做测试分析？

答：

 1、确定范围，任何产品的需求无非两种类型：功能需求和非功能需求

2、确定测试点，也就是确定测试具体内容

3、测试执行准备和场景设计时 ，也就是设计测试用例和测试场景时要充分考虑系统的技术特点。

 4、确定工作量

　　测试分析基本是由大到小，由外到里的分析方法

　　确定大范围，规则细分，技术确认 最后就要估算测试工作量

17.性能测试的步骤？

答：一、制定性能测试目标

二、性能测试场景获取

三、性能测试数据确定

四、性能测试用例设计

五、性能测试环境准备与搭建

18.你如何识别性能测试的瓶颈？

答：

  1) 查看系统日志，如果日志记录的全面，很容易通过日志发现问题。比如，系统宕机时，系统日志打印了某方法执行是抛出out of memory的错误，很快定位到导致内存溢出的问题在哪里。

        2) 利用性能监控工具，比如：linux系统环境下通过nmon来监控系统性能。

        3) 设计合理的性能测试场景，好的测试场景能更加快速的发现瓶颈。

        4) 了解系统参数配置，可以进行后期的性能调优

19.请解释一下常用的性能测试指标含义？

答：

响应时间，并发用户数，吞吐量，性能计数器，tps,hps,qps

20.响应时间，并发用户数，吞吐量，性能计数器，tps,hps,qps

答：性能指标

21.针对性能测试，负载测试，压力测试你在项目中的使用？

答：

1）性能测试
性能测试主要评价系统或组件的性能是否和具体的性能需求一致，例如：对访问速度的性能需求或对内存使用情况的需求。特定性能测试的关注点在于组件或系统在规定的时间内和特定的条件下响应用户或系统输入的能力。
不同的性能的度量方法取决于不同的被测对象。对于一个单独软件组件，其性能可以根据CPU主频来判定。而带客户端的系统，其性能则要根据系统处理特定用户请求的响应时间来判定。对于那些由多种组件（如客户端、服务器、数据库）构成的系统，则要进行各组件之间的性能测试。

2）负载测试
负载测试是一种通过增加负载来评估组件或系统的性能的测试方法。例如：通过增加并发用户数和（或）事务数量来测量组件或系统能够承受的负载。负载测试和性能测试的主要区别在于负载测试时，系统负载是逐渐增加的，而不是一步到位，负载测试需要观察系统在各种不同的负载情况下是否都能够正常工作。

3）压力测试
压力测试是评估系统处于或超过预期负载时系统的运行情况。压力测试的关注点在于系统在峰值负载或超出最大载荷情况下的处理能力。在压力级别逐渐增加时，系统性能应该按照预期缓慢下降，但是不应该崩溃。压力测试还可以发现系统崩溃的临界点，从而发现系统中的薄弱环节。
例如：系统最大支持的同时在线用户数是1000个，压力测试需要测试在1000个用户甚至2000个用户同时在线时系统的表现。虽然测试时负载已经超过了系统的设计能力，但是在这种情况下被测试系统也不应该发生崩溃。压力测试也可以针对系统资源进行测试，例如：在系统内存耗尽情况下，测试系统的运行情况，这种情况下被测试系统也不应该崩溃。

22.如何判断一个bug是前端bug还是后端bug？

答：

1.如果请求数据与接口文档不一致，则是前端问题

2.如果请求数据与接口文档一致，响应数据与接口文档也一致，则是前端问题

3.如果请求数据与接口文档一致，响应数据与接口文档不一致，则是后端问题

23.说一说你所知道的python  数据类型有哪些？

答：

数字、字符串、列表、元组、字典、集合这六种基本数据类型。浮点型、复数类型、布尔型(布尔型就是只有两个值的整型)、这几种数字类型。列表、元组、字符串都是序列。”

24.你在测试中发现一个bug，但是开发人员认为这不是一个bug，你怎么做？

答：

1. 先跟开发沟通，确认系统的实际结果是不是和需求有不一致的地方；有些地方可能需求没提及，但是用户体检不好，我们也可以认为是bug。
2. 如果开发以不影响用户使用为理由，拒绝修改，我们可以和产品经理，测试经理等人员进行讨论，确定是否要修改，如果大家都一致认为不用改，就不改。

25.给你个网站，你如何测试？给你个app程序你要怎么做？

答：

首先，确认需求

其次，分析测试需求，并制定测试计划，确定测试范围、使用测试技术以及对测试进行人员安排等等

再然后，根据测试需求编写测试用例，可使用Excel或者相关用例管理工具对用例进行管理

根据用例进行测试

若发现问题，则将问题提交到相应的缺陷管理工具，指派到问题负责人。

问题修复完毕，对修复的问题进行回归验证，并验证是否有引发其他问题

最后编写测试报告

 

26.什么是测试用例？什么是测试脚本？两者关系？

答：

测试用例：为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期望结果的一个特定的集合。

测试脚本是为了进行自动化测试而编写的脚本。

两者的关系： 测试脚本的编写必须对应相应的测试用例

27.简述：静态测试，动态测试，黑盒测试，白盒测试，a测试，B测试分别是什么？

答：

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

28.在你以往的工作中，一条软件缺陷记录都包含了哪些？

答：

一条Bug记录最基本应包含：

bug编号；
bug严重级别，优先级；
bug产生的模块；
首先要有bug摘要，阐述bug大体的内容；
bug对应的版本；
bug详细现象描述，包括一些截图、录像....等等；
bug出现时的测试环境，产生的条件即对应操作步骤；

高质量的Bug记录：

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

29.在你的项目中详细的描述了一个测试活动完整的过程？

答：

　1-项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员，测试人员以及客户的意见，完成项目计划。然后sqa进入项目，开始进行统计和跟踪

　　2-开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包括是否有遗漏或者双方理解不同的地方。测试人员完成测试计划文档，测试计划包括的内容上面有描述。

　　3-测试人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档，详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。

　　4-测试用例完成后，测试和开发需要进行评审。

　　5-测试人员搭建环境

　　6-开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测试，发现bug后提交给bugzilla。

　　7-开发提交第二个版本，包括bug fix以及增加了部分功能，测试人员进行测试。

　　8-重复上面的工作，一般是3-4个版本后bug数量减少，达到出货的要求。

　　9-如果有客户反馈的问题，需要测试人员协助重现以及回归测试。

30.如果项目周期很短，测试人力匮乏，你是怎么协调的？

答：

• 依据代码review的结果和影响范围，对测试内容进行适当的裁剪。
• 借助自动化工具的支持，提高测试案例的执行效率。
• 调整组内任务的优先级，进行人力协调，优先投入最紧要的项目。
• 必要的情况下加班

 31.描述下你团队的测试分工？

答：

按测试流程划分

　　我们的项目测试流程一般需要，制定测试计划，编写测试用例，执行测试用例，输出测试报告等工作，我们可以根据流程中的各个阶段来进行划分。

32.你做移动端的应用和web的程序应用都是如何做兼容性测试的？

答：

移动端应用：我们需要依据自身APP用户群体的特征以及使用习惯，去做相应的兼容。比如用户群体如果大多是老人的话，可以考虑大字体的适配。比如针对旅游人士，可以考虑过程中网络的状况。如果拥有大量海外用户，可以考虑多币种、多语言、多度量、时区问题。还包括硬件，软件，技术，网络，iOS APP兼容性（屏幕分辨率，屏幕尺寸（含异形），操作系统版本，开发语言，第三方库或SDK，安装、升级）Android APP兼容性（屏幕分辨率，屏幕尺寸（含异形），Android版本，系统版本，处理器架构（arm、x86），开发，语言（Java、koltin、混合），第三方库或SDK，安装，升级，H5兼容性，CSS样式兼容（一些属性的浏览器标示前缀没有添加，导致默认浏览器不认识这个属性，所以样式错乱。有些布局不灵活，样式边界处理不好，导致宽窄屏显示异常），JS兼容（主要是浏览器或者系统版本，新的js api不支持，但是没有做降级处理））

web端应用：操作系统、浏览器、分辨率和网速方面兼容性测试；

33.请简述移动应用的灰度是怎么做的？

答：

内部二维码下载

白名单用户方式

国内小市场先上，国外用 Google Play的 β版，默认开放5%

后台控制的方式，开放给一定比例的用户

34.请简述移动应用在升级安装时候应该考虑的场景？

答：

1.APP有新版本时，打开APP是否有更新提示。

2.当版本为非强制升级版时，用户可以取消更新，老版本能正常使用。用户在下次启动app时，仍能出现更新提示。

3.当版本为强制升级版时，当给出强制更新后用户没有做更新时，退出APP。下次启动app时，仍出现强制升级提示。

4.不删除APP直接更新，检查是否能正常更新，更新后能否正常工作。

5.删除老的APP，重新下载APP，能不能正常工作。

6.不删除APP直接更新，检查更新后的APP和新安装的APP提供的功能一样。

7.检查在线跨版本升级能否成功，版本过老是否提示用户重装。

8.更新成功后，用户数据有没有丢失，各个配置项是否还原。

35.如果让你来测试扫码支付，你会考虑哪些场景？

答：

• 卡的类型（一类户：借记卡、信用卡、各个开户行）
• 二类户：虚拟账户如微信里的零钱账户、支付宝的余额宝、电子账户
• 二维码的商户类型（微信、支付宝、汇宜、银联）
• 支付限额（单笔限额、累计限额、日累计、月累计、支付笔数）
• 退款（退款入口、退款进度、退款结果）
• 对账：资金流动（我方扣款数额正确，对方收款数额正确）数额及时效
• 支付结果展示、交易明细
• 支付接口安全性、接口的性能
• 异常情况（卡异常、余额不足）
• 连续扫码支付，每天的扫码支付次数限制及数额限制
• 二维码有效期
• 有无相机权限
• 前后置摄像头
• 像素低端的手机能否扫码成功
• 兼容性（不同手机厂商自带相机功能实现不一致）

36.请描述下微信朋友圈发小视屏的用例设计？

答：

• 功能：

入口图标的标识度

进入和退出操作简易度

取景框大小

拍景和自拍切换

视频的像素限制

视频的时长限制

发送的进度提示

• 性能：

发送的时间

操作是否卡顿

• 兼容：

不同机型分辨率

不同系统版本

不同网络情况

不同流量情况

37.一台客户端有三百个客户与三百个客户端有三百个客户对服务器施压，有什么区别？

答：

一个客户端，三百个用户

只有一个客户端，三百个用户肯定不能同时进行操作，假设每次一人操作客户端对服务器施压，服务器承受的压力小但持续时间长

三百个客户端，三百个用户

假设三百个客户端同时进行操作对服务器施压，就要求服务器带宽能够承受三百人同时在线操作，且服务器短时间内承受压力大但持续时间短

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

答：

尽量面对面的沟通，其次是能直接通过电话沟通，如果只能通过Email等非及时沟通工具的话，强调必须对特性的理解深刻以及能表达清楚。

运用一些测试管理工具如TestDirector进行管理也是较有效的方法，同时要注意在TestDirector中对BUG有准确的描述。

在团队中建立测试人员与开发人员良好沟通中注意以下几点：

一真诚、二是团队精神、三是在专业上有共同语言、四是要对事不对人，工作至上

当然也可以通过直接指出一些小问题，而不是进入BUG Tracking System来增加对方的好感。

39.简述你在以前的工作中做过哪些事情，比较熟悉什么？

答：

我之前做过的主要是功能测试，性能测试，web自动化测试、app测试、接口测试、也有用过charles进行一些关于弱网测试，修改参数值压力测试等等，也使用Jmeter做过一些性能方面的测试，比如说数据库的压测，性能测试，脚本录制等，也用过postman进行接口测试。我对于缺陷管理工具比如禅道，版本控制器git等能够熟悉使用。也对数据库、linux 、Fiddler这些应用也比较熟悉

41.在windows下保存一个文本文件时会弹出保存对话框，如果为文件名建立测试用例，等价类应该怎样划分？

答：

单字节，如A；双字节， AA、我我；特殊字符 /‘。‘；、=-等；保留字，如com；文件格式为8.3格式的；文件名格式为非8.3格式的；/,,*等九个特殊字符。

42.假设有一个文本框要求输入10个字符的邮政编码，对于该文本框应该怎样划分等价类？

答：

特殊字符，如10个*或￥；英文字母，如ABCDefghik；小于十个字符，如123；大于十个字符，如11111111111；数字和其他混合，如123AAAAAAA；空字符；保留字符

43.你以往的工作中是否曾开展过测试用例的评审工作？如果有，请描述用例评审的过程和评审内容？

答：

一:评审的过程
1、确定需要评审的原因
2、确定进行评审的时机
3、确定参与评审人员
4、明确评审的内容
5、确定评审结束标准
6、提前至少一天将需要评审的内容以邮件的形式发送给评审会议相关人员。并注明详审时间、地点及偿参与人员等。
7、 在邮件中提醒评审会议相关人员至少简读一遍评审内容，并记录相关的疑问，以便在评审会议上提出。
8、 会议主持者(一般为用例编写人员)应在会议前整理相关疑问，以便在会议上提出。
二：评审内容
1、 用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。
2、 优先极安排是否合理。
3、 是否覆盖测试需求上的所有功能点。
4、 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法。
5、 是否已经删除了冗余的用例。
6、 是否包含充分的负面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在“保护”20%的功能实现。
7、 是否从用户层面来设计用户使用场景和使用流程的测试用例。
8、 是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。

44.在你测试的过程中如果发现时间上不允许进行全部测试，你应该怎么做？

答：肯定是先对基本功能进行测试，把大的缺陷排除，没有时间了就剩下一些不仅要不影响产品正常运行的缺陷

45.列举web自动化中常见的元素定位方式是？

答：

通过class属性定位
通过id属性定位
通过name属性定位
通过link属性定位
通过partialLink定位
通过标签tagname定位
通过css定位
通过xapth定位

46.简述你知道的延时等待方式？

答：

sleep()： 强制等待，设置固定休眠时间。后脚本的执行过程中执行 sleep()后线程休眠，而另外两种线程不休眠。
implicitly_wait()：隐式等待，是设置的全局等待。设置等待时间，是对页面中的所有元素设置加载时间，如果超出了设置时间的则抛出异常。隐式等待可以理解成在规定的时间范围内，浏览器在不停的刷新页面，直到找到相关元素或者时间结束。
WebDriverWait()：显示等待，是针对于某个特定的元素设置的等待时间，在设置时间内，默认每隔一段时间检测一次当前页面某个元素是否存在，如果在规定的时间内找到了元素，则直接执行，即找到元素就执行相关操作，如果超过设置时间检测不到则抛出异常。默认检测频率为0.5s，默认抛出异常为：NoSuchElementException。

47.自动化测试用例覆盖率多少？

答：

35%到40%

48.完整运行一次自动化用例需要多久时间？

答：

主要跑的是业务流，所以跑一次需要半个小时左右

49.什么是分层自动化？

答:

传统的自动化测试更关注的产品UI层的自动化测试，而分层的自动化测试倡导产品的不同阶段（层次）都需要自动化测试。

金字塔结构， 最底层UnitTest，往上接口API/集成起来的service， 最上面UI自动化

50.你的测试数据是怎么准备的？

答：

一个是根据被测系统需求的分析，针对正常业务，异常情况，边界情况等来构建完整的数据，又称为“造”数据。

第二种方式就是利用现有系统，这适合已有类似系统，测试是针对升级或者增加功能的产品化的系统。

还有一种方式就是将现有非电子化的业务数据录入到系统中，在验证业务的同时也完成了测试数据的积累。

51.请简述Appium和selenium的原理？

答：

selenium：
IDE,俗称集成开发环境（编辑器），client（1.编写脚本，形成操作指令集，并运行时，会启动webdriver。2.webdriver启动后，绑定ip和端口，向发送来的请求的链接创建session（首次）。webdriver提供的http服务，client通过API接口访问webdriver，发送指令，webdriver接到指令后，按照自己封装的原生的浏览器API，对浏览器进行操作。webdriver将操作完成结果返回给客户端）
简化版：
1.IDE,俗称集成开发环境（编辑器），client（1.编写脚本，形成操作指令集，并运行时，会启动webdriver。通过HTTP协议传输给Webdriver
2.webdriver启动后，绑定ip和端口，向发送来的请求的链接创建session（首次）。webdriver提供的依http协议方式提供API接口服务，client通过API接口访问webdriver，发送指令，数据格式是JSON格式。webdriver接到指令后，按照自己封装的原生的浏览器API，对浏览器进行操作。webdriver将操作完成结果依照JSON格式返回给客户端
appium：
Appium是C/S架构的，更像是一个proxy，连接其被测移动平台和测试脚本。
appium是基于 webdriver 协议添加对移动设备自化api扩展而成的。

52.如果使用monkey发现了一个闪退，请问怎么使用monkey重现它？

答：

53.Charles拦截并修改请求和返回值的步骤以及在你项目中的应用场景？

答：

54.Charles如何抓取app端的https接口的？

答：

55.如何实现jenkins实现自动化打包发布和启动？

答：

1.下载jenkins安装包并安装
本例使用jenkins-2.86的windows版本

2.安装常用插件
如PUBLISH OVER SSH、Subversion Plug-in、Credentials Binding Plugin、Maven Integration plugin

3.配置svn账号，用于拉取源码

4.配置maven、JDK

5.配置SSH服务器

6.构建一个maven工程

7.构建完成后把war包发布到远程tomcat，并执行脚本重启tomcat

8.需要修改脚本为可执行脚本，否则jenkins权限不够执行shell脚本

56.如何进行jmeter上下游接口测试？

答：

57.你为什么离开上家公司？离职原因？

答：

想多挣点钱

58.请写出冒泡排序？

答：

a = [9,2,3,1,6,7,0]
# 确定循环次数为 列表长度-1次
times = len(a) -1

while times > 0:
	for i in range(times):
		if a[i] < a[i+1]:
			a[i],a[i+1]=a[i+1],a[i]
	times = times -1

print(a)

59.1-9999数列中数字3出现的次数，用最优解？

答：

def count_digit(number):
    return len(str(number))

def countThree(digit):
    if not isinstance(digit,int):
        raise TypeError('number is not int')
    # digit = len(str(number))
    if(digit <=0):
        return 0
    if(digit ==1):
        return 1
    return 10*countThree(digit-1) + 10 **(digit-1)

print(countThree(count_digit(9999)))

60从一个数组中找出前4个最大的数，用最优解？

答：

def qiuckSort(list):
        if len(list)<2:
            return list
        mid = list[0]
        left = [i for i in list[1:] if i <= mid]
        right = [i for i in list[1:] if i >= mid]
        finallyList = qiuckSort(left)+[mid] + qiuckSort(right)
        return finallyList
array = [3, 0, 1, 832,23,45, 5, 5, 6,46, 9, 56, 897]
print(qiuckSort(array)[-4:])

61.写一段程序，删除字符串a中包含的字符串吧，举例 输入a=“asdw”，b="sd" 返回 字符串 “aw” 并测试这个程序？

答：

62.写一个方法把字符串转为数字，比如 str=‘1234’，变成int1234.并测试这个程序？

答：

63.数据库的中的左连接右连接和全连接内连接的区别？

答：

left join （左连接）：返回包括左表中的所有记录和右表中连接字段相等的记录。
right join （右连接）：返回包括右表中的所有记录和左表中连接字段相等的记录。
inner join （等值连接或者叫内连接）：只返回两个表中连接字段相等的行。
full join （全外连接）：返回左右表中所有的记录和左右表中连接字段相等的记录。

64.测试结束的标准是什么？

答：即是测试的各项指标已达到发版标准，程序正常发版，这一版本测试结束。