我测了啊,我真测了!

测到怀疑人生~

对测试人员来讲,什么事情比较尴尬?
——线上出问题。

再尴尬一点儿呢?
——没测到,线上出问题。

最尴尬呢?
——明明测到了,线上还是出问题。

场景1:没测到,生产环境出问题

意料之内情理之中,这太正常了。没测到出了问题不该惊讶,没出问题才该烧香。此时不应指责出问题,而应思考没测到的原因是什么。第一反应是测试人员遗漏了,好像也没更多原因。但当我们把视角切换到真实研发过程中,就会发现没测到的原因实在太多了!

  1. 没考虑到,测试漏测了
    这真是测试的锅,测试人员确实应该全面理解业务,设计高效覆盖的用例集。但在功能设计时如有良好规划,可以减少没想到造成的漏测。

  2. 考虑到了,但还是没测
    一般是时间紧任务急,来不及测,但又没向团队暴露风险。多半也是测试的失职。

  3. 不可抗力必须上线,来不及测
    大家清楚的知道风险,但遇到不可抗力,如法律法规等,无法完成全部测试就必须上线,这种情况我们且上且观察,共同承担风险,并充分思考线上事故的紧急预案。

  4. 流程问题,未经测试就上线
    开发自己上线了功能,没经过测试人员测试,也没有充分自测。这种鬼故事在过去的职业生涯中我至少见过5次。还是不能寄希望于人的专业性,应更多依赖于可控可追溯的流程体系来保证。

  5. 大家认同不需要测,直接上
    比如修改文案,或做简单的图片替换等。越是认为没问题的,往往越出幺蛾子。就好比我们埋头苦干往往没人看,刚要划水,抬头就是老板清静如水的目光。软件就跟成精了一样,分分钟教你做人,质量工作真是一丝都不能倦怠。

  6. 所有人都没想到,就没测
    之前的一个项目上,既有常规功能的迭代上线,又有特殊功能只迭代不上线,为了好区分,我们为不上线的功能做了开关,其实代码都上去了,只是Feature没打开。一次规模稍大的常规上线部署完成后,按照惯例验证生产环境,测试人员惊讶地发现本该关着的功能被打开了,不该出现的功能出现了。于是连忙把开关关掉,并排查原因,发现是有一个数据库脚本把开关数据导到生产环境了。从此以后,每次上线我们都会检查所有Feature Toggle的状态。

以上列举了一些原因,可能还有其他更多原因。不管什么原因没测到,终究还是让缺陷逃逸到生产了。但只要我们找到没测到的原因,有针对性的改进,还是比较容易避免这类问题的。

场景2:明明测了,生产环境还出问题

常在河边走哪有不湿鞋,测了还出事儿,这才是该怀疑人生的场景。这种情况往往问题也不好排查,通常是先赶紧排查问题,一定时间窗内找不到问题或无法快速解决,哪怕先回滚呢,事后我们再仔细复盘。测了还出事儿其实并不少见,原因也同样有很多。

  1. 以为测了,其实没测
    由于测试人员对业务理解不够充分,或者测试设计能力不足,以为已经充分测试了,但其实遗漏了比较关键的测试用例。这类问题可以直接等同于场景1中的某种情况。

  2. 环境差异性
    由于生产环境和测试环境的差异性导致测试结果的失效。不妨脑洞一下,都有哪些因素造成了环境差异性?比如软件配置上的差异:数据库账户、接口配置、服务和端口、第三方插件、集成服务、不同的应用渠道等……或者其他硬件上的差异。这种情况下可能并不是被测软件本身的缺陷,但由于环境差异性导致了测试环境通过的用例,在生产环境下得到了不同的结果。

  3. 数据差异性
    由于测试数据的差异性导致的生产环境缺陷并不少见。在测试环境,测试人员选取典型的测试数据进行测试,或许是批量生成的有一定规律的测试数据。这些数据可能用着顺手每次都会被复用,也可能形成了针对特定业务的测试数据集。这本是好事儿,但往往就像耐药性一样,这些被测软件用习惯的数据不利于揭示新的或隐藏的缺陷。而在生产环境,由于用户量大、操作不规范、真实业务的复杂性等原因,使得生产环境的数据更具备多样性,这就给测试结果的准确性带来更大的挑战。(可参考文末推荐阅读文章了解更多内容)

  4. 用户量级/业务量级差异性
    这其实也是数据差异性的一种,单提出来是因为引发的缺陷不同,上一种情况引发的是特定测试用例的结果不准确,或者说是普通的缺陷。而由于业务量级不同引发的往往是性能缺陷,高并发、大量堆积的业务数据造成服务中断等,这些情况引发的缺陷往往业务影响更大,定位、修复和性能调优的难度也更大。哪怕在测试环境进行了充分的性能测试,也极有可能在生产环境并行大量其他业务的条件下,造成灾难般的性能缺陷。

  5. 其他集成问题
    与集成方约定的上线时间、切换动作、兼容方式、集成验证等,都有可能在测试环境和生产环境有所不同。因此,在上线后与集成方一起验证集成功能的正确性非常必要。毕竟相比于自己的软件缺陷,集成引起的缺陷可控性更差,修复周期也更长。应尽早发现这类缺陷,以免造成更大的损失。

  6. 上线不完全
    这种就更诡异了,软件功能完全没问题,各种差异性也已排除或修复,但仍然可能因为发布问题死在线上。由于发布本身的复杂性、上线功能较多、服务间功能耦合、或是上线步骤繁琐、手动操作过多等原因,都有可能引起上线不完整,一部分关键代码没有上线。这类问题好发现好排查,但着实恶心人,本不应发生。

测试到底该解决什么问题?

先上结论,相比于发现更多缺陷,我认为测试最应该解决的问题是(每个字都很重要):

排除
用户或客户
对软件的预期
和软件真正的表现
生产环境上的
差异

具体怎么做呢?可参考以下列表逐步递进地完善实践:

  1. 充分了解被测业务
  2. 提升测试设计能力
  3. 在测试环境,确保软件业务功能没问题
  4. 充分思考环境差异性
  5. 排除数据差异性,用多样化的数据进行测试
  6. 排除或尽力约束集成方问题
  7. 在预生产环境进行完整的回归测试和发布演练(在发布过程复杂或对发布时间限制较严格时可选)
  8. 对发布后可能出现的风险进行预判,确认快速恢复机制
  9. 采用自动化流程、发布预演等实践,确保软件完全发布
  10. 完成上线后,立即对生产环境进行允许的测试和检验
  11. 投产使用后,持续监控服务日志和业务数据

本文就进行到这儿了。大家遇到过哪些类似的血泪故事呢?欢迎分享和讨论。 ——————————————————————————————————————————

推荐阅读:

1.《生产环境又有问题?都是脏数据惹的祸!》
2.《一次Testing in Production方案的探索》