2018年6月8日，作为第一届TMMi中国峰会圆桌会议的嘉宾，我参与讨论了“如何更好的复用测试资产”这个测试主题，其中分享了我对该话题的一些想法和经验。现在通过文章的方式将当时讲解的内容进行了一些归纳和总结，供大家参考和探讨。
测试资产不仅仅包括测试过程中输出的各个测试文档，同时包括测试团队积累的测试经验、技能和思维等。测试工作中经常会出现下面的场景：你作为测试人员工作几年之后，在测试经验、技能和能力方面非常出色，有可能就会开始你的测试管理职位；或者，随着自己技能和能力的不断增加，在有更好机会出现时离开当前公司；此时，假如团队内没有很好的测试资产复用要求，你这么多年在测试团队内积累的经验和技能等，就会随着你职位的改变或者跳槽而出现中断，甚至几乎没有任何传承。因此，测试资产复用对于测试团队的经验传承和持续改进是不可或缺的。
测试资产的复用，套用结构化思维的精髓，同样是有框架的，其核心是分层次的，即测试过程中必须根据不同目的，对不同层次的测试资产进行复用。主要包括：
1、文档复用
2、经验复用
3、思维复用
一、文档复用
测试贯穿于整个开发生命周期，对于较为正式的测试过程，其每个测试阶段都会输出相应的文档，这就是最基础的测试资产。我们以ISTQB的测试过程为例，其生命周期由5个阶段组成，分别是：
1）测试计划与监控
2）测试分析与设计
3）测试实现与执行
4）测试出口准则评估与报告
5）测试结束活动
ISTQB初级认证提供的测试过程作为一个重流程的典型，每个阶段输出的文档输出参考的是IEEE 829 - 1998文档标准。当然，测试实践中我们并不一定会全版套用标准中规定的每个细节，而是根据项目特点、产品特点、质量要求等对标准内容进行裁剪。不管是具体文档形式输出，还是存在于个人脑海中的文档内容，是测试团队可以复用的第一次层次资产。IEEE 829 - 1998文档标准包含的文档类型如下图所示。
二、经验复用
测试人员的优秀经验是开展成功测试的重要组成部分，测试过程中很多缺陷的发现不是在验证需求是否实现的过程，而是测试人员在相对独立自主开展探索性测试中发现的。此过程中测试人员假如能构建结构化的测试经验资产，就可以在测试团队内有效分享测试思路和经验，同时可以减少其他测试人员测试相近类型被测对象时走弯路，或者重复测试工作。
测试人员的经验总结，属于测试团队可以利用的第二层次资产。有了该层次的测试资产，测试团队的经验相对不会随着测试人员的流动而消失。下面是我在测试工作中实践的两个思路：
全局视角：DTO（Data Test Overview），针对不同项目或者产品中共性的一些功能，例如：通讯产品中通常都会有DHCP功能以获取IP地址。此时，会针对DHCP功能形成DTO文件。
责任人：完整经历过该功能测试分析、设计和执行的测试人员，针对该功能的测试人员有丰富的测试经验；
测试分析与设计：以思维导图的方式罗列该功能的主要测试点，而非详细的测试用例。基于结构化思维和发散性思维构建该功能测试点的框架；
测试实现与执行：该功能的测试点罗列更偏向脚本化思路，而测试执行过程中，基于脚本化的测试点基础之上，结合探索性测试的发散特点，实现脚本化测试和探索性测试的平衡；
优点：结构化与发散性思维的平衡，更方便维护和测试思维的发散；
缺点：测试点的颗粒度选择问题，在测试团队内部不容易统一；
局部视角：将产品测试过程中一些共性的测试点进行归纳和总结，以形成缺陷攻击列表，例如：
强制无效输出：年月日的测试；
文件保存：文件中出现“\”字符；
强制恢复默认值：全局变量和局部变量之间是否能恢复到默认值；
重复创建和删除条目：重复Enable和Disable，导致内存泄漏，业务不通；
全局变量和局部变量的关系：IGMP总开关和端口开关之间的切换；
测试技术：例如等价类边界值分析；
三、思维复用
除了前面提到的文档复用和测试经验复用之外，更重要的是将测试过程中应用的结构化思维、发散性思维和可视化思维形成资产，在测试团队内共享和传承。相对而言，测试思维在测试团队内的复用是更困难的，但是对测试团队能力的提升也是最有效的。即使大家面对的是同样的文档、经验和测试对象，由于测试人员之间思维方式不同，测试得到的结果都会是截然不同。下面是测试用例为例，说明测试思维在测试工作中的作用。
测试用例是测试分析与设计阶段的重要输出，其质量直接影响了后续的测试执行效率和有效性。结构化思维的应用有助于提升测试分析与设计活动的质量，其核心是构建框架，把表象杂乱复杂的测试点/测试用例变得结构而有序。“问题驱动的软件测试设计”课程体现的就是结构化思维在其中的应用过程 - 自上而下的结构化构建（可以参考下面的框架图）：
选择框架：根据测试过程中经常面临的4大问题入手，搭建了有4个维度组成的框架，分别是基于质量模型、基于领域知识、基于规格说明、重点选择和测试执行。结构化思维中其属于搭架子的过程，常见的架子除了基于行业背景知识外，还有时间架、空间架和三角架等；
分层/分类：对框架中的每个维度或架子进行分层和分类。例如：针对领域知识，包含了功能交互模型和用户场景模型等。
继续细分：根据对测试目标和测试人员能力等因素的考虑，确定测试点的颗粒度，然后根据颗粒度要求继续对每个维度/架子进行不断详细化，直到满足要求为止；
检查框架：分层/分类和细化过程，需要不断检查每个层次之间是否满足MECE原则（相互独立、完全穷尽，简单地讲就是各个分类之间不重叠不遗漏）；
构建测试资产以及在测试团队内的分享和传承，不仅需要测试团队有这个意识，同时也需要测试流程、技术和工具的支持。同时，不同测试资产之间是相互支撑和反馈的，需要我们持续调整和改进。
[本文提到的结构化思维、发散性思维、可视化思维、测试资产等内容，将在后续的文章中陆续推出，敬请关注并欢迎大家与我对文中内容进行探讨！]
网友评论