程序的自我修养（1）——自测

【前言】

在开发过程中，每完成一个小地方，测试看看功能是否符合预期，是每个程序都会做的，这一过程也叫做自测。

可以说，每个程序都知道并且会自测，然而，实际中却经常有不自测的情况，可能由于程序疏忽、偷懒、被逼等等原因，我们来分析一下。

我们将不自测导致的情况分为编译不通过、进入有报错、测试有Bug三类。

【编译不通过】

提交通过编译是最基本的情况，一般需要做自动检测，基于当次提交和后台中的代码做检测，看看当次提交是否通过了编译。

本地编译不通过

这种本地编译都没通过就直接提交属于作死，被发现一次要被锤一次

当然，基本没有主观上没编译过就提交的，都是在特殊情况下过于自信不依赖编译完成急于提交的。

这种自信往往是逻辑上的，但编译不过往往和逻辑是没关系的，例如：

• 逗号、分号、括号的中英文区分个人基本不会去看，有可能不小心输入中文了。
• CV的时候不小心少Copy了一个分号，但没注意
• 函数名输入错误或者对的，但和原有函数没对上
• 等等各种各样的情况

这些情况等本地编译下就能知道，但偏偏编译一次时间过长，有些时候急于提交不想浪费时间或者懒得等，例如：

• 之前编译没问题，现在就修改一个很小的地方，编译一次时间太长了，不用再等着编译一次了
• 马上就要打包了，等编译好再提交就来不及了
• 要快速修复一个问题，再等编译就太费时间了
• 等等各种各样的情况

建议无论什么情况下，只要有改动，就要等编译完成后再提交

主干编译不通过

文本编码不通过：这种设置下文本编码即可

宏命令不通过，这种情况本地编译检查不出来，分为三类：

• 增加代码：宏内有错误没看出来，编译也检查不到：建议先写代码编译过了之后再加宏
• 减少代码：删掉一个没有用的代码，但偏偏宏内引用了：建议删除前全局搜一搜
• 修改代码：别的地方都修改了，但宏内引用了，没改到：建议别的地方都修改后再全局搜一搜

漏提交，这种情况比较常见，提交的时候忘记了或者不知道某个脚本也应该提交，其原因可能是：

• 前后间隔几天了，忘记某个脚本需要提交了：建议在最高层级提交，虽然很慢
• 提交层级不对，有个脚本在另外一个文件夹内：建议在最高层级提交，虽然很慢
• 提交的脚本是新增的，没有Add：建议新增脚本后立即Add，否则之后提交很容易忘记
• 疏忽大意忘记提交了：这种真没办法了
• 正在提交时被人打断，导致忘记了某个地方要提交：建议提交时提交完了再沟通

【进入有报错】

相比编译不通过，进入有报错是指游戏内常见模块进不去或刚进入就报错等，这些常见模块包括游戏启动进入登录界面、游戏大厅、匹配进入战斗等，根据游戏类型有所区别。

进入有报错常来自于错误提交，本地是没问题的，但由于错误的提交导致主干有报错

错误提交，指需要提交的内容都提交了，但额外多了或少了其他内容，例如：

• 本地有一些调试用的Error Log，不小心提交上去了：建议提交前仔细看Diff，不要一晃而过
• 本地有开发需要修改了其他代码，提交前本应恢复原样的，但不小心提交上去了：建议提交前仔细看Diff，不要一晃而过
• 处理冲突时，删掉了其他人的东西提交了：建议处理冲突后再次提交时仔细看Diff，不要一晃而过
• 两个功能的修改在同一个脚本中，只需要提交一个功能的，但附带上了另外功能的内同：建议处理冲突后再次提交时仔细看Diff，不要一晃而过
• 修改了一个很简单的地方，编译过了，重新进入测试一遍耗时长，赶着提交，自信没问题：建议修改后重新测一测
• 等等其他情况

还有一种特殊情况是，有些常见模块不在自测范围内。

总而言之，在提交前要耐心、仔细看Diff。

【测试有Bug】

测试有Bug主要是QA反馈的Bug，主要分为功能开发中和功能开发后。

功能开发中，程序应该对着需求和测试用例中的每一点在开发过程中或者开发到一定阶段时，像QA一样去自测。

 严格按照这样来做，就能保证基本不会出常规性Bug，但实际上却难以严格按照这样做，有各种各样主观或客观上的原因，例如：

• 看逻辑觉得没问题，测试比较繁琐，不想再测一遍
• 不看或没仔细看需求和测试用例
• 没注意有个地方需要测试
• 有一个很小的点，可能当时记得，但在前前后后开发过程中，就忘记自测了
• 各种log混淆，自测时没看到有报错
• 心存侥幸，认为刚才报错从逻辑上不会再次发生，没深究
• 各种边界情况、特殊情况没有或无法考虑，也没自测
• 时间很紧急，只能优先保证主要的没问题，其他的没时间去考虑
• 需求模糊或需求矛盾
• 没有测试用例
• 要测试的常规情况很多，程序不可能一一自测
• 都是敏捷开发，迭代修改很频繁，可能之前测着没问题，随着迭代优化就有问题了，也不可能一一自测下
• 没有数据等情况导致没有自测条件
• 等等其他原因

