详细的软件测试级别

出于在不同开发阶段进行测试的目的，测试活动分为需求测试，组件/单元测试，集成测试，系统测试，验收测试，Alpha测试，Beta测试，UAT测试和其他级别.

一个，需求测试

软件测试的双V模型要求测试工程师在需求阶段开始制定系统测试计划，并考虑系统测试方法，但这还不够. 全面的质量管理要求在每个阶段进行验证和确认活动. 因此，在需求阶段，测试工程师还需要自己测试需求. 此测试是必需的，因为在许多失败的项目中，返工的70％至85％是由需求错误引起的. 由于错误的要求导致大量返工非常痛苦，导致进度延迟，缺陷扩散甚至项目失败. 因此，测试工程师需要从软件生产需求的源头开始进行测试.

需求测试（Requirement Test）用于检查需求规范中是否存在诸如描述不正确，定义不明确，用例不正确以及语言含糊等问题. 主要从以下几个方面考虑.

1. 诚信.

每个要求都必须清楚地描述要实现的功能，并为开发人员提供设计和实现这些功能的所有必要基础.

2. 正确性.

每个要求都必须准确说明要开发的功能.

3. 一致性.

一致性是指它不与其他软件要求或高层（系统，业务）要求相矛盾，或者与项目宣传材料相一致.

4. 可行性.

每个要求必须在已知系统和环境的能力和限制范围内可以实现.

5. 没有歧义.

需求手册的所有读者只能有一个清晰统一的解释. 由于自然语言很容易导致歧义，因此请尝试以简洁明了的用户语言表达每个需求.

6. 坚固.

在需求描述中是否已经分析了可能发生的异常，并且已经处理了这些异常的容错能力.

7. 必要.

必要性可以理解为每个要求都用于授权书面文档的“根”. 为了使每个需求都可以追溯到客户的输入，例如需求用例或其他来源.

8. 可测试性.

可以通过设计测试用例或其他验证方法来测试每个需求.

9. 可修改性.

每个需求在软件需求规范中应该只出现一次. 这使得在进行更改时易于保持一致性. 另外，使用目录表，索引和交叉引用列表方法将使修改软件需求规范变得更加容易.

第二，组件/单元测试

在软件系统中，系统对象的基本单元称为组件或程序单元. 程序代码中的功能或类称为“单元”，而实现独立要求的功能模块则称为组件/单元. 组件可能包含多个单元.

组件/单元测试（单元测试）是用于对软件的基本组件单元（软件设计的最小单元）进行正确性测试的测试. 其目的是检测被测组件/单元与详细设计规范的符合程度. 通过组件/单元测试活动来验证被测试对象的功能或非功能特性，并发现它可能存在诸如内存泄漏，算法冗余，分支覆盖范围低和循环调用效率低的问题. 此类缺陷在系统测试级别上很难找到. 因此，组件/单元测试可以尽早发现缺陷，并且修复缺陷的成本相对较低.

组件/单元测试通常由开发人员执行，并且成本相对较高. 在敏捷的研发模型中，测试工程师可能还需要实施此测试活动. 组件/单元测试活动也可以使用自动化测试方法.

组件/单元测试活动基于组件/单元要求，详细的设计文档，被测代码，编程规范等. 典型的测试对象通常包括组件，功能，类，数据转换/移植过程，模型和关键的字典等，要注意内部数据结构的正确性，逻辑控制和被测对象的异常处理.

[案例1计算器单元测试]

计算器软件具有加，减，乘和除四个基本功能. 要在其上执行单元测试，请使用Junit单元测试工具对其进行如下实现.

计算器功能代码:

测试结果如图1所示.

图1单元测试示例

从以上情况可以看出，除法测试失败. 预期结果为4，但实际结果为3. 检查代码，因为除法功能代码错误，并且“ a / b”错误写为“ a-b”. 在进行单元测试时，仅关注每个功能或类单元的输入和输出，并根据预期结果与实际结果的比较来判断被测对象的正确性.

三，整合测试

可以通过组件/单元测试通过后的组件或单元的集成测试. 集成测试（Integration Testing）用于测试组件/单元之间以及组件/单元与第三方接口之间. 其目的是验证接口是否符合设计并满足要求.

根据被测对象的集成程度，集成测试可以分为三种类型的集成: 组件/单元之间的集成，模块之间的集成以及子系统之间的集成. 集成规模越大，发现缺陷就越困难. 因此，根据被测对象的系统结构特征，首先要进行组件/单元之间的集成测试，并采用自下而上或自上而下的增量策略. 实施集成测试活动后，Big Bang集成策略逐渐被淘汰.

[案例2计算器集成测试]

单元测试中的案例1计算器功能alpha 测试是系统测试的一种，假设加alpha 测试是系统测试的一种，减，乘和除这四个功能是独立的类文件. 当使用集成测试的自顶向上策略时，首先要测试每个类，然后在划分代码如下时测试主控制模块:

实施集成测试并构造测试输入a = 4和b = 0时，将引发异常，如图2所示.

图2-异常集成测试示例

集成测试的目的是检查软件模块是否符合“摘要设计规范”，重点是接口与模块之间的数据传输之间的关系以及组合后模块的整体功能. 集成测试实现者通常是开发人员，但是他们当然也可以是测试工程师. 现在，许多企业集成测试都实现了自动化测试，并且更加关注界面测试.

四个系统测试

系统测试（System Test）是将通过集成测试的软件部署到更复杂的计算机用户环境中进行测试. 这里提到的复杂的计算机用户环境实际上是模拟的用户真实计算机环境.

在大多数情况下，集成测试是在相对干净的系统中进行的. 所谓的干净，即测试机器上没有冗余软件，只有所需的操作系统和被测试的软件. 集成测试完成后，将被测试软件放在更复杂的操作环境中，以进行集成和确认测试. 在此过程中，通常会有很大的收获. 例如，在安装和测试时，您会发现在集成阶段安装没有问题，但是无法在复杂的用户环境中安装. 例如，一家公司开发了一种财务软件，该软件使用Excel 2000版本中的某些绘图控件. 在集成测试阶段，仅财务软件和Excel 2000安装在测试环境中，但是在系统测试过程中，测试环境可能为. 还安装了还需要调用Excel控件的其他软件. 此时，可能会发生控制资源争用错误.

系统测试的目的是将系统需求与系统定义进行比较，并找出软件需求与系统需求之间的矛盾之处. 系统测试阶段主要执行安装和卸载测试，兼容性测试，功能确认测试，性能测试，安全性测试等. 系统测试阶段使用黑盒测试方法，主要检查软件的功能和性能. 在测试中. 如果该软件可以按照用户的合理期望工作，则可以认为它已通过系统测试，相反，它似乎是缺陷. 图3显示了在系统测试阶段修改资产类别时无法正确读取注释信息的缺陷，这无法满足用户的期望.

图3: 系统测试备注读取错误缺陷的示例

系统测试过程实际上是一个配置检查过程. 检查软件生产过程中是否存在遗漏，并确保已填补泄漏，以确保交付的产品符合用户质量要求.

系统测试通常由独立的测试团队完成. 测试基础通常包括需求规范，需求用例，功能规范，功能需求列表，风险分析报告等，主要基于需求规范. 测试对象包括软件系统，用户手册，操作说明，系统配置和配置数据等.

五，验收测试

完成系统测试后，通常需要先进行验收测试，然后再交付给用户进行部署. 验收测试（Acceptance Test）是基于用户的测试. 接受小组应由项目团队成员，用户代表或系统的其他利益相关者组成. 原则上，它是在用户所在地进行的，但是如果用户同意，也可以在公司内部模拟用户环境.

验收测试根据合同，“需求规格表”或“验收测试计划”对成品进行验收测试. 在此阶段，发现缺陷不是其主要目的. 预期验收测试将使用户能够对要交付的应用程序的软件系统建立信心.

基于项目的软件系统通常需要接受测试. 验收测试通常可以具有Alpha测试，Beta测试，UAT测试和其他验收测试表格.

六. 阿尔法测试

Alpha测试是由用户在开发环境中进行的测试，也可以在开发组织内用户模拟的实际操作环境中进行测试. 在Alpha测试期间，该软件会在自然环境中使用. 开发人员坐在用户旁边，并随时记录错误情况和使用问题. Alpha测试是在受控测试环境中实施的. 其目的主要是评估软件产品的FLURPS（即功能，本地化，可用性，可靠性，性能和技术支持）.

七. Beta测试

Beta测试是由一个软件的多个用户在一个或多个用户的实际使用环境中进行的测试. 与Alpha测试不同，执行Beta测试时，开发人员通常不在测试现场. 因此，Beta测试是在开发人员无法控制的环境中进行的软件现场应用程序. 测试人员发现问题后，将其收集并提交给开发人员进行维修.

八，UAT测试

UAT测试（用户接受测试）是用户接受测试. 通常用于商业用户，以验证系统的可用性. 通常情况下，购买者组织最终用户或软件利益相关者对被测对象进行选择性的功能试验，同时关注被测对象核心功能的应用性能，为接受软件系统提供数据依据. 例如，当银行交付外包项目时，它会组织一些银行终端应用程序人员（例如柜台服务人员）进行验收测试，这称为UAT测试.

UAT模式测试的另一种可能性是根据法律法规和当前行业标准进行验收测试. 例如，政府机构购买的环境监控系统必须符合政府的管理要求和环境法规.

本文来自汇智电力金牌导师-鲍格

感兴趣的IT人员欢迎添加q: 2834267066交流

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/jisuanjixue/article-275477-1.html