软件测试理论学习

一、基础与概述

1.软件测试的定义

软件测试是软件开发过程中不可或缺的一环，它旨在通过执行一系列有计划、有组织的操作，来验证软件产品是否满足其需求规格说明书中的要求，并识别、报告和跟踪软件中的错误或缺陷。

2.软件测试的重要性

软件测试在软件开发过程中具有举足轻重的地位，主要体现在以下几个方面：

1. 确保软件质量：通过全面的测试，可以发现并修复软件中的错误和缺陷，从而提高软件的可靠性、稳定性和性能。这对于用户来说至关重要，因为高质量的软件能够提供更好的用户体验和更高的满意度。
2. 降低风险：在软件开发的早期阶段发现并修复缺陷，可以显著降低后期修复的成本和难度。这有助于避免在软件发布后出现重大问题，从而保护企业的声誉和利益。
3. 支持决策制定：测试结果为软件开发团队提供了宝贵的反馈，有助于他们了解软件的当前状态和未来发展方向。这有助于团队做出更加明智的决策，如调整开发计划、优化资源分配等。
4. 促进持续改进：通过测试活动，可以发现软件开发过程中存在的问题和不足之处。这有助于团队总结经验教训，不断改进开发流程和测试方法，提高软件开发的效率和质量。

3.软件测试的基本原则

为了确保软件测试的有效性和可靠性，需要遵循以下基本原则：

1. 独立性：测试活动应独立于开发活动进行，以确保测试的客观性和公正性。测试人员应独立于开发团队之外，以避免潜在的偏见和利益冲突。
2. 可追溯性：测试用例应能够追溯到需求规格说明书中的具体需求，以确保测试活动的完整性和准确性。这有助于验证软件是否满足所有需求要求。
3. 可重复性：测试活动应能够重复进行，以便在不同的时间点和不同的环境下验证软件的一致性和稳定性。这要求测试过程具有可重复性和可控制性。
4. 完整性：测试应覆盖软件的所有重要方面和关键功能，以确保测试的全面性和完整性。这要求测试团队具备全面的测试技能和知识，能够设计并执行有效的测试用例。

综上所述，软件测试作为软件开发过程中的重要组成部分，其定义、重要性和基本原则对于确保软件质量、降低风险、支持决策制定以及促进持续改进具有至关重要的作用。

4.软件测试的目的

软件测试的目的对软件进行质量评估，给出建议。测试人员通过模拟用户使用场景，对软件进行各种操作，以发现潜在的问题和错误。

二测试策略与规划

1.软件测试策略

软件测试策略是指测试团队为达到测试目标而采取的一系列方法和技术。这些策略旨在确保测试的有效性和高效性，从而满足软件项目的质量和时间要求。

在制定软件测试策略之前，我们先要明确测试目标、确定产品质量目标、划分测试阶段、确定测试方法、制定详细的测试计划、并考虑到测试人员、测试工具、测试环境等资源的影响。

1.1 明确测试目标

1. 测试要解决的问题：详细列出当前软件产品存在的已知问题或潜在风险。
2. 验证的功能点：明确所有需要验证的软件功能点，包括正常操作和异常处理。
3. 性能要求：设定具体的性能指标，如响应时间、吞吐量、并发用户数等，并定义可接受范围。

1.2 确定产品质量目标

1. 需求覆盖度：设定需求覆盖率的最低标准（如95%以上）。
2. 测试用例执行度：确保所有测试用例至少执行一次，并跟踪未执行或未通过用例的处理情况。
3. 安全测试：明确安全测试的范围和漏洞容忍度。
4. 性能测试：定义性能测试的场景、负载模型和评估标准。
5. 代码规范：制定代码审查标准，确保代码质量。
6. Bug修复率：设定Bug修复率的目标，并跟踪修复进度。

1.3 明确划分测试阶段

软件测试类型按开发阶段分为单元测试，集成测试，确认测试，系统测试，验收测试。

