软件测试复习

第一章

1 软件测试学科的发展

1957～1978年，以功能验证为导向，测试是证明软件是正确的（正向思维）。
1978～1983年，以破坏性检测为导向，测试是为了找到软件中的错误（逆向思维）。
1983～1987年，以质量评估为导向，测试是提供产品的评估和质量度量。
1988年起，以缺陷预防为导向，测试是为了展示软件符合设计要求，发现缺陷、预防缺陷。

2 正向测试与反向测试的定义，关系

Bill Hetzel博士（正向思维的代表）：

  • 软件测试就是为程序或系统能够按预期设想运行而建立信心的过程。
  • 软件测试是一系列活动以评价一个程序或系统的特性或能力并确定是否达到预期的结果
  • 测试是为了验证软件是否符合用户需求，即验证软件产品是否能正常工作

Glenford J. Myers （反向思维的代表）：

  • 测试是为了证明程序有错，而不是证明程序无错误
  • 一个好的测试用例是在于它能发现至今未发现的错误
  • 一个成功的测试是发现了至今未发现的错误的测试

3 从经济视角认知软件测试

测试的经济观点就是以最小的代价获得最高的软件产品质量。经济观点也要求软件测试尽早开展工作，发现缺陷越早，返工的工作量就越小，所造成的损失就越小。测试的成本< 缺陷造成的损失，测试才有意义。

4 SQA，与软件测试关系

联系

SQA指导、监督软件测试的计划和执行，督促测试工作的结果客观、准确和有效，并协助测试流程的改进。
软件测试是SQA重要手段之一，为SQA提供所需的数据，作为质量评价的客观依据。

区别

SQA是一项管理工作，侧重于对流程的评审和监控
测试是一项技术性的工作，侧重对产品进行评估和验证

第二章

1 缺陷定义，现象，判定准则

定义

任何程序、系统中的问题，如与产品设计书的不一致性、不能满足用户的需求

现象

功能、特性没有实现或部分实现

设计不合理，存在缺陷

实际结果和预期结果不一致

运行出错，包括运行中断、系统崩溃、界面混乱

数据结果不正确、精度不够

用户不能接受的其他问题，如存取时间过长、界面不美观

判定准则

1)需求规格说明书和其它需求、设计规范文档

2)竞争对手的产品

3)启发式测试预言（Heuristic oracle）

4)统计测试预言（Statistical oracle）

5)一致性测试预言（Consistency oracle）

6)基于模型的测试预言（Model-based oracle）

7)人类预言（Human oracle）

2 软件缺陷产生的原因有哪？

  1. 技术问题

    算法错误、计算和精度问题

    接口参数传递不匹配

  2. 团队工作

    沟通不充分，误解

  3. 软件本身

    文档错误、用户使用场合(user scenario)，

    时间上不协调、或不一致性所带来的问题

    系统的自我恢复或数据的异地备份、灾难性恢复等问题

3 产品质量的内容，内部，外部，使用质量

产品质量是人们实践产物的属性和行为，是可以认识，可以科学地描述的，并且可以通过一些方法和人类活动，来改进质量。

4 如何理解软件规格说明书缺陷

软件规格说明书（也称为需求规格说明书或功能需求说明书）是软件开发过程中的关键文档，它详细描述了软件的功能、性能、接口和其他属性。理解软件规格说明书中的缺陷对于确保软件质量至关重要。以下是如何理解软件规格说明书缺陷的几个方面：

  1. 不完整性
    • 如果规格说明书没有涵盖所有必要的需求，或者遗漏了关键的用户故事、场景或业务流程，那么它就是不完整的。
    • 缺陷可能表现为遗漏了某些功能、性能要求、安全要求或用户交互。
  2. 模糊性或歧义性
    • 如果规格说明书的描述含糊不清或存在歧义，那么开发人员可能会对其产生不同的解释，导致不一致的实现。
    • 缺陷可能表现为使用不明确的术语、缺少上下文或缺少必要的图表、模型或示例。
  3. 不一致性
    • 如果规格说明书内部存在矛盾或与其他相关文档（如用户手册、设计文档等）不一致，那么它就是不一致的。
    • 缺陷可能表现为功能描述之间的冲突、数据格式的不匹配或与其他系统接口的不兼容。
  4. 不可验证性
    • 如果规格说明书中的需求无法通过测试或其他验证手段来确认是否满足，那么它就是不可验证的。
    • 缺陷可能表现为缺乏明确的验收标准、测试用例或性能度量指标。
  5. 非功能性需求缺陷
    • 规格说明书通常不仅包含功能性需求，还包含非功能性需求，如性能、安全性、易用性、可维护性等。
    • 如果这些非功能性需求描述不足或遗漏，则可能导致软件在某些方面不满足用户期望或行业标准。
  6. 忽略用户反馈或市场需求
    • 如果规格说明书没有充分考虑用户反馈或市场需求的变化，那么它可能无法反映用户的真实需求或市场的最新趋势。
    • 缺陷可能表现为过时的功能、忽视用户痛点或无法满足新兴市场需求。
  7. 技术可行性问题
    • 如果规格说明书中的需求在技术上无法实现或实现成本过高，那么它可能存在技术可行性问题。
    • 缺陷可能表现为对技术栈的误解、不切实际的性能要求或过于复杂的业务流程。

