Python项目的质量保证
首先来打个不恰当比喻，你在市场上购买苹果时，挑选最好的苹果相当简单。你可以通过触摸它们来挑选，选择最好的颜色、成熟度和没有可见的伤疤。这个过程称为质量控制——你只选择满足你要求的优质产品。当分拣站里有大量苹果时，事情就会变得复杂。确保良好的产品质量变得非常困难。只有这个过程的自动化才能解决问题。
同样的问题也适用于软件。当你单独处理一个小项目时，关注代码格式、良好的编码实践、包版本控制和测试非常简单。然而，一旦项目不断增长，并且添加了新的脚本和依赖项，手动检查质量就会变得困难。这就是质量保证发挥作用的时刻。
软件开发过程中的QA、QC和测试（基于文章）
质量保证 (QA)是确保最终产品符合预定的公司标准的常见做法。这是一种积极主动的方法，专注于防止流程级别的缺陷。它的目的是建立适当的流程并引入质量标准。
质量控制 (QC)是一种反应性方法，这意味着我们要确保产品在发布之前符合要求和规格。此过程的目的是验证产品质量。
测试是检测软件中的错误和不需要的功能。它侧重于源代码和设计。
为什么质量检查如此重要？简而言之，它影响软件可靠性、维护成本、产品改进等等。
-
Python 项目的QA步骤
一旦我们知道了在项目中应用 QA 的目的，我们就将重点放在实际方面。
1.pylint -错误检查器
Pylint 分析代码而不实际运行它（静态代码分析器）。它遵循PEP 8推荐的风格。
2.black -代码格式化程序
Black 确保代码库中的所有代码都遵循相同的样式规则。
3.isort -导入排序器
按字母顺序对导入进行排序，并自动将它们按类型分成不同的部分。在处理大量进口时很有用。
4.mypy -静态类型检查器
它确保在代码中正确使用变量和函数。只需将类型提示（ PEP 484 ）添加到 Python 程序中，当你错误地使用这些类型时，mypy 就会发出警告。
5.pydocstyle -文档字符串约定合规性检查器
使用--convention选项指定现有约定并选择已检查错误的基本列表。可能的约定：pep257、numpy、google。
6.bandit —安全问题查找器
它报告潜在的安全问题，例如漏洞、不安全的加密实践、硬编码秘密等等。
7.pytest —测试框架
该框架支持编写各种类型的软件测试，包括单元测试、集成测试、端到端测试和功能测试。其中一些功能包括参数化测试、固定装置和断言重写。
尽管上面提到的库是众所周知的老库，但请毫不犹豫地用更适合您的替代品（来自 Google 的yapf代码格式化程序、 Ruff linter 等）替换它们。
-
Python模块的QA 脚本模板
让我们考虑以下项目结构：
.├── my_module│ └── ...├── tests│ ├── conftest.py│ ...├── README.md└── qa.sh即用型QA 脚本可能如下所示（由Piscada开发）：
#!/bin/bashecho"======== pylint ========"python -m pylint my_moduleexit_pylint=$?echo""echo"======== black ========"python -m black --check --diff my_moduleexit_black=$?echo""echo"======== isort ========"python -m isort my_module --check-only --diffexit_isort=$?echo""echo"======== mypy ========"python -m mypy my_moduleexit_mypy=$?echo""echo"======== pydocstyle ========"python -m pydocstyle --convention=numpy my_moduleexit_pydocstyle=$?echo""echo"======== bandit ========"python -m bandit -r my_moduleexit_bandit=$?echo""echo"======== pytest ========"python -m pytestexit_pytest=$?echo""echo"======== exit status ========"echo"pylint: $exit_pylint, black: $exit_black, mypy: $exit_mypy, pydocstyle: $exit_pydocstyle, bandit: $exit_bandit, pytest: $exit_pytest"! (( exit_pylint || exit_black || exit_mypy || exit_pydocstyle || exit_bandit || exit_pytest))每个步骤都可以通过添加或更改命令标志来个性化。pyproject.toml否则，如果使用 Poetry，包配置也可以在文件中定义。
# [...] poetry configuration sections[tool.black]line-length = 88# default value but can be change to [79, 80 or any other][tool.pylint.messages_control]good-names = ["df", "np", "pd"][tool.pylint.format]max-line-length = 88[tool.isort]profile = "black"line_length = 88[tool.mypy]no_implicit_optional = "False"[tool.pydocstyle]convention = "numpy"# ...例如，如果使用除 之外的文档字符串约定，请更改命令convention的选项。更改配置时请参阅软件包文档。pydocstylenumpy
请记住，某些没有适当配置的软件包可能不兼容。例如，黑色和异色会相互纠正。为了防止这种情况，请定义profile = “black”isort包。
-
语义版本控制
此外，你可以添加 QA 步骤来检查中定义的项目版本是否pyproject.toml有效且尚未使用。对于语义版本控制验证，semver可以使用库。此外，以下代码检查存储库中是否存在标签。
import gitrepo = git.Repo(".git/")new_tag = "0.1.1"if new_tag in repo.tags:print("Tag exists.")else:print("Tag doesn't exist")运行质量检查
首先，赋予文件qa.sh执行权限：
chmod+x qa.shQA 脚本可以通过多种方式运行，例如：
./qa.sh# orbash qa.sh# orsh qa.sh如果使用poetry包管理器，请记住添加poetry run，例如：poetry run ./qa.sh。
在脚本输出结束时，将显示错误摘要。在理想的情况下，它看起来像这样：
======== exit status ========pylint: 0, black: 0, mypy: 0, pydocstyle: 0, bandit: 0, pytest: 0-
何时运行 QA 脚本？
在将分支与主分支合并之前进行质量检查可能会导致许多错误、警告和……挫败感。
一个好的做法是每次将更改推送到分支时运行 QA 脚本。因此，您将能够持续控制代码的质量。任何错误或不符合标准的行为都将被及早发现。
例如，可以使用预提交挂钩
自动运行 QA 脚本。Git Hooks是Git在发生某些事件时可以自动执行的脚本。预提交挂钩意味着脚本将在您提交更改之前执行。为此，创建一个符号链接，如下所示：
ln -s ./qa.sh .git/hooks/pre-commit另一个解决方案可能是在 CI/CD 管道中运行 QA 脚本。您不需要手动运行它，一切都是自动化的。为此，请考虑使用Github Actions或Bitbucket Pipelines 。
结论
在开发生命周期中发现错误越晚，对业务的影响就越严重。检测错误只是一回事。二是查找原因，修复bug。如果没有高质量的代码，调试就会变得复杂、耗时且成本高昂。更不用说团队成员士气低落，也没有工人急于接手修复任务。
因此，在项目中实施质量保证非常重要。在此过程中，不仅会检查代码的功能，还会检查是否符合公认的标准，例如代码格式约定。因此，代码更具可读性且易于维护。
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：【文末自行领取】
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！
