APP测试

 

仅仅从功能测试的层面上来讲的话，在流程和功能测试上是没有区别的。那么区别在哪里呢？

我个人觉得就是由于载体不一样，所以系统测试和一些细节可能会不一样。

那么我们就要先来了解，web和app的区别。

web项目，一般都是b/s架构，基于浏览器的，而app则是c/s的，必须要有客户端。那么在系统测试测试的时候就会产生区别了。

系统架构

来看的话，web测试只要更新了服务器端，客户端就会同步会更新。而且客户端是可以保证每一个用户的客户端完全一致的。但是app端是不能够保证完全一致的，除非用户更新客户端。如果是app下修改了服务端，意味着客户端用户所使用的核心版本都需要进行回归测试一遍。

性能方面

web页面可能只会关注响应时间，而app则还需要关心流量、电量、CPU、GPU、Memory这些了。至于服务端的性能是没区别，这里就不谈。

兼容方面

web是基于浏览器的，所以更倾向于浏览器和电脑硬件，电脑系统的方向的兼容，不过一般还是以浏览器的为主。而浏览器的兼容则是一般是选择不同的浏览器内核进行测试（IE、chrome、Firefox）。app的测试则必须依赖phone或者是pad，不仅要看分辨率，屏幕尺寸，还要看设备系统。系统总的来说也就分为Android和iOS，不过国内的Android的定制系统太多，也是比较容易出现问题的。一般app的兼容测试三种方法，云测试，请团队测试，真机测试。云测试咱们稍后再聊，这里说说真机的选择。首先要选择主流的机型，其次要选择不同的分辨率，尺寸，然后就是不同的操作系统。

相比较web测试，app更是多了一些专项测试：

健壮性测试：

　　一些异常场景的考虑以及弱网络测试。这里的异常场景就是中断，来电，短信，关机，重启等。

　　而弱网测试是app测试中必须执行的一项测试。包含弱网和网络切换测试。需要测试弱网所造成的用户体验，重点要考虑回退和刷新是否会造成二次提交。需要测试丢包，延时的处理机制。避免用户的流失。这些在前面的弱网测试那篇已经讲过，这里不再讲了。

安装、卸载、更新：

　　web测试是基于浏览器的所以不必考虑这些。而app是客户端的，则必须测试安装、更新、卸载。除了常规的安装、更新、卸载还要考虑到异常场景。包括安装时的中断、弱网、安装后删除安装文件，更新的强制更新与非强制更新、增量包更新、断点续传、弱网，卸载后删除app相关的文件等等。这里讲起来的话太多了，如果有疑问的同学可以评论或者给我留言。

界面操作：

　　现在app产品的用户都是使用的触摸屏手机，所以测试的时候还要注意手势，横竖屏切换，多点触控，事件触发区域等测试。

剩下的可能就是使用的工具的不同吧。

就自动化来讲，web大多用的selenium、webdriver，而app则是appium。

性能使用的工具web则是LR，app使用Jmeter要多一点。

这里只是讲的一个大致的区别。有些东西我到现在也没了解到。所以也只能写成这样了。

总的来说区别并没有多大。测试的产品千变万化，测试的思想是不变的。工具即使不同，只要理解原理做起来并没有什么难度。

 

 

 

详细列明：

　　1.2测试周期

　　测试周期可按项目的开发周期来确定测试时间，一般测试时间为两三周（即 15个工作日），

　　根据项目情况以及版本质量可适当缩短或延长测试时间。正式测试前先向主管确认项目排期。

　　1.3测试资源

　　测试任务开始前，检查各项测试资源。

　　--产品功能需求文档；

　　--产品原型图；

　　--产品效果图；

　　--行为统计分析定义文档；

　　--测试设备（    ios3.1.3-ios5.0.1；  Android1.6-Android4.0； Winphone7.1及以上；       Symbian

　　v3/v5/Nokia Belle等）；

　　--其他。

　　1.4日报及产品上线报告

　　1）测试人员每天需对所测项目发送测试日报。

　　2）测试日报所包含的内容为：

　　--对当前测试版本质量进行分级；

　　--对较严重的问题进行例举，提示开发人员优先修改；

　　--对版本的整体情况进行评估。

　　3）产品上线前，测试人员发送产品上线报告。

　　4）上线报告所包含的内容为：

　　---对当前版本质量进行分级；

　　---附上测试报告（功能测试报告、兼容性测试报告、性能测试报告以及 app可用性能标准结

　　果）；

　　--总结上线版本的基本情况。若有遗留问题必须列出并记录解决方案。

　　2.1安全测试

　　2.1.1软件权限

　　1）扣费风险：包括发送短信、拨打电话、连接网络等

　　2）隐私泄露风险：包括访问手机信息、访问联系人信息等

　　3）对App的输入有效性校验、认证、授权、敏感数据存储、数据加密等方面进行检测

　　4）限制/允许使用手机功能接人互联网

　　5）限制/允许使用手机发送接受信息功能

　　6）限制/允许应用程序来注册自动启动应用程序

　　7）限制或使用本地连接

　　8）限制/允许使用手机拍照或录音

　　9）限制/允许使用手机读取用户数据

　　10)限制/允许使用手机写人用户数据

　　11)检测App的用户授权级别、数据泄漏、非法授权访问等

　　2.1.2安装与卸载安全性

　　1）应用程序应能正确安装到设备驱动程序上

　　2）能够在安装设备驱动程序上找到应用程序的相应图标

　　3）是否包含数字签名信息

　　4）JAD文件和  JAR包中包含的所有托管属性及其值必需是正确的

　　5）JAD文件显示的资料内容与应用程序显示的资料内容应一致

　　6）安装路径应能指定

　　7）没有用户的允许,应用程序不能预先设定自动启动

　　8）卸载是否安全,其安装进去的文件是否全部卸载

　　9）卸载用户使用过程中产生的文件是否有提示

　　10）其修改的配置信息是否复原

　　11）卸载是否影响其他软件的功能

　　12）卸载应该移除所有的文件

　　2.1.3数据安全性

　　1）当将密码或其他的敏感数据输人到应用程序时,其不会被储存在设备中,同时密码也不会

　　被解码

　　2）输人的密码将不以明文形式进行显示

　　3）密码,信用卡明细,或其他的敏感数据将不被储存在它们预输人的位置上

　　4）不同的应用程序的个人身份证或密码长度必需至少在 4一  8个数字长度之间

　　5）当应用程序处理信用卡明细,或其他的敏感数据时,不以明文形式将数据写到其它单独的

