系统工程思考收获：参数和模式的矩阵极为稀疏的现象（2）思考一些测试系统中的错误设计

这里，想举个简单的示例，来分析bug系统的一些问题。

来分析，为什么有些公司的bug系统完理成本过高的问题 。

用到前一篇的内容。

以测试为例。我们先来全局看一下。

两个最小粒度

测试平台，除了需求（或者CR）以外，case和bug（defect,issue）是两个最重要的最小粒度。

前文所述，最小粒度不可再分解。即不可再观察和分解这个最小粒度本身。否则管理成本一定高。以人体为例，一个系统，由12万亿个cells组成，所以，不可以直接去管理每个细胞。什么权谋术，洙如此类，在这里没有个蛋用。如果有用，中国早己世界第一了。管理是门科学，一定要相信科学。除非只想开个小夫妻店，或是像华为那样一定所谓的只做能做的事的对少数人bao正的公司（mzbz）。

用例相当于内部的合同，系统或需求部门，与测试部门，以及研发部门认可这个合同。其不可更改，不可分解。

测试的结果，导出bug.

bug在管理层面，比用例更加复杂，但它仅仅是测试与研发的接口，这个认可过程看起来简单（实际不一定）。

三管三控中的三控在测试系统映射的三个维度

三控指：成本（投资，赢得）、进度、质量。

三个维度，在产品序列和系统中的映射为：产品类型（版本类型组合）、版本发布周期（实际是生产周期，发布只是计划，能生产出来才行）、产品的特性总量。

如前一遍所述，最小粒度，我们分为三个维度映射后（见前文，以人体为例，钠门-酸碱差，钾门-电负压，胞膜的一端亲水，一端疏水，三个维度，由体液调节和控制其新陈代谢和生死），总有一个维度，会变少。

那么，我们可以发现，发布周期，是固有值，企业无法提升此值，因为内外因素这些客观条件决定此值，不可调优。

特性总量由市场竞争决定。代表质量。也就是测试用例。

产品类型一般而言，相对多些，代表公司盈利能力，即公司能否同时维持多种类型的产品，参与多种类型市场竞争，适应多类型用户。

（以智能手机为例，产品类型，也会变得越来越少（对产品经理不是好消息~~），这是趋势，但未必能普适，大多数市场产品，是小众的（当然，互联网人不了解民间疾苦），所以，类型很关键，特别对测试系统来说）。

OK，三个维度对上了。version(type) --money; plan--process; quality--casesuit.

用例和defect的与三维度的映射

二者类型。我们只关注defect好了。

我们create defect时要填的内容太多了。

这里有几个问题 ，一个是为什么不自动提defect呢？

当然可以了。前提是你的大系统是由良好的管理模型管理的。

否则提出来之后，将有几个问题：

1. 指向的version type要清楚，version type的问题 是它也在不断改变。产品经理总是在改变。而且往往是不可商量的。

2. 测试过程是动态的，issue是会被修复，修复后还有可能regression。这些过程都需要保存。而且，修复与issue并不是完全同步的。

3. 测试的质量责任，一般相对好匹配。只要issue指向case.当然，也不是那么容易，因为产品的质量，不是向case负责，而是向需求负责，但这里不是我们想聊的。我们假定没问题。

4. 人能看得懂啊。这个可不简单。

5。 反向可理解性，即计算机也能看得懂。这是大事，而且也不容易。因为系统面对的不确定性，导致系统必须有能力进化。

系统强调动态，强调演进。

但是，但是啊，。。。真正的系统，可不是抛弃式的演进，而是继承式的演进。

例如，今天QA觉得，先projecct，然后大版本，作为issue的描述，明天这个条件可能就不成立了啊。

那么之前几年积累的数据就放弃了？

是，很多人这么干。在一家公司，员工做不对的事，对公司有害的事，反而得到奖励，这是管理的问题，但在中国极为普遍。

因为有的不合格老板有时只认钱。特别是靠关系作垄断生意的。

所以有时我们讲管理，完全是在扯蛋。

我是说我也在扯蛋。

我这里说的技术管理，是强调在产品足够复杂的前提下的质量、进度、成本的市场竞争优势，给客户带来价值的能力。

但，如果市场是关系型的，质量无所谓，用户根本不用，讲管理都是扯。中国确定存在这样的问题 ，说起来头头是道，完全行不能啊。所以，大家扯蛋的情况，比不扯的时候多得多。

一个点：如何在ISSUE上将version type和版本定义体系关联上呢

以此细节结束本文。

系统工程师要将流程在最小料度上模拟后才可以认为是可行的。例如有人说华为20万人，搞软件没问题，那是因为你没像系统工程师那样用放大镜看看，华为的每名员工所处的KPI环境，以及价值观环境。以及这种环境只能招这类人，这类人又进一步加强mzbz  的现实的情况。勿在浮沙铸高台。当然，开放和动态，也是关键。还有数据继承。

======================================

issue上关联的version type，应当只是一个id.

这个ID指向一个版本阵列。

然后由一个算法，生成人可以读的版本序列。

然后，在issue中，存在这个生成序列的算法版本号，当然，也要在issue中记下这个版本序列的版本号。

现在，不论是版本阵列的结构发生改变，不是算法发生演进，系统，都有能力将已生成的issue逆向理解，重新生成当前版本的人可以理解的version type.

***当然要注意，issue要指向case，也指向空上版本阵列。即，有一个描述issue的summary，也要有这个issue所在序列。

而不要将二者，都作到issue的标题中去。

================================

这是本文的结论，看起来很细节，但就是如此。人体中最复杂的，可能是就cell本身。我们不去研究cell，至少要知道人体是如何来调节这120万亿个cells的。

同样我们做技术管理，这种世界最难的事（因为你面对的是最聪明的人，高学历的人），在最难的国家，如果你不能在最小料度进行推演，是几乎没有可能成功的。

未来的社会，关系就是关系，你再搞也搞不过人家小舅子。他们能做的，我们就不要去做了。我们能做的，一定是竞争激烈的。