5 verification,validation

软件测试是由“验证（Verification）”和“有效性确认（Validation）”活动构成的整体

Verification： Are we building the product right？是否正确地构造了软件？即是否正确地做事，验证开发过程是否遵守已定义好的内容。验证产品满足规格设计说明书的一致性

Validation： Are we building the right product? 是否构造了正是用户所需要的软件？即是否正在做正确的事。验证产品所实现的功能是否满足用户的需求

6 软件测试不同层次测试的对象和任务

7 静态测试的内容包括什么？开展相关活动时采用的形式有哪些？

静态测试包括对软件产品的需求和设计文档、代码的评审（技术评审、文档评审等），以及对代码的静态分析等。

管理评审、流程评审不属于静态测试，而是属于质量保证（QA）；

评审的主要形式：互为评审 (Peer review)、走查 (walk-through)、会议评审 (Inspection)；

代码的静态分析主要采用工具进行，但人工的代码评审也不可或缺。

8 测试工作的流程

9 软件测试的工作范畴

测试需求分析、测试策略指定、测试计划、测试设计、测试执行、测试结果和过程评估

第三章

1 等价类

  • 等价类是某个输入域的子集，在该子集中每个输入数据的作用是等效的.
  • 将输入数据分成若干个等价类，从每个等价类选取一个代表性的数据作为测试用例
  • 等价类分为有效等价类（合理的数据）和无效等价类（异常的数据）

2 边界值法

  • 很多错误发生在输入或输出范围的边界上，因此针对各种边界情况设置测试用例，可以更有效地发现缺陷。

  • 设计方法：

    确定边界情况（输入或输出等价类的边界）

    选取正好等于、刚刚大于或小于边界值作为测试数据

3 决策表（判定表），因果图法

  • 在实际应用中，许多输入是由多个因素构成，而不是单一因素，这时就需要多因素组合分析。
  • 对于多因素，有时可以直接对输入条件（成立或不成立）进行组合设计，不需要进行因果分析，这时就采用判定表方法。
  • 决策表由“条件和活动”两部分组成，即列出一个测试活动执行所需的条件组合，所有可能的条件（输入）组合定义了一系列的选择，而测试活动（结果输出）需要考虑每一个选择。

  • 因果图针对更为复杂的“多种输入条件、产生多种结果”设计组合测试用例。

  • 设计方法：

    分析软件Spec描述的哪些是原因（输入条件）、哪些是结果（输出），给每个原因和结果赋予一个标示符。

    找出原因与结果、原因与原因之间的对应关系，画出因果图

    在因果图上标上哪些不可能发生的因果关系，表明约束或限制条件

    根据因果图，创建（转化为）判定表，将复杂的逻辑关系转化为简单的组合矩阵

    把判定表的每一列转化为测试用例。

4 各种逻辑覆盖法

1.语句覆盖

设计若干测试用例，运行被测程序，使程序中的每个可执行语句至少被执行一次

2.判定覆盖

判定覆盖：设计若干用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次，即判断真假值均曾被满足。一个判定代表着程序的一个分支，所以判定覆盖也被称为分支覆盖。

3.条件覆盖

4.判定/条件覆盖

5.条件组合覆盖

6.MC/DC覆盖

5 路径覆盖法

  1. 依据代码绘制流程图
  2. 确定流程图的圈复杂度（cyclomatic complexity ）
  3. 确定线性独立路径的基本集合( basis set )
  4. 设计测试用例覆盖每条基本路径

6 功能图法，EFMS

  • 每个程序的功能通常由静态说明和动态说明组成

    静态说明描述了输入条件和输出条件之间的对应关系

    动态说明描述了输入数据的次序或者转移的次序

  • 功能图法就是为了解决动态说明问题的一种测试用例的设计方法

  • 功能图由状态迁移图（state transition diagram，STD）和逻辑功能模型（logic function model， LFM）构成

有限状态机（ Finite State Machine ，FSM）是对象行为建模的工具，以描述对象在其生命周期内所经历的状态序列，以及如何响应来自外界的各种事件。

第四章

1 测试左移和右移，贯穿全生命周期的测试思想

  • 软件测试贯穿全生命周期
  • 测试左移：不仅让开发人员做更多的测试，而且需要做需求评审、设计评审，以及第1章介绍的验收测试驱动开发（ATDD）；
  • 测试右移：是在线测试（Test in Production，TiP），包括在线性能监控与分析、A/B测试和日志分析等，可以和现在流行的DevOp联系起来。

2 w模型

3 TMAP定义，几个阶段，模型基石及关系

TMap (Test Management Approach，测试管理方法)是一种结构化的、基于风险策略的测试方法体系, 目的能更早地发现缺陷，以最小的成本、有效地、彻底地完成测试任务，以减少软件发布后的支持成本。

TMap所定义的测试生命周期由计划和控制、准备、说明、执行和完成等阶段组成

4 SBTM基本要素，结果，原理

要素：session、mission。charter

  • Session(会话)是一段不受打扰的测试时间（通常是90分钟），是测试管理的最小单元。
  • 每个session关联一个特定的、目标明确的测试任务（mission）
  • Charter (章程，即测试指导) ：对每个session如何执行进行简要的描述，相当于每个session需要一个简要的计划（提纲）
  • 一系列Session相互支持，有机地组合在一起，周密地测试了整个产品。

