这个就相当于问你给把小刀怎么测试。
从功能，易用性，可靠性，安全性，兼容性等等这些角度去测试。
详细的测试用例就很多了

单聊能力提升，至于团队具备能力以后，成员是否有被组织调动起来的意愿，这个不论了（这个应该是属于激励层面的事情）

部门里面不同能力层级的人，应该有不同的提升方向。
最下面执行层的人，做基础知识的巩固，技术能力的拓展，还有价值观的宣导（比如敏捷文化，甚至职业素养）
中间的核心骨干力量作为团队引擎，主要做创新能力的培养，前沿技术实践这些的灌输。
然后上面的，提升管理能力，多给团队搞搞团建，明确目标。

我觉得这些应该就差不多了。

嗯，有道理，多谢

抱歉，截图的文字打错了，我已经修改了。 实际发现 exec 文件只有 class 级别的覆盖信息，所以我比较纳闷他实际是怎么解析出来的。 因为连方法名和行数都没有体现出来，难道是这个信息存在其他地方？

建议前三年还是不要碰管理。 技术不积累到一定程度，没法带人的，除了追进度，没法做深入的东西。

多谢分享

好的，多谢分享

大概分这么几部：
1、下载 jacoco 包
2、在业务系统添加启动参数
3、使用 jacoco 命令行收集 exec 数据
4、使用 jacoco 命令行生成测试报告。
我之前参考https://www.cnblogs.com/wang1001/p/12627198.html这个来搞的

和单元测试度量覆盖率一样。 在手工测试完成以后，从部署应用的服务器上收集下覆盖数据就行。
我们这边是 java 语言，使用 jacoco 来收集。 兄弟你有时间也可以去了解下

嗯，说的有道理。 看来增量的计算得赶紧布上去了

增量到 70%，你们的线上质量控制大概是个什么情况？ 你们是什么类型的业务啊？

现在这个问题有答案了么？求分享

是的，通过下面这个命令就可以直接在容器内操作，通过 jacoco 的命令行来收集 exec

kubectl exec -it <podName> -c <containerName> -n <namespace> -- shell comand

楼主现在面对的问题，我正在干。
类似恒捷说的那样，一个容器你就把它当做一个独立的服务器来操作就可以。
我这边服务大概有 200 个左右，每个服务至少两个容器节点。 直接通过一个 k8s 的 master 节点，远程操作所有 container 就可以

我们获取 exec 文件是通过 tcp 方式获取的，在部署 java 应用服务时，指定了 -javaagent 参数的 output 为 tcpserver ，并指定可用端口，所以 javaagent 参数设定如下： output=tcpserver,address=0.0.0.0,port=6300，

我看到文章里说用的是 tcpserver 的方式输出，但是看系统设计图，写的又是 tcpclient 的方式，这块是不是我理解偏了？

能不能科普下 tcpclient 模式是怎么使用的，目前平台这块的资料很少哦

可以指定 sourcefile 的位置

1、你能获取到这些指标数据，比如 70% 的覆盖率，特别接口 95% 的覆盖。
2、没有产生一个 bug。
上面这俩都是价值了，你能作为参考，告诉你业务基本没问题。

这东西就跟空气一样，不产生问题的时候，什么都好。 哪天没了空气你试试，会举步维艰

en......看了一半，忍不住出来冒个泡。 首先夸下你领导，我觉得做法没什么问题，和我们目前实践的过程很相似。

1，验收要由测试做用例文档出来，供需求方来验收。
2，测试应有决策权，决定项目上线否。
3，决定上线应对照上线标准来，但是上线标准是根据测试报告来的。

问题 1： 我不清楚你们的业务是自研的系统还是向第三方开发的系统，如果是第三方的，这个步骤肯定非做不可，这个是交付物之一。
如果是自研的东西，也是要测试用例的。不过在于测试用例是啥形式。
比如公司自己的电商网站，俩周一迭代，处于项目前期，那么着重与内部迭代堆砌功能，写个 xmind 保障快速验证就 ok 了。
到中后期以后，每次上线都要做大量的回归，那么这个时候要分析的东西就多了，是否影响其他功能，是否影响历史数据，是否要做兼容性测试？压力测试做了没？主流程要跑哪些？ 最关键的是，你怎么证明你的结论是可信的 ----- 只有用例。只有你执行用例的测试计划能说明。

