协成这个东西这么不好理解，需要一定水平才用得了，另外一般测试脚本用得着协成异步 ？(性能可能需要，并发加状态切换)
重试这个东西，直接一个装饰器就解决了。

为什么那么多人把 bug 管理、用例管理、测试产品/版本管理这些周边的东西，融入测试本身来。
作为一名普通测试，这些都不是核心，这些东西其实是测试管理方面的东西，跟测试小兵没什么毛线关系。
何况这个平台也只有一个接口测试功能，实际上的产品可能需要的是 app 测试、web 测试、rest 接口测试、CLI 测试、SNMP 测试、串口测试、UI 测试、嵌入式 API 测试、等等。我觉得先把这些东西独立搭建起来才是重点。
不用搞这个网页，自己仿照别人的代码实现一套功能框架，比如在 linux 下如何使用 bash 脚本实现一套自动化框架？如何通过串口对嵌入式系统的 API 调用实现一套可行性的代码？所有的框架都是麻雀虽小五脏俱全，日志、断言、参数导入、用例识别、测试套、参数恢复、结果统计等等。
小厂说实话，根本用不上这么高大上又全面的平台，自动化测试框架本身就够了；大厂这些东西也用不着你来做，可能测试工具部都已经做好了，用就行了。

1.自动化测试只能有后端人员来写脚本，因为公司的测试人员没有这个技能。
---- 我是后端开发，又不是测试，为啥要我来写 ？
2.没有设计合理的测试用例，只能通过用户行为驱动去覆盖 app 的功能。
---- 我不会测试设计，怎么办 ？
3.在上线新功能的时候，测试人员已经把所有的功能都测试完了，自动化测试方面都还没有进行或者进展很慢，跟不上发版计划。
---- 好像来不及自动化，版本就要上线了，自动化了个寂寞。
4.在实际使用过程中，很容易出现一些异常情况，例如：单个测试用例运行毫无问题，一旦串行多个测试用例或多或少的会出现一些异常现象。 该怎么来规避？
---- 这他么自动化有这么多坑，咋填 ？
大概翻译了一下你的迷茫，翻译错了的话，切勿对号入座！！！解决方案：
1、怒吼老板：尼玛是舍不得花钱请自动化专业人才吗 ？让老子一个后端来顶。滚！要不就自己滚！很显然，开发经理对于自己的重臣，是不会抛出去接这个锅的。被抛出去的，肯定不是领导的心腹。
2、环境太差，舍不得滚，怎么办 ？硬着头皮上，恭喜你成功从后端开发转型成为测试开发！新任自动化测试经理一枚

是的，我说的前提是"测试做得好"，很多知识只需要了解，但是需要了解的东西和需要管的杂事要比开发多很多。
如果对于这个有疑问，你可以试着去观察下，或者问下论坛里面几个大佬，特别是那种独立把公司的测试平台搞起来的那种。
同样的岗位级别，薪酬水平要比开发低一个档次；业务和技术深度确实没有发开深，但是需要的知识面比开发多太多。
如果是那种大公司的，测试工具、bug 平台、用例平台、甚至自动化平台都有专门团队打包好了那种，就当我没说。

做测试开发，应该还不需要去刷什么 LeetCode 吧，那是搞开发才需要的。
如果你想做开发，我没有建议，因为我不会。
如果你还想做测试开发，那你就去把你的 python 和 UI 测试研究深入一点。
面试的时候不要怯场，你自己都觉得不行，那面试官凭什么会觉得你行。
先找到工作糊口，后面的事情再说，进了公司一般都会有一段时间的适应期，适应期里面好好表现做点成绩就行。
学习的事情，一旦开窍，就很容易突破了，前提是你得沉下心来学。

你的测试数据如果不是成百上千，你就不要放到 excel 里面管理，直接放在普通文本里面，或者直接作为 python 的变量来储存就行了。一个 Pycharm IDE 就可以管理，非要去打开几个 Excel 占内存干什么。
另外一种变通的做法就是，你把你的接口定义的默认值放在 excel 里面 (注意这个 excel 以后都不动，除非开发增删改了接口)，然后在测试用例里面对这组默认值取相对变化的值 (自己实现一个函数)，来形成同一个接口的各种各样的测试参数。

