功能模块划分：

功能模块划分时应该遵循什么样的规则？

模块划分原则：

1、高内聚，低耦合

2、重整体，轻局部

功能模块划分有哪些比较好的方法？

模块划分方法1：

功能流程法：将功能的基本流程画出来，根据流程的每个大的环节进行模块划分，然后再细化和查漏补缺；

举例：请就银行ATM的取款功能进行模块划分

插卡环节-密码登录环节-输入金额环节-取卡环节-取走钱币环节

模块划分方法2：

层次划分法：按照逻辑层次逐层细化出模块的过程，比较适用于UI划分，大的系统模块划分等；

举例：请就dota的这款游戏进行模块划分

dota-战斗外内容-战斗内内容-账号登录-按键设置-英雄-道具

动画-技能

模块划分方法3：

类型划分法：按照功能包含内容的不同类型进行划分

举例:兵种测试，道具测试等

兵种测试-可训练兵种-不可训练兵种

道具测试-可消耗道具-不可消耗道具

类型划分比较适用于一个功能种类相对独立，种类之间关联度较低的情况

模块划分注意事项

不同的划分方法适用不同的场景，要具体问题具体分析

有时候一个功能需要结合多种方法进行划分

划分方法不重要，划分原则更重要一些

划分完毕后，要结合需求文档重新梳理，确保模块清晰，覆盖完整

功能模块划分

1. 遵循原则

1. 高内聚，低耦合【货币购买，月卡+普通货币购买】

2. 重整体，轻局部【货币购买，UI购买】
   

2. 划分的方法

1. 功能流程法：画出来，根据流程每个大环节进行模块划分，然后再细化和查漏补缺

2. 层次划分法：逻辑层次，比较适合UI划分【战斗内【账号登陆，按键】、战斗外【英雄【动画，技能】，道具】】

3. 类型划分法：道具测试【可消耗、不可消耗道具】

3.注意事项

    1.具体问题具体分析


    2.原则更重要


    3.根据需求文档重新梳理，模块清晰，功能完整

功能模块划分

（1）划分原则：（博主自己的总结，不存在与任何软件测试书籍中）

1、高内聚，低耦合：模块内关联度高；模块间关联度低，无法合并成一个模块

比如一个货币购买的功能，月卡的购买和普通货币的购买可以划分成两个单独的模块，因为两者几乎不存在任何关联度，购买其中任何一个模块不会对另一个模块产生影响，符合低耦合的原则；

如果就月卡的购买进行分拆的话，显然没必要继续划分成功能和UI两个模块，因为月卡的购买流程非常简单，而且功能之间的关联度非常高，符合高内聚的原则。

2、重整体，轻局部：功能整体上关注模块构成、逻辑和覆盖范围，轻局部不用纠结较为具体的细节

还是以货币的购买功能为例，整体上可以划分为UI、购买与领取、特殊情况等大模块，或许也可以划分成一些子模块；不用太关注细节，比如页面上显示的倒计时、UI按钮的位置等等

（2）划分方法：（博主自己的总结，不存在与任何软件测试书籍中）

1、功能流程法（小系统）：将功能的基本流程画出来，根据流程的每个大的环节进行模块划分，然后再细化和查漏补缺

举例;（银行取钱模块划分：插卡 -- 输密码 -- 输入金额 --取钱 -- 退卡）

2、层次划分法（大系统）：按照逻辑层次逐层细化出模块，比较适用于UI划分，大的系统模块划分等

（dota游戏模块划分：见截图）

3、类型划分法：按照功能内容的不同类型进行划分（如按照道具的不同类型进行划分）

注意点

不同方法适用于不同场景 具体问题具体分析

有时候一个功能要结合多种方法进行划分

划分方法不重要，划分原则更重要

划分完成后，结合需求文档重新梳理，确保模块清晰、覆盖完整、符合需求设计

 就是分类学家该干的事. 这几种方法吧, 说好也好, 说不好也不好. 综合来说, 模块划分跟代码相关性很大. 在代码未知的情况下进行模块划分, 应该以游戏操作逻辑为主.

模块划分的原则：

不要过于执着分拆，要判断功能之间的独立性

模块划分注意事项

模块划分法2：层次划分法

模块划分法1：功能流程法

模块划分法3：类型划分法

注意事项：

模块划分：

类型划分法，按照功能包含内容的不同类型进行划分

模块划分：

层次划分法，按照逻辑层次逐层细化出模块

模块划分：

功能流程法，根据功能基本流程每个环节进行划分，然后再细化

模块划分原则：

高内聚低耦合：模块之间没有联系，模块内部不再继续细分

重整体轻局部：从功能整体关注模块的构成，不纠结于具体细节

模块划分原则：

• 高内聚，低耦合

• 重整体，轻局部
  

模块划分方法：

1. 功能流程法（画出功能的基本流程）

2. 层次划分法（按照逻辑层次逐层划分）

3. 类型划分法（按照功能包含内容划分）
   

模块划分方法3

模块划分方法2

模块划分方法1

测试用例第二步：模块划分

模块划分原则

模块划分原则

