web测试

前言：现在的这个社会跟随着移动互联网的极速发展下，移动端应用以及使用人群呈指数增长，测试岗app类显然是需求大增；目前APP的需求量明显大过于WEB测试；作为WEB测试出身的我现在都有点开始担忧:) 那我们来说说它们的异同点。 1>APP与WEB的相同点 其实简单来说不管是web测试，还是目前比较火热的APP测试，万变不离其中，测试基本远离是基本没有改变的 1）设计测试用例时，依然都是依据边界值分析法、等价类划分等； 2）多数采用黑盒的测试方法，来验证业务功能是否得到正确的应用； 3）需要检查界面的布局、风格和按钮等是否简洁美观、是否统一等； 4）测试页面载入和翻页的速度、登录时长、内存是否溢出等； 5）测试应用系统的稳定性等。 2>APP与WEB的不同点 相对于web测试，手机软件测试，除了要考虑基本的功能测试、性能等，还要考虑手机本身固有的属性特征。所以对比web测试和手机app测试，手机测试过程中还需要注意如下几个方面特性： 1）手机作为通信工具，来电、去电、接收短信等操作都会对app应用程序产生影响，所以app测试第一个要考虑的属性特征是：中断测试。 中断测试有人为中断、新任务中断以及意外中断等几种情况，主要从以下几个方面进行验证： a.来电中断：呼叫挂断、被呼叫挂断、通话挂断、通话被挂断 b.短信中断：接收短信、查看短信 c.其他中断：蓝牙、闹钟、插拔数据线、手机锁定

单纯从功能测试的层面上来讲的话，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

WEB测试重点 1.功能测试： 所实现的功能是否和需求一致； 2.界面测试： 界面是否美观，风格是否一致，文字内容是否正确； 3.链接测试： 打开链接速度是否合理；是否链接到正确的页面；是否有空白页面； 4.性能测试： 系统能支持多少用户同时在线；超过这些用户数，系统会给出什么样的反映； 5.兼容性测试： 项目在不 同操作系统，不同浏览器上功能是否能正常使用； 6.安全性测试： 用户的登录名和密码在传输过程中是否是加密传输的； 用户长时间未操作页面，session会话是否会过期，要求用户重新登录； 日志文件cookies里的用户名和密码是否是加密的； 登录次数和登录设备是否有限制，是否支持一个账号多个设备登录； APP测试重点 1.安装卸载测试： app在 不同的操作系统（安卓和ios），不同的版本，不同的机型上是否都能安装成功； 在安装过程中，突然断网或网络不好，是否给出有好的提示，网络恢复之后是否能正常下载； 在安装过程中，突然内存不足，是否有相应的提示； 在安装过程中，是否支持取消操作； 在安装过程中，突然死机，断电，卡死，手机恢复正常后，是否能正常安装；、 安装成功后能否正常运行 卸载时在不同系统，不同版本上能够卸载成功； 在卸载过程中是否支持取消操作； 在卸载过程中，突然死机，断电，卡死，手机恢复正常后，是否能正常卸载； 卸载完成之后，查看文件是否卸载干净； 2.运行测试

单纯从功能测试的层面上来讲的话， APP 测试、 web 测试 在流程和功能测试上是没有区别的 根据两者载体不一样，则区别如下： 1 、系统结构方面 web 项目， b/s 架构，基于浏览器的； web 测试只要更新了服务器端，客户端就会同步会更新 app 项目， c/s 结构的，必须要有客户端； app 修改了服务端，则客户端用户所有核心版本都需要进行回归测试一遍 2 、性能方面 web 项目 需监测 响应时间、 CPU 、 Memory app 项目 除了监测 响应时间、 CPU 、 Memory 外，还需监测流量、电量等 3 、兼容方面 web 项目： 1. 浏览器（火狐、谷歌、 IE 等） 2. 操作系统（ Windows7 、 Windows10 、 Linux 等） app 项目： 1. 设备系统 : iOS （ ipad 、 iphone ）、 Android （三星、华为、联想等） 、 Windows （ Win7 、 Win8 ）、 OSX （ Mac ） 2. 手机设备可根据 手机型号、分辨率不同 3. 安装、更新、卸载 安装：需考虑安装时的中断、弱网、安装后删除安装文件等情况 卸载：需考虑 卸载后是否删除 app 相关的文件 更新：分强制更新、非强制更新、增量包更新、断点续传、弱网状态下更新 4 、相对于 Wed 项目， APP 有专项测试 1. 干扰测试

不管是传统行业的web测试，还是app测试，都离不开测试的基础知识，即是不管怎么变，测试的原理依然会融入在这两者当中。 1、Web测试和APP测试相同点 1）设计测试用例时，依然都是依据边界值分析法、等价类划分等； 2）多数采用黑盒的测试方法，来验证业务功能是否得到正确的应用； 3）需要检查界面的布局、风格和按钮等是否简洁美观、是否统一等； 4）测试页面载入和翻页的速度、登录时长、内存是否溢出等； 5）测试应用系统的稳定性等。 2、不同点 相对于web测试，手机软件测试，除了要考虑基本的功能测试、性能等，还要考虑手机本身固有的属性特征。所以对比web测试和手机测试，手机测试过程中还需要注意如下几个方面特性： 1）手机作为通信工具，来电、去电、接收短信等操作都会对app应用程序产生影响，所以app测试第一个要考虑的属性特征是：中断测试。 中断测试有人为中断、新任务中断以及意外中断等几种情况，主要从以下几个方面进行验证： a.来电中断：呼叫挂断、被呼叫挂断、通话挂断、通话被挂断 b.短信中断：接收短信、查看短信 c.其他中断：蓝牙、闹钟、插拔数据线、手机锁定、手机断电、手机问题（系统死机、重启） 2）手机用户对app产品的安装卸载操作：从上一个版本/上两个版本直接升级到最新版本。 全新安装新版本 新版本覆盖旧版本安装 卸载旧版本，安装新版本 卸载新版本，安装新版本 3

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

