需求分析：

• 整体流程图：

需求提取 -> 需求分析 -> 需求评审 -> 更新后的测试需求跟踪xmind

• 分析流程：

1. 需求提取：

• 分析依据（包括：需求矩阵、产品交互图、需求说明书）

• 获取需求的纬度

1. 客户价值

• 可以为客户带来哪些价值？

• 可以解决哪些问题？

• 根据以上问题定位功能是否合理

1. UI功能 - 展示功能

2. 模块关联-历史模块

• 新功能模块关联

• 考虑是否关联？耦合部分是否需要支持？

1. 客户使用场景-部署方式

• 网络特性

• 客户使用服务器常见外设

1. 性能参数-性能要求

• 网卡最低速率

1. 硬件支持

• 输出（提取最原始的测试需求）

2. 需求分析：

1. 分析依据（五维分析）

• 用户场景

1. 功能是否和场景强关联

2. 网络拓扑能否满足客户需求

3. 和竞争对手比较差异

4. 功能是否能满足客户实际应用场景

5. 是否考虑了用户的实际操作

• 明确性

1. 范围明确性（参数、类型长度范围）

2. 清晰性限制等范畴

3. 无法预知影响的需求提出进行确定，风险

• 二义性

1. 概念模糊【大概念、第三方支持、与上个版本相同】

2. 支持与不支持等范畴

3. 一个需求描述能出现多种理解

• 完整性

1. 需求一致性【用户需求、需求规格、需求矩阵三者是否同意】

2. 需求完整【隐形需求】

3. 关联性【与新老功能、与外置软件设备】

• 可测试性

1. 实现测试需要的工具、方法【调试、接口命令】

2. 定位方式【日志等形式观察】

3. 复杂环境、容量边界、操作时过程不可见

• 输出

1. 测试需求跟踪

2. 缺陷预防bug

3. 工具需求

4. 整理出明确的需求点

5. 测试地图

• 分析思路误区：需求和实现的区别【现有需求才有代码实现，不能把代码实现当作需求】

• 需求分析的意义

1. 明确产品给客户带来的价值

2. 明确产品支持和不支持的功能

3. 明确产品各个功能的约束性

4. 知道开发实现功能

5. 知道测试分析和产出测试点

测试设计：

• 测试分析：

1. 我们需要做什么？

• 把明确的需求点转换成测试项

• 缺陷预防

2. 怎么做？

• 整体模块分析

• 逻辑分析【这一点主要是从产品实现的原理上去分析可能的影响】

1. 怎么做？

• 开发的设计文档

1. 补充和挖掘测试点

• 全部服务的异常监控、服务重启

• 各类存储对空间的占用、占满、是否需要做存储的接口测试

• 所有类型的管理员、操作权限测试、支持的多少管理员并发操作

• 对流程图的挖掘 -- 流程图全部流程测试、流程图重要的节点异常测试

• 对状态的挖掘 -- 所有状态的相互转化需要覆盖全、状态转化是否合理、每一个状态下哪些操作可做哪些不可做，多个状态是否可以共存

• 对关联项的挖掘 -- 流程进展到哪一步关机重启/服务重启、和备份配置的关联，和操作日志的关联等等

• 任务的并发操作测试、是否可配置、是否会出现性能不足，是否符合用户场景

• 异常处理机制测试，异常处理机制是否完善

• 指标测试，开发的指标设计是否合理

1. 修正不合理的需求

• 如何分析

1. 逻辑原理：

• 该模块是否涉及到一些全新的概念(比如我们的 bbc 全量包)，需要明确?

• 该模块包括哪些服务?

• 该模块涉及到哪些存储技术(如 mysql、dap、redis)?具体怎么存储的?占用大小如何?

• 该模块的操作流程有哪些?是否有子流程图?

• 该模块是否有多个状态的转化?是否有明确的状态转化图?

• 该模块对多个管理员是否区分，管理员权限如何设计?

• 该模块是否有一些特殊的操作限制?操作限制是否有明确的表格?

• 该模块的任务是否有并发需求?并发的设计?

• 该模块的所有指标如何?

