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

相同点

不管是传统行业的web测试，还是新兴的手机app测试，都离不开测试的基础知识：

 

1）同样的设计测试用例方法：边界值分析法、等价类划分、错误推测法、场景法等（若想看这些基础课视频，直接点击原文看腾讯课堂的视频，都有，且免费！）；

 

2）同样的测试方法：黑盒测试，验证业务功能是否正确符合用户或者设计预期；

 

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

 

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

 

5）应用的稳定性：测试应用系统的稳定性等，不会闪退卡死等。

 

不同点

相对于web测试，APP测试，除了要考虑基本的功能测试、性能等，还要考虑手机本身固有的属性特征。所以APP测试过程中还需要注意如下几个方面特性：

 

1）手机作为通信工具，来电、去电、接收短信等操作都会对app应用程序产生影响，所以app测试第一个要考虑的属性特征是：中断测试。

 

中断测试有人为中断、新任务中断以及意外中断等几种情况，主要从以下几个方面进行验证：

a.来电中断：呼叫挂断、被呼叫挂断、通话挂断、通话被挂断

b.短信中断：接收短信、查看短信

c.其他中断：蓝牙、闹钟、插拔数据线、手机锁定、手机断电、手机问题（系统死机、重启）

 

2）手机用户对app产品的安装卸载操作：

 

a.从上一个版本/上两个版本直接升级到最新版本。

b.全新安装新版本

c.新版本覆盖旧版本安装

d.卸载旧版本，安装新版本

e.卸载新版本，安装新版本

 

3）web自动化测试使用的工具较常用的是QTP，而android手机自动化测试工具比较常用的是monkey、monkeyrunner、appium。

 

 

1. Ios和android测试的侧重点是？

1、Android多分辨率测试，20多种，IOS较少。

2、Android手机操作系统较多，IOS较少且不能降级，只能单向升级；新的IOS系统中的资源库不能完全兼容低版本中的IOS系统的应用，低版本IOS系统中的应用调用新的资源库，会直接导致闪退。

3、Android操作习惯，Back键是否被重写，应用数据从内存移动到SD卡能否正常运行。

4、安装卸载测试：Android的下载和安装平台较多，IOS主要是AppStore，iTunes，TestFlight。

5、Push测试：Android点击home键，程序后台运行，此时点击Push消息，唤醒后台应用；iOS点击home键关闭程序和屏幕锁屏的情况。

6、单条item的操作：Android中分为点击和长按，点击一般进入一个新的页面，长按进入编辑模式。IOS中分为点击和滑动，点击一般进入一个新的页面，滑动会出现对item的常用操作。

7、悬浮窗：Android中可以有各种悬浮窗，IOS并不支持。

 

 

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

1.安装和卸载

●应用是否可以在IOS不同系统版本或android不同系统版本上安装（有的系统版本过低，应用不能适配）

●软件安装后是否可以正常运行，安装后的文件夹及文件是否可以写到指定的目录里。

●安装过程中是否可以取消

●安装空间不足时是否有相应提示

●如果应用需要通过网络验证之类的安装，需要测试一下断网情况下是否有相应提示

●是否可以删除应用（可通过桌面删除，也可以通过软件卸载安装。曾发现在IOS手相上有个应用安装时未完全安装，终止安装后，未完成安装的应用图标一直显示在手机上，并且无法成功删除）

●测试卸载后文件是否全部删除所有的安装文件夹

●卸载过程中出现死机，断电，重启等意外的情况，待环境恢复后是否可以正确卸载

●卸载是否支持取消功能，单击取消后软件卸载情况是否正常

2.运行

●APP安装完成后，是否可以正常打开软件

●APP运行时，是否有加载图示

●APP的速度是可以让人接受，切换是否流畅

●用户登录状态太久，sessionId会过期，会出现“虽然是登录状态，系统会提示用户没有登录。

3.登录

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

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

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

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

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

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

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

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

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

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

4.离线

离线是应用程序在本地的客户端会缓存一部分数据以功程序下次调用

●对于一些程序，需要在登录进来后，这时没有网络的情况下可以浏览本地数据

●对于无网络时，刷新获取新数据时，不能获取数据且能给出友好提示

●切换到后台，再次切换到前台时，可以正常查看

●离线后又连上网，这时对数据有更新时，需要从服务器端获取新数据来更新客户端数据，且要更新本地缓存信息

●对于一些界面的数据不提供离线查看，需要给出相应提示且界面更新后无任何数据

●确认在无网情况下可以浏览本地数据

●确认退出APP再开启APP时能正常浏览

●确认切换到后台再切回APP应用时可以正常浏览

●锁屏后再解锁回到应用前台可以正常浏览

●服务端的数据有更新时有离线的提示

5.数据更新

●确认有数据更新后，哪些地方需要手动刷新，哪些地方需自动刷新。

●确认从后台切换回前台时，哪些页面需要进行数据更新

●根据需求和逻辑，确认哪些数据是从服务端请求实时响应，哪些是缓存到本地的数据。

6.消息推送开关设置

●默认开关应该是全打开状态

●设置开关可以自由打开关闭

●设置开关打开状态下，消息推送是否可正常接收（应用启用中和应用关闭时都应该可以收到）

●确认后台未打开APP客户端时，手机消息栏可以接收到消息提醒。且点击可查看。点击后消息栏中消失

●确认APP客户端启动时，可以收到消息提醒，且点击可查看。客户端运行时，消息不会进消息栏。

●设置开关关闭时，客户端接收不到消息推送。

7.软件更新

●当客户端有新版本时，有更新提示

●软件更新一定要测，确保android软件更新可以正确更新新版本，且安装运行正确。

●确保IOS软件更新会有限制，只有上了商店且有版本更新时才会测试，但是如果真有问题，再发现问题不点晚，可以让开发先在测试机上模拟一个地址进行测试。

●用户取消版本更新时，老版本可以正常使用，但是下次启动应用时，仍出现更新提示

●当有新版本时，不删除客户端的情况下，直接更新检查是否能正常更新，且更新后客户端的功能是否最新版本（正常来讲不用强制删除本地客户端可以正常更新）

8.异常测试

●没有内存空间时，APP能否正确响应

●APP运行中手机断电

●APP运行中断开网络

●反复操作某个功能，不断点击，刷新时，是否会闪退

●APP运行时拔打或接听电话

●APP运行时发送信息、收取邮件等

●多个APP运行时

●不断切换前台和后台，是否影响应用正常功能

●APP运行时，启动相机功能

９.网络环境

●测试２G、３Ｇ，４Ｇ，wifi网络下应用运应的速度

●内网测试时，选择到外网操作是否有异常处理

●网络不好时，提交数据是否一直处理提交中，是否会有延迟，数据交换失败是否会有提醒

●有网到无网再到有网环境时，数据是否可以自动恢复，正常加载

10.其它

●接口测试。让开发提供一份接口文档，一定要将接口测试通。在接口测试阶段，将缺少接口，接口不完善的缺陷挖掘出来。这个需要准备充分的后台数据。

●导航测试。在运行APP时，不管在哪个接点，导航是否直观，精准，页面切换是否正确。

●图片测试。图片，按钮是否自适应。

●内容测试。要进行超长字符，空字符校验且校验是否有错别字

●功能测试。功能是否实现。

●易用性测试。所开发的功能，是否让用户容易接受，是否符合大众的操作习惯。

●适配性测试。应用在不同设备，不同系统上是否适配。

●UI测试。应用的设计是否够美观。

 

 

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

1、检查Push消息是否按照指定的业务规则发送。

2、检查不接收推送消息时，用户不会在接收到Push消息。

3、如果用户设置了免打扰的时间段，检查在免打扰时间段内，用户接收不到Push。在非免打扰时间段内，用户能正常收到Push。

4、当Push消息是针对登录用户的时候，需要检查收到的Push与用户身份是否相符，没有错误的将其他人的消息推送过来。一般情况下，只对手机上最后一个登录用户进行消息推送。

5、测试Push时，在开关机、待机状态下执行推送，消息及其推送跳转的正确性。

6、push消息时，会有红点展示，推送消息阅读前后数字的变化是否正确；

7、应用在开发、未打开状态、应用启动且在后台运行的情况下是push显示和跳转是否正确。

8、多条推送的合集的显示和跳转是否正确。

 

 

 

1. App的闪退通常是什么原因造成的？

一般App闪退是由于以下几个原因造成的.

 

   1.缓存垃圾过多

 

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

 

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

 

  3.应用版本兼容问题

 

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

 

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

 

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

 

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

 

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

 

 

 

1. 常见的接口协议/类型是什么?

软件系统之间的接口是实现一个系统跟另外系统进行信息交互的桥梁，接口一般分为两种：程序内部的接口和系统对外的接口，软件接口的通常分为两类：webservice接口和http api接口

