2021-02-22

一.Web/App测试区别：

单纯从功能测试的层面上来讲的话，APP 测试、web 测试 在流程和功能测试上是没有区别的。
系统架构方面：
web项目，一般都是b/s架构，基于浏览器的
app项目，则是c/s的，必须要有客户端，用户需要安装客户端。
web测试只要更新了服务器端，客户端就会同步会更新。App项目则需要客户端和服务器都更新。
性能方面:
web页面主要会关注响应时间
而app则还需要关心流量、电量、CPU、GPU、Memory这些。
它们服务端的性能没区别，都是一台服务器。
兼容方面：
web是基于浏览器的，所以更倾向于浏览器和电脑硬件，电脑系统的方向的兼容
app测试则要看分辨率，屏幕尺寸，还要看设备系统。
web测试是基于浏览器的所以不必考虑安装卸载。
而app是客户端的，则必须测试安装、更新、卸载。除了常规的安装、更新、卸载还要考虑到异常场景。包括安装时的中断、弱网、安装后删除安装文件
此外APP还有一些专项测试：如网络、适配性。。。
APP测试特点
（除了按需求说明书外的 功能测试 之外还需要进行如下测试）
1： 适配性测试（也叫兼容性测试，不同的安卓版本，不同厂商，不同手机品牌）
2： 不同网络测试 （2G网络/3G网络/4G网络/WIFI网络）
3; 在线升级测试
4： 中断测试（电话、短中消息打扰）
5： 耗电量测试
6： 弱网测试（信号差，信号屏蔽实验室）
7： 安装卸载 （C/S）
8: 流量测试

二.安卓和IOS测试区别和注意点

区别：
1，操作系统：android操作系统较多，IOS较少只能升级不能降级，并且新的版本的资源库不能完全兼容旧版中系统中的应用，如果低版本应用调用了高版本的资源库，会导致系统崩溃
2，安装卸载测试：
应用发布后：下载安卓包的平台和渠道很多：豌豆荚、应用宝、360手机助手等；IOS 主要有 App store、iTunes
本地测试：安卓手机可以通过扫码或者直接安卓APK包安装测试包；IOS要安装测试包必须绑定手机的uuid才可以安装ipa测试包
3，按键操作测试：安卓手机针对每一款手机有不一样的操作；苹果手机操作习惯单一
4，开发语言：虽然同样的业务安卓和IOS的展示形式和业务一致，但是底层全完不一样。安卓的应用是有java语言实现的;iOS用objectC实现

三.App登录方式和测试重点总结

所有软件测试基础课程中，都会拿注册登录做例子，网上也能搜一堆，尤其是对于普通账户密码登录的情况，需要考虑账户密码的长度限制、字符类型、匹配判断等等。

目前市场上APP常用的登录方式有账密登录、手势登录，账密登录里又支持邮箱、账号、手机号登录。对于同时支持多种登录方式的APP，测试时除了考虑每种方式是否能够登录成功以外，特别需要考虑不同登录方式的优先级、对于用户习惯登录方式的设置和记忆、各种登录方式之间的切换、不同设备的不同方式登录等等。

今天与大家一起对App登录方式及测试重点进行梳理，主要关注一些特殊点，以及容易出现漏测的情况。
首先是账密登录的手机号支持，先了解下手机号登录的通用流程图：

一、输入手机号
1．通用运营商覆盖。
国内主流的三大运营商，移动、联通和电信号段。
如果APP有海外版，那么要考虑海外的电话号码格式和运营商号段。

2．虚拟号段。
通常情况下测试人员都会考虑到不同运营商的手机号，但是会容易漏掉虚拟号段170和171，而170和171因为是虚拟号段，并无实名制，所以大肆被不法份子所利用的号段，更是容易被一些恶意用户用来薅羊毛。

3．新开放的号段。
随着政策变化，国家会时不时开放一些新号段，比如近期开通的联通166，移动198和电信199，也是测试人员容易忽略掉的。

