设计测试策略

距离我一次写测试相关话题的文章，已经有相当长的一段时间了。对于自动化测试相关的内容，我大抵还算是熟悉的。毕竟，开发人员写测试这件事在 ThoughtWorks 是自然而然的，它也体现在我的开源项目上。恰好，最近我正在帮助客户设计和实施测试策略。 我便有了想法重新写一篇文章，体系性的介绍一下相关的内容。我那已经达到 800+ 篇的博客，正好缺失这样的一篇文章。 PS：我并非一个专业的测试工程师，其中若有偏颇之处，欢迎大家指正。 什么是测试策略？ 测试策略是一份在特定环境约束之下，描述软件开发周期中关于测试原则、方法、方式的纲要，并阐述了它们之间如何配合，以高效地减少缺陷、提升质量。在这份策略中，需要描述测试的类型、目标、方法、准入准出条件、所需的时间、资源以及环境等信息。 测试策略是一个因地制宜地策略模式，针对于不同的公司、不同的团队、不同类型的项目，相关的内容内容或多或少会出现变化。如对于快速迭代的互联网公司来说，单元测试、UI...

6h

Rust.unwarp()： 编译器驱动开发

用 Rust 来写个应用，这个想法颇久了。之前呢，要么找不到合适的场景，要么觉得 Rust 门槛有些高。直到最近呢，刚好对底层编程有点想法，便想着用这门语言做点东西玩玩。 考虑到，我用这门语言的时间只有一星期多，某些观点和感受并非那么准确。因此，我的观点并不适合作为一份参考材料。 Rust 是什么？ 让我来 copy 一下 Rust 是由 Mozilla 主导开发的通用、编译型编程语言。设计准则为“安全、并发、实用”，支持函数式、并发式、过程式以及面向对象的编程风格。 Rust 语言原本是 Mozilla 员工 Graydon Hoare 的私人项目，而 Mozilla 于 2009 年开始赞助这个项目，并且在 2010 年首次揭露了它的存在。 顺便加上 MDN 上的介绍：...

1w

迁移防护网

每次看到遗留系统的时候，我总想着设计一个迁移方案。时间一久，收集的案例一多，外加上我也有了越来越多的案例，便想着记录一下这些内容。 遗留系统的迁移 遗留系统的迁移是一个相当复杂的工作，以至于重写的成本甚至比迁移的成本更高。但是从技术维度来看，步骤无非就是： 设定迁移的目标 制定迁移的计划 迁移计划的验证（PoC） 实施应用程序的迁移 校验迁移结果 对，就是这么简单。 遗留资产 我们通过把数字化时代的遗留资产划分了这几种类型： 遗留代码。所有没有测试的代码。 遗留基础设施。所有不安全、没有弹性、不可靠的基础设施。 遗留系统。所有不可观察、没有支持的自制系统或者商业化系统（COTS） 遗留架构。所有限制交付价值的架构。 旧式流程。所有不可度量的流程（缺少...

2w

停止复用

最大化重用会使得可用复杂化。 —— 《Java 应用架构设计》 这个标题有点标题党了，但是我觉得你能理解：为什么我会用这么一个吓唬人的标题？ 文章起源于我对于模块化、微服务、Serverless 以及单体应用几种不同的架构模式的思考。而这其中的一个原因就是：人们经常从一个极端走另外一个极端。既然单体不好，那么我们就要 FAAS 来替换单体；既然模块化架构有各种问题，那么我们应该回到大单体。 微架构 微架构是一系列架构风格的总称，通过构建一系列责任单一的小型应用，再组合出一个复杂的大型应用系统。受限于不同的运行环境，它还具备有不同的特性。 对于运行操作系统的微架构来说，它具备了语言无关的特性，如微服务；对于运行在浏览器的微架构来说，它具备了易于集成遗留系统的优势，如微前端；对于运行在移动操作系统虚拟机环境的微架构来说，它具备了应用可嵌入式的特质，如插件化。...

3w

README 驱动开发

最近，我又挖了几个开源项目的坑，Ledge、Ledge Framwork、Igso 等等。每次挖新坑的时候，经常性地都要花很多的时间，想着怎么编写 README、完善 README。而就是这么一个简单的 README 的编写，它都要花费我相当长的时间，或是几个小时，或是几天。 问题来了，我真的是在写 README 吗？ 引子 1：不止自述的 README README，又称“自述文件”，是随着软件发布的一种说明文件，里面通常包含有软件的描述或使用的注意事项。 在众多的开源项目里，README 是我们最常修改的文件之一。每当我们添加了一个新的功能，一个新的特性的时候，我们的第一反应就是更新一下 README，以向世人宣告我们的开源产品又添加了新的功能。 所以，在我的那本《GitHub...