l webService接口是走soap协议通过http传输，请求报文和返回报文都是xml格式的，我们在测试的时候都用通过工具才能进行调用，测试。

l http api接口是走http协议，通过路径来区分调用的方法，请求报文都是key-value形式的，返回报文一般都是json串，有get和post等方法，这也是最常用的两种请求方式。

不同软件之间对接常用的接口协议：

1) OPC协议：

OPC（Object Linking and Embedding(OLE) for Process Control）是微软公司的对象连接和嵌入技术在过程控制方面的应用。该标准中定义了在基于PC的客户机之间进行自动化数据实时交换的方法。

2) ODBC

开放数据库连接（Open Database Connectivity，ODBC）是为解决异构数据库间的数据共享而产生的，现已成为WOSA(The Windows Open System Architecture(Windows开放系统体系结构))的主要部分和基于Windows环境的一种数据库访问接口标准ODBC 为异构数据库访问提供统一接口。

3) WebService协议

是一个平台独立的，低耦合的，自包含的、基于可编程的web的应用程序，Web Service技术，能使得运行在不同机器上的不同应用无须借助附加的、专门的第三方软件或硬件， 就可相互交换数据或集成。

4) Http Restful协议

是一种网络应用程序的设计风格和开发方式，适用于移动互联网厂商作为业务使能接口的场景，实现第三方OTT调用移动网络资源的功能，动作类型为新增、变更、删除所调用资源。

 

 

 

 

 

 

 

1. 常见的接口请求方式是什么？

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

 

 

 

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

2开头的状态码

 

   2xx表示成功处理了请求状态码

 

   200（成功）服务器已经成功处理了请求通常；

 

3开头的状态码

 

   3xx（重定向）表示要完成请求，需要进一步操作，通常这些状态码用来重定向

 

   304（未修改）自从上次请求后，请求的网页未修改过，服务器返回此响应时不会返回网页内容；

 

4开头的状态码

 

   4xx(请求错误)这些状态码表示请求可能出错，妨碍了服务器的处理

 

   400（错误请求）服务器不理解请求的语法；

 

   403（禁止）服务器拒绝请求

 

   404（未找到）服务器找不到请求的网页

 

5开头的状态码

 

  5xx(服务器错误)这些状态码表示服务器再尝试处理请求时发生内部错误，这些错误可能是服务器本身错误而不是请求错误

 

   501（尚未实施）服务器不具备完成请求的功能；

 

 例如：服务器无法识别请求方法时可能会返回此代码

 

  500（服务器内部错误）服务器遇到错误无法完成请求

 

   502（错误网卡）服务器做为网关或代理，从上游服务器收到无效响应

 

   503（服务不可用）服务器目前无法使用（由于超载或者停机维护）通常这只是暂时状态

 

  504（网关超时）服务器做为网关或代理，但是没有及时从上游服务器收到请求

 

   505（http版本不受支持）服务器不支持请求中所用的http协议版本

 

 

 

1. 接口测试的原理是什么?

对于接口测试，首先测试人员要懂代码，你只需要知道接口的作用是什么就可以了（有文档更好，但大部分都没有）；其次，自己去读开发的代码；然后，根据该接口功能及代码写测试用例；

用例设计：

1：写一个程序去调用该接口，看是否能够达到该接口所定义的功能

2：根据该接口参数，构造不同的用例，测试接口在参数合法及非法情况下能否达到预期效果

3：根据该接口中的逻辑，设计不同条件的用例，测试该接口实现代码的逻辑

4：进行容错及健壮性测试

5：静态检测代码，看是否有内存泄露、或永远走不到的分支、代码规范及逻辑是否合理。

6：对于一些接口，需要进行多线程测试

 

 

 

 

 

 

 

1. 后台接口测试了一遍前端也测试一遍是不是重复测试?

从后端角度出发：后端测试自己开发的接口，更多在于单测层面，好的开发会从接口业务调用场景出发，覆盖一些功能case，但是开发测试自己的代码，他往往觉得自己的代码已经很完美了，所以开发测试自己的代码往往是覆盖不全面的。

 

从前端角度出发：前端开发要和后端联调，所以前端的关注点是你接口返回给我的数据结构是不是严格按照技术方案上契约来设计的，你让我传给接口的参数是不是按照契约约定的，，所以前端开发不太关注接口逻辑对不对，只关心我只要入参给的对，返回的数据结构对就行了。

 

从测试角度出发：测试是保证质量最重要的一环，接口测试我们不仅仅只考虑功能层面用例，还要从非功能层面出发，比如接口性能，稳定性，安全性。我们还要结合业务场景，去思考一些反向的异常case，和其他服务相互调用过程的异常场景怎么兜底，依赖服务响应超时怎么兜底，系统异常怎么兜底等。

 

综上，因为前后端对同一个接口的关注点是不同的，所以不能说是重复测试。保证质量，更多依赖测试人员。三者相互协调能得到质量最优解。

 

1. 接口测试的流程/步骤(你的接口测试怎么做的)？

准备阶段（80%）

        拿到开发的接口文档，并理解每个接口的参数及含义

         了解被测试系统的业务流程

         编写 接口测试用例

执行阶段（10%）

       测试用例/测试场景执行

       测试数据/系统数据收集

分析阶段（10%）

    数据汇总/日志分析

测试报告

 

通过开发给的接口文档去了解接口有哪些内容

首先，接口文档应该包含以下内容：
1）接口说明
2）调用url
3）请求方法（get\post）
4）请求参数、参数类型、请求参数说明
5）返回参数说明

2.了解业务需求及业务流程

3.编辑接口用例

如何编写接口的用例？
其实接口的用例与功能测试的用例类似，下面简单的写下，比如说：
A功能测试，用例标题：
输入正确的用户名、密码规范，注册成功
用户名不规范，注册失败
…
B那如果接口测试的话，用例标题：我喜欢用思维导图的形式编写案例

4.执行接口用例

5.编写接口测试报告

 

 

 

 

 

 

1. get/post的区别？

1、传送方式：get通过地址栏传输，post通过报文传输。

2、传送长度：get参数有长度限制（受限于url长度），而post无限制

3、GET和POST还有一个重大区别，简单的说：

GET产生一个TCP数据包；POST产生两个TCP数据包

长的说：

对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；

而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。

也就是说，GET只需要汽车跑一趟就把货送到了，而POST得跑两趟，第一趟，先去和服务器打个招呼“嗨，我等下要送一批货来，你们打开门迎接我”，然后再回头把货送过去。

因为POST需要两步，时间上消耗的要多一点，看起来GET比POST更有效。因此Yahoo团队有推荐用GET替换POST来优化网站性能。但这是一个坑！跳入需谨慎。为什么？

1. GET与POST都有自己的语义，不能随便混用。

2. 据研究，在网络环境好的情况下，发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下，两次包的TCP在验证数据包完整性上，有非常大的优点。

3. 并不是所有浏览器都会在POST中发送两次包，Firefox就只发送一次。

 

 

1. 如何编写接口测试用例？

测试每个参数类型不合法的情况(类型不合法容易遗漏NULL型)
* 测试每个参数取值范围不合法的情况
* 测试参数为空的情况
* 测试参数前后台定义的一致性
* 测试每个参数的上下限(这里容易出致命的BUG，如果程序处理不当，可能导致崩溃)
* 如果两个请求有严格的先后顺序，需要测试调转顺序的情况

 

 

 

 

 

 

 

1. 性能测试都包含了哪些？（负载测试 压力测试 容量测试）

1、负载测试；通过自动化测试工具模拟程序或者软件系统在超强负荷条件下，观察系统各项性能指标的变化情况，一般与压力测试共同进行。

2、强度测试；指系统在资源条件很差工作环境下的运行情况，如人为限制网络带宽，内存等。

3、容量测试；一般指模拟用户不断增加时，确定系统可以处理同时在线的最大用户数量。

 

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

要开展性能测试是有一些前提的：

首先，基础的功能测试要完成，并且要保证系统是处于比较稳定的状态；

然后，当系统的使用人数比较多或者并发量比较大的时候可以考虑性能测试；因为如果系统使用的人比较少，其实是没必要进行性能测试的；

 

然后，了解本次性能测试的目标：QPS预估多少，CPU或者内存预计占比多少，磁盘占用等等；

 

接着，了解当前应用的服务器配置及和其他服务的关联关系，当前时间点的QPS等，确保性能测试时不会被别的服务影响，或者影响到别的服务；

然后，准备好性能测试工具Jmeter或者LoadRunner等；

以上都准备好后，就可以开始性能测试工作了。

 

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

1.根据需求规格提取独立的功能点，确定测试范围；

2.对独立功能进行分析，确定各独立功能的测试点；

3.对业务场景即功能组合进行分析，提供业务场景的测试点；

4.对非功能特性进行分析，了解需要测试的非功能特性；