二、输入验证码
短信验证码一般的原理是，前端APP通过短信接口提交一个请求，向服务端提供一个Token参数，服务端对这个Token参数进行校验，校验通过之后，再通过该接口向用户手机发送短信。

1．验证码时间限制
通常验证码有两个时间限制，一个是触发发送的时间，可以有效的避免对单用户的短信轰炸。通常的表现形式是，在界面上，一旦触发短信发送后，会设定一个一定时间的倒数，可以是60s，也可以是120s，以此来控制用户无法重复多次提交发送短信验证码的请求。
另一个是接收后的验证码有效时间限制。超过限制时间，校验时会提示该验证码已失效，需要重新获取。

2．验证码次数限制
对于连续获取验证码但不进行校验的手机号，应该要有防刷机制，系统可对该手机号进行保护。达到设定次数时提示超过上限，无法再次触发给该手机号发送验证码。
对使用同一个手机号在一天内获取验证码，也一般会有个最大值的限制。

3．验证码的内容
验证码的内容，一般是跟随验证码触发的场景的，比如注册验证码、交易验证码。另外验证码内容务必要包含品牌的标识，让用户一眼感知到这个验证码是来自什么APP，或者什么公司的。
不管是账密登录，还是手势录，安全都是接口测试和功能测试的重点，也是容易被很多测试人员所容易漏关注的。

三、安全的测试
1．登录时效。
登录成功之后的cookie是多久，会否超时自动下线等等。

2．登录冲突。
多个设备同时登录一个账户的处理机制。另外跨平台是否支持同一账户同时登录等等。

3．登录异常。
跨地域，非常见IP所在地登录的风险控制机制。长时间未登录，突然登录的检测机制等等。

4．密文传输。
会否对账户密码进行加密传输，日志脱敏等等。

四.APP消息推送如何测试？

消息推送功能是很多APP都有的功能，那测试过程需要注意哪些地方？

消息推送对象

消息推送一般可以自定义推送对象，有全部推送，精确推送，及安卓和IOS渠道推送，注意推送对象是否正确，推送之前确认自己是否在测试环境操作，以免造成生产问题。

消息简介

客户端收到消息推送有两种形式，客户端后台运行一般推送显示在通知栏，客户端前台运行一般弹出弹框，简介内容注意字数过多溢出情况。

消息详情

注意详情所支持的内容，包括文字、图片、表情包、换行以及链接跳转。

消息推送场景（支持定时推送）

（1）消息推送时间：
a)设置过去时间
b)未推送之前修改消息内容
c)删除消息，查看是否还会推送
（2）客户端运行状态
a)前台运行
b)后台运行
c)进程关闭状态
（2）特殊场景
a)多个提醒冲突
b)当天设置当天推送
c)当天设置隔几天起效

五.app的闪退是什么原因造成的？

1.网络异常引起的
2.app中访问网络的地方，组件中的lmageview没有正常的下载并显示到app页面。
3.app的sdk和手机的系统不兼容。
4.拍照选择图片后闪退：手机内存小、部分手机在使用相机拍照时候纯在横屏竖屏切换，可能导致我们重新调整生命周期，
5.还是版本问题，一般有些api在老版本中有，在新版本没有，造成对象为空引起闪退。
6.缓存垃圾过多，由于安卓系统的特性，如果长时间不清理垃圾文件，会导致越来越卡，也会出现闪退的情况。
7.权限问题、一般是Android manifest文件中忘记配置相关权限。
8.在用as开发Android程序时，涉及到Android真机版本，在生成apk文件时，如果把v1v2全部勾选，可能会出现闪退。

六.常见接口协议

