这才是史上最全的“软件测试”思维导图!

这才是史上最全的“软件测试”思维导图！

从当初偶然的机会进入测试领域，到现在已经多年了，在这些年做过测试执行、测试技术研究、测试工具等测试相关的工作。最近在工作上有些迷茫，不知道后面的职业道路怎么走，感觉很多测试技能，经验都没得到很好的总结和思考。之前接触过思维导图，但是一直没有发现其价值所在，最近又重新关注，发现思维导图真是个好东东，对测试工作有很大的帮助，所以特总结一下，分享给大家。

一、测试是否需要建模

通常一谈到建模，大家普遍都认为开发才需要，对测试来说，最多可能是在测试设计阶段才需要建模。对于测试模型，一般都谈的比较少，因为很多人都认为测试要求不高，不需要什么模型，也没有什么模型。那么我们分析一下测试的特点以及建模的价值。在工作中，对测试人员的要求，知识面越广越好。和开发人员进行比较，开发人员是纵向发展，测试人员是横向发展。测试的特点要求知识面广，在做测试的过程中要考虑的很全面，那么一方面有多的输入，另一个方面我们要防止测试遗漏，有很高的要求，我们怎么做呢？我们如何防止测

试遗漏？那么就需要建模。因此这个也就是测试建模的价值所在，并不在乎你的模型是复杂还是简单，达到你想要的效果即可。那么测试建模有什么特点呢？我认为有如下两个特点：一是简单，二是有效。因此我强烈推荐大家在工作中用起来，花几分钟时间就能取得很好的效果，这样的事情太有价值了。

二、测试如何建模

我虽然是学计算机出生，但是在学校中并没有涉及到测试，进入测试领域也属偶然，在工作中并没有参与过系统的测试基础培训，也没有完整的学习过。因此在工作这么多年后，发现自己要想提升，基础知识必不可少。

先谈几种生活中的场景：

场景一：我家有一个3岁多的宝宝，暑假报名去学习跳舞，整整一个暑假，老师只教压腿、弯腰等基本功；

场景二：我最近在学习吉他，报了一个培训班，吉他老师只让天天练习右手拨弦，左手按品位，打个比喻，就要像程序员按键盘那样灵活。

场景三：很多知名的大学教授，特别是国外的一些学校，总是在给本科生代课，以前我也不理解，感觉这些是很大的浪费。大家都知道本科生学习的很多东西都是基础知识，要想解决深层次的问题必须要有牢固的基本功。

有了基本功，那么如何提升自己呢？这时我翻阅的一些杂七杂八的书籍有了一些提醒，比如经济学，经济学的发展就是不断的总结理论，推翻理论的过程。因此我认识到要想提升自己，必须也有一套方法或者模型。再者，经过这么多年的人生经历，我感悟到世上万事万物一定有些内在的东西是相通的，类似的，就像前面提到的三种场景一样，整理出来的模型一定应该是通用的。

先从最简单的IPO模型谈起吧，下面是一个IPO模型

这个模型很简单，但是也很实际。作为一个职场人士，在工作中总要有自己的加工和输出，否则就毫无价值，只能失业了。下面的模型就是在IPO模型基础上扩展得到的，我们做测试建模就是结合测试特有的东东对下图进行细化：

●基本功：是指最基础，可以在不同环境中都可以使用的技能或知识，比如编程语言，数据库，操作系统等计算机方面的知识，测试理念、黑白盒测试的基本方法等。

●上下文：解决问题或者达到目标的环境，比如当前的项目，产品等。理解或者梳理上下文尤其重要，但是在实际测试中却通常被忽略。比如如何对一只铅笔进行测试？这个问题怎么回答，回答之前一定要考虑上下文。

●经验：测试人员通过工作和生活的总结积累，因人而异。

●方法：这里的方法重点指利用思维导图来建模解决问题的方法(关于思维导图和XMind 工具，请读者自行上网搜索)

●目标：需要解决的问题

我认为测试建模的过程就是使用上面这个模型的应用，其中不变的是基本功，建议大家花时间打牢基本功，无论在哪个公司做测试都用得上。上下文是最容易忽略的，通常大家会根据第一反应去回答、解决问题，建议利用思维导图的方式将上下文分析全面了，很多时候全面

了解了上下文解决问题的方法自然就出来了。

三、为什么要选择思维导图呢？

思维导图是一种将放射性思考具体化的方法，它简单却又极其有效，是一种革命性的思维工具。大家可以在网络上找到关于思维导图的相关资料以及范例。前文描述过测试工作的特点，因此我觉得对测试来说思维导图是最合适不过的工具。

四、最全软件测试思维导图

这是一副完整的思维导图，重点是左边的方法（methogology）及其应用，然后介绍了测试原则、测试流程、测试工具、测试活动等。还有一些内容，是间接和测试相关的，如学习资源（如网站、杂志、图书、培训等）、社会（如博客、社区、竞赛、调查等）、计算机技术（如web、嵌入式软件、桌面、数据库、搜索引擎等），其中目前流行的Mobile技术是放在嵌入式软件中。

左边的方法, 首先分为动态、静态的方法，大家熟悉的黑盒方法、白盒方法基本归入动态方

法中，这种划分不一定科学，但符合多数测试人的习惯，而且也没有完全隔离它们，它们之间还是通过线联系在一起。运维相关的测试、性能测试、安全性测试，虽然归入白盒方法，但从黑盒方法有一根线连到这里，说明不是纯白盒方法，可以理解为灰盒方法。里面也有一些新的东西，如Happy-Path Teating, 在Wikipedia中被定义为"a well-defined test case using known input, which executes without exception and produces an expected output"

静态测试方法，主要是走查、代码评审等，文档测试不能算方法，只是测试类型。在测试层次中，丢掉了验收测试（业务层）, 而单元测试的方法分支测试／条件覆盖、基本路径测试等，连到白盒测试。各种类型的测试还比较全，但把Code coverage放在这里不合适。

测试实践中内容丰富，包括敏捷测试、TDD／BDD（少了ATDD）、探索式测试、结对测试、数据／上下文／代码驱动测试等。组合测试更应该在测试方法或测试类型中，不应该在这里。输入／输出数据，缺少真正的实践，只是列出一些UI元素等，价值没能体现出来。

测试原则，侧重基于风险饿测试，到Oracle（测试启发式准则），思路也有些怪，大家可

以慢慢体会，时间关系，就不展开讨论；

工具，一方面从Bug跟踪开始到测试管理，再到Drivers／Stubs（真实醉了）；另方面从Forensics（取证）开始，到版本控制、部署工具，再到性能测试、安全性测试、自动化测试等工具，这种思路也是奇特。

流程中，标准大类倒是全了，和测试相关的计划、策略、测试用例、缺陷、报告都提到，还涉及开发流程、交付流程。支持活动，涉及更广，如项目计划、配置管理、质量管理、变更管理、风险管理等。

从中让我们体会到，知道（软件测试）得越多，越有一种（对软件测试）敬畏感。