持续更新中loading……
jmeter元件有哪些
* jmeter中共有8类可被执行的元件（test plan和thread group不属于元件），其中，sampler（取样器）是不与其他元件发生交互的作用的元件。
* 1，Config Elements：配置元件，如CSV参数化，http信息头管理器，cookie管理器，http授权管理器等。
* 2，Pre-porcessors：前置处理器，如用户参数
* 3，Timer：定时器，包括集合点，固定定时器等
* 4，sampler：取样器，如http取样器，debug sampler 取样器等。
* 5，Post-porcessors：后置处理器（如json提取器，正则表达式提取器等）
* 6，Assirtions（除非Sampler得到的返回结果为空）----断言
* 7， Listener（除非Sampler得到的返回结果为空）---监听器
* 8，逻辑控制器：如if控制器，事务控制器，循环控制器等
* 以上8类监听器前7类是按照从上至下的顺序执行的。
抽奖活动的测试点
（功能 UI 性能 安全 易用性 兼容性 性能 等几个方面来考虑）
UI：
首页banner
活动页面（显示剩余次数，抽一次少一次，立即刷新）
支付后获得抽奖机会页面（转盘，跑马灯）活动时间：
时间未到，能不能看到活动页面，如果看得到，点击抽奖，应提示时间未到，提交订单也是无法获取抽奖机会的获得抽奖次数的入口：
订单类型
1.普通
2.满减
3.优惠券
4.满减+优惠券
5.第一次下单
6.满足多少给机会
7.积分+金额
8.推荐好友下单获得抽奖次数的限制：
同一userId每天最多获得多少次（需求）奖品发放：
虚拟直接发到账户。（记录，通知）
实体，就要弹框提示（订单记录，物流记录，甚至数据库都可以，看需求，最起码数据得有）兼容性：
各个浏览器，手机的兼容性能：
同一时间，大并发抽奖，服务器能不能及时响应安全：
session过期，点击抽奖
未登陆，进入活动页面
概率：
普通：设置的概率不是100%，那么就手动点点，保证不是100%就可以了，再让开发协助设置100%，手动测试每一次测试都能保证100%中奖就OK。
接口：jmeter，大并发（3000次）
计算实际中奖概率=中奖次数/抽奖总次数后台添加活动：（管理功能，基本要求能保证功能正常使用就可以）
活动标题：
活动类型：
活动奖项：
开始结束时间：
概率：
app和PC测试的区别
单纯从功能测试的层面上来讲的话，APP 测试、web 测试在流程和功能测试上是没有区别的。
相同点：
1.同样的测试用例设计方法；
2.同样的测试方法：都会依据原型图或效果图检查UI；
3.测试页面载入和翻页的速度、登录时长、内存是否溢出等；
4.测试应用系统的稳定性；
不同点：
1⃣️系统结构方面
web项目，b/s架构，基于浏览器的；web测试只要更新了服务器端，客户端就会同步更新。
app项目，c/s结构的，必须要有客户端；app 修改了服务端，则客户端用户所有核心版本都需要进行回归测试一遍。
2⃣️性能方面
web项目 需监测 响应时间、CPU、Memory；
app项目 除了监测 响应时间、CPU、Memory外，还需监测 流量、电量等；
3⃣️兼容性方面
web项目：浏览器（火狐、谷歌、IE等）；操作系统（Windows7、Windows10、Linux等）。
app项目：设备系统:iOS（ipad、iphone）、Android（三星、华为、联想等） 、Windows（Win7、Win8）、OSX（Mac）；手机设备可根据 手机型号、分辨率、屏幕尺寸不同。
4⃣️相对于 Web项目，APP有专项测试
1）干扰测试：中断，来电，短信，关机，重启等。
2）弱网络测试（模拟2g、3g、4g、5g，wifi网络状态以及丢包情况）；网络切换测试（网络断开后重连、3g切换到4g、5g/wifi 等）。
3）安装、更新、卸载，中断、前后台切换。
安装：需考虑安装时的中断、弱网、安装后删除安装文件，全新安装、升级安装、第三方工具安装等情况；
卸载：需考虑第三方工具卸载、直接卸载卸，载后是否删除app相关的文件；
更新：分强制更新、非强制更新、增量包更新、断点续传、弱网状态下更新；
中断：来电中断、短信中断、闹钟中断、手机锁定、手机断电、手机死机；
4）界面操作：关于手机端测试，需注意手势，横竖屏切换，前后台切换。
5)权限测试：设置某个App是否可以获取该权限，例如是否可访问通讯录、相册、照相机等。
APP测试关键点
- 功能测试
- 兼用性测试
- 安装，卸载，升级测试
- 干扰测试
- PUSH测试
- 用户体验测试
- 稳定性测试
9.1功能测试
显性需求
根据设计文档，需求文档验证APP各个功能的实现
隐性需求：需求规格说明书中没有明确定义的功能需求，
隐形需求
相关业务：功能影响的业务
其他角度：分支流程，逆行思维，异常操作
补充精简：测试经验
（如下需求文档）
1. .发布主题时：添加标题，添加内容，添加图片，
2. 标题要求：标题不能超过30个字
3. 内容要求：内容不能少于4个字，不能多于500字
4. 图片不能超过10M
10.兼容性测试
关注点：查看：主流机型 https://tongji.baidu.com/research/app
云测试平台：https://www.testin.cn/realmachine/index.htm
● 手机型号
覆盖市场主流机型：
app线上用户机型排名
● 系统版本
Android系统
4.4 ，5.1，6.0，7.0，10.0
ios系统
9.x, 10.x.11.x.12.x 14.x
● 屏幕尺寸,分辨率
分辨率
1080x1920，720x1280
屏幕尺寸
5.5，4.7，6.2
● 网络
2G,3G,4G,wifi
● 应用兼容性
与手机的硬件兼容
home键，电源键，音量调节
与外部硬件设备兼容
耳机，蓝牙等
与其他APP兼容
后台在播放音乐时，进入动态页面点击动态视频的播放，系统如何处理
与手机操作系统软件的兼容
wlan设置
11.安装卸载升级测试
APP客户端是需要安装卸载升级的
● 安装测试关注点
正常场景
1. 在不同的操作系统版本上安装
2. 从不同的安装渠道安装（APP应用商城，手机助手，直接下载apk包或者ipa包）
异常场景
1. 安装时出现异常（关机，断网）恢复后能否继续安装
2. 安装时存储空间不足
3. 安装时取消后再次安装
4. 正在运行时覆盖安装
5. 低版本覆盖安装高版本
6. 卸载后安装
● 卸载测试关注点
1. 正常卸载（手工卸载，工具卸载）
2. 运行时卸载
3. 取消卸载
4. 卸载异常中断
5. 卸载后无效数据残留
● 升级测试关注点
1. 从临近版本升级
2. 跨版本升级
3. 不同渠道升级（应用商城，手机助手）
4. 升级提醒成功（可不提醒，可以提醒，强制升级）
5. 应用内升级时非wifi提醒
6. 自动升级（检测到有新版本自动升级）
升级后：升级前的数据和升级后的数据是否发生混乱
12.干扰测试
交叉测试又叫“冲突测试”或者“干扰测试”
指的是一个功能在执行过程中，另一个事件或操作对该过程进行干扰的测试，例如：在APP前台/后台运行的同时接听来电或者下载文件等。
● 交叉事件测试关注点：
所有可能会影响APP正常运行的场景
1. APP运行时接打电话
2. APP运行时收发信息
3. APP运行时查看应用推送
4. APP运行时接上蓝牙设备
5. APP与运行时接收文件弹窗提醒
6. APP与运行时旋转屏幕
7. APP运行时切换网络（4G,WIFI）
8. APP运行时使用相机，计算器等手机自带应用
9. APP运行时电量警告，插拔充电器
交互性：一个APP使用另一个app的功能，例如：一个淘宝上一个闲鱼的产品，单机跳转到咸鱼app上
13，push消息测试
APP使用push消息的原因
消息推送场景
产品角度：功能需要 如：新闻类产品的新闻推送，工具类产品的广告推送等
运营角度：活动运营需要。如：电商类产品的促销活动，召回用户提高活跃度
消息推送原理：
● pull客户端主动获取
客户端固定时间主动向服务器获取信息，如果有更新信息，则发送到客户端
短链接
● push客户端被动接受
当服务器有更新信息时，主动发送到客户端
长连接
区别：
push比pull方式更好
push方式比pull方式更省资源
pull费资源的原因：客户端需要不断的检测服务器的变化，更费客户端的资源，cpu,网络流量，系统电量。
push推送图
1.自己搭建推送服务器
好处：功能好，性能好
缺点：成本高
2.调用第三方推送平台
手机厂商：小米推送，华为推送
第三方平台：友盟推送，极光推送，云巴、
BAT大厂推送：阿里云移动推送 腾讯信鸽推送 百度云推送
push推送设置
针对不同的用户群体：全部用户 部分用户 特定用户
手机端设置：
屏蔽推送，是否接受通知
push测试的关注点
1. push消息是否按指定业务规则发送
2. 当push消息针对特定用户，用户是否会收到push消息
3. 设置了屏蔽推送消息，用户是否会收到
4. 收到Push消息，是否能正常打开
5. APP在前台使用时，收到push消息如何提示
6. APP在后台使用时，到Push消息如何提示
7. APP离线，是否能收到push消息
15，用户体验测试
关注点
● UI测试
对照UI设计文档，检查每个页面，窗口，布局，风格等
注意：图片，按钮（选中效果，没选中效果），字体大小，颜色，居中对齐
● 易用性测试
是否有空数据界面设计，引导用户去执行操作
菜单层次是否太深
交互流程分支是否太多
界面按钮是否布局合适，点击范围是否适中
软硬件交互：back，home
● 横屏竖屏
app所有页面横屏竖屏切换是否正常
如果有表格更应该着重关注
● 手机应用的其他辅助
放大字体，语言转换，多点触碰等功能
iOS 和安卓的区别
1 . Android长按home键呼出应用列表和切换应用，然后右滑则终止应用；
2. 多分辨率测试，Android端20多种，ios较少；
3. 手机操作系统，Android较多，ios较少且不能降级，只能单向升级；新的ios系统中的资源库不能完全兼容低版本中的ios系统中的应用，低版本ios系统中的应用调用了新的资源库，会直接导致闪退（Crash）；
4. 操作习惯：Android，Back键是否被重写，测试点击Back键后的反馈是否正确；应用数据从内存移动到SD卡后能否正常运行等；
5. push测试：Android：点击home键，程序后台运行时，此时接收到push，点击后唤醒应用，此时是否可以正确跳转；ios，点击home键关闭程序和屏幕锁屏的情况（红点的显示）；
6. 安装卸载测试：Android的下载和安装的平台和工具和渠道比较多，ios主要有app store，iTunes和testflight下载；
7. 升级测试：可以被升级的必要条件：新旧版本具有相同的签名；新旧版本具有相同的包名；有一个标示符区分新旧版本（如版本号），对于Android若有内置的应用需检查升级之后内置文件是否匹配（如内置的输入法）
另外：对于测试还需要注意一下几点：
1. 并发（中断）测试：闹铃弹出框提示，另一个应用的启动、视频音频的播放，来电、用户正在输入等，语音、录音等的播放时强制其他正在播放的要暂停；
2. 数据来源的测试：输入，选择、复制、语音输入，安装不同输入法输入等；
3. push（推送）测试：在开关机、待机状态下执行推送，消息先死及其推送跳转的正确性；应用在开发、未打开状态、应用启动且在后台运行的情况下是push显示和跳转否正确；推送消息阅读前后数字的变化是否正确；多条推送的合集的显示和跳转是否正确；
4. 分享跳转：分享后的文案是否正确；分享后跳转是否正确，显示的消息来源是否正确；
5. 触屏测试：同时触摸不同的位置或者同时进行不同操作，查看客户端的处理情况，是否会crash等
黑盒测试方法
(一)等价类划分法
等价类划分法是一种典型的、重要的黑盒测试方法，它将程序所有可能的输入数据划分为若干个等价类。然后从每个部分中选取具有代表性的数据当做测试用例。测试用例由有效等价类和无效等价类的代表数据组成，从而保证测试用例具有完整性和代表性。使用该方法设计测试用例主要有两个步骤：(1)确定等价类；(2)生成测试用例。
(二)边界值分析法
边界值分析法是对程序输入或输出的边界值进行测试的一种黑盒测试方法。实际的测试工作证明，考虑了边界条件的测试用例比那些没有考虑边界条件的测试用例具有更高的测试回报率。这里所说的边界条件，是指输入和输入等价类中那些恰好处于边界、或超过边界、或在边界以下的状态。
(三)因果图法
因果图法也是较常用的一种黑盒测试方法，是一种简化了的逻辑图。因果图能直观地表明输入条件和输出动作之间的因果关系，能帮助测试人员把注意力集中到与程序功能有关的输入组合上。因果图法是一种适合于描述对于多种输入条件组合的测试方法，根据输入条件的组合、约束关系和输出条件的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况
(四)错误推测法
错误推测法是基于以往的经验和直觉，参照以往的软件系统出现的错误，推测当前被测程序中可能存在的缺陷和错误，有针对性地设计测试用例。
用错误推测法设计测试用例的基本思想是：列举出程序中可能犯出现的错误或容易发生错误的特殊情况的清单，然后根据清单和已经设计好的测试用例来编写特定的测试用例。例如，程序中出现的输入数据为“0”或者字符为空就是一种错误易发情况；在出现输入或输出的数量不定的地方，数量为“没有”和“一个”也是错误易发情况。特别需要注意的是，在阅读规格说明时联系程序员可能做的假设来确定测试用例，测试人员要站在用户的角度来考虑输入信息，而不必去管这些信息对于被测程序是合理还是不合理的输入。[2]