结果：

  • A session sheet (测试报告) ： 相当于测试报告，供第三方（如测试经理、ScrumMaster等）进行检查的材料。它最好能被工具扫描、解析和合成。
  • Debriefing（听取口头报告）：口头汇报，更准确地说，是测试人和其lead/Manager之间的对话。

5 测试几个学派的特点

①分析流派：认为测试是严格的和技术性的，在学术界有许多支持者

②标准流派：将测试视为衡量进度的一种方法，强调成本和可重复的标准

③质量流派：强调过程规范性，监督开发人员并充当质量的看门人

④上下文驱动流派：强调人的价值，寻找涉众关心的bug

⑤敏捷流派：强调自动化测试，使用测试来快速验证开发是完整的

6 TMM，TPI，CTP, STEP定义，特点

TMM
TMMi呈现的是一个过程改进的阶段型架构。它包括阶段或级别，组织可以通过它们使测试过程从临时的和未管理的状态进化为已管理、已定义、已测量和优化的状态。在TMMi中有5个级别，规定了成熟度级别和测试过程改进的路径。每个级别都有一组过程域，组织需要实施这些过程域来达到对应的成熟度级别。

  • TMMi1级—初始

  • TMMi2级—已管理

  • TMMi3级—已定义

  • TMMi4级—已测量

  • TMMi5级—优化

过程能力描述了遵循一个软件测试过程可能达到的预期结果的范围。TMM的建立，得益于以下3点：

  • 充分吸收CMM的精华
  • 基于历史演化的测试过程
  • 业界的最佳实践

TPI
TPI是基于连续性表示法的测试过程改进的参考模型，是在软件控制、测试知识以及过往经验的基础上开发出来的。

CTP
关键测试过程（Critical Test Process，CTP）评估模型主要是一个内容参考模型，一个上下文相关的方法，并能对模型进行裁剪。

使用 CTP 的过程改进，始于对现有测试过程的评估， 通过评估以识别过程的强弱，并结合组织的需要提供改进的意见。

STEP
STEP（Systematic Test and Evaluation Process，系统化测试和评估过程）是一个内容参考模型，认定测试是一个生命周期活动，在明确需求后开始直到系统退役。

第五章

1 代码评审的形式及各自特点

  1. 即时代码评审（配对编程）
    • 特点：开发人员编写代码时，审阅者坐在旁边即时阅读并更正代码。也被称为配对编程。
    • 优点：适用于高度复杂的程序，两个开发人员可以更快、更有效地解决问题。
    • 缺点：所需的时间和人力成本较高，可能影响开发人员的平均行数。同时，即时更正可能会中断代码作者的工作流程，并影响开发人员的学习曲线。
  2. 同步代码评审
    • 特点：编码器生成代码后，要求审阅者进行评审。评审员与编码员会合，一边讨论一边评审代码。
    • 优点：实施较为方便，是非正式和自发的过程。
    • 缺点：可能导致开发人员强制上下文切换，影响工作效率。此外，由于缺乏对任务目标的深入了解，遗漏错误和小故障的概率较高。
  3. 基于会议的代码评审
    • 特点：程序员完成工作后召开会议，整个技术团队一起讨论并改进代码。
    • 优点：有助于团队成员更清楚地了解流程，并在团队中传播知识。
    • 缺点：不常用，因为考虑到时间、人力成本、效率等因素，不太可能持续执行。通常只在团队对代码评审过程缺乏经验时使用。
  4. 基于工具的代码评审（异步代码检查）
    • 特点：程序员完成代码后，通过工具让其他人查看和评审代码。
    • 优点：异步完成，评审者可以根据自己的时间安排进行评审，提高了评审的灵活性。
    • 缺点：依赖工具进行评审，可能无法完全覆盖所有问题和场景。
  5. 个人评审
    • 特点：由一名开发者独立完成代码评审。
    • 优点：简单快捷，适合小型项目或代码片段的评审。
    • 缺点：可能受限于评审者的知识水平和经验，容易遗漏问题。
  6. 团队评审
    • 特点：由开发团队的成员共同完成代码评审。
    • 优点：可以集思广益，从多个角度发现和解决问题。
    • 缺点：需要协调团队成员的时间和精力，可能耗时较长。
  7. 对等评审
    • 特点：由两个开发者相互评审彼此的代码。
    • 优点：有助于开发人员之间的相互学习和提高。
    • 缺点：可能受限于评审者的知识水平和经验，且可能存在主观偏见。
  8. 审查委员会评审
    • 特点：由一个由开发者、测试人员和领导人组成的委员会进行评审。
    • 优点：能够从多个角度全面评估代码质量，确保代码符合标准和规范。
    • 缺点：组织起来较为复杂，需要协调多个部门和人员的时间和精力。

2 单元测试定义，作用，目标

单元测试：单元测试是对软件基本组成单元（如函数、类的方法等）进行的测试

单元质量是系统质量的基石，单元测试可以比系统测试测得更彻底

测试目标

主要目标：检验各单元模块是否被正确地编码

需要验证以下内容：