TCP/IP协议成为基础的网络协议，涉及四层：应用层、传输层、网络层、网络接口层
TCP协议
TCP协议是在传输层中，一种面向连接的、可靠的、基于字节流的传输层通信协议。
TCP与UDP的区别
TCP：面向连接、错误重传、拥塞控制，适用于可靠性高的场景（通话等）UDP：不需要提前建立连接，实现简单，适用于实时性高的场景（视频传输、游戏传输等）
Restful软件架构风格（软件架构状态转换）
借助于http协议的基本请求方法代表资源的状态切换post：新增或者更新get：获取资源put：更新资源delete：删除资源
RPC协议
以本地代码调用的方式实现远程执行
Dubbo、gRPC（语言中立、平台中立的数据序列化框架）、Thrift均支持RPC协议

常见状态码

100 继续。客户端应继续其请求
101 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议

200 请求成功。一般用于GET与POST请求
201 已创建。成功请求并创建了新的资源

300 多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择

301 永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替
302 临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI

400 客户端请求的语法错误，服务器无法理解
404 服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面

接口测试原理、流程

接口测试的原理是模拟客户端向服务器发送报文请求,服务器接收请求报文后对相应的报文做处理并向客户端返回应答,客户端接收应答的一个过程。
接口测试流程：
　　　　模拟客户端连接服务器(服务器提供的端口是否可访问)
　　　　　　　　↓
　　　　客户端发送报文请求
　　　　　　　　↓
　　　　服务器端接收请求并做处理
　　　　　　　　↓
　　　　检查返回的预期结果并与实际结果对比
　　　　　　　　↓
　　　 　　　　结束

如何编写接口测试用例

自动化始终只是辅助测试工作的一个手段，对于测试人员而言，测试基础和测试用例的设计才是核心。如果测试用例的覆盖率或者质量不高，那将这部分用例实现为自动化用例的意义也就不大了。
那么，接口测试用例应该怎么编写呢？
接口的定义 ：
主要是子模块或者子系统间交互并相互作用的部分。
1
因此，可以分析，系统间的接口包含三部分：输入、处理逻辑、输出。
应该怎么分析一个接口？
获取接口文档：和黑盒测试一样，我们是从需求文档中去挖掘测试点，设计测试用例。对于接口测试，同样是有对应的接口文档的。
分析接口文档，提取测试点：
1）、输入： 接受哪些参数、参数的类型、可选参数和必选参数等；根据输入参数采用等价类、边界值分析法等进行设计；
2）、业务逻辑：对于一个接口，不同的输入参数或组合，流程或状态的转移是不同，可以根据业务逻辑画出流程图或状态转移图，确保每种状态至少被访问了一次；
3）、输出：根据文档规定的输出，反向设计测试数据，使所有的输出状态都被包含了；
测试用例：同时对输入、业务逻辑、输出进行考虑时，肯定会存在用例的冗余，在最大限度覆盖业务功能和规则下，选取最优用例集合。同时，需要考虑异常数据和场景。

怎么确定用例的覆盖率？
在没有特殊要求的情况下，至少需要考虑以下内容：
1）、业务功能覆盖是否完整
2）、业务规则覆盖是否完整
3）、参数验证是否达到要求（边界、业务规则）
4）、接口异常场景覆盖是否完整
如果接口需求还包含性能或者安全要求，还要对接口进行性能测试和安全测试，就需要考虑：性能指标是否满足要求、安全指标是否满足要求。
总结
对于接口测试，测试采用的方法是与黑盒测试一致的，可以把接口测试看作是没有界面的功能测试；
可以看看大师的文章：https://mp.weixin.qq.com/s/ZH6gyUe9U12vKGoASgsLvw，提升点点点技能

负载测试，并发测试，压力测试区别

负载测试
1、定义：
负载测试是通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足性能指标的情况下，系统所能承受的最大负载量的测试。
2、目的：
不把系统搞挂的测试，使系统能够在最大的压力下可以正常运行。从而获取系统指标。
3、方法：
不断增加请求压力，直到服务器某个资源项达到饱和（比如CPU使用率达到90%+）或某个指标达到安全临界值（比如运维的监控告警阈值or拐点）。系统负载压力包含并发用户数、持续运行时间、数据量等。其中并发用户数是负载压力的重要指标。