单纯从 功能测试 的层面上来讲的话，APP 测试、 web 测试 在流程和功能测试上是没有区别的。 　 　根据两者载体不一样，则区别如下： 　　系统结构方面 　　web项目，b/s架构，基于 浏览器 的；web测试只要更新了服务器端，客户端就会同步会更新。 　　app项目，c/s结构的，必须要有客户端；app 修改了服务端，则客户端用户所有核心版本都需要进行回归测试一遍。 　 　性能方面 　　web项目 需监测 响应时间、CPU、Memory 　　app项目 除了监测 响应时间、CPU、Memory外，还需监测 流量、电量等 　　 兼容方面 　　 （1）web项目： 　　1. 浏览器（火狐、 谷歌 、IE等） 　　2. 操作系统 （Windows7、Windows10、 Linux 等） 　　 （2）app项目： 　　1. 设备系统:iOS（ipad、 iphone ）、 Android （ 三星 、 华为 、联想等） 、 Windows （Win7、Win8）、OSX（Mac） 　　2. 手机 设备可根据 手机型号、分辨率不同 　　 相对于 Wed 项目，APP有专项测试 　　1. 干扰测试：中断，来电， 短信 ，关机，重启等 　　2. 弱网络测试（模拟2g、3g、4g，wifi网络状态以及丢包情况）；网络切换测试（网络断开后重连、3g切换到4g/wifi 等） 　　3. 安装

环境：zabbix4.0 最近业务上碰到一个需要进行web监控的项目，发现zabbix4.0和3.0版本有些项目变得不一样了，特地写此文章记录一下，让迷路的小伙伴们少踩点坑 从上图可以很清楚的看到，4.0的scenario把以前的变量以及头部细化，进到steps，也是一样，把post也细化为name和value了 在很多文章中看到4.0版本的name需要做成这样形式的{aaa}，经过测试发现并不是这样，导致我调个web场景浪费了很多时间，最后发现，name就直接输入字符串就行，比如aaa,bbb，无需加其他的符号，value也是一样，就此，结束了这场痛苦的调试。 在一个全新的环境搭建新版本，真的不是很建议，一来新版本的东西网上的教程太少，学习成本太高，很多都需要自己去摸索，二来新的东西不一定就是好的，有些不稳定，所以如果是在企业，建议选择稳妥的版本，这样能大大提高效率。 来源： https://blog.csdn.net/qq_24601199/article/details/99671185

前言 吐槽一下网上的各种转换教程。。说的真的是吵来吵去，有用的东西极少。特此自己写一篇好使的。 转换过程 建好的maven工程 建好的maven工程长这个鬼样子~~，没有使用骨架。就是普通的建立方式。 生成webapp，web-inf和web.xml 首先选择我们的工程，往idea的右上方看，找到如下的图标 点击后，选择modules，点击上方加号，选择web。 进入如下页面： 上面的path是让你设置生成web.xml的位置。 下面的是让你设置webapp的web目录是哪个。 按照我所展示的目录结构是最好的。 生成完毕后，如下 发现webapp上有个地球标志，生成成功。 发布测试 至此转换就成功了。我们在web-inf下建立一个index,jsp页面，上面打印一个helloworld。 发布到tomcat。 访问8080.页面显示正常 目录资源放的位置 配置文件还是放在resource下，静态css，js，img之类的放在webapp下。页面放在web-Inf下。 来源： https://www.cnblogs.com/jichi/p/11356759.html

背景 在上一章( 直击根源：vue项目微信小程序页面跳转web-view不刷新 )解决了vue在小程序回退不刷新的问题之后，会引出了一个刷新的页面需要点击返回两次才能返回上一个页面 问题描述 在A页面从B页面带了参数返回之后，A页面会刷新，直接导致了，A页面返回上一个页面需要点击两次，其中点击一次时还是A页面。 解决方案 首先第一个想法就是，设置一下退回按钮直接跳到上一个页面去；经过资料查找，回退按钮是没有直接触发函数的，也就是说不能直接控制回退的功能。 在寻找资料时，发现可以间接的触发一个unload函数，于是尝试在当前页面退回按钮点击后，会立即触发当前页面的unload方法，在unload里面尝试跳转到A的前一页，结果如下： 在A页面添加了unload方法，然后跳转到指定的页面，发现一个现象，第一次点A退回，是不触发unload，第二次才触发了unload，也就是说在B回到A页面之后刷新之后的A页面不触发unload页面。` 那么是web-view刷新产生的这个页面，也不能干掉，让web-view刷新这个页面就可以了，找了很多资料，没有理出一个头绪，web-view既然是第二次刷新产生的，那么让只刷新第一次是不是就可以解决了，于是做了如下尝试： 在B页面把A页面的web-view的src变量置为空，然后在A页面web-view上添加 wx:if={{src!==''}}