软件测试基础知识

什么是软件测试
软件测试是评估和验证软件产品或应用程序是否根据其特定要求正确、安全、高效运行的过程。它通常是通过人工或自动化手段运行或检测软件系统，以验证其是否满足需求并识别预期与实际结果差异的过程
在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。

软件测试的目的：
测试是程序的执行过程，目的在于发现错误。一个成功的测试用例在于发现至今未发现的错误，确保产品完成了它所承诺或公布的功能，并且用户可以访问到的功能都有明确的书面说明；确保产品满足性能和效率的要求；确保产品是健壮的和适应用户环境的

软件测试的原则：

测试用例中一个必须部分是对预期输出或接过进行定义；程序员应避免测试自己编写的程序；编写软件的组织不应当测试自己编写的软件；应当彻底检查每个测试的执行结果；测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应当根据无效和未预料到的输入情况；检擦程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”；应避免测试用例用后即弃，除非软件本身就是个一次性的软件；计划测试工作时不应默许假定不会发现错误；程序某部分存在更多错误的可能性，与该部分已经发现错误的数量成正比

软件测试分类
软件测试方法的分类有很多种，以测试过程中程序执行状态为依据可分为静态测试（Static Testing）和动态测试（Dynamic Testing）；以具体实现算法细节和系统内部结构的相关情况为根据可分黑盒测试、白盒测试和灰盒测试三类；从程序执行的方式来分类，可分为人工测试（Manual Testing）和自动化测试（Automatic Testing）

静态测试和动态测试
1）静态测试。静态测试的含义是被测程序不运行，只依靠分析或检查源程序的语句、结构、过程等来检查程序是否有错误。即通过对软件的需求规格说明书、设计说明书以及源程序做结构分析和流程图分析，从而来找出错误。例如不匹配的参数，未定义的变量等。
2）动态测试。动态测试与静态测试相对应，其是通过运行被测试程序，对得到的运行结果与预期的结果进行比较分析，同时分析运行效率和健壮性能等。这种方法可简单分为三个步骤：构造测试实例、执行程序以及分析结果。

黑盒测试、白盒测试和灰盒测试
1）黑盒测试。之所以被称为黑盒测试是因为可以将被测程序看成是一个无法打开的黑盒，而工作人员在不考虑任何程序内部结构和特性的条件下，根据需求规格说明书设计测试实例，并检查程序的功能是否能够按照规范说明准确无误的运行。其主要是对软件界面和软件功能进行测试。对于黑盒测试行为必须加以量化才能够有效的保证软件的质量
2）白盒测试。其与黑盒测试不同，它主要是借助程序内部的逻辑和相关信息，通过检测内部动作是否按照设计规格说明书的设定进行，检查每一条通路能否正常工作。白盒测试是从程序结构方面出发对测试用例进行设计。其主要用于检查各个逻辑结构是否合理，对应的模块独立路径是否正常以及内部结构是否有效。常用的白盒测试法有控制流分析、数据流分析、路径分析、程序变异等，其中逻辑覆盖法是主要的测试方法。
3）灰盒测试。灰盒测试则介于黑盒测试和白盒测试之间。灰盒测试除了重视输出相对于出入的正确性，也看重其内部表现。但是它不可能像白盒测试那样详细和完整。它只是简单的靠一些象征性的现象或标志来判断其内部的运行情况，因此在内部结果出现错误，但输出结果正确的情况下可以采取灰盒测试方法。因为在此情况下灰盒比白盒高效，比黑盒适用性广的优势就凸显出来了。

黑盒测试的测试用例常见设计方法

1)等价类划分： 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.

实际案例：用户注册密码设置
假设某系统对用户密码的要求如下：

密码长度为 ‌6～10位‌，且必须包含‌大写字母、小写字母和数字‌三者组合。

1. 划分等价类