模块划分注意事项

模块划分方法3

模块划分方法2

模块划分方法

功能模块划分

（2）如何写好测试用例之——功能模块划分：

（老师个人观点，经验所得）

功能模块划分原则：

a.高内聚，低耦合（模块内的功能紧密联合若尝试分拆则分拆后的内容很难单独继续存在。模块与模块间的联系关联度低无法合并为一个模块）

b.重整体，轻局部（在划分模块式须有大局观，从功能整体的层面上去关注模块的构成，如模块的逻辑，模块的覆盖范围等等。划分模块时不要纠结于某些具体的细节）

功能模块划分方法：

a.功能流程法：将功能的基本流程画出来，根据流程的每个大的环节进行模块划分，然后再细化和查漏补缺。

举例：请就银行ATM的取款功能进行模块划分？

插卡->密码登录->输入金额->取出钱币->取卡

b.层次划分法：按照逻辑层次逐层细化模块的过程，比较适用于UI划分，大的系统模块划分等。

举例：请就Dota这款游戏进行模块划分？

                                ->账号登录

          ->战斗外内容         ......

                                ->按键设置

DOTA      

                               ->英雄

          ->战斗内内容    ......

                               ->道具

c.类型划分法：按功能内容的类型划分。适用于一种功能的种类相对独立，而且种类间的耦合度较低的情况。

举例：兵种测试，道具测试等。

兵种测试分（可训or不可训）

道具测试分（可消耗or不可消耗）

PS：具体问题具体分析，有时候一个功能可结合多种方法划分，注重划分原则，划分完毕后结合需求文档重新梳理。

功能模块划分

划分原则：（博主自己的总结，不存在与任何软件测试书籍中）

1、高内聚，低耦合：模块内关联度高；模块间关联度低，无法合并成一个模块

比如一个货币购买的功能，月卡的购买和普通货币的购买可以划分成两个单独的模块，因为两者几乎不存在任何关联度，购买其中任何一个模块不会对另一个模块产生影响，符合低耦合的原则；

如果就月卡的购买进行分拆的话，显然没必要继续划分成功能和UI两个模块，因为月卡的购买流程非常简单，而且功能之间的关联度非常高，符合高内聚的原则。

2、重整体，轻局部：功能整体上关注模块构成、逻辑和覆盖范围，不用纠结较为具体的细节

还是以货币的购买功能为例，整体上可以划分为UI、购买与领取、特殊情况等大模块，或许也可以划分成一些子模块；不用太关注细节，比如页面上显示的倒计时、UI按钮的位置等等

划分方法：（博主自己的总结，不存在与任何软件测试书籍中）

1、功能流程法（小系统）：将功能的基本流程画出来，根据流程的每个大的环节进行模块划分，然后再细化和查漏补缺

（银行取钱模块划分：插卡 -- 输密码 -- 输入金额 --取钱 -- 退卡）

2、层次划分法（大系统）：按照逻辑层次逐层细化出模块，直至不能划分

（dota游戏模块划分：见截图）

3、类型划分法：按照功能内容的不同类型进行划分（如按照道具的不同类型进行划分）

注意点

不同方法适用于不同场景

有时候一个功能要结合多种方法进行划分

划分方法不重要，原则更重要

划分完成后，结合需求文档重新梳理，确保模块清晰、覆盖完整、符合需求设计

功能模块划分

划分原则：（博主自己的总结，不存在与任何软件测试书籍中）

1、高内聚，低耦合：模块内关联度高；模块间关联度低，无法合并成一个模块

比如一个货币购买的功能，月卡的购买和普通货币的购买可以划分成两个单独的模块，因为两者几乎不存在任何关联度，购买其中任何一个模块不会对另一个模块产生影响，符合低耦合的原则；

如果就月卡的购买进行分拆的话，显然没必要继续划分成功能和UI两个模块，因为月卡的购买流程非常简单，而且功能之间的关联度非常高，符合高内聚的原则。

2、重整体，轻局部：功能整体上关注模块构成、逻辑和覆盖范围，不用纠结较为具体的细节

还是以货币的购买功能为例，整体上可以划分为UI、购买与领取、特殊情况等大模块，或许也可以划分成一些子模块；不用太关注细节，比如页面上显示的倒计时、UI按钮的位置等等

划分方法：（博主自己的总结，不存在与任何软件测试书籍中）

1、功能流程法（小系统）：将功能的基本流程画出来，根据流程的每个大的环节进行模块划分，然后再细化和查漏补缺

（银行取钱模块划分：插卡 -- 输密码 -- 输入金额 --取钱 -- 退卡）

2、层次划分法（大系统）：按照逻辑层次逐层细化出模块，直至不能划分

（dota游戏模块划分：见截图）

3、类型划分法：按照功能内容的不同类型进行划分（如按照道具的不同类型进行划分）

注意点

不同方法适用于不同场景

有时候一个功能要结合多种方法进行划分

划分方法不重要，原则更重要

划分完成后，结合需求文档重新梳理，确保模块清晰、覆盖完整、符合需求设计

类型划分法

dota游戏模块划分