质量保障 -- 属于我的臻于至善之路

前言

本博客是学习网易游戏学院的质量保障一书所记录的笔记

至于我为什么选择QA而不是单纯的后端开发, 我想, 是因为这些不局限于单一领域的业务,
能从全面质量视角去审视、去接触以及影响改变整个游戏制作过程吧
这无疑能让人特别兴奋， 不是吗？

成为一位合格的游戏测试工程师所要具备的条件有哪些?
细心, 热爱游戏这些固然重要
但是最关键的是要有责任心以及一定的坚持
为了成为同伴们最值得信赖的QA. 我将沿着这条路一直走下去

第一章-道法自然

QA眼中的质量

QA的宗旨是通过了解各部门的现状, 发现问题, 提供指引或解决方案, 跟进实施等各种方式, 为产品提供设计品质, 制作品质, 运营品质, 营销品质等等一系列的品质保证

• 在适当的时候坚持使用自己的QA的职权
  这里最重要的一点就是对自己签下的"测试通过, 同意发布"负责
  场景: 当你(作为一个测试)发现了一个问题, 当你把这个问题反馈给程序/策划他们没有认同, 觉得问题不大可以接着外放时, 沟通后如果你们仍然各持己见的话, 此时你应当禁止版本外放, 对自己的产品负责, 绝不可以随便让问题从手中漏过去

• 要树立高度的质量观起点
  (1) 0 Bug (2)令玩家满意 (3)提升生产力

• 如何0 Bug?
  让测试更深入: 身为测试人员功能测试, 文档分析, 用例设计这些都是QA的基本功. 外放遗漏的话很可能是QA遗漏了一些需要测试的情况, 这分为三个层次.
  1.需求的遗漏.(没有做好准备工作或者频繁的需求变动) 2.游戏的情景想象不足(思路不仅仅停留在策划文档里, 此时测试应该是一个玩家, 站在玩家的角度去思考问题) 3.对游戏内部的游戏机制不够了解. (仅仅只是黑盒测试, 所以我们应当去尝试灰盒测试, 探索性测试, 甚至是充分的代码阅读)

   <<探索性测试>> James A.Whittaker著
   探索性测试可以说是一种测试思维技术。
   它没有很多实际的测试方法、技术和工具，但是却是所有测试人员都应该掌握的一种测试思维方式。
   探索性强调测试人员的主观能动性，抛弃繁杂的测试计划和测试用例设计过程，
   强调在碰到问题时及时改变测试策略。
  

  探索专项测试:比如单独进行性能测试, 压力测试, 兼容性、电量等各类专项测试
  用变动监控和自动化来应对版本迭代: 比如Airtest这种专门针对手游的自动化测试框架, 可以用Python语言和图像识别来编写通用的自动化测试脚本
  建立标准, 进行过程改进, 预防同类问题

• 如何让玩家满意?
  游戏体验是否能让玩家满意主要集中于几点(游戏漂不漂亮, 游戏是否流畅, 游戏好懂吗操作麻烦吗, 游戏难吗有挑战性吗). QA需要将易上手, 数值合理, 作为可玩性测试中需要去分析的部分
  同时需要去收集玩家的反馈 收集运行数据 研究数值

这里书上有一个我觉得不太好的点
书中前文提及QA部在质量观也拥有了一个很朴实很高的起点(后面就提到了0Bug 令玩家满意这两点)
(此时前后文在说为玩家服务为玩家着想)
之后再说起的时候就是以"能为公司带来新的竞争力的目标"来形容
(把从服务玩家的角度变成了服务公司的角度)
虽然也可以说玩家服务好了公司竞争力就高了, 但是这总归还是有比较大的差别的

