手自一体提效软件测试

手自一体提效软件测试

什么是手自一体

开车的老司机朋友可能了解汽车的手自一体变速箱，这个方案既又自动变速器的功能，又允许驾驶员手动控制变速器的换挡过程。当然随着汽车智能化的推进，汽车研发的方向已经转变，在电动车时代几乎无人提及了。

那么，什么是软件测试的手自一体呢？

笔者在10年多前组建某个核心系统测试团队的时候，提出了“手自一体”的自动化测试的概念。当时我们发现，在该系统之前的测试团队（项目外包）在工作时，针对新业务改造的测试，采取的是一种“T迭代测本迭代需求，T+1迭代进行T迭代新增用例自动化”的工作模式。当然这也是那个时期很多测试团队的工作模式，甚至是某些敏捷教练口中的“敏捷测试模式”。（实际上测试人员是在并行处理三个迭代的工作，因为T+2需求也已经启动了）

为了能够实现在T迭代中完成本迭代相关的所有测试工作，笔者提出了能不能把手工测试和自动化测试同时完成的题目，在手工测试用例设计和执行的过程中，同步完成自动化用例的编写、执行和验证、入库的工作。这就是手自一体测试的由来。

以下是若干年前在“简书”上简单写的一段话，介绍的这个方案，核心在于写完测试用例用例后先执行（核心系统是纯后台，只能通过接口进行测试），用执行结果来作为测试用例的预期结果，当然还需要有一些配套的测试数据管理的工作。

###手自一体与预期结果生成

经过[某次缺陷漏测事件]()的根因分析之后，团队决定宁可多验浪费，不可少验遗漏的原则,对返回值进行全部验证。

为了减轻全部验证带来的工作量的剧增，团队设计了“手自一体”的测试框架。在预期结果及验证部分，有如下的特点

1）采用了“运行结果作为预期结果”的方式，不再通过人工编写预期结果字段值，而是通过执行用例步骤来产生执行结果，然后再进行人工验证，确认执行正确无误后，再将执行结果保存成为预期结果。达到了用例设计与执行一体，手工用例与自动化用例一体的效果。

2) 执行结果的调整。对于某些如时间戳、序列号等字段，由于每次运行时均不相同，且基本与被测业务无关，因此在测试框架中，还需要对指定的类似字段进行调整，在进行预期结果和实际运行结果比较时忽略这些字段。

通过上述调整后，就可以做到测试用例用例中预期结果的自动生成，而不是人工编写了。人只需要对结果进行稽核验证和调整即可，发挥的是测试人员的思考能力，而不是简单枯燥和重复的脚本和数据编写。

这个背后的逻辑是： “Do the thing right first time ,and any time”。

看到这里，可能有读者就回过味来了。说了半天，这个的底层技术不就是客户端的流量录制回放吗（不用管服务端依赖的那种）。

对于浏览器/APP的测试来说，有不少现成的工具可以实现啊。

例如，

1)在浏览器中使用Fiddler/Charles插件录制测试人员在页面上的操作

2)保存成为HAR格式，

)通过HAR2CASE转存为JSO/XML格式，成为测试用例，并做相应的修改。

4)使用HttpRunner执行测试用例。

这套方案全程不需要二次开发，直接拿着工具就能上手，非常适合缺乏测试基建资源的团队来快速上手。

当然实际用下来还是会有不少自动化用例本身，以及测试数据管理的问题，这个和前面的案例1是类似的。

案例- LLM重新定义BDD/ATDD

最后再擦边一下LLM, 碰瓷一下BDD/ATDD。

先说结论，BDD/ATDD 不是手自一体。因为要有人写一遍Spec, 然后再有人去写feature胶水层去把Spec翻译成自动化用例。所以还是两遍的工作量。

而在IDE中，LLM代码续写已经是一个非常常见的应用场景了。除了写点代码之后，按tab键续写代码，智能化IDE也可以根据描写的中文描述，来编写代码或者是单元测试代码。

类似的，也有团队在尝试基于LLM的测试用例转自动化用例的案例。只要写一句中文字描述的用例步骤，通过RAG+LLM的方案，自动续写出对应的自动化脚本。

这种形态下，如果再实施BDD/ATDD, 就是一种手自一体的模式了。

怎么样，是不是心动了？赶紧在新的一年实施起来吧。