大家好！我是新人唱跳 rap 打篮球，是一个立志 2025 年开始每周都能水一篇文章的人
最近两周比较忙，来新公司以后需要熟悉产品业务功能，需要和开发沟通学习不少东西
工作外的时间也是去打篮球去了，有个朋友一起确实会比较积极一点
做测试的朋友都知道，进行测试分析、写测试点是我们的基本功，但想写好测试点其实不容易得
今天分享一下我在工作中，前辈交给我的分析方法，使用金字塔原理进行测试点分析，让我们的测试分析更有方向、条例
这算个大坑吧，很早之前就存了草稿，但是一直没写，因为自己其实掌握的也就一般，这里就给大家做个简单介绍吧
《金字塔原理》也是一本书，有兴趣的朋友也可以直接买来看看
下面我根据自己的实际经历讲讲我眼中的金字塔原理
我刚去上家公司的时候已经有 3 年左右没有写过功能测试用例，工作内容基本都是做自动化代码开发以及环境维护相关的工作内容
当我复杂第一个项目相关的测试案例编写时，一下子就不知所措了
第一个版本的测试用例下来，被产品、开发、测试吐槽了个体无完肤，当然也有我对产品本身不熟悉的原因
第二个版本我又闷头去改了一个版本，还是不行，主要就是写的用例没有重点、没有条理，自己也觉得确实不行
第三个版本是导师给我说了一下，推荐我去看金字塔原理，让自己的测试点更有结构化的条例，这样就就算有缺失也很容易给评审人员发现
学习一下后，第三个版本也就顺利通过了评审，这件事也算是自己失败中的经验吧。
这里只是给没有多少测试经验、或者头痛写测试点的朋友做个分享，希望可以帮助到你们
当需求点如乱麻的帅到脸上时，其实最主要的就是将零碎的想法转化成一个有结构的体系
这里就要说到 xmind 了，一个帮我们结构化整理内容的工具，帮助我们快速将零碎的想法整理好
借助 xmind，可以通过以书面形式组织和表达思想，是金字塔原理的实际应用，借助金字塔原理 +xmind，可以帮助我们界定问题、分析问题
从更广泛的方面说，金字塔原理可以用来知道组合和管理整个写作过程。
及东南来说，任何事情都可以被归纳出一个中心论点，而此中心论点可由三至七个论据支持，这些一级论据本身也可以是个论点，被二级的三到七个论据支持，如此延伸，状如金字塔。
这样的方式和我们人类思维基本规律一致：大脑会自动将所发现的事务以及某种逻辑模式组织起来，也就说大脑有对事务进行归纳组织的偏好。
我们的大脑善于将信息归纳分组，以便于理解和记忆。读者会将读到的思想进行归类分组和总结概述，以便记住。
以我们测试点分析为例子，我们一般会以一个迭代作为一个项目的目标，一个迭代下有很多需求，一个需求下有对应了很多功能，类似这个样子
但是会遇到很多问题，比如说一个需求下的功能点太多，光使用功能点表达没有体现一个大的场景的测试
这就需要我们在功能的基础上再增加一个或多个分层，来帮助我们整理测试思路，这和我们的经验和业务相关
我的实际操作建议是，每个节点细分点不要超过 6 个，如果超过了就需要考虑再进行一下分层
每当我们评审测试点时，收缩结构，然后一层一层的点开节点，向需求、开发、测试人员展示你的思路，确定测试是否有遗漏点
当注意的是，编写测试点一定要对需求和功能有一定的理解，不然写出的测试点也是牛头不对马嘴了
这些都是我一些个人经验，希望对没有思路的你有点帮助
我对金字塔原理也是简单的了解一下，也是趁着这个机会再学习一下
金字塔原理的四个基本原则是
金字塔内部的逻辑关系，前面先引出读者、评审者最初的疑问、关注点
这里引出读者一般对于测试人员来说就是这个大的迭代
纵向关系，这个迭代有一个需求是什么，需求下的功能是什么，我按什么思路进行测试分析，有那些测试点
横向关系，这里分演绎推理和归纳推理，这里主要是归纳是应遵守 MECE 原则
也就是我们在拆分功能点时应该把握的原则
对于我们测试来说，并不是将功能进行一个简单的划分，而是在拆解需求的过程中找到测试点，针对一个个的测试点进行延展
这里有可能是某个相关联的测试点不属于本次开发的模块，但又需要测试
有可能是一个功能点下设计的功能检查点众多
这里对应了构建金字塔原理构建方法中的，自上而下和自下而上法
自上而下思考，得出测试基础测试分析，不断与产品、开发确认以获得完整的测试点和测试思路
先发散，后总结。用这种方式思考，不仅更容易找到逻辑结构，也更容易培养你的机构化思维。
不知不觉写了这么多，感觉写太多也没人想看了，今天就介绍金字塔原理中关于表达的逻辑吧！
希望能对不擅长写测试点的朋友们有一点帮助
我是新人唱跳 rap 打篮球，是一个立志 2025 年开始每周都能水一篇文章的人，希望我的文章可以给你带来好心情！