你这个框架分层好粗糙啊
建议你分三层，公共 API 一层，业务 API 一层，测试用例一层。
每一层都是一个独立的 python 包，这样你再加入新的产品、新的业务 API，就可以做到很好的封装和隔离。
测试数据和测试配置 conf、测试报告都归测试用例那一层。
测试用例的上一层就是测试执行器，也就是你的 run_test.py

既然不喜欢写代码，现成的 java 开发工作也要转成测试点点点。
测试里面有技术的大多都需要写代码，要么是行业业务专家，跟你的初衷背离了。
测试想要搞得很好，学习的深度虽然比开发浅，但是学习和工作内容的广度要远远超过开发。
建议你搞人际关系，走另外一种通道。

这是可以对不同的 key 有不同规则功能的：

图片里面有错误，应该是 cmpdict.items()
这个对比功能也可以放在 **kwargs 里面实现，动态的，有几个就加几个。就可以不需要那个 cmpdict 参数了

你看这个可不可以：

能达到这么高的水平，还来做什么测试 ？
移动互联网测试行业卷的这么厉害吗 ？ 按照文中这个思路，一个公司只要一个测试就够了，因为他又要懂行业懂产品懂业务，又要懂测试懂开发懂运维，还要懂管理懂架构，还要能够 996 加班测版本，文能与产品开发撕逼，武能撸代码写工具设计 QA 架构，然后拿着同水平开发一半的工资，等着 35 岁被裁员 ...

不要谈感情，谈感情伤钱。工作就是工作，把工作做好，拿薪酬。
想学到更多，除了喜欢折腾之外，极有可能是对自己的认可和期望都很大，希望能够用最短的时间达到一个目标台阶 (薪酬或岗位级别)，然后再慢下来沉淀。
说话也不能太直，太直了伤人，容易招小人，当然除非自己很强大。但即使这样，虽然小人无法伤害到你，但他们可以在某些地方拖累你，有时候一句坏话可能就会影响一个员工在老板心中的形象。

itest 这个平台，好是好，就是什么都想做，感觉不好。
项目管理，需求管理，测试任务管理，人员管理，测试用例管理，bug 管理，指标统计都可以放在一起，都是属于测试管理层面的事情，一站式很好。
但是为什么要把测试执行和自动化测试集成到里面呢 ？ 环境管理、脚本编写、自动化接口测试，这是具体执行层面的东西，混进来之后反而造成了这个平台的混乱。
本来测试执行层面的事情都不是一个工具或者平台可以搞定的事情，itest 怎么可能都搞得进来。目前 itest 上面集成接口测试之后，就把自己限制在很小的一个 web 接口测试范围了。接口的范围太大了，CLI 接口、SNMP 接口、NetConf 接口等等，除了接口测试以外呢 ？ GUI 测试、场景测试、嵌入式测试.....都包含进来吗 ？
任何一个产品都少不了几种测试手段或者工具，强大到如 jenkins 这样的工具，也只是提供集成接口来进行工具之间的衔接，而不是全部囊括。
什么都想干反而可能搞不好，就算想都做，最好把自己的平台做成一个工具集，可选的插入式集成。

关键是要实践，光看代码没有；在实践中调试并找到成就感。

说的很对，眼界不够高见识也不太广，外加缺乏一些魄力。

在这些点上就可以，任何形式都可以，我也不是特别能系统地表达出来。
我个人的做法是与下属更多沟通式的交流，而不是命令式的；另外，我会引导下属从心底里想学技术。

暂时只考虑深圳广州。

站的高度比较高

一路走来不容易,但是努力的途径总是相似的.

谢谢捧场

有空的话我会再发表我的技术分享,你可以关注一下.
另外我自己目前也在谋求新的工作,暂时不方便谈论带不带的事情.

谢谢

修改了一下,不是<测试设计的艺术>,是<软件测试的艺术>.

深圳 - 南山