信息能否正确地流入和流出单元。
在单元工作过程中，其内部数据能否保持其完整性，包括内部数据的形式、内容及相互关系不发生错误，也包括全局变量在单元中的处理和影响。
在为限制数据加工而设置的边界处，能否正确工作。
单元的运行能否做到满足特定的逻辑覆盖。
单元中发生了错误，其中的出错处理措施是否有效。

3桩程序，驱动程序

驱动程序
用于模拟被测模块的上级模块，能够调用被测模块，驱动模块接受测试数据，调用被测模块并把相关数据传送给被测模块。

桩程序
用于模拟被测模块工作过程中所调用的下层模块，一般很少进行数据处理，一般只检测被测模块传输数据的正确性。

4 集成测试的概念

集成测试是将软件集成起来，对模块之间的接口进行测试。集成测试又叫子系统测试、组装测试、部件测试等。

5 单一系统的集成测试的集成模式及优缺点

  • 非渐增式测试模式：先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序，如大棒模式。
  • 渐增式测试模式：把下一个要测试的模块同已经测试好的模块结合进来进行测试，测试完后再把下一个应该测试的模块结合起来测试。渐增式测试又可以根据每次添加模块的路线分为自顶向下测试、自底向上测试和混合测试等方式。
    • 自顶向下：从主控模块开始，沿着软件的控制层次向下移动，从而逐渐把各个模块结合起来。在集成过程中，可以使用深度优先的策略或宽度优先的策略。
    • 自底向上：从“原子”模块（ 即在软件结构最底层的模块） 开始集成以进行测试。
    • 混合策略：在具体测试中，可采用混合策略，即结合上述的两种方法逐步实施集成测试。

6 微服务特点，测试目标？测试基本步骤？

微服务特点：

微服务（或称微服务架构）是一种云原生架构方法，具有以下主要特点：

  1. 单一职责原则：每个服务应该负责单独的功能，这是SOLID原则之一。
  2. 独立部署、升级、扩展和替换：每个服务都可以单独部署及重新部署而不影响整个系统，这使得服务很容易升级。
  3. 支持异构/多种语言：每个服务的实现细节都与其他服务无关，服务之间能够解耦，团队可以针对每个服务选择最合适的开发语言、工具和方法。
  4. 轻量级：微服务通常有轻量级的分布式服务框架承载，采用了P2P通信，无中心节点，性能可以线性增长；第三方软件依赖减少，减少类冲突和冗余依赖，集成和升级更方便。

微服务测试目标：

微服务测试的主要目标是确保每个微服务都能按照预期工作，并且与其他服务能够无缝集成。测试目标包括：

  1. 功能验证：验证每个微服务是否实现了其预期的功能。
  2. 性能验证：确保每个微服务在性能上满足要求，并且在高负载下能够稳定运行。
  3. 可靠性验证：测试微服务的容错能力，确保在出现故障时能够保持系统的整体运行。
  4. 安全性验证：验证微服务的安全性，包括数据保护、身份验证和授权等。

微服务测试基本步骤：

  1. 确定系统架构：了解微服务架构，明确每个微服务的职责、接口、依赖项和通信方式。
  2. 编写测试用例：根据微服务的功能和性能要求，编写测试用例。测试用例应覆盖不同的测试级别，如单元测试、集成测试和端到端测试。
  3. 模拟依赖项：在微服务中，各个服务之间可能存在依赖关系。在测试过程中，需要模拟这些依赖项并确保它们正确地处理请求和响应。
  4. 进行自动化测试：使用自动化测试工具来执行测试用例，并监控测试结果。自动化测试可以节省时间并减少错误。
  5. 监控和日志记录：在微服务环境中，监视服务的健康和日志记录非常重要。通过监控可以及时发现故障和性能问题，并通过日志记录进行故障排查。
  6. 修复问题并重新测试：如果在测试过程中发现问题，需要修复问题并重新进行测试，以确保问题已经被解决。

7 集成测试的目标

集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。

目标在于检验与软件设计相关的程序结构问题。如数据穿过接口时可能丢失；一个模块与另一个模块可能有由于疏忽的问题而造成有害影响； 把子功能组合起来可能不产生预期的主功能；个别看起来是可以接受的误差可能积累到不能接受的程度；全程数据结构可能有错误等。

第六章

1 功能测试的基本思路

功能测试：根据产品规格说明书，来检验被测试的系统是否满足各方面功能的使用要求

2 回归测试需要解决的问题。回归测试的策略和方法

  • 一旦程序某些区域被修改了，就可能影响原来正常工作的区域，导致受影响的区域出现回归缺陷。
  • 回归缺陷：原来正常工作的功能，没有发生需求变化，而由于受其它改动影响而产生的问题。
  • 回归测试就是为了发现回归缺陷而进行的测试。如果没有回归测试，产品就带着回归缺陷被发布出去了，造成严重后果。

第七章

1 性能测试目标

  • 获取系统性能某些指标数据
  • 为了验证系统是否达到用户提出的性能指标
  • 发现系统中存在的性能瓶颈，优化系统的性能

2 什么是性能测试？

性能测试（performance test）就是为了发现系统性能问题或获取系统性能相关指标而进行的测试。一般在真实环境、特定负载条件下，通过工具模拟实际软件系统的运行及其操作，同时监控性能各项指标，最后对测试结果进行分析以确定系统的性能状况。

3 系统性能表现

