我们软件测试课程有课程分组任务，我选择了STEP模型，刚好最近Plate在重构中也在经历测试阶段了，借此机会我希望用STEP为框架去理解Plate的测试实践。本文只是自己的思考，肯定不100%正确，但是足够了

何为STEP模型

STEP模型是软件测试中的一种测试模型，具体我感觉我也说不清楚，可能问Ai，才能知道最标准化的答案，我只能去回答一些自己对于这个事物的认知。

STEP模型思想，把测试融入进来的了开发的过程中，让开发和测试紧密结合（？？TDD测试驱动开发？？）。分为三个阶段

1. *Planning--测试规划*
2. *Acquisition--测试资源准备*
3. *Measurement--测试执行与评估*

可能做个人项目的时候，不会考虑很多，就是一直写，考虑功能实现即可，也不会考虑什么地方可能会出现什么Bug，当然可能会自觉维护单元测试。然后，等东西做出来，自己使用的时候就发现了有很多的bug，然后就去修复，修复后自己又使用，发现bug确实修好了，那就心安理得的万事大吉了。后面又出现了Bug，代码改动太大了，不小心让之前的修好的bug回归了，然后又只有测试了单个的刚刚修好的bug，就导致bug回归了，你还被蒙在鼓里。然后你在修好一个bug的之后，你还会对之前的修好的bug进行测试，但是随着你bug越修越多，你每次修复的之后，测试的成本越来越大（因为之前修复好了很多的bug，每次修完bug还要测试之前修复的bug，防止bug回归）。为了解决这个问题，你又想到，在修复完bug后，我要留下一份自动化测试，以后让自动化测试测试bug有没有回归。这样一套，自上而下的思考，就可以引出来了STEP模型的思想。

现在自下而上的回归，我们开发的时候，就要去思考我们应该怎么测试，留下什么测试。写代码的时候，准备测试用例，测试数据，留下自动化测试，写完功能跑一遍自动化测试，但是还会有没有考虑到到的bug。如果后面实际使用中又出现了bug，那么我们就只需要在此基础上修bug和测试功能了，不用为之前的bug而烧心了，积累的自动化测试会保护好已覆盖的行为，持续回归保护。

STEP思想去理解Plate测试

我们把Plate目前要做的测试按照STEP的三个阶段去理解：

这样梳理下感觉就清晰很多了，也方便我自己去理解了接下来要做的事情（等Ziad起床后安排好工作，然后就去实际测试录屏记录Bug，提交issue）。

其中这种提前植入Bug的方式我觉得还挺有意思的，不只是为了让我们找到它，还能帮助团队判断测试方法有没有发现问题的能力。检查“这个功能表现对不对”，是在评价产品。比较不同探索方法能发现多少已知问题，则是在评价测试过程。

比较有意思的是，测试计划还会记录每条回归测试源码的 hash。Agent 准备下一轮测试时，会读取上一轮的记录，再通过 pnpm kb 获取当前测试的 hash 和 CI 覆盖情况。如果 hash 变了，就说明这条测试被修改过，需要重新确认它还能检测出原来的 Bug。确认方式是让修改后的测试在修复前的代码上因原问题而失败，并在修复后通过。核验完成后，再更新记录中的 hash；否则，该问题仍保留在待复测清单中。

Tail

STEP模型是一种测试的指导思想，但是我感觉，其实很多的时候不用去过分的去使用这种思想，很多事情其实都是水到渠成的，是经验主义？做多了就知道了（或许这些理论是从实践中总结出来的）。我感觉其实更要关注的是如何让Agent在写代码的做好测试，做一套很好的测试流程，让Agent的代码能更加的信任，lauren大佬就做好了这件事，视频中能学到很多。当前团队对于测试的看法是要以全自动测试作为长期的目标，不用人工测试。

写文章我觉得是一件需要去坚持的下去的事情，尤其是当今信息流这么的庞大，安静的写写文章才能更好的引发起自己的思考。每次Astra用麻木的时候写写文章可以给自己醒醒脑，就算写写日常也好。