4w

开源游戏：开源会为企业带来什么

上周在公司内部又做了一次关于开源的分享，与三月份那次稍有不同的是，这次的关注点主要是：企业与开源软件。 开始之前，让我们再说说开源软件到底代表的是什么？ 开源软件是源代码可以任意获取的计算机软件，任何人都能查看、修改和分发他们认为合适的代码。开源软件依托同行评审和社区生产，皆以分散、协作的方式开发。 由于，这篇文章所针对的是企业，所以这里的侧重点是：开源会为企业带来什么？按照这个模式，分享的内容分为了四个部分： 开源发展现状 开源发展案例分析 企业开源能力模型 企业开源模式 考虑到『开源发展案例分析』是各种业内案例，不适合用文章描述，这里就只介绍剩下的三个维度。 开源发展现状 按照时间线，我把开源划分了四个时代： 弱版权时代。哪来的闭源。Unix 在...

Jun 2020

逆数字化：数字化时代的自由在何处？

很早以前，我便想着写一篇文章吐槽一下数字化时代。如果你熟知我在开源世界的贡献（代码 + 内容），就知道我一直是开源软件、自由软件的拥趸：RMS 一直是对的 [🐶🐶🐶] 。 首先，在这里讨论的是法律规定以内的自由，也就是守法前提下的自由。 直到，最近发生了一些事情，我才开始重新重视了一下这个问题。从现象来说，大致是这样的： 数字的『所有权』。我买了一本电子书，但是我只有阅读版权，而非所有权。如果是一本实体书，我可以把它出借个我的朋友，又或者是再次出售。除此，内容的提供商，它们『随时』有可能剥夺了我的使用权。尤其是，在中国特色的内容体系下。 随时可消失的数字产品。这个故事的起源是，我开通了网易云音乐的 VIP，而我在下载到本地的音乐会被它们删除。因为它们失去了版权，所以我们的相关歌曲都会被删除。当然了...

Jun 2020

需求代码化

需求代码化，即将软件开发需求抽象为特定的领域语言，并使用管理代码一样的方式来管理需求，追踪需求的变化 。同时，为通过新的 API 来对接版本管理系统，以可视化需求，演变为看板代码化。 为了解决某种需求/需要，我们计划设计一个软件系统。通过与利益相关者进行交流之后，确认了新的系统是有必要存在的。于是，我们产生了一系列的概念和想法，并通过诸如愿景梳理、用户分析等一系列的想法，我们将这些想法明确下来。 在开始软件开发前，我们定义好了产品是什么，随后梳理出了用户故事地图。我们定义了在什么场景下，需要哪些用户，在哪里做些什么事情，并对这些行为做出响应。有了这些定义之后，我们作为这个系统的架构设计师，便开始思考需要保存、显示哪些数据，才能完成这个业务目标。 在进入开发之前，这些想法设计等，都被明确为软件需求，简称为需求。...

May 2020

Yiki：元微前端框架

PS：Yiki（YY + Wiki）是一些关于软件开发、软件架构新设计的原型思考的 wiki。它针对于一些即将出现的新模式而设计，但是在当前阶段又缺乏足够的时间进行设计。（主要是最近没时间造这个轮子） 在过去的一两年里，从我接受到的一些线上、线下咨询的情况来看，微前端架构被越来越多中大型系统所采用。它们被用于不同类型的问题： 团队间协作 遗留系统改造 通过新技术创造价值（KPI） 这段时间里，也诞生了一个又一个优秀的微前端框架，如为 Angular 设计的 ngx-planet，还有适用于多种框架的 Umijs 的 qiankun……。 由于不同的微前端框架都源于它们的使用场景，也受限了它们不能满足于其它场景。受限于使用场景，这些微前端框架都需要不同程度的改造，才能满足各自的需要。...

May 2020

云开发

随着持续部署、DevOps 在各个企业的推进，越来越多的企业已经有完善的基础设施，软件开发团队只需要一个在线的 IDE，就可以完成开发工作，这就进入了云开发时代。 什么是云开发？ 云开发，是一种将开发过程完全迁移至云端的云原生开发模式，开发者可以在浏览器端、客户端完成一切的软件开发活动，如代码修改、调度、本地构建、代码提交、部署等等活动。其展示形式往往是通过在线 IDE 的形式完成。 在过去的一二年里，有越来越多的云厂商，选择了云开发的模式。值得注意的是，我们在这里定义的云开发和国内云厂商定义的云开发略有不同。国内云厂商所针对的是轻量级的应用开发，这里我们所针对的是所有场景下的云开发模式。换句话来说，支持轻量级应用开发是一个必由之路（MVP）。 对于一个云开发产品来说，它具备了这么一些关键要素：...

May 2020