4 按照测试目的分，性能测试类型

  • 性能基准测试：在系统标准配置下获得有关的性能指标数据，作为将来性能改进的基线(Baseline)
  • 性能验证测试：验证系统是否达到事先已定义的系统性能指标、能否满足系统的性能需求
  • 性能规划测试：在多种特定的环境下，获得不同配置的系统性能指标，从而决定系统部署的软硬件配置选型
  • 容量测试可以看作性能的测试一种，因为系统的容量可以看作是系统性能指标之一
  • 压力测试 (Stress test) ：模拟实际应用的软硬件环境及用户使用过程的高负载、异常负载、超长时间运行，从而加速系统崩溃，以检查程序对异常情况的抵抗能力，找出性能瓶颈、不稳定等问题。
  • 渗入测试（soak test），通过长时间运行，使问题逐渐渗透出来，从而发现内存泄漏、垃圾回收（GC）或系统的其他问题，以检验系统的健壮性
  • 峰谷测试（peak-rest test），采用高低突变加载方式进行，先加载到高水平的负载，然后急剧降低负载，稍微平息一段时间，再加载到高水平的负载，重复这样过程，容易发现问题的蛛丝马迹，最终找到问题的根源

5 性能测试的基本过程

6 什么是安全性测试

安全性测试是验证应用程序的安全级别和识别潜在安全性缺陷的过程。它的主要目的是查找软件程序设计中存在的安全隐患，并检查应用程序对非法侵入的防范能力。

7 渗透测试实施策略

  • 全程监控：采用类似wireshark的嗅探软件进行全程抓包嗅探
  • 择要监控：对扫描过程不进行录制，仅仅在数据分析后，准备发起渗透前才开启软件进行嗅探
  • 主机监控：仅监控受测主机的存活状态
  • 指定攻击源：多方监控指定源（某主机）进程、网络连接、数据传输等
  • 对关键系统，可以采用对目标的副本进行渗透测试

8 软件安全性测试有哪两种？有什么关系和区别？

  • 安全功能测试 (Security Functional Testing)：数据机密性、完整性、可用性、不可否认性、身份认证、授权、访问控制、审计跟踪、委托、隐私保护、安全管理等

  • 安全漏洞测试 (Security Vulnerability Testing)：从攻击者的角度, 以发现软件的安全漏洞为目的。安全漏洞是指系统在设计、实现、操作、管理上存在的可被利用的缺陷或弱点

关系与区别：

  • 关系
    • 功能安全性测试和安全漏洞测试是软件安全性测试的两个重要方面，它们共同构成了软件安全测试的完整体系。
    • 功能安全性测试关注软件功能的正确性，而安全漏洞测试关注软件系统的安全防护能力。二者相辅相成，共同提高软件的安全性。
  • 区别
    • 测试目标：功能安全性测试主要关注软件功能的正确性，而安全漏洞测试主要关注软件系统的安全防护能力。
    • 测试方法：功能安全性测试通常采用黑盒测试方法，通过设计测试用例来验证软件的功能表现；而安全漏洞测试则可能采用白盒测试方法，通过深入分析软件系统的内部结构和代码来发现潜在的安全漏洞。
    • 测试结果：功能安全性测试的结果通常用于评估软件的功能质量和用户体验；而安全漏洞测试的结果则直接反映软件系统的安全防护能力和可能存在的安全风险。

9 安全性测试的任务

全面检验软件在需求规格说明中规定的防止危险状态措施的有效性和在每一个危险状态下的反应

对软件设计中用于提高安全性的结构、算法、容错、冗余、中断处理等方案，进行针对性测试

在异常条件下测试软件，以表明不会因可能的单个或多个输入错误而导致不安全状态

对安全性关键的软件单元、组件，单独进行加强的测试，以确认其满足安全性需求

10 安全性测试方法按内外部分为哪两种？

基于威胁的方法：从软件外部考察其安全性，识别软件面临的安全威胁并测试其是否能够发生

基于漏洞的方法 ：从软件内部考虑其安全性，识别软件的安全漏洞，如借助特定的漏洞扫描工具

11 什么是XSS攻击和sql注入攻击，如何进行测试和防范

XSS攻击

定义

XSS攻击（跨站脚本攻击）通常指的是通过利用网页开发时留下的漏洞，通过巧妙的方法注入恶意指令代码到网页，使用户加载并执行攻击者恶意制造的网页程序。这些恶意网页程序通常是JavaScript，但实际上也可以包括Java、VBScript、ActiveX、Flash或者甚至是普通的HTML。

测试方法

  1. 反射型XSS
    • 找寻目标：找到应用程序中所有接受用户输入并在响应中反映这些输入的地方。
    • 测试注入：尝试插入各种恶意脚本载荷，观察是否在响应中原样反映出来。
    • 绕过过滤器：如果应用程序具有某种输入过滤或转义机制，尝试使用不同的编码、大小写或其他技巧来绕过它们。
  2. 存储型XSS
    • 找寻目标：查找应用程序中的所有地方，可以提交数据并在其他地方再次显示这些数据。
    • 测试注入：尝试插入恶意载荷，并希望这些载荷能够被存储并在后续的请求中再次呈现给用户。
    • 检查后端：了解后端如何处理和存储数据可以帮助更好地定制攻击。
  3. DOM型XSS
    • 分析JavaScript：检查代码中如何处理用户输入，特别是与DOM操作相关的部分。

