《移动App测试实战》读书笔记

第一章 概述

什么是移动产品？ 移动产品是一个能够在移动设备上安装的App，或者一个能够在移动设备上访问的定制页面。

 

1.1 研发流程

互联网产品的研发过程主要涉及如下职位分工。

产品经理：负责产品方向或需求规划，需求可能来自于产品经理本人或者由其代理的第三方客户

项目经理：负责项目实施安排，资源、进度、变动、风险等

设计师：产出设计原型

开发：产出可运行的实际产品，也可细分为架构师、后台开发、web前端开发、Android开发、IOS开发

测试：质量把关，负责产品的功能、性能、稳定性的测试

运维：负责产品服务端运行环境的维护，平常的配置管理、容量规划、网络和设备故障灯，也包括监控平台的建设

运营：负责产品的推广

研发流程通常为：需求规划—>开发实现—>产品体验（主要由产品经理进行，产出体验反馈邮件）—>测试—>发布—>运营

测试人员在该流程中的主要职责有：参与需求评审—>测试用例设计/测试用例评审（产出测试用例）—>协助准备产品体验环境—>测试执行（产出bug）—>发布情况关注—>上线后（线上问题汇总）

从测试人员的角度，现场会议式的需求评审的价值主要在如下几个方面：

1）理解需求，为编写测试用例打基础

2）基于对需求细节的了解，能够更准确地评估测试的要点和工做量

3）发现需求中模糊不清的地方，从质量管理的角度进行

另外对于实现复杂的功能，还须要进行技术方案的评审，不了解技术细节，不少测试场景都没法覆盖

1.2 测试用例的设计和评审

不编写测试用例的缺点：

1）测试会很盲目

2）体现了测试的系统性、深度和效率

3）不便于知识的积累和传递

编写方法：通常先编写测试设计文档，再编写正式的测试用例，本书做者给出的测试用例示例也是使用思惟导图形式

Android名词：增量升级（Smart App Updates）

最快速提升测试设计能力的实践是参加测试用例评审，能够很快打开测试思路；另外就是用例设计的workshop，由所有的测试人员参加，各抒已见，能够看出每一个人对测试的维度、深度、全面性

 

1.3 测试进度管理

 

第二章 功能自动化

主要包括基于接口的自动化和基于App UI的自动化

2.1 轻量接口自动化测试

web产品和移动产品都必须依赖大量的后台接口提供的服务，能够经过模拟UI操做，从界面上发起请求来测试，可是效率不高且稳定性很差。最好的办法是从接口层面发起请求。

一些比较稳定的基础性组件，如底层平台、API、SDK等；或者功能通用性高的产品，能够作到比较高的自动化率，偏重应用层业务的，则相对困难。

2.1.1 特性介绍

选用开源测试工具Jmeter的优势以下：

1）支持多种不一样类型的协议

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2）对HTTP协议的支持比较全面，还提供了cookie管理、cache管理、消息头和受权管理等

3）其余非直接支持的协议能够经过扩展方式实现，能够经过Jmeter的OS Process Sampler来进行桥接和测试

4）支持丰富的断言

5）支持内嵌自定义脚本，可使用Javasript和Java等语言

6）能够直连DB检查数据

7）能够嵌入执行第三方命令行

8）文本的输入和输出

9）图形界面和命令行启动执行

10）工具自己很是稳定，有用户基础

2.1.2 实践

一些名词：

CGI—单个业务接口

Function—一个对外有逻辑意义的请求组合

TestCase—一个成品

TestSuite—一个用例的集合

大体讲解了如何组织自动化测试，未具体实践，所以未截图，先略过这里

2.2 UI层面的自动化

对于一个在快速发展中的App，UI自动化可能更适合一些基础功能的回归，而不是替代手工的功能测试，特别是对于新的功能点。

2.2.1 Android的UI自动化

.... 移动App的自动化测试暂未用到，这里直接略事后面关于Android和IOS App的自动化测试，跳到第三章

 

第三章  性能测试

性能测试的开展和被测系统特色相关，针对移动互联网产品的构成，性能能够分为前端性能和后台接口性能，进一步，前端又分为web页面和原生的App代码。

3.1 web前端性能测试

移动互联网产品，前端性能涉及web的主要有两部分：

① M站，即触屏版（使用手机浏览器访问）

咱们在PC浏览器和手机浏览器上输入同一个网站的同一个URL，返回的内容彻底不一样。这是考虑了手机屏幕的大小和流量等状况，返回了专门的M版本。

② 混合App的存在，既有原生代码，也有内嵌的网页（使用App内嵌的浏览器组件，如WebView实现）

原生模板有限，开发新模板又须要时间，使用html页面会更加灵活和便利

HTTP借助下层的TCP协议来运做，HTTP请求由：请求行、消息报头、请求正文（可选）组成；HTTP响应由：状态行、消息报头、响应正文组成

能够经过网络抓包工具（如WireShark）从TCP协议层面来了解HTTP的交互过程，TCP链接创建（3次握手）—发出HTTP请求—响应返回—TCP链接断开（4次挥手）

* TCP链接是能够复用的，能够用一个TCP链接来发起多个HTTP请求，链接的复用对于性能的提高是很重要的，浏览器和不少HTTP请求模拟测试工具都提供了一个参数，能够对这个并行链接数进行设置。

* 浏览器并非获取了整个页面完整的html文件后再进行解析，并发起对其余资源的请求；而是获取了部分的HTML内容后，就开始了解析，并基于解析的内容发起了针对其余页面元素的请求，这样更加高效

* 从HTTP1.1 开始，支持了pipeline方式，能够实如今同一个TCP链接下，一个HTTP请求若是因为服务器处理时间或响应文件太大而暂时没有响应，能够继续发出第二个HTTP请求，而没必要等待第一个HTTP响应的返回

可是，在chrome浏览器中试用时，有明显的缺陷，指望的HTTP2.0中能有所改善。

HTTP协议中有一些特性和性能息息相关：

* HTTP传输过程当中的数据压缩

HTTP头信息中 Accept-Encoding 来标识是否使用gzip，只有客户端在头信息中指明可使用时，服务端才返回压缩的内容，另外一方面，服务器端也要开启压缩相关的设置

* 缓存的管理

在第二次请求页面后，部分HTTP200响应被标识为（from cache），表示本次访问时这些URL内容都是直接从本次缓存文件中读取，而不是经过HTTP请求来获取的

缓存过时后，再次请求，响应为HTTP304 Not Modified，发起了HTTP请求，可是服务器接收到浏览器的请求后，判断认为服务端最新的该文件版本和客户端已有的一致，因而告诉客户端不须要再传输完整的内容了，能够直接用本地的版本。这样的好处是：虽然客户端仍是要发起请求，可是服务端只需经过304简单应答，而没必要从新传输文件的内容，一样起到缓存的目的。

这样处理也会有欠考虑的状况，最好的办法是经过Etag来判断缓存是否有效。Etag经过计算文件的哈希值来判断文件内容是否被修改。

web前端的性能测试方式：

前端经常使用的性能测试工具很是多，如：Fiddler、Yslow、HttpWatch、Firebug以及各个浏览器自带的开发者工具等，也有一些在线的前端性能测试工具，如WebPageTest.

对于M站应用，如何来调试用手机浏览器访问的页面？

在Chrome浏览器上安装ChromeADB插件—将手机经过USB线与PC链接，在PC的Chrome浏览器里打开如下的URL：chrome://inspect/#devices就能在PC浏览器中看到链接的手机和手机上Chrome中打开的页面，而后用PC浏览器进行调试。