测试基本功
软件工程基础
软件概述
软件生命周期
问题定义 → 需求分析 → 软件设计 → 软件开发 → 软件测试 → 软件维护 → 淘汰
软件开发模型
- 瀑布模型 线性流程
- 快速原型模型 先出原型，确认后再开发
- 迭代模型 拆分组件逐个开发测试
- 螺旋模型 计划/风险分析/实施/客户评估
- 敏捷模型 子项目+迭代
- Scrum 产品负责人(Scrum Master)分组划分优先级管理
- Kanban 可视化软件「看板卡」，随时更新
ISO/IEC 9126:1991 软件质量标准
- 功能性
- 可靠性
- 可使用性
- 效率
- 可维护性
- 可移植性
测试分类
测试阶段分类
单元测试 → 冒烟测试 → 集成测试 → 系统测试 → 验收测试
**单元测试**
单元测试是第一步测试，由开发人员自测，需要理解每个函数、每行代码的含义，是 白盒测试 的一种。单元测试对软件设计的最小单位——程序模块进行正确性检查，验证软件是否满足需求与设计。
需要从程序内部结构出发设计测试用例，例如对某函数的每一种输入查看输出。
**冒烟测试**
名称来源：测试电路板能否正常工作的需求是测试工程师诞生的起源，而在电路板测试的第一步就是给它上电，检查电路能否正常接通。如果线路出现短接或者元器件损坏等重大问题时，电路板就会因发热而冒烟。
系统可以正常运作是一切测试的基础。
冒烟测试指先跑一遍程序，确认程序的主要系统都可以运行，不存在卡死、阻断等影响验收的缺陷，是在构建新版本后，进行正式的测试验收之前进行的最基本的测试。
可以认为冒烟测试是测试测试工作能否正常进行的测试。
**集成测试**
集成测试将单元测试通过的程序模块组合在一起测试。
简单来讲就是将程序模块放在一起，查看各个模块之间的相互影响。
需要着重检查的有以下 2 点：
- 模块内出现的会影响全局的变量
- 模块的输出是否符合耦合模块的输入规范，以及对其他所有模块的影响
**确认测试**
确认测试一般由第三方机构进行，作用是验证软件功能和性能是否和用户要求的一致。在系统测试或者交付之前进行，以保证做出来的功能与需求相符。
确认测试并非必要的测试流程，大部分在外包制作交付的时候才会出现。
**系统测试**
将软件放在实际环境中运行，并和其他系统成分组合在一起进行测试。
系统测试可以认为是将所有模块都组合在一起的集成测试。相比于集成测试，系统测试还需要注意程序外部带来的影响，比如网络情况、硬件性能、操作人员的不规范操作、数据库调用读取、跨时间段等等。
**验收测试**
以用户为主的测试，软件开发人员和质量保证人员以及用户参与，由用户设计测试用例。
总之就是让甲方大概看一遍。
测试技术分类
软件质量特性分类
功能测试
测试软件功能是否满足客户需求，包括准确性、易用性、适合性、互操作性等。
性能测试
测试软件消耗资源是否满足设计需求，包括负载测试、压力测试、兼容性测试、可移植性测试和健壮性测试等。
自动化程度分类
手工测试
自动化测试
阶段分类
α 测试
对软件的最初版本进行测试，不对外发布，在上线之前，由开发人员和测试人员进行测试，在可控环境下进行（内侧）。
β 测试
对上线发布之后的版本进行测试，由用户测试并进行反馈（公测）。
回归测试
在提交的缺陷被修复后，进行的验证测试，用来确保缺陷已被修复且没有产生其他不良影响。
测试模型
V 模型
图中同一行的测试依据是对应的：
- 依据需求分析进行系统测试
- 依据概要设计进行集成测试
- 依据详细设计进行单元测试
W 模型
W 模型实际上是两个 V 模型交叉，强调开发和测试同步进行。
H 模型
H 模型将测试流程独立出来，在开发过程中随时进行测试，只要有开发部分完成就进行测试。
X 模型
X 模型将程序分片，对每个小部分进行反复迭代测试，再集成继续进行迭代测试。
测试原则
1 测试基于需求
2 测试尽早进行
3 不可能穷尽测试
不可能将所有的输入输出组合都尝试一遍，要根据测试的风险和优先级等确定测试的关注点，从而获得测试工作量、成本、风险和收益之间的平衡。
4 GoodEnough 原则
测试的投入产出要适当权衡，形成充分的质量评估过程。不可能不计成本地发现所有的缺陷，足够好就可以了。
软件测试是为了找出软件中的缺陷，而不是证明软件没有缺陷。
5 “二八”定理
一般情况下，80% 的缺陷集中在 20% 的模块当中，缺陷并不平均分布。在测试的时候要抓住主要矛盾。
6 避免缺陷免疫
测试人员越熟悉软件越会忽略一些小问题，要对测试用例不断修改和评审进行迭代，且测试人员要发挥主观能动性。
游戏测试基本流程
游戏测试基本流程
功能会议 → 测试用例 → 冒烟测试 → 详细测试 → 回归测试 → 检查checklist 或 随机测试
- 功能会议
- 对测试的需求
- 测试风险
- 测试重难点、工具需求
- 优化测试方案
- 测试用例
- 书写测试用例
- 根据需求调整更新用例
- 冒烟测试
- 快速测一遍
- 主逻辑畅通、无明显 Bug、功能正常展开
- 详细测试
- 依据测试用例进行详细测试
- 回归测试
- 将提交 bug 后修复的模块进行验证测试
- 检查
- 根据测试点进行快速检查，查缺补漏
测试用例设计
一般考虑的测试类型
- 功能测试
- 性能测试
- 兼容性测试
- 服务端压力测试
- 安全测试
- 安装卸载测试
- 易用性测试
- GM 测试
- SDK 测试
首页格式
测试用例首页要包含：项目名、用例名、编写人/修改人、日期、备注、需求文档地址、游戏版本、干系人、用例等级等。
正文页
正文部分包含：id、模块、测试先决条件、输入、预计输出、备注等。
测试缺陷管理（Bug 提交）
在执行测试用例之后，获得的输出和预期输出不匹配时，就出现了“缺陷”，测试工程师需要向开发提交缺陷。
判定缺陷存在的标准为：① 与需求不符；② 与常识相悖。
发现 Bug 仅仅是测试的开始。
公司会使用自己的项目和缺陷管理系统，或者第三方缺陷管理系统，如 Jira、禅道等。
测试工程师需要在缺陷管理系统中创建一个缺陷类型的任务单来报告缺陷，包含如下内容：
- 缺陷标题
- [模块名] 简要描述
- 测试环境
- 游戏版本、系统、服务器、账号
- 现象描述
- 复现步骤+复现概率
- 缺陷等级
- P0 Blocker(阻塞测试流程的缺陷)
- P1 Critical(非阻塞但影响严重)
- P2 Major(影响主要功能)
- P3 Normal(一般缺陷)
- P4 Trivial(不修复也影响不大)
- 期望结果
- 正常情况下的预期输出
开发收到提交并认可后会进行修复，修复完成之后要再进行测试来验证修复成果，称作回归测试。该测试一是确定缺陷被修复，而是确定没有其他模块因修复而产生了不良影响。
测试报告
测试工程师在进行测试的本职工作之外，还应做到识别项目中的潜在风险并进行预防。
通过测试环节，测试工程师会收集到代码出现错误地方的数据，并由此可追溯到项目的具体模块和具体负责人上，从而给出项目质量的评估报告。此外，在测试产品的过程中，还要从用户的角度上对项目提出使用意见，以此来改善产品的使用体验。
测试报告主要包含几个重要部分：
- 从需求分析开始到评审最终上线的关键节点记录，并指出研发过程的瓶颈和多风险环节。
- 对测试过程及上线后的缺陷发生原因进行总结，并指出多缺陷模块。
- 对比项目迭代过程中的质量数据，给出提升方向。
评论