| 编辑推荐: |
本文主要介绍了为什么要测试建模？什么是测试建模!及怎样展开测试建模。
本文来自于简书，由火龙果软件Linda编辑推荐。 |
|
导语
加入测试建模小组八个多月的时间，在日常的测试工作中，经常会有身边的小伙伴们对我们的建模很好奇，会问“什么是测试建模？”“为什么要测试建模？”“建模能给我们带来什么好处？”“建模和我们现在的测试设计区别到底在哪里？“等等诸如此类的问题。思来想去，实在有必要跟大家分享下自己对测试建模的一些想法，如有不正确的地方，欢迎指正。
一、为什么要测试建模？
抽象是认知事物的一种关键途径，是人类智慧的体现。比如，在立体几何中，三维坐标用于抽象世界空间（X+Y+Z）；在地理学中，地图用于抽象生存空间（交通路线+标志性建筑+其它）；在生活中，身份证用于个人身份抽象（身份证号+照片）；在软件工程中，类/结构体用于目标的抽象等。可以说，抽象是为了用少量的特征或属性来给对象打标签，这些标签要具体、可度量，且识别性强等。抽象这个词大家都不陌生，那么建模是什么呢？我认为，建模是对目标进行的系统的、结构化的、多层次的和多视角的抽象。我们知道，软件测试是一个复杂冗长的工作。我们是否能够通过对待测试目标进行抽象和建模来指导我们的测试工作呢？下面我将从测试建模的必然性以及它的重要性两个方面来阐述我们为什么要测试建模。
1.1测试建模的必然性
当前的软件测试它包括哪些方法呢？我觉得下面这张图承载的内容非常的立体丰富，基本涵盖了软件测试的主要方法。软件测试，它是一个系统工程。可以从单元测试到系统测试；可以从压力测试到功能测试；从黑盒测试到白盒测试等。随着软件容量的扩增和软件需求的变更，常用测试方法需要重新设计和增加测试用例，而一些特定用处的测试用例会变得越来越不重要，尤其是复杂系统的潜在问题会更加隐蔽，导致常用方法更加捉襟见肘了。 
系统的规模越来越大，测试工作越来越复杂，工作量越来越繁重，如何减少测试过程的盲目性，提高测试过程的效率，基于模型的测试（Model-based
testing, MBT），MBT应运而生。它具有科学性、系统性和指导性，为我们的思考、实践和测试工作指明了方向。
对于有测试工作经验的人而言，它能激发你的头脑风暴，锻炼你的思维方式，让你高屋建瓴，有理有据；对于初次接触测试的人而言，它能诱导你特异才华的展现，用一种不一样的视角来看待软件建模，给老司机们带来惊喜。可以说，测试建模能够挖掘出团队和个人的潜能，让大家能够多层次、多视角来认识和量化待测试目标，从而更加系统科学地指导软件测试工作。
1.2测试建模的重要性
通过对系统的行为（Behavior）进行抽象和建模，MBT能够处理好常用方法的困难之处。一项调研统计发现，MBT能够额外检测出59%的Bugs，降低17%的测试费用并缩短25%的测试时间。它已经成为测试管理的一个重要参考依据。实际上，在设计测试用例之前，我们的头脑中已经有一些需要面对的测试场景以及一些大致的测试思路，也可能有功能清单或某种图表，或者会有谁是用户、用户关心什么等一些初步概念。然而更重要的是，我们如何将这些测试思路或内容形成条理清晰、系统全面、分工明确的软件测试文档和用例，以供测试评审和执行、Bug分析和修复等。此外，软件测试涉及到的人，他们职能不同，视野高度不同，关注度不同，比如产品经理、开发人员、测试人员和终端用户等等，因此，它需要涉及产品各个维度的质量验证。
MBT体现了团队和个人的专业素养、思维角度以及思考深度，能够增强我们的推理能力，同时识别潜在的风险。它正成为测试工程师的基本技能要求。需要指出的是，MBT是为了更好的进行软件测试，而不是为了撰写尽量多的测试用例。下面，从主观（人的角度）和客观（产品的角度）角度来说明MBT的重要性。
1.2.1 --主观角度
测试建模有利于个人认识被测对象
MBT有利于个人更系统全面地认识被测系统。针对被测系统，我们一般需要明确“5W”规则的内容：测试目的（Why），测试范围和内容（What），测试时间范围（When），测试方法和工具（What）以及测试文档和软件的存放位置（Where）。在MBT情况下，Why体现在被测系统的抽象建模和初步验证模型阶段，What体现在可控地生成测试用例阶段。如果对测试目的有疑问，需要及时沟通以校正个人或补充团队对测试对象的认识；如果对测试方法和工具有疑问，那么自我学习和技术交流就变得比较重要。对被测系统的深入认识，是个人合理有效执行测试用例的前提，也是团队内和团队间进行高效沟通的第一步。
测试建模有利于团队合作和问题解决
针对同一被测系统，团队内的我们由于能力和经验的差异可能出现认识水平上的不一致。这种不一致可能体现在内部组会讨论、测试任务分配以及上下级沟通等方面。然而，对被测系统进行多维度建模后，大家可以在指定的维度上进行有效沟通和讨论。
团队间的有效沟通在测试工作中非常重要，通常也非常困难。比如在软件开发过程中，Bug的出现就将软件测试接口人员与对应的开发人员联系在一起。基于MBT来梳理被测系统的内部逻辑和数据流情况，高效的跨角色、跨团队和跨时间交流变得可能。
以上两点也要求被测系统相关人员能够在关注本职工作之余，关注整体项目进展，从而了解本阶段的重点关注内容，提前作好准备工作，使得自己在遇到问题时候能够从容应对和团队合作。
1.2.2--客观角度
测试建模有利于系统高效的软件测试
MBT是被测系统的抽象模型，它可以根据需要和项目进展而动态更新，而测试用例则可以根据实际需要自动生成（如U2TP,
UML 2 Test Profile）。这就意味着，我们可以借助专业工具来设计和自动生成测试用例，而我们的工作重心可以放在（1）被测系统的多视角建模；（2）MBT模型质量；（3）MBT模型更新；（4）自动化测试；（5）风险评估；以及（6）个人能力提升。这样，我们测试人员就可以变被动为主动，来关注项目进展和对应技能提升。
测试建模有利于客观合理地度量测试进度
常用的软件测试度量方法包括缺陷度量、测试用例深度、测试执行效率和测试覆盖度等。这些度量方法能够检测到的缺陷是随着时间的推进才能逐步发现的，而检测到的bug可能是冰山一角。相对地，在建立被测系统模型后，MBT能够通过代码覆盖率（code
coverage）、规范覆盖率（specification coverage）或其它度量方法来生成测试用例的数量，更加客观合理，也更加高效。
二、什么是测试建模!
2.1测试建模的概念
测试建模，我认为就是将测试思路或内容形成条理清晰、系统全面的模型而展开的测试（MBT）。这里，需要对本文后面要论述的几个专业名次进行说明。
SUT：System Under Test，被测系统模型，也称类比模型。
TRM：Test Ready Model，测试准备模型，也称分析模型。
2.2测试建模的方法
测试建模的方法从宏观上来看，主要分为SUT建模和TRM建模。从微观上来看又派生了很多的模型。在实际工作中，我们拿到被测系统后，会在脑海里进行瞬时画像建模，也就是构建了心智模型。而从心智模型过渡到测试用例，中间过程的不同决定了不同的测试设计，如图3所示。
路径一（红色箭头）：从心智模型（Mental Model）直接得到测试用例（Ad-hoc Test
Design，基于临时需求）；
路径二（黄色箭头）：从心智模型得到TRM模型，再由TRM模型生成测试用例（TraditionalExploratory传统测试设计）；
路径三（蓝色箭头à紫色箭头）：从心智模型到SUT模型，再由SUT模型生成测试用例（教科书式）；
路径四（蓝色箭头）：从心智模型到SUT模型，再由SUT模型到TRM模型，最终由TRM模型生成测试用例（MBT）。
由上图所示，MBT强调中间过程。特别说明的是，MBT是一个循序渐进、逐步完善的过程，需要将被测系统的各个方面进行考虑，在发布周期之前形成完善的模型有利于整个产品的开发、测试和发布等工作，如图4所示。 
Figure 3 MBT与其它测试设计的区别
Figure 4 MBT建模步骤
我们拿到被测需求后，首先会进行SUT抽象建模；分析需求进行TRM建模；初步模型验证；基于模型可控地生成测试用例；优化并生成可执行测试用例。根据用户关注重点的差异，第一步可以对被测系统进行功能建模，也可以进行用户使用环境建模；第四步可以针对一些模式（Patterns）或测试特异性（Test
specifications）来生成用例，也可以根据测试覆盖率等软件测试度量规则（Criteria）来生成测试用例。
2.2.1--SUT模型
SUT****模型是心智模型（对产品的理解、设想和体验）的外化（以及与现有模型的整合），是一种图形化或形式化的类比模型。它涉及到不同的层次（如系统、组件和工作环境）、不同视角（如语境/上下文、组件与结构、功能、行为和用户体验）和不同关注点（如数据类型、因果关联、程序结构、任务控制、动作、事件和接口）等。
Figure 5 SUT建模的语言及表示法
经过抽象、泛化和删减后，SUT模型只保留有助于实现特定测试目的的特征。在生成可执行测试用例前，SUT模型的实例化可能用到的技术（如图5）包括Finite
State Machine (FSM)，Message Sequence Chart (MSC)，
Control FlowGraph (CFG)，Event Flow Diagram，MarkovChains和UML
Testing Profile 等。图5里面的模型仅作为实例更多偏向局部，实际SUT远不止这些，如语法测试（SYNTAX
TESTING），NLP（自然语言语义模型），此外还有从整体视角的HTSM和ACC等等。
2.2TRM模型
TRM****模型是对SUT模型的扩展和转化（参考图3），以使模型达到可测试的标准；该模型也可独立使用，即给出相关信息，我们就可以设计或使用一套测试设计算法，用来产生可以运行的测试用例。它根据SUT模型特征和项目实际情况增加或凸显质量风险信息。必要时TRM需要创建新的模型，这是测试建模的主要难点之一，但也体现了我们价值所在。另外，它转化SUT模型以达到可测试标准，并增加“怎么测”的信息，同时为SUT模型修改重构提供反馈。
由图3可知，SUT和TRM模型有密切的关系，那么它们的侧重点有哪些区别呢？相对来说，SUT层次更高，更温和，以描述被测对象为己任（更抽象）；而TRM更接地气，更直接，以揭露风险为使命（更具体）。实践中，TRM模型一般以发现SUT的潜在风险为导向。与SUT建模相比，TRM缺少现成的系统的方法论指导，缺少可参考借鉴的方法，更倚重经验，却缺少经验积累（探索式测试提供了一些思路）。因此，TRM建模是目前研究探索的一个重点。
三、怎样展开测试建模
下面主要针对新手初次接触测试建模，该如何展开进行举例说明。
Figure 6测试建模输入输出
在实际测试过程中，我们拿到的输入通常是需求说明书或是开发的实现代码等，经过测试人员的建模加工后，最终生成测试用例。针对需求分析从整体角度，我们往往会使用HTSM或ACC模型进行全局系统化分析（二者选其一，针对具体的模型含义可以参考相关的资料有详细的说明）；针对局部分析我们会使用NLP分析深入理解被测需求（包括识别关键变量），基于NLP的分析结果再进行具体的模型构建，如业务流程图、决策树等等；接着，结合关键变量进行风险分析，完善模型；最终将模型通过自动化或手工方式转换成用例。
由于篇幅所限，下面是我的一个小需求的实践，看官们重点看思路哈。
需求描述如下
3.1需求理解
（本次需求无代码权限，因此不涉及开发实现）
本需求比较小，属于局部需求，因此无需使用全局模型。首先使用NLP（3点12要素）进行需求理解。
3.2依据需求特点进行SUT建模
依据NLP的分析，识别该需求的关键变量。
依据需求特点，该需求涉及多个属性（变量）间存在不同的关系，对应有不同的规则，因此主要采用决策树模型，辅助其它场景补充。
Figure 7 SUT建模
3.3SUT转换TRM建模
Figure 8 TRM建模
3.4TRM模型转换用例
决策树转换程决策表即是所得用例，关于决策树转换决策表的方法本文不赘述。特别需要注意的是，经过分析存在较多的重复验证点，在转换过程中剔除重复验证点，如执行退出的case。
上述过程是为了说明MBT的过程以及美观，实际工作中无需工具绘图。
四、总结
也许最开始你总是在纠结测试建模和测试设计有什么区别，一旦你习惯性使用测试建模去进行测试分析时，你会发现你的测试工作会变得更加有条不紊，有理有据。这就是测试建模真正给你带来的帮助。它在潜移默化地让你用科学系统化的方法论去指导自己开展测试工作，让你的思维更加缜密而又细致。MBT模型能够根据被测系统的改变而更新，还能够根据规则动态生成测试用例，尤其是它能够抽象出复杂的被测系统的结构和内在逻辑，给我们多层面多维度地呈现被测系统。MBT将是未来软件测试的一个重要方向。
模型种类繁多，不在于它好或是不好，对或是不对，而在于合不合适，在于使用它的人如何去用。各个模型好比烹饪时的各种调料，想做出什么样的佳肴凭君搭配选择，当然也存在推荐，你可以选择接受或是拒绝，烹饪出来的佳肴只要是你想要的，目的就达到了。
|
