软件测试的结构化思维（下）

阅读说明：结构化思维要点使用蓝色加粗字体，可结合上篇（ 软件测试的结构化思维（上））进行深入理解；与思维方式相关的使用了斜体。

越来越多的人认同一个观点，即人与人最大的区别是思维方式（way of thinking）不同。

多年以前，我第一次负责制定一个大型项目的性能测试方案，尽管之前我负责并执行过几个性能测试项目也完成得很好，手头的各种相关资料也可以说很完备，但花了足足两天通宵达旦的时间还是毫无头绪，这个项目实在是太复杂了！不得已在快下班的时候，我去向上司（也是我的老板）请教。

他二话没说，拿出来一张A4纸，问我：“这个方案的目标是什么？”

他在纸的中心画了一个方框，在其中写下了“性能需求”四个字，并给我解释：“也就是性能需求。再具体点，他们的性能需求是什么？”

“并发能力、响应速度、资源利用率、性能调优[1]。”我很肯定地说。

“不错。那么现在你的问题是什么？”他一边接着提问一边把这四项画在性能需求的下面。

“我梳理出来了131个交易类型，不知道从哪里下手。”看着他画的框图，虽然我毫无头绪的思路中仿佛有那么一星半点的曙光，但我依然没抓到要点，问题仍然很棘手。我特意强调了一下数量131，想提醒他我也是下了功夫的，可不是随便拿问题来占用他的宝贵时间。

“跟刚才一样。不知道从哪里下手的时候，就继续确定目标，越具体越好，直到你知道要做什么。”他好像并没注意到我的小心机。

（后来当我也成了某些人的上司以后，才明白直属手下是否努力是会时时看在眼里的，当年的心机简直画蛇添足。）

“我的目标就是获知这131个交易的性能表现。也就是每一个交易的并发支持，每一个交易的响应速度，除了它们的单交易场景[2]之外，它们的混合交易场景[3]也要获得并发支持、响应时间、资源利用率，结合设备优配[4]，这是一个测试场景[5]呈现级数增长的方案啊。”我的头瞬间变得更大了——我想我理解得足够具体了吧，这于事无补啊，声音也无意识地拔高。

“你说的没错，最终目标确实是获得全交易[6]的性能表现，但这并不是一个可执行的目标，而且你的理解也不是具体化，你是全面化了。遇到与现实差距大的目标，要做的真正的具体化工作是非量化的转为量化、模糊的清晰化、有歧义的转变为可例证的，通过这些手段把它转化成容易执行的。”他缓缓地说，“这里你的全交易131个，继续梳理它、把复杂的交易分离出来，直到最终获得典型交易[7]的性能表现。”

“我知道典型交易的意思，但这131个交易是整合了不同的设备终端、不同业务类型，并没有办法再进行分割和分类了啊。”

“从来没有没办法这种事，以后不要说这种话，也不要有这种想法。”他一边纠正我，一边用画图打开了被测系统的一个子模块图，在上面画了几条彩色的线（我看明白了这是主流程），然后又画了几条红色短线，他用鼠标敲着那几条红线，“你的131个交易现在可以继续分割和分类了吗？”

我恍然大悟：“啊，挡板[8]！我知道了。有了这些挡板，就可以将交易按层分割，这样这些交易流独立在每一层上就有许多重复了。而且通过这样的黑盒化，只需要关心两头的数据（输入和输出）符合预期即可，根本不必过分关注业务了。”想到自己在业务细节上熬夜加班，一时五味杂陈。

“我一下子没想到挡板，就卡在这里了。”

（现在看来当年明明是被上司的实力碾压成了碎渣，但是由于思维水平所限，觉得不过是没想到而已。所以不自觉地顶嘴、不自觉地为自己争辩。）

他完全不在意我的态度：“分层的分类方法只是分类的一种而已。你还可以用其它的方法分类呀。多使用不同的分类方法，目标越来越具体，答案也就会呼之欲出。”

话说到这里，我才终于把注意力从问题本身，转到了上司提供的思路上面。也终于注意到了他的关键词：目标、具体化、分类。

还有什么分类方法呢？我的脑子飞速运转了起来，“还可以按照约束条件分类，比如峰值要求[9]，同样峰值要求的交易归于一类，可以复用测试场景；还有软硬件条件、网络等约束条件也可以分类。还可以按照重要性（引起资金变动的交易更重要）、按照使用频率（如取款>存款>开户>销户）、按照时间（交易集中时间：如银行开门时间各种开户、销户等柜台业务密集；午餐时间取款业务密集）……”思维方式一旦变化，我发觉自己思路打开了，问题也清晰了，最后我说：“我之前做的131个交易的提取工作是依照路径分类，也是分类的一种。”总算挽回一点面子。

他赞许地点点头肯定了我：“不错，这个分类方式在这里很关键也很必要。不过，除了这些，在做方案尤其是像这样集群式的大项目性能测试方案时，有一种分类方法是必不可少的。”

