看向哪个方向深入了，一般我们会分成业务、技术深度
1、业务深度
足够了解业务需求，在产品需求阶段，能够推进产品经理对于功能设计的完善，不合理以及挂件类功能，提前劝退
当产生功能歧义时，能够指导开发对功能需求的理解，推进产品及时进行功能需求更正
功能需求、项目进度整体把控，研发整个阶段足够敏感，各环节主动 push，及时审查以及推进各阶段风险解决

2、技术深度
熟悉研发框架，能够分析缺陷产生于框架哪一层，具体原因相关
与开发进行功能实现方案探讨，能够解读开发功能具体实现方案，提前规避研发风险（很多时候都是开发告诉我们如何做的，测试可以一起加入探讨，明确需求如何实现）
对于缺陷，能够有更加明确的日志以及问题原因分析（哪块代码，由于什么导致，建议如何修改 ，一些懂代码的测试同学，是能够辅助给出具体产生原因以及修改建议的）

还有一个方向是测试基建的完善
各阶段自动化建设
各阶段效能工具的建设
各阶段验收流程的优化（也可以做为基建一部分）

如果你可以起步开发，直接开发岗位还是比较合适的

这样测试会很累，费力还不讨好吧.......
不过也要看：纯保姆式，或兼职教育式了

如果纯保姆，只能说你们总监太会做人了......

管理员还没有走发贴审核，现在应该可以了

@charseki 楼主可以加我下微信 不 15910532052

接口测试脚本，最好以接口本身的功能转化用例
功能测试场景，只是使用到了接口中的功能

设备没有连接上啊

没事，邮箱我们也收到了，会正常沟通处理

我用的也和你这个差不多，是这个网站 www.json.cn

很多公司应该都有类似于这样的强制淘汰率，其实也是维持团队活力的一部分吧
不过我们以前是连续一直 C 会有被淘汰的风险，但团队中都不错的情况下，有可能人性化的做轮背，不过这个也要看公司文化了

不要这么消极嘛，因为有时候也是个机会呀。

QA 是负责整体质量的，上线后，如果出问题 ，也一定是 QA 负责，要背起来
但是我们会同等向上追责：
1、测试前确定的范围，是否包含
2、研发是否违规上新代码
3、运维配置是否遗漏
4、等等

重视研发的团队，出问题一般就会指向 QA
但强势的 QA 团队，出问题一定是向上追责且追溯的，谁都跑不了

很多公司奖金、职级晋升，都和绩效有直接关系，其实已经算是奖惩了。
我们以前针对季度 kpi 中某一项有过罚款制度，但并不是针对一线同学的，最后大家也麻木了，起不到效果后，废弃了

我的

来一场，35 岁以后职业人生探讨吧。。。。

好，你加我下微信 吧,我把活动详情也补全了，我手快点审核 通过了，只能我来改了
xiaozhao129540

活动，我们放开了，这个问题 ，我们修复下

目 前是延期~改动时间了

目前还没有变动，如果有变化，会及时和同学们进行沟通的

基于平台类型 的 java 的偏多一些，脚本向的 python 更容易上手一些

把具体内容贴出来吧？纯链接也没意义