• 该模块是否有异常处理机制?在设备各种异常时，该模块的设计是否满足能稳健运行?

1. 场景分析

• 从用户的使用习惯和使用方法去分析影响

• 检查当前案例是否覆盖到用户场景

1. 关联测试分析：

• 考虑你的模块所在整个系统的地位，分析上下游的影响

• 对老功能的影响

1. 经验补充分析

• 版本分析

• 模块分析

1. 输出

• 测试项

• 补充测试地图

• 测试设计：

1. 需要做什么？

• 把测试项细化成测试点 

• 缺陷预防 

1. 需要做什么？

• 基本设计方法

1. 等价类划分法【将输入域和输出域划分为不同的等价类，等价类之内的操作结果相同】，使用范围：显示输入框输入

2. 边界值法【需要结合等价类划分法方法，在划分出来的等价类选取有代表性的值】

3. 正反对比【一般会放到同一个用例里覆盖】

4. 字符多样性【考虑不同字符的输入】

5. 测试类型

• 产品专项测试

• 正交组合设计【正交矩阵，覆盖各个参数间的组合情况】

• 业务逻辑设计【根据业务设计测试点】

1. 输出：

• 基本测试点

用例设计：

1. 需要做什么？

• 把测试点用文字完整表述出来

1. 怎么做？

• 功能用例框架：

1. 模块框架模板

• 需求类

1. UI测试【如果UI用例可以被功能用例覆盖，这里可以不写】

• 公共测试类：

1. 链接

• 选中会有高亮显示

• 点击跳转到对应页面

• 当前页面对应的名称下有区别显示

1. 翻页

2. 按钮

3. 输入框【这个功能用例一般可以覆盖】

4. 下拉框

5. 排序

6. 条目选择【这个很重要，第一次集成测试一定要保证每个选项都是有效的】

7. 搜索

• 所有字符类型验证

• 为空验证

• 模糊搜索

• 精确搜索

• 搜索不存在的关键词

1. 刷新

• 验证自动刷新

• 验证手动刷新

• 验证持续刷新

1. 拖动

2. 移动

• 点击下移，往下移动一行

• 点击上移，往上移动一行

• 最上面的行，上移不能点击，图标灰色

• 最下面的行，下移不能点击，图标灰色

1. 功能测试

• 测试点：

1. 功能基本流程逻辑覆盖

2. 业务流程多样性覆盖

3. 用户操作习惯的多样性

4. 模块配置的多样性

5. 数据流的多样性覆盖

• 测试目录

1. 平级分类相对独立

2. 上下级分类有关联

3. 下级从上级细化而来

• 关联类：

1. 模块与模块之间的

2. 模块与功能之间

3. 模块与硬件之间

• 场景类

1. 建模思路

• 部署方式【比如用户一般使用2主机还是3主机部署集群】

• 数据流

• 业务流【用户是怎么使用申请工单，是怎么样的完整流程】

• 操作顺序【创建云主机的顺序之类的】

• 配置方法【用户一般怎么配置使用静态路由】

• 使用时间【用户会不会连续长时间开启云主机】

• 用户角色【一般那些角色做什么操作】

1. 用户操作的设计方向

• 最常用的功能

• 最容易出现网上问题的功能

• 典型客户使用的功能

• 版本的性能验证

• 专项类

1. 兼容性

2. 可靠性【测试产品在异常情况下能否正常工作或者是恢复正常工作，可靠性重点测试对模块自身处理的覆盖】. 补充：容错性测试【测试系统在非正常操作、非正常的外部环境下是否能够处理错误和正常运行】

eg：

• 针对数据库的测试：【磁盘空间不足、数据库文件损坏、无读写数据权限、写数据时断电、写数据时强制关闭mysql、读写速度】

• 针对网络设备：【网络中有攻击数据、丢包时延大、IP冲突、网络线路断开、同时掉电】

• 针对程序：【 客户端进程被手动停止、设备后台资源cpu、内存占满】

  3. 安全性【主要是验证程序有哪些缺陷可能会造成安全方面的问题】

eg：

• 密码加密方式【什么时候用明文，什么时候用密码显示】 

