02 分层架构软件测试

Posted on Wed, 25 Dec 2024 17:11:14 +0800 by LiangMingJian

1.分层架构概述 #

1.1 定义 #

• 分层体系结构指的是将系统的组件分隔到不同的层中，每一层中的组件处在同一抽象级别，保持内聚性，并且每一层都与它下面的各层保持松散耦合。
• 这种风格支持基于可增加抽象层的设计，允许将一个复杂问题分解成一个增量步骤序列的实现。
• 不同的层次处于不同的抽象级别，越靠近底层，抽象级别越高，越靠近顶层，抽象级别越低。
• 由于每一层最多只影响两层，因此只要给相邻层提供相同的接口，就允许每层用不同的方法实现，为软件复用提供支持。

1.2 层次 #

• 表示层：也称为用户界面层，负责业务和视图的展开。
• 服务层：也称为应用层，为表示层提供各种服务的支持。
• 业务逻辑层：也称为领域层，负责业务的规则、业务的流程方面逻辑的实现。
• 数据层：负责数据的访问、数据的管理服务，例如数据库，存储文件等。

1.2 优点 #

• 利于合作开发：由于某一层仅仅调用其相邻下一层所提供的程序接口，因此只需要本层的接口和相邻下一层的接口定义清晰完整，开发人员在开发某一层时就可以只关注集中这一层所用的功能和技术。
• 维护方便：只要前后提供的服务（接口）相同，即可替换，可以很容易用新的实现来替换原有层次的实现。
• 分层独立：即使某层业务发生变化，其他两层也不需要变化，系统各层之间的依赖程度很低。
• 复用性强：充分利用现有的功能程序组件，将已经辨识的具有相对独立功能的层应用于新系统的开发，缩短系统开发周期。

1.3 缺点 #

• 成本增加：因为要将软件先抽象出来，然后分层，然后再开发，所以开发成本可能会增加。
• 修改困难：一些复杂的业务中，由于业务流程发生变化，为了这个变化所有层都需要修改。
• 性能下降：本来是直接简单的操作，需要在整个系统中层层传递，势必造成性能的下降，同时也加大的开发的复杂度。
• 设计困难：由于难以找到一个合适的、正确的层次抽象方法，所以并不是每个系统都可以很容易地划分为分层的模式。

1.4 示例：MVC 三层模式 #

• MVC 模式是软件工程中常见的一种分层体系结构，该模式把软件系统（项目）分为三个基本部分：模型（Model）、视图（View）和控制器（Controller）。
• 视图（View）是界面的显示，以及与用户的交互功能，例如表单、网页等。
• 控制器（Controller）是一个分发器，用来决定对于视图发来的请求，需要用哪一个模型来处理，以及处理完后需要跳回到哪一个视图。
• 模型（Model）持有所有的数据、状态和程序逻辑。模型接受视图数据的请求，并返回最终的处理结果。负责实体对象相关的业务逻辑。
• 示例：在基于JAVAEE（J2EE）技术开发的软件系统中，常用 HTML，JSP 来实现视图层，使用 Servlet 来实现控制器，使用 EJB 来实现模型层。其中 JSP，Servlet，EJB都是服务器端应用组件

2.表示层的测试 #

2.1 常规测试项 #

2.1.1 内容显示和必输项检查 #

• 名称是否显示正确
• 是否是必输项
• 初始值及状态检查
• 元素关联性检查
• 信息内容正确性检查
• 控件类型是否显示正确

2.1.2 按钮/链接正确性检查 #

• 按钮/链接点击后在没有得到返回前按钮需不可用
• 点击按钮/链接后可正常跳转到相应界面或窗口执行

2.1.3 通用检查 #

• 风格一致（与同类界面视觉风格、字体、图标一致）
• 标题显示（界面标题和任务栏显示的标题正确）
• 元素位置（元素水平、垂直对齐）
• 元素尺寸（元素尺寸合理，行列间距一致）
• 窗口特性（切换、移动、改变大小、刷新时界面正常）