问题 2：测试是否要有决策权，决定项目上线否？
必须要有， 这个是血淋淋的教训，遇到能放权的领导，一定要逮住别放。
我们之前发布节奏很紧张，由于是按照微服务拆分的团队，中间还会时不时的出现各团队发布热修复的事情。 所以项目交错的情况下，时不时来个发布，测试会疲于奔命，累死不说，还无法保障发布质量，上线就背锅。
反馈有有风险之后，前面的领导的解决办法就是，加班或者号召开发一起测试。但是实际产出是不明显的，在团队能力没有达到快速验证，快速发布的情况下，发布的越多，失误越多。 测试全盘防守，bug 攻其一点，屡战屡败。
后来新调任的大佬拍板，后续的发布申请最后一环由测试团队老大决定是否发布，发布频率要维持两周一个版本，中间发布的规则，测试来制定。 这样运行以后，测试这边的工作量大幅下降，除了一个第三方对接的问题，目前其他团队没有听说反馈很严重的线上问题了。

问题 3：上线标准的问题。
一定要有，和问题 2 结合起来看。 建议采用 DI 值来控制质量，大于 DI 阈值，坚决不能上线。
这个 DI 的结果是直接从测试的测试报告中拿来的，让测试的结果直接决定是否达到质量标准。这样测试才能对质量负责，其他情况下受团队干扰或者发布日期干扰后得出来的发布结论都是不靠谱的，猜都不用猜，肯定是带病上线。

再后说下 UI 校验产出的问题。
测试做 UI 测试，真的是不专业，这个是事实。 产品上线后，UI 有问题，测试挨骂，UI 也得挨骂。
所以怎么办？专业的人做专业的事。 每个迭代发布前，让 UI 检查交互和页面是否符合自己的设计，但是问题的定级是否必须修改，这个需要测试和 UI 讨论下。

最后说下测试的角色。
以前看过一个大佬的帖子，说测试以前分功能测试，QA，测试开发，现在是三位一体。我觉得很对，我们这边目前招聘测试都是要问下是否用过 python，有没有写过自动化代码，你们的迭代过程哪里做的好，哪里不好，出现过最大的线上问题是啥，迭代延期了测试是怎么做的。 为什么问这个，因为这个就是测试现在面临的问题。
敏捷的文化已经流行起来了，当开发是小团队运行的时候，测试也会跟着去适应。1~2 个人负责一个团队的日常测试工作的时候，除了用例设计，执行这些要掌握，团队的沟通，问题反馈，持续改进，自动化落地，这些都是测试的事情。
测试处在整个软件开发过程的相对最末端，前面的需求，设计，开发，转测，哪个环节出了问题，受苦的不得是测试。 所以，保证一定的敏感度，推动改进，从利己的角度讲，也是必要的。

测试这个岗位需要懂的东西很多，除了测试理论，往高了走，简单的运维，开发技能，项目管理能力，推动解决复杂问题的能力，团队管理能力都是路上的必修课。

从你提问看起来，目前你应该是团队的 leader 了，最后，祝你好运！能快速的成长起来

我们这边目前在使用的就是 locust，作为性能测试工具使用，看起来蛮不错。 本身前端页面可以展示 tps 的变化，另外从阿里云的接口获取到服务端的数据，进行分析，基本上不用做什么事情就齐活了。

不过要是作为性能测试平台的话，我不清楚你要集成什么功能。 如果你要进行历史数据的累计，然后进一步做各种维度长期的数据分析的话，可能用 Django 开发比较好一些。

嗯，是的。 一直在纠结怎么判断是修改的删除和 非修改的删除，钻牛角尖了

需求会议 -- 设计 --- 设计串讲 --- 用例评审 --- 测试。

在用例评审阶段还有人质疑需求和解决方案是不是太迟了？

没看到薪资的说明

使用代理以后还是有问题，还有其他解决方法吗？

发现网上的代理 IP 质量都不高，响应也比较慢。

我在什么芝麻代理和西瓜代理上都付费买过，每次都总是有一些 IP 是有问题的，没法响应。