类别	条件描述	类型
E1	长度为6～10位，含大写、小写和数字	有效等价类
E2	长度 < 6	无效等价类
E3	长度 > 10	无效等价类
E4	全为大写字母	无效等价类
E5	全为小写字母	无效等价类
E6	全为数字	无效等价类
E7	大写+小写，无数字	无效等价类
E8	大写+数字，无小写	无效等价类
E9	小写+数字，无大写	无效等价类
E10	长度为6～10位，含大写、小写和数字，包含特殊符号	无效等价类

2)边界值分析法：是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.

使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.

实际案例：用户年龄输入框（18-65岁）
假设某系统要求用户年龄必须在 ‌18 到 65 岁之间（含）‌，即有效范围为 [18, 65]。
根据边界值分析法，我们应选取以下测试数据：

‌最小边界附近‌：17（无效）、18（有效）、19（有效）
‌最大边界附近‌：64（有效）、65（有效）、66（无效）

输入值	类型	说明
17	无效值	刚好小于最小边界，用于验证系统是否拒绝过小输入
18	有效值	最小合法年龄，边界上的有效输入
19	有效值	紧邻最小边界的内部值，验证正常流程
64	有效值	紧邻最大边界的内部值
65	有效值	最大合法年龄，边界上的有效输入
66	无效值	刚好大于最大边界，验证系统是否拒绝过大输入

3)错误猜测法：基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.

错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.

4)因果图方法：前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图(逻辑模型). 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

5)正交表分析法：可能因为大量的参数的组合而引起测试用例数量上的激增，同时，这些测试用例并没有明显的优先级上的差距，而测试人员又无法完成这么多数量的测试，就可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性。

6)场景分析方法：指根据用户场景来模拟用户的操作步骤，这个比较类似因果图，但是可能执行的深度和可行性更好。

7)状态图法：通过输入条件和系统需求说明得到被测系统的所有状态，通过输入条件和状态得出输出条件;通过输入条件、输出条件和状态得出被测系统的测试用例。

8)大纲法：大纲法是一种着眼于需求的方法，为了列出各种测试条件，就将需求转换为大纲的形式。大纲表示为树状结构，在根和每个叶子结点之间存在唯一的路径。大纲中的每条路径定义了一个特定的输入条件集合，用于定义测试用例。树中叶子的数目或大纲中的路径给出了测试所有功能所需测试用例的大致数量。

软件测试V模型
V模型大体可以划分为以下几个不同的阶段步骤：客户需求分析、软件需求分析、概要设计、详细设计、软件编码、单元测试、集成测试、系统测试、验收测试。

客户需求分析
即首先明确客户对于产品的需求，软件所具备的功能。这一点上比较关键的是分析师和客户沟通时的理解能力与交互性。要求分析师能准确的把客户所需要达到的功能，实现方式，等表述出来，给出分析结果，写出需求规格说明书。

软件需求分析
主要根据客户需求分析出软件方面的需求，即需要软件需要的功能，软件需要适应的硬件功能。该部分关键的是做到需求的剥离，以保证软件功能需求覆盖客户需求且不涵盖硬件或其他方面的需求，以方便软件工程师的进一步开发。

概要设计
主要是架构的实现，指搭建架构、表述各模块功能、模块接口连接和数据传递的实现等项事务。

详细设计
对概要设计中表述的各模块进行深入分析，对各模块组合进行分析等，这一阶段要求达到伪代码级别，已经把程序的具体实现的功能，现象等描述出来。其中需要包含数据库设计说明。

软件编码
按照详细设计好的模块功能表，编程人员编写出实际的代码。

单元测试
按照设定好的最小测试单元进行按单元测试，主要是测试程序代码，为的是确保各单元模块被正确的编译，单元的具体划分按不同的单位与不同的软件有不同，比如有具体到模块的测试，也有具体到类，函数的测试等。

集成测试
经过了单元测试后，将各单元组合成完整的体系，主要测试各模块间组合后的功能实现情况，以及模块接口连接的成功与否，数据传递的正确性等，其主要目的是检查软件单位之间的接口是否正确。根据集成测试计划，一边将模块或其他软件单位组合成系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。

系统测试
经过了单元测试和集成测试以后，我们要把软件系统搭建起来，按照软件规格说明书中所要求，测试软件其性能功能等是否和用户需求相符合，在系统中运行是否存在漏洞等。