2.2 基于 Web 端的表示层测试 #

• 浏览器可移植性测试：基于不同类型的浏览器、不同的浏览器版本及分辨率构建浏览器的兼容矩阵，进行测试。
• 页面性能测试：响应时间的可接受度。
• Web 端涉及的质量特性：可移植性，易用性，性能效率。

2.3 基于 PC 端的表示层测试 #

• 安装/卸载测试。
• 在线升级测试。
• 网络切换测试。
• 可移植性测试。
• PC 端涉及的质量特性：可移植性，易用性，功能性。

2.4 基于移动端的表示层测试 #

• 安装/卸载测试。
• 切换测试：网络切换、前后台切换。
• 在线升级测试。
• 安全测试：软件权限、应用安全。
• 性能测试：启动耗时、CPU、内存、耗电量、流量、功耗、流畅度。
• 可移植性测试：APP 对不同机型的适用情况。
• 移动端涉及的质量特性：可移植性，易用性，性能效率，功能性，安全性。

2.5 表示层测试设计和实施的原则 #

• 需要特别关注软件易用性。
• 在软件需求分析和用户界面设计阶段，测试人员职责是参入同行评审，了解软件需求和用户界面要求，以及使用场景和用户特点，根据经验，从测试角度提出建议。
• 测试人员在用户界面设计阶段结束后，可以提出对易用性问题的主观看法。
• 在测试设计阶段，测试人员职责是根据软件需求规格说明书、用户界面设计以及软件人机交互友好性、易用性的测试准则设计测试用例。
• 在上线之前，用户界面测试与功能测试同步确认一次，保证与最终版本的一致性。
• 一般情况下表示层测试不作为专项测试内容，可与其他质量特性的测试混合进行。

3.服务层的测试 #

3.1 功能性测试 #

• 业务功能性测试（场景、异常场景）
• 边界测试（基于输入输出的边界测试）
• 单接口的不同参数组合测试
• 多接口的不同业务组合（业务流）测试

3.2 信息安全性测试 #

• 敏感信息是否加密
• 身份认证
• 注入
• 信息泄露

3.3 性能测试 #

• 响应时间
• 吞吐量
• 并发数
• 服务器资源（CPU、IO、内存、网络）

3.4 服务接口层测试设计和实施原则 #

• 越早越好，越早发现BUG，修复成本越低
• 检查接口的功能、性能
• 对于前后端架构分离的系统，从安全层面来说，只依赖前端进行限制已经完全不能满足系统的安全要求，需要后端从接口层进行验证；前后端传输数据等信息是否加密传输需要验证
• 接口测试比较容易实现自动化测试

3.5 接口测试质量评估的原则 #

• 业务功能覆盖是否完整
• 业务规则覆盖是否完整
• 参数验证是否达到要求（边界、业务规则）
• 接口异常场景覆盖是否完整
• 性能指标是否满足要求
• 安全指标是否满足要求

4.业务层的测试 #

4.1 功能性测试 #

• 对功能模块中所有存在输入条件的功能进行测试
• 对功能模块中所有存在输出结果的功能进行验证测试
• 对功能模块中所有存在业务规则的功能进行测试
• 对功能模块中存在异常情况或错误数据处理的功能进行测试
• 验证是否满足需求要求的所有功能，强调业务功能的完整性
• 验证功能实现是否满足用户需求和系统设计的隐藏需求，强调业务功能的适合性
• 对流程中调用的对外接口进行测试
• 对流程中的入口条件进行测试，验证其处理逻辑、错误控制等
• 对主要的流程进行逻辑正确性验证，再覆盖多个流程分支的全流程测试

4.2 信息安全性测试 #

• 通过源代码审计的测试方法进行检测
• 常见的代码问题，如编码错误，编码规范，重复等

4.3 业务功能测试策略 #