　　文件或者临时文件中。以 6）防止应用程序异常终止而又没有侧除它的临时文件,文件可能

　　遭受人侵者的袭击,然后读取这些数据信息。

　　7）当将敏感数据输人到应用程序时,其不会被储存在设备中

　　8）备份应该加密,恢复数据应考虑恢复过程的异常?通讯中断等,数据恢复后再使用前应该

　　经过校验

　　9）应用程序应考虑系统或者虚拟机器产生的用户提示信息或安全替告

　　10）应用程序不能忽略系统或者虚拟机器产生的用户提示信息或安全警告,更不能在安全警

　　告显示前,，利用显示误导信息欺骗用户，应用程序不应该模拟进行安全警告误导用户

　　11）在数据删除之前，应用程序应当通知用户或者应用程序提供一个“取消”命令的操作

　　12）“取消”命令操作能够按照设计要求实现其功能

　　13）应用程序应当能够处理当不允许应用软件连接到个人信息管理的情况

　　14）当进行读或写用户信息操作时,应用程序将会向用户发送一个操作错误的提示信息

　　15）在没有用户明确许可的前提下不损坏侧除个人信息管理应用程序中的任何内容Μ

　　16）应用程序读和写数据正确。

　　17）应用程序应当有异常保护。

　　18）如果数据库中重要的数据正要被重写,应及时告知用户

　　19）能合理地处理出现的错误

　　20）意外情况下应提示用户

　　2.1.4通讯安全性

　　1）在运行其软件过程中,如果有来电、SMS、EMS、MMS、蓝牙、红外等通讯或充电时,是

　　否能暂停程序，优先处理通信,并在处理完毕后能正常恢复软件,继续其原来的功能

　　2）当创立连接时,应用程序能够处理因为网络连接中断,进而告诉用户连接中断的情况

　　3）应能处理通讯延时或中断

　　4）应用程序将保持工作到通讯超时,进而发送给用户一个错误信息指示有连接错误

　　5）应能处理网络异常和及时将异常情况通报用户

　　6）应用程序关闭或网络连接不再使用时应及时关闭)断开

　　7) HTTP、HTTPS覆盖测试

　　--App和后台服务一般都是通过  HTTP来交互的，验证  HTTP环境下是否正常；

　　--公共免费网络环境中（如：麦当劳、星巴克等）都要输入用户名和密码，通过  SSL认证

　　来访问网络，需要对使用 HTTP Client的  library异常作捕获处理。

　　2.1.5人机接口安全性

　　1）返回菜单总保持可用

　　2）命令有优先权顺序

　　3）声音的设置不影响应用程序的功能

　　4）应用程序必需利用目标设备适用的全屏尺寸来显示上述内容

　　5）应用程序必需能够处理不可预知的用户操作,例如错误的操作和同时按下多个键

　　2.2安装、卸载测试

　　验证 App是否能正确安装、运行、卸载

　　2.2.1安装

　　1）软件在不同操作系统（Palm OS、Symbian、Linux、Android、iOS、Black Berry OS 6.0、

　　Windows Phone 7）下安装是否正常。

　　2）软件安装后的是否能够正常运行，安装后的文件夹及文件是否写到了指定的目录里。

　　3）软件安装各个选项的组合是否符合概要设计说明

　　4)）软件安装向导的 UI测试

　　5）软件安装过程是否可以取消，点击取消后，写入的文件是否如概要设计说明处理

　　6）软件安装过程中意外情况的处理是否符合需求（如死机，重启，断电）

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

　　8）安装后没有生成多余的目录结构和文件

　　9）对于需要通过网络验证之类的安装，在断网情况下尝试一下

　　10）还需要对安装手册进行测试，依照安装手册是否能顺利安装

　　2.2.2卸载

　　1）直接删除安装文件夹卸载是否有提示信息。

　　2）测试系统直接卸载程序是否有提示信息。

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

　　4）卸载过程中出现的意外情况的测试（如死机、断电、重启）。

　　5）卸载是否支持取消功能，单击取消后软件卸载的情况。

　　6）系统直接卸载 UI测试，是否有卸载状态进度条提示。

　　2.3 UI测试

　　测试用户界面(如菜单、对话框、窗口和其它可规控件)布局、风格是否满足客户要求、文字

　　是否正确、页面是否美观、文字、图片组合是否完美、操作是否友好等。

　　UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏觅功能。

　　确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。

　　2.3.1导航测试

　　1）按钮、对话框、列表和窗口等；或在不同的连接页面之间需要导航

　　2）是否易于导航，导航是否直观

　　3）是否需要搜索引擎

　　4）导航帮助是否准确直观

　　5）导航与页面结构、菜单、连接页面的风格是否一致

　　2.3.2图形测试

　　1）横向比较。各控件操作方式统一

　　2）自适应界面设计，内容根据窗口大小自适应

　　3）页面标签风格是否统一

　　4）页面是否美观

　　5）页面的图片应有其实际意义而要求整体有序美观

　　6）图片质量要高且图片尺寸在设计符合要求的情况下应尽量小

　　7）界面整体使用的颜色不宜过多

　　2.3.3内容测试

　　1）输入框说明文字的内容与系统功能是否一致

　　2）文字长度是否加以限制

　　3）文字内容是否表意不明

　　4）是否有错别字

　　5）信息是否为中文显示

　　6）是否有敏感性词汇、关键词

　　7）是否有敏感性图片，如：涉及版权、专利、隐私等图片

　　2.4功能测试

　　根据软件说明或用户需求验证  App的各个功能实现，采用如下方法实现并评估功能测试过

　　程：

　　1)采用时间、地点、对象、行为和背景五元素或业务分析等方法分析、提炼 App的用户使用

　　场景，对比说明或需求，整理出内在、外在及非功能直接相关的需求，构建测试点，并明确

　　测试标准，若用户需求中无明确标准遵循，则需要参考行业或相关国际标准或准则。

　　2)根据被测功能点的特性列丼出相应类型的测试用例对其进行覆盖，如；涉及输入的地方需

　　要考虑等价、边界、负面、异常或非法、场景回滚、关联测试等测试类型对其进行覆盖。

　　3)在测试实现的各个阶段跟踪测试实现与需求输入的覆盖情况，及时修正业务或需求理解错

　　误。

　　2.4.1运行

　　1）App安装完成后的试运行，可正常打开软件。

　　2）App打开测试，是否有加载状态进度提示。

　　3）App打开速度测试，速度是否可观。

　　4）App页面间的切换是否流畅，逻辑是否正确

