最近读了朱少民老师写的一本看家本领：软件测试中的系统思维，受益匪浅。 系统思维对于软件测试工作至关重要，但由于它是一种非常综合的思维方式，因此学习和掌握难度大，培训周期长。 本文向您介绍一种实用性强、价值高、易于掌握的具体思维（不同于综合思维）的方法——结构化思维。
结构化思维的应用范围非常广泛，可以应用于生活的各个方面。 它还可以帮助软件测试的各种特定任务更有效地进行。 是软件测试工程师、测试经理、测试架构师等软件测试人员必备的思考。 方法之一。
系统思维和分析思维的对比
系统思维强调考虑问题的全面性。 结构化思维可以说是系统思维的一部分，但它主要强调问题的结构清晰性。
分析思维也考虑问题的清晰度，但其重点是线索之间的逻辑因果关系。 结构化思维的重点在于各种线索的有序性，即相应的结构化模型匹配。
测试你的结构化思维能力
问：如何将200毫升的水倒入100毫升的杯子中？
明确这不是一个急转弯，您需要尽可能多地考虑多个解决方案。 （您可以尝试先在这里写下您的答案，然后再阅读）
结构化思维对于我们来说并不陌生。 这并不是一个全新的想法。 每个人都或多或少地掌握了它。 比如我们常用的总分结构，就是最简单的结构化思维方式。 结构化软件开发方法中的自上而下的结构也是结构化思维的典型应用（需要说明的是，结构化开发方法实际上是系统思维的应用，但这里我们只关注结构化思维部分）。 此外，还有一些常用的分析结构，如SWOT、5W2H等，也是结构化思维的应用。
就像神雕三部曲里一样，九阴真经很多人都学过，但是水平却相差甚远。 很多人都知道这些结构化思维方法，但是在解决问题的时候还是不知道如何下手。 下面总结了结构化思维的三个要点，可以帮助大家更有效地应用和提高结构化思维。
第一点：明确核心问题——可衡量的目标
开始结构化思维的前提是一个可衡量的目标。 如果它的目标不明确，就必须先进行转换。 转型的时候，需要深挖问题的核心。 转化方法可以是从不熟悉的问题到熟悉的问题； 从抽象问题到具体问题。
金庸小说《侠客行》中，王八蛋请谢彦客教导石钟玉做个好人。 “教人做好人”在这里并不是一个明确的目标。 为了让心上人尽快获得自由，丁玲采取了目标转化的方法：一一总结身边遇到的好人的特点，然后把这个目标变成一个可衡量的目标，比如孝敬长辈。 、信守承诺、努力工作、诚实守信等，然后明确目标，如果在一定的可验证的时间内没有违反这些原则，则认为目标已经实现。 这样，目标就转化为“一段时间内不犯错误、不失信”等可衡量的目标。
无论您是在着手一项测试任务、个人理想还是家庭愿望，第一步都是将其变成可衡量的目标。
以性能测试为例，“对这个系统做一个性能测试”并不是一个可衡量的目标。 这也是很多没有实践经验的工程师的困惑，所以很多工程师认为性能测试“太深”，或者认为获取最大并发数就是性能测试。 出现这个问题的原因是结构化思维的第一步没有做好。 改造的方法就是尽可能量化性能测试目标，比如最大响应时间、吞吐量预期、最大可能并发估计、最频繁在线人数等。
软件测试问题：我为我的部门（30人）建立了一个审计系统，收集并记录每个人在办公室访问外网的行为，并每周提供分析报告。 请测试该系统的性能。 评估以下场景的价值，设计合理的性能测试场景。
首先运行1w并发测试，看看是否可以暴露一些程序错误。
测试30人并发、连续运行72小时的系统稳定性
测试访问钓鱼网站的后果
当多人同时从外网下载数据时，系统响应时间
第二点：合理分解问题，然后对分解的信息进行分类
无论采用哪种结构化思维方式，目标确定后，需要做的就是对问题进行分解，然后对分解后的信息进行分类。
例如，测试工作中测试时间不足的常见问题，可以通过测试用例的优先级分类来解决：预先将测试用例按照重要性划分为梯队，之后按照优先级从高到低的顺序进行。测试开始。 。 测试不充分的风险可以显着降低。
上述不同的结构化思维，归根结底都是分类角度不同导致结构不同的结果。
SWOT分为优势、劣势、机会、威胁； 5W2H分为何时、何地、何人、为何、做什么、如何做、花多少钱。 不同的分类结构旨在解决不同的问题。 积累更多现成的结构化思维无疑有助于我们更快地掌握多角度分类。
第三点：结构改进与优化
目标和分类完成后，我们就会有一个充满信息的结构，线索也会比以前清晰得多。 但不要就此止步，继续向这个结构添加更多信息，这些信息可以来自互联网、图书馆软件测试方法和技术 第三版 朱少民，甚至是你偶尔听到的信息。
前段时间，有人批评现代人的学习过于碎片化。 他们厌恶从公众号上读几篇关于测试的技术文章，就好像他们已经学会了如何测试一样。 他们认为学习的时候还是需要脚踏实地的看书、实践，才能系统的贯彻执行。 学习。
我的观点是，知识从哪里来并不重要，但知识结构一定要清晰：学到了什么，还欠缺什么； 工作也是如此。 很多测试人员都是从功能测试进入这个行业的。 虽然都是点点滴滴，但是工作质量却得到了提高。 这是非常不同的。 学习了结构化思维之后，你需要知道每个点的行为属于你的结构的哪一部分。 任何时候，你都可以清楚地知道该往哪里投入更多。
基于质量管理体系持续改进的思路，结构的改进和优化也需要持续进行。
现在解决上面的问题，首先分析一下问题的核心：正常情况下200ml的液位不能倒入100ml的杯子中是什么原因？ 因为水会流出来。 为什么水会流出来？分类：主要有3个原因
罩杯原因：罩杯太小、罩杯不够等。
水的原因：水太多、水是液体会流动等。
外部原因：重力等。
一一解决并总结
杯子的话，换个容器，拿2个杯子，先把水放进气球里，再放进杯子里……
水的话，喝一半然后冻成冰块……
由于外部原因，去外太空操作……
篇幅有限，仅仅阅读这一部分不足以学习结构化思维。 要想成为自己的，就必须按照以上三个要点坚持训练。 用不了多久，你就会发现工作变得越来越容易——自古深情留不住，套路总是得人心——因为有条理的思维，没有疏忽、遗漏，思路清晰，负担减轻。大脑被照亮； 因为结构化思维，你可以快速得到结果解决方案，让软件测试工作变得轻松高效……
这是本文的后半部分：
越来越多的人认同这样一个观点：人与人之间最大的区别在于思维方式。
很多年前，我第一次负责制定一个大型项目的性能测试计划。 虽然之前我负责并执行过几个性能测试项目，并且完成得非常好，而且手头的各种相关资料也可以说是齐全，但是还是花了很长的时间。 忙了两天通宵，还是没有任何头绪。 这个工程太复杂了！ 不得已，当我快要下班的时候，我去向我的主管（也是我的老板）请教。
他二话不说，拿出一张A4纸，问我：“这个计划的目标是什么？”
他在纸的中央画了一个方框，在里面写了“性能要求”几个字，并向我解释道：“就是性能要求。具体来说，他们的性能要求是什么？”
“并发性、响应速度、资源利用率、性能调优[1]。” 我很肯定地说。
“很好。那你现在有什么问题吗？” 他一边继续询问，一边在性能要求下画出了这四项。
“我整理了131种交易类型，我不知道从哪里开始。” 看着他画的框图，虽然在我毫无头绪的思考中似乎有了一丝希望，但我还是没有抓住重点，问题仍然很大。 棘手。 我特意强调了131这个数字，是想提醒他，我已经很努力了，不是问问题来占用他宝贵的时间。
“和以前一样，当你不知道从哪里开始的时候，就不断地设定目标，越具体越好，直到你知道自己想做什么。” 他似乎没有注意到我的小心。
（后来当了别人的老板，我才发现，我的直属下属总是会看他们是否努力，而我当年的心机根本就是多余的。）
“我的目标是了解这131个事务的性能。即每个事务的并发支持情况，每个事务的响应速度，除了它们的单一事务场景[2]，它们的混合事务场景[3]我们还需要获得并发支持、响应时间、资源利用率，并结合设备优化[4]，这是一个在测试场景中呈现指数增长的解决方案[5]“我的头瞬间变大了——我。 我想我已经听得够具体了，但无济于事的是，声音不自觉地提高了。
“你是对的，最终目标确实是获得全交易的性能[6]，但这不是一个可执行的目标，而且你的理解并不具体，你是全面的。遇到与现实差距较大的目标时，真正要做的具体工作，是把不量化的变成量化的，把模糊的变成清晰的，把模糊的变成说明的，用这些手段把它变成容易实现的东西。” 他缓缓说道。 说，“这是您的 131 笔完整交易。继续对其进行排序并分离复杂的交易，直到您最终获得典型交易的性能 [7]。”
“我知道典型的交易意味着什么，但这131笔交易融合了不同的设备终端和不同的业务类型，没有办法对其进行细分和分类。”
“从来没有过这样的事情，以后不要说这样的话，也不要有这样的想法。” 他一边纠正我，一边用Paint打开了被测系统的子模块图，并在上面画了几条彩色的线条。 线（我理解这是主要过程），然后画了几条短红线。 他用鼠标点了点红线，“你们的131笔交易现在还能继续划分分类吗？”
我恍然大悟：“啊，挡板[8]！我知道了。有了这些挡板，就可以将交易分层划分，让这些交易流在每一层独立地有很多重复。而通过这种黑箱，你只需要关心两端（输入和输出）的数据符合预期，不必过多关注业务。“一想到业务细节熬夜加班，我的心情很复杂。
“我没想到挡板的事，结果就卡在这里了。”
（现在看来，我是被上级的实力压碎了，但由于我的思维水平有限，我觉得自己只是没想到，所以我不自觉地顶嘴，为自己辩解。）
他根本不关心我的态度：“层次分类方法只是分类的一种，你还可以使用其他的分类方法。不同的分类方法使用得越多，目标就会越来越具体，目标也会越来越具体。”答案将显而易见。”
说到这里，我终于把注意力从问题本身转向了老板提供的想法。 我终于注意到他的关键词：目标、具体、分类。
还有哪些分类方法？ 我脑子飞转，“还可以根据约束来分类，比如峰值要求[9]。相同峰值要求的交易归为一类，测试场景可以复用；还有软件、硬件等约束条件、网络等” 分类。 还可以根据重要性（引起资金变动的交易更重要）、使用频率（如取款>存款>开户>关户）、时间（交易集中时间：如银行营业时间、各种开户、关户等。柜台业务密集；午餐时间取款业务密集）……”思维方式一转变，我发现思路开阔了，问题也清晰了。我说：“我之前做的131笔交易的提取工作是按照路径分类的。 这也是一种分类。 “终于挽回了一些面子。
他赞同地点点头，对我表示肯定：“是的，这种分类方法在这里是非常关键和必要的。但是，除了这些之外，在制定计划时，尤其是像这样集群式的大型项目性能测试计划时，分类方法是必要的。”必不可少。”
他露出了一种我不太能理解的表情。 他看起来很神秘？ 是的，这就是神秘的表情。 “就是对人进行分类，以人为本。有意识地考虑业务复杂性（对于银行专家）、编程技术难度（界面开发人员）、数据库难度（DB专家）、设备支持难度（网络/配置管理员）等。通过对测试工作进行分类，在执行过程中可以指派专业的人去做专业的任务。”
我试着回忆一下我见过的计划——没有一个计划如此分裂。 他们都专注于被测系统本身。 理论上来说，人员应该是随叫随到的（当然，现实很骨感，测试进度往往都卡在所谓的相关人员身上）。 ）。 他注意到我脸上的困惑，然后解释道：“是的，这一点一般不会在纸上说明，而且很多性能测试设计者自己都忽略了这一点，但你要知道，专业性是体现在细节和性能上的。”风险防范。”
我想起扁鹊三兄弟的故事[10]。 大哥能在病人生病之前治愈他。 他是注重细节和防范风险的高手吧？ 但他是最不出名的。 我老板的计划比我自己的更无聊（当时我被认为是高级性能测试工程师，而不是新手）。 它一定显着减少了执行期间的工人数量/天数。 客户能接受吗？ 是否会影响项目收益？
（如果你太注重得失，而不能全心全意地解决问题，你还谈什么专业？）
他没有注意到我分心，继续问我：“好吧，你的需求目标很明确，你的策略是什么？”
我又被这个问题搞糊涂了。 他指着纸上的框图提醒我：“虽然这四个都是性能要求，但其核心是并发。” 他标记了并发，然后继续问我：“你要做的就是具体的，想一下如何验证并发？”
我很快顺着他的思路：“首先判断系统在负载并发方面是否满足业务性能要求（或设计要求）。然后，如果条件允许，施加负载压力，以获得系统的最大并发量。通过负载压力测试以实现该测试目标。”
“太好了。反应速度怎么样？”
“判断不同负载条件下系统响应速度是否满足业务性能要求。首先完成基准测试，即单个用户/事务应用的系统响应速度测试。然后获得不同负载级别下的加权系统响应速度。” ”
“嗯，很清楚了，你肯定在资源利用和设备优化（性能调优）方面做了一些工作吧？” 见我点头，他继续问道：“我们也有测试策略，所以是时候测试一下模型了，你来说说吧。”
我也拿了一张A4纸，按照他的例子，在中间写下了测试模型，然后按照他的想法在心里问自己，目标明确吗？ 如何分类？ 哪种分类更合理？ 答案是什么？ 很快我就在纸上完成了这幅画。
他很满意，笑着问我：“你还有什么问题吗？”
测试计划已经准备好了，剩下的就是完成测试环境准备、工具准备、前提条件、数据准备等相关内容。 即使我仍然遇到一些问题，但我显然已经掌握了老板的结构化思维。 ，问题总是能很快解决。 我有信心今晚加班两个小时就能完成这个计划！
虽然心里充满了感激，但还是说不出“没问题”这三个字。 我终于忍不住问了之前关于“扁鹊哥”不被顾客接受，可能影响他收入的问题。
他哈哈大笑，“不被客户接受？那客户为什么要高薪聘请我们？客户很清楚软件测试方法和技术 第三版 朱少民，雇用不专业的人是浪费时间和金钱。你知道我们的性能测试项目是飞比XX公司（一家油井公司）。” ——业内知名的检测公司）外包公司要多少钱？十个比我们两个人一周赚的钱多！让我们学学如何变得专业吧！
——这么多年过去了，那自信的笑声似乎依然在我耳边响起。 那时，我的老板刚刚结婚，刚刚开始自己的事业。 那是他为自己的马蹄病感到非常自豪的时候——我从他那里学到了所有新东西。 思维方式不断刷新我的格局。
特别感谢李中秋老师的《结构化思维》（京东有售），解答了我很多关于结构化思维的困惑。 此外，Barbara Minto 的《金字塔原理》一书介绍了结构化思维的许多关键技术。 我向大家推荐这两本书。
由于水平有限，难免有疏漏之处，还请不吝赐教。
词汇表
[1]性能调优，[4]设备优化：程序调优、数据库调优、中间件调优、设备优化等都属于性能调优的范畴。 性能调优最常见的应用是程序调优。 ，即通过性能测试发现程序中潜在的风险，并指导开发人员修复； 这里的性能调优工作主要是设备优化，即采用不同配置的设备来获得更好的系统性能。
[2]单事务场景、[3]混合事务场景、[5]测试场景：性能测试中的测试场景是指使用脚本程序来模拟用户行为； 单笔交易场景是指所有模拟用户都进行相同的操作，比如所有人都在提币； 混合交易场景模拟用户按比例进行不同的操作，例如有人提款，有人存款，有人开户等。
[6]全量交易，[7]典型交易：这里的全量交易是指系统中产生数据交换的所有用户行为或模拟用户行为； 这里的典型交易是指可以代表整个交易的单个交易或单个交易的一部分。
[8] 挡板：由于硬件资源、多系统协调等客观因素的限制，在无法搭建完整的测试环境时，采用一些程序来模拟部分测试环境。 这时，被模拟程序隔离的原始现实将不再被关注。 测试环境。 用于模拟测试环境的程序称为挡板。
[9]峰值需求：指银行最大并发交易数的需求指标。
[10]扁鹊三兄弟的故事：请百度《扁鹊三兄弟的故事》。