1. 单元测试又称为模块测试，是针对软件设计的最小单位——程序模块进行正确性检查的测试工作，单元测试需要从程序内部结构出发设计测试用例，多个模块可以平行地独立进行单元测试。
2. 集成测试 又称为 组装测试 或 联合测试，在单元测试的基础上需要将所有模块按照概要设计说明书和详细设计说明书的要求进行组装。
3. 确认测试 的目标是验证软件的功能和性能以及其他特性是否与用户的要求一致。确认测试一般包括有效性测试和软件配置复查。一般由第三方测试机构进行。
4. 系统测试：软件作为计算机系统的一部分，与硬件、网络、外设、支撑软件、数据以及人员结合在一起，在实际或模拟环境下，对计算机系统进行测试，目的在于与系统需求比较，发现问题。
5. 验收测试：以用户为主的测试，软件开发人员和质量保证人员参加，由用户设计测试用例。不是对系统进行全覆盖测试，而是对核心业务流程进行测试。

1.4 明确测试计划安排

（1）时间安排

1. 遵守趋势收敛原则：测试计划时间安排上应遵守趋势收敛的原则，即越到后面，测试周期越短，问题应该越少。
2. 分阶段测试：根据项目规模和复杂度，将测试工作划分为不同的阶段，如单元测试、集成测试、系统测试和验收测试等。每个阶段应有明确的起止时间和测试目标。
3. 测试轮次安排：对于大型项目，测试可能需要分为多轮进行。每轮测试应有明确的测试范围和重点，并遵循“全面覆盖、逐步深入”的原则。例如，可以采用“3+1”模式（三轮详细测试+一轮回归测试）或“2+1”模式（两轮详细测试+一轮回归测试），具体轮次和时间分配根据项目需求确定。
4. 预留缓冲时间：在制定测试计划时，应预留一定的缓冲时间以应对可能出现的延期、缺陷修复等问题。

（2）资源分配

1. 测试环境资源：根据测试需求搭建相应的测试环境，包括硬件资源、软件资源（如操作系统、数据库、中间件等）和网络资源。确保测试环境与生产环境尽可能一致，以提高测试结果的准确性和可靠性。
2. 测试工具资源：选择合适的测试工具，如自动化测试工具、性能测试工具、缺陷跟踪系统等，并对其进行必要的配置和培训。确保测试团队能够熟练使用这些工具以提高测试效率和质量。

2.软件测试方法

2.1 静态测试与动态测试

（1）静态测试：在软件代码不运行的情况下，通过检查和分析代码、文档等，发现潜在的错误和缺陷。这包括代码审查、静态代码分析等。

测试类型	适用场景	优点	缺点
静态测试	代码审查 需求分析 设计审查 代码风格检查	能在代码执行前发现问题；提高代码质量和可维护性；覆盖所有代码路径	无法发现运行时错误；需要测试人员具备较高的编程和代码审查能力；可能无法识别所有潜在问题
动态测试	功能测试 性能测试 稳定性测试 负载测试	能在实际运行环境中测试软件；发现运行时错误和性能问题；可结合多种测试方法（黑盒、白盒、灰盒）	测试覆盖率可能受限；需要准备测试环境和数据；可能需要复杂的测试场景设计

（2）动态测试：通过运行软件来测试其功能、性能和稳定性。动态测试包括单元测试、集成测试、系统测试和验收测试等。

2.2 白盒测试、黑盒测试、灰盒测试

（1）白盒测试（又称结构测试）：测试人员全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。其测试方法有代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、域测试、符号测试、路径覆盖和程序变异；覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。

（2）黑盒测试（又称功能测试）：该类测试注重于测试软件的功能性需求，能更好、更真实地从用户角度来考察被测系统的功能性需求实现情况。在软件测试的各个阶段，如 单元测试、集成测试、系统测试及验收测试 等阶段中，黑盒测试都发挥着重要作用，尤其在系统测试和确认测试中，其作用是其他测试方法无法取代的。

（3）灰盒测试：灰盒测试是介于黑盒测试和白盒测试之间的一种测试方法。测试人员既了解软件的部分内部结构和实现细节，又关注软件的外部行为和功能。灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。灰盒测试不像白盒那样详细、完整，但又比黑盒测试更关注程序的内部逻辑，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。

