测试需要思考者吗？(二)

#bo\Z&i.PG8D0

我们再从宏观层面来分析大型机构更需要思考系统型的测试领导者。你见过哪个公司的CEO每天在写代码，在研究研发工具的使用吗？即使这个CEO是从程序员发展过来的，虽然写程序很重要，这位CEO是团队中写代码最牛的人，但是从整个公司的角度出发，他还有更多更重要的事需要他去选择，判断，布局，舍弃，创新。毕竟他的时间是有限的，当他什么都思考的很清楚时，他也可以写代码。只是他要对大团队负责，这时组织上不缺一个神枪手，更需要一个领导者，一个带领大家用最短路径达到目的地的导师。而这位导师一定是思考型的员工，他不但要找到正确的事来做，还要规划好运作思路。也许有网友会说，规划工作很空，是虚的。不就是写一个计划，第一步做什么，第二步做什么，谁都可以做。

 那我再分享一个产品线可靠性测试规划的案例吧：某产品线有A,B,C,D,E 5个产品。最后上线时，是5个产品一起组合才能达到业务目标。在我没有指导前，5个产品组的人都是各自为战，在自己产品组做异常测试，故障模拟。我来后，首先就是广泛调研，然后得出2个主要困难：1、几乎所有人都对可靠性测试理解很少；2、要进行故障模拟，实现难度大，而且也担心故障模拟类型不够。然后：分析出5个产品未来工作时之间的依赖关系图，从而得出5个产品的可靠性依赖关系图。发现A产品和B产品是所有产品依赖关键的最低层，因此在今年不到3个月的时间内，重点工作就应该聚焦到A和B产品的可靠性测试场景的收集系统化上。我们知道了A和B会常出现哪些故障，C,D,E的故障模拟测试就不会出现大的遗漏。同时，还可以给A和B的研发人员提可测试性需求，让未来C,D,E的测试人员不用再苦恼如何触发A和B的故障，直接使用A和B的故障模拟功能，就可很轻松地实现可靠性测试，大大节约后期测试的时间，测试设备的需求。现在已确定了今年正确的工作重点，也指明了A,B,C,D,E 5个产品在可靠性测试工作上的协作关系。51Testing软件测试网^1IM#x%Y6`

最后，就是要帮助A产品的测试人员细化故障场景的架构。假设是一款分布式文件系统的自研产品，在我未出现前，故障场景就只有几个：网线掉了，服务器停电了，硬盘坏了，还有一些平时发现的bug场景。谈不上全面，肯定有许多可靠性方向上的遗漏。我给他这样的指导：首先，你需要把故障场景分为基础2类：分布式系统的常见故障（而不仅是分布式文件系统）、文件系统的常见故障；其次，再加第3类故障——分布式与文件系统组合时可能会出现的故障，这时还需要对3大类故障场景中的故障进行细化的2级分类。最后，需要对故障描述的粒度质量进行要求，要确保测试人员可以直接使用故障描述的文字写出测试用例。并且要对所有故障场景使用RBT（基于风险的测试）方法，筛选出风险值最高的可靠性测试场景，这样后续可靠性测试工作就有了进行决策的依据了，确保最重要的故障场景优先得到充分的验证。51Testing软件测试网-Y$UO6x*RK6{8jvq5~W

一个产品线的可靠性测试工作从简单的产品组各自为战，故障场景收集简单随意——>到现在产品组之间互相配合，故障场景收集系统，细化——>到整个产品线一年的可靠性测试工作重点有理有据（不是拍脑袋）准确确定，足够指导后续的工作高效开展。

 因此，从宏观面来看，至少对于大型测试机构必须需要有一定比例的能系统性思考型的员工，并将他们放在合适的位置，即使他的编程能力没有操作型员工强。对于公司整体而言，整个测试组织的工作效率会整合地更高效。各位测试经理在招募员工时，要开始考虑招募思考型员工了，而不只是找编程高手。如何识别这样的员工，就应该是测试经理们的基本素质了。51Testing软件测试网
TH Aq:[

 无论是复合型测试架构师，还是专项测试架构师同样也需要首先是一位思考者，才能真正带领公司级资源进行正确高效的规划，指明正确的选择。我建议：认为技术规划很简单，任何人都能做，技术规划没有用，是空，虚，泛的人，应该更开放些。之所以你有这样的观点，我也理解，那是因为你没有看到真正系统化，指导工作执行落地的技术规划。处于职业道德，我不会共享完整的技术规划PPT，但我尽量在blog文字中插入一些技术规划的思路，希望大家能从中吸收有用的信息。