七星海棠2022-05-24之前项目做的自动化思路大概也是这个样子，运用了srp和ocp原则，但没有这么系统地思考和总结，看了这篇后，思路上更清晰了，以后跟别人介绍的话措词上可以更专业了作者回复: 这说到点子上了，能做也要能说。知行合一才是真学到了。
2- jogholy2022-05-16如果testjob最后根据roi分配到了不同层去做自动化，又怎么做到互相咬合的呢?不同层的实现工具都不一样，数据结构也没有共用，是需要自己搭建一个分层自动化的大平台打通层次之间吗?
作者回复: 在链接工具一讲里提到了这个思路，让工具的归工具，让框架真正起到超越工具的作用！
共 2 条评论1 
Sarah2022-05-02当前项目是纯前端，我觉得是跟testJob 类似的思想，也是采用分层的方式，也是测试设计先行的原则。但是由于不需要验证后端逻辑，所以只分了2层，UT和E2E，在实现上，这两个层是相互独立没有交互的。 有点难理解老师所说的不同子job之间相互咬合的情景，求解惑🙏作者回复: 非常理解！讲这个Job模型设计，是一个新的设计方法论，需要从各个方面来介绍，就像盲人摸象一样，最后得出一个全面的理解，你不妨看完后面章节，再感受一下。可以加我微信，sunshinelius。
Sophia-百鑫2023-09-15 来自上海在定稿的设计图里，个人认为下订单的job 应该可以去掉。即整个订单测试步骤 是 登录job->创建订单job->验证订单job ，这3个job属于同级并有前后依赖关系，验证订单job可再拆分成快递号验证，短信验证，UI 验证， 其他验证等Job。下订单job去掉的理由如下： 下订单job 的描述不够专业或不够清晰，不符合单一职责原则，此外放在那里使链路可读性差。 请老师看看是这样吗？
linxs2023-09-06 来自广东之前做的api自动化，是自己封装了脚手架，input包含测试数据，重试超时机制，以及一条流程的配置信息，然后脚手架去解析执行这条流程，然后输出日志和结果，然后每个测试场景写一份配置文件即可执行
鑫宝2023-07-11 来自上海之前做的都是框架里面。 testcase 里面套步骤。 第一次接触老师的 test job 理念，还是挺新的。但是不太理解，看来得多看几遍才能明白了
Geek_225ad62023-04-25 来自陕西我理解：手工测试当然也是适用的，而且这里也可以手工和自动化结合，将大的Job细分之后，部分的Job自动化，大的Job不能完全自动化部分，手工执行，和自动化部分合并输出结果 Job方法本质是一种抽象表述分析的方法