　　5）注册

　　--同表单编辑页面

　　--用户名密码长度

　　--注册后的提示页面

　　--前台注册页面和后台的管理页面数据是否一致

　　--注册后，在后台管理中页面提示

　　6）登录

　　--使用合法的用户登录系统。

　　--系统是否允许多次非法的登陆，是否有次数限制。

　　--使用已经登陆的账号登陆系统是否正确处理。

　　--使用禁用的账号登陆系统是否正确处理。

　　--用户名、口令（密码）错误或漏填时能否登陆。

　　--删除或修改后的用户，原用户登陆。

　　--不输入用户口令和用户、重复点（确定或取消按钮）是否允许登陆。

　　--登陆后，页面中登陆信息。

　　--页面中有注销按钮。

　　--登陆超时的处理。

　　7）注销

　　--注销原模块，新的模块系统能否正确处理。

　　--终止注销能否返回原模块，原用户。

　　--注销原用户，新用户系统能否正确处理。

　　--使用错误的账号、口令、无权限的被禁用的账号进行注销

　　2.4.2应用的前后台切换

　　1) APP切换到后台，再回到  app，检查是否停留在上一次操作界面。

　　2)  APP切换到后台，再回到  app，检查功能及应用状态是否正常，IOS4和   IOS5的版本的处

　　理机制有的不一样。

　　3) app切换到后台，再回到前台时，注意程序是否崩溃，功能状态是否正常，尤其是对于从

　　后台切换回前台数据有自动更新的时候。

　　4)手机锁屏解屏后进入    app注意是否会崩溃，功能状态是否正常，尤其是对于从后台切换

　　回前台数据有自动更新的时候。

　　5)当   App使用过程中有电话进来中断后再切换到   app，功能状态是否正常

　　6)当杀掉   app进程后，再开启  app，app能否正常启动。

　　7)出现必须处理的提示框后，切换到后台，再切换回来，检查提示框是否还存在，有时候

　　会出现应用自动跳过提示框的缺陷。

　　8)对于有数据交换的页面，每个页面都必需要进行前后台切换、锁屏的测试，这种页面最

　　容易出现崩溃。

　　2.4.3免登录

　　很多应用提供免登录功能，当应用开启时自动以上一次登录的用户身份来使用app.

　　1) app有免登录功能时，需要考虑IOS版本差异。

　　2)考虑无网络情况时能否正常进入免登录状态。

　　3)切换用户登录后，要校验用户登录信息及数据内容是否相应更新，确保原用户退出。

　　4)根据MTOP的现有规则，一个帐户只允许登录一台机器。所以，需要检查一个帐户登录多

　　台手机的情况。原手机里的用户需要被踢出，给出友好提示。

　　5) app切换到后台，再切回前台的校验

　　6)切换到后台，再切换回前台的测试

　　7)密码更换后，检查有数据交换时是否进行了有效身份的校验

　　8)支持自动登录的应用在进行数据交换时，检查系统是否能自动登录成功并且数据操作无

　　误。

　　9)检查用户主动退出登录后，下次启动app，应停留在登录界面

　　2.4.4数据更新

　　根据应用的业务规则，以及数据更新量的情况，来确定最优的数据更新方案。

　　1)需要确定哪些地方需要提供手动刷新，哪些地方需要自动刷新，哪些地方需要手动+自动

　　刷新。

　　2)确定哪些地方从后台切换回前台时需要进行数据更新。

　　3)根据业务、速度及流量的合理分配，确定哪些内容需要实时更新，哪些需要定时更新。

　　4)确定数据展示部分的处理逻辑，是每次从服务端请求，还是有缓存到本地，这样才能有

　　针对性的进行相应测试。

　　5)检查有数据交换的地方，均有相应的异常处理。

　　2.4.5离线浏览

　　很多应用会支持离线浏览，即在本地客户端会缓存一部分数据供用户查看。

　　1)在无网络情况可以浏览本地数据

　　2)退出   app再开启  app时能正常浏览

　　3)切换到后台再切回前台可以正常浏览

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

　　5)在对服务端的数据有更新时会给予离线的相应提示

　　2.4.6 App更新

　　1)当客户端有新版本时，有更新提示。

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

　　时，仍能出现更新提示。

　　3)当版本为强制升级版时，当给出强制更新后用户没有做更新时，退出客户端。下次启动

　　app时，仍出现强制升级提示。

　　4)当客户端有新版本时，在本地不删除客户端的情况下，直接更新检查是否能正常更新。

　　5)当客户端有新版本时，在本地不删除客户端的情况下，检查更新后的客户端功能是否是

　　新版本。

　　6)当客户端有新版本时，在本地不删除客户端的情况下，检查资源同名文件如图片是否能

　　正常更新成最新版本。如果以上无法更新成功的，也都属于缺陷。

　　2.4.7定位、照相机服务

　　1) App有用到相机，定位服务时，需要注意系统版本差异

　　2)有用到定位服务、照相机服务的地方，需要进行前后台的切换测试，检查应用是否正常。

　　3)当定位服务没有开启时，使用定位服务，会友好性弹出是否允许设置定位提示。当确定

　　允许开启定位时，能自动跳转到定位设置中开启定位服务。

　　4)测试定位、照相机服务时，需要采用真机进行测试。

　　2.4.8时间测试

　　客户端可以自行设置手机的时区、时间，因此需要校验该设置对 app的影响。

　　--中国为东 8区，所以当手机设置的时间非东  8区时，查看需要显示时间的地方，时间是否

　　展示正确，应用功能是否正常。时间一般需要根据服务器时间再转换成客户端对应的时区来

　　展示，这样的用户体验比较好。比如发表一篇微博在服务端记录的是  10：00，此时，华盛

　　顿时间为 22：00，客户端去浏览时，如果设置的是华盛顿时间,则显示的发表时间即为  22:00,

　　当时间设回东 8区时间时，再查看则显示为  10：00。

　　2.4.9 PUSH测试

　　1)检查   push消息是否按照指定的业务规则发送

　　2)检查不接受推送消息时，检查用户不会再接收到    push.

　　3)如果用户设置了免打扰的时间段，检查在免打扰时间段内，用户接收不到   PUSH。

　　在非免打扰时间段，用户能正常收到 push。

　　4)当    push消息是针对登录用户的时候，需要检查收到的   push与用户身份是否相符，没有

　　错误地将其它人的消息推送过来。一般情况下，只对手机上最后一个登录用户进行消息推送。

　　5)测试   push时，需要采用真机进行测试。

　　2.5性能测试

