功能测试复习

一。测试流程

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

十。微信小程序概念

十一。微信小程序与APP对比