感谢楼主的无私奉献,对 Python 不熟,有时间拜读下代码.

楼主是一个优秀的员工,赞赏,考虑公司利益的员工一个定是个好员工.

但是,公司的邮件,最好是不要这样直接 post 出来.

本人可以理解作为一个 employee 的尴尬.你想解决现有的问题,你不可以决定什么,你可以建议,但是建议是不会听的.

楼上有位兄弟说的很对,先找准自己的位置.

找自己的位置前,先确定自己的性格特质.不同性格特质的人,决定了他的职业发展.

如果只是抱怨,没有作为的 tester 也有很多,我觉得他们说的都很对,但是都没办法改变现实.

个人见解:

• 测试这个部门其实可以权利很大,因为他们要为质量负责 (虽然不是全部责任),不过这要看测试主管.我之前见过有跟老板对着干的.
• 单个 tester 也可以权利很大,他们的专业性是整个公司最强的,我经常对他们说,你们一对你测试的产品一票否决,但是确从来没人执行过这样的权利.
• 还有一般老板都是结果导向的,如果你能先把你的方案换算成钱之后.可能老板会喜欢看
• 书面正式沟通不如口头非正式沟通来得效果好,真的,不信你试试.

• 需求管理,看项目管理水平和团队执行力.
• 本身变更控制就需要很严格的,所以一般为了减少变更,通常采用敏捷开发方式.控制迭代版本周期.
  
• 搭建项目管理系统是必须的,这能解决大部分问题,但是前提是团队的执行力要跟上.不要指望以被通知的方式获得需求变更.所有的需求需要进入项目管理系统.
• 确认需求不应该在开发过程中,应该在需求阶段

测试过程中，QA 需要与产品不断的沟通确认需求

公司开发文化决定,楼主的角色可能左右,不过可以提提意见.

看了楼主的想法,还是挺不错的,消除重复劳动,可以提升生成率

前几天实现过类似的框架,由于是公司内部的,暂时还没法开源
不过可以交流下想法
个人看法

• CI,执行效率很重要,需要考虑并行测试.
• 执行生命周期不建议使用任务的方式,有时候因为程序 bug,没有接收到任务,可能无法判断,是否是 CI 成功.整个设计应该更简单一些,简单更强壮一点.
• 语言建议选择脚本语言,更新部署比较容易,开发效率也相对较高
• 将测试分层,基本的 HTTP error,可以使用全局控制,集成测试,还是需要写脚本
• 录制可以作为辅助工具,不可以作为判定标准
• 提供可追溯的日志,建议结合现有测试框架 (xxunit),并且记录 http 的 request 和 resonse
• 在测试报告中带上这些日志,可以让程序员马上定位到
• 数据库建议使用内存数据库,比如 mongo 之类的,有可能你还需要用到 redis.并行测试很可能需要加一些锁.文件有个比较大的问题是需要加写锁
• 尽可能不要用 java,类型转换会使代码量大大增加
• 建议脱离 jenkins 依赖,使之可以单独运行
• 不同环境,可以使用统一配置,然后使用环境变量作为参数传入
• CI 的情况很复杂,最好在整个软件的生命周期里按照一定的频率执行.运营产生的数据可能会使接口返回不可预期.
• 邮件通知名单可以和项目绑定,并且控制发送策略,有时候邮件刷屏会让程序员忽略.
• 生产环境做接口测试可能会产生大量对业务干扰的数据,这个需要提前做策略
• 测试脚本,最好是即放即用的,这就是脚本语言的好处
• 尽可能不要使用 DSL
• 注意测试框架的强壮性,任何框架错误可能导致大量发送邮件