【饭谈】AI生成用例...这个思路可能错了_测试用例设计人工智能

从大概三四年之前开始，我就在偷偷的研究这个路子- 智能的生成测试用例。

    因为那时候我想的是：各种自动化技术，都是在执行用例阶段发挥，那这之前的编写用例阶段，如果也能用智能自动化的办法生成用例，那岂不是爽死？怎么样中了么？正在阅读的你一定也曾有过这样的想法吧？

    于是，我在那之后创造了黑盒十一种用例设计方法的自动化辅助工具和相关算法，诸如状态迁移算法还被某n技术平台加精推广过。不过，很快这些工具迎来了瓶颈，就是永远都只能按照固定规则生成固定数量用例，它没法发散思维，没法去覆盖那些犄角旮旯，降低的成本也不过1/5而已。但后来业内出现了AI人工智能技术，这简直是救命良药，让我又再次燃起了希望的曙光。于是我便开始潜心去实现更像人的 用例自动生成。

    可是，在前不久，我却突然意识到，这条路线有可能是有问题的....

    注意，我是说可能，因为我到现在也还无法确定，更不知道未来会如何，自己该不该继续钻研这条路线。

    起因是一个老先生跟我的探讨。

    老先生：“小饭，你说是先有的开发还是先有的测试？”

    我：肯定是开发啊。

    老先生：那你说，为什么有了开发之后就要有测试了呢？

    我：因为软件总有bug出现，老板不放心呗，才让测试独立成了一个大型行业。

    老先生：那你说，假如一个软件真的一个bug没有，那还有必要测试么？

    我：肯定得有啊，我们也经常发现一些提测的需求一个bug没有的情况，但是哪可能不测试就直接上线。

    老先生：那你都没测出bug，没有价值，为什么还必须得测？这不是浪费时间么？

    我愣了一下，心说【好家伙，在这等我呢？】

    我突然想起以前老师说的一句话，就跟老先生说：一条跨海大桥，人之所以敢上去走，那是因为两边有围栏，虽然没有人会瞎的一样脱离大桥走进海里，而如果有人要跳海自杀，那么围栏也没卵用。而那些车之所敢在上面行驶，也是因为有围栏，虽然围栏一撞还是会冲下去。但是这就是心理安全感啊，光秃秃的桥面没有围栏，谁敢上去？正如软件测试一样，一个没有经过测试的软件是不可靠的，没有人敢承担风险上线的，哪怕这个软件其实并没有bug，测试流程也可能没有实际作用，但是没人会拿阳寿去赌，该测还是得测。

    老先生：看来你是明白的这个道理的，那你为什么还要去钻研ai生成用例呢？

    我：毕竟可以省去很多人工成本啊！

    老先生：那我问你，ai对某个功能生成了用例之后，你还会去重新手动写一遍用例做对比么？

    我：我当然不会，ai都生成了，那我为什么还要写一遍？我有大病？

    老先生：那你是怎么确定，ai没有漏了用例或者测试点呢？

    我顿时哑口无言...

    老先生：你根本没法确定，ai无论生成多少，哪怕真的生成了100%的用例，但是你仍然不会放心，只要你一天没有亲自手动写一遍用例做比对，那它就是一天不可靠！没测之前软件不可靠，你用ai生成了用例之后，依然不可靠。疑心生暗鬼啊，当怀疑一旦出现，那罪名就已成立。测试本来就是要测个可靠求个安心，结果你满眼都是降低人力成本，却把本来可靠的事再次变得不可靠起来。这是动了测试的根基命脉啊。就算你同意，你领导，老板都同意这样。但是客户会同意么？比如说银行app告诉你这个存钱功能是ai来负责测试的，一旦漏测你就倾家荡产，你还敢存钱么？

    在未来，通过小成本ai测试的软件可能会被打上【廉价】【不可靠】【不负责】等标签，那和没测过的软件相比并没有本质上的区别，一样会遗留不知道多严重的bug。而那些手动写用例测试的，会被打上【纯手工】【高端】【可靠】的标签，让软件身价暴增。

    测试本来相对于整个软件研发流程来说，人力成本就很低，而意义却重大，那就是让不可靠变的可靠。而有格局的老板，不会因小失大，为了省掉这点测试人力成本，就让不可靠之后变的还是不可靠。所以，这条路可能行不通。

    我听完后，沉思良久，也许我曾经的那种没有使用发散ai也没有太先进的智能，就是一个简单的辅助生成工具反而更可靠一点，虽然省掉的成本并不高，而且还有无法逾越的瓶颈。

    但是，我毕竟不是普通人，我眯起了眼睛，看着面前的老先生，怀疑起他的动机。

    我问他：那您跟我说这些是为什么呢？

    老先生：没有为什么，只是点你一下。

    我：嗯，感谢指点，我会慎重考虑的。

    回到家，我心说 [谁信你啊，你个糟老头子，坏的很！你虽然很懂测试，但是你不懂市场，更不懂人性~ ]