1)Android长按home键呼出应用列表和切换应用,然后右滑则终止应用;
2)多分辨率测试,Android端20多种,ios较少;
3)手机操作系统,Android较多,ios较少且不能降级,只能单向升级,新的ios系统中的资源库不能完全兼容低版本中的ios系统中的应用,低版本ios系统中的应用调用了新的资源库,会直接导致闪退;
4)操作习惯:测试Android,Back键是否被重写,测试点击Back键后的反馈是否正确,应用数据从内存移动到SD卡后能否正常运行等;
5)push测试:Android,点击home键,程序后台运行时,此时接收到push,点击后唤醒应用,此时是否可以正确跳转,ios,点击home键关闭程序和屏幕锁屏的情况;
6)安装卸载测试:Android的下载和安装的平台和工具和渠道比较多,ios主要有appstore,iTunes和testflight下载。
app测试:
1)安装卸载测试;2)运行测试;3)更新测试;4)兼容测试;5)弱网环境测试;6)中断冲突测试(app运行时拨打电话或者接电话、发信息、接收邮件、启动相机等有和提示;app运行是突然断网、断电、不断点击、不断刷新、切换前后台是否崩溃(变态测试))
7)压力测试(安装用monkey,不断点击、滑动屏幕,看软件是否崩溃)
8)应用的前后台切换;9)消息推送开关测试;10)跨app跳转/分享
web测试:
1)功能测试;2)界面测试;3)链接测试;4)性能测试;5)兼容性测试;6)安全性测试
系统指标:用户场景/需求直接体现
1)并发用户数;2)响应时间;3)事务成功率;4)超时错误率;
资源指标:硬件资源消耗
1)CPU中央处理器;2)内存;3)I/O;4)带宽;
1)内存;2)CPU;3)流量;4)电量;5)启动速度
6)滑动速度、界面切换速度;7)与服务器交互的网络速度
APP性能测试要点:一般性能测试、负载测试、压力测试、稳定性测试
①性能测试:
1.资源消耗:
cpu的占用、内存的占用、流量的耗用、电量的耗用
2.响应能力测试:
App安装、卸载的响应时间,启动消耗时间的测试(热启、冷启),页面加载时间的测试
3.负载测试:
进行负载测试是否有异常
4.压力测试:
进行压力测试是否有异常,进行压力测试看APP能承受的最大性能指标
5.稳定性测试:
稳定性测试的时候常会用monkey进行。主要通过monkey的伪随机事件流进行大量的点击、滑动等操作,这是为了检测出产品中隐藏的crash、anr等缺陷,确保没有问题。
②压力测试与负载测试两者区别
• 相同点:
都是性能测试
• 不同点:
1.负载测试强调系统正常工作情况下的性能指标
2.压力测试的目的是发现在什么条件下系统的性能变得不可接受,发现应用程序性能下降的拐点。
(1)、连接超时
这个是App关闭的首要问题,而在移动应用中网络错误数据比例报错中最高的就是连接超时错误。
(2)、崩溃
APP的崩溃,就是用户的崩溃。当用户使用你的App出现闪退或崩溃时,他们很有可能跑去App Store赠送你一个“一星”差评。
(3)、系统交互(电话短信干扰,低电量提醒,push提醒,usb数据线插拔提醒,充电提醒等)
在APP使用过程中,可能会遇到各种中断场景,那么一旦发生这些场景,APP就卡死或者闪退,想必也没有多少用户愿意持续使用你的APP。
(4)、弱网下的运行情况
电梯里、地铁上,网络信号差时,APP页面的菊花转不停,界面卡死,同时错误提示一堆,这样的情况怎能不让用户抓狂。
(5) 、CPU使用问题
CPU频率设置过高时会导致过热,过热导致耗电更严重, CPU频率设置过低导致手机滞后,应用处理缓慢同样会导致耗电。更多时候,用户解决CPU超载问题只能关闭甚至卸载App,App就被Kill了!
1)视频播放的状况十分依赖于网络环境,所以在不同的网络环境(WIFI、2G、3G、4G、弱网、无网络)下都需要测试视频在客户端运行的效果。针对不同网络的模拟,我们选用的是测试网络延迟和丢包工具Network-Emulator-Toolkit-x64。
2)测试时除常规需要验证项:播放模式(横屏、竖屏、横屏竖屏切换),播放制式(WIFI、2G、3G、4G),播放键位(返回、关闭、播放/暂停、最大化/最小化、音量),播放机制(首次进入、开始播放、暂停播放、继续播放、连续播放)等,还需设计一套测试异常类的用例集。
通过对容器云方案和微服务架构的整体考虑,DevOps分成以下过程
持续集成:开发人员研发的代码向软件整体部分交付,频繁进行集成以便快速发现问题。
持续交付:在已完成集成的代码上面将完成测试的代码部署到“类生产环境”中。
持续部署:已交付的代码在通过评审之后,自动部署到生产环境中。
持续监控:通过专业的监控软件(如Prometheus等),按事先设置的监控策略,监控业务应用以及系统平台的运行情况,形成监控报告和监控展示。
持续反馈:基于监控的结果作数据分析,提供建议方案,如针对应用的监控,实现应用的弹性伸缩等能力。
持续改进:基于反馈的意见,启动新的改进计划流程。
(1)、测试环境搭建
微信Web开发者工具安装、授权测试用的微信号可预览和调试小程序
(2)、测试范围
1.权限测试
需要检查以下几种情况下微信用户访问的权限
1)未授权微信登录小程序
未授权时,一般使用一些业务功能的时候,都会弹出提醒:先授权再操作对应功能。or在提交数据到后台的时候,会提示补充相关身份信息才能提交成功
2)已授权微信登录小程序
授权微信访问小程序,意味着自己的微信账号可被小程序管理方所获取,自动以微信的身份行使业务操作权限,比如咨询、支付、数据查询等
3)同一微信号在不同手机端登录授权查看数据权限
同一微信号在不同手机微信端授权登录同一小程序之后,所能查看的数据和操作的权限都应该是同步一致的
2.功能测试
1)按功能模块测试
根据设计好的各个大类功能模块划分,然后再逐级细化,覆盖到每个功能尽可能全面的测试点
2)按业务流程测试
小程序的业务,比如咨询、支付、播放、查询、下载。把各个功能点串联起来形成完整的业务流程来检查;同一个业务,可能有不能的路径来实现,每个路径都需要覆盖检查
3)按数据流向测试
根据数据从某一端操作输入和输出流向,设计基于数据流的测试用例,输出的数据也可能成为另外一端的输入,检查输入的数据是否按照代码逻辑执行正确的输出,是否数据发生异常(无法输入;有输入却无任何输出;输出不正确;多余的输出其他信息…)
4)同一功能不同的入口有效性的检查
小程序中在首页、列表页、详细页、其他的业务功能相关页面,都有可能存在同一个功能的入口,如付费咨询、免费咨询业务中,可以直接从首页进入付费咨询入口,也可以通过免费咨询入口再切换到付费咨询入口。每一个入口路径都需要覆盖检查
5)交互性检查
一般而言,产生数据和功能交互变化的情况主要有这几个分类:前台<–>前台、后台<–>后台、前台<–>后台。前台从A1页面提交的数据,可能需要在前台A2页面查看到,也会在对应后台的B页面查到记录;后台B1页面修改or添加的数据,对应到前台的A页面产生交互变化,后台本身的不同页面之间也可能存在同一个数据的输出值
3.版本配置测试
有时候小程序一次性做了几套不相同的模板,在前端程序代码中修改配置参数,保存后重新编译,即可从一个版本切换到另一版本,同时也需要在管理后台作相应的切换,以保证前端进行数据调用
对于非公用的部分:不同版本直接的切换,需要保证彼此的功能模块和数据独立性不受干扰影响,即不同版本的管理后台所添加的数据只应该调用到各自对应模板的前台小程序中,不同版本的小程序从前台提交的数据也只会提交到各自管理后台,不应该有交差重叠
对于公用的部分:切换不同的模板,都会显示相同的内容
4.兼容性测试
1)手机操作系统
常规的手机端OS为:Android(7.x/6.x/4.x/2.x…)、IOS(11.x/10.x/9.x…)
2)微信版本
对于已上线的小程序,有可能会因为微信版本升级之后导致对部分小程序的组件支持产生冲突,手机端微信上查看的小程序页面出现样式有异常,比如出现少部分区域的黑屏,这种情况需要同步在小程序的程序包中修改一些组件再次更新
5.易用性测试
1)导航
定位到页面某个模块所在位置,回到顶部or底部,导航条的收展,导航标签的文字是否容易理解
2)功能入口
重要且常用业务的功能入口,是否在比较显眼的位置,业务操作过程是否便于大多数用户使用和查看
3)上下层级进入&返回
首页<–>列表页、列表页<–>详细页 、首页<–>详细页。不同层级之间的进入和返回实现是否有相应按键易操作
4)字体、图片、动态交互效果
字体:标签、标题、内容、动态播放字体…
图片:轮播图、背景图、封面图、触屏产生的交互图…
1)等价类划分法;
2)边界值分析法;
3)因果图法;4)功能分析法;5)场景设计法;6)错误推断法;
7)决策表 8)正交实验法
1)性能测试的需求分析:客户需求、新系统性能严重、旧系统扩容、优化系统瓶颈等
2)性能测试工具的选型:商业loadrunner,开源工具Jmeter、Locust或自主研发
3)性能测试环境准备:软件环境、测试环境、网络环境
4)性能测试业务分析:针对哪些业务做性能测试(稳定的测试点、变动较少的页面)
5)性能测试数据准备:准备基
础数据
6)性能测试执行策略:不同业务的用户分配比例、运行时长、思考时间 、集合点的设置等。
7)性能测试监控:中间件的监控、数据库服务器的监控、系统服务器的监控。
8)性能测试分析与调优:分析整个系统哥哥部分的监控结果;对程序处理过程优化,程序算法优化,中间件各个部分配置参数的调整,数据库SQL语句、索引、表结构的优化。
自动化测试要引入的话,首先要系统或者平台的功能达到基本稳定后才能开始,那首先要规划定位主要做哪些功能的自动化才有意义?是为了后续更新保证以前的功能不受影响,更新后正常使用。按照我们平台的话,就是那些最基本的功能,比如登录功能,搜索功能,下单流程。这几个功能使用频率最高,所以对于电商平台,首先做自动化的就是针对这些基础功能开展。
HTTP的全称是Hypertext Transfer Protocol Vertion (超文本传输协议),说通俗点就是用网络链接传输文本信息的协议; HTTPS(Secure Hypertext Transfer Protocol)安HTTP全超文本传输协议。
1)https协议需要到ca申请证书,一般免费证书较少,因而需要一定费用。
2)http是超文本传输协议,信息是明文传输,https则是具有安全性的ssl加密传输协议。
3)http和https使用的是完全不同的连接方式,用的端口也不一样,前者是80,后者是443。
4)http的连接很简单,是无状态的;HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议,比http协议安全。
200 OK:请求成功。一般用与GET与POST请求。
302 Fund:请求重定向。临时移动,资源知识六十被移动,客户端应继续使用原有URL
304 :请求资源没有改变,访问本地缓存。
400 Bad Request:客户端请求有语法错误,不能被服务器所理解。
401 Unauthorized:请求要求用户的身份认证。
403 Forbidden:服务器理解客户端的请求,但是拒绝执行此请求。
404 Not found:请求资源不存在。通常是用户路径编写错误,也可能是服务器资源已删除。
500 Server Unavailable:服务器内部错误。通常程序抛异常。
状态信息:状态信息是根据状态码变化而变化的
Cookie和session区别:
1.cookie数据是存在客户浏览器上,session数据存放在服务器上。
2.Cookie不是很安全,别人可以分析存放在本地的cookie并进行cookie欺骗(使用用户的cookies获取相关信息。)
3.Session比较安全,会存放在一定时间内保存在服务器上。当访问增多,会比较占用服务器的性能
4.单个cookie保存的数据不能超过4k, 很多浏览器都限制一个站点最多保存20个cookie。
Cookie session的利弊:
带上cookie、session的好处:很多网站必须登录之后(或者获取某种权限之后)才能够请求到相关数据。
带上cookie、session的弊端:一套cookie、session往往和一个用户对应。
请求太快,请求次数太多,容易被服务器识别为爬虫。从而是账号受到损害
使用建议:
1.不需要cookie的时候尽量不需要使用cookie
2.为获取登录之后的页面,我们必须发送带有cookie的请求,此时为了确保账号安全应该尽量降低数据采集速度。
1)进程/应用程协议
常见协议有:Telnet、FTP、SMTP、HTTP、DNS等。由客程序和服务程序两部分组成,程序通过服务器与客户机交互。
2)主机—主机层协议
建立并且维护连接,用于保证主机间数据传输的安全性。这一层主要有两个协议:
TCP(Transmission Control Protocol:传输控制协议;面向连接,可靠传输
UDP(User Datagram Protocol):用户数据包协议;面向无连接,不可靠传输
3)Internet层协议
负责数据的传输,在不同网络和系统间寻找路由,分段和重组数据报文,另外还有设备寻址。些层包括如下协议:
IP(Internet Protocol):Internet协议,负责TCP/IP主机间提供数据报服务,进行数据封装并产生协议头,TCP与UDP协议的基础。
ICMP(Internet Control Message Protocol):Internet控制报文协议。ICMP协议其实是IP协议的的附属协议,IP协议用它来与其它主机或路由器交换错误报文和其它的一些网络情况,在ICMP包中携带了控制信息和故障恢复信息。
ARP(Address Resolution Protocol)协议:地址解析协议。
RARP(Reverse Address Resolution Protocol):逆向地址解析协议。
TCP协议保证传输可靠的方法主要有:校验和,序列号,确认应答,超时重传,连接管理,流量控制,拥塞控制。
1.先说一下TCP的优缺点吧。优点呢,TCP是可靠的连接,由于有基本的重传确认机制,可以保证把一个数据块完完整整的从A传到B;缺点也是因优点而生,因为有三次握手,所以会传输更多的包,浪费一些带宽;因为需要可靠地连接进行通信,则需要双方都必须持续在线,所以在通信过程中server需要维持非常大的并发连接,浪费了系统资源,甚至会出现宕机;再者就是因为有重传确认,则会浪费一部分的带宽,且在不好的网络中,会因为不断地连接断开连接,严重降低了传输效率。
2.相对于TCP来说,UDP是非面向连接的不可靠的协议,其优点也因为缺点而生。首先,因为没有三次握手,所以会起步比较快,延时小;另外,由于不需要双方持续在线,所以server不用维护巨量的并发连接,节省了系统资源;三,因为没有重传确认,虽然到达的数据可能会有所缺失,但在不影响使用的情况下,能更高效的利用网络带宽。
基于前面的说法,总结一下本文的问题答案。TCP适合实时性要求不高,但要求内容要完整传输的应用。相比而言,UDP由于无连接、无重传确认,所以传输效率高、延时小,适合实时性要求高的应用,如游戏服务器,音频,视频等;另外,由于不用维持大的并发量,所以适合巨量服务的server,加上合适的时间控制,可以用来设计更大的并发服务器;再者就是,UDP可以更高效的利用网络带宽。