并发测试
1、定义：
1、目的：检查系统是否有并发问题，例如内存泄漏、线程锁、资源争用等问题。
2、方法：确定用户并发数，必须知道系统所承载的在线用户数。然后在单位时间内(S)同时发起一定量的请求。
3、确定并发用户数的方法：
例如：公司OA系统账号或者总用户有2000人；最高峰在线500人；但是这500人并不是作为并发用户存在的概念。即并不表示服务器实际承载的压力；有可能40%关注的是首页新闻公告板之类（注意看新闻这个阶段是不能造成服务器的压力）；20%用户在查询资料或者操作表格；20%用户在发呆；20%在页面之间跳转；在这种情况下，只有真正20%用户在对服务器造成实质的影响。
我们将这个查询、操作表格作为一个业务范畴来说；直接将这部分业务并发用户称为并发用户数：
1.计算平均并发用户数：C=NL/T
2.并发用户峰值数：C’ ≈ C+3根号C
公式（1）中，C是平均的并发用户数；n是login session的数量；L是login session的平均长度；T指考察的时间段长度。
公式（2）则给出了并发用户数峰值的计算方式中，其中，C’指并发用户数的峰值，C就是公式（1）中得到的平均的并发用户数。该公式的得出是假设用户的login session产生符合泊松分布而估算得到的。
假设有一个OA系统，该系统有3000个用户，（可以看注册信息）平均每天大约有400个用户要访问该系统，（日志文件查看）对一个典型用户来说，一天之内用户从登录到退出该系统的平均时间为4小时，在一天的时间内，用户只在8小时内使用该系统。
则根据公式（1）和公式（2），可以得到：
C = 4004/8 = 200
C’≈200+3根号200 = 242
但是一般的做法是把每天访问系统用户数的10%作为平均的并发用户数。最大的并发用户数乘上一个值，2或者3.
假如说用户要求系统每秒最大可以处理100个登陆请求，10/25/50/75/100 个并发用户来执行登陆操作，然后观察系统在不同负载下的响应时间和每秒事务数。如果用户数在100的时候，响应时间还在允许范围呢，就要加大用户数，例如120 等 。个人理解这个用户数就是我们经常说的等价类和边界值法来设定。

压力测试
1、定义：
是给软件不断加压，强制其在极限的情况下运行，观察它可以运行到何种程度，从而发现性能缺陷。
2、目的：
把系统搞挂的测试。
3、方法：以负载测试或者并发测试为依据，给软件不断加压，强制其在极限的情况下运行，观察它可以运行到何种程度，从而发现性能缺陷。

需要验证系统是否满足性能指标（比如最大响应时间，最大并发用户数，典型处理时间，吞吐率等）的时候需要性能测试。
性能测试一般来说需要构造近似的用户使用场景，模拟用户请求调用，有时候需要单独测试的话，还可以用mock。

测试分析

测试分析的过程，就是明确需求的目的和价值、分析需求的可行性以及评估需求的优先级，最终明确测试对象和测试范围，测试的重点和难点。

步骤	目的
1. 理解需求、分析需求的价值。	理解需求的目的和价值。
2. 分析需求的可行性。	评估实现方案的可行性，是否可以做。
3. 评估需求的优先级。	评估做不做，什么时候做。
4. 测试分析。	1. 明确测试对象、测试范围；2. 明确测试的重点、难点

性能测试一般流程

step1 分析 性能测试需求
step2 编写 性能测试计划
step3 编写 性能测试用例
step4 编写 测试脚本
step5 设计 测试场景
step6 执行 场景
step7 监控 场景运行
step8 分析 测试结果
step9 系统性能 调优
step10 性能测试总结
ps:重复5-9步直到测试计划完成、结果满意。