具体的原因多种多样，还涉及到如何认定Bug，之后有时间再单独谈一谈。

要注意的是，我们这里说的是由于没有自测而导致的Bug，不是其他原因导致的Bug。

没有自测是从结果来看的，而不是看过程的。

功能开发后，是指QA明确了Bug复现的方式，程序提交说修复了，但QA测试发现仍没修复，可能的情况是：

• 按照流程测试一遍太复杂，程序看着逻辑上没问题，也没报错，觉得没必要测一遍
• 程序自测流程不完整，有些地方是绕逻辑模拟的
• 程序只做了部分情况的测试，另一部分没做
• QA过了很久才测试，中间有什么其他改动，导致又出了新的问题
• 多个不同的原因导致同一个错误表现，QA给的复现方式只是其中之一
• 等等其他情况

修复Bug的正确流程是：按照原有方式复现一次Bug,随后添加修复逻辑，再按照原有方式测试一次，没有出现，才算作修复。

【如何看待自测】

自测被视为程序的基本修养，程序这样认为的，QA也是这样认为的，策划（产品）也是这样认为的，这是一个公认的事情。

如果你经常不自测导致出了问题，那么给人的印象就不好，导致信任问题，最直接的体现就是：

如果出现了报错，只要和你所做的功能相关，即使真的不是你所导致的，那么首先也会怀疑你，Bug会被指派给你，你必须花时间看看为什么报错以自证清白。

注意，这里说的是经常不自测导致出了问题。因为看的是结果不是过程，所以理论上你可以不用自测，只要保证不出问题即可。

那么这会不会与自测的修养相互矛盾呢？这要从管理的角度来看

管理水平是很难提升的，比技术水平提升困难太多倍。因此国内外的管理基本都是基于结果的粗放管理，没有基于过程的精细管理。

在这种背景下，结果正确但过程与理论上的不符合，却按照理论上的进行惩处，仅就自测这种简单的事情而言，属于吹毛求疵或是过于苛责或是故意针对或是恶意刁难。

因此，程序在自测上的自我修养是不出现自测错误，而不是有自测过程。

自测错误有哪些，上文已经说过了。我们可以看到，绝大多数情况都不是程序主观上故意不自测，而是过于自信以期节省自测的过程，比较有时候自测流程完整走一遍比写代码的时候久太多了。

可能多数情况下过自信的提交是没问题的，但人毕竟不是机器，状态会时好时坏，都会有犯错的时候，总会在某次马失前蹄。

因此，要求不出错是不可能的，这是一个不合理的要求。尽管有极少数人目前为止从没出错，但不代表之后不会出错。

合理的管理要求是，允许在一段时间内有一定测数的出错，不要连续出错或在关键时刻出错。

没有自测过程的出错概率根据人而定：经验丰富的老人踩坑多，经验丰富、习惯良好，出错概率低；新人经验少，出错概率高。

注意，十次中有一次出错，就算概率高。

减少人为因素的出错的方式有：经验丰富、习惯良好、流程规范，其中流程规范意味着要有完整的自测流程。

对比而言，在相同的出错率下，新人比老人要花费更多的时间在自测上，在时间紧张或测试繁琐的情况下也更不愿意做自测。

所以追溯自测出错的责任人，绝大多数都是新人。

新人常常比较自信，或者说没有养成自测的习惯，需要被不自测的后果毒打几次，才会养成自测的习惯。

这里说的新人是指刚入行的新人，而不是刚入职的新人，他们有以下特点：

1. 没有自测习惯：有些时候会做自测，有些时候急于提交而忘记自测，没有每次提交都自测的习惯
2. 过于自信不用自测：有时只是在原来基础上，改动一个很小的地方，认为一定没问题，不需要再测一下了
3. 没有意识到有些情况需要测：新人由于缺少经验，并不知道有些情况需要自测

因此，新人要降低出错概率，要坚持完整的自测流程。 

【自测出错对不同人的区别】

在合理的管理要求下，不同人出错所造成的后果是不同的。至于有什么处罚，就看不同组的管理风格和氛围了。

没有处罚是不可能的，否则出错次数可能越来越多，不利于管理。

管理者，通常是组内的技术负责人对上、对QA组、对策划（产品）组要为日常开发的稳定性负责。

太处罚过于严厉也是不可的，这会打消程序组积极性，迫使他们花费更多时间去做完整的自测流程而导致整体开发节奏变慢。

因此，如何选择处罚措施，是对管理者的考验。

当要实施处罚时，新人往往是杀鸡儆猴的对象。这里的新人是指刚入职的新人。

 这意味着新人会被：在大群里被公开严厉处刑，多次被处罚后，被人质疑能力，再犯后可能会有绩效上的处罚

 因此，新人最好按照流程规范以降低出错概率，尤其是已经公开处罚的情况下。

对老人：在大群里会被略微提下，老人多次出现此类错误会被人质疑态度，特殊情况下这会是被PUA的理由

对核心：看情况会被轻微提下，多次出现此类错误也不会有其他问题

对管理：如果管理者还会提交代码并出现此类错误，其他人也不会多说什么，就看管理者是否自觉接受处罚了。