一。测试流程
1.需求评审 确保各部门需求理解一致
2.计划编写 测什么，谁来测，怎么测
3.用例设计 验证项目是否符合需求的操作文档
4.用例执行 项目模块开发完成开始执行用例文档实施测试
5.缺陷管理 对缺陷进行管理的过程
6.测试报告 实施测试结果文档
1.需求评审：
1.评审之前：阅读需求，记录疑问点
2.评审形式：一般以会议的形式展开(产品经理、项目经理、 开发人员、测试工程师）
3.评审目的：明确测试范围，站在不同角度对需求进行查漏补缺，各部门对需求理解一致
4.评审产出：各部门工作内容，评审通过的需求文档
2.测试计划：
编写测试计划目的： 指导测试组成员进行工作和让测试组以外的项目成员了解测试的工作
编写人员：项目测试负责人
计划类型：项目总计划/个人执行计划
核心内容：测试对象和范围/测试进度安排/准入准出标准
二。业务流程测试
1.业务流程定义：客户使用软件的过程中，为了达成自身的所想 要的目的，按照指定的顺序去操作软件的功能，这样的操作过程叫业务流程
2.业务流程来源：
正常情况：一般由产品提供
特殊情况：测试人员自己画
3.业务流程测试方法：流程图
流程图法也叫场景法，是用流程图描述用户的使用场景，然后通过覆盖流程路径来设计测试用例。 适用场景： 在业务场景中涉及多功能的组合逻辑
使用步骤：
根据流程图找出路径
编写测试用例（从开始到结束为一条路径，有多少条路径就有多少条用例）
流程图法测试不需要深入功能内部详细测试，主要测试流程
业务流程测试完成后需要针对单模块进行更加详细的测试
三。单模块测试
1.单模块测试内容：
1.功能
2.UI界面性
3.兼容性
4.易用性
5.性能
6.安全
以用户角度，待测试软件的可见功能（需求说明书）
产品原型图（UI/UE设计稿）所绘制的效果（显示与布局）
以用户角度，待测试软件的可见功能（需求说明书）
以用户角度，检查系统是不是很好操作，很好上手
2.单模块功能测试步骤：
1.熟悉需求
2.提取测试点，编写测试用例
3.测试用例评审
4.执行测试用例
5.记录执行过程，登记跟进缺陷
6.测试报告
1.熟悉需求：
需求来源：需求文档/UI或UE设计稿（产品原型图）/已存在的软件界面
怎么熟悉需求：阅读并理解文档描述，操作已存在的软件界面，能构造出对应场景
熟悉程度：说清楚用户使用该功能时能做什么？ 能列出该模块下的功能点有哪些？
2.用例编写:
根据测试点逐条编写测试用例
将分析设计后的测试点，进行逐条覆盖，转化为测试用例（8要素形式）
1条 测试用例尽可能多的覆盖 多个 正向测试点（1对多）
1条 测试用例只能覆盖 1个 逆向测试点（1对1）
用例设计编写格式说明
用例编号：项目_模块_编号
用例标题：预期结果（测试点）
模块/项目：所属项目或模块
优先级：表示用例的重要程度或影响力P0~P4（P0最高）
前置条件：要执行此条用例，有哪些前置操作
测试步骤：描述操作步骤
测试数据：操作的数据，没有的话可以使用/表示空
预期结果：期望达到的结果
3.用例评审
评审目的：1.查漏补缺 2.与开发人员实现方案保持同步
评审形式：1.会议形式 2.交叉评审
评审结果：项目内一致认可的测试用例
4.执行测试
何时执行：1.冒烟测试通过 2.按照测试计划约定的时间 3.测试环境以及准备就绪
用例执行方式：1.逐条执行 2.按优先级执行 3.按模块重要性逐一执行
执行结果记录：
测试通过----PASS
测试失败----FALL
测试阻塞----BLOCK
功能缺失----N/A
5.缺陷跟进与管理
1.登记缺陷：缺陷要保证能够复现，一个缺陷报告只描述一个 BUG
2.跟进缺陷：每日跟进禅道上缺陷情况。优先级较高的缺陷要及时驱动开发进行修复
目标：缺陷的修复速度不能影响测试进度和上线时间
3.回归缺陷：对于禅道状态为已解决的问题进行再次测试 。回归测试时一定保障测试环
境包含了修复缺陷的代码。回归测试通过则关闭，不通过则重新打开
6.测试报告
报告核心内容：
1.测试过程回顾：测试过程中实际使用的环境、资源、进度、配置等信息。
2.测试统计分析：测试过程中产生的数据，主要是测试用例和缺陷报告的数据。
3.测试结果确认：测试结果的模块确认和整个产品系统的整体结果确认。
4.测试总结改进：测试过程中好的地方和不足之处的总结，为后续项目提供经验。
测试报告需要测试执行人员最终汇总编写，要求实事求是，是对产品质量的承诺。
四。抓包
1.说明：客户端向服务器发送请求以及服务器响应客户端的请求，都是 以数据包 来传递的。
2.抓包 （packet capture）：通过工具拦截客户端与服务器交互的数据包
常用抓包工具有哪些：
Ø Fiddler
Ø Charles
Ø Firebug等
3.Fiddler 是一个 http 协议调试代理工具，它能够记录并检查所有你的电脑和互联网之间的 http 通讯。
4.常见的三种应用场景
1.定位前后端Bug
2.弱网测试
3.绕过界面限制直接测试服务器
5.定位前后端 Bug 的步骤
① 如果抓不到请求，显然是前端问题。
② 如果有请求但是没响应，那就是后端的问题；
③ 如果有请求也有响应，需要查看响应信息，如果返回报错了，则需要具体分析报错内容
6.
7.弱网测试
弱网环境下可能会出现的异常
Ø 上传文件时进度卡住不动
Ø 登录不上或者登录后立即掉线
Ø 响应过程中页面控件可点击，导致崩溃
Ø 搜索不响应，多次点击后结果显示总在刷新被替换
弱网测试步骤：
1.设置要模拟的网络速度
2.开启网络延时
3.测试项目
弱网延迟时间计算公式：
延时ms=[1KB/(速率bps/8)B/s]*1000
单位换算关系：( B:字节 b:位)
Ø 1B = 8b
Ø 1B/s = 8b/s(或1Bps=8bps)
Ø 1KB = 1024B
Ø 1KB/s = 1024B/s
Ø 1MB = 1024KB
Ø 1MB/s = 1024KB/s
Ø 1Mbps=1000 000bps
Ø 1M带宽：速率为1Mbps
Ø 1s = 1000ms
例如：
上行：[1/(2.7/8)]*1000=2962ms
下行：[1/(9.6/8)]*1000=833ms
为什么 要绕过界面限制做测试？界面限制导致部分异常数据无法输入
绕过界面限制直接测试服务器步骤：
1.设置断点
2.修改请求
3.修改响应
请求之前设置断点：
修改请求
设置断点：响应之后
修改响应
七。互联网公司知识
1.迭代模型
速度不同：开发模型不一样
传统行业：瀑布模型
互联网行业：敏捷模型
敏捷开发（scrum）模型
Scrum ： 是一个敏捷开发框架，是一个增量的，迭代的开发过程
迭代（sprint）：项目开发过程中最小周期，每个sprint周期建议为2-4周。在scrum框架 中，整个开发周期包括若干个小的迭代周期。
产品功能列表（ Backlog ）：在 Scrum 中，将产品 Backlog 按 商业价值 排出需求列表
Scrum 三种角色：
Product Owner(产品负责人 ) :定义需求，进行需求排期
Scrum Master(项目经理 ) :管理项目，确保scrum 顺利执行
Dev Team( 开发团队 )
实现客户需求
成员：开发、测试、UI 。
团队人数：一般5 人到 9 人。开发测试比一般为： 3:1 — 5:1
2.发布策略
3.APP软件包类型
4.APP客户端（内部）发布平台
在实际测试工作中，为了方便测试程序包的安装和管理，可以使用一些应用内测分发平台。如：蒲公英、Testlink等
操作步骤：
Ø 开发将应用测试包上传到这些平台上
Ø 平台可以生成对应的二维码
Ø 测试直接扫码进行应用安装
5.APP客户端（线上）发布平台
产品测试完成后要在线上进行发布，让用户进行下载使用。下面是安卓和 IOS 应用常用的发布平台和渠道
Ø 安卓应用：豌豆荚、应用宝、 360 手机助手、各类手机品牌商城等；
Ø IOS 应用： 主要有 App store 、 iTools
l 操作步骤：
Ø 开发者账号注册，申请在发布平台（各种应用商店）上架
Ø 针对不同的发布平台，在软件包中加入对应的平台ID（渠道ID），上传到发布平台
Ø 平台审核通过后，用户即可在应用商店中下载
l 一般线上发布过程，由开发人员负责。
l 在软件包加入平台ID后，上传到发布平台时，需要测试人员验证核心的业务功能
六。APP测试基本知识
1.APP应用环境与web项目环境对比
相同点：1. APP和web使用的后端服务器是相同的
2. 前后端都使用HTTP协议进行交互（也有部分APP用socket来交互）
不同点：1. APP是C/S结构，web浏览器是B/S结构
2. APP前后端交互的数据格式以Json 为主，web前后端交互的数据格式为Json/HTML都有
C/S结构（Client/Server结构）是一种分布式计算模型，其中客户端应用程序和服务器应用程序通过网络进行通信。在C/S结构中，客户端负责处理用户界面和用户输入，并向服务器发送请求，而服务器负责处理客户端请求并提供相应的服务。这种结构通常涉及两个独立的应用程序，即客户端应用程序和服务器应用程序。
B/S结构（Browser/Server结构）是一种Web应用程序的架构模式。在B/S结构中，客户端使用Web浏览器作为用户界面，而服务器提供网站的功能和服务。客户端通过浏览器向服务器发送请求，并接收由服务器生成的HTML等响应。这种结构使得用户可以通过浏览器访问服务器上的应用程序，而无需在本地安装任何特定的客户端软件。
总结：
- C/S结构是一种分布式计算模型，涉及独立的客户端和服务器应用程序之间的通信。
- B/S结构是一种Web应用程序的架构模式，涉及通过浏览器访问服务器上的应用程序。
- C/S结构和B/S结构在应用场景和通信方式上存在差异，选择哪种结构取决于具体的需求和应用程序的特点。
JSON(JavaScript Object Notation) 是一种轻量级的数据交换格式。采用完全独立于编程语言的文本格式来存储和表示数据。
JSON最常用的格式是对象的键值对。例如： {"firstName": "Brett", "lastName": "McLaughlin"}
2。APP项目测试内容介绍
功能测试：1.业务测试 2.功能模块测试
专项测试：1.安装卸载升级 2.push消息推送 3.交叉事件测试 4.用户体验测试 5.兼容性测试
性能测试：1.CPU、内存占用 2.启动速度 3.流量、电量消耗 4流畅度 5稳定性
七。APP专项测试
1。安装卸载升级 2.兼容性 3.push消息推送 4.交叉事件 5.用户体验
八。APP性能测试
1.SoloP性能测试
2.APP性能指标
1.内存 2.CPU 3.流量 4.电量 5.启动速度 6.流畅度 7.稳定性
3.ADB命令
4.Monkey
九。APP抓包--Charles
十。微信小程序概念
1.微信小程序基础
“触手可及”“即用即走”
概念：简称小程序 ， 英文名称 Mini Program，是依附于微信而无需 再次下载安装的应用程序
实现了应用“ 触手可及 ”的梦想， 用户扫一扫或搜一下即可打开应用
特点：无需下载，即用即走 功能丰富，清爽体验，流量大，易聚变（传播）
应用领域：零售，出行，医疗
使用角度覆盖：衣食住行用
2.微信小程序设计
基于微信小程序轻快的特点，旨在微信生态体系内，建立友好、高效、一致的用户体验。
更多参见微信官方链接: https://developers.weixin.qq.com/miniprogram/design/
基于微信小程序轻快的特点，旨在微信生态体系内，建立友好、高效、一致的用户体验
小程序优点：1.导航明确，来去自如 每个页面的导航指向清晰，有路可退
2.流程明确，避免干扰 集中精力聚焦当前任务，保持流程使用
3.重点突出，主次分明 简明扼要，重点突出，无过多干扰
4.符合预期，降低难度 根据用户的使用习惯，降低学习使用成本
5.减少等待，明确反馈 需要等待过程中保持动态效果，反馈形式多样
6.异常处理，和谐统一 异常提醒清楚，保持页面风格统一
小程序不足：业务逻辑：过于负载逻辑不存在不可控的异常问题
页面数量：每个应用最多能打开5个页面（包含页面跳转）一般设计不超过三级页面
文件大小：小程序源码文件有大小限制（目前总包大小不超过20M，单个分包不超
过2M)
3.微信开发者工具
版本：
开发版 开发版：内部最新版本稳定性欠佳。
预发布版
预发布版：已通过微信内部测试，稳定性一般。
稳定版
稳定版：使用多，基本稳定（第三方开发和测试使用的首选）。
支持windows和macos版本
工具下载链接地址：
https://developers.weixin.qq.com/miniprogram/dev/devtools/download.html
模拟器：开发者工具模拟手机显示当前项目运行后状态显示。
编辑器：编辑代码的区域，提供快捷显示 / 关闭项目代码区域。
调试器：调试代码的区域，提供快捷显示/关闭调试区域。
编译：将源代码转换为计算机可识别的机器码过程（配合清缓存一起使用）。
4.微信小程序项目结构
5.小程序和APP的对比
微信小程序：1.简单，无需安装。2.无需注册，只需授权。3.兼容各种手机（与微信有关）4.开发成本费用低。5.超10亿+的流量入口
APP：1.复杂，需要安装。2.需要注册登录。3.不同移动操作系统需要分别开发4.开发成本费用高5.自行推广引流
6.微信小程序测试准备
获取微信提供的相关服务的必备账号 密码（APPID和APPSecret配合使用）
APPID： 验证小程序的合法性（对外公开）
小程序的唯一标识 （“身份证”）
APPSecret： APPID对应的密码（私有的）
确保不能泄露
正式账号申请参见链接：微信公众平台（ https://mp.weixin.qq.com/ ）
l 个人版：需要个人身份证件（身份证）
l 企业版：需要企业营业执照、法人身份证件等信息
6.小程序非功能性设计
1.兼容性测试：兼容微信版本（当前和上一个）设备分辨率（UI元素自适应显示）
2.易用性测试：根据实际用户遵循其专业性，结合功能验证其体验性
3.弱网测试：1.WIFI网络正常使用 2.移动网络正常使用 3.WIFI和移动网络切换正常使用
4.性能测试：首次加载事件，刷新白屏时间，设备CPU和内存耗费比例
测试要求：
1.用例要求：大多数非功能测试不需要单独编写用例。可以之间使用业务流程用例结合功能点 验证非功能点
2.人员要求：非功能测试一般要求测试人员测试
部分非功能测试需要有专业人员测试（UI布局，性能指标）
3.时间要求：一般是在功能测试完毕后，进行非功能测试
用例提取执行：
1.根据测试计划安排.根据测试计划安排，结合开发实际提交 的模块范围选取对应模块用例进行一一 执行，并记录执行过程及结果。
2.根据实际提交执行：根据开发实际提交时间，沟通并修正测试 计划，并按照提交模块范围选取对应模块 用例进行一一执行，并记录执行过程及结果。
3.根据业务重要程度提交：根据测试进度，单模块测试通过后， 按照业务流程要求，结合用户实际使 用场景进行业务流程的全面测试，并记录执行过程及结果。
4.按照验收优先级执行：最终根据用例优先级提取关联用户实际场景的业务用例，站在用户使用角度进行执行，直到验收通过。
提交bug的原则：1.可复现2.唯一性（一个bug报告对应一个独立的问题3.规范性（符合公司规范）
测试报告总结：1.测试过程回顾（测试过程中实际的环境，资源，进度，配置等）
2.数据统计分析（测试过程中产生的数据，主要是测试用例和缺陷报告的数据）
3.结果确认（测试结果的模块确认和整个产品系统的整体结果确认）
4.总结改进（测试过程中好和不好的地方总结，为后续项目提供经验）
