基于 BDD 的 UI 自动化测试框架 - KoolTest

Apache License
JAVA
CPPAlien · 2021年09月13日 · 553 次阅读 · 0 条评论

项目首页:https://github.com/Kujiale-Mobile/kooltest
项目文档:https://github.com/Kujiale-Mobile/KoolTest/wiki

不管是需求文档、代码、还是测试用例,本质上都是一种知识的表达,不同时期每一种知识载体的权威性也不同。比如在需求评审阶段,需求文档就是最权威的知识。而测试阶段,测试用例又变成了最权威的知识载体。当代码上线后,则代码就成了最权威的知识载体(无线上 Bug 情况下)。如果每一步都做的很完美,那么这三个载体承载的知识点是一样的,只是表达的方式不同,但他们都具有权威性。但在现实中,我们是不可能做到如此完美的。很多公司的情况是,随着不断的迭代,需求文档和测试用例因为更新不及时,基本没有太大参考价值,线上代码成为了唯一的权威知识载体。随着研发人员的变动和项目的变大,最终导致没有任何一个人可以全盘知道这个系统的所有细节,代码上线也变得心惊胆战,而这导致了无法稳定的可持续性交付。

那我们要如何去解决这类问题呢?很自然想到的一个是,我们可以建一个文档,这个文档要尽可能和线上的权威知识源保持一致,在上线前投入人力按照文档上的说明逐条执行,如果出现问题就和开发沟通,去识别到底是产品需求的变化还是产生了 BUG。另一个可能想到的是我们要上自动化,我们再写一堆测试代码去描述业务,然后自动化执行发现业务问题。 这两种方法本质都是想在除了代码作为唯一权威知识源的情况下,去构建另外一个冗余的权威知识源。而这两种各自都有其缺点,第一种需要大量的人力资源投入做到文档的更新和执行上,往往很容易漏测。第二点产生的冗余知识代码书写和维护本身也是一个大难题,最终也只局限在少部分人中,最终一样不断人来人走,变得无人能懂。

那我们思考,可否把这些冗余的知识源既可以用领域语言的表达出来,而且还可以执行呢?目前行业中 DDD 和 BDD 的思想给我们提供了一些思路,KoolTest 框架即是该思想理念的集合。

评论列表
暂无评论.