　　评估App的时间和空间特性：

　　1)极限测试：在各种边界压力情况下，如电池、存储、网速等，验证App是否能正确响应。

　　--内存满时安装  App

　　--运行 App时手机断电

　　--运行 App时断掉网络

　　2)响应能力测试：测试App中的各类操作是否满足用户响应时间要求。

　　--App安装、卸载的响应时间

　　--App各类功能性操作的影响时间

　　3)压力测试：反复/长期操作下、系统资源是否占用异常。

　　--App反复进行安装卸载，查看系统资源是否正常

　　--其他功能反复进行操作，查看系统资源是否正常

　　4)性能评估：评估典型用户应用场景下，系统资源的使用情况。

　　5)Benchmark测试（基线测试）：与竞争产品的Benchmarking,产品演变对比测试等。

　　2.6交叉事件测试

　　针对智能终端应用的服务等级划分方式及实时特性所提出的测试方法。交叉测试又叫事件或

　　冲突测试，是指一个功能正在执行过程中，同时另外一个事件或操作对该过程进行干扰的测

　　试。如；App在前/后台运行状态时与来电、文件下载、音乐收听等关键运用的交互情况测

　　试等。交叉事件测试非常重要，能发现很多应用中潜在的性能问题。

　　1）多个 App同时运行是否影响正常功能

　　2）App运行时前/后台切换是否影响正常功能

　　3）App运行时拨打/接听电话

　　4）App运行时发送/接收信息

　　5）App运行时发送/收取邮件

　　6）App运行时切换网络（2G、3G、wifi）

　　7）App运行时浏览网络

　　8）App运行时使用蓝牙传送/接收数据

　　9）App运行时使用相机、计算器等手机自带设备

　　2.7兼容测试

　　主要测试内部和外部兼容性

　　1）与本地及主流App是否兼容

　　2）基于开发环境和生产环境的不同，检验在各种网络连接下(WiFi、GSM、GPRS、EDGE、WCDMA、

　　CDMA1x、CDMA2000、HSPDA等)，App的数据和运用是否正确

　　3）与各种设备是否兼容，若有跨系统支持则需要检验是否在各系统下，各种行为是否一致

　　--不同操作系统的兼容性，是否适配

　　--不同手机屏幕分辨率的兼容性

　　--不同手机品牌的兼容性

　　2.8回归测试

　　1）Bug修复后且在新版本发布后需要进行回归测试。

　　2）Bug修复后的回归测试在交付前、要进行全量用例的回归测试。

　　2.9升级、更新测试

　　新版版发布后，配合不同网络环境的自劢更新提示及下载、安装、更新、启劢、运行的验证

　　测试。

　　1）测试升级后的功能是否与需求说明一样

　　2）测试与升级模块相关的模块的功能是否与需求一致

　　3）升级安装意外情况的测试（如死机、断电、重启）

　　4）升级界面的 UI测试

　　5）不同操作系统间的升级测试

　　2.10用户体验测试

　　以主观的普通消费者的角度去感知产品或服务的舒适、有用、易用、友好亲切程度。通过

　　不同个体、独立空间和非经验的统计复用方式去有效评价产品的体验特性

　　升产品的潜在客户满意度。

　　1）是否有空数据界面设计，引导用户去执行操作。

　　2）是否滥用用户引导。

　　3）是否有不可点击的效果，如：你的按钮此时处于不可用状态，那么一定要灰掉，或者拿

　　掉按钮，否则会给用户误导

　　4）菜单层次是否太深

　　5）交互流程分支是否太多

　　6）相关的选项是否离得很远

　　7）一次是否载入太多的数据

　　8）界面中按钮可点击范围是否适中

　　9）标签页是否跟内容没有从属关系，当切换标签的时候，内容跟着切换

　　10）操作应该有主次从属关系

　　11）是否定义 Back的逻辑。涉及软硬件交互时，Back键应具体定义

　　12）是否有横屏模式的设计，应用一般需要支持横屏模式，即自适应设计

　　2.11 硬件环境测试

　　2.11.1手势操作测试

　　1）手机开锁屏对运行中的 App的影响

　　2）切换网络对运行中的 App的影响

　　3）运行中的 App前后台切换的影响

　　4）多个运行中的 App的切换

　　5）App运行时关机

　　6）App运行时重启系统

　　7）App运行时充电

　　8）App运行时kill掉进程再打开

　　2.11.2网络环境

　　手机的网络目前主要分为2G、3G、wifi。目前2G的网络相对于比较慢，测试时尤其要注意此

　　块的测试。

　　1)无网络时，执行需要网络的操作，给予友好提示，确保程序不出现crash。

　　2)内网测试时，要注意选择到外网操作时的异常情况处理。

　　3)在网络信号不好时，检查功能状态是否正常，确保不因提交数据失败而造成crash。

　　4)在网络信号不好时，检查数据是否会一直处于提交中的状态，有无超时限制。如遇数据

　　交换失败时要给予提示。

　　5)在网络信号不好时，执行操作后，在回调没有完成的情况下，退出本页面或者执行其他

　　操作的情况，有无异常情况。此问题也会经常出现程序crash。

　　2.11.3服务器宕机或出现  404、502等情况下的测试

　　后台服务牵涉到 DNS、空间服务商的情况下会影响其稳定性，如：当出现域名解析故障时，

　　你对后台 API的请求很可能就会出现  404错误，抛出异常。这时需要对异常进行正确的处

　　理，否则可能会导致程序不能正常工作。

　　2.12接口测试

　　服务端一般会提供JSON格式的数据给客户端，所以我们在服务端需要进行接口测试，确保

　　服务端提供的接口并转换的JSON内容正确，对分支、异常流有相应的返回值。此块测试可

　　以采用itest框架进行测试。最方便的是采用httpclient进行接口测试。

　　进行服务端测试时，需要开发提供一份接口文档。

　　2.13客户端数据库测试

　　1）一般的增、删、改、查测试。

　　2）当表不存在时是否能自动创建，当数据库表被删除后能否再自建，数据是否还能自动从

　　服务端中获取回来并保存。

　　3 ）在业务需要从服务端取回数据保存到客户端的时候，客户端能否将数据保存到本地。

　　4）当业务需要从客户端取数据时，检查客户端数据存在时，app数据是否能自动从客户端

　　数据中取出，还是仍然会从服务器端获取？检查客户端数据不存在时，app数据能否自动从

　　服务器端获取到并保存到客户端

　　5 ）当业务对数据进行了修改、删除后，客户端和服务端是否会有相应的更新。

 

