0%

测试可靠性

预测信息准确的前提:

  1. 系统完全没有改变
  2. 充分描述整个系统的改变

测试是一个用来证明变更前系统的某些领域相等的手段。

软件测试的类型

  • 传统测试
  • 生产测试

    传统测试

  • 单元测试
  • 集成测试
  • 系统测试
    • 冒烟测试
    • 性能测试
    • 回归测试

每个测试都有成本,通常来说单元测试时间成本低 如果要将完整的功能架设起来测试,通常需要几个小时。关注测试成本,是软件提升效率的重要因素。

生产测试

生产测试和一个已经部署在生产环境的业务系统直接交互,而不是运行在封闭的测试环境。有时候称为黑盒测试

  • 配置测试
  • 压力测试
  • 金丝雀测试
    • 一小部分机器先升级,保持一定的孵化期。
    • 将代码置于比较难以预测的用户流量下
    • 需要能够快速的回滚

创造一个构建和测试环境

  • 测试的重点集中在用最小力气得到最大收益的地方
    • 划分优先级
    • 寻找关键函数关键类
    • 寻找提供给其他团队的 API
  • 发布前,通过冒烟测试
  • 寻找到的 bug 变成测试用例
  • 建立良好的测试基础设施
    • 追踪代码变更
    • 每次代码改变就进行构建
  • 精确的构建,只构建修改的地方,并执行修改代码的单侧
  • 使用工具可视化或者量化测试覆盖度
  • 和钱相关的系统需要更多测试

大规模测试

单元测试需要有针对性的覆盖组件中相互依赖的部分

测试大规模使用的工具

针对灾难的测试

灾难恢复工具被精心设计为离线运行

  • 计算出一个可记录状态,等同于服务完全停止的状态
  • 将可记录的状态推送给非灾难验证工具
  • 支持常见的发布安全边界检查

对速度的渴求

有的时候测试的结果会在重复运行下发生改变。所以需要针对某些场景,重复运行一定数量的测试。

发布到生产环境

通常,生产环境的配置文件容易被测试忽略。

集成

使用解释性语言编写配置文件是有风险的。程序的执行时间没有上限,需要加入截止时间检查。

使用成熟的语法(YAML)和大量测试的解析器。

生产环境探针

测试机制是对确定的数据检验系统行为是否可以接受。
监控机制择时在未知数据输入下系统行为是否可以接受。

已知的正确请求应该成功,已知的错误请求应该失败。重放已知请求观察系统是否正常。

(感觉应该是书翻译的问题所谓的探针应该是 mock 服务。mock 服务部署在生产环境 。在确定的入参下,有确定的返回值。调用方可以使用这个探针进行测试)

小结

测试是工程师提高可靠性投入回报比较高的手段。

事后总结:从失败中学习

哲学

保证事故能够被记录下来,理清所有根源问题。确保实施有效的措施是的未来重现的几率和影响得以降低,甚至避免。

书写事后总结不是一种惩罚,而是整个公司的一次学习机会。

需要书写的标准:

  • 用户可见的宕机或者服务质量下降到一定标准
  • 任何形式的数据丢失
  • on-call 工程师需要人工介入
  • 问题解决耗时超过一定限制
  • 监控问题
Read more »

应急事件响应

测试导致的事故

SRE 故意破坏系统,利用这些测试发现系统的薄弱地方。

在某次测试中发现了额外的系统依赖。

响应

  • 终止测试
  • 用以前 测试过的方法 回滚了数据
  • 找到开发者修复了相关问题
  • 制定了周期性测试机制来保证问题不重现

事后总结

好的方面:
事先沟通,有足够信息推测是测试造成的问题。
快速恢复了系统。
遗留一个代办,彻底修复问题。制定了周期性的测试流程。

Read more »

有效的故障排查手段

理论:

反复采用假设排除手段的过程:
不断提出一个造成系统问题的假设,进而针对这些假设进行测试和排除

常见的陷阱

  • 关注的错误的系统现象,或者错误地理解了系统现象的含义。
  • 不能正确的修改系统的配置信息,输入信息或者系统运行环境。
  • 将问题过早的归结为极为不可能的因素,或者之前曾经发生过的问题
  • 试图解决与当前问题相关的一些问题,却没有认识到只是巧合。
Read more »

新财年换了领导,管理风格也有一些区别。在团队内增加了一个 SRE 的职位。这一财年我将会承担一部分 SRE 的工作。

之前作为开发者,总的来说从开发的角度来思考系统的稳定性。现在需要从更高更全面的角度来思考和理解站点的稳定性。上网研究了一番,SRE 是 google 的一个职位同时 SRE 也是一套 google 总结出来的站点稳定性的方法论。所以找来了 《SRE google 运维解密》。这本书成书比较早,里面有些章节介绍的技术栈可能过时。具体我也不了解 google 内部是否还在使用。但是方法论还是很合理、科学的。

一直以来我工作过的团队对于风险的态度都是,预防和杜绝。但是在这本书里面,google 对于风险的态度就变成了管理,合理使用,甚至利用风险来保证项目的迭代。

Read more »

2021 就这么结束了。

今年我做爸爸了。
今年九月,迎来了我们家的小朋友。豆嫂从怀孕一路走来。如打怪升级一样。一关一关的过,颇为不容易。

jia

Read more »

终于有一个 Java 版的微信机器人了。

公众号很久没有更新了。主要两个原因,换了工作之后,第一,要花更多的时间去了解和学习新的业务。第二,我最近把几乎所有的业余时间都来写这个 Java 版的微信机器人了。

java-wechaty

Wechaty 是什么

官网的描述是:

  • A Conversational AI RPA SDK for Chatbot

其实就是一个能够快速构建聊天机器人的开源 SDK。最早的时候,Wechaty 只是一个基于服务于微信工具库,现在逐渐的发展到可以对接世面上的主流聊天软件包括不限于:微信,企业微信,钉钉,Line 等。

编程语言也由原来的单一语言(TypeScript) 发展到,Java,Scala,Python,Go 等多语言实现的工具库了,同时社区生态还在不断的壮大。

Github 地址:https://github.com/wechaty/wechaty 目前已经有 7.9k 的 star 了。

Read more »

最近研究 Vetrx 简直爱不释手。迫不及待的想给大家介绍一下。

carbon

Vertx 是什么

  • Vertx 是一个运行在 JVM 上,用来构建响应式应用的工具集。
  • 基于 netty 的高性能的,异步的网络库。
  • 对 netty 进行了封装,提供更加友好的 API。
  • 同时实现了一些基于异步调用的库,包括database connection, monitoring, authentication, logging, service discovery, clustering support, etc。
Read more »

“山川异域,风月同钉”,被钉钉暴打的你,是不是已经想写一个机器人调戏一下钉钉了。在写机器人的时候,钉钉机器人的回调需要填写一个公网 http 地址。

这还没开发机器人,就没有 http 服务,没有 http 服务就收不到钉钉的回调,没有回调就不能调试机器人。不能调试机器人,就不能上线。

black

Read more »