"测试是为发现错误而执行程序的过程。"
测试应当遵循以下原则：
- 测试用例必须对预期输出或结果进行定义。
- 应当彻底检查每个测试的执行结果。
- 测试用例的编写不仅应当根据有效或预料到的输入情况，还应当根据无效或未预料到的输入情况。
- 避免测试用例用完即弃。
1 代码检查
这个过程是发现错误，而非提出解决方案。1）逐条语句讲述程序的逻辑结构。2）参考常见的编码错误列表。
1.1 常见的编码错误列表
1、数据引用错误
1）是否有引用的变量未赋值或未初始化。
2）对于所有的数组引用，每个下标的值是否在界限内。
2、数据声明错误
1）是否所有的变量都进行了明确的声明。
2）如果没有明确声明，默认的属性能否被正常理解。
3）是否每个变量都被赋予了正确的长度和数据类型。
4）是否存在着相似名称的变量。（这种情况不一定是错误，单应被视为警告）
3、运算错误
1）是否存在不一致的数据类型的变量间运算。
2）是否有混合模式的运算。（例如将浮点变量与一个整形变量做加法运算）
3）赋值语句的目标变量的数据类型是否小于右边表达式的数据类型或结果。
4）运算中是否存在表达式向上或向下溢出的情况。
5）除法运算中的除数是否可能为0。
6）在特定场合，变量的值是否超出了有意义的范围。
7）赋值顺序和操作符的优先顺序是否正确。
4、比较错误
1）是否有不同数据类型的变量之间的比较运算。
2）是否有混合模式的比较运算或不同长度的变量间的比较运算，如果有，应确保程序能正确理解转换规则。
3）比较运算符是否正确。
4）每个布尔表达式所叙述的内容是否都正确。
5、控制流程错误
1）是否所有循环最终都终止了。
2）由于实际情况没有满足循环的入口条件，循环体是否可能从未执行过?如果是，这样是否是一处遗漏。
3）是否存在"仅差一个"的错误，迭代次数恰恰多一次或少一次。
4）是否存在不能穷尽的判断。
6、接口错误
1）参数是否匹配。
7、输入/输出错误
1）是否有足够的可用内存空间，来保留程序将读取的文件。
2）是否所有的文件在使用之后都关闭了。
3）程序是否正确处理了类似"File Not Found"这样的错误。
8、其他检查
1）如果程序编译通过了，但计算机提供了一个或多个"警告"或"提示"信息，应对此逐一进行认真检查。
2）程序能否对其输入的合法性进行检查。
3）程序是否遗漏某个功能。
2 测试用例的设计
对任何程序的测试必定是不完全的，那么，最显然的测试策略就是努力使测试尽可能完全。
2.1 白盒测试
是一种基于对程序内部逻辑结构、代码实现细节的理解。关注"代码如何工作"。（单元测试属于白盒测试）
核心目标：
- 验证程序内部逻辑的正确性（如条件判断、循环执行、函数调用等）；
- 发现代码级缺陷（如逻辑错误、分支遗漏、变量未初始化、数组越界、死循环等）；
- 确保所有代码路径被充分覆盖（避免"沉睡代码"或未测试的分支）；
- 验证代码对边界条件、异常场景的处理逻辑（如空指针）。
白盒测试主要分为静态测试（不运行代码）和动态测试（运行代码）。
2.1.1 静态测试方法
1、代码审查
由团队交叉检查代码，重点关注逻辑漏洞、代码规范、潜在风险。
2、静态代码分析工具
借助工具自动化扫描代码、效率远高于人工审查。
3、文档审查
验证详细设计文档、流程图与代码实现的一致性。避免"设计与落地脱节"。
2.1.2动态测试方法
按覆盖读从低到高排序：
1、语句覆盖
确保每一行可执行代码都被执行最少1次。最基础，无法检测分支问题。
2、分支覆盖/判定覆盖
确保每个if/else、switch等判定的"真/假"分支都被执行。仍可能遗漏条件细节。
3、条件覆盖
确保判定中的每个子条件的"真/假"都被覆盖。关注条件本身，但仍可能未覆盖所有判定结果。
4、条件-分支覆盖
同时满足"判定覆盖"和"条件覆盖"。
5、条件组合覆盖
确保判定中所有子条件的"真/假"组合都被执行。覆盖最全面，能及时发现大部份逻辑漏洞，但用例量较大。
6、路径覆盖
设计足够的测试用例，覆盖程序中所有可能的执行路径。最强大的覆盖标准，但是用例数量可能非常庞大（甚至无穷）。
2.1.3 基本路径测试方法
在程序控制图的基础上，通过分析控制结构的环路复杂性，导出基本可执行路径集合，从而设计测试用例。步骤如下：
- 根据代码绘制控制流图。
- 计算环路复杂度。
- 确定线性独立路径的基本集合。
- 设计测试用例。
2.2 黑盒测试
不关注软件内部代码逻辑和实现细节，仅通过输入数据、观察输出结果和交互行为。关注"功能如何表现"。
2.2.1 等级分析
将程序的输入划分为若干个子集（即"等价类"），使得在同一个子集中的每个输入数据，在揭露程序错误方面是等价的。
如果这个子集中的一个输入能检测某个缺陷，那么该子集的其他任何输入也能检测同样的缺陷；反之，如果不能，那么其他也不能。
基于的假设：软件对同一类别的输入数据的处理方式是相同或相似的。
|-------|--------------------------------------------------------------------------------------------|
| 有效等价类 | 符合软件规格说明的、合理的、有意义的输入数据构成的集合。 目的：检验软件是否实现类预期的功能。 |
| 无效等价类 | 不符合软件规格说明的、不合理的、无意义的输入数据构成的集合。 目的：检验软件是否具备良好的容错性，能否正确处理异常输入。 划分无效等价类至关重要，好多缺陷都发生在边界和异常处理上。 |
表 等价类的类型
【划分原则】
1、数值型输入
1）按"范围"划分；2）按"类型"划分，若需求要求"整数"，则无效等价类包括"小数"、"负数"及"字符串"；3）按"特殊值"划分
2、字符串型输入
1）按"长度"划分；2）按"格式"划分，比如手机号格式；3）按"内容划分"，例如需求规定输入须包含"@"
3、布尔型输入
有效布尔值及非布尔值。
4、日期型输入
1）按"合法性"划分；2）按"范围"划分
5、路径/文件输入
1）按"文件类型"划分；2）按"文件大小"划分。
【优缺点】
优点： 1）系统化、科学化：避免了随机选择测试数据的盲目性。2）高效：用少量有代表性的测试用例覆盖大量潜在输入，大大减少了测试用例数量。3）考虑了无效数据。
****缺点：****1）高度依赖测试人员的经验：等价类的划分是否准确、完整。2）可能忽略边界值。3）不适用逻辑依赖强的输入：如果输入数据之间存在强烈的逻辑关系或内部状态依赖，仅靠独立的等价类划分可能不够。
2.2.2 边界值分析
核心经验：边界是错误的"高发区"
输入和输出等价类中那些恰好处于边界、或超过边界、或在边界以下的状态。
2.2.3 因果图
专门解决"多输入条件组合触发多输出结果。弥补了等价划分法和边界值分析的不足（后两者更侧重"单条件"或"范围"，而因果图聚焦"多条件组合"）
【核心概念】
因（Cause）
输入条件，指功能的所有输入项（包括"是否满足条件"的二值判断），用C+编号表示（C1、C2）
每个"因"只有两种状态：真（T）（满足输入条件）或假（F）（不满足输入条件）
例如登录功能中，"用户名正确"（C1）、"密码正确"（C2）、"验证码正确"（C3）
果（Effect）
输入条件组合触发的功能输出或状态编号。用E+编号表示（E1、E2）
每个"果"也只有两种状态：真（T）（结果出现）或假（F）(结果不出现)。
例如 "登录成功"（E1）、"提示用户名错误"（E2）、"提示密码错误"（E3）
核心逻辑关系
通过特定符号表示"因"于"果"之间的逻辑关系。
1）恒等 →
若C为真，则E必为真；C为假，则E必为假。
2）与 ∧
所有C均为真时，E才为真；任意C为假，E为假。
3）或 ∨
任意一个C为真时，E为真；所有E为假时，E才为假。
4）非 ~
C与E的状态相反。
约束条件
C与C的关联、E与E的关联。
1）互斥 Exclusive，E
多个C中，最多只能有一个为真。
2）包含Inclusive，I
多个C中，至少有一个为真。
3）唯一Only One O
多个C中，必须且只能有一个为真。
4）要求 Require R
若C1为真，那B1必须为真。 C1 -> C2
5）强制 Mask M
若E1为真，则E2必须为假
【设计步骤】
1、分析需求
C（输入条件）：所有影响功能输出的输入项
E（输出结果）：所有可能的功能输出或状态变化。
2、明确C与E的逻辑关系。
3、绘制因果图。
4、将因果图转化为判定表。
5、从判定表生成测试用例。
【优缺点】
****优点：****1）逻辑覆盖全面；2）可视化清晰；3）用例针对性强；4）适合复杂功能
****缺点：****1）学习成本高；2）输入条件过多时组合爆炸；3）依赖需求清晰度；4）不适合简单功能；
2.3 测试策略
1）如果规格说明中包含输入条件组合的情况，应首先使用因果图分析方法。
2）在任何情况下都应使用边界值分析方法。
3）因为输入和输出确定有效和无效等价类，在必要情况下对上面确认的测试用例进行补充。
4）使用错误猜测技术增加更多的测试用例。
错误猜测：利用直觉和经验猜测出错的可能类型，然后编写测试用例来暴露这些错误。
5）针对上述测试用例集检查程序的逻辑结构。