测试类型	适用场景	优点	缺点
黑盒测试	功能验证 用户界面测试  兼容性测试	不需要了解内部实现；模拟用户实际使用场景；易于理解和设计测试用例	可能无法发现内部逻辑错误；测试覆盖率有限（除非大量测试用例）
白盒测试	单元测试 集成测试 代码路径覆盖	高代码覆盖率；易于定位问题；提高代码质量和可靠性	实施难度大，需要编程能力   成本高，需要更多时间和资源；可能忽略外部行为
灰盒测试	集成测试 系统测试 特定功能验证	结合黑盒和白盒的优点；平衡内部逻辑和外部行为；提高测试效率	平衡点难把握；可能过度依赖内部信息；需要一定的经验和技巧

2.3 自动化测试与手工测试

（1）自动化测试：利用自动化测试工具来执行测试用例，提高测试效率和准确性。自动化测试适用于重复性强、易于自动化的测试场景。

（2）手工测试：由测试人员手动执行测试用例，适用于复杂度高、难以自动化的测试场景。

测试类型	适用场景	优点	缺点
自动化测试	回归测试 性能测试 负载测试 持续集成/持续部署	提高测试效率和一致性；减少重复劳动；模拟复杂测试场景	维护成本高，需要更新测试用例；难以覆盖所有场景（如用户交互）；需要测试团队具备编程能力
手工测试	探索性测试 业务流程测 用户体验测试	灵活性和直觉性；发现边界情况和潜在问题；前期投入成本低	测试效率和一致性可能受限；难以进行长时间或大规模测试；测试结果判定可能依赖个人经验

3.测试策略与计划的实施

3.1 测试过程

1. 需求分析：理解需求，确定测试范围和重点。
2. 制定测试计划：明确测试目标、资源、进度等。
3. 设计测试用例：根据需求和测试类型设计合理的测试用例。
4. 执行测试：按照测试计划执行测试，记录结果并跟踪缺陷。
5. 缺陷管理：对缺陷进行跟踪、验证、修复和回归测试。
6. 测试总结：评估测试效果，编写测试报告。

3.2 测试策略与计划时需要遵循的原则

1. 尽早且全程参与：测试活动应从项目初期就开始，这样做可以更早地发现并纠正问题。同时，测试应贯穿整个软件开发周期，确保每个阶段的质量。
2. 独立性原则：测试团队应保持独立，避免与开发团队有直接的利益关系。
3. 全面性与深度：测试应覆盖软件的所有功能和特性，以确保没有遗漏。同时，测试还需具有深度，不仅要验证软件是否按照预期工作，还要检查它是否正确地处理了边界条件和异常情况。
4. 风险管理：在测试过程中，应识别并评估可能影响项目成功的风险，并制定相应的风险缓解策略。
5. 回归测试：每当软件发生变更时（如修复bug、添加新功能），都需要进行回归测试，保持软件的稳定性和可靠性。
6. 强化文档记录：测试过程中产生的所有文档（如测试用例、测试报告等）都应妥善保存和管理。这些文档不仅是测试结果的记录，也是后续维护和改进的重要依据。
7. 加强团队协作与沟通：有效的沟通可以减少误解和冲突，提高团队的整体效率。
8. 持续优化测试策略与流程：随着项目的进展和经验的积累，测试团队应不断回顾和评估测试策略与流程的有效性，并根据需要进行调整和优化。

三、测试设计与实施

1.良好测试用例的设计要求

（1）测试用例必须简单透明：

创建尽可能简单的测试用例。它们必须清晰明了，因为测试用例的作者可能不会执行它们。使用自信的语言，例如转到主页，输入数据，单击此按钮，依此类推。这使理解测试步骤变得容易，并且测试执行速度更快。

（2）与最终用户一起创建测试用例

任何软件项目的最终目标都是创建满足客户要求并且易于使用和操作的测试用例。测试人员必须创建测试用例，并牢记最终用户的观点

（3）避免重复测试用例

不要重复测试用例。如果需要一个测试用例来执行其他测试用例，请在前提条件栏中通过其测试用例ID调用该测试用例。

（4）不确定性

准备测试用例时，请勿假定你的软件应用程序具有某功能。

（5）确保覆盖率100％

确保编写测试用例以检查规范文档中提到的所有软件要求。使用可追溯性矩阵来确保没有任何功能/条件未经测试。

（6）测试用例必须是可识别的

命名测试用例ID，以便在跟踪缺陷或在以后识别软件需求时容易识别它们。

（7）实施测试技术

无法检查软件应用程序中的所有可能条件。软件测试技术可帮助您选择一些测试案例，以最大可能地发现缺陷。