　移动互联网的大背景下，流量测试是非常有必要的一项终端测试。我最近对android的流量测试进行了研究，目前做这块的方法有很多，方法也在不断的更新。目前很多工具携带了流量统计的功能，但是我试用后都很难获得准确的数据，目前靠谱的在方法有如下两种：

　　1、tcpdump +wireshark相结合的方法

　　2、读取该APP对应的tcp_snd/tcp_svn文件的值

　　那这种测试可以给我们带来什么？

　　1.可以让我们很清楚的知道用户在某种场景下使用我们的产品需要消耗多少流量。

　　2.流量数据分析可以指导我们去做优化。比如cgi的调用和参数设置是否合理，有些资源或者配置是否可以本地化？

　　3.流量的优化可以带来速度的优化。减少tcp数据包的个数，或者直接减少请求数都可以带来速度的优化。

　　总的来说，就一点，就是帮助用户省流量钱！！

　　tcpdump +wireshark的方法

　　第一步：tcpdump抓包

　　1.默认安装了adb以及java环境以及安装了wireshark

　　2.打开cmd,进入adb目录，测试设备的连接

    

　　3.把tcpdump拷贝的/data/local/tcpdump目录 （此步需要获取手机root权限）

    

　　这时我们可以看到root的标志符号 #，表示当前已经是root状态。利用adb shell在手机上创建目录 /data/local/tcpdumpb并执行命令：

   

　　Ｄ:\adbtools是之前我下载的tcpdump存放的位置。

　　4.修改tcpdump的权限

   

　　５..执行抓包命令

　　adb shell data/local/tcpdump -p -vv -s 0 -w /sdcard/capture.pcap

　　6.抓的包在sdcard目录下，导出包（adb pull /sdcard/capture.pcap ）

   

　　第二步：wireshark统计流量

　　wireshark打开刚刚的抓包文件，使用filte做过滤，根据wireshark显示过滤器的语法，假设APP对应的目标服务器的地址是（121.14.76.22）

   

　　Filter的语法：

　　“入流量” ip.src == 121.14.76.22

　　“出流量” ip.dst == 121.14.76.22

　　那么怎么统计这些过滤出来的包的大小呢？statistics下面有一个summary：

   

　　我们要的数据就在这里，我们要的入流量的数据就是红框里面的数值。

   

　　看/proc/uid_stat//下的tcp_rcv和tcp_snd文件

　　1.怎么获取uid

　　Adb shell进入手机之后，执行ps

   

　　Uid的值就是在63+10000=10063 ,即在要统计的APP后面的数据上加上10000.

　　2.Cat这个文件即可，单位是byte.

   

　　我测试了这两种方法在同一个场景下的区别，相差很小。

 

那么我们是怎么上线呢？

　　1，借助VS的发布把网站发布到本地；

　　2，从tfs里查看，从上次发布之后开发人员签入的历史记录，识别出需要更新哪个dll、哪个页面或view、样式、脚本等，按网站的目录结构制作一个上线的增量更新包；

　　3，如果有配置修改，复制一个线上的web.config到更新包，再加上或修改相应的配置；如果有文件压缩任务的，执行压缩；等等的修改完善增量包使之符合上线要求；

　　4，找一个合适的时机覆盖线上网站目录，如果有多台实际服务器，就执行多次；或者你们有跳板机，并且有相应的文件的同步机制；再或者先更新预上线环境，测试之后，线上直接切换站点到预上线。

　　好，一次上线完

 

 

IOS项目开发的过程中经常会用到一个测试的问题，特别是外包的项目，客户拿了那么多钱，看不到产品时时的进度说不过去，而且UI和功能是否和符合用户需求这个很重要，需要客户的认同。

　　所以就需要时时给开发中的产品打包，让客户去检查是否符合需求。

　　接入正题：

　　先讲一下大概的思路，具体的步骤往下看。

　　1.往开发者账号里面添加测试设备

　　2.创建证书和配置文件（配置文件选设备和证书的时候建议都选）

　　3.打包

　　4.安装到客户的手机

　　具体细节：

　　有些外包是用外包的开发者账号，有的是用人家公司的开发者账号，其实都无所谓了。只要打包时候的开发者账号和你添加设备的开发者账号一样就行了。

　　1.进入开发者中心，找到证书配置文件那一页

　　2.创见证书（并下载到电脑上，双击添加到登录里面）

　　3.创建APPID

　　4.添加设备（主要就是UDID，要把所有测试设备的UDID都添加进来，不然将来打包安装不上。

　　5.创建配置文件（选择证书的时候建议有多少选多少，设备也一样全部选中）

　　6.接着就是将创建好的配置文件下载到电脑上，双击配置文件，在Xcode中选择刚才创建的配置文件即可。

　　7.在选择模拟器的地方调成Generic iOS Device。

　　8.Product->Archive

　　9.Export(和正常的一样)->会有四个选项，选最后一个Save for Development Deloyment,然后next，选择刚才导入的证书，next，next，next，Export选个地方保存一下就可以了。

　　10.就是将打好包安装到手机上

详细：

　1、创建对应名称的xcode工程

　　2、若已安装了cocoaPods 但未创建仓库则直接创建cocoaPods仓库，步骤如下

　　a、 在终端中cd到 Xcode工程文件根目录? 执行pod init 生成 podfile文件，生成成功后只有一个podfile文件

　　注：若出现RuntimeError - [Xcodeproj] Unknown object version.错误，说明你的 Xcode 版本和 CocoaPods 的版本不匹配，你需要更新你的 CocoaPods ，终端输入命令gem install cocoapods --pre 等待CocoaPods更新成功后再执行pod init操作

　　b. 执行 ：open -a xcode podfile 打开生成的podfile文件（或者直接打开文件夹中的podfile文件）

　　c. 在podfile 内添加需要的第三方插件，如pod 'WechatOpenSDK'表示下载最新版本，pod 'AFNetworking', '~> 3.1.0'表示下载指定版本，更改了podfile 记得pod update

　　d .执行pod install --verbose --no-repo-update，对应的库下载完成后会生成xcworkspace文件以及其他的pod相关文件。

　　至此cocoaPods 添加完成 ，运行工程，发现Podfile 内添加的头文件无法找到，继续

　　e. 选择Target - Build Settings 搜索User Header Search Paths，并输入$(PODS_ROOT)

　　f. 打开并使用xcworkspace文件

　　若未安装cocoaPods 则先安装再创建仓库，参考：iOS安装CocoaPods详细过程