防范措施

  1. 输入验证：在服务器端对用户输入进行验证和过滤，检查输入是否符合预期的格式。
  2. 输出转义：在将用户输入显示给用户之前，确保对其进行转义，以防止恶意脚本的注入。
  3. CSP（Content Security Policy）：使用CSP来限制JavaScript的来源，防止恶意脚本的注入。

SQL注入攻击

定义

SQL注入攻击是指后台数据库操作时，如果拼接外部参数到SQL语句中，就可能导致欺骗服务器执行恶意的SQL语句，造成数据泄露、删库、页面篡改等严重后果。

测试方法

  1. 基于错误消息的注入测试：尝试注入语法错误，观察返回的错误消息是否包含敏感信息或数据库结构。
  2. 基于布尔注入的测试：注入布尔表达式，观察返回的结果是否符合预期。
  3. 基于时间延迟的注入测试：注入延迟语句，观察查询的执行时间是否明显延长。
  4. 基于报错注入的测试：注入报错语句，观察返回的错误消息是否包含敏感信息。

防范措施

  1. 用户分级管理：严格控制用户的权限，对于普通用户，禁止给予数据库建立、删除、修改等相关权限。
  2. 参数传值：禁止将变量直接写入到SQL语句，必须通过设置相应的参数来传递相关的变量。
  3. 基础过滤与二次过滤：对用户输入进行检查，对于单引号、双引号、冒号等字符进行转换或者过滤。
  4. 使用安全参数：在数据库设计时设置专门的SQL安全参数，尽量使用安全参数来杜绝注入式攻击。
  5. 漏洞扫描：使用专业的扫描工具，及时发现系统存在的SQL攻击安全漏洞。

12 web安全性测试可从哪些方法开展

13 什么是软件可靠性？可从哪几个指标度量？各自的定义

可靠性：在规定的一段时间和条件下，软件能维持其性能水平的能力有关的一组属性，可用成熟性、容错性、易恢复性三个基本子特性来度量。

  • 成熟性度量：通过错误发现率DDP（Defect Detection Percentage）来表现。DDP越小，软件越成熟。

    DDP=测试发现的错误数量/已知的全部错误数量

  • 容错性测试在下面一节介绍

  • 恢复性的测试先设法（模拟）使系统崩溃、失效等，然后计算其系统和数据恢复的时间来做出易恢复性评估。

14 容错测试的要点？

容错测试是一种对抗性的测试过程。在这种测试中，通过各种手段让软件强制性地发生故障，或将把应用程序或系统置于（模拟的）异常条件下，以产生故障，例如设备输入/输出（I/O）故障或无效的数据库指针和关键字等

15 什么是A/B测试？有什么特点

A/B测试（ABTest） 是将用户分成不同的组，同时在线试验产品的不同版本，通过用户反馈的真实数据来确定哪一个方案更好

特点

  • 先验性：采用流量分割与小流量测试的方式，先让线上部分小流量用户使用以验证设计，再根据数据反馈来推广到全流量，减少产品损失
  • 并行性：同时运行两个或两个以上版本的试验完成对比分析，而且保证每个版本所处的环境一致的，避免流程周期长的问题，节省验证时间
  • 科学性：基于统计的数据来做出决策，避免主观或经验的错误决策

第八章

1 软件本地化，国际化，全球化，相互关系

I18N——软件国际化

I18N是借助功能设计和代码实现中软件系统有能力处理多种语言和不同文化，使创建不同语言版本时，不需要重新编写代码的软件工程方法。

  • 支持Unicode字符集、双字节的字符

  • 分离程序代码和显示内容

  • 消除Hard code

  • 使用Header files 去定义经常被调用的代码段

  • 改善翻译文本尺寸，具有调整的灵活

  • 支持各个国家的键盘设置

  • 支持文字排序和大小写转换

  • 支持各个国家的度量衡，时区，货币单位格式等的设置

  • 国际化用户界面设计（自我定义）。

L10N——软件本地化

L10N是将一个软件产品按特定国家/地区或语言市场的需要进行加工，使之满足特定市场上的用户对语言和文化的特殊要求的软件生产活动。

  • 翻译
  • 地区文化、宗教
  • 度量衡和时区等
  • 软件用户界面（UI）
  • 联机文档 (帮助文档和功能性的PDF文档)
  • 热键设置

G11N——软件全球化
G11N = I18N + L10N

关系和区别

  • I18N是L10N的基础和前提，为L10N做准备
  • L10N是I18N向特定本地语言环境的转换
  • I18N 是软件产品源语言开发的一部分，属于Engineering
  • L10N 可以独立于Engineering，可由第三方完成

2 unicode与utf-x关系，特点

关系

  • Unicode：是一种在计算机上使用的字符编码标准，旨在将全世界常用文字都涵盖进去。它为每种语言中的每个字符设定了统一并且唯一的二进制编码，以满足跨语言、跨平台进行文本转换、处理的要求。
  • UTF-X：是Unicode的实现方式或编码格式，其中“X”表示码元的宽度（比特数）。Unicode编码本身并不直接决定字符在内存或磁盘上的存储方式，而是由UTF-X这样的编码格式来决定的。

特点

