发表于

我写这篇文章来抒发一些想法，另一方面是作为我之前一篇文章的后续。此刻，我又想起来聂帅给我讲过的”人的思维是螺旋上升的”。

我们还是以开发者测试举例，因为之前提了很多想法，虽然我的角色有些变化，大家还是在找我讨论，谢谢大家看得起我（笑）。

为了满足读者的背景，我来给大家快速补齐一下角色和平台：

  • 测试：把握整体，确保测试的分层，避免大量都是耗时的集成测试用例，结合我们的资源、我们的开发测试比例，将部分确定性，执行相对更简单的测试放到开发者侧。
  • 开发：按照测试的总体设计书写用例，这有很多种方式，比如就写在代码的test里、用低码平台书写，但核心你一定要和测试平台关联，这个关联有很多方式，低码平台那自然是天生关联的，写在本地代码里的话呢？有很多方式，我最推荐的是用测试平台的id（这可能有意义，也可能无意义），Anyway，再把测试平台的描述（这很让人难看懂）放到测试方法的注释里。这样我们测试就只有一个Truth，就是测试平台，从工程上会更好。当前为了炫技，我还考虑过用Powershell解析Java语法生成，还买了一本Powershell的书（笑），需要投入太大，后来就没搞了。
  • 某低码平台：没什么的好说的
  • Test平台：基本上上面都讲了

2024年，我倾向于在代码仓书写测试用例的方式来完成API Test的工作，它实际会更快一点。
2025年到不久之前，我在想低码化是不是更好，代码将来是burden，是负担。人来仅维护描述，测试用例的书写相对很模块化。

但是，最近我们将 测试平台的id（这可能有意义，也可能无意义），Anyway，再把测试平台的描述（这很让人难看懂）放到测试方法的注释里 这一部分SKILL化了，这是很大的提升，过去，我们对着测试平台一个一个复制方法名称，再把描述拷贝到注释里，这样的工作不复存在了。SKILL起码把这一细分流程的效率提升了10倍以上。可以预想，开发者不会再抗拒这个工作，为什么要拒绝有丰富经验的测试帮你设计好的用例呢，同时还生成了方法名、注释来引导Agent更好地生成代码。

这某种程度上也是贯彻SDD的理念，将流程串起来了。

最后是我想抒发的感受，过去，我们开发一个这样的工具，可能需要一周以上的时间不止，现在我们用SKILL，优秀的工程师们，一天乃至半天的时间就可以完成。尝试让AI Agent直接生成交付件，把重复的工作SKILL化。