• 测试需求分析
  • 根据业务需求和系统设置明确的测试目标、测试条件以及功能点进行的测试
  • 基于用户的连续操作行为实现业务的流程、系统的处理流程相关的测试
  • 基于测试人员的技术和经验技术来分析系统可能出错的地方、找出系统最容易出错的功能点或场景进行测试
• 测试用例设计
  • 检测当输入或输出为最大、最小、临界值时交易能否正确处理
  • 基于业务逻辑的重要程度对测试用例级别进行划分
  • 检测系统正常的业务处理、流程是否能够正确执行
  • 检测关联系统在正常情况下的协调运作情况
  • 检测系统异常的业务处理、容错处理是否能够正常执行
  • 检测关联系统存在异常时，本系统是否能够正确判断
• 用例评审
  • 详细
  • 全面
  • 一致
• 测试实施执行
  • 先测功能后测流程
  • 先测主流程后侧分支流程
  • 先测系统内的流程，后测系统间的流程
  • 按优先级执行测试，并保存执行记录

4.4 代码审计测试策略 #

• 代码审计前期准备阶段：技术人员和客户代表对代码服务相关的技术进行详细的交流，由此确定代码审计的方案，决定哪些代码要审计、用什么方式审计、审计的时间、审计的要求等。
• 代码审计实施阶段：一般会用专门的代码审计工具扫描获取初步信息，然后进行人工的代码审查，最后结合自动化扫描的结果和人工审查的结果生成报告提交给客户。
• 复测实施阶段：代码审计报告提交和沟通之后，跟开发人员针对代码审查发现的问题进行修改，然后代码审查人员进行回归的检查，然后提交复查的报告。
• 成果汇报阶段：根据审查和复查的结果，整理审查输出的成果，最后生成代码审查报告。

5.数据层的测试 #

5.1 安全性策略 #

• 一般用基于规格说明的测试技术，以人工功能检查为主要形式。
• 检查包括用户及口令管理，授权和审计管理，数据加密在内的内容。

5.2 性能效率策略 #

• 采用TCP的性能测试标准和规范
• 目前常用的性能测试规范包括：
  • 针对 OLTP 系统的性能测试规范 TCP-C
  • 针对电子商务应用的性能测试规范 TCP-W
  • 针对大数据基准测试 OLAP 的性能测试规范 TCP-DS

5.3 可靠性策略 #

• 联机备份
• 故障恢复

5.4 数据正确性与完整性策略 #

• 采用基于规格规格说明测试方法，以手工测试为主。
• 测试包括存储数据的方式，数据类型和长度，数据日期和时间字段，国际化，字符集编码在内的内容。

5.5 功能性策略 #

• 安装与配置
• 数据库存储管理
• 模式对象管理
• 非模式对象管理
• 交互查询工具
• 性能检测与调优
• 数据迁移工具
• 作业管理

5.6 数据迁移策略 #

5.6.1 数据迁移测试的原则 #

• 完整性原则：验证数据一条都没有少
• 正确性原则：验证数据绝对都是正确的
• 适用性原则：数据层旧系统迁移到新系统里面符合新系统的规范和要求
• 有效性原则：需要对老系统中不符合规范的数据进行清洗，必要时补充符合规范的数据内容
• 安全性原则：对敏感数据安全和保密方面的情况

5.6.2 数据迁移涉及的用例 #

• 对迁移后的新旧数据进行数据对比，验证数据是否正确。
• 从业务上来判断，在应用程序中做一个流程，验证数据是否正常。

5.6.3 数据迁移的测试方法 #

• 技术核验：由迁移验证程序来验证对比迁移前后的数据
• 静态对比：根据业务的需求，对关键的业务数据进行源和目的地之间的直接比较
• 动态对比：选择关键的业务功能，在新旧系统之间同时进行操作，验证新旧系统之间的运算结果是不是相同
• 业务连续性验证测试：使用存在的数据进行业务的测试