Unicode

  1. 唯一性：为每种语言中的每个字符设定了统一并且唯一的二进制编码。
  2. 跨平台性：满足跨语言、跨平台进行文本转换、处理的要求。
  3. 可扩展性：不断扩展以支持新的字符和符号，新版本会引入新的码点。
  4. 广泛字符支持：能够表示非常广泛的字符范围，包括各种文字、符号、表情符号等。

UTF-X

  • UTF-8
    • 8位变长编码：对于大多数常用字符集（如ASCII中的0~127字符）只使用单字节，而对其他常用字符（如中文）使用多字节（通常是3字节）。
    • 兼容性：与ASCII编码兼容，使得ASCII字符在UTF-8中仍然只占用一个字节。
    • 广泛使用：由于其高效的编码方式和兼容性，UTF-8成为互联网上最为常见的字符编码方式。
  • UTF-16
    • 16位编码：大部分情况下，UTF-16使用两个字节（16位）来表示一个字符，但某些特殊字符可能需要使用四个字节（称为“代理对”或“surrogate pairs”）。
    • 与Unicode码点关联：UTF-16编码大致相当于Unicode编码的实现，与CPU字序有关。
  • UTF-32
    • 32位固定编码：每个字符都使用四个字节（32位）进行编码，因此也被称为UCS-4或Unicode编码的直接表示。
    • 简洁性：由于每个字符都使用固定长度的编码，因此编码和解码过程相对简单。

3 软件本地化基本步骤

  • 建立配置管理体系，跟踪目标语言各个版本的源代码
  • 创造和维护术语表
  • 源语言代码和资源文件分离、或提取需要本地化的文本
  • 把分离或提取的文本、图片等翻译成目标语言
  • 把翻译好的文本、图片重新检入目标语言的源代码版本
  • 如果需要，编译目标语言的源代码
  • 测试翻译后的软件，调整UI 以适应翻译后的文本
  • 测试本地化后的软件，确保格式和内容都正确

4 本地化测试主要有哪些工作

功能性测试，所有基本功能、安装、升级等测试；

翻译测试，包括语言完整性、术语准确性等的检查；

可用性测试，包括用户界面、度量衡和时区等；

兼容性调试，包括硬件兼容性、版本兼容性等测试；

文化、宗教、喜好等适用性测试

手册验证，包括联机文件、在线帮助、PDF文件等测试

5 软件本地化测试完整路线

第九章

1 自动化测试与测试自动化

通过平台、系统或工具自动地完成测试的某类工作都可以归为测试自动化

自动化测试更侧重的测试用例或测试数据生成、测试执行和测试结果呈现等自动化

2 如何理解测试自动化

  • 定义：测试自动化是把以人为驱动的测试行为转化为机器执行的一种过程。它旨在通过自动化工具和脚本执行测试用例，自动比对测试结果与预期结果，以评估系统的功能和性能。
  • 目的：通过测试自动化，可以节省人力、时间和硬件资源，提高测试覆盖率、减少回归测试的工作量，并确保测试的一致性和准确性。

3 测试自动化实现的原理，几种技术

代码分析：类似于高级编译系统，在工具中定义类、对象、函数、变量等定义规则、语法规则等，在分析时对代码进行语法扫描，找出不符合编码规范的地方。

对象识别 ：Windows对象 、Mac对象、Web DOM对象

脚本技术： 线性脚本 结构化脚本 数据驱动脚本、关键字驱动脚本

自动比较技术：静态比较和动态比较，简单比较和复杂比较，敏感性测试比较和健壮性测试比较，比较过滤器

测试自动化系统的构成：测试工具的分类、测试工具的选择、测试自动化普遍存在的问题、自动化测试的引入和应用

自动化测试的引入和应用

找准测试自动化的切入点

把测试开发纳入整个软件开发体系

测试自动化依赖测试流程和测试用例

软件测试自动化的投入较大

进行资源的合理调度

4 自动化测试的流程

需求分析：

  • 确定测试范围：识别哪些功能适合自动化测试。
  • 定义测试目标：明确自动化测试的目的和预期结果。

测试计划：

  • 制定测试策略：确定测试工具、框架和技术。
  • 资源分配：分配测试人员、硬件和软件资源。
  • 时间安排：制定测试时间表，包括开发、执行和维护时间。

测试设计：

  • 编写测试用例：根据需求文档和功能说明编写详细的测试用例。
  • 选择测试数据：确定并准备所需的测试数据。

环境搭建：

  • 配置测试环境：搭建所需的硬件和软件环境，包括服务器、数据库和网络配置。
  • 安装测试工具：安装和配置自动化测试工具和框架。

脚本开发：

  • 编写自动化测试脚本：根据测试用例使用编程语言编写自动化测试脚本。
  • 参数化测试脚本：使脚本能够处理不同的数据输入，支持数据驱动测试。

脚本调试：

  • 调试和验证：运行测试脚本，确保其能够正确执行并捕获预期的结果。
  • 修正错误：修复调试过程中发现的脚本问题。

测试执行：

  • 自动化执行：将测试脚本集成到CI/CD流水线，通过持续集成工具（如Jenkins、GitLab CI）自动触发测试执行。
  • 手动执行：在必要时手动触发测试执行，例如在开发和调试阶段。

