问题集

 

以下皆为收集各大佬内容整理

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: 流量测试

 

测试报告包含内容

 

 

软件测试报告的组成：

一、概述

        包括项目背景、需求分析

二、测试时间、测试环境

三、测试过程

        评审记录、测试范围、测试用例

四、功能实现清单

        列出是否已经按照测试计划实现功能

五、缺陷统计

测试缺陷统计；
测试用例执行情况统计
六、测试统计情况

资源统计
执行情况
问题统计
问题列表
遗留的问题
七、测试总结

测试结论；（是否通过）
测试内容、测试用例的覆盖程度、bug的解决程度
八、测试风险
————————————————
版权声明：本文为CSDN博主「like_that」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/like_that/article/details/102821357

 

安卓和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)当天设置隔几天起效

常见接口协议

TCP/IP协议成为基础的网络协议，涉及四层：应用层、传输层、网络层、网络接口层

TCP协议

TCP协议是在传输层中，一种面向连接的、可靠的、基于字节流的传输层通信协议。

TCP与UDP的区别

• TCP：面向连接、错误重传、拥塞控制，适用于可靠性高的场景（通话等）
• UDP：不需要提前建立连接，实现简单，适用于实时性高的场景（视频传输、游戏传输等）

Restful软件架构风格（软件架构状态转换）

• 借助于http协议的基本请求方法代表资源的状态切换
• post：新增或者更新
• get：获取资源
• put：更新资源
• delete：删除资源

RPC协议

以本地代码调用的方式实现远程执行
Dubbo、gRPC（语言中立、平台中立的数据序列化框架）、Thrift均支持RPC协议

常见状态码

状态码	状态码英文名称	中文描述
100	Continue	继续。客户端应继续其请求
101	Switching Protocols	切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议
200	OK	请求成功。一般用于GET与POST请求
201	Created	已创建。成功请求并创建了新的资源
202	Accepted	已接受。已经接受请求，但未处理完成
203	Non-Authoritative Information	非授权信息。请求成功。但返回的meta信息不在原始的服务器，而是一个副本
204	No Content	无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档
205	Reset Content	重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域
206	Partial Content	部分内容。服务器成功处理了部分GET请求
300	Multiple Choices	多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择
301	Moved Permanently	永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替
302	Found	临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI
303	See Other	查看其它地址。与301类似。使用GET和POST请求查看
304	Not Modified	未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源
305	Use Proxy	使用代理。所请求的资源必须通过代理访问
306	Unused	已经被废弃的