• 提升生产力
  去除掉冗杂重复的手动操作, 转换为自动化操作(即重复的部分只需要输入一次策划程序员填表
• QA究竟是什么
  (Quality Auusurance)质量保障, 抛开文绉绉的标准文字, 用通俗的话来说的话就是
  为用户在产品质量方面提供保障, 保证用户购得产品在寿命期内质量可靠的相关活动, 而我们这种从事活动的人员就是QA人员
• QA需要去做一些什么
  (1)测试检验(相比于质量裸奔大大降低因为缺陷产品带来的亏损)
  (2)短迭代周期或流程上游的质量保障(提前介入, 可以减少对"废品"的多次加工)
  具体的操作有两点:
  1. 短迭代周期中及时开展质量保障
     在敏捷的开发模式下必须紧跟每个周期的时间窗口, 这样才能把风险和质量问题扼杀在萌芽阶段, 核心是在快节奏中快速响应测试需求
  2. 推进质量保障往开发周期内的上游环节挺进
     (此时一位熟练的QA会形成策划文档分析, 表检查, 程序代码静态检查, 美术资源检查等一系列的解决方案甚至是工具平台, 会成为一个最了解开发协同全貌的角色

那是不是熟练的QA更适合项目管理这个职位?..

(3) 过程管理–过程控制与过程改进

这里原文标题应该漏了(质量两个字) 过程(质量)管理

过程质量控制: 为了打到质量要求所采取的作业技术和活动. 其目的在于为了监视过程并排除质量环所有阶段中导致不满意的因素, 以此来确保产品质量

过程质量改进:过程质量改进是使效果打到前所未有的水平的突破过程

过程质量控制和改进的相关工作不仅限于技术技能和业务, 同时也设计数据收集分析,

• 质量检测过程
  (1)目标设定 (2)设计用例 (3)用例执行
  测试用例三要素
  测试的前提和环境
  可操作的测试方法和测试结果收集方法
  预设用作与实际测试结果相比对的结果

这个预计用作究竟是指什么..原文中好像也没讲, 是不是打错字了, 应该是..预计结果?

我们这个质量团队

QA的画像

• 极客-技术背景
  有着良好的计算机基础你才能更好的和程打交道, 或者自己去书写一些指令
• 包青天-审慎
  耐心细致是QA的必备属性, 作为游戏开发团队的最后一环, QA的严谨需远高于开发团队中的任何其它岗位. 你需要获得"靠谱", “周全”, "稳"这些来自其他人的评价
• 侦探-思维技巧
  如果现在产品要调整某样重要物资的投放, QA可以动用思维技巧预先判断其产生的影响吗?
  QA需要如同侦探一样需要绕开一些常见的思维陷阱, 并运用各种思维技巧.
  就比如玩家上报了一个错误"他在副本中卡住了, 但其他人都没事, 不知道他的情况是怎么出现的"这时候你怎么考虑的.
  经验和思维技巧将很大影响你的破案效率
• 超人-责任心
  QA的责任心是不容被挑战的, 一定要勇于承担自己的责任, 不能满目推锅和揽锅
  同时要明确这件事中QA有哪些本可以做得更好的地方
• 匡衡-主动性
  对新人QA来说, 大部分时候做哪些工作是由主管安排的, 但如何去完成一项工作则是很大程度可由自己决定的.
  比如普通QA接到测试需求可能就是测试, 提Bug, 验证, 关单
  但是, QA涉足的领域, 能做的事, 或许比任何其它岗位都要广
  主动的QA除了普通QA做的这些事以外, 他可能还会
  1.在程序开工前就分析需求文档, 沟通后提前设计测试用例
  2.开发时就时刻关注各方进度, 进度比较紧张时就主动提出先行测试以免后期测试时间不足
  3.测试的同时完善测试指令, 记录该系统的相关知识到组内的知识管理系统里面
  4.外放前, 主动邀请策划和美术在内服体验, 如果有不满还能在外放前迭代修改
  5.外放前, 也能在外服观察进展和玩家反馈情况, 汇报问题
  6…跟进测试过程中, 思考记录团队内一些流程和人员的问题, 事后主动与主管商量如何改进
  两个能力相同的人, 在不同的主动性下, 最终结果相差甚远
• 游戏热爱者-产品设计
  虽然游戏产品设计的大方向是由产品经历和策划共同把控的, 但是产品的质量、体验以及品质是由策划和QA共同把控的. 从一开始刚写出设计文档, 到最后玩法外放到外服, 整个过程QA都可以参与到设计中, 提出各种意见.
• 项目管理者
  项目整合管理
  大局观, 确保项目全局的利益, 对范围进度成本质量等分目标进行整合
  项目范围管理
  QA需保证程序,美术,UI等输出内容都是在策划需求范围内的, 没有偏差, 并推动策划去验收.
  在面对复杂的新内容时, QA需要去做好工作去分解结构
  项目进度管理
  进度失控 = 加班
  有全局观的QA需要把控好整个项目的进度
  项目成本管理
  QA对项目成本, 人力成本, 时间成本知会并且在合适的时候提出建议
  项目质量管理
  需要QA能够对产品流程有深刻的理解, 并能影响和说服他人,
  项目资源管理
  其中最重要的是人力管理, 因为这涉及到团队建议, 团队管理, 冲突解决和团队工作分配等问题.
  项目风险管理

这里我不是特别理解, 原文说从测Bug的层面中跳出来, 对每项工作的跟进中识别风险, 
分析风险, 应对风险, 那就说明对产品和团队有深入理解了. 
可是项目风险管理究竟是不是就是识别风险, 分析风险, 应对风险呢, 这属于管理吗?

• 擅长打交道的人
  提出流程改进时也多站在对方角度去思考问题, 寻求双赢, 探讨问题时多用数据, 论据说话
  在一些流程改进上, 若总想着通过技术手段去自动化检测, 报警, 纠正, 或许成本极高.而巧妙的沟通合作能力, 或许马上就能达到同样, 甚至更好的效果

新Flag, 六月结束前看完<<非暴力沟通>>并记录要点, 最后写一篇心得体会

• 热爱学习和分享
  那不就是我了!

第二章-神术妙策

理解测试业务

关于"快" “准” “狠” 的探讨

测试工作得快准狠是相辅相成的， 缺一不可
在测试时间紧的时候要快可能没有时间去了解程序实现来兼顾准和狠， 但是如果准了测试量就少了， 自然也能快。如果不够狠的话， 遗漏了重要Bug， 就算暂时快了， 放出之后一堆尾要收，还是不够快。
即
QA需要做一个精准的射手， 不做多余的测试， 也不把必要的测试遗漏
测试可以合理的分解测试模块， 化繁为简
不仅要听， 更要去看， 看完要去思考内容
黑盒测试要和白盒测试并行， 不能只有白盒没有黑盒， 也不能只有黑盒没有白盒

QA对产品不仅测试功能， 也关注体验

这让我想起了第一次面试的时候，面试官问我怎么对游戏王的卡牌进行测试
（当时的我没有去想模型啊， ATK之类的（（（
最先想到的就是英文文字描述翻译的问题（国服不准出现英文）
有几张怪兽卡的前缀是等级（英文原版是Lv）， 有一张魔法卡效果描述为给拥有"Lv"前缀的怪兽干嘛干嘛干嘛
*（其余进行交互的魔法卡陷阱卡都是以"等级"来作为描述
但是玩家找不到Lv开头的怪兽，这会造成他们的迷惑

在一顿描述之后面试官说我偏了（
现在看也确实偏了， 但仔细想想我还真挺在意玩家游戏体验的（
这里还推荐了一本书<<点石成金: 访客至上的网页设计秘笈>>

这里还提了一个有趣的点， 当你觉得是Bug而程序认为不是Bug的时候。 
可以先去和策划达成一致来让他们乖乖就范

过了五天后修订: 当程序认为是feature的时候可以进行策划,QA,程序三方确定, 最后还是让策划拍板
其实现实中蛮多这样的例子的, 书上举例了一款任天堂赛车游戏, 我所知道的还有像是文明里那样的核弹狂魔

用户体验问题的可能来源：
策划思考局限（考虑不周全， 时间赶）， 程序偷懒(拒绝复制黏贴， 打的一手好错字)，
开发效率（发现问题解决问题都需要时间），评判标准缺失（究竟怎么样才算用户体验好？）
视野局限性（QA发现问题也有局限性， 比如测试时主要还是发现系统功能性的问题为主要目的， 测试环境也有局限性， 无法完全仿真外服。 个人认知也会有局限性）
对于这些体验问题我们QA可以做到的事：
职业使命（有问题你肯定要去找策划和程序的）， 为UE测试提供一个更完善的版本
合理权衡，后期迭代（比如有一个久远的Bug可以不用立即修复，紧急Bug的优先级就upup）
各种建议（细水长流，从项目初期就开始）， 多角度交流（遇事不决， 可以问问别的QA或者你的Boss）
深入的游戏体验（每一位QA都应该是一位出色的玩家）

关于过程质量控制

这里介绍一个产品“代号M”的做法， 就是QA通过前置控制手段来保证提测的代码质量，从而达到减少后期修复问题成本的目的
影响玩法制作质量的几个重要因素：

• 各个环节相关人员的拖延
• 各个环节交付的内容不完善
• 各种暗改
• 不断重复踩坑
• 新人业务不熟悉

测试设计与管理

关于

这里书P062页出现了段落重复（第一段第二段内容相同），虽然说人工校验肯定会有差错
但是在QA书籍中出现这么明显低级的错误属实不应该

如何通过文档分析告知策划、程序等相关人员功能的细节与不足

文档分析需要QA有测试经验以及游戏经验
测试经验可以帮助我们发现设计中的错误
游戏经验可以帮助我们改善游戏体验

• 关注文档本身的细节
  一个标点， 一个错别字， 表述不明确都可以能导致事故的发生
  常见的异常情况需要去考虑， 比如掉线顶号以及背包满
  查缺补漏的方法： 怀着写用例的心情去做分析

吐槽：这里还没教怎么写用例呢。。教怎么写用例在下一节，虽然我大概知道写用例需要很用心很细致，
但是如果一个人没有Get到这个点或者说我现在理解就有误的话那其实关于这段是不好说明的
比如，从哪些角度去想测试点

• 报警机制与细节
  在合适的地方添加报警机制， 即设定一个阙值， 如果超过阙值的话就会报警
  以及在可能出错的地方提出一定的预警建议

这里还探讨了一下关于QA对数值方面的分析意见 -> 一般实际过程中对数值什么都做不了吗
原文中对这个问题给出了一个否定的回答，但后续的举例不足以证明QA还能再数值方面提供建设性的建议
原文中说奖励方面是否明确给出， 发放方式是否安全....（这些真的是数值方面的内容吗？
感觉写这一章的QA好像不是特别细致，错误比较多（当然也很有可能只是我认为他错了。。

• 站在玩家的角度和身份去思考
  任务或者操作是否过于复杂？是不是这不太够吸引玩家？这是不是玩法过于借鉴了？
  以及还需要考虑一下程序员（对你对程序都好）
• 策划文档的“望 闻 问 切”
  1）望：文档设定需要符合实际，比如对于现实中存在的东西，是不能任意扭曲的。
  分析文档要注意细节，前期文档工作越细致，后期需要返工的东西就越少（这里再次建议一边写测试用例一边做文档分析可以减少遗漏的方法
  要注意防止玩家非法得利， 要控制开销

  那是不是写书的时候也可以一边写测试用例一边写书
  （比如P068的第一行“游戏中论坛的回帖”这句话突然出现在这里就莫名其妙）
  不知道是不是有一段没删干净还是。。。（（（
  

  2）闻：不要被动的去测试, 要去主动参与游戏的制作过程中
  比如策划在和程序之间进行交流的时候就要主动去参与, 多去了解是否策划又有新点子了, 或者在某个地方进行了修改
  3）问：去深度挖掘需求, 对于一些不是那么熟悉的事务拒绝想当然, 要去多问策划和程序
  4）切：在想到有可行性的解决方案或者疑虑后主动和策划进行切磋

如何通过用例设计完善测试点，如何在测试过程中通过一些方法优化测试效率及规范流程

明确测试目的 -> 编写粗略测试点 -> 完善测试点 -> 用例划分

• 了解设计的原始需求(明确测试目的)
  只有知道原始需求编写的测试用例才能更有目的性以及更加完善, 同时, 在需求分析阶段, 理解设计需求也能修正掉一些不合理的设置
• 熟悉系统的功能需求(编写粗略测试点)
  测试点一定要覆盖所有的功能需求点,这是最基本的一点. 由功能需求出发得出的测试用例就好比我们完整测试用例大树中的主干部分, 只有主干部分根深蒂固才能在此基础上枝繁叶茂
• 了解实现原理(完善测试点)
  不仅要理解原始需求以及软件功能需求, 还要了解程序的实现原理, 理解内部处理的流程, 使测试用例能够覆盖到所有的代码分支, 并且覆盖到可能会造成影响的其他模块
• 还原用户场景(完善测试点)
  不再是以计算机从业者的角度看待, 而是以玩家的角度去看待
• 测试框架(用例部分)
  测试框架从小到大划分
  功能 -> 兼容性 ->性能 ->性能 ->容错 -> UI界面 ->安全性
  在功能性的测试点完成之后, 应该多考虑一下非功能的测试点
• 编写测试用例方法和思路
  常用的测试用例设计方法: 等价划分法, 边界值法, 域分析法, 输出域分析法, 场景法, 正交试验法, 组合分析法, 分析类法, 判定表法, 状态迁移法, 错误推测法等

草, 这些我都不会(看完这本书我立刻去看Google软件测试之道

如何将测试遗漏进行总结增长测试能力

如果你不能量化它, 你就不能理解它, 如果不理解就不能控制它, 不能控制也就不能改变它

流程阶段             测试遗漏的原因
需求阶段				沟通问题 -> 注重沟通 ->多方会谈 ->每个功能出来之后都要进行评审和进度评估
					文档分析问题  -> 单人思维局限 -> 两两搭配进行测试
开发阶段				未通知相关功能回归问题
					紧急需求问题 -> 再紧急也不能跳过经过QA测试这一步骤
测试阶段				用户体验问题  -> 去尝试从用户(玩家)本身去思考
					测试支持不足问题  
发布阶段				搭车发布问题  
					发布环境不一致问题
我们需要有
持续改进的心态    

发现缺陷        任何阻碍流程的问题
				与优秀同类的对比
				收集同事的抱怨点(去了解痛点)
收集数据			数据要有效
				数据量要足够(可以借助redmine等工具)(这是一款项目管理软件)

分析数据、深入挖掘	 外部环境分析
					内部因素分析
解决问题、形成新规则		有说服力的展现方法
						良好的沟通方式
						新的奖惩制度
				

到了这里这本书也看完一半啦~可喜可贺!!

专项业务测试与实践

QA的工作不仅仅是需要保证测试质量, 所有能提升产品工作效率的工具, 都值得QA去关注

• 游戏数值测试
• 上游产出质量保证
• 性能与优化
• 客户端发布流程

在介绍的时候用到了assets lib等缩写字眼, 这里注释一下全称会不会好一些(
毕竟看这本书的人不可能都像我一样拥有技术背景(

• MTL测试服务

第三章-积厚成器

测试开发技术

Hunter远程运行管控平台

吐槽: 在上一章有很多游戏玩家一看就懂的名词如"帧率低""CPU"花大量的篇幅去解释
在这一章诸如"safaia""rpc"提都不提(

AirTest自动化测试方案

Airtest Project这个项目下边有两个底层的测试框架

• Airtest基于设备层模拟输入和图像识别的测试框架
• Poco基于游戏引擎UI控件检索的测试框架

线上监控平台

测试平台实践案例