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

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

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

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

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

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

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

    个人见解:

    • 测试这个部门其实可以权利很大,因为他们要为质量负责 (虽然不是全部责任),不过这要看测试主管.我之前见过有跟老板对着干的.
    • 单个 tester 也可以权利很大,他们的专业性是整个公司最强的,我经常对他们说,你们一对你测试的产品一票否决,但是确从来没人执行过这样的权利.
    • 还有一般老板都是结果导向的,如果你能先把你的方案换算成钱之后.可能老板会喜欢看
    • 书面正式沟通不如口头非正式沟通来得效果好,真的,不信你试试.
  • 快速迭代下的需求管理 at 2016年07月25日
    • 需求管理,看项目管理水平和团队执行力.
    • 本身变更控制就需要很严格的,所以一般为了减少变更,通常采用敏捷开发方式.控制迭代版本周期.
    • 搭建项目管理系统是必须的,这能解决大部分问题,但是前提是团队的执行力要跟上.不要指望以被通知的方式获得需求变更.所有的需求需要进入项目管理系统.
    • 确认需求不应该在开发过程中,应该在需求阶段

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

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

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

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

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