　　若安装了cocoaPods并创建了对应仓库，则添加其他开源库只需cd到工程目录下pod install或pod install --verbose --no-repo-update、pod update或pod update --verbose --no-repo-update，使用其中一种方式即可（pod install和pod update相对较慢）

　　3、设置appicon和launchImage

　　设置appicon：直接在Assets.xcassets文件中点击右键新建AppIcon并导入对应尺寸的图标

　　设置appicon

　　然后在General->App Icons And Launch Images中选择Asset下的AppIcon即可。

　　设置LaunchImage：app加载启动图有两种方式1、在Assets文件中新建Launch Image并导入对应尺寸图片（参考“设置appicon”） 2、在系统默认的LaunchScreen.storyboard中添加背景图。通常使用方式1，因为可在LaunchImage中导入各个机型不同尺寸的启动图。

 

 

 

最近无埋点技术很是流行，抽空研究了下诸葛IO，talkingData以及百分点这些业内知名公司的无埋点SDK，抽取其中重要的信息供大家参考：

　　1、首先什么是无埋点呢，其实所谓无埋点就是开发者无需再对追踪点进行埋码，而是脱离代码，只需面对应用界面圈圈点点即可追加随时生效的事件数据点。

　　无埋点的好处

　　其实无埋点并不是完全不用写代码，而是尽可能的少写代码。开发者将SDK集成到项目中，配置并初始化SDK之后，接下来就可以进行可视化操作。这个可以不依赖开发者，一些实施人员都是通过后台的配制，就达到埋点的配制，还有新增埋点改动都是很方便的实现。最后就是配制和代码，可以很灵活地扩展，动态地更新。

　　2、上面我们写道无埋点要进行可视化操，参考百分点、talkingData采用相对简单可行的办法是对当前的屏幕进行截图，截图完了以后做一些处理。做一些压缩，然后传到服务端，服务端进行展现，就把屏幕截图展现出来。屏幕截图做完了，下一步，需要在管理界面进行配置，对于可点击的组件进行配置，就需要把这些界面框起来展现给使用者。下面是截取的talkingData的可视化操作为例，为大家展示可视化埋点的流程：

　　项目嵌码之后，进入可视化链接页面，摇一摇连接设备：

　　摇一摇，连接设备

　　链接成功之后，平台获取当前界面截图：

　　平台自动获取连接设备当前界面

　　为要统计的界面元素命名事件，添加追踪点，至此埋点操作完成：

　　选择界面中的元素来追加事件

　　这里需要指出一下，无埋点只是针对一些简单的操作统计，如按钮点击的次数、时间等。如果是比较复杂的应用场景，例如支付事件，需要统计商品名称、价格、数量等，这就需要通过埋点来收集详细的参数。

 

　3、无埋点实现方式：

　　整个技术里面比较关键的一点是怎么拿到屏幕控件信息。这一块儿主要就是三个问题。第一，就是获取时机。第二，就是拿控件什么信息，什么信息是需要用到的。第三，就是比较关键的，如何生成控件的唯一ID，ID是在程序内部生成。需要保证在不同的手机上面，这些ID是一样的。还要保证每一次启动ID都是不变。

　　首先是Android：

 

 

 

　　然后，接下来我们可以看一下iOS，同样的，也是面临三个问题：

 

　　iOS无埋点的核心技术是利用苹果的runtime机制，把系统事件、点击事件的指针替换成我们自己的函数来监测用户的操作，我们在自己的函数中采集并发送需要的数据。

　　4、遇到的问题和解决办法

　　第四部分，讲一下我们在实现无埋点技术的时候，遇到了什么坑？以及采用什么方法来解决这些坑。

　　长连接断开的问题，我们之前是设计每隔5秒发送一次截图，一般不会产生断开。但是，后面做了一些优化，我们不会每隔5秒就发，这样就会导致这个链路长时间没有数据。然后，我们解决方法也是采取了业界通用的方法，发一个心跳，通过发一个心跳来保证这个链路一直是活着的。

　　第二个问题就是摇一摇遇到的问题，我们遇到的问题是这样的，你拿着手机摇一摇，什么时候连接成功呢？你得给用户一个反馈，要不用户就是一直摇下去，我们后来想的方法是，摇成功给他一个振动，振动了，用户有反馈，就知道这个连接成功了，不需要摇了。然后，就是带来另外一个问题。有时候运动当中，又会产生一些误操作，就是导致手机会振一下。这个怎么解决呢？我们就想了一下，可以通过给服务端有一个交互，管理界面里面发现有一个请求过来要连了会有一个确认的按钮，用户确认之后，SDK收到确认消息以后，我们再去振动。这样的话，既可以给用户反馈，也不会说在它误操作情况下振动。这样就不会造成误操作，也不会无缘无故地进行振动。

　　界面传输的优化，因为在整个配制过程当中，传输数据量最大的就是屏幕的截图。怎么把这个优化一下？就可以更好地提升我们的体验度，还有流畅性。图片采用jpeg格式，把图片质量选择0.6，刚好是可以看清楚的。然后，也最大限度地降低了这个图片大小。

　　然后，整个传输效率，有这样一个问题。我在当前界面，默认就是5秒传一次。我点了一下，我在当前一个列表界面，点了一下切换到详情界面。最坏的情况下就是等5秒，加上网络传输效果，管理界面就看到新的屏幕。这种体验是很差的，因为实时性太差。所以，这一块做了一个优化。尽量让它实时传过去，我们在屏幕切换的时候，主动发一次截图。这样的话，等的时间就是网络传输的时间，不用等5秒固定的时间。这一块用户体验上面就是更流畅一些。

　　有的时候屏幕界面没有任何的变化的，这个时候每隔5秒传一次没有必要的。所以，我们把屏幕截图做一个md5进行保留，传输时对比md5，当切换到下一个的时候，我们就发新的屏幕截图。这样就会减少很多不必要的屏幕的传输。然后，也会节省很多的流量。

　　控件ID重复的问题。前面说过我们的ID生成规则可以解决90%的问题，但是，有一些问题还是解决不了。生成ID重复，重复的话就会产生一个什么样的效果和问题？同样两个按纽，一个注册，对于注册定义了一个埋点，就是注册点击，用户实际操作的时候点登陆的时候也是发过来一个注册点击消息。这样就是统计不准，因为这种比较的特殊，我们采用的解决方案，通过服务端发一些特殊配制。把这些配制里面，因为这两个button里的text不一样，一个是注册，一个是登陆。我们把text信息放在ID的这个生成规则里面，最终生成两个不同的ID，也是可以解决这个问题。

