Skip to content

Latest commit

 

History

History
487 lines (318 loc) · 19.7 KB

SETduty.md

File metadata and controls

487 lines (318 loc) · 19.7 KB
Raw

单元测试、代码覆盖率、功能测试、压力测试

🔰构建任何分支 🔰构建任何PR 🔰上传制品 👍容器化构建 (Docker)

👍自动化测试(支持触发冒烟/单元/回归测试)

👍性能测试

👍代码覆盖率收集 🔰漏洞扫描 🔰License扫描

👍Code Lint

👍静态代码分析

👍动态代码分析 🔰Email或Slack通知

2.2 SET((Software Engineer in Test)

软件测试开发工程师，也是开发角色，重心在可测性测试和通用测试基础框架上。

  • 更关注质量提升和测试覆盖度的增加。
  • 写代码的目的是可以让SWE测试自己的功能。

2.3 TE(Test Engineer)

　　测试工程师，承担着产品专家、质量顾问、风险分析师的角色。

  • 把用户放在第一位思考
  • 组织整体质量实践、分析解释测试运行结果，驱动测试执行，构建端到端的自动化测试

谷歌测试类型

  • 小型测试 　　一般来说都是自动化实现的，用于验证一个单独函数或者独立功能模块的 代码是否按照预期工作，着重于典型功能性问题、数据损坏、错误条件和大小差异错误 等方面的验证。通常是由SWE来实现。
  • 中型测试 　　通常也都是自动化实现，一般会涉及到2个或2个以上模块的交互，重点在于 验证这些功能近邻区之间的交互，以及彼此调用时的功能是否正确。 　　SET会驱动这些测试的实现及运行，SWE会深度参与，一起编码、调试和维护 这些测试。在开发过程的后期，TE 会通过手动或自动化地执行这些用例。
  • 大型测试 　　涵盖三个或以上(通常更多)的功能模块，使用真实用户使用场景和实际用户数据， 大型测试关注的是所有模块的集成，但更倾向于结果驱动，验证软件是否满足 最终用户的需求。 　　所有的三种工程师角色都会参与，或是通过自动化测试，或是探索式测试。

按照测试方法分类：

  • 黑盒测试
  • 白盒测试
  • 灰盒测试

按照测试阶段分类：

  • 单元测试
  • 集成测试
  • 系统测试
  • 验收测试

按照测试形式分类：

  • 静态测试
  • 动态测试

按照软件质量特性分类：

  • 功能测试
  • 安全测试
  • 性能测试
  • 可靠性测试
  • 压力测试
  • 安装测试
  • 用户界面测试
  • 兼容性测试

其他：

  • 冒烟测试

  • 回归测试

  • 随机测试

  • 探索性测试

  • 黑盒测试 　　指的是把被测的软件看作是一个黑盒，只关心软件的输入和输出 它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。黑盒技术设计测试用例的方法：等价类划分、边界值分析、错误推测、因果图和综合策略。

  • 白盒测试 　　指的是把盒子盖子打开，去研究里面的源代码和程序结果它是按照程序内部的结构测试程序， 通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。 白盒测试设计测试用例方法：控制流测试（语句覆盖测试、分支覆盖测试、条件覆盖测试、条件组合覆盖测试、路径覆盖测试）、 数据流测试、程序变异、程序插桩、域测试和符号求值等。

  • 灰盒测试 　　介于白盒与黑盒之间，在关注输出正确的同时也考虑内部的实现逻辑。这种关注不象白盒那样详细、完整，只是通过一些 表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多， 如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。

3.1 功能测试

  • 严格根据提测任务进行测试，检查提测任务是否符合规范（需求状态、必要信息）
  • 测试期间发现Bug，根据提单规范及时提TAPD单，填写必要信息，填写优先级和影响程度，并分配给开发同学，针对需求拉小群
  • TAPD发送测试报告，注意需求、提测任务、Bug的TAPD状态

3.2 回归

  • 针对功能测试发现的Bug，在开发解决完Bug后，进行回归
  • 跟进Bug进度，及时处理拒绝的Bug，分配对应处理人
  • 开发解决完Bug，需要核对Bug产生原因；挂起的Bug，需要产品、开发、测试三方达成一致
  • 遇到阻塞性问题，重点提出，尤其是跨小组跨区域的，及时找人

3.3 集成

  • 原则上，功能测试通过了，才能进行迭代集成测试；有例外情况，需要开发、产品达成一致

  • 根据Bug数量情况，按需组织Bug Review会议，决定是否解决、什么时候解决

  • TAPD发送测试报告，关系到是否允许上线

  • 接口测试：一般主要是Curl命令，Postman，Postwomen，Swagger UI, Yapi等

  • 压力测试：Jmeter，SoupUI等

  • 抓包工具：Fiddler，Charles，Wireshark，Whitle等

测试人员职责

集成测试

  • 目标：验证不同模块或服务之间的接口是否按预期工作。
  • 方法：设计针对模块交互的测试用例，可能需要修改Makefile来编译特定组件或整个应用程序。
  • 工具：可能使用持续集成工具（如GitLab CI/CD）来自动化测试流程。

系统测试

  • 目标：确保整个系统作为一个整体满足用户需求和业务目标。
  • 方法：基于需求文档设计测试用例，执行端到端的测试流程。
  • Makefile：使用Makefile定义的规则来部署系统测试环境。

性能测试

  • 目标：评估软件在高负载或长时间运行下的性能表现。
  • 方法：使用性能测试工具（如JMeter、LoadRunner）设计测试场景，并执行测试。
  • Makefile：可能需要在Makefile中添加特定规则来配置性能测试环境或运行测试脚本。

安全测试

  • 目标：识别和修复可能被利用的安全漏洞。
  • 方法：执行代码审查、使用自动化安全扫描工具（如OWASP ZAP、Fortify）。
  • Makefile：集成安全检查到构建流程中，确保每次构建都进行安全测试。

测试自动化

  • 目标：提高测试效率和覆盖率，减少人工测试的重复性工作。
  • 方法：开发自动化测试脚本，使用自动化测试框架（如Selenium、Appium）。
  • Makefile：在Makefile中添加规则来运行自动化测试脚本。

测试策略

  • 目标：制定全面的测试计划，包括测试类型、方法、资源和时间表。
  • 方法：基于产品需求和风险评估，确定测试的重点和优先级。

测试报告

  • 目标：记录测试结果，提供详细的反馈给开发团队和利益相关者。
  • 方法：使用测试管理工具（如TestRail、JIRA）生成测试报告。
  • Makefile：自动化测试完成后，Makefile可以触发报告生成过程。

与Makefile的结合

Makefile是一个强大的工具，可以用于定义测试流程中的编译、链接、部署和执行测试等步骤。测试人员可以利用Makefile来：

  • 自动化测试环境的搭建和清理。
  • 编译测试工具或测试框架。
  • 运行集成测试、系统测试、性能测试和安全测试。
  • 收集和整理测试结果，生成测试报告。

示例Makefile规则

# 定义测试环境变量
TEST_ENV_VARS := export TEST_MODE=true

# 集成测试
integration-test:
	$(TEST_ENV_VARS) ./run_tests.sh integration

# 系统测试
system-test:
	$(TEST_ENV_VARS) ./run_tests.sh system

# 性能测试
performance-test:
	$(TEST_ENV_VARS) ./run_performance_tests.sh

# 安全测试
security-test:
	$(TEST_ENV_VARS) ./run_security_scan.sh

# 自动化测试
test-automation:
	$(TEST_ENV_VARS) ./run_automation_tests.sh

# 生成测试报告
test-report:
	$(TEST_ENV_VARS) ./create_test_report.sh

通过这种方式，测试人员可以确保测试流程的自动化和标准化，提高测试效率和质量。

要实现在每次代码提交时自动执行测试，包括C++代码的语法检查、逻辑问题检测、鲁棒性测试等，您可以设置一个持续集成/持续部署（CI/CD）流程。以下是实现这一流程的步骤：

  1. 选择CI/CD工具： 选择一个CI/CD工具，如GitLab CI/CD、Jenkins、GitHub Actions、Travis CI等，这些工具可以与您的代码仓库（如GitLab、GitHub）集成。

  2. 编写.gitlab-ci.yml或等效配置文件： 创建一个CI/CD配置文件，定义构建和测试的步骤。例如，使用GitLab CI/CD时，您需要在项目根目录下创建.gitlab-ci.yml文件。

  3. 语法检查： 在CI/CD配置文件中添加步骤，使用静态代码分析工具（如cppcheck、clang-tidy、Coverity等）来检查C++代码的语法问题和潜在的逻辑错误。

  4. 单元测试： 配置单元测试步骤，使用您选择的测试框架（如Catch2、Google Test等）来执行单元测试，确保代码逻辑正确。

  5. 集成测试： 如果需要，添加集成测试步骤，确保多个组件或模块协同工作时的逻辑正确性。

  6. 系统测试： 添加系统测试步骤，以验证整个系统作为一个整体的鲁棒性和功能符合性。

  7. 代码覆盖率： 集成代码覆盖率工具（如gcov、lcov等）来检查测试的覆盖情况，确保关键代码都被测试覆盖到。

  8. 构建可执行文件： 在CI/CD流程中构建可执行文件，并确保所有依赖项都已正确安装。

  9. 自动化脚本： 编写自动化脚本，用于运行测试、收集测试结果和覆盖率报告。

  10. 设置触发条件： 配置CI/CD流程的触发条件，例如每次提交、合并请求或定期定时触发。

  11. 错误报告： 设置流程以在测试失败时发送错误报告，例如通过电子邮件、Slack或其他通知方式。

  12. 代码审查： 集成代码审查工具，如GitLab的Merge Request功能，以人工检查代码质量和测试结果。

  13. 文档化： 确保CI/CD流程和相关配置文件有良好的文档说明，方便团队成员理解和维护。

  14. 权限和安全性： 确保CI/CD流程符合组织的安全性要求，不泄露敏感信息。

1. 准备工作

  • 了解项目：熟悉项目结构和Makefile，了解编译和链接过程。
  • 安装GitLab Runner：确保您的GitLab实例配置了Runner，它将执行CI/CD作业。

2. 编写.gitlab-ci.yml

3. 语法和风格检查（Lint）

  • 工具：cppcheck 或 clang-tidy
  • 配置：在.gitlab-ci.yml的lint阶段中添加检查命令。

4. 编译项目

  • 工具：使用项目的Makefile
  • 配置：在.gitlab-ci.yml的build阶段中添加make命令。

5. 单元测试和逻辑测试

  • 工具：Google Test、Boost.Test或其他C++测试框架
  • 编写测试代码：为关键功能编写测试用例。
  • 配置：在Makefile中添加test目标，并在.gitlab-ci.yml的test阶段中运行make test。

6. 集成测试

  • 编写集成测试：测试模块间的交互。
  • 配置：可能需要在Makefile中添加特定的集成测试目标。

7. 性能测试

  • 工具：Valgrind、gprof或其他性能分析工具
  • 配置：在CI流程中添加性能测试阶段，运行性能测试命令。

8. 代码覆盖率

  • 工具：gcov、lcov
  • 配置：运行测试后，使用这些工具生成覆盖率报告，并在.gitlab-ci.yml中配置为artifacts。

9. 代码审查

  • 人工审查：鼓励团队成员进行代码审查。
  • 自动化工具：可以使用ESLint、Stylelint等工具进行代码风格审查。

10. 部署（如果需要）

  • 配置：在CI流程中添加部署阶段，自动化部署到测试或生产环境。

11. 持续集成触发

  • 提交代码：每次提交或合并请求时，GitLab Runner将自动触发CI流程。

12. 监控和报告

  • 使用GitLab UI：监控测试执行情况和结果。
  • 配置通知：设置电子邮件或其他通知，以便在测试失败时收到通知。

13. 文档和维护

  • 文档化：记录CI/CD流程和测试策略。
  • 维护：定期回顾和更新CI/CD配置和测试代码。

测试一般流程：

  1. 代码编写：开发者编写代码，并可能在本地运行测试和静态分析。

  2. 提交和推送：开发者将更改提交到Git仓库，并推送到远程仓库（如GitLab）。

  3. 触发CI/CD：推送操作触发GitLab CI/CD流程。

    4. 运行.gitlab-ci.yml：

    .gitlab-ci.yml是一个配置文件，定义了GitLab CI/CD的流程。它告诉GitLab如何构建、测试、分析和部署代码。这个文件通常包含以下几个部分：

    • stages：定义了CI/CD的各个阶段，如build、test、deploy等。
    • jobs：定义了在每个阶段要执行的具体任务。
    • script：指定了每个任务要运行的命令序列。
    • artifacts：定义了CI/CD过程中生成的文件，如测试报告、构建产物等，这些文件可以在GitLab界面上下载查看。
    • cache：定义了需要被缓存的文件或目录，以加速构建过程。

    5. 编译和构建：

    Makefile是一个构建自动化工具，它定义了一系列的规则和依赖关系来编译和链接源代码。一个典型的Makefile可能包含：

    • 目标：通常是构建产物，如可执行文件或库文件。
    • 依赖：目标文件依赖的源文件或其他目标。
    • 命令：生成目标所需的shell命令。

    例如，一个简单的Makefile可能如下所示：

    all: my_program

my_program: main.o utility.o
	g++ -o my_program main.o utility.o

main.o: main.cpp
	g++ -c main.cpp

utility.o: utility.cpp
	g++ -c utility.cpp

clean:
	rm -f my_program *.o

    在这个Makefile中：

    • all是默认目标，依赖于my_program。
    • my_program的构建依赖于main.o和utility.o两个对象文件。
    • main.o和utility.o的生成依赖于相应的.cpp源文件。
    • clean是一个伪目标，用于清理构建产物。

    6. 静态代码分析（可以转到yml）：

    静态代码分析是在不运行代码的情况下检查代码质量的工具。它可以检测出潜在的错误、代码风格问题、复杂度过高的函数等。在.gitlab-ci.yml中，你可以添加一个步骤来运行静态分析工具，例如：

    analyze:
  script:
    - cppcheck --enable=all --inconclusive --verbose cppcheck_output.xml .
  artifacts:
    reports:
      cppcheck: cppcheck_output.xml

    在这个例子中：

    • analyze是一个job，它运行cppcheck工具。
    • script定义了要执行的命令。
    • artifacts定义了如何保存分析报告。

    7. 测试：

    单元测试是验证代码单个部分（如函数或类）是否按预期工作的测试。使用Catch2这样的测试框架，你可以编写测试用例并运行它们来验证代码功能。在.gitlab-ci.yml中，你可以定义一个job来运行这些测试：

    test:
  script:
    - ./run_tests

    在这个例子中：

    • test是一个job，它运行run_tests脚本或可执行文件，这个文件负责执行所有的测试用例。

    在代码层面，一个Catch2的测试用例可能如下所示：

    #define CATCH_CONFIG_MAIN
#include "catch.hpp"
#include "my_header.h"

TEST_CASE("Addition") {
    SECTION("Add two positive numbers") {
        REQUIRE(add(2, 3) == 5);
    }
    SECTION("Add two negative numbers") {
        REQUIRE(add(-1, -2) == -3);
    }
    SECTION("Add positive and negative numbers") {
        REQUIRE(add(-1, 2) == 1);
    }
}

    在这个测试用例中：

    • TEST_CASE定义了一个测试案例，它包含多个SECTION。
    • REQUIRE是一个断言宏，用于验证函数的返回值是否符合预期。

    这些步骤结合起来，形成了一个完整的CI/CD流程，从代码提交到自动化测试和分析，再到可能的部署，确保了代码质量和快速反馈。

    8.报告：生成测试报告和静态分析报告。

    9.合并请求：如果所有检查都通过，开发者可以创建一个合并请求将更改合并到主分支。

    10.部署：在合并到主分支后，CI/CD流程可能自动部署代码到生产环境或测试环境。

    11.反馈循环：开发者根据CI/CD流程中的反馈进行必要的调整。

1. 配置 .gitlab-ci.yml

在项目的根目录下创建或更新 .gitlab-ci.yml 文件，定义你的 CI/CD 流程。例如：

yamlstages:
  - test

test_job:
  stage: test
  script:
    - echo "运行测试脚本"
    - make test  # 假设你的测试命令是 make test
  only:
    - merge_requests
  except:
    - branches  # 这会跳过对分支的直接提交，只对 MR 运行测试

这个配置会在每次创建 Merge Request 时运行 test_job，但不会在直接推送到分支时运行。

2. 设置保护规则

在 GitLab 的项目设置中，你可以为分支设置保护规则，以防止不合格的代码被合并。

  • 进入你的项目设置页面。
  • 选择 "Repository" > "Protected Branches"。
  • 选择你想要保护的分支（通常是 main 或 master）。
  • 启用 "Allow only merge requests to be merged" 选项，这样只有通过 Merge Request 才能合并代码。

3. 配置 Merge Request 规则

在 GitLab 的项目设置中，你可以设置 Merge Request 规则，要求所有 MR 必须通过所有配置的 CI 测试。

  • 进入 "Settings" > "Merge Requests"。
  • 找到 "Pipeline must succeed" 选项并启用它。
  • 选择 "test_job" 作为必须成功的作业。

4. 编写测试代码

确保你的项目中有适当的测试代码，并且它们能够覆盖关键功能和边界条件。

5. 提交和推送代码

开发者需要按照以下步骤提交代码：

  • 将他们的更改推送到一个新分支。
  • 创建一个 Merge Request，将他们的分支合并到受保护的分支。

6. 运行 CI/CD 测试

当开发者提交 Merge Request 时，GitLab CI 将自动运行 .gitlab-ci.yml 中定义的测试作业。

7. 审查和合并

  • 测试通过后，代码被认为是合格的，可以被合并。
  • 如果测试失败，开发者需要修复问题并重新推送更改，直到测试通过。

注意事项

  • 确保所有开发者都了解 CI/CD 流程和测试的重要性。
  • 测试作业应该尽可能快速和全面，以避免长时间的等待和不必要的合并阻塞。
  • 考虑使用 GitLab 的 "Review Apps" 功能，为每个 MR 生成一个可访问的应用程序实例，以便于测试和审查。

通过基础设施即代码（Infrastructure as Code, IaC）、持续集成/持续部署（CI/CD）和容器化技术来实现高效的开发和部署流程。以下是一个详细的逐步指南，使用 Terraform、GitLab CI、Docker 和 Kubernetes 来实现这一目标。