看了这个标题时候的感受：
问题是： 研发提测质量导致测试工作量加大，因此公司内部开始推行测试对研发的提测质量打分，与研发的绩效考核相关。
对策是： 给研发提测质量进行打分， 请问这不会加大测试工作吗？ 难道研发提测质量的提高只要政策一出就能马上改好吗？在没有改好之前，测试工作量是大了还是少了？

看了 测试对开发质量标准的感受：

1. 研发文档，具体指什么？这个有过于教条的问题，也很难评估，写一句话说清楚了和写一大堆说不清楚，不是有产品经理有需求文档吗？不是有 Bug 描述吗？不知道这个指的是什么。
2. 测试顺利程度？这是什么意思？主流程没有 Block 的 Bug？低级 Bug 不低级根本不重要，只有严重程度高的 Bug 才重要，所以低级 Bug 是什么？
3. Release Notes 需要完整准确： 我有点好奇，难道没有 Bug 管理系统吗？修改了 Bug，直接 Bug 就进入 Release Notes 呀
4. 是否有自测： 不是和测试顺利程度有相关性吗，测试关系的是结果，是不是否自测已经是手段了，如果质量好，不自测由怎么样？因为人家找到办法了，你管不着的，看结果的。这和表示质量的指标没有一毛钱关系
5. 是否有已知问题： 就算知道了，也不告诉你，你知道吗？也不是质量的指标吧
6. 变改变测： 这不是常态吗？有 Bug 马上修改，和方便就发布了，马上验证，否则 CI 要来做什么？我很难理解这个的出发点是什么？变改变测很明显好处是开发测试流程缩短了，不太好的是，确实有时可能会改错，或者影响一下其他，但是我觉得没有上集成环境/回归环境，变改变测是常态呀，要不然发明哪些 CI 我不知道为了什么？

当然一笑而过，只求大家都不要太为难相互，出问题之后可能有很多原因的，太宽泛的提测质量不好一句话很难说清楚，没有具体的东西的话，之后怎么评估提测质量好了呢？工作不要搞得像仇家一样。

支持

做完这些应为不太确定是不是完全正确，然后需要测试再全量回归一下，有时想想测试确实痛苦，这本来就是不存在的事情。及不重要又不紧急的事情，最后被推到了又紧张，又紧急的事情。关键是万一问题还要背锅，没出问题都是应该的。测试开发何苦折腾测试呢。 就这个事情，和代码重构真的不在一个维度上的，代码根本就没有重构， 重构什么了？那个 Bean 还是那个 Bean，只不过是编译的时候把 GET/SET 方法给自己生成了而已，对代码没有做任何形式的重构。

提高效率是好事，但是提高到代码重构工具，这肯定上不合适的，这肯定说不上重构，哪怕一点都说不上。

用@Data和用 IDE 直接生成 GET/SET 没大区别，就是看着烦了点，但是 Lombak 说不定还存在点坑，然后不只不觉的就引入了风险。

一切都是矛盾呀，一面说管控变更，一面一动手就用代码改代码了， 代码改代码风险并不会小。

业务体量还不够复杂，这个确实，不过呢也不算太简单，同时业务体量这个东西很有迷惑性，是指功能多？还是指用户量多。如果用户量多，其实呢不一定用例多。业务复杂，使用人少，也可能用例很多，所以这个光一句业务体量不够复杂本身就不够清晰.
公司内某业务回归几万条用例的问题，需要精准测试，但是呢，重复的多少？没人愿意去重新搞搞清楚的可能也是有的？
另外为什么要全量回归呢？不是拆分了微服务了吗，不是敏捷小步快走吗？那么如果还是动一下要几万个 Case，那么微服务的意义在哪里，敏捷的意义在哪里，是不是先反思一下领域拆分问题？

如果精准到几千条，那我想问下，如果直接通过优先级是 P1-P2 的过滤一下筛选，几万条能过滤到几千条吗？然后这个几万条用例，一条用例的定义是什么？是一个步骤还是一个场景？

个人觉得更全面的了解一下实际情况对我做决定很有帮助，所以多问几个问题。先谢过！

我觉得这些都没有问题，我只是考虑我自己实际的情况分析，同时想看看如果要做怎么做成本更低，

1. 比如你说 OpenTracingAPI，Skywalking 只是一个例子，事实上如果一个公司多语言的话，我第一反应链路 Trace 会比从代码 AST 解析出来分析要方便，否则你每个语言来一套？
2. 而追踪接口变化，我第一反应也是觉得通过 API Spec 文件差异更容易实现，而我们确实也是多语言也使用 API Spec 先行这种方式进行开发，所以我觉得没有必要去做 AST 方式或者 Parse 代码方式去实现；
3. 至于内部调用链和 Opentracing API 个人理解没什么冲突，如果 Tracing ID 一直传下去，直到返回，远程和内部调用没多大区别，至于是不是 JAVA 微服务，问题是我看到的例子大部分 code instrumetation 都是用 JVM 做例子，JACOCO 做例子的，如果是 JAVA 微服务，反而我觉得可能成本相对低一些，毕竟很多人都做了这个，至于其他语言的，我不确定成本会到哪里
4. 另外就是关于精准的判断遗漏，工程师还是会加入，那么你说为了防止遗漏，我觉得没问题，只是我们可能还没到这个程度，公司小选择相信人，毕竟最终你还是要工程师做决定，那就考虑省去这部分平台建设
5. 代码调用链路分析这个事儿，本身并不复杂，就是个会者不难难者不会的问题， 这个肯定的，几乎所有的问题都这样

好多对上英文你就不惊讶了，比如造数工厂， data factory，就这么个事情。

何必搞这么复杂呢？这样不行吗？ 数据驱动就在最外面驱动好了

import unittest
from ddt import ddt, data
type = [1,2]
@ddt
class MyTestCase(unittest.TestCase):
    courseClassify_list = []    #最终为[('data3', 'data4'),('data3', 'data4')]的状态
    @data(*type)
    def test_A(self,data):
        # 执行A测试用例并向courseClassify_list插入数据
        self.courseClassify_list.append(('data3', 'data4'))  #共2条用例，都会生成一份('data3', 'data4')
        print(self.courseClassify_list)  # 验证是否成功插入数据
        for item in self.courseClassify_list:
            print(item)

if __name__ == '__main__':
    unittest.main()

我觉得权责要对等，谁背锅谁负责，我都是直接说，我背锅那以后都是我负责，你们都得配合我，看整不死你们。。。。。。。。。

不会出现响应时间和 TPS 同时变多的情况，因为这两个本身就有点互斥的意思。

这都需要有前提吧，如果是多节点，分布式呢？响应时间长一点，TPS 增加也做得到的吧，而且分布式，多节点的目的就是用网络传输上有额外小延时的损耗换取获取更大的 TPS. 所以响应时间和 TPS 是可以同时增长的，就是有前提。

会 Java 才算是会代码？这么说的人大部分我估计也不会代码，现在语言和语言直接的差别越来越小了，各种特性都在趋同，并且还有发展，这么语言和好的，可以加到另外的语言里面去的。 脚本语言 python，typescript 和 JAVA 区别越来越小了，会代码这个程度，最重要的我个人认为是熟练度。