（8）自清理

创建的测试用例必须使测试环境返回到测试前状态，并且保证测试环境可用。对于配置测试尤其如此。

（9）可重复和独立

无论由谁进行测试，测试用例每次都应产生相同的结果

（10）同行评审

创建测试用例后，请他们的同事对其进行审查。你的同事可以发现你的测试用例设计中的缺陷，而你可能很容易错过这些缺陷。

2.测试用例设计方法

2.1 等价类划分

把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。

1. 有效等价类：满足输入数据要求的类
2. 无效等价类：不满足输入数据要求的类

设计测试用例时，要同时考虑这两种等价类。因为软件不仅要能接收合理的数据，也要能经受意外的考验，这样的测试才能确保软件具有更高的可靠性。

示例：例如qq密码要求设置的位数在6-16位，那么可以将输入的数据划分成如下几个类：

Ps：根据等价类测试的不同策略，可以进一步细分为弱一般等价类测试和强一般等价类测试。弱一般等价类是基于单缺陷假设，即假设程序在每次执行时最多只会出现一个错误，而强一般等价类是基于多缺陷假设，不仅考虑了有效输入，还考虑了无效值的情况，即假设程序在执行时可能同时出现多个错误。

2.2 边界值分析

边界值分析法就是对输入或输出的边界值进行测试的一种方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。

常见的边界值：

1)对16-bit 的整数而言 32767 和 -32768 是边界

2)屏幕上光标在最左上、最右下位置

3)报表的第一行和最后一行

4)数组元素的第一个和最后一个

5)循环的第 0 次、第 1 次和倒数第2 次、最后一次

通常情况下，软件测试所包含的边界检验有几种类型：数字、字符、位置、重量、大小、速度、方位、尺寸、空间等。相应地，其边界值应该在：最大/最小、首位/末位、上/下、最快/最慢、最高/最低、最短/最长、空/满等情况下。

2.3 因果图法（判定表法）

指根据输入输出之间的对应关系设计测试用例的方法。

举个例子：产品说明书：有一个处理单价为1元5角钱的盒装饮料的自动售货机软件。若投入1元5角硬币，按下“可乐”、“雪碧”、或“红茶”按钮，相应的饮料就送出来。若投入的是2元硬币，在送出饮料的同时退还5角硬币。用因果图法设计测试用例如下图所示：

因果图设计测试用例步骤：充分理解需求；分析可能的输入、输出；将输入、输出用判定表表示；判定表每一行数据对应到一个测试用例。

2.4 正交表法

因果法实际用例太多，交正法的目的是为了减少用例数目。它是根据正交性，由试验因素的全部水平组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析了 解全面试验的情况，找出最优的水平组合。正交试验设计是一种基于正交表的、高效率、快速、经济的试验。

正交表的两条性质：

1. 每一列中各数字出现的次数都一样多。
2. 任何两列中的各有序数对出现的次数都一样多。

根据正交表设计测试用例的步骤：①充分理解需求；②确定因素，确定水平；③画正交表；④补充正交表；⑤将正交表转换成测试用例。（可以通过allpairs来设计正交表）

以用户注册的需求为例：姓名、邮箱、密码、确认密码、验证码必须全部输入才能进行注册。因素：姓名、邮箱、密码、确认密码、验证码。水平：填写/不填写。

2.5 场景设计法

现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。

根据场景设计法设计测试用例步骤：①确定主事件流；②确定次事件流；③将这些事件转换成测试用例（一个场景对应一个测试用例）。

1. 主事件流：用户经常操作的场景（比如，通过美团点外卖）。
2. 次事件流：基于主事件流（比如，在点外卖时手机没电了）。

以ATM机取款的需求为例，主事件流和基于主事件流的次事件流如下图：

编号	测试项	操作步骤	预期结果
1	成功取款	插卡； 输入正确密码； 选择业务（取款）； 输入取款金额； 成功取款； 取卡	...
2	插卡失败	插卡；
3	密码输入错误
4	...

2.6 错误猜测法

针对经验和直觉来判断软件可能存在的缺陷。

以注册为例：校验中特殊字符空格的处理?密码校验中的大小写？

姓名中的特殊字符？密码发送是否明文？

2.7 方法对比

