接口测试 新公司搞自动化让对着用例翻译，这合理吗
背景：
- 新到了个公司，公司要搞自动化
- 直接甩了个几千个用例的文档，让我挑出来能实现的用代码翻译
- 公司不搞接口测试，不是互联网公司，传统软件公司
然后我说这用例太多了，咱先从核心开始把，让熟悉业务的先把核心给我摘出来。说行
后来核心晒出来有个三四百条，我说这都是端到端功能用例，我们可以先把重要的接口，业务流程搞成自动化，最核心的用户最常用的操作流程用 ui 做一遍。
领导听了发话了，接口是应该研发自测保证的，做了单接口也没意义，ui 的维护量太大不能做，就让我对这用例看看哪些是和接口有关系的。把用例里涉及的接口都一个个理出来，再串起来做成自动化用例。。。。老哥们这合理吗，我人傻了，接口文档也和没有一样
我这样搞完，最多也就是提高了后端的稳定性，你业务该怎么测还是怎么测啊， 除非前端不改，就后端改了，这样跑完正常的话业务不用再测试这个功能。
吐血。
不河里，我觉得现阶段实际情况以及你的想法该说还是得说，不听咱再想办法。
传统公司都是以稳为主，这种想法很正常。我建议你先和领导沟通：
- 评估一下现有的几千条用例，是不是都适合直接转化为自动化用例？ 2.如果不适合，是不是可以先从主要流程入手？
传统业务没有接口文档挺常见. 曾经见过传统业务的 UI 自动化用例搞到 2000 多条的. 业务不同, 适合的方向不同.
可能你接触的这个业务不太适合搞接口测试? UI 搞起来.
直接甩了个几千个用例的文档，让我挑出来能实现的用代码翻译
- 让你挑
- 挑能实现的
有这么大的主动权了，还难吗？
前期基建不搞好，搞 UI 自动化跑几千条 case 就是个自杀行为。
没啥用，你领导看起来不懂技术，觉得自动化就是银弹
你一个人弄的自动化，不管做多好，你的同事还是该怎么测就怎么测，因为他不了解你怎么弄的话，是没法完全信任你的自动化的。
看你这个领导给的任务，像是为了自动化而自动化，而不是为了提效而自动化。你先问清楚你领导做自动化是为了啥吧。
做这个的目的是啥？如果是你的 KPI，将就做呗，管他用不用的起来呢
我还碰到过更离谱的，我以前在一家公司刚入职的时候 ，丢过来上百个接口文档，让我都自动化掉。用例都没有，都不知道如何下手，最后没办法，只能一点点找人问，整理 请求链路，业务逻辑 写自动化。
可以先从冒烟的用例开始做，做完冒烟用例每天定时 run 出报告也能体现你的价值了。
领导说单接口有开发保证那你就安心做好 UI 呗，传统公司可能更注重 UI 吧，接口一般没有问题就可以了。
我司目前是主要做 UI 验证 + 接口辅助 UI 步骤，BDD 模式的，根据优先级来写自动化 case
个人拙见：
之前做过类似，大概需要几步：
- 接口文档如果不足，需要和领导说明，将接口文档做起来；当然，听楼主描述，可能性不太大；
- 测试用例分级，例如分成 P0，P1，P2，P3，P4 等；测试用例分好级别后，有回归的意义；
自动化本身从零做起，应该就是从回归测试开始做， 做的过程中调整策略，根据项目情况，人员情况，调整覆盖范围
如果只有楼主一个人做的话，其实自由度很高， 真的做好了之后，收获会很大；最好能加上邮件汇报测试结果，抄送所有测试人员，能够提高自动化测试的认可度；