标签：部分 总监 不同 建议 submit pass 包含 最好 白盒测试
产品上线了，其中经历了多少磨难，如今还在继续。
No1. 产品不给力
产品上线之前，作为QA，有幸参加了公司的需求会议，不过这个会议把我雷的外焦里嫩。首先，产品对业务功能没有明确的需求。在讨论过程中往往是拍脑袋的决定，这一个决定包含了研发团队的多少汗水和痛苦。其次，需求真的很烂。 用户界面真的很丑，提示真的让人看不懂，作为对业务还算了解的人，看了产品定义的提示完全不知道在说什么。比如：‘啊哦.....’ 可能是代沟真心理解不了。也许审美不同，这个也算OK吧。最不能让人接受的就是这个界面经历的N次改版。往往是这版没做完，下一个版本就出来了。我想说这不是在黑板上涂鸦。最后可能是摊子铺的太大了吧。 各种平台，IOS，android，PC，Mac，web。不过大部分夭折了。
No2. 流程
上线之前，sprint迭代，除了需求变来变去，服务核心逻辑变过一次。还OK吧，工作挺愉快的。 上线之后就不敢恭维了，每个commit都需要技术总监确认。总监真的很忙啊，天天开会，是吧？哪来的时间去一直关注这个小事情呢？ 所以大家就一起等待，千年等你回。这样行不行： dev提交commit， dev或QA做做白盒测试(如果有)， QA做功能测试(针对commit的和回归测试)。 pass， 大家都可以submit嘛，fail？那只能从头开始了。
No3. 部署
devops，可惜啊没搞起来。其实个人觉得搞个QAops还是可以的，我们的ops对我们的业务，部署一点都不懂，每次部署都需要QA去指导。 哎。。。好处在哪儿呢，除了经常线上部署都需要好几个小时。QA做吧，很快的，最多不会超过半个小时的。 其实不管是上线部署还是对产品业务的了解，或者说是问题的调试，QA除了比不了专业人事，业务比不过产品，code和调试比不过开发，运维监控比不了ops。但是我们是dev里面，业务和运维监控最好的； 产品里面code调试最好的；ops里面部署和业务最好的。所以QA是一个承上启下的作用。发布部署找QA啊。 我们可以给你搞定jenkins，可以搞定安装脚本，可以丰富安装脚本。安装部署吗？分分钟搞定。
No4. Code管理
gitlab，分支太多了，一个项目一个分支。 我的测试脚本一个性能测试分支，一个功能测试分支。我都受不了。维护起来太麻烦。特别是端上，code不够健壮，不够灵活啊。
No5. 数据库表结构变化
上线之后,这个是最痛苦的. 到现在也没想到好的办法. 全新安装和升级. 特别是热生. 是一个比较痛苦的过程.
吐完了, 语言组织不好, 随便喷吧. 如果有好的建议那是更好的.
标签：部分 总监 不同 建议 submit pass 包含 最好 白盒测试
原文地址：http://www.cnblogs.com/v394435982/p/6412559.html