测试方法	适用场景	优点	缺点
等价类划分	输入条件多，且部分输入条件对程序影响相同或类似。	提高测试效率，减少冗余测试。覆盖输入域的等价类，保证测试的全面性。	可能忽略边界情况，需结合边界值分析。复杂输入条件的等价类划分可能耗时。
边界值分析	输入域有明确边界，边界值往往是程序出错的高发区。	专注于边界值测试，有效发现边界错误。提供更精细的测试覆盖。	可能忽略非边界值的重要输入情况。需与其他方法结合使用以确保全面覆盖。
因果图法（判定表法）	输入条件之间存在复杂的逻辑关系。	清晰表示输入条件间的逻辑关系。自动生成测试用例，减少部分设计工作。	简单场景可能过于复杂，导致资源浪费。输入条件多时，测试用例数量可能庞大。
正交表法	多个输入参数，每个参数有多个取值，需测试参数组合。	少量测试用例覆盖多参数组合，提高测试效率。平衡测试覆盖率和成本。	可能无法覆盖所有参数组合，需补充额外测试。设计合理的正交表需要一定技巧和经验。
场景设计法	测试系统业务流程或用户场景。	从用户或业务角度设计测试用例，贴近实际需求。覆盖多个业务流程和用户场景，提高测试全面性。	可能忽略非主要业务流程的测试。复杂业务流程设计测试用例耗时较长。
错误猜测法	无明确测试标准或规范，依赖经验和直觉。	发现常规方法难以发现的错误或缺陷。依赖经验和直觉，可能发现未知问题。	主观性强，受测试人员经验和知识水平限制。可能无法全面覆盖系统功能和场景。

3.测试类型

1. 功能测试：检查软件是否满足需求规格，包括正常情况和异常情况。
2. 性能测试：评估软件的性能指标，如响应时间、吞吐量等。
3. 安全性测试：检查软件是否能够抵御恶意攻击，保护数据安全。
4. 兼容性测试：验证软件在不同平台、浏览器、操作系统等环境下是否能够正常工作。
5. 用户界面测试：评估软件的易用性和用户体验，包括布局、导航、可读性等。
6. 安装与卸载测试：确保软件的安装和卸载过程简单、稳定。
7. 回归测试：在修复缺陷后，验证修改是否引入新的问题。
8. 压力测试：模拟高负载情况，检查软件的稳定性和性能瓶颈。

四、测试环境管理

正常的软件研发交付流程中要经过的环境如下：

1. 本地环境（host）：开发在自己电脑或本地服务器进行需求开发的环境，只要自己负责的部分能实现既定功能即可；
2. 开发环境（dev）：开发同学将自己本地实现的代码统一发布进行功能联调的环境，一般单元测试也在这个环境进行；
3. 测试环境（sit）：绝大多数测试活动开展的环境，在这个环境开展接口/功能/性能/自动化等一系列测试活动，对代码功能实现/异常处理/构建成功率/是否存在性能瓶颈进行测试验证；
4. 验收环境（uat）：将通过测试的代码发布，让产品介入进行验收，确认是否满足其预期的环境；
5. 预发环境（ppe/ade）：也有称之为灰度环境的，简单来说就是将测试验收通过的代码发布到该环境，运行一段时间并做持续的跟进观察，是否存在其他问题或者遗漏项（也有通过技术手段让小部分用户的请求路由到该环境，进行验证）；
6. 生产环境（prd/prod）：所谓的线上环境，即用户使用的环境。

上述的所有环境，基本都要遵循如下几点规范：

1. 网络隔离：即请求不能跨环境访问，特别是非生产和生产环境；
2. 数据隔离：即不同环境都要有自己独立的数据源，原则上不能共享同一份数据源；
3. 流转卡点：代码发布到下一个环境节点，原则上都要满足流转的状态或者标准，不能随意发布；
4. 其他事项：如果某个环境有多套，建议共享数据源，这样维护和变更成本低。

同时，还需要注意环境监控与恢复

1. 实时监控：利用监控工具对测试环境进行性能、状态和安全的实时监控，设置告警机制以快速响应问题。
2. 恢复机制：测试结束后，通过自动化工具或脚本快速恢复环境至初始状态，定期验证恢复流程的有效性。

五、测试自动化与工具

1.APP功能自动化测试