• 隐私数据隐藏【用户的隐私显示】

• 设备的完整目录【完整的目录会增加后台被攻击的危险】

• 文件上传功能【检查上传的文件类型；限制上传文件的权限】

• 防暴力破解【对于连线认证之类的操作要冻结、禁用其连续错误尝试操作】

  4. 脚本测试

• 使用注意细节

1. 文件夹以01-xx，02-xx区分开

2. 每个文件夹下不能超过10个用例

3. 每个测试用例一个测试点

4. 在02-功能测试的描述中，备注说明功能测试框架的思路

• 用例整体规范

1. 用例标题【好的标题需要准确的表达你的测试目的、要测试的测试点】

eg：

1. 测试。。。

2. 验证。。。

3. 。。。的测试

4. 与。。。的关联测试

5. 。。。的异常测试

6. 。。。的兼容性测试

• 用例属性

1. 测试环境【默认的前置条件可以不用写；写的前置条件要准确，不要写的模糊】

2. 测试方法

3. 优先级

• BVT【最最最基本的功能】-BVT(10%)：模块最基本的功能验证(含常用部署、基本关联)，推荐1级用例的20%左右

• level1【基本操作、基本场景】-Leve1(30%)：基本需求点，基本逻辑，基本可靠性，基本关联，基本用户场景

• level2【比较少见的正常操作】-Leve2(40%)：常见功能/逻辑细化点/专项细化点，常见关联/容错/边界值/用户场景

• level3【异常操作；后续不需要再执行】-Leve3(20%)：错误提示、极少测试的用例、非常见部署方式/用户场景/容错/边界值等

1. 用例格式

• 前置条件

• 测试步骤【单个用例全部步骤不能超过8步】

• 后置条件【不是必填的】

• 预期结果

• 备注【不是必填的】

1. 语言规范

• 语言简练

• 不能出现模糊的形容词【比如说大概、可能、很多、差不多】

1. 可维护性

• 灵活运用模块备注

1. 设计原则

• 目的明确【一个用例对应一个测试点；测试步骤和测试目的一致】

• 用例效率

1. 保证设计出来的用例10分钟内可以执行完成；

2. 用例需要的环境可以整理出来，然后写到模块备注中，让执行者先准备好环境一次性执行全部用例；

3. 执行的时候按照测试集方式来执行；

4. 有工具可以实现的用例不要采用脚本方式实现。

3. 测试步骤：

• 用户角度

1. 设计的用例要符合用户的操作顺序和操作习惯

2. 符合用户的使用环境

3. 符合用户的配置

• 可执行

1. 不要出现那种用例设计没有错，但是执行起来很复杂或者是依赖环境很夸张的用例

• 正反对比

1. 这一点很重要，很多时候我们会把有正反操作的用例分开写，其实是可以合在一个用例里面写

• 强弱关联

1. 对于强关联的步骤一定要写清楚

2. 对于弱关联的可以备注或者是不写

• 测试用例不能出现操作步骤

1. 直接写需要做的操作就可以了

4. 预期结果

• 用户角度：

1. 反思用户期望操作完会有什么结果

2. 反思客户最关注的测试点

• 可检查

1. 预期结果要可以观察到，不要写的很模糊

2. 把重点检查的检查点覆盖到

• 用例编写口诀

1. 强弱正反之业务

2. 重点突出之效率

3. 目的明确之语言

4. 框架覆盖之检查

5. 逻辑场景之经验

用例执行和回归

• 用例执行标准

1. 执行优先级

• 建议用例级别执行顺序【bvt、leve1、leve2、leve3】

• 建议用例区域执行顺序【基本功能、高风险区域、复杂逻辑优先测试】

2. 用例执行状态

• Not Complete：用例无效、用例错误、无测试环境等过程状态

• Passed：执行通过

• No Run：默认状态，未执行

• N/A：无须执行，需填写备注，需处理；

• Failed：执行失败，需填写BUGID

• Blocked：被其他问题阻塞

• Not Modify：由Failed状态而来，用例发现的bug不修改，bug为halt、Won't Fix

