不管是传统行业的web测试，还是新兴的手机app测试，都离不开测试的基础知识：
1）同样的设计测试用例方法：边界值分析法、等价类划分、错误推测法、场景法等（若想看这些基础课视频，直接点击原文看腾讯课堂的视频，都有，且免费！）；
2）同样的测试方法：黑盒测试，验证业务功能是否正确符合用户或者设计预期；
3）都要检查UI：界面的布局、风格和按钮等是否简洁美观、是否统一等；
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、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并不支持。
1.安装和卸载
●应用是否可以在IOS不同系统版本或android不同系统版本上安装（有的系统版本过低，应用不能适配）
●软件安装后是否可以正常运行，安装后的文件夹及文件是否可以写到指定的目录里。
●安装过程中是否可以取消
●安装空间不足时是否有相应提示
●如果应用需要通过网络验证之类的安装，需要测试一下断网情况下是否有相应提示
●是否可以删除应用（可通过桌面删除，也可以通过软件卸载安装。曾发现在IOS手相上有个应用安装时未完全安装，终止安装后，未完成安装的应用图标一直显示在手机上，并且无法成功删除）
●测试卸载后文件是否全部删除所有的安装文件夹
●卸载过程中出现死机，断电，重启等意外的情况，待环境恢复后是否可以正确卸载
●卸载是否支持取消功能，单击取消后软件卸载情况是否正常
2.运行
●APP安装完成后，是否可以正常打开软件
●APP运行时，是否有加载图示
●APP的速度是可以让人接受，切换是否流畅
●对于多个端都进行操作时，确保数据库操作无误，且每个端可以及时看到数据的更新
4.离线
离线是应用程序在本地的客户端会缓存一部分数据以功程序下次调用
●对于无网络时，刷新获取新数据时，不能获取数据且能给出友好提示
●切换到后台，再次切换到前台时，可以正常查看
●离线后又连上网，这时对数据有更新时，需要从服务器端获取新数据来更新客户端数据，且要更新本地缓存信息
●对于一些界面的数据不提供离线查看，需要给出相应提示且界面更新后无任何数据
●确认在无网情况下可以浏览本地数据
●确认退出APP再开启APP时能正常浏览
●确认切换到后台再切回APP应用时可以正常浏览
●锁屏后再解锁回到应用前台可以正常浏览
●服务端的数据有更新时有离线的提示
5.数据更新
●确认有数据更新后，哪些地方需要手动刷新，哪些地方需自动刷新。
●确认从后台切换回前台时，哪些页面需要进行数据更新
●根据需求和逻辑，确认哪些数据是从服务端请求实时响应，哪些是缓存到本地的数据。
6.消息推送开关设置
●默认开关应该是全打开状态
●设置开关可以自由打开关闭
●设置开关打开状态下，消息推送是否可正常接收（应用启用中和应用关闭时都应该可以收到）
●确认后台未打开APP客户端时，手机消息栏可以接收到消息提醒。且点击可查看。点击后消息栏中消失
●确认APP客户端启动时，可以收到消息提醒，且点击可查看。客户端运行时，消息不会进消息栏。
●设置开关关闭时，客户端接收不到消息推送。
7.软件更新
●当客户端有新版本时，有更新提示
●软件更新一定要测，确保android软件更新可以正确更新新版本，且安装运行正确。
●确保IOS软件更新会有限制，只有上了商店且有版本更新时才会测试，但是如果真有问题，再发现问题不点晚，可以让开发先在测试机上模拟一个地址进行测试。
●用户取消版本更新时，老版本可以正常使用，但是下次启动应用时，仍出现更新提示
●当有新版本时，不删除客户端的情况下，直接更新检查是否能正常更新，且更新后客户端的功能是否最新版本（正常来讲不用强制删除本地客户端可以正常更新）
8.异常测试
●没有内存空间时，APP能否正确响应
●APP运行中手机断电
●APP运行中断开网络
●反复操作某个功能，不断点击，刷新时，是否会闪退
●APP运行时发送信息、收取邮件等
●多个APP运行时
●不断切换前台和后台，是否影响应用正常功能
●APP运行时，启动相机功能
９.网络环境
●测试２G、３Ｇ，４Ｇ，wifi网络下应用运应的速度
●内网测试时，选择到外网操作是否有异常处理
●网络不好时，提交数据是否一直处理提交中，是否会有延迟，数据交换失败是否会有提醒
●有网到无网再到有网环境时，数据是否可以自动恢复，正常加载
10.其它
●接口测试。让开发提供一份接口文档，一定要将接口测试通。在接口测试阶段，将缺少接口，接口不完善的缺陷挖掘出来。这个需要准备充分的后台数据。
●导航测试。在运行APP时，不管在哪个接点，导航是否直观，精准，页面切换是否正确。
●图片测试。图片，按钮是否自适应。
●内容测试。要进行超长字符，空字符校验且校验是否有错别字
●功能测试。功能是否实现。
●易用性测试。所开发的功能，是否让用户容易接受，是否符合大众的操作习惯。
●适配性测试。应用在不同设备，不同系统上是否适配。
●UI测试。应用的设计是否够美观。
1、检查Push消息是否按照指定的业务规则发送。
2、检查不接收推送消息时，用户不会在接收到Push消息。
5、测试Push时，在开关机、待机状态下执行推送，消息及其推送跳转的正确性。
6、push消息时，会有红点展示，推送消息阅读前后数字的变化是否正确；
7、应用在开发、未打开状态、应用启动且在后台运行的情况下是push显示和跳转是否正确。
8、多条推送的合集的显示和跳转是否正确。
一般App闪退是由于以下几个原因造成的.
1.缓存垃圾过多
2.运行的程序过多,导致内存不足
3.应用版本兼容问题
如果应用版本太低，会导致不兼容，造成闪退。此外，有些新版本在调试中，也会造成应用闪退。
解决方法：如果是版本太旧，更新为新版本即可；如果是新版本闪退，可能是应用在改版调试，可卸载后安装旧版。
4.检查APP中访问网络的地方，组件中的ImageView是否可以正常的下载并显示到app页面上。
5.检查APP的sdk和手机的系统是否兼容。
6.在一些特定情况下的闪退,比如播放视频,在Android5.0升级到Android6.0的时候,有些系统API老版本有,新版本没有,到时回去对象的时候失败,报空,系统就会出现闪退问题.
不同软件之间对接常用的接口协议：
1)OPC协议：
2)ODBC
3)WebService协议
4)HttpRestful协议
1、Get向特定资源发出请求（请求指定页面信息，并返回实体主体）2、Post向指定资源提交数据进行处理请求（提交表单、上传文件），又可能导致新的资源的建立或原有资源的修改3、Put向指定资源位置上上传其最新内容（从客户端向服务器传送的数据取代指定文档的内容）4、Head与服务器索与get请求一致的相应，响应体不会返回，获取包含在小消息头中的原信息（与get请求类似，返回的响应中没有具体内容，用于获取报头）5、Delete请求服务器删除request-URL所标示的资源（请求服务器删除页面）6、opions返回服务器针对特定资源所支持的HTML请求方法或web服务器发送测试服务器功能（允许客户端查看服务器性能）
2开头的状态码
2xx表示成功处理了请求状态码
200（成功）服务器已经成功处理了请求通常；
3开头的状态码
3xx（重定向）表示要完成请求，需要进一步操作，通常这些状态码用来重定向
304（未修改）自从上次请求后，请求的网页未修改过，服务器返回此响应时不会返回网页内容；
4开头的状态码
4xx(请求错误)这些状态码表示请求可能出错，妨碍了服务器的处理
400（错误请求）服务器不理解请求的语法；
403（禁止）服务器拒绝请求
404（未找到）服务器找不到请求的网页
5开头的状态码
5xx(服务器错误)这些状态码表示服务器再尝试处理请求时发生内部错误，这些错误可能是服务器本身错误而不是请求错误
501（尚未实施）服务器不具备完成请求的功能；
例如：服务器无法识别请求方法时可能会返回此代码
500（服务器内部错误）服务器遇到错误无法完成请求
502（错误网卡）服务器做为网关或代理，从上游服务器收到无效响应
503（服务不可用）服务器目前无法使用（由于超载或者停机维护）通常这只是暂时状态
504（网关超时）服务器做为网关或代理，但是没有及时从上游服务器收到请求
对于接口测试，首先测试人员要懂代码，你只需要知道接口的作用是什么就可以了（有文档更好，但大部分都没有）；其次，自己去读开发的代码；然后，根据该接口功能及代码写测试用例；
用例设计：
1：写一个程序去调用该接口，看是否能够达到该接口所定义的功能
2：根据该接口参数，构造不同的用例，测试接口在参数合法及非法情况下能否达到预期效果
3：根据该接口中的逻辑，设计不同条件的用例，测试该接口实现代码的逻辑
4：进行容错及健壮性测试
5：静态检测代码，看是否有内存泄露、或永远走不到的分支、代码规范及逻辑是否合理。
6：对于一些接口，需要进行多线程测试
从后端角度出发：后端测试自己开发的接口，更多在于单测层面，好的开发会从接口业务调用场景出发，覆盖一些功能case，但是开发测试自己的代码，他往往觉得自己的代码已经很完美了，所以开发测试自己的代码往往是覆盖不全面的。
从测试角度出发：测试是保证质量最重要的一环，接口测试我们不仅仅只考虑功能层面用例，还要从非功能层面出发，比如接口性能，稳定性，安全性。我们还要结合业务场景，去思考一些反向的异常case，和其他服务相互调用过程的异常场景怎么兜底，依赖服务响应超时怎么兜底，系统异常怎么兜底等。
准备阶段（80%）
拿到开发的接口文档，并理解每个接口的参数及含义
了解被测试系统的业务流程
编写接口测试用例
执行阶段（10%）
测试用例/测试场景执行
测试数据/系统数据收集
分析阶段（10%）
数据汇总/日志分析
测试报告
通过开发给的接口文档去了解接口有哪些内容
首先，接口文档应该包含以下内容：1）接口说明2）调用url3）请求方法（get\post）4）请求参数、参数类型、请求参数说明5）返回参数说明
2.了解业务需求及业务流程
3.编辑接口用例
如何编写接口的用例？其实接口的用例与功能测试的用例类似，下面简单的写下，比如说：A功能测试，用例标题：输入正确的用户名、密码规范，注册成功用户名不规范，注册失败…B那如果接口测试的话，用例标题：我喜欢用思维导图的形式编写案例
4.执行接口用例
5.编写接口测试报告
1、传送方式：get通过地址栏传输，post通过报文传输。
2、传送长度：get参数有长度限制（受限于url长度），而post无限制
3、GET和POST还有一个重大区别，简单的说：
GET产生一个TCP数据包；POST产生两个TCP数据包
长的说：
而对于POST，浏览器先发送header，服务器响应100continue，浏览器再发送data，服务器响应200ok（返回数据）。
也就是说，GET只需要汽车跑一趟就把货送到了，而POST得跑两趟，第一趟，先去和服务器打个招呼“嗨，我等下要送一批货来，你们打开门迎接我”，然后再回头把货送过去。
1.GET与POST都有自己的语义，不能随便混用。
3.并不是所有浏览器都会在POST中发送两次包，Firefox就只发送一次。
测试每个参数类型不合法的情况(类型不合法容易遗漏NULL型)*测试每个参数取值范围不合法的情况*测试参数为空的情况*测试参数前后台定义的一致性*测试每个参数的上下限(这里容易出致命的BUG，如果程序处理不当，可能导致崩溃)*如果两个请求有严格的先后顺序，需要测试调转顺序的情况
1、负载测试；通过自动化测试工具模拟程序或者软件系统在超强负荷条件下，观察系统各项性能指标的变化情况，一般与压力测试共同进行。
2、强度测试；指系统在资源条件很差工作环境下的运行情况，如人为限制网络带宽，内存等。
3、容量测试；一般指模拟用户不断增加时，确定系统可以处理同时在线的最大用户数量。
要开展性能测试是有一些前提的：
首先，基础的功能测试要完成，并且要保证系统是处于比较稳定的状态；
然后，当系统的使用人数比较多或者并发量比较大的时候可以考虑性能测试；因为如果系统使用的人比较少，其实是没必要进行性能测试的；
然后，了解本次性能测试的目标：QPS预估多少，CPU或者内存预计占比多少，磁盘占用等等；
然后，准备好性能测试工具Jmeter或者LoadRunner等；
以上都准备好后，就可以开始性能测试工作了。
1.根据需求规格提取独立的功能点，确定测试范围；
2.对独立功能进行分析，确定各独立功能的测试点；
3.对业务场景即功能组合进行分析，提供业务场景的测试点；
4.对非功能特性进行分析，了解需要测试的非功能特性；
5.针对系统级接口进行分析，了解被测试对象、测试规格。分析可测性，确定测试方法、工具。
一、准备工作
1、系统基础功能验证
性能测试在什么阶段适合实施？切入点很重要！一般而言，只有在系统基础功能测试验证完成、系统趋于稳定的情况下，才会进行性能测试，否则性能测试是无意义的。
2、测试团队组建
根据该项目的具体情况，组建一个几人的性能测试team，其中DBA是必不可少的，然后需要一至几名系统开发人员（对应前端、后台等），还有性能测试设计和分析人员、脚本开发
3、工具的选择
综合系统设计、工具成本、测试团队的技能来考虑，选择合适的测试工具，最起码应该满足一下几点：
②工具运行在Windows平台上；
③支持对webserver、前端、数据库的性能计数器进行监控；
4、预先的业务场景分析
为了对系统性能建立直观上的认识和分析，应对系统较重要和常用的业务场景模块进行分析，针对性的进行分析，以对接下来的测试计划设计进行准备。
二、测试计划
测试计划阶段最重要的是分析用户场景，确定系统性能目标。
1、性能测试领域分析
根据对项目背景，业务的了解，确定本次性能测试要解决的问题点；是测试系统能否满足实际运行时的需要，还是目前的系统在哪些方面制约系统性能的表现，或者，哪些系统因素导致
系统无法跟上业务发展？确定测试领域，然后具体问题具体分析。
2、用户场景剖析和业务建模
3、确定性能目标
④服务器的CPU平均使用率小于70%，内存使用率小于75%；
三、测试脚本设计与开发
1、测试环境设计
本次性能测试的目标是需要验证系统在实际运行环境中的性能外，还需要考虑到不同的硬件配置是否会是制约系统性能的重要因素！因此在测试环境中，需要部署多个不同的测试环境，
在不同的硬件配置上检查应用系统的性能，并对不同配置下系统的测试结果进行分析，得出最优结果（最适合当前系统的配置）。
这里所说的配置大概是如下几类：
①数据库服务器
②应用服务器
③负载模拟器
④软件运行环境，平台
测试环境测试数据，可以根据系统的运行预期来确定，比如需要测试的业务场景，数据多久执行一次备份转移，该业务场景涉及哪些表，每次操作数据怎样写入，写入几条，需要多少的
测试数据来使得测试环境的数据保持一致性等等。
可以在首次测试数据生成时，将其导出到本地保存，在每次测试开始前导入数据，保持一致性。
2、测试场景设计
通过和业务部门沟通以及以往用户操作习惯，确定用户操作习惯模式，以及不同的场景用户数量，操作次数，确定测试指标，以及性能监控等。
3、测试用例设计
确认测试场景后，在系统已有的操作描述上，进一步完善为可映射为脚本的测试用例描述，用例大概内容如下：
用例编号：查询表单_xxx_x1（命名以业务操作场景为主，简洁易懂即可）
操作步骤：
①进入对应页面。。。。。。
③勾选导出数据。。。。。。
④修改上传数据。。。。。。
PS：这里的操作步骤只是个例子，具体以系统业务场景描述；
4、脚本和辅助工具的开发及使用
按照用例描述，可利用工具进行录制，然后在录制的脚本中进行修改；比如参数化、关联、检查点等等，最后的结果使得测试脚本可用，能达到测试要求即可；
PS：个人而言，建议尽量自己写脚本来实现业务操作场景，这样对个人技能提升较大；一句话：能写就绝不录制！！！
四、测试执行与管理
在这个阶段，只需要按照之前已经设计好的业务场景、环境和测试用例脚本，部署环境，执行测试并记录结果即可。
1、建立测试环境
按照之前已经设计好的测试环境，部署对应的环境，由运维或开发人员进行部署，检查，并仔细调整，同时保持测试环境的干净和稳定，不受外来因素影响。
2、执行测试脚本
这一点比较简单，在已部署好的测试环境中，按照业务场景和编号，按顺序执行我们已经设计好的测试脚本。
3、测试结果记录
根据测试采用的工具不同，结果的记录也有不同的形式；现在大多的性能测试工具都提供比较完整的界面图形化的测试结果，当然，对于服务器的资源使用等情况，可以利用一些计数器或
第三方监控工具来对其进行记录，执行完测试后，对结果进行整理分析。
五、测试分析
1、测试环境的系统性能分析
根据我们之前记录得到的测试结果（图表、曲线等），经过计算，与预定的性能指标进行对比，确定是否达到了我们需要的结果；如未达到，查看具体的瓶颈点，然后根据瓶颈点的具体数据，
进行具体情况具体分析（影响性能的因素很多，这一点，可以根据经验和数据表现来判断分析）。
2、硬件设备对系统性能表现的影响分析
由于之前设计了几个不同的测试环境，故可以根据不同测试环境的硬件资源使用状况图进行分析，确定瓶颈是再数据库服务器、应用服务器抑或其他方面，然后针对性的进行优化等操作。
3、其他影响因素分析
影响系统性能的因素很多，可以从用户能感受到的场景分析，哪里比较慢，哪里速度尚可，这里可以根据2\5\8原则对其进行分析；
至于其他诸如网络带宽、操作动作、存储池、线程实现、服务器处理机制等一系列的影响因素，具体问题具体分析，这里就不一一表述了。
4、测试中发现的问题
在性能测试执行过程中，可能会发现某些功能上的不足或存在的缺陷，以及需要优化的地方，这也是执行多次测试的优点
1)查看系统日志，如果日志记录的全面，很容易通过日志发现问题。比如，系统宕机时，系统日志打印了某方法执行是抛出outofmemory的错误，很快定位到导致内存溢出的问题在哪里。
2)利用性能监控工具，比如：linux系统环境下通过nmon来监控系统性能。
3)设计合理的性能测试场景，好的测试场景能更加快速的发现瓶颈。
4)了解系统参数配置，可以进行后期的性能调优
1注册用户数
注册用户数指软件中已经注册的用户，这些用户是系统的潜在用户，随时都有可能上线。这个指标的意义在于让测试工程师了解系统数据中的数据总量和系统最大可能有多少用户同时在线。
2在线用户数
3并发用户数
不同于在线用户数，并发用户数是指某一时刻向服务器发送请求的在线用户数，他是衡量服务器并发容量和同步协调能力的重要指标，从这个含义上讲，我们可能会如下两种理解：
同一时刻向服务器发送相同或者不同请求的用户数，也就是说，既可以包括对某一业务的相同请求，也可以包括对多个业务的不同请求
同一时刻向服务器发送相同请求的用户数，仅限于某一业务的相同请求
（1）在3秒之内，页面给予用户响应所有显示，可认为是很不错的
（2）在3-5秒之内，页面给予用户响应所有显示，可认为是好的
（3）在5-10秒之内，页面给予用户响应所有提示，可认为是勉强接受的
（4）超过10秒后就有点让人不耐烦，用户会感觉很坑不会继续等待下去
6每秒点击数
7吞吐率
8业务成功率
指多用户对某一业务发起操作的成功率。例如，测试网络订票系统的并发处理性能，在早上8:00——8:30半小时的高峰里，要求能支持10万比订票业务，其中成功率不少于98%。也就是说系统允许200笔订票业务超时或者因其他原因导致未能订票成功。
9资源利用率
资源利用率就是指资源的使用情况，如CPU使用率、内存使用率、网络宽带的使用情况、磁盘I/O的输入输出量等系统硬件方面的监控指标。一个完整的系统是由软件和硬件组成，缺了任何一方都不可能成为一个正常运作的系统，所以资源利用率也是测试人员的一个监控点，并在当前软件的发展趋势下，硬件资源的成本也不可小视。
10每秒事务数（TPS）
TPS表示服务器每秒处理的事务数，他是衡量系统处理能力的一个非常重要的指标，在性能测试中，通过检测不同用户的TPS,可以估算出系统处理能力的拐点。
11访问量（PV）
页面访问量（PageView）,每打开一次页面，PV计数+1，刷新页面也算。
12访问数（UV）
访问数（UniqueVisitor）,指独立访客的数量，一台电脑终端为一个访客。
13IP访问数（IV）
IV指的是独立IP访问数，计算是以一个独立的IP在一个计算时段内访问网站计算为1次IP访问数。在同一个计算时段内不管这个IP访问多少次均计算为1次。
并发数并发数是指系统同时能处理的请求数量，这个也是反应了系统的负载能力。
QPS（每秒查询数）、TPS（每秒事务数）是吞吐量的常用量化指标，另外还有HPS（每秒HTTP请求数）。
Linux中可以使用top或者uptime命令看到当前系统的负载及资源利用率情况。
资源利用率：指系统各种资源的使用情况，如cpu占用率为68%，内存占用率为55%，一般使用“资源实际使用/总的资源可用量”形成资源利用率。
1）性能测试
2）负载测试
负载测试是一种通过增加负载来评估组件或系统的性能的测试方法。例如：通过增加并发用户数和（或）事务数量来测量组件或系统能够承受的负载。负载测试和性能测试的主要区别在于负载测试时，系统负载是逐渐增加的，而不是一步到位，负载测试需要观察系统在各种不同的负载情况下是否都能够正常工作。
3）压力测试
例如：系统最大支持的同时在线用户数是1000个，压力测试需要测试在1000个用户甚至2000个用户同时在线时系统的表现。虽然测试时负载已经超过了系统的设计能力，但是在这种情况下被测试系统也不应该发生崩溃。压力测试也可以针对系统资源进行测试，例如：在系统内存耗尽情况下，测试系统的运行情况，这种情况下被测试系统也不应该崩溃。
将问题提交到缺陷管理库里面进行备案。
2、要获取判断的依据和标准：
根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；根据用户的一般使用习惯，来确认是否是缺陷；
4、合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。
等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。
网站测试分以下几方面内容
性能测试
（2）负载测试：负载测试是在某一负载级别下，检测电子商务系统的实际性能。允许多少个用户同时在线，可以通过相应的软件在一台客户机上模拟多个用户来测试负载。
（3）压力测试：压力测试是测试系统的限制和故障恢复能力，也就是测试电子商务系统会不会崩溃。
安全性测试
对网站的安全性（服务器安全，脚本安全）可能有的漏洞测试，攻击性测试，错误性测试。对电子商务的客户服务器应用程序、数据、服务器、网络、防火墙等进行测试。用相对应的软件进行测试。
基本测试
包括色彩的搭配，连接的正确性，导航的方便和正确，CSS应用的统一性。
网站优化测试
（1）引擎优化测试：好的网站是看它是否经过搜索引擎优化了，网站的架构、网页的栏目与静态情况等。
（2）用户优化测试：用户来到网站能能够在3-5次，找到其需要的内容。方便用户的网站倍受用户的亲昵。
功能实现：网站现有版本，需求是否完全实现。满足需求的网站才是有用的网站。
App测试
1．功能测试
2．客户端性能测试
3．适配兼容测试
4．安全测试
5．服务器性能测试
测试用例：
一组由前提条件、输入、执行条件、预期结果等组成，以完成对某个特定需求或者目标测试的数据，体现测试方案、方法、技术和策略的文档
测试脚本：
一般指的是一个特定测试的一系列指令，这些指令可以被自动化测试工具执行。为了提高测试脚本的可维护性和可复用性，必须在执行测试脚本之前对它们进行构建。
测试脚本是一段代码不假。但是这段代码可能是为了执行某一条，或很多条测试用例而写的。也有可能，本身就是一条用例。用例本身并不局限在基于功能。脚本和用例没有并列的可比性。脚本可能是用例，也可能是执行用例用的功能。用例也可能是脚本。
静态测试
静态测试是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。
动态测试
单元测试
集成测试
系统测试
验收测试
回归测试
黑盒测试
黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。
白盒测试
白盒测试，也称为结构化测试、基于代码的测试，是一种测试用例设计方法，它从程序的控制结构导出测试用例。用白盒测试产生的测试用例能够：1）保证一个模块中的所有独立路径至少被使用一次；2）对所有逻辑值均需测试true和false；3）在上下边界及可操作范围内运行所有循环；4）检查内部数据结构以确保其有效性。
α测试
一般只供内部测试使用
β测试
已经消除了软件中大部分的不完善之处，但仍有可能还存在缺陷和漏洞，一般只提供给特定的用户群来测试使用
一条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.在你的项目中详细的描述一个测试活动完整的过程？
一、项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员，测试人员以及客户的意见，完成项目计划。然后进入项目，开始进行统计和跟踪
依据代码review的结果和影响范围，对测试内容进行适当的裁剪。借助自动化工具的支持，提高测试案例的执行效率。调整组内任务的优先级，进行人力协调，优先投入最紧要的项目。必要的情况下加班
一个测试经理，3个测试组长，每个组有5个测试人员：包括自动化测试、，功能测试、性能测试等的测试工程师。
移动端
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极速浏览器（兼容模式）、搜狗浏览
（2）Firefox内核常见的浏览器即火狐浏览器（Firefox）；
（3）Chrome内核常见的浏览器有
3.分辨率兼容性
同一个页面在不同分辨率下，显示的样式可能会不一样。可以通过对浏览器的缩放的比例进行不同分辨率的测试。
台式机分辨率：：1024×768、1280×1024、1440×900
笔记本电脑分辨率：1024X768、1280X800、1440X900、1600X9000
4.网速测试
项目在不同的网络环境中是否正常的运行，通过Charles、Fiddler等工具进行弱网测试。
iOS平台的灰度发布，不建议在越狱渠道上做。做大渠道（其实就是91）肯定会影响收入指标（主要针对电商app），做小渠道完全没结果，而且还有被大渠道抓包的风险。那么解决方案就剩下有分发权限的299刀高级开发者帐号了，只要培养足够的用户量，这个样本容量还是足够大的。当然，要自搞个新开发者帐号，要考虑如何回收这个帐号发出去的版本都是麻烦事，如果只是为了测试某个功能，也可以就拿91渠道干一票。（表面上PM好像实现了目的，但工程师必然叫苦连天，个人觉得是个亏本买卖，不值当。）
最后，一切的前提都是：1.做好版本管理（一个有条理、敬畏秩序的、能写代码的发布经理）；2.打好数据桩（重点注意按版本观测所有数据，数据要贯通不要片段）；3.灰度版本有回收能力（不然老板时不时因为微博用户报告的某个灰度版本的bug来让你擦屁股就不用干正事了）。这部分我100%同意一楼张瑞老师的意见。
好的方法论（灰度发布）貌似能解决的一切问题，但是把这个推行起来的那个人，说起来都是泪。
1.APP有新版本时，打开APP是否有更新提示。2.当版本为非强制升级版时，用户可以取消更新，老版本能正常使用。用户在下次启动app时，仍能出现更新提示。3.当版本为强制升级版时，当给出强制更新后用户没有做更新时，退出APP。下次启动app时，仍出现强制升级提示。4.不删除APP直接更新，检查是否能正常更新，更新后能否正常工作。5.删除老的APP，重新下载APP，能不能正常工作。6.不删除APP直接更新，检查更新后的APP和新安装的APP提供的功能一样。7.检查在线跨版本升级能否成功，版本过老是否提示用户重装。8.更新成功后，用户数据有没有丢失，各个配置项是否还原
功能测试用例
卡的类型（
一类户：借记卡、信用卡、各个开户行
支付限额（单笔限额、累计限额、日累计、月累计、支付笔数）
退款（退款入口、退款进度、退款结果）
对账
资金流动（我方扣款数额正确，对方收款数额正确）数额及时效
支付结果展示、交易明细
连续扫码支付，每天的扫码支付次数限制及数额限制
二维码有效期
有无相机权限
前后置摄像头
像素低端的手机能否扫码成功
兼容性
兼容性（不同手机厂商自带相机功能实现不一致）
安全性：
1.是否有超时超次限制
3.如果使用了安全套字，需要测试加密是否正确，加密前后的信息完整性，正确性
性能
2.系统的吞吐量（TPS）
3.系统的硬件资源情况（CPU、硬盘、磁盘）
4.网络资源占用情况等。
异常场景
异常情况（卡异常、余额不足）
站在测试人员的技术测试角度：
1.功能测试
功能测试是软件测试中最基本的测试，功能实现不满足要求，软件就不能发布测试。要进行功能测试，首先就需要了解朋友圈的各个功能，那么如何了解朋友圈的功能呢？——需求文档。因为所有的开发设计、测试设计等，都是以需求文档来进行的。需求文档中规定了必须有哪些功能，那么我们在测试的时候就可以对比知道哪些功能实现了，还有哪些功能未实现（需要说明的是：开发计划明确说明当前版本暂不实现的功能，不能算作bug）。
1）发朋友圈、删除朋友圈，看朋友圈；
2）朋友圈的类型（图、文、混合）；
5）屏蔽与被屏蔽，不能查看对应好友的朋友圈；
————————————————
我们做基础功能测试，就需要对朋友圈具有的所有功能进行测试。
2.可靠性测试
规定的功能是指提供给定的服务，软件产品所必须具备的功能。
软件可靠性不但与软件存在的缺陷（或）差错有关，而且与系统输入和系统使用有关。软件可靠性的概率度量程为软件可靠度。
3.性能测试
性能测试主要对服务器的性能进行测试的。在App上，性能测试分为客户端性能、服务器性能。
4.其他测试
例如：
1）在弱信号的情况，进行发朋友圈、看朋友圈等操作，测试其是否会产生其它未知故障。（例如对WiFi信号进行限速）
2）在不同的客户端的兼容性测试，使用不同平台的客户端进行朋友圈的功能测试。（例如使用不同厂商的手机、平板）
站在用户的角度
站来用户角度来说，易用性是其评价软件好坏最主要的一点，功能操作是否简单明了，给出的提示是否清楚明白无二意，还有就是界面布局否美观合理。
除此之外，我们还要模拟不同的用户场景下的使用。把自己想象为不同的用户（小白用户，资深用户），因为不同的用户有不同的使用习惯，这也类似于发散测试，因人而异
一，有共同的目标，共同的利益。二，默契。三，大度，谦让，素质。
维持测试人员与团队其他成员的良好关系从两个方面入手：
二、缺陷的奖罚制度很多时候开发和测试人员之间发生争执是因为缺陷引起。开发人员认为问题太小，不属于缺陷；测试人员考虑易用性认为必须修改。其实如果建立合理的缺陷奖罚制度，这些都可以避免。比如内部测试阶段，发现缺陷不作为开发人员的考核依据；而客户验收阶段的缺陷则严重影响测试和开发的考核成绩。这样开发人员对待缺陷的态度会比较积极，有时还会帮助测试人员发现缺陷。根据开发人员修改解决缺陷的数量和难度，在考核中适当加分，会使开发人员乐于修改缺陷，甚至是不属于自己开发范围内的缺陷。除此之外，当项目到达一定阶段，可以组织所有成员一起去发现和记录缺陷，并奖励发现缺陷数量最多的人。调动大家的积极性，养成发现并记录缺陷的习惯。
单字节，如A；双字节，AA、我我；特殊字符/‘。‘；、=-等；保留字，如com；文件格式为8.3格式的；文件名格式为非8.3格式的；/,,*等九个特殊字符
特殊字符，如10个*或￥；英文字母，如ABCDefghik；小于十个字符，如123；大于十个字符，如11111111111；数字和其他混合，如123AAAAAAA；空字符；保留字符
一、评审前需要做哪些准备工作
①需求评审结束后，就可以着手把需求拆分为功能点。
②把功能点再分解为具体的测试用例。
③用例写完后，自己先做好自检，自检中，针对有疑问的点罗列出来，可事先跟产品开发讨论，确定结果后完善用例，仍有疑问的可先做标记，评审会上抛出一起讨论。
二、用例评审参加人员
主要是产品、开发（客户端和后端）、测试、项目负责人、运营。
对于敏捷开发项目，建议控制在半小时以内。
四、用例评审的形式
1、对照测试用例，从上而下，从左到右，逐条念。
2、先对功能复杂，优先级高，疑问多的用例进行评审，再评审功能简单，优先级低的功能点。
五、正式评审
1、评审要按用例的优先级，功能的复杂程度进行；
2、评审过程中尽量做到，思路清晰，用最简洁的语言阐述每一个功能点；
3、超过5分钟无法确定结果的问题留作会后讨论跟进。
六、评审结束后需要做些什么事
②会上未确定的内容，会后继续跟进，直到确定结果。
这个总结是给自己整个用例评审工作总结，同时需同步给项目组其他成员，做好信息共享
通常，不管是开发产品还是做具体的项目，都会发生耽误进度的情况。
比较好的做法是按照下面的步骤逐步来完成和改进工作：
△因此，面对这种情况，测试负责人要做的就是带领测试小组充分利用所有资源来保证质量。
（2）在实际工作中和开发人员共同配合，逐步改进工作。只有整个团队的软件开发能力提高了，才能从根源上解决问题。
△因此，测试负责人要带领团队和开发小组共同寻找适合自己的开发模式，从而使项目规划的更加合理，进而按照预定计划来开展测试工作。总之，在任何情况下，测试负责人都不应该抱怨。只有积极的面对问题，才能更好的解决问题。
css选择器定位：根据标签的层级关系进行定位
class单个属性定位：self.driver.find_element_by_css_selector(’.table-dragColumns’).click()#用单个属性来定位前面加个（.）
直接包含空格的css定位神器：
self.driver.find_element_by_css_selector(‘class="dtb-style-1table-dragColumns’).click()#包含整个类
延时等待分为三种，分别是：硬性等待、隐式等待、显示等待
1、硬性等待：Thread.sleep(longmillis)
硬性等待，线程休眠，强制等待
Thread.sleep(longmillis)
使用场景：页面切换时
2、隐式等待：TimeOuts--implicitlyWait
设置方式
driver.manage().timeouts().implicitlyWait(longtime,TimeUnit.SECONDS);
优点：相对灵活
缺点：设置是针对全局的，在WebDriver实例的整个生命周期有效，但是并不是所有的元素都需要等待
3、显示等待（智能等待）：WebDriverWait
显示等待通常是我们自定义一段代码，用来等待某个条件发生以后，再继续执行后续的代码（如找到元素、元素可点击、元素已显示）
可以自己指定某个元素需要等待，在有必要进行等待的时候进行等待
默认是0.5秒轮循一次，在dom中查找一次元素
我们可以自己设置期望条件
注意：在自己设置期望条件时，return时不能直接点击该元素，因为返回是webElement时只能说明该元素在dom中间存在，但是能不能点击是不确定的
因为元素能被点击具备三个条件：1、在dom中间存在；2、已经显示在页面上（isDisplayed）；3、有效性（可以进行click操作）
覆盖率在70%左右。
主要跑的是业务流，所以跑一次需要半个小时左右
分层自动化测试（经典图如下）分三层，最底层是单元层，中间是服务层，顶部是UI层，而这三层越底层做自动化测试，实现成本越低，越容易看见成效。
手动的方式创建数据，通过软件的某个具体的业务流程创建数据
这种方式适合于需要的测试数据少，也是平时测试中使用最多的方式。
修改数据库
修改浏览器
有时候一个网页需要显示100个商品信息，但是如果不断的创建100个商品信息则不太现实，测试时也只是想看显示100个商品时页面显示是否正常，这个时候可以通过修改网页html代码进行实现。
程序自动生成，通过编写程序实现商品数据的批量生成
本地数据库的导入功能
如果已有一批数据，只是这个数据是存储在本地，而不是数据库中，则可以通过导入数据的方式，实现数据的创建。
线上数据导入到测试环境
在Android端，appium基于WebDriver协议，利用Bootstrap.jar，最后通过调用UiAutomator的命令，实现App的自动化测试。
UiAutomator测试框架是AndroidSDK自带的AppUI自动化测试Java库。
另外由于UiAutomator对H5的支持有限，appium引入了chromedriver以及safaridriver等来实现基于H5的自动化。
1)client端也就是我们testscript是我们的webdriver测试脚本。
2)中间是起的Appium的服务，Appium在服务端起了一个Server（4723端口），跟seleniumWebdriver测试框架类似，Appium持标准的WebDriverJSONWireProtocol。在这里提供它提供了一套REST的接口,AppiumServer接收webdriverclient标准rest请求，解析请求内容，调用对应的框架响应操作。
3)appiumserver会把请求转发给中间件Bootstrap.jar，它是用java写的，安装在手机上.Bootstrap监听4724端口并接收appium的命令，最终通过调用UiAutomator的命令来实现。
4)最后Bootstrap将执行的结果返回给appiumserver。
5)appiumserver再将结果返回给appiumclient。
在IOS端，appium同样使WebDriver的一套协议。
与Android端测试框架不同的是，appiumios封装了apple的Instruments框架，主要用了Instrument里的UIAutomation（Apple的自动化测试框架），然后在设备中注入bootstrap.js进行监听。
①client端依然是testscript是我们的webdriver测试脚本。
②中间是起的Appium的服务，Appium在服务端起了一个Server（4723端口），跟seleniumWebdriver测试框架类似，Appium持标准的WebDriverJSONWireProtocol。在这里提供它提供了一套REST的接口,AppiumServer接收webdriverclient标准rest请求，解析请求内容，调用对应的框架响应操作。
③appiumserver调用instruments.js启动一个socketserver，同时分出一个子进程运instruments.app，将bootstrap.js（一个UIAutomation脚本）注入到device于和外界进行交互
④最后Bootstrap.js将执行的结果返回给appiumserver
⑤appiumserver再将结果返回给appiumclient。
所以我们可以看到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等。
: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(pid1952)
Eventsinjected:4486
//[calendar_time:2019-05-2211:41:10.905system_uptime:131091]//Sendingevent#4400
第一步：首先我们需要对要拦截的接口进行断点调试
第二步：然后我们就正常的请求接口，这个时候charles断点的原因，会导致请求被等待中
第三步：这个时候我们就可以修改返回结果了
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在项目中的使用：
1、下载安装好Charles
2、设置Charles上的代理
打开Charles->Proxy->ProxySetting，设置代理端口为8888，并勾选EnabletransparentHTTPproxying
3、设置iphone上的代理
Settings->WLAN选择同一网络，
设置server：PC的ip地址port：8888
4、PC端安装Charles证书
Charles->Help->SSLProxying->InstallCharlesRootCertificate下载证书
如果证书不被信任，可以点击Charles->Help->SSLProxying->SaveCharlesRootCertificate保存证书到指定文件，然后可以通过将证书导入到“受信任的根证书颁发机构du”存储区中解决该问题：
①win+r运行mmc，将证书添加到管理单元
②受信任的根证书颁发机构->证书右键导入刚才保存的Charles证书就ok了
5、iphone安装Charles证书
①构建一个maven工程
②构建完成后把war包发布到远程tomcat，并执行脚本重启tomcat
③需要修改脚本为可执行脚本，否则jenkins权限不够执行shell脚本
1．接口选择：一般情况下，接口主要有两类，即查询接口和数据保存接口。保存接口主要是将传入的参数先做数据校验，数据校验通过后将其保存到表中。
2．用jmeter进行多接口测试。先添加一个名称为InterfaceTest的线程组。
3．在线程组上添加一个Http请求。
4．对Http请求的服务器的IP地址、传输编码等进行配置。
7．添加监听器，察看结果树和聚合报告。
8．运行，查看结果。
publicstaticint[]buddleSort(int[]arr){
for(inti=1;i for(intj=0;j if(arr[j] inttemp=arr[j]; arr[j]=arr[j+1]; arr[j+1]=temp; } returnarr; Defcount_digit(number): Returnlen(str(number)) DefcountThree(digit): Ifnotisinstance(digit,int): RaiseTypeError(‘numberisnotint’) #digit=len(str(number)) If(digit<=0): Return0 If(digit==1): Return10*countThree(digit-1)+10**(digit-1) Print(countThree(count_dight(9999))) defqiuckSort(list): Iflen(list)<2: Returnlist Mid=list[0] Left=[iforiinlist[1:]ifi<=mid] Right=[iforinlist[1:]ifimid] finallyList=qiuckSort(left)+[mid]+qiuckSort(right) ReturnfinallyList Array=[3,0,832,23,35,5,5,6,45,9,87,897] Print(qiuckSort(array)[-4:]) publicstaticvoidmain(Stringargs[]){ Stringtest=test("sahsjkshabshwkiixab",""); System.out.println(test); publicstaticStringtest(Stringstr,Stringtargetstr){ StringBufferbf=newStringBuffer(); if(str==null||targetStr==null){ returnbf.toString(); if(str.length()>=targetstr.length()){ for(inti=0;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; bf.append(str); }}} 本程序写完后，运行测试过程中，遇到一个有意思的问题，当输入字符串某个为null的时候，程序进入死循环，一直没执行完，后发现是因为判断条件if(str==null||targetStr==null)不生效导致； 为什么不生效呢？？？？ 因为搞混了“”和null是有区别的， 1.null表示这个字符串不指向任何的东西，如果这时候你调用它的方法，那么就会出现空指针异常。 2.""表示它指向一个长度为0的字符串，这时候调用它的方法是安全的。 3.null不是对象，""是对象，所以null没有分配空间，""分配了空间，例如：Stringstr1=null;str引用为空Stringstr2="";str应用一个空串 4，所以，判断一个字符串是否为空，首先就要确保他不是null，然后再判断他的长度。Stringstr=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) defStrToInt(): words=input('input:') try: word=words.replace('','') word=int(word) returnword exceptExceptionase:returne if__name__=="__main__": a=StrToInt() print(a) leftjoin（左连接）：返回包括左表中的所有记录和右表中连接字段相等的记录。rightjoin（右连接）：返回包括右表中的所有记录和左表中连接字段相等的记录。innerjoin（等值连接或者叫内连接）：只返回两个表中连接字段相等的行。fulljoin（全外连接）：返回左右表中所有的记录和左右表中连接字段相等的记录。 1、内联接（典型的联接运算，使用像=或<>之类的比较运算符）。包括相等联接和自然联接。内联接使用比较运算符根据每个表共有的列的值匹配两个表中的行。例如，检索students和courses表中学生标识号相同的所有行。2、外联接。外联接可以是左向外联接、右向外联接或完整外部联接。在FROM子句中指定外联接时，可以由下列几组关键字中的一组指定： 2）RIGHTJOIN或RIGHTOUTERJOIN右向外联接是左向外联接的反向联接。将返回右表的所有行。如果右表的某行在左表中没有匹配行，则将为左表返回空值。3）FULLJOIN或FULLOUTERJOIN完整外部联接返回左表和右表中的所有行。当某行在另一个表中没有匹配行时，则另一个表的选择列表列包含空值。如果表之间有匹配行，则整个结果集行包含基表的数据值。3、交叉联接交叉联接返回左表中的所有行，左表中的每一行与右表中的所有行组合。交叉联接也称作笛卡尔积。FROM子句中的表或视图可通过内联接或完整外部联接按任意顺序指定；但是，用左或右向外联接指定表或视图时，表或视图的顺序很重要。有关使用左或右向外联接排列表的更多信息，请参见使用外联接。