使用框架：Pycharm+python+appium+android sdk+夜神模拟器

主要要学的内容：元素定位，模拟点击、滑动页面，捕获toast，截图对比等。

2.接口自动化测试

接口测试的原理就是模拟客户端向服务器发送请求，服务器接收请求报文后对相应的报文做处理并向客户端返回应答，客户端接收应答的过程。

2.1 接口测试点及用例设计方法

接口测试采用的方法其实与黑盒测试一致的，甚至可以把接口测试理解为没有界面的功能测试。只不过接口测试的关注点主要在请求和响应上。另外，还包括接口的安全，接口的性能等。常用的用例设计有等价类，边界值法等。

一般测试用例的设计要从单接口参数的校验到整个业务功能点的验证，还可以验证一些安全性和异常情况。

2.2 HTTP基础知识

DNS：Domain Name Server 域名服务器

http:// www.baidu.com: 80/ adv_search? w=py&order=false# tag

HTTP报文格式分为两种：

1. 请求报文：请求行，请求头部，回车换行，消息体
2. 响应报文：状态行，响应头部，回车换行，消息体

HTTP由请求和响应构成，是一个标准的客户端服务器模型（B/S架构）。HTTP协议永远都是客户端发起请求，服务器回送响应。

HTTP请求组成部分：URL地址，请求参数（可选），请求头，请求体（仅限POST请求）；对于响应内容部分，主要关注两个点：响应状态码，响应内容。

HTTP常见状态码：

HTTP工作过程：

1. 浏览器输入；
2. dns域名解析：域名与IP映射（第一次访问去DNS找对应IP，不是第一次访问则本机存有IP）；
3. 建立tcp连接（三次握手）；
4. 发送http request：请求信息；
5. web服务器接收请求；
6. 应用服务器处理业务逻辑；
7. 关闭tcp连接：请求响应完成。如果浏览器在其头部信息中加入了connection:keep-alive，则tcp连接将任然保持打开状态；
8. 浏览器：渲染响应页面。

2.3 接口测试工具

Jmeter；Apifox；postman。

六、测试报告与评估

1.测试报告的编写目的

测试报告是完成测试工作之后，测试人员交出的一份总结性汇报文档，这既是对测试工作的一个总结，也是对测试对象的一个评估。在企业中测试报告一般是给所有与这个项目有关的人看的，包括项目领导，产品，运营，前后端开发等等，甚至是销售人员，所以这一份报告要给这么多不同岗位的人提供他们想要的信息，那就需要有逻辑。

2.测试报告的内容

2.1 工作内容

首先，这份报告应该体现工作内容，包括但不限于：

1. 功能测试：系统全部功能的走查/验证/回归，系统设计规格书内的功能是否全部实现，是否正常操作产生了异常预期
2. 性能测试：系统整体性能的验证，在平时工作时，CPU和MEM的剩余；在极限场景下，系统的剩余性能，能否稳定工作
3. 压力测试：一般考察7*24h下，系统的稳定情况，微信可否连续聊天，抖音能否持续推送视频，连续登录10000次账号成功率是否高于99.9999%
4. 安全测试：这里就要考虑系统的各种安全情况，例如SQL注入，网络攻击等
5. UI测试：这要求测试人员以一个真实用户的角度，去考虑这一功能的呈现，该有的弹框是不是都有，图标设计的是不是对称，某一功能的路径会不会太深
6. 兼容性测试：这就包括多种兼容性，软件兼容性比如新旧版本的游戏能否互通，硬件兼容性比如市面常见的手机电脑能否支持该软件的平稳运行，甚至于蓝牙耳机鼠标等各种外设
7. 数据一致性测试：这种数据一致性体现在各个方面，SQL查询结果是否正确，返回值是否正常，网络数据传输前后是否完全一致
8. 可靠性测试/异常测试：一般都考虑各种异常情况下的系统反馈，比如系统剩余空间不足5%检查软件能否正常运行，弱网丢包率高于50%语音通话的质量能否接受，读写过程中插拔外设是否对原始数据有损坏

2.2 软件结果

告诉大家经过测试工作，软件质量到了一个什么样的地步？【例如】

（1）当前软件版本质量：高

各项功能均已正确实现，系统经过7*24小时无任何稳定性问题，复合准出标准，予以准出！