3. 自动化用例

• 覆盖全部bvt用例

• 大部分level1（基本的功能一定要覆盖）

4. 执行技巧总结

• 执行前：

1. 首先要看执行备注（模块备注、文件夹备注、用例备注），了解这个模块是做什么的，需要注意哪些点和执行的辅助命令和工具

2. 然后把一个模块下的所有用例大概过下，能一起执行的可以一起执行

• 执行时：

1. 增改查删顺序执行用例

2. 一类的用例一并执行，比如说测试多种不同的nfv设备的授权之类操作，虽然每个nfv设备都是一个用例，但是都可以一起操作

3. 执行UI限制的用例，可以把限制条件整理出来，做成模版，直接套用

4. 执行的时候关注的测试点，遇到测试点很简单但是测试步骤很复杂的，可以异测试点测试为主，和用例编写的人协商优化一些执行步骤，或者是先自己优化再备注，后面统一和用例执行人讨论可不可以这样优化

5. 不理解的用例可以问执行过的人或者是写用例的人

6. 耗时或者是异常的用例【可以在别人休息吃饭的空闲时间去执行，不要影响公共测试环境】

• 执行后

bug回归标准

1. bug分类：

• low【UI问题、体验问题】

• medium【基本功能问题】

• high【性能问题】

• urge【宕机、无法使用、数据丢失、业务无法使用】

1. 补充用例

• 在执行用例或者是回归bug的时候遇到level1级别的用例没有覆盖的一定要补充用例覆盖

• 用例覆盖点过多，把几个级别的用例覆盖了，需要拆分用例

1. 质量分析

1. Bug的类型主要是哪几类？

包括：功能问题,性能问题,稳定性,可靠性,关联,兼容性,需求方案等改进,易用体验性,异常容错；分析出主要类别后，在进一步分析各个类别产生的根本原因，比如用例编写问题（测试步骤达不到测试目的，用例有歧义等）；改动引发（是需求、方案变动带来的还是纯粹的改一个bug引发另一个？）

2. 模块质量分析

• 缺陷分析

• 用例质量分析

• 测试漏侧分析

• 需求变更分析

• 模块改动分析

• 发散测试分析

• 重点难点分析

• 开发人员评价

• 回归测试分析

bug定位

• 前端定位：

1. 工具

谷歌浏览器

network

检查参数【是否准确、是否有缺少】

检查响应时间【查看加载时间】

检查响应内容【查看响应内容是否有缺少{缺少的话是后端返回的问题；如果没有缺少的话有可能是前端处理的问题}】

source【在测试用例的时候可以打开source调试，有一些页面的错误可以被俘获到】

postman【模拟请求发送是否正常】

• 后端定位：

1. 后台报错日志

• 方法一：

cd日志文件所在的目录 | grep -rn "关键词"

根据行号查看异常日志内容 ：tail -n +203915 文件名 | head -n 200行 （显示文件中第203915行之后的200行）

• 方法二：

less 具体的目录文件 #进入指定的目录文件

然后 /关键词

2. 数据库【mysql】

非技术方法

• 对比法【比如说acmp上私有云的功能都是沿用acloud的功能，想判断acmp上的问题可以对比查看acloud上是不是有也有这个问题，如果有很可能是acloud引入的问题】

• 客户导向法【对于一些新功能，我们可以根据用户场景去判断这个功能实现是属于正常的操作还是不合理的设计】

• 逻辑分析【有时候开发自己设计的产品实现原理不一定是合理的，可以分析下实现步骤，看看是不是有问题】

总结下排除思路

• 判断是否是必现问题【先查看是否是必现的【到别的环境去试下问题是否能必现】；非必现的问题【排查网络问题；资源不足的问题】】

• 判断是我们平台本身的问题

• 判断是前端的问题还是后端的问题【抓包查看请求，请求中的返回数据是否显示完整。显示完整，那么一般就是前端没有处理好数据显示，找前端看看；如果返回数据有空缺或者是不完整，那就找后端看看】

作者：小嘉欣_sunny

原文链接：https://www.cnblogs.com/sunshine-blog/p/9782201.html