1）设计测试用例时，依然都是依据边界值分析法、等价类划分等；
2）多数采用黑盒的测试方法，来验证业务功能是否得到正确的应用；
3）需要检查界面的布局、风格和按钮等是否简洁美观、是否统一等；
5）测试应用系统的稳定性等。
不同点：
●对于多个端都进行操作时，确保数据库操作无误，且每个端可以及时看到数据的更新
push消息针对不同的用户群体：
全部用户部分用户特定用户
1、push消息能否按照正确的业务流程进行推送
2、push消息针对特定的用户时，后台检测是否推送正确给特定用户
3、当用户离线时，能否接收到push消息
4、当用户离线3天时，能否接收到最早之前的消息
5、当用户选择不接收消息推送时，那么是否还有消息推送
1.缓存垃圾过多
2.运行的程序过多,导致内存不足
3.应用版本兼容问题
如果应用版本太低，会导致不兼容，造成闪退。此外，有些新版本在调试中，也会造成应用闪退。
解决方法：如果是版本太旧，更新为新版本即可；如果是新版本闪退，可能是应用在改版调试，可卸载后安装旧版。
4..检查APP中访问网络的地方，组件中的ImageView是否可以正常的下载并显示到app页面上。
5.检查APP的sdk和手机的系统是否兼容。
6.在一些特定情况下的闪退,比如播放视频,在Android5.0升级到Android6.0的时候,有些系统API老版本有,新版本没有,到时回去对象的时候失败,报空,系统就会出现闪退问题.
1、HTTP超文本传输协议
2、HTTPS安全超文本传输协议
3、FTP文件传输协议(Xshell的文件拖拽)
4、TCP网络控制协议
5、IP互联网协议
6、UDP用户数据协议
1、Get向特定资源发出请求（请求指定页面信息，并返回实体主体）2、Post向指定资源提交数据进行处理请求（提交表单、上传文件），又可能导致新的资源的建立或原有资源的修改3、Put向指定资源位置上上传其最新内容（从客户端向服务器传送的数据取代指定文档的内容）4、Head与服务器索与get请求一致的相应，响应体不会返回，获取包含在小消息头中的原信息（与get请求类似，返回的响应中没有具体内容，用于获取报头）5、Delete请求服务器删除request-URL所标示的资源（请求服务器删除页面）6、opions返回服务器针对特定资源所支持的HTML请求方法或web服务器发送测试服务器功能（允许客户端查看服务器性能）
不是，接口测试和app测试的活动有部分重复的内容，主要集中在业务功能测试方面。除此之外，针对各自特性的测试都不一样，需要分别进行有针对性的测试，才能确保整个产品的质量。
①仔细阅读“接口说明/设计文档”。将每个接口当成被测功能点来理解。接口也有功能、性能、安全等测试。
②设计接口测试方案，比如确定要使用的接口测试工具。
④将设计好的接口测试用例转移到接口测试工具中。
⑤在工具中实施接口测试。
⑥收集测试结果（如有缺陷也要提交）,提交测试报告。
一、功能不同
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安全性较高。
测试用例：同时对输入、业务逻辑、输出进行考虑时，肯定会存在用例的冗余，在最大限度覆盖业务功能和规则下，选取最优用例集合。同时，需要考虑异常数据和场景。
在没有特殊要求的情况下，至少需要考虑以下内容：1）、业务功能覆盖是否完整2）、业务规则覆盖是否完整3）、参数验证是否达到要求（边界、业务规则）4）、接口异常场景覆盖是否完整
如果接口需求还包含性能或者安全要求，还要对接口进行性能测试和安全测试，就需要考虑：性能指标是否满足要求、安全指标是否满足要求。
负载测试-核实在保持配置不变的情况下，测试对象在不同操作条件（如不同用户数、事务数等）下性能行为的可接受性。
强度测试-核实测试对象性能行为在异常或极端条件（如资源减少或用户数过多）之下的可接受性。
容量测试-核实测试用户同时使用软件程序的最大数量。
1、确定范围，任何产品的需求无非两种类型：功能需求和非功能需求
2、确定测试点，也就是确定测试具体内容
3、测试执行准备和场景设计时，也就是设计测试用例和测试场景时要充分考虑系统的技术特点。
二、性能测试场景获取
三、性能测试数据确定
四、性能测试用例设计
五、性能测试环境准备与搭建
1)查看系统日志，如果日志记录的全面，很容易通过日志发现问题。比如，系统宕机时，系统日志打印了某方法执行是抛出outofmemory的错误，很快定位到导致内存溢出的问题在哪里。
2)利用性能监控工具，比如：linux系统环境下通过nmon来监控系统性能。
3)设计合理的性能测试场景，好的测试场景能更加快速的发现瓶颈。
4)了解系统参数配置，可以进行后期的性能调优
2）负载测试负载测试是一种通过增加负载来评估组件或系统的性能的测试方法。例如：通过增加并发用户数和（或）事务数量来测量组件或系统能够承受的负载。负载测试和性能测试的主要区别在于负载测试时，系统负载是逐渐增加的，而不是一步到位，负载测试需要观察系统在各种不同的负载情况下是否都能够正常工作。
数字、字符串、列表、元组、字典、集合这六种基本数据类型。浮点型、复数类型、布尔型(布尔型就是只有两个值的整型)、这几种数字类型。列表、元组、字符串都是序列。”
首先，确认需求
其次，分析测试需求，并制定测试计划，确定测试范围、使用测试技术以及对测试进行人员安排等等
根据用例进行测试
若发现问题，则将问题提交到相应的缺陷管理工具，指派到问题负责人。
问题修复完毕，对修复的问题进行回归验证，并验证是否有引发其他问题
最后编写测试报告
测试用例：为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期望结果的一个特定的集合。
测试脚本是为了进行自动化测试而编写的脚本。
两者的关系：测试脚本的编写必须对应相应的测试用例
一条Bug记录最基本应包含：
2-开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包括是否有遗漏或者双方理解不同的地方。测试人员完成测试计划文档，测试计划包括的内容上面有描述。
3-测试人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档，详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。
4-测试用例完成后，测试和开发需要进行评审。
5-测试人员搭建环境
6-开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测试，发现bug后提交给bugzilla。
7-开发提交第二个版本，包括bugfix以及增加了部分功能，测试人员进行测试。
8-重复上面的工作，一般是3-4个版本后bug数量减少，达到出货的要求。
9-如果有客户反馈的问题，需要测试人员协助重现以及回归测试。
按测试流程划分
我们的项目测试流程一般需要，制定测试计划，编写测试用例，执行测试用例，输出测试报告等工作，我们可以根据流程中的各个阶段来进行划分。
移动端应用：我们需要依据自身APP用户群体的特征以及使用习惯，去做相应的兼容。比如用户群体如果大多是老人的话，可以考虑大字体的适配。比如针对旅游人士，可以考虑过程中网络的状况。如果拥有大量海外用户，可以考虑多币种、多语言、多度量、时区问题。还包括硬件，软件，技术，网络，iOSAPP兼容性（屏幕分辨率，屏幕尺寸（含异形），操作系统版本，开发语言，第三方库或SDK，安装、升级）AndroidAPP兼容性（屏幕分辨率，屏幕尺寸（含异形），Android版本，系统版本，处理器架构（arm、x86），开发，语言（Java、koltin、混合），第三方库或SDK，安装，升级，H5兼容性，CSS样式兼容（一些属性的浏览器标示前缀没有添加，导致默认浏览器不认识这个属性，所以样式错乱。有些布局不灵活，样式边界处理不好，导致宽窄屏显示异常），JS兼容（主要是浏览器或者系统版本，新的jsapi不支持，但是没有做降级处理））
web端应用：操作系统、浏览器、分辨率和网速方面兼容性测试；
内部二维码下载
白名单用户方式
国内小市场先上，国外用GooglePlay的β版，默认开放5%
后台控制的方式，开放给一定比例的用户
1.APP有新版本时，打开APP是否有更新提示。
2.当版本为非强制升级版时，用户可以取消更新，老版本能正常使用。用户在下次启动app时，仍能出现更新提示。
3.当版本为强制升级版时，当给出强制更新后用户没有做更新时，退出APP。下次启动app时，仍出现强制升级提示。
4.不删除APP直接更新，检查是否能正常更新，更新后能否正常工作。
5.删除老的APP，重新下载APP，能不能正常工作。
6.不删除APP直接更新，检查更新后的APP和新安装的APP提供的功能一样。
7.检查在线跨版本升级能否成功，版本过老是否提示用户重装。
8.更新成功后，用户数据有没有丢失，各个配置项是否还原。
入口图标的标识度
进入和退出操作简易度
取景框大小
拍景和自拍切换
视频的像素限制
视频的时长限制
发送的进度提示
操作是否卡顿
不同机型分辨率
不同系统版本
不同网络情况
不同流量情况
一个客户端，三百个用户
三百个客户端，三百个用户
运用一些测试管理工具如TestDirector进行管理也是较有效的方法，同时要注意在TestDirector中对BUG有准确的描述。
在团队中建立测试人员与开发人员良好沟通中注意以下几点：
一真诚、二是团队精神、三是在专业上有共同语言、四是要对事不对人，工作至上
当然也可以通过直接指出一些小问题，而不是进入BUGTrackingSystem来增加对方的好感。
我之前做过的主要是功能测试，性能测试，web自动化测试、app测试、接口测试、也有用过charles进行一些关于弱网测试，修改参数值压力测试等等，也使用Jmeter做过一些性能方面的测试，比如说数据库的压测，性能测试，脚本录制等，也用过postman进行接口测试。我对于缺陷管理工具比如禅道，版本控制器git等能够熟悉使用。也对数据库、linux、Fiddler这些应用也比较熟悉
单字节，如A；双字节，AA、我我；特殊字符/‘。‘；、=-等；保留字，如com；文件格式为8.3格式的；文件名格式为非8.3格式的；/,,*等九个特殊字符。
特殊字符，如10个*或￥；英文字母，如ABCDefghik；小于十个字符，如123；大于十个字符，如11111111111；数字和其他混合，如123AAAAAAA；空字符；保留字符
通过class属性定位通过id属性定位通过name属性定位通过link属性定位通过partialLink定位通过标签tagname定位通过css定位通过xapth定位
主要跑的是业务流，所以跑一次需要半个小时左右
金字塔结构，最底层UnitTest，往上接口API/集成起来的service，最上面UI自动化
一个是根据被测系统需求的分析，针对正常业务，异常情况，边界情况等来构建完整的数据，又称为“造”数据。
第二种方式就是利用现有系统，这适合已有类似系统，测试是针对升级或者增加功能的产品化的系统。
还有一种方式就是将现有非电子化的业务数据录入到系统中，在验证业务的同时也完成了测试数据的积累。
1.下载jenkins安装包并安装本例使用jenkins-2.86的windows版本
2.安装常用插件如PUBLISHOVERSSH、SubversionPlug-in、CredentialsBindingPlugin、MavenIntegrationplugin
3.配置svn账号，用于拉取源码
4.配置maven、JDK
5.配置SSH服务器
6.构建一个maven工程
7.构建完成后把war包发布到远程tomcat，并执行脚本重启tomcat
8.需要修改脚本为可执行脚本，否则jenkins权限不够执行shell脚本