（2）当前软件版本质量：中

各项功能基本实现，系统经过7*24小时存在稳定性问题，遗留问题主要分为3类：第一，第二，第三，问题出现后系统可自动恢复，带风险准出！

（3）当前软件版本质量：低

各项功能基本实现，仍存在遗留问题，系统经过7*24小时仍存在稳定性问题，包括内存泄漏等严重问题，不予准出！

不同的测试结果有不同的应对方式！

2.3 体现价值

虽然这叫一份测试报告，但是有些软件庞大，光功能点就动辄成百上千，大的模块都有十几个，一个人是测不完的，对于整个项目，可能分为不同的测试小组，在编写测试报告时，所有的进展都要在这里汇总，因为这一份测试报告就是整个项目的出口，而不是一个人工作的呈现。

2.4 测试报告的结构（依团队写法写）

举例：先总后分的写法

（1）首先呈现结论

直接给出当前软件结论，问题影响多大、是否影响用户使用、是否能够发布等。

（2）当前遗留问题&排期

任何系统都一定会存在各种各样的bug，大到内存泄漏，小到token提示信息缺失。

原则上有严重问题其实是不能发版的，但是如果不影响用户使用或者有应对措施就可以。比如CSDN客户端会crash，但是前提是需要连续刷24h，这样的客户场景一般难以遇到；比如CSDN在多后台情况下打开就闪退，那么可以弹窗提示客户手动清理后台后再次尝试打开。

所有的严重问题必须在下一个版本完成迭代，剩余遗留问题给出排期。

对于一些普通问题或者提示性问题，虽然不严重，但它是问题就得解决，必须得给出排期，并且精确到责任人，比如这么几类情况

这个问题可能对用户影响更大，下个版本必须解；

这个问题有点难解，第二个版本再排期；

这个问题现在连头绪都没有，长期跟踪；

（3）软件版本&算法/组件版本

这里一定要写清楚所有的软件版本，方便以后问题的迭代和回溯，比如像下面这样：

当前软件版本号V1.2.3

推荐算法模型为recommend_20220407_1305_alpha

当前软件MD5值为23gk2hf2v3uf2y3g23guy

软件包升级下载链接为https:test0407/download/test.apk

以此类推……

（4）全业务回归情况

这里要写出系统测试情况，做了什么测试，覆盖了多少轮，一个是体现你的工作情况，另一个反馈完整的软件质量，比如：

功能测试：ALL：100，PASS：96，FAIL：4，BLOCK：0，通过率96%

性能测试：ALL：100，PASS：81，FAIL：9，BLOCK：10，通过率90%（BLOCK不能算在已执行里面，这里是81/90）

以此类推……

Ps：从测试BUG图、BUG优先级、测试类型、BUG模块分布图、最近提交的缺陷图、BUG状态分布方面呈现，度量方法如：资源消耗、缺陷密度、测试覆盖率、执行率、执行通过率、缺陷解决率。

（5）各类专项进展&竞品分析

还是上面说过的其他团队的进展，或者你这产品的卖点，做一个专项，要有评测和竞品分析。虽然这两项往往都是合在一起的，但是这里分开举例，比如自动编辑博文专项：

对于百字文章，成功率高达100%，对于错别字的识别，成功率高达99.86%；

对于千字文章，成功率高达97.03%，对于错别字的识别，成功率高达96.28%；

对于万字文章，成功率不低于80%，对于错别字的识别，成功率不低于75%；

再比如发帖耗时的竞品分析：

发帖耗时这一方面，在各量级的文章下都优于友商不知网：

优势是发帖耗时更低，只需要183ms，速度领先35.76%；

劣势是弱网下发帖的成功率太低，仅27.30%，同样网络下低于不知网的49.72%；

能画图表的就画图表，问题清单或者问题描述也可以用xmind的形式绘制出来，该复杂的地方就复杂，该简单的时候就简单，详略得当。

七、项目管理

团队组建：根据项目需求组建测试团队，明确各成员角色和职责。

技能提升：通过培训和学习提升团队成员的测试技能和知识水平。

沟通与协作：建立有效的沟通机制，促进测试团队与开发团队、产品团队等其他团队成员之间的协作和配合。

测试文化：培育积极的测试文化，鼓励团队成员主动发现问题、提出改进意见。