5.针对系统级接口进行分析，了解被测试对象、测试规格。分析可测性，确定测试方法、工具。

 

 

 

 

 

1. 性能测试的步骤/流程？

一、准备工作

1、系统基础功能验证

性能测试在什么阶段适合实施？切入点很重要！一般而言，只有在系统基础功能测试验证完成、系统趋于稳定的情况下，才会进行性能测试，否则性能测试是无意义的。

2、测试团队组建

根据该项目的具体情况，组建一个几人的性能测试team，其中DBA是必不可少的，然后需要一至几名系统开发人员（对应前端、后台等），还有性能测试设计和分析人员、脚本开发

和执行人员；在正式开始工作之前，应该对脚本开发和执行人员进行一些培训，或者应该由具有相关经验的人员担任。

3、工具的选择

综合系统设计、工具成本、测试团队的技能来考虑，选择合适的测试工具，最起码应该满足一下几点：

①支持对web（这里以web系统为例）系统的性能测试，支持http和https协议；

②工具运行在Windows平台上；

③支持对webserver、前端、数据库的性能计数器进行监控；

4、预先的业务场景分析

为了对系统性能建立直观上的认识和分析，应对系统较重要和常用的业务场景模块进行分析，针对性的进行分析，以对接下来的测试计划设计进行准备。

 

二、测试计划

测试计划阶段最重要的是分析用户场景，确定系统性能目标。

1、性能测试领域分析

根据对项目背景，业务的了解，确定本次性能测试要解决的问题点；是测试系统能否满足实际运行时的需要，还是目前的系统在哪些方面制约系统性能的表现，或者，哪些系统因素导致

系统无法跟上业务发展？确定测试领域，然后具体问题具体分析。

2、用户场景剖析和业务建模

根据对系统业务、用户活跃时间、访问频率、场景交互等各方面的分析，整理一个业务场景表，当然其中最好对用户操作场景、步骤进行详细的描述，为测试脚本开发提供依据。

3、确定性能目标

前面已经确定了本次性能测试的应用领域，接下来就是针对具体的领域关注点，确定性能目标（指标）；其中需要和其他业务部门进行沟通协商，以及结合当前系统的响应时间等数据，确定

最终我们需要达到的响应时间和系统资源使用率等目标；比如：

①登录请求到登录成功的页面响应时间不能超过2秒；

②报表审核提交的页面响应时间不能超过5秒；

③文件的上传、下载页面响应时间不超过8秒；

④服务器的CPU平均使用率小于70%，内存使用率小于75%；

⑤各个业务系统的响应时间和服务器资源使用情况在不同测试环境下，各指标随负载变化的情况等；

4、制定测试计划的实施时间

预设本次性能测试各子模块的起止时间，产出，参与人员等等。

 

三、测试脚本设计与开发

性能测试中，测试脚本设计与开发占据了很大的时间比重。

1、测试环境设计

本次性能测试的目标是需要验证系统在实际运行环境中的性能外，还需要考虑到不同的硬件配置是否会是制约系统性能的重要因素！因此在测试环境中，需要部署多个不同的测试环境，

在不同的硬件配置上检查应用系统的性能，并对不同配置下系统的测试结果进行分析，得出最优结果（最适合当前系统的配置）。

这里所说的配置大概是如下几类：

①数据库服务器

②应用服务器

③负载模拟器

④软件运行环境，平台

测试环境测试数据，可以根据系统的运行预期来确定，比如需要测试的业务场景，数据多久执行一次备份转移，该业务场景涉及哪些表，每次操作数据怎样写入，写入几条，需要多少的

测试数据来使得测试环境的数据保持一致性等等。

可以在首次测试数据生成时，将其导出到本地保存，在每次测试开始前导入数据，保持一致性。

2、测试场景设计

通过和业务部门沟通以及以往用户操作习惯，确定用户操作习惯模式，以及不同的场景用户数量，操作次数，确定测试指标，以及性能监控等。

3、测试用例设计

确认测试场景后，在系统已有的操作描述上，进一步完善为可映射为脚本的测试用例描述，用例大概内容如下：

用例编号：查询表单_xxx_x1（命名以业务操作场景为主，简洁易懂即可）

用例条件：用户已登录、具有对应权限等。。。

操作步骤：

①进入对应页面。。。。。。

②查询相关数据。。。。。。

③勾选导出数据。。。。。。

④修改上传数据。。。。。。

PS：这里的操作步骤只是个例子，具体以系统业务场景描述；

4、脚本和辅助工具的开发及使用

按照用例描述，可利用工具进行录制，然后在录制的脚本中进行修改；比如参数化、关联、检查点等等，最后的结果使得测试脚本可用，能达到测试要求即可；

PS：个人而言，建议尽量自己写脚本来实现业务操作场景，这样对个人技能提升较大；一句话：能写就绝不录制！！！

 

四、测试执行与管理

在这个阶段，只需要按照之前已经设计好的业务场景、环境和测试用例脚本，部署环境，执行测试并记录结果即可。

1、建立测试环境

按照之前已经设计好的测试环境，部署对应的环境，由运维或开发人员进行部署，检查，并仔细调整，同时保持测试环境的干净和稳定，不受外来因素影响。

2、执行测试脚本

这一点比较简单，在已部署好的测试环境中，按照业务场景和编号，按顺序执行我们已经设计好的测试脚本。

3、测试结果记录

根据测试采用的工具不同，结果的记录也有不同的形式；现在大多的性能测试工具都提供比较完整的界面图形化的测试结果，当然，对于服务器的资源使用等情况，可以利用一些计数器或

第三方监控工具来对其进行记录，执行完测试后，对结果进行整理分析。

 

五、测试分析

1、测试环境的系统性能分析

根据我们之前记录得到的测试结果（图表、曲线等），经过计算，与预定的性能指标进行对比，确定是否达到了我们需要的结果；如未达到，查看具体的瓶颈点，然后根据瓶颈点的具体数据，

进行具体情况具体分析（影响性能的因素很多，这一点，可以根据经验和数据表现来判断分析）。

2、硬件设备对系统性能表现的影响分析

由于之前设计了几个不同的测试环境，故可以根据不同测试环境的硬件资源使用状况图进行分析，确定瓶颈是再数据库服务器、应用服务器抑或其他方面，然后针对性的进行优化等操作。

3、其他影响因素分析

影响系统性能的因素很多，可以从用户能感受到的场景分析，哪里比较慢，哪里速度尚可，这里可以根据2\5\8原则对其进行分析；

至于其他诸如网络带宽、操作动作、存储池、线程实现、服务器处理机制等一系列的影响因素，具体问题具体分析，这里就不一一表述了。

4、测试中发现的问题

在性能测试执行过程中，可能会发现某些功能上的不足或存在的缺陷，以及需要优化的地方，这也是执行多次测试的优点

 

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

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

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

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

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

 

 

1. 请解释下  常用的性能测试指标的含义?

1 注册用户数

        注册用户数指软件中已经注册的用户，这些用户是系统的潜在用户，随时都有可能上线。这个指标的意义在于让测试工程师了解系统数据中的数据总量和系统最大可能有多少用户同时在线。

2 在线用户数

          在线用户数是指某一时刻已经登录系统的用户数量。在线用户数只是统计了登录系统的用户数量，这些用户不一定都对系统进行操作，对服务器产生压力。

3 并发用户数

        不同于在线用户数，并发用户数是指某一时刻向服务器发送请求的在线用户数，他是衡量服务器并发容量和同步协调能力的重要指标，从这个含义上讲，我们可能会如下两种理解：

   同一时刻向服务器发送相同或者不同请求的用户数，也就是说，既可以包括对某一业务的相同请求，也可以包括对多个业务的不同请求

  同一时刻向服务器发送相同请求的用户数，仅限于某一业务的相同请求

4 请求的响应时间

          响应时间就是用户感受软件系统为其服务所消耗的时间。对于web系统，请求的响应时间指的是从客户端发起的一个请求时间，到客户端接收到从服务器返回的响应结束。

（1）在3秒之内，页面给予用户响应所有显示，可认为是很不错的

（2）在3-5秒之内，页面给予用户响应所有显示，可认为是好的

（3）在5-10秒之内，页面给予用户响应所有提示，可认为是勉强接受的

（4）超过10秒后就有点让人不耐烦，用户会感觉很坑不会继续等待下去

5 事务的响应时间

        事务是指用户在客户端做一种或多种业务所小阳台的操作集，事务的响应时间就是衡量用户执行这些操作集所花费的时间。在性能测试中，一般通过计算事务的开始时间和结束时间的差值来获取事务的响应时间。

6 每秒点击数

         每秒点击数是指每秒钟像web服务器提交的HTTP请求数，它是衡量服务器处理能力的一个常用指标。需要注意的是，这里的响应时间并非鼠标的一次单击操作，因为在一次单击操作中，客户端可能向服务器发出多个HTTP请求，切勿混淆。