结果分析：

  • 生成报告：收集和整理测试执行的结果，生成详细的测试报告。
  • 结果验证：验证测试结果是否符合预期，分析测试失败的原因。

缺陷管理：

  • 缺陷报告：记录在测试过程中发现的缺陷，使用缺陷管理工具（如JIRA、Bugzilla）进行跟踪。
  • 缺陷修复：开发团队根据缺陷报告修复问题，修复完成后重新测试。

回归测试：

  • 自动化回归测试：在每次代码变更后执行自动化回归测试，确保新的修改没有引入新的缺陷。
  • 更新测试脚本：根据需求变化和缺陷修复情况更新测试脚本。

测试优化：

  • 反馈和改进：根据测试结果和反馈，不断优化测试用例、测试脚本和测试流程。
  • 提高覆盖率：增加新的自动化测试用例，提高测试覆盖率和深度。

维护和管理：

  • 脚本维护：定期维护和更新测试脚本，确保其与软件版本一致。
  • 测试环境管理：维护测试环境的稳定性和一致性，避免环境差异导致的测试失败。

5 几种脚本技术

线性脚本
结构化脚本
数据驱动脚本
关键字驱动脚本

6 自动化功能测试基本构成

  1. 测试工具和框架
  • 自动化测试工具：用于执行自动化测试脚本的工具，如Selenium、Appium、QTP/UFT等。
  • 测试框架：用于组织和运行测试的框架，如JUnit、TestNG、PyTest等。
  • 辅助工具：如CI/CD工具（Jenkins、GitLab CI）、版本控制系统（Git）和缺陷管理工具（JIRA、Bugzilla）。
  1. 测试脚本
  • 脚本开发：使用编程语言（如Java、Python、JavaScript）编写测试脚本，模拟用户操作并验证功能。
  • 脚本管理：组织和维护测试脚本，包括版本控制和代码复用。
  • 数据驱动测试：通过参数化脚本使其能够处理不同的数据输入，从而进行广泛的测试。
  1. 测试数据
  • 数据准备：创建和管理用于测试的数据集，包括输入数据和预期结果。
  • 数据存储：测试数据可以存储在文件（如CSV、JSON、XML）或数据库中，以便于读取和使用。
  1. 测试环境
  • 环境配置：设置和配置测试所需的硬件和软件环境，包括测试服务器、操作系统、浏览器、数据库等。
  • 环境管理：确保测试环境的稳定性和一致性，避免环境差异导致的测试失败。
  1. 测试执行
  • 自动化执行：通过自动化工具和脚本执行测试，通常集成到CI/CD流水线中以实现持续测试。
  • 手动触发：在必要时手动运行测试脚本，特别是在调试和开发阶段。
  1. 测试结果分析
  • 结果报告：生成测试执行结果报告，包括测试通过与失败的详细信息。
  • 日志记录：记录测试执行日志，用于分析测试失败原因和调试脚本。
  1. 缺陷管理
  • 缺陷报告：记录测试中发现的缺陷，并使用缺陷管理工具进行跟踪和管理。
  • 缺陷修复：开发团队根据缺陷报告修复问题，测试团队重新验证修复后的功能。
  1. 反馈和优化
  • 结果反馈：分析测试结果和缺陷报告，反馈给开发和测试团队。
  • 测试优化：根据反馈不断优化测试脚本、测试数据和测试流程，提高测试效率和覆盖率。
  1. 维护和更新
  • 脚本维护：定期更新和维护测试脚本，以确保其与软件最新版本保持一致。
  • 环境维护：保持测试环境的最新配置，定期检查和更新环境设置。

7 TA框架的构成及各部分特点

  1. Harness/IDE
  • 集成开发环境：提供开发和执行测试脚本的统一平台。
  • 调试功能：支持调试测试脚本，提供断点设置、变量监控等功能。
  • 结果显示：集成报告功能，展示测试结果和日志。
  1. 脚本语言（Script Language）
  • 灵活性：使用高级编程语言（如Python、Java、JavaScript）编写测试脚本，灵活性高。
  • 可读性：脚本语法清晰易懂，便于测试人员编写和维护。
  • 可复用性：支持模块化编程，方便代码复用和维护。
  1. 代理（Agents）
  • 分布式执行：支持在不同环境或机器上执行测试，适合大规模测试任务。
  • 资源管理：管理和分配测试资源，优化测试执行效率。
  • 监控功能：实时监控测试执行状态，记录执行日志。
  1. 工具（Tools）
  • 测试工具集成：支持集成各种测试工具，如Selenium、Appium等，用于不同类型的测试（功能测试、性能测试等）。
  • 自动化功能：提供自动化操作的支持，模拟用户行为、进行界面操作等。
  • 扩展性：支持插件机制，可以扩展和定制工具功能。
  1. 任务安排（Scheduler）
  • 自动调度：根据预设计划自动安排测试任务的执行，支持定时和触发机制。
  • 任务管理：管理测试任务的生命周期，包括任务的创建、启动、暂停和终止。
  • 并发执行：支持并发执行多个测试任务，提高测试效率。
  1. 报告（Report）
  • 结果汇总：汇总测试结果，生成详细的测试报告。
  • 可视化：提供图表和统计信息，直观展示测试结果和覆盖率。
  • 可追溯性：详细记录测试执行过程，便于追踪和分析问题。