今天领导大发一通脾气，原因是组里的【质量】太差，次次被领导的领导提出来训，于是我趁这个机会了解了一下领导口中的【质量】是什么：

• 【SIT阶段的问题单】太多
• 【缺陷密度】太高

那么什么是【SIT阶段的问题单】呢，这里介绍一下背景：开发在没有需求单的情况下，提代码需要一个问题单，问题单里面有一个选项叫【问题阶段】。开发自己提单要选【UT】阶段，表示这个问题单是开发自测发现的问题，这样的问题单不会被统计质量；但是如果测试在测试阶段测出了问题，就要提【SIT】或者更往后的阶段的问题单了。一句话总结：测试测出来的问题单，就是SIT阶段的问题单

测试阶段是用来发现问题的，但是测试阶段测试出来的问题不能太多，否则要挨叼。熟悉吗？有没有让你想起学生时代“垃圾桶里面不能有垃圾”这样的规定？🙂

那么什么是【缺陷密度】呢？再次介绍一下：开发做需求的时候，每一个需求单需要填写一个【预估代码量】，然后开发通过这个需求单提交的代码会被统计并计算得到【有效代码】，【有效代码】是如何计算的呢：如果开发实际提交的代码低于【预估代码量】的一半，那么有效代码为0；如果开发实际提交的代码高于【预估代码量】的两倍，那么按预估代码量的两倍计算有效代码。所以代码不能预估的太低，否则代码写多了白写；有也不能估计的太高，否则更白写

想必制定这个规则的人一定是代码水平不知道高到哪里去的大佬；毕竟在自己动手开发之前连自己需要写多少行代码都能提前预估到👍

综上所述，【缺陷密度】就是【有效代码】的数量除以【SIT阶段的问题单】得到。相信聪明的你已经发现要如何破解这个局了，使劲写废话代码不就完事了吗？确实，只不过咱是有追求的人，不到万不得已，不想做这种无意义的事情。

另外，我司的测试水平仿佛还停留在原始时代。一说测试，就是一个测试经理（扯皮大王）带着几个测试点点点。自动化测试？没有。工程能力？没有。测试拿着一台版本号都被魔改了的测试机测出来一个无厘头问题，测试经理硬是狡辩不让开发走非问题。原因是：你能证明这个问题一定是机器的软件导致的吗？这种行为就好比：你做了一辆车给我，我开着这辆车在破路上摇摇晃晃，然后跟你说你这个车的性能不行，还要反问你：你怎么能保证一定是路的问题呢？万一车本身也有问题呢？在一条路上跑不出来，那全国那么多条路，万一有一条出问题了怎么办？ 先污蔑别人，然后要求别人自证清白，典中典。