　　还有一个难点通过可视化埋点的事件名称会先通过平台传到服务器，服务器再传给所有用户APP中的SDK，SDK进行判别是哪个界面的哪个事件被动态埋点了，然后进行统计，并发送数据到后台进行统计分析。判断某个界面的某个事件应该会比较棘手，在这里先做一个标记。

　　当然在写SDK的过程中肯定还有很多的坑，我会在以后的时间里一一记录下来，同时也欢迎大家提出自己的见解。

　　主要参考：以上是之前找的资料，时间久了就忘了出处，故没有粘贴作者信息，但这些信息给自己在实践的过程中提供了很多的指导，这里多谢作者，以后找到出处一定补上。

 

　　构建过程

　　项目的构建： 当我们打开一个项目，我们可以看到的是我们写的Java Code文件or Other JVM Code，资源文件，Build配置文件，但是通过run the project，我们就可以得到一个在我们的Andoid设备上可以运行的Apk，上线应用市场，还需要我们对其进行签名处理，来确保我们App的唯一性和安全性。整个过程就是所谓的项目构建。

　　如何实现整个构建的过程，对于每一个构建的步骤，都需要相应的功能模块来进行，比如Java Code编译，如何打成dex包等等，而这Android则为我们提供了相应的工具，在Android Studio命令行窗口中，我们可以通过相应的命令行来进行控制，但是，整个构建过程涉及到很多的步骤，很多的工具的使用，如果都通过命令行来进行控制，势必会相当麻烦，因此Androd Studio等IDE则对整个过程进行了一个打包，当我们在Run project的时候，底层的打包工具就会被调用，打包流程都会自动执行。然后我们只需要对构建文件按照自己的需求进行相应的配置，就可以构建出自己所需要的项目。

　　那么，整个Andoid项目的构建过程中，都执行了那些构建的任务呢？

　　首先看一下，Google官方为我们提供的详细的构建过程图

　　如果你接触Android开发已经有一段时间了，我想当你看到这张图的时候，就会觉得很清晰。但是更多的可能会一头雾水，如果之前没有阅读相关的资料的话，那么，接下来，将针对上述的构建过程，先给出一个概述，这样你将会整个构建流程在心中有一个框架，然后针对其中具体的细节，进行进一步详细的讲解。

　　图中绿色标注为其中用到的相应工具，蓝色代表的是中间生成的各类文件类型。

　　●首先aapt工具会将资源文件进行转化，生成对应资源ID的R文件和资源文件。

　　●adil工具会将其中的aidl接口转化成Java的接口

　　●至此，Java Compiler开始进行Java文件向class文件的转化，将R文件，Java源代码，由aidl转化来的Java接口，统一转化成.class文件。

　　●通过dx工具将class文件转化为dex文件。

　　●此时我们得到了经过处理后的资源文件和一个dex文件，当然，还会存在一些其它的资源文件，这个时候，就是将其打包成一个类似apk的文件。但还并不是直接可以安装在Android系统上的APK文件。

　　●通过签名工具对其进行签名。

　　●通过Zipalign进行优化，提升运行速度（原理后文会提及）。

　　●最终，一个可以安装在我们手机上的APK了。

　　通过上述讲解，我想对于Android项目的整个构建过程，应该有了一个很清晰的框架了，下面将针对其中的具体的细节，和前面挖的一些坑，来进行更细致的分析，下图是一个Android项目构建过程的详细步骤图。

　　接下来的分析，我们还是按照上述构建过程概述的顺序和流程，进行具体的分析。

　　第1步：aapt打包资源文件，生成R.java和编译后的资源（二进制文件）

　　讲到资源文件的处理，我们先来看一下Android中的资源文件有那些呢?Android应用程序资源可以分为两大类，分别是assets和res：

　　1.assets类资源放在工程根目录的assets子目录下，它里面保存的是一些原始的文件，可以以任何方式来进行组织。这些文件最终会被原装不动地打包在apk文件中。如果我们要在程序中访问这些文件，那么就需要指定文件名来访问。例如，假设在assets目录下有一个名称为filename的文件，那么就可以使用以下代码来访问它：

　　AssetManager?am=?getAssets();????InputStream?is?=?assset.open("filename");

   2.res类资源放在工程根目录的res子目录下，它里面保存的文件大多数都会被编译，并且都会被赋予资源ID。这样我们就可以在程序中通过ID来访问res类的资源。res类资源按照不同的用途可以进一步划分为以下10种子类型：

　　layout(布局文件)，drawable，xml，value，menu，raw，color，anim，animator，mipmap。

　　为了使得一个应用程序能够在运行时同时支持不同的大小和密度的屏幕，以及支持国际化，即支持不同的国家地区和语言，Android应用程序资源的组织方式有18个维度，每一个维度都代表一个配置信息，从而可以使得应用程序能够根据设备的当前配置信息来找到最匹配的资源来展现在UI上，从而提高用户体验。由于Android应用程序资源的组织方式可以达到18个维度，因此就要求Android资源管理框架能够快速定位最匹配设备当前配置信息的资源来展现在UI上，否则的话，就会影响用户体验。为了支持Android资源管理框架快速定位最匹配资源，Android资源打包工具aapt在编译和打包资源的过程中，会执行以下两个额外的操作：

　　●赋予每一个非assets资源一个ID值，这些ID值以常量的形式定义在一个R.java文件中。

　　●生成一个resources.arsc文件，用来描述那些具有ID值的资源的配置信息，它的内容就相当于是一个资源索引表。包含了所有的id值的数据集合。在该文件中，如果某个id对应的是string，那么该文件会直接包含该值，如果id对应的资源是某个layout或者drawable资源，那么该文件会存入对应资源的路径。

　　为什么要转化为二进制文件？

　　●二进制格式的XML文件占用空间更小。这是由于所有XML元素的标签、属性名称、属性值和内容所涉及到的字符串都会被统一收集到一个字符串资源池中去，并且会去重。有了这个字符串资源池，原来使用字符串的地方就会被替换成一个索引到字符串资源池的整数值，从而可以减少文件的大小。

　　●二进制格式的XML文件解析速度更快。这是由于二进制格式的XML元素里面不再包含有字符串值，因此就避免了进行字符串解析，从而提高速度。

　　有了资源ID以及资源索引表之后，Android资源管理框架就可以迅速将根据设备当前配置信息来定位最匹配的资源了。

　　对于具体的一些操作流程，可以参考本人之前的一篇文章APK打包安装过程或者更偏向于源码层级的老罗的文章。（文后参考文献链接）