他露出了一种我看不太懂的表情，好像是神秘？对，就是神秘的表情。“那就是按照人员分类，以人为本。有意识地考虑到业务复杂度（针对银行业务专家）、编程技术难度（开发接口人）、数据库难度（DB专家）、设备支持难度（网络/配置管理员）等将测试工作进行分类，执行的时候就能集中安排专业的人去做专业的事。”

我努力回想我见过的方案里——没有这么分的，都是关注被测系统本身，人员理论上都应该是随叫随到的（当然现实很骨感，测试进度经常卡在所谓相关人员）。他注意到我面露疑惑，接着解释：“是的，这一般不会在纸面上说明，并且很多性能测试设计人员本身也忽略了这一点，但你要知道，专业就体现在细节、体现在更早的风险预防上。”

我想到了扁鹊三兄弟的故事[10]，大哥能在病人还没有感觉自己生病的时候就治好病，是注重细节、风险预防的高手了吧？可是他却最没有名气。上司的方案比我自己闷出来的（当时我也算一个高级性能测试工程师，可不是小白）执行时候肯定大幅减少了工作人/日，客户能接受吗？会不会影响项目的收入？

（得失心太重，不能全心地关注解决方案，又怎么做到专业呢？）

他没注意到我走神了，继续提问我：“好了，你的需求目标明确了，你的策略呢？”

我又被一下子问懵了。他指着纸上的框图提示我：“这四条虽然都是性能需求，但其中最核心的是并发能力。”他在并发能力上打了个记号，继续问我：“你要做的还是把它具体化，想一下怎样验证并发能力？”

我赶紧跟上他的思路：“首先确定系统是否在负载并发能力上达到了业务性能需求（或设计要求）。然后，在条件允许的情况下，负载加压获得系统最大并发能力。通过负载压力测试实现该测试目标。”

“很好。那么关于响应速度呢？”

“确定不同负载条件下，系统响应速度是否达到业务性能需求。首先完成基准测试，即单用户/交易申请的系统响应速度测试。然后在不同负载级别上获得加权的系统响应速度。”

“嗯，很清楚，想必资源利用率和设备优配（性能调优）你也做过工作了？”见我点头，他继续问，“测试策略也有了，那么该轮到测试模型了，你来说说看吧。”

我也拿了一张A4纸，学着他的样子，写下测试模型在中间，然后按照他的思路在心里问自己，目标明确了吗？怎么分类？哪些分类更合理？答案是什么？很快我在纸上完成了这个图。

他很满意，笑眯眯地问我，“你还有什么问题吗？”

测试方案已经呼之欲出了，剩下的无非就是把测试环境准备、工具准备、前提条件、数据准备等相关内容补充完整，哪怕还会遇到一些问题，但我显然已经掌握了上司的结构化思维方式，问题总能快速解决。我有信心今晚加班两个小时就可以搞定这个方案！

虽然满心感激，但没问题三个字我还是没能说出口。我终于还是忍不住问出了前面那个关于“扁鹊大哥”不被客户接受、可能影响收入的问题。

他哈哈大笑，“不被客户接受？那客户为什么高薪聘请我们？客户很清楚请来不专业的人就是浪费时间和金钱，你知道我们的性能测试项目费比XX公司（业内有名气的测试外包大公司）贵多少倍吗？他们十个人干一个月也没我们两个人干一个星期赚得多！好好学学怎么做到专业吧。”

——这么多年过去了，那自信的笑声仿佛还在耳边，那时我上司刚刚新婚，也刚刚出来自己创业，正是春风得意马蹄疾——而我，跟他学到的一个个崭新的思维方式，不停地刷新了我的格局。

名词解释

[1]性能调优、[4]设备优配：程序调优、数据库调优、中间件调优、设备优配等都是性能调优的范畴，性能调优的最常见应用是程序调优，即通过性能测试发现程序中的潜在风险并指导开发人员修复；本文这里的性能调优工作主要是设备优配，即利用设备的不同配置来获得更好的系统性能表现。

[2]单交易场景、[3]混合交易场景、[5]测试场景：性能测试中的测试场景指的是使用脚本程序模拟用户行为；单交易场景即所有模拟用户执行相同的操作，比如所有人都在进行取款操作；混合交易场景即模拟用户按比例执行不同的操作，比如一部分人在取款，一部分人在存款，一部分人在开户等。

[6]全交易、[7]典型交易：这里的全交易是指系统中所有产生数据交换的用户行为或模拟用户行为；这里的典型交易指可以代表全交易的单交易或单交易的一部分。

[8]挡板：由于硬件资源、多系统协调等客观条件因素限制，无法搭建完整测试环境的情况下，采用某些程序模拟部分测试环境，此时将不再关注被模拟程序隔离的原真实测试环境。用来进行测试环境模拟的程序即被称作挡板。

[9]峰值要求：这里指的银行交易最大并发数量的需求指标。

[10]扁鹊三兄弟的故事：请百度“扁鹊三兄弟的故事”。