验收测试
主要就是用户在拿到软件的时候，在使用现场，会根据前边所提到的需求，以及规格说明书来做相应测试，以确定软件达到预期的效果。

软件测试W模型

Alpha测试和Beta测试
Alpha测试是软件发布前的内部测试阶段，Beta测试是面向真实用户的公测阶段‌。两者共同构成软件验收测试的核心环节，用于在正式发布前发现并修复问题。

Alpha Testing
‌执行者‌：由开发公司内部人员（如开发工程师、质量保证团队）在受控环境中进行。
‌环境‌：通常在实验室或模拟实际操作环境中完成，测试人员可即时反馈问题并由开发团队快速修复。
‌目的‌：验证软件的功能、可用性、可靠性、性能和支持能力（统称FLURPS），重点检查界面设计与核心功能是否符合预期。
‌阶段‌：一般在编码完成或子系统测试后启动，是进入Beta测试前的关键前提。
‌特点‌：软件可能存在较多Bug，功能不完整，‌不建议普通用户安装使用‌。

Beta Testing
‌执行者‌：由真实用户或外部测试者在实际使用环境中进行。
‌环境‌：用户在自己的设备和网络条件下使用软件，测试场景多样且不可控。
‌目的‌：
验证软件在真实环境中的兼容性与稳定性；
发现开发团队未预见的使用场景问题；
收集用户对界面友好性、功能流畅性的反馈；
评估服务器负载能力与多平台适配情况。
‌类型‌：
‌封闭式Beta测试‌：邀请特定用户群体（如忠实用户、合作伙伴）参与，反馈质量较高。
‌开放式Beta测试‌：向公众开放注册，覆盖范围广，但反馈质量参差不齐。
‌特点‌：版本已接近最终版（Release Candidate），但仍可能存在缺陷，需通过大规模用户测试进一步优化。

两者核心区别总结

	Alpha测试	Beta测试
‌测试人员‌	内部员工/质量团队	外部真实用户
‌测试环境‌	受控的实验室环境	用户自有的真实使用环境
‌‌测试重点‌	功能完整性、核心逻辑验证	兼容性、用户体验、稳定性
‌‌反馈机制‌	实时沟通，快速修复	定期收集报告，集中分析优化
‌‌‌发布范围‌	仅限内部或小范围专业测试人员	面向大众或特定用户群公开发布

白盒测试中的覆盖方法

1. ‌语句覆盖‌（Statement Coverage）
   确保程序中的‌每个可执行语句至少执行一次‌。这是最基础的覆盖标准，但无法保证所有分支或条件都被充分测试，可能遗漏逻辑错误。

2. ‌判定覆盖‌（Decision Coverage，又称分支覆盖）
   要求每个‌判断的真假分支至少各执行一次‌，例如 if 语句的 true 和 false 路径都要走一遍。相比语句覆盖更强，能发现更多控制流问题。

3. ‌条件覆盖‌（Condition Coverage）
   确保每个‌布尔子表达式（条件）的真假值至少出现一次‌。例如在 if (A > 0 && B < 0) 中，分别测试 A > 0 为真/假、B < 0 为真/假的情况。

4. ‌判定/条件覆盖‌（Decision/Condition Coverage）
   同时满足‌判定覆盖和条件覆盖‌的要求，既保证每个判断的分支被执行，也保证每个子条件取到所有可能的值。它弥补了前两者的不足，但仍不考虑条件组合。

5. ‌条件组合覆盖‌（Multiple Condition Coverage）
   要求每个判定中‌所有条件的可能取值组合至少执行一次‌。例如两个条件有 2²=4 种组合（真真、真假、假真、假假），需全部覆盖。测试强度高，但用例数量随条件增加呈指数增长。

6. ‌路径覆盖‌（Path Coverage）
   确保程序中‌所有可能的执行路径都被覆盖‌，包括循环、嵌套分支等形成的完整流程路径。理论上最彻底，但由于“路径爆炸”问题，实际项目中常采用基本路径覆盖作为替代。