　　第2步：aidl

　　aidl，全名Android Interface Definition Language，即Android接口定义语言。是我们在编写进程间通信的代码的时候，定义的接口。

　　输入：aidl后缀的文件。输出：可用于进程通信的C/S端java代码，位于build/generated/source/aidl。

　　第3步：Java源码编译

　　我们有了R.java和aidl生成的Java文件，再加上工程的源代码，现在可以使用javac进行正常的java编译生成class文件了。

　　输入：java source的文件夹（另外还包括了build/generated下的：R.java, aidl生成的java文件，以及BuildConfig.java）。输出：对于gradle编译，可以在build/intermediates/classes里，看到输出的class文件。

　　第4步：代码混淆（proguard）

　　源码编译之后，我们可能还会对其进行代码的混淆，混淆的作用是增加反编译的难度，同时也将一些代码的命名进行了缩短，减少代码占用的空间。混淆完成之后，会生成一个混淆前后的映射表，这个是用来在反应我们的应用执行的时候的一些堆栈信息，可以将混淆后的信息转化为我们混淆前实际代码中的内容。

　　而这个过程使用的工具就是ProGuard，是一个开源的Java代码混淆器（obfuscation）。ADT r8开始它被默认集成到了Android SDK中。 其具备三个主要功能。

　　●压缩 - 移除无效的类、属性、方法等

　　●优化 - 优化bytecode移除没用的结构

　　●混淆 - 把类名、属性名、方法名替换为晦涩难懂的1到2个字母的名字

　　当然它也只能混淆Java代码，Android工程中Native代码，资源文件（图片、xml），它是无法混淆的。而且对于Java的常量值也是无法混淆的，所以不要使用常量定义平文的密码等重要信息。同时对于混淆，我们可以通过代码制定去混淆那些，不去混淆那些。

　　-keep public class com.rensanning.example.Test

　　第5步：转化为dex

　　调用dx.bat将所有的class文件转化为classes.dex文件，dx会将class转换为Dalvik字节码，生成常量池，消除冗余数据等。由于dalvik是一种针对嵌入式设备而特殊设计的java虚拟机，所以dex文件与标准的class文件在结构设计上有着本质的区别,当java程序编译成class后，使用dx工具将所有的class文件整合到一个dex文件，目的是其中各个类能够共享数据，在一定程度上降低了冗余，同时也是文件结构更加经凑，实验表明，dex文件是传统jar文件大小的50%左右。class文件结构和dex文件结构比对。

　　第6步：apkbuilder

　　打包生成APK文件。旧的apkbuilder脚本已经废弃，现在都已经通过sdklib.jar的ApkBuilder类进行打包了。输入为我们之前生成的包含resources.arcs的.ap_文件，上一步生成的dex文件，以及其他资源如jni、.so文件。

　　大致步骤为

　　以包含resources.arcs的.ap_文件为基础，new一个ApkBuilder，设置debugMode

apkBuilder.addZipFile(f); 　　apkBuilder.addSourceFolder(f); 　　apkBuilder.addResourcesFromJar(f); 　　apkBuilder.addNativeLibraries(nativeFileList); 　　apkBuilder.sealApk(); // 关闭apk文件 　　generateDependencyFile(depFile, inputPaths, outputFile.getAbsolutePath());

　　第7步：对APK签名

　　对APK文件进行签名。Android系统在安装APK的时候，首先会检验APK的签名，如果发现签名文件不存在或者校验签名失败，则会拒绝安装，所以应用程序在发布之前一定要进行签名。签名信息中包含有开发者信息，在一定程度上可以防止应用被伪造。对一个APK文件签名之后，APK文件根目录下会增加META-INF目录，该目录下增加三个文件：

　　MANIFEST.MF

　　[CERT].RSA

　　[CERT]

　　Android系统就是根据这三个文件的内容对APK文件进行签名检验的。签名过程主要利用apksign.jar或者jarsinger.jar两个工具。将根据我们提供的Debug和Release两个版本的Keystore进行相应的签名。

　　MANIFEST.MF中包含对apk中除了/META-INF文件夹外所有文件的签名值，签名方法是先SHA1()(或其他hash方法)在base64()。存储形式是：Name加[SHA1]-Digest。

　　[CERT].SF是对MANIFEST.MF文件整体签名以及其中各个条目的签名。一般地，如果是使用工具签名，还多包括一项。就是对MANIFEST.MF头部信息的签名。

　　[CERT].RSA包含用私钥对[CERT].SF的签名以及包含公钥信息的数字证书。

　　第8步：zipalign优化

　　Zipalign是一个Android平台上整理APK文件的工具，它首次被引入是在Android 1.6版本的SDK软件开发工具包中。它能够对打包的Android应用程序进行优化， 以使Android操作系统与应用程序之间的交互作用更有效率，这能够让应用程序和整个系统运行得更快。用Zipalign处理过的应用程序执行时间达到最低限度，当设备运行APK应用程序时占更少的RAM。

　　●Zipalign如何进行优化的呢？

　　调用buildtoolszipalign，对签名后的APK文件进行对齐处理，使APK中所有资源文件距离文件起始偏移为4字节的整数倍，从而在通过内存映射访问APK文件时会更快。同时也减少了在设备上运行时的内存消耗。如果对于为何提速不理解，那么可以看下内存对齐的规则以及作用该篇文章，对于内存对齐的好处有比较生动详细的解释。最终这样我们的APK就生成完毕了。

　　典型的APK中内容

　　●AndroidManifest.xml 程序全局配置文件

　　●classes.dex   Dalvik字节码

　　●resources.arsc   资源索引表

　　●META-INF该目录下存放的是签名信息

　　●res  该目录存放资源文件

　　●assets该目录可以存放一些配置或资源文件

　　总结

　　至此，对于Andoid项目构建过程的分析已经完成，当然，并没与深入到源码层级的分析，本文的旨在对于构建过程流程上的了解和其中一些优化的原因所在，为后续通过Gradle插件hook构建过程来做一定的操作，做一个铺垫。

 

目前来说，越来越多的行业互联网化，也掀起了互联网金融的浪潮，第三方支付的开发也越来越广泛，一般大型的第三方支付系统包括，前置系统，支付系统，渠道系统，账务系统，清结算系统，运营与维护管理平台。下面我们来了解一下常见的一些支付流程，让大家了解了解

　　快捷支付流程

　　担保支付流程

　　代收流程

　　代付流程

　　余额支付流程

　　网关支付流程

　　二维码支付流程