7 吞吐率

         吞吐率通常指单位时间内从服务器返回的字节数，也可以单位时间内客户提交的请求数。吞吐率是大型web系统衡量自身负载能力的一个重要指标，一般来说，吞吐率越大，单位时间内处理的数据就越多，系统的负载能力也强。吞吐率yu很多因素有关，服务器的硬件配置，网络的宽带及拓扑结构，软件的技术架构等。

8 业务成功率

         指多用户对某一业务发起操作的成功率。例如，测试网络订票系统的并发处理性能，在早上8:00——8:30半小时的高峰里，要求能支持10万比订票业务，其中成功率不少于98%。也就是说系统允许200笔订票业务超时或者因其他原因导致未能订票成功。

9 资源利用率

          资源利用率就是指资源的使用情况，如CPU使用率、内存使用率、网络宽带的使用情况、磁盘I/O的输入输出量等系统硬件方面的监控指标。一个完整的系统是由软件和硬件组成，缺了任何一方都不可能成为一个正常运作的系统，所以资源利用率也是测试人员的一个监控点，并在当前软件的发展趋势下，硬件资源的成本也不可小视。

10 每秒事务数（TPS）

          TPS表示服务器每秒处理的事务数，他是衡量系统处理能力的一个非常重要的指标，在性能测试中，通过检测不同用户的TPS,可以估算出系统处理能力的拐点。

11 访问量（PV）

　　　页面访问量（Page View）,每打开一次页面，PV计数+1，刷新页面也算。

12 访问数（UV）

　　   访问数（Unique Visitor）, 指独立访客的数量，一台电脑终端为一个访客。

13 IP访问数（IV）

　　　IV指的是独立IP访问数，计算是以一个独立的IP在一个计算时段内访问网站计算为1次IP访问数。在同一个计算时段内不管这个IP访问多少次均计算为1次。

 

 

1. 响应时间   并发用户数  吞吐量  性能计数器  TPS  HPS   QPS?

并发数
并发数是指系统同时能处理的请求数量，这个也是反应了系统的负载能力。

响应时间
响应时间是一个系统最重要的指标之一，它的数值大小直接反应了系统的快慢。响应时间是指执行一个请求从开始到最后收到响应数据所花费的总体时间。

吞吐量
吞吐量是指单位时间内系统能处理的请求数量，体现系统处理请求的能力，这是目前最常用的性能测试指标。

QPS（每秒查询数）、TPS（每秒事务数）是吞吐量的常用量化指标，另外还有HPS（每秒HTTP请求数）。

跟吞吐量有关的几个重要是：并发数、响应时间。

QPS（TPS），并发数、响应时间它们三者之间的关系是：

QPS（TPS）= 并发数/平均响应时间

性能计数器
性能计数器是描述服务器或操作系统性能的一些数据指标，如使用内存数、进程时间，在性能测试中发挥着“监控和分析”的作用，尤其是在分析统统可扩展性、进行新能瓶颈定位时有着非常关键的作用。

Linux中可以使用 top 或者 uptime 命令看到当前系统的负载及资源利用率情况。

资源利用率：指系统各种资源的使用情况，如cpu占用率为68%，内存占用率为55%，一般使用“资源实际使用/总的资源可用量”形成资源利用率。

 

 

 

 

 

 

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

1）性能测试

性能测试主要评价系统或组件的性能是否和具体的性能需求一致，例如：对访问速度的性能需求或对内存使用情况的需求。特定性能测试的关注点在于组件或系统在规定的时间内和特定的条件下响应用户或系统输入的能力。

不同的性能的度量方法取决于不同的被测对象。对于一个单独软件组件，其性能可以根据CPU主频来判定。而带客户端的系统，其性能则要根据系统处理特定用户请求的响应时间来判定。对于那些由多种组件（如客户端、服务器、数据库）构成的系统，则要进行各组件之间的性能测试。

 

2）负载测试

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

 

3）压力测试

压力测试是评估系统处于或超过预期负载时系统的运行情况。压力测试的关注点在于系统在峰值负载或超出最大载荷情况下的处理能力。在压力级别逐渐增加时，系统性能应该按照预期缓慢下降，但是不应该崩溃。压力测试还可以发现系统崩溃的临界点，从而发现系统中的薄弱环节。

例如：系统最大支持的同时在线用户数是1000个，压力测试需要测试在1000个用户甚至2000个用户同时在线时系统的表现。虽然测试时负载已经超过了系统的设计能力，但是在这种情况下被测试系统也不应该发生崩溃。压力测试也可以针对系统资源进行测试，例如：在系统内存耗尽情况下，测试系统的运行情况，这种情况下被测试系统也不应该崩溃。

 

 

 

1. 如何判断一个bug是前端bug还是后台bug?

对于一个优秀的软件测试工程师来说，区分BUG属于前端还是后端是尤为重要的。
页面请求过程
弄清楚如何定位和分类BUG之前，需要了解一下页面请求的过程，以 http 请求为例，请求过程如下：
用户在前端页面操作，如点击某个功能
页面携带数据进行请求，访问具体功能接口
由后端服务执行该接口相应的业务逻辑，如涉及数据，再去请求并组装数据返回给前端
前端页面进行渲染和展示对应的页面和数据
前后端BUG各有什么样的特点？
前端BUG
– 界面相关
– 布局相关
– 兼容性相关
后端BUG
– 业务逻辑相关
– 性能相关
– 数据相关
– 安全性相关

 

 

 

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

1. 数字类型
Python数字类型主要包括int（整型）、long（长整型）和float（浮点型），但是在Python3中就不再有long类型了。
int（整型）
在32位机器上，整数的位数是32位，取值范围是-231~231-1，即-2147483648~214748364；在64位系统上，整数的位数为64位，取值范围为-263~263-1，即9223372036854775808~9223372036854775807。
long（长整型）
Python长整型没有指定位宽，但是由于机器内存有限，使用长的长整数数值也不可能无限大。
float（浮点型）
浮点型也就是带有小数点的数，其精度和机器有关。
complex（复数）
Python还支持复数，复数由实数部分和虚数部分构成，可以用 a + bj,或者 complex(a,b) 表示， 复数的实部 a 和虚部 b 都是浮点型。
2. 字符串
在Python中，加了引号的字符都被认为是字符串，其声明有三种方式，分别是：单引号、双引号和三引号；Python中的字符串有两种数据类型，分别是str类型和unicode类型，str类型采用的ASCII编码，无法表示中文，unicode类型采用unicode编码，能够表示任意字符，包括中文和其他语言。
3. 布尔型
和其他编程语言一样，Python布尔类型也是用于逻辑运算，有两个值：True（真）和False（假）。
4. 列表
列表是Python中使用最频繁的数据类型，集合中可以放任何数据类型，可对集合进行创建、查找、切片、增加、修改、删除、循环和排序操作。
5. 元组
元组和列表一样，也是一种序列，与列表不同的是，元组是不可修改的，元组用”()”标识，内部元素用逗号隔开。
6. 字典
字典是一种键值对的集合，是除列表以外Python之中最灵活的内置数据结构类型，列表是有序的对象集合，字典是无序的对象集合。
7. 集合
集合是一个无序的、不重复的数据组合，它的主要作用有两个，分别是去重和关系测试。

 

 

 

1. 你在测试中发现了一个bug，但是开发经理认为这不是一个bug，你应该怎样解?

将问题提交到缺陷管理库里面进行备案。

2、要获取判断的依据和标准：

根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；
如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；
根据用户的一般使用习惯，来确认是否是缺陷；

3、与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；

4、合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。

等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。

 

 

 

 

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

网站测试分以下几方面内容

性能测试

（1）连接速度测试：用户连接到电子商务网的速度与上网方式有关，他们或许是电话拨号，或是宽带上网，打开速度越快的网站，越受用户喜爱。

（2）负载测试：负载测试是在某一负载级别下，检测电子商务系统的实际性能。允许多少个用户同时在线，可以通过相应的软件在一台客户机上模拟多个用户来测试负载。

（3）压力测试：压力测试是测试系统的限制和故障恢复能力，也就是测试电子商务系统会不会崩溃。

 

安全性测试

对网站的安全性（服务器安全，脚本安全）可能有的漏洞测试，攻击性测试，错误性测试。对电子商务的客户服务器应用程序、数据、服务器、网络、防火墙等进行测试。用相对应的软件进行测试。

 

 

 

基本测试

包括色彩的搭配，连接的正确性，导航的方便和正确，CSS应用的统一性。

 

网站优化测试

（1）引擎优化测试：好的网站是看它是否经过搜索引擎优化了，网站的架构、网页的栏目与静态情况等。

（2）用户优化测试：用户来到网站能能够在3-5次，找到其需要的内容。方便用户的网站倍受用户的亲昵。

功能实现：网站现有版本，需求是否完全实现。满足需求的网站才是有用的网站。

 

App测试

1．功能测试

2．客户端性能测试

3．适配兼容测试

4．安全测试

5．服务器性能测试

 

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

测试用例：

一组由前提条件、输入、执行条件、预期结果等组成，以完成对某个特定需求或者目标测试的数据，体现测试方案、方法、技术和策略的文档

测试脚本：

一般指的是一个特定测试的一系列指令，这些指令可以被自动化测试工具执行。 为了提高测试脚本的可维护性和可复用性，必须在执行测试脚本之前对它们进行构建。

测试脚本是一段代码不假。但是这段代码可能是为了执行某一条，或很多条测试用例而写的。
也有可能 ，本身就是一条用例。
用例本身并不局限在基于功能。
脚本和用例没有并列的可比性。
脚本可能是用例，也可能是执行用例用的功能。用例也可能是脚本。

 

 

1. 简述：静态测试、动态测试、黑盒测试、白盒测试、α测试 、β测试分别是什么？

静态测试

静态测试是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。

动态测试

单元测试

集成测试

系统测试

验收测试

回归测试

 

 

黑盒测试

黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。

白盒测试

白盒测试，也称为结构化测试、基于代码的测试，是一种测试用例设计方法，它从程序的控制结构导出测试用例。用白盒测试产生的测试用例能够：
1）保证一个模块中的所有独立路径至少被使用一次；
2）对所有逻辑值均需测试true和false；
3）在上下边界及可操作范围内运行所有循环；
4）检查内部数据结构以确保其有效性。

 

α测试

一般只供内部测试使用

β测试

已经消除了软件中大部分的不完善之处，但仍有可能还存在缺陷和漏洞，一般只提供给特定的用户群来测试使用

 

 

1. 在您以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？

一条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.确认步骤完整，准确，简短

保证快速准确的重复缺陷，“完整”即没有缺漏，“准确”即步骤正确，“简短”即没有多余的步骤。

根据缺陷，可选择是否进行图象捕捉

为了直观的观察缺陷或缺陷现象，通常需要附加缺陷或缺陷出现的界面，以图片的形式作为附件附着在记录的“附件”部分。为了节省空间，又能真实反映缺陷或缺陷本质，可以捕捉缺陷或缺陷产生时的全屏幕，活动窗口和局部区域。为了迅速定位、修正缺陷或缺陷位置，通常要求附加中文对照图。

△附加必要的特殊文档和个人建议和注解

如果打开某个特殊的文档而产生的缺陷或缺陷，则必须附加该文档，从而可以迅速再现缺陷或缺陷。有时，为了使缺陷或缺陷修正者进一步明确缺陷或缺陷的表现，可以附加个人的修改建议或注解。

 

12.检查拼写和语法缺陷

在提交每条缺陷或缺陷之前，检查拼写和语法，确保内容正确，正确的描述缺陷。

 

13.尽量使用短语和短句，避免复杂句型句式

软件缺陷管理数据库的目的是便于定位缺陷，因此，要求客观的描述操作步骤，不需要修饰性的词汇和复杂的句型，增强可读性。

以上概括了报告测试缺陷的规范要求，随着软件的测试要求不同，测试者经过长期测试，积累了相应的测试经验，将会逐渐养成良好的专业习惯，不断补充新的规范书写要求。此外，经常阅读、学习其他测试工程师的测试缺陷报告，结合自己以前的测试缺陷报告进行对比和思考，可以不断提高技巧。

14.缺陷描述内容

缺陷描述的内容可以包含缺陷操作步骤，实际结果和期望结果。操作步骤可以方便开发人员再现缺陷进行修正，有些开发的再现缺陷能力很差，虽然他明白你所指的缺陷，但就是无法再现特别是对系统不熟悉的新加入开发人员，介绍步骤可以方便他们再现。实际结果可以让开发明白错误是什么，期望结果可以让开发了解正确的结果应该是如何。

 

 

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

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

1. 开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包括是否有遗漏或者双方理解不同的地方。测试人员完成测试计划文档，测试计划包括的内容上面有描述。
2. 测试人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档，详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。
3. 测试用例完成后，测试和开发需要进行评审。
4. 测试人员搭建环境
5. 开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测试，发现bug后提交给bugzilla。
6. 开发提交第二个版本，包括bug fix以及增加了部分功能，测试人员进行测试。
7. 重复上面的工作，一般是3-4个版本后bug数量减少，达到出货的要求。
8. 如果有客户反馈的问题，需要测试人员协助重现以及回归测试。

 

 

 

 

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

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

 

 

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

一个测试经理，3个测试组长，每个组有5个测试人员：包括自动化测试、，功能测试、性能测试等的测试工程师。

 

 

 

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

移动端

1、适配系统版本：

 

去二手平台找到低版本的设备

 

2、 适配不同机型：

选择世面上的主流机型

3、适配尺寸

4、适配分辨率：

分辨率常见的720p(720×1280),1080p(1080×1920),2k(2560×1440)

5、适配网络：

三大运营商 、信号：2G、3G、4G、5G、WiFi

6、适配异形屏

现在手机花里胡哨的，全面屏、曲面屏、3D屏、刘海屏、挖孔屏、越来越多，所以我们也需要测试一下系统状态栏

7、涉及到蓝牙、耳机，看对应功能需要了

————————————————————————

web端

1.操作系统兼容性

市场上有很多不同的操作系统，Windows 、Mac、Linux等操作系统。同一个应用在不同的操作系统下，可能会有兼容性问题，可能有些系统正常，有些系统不正常。

2.浏览器兼容性

国内主流的浏览器内核主要有3种：IE内核、Firefox内核和Chrome内核；

（1）IE内核常见的浏览器有：360安全浏览器（兼容模式）、360极速浏览器（兼容模式）、搜狗浏览

器（兼容模式）、QQ浏览器；

（2）Firefox内核常见的浏览器即火狐浏览器（Firefox）；

（3）Chrome内核常见的浏览器有

3.分辨率兼容性

同一个页面在不同分辨率下，显示的样式可能会不一样。可以通过对浏览器的缩放的比例进行不同分辨率的测试。

台式机分辨率：：1024×768、1280×1024、1440×900

笔记本电脑分辨率：1024X768 、1280X800、1440X900、 1600X9000

4.网速测试

项目在不同的网络环境中是否正常的运行，通过Charles、Fiddler等工具进行弱网测试。

 

 

 

1. 请讲诉移动应用的灰度是怎么做的？

Android 平台的灰度发布，和 PC 客户端的灰度发布方法是一致的，简而言之是通过通知（自建的和系统的）进行按比例发布 beta 版，等到版本稳定再针对渠道做大规模的稳定版发布（涉及到付费投放、市场资源投入，谁也不想市场人员指着你的鼻子叫唤）。
建议请教一下企鹅公司做过 PC 客户端软件的工程师（我第一次了解客户端如何做灰度就是请 QQ 音乐一位工程师转 PM 的老师讲了一课，我尝试召唤他来解答这个问题）。To know the road ahead, ask those coming back.

iOS 平台的灰度发布，不建议在越狱渠道上做。做大渠道（其实就是 91）肯定会影响收入指标（主要针对电商 app），做小渠道完全没结果，而且还有被大渠道抓包的风险。那么解决方案就剩下有分发权限的 299 刀高级开发者帐号了，只要培养足够的用户量，这个样本容量还是足够大的。
当然，要自搞个新开发者帐号，要考虑如何回收这个帐号发出去的版本都是麻烦事，如果只是为了测试某个功能，也可以就拿 91 渠道干一票。（表面上 PM 好像实现了目的，但工程师必然叫苦连天，个人觉得是个亏本买卖，不值当。）

最后，一切的前提都是：
1. 做好版本管理（一个有条理、敬畏秩序的、能写代码的发布经理）；
2. 打好数据桩（重点注意按版本观测所有数据，数据要贯通不要片段）；
3. 灰度版本有回收能力（不然老板时不时因为微博用户报告的某个灰度版本的 bug 来让你擦屁股就不用干正事了）。
这部分我 100% 同意一楼张瑞老师的意见。

好的方法论（灰度发布）貌似能解决的一切问题，但是把这个推行起来的那个人，说起来都是泪。

 

 

 

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

1.APP有新版本时，打开APP是否有更新提示。
2.当版本为非强制升级版时，用户可以取消更新，老版本能正常使用。用户在下次启动app时，仍能出现更新提示。
3.当版本为强制升级版时，当给出强制更新后用户没有做更新时，退出APP。下次启动app时，仍出现强制升级提示。
4.不删除APP直接更新，检查是否能正常更新，更新后能否正常工作。
5.删除老的APP，重新下载APP，能不能正常工作。
6.不删除APP直接更新，检查更新后的APP和新安装的APP提供的功能一样。
7.检查在线跨版本升级能否成功，版本过老是否提示用户重装。
8.更新成功后，用户数据有没有丢失，各个配置项是否还原

 

 

 

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

功能测试用例

卡的类型（

一类户：借记卡、信用卡、各个开户行

二类户：虚拟账户如微信里的零钱账户、支付宝的余额宝、电子账户

二维码的商户类型（微信、支付宝、汇宜、银联）

支付限额（单笔限额、累计限额、日累计、月累计、支付笔数）

退款（退款入口、退款进度、退款结果）

对账

资金流动（我方扣款数额正确，对方收款数额正确）数额及时效

支付结果展示、交易明细

连续扫码支付，每天的扫码支付次数限制及数额限制

二维码有效期

有无相机权限

前后置摄像头

像素低端的手机能否扫码成功

兼容性

兼容性（不同手机厂商自带相机功能实现不一致）

 

安全性：

1.是否有超时超次限制

2.测试用户操作时相关信息是否写入了日志文件、是否可追踪等

3.如果使用了安全套字，需要测试加密是否正确，加密前后的信息完整性，正确性

 

性能

1.用户操作的响应时间

2.系统的吞吐量（TPS）

3.系统的硬件资源情况（CPU、硬盘、磁盘）

4.网络资源占用情况等。

 

异常场景

异常情况（卡异常、余额不足）

 

 

 

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

站在测试人员的技术测试角度：

1.功能测试

功能测试是软件测试中最基本的测试，功能实现不满足要求，软件就不能发布测试。要进行功能测试，首先就需要了解朋友圈的各个功能，那么如何了解朋友圈的功能呢？——需求文档。因为所有的开发设计、测试设计等，都是以需求文档来进行的。需求文档中规定了必须有哪些功能，那么我们在测试的时候就可以对比知道哪些功能实现了，还有哪些功能未实现（需要说明的是：开发计划明确说明当前版本暂不实现的功能，不能算作bug）。

 

相信玩过微信朋友圈的人都能知道微信朋友圈大概有以下基础功能：

1）发朋友圈、删除朋友圈，看朋友圈；

2）朋友圈的类型（图、文、混合）；

3）评论朋友圈；

4）朋友圈的对外接口（例如，王者荣耀，把战绩分享至朋友圈等）；

5）屏蔽与被屏蔽，不能查看对应好友的朋友圈；

 

————————————————

我们做基础功能测试，就需要对朋友圈具有的所有功能进行测试。

 

发朋友圈：我们可以通过短按或者常按朋友圈中的照相机图标，分别发起图片版或文字版的朋友圈操作，在此过程中，我们需要关注进行发起操作的响应时间是否符合需求。然后就需要对发朋友圈进行全面的测试了，其中包括，正常发朋友圈，取消发朋友圈，多次发朋友圈等。如果需求中对朋友圈的内容有限定，例如不允许出现敏感字眼等。

 

2.可靠性测试

先来说一下软件可靠性的概念：软件可靠性（software reliability）是软件产品在规定的条件下和规定的时间区间完成规定功能的能力。

规定的条件是直接与软件运行相关的使用该软件的计算机系统的状态和软件的输入条件，或统称为软件运行时的外部输入条件；

规定的时间是指软件的实际运行时间区间；

规定的功能是指提供给定的服务，软件产品所必须具备的功能。

软件可靠性不但与软件存在的缺陷（或）差错有关，而且与系统输入和系统使用有关。软件可靠性的概率度量程为软件可靠度。

 

3.性能测试

性能测试主要对服务器的性能进行测试的。在App上，性能测试分为客户端性能、服务器性能。

对客户端性能我们主要关注的指标有：CPU占用率、内存占用率、流量耗用量等。举个例子，如果发起朋友圈操作之前，手机的CPU使用率为30%，发起操作之后，忽然涨到了80%，不关闭朋友圈的相关操作，CPU使用率降不下来，那么对于整个朋友圈的性能问题就得需要我们去好好找原因了。

 

对提供朋友圈服务的服务器进行性能测试时，我们需要进行压力测试、负载测试、稳定性测试。常用的工具就是Loadrunner了，主要关注的指标有：CPU、内存、响应时间等。

 

4.其他测试

例如：

1）在弱信号的情况，进行发朋友圈、看朋友圈等操作，测试其是否会产生其它未知故障。（例如对WiFi信号进行限速）

2）在不同的客户端的兼容性测试，使用不同平台的客户端进行朋友圈的功能测试。（例如使用不同厂商的手机、平板）

3）安全性测试（例如在朋友圈儿中输入一些脚本程序代码什么的，测试是否会将微信客户端搞崩溃什么的。

站在用户的角度

站来用户角度来说，易用性是其评价软件好坏最主要的一点，功能操作是否简单明了，给出的提示是否清楚明白无二意，还有就是界面布局否美观合理。

 

除此之外，我们还要模拟不同的用户场景下的使用。把自己想象为不同的用户（小白用户，资深用户），因为不同的用户有不同的使用习惯，这也类似于发散测试，因人而异

 

 

 

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

对服务器来说，一个客户端只需要一组数据连接与服务器相连，三百个客户端，当然就要三百组数据连接与服务器相连，这就是区别。

如果你只是想要让服务器支持300个在线客户。
如果这三百个客户分布在不同的电脑上，你也只有三百个客户端才能解决问题。
如果这三百个客户是由同一台电脑控制的，就好比每个客户分到键盘的一个按键，轮到谁就谁按，那你就不需要分什么服务端和客户端了，全部装一个机器就行了。

对服务器的压力，主要受这些方面的影响
1、客户端和服务端的连接数，连接数越多，资源占用越大，即使不操作连接也是保持的；
2、数据传输量，如果单个客户端只传送各自有限的信息，数据量是不大的，还可以错开时间传输；
3、计算量，如果服务器需要处理大量运算，CPU肯定占用量会很高

所以，
1、如果一个客户端可以让几个客户用，那么一个客户端多支持几个人，可以有效较少连接数
2、只传输真正需要的数据，可以有效减少数据传输量
3、某些运算，可以让客户端来计算，可以大大减轻服务器的负担
3、使用缓存，客户端缓存和服务端都可以减少数据读取次数，客户端缓存还可以大大减少数据传输的量

 

 

 

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

一，有共同的目标，共同的利益。二，默契。三，大度，谦让，素质。

维持测试人员与团队其他成员的良好关系从两个方面入手：

一、提高测试人员的技术水平 测试人员的技术水平主要体现在业务领域知识、业务理解、发现缺陷深度、缺陷定位、文档编写能力等。如果掌握丰富的业务知识并有很强的理解力，对于理解需求和发现需求问题有很大帮助。比如在需求规格说明书的评审会议上，提出建设性意见，可以使其他成员刮目相看并得到重视。 发现有深度的缺陷并且描述清晰，还能定位出缺陷的具体位置及原因，帮助开发人员节省了很多时间，减少不必要的沟通。最后得到开发人员的信任并建立良好的合作关系。 测试文档也能体现工程师的技术水平。除了内部，还要让项目组的其他成员看明白。

 二、缺陷的奖罚制度 很多时候开发和测试人员之间发生争执是因为缺陷引起。开发人员认为问题太小，不属于缺陷；测试人员考虑易用性认为必须修改。其实如果建立合理的缺陷奖罚制度，这些都可以避免。比如内部测试阶段，发现缺陷不作为开发人员的考核依据；而客户验收阶段的缺陷则严重影响测试和开发的考核成绩。这样开发人员对待缺陷的态度会比较积极，有时还会帮助测试人员发现缺陷。根据开发人员修改解决缺陷的数量和难度，在考核中适当加分，会使开发人员乐于修改缺陷，甚至是不属于自己开发范围内的缺陷。 除此之外，当项目到达一定阶段，可以组织所有成员一起去发现和记录缺陷，并奖励发现缺陷数量最多的人。调动大家的积极性，养成发现并记录缺陷的习惯。

 

 

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

我主要的工作是系统测试和自动化测试，也曾少量涉及性能测试。在系统测试中，主要是对BOSS系统的业务逻辑功能，以及软交换系统的Class+5特性进行测试。性能测试中，主要是进行的压力测试，在各个不同数量请求的情况下，获取系统响应时间以及系统资源消耗情况。自动化测试主要是通过自己写脚本以及一些第三方工具的结合来测试软交换的特性测试

 

 

 

1. 请说出这些测试最好由那些人员完成，测试的是什么？

 

 

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

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

 

 

 

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

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

 

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

一、评审前需要做哪些准备工作

①　需求评审结束后，就可以着手把需求拆分为功能点。

②　把功能点再分解为具体的测试用例。

③　用例写完后，自己先做好自检，自检中，针对有疑问的点罗列出来，可事先跟产品开发讨论，确定结果后完善用例，仍有疑问的可先做标记，评审会上抛出一起讨论。

④　和评审人员（开发和产品）确定好具体的评审时间并提前把测试用例发给参会人员查看。

 

二、用例评审参加人员

主要是产品、开发（客户端和后端）、测试、项目负责人、运营。

三、用例评审时间

        对于敏捷开发项目，建议控制在半小时以内。

四、用例评审的形式

1、对照测试用例，从上而下，从左到右，逐条念。

2、先对功能复杂，优先级高，疑问多的用例进行评审，再评审功能简单，优先级低的功能点。

五、正式评审

1、评审要按用例的优先级，功能的复杂程度进行；

2、评审过程中尽量做到，思路清晰，用最简洁的语言阐述每一个功能点；

3、超过5分钟无法确定结果的问题留作会后讨论跟进。

六、评审结束后需要做些什么事

①　评审结束后，第一时间整理测试用例，把修正的内容重新整理补全。

②　会上未确定的内容，会后继续跟进，直到确定结果。

这个总结是给自己整个用例评审工作总结，同时需同步给项目组其他成员，做好信息共享

 

 

 

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

通常，不管是开发产品还是做具体的项目，都会发生耽误进度的情况。

一旦整体进度不能向后延迟，项目相关人员习惯上的做法就是缩减测试时间。尤其在功能还没有开发完成的情况下，这种现象更为突出。担负着质量重任的测试经理，如何来解决这个问题呢？

比较好的做法是按照下面的步骤逐步来完成和改进工作：

（1）按照测试任务的轻重缓急，尽最大努力完成测试任务。在时间不足的情况下，我们应该对测试任务按照优先级来划分，重要紧急的任务先完成。这个时候的测试任务是一种辅助性工作，其目的就是尽最大努力来提高质量。

△因此，面对这种情况，测试负责人要做的就是带领测试小组充分利用所有资源来保证质量。

 

（2）在实际工作中和开发人员共同配合，逐步改进工作。只有整个团队的软件开发能力提高了，才能从根源上解决问题。

△因此，测试负责人要带领团队和开发小组共同寻找适合自己的开发模式，从而使项目规划的更加合理，进而按照预定计划来开展测试工作。总之，在任何情况下，测试负责人都不应该抱怨。只有积极的面对问题，才能更好的解决问题。

 

 

 

 

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

css 选择器定位：根据标签的层级关系进行定位

class单个属性定位：self.driver.find_element_by_css_selector(’.table-dragColumns’).click()#用单个属性来定位前面加个（.）

直接包含空格的css定位神器：

self.driver.find_element_by_css_selector(‘class=”dtb-style-1 table-dragColumns’).click()#包含整个类

 

 

 

 

1. 简述你知道的延时等待的方式?

延时等待分为三种，分别是：硬性等待、隐式等待、显示等待

1、硬性等待：Thread.sleep(long millis)

硬性等待，线程休眠，强制等待

Thread.sleep(long millis)

（不推荐使用，容易造成时间上的浪费，受到网络原因的影响因素太大。）

使用场景：页面切换时

2、隐式等待：TimeOuts–implicitlyWait

在设置的超时时间范围内不断的查找元素，直到找到元素或者超时

设置等待时间为5秒，第3秒找到元素，不再继续等待

设置方式

driver.manage().timeouts().implicitlyWait(long time, TimeUnit.SECONDS);

优点：相对灵活

缺点：设置是针对全局的，在WebDriver实例的整个生命周期有效，但是并不是所有的元素都需要等待

3、显示等待（智能等待）：WebDriverWait

显示等待通常是我们自定义一段代码，用来等待某个条件发生以后，再继续执行后续的代码（如找到元素、元素可点击、元素已显示）

可以自己指定某个元素需要等待，在有必要进行等待的时候进行等待

默认是0.5秒轮循一次，在dom中查找一次元素

我们可以自己设置期望条件

注意：在自己设置期望条件时，return时不能直接点击该元素，因为返回是webElement时只能说明该元素在dom中间存在，但是能不能点击是不确定的

因为元素能被点击具备三个条件：1、在dom中间存在；2、已经显示在页面上（isDisplayed）；3、有效性（可以进行click操作）

 

 

 

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

 　　覆盖率在70%左右。

 

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

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

 

 

 

1. 什么是分层自动化？

分层自动化测试（经典图如下）分三层，最底层是单元层，中间是服务层，顶部是UI层，而这三层越底层做自动化测试，实现成本越低，越容易看见成效。

 

 

 

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

手动的方式创建数据，通过软件的某个具体的业务流程创建数据

这种方式适合于需要的测试数据少，也是平时测试中使用最多的方式。

修改数据库

这样的方式比较简捷，花费的时间成本最低。

修改浏览器

有时候一个网页需要显示100个商品信息，但是如果不断的创建100个商品信息则不太现实，测试时也只是想看显示100个商品时页面显示是否正常，这个时候可以通过修改网页html代码进行实现。

程序自动生成，通过编写程序实现商品数据的批量生成

这样才有充足的时间去写这个自动生成商品数据的脚本。

本地数据库的导入功能

如果已有一批数据，只是这个数据是存储在本地，而不是数据库中，则可以通过导入数据的方式，实现数据的创建。

线上数据导入到测试环境

要求事先先进行调研，先确定线上的数据是否是自己想要的数据，导入到线下的数据是否还需要再次加工？加工所要花费的时间成本的大小进行衡量。

 

 

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

Appium的工作原理

2.1 Android

在Android端，appium基于WebDriver协议，利用Bootstrap.jar，最后通过调⽤用UiAutomator的命令，实现App的自动化测试。

UiAutomator测试框架是Android SDK自带的App UI自动化测试Java库。

另外由于UiAutomator对H5的支持有限，appium引入了chromedriver以及safaridriver等来实现基于H5的自动化。

appium 在android端工作流

1) client端也就是我们 test script是我们的webdriver测试脚本。

2) 中间是起的Appium的服务，Appium在服务端起了一个Server（4723端口），跟selenium Webdriver测试框架类似， Appium⽀持标准的WebDriver JSONWireProtocol。在这里提供它提供了一套REST的接口,Appium Server接收web driver client标准rest请求，解析请求内容，调⽤用对应的框架响应操作。

3) appium server会把请求转发给中间件Bootstrap.jar ，它是用java写的，安装在手机上.Bootstrap监听4724端口并接收appium 的命令，最终通过调⽤用UiAutomator的命令来实现。

4) 最后Bootstrap将执行的结果返回给appium server。

5) appium server再将结果返回给 appium client。

 

2.2 ios

在IOS端，appium同样使⽤WebDriver的一套协议。

与Android端测试框架不同的是，appium ios封装了apple的 Instruments框架，主要用了Instrument里的UI Automation（Apple的⾃自动化测试框架），然后在设备中注⼊入bootstrap.js进⾏行监听。

appium 在ios端工作流

 

①　client端 依然是 test script是我们的webdriver测试脚本。

 

②　中间是起的Appium的服务，Appium在服务端起了一个Server（4723端口），跟selenium Webdriver测试框架类似， Appium⽀持标准的WebDriver JSONWireProtocol。在这里提供它提供了一套REST的接口,Appium Server接收web driver client标准rest请求，解析请求内容，调⽤用对应的框架响应操作。

③　appium server调用instruments.js 启动⼀一个socket server，同时分出一个⼦子进程运⾏instruments.app，将bootstrap.js（一个UIAutomation脚本）注⼊入到device⽤于和外界进行交互

④　最后Bootstrap.js将执行的结果返回给appium server

⑤　appium server再将结果返回给 appium client。

所以我们可以看到android与ios区别在于appium 将请求转发到bootstrap.js或者bootstrap.jar.然后由bootstrap 驱动UIAutomation和UiAutomator去devices上完成具体的动作。

SELENIUM工作原理

我们使用Selenium实现自动化测试，主要需要3个东西

1.测试脚本，可以是python，java编写的脚本程序（也可以叫做client端）

2.浏览器驱动, 这个驱动是根据不同的浏览器开发的，不同的浏览器使用不同的webdriver驱动程序且需要对应相应的浏览器版本，比如：geckodriver.exe(chrome)

3.浏览器，目前selenium支持市面上大多数浏览器，如火狐，谷歌，IE等。

 

 

 

 

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

:Switch: #Intent;action=android.intent.action.MAIN;category=android.intent.category.LAUNCHER;launchFlags=0x10200000;component=com.iBer.iBerAppV2/.MainActivity;end

解释：每个seed值 前面都会有个Switch 告诉你从啥页面开始 ，如上面告诉你 com.iBer.iBerAppV2/.MainActivity开始出现闪退。

 

// CRASH: com.iBer.iBerAppV2 (pid 1952)

Events injected: 4486

//[calendar_time:2019-05-22 11:41:10.905 system_uptime:131091]
// Sending event #4400

解释: 从日志看到 第4400个事件 大概在2019-05-22 11:41:10.905 发生，那么第4486个事件就是该时间之后，我们去看手机日志

 

 

 

 

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

第一步：首先我们需要对要拦截的接口进行断点调试

第二步：然后我们就正常的请求接口，这个时候charles断点的原因，会导致请求被等待中

第三步：这个时候我们就可以修改返回结果了

参考链接：https://blog.csdn.net/BunnyCoffer/article/details/90169479

 

 

 

 

 

Charles的安装和使用：

说明
charles相当于一个插在服务器和客户端之间的“过滤器”；
当客户端向服务器发起请求的时候，先到charles进行过滤，然后charles在把最终的数据发送给服务器；
注意：此时charles发给服务器的数据，不一定是客户端请求的数据；charles在接到客户端的请求时可以自由的修改数据，甚至可以直接Block客户端发的请求；
服务器接收请求后的返回数据，也会先到charles，经过charles过滤后再发给客户端；
同理：客户端接收的数据，不一定就是服务器返回的数据，而是charles给的数据；
正因为上面的原理，所以charles能实现的功能，对前端开发者来说非常有吸引力，相当于请求和响应都可控的，而且charles为了控制更加方面，提供很多简洁的操作；

Charles的主要功能：
• 抓取 Http 和 Https 的请求和响应，抓包是最常用的了。
• 重发网络请求，方便后端调试，复杂和特殊情况下的一件重发还是非常爽的（捕获的记录，直接repeat就可以了，如果想修改还可以修改）。
• 修改网络请求参数（客户端向服务器发送的时候，可以修改后再转发出去）。
• 网络请求的截获和动态修改。
• 支持模拟慢速网络，主要是模仿手机上的2G/3G/4G的访问流程。
• 支持本地映射和远程映射，比如你可以把线上资源映射到本地某个文件夹下，这样可以方面的处理一些特殊情况下的bug和线上调试（网络的css，js等资源用的是本地代码，这些你可以本地随便修改，数据之类的都是线上的环境，方面在线调试）；
• 可以抓手机端访问的资源（如果是配置HOST的环境，手机可以借用host配置进入测试环境）

 

Charles在项目中的使用：

https://zhuanlan.zhihu.com/p/151774468

 

 

 

1. Charles如何抓取app端的htpps接口的？

1、下载安装好Charles

2、设置Charles上的代理

打开Charles->Proxy->Proxy Setting，设置代理端口为8888，并勾选Enable transparent HTTP proxying

3、设置iphone上的代理

Settings->WLAN 选择同一网络，

设置server：PC的ip地址 port：8888

4、PC端安装Charles证书

Charles->Help->SSL Proxying->Install Charles Root Certificate 下载证书

如果证书不被信任，可以点击Charles->Help->SSL Proxying->Save Charles Root Certificate保存证书到指定文件，然后可以通过将证书导入到“受信任的根证书颁发机构du”存储区中解决该问题：

 

①win+r 运行mmc，将证书添加到管理单元

②受信任的根证书颁发机构->证书 右键导入刚才保存的Charles证书就ok了

5、iphone安装Charles证书

6、在Charles上添加上想要解析的https网址的域名

 

链接：https://blog.csdn.net/qq_35556233/article/details/107109915

 

 

 

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

①　构建一个maven工程

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

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

④　jenkins控制台乱码
自行百度：http://blog.csdn.net/gld824125233/article/details/52549557

链接：https://blog.csdn.net/will_lam/article/details/78412093

 

 

 

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

1．接口选择：一般情况下，接口主要有两类，即查询接口和数据保存接口。保存接口主要是将传入的参数先做数据校验，数据校验通过后将其保存到表中。

2．用jmeter进行多接口测试。先添加一个名称为InterfaceTest的线程组。

3．在线程组上添加一个Http请求。

4．对Http请求的服务器的IP地址、传输编码等进行配置。

5．再新增一个名称为“增加 信用卡账户信息接口”的http请求，并做好有关配置。

6．再新增一个名称为“ 保存信用卡账单接口”的http请求，并做好有关配置。

7．添加监听器，察看结果树和聚合报告。

8．运行，查看结果。

链接：https://jingyan.baidu.com/article/25648fc15ce3439190fd0053.html

 

 

1. 你为什么离开上家公司？离职原因（这个会在最后问）
2. 请写出冒泡排序

public static int[] buddleSort(int[] arr){

    for(int i=1;i<arr.length;i++){

        for(int j=0; j<arr.length-i; j++){

            if(arr[j] < arr[j+1]){

                int temp = arr[j];

                arr[j] = arr[j+1];

                arr[j+1] = temp;

            }

        }

    }

    return arr;

}

 

1. 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 0

Return 10*countThree(digit-1) + 10 **(digit-1)

Print(countThree(count_dight(9999)))

 

1. 从一个数组中找出前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 in list[1: ] if i mid]

finallyList = qiuckSort(left) + [mid] + qiuckSort(right)

Return finallyList

Array = [3,0,832,23,35,5,5,6,45,9,87,897]

Print(qiuckSort(array)[-4:])

 

 

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

public static void main(String args[]){

String test=test(“sahsjkshabshwkiixab”,””);

System.out.println(test);

}

public static String test(String str,String targetstr) {

StringBuffer bf = new StringBuffer();

if (str==null||targetStr==null) {

return bf.toString();

}

if (str.length()>=targetstr.length()){

for(int i=0;i<str.length();i++){

if(i+targetstr.length()>str.length()){

bf.append(str.substring(i,str.length())); break;

}

if(!str.substring(i,i+targetstr.length()).equals(targetstr)){

bf.append(str.substring(i,i+1));

}

else{

i=i+targetstr.length()-1;

}

}

return bf.toString();

}

else {

bf.append(str);

return bf.toString();

} } }

本程序写完后，运行测试过程中，遇到一个有意思的问题，当输入字符串某个为null的时候，程序进入死循环，一直没执行完，后发现是因为判断条件 if (str==null||targetStr==null) 不生效导致；

为什么不生效呢？？？？

因为搞混了“”和null是有区别的，

1. null表示这个字符串不指向任何的东西，如果这时候你调用它的方法，那么就会出现空指针异常。

2.””表示它指向一个长度为0的字符串，这时候调用它的方法是安全的。

3. null不是对象，””是对象，所以null没有分配空间，””分配了空间，例如： String str1 = null; str引用为空 String str2 = “”; str应用一个空串

4，所以，判断一个字符串是否为空，首先就要确保他不是null，然后再判断他的长度。 String str = xxx; if(str != null && str.length() != 0) { }

另外考虑效率的问题：s.equals(“”) 慢于s.length() <= 0；而s.isEmpty()有可能不兼容；

所以此处最好将判断条件修改为 if (str==null||str.length()==0||targetstr==null||targetstr.length()==0)

 

 

 

1. 写一个方法把字符串转为数字，比如 str=”1234″，变成 int 1234。并且测试这个程序

def StrToInt():

 words = input(\’input:\’)

try:

word = words.replace(\’ \’,\’\’)

word = int(word)

return word

except Exception as e: return e

if __name__==”__main__”:

a = StrToInt()

print(a)

 

 

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

基本定义：　　

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

1、内联接（典型的联接运算，使用像 =  或 <> 之类的比较运算符）。包括相等联接和自然联接。     
　　内联接使用比较运算符根据每个表共有的列的值匹配两个表中的行。例如，检索 students和courses表中学生标识号相同的所有行。   
    
2、外联接。外联接可以是左向外联接、右向外联接或完整外部联接。     
　　在 FROM子句中指定外联接时，可以由下列几组关键字中的一组指定：     

　　1）LEFT  JOIN或LEFT OUTER JOIN     
　　左向外联接的结果集包括  LEFT OUTER子句中指定的左表的所有行，而不仅仅是联接列所匹配的行。如果左表的某行在右表中没有匹配行，则在相关联的结果集行中右表的所有选择列表列均为空值。       

　　2）RIGHT  JOIN 或 RIGHT  OUTER  JOIN     
　　右向外联接是左向外联接的反向联接。将返回右表的所有行。如果右表的某行在左表中没有匹配行，则将为左表返回空值。       
　　3）FULL  JOIN 或 FULL OUTER JOIN
　　完整外部联接返回左表和右表中的所有行。当某行在另一个表中没有匹配行时，则另一个表的选择列表列包含空值。如果表之间有匹配行，则整个结果集行包含基表的数据值。   
    
3、交叉联接   
　　交叉联接返回左表中的所有行，左表中的每一行与右表中的所有行组合。交叉联接也称作笛卡尔积。    
　　FROM 子句中的表或视图可通过内联接或完整外部联接按任意顺序指定；但是，用左或右向外联接指定表或视图时，表或视图的顺序很重要。有关使用左或右向外联接排列表的更多信息，请参见使用外联接。     

 

 

 

 

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

错误强度曲线下降到预定的水平