View on GitHub

ITMO-PE

My study notes about Program Engineering at University ITMO

MainPage/Rubiesh/Rubiesh

Exam Тестировано ПО (2013/2014)

1. Понятие тестирования ПО. Основные определения.
软件测试的概念。基本定义。

Тестирование программного обеспечения - проверка соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов, выбранном определенным образом.
软件测试是检查程序的实际行为与预期行为是否一致的过程，这通过特定方式选择的一组测试来实现。

В более широком смысле, тестирование - это одна из техник контроля качества, включающая в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis).
在更广泛的意义上，测试是一种质量控制技术，涵盖了测试管理（Test Management）、测试设计（Test Design）、测试执行（Test Execution）和测试结果分析（Test Analysis）等活动。

Верификация (Verification) - это процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа. Т.е. выполняются ли наши цели, сроки, задачи по разработке проекта, определенные в начале текущей фазы.
验证（Verification）是评估系统或其组件的过程，目的是确定当前开发阶段的结果是否符合该阶段开始时设定的条件。换句话说，是否实现了在当前阶段初期设定的目标、时间和开发任务。

Валидация (Validation) - это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе.
确认（Validation）是确定开发中的软件是否符合用户的期望和需求以及系统的要求。

Тестовый случай - Input-Processing-Output. Должен быть повторяемым.
测试用例 — 输入-处理-输出。必须是可重复的。

Тестовый сценарий - набор тестовых случаев
测试场景 — 一组测试用例。

2. Цели и принципы тестирования (ISTQB).
测试的目标和原则（ISTQB）。

Цели тестирования: 测试目标：

Принципы тестирования:
测试原则：

  1. Тестирование демонстрирует наличие дефектов (их отсутствие показать нельзя)
    测试表明缺陷的存在（无法证明它们不存在） Тестирование может показать наличие дефектов в программе, но не доказать их отсутствие. Тем не менее, важно составлять тест-кейсы, которые будут находить как можно больше багов. Таким образом, при должном тестовом покрытии, тестирование позволяет снизить вероятность наличия дефектов в программном обеспечении. В то же время, даже если дефекты не были найдены в процессе тестирования, нельзя утверждать, что их нет.
    测试可以表明程序中存在缺陷，但不能证明它们不存在。尽管如此，制定能够发现尽可能多缺陷的测试用例仍然非常重要。通过适当的测试覆盖，测试能够减少软件中存在缺陷的可能性。同时，即使在测试过程中未发现缺陷，也不能断言它们不存在。
  2. Исчерпывающее тестирование недостижимо (полное тестовое покрытия недостичь)
    穷尽测试是无法实现的（无法实现完全测试覆盖率）
    Невозможно провести исчерпывающее тестирование, которое бы покрывало все комбинации пользовательского ввода и состояний системы, за исключениям совсем уж примитивных случаев. Вместо этого необходимо использовать анализ рисков и расстановку приоритетов, что позволит более эффективно распределять усилия по обеспечению качества ПО.
    无法进行覆盖所有用户输入组合和系统状态的穷尽测试，除非是在极为简单的情况下。因此，需要使用风险分析和优先级排序，从而更有效地分配保证软件质量的工作。
  3. Раннее тестирование (чем раньше тем лучше)
    尽早进行测试（越早越好）
    Тестирование должно начинаться как можно раньше в жизненном цикле разработки программного обеспечения, и его усилия должны быть сконцентрированы на определенных целях.
    测试应尽早在软件开发生命周期的初期开始，并且其工作应集中于特定目标。
  4. Скопление дефектов (несколько модулей содержат основную массу ошибок)
    缺陷聚集（少数模块包含大部分错误） Есть сложные куски программы. Дефекты в основном в них. Модули сами по себе сложные, поэтому все баги в них Разные модули системы могут содержать разное количество дефектов
    • то есть, плотность скопления дефектов в разных элементах программы может отличаться. Усилия по тестированию должны распределяться пропорционально фактической плотности дефектов. В основном, большую часть критических дефектов находят в ограниченном количестве модулей. Это проявление принципа Парето: 80% проблем содержатся в 20% модулей.
      系统的不同模块可能包含不同数量的缺陷，即程序各个元素中缺陷的聚集密度可能不同。测试工作应根据缺陷的实际密度进行分配。通常，绝大多数关键性缺陷集中在少数模块中。这是帕累托原则的体现：80%的问题集中在20%的模块中。
  5. Парадокс пестицида (если часто проводить правки, то тесты со временем ломаются и их нужно чинить) (жуки привыкают к пестициду) Прогоняя одни и те же тесты вновь и вновь, Вы столкнетесь с тем, что они находят все меньше новых ошибок.
    杀虫剂悖论（频繁修复后，测试会逐渐失效，需要修复测试） Поскольку система эволюционирует, многие из ранее найденных дефектов исправляют и старые тест-кейсы больше не срабатывают. Чтобы преодолеть этот парадокс, необходимо периодически вносить изменения в используемые наборы тестов, рецензировать и корректировать их с тем, чтобы они отвечали новому состоянию системы и позволяли находить как можно большее количество дефектов.
    反复运行相同的测试会发现越来越少的新错误。随着系统的进化，许多早期发现的缺陷会被修复，旧的测试用例将失去作用。为了克服这一悖论，需要定期修改测试集，审查和调整它们，以适应系统的新状态，并发现尽可能多的缺陷。
  6. Тестирование зависит от контекста
    测试依赖于上下文
    (если речь о больничном софте, то нужно лучше тестировать. Также тесты не должны быть сложнее, чем реальные кейсы, то есть проверяем на реальных данных).
    （如果我们谈论的是医院软件，那么我们需要更好地测试。而且，测试不应该比真实案例更复杂，即我们检查真实数据）。
    Выбор методологии, техники и типа тестирования будет напрямую зависеть от природы самой программы. Например, программное обеспечение для медицинских нужд требует гораздо более строгой и тщательной проверки, чем, скажем, компьютерная игра. Из тех же соображений, сайт с большой посещаемостью должен пройти через серьезное тестирование производительности, чтобы показать возможность работы в условиях высокой нагрузки.
    测试方法、技术和类型的选择将直接依赖于程序的性质。例如，医疗需求的软件比电脑游戏需要更加严格和详细的测试。出于同样的考虑，高访问量的网站必须经过严格的性能测试，以证明它能够在高负载条件下正常运行。
  7. Заблуждение об отсутствии ошибок.
    无错误的误解 Обнаружение и исправление дефектов не помогут, если созданная система не подходит пользователю и не удовлетворяет его ожиданиям и потребностям.
    即使发现并修复了缺陷，若开发的系统不适合用户，也无法满足用户的期望和需求，依然无济于事。

3. Основная цель тестирования. Уровень доверия, корректное поведение, реальное окружение.
测试的主要目标。信任水平、正确行为、真实环境。

Основная цель тестирования - увеличение приемлемого уровня пользовательского доверия в том, что программа функционирует корректно во всех необходимых обстоятельствах
测试的主要目标是提高用户对程序在所有必要环境下正常运行的信任水平。

4. Тестирование и качество. Уровни восприятия тестирования в компании.
测试与质量。公司内对测试的认知层次。

Уровень 0 - тестирование == отладка
0级 - 测试等同于调试

  1. Не отличает некорректное поведение и ошибки в программе
    无法区分程序中的不正确行为和错误
  2. Не учитывает требования надежности и безопасности
    不考虑可靠性和安全性要求

**Уровень 1 - предназначение

Уровень 2 - Демонстрация ошибок
2级 - 演示错误

На данном уровне может происходить конфликт разработчиков и тестировщиков
在此级别，开发人员和测试人员之间可能会发生冲突

Уровень 3 - Тестирование может показать наличие ошибок
3级 - 测试可以显示错误的存在

  1. Используя ПО мы подвержены рискам
    使用软件时，我们面临风险
  2. Риск - последствия незначительные
    风险 - 后果不严重
  3. Риск - последствия катастрофические
    风险 - 后果灾难性的
  4. Тестировщики и разработчики совместно снижают риски
    测试人员和开发人员共同降低风险

Уровень 4 - Тестирование - это возможный способ оценки качества программного обеспечения в терминах найденных дефектов&& **4级 - 测试是一种通过发现缺陷来评估软件质量的方式

Способы оценивания качества:
质量评估方法：

5. Участники тестирования, их роль, квалификация и обязанности.
测试参与者，他们的角色、资质和职责。

6. Мониторинг прогресса и контроль тестирования (ISTQB)
测试进度监控与控制（ISTQB）。

Целью мониторинга тестирования - является обзор процесса тестирования и предоставление результата заинтересованным лицам.
测试监控的目的是审查测试过程，并向相关人员提供结果。

Информация отслеживается вручную или автоматически и может быть использована для измерения критериев выхода, таких как покрытие.
信息可以手动或自动跟踪，并用于衡量退出标准，如覆盖率。

Метрики также могут быть использованы для оценки прогресса тестирования по сравнению с запланированным расписанием и бюджетом.
度量标准也可用于评估测试进度与计划进度和预算的比较。

Метриками могут являться тестовое покрытие, количество пройденных тестов, количество найденных дефектов и т.д.
度量标准可以包括测试覆盖率、通过的测试数量、发现的缺陷数量等。

Контроль тестирования описывает любые направляющие или корректирующие действия, принятые как результат по полученной и собранной информации и значениям метрик в результате мониторинга.
测试控制描述了基于通过监控获得的信息和度量值所采取的任何指导或纠正措施。

Контроль тестирования может затрагивать любые действия по тестированию, а также воздействовать на другие действия и задачи жизненного цикла ПО.
测试控制可以涉及任何测试活动，并影响软件生命周期中的其他活动和任务。

Такими действиями могут быть правильная приоритизация усилий тестирования, привлечение большего количества ресурсов на тестирование, уменьшение объема предстоящего релиза и т.д.
此类措施可能包括正确的测试优先级、增加测试资源、减少即将发布的版本规模等。

7. Модульное тестирование. Понятие модуля. Драйверы и заглушки.
单元测试。模块的概念。驱动程序和桩。

Модульное тестирован - это процесс в программировании, позволяющий проверить модули исходного кода программы.
单元测试是编程中的一个过程，用于验证程序源代码的模块。

Цель модульного тестирования - изолировать отдельные части программы и показать их работоспособность.
单元测试的目标是将程序的各个部分隔离开来，并展示它们的可操作性。

В ходе модульного тестирования решаются задачи:
在单元测试过程中解决以下问题：

Понятие модуль (модуль программы) - компонент минимального размера, который может быть независимо протестирован в ходе верификации программной системы
模块（程序模块）的概念 - 是程序系统验证过程中可以独立测试的最小组件。

Модуль может быть одним из:
模块可以是以下之一：

Заглушка - часть программы, которая симулирует обмен данными с тестируемым компонентом, выполняет имитацию рабочей системы.
桩 - 是程序的一部分，用于模拟与被测试组件的数据交换，并模仿实际系统的工作。

Драйвер - определенный модуль теста, который управляет тестируемым нами элементов.
驱动程序 - 是特定的测试模块，用于控制我们正在测试的元素。

8. V-образная модель. Статическое и динамическое тестирование.
V模型。静态测试与动态测试。

V-образная модель - описывает подход к разработке приложений, при котором тестирование ведется параллельно с разработкой на каждом из её этапов.
V 形模型 - 描述了一种应用程序开发方法，其中测试与每个阶段的开发并行进行。

Преимущества V-модели:
V模型的优点：

Недостатки V-модели:
V模型的缺点：

Статическое тестирование:
静态测试：

Динамическое тестирование:
动态测试：

9. Валидация и верификация. Тестирование методом “чёрного” и “белого” ящика.
验证与确认。黑盒测试与白盒测试。

Верификация - это проверка на соответствие правилам.
确认是对符合规则的检查。
Правила оформляются в виде документа. То есть, должен быть документ с требованиями к документации.
规则以文件形式呈现。也就是说，必须有文件来规定文档的要求。
Если документация соответствует требованиям этого документа, то она прошла верификацию.
如果文档符合这些要求，那么它通过了确认。

Валидация - это проверка правильности выводов.
验证是对结论正确性的检查。
То есть, должен быть свод знаний, в котором описано, как получить описание конструкции на основе данных об объекте.
也就是说，必须有知识体系来描述如何根据对象的数据获取结构描述。
Проверка правильности применения этих выводов - есть валидация.
验证是检查这些结论应用的正确性。
В том числе это проверка описания на непротиворечивость, полноту и понятность.

Методы “черного ящика”
黑盒测试方法： Метод тестирования при котором не используется знания о внутреннем устройстве тестируемого объекта
测试方法不使用关于被测试对象内部结构的知识

Методы “белого ящика”
白盒测试方法： Тестирование кода на предмет логики работы программы и корректности её работы.
测试代码的逻辑及其工作的正确性。 Тестирование позволяет проверить внутреннюю структуру программы.
这种测试方法可以检查程序的内部结构。
Исходя из этой стратегии тестировщик получает тестовые данные путем анализа логики работы программы.
根据这种策略，测试人员通过分析程序的逻辑获得测试数据。

Валидация → черный ящик
验证 → 黑盒测试

Верификация → белый ящик
确认 → 白盒测试

10. Тестовый случай, тестовый сценарий и тестовое покрытие.
测试用例、测试场景与测试覆盖率。

Тестовый случай (Input → Processing → Output)
测试用例 (输入→处理→输出)

Имеет: 具备以下要素：

Характеристики:
特点：

Тестовый сценарий - это последовательность тестовых случаев.
测试场景是测试用例的序列。
Показывает типичное использование системы.
显示系统的典型使用情况。
Также должен обрабатывать не только корректное поведение, но и вариант ошибки, вроде НЕВЕРНОГО pin кода и блокировать карточку после 3-х раз.
还应处理错误情况，比如错误的PIN码，并在三次输入错误后锁定卡片。

Свойством является определение корректного поведения в:
特性是在以下方面定义正确行为：

Тестовое покрытие - это одна из метрик оценки качества тестирования, представляющая собой плотность покрытия тестами требований либо исполняемого кода.
测试覆盖率是评估测试质量的指标之一，表示需求或可执行代码的测试覆盖密度。

Полное покрытие к сожалению невозможно :( Выбор может производиться с помощью следующих методов:
遗憾的是，完全覆盖是不可能的。

11. Полное тестовое покрытие. Оценка объема и времени полного покрытия.
完全测试覆盖率。覆盖范围和时间的估计。

Полное тестовое покрытие недостижимо, поэтому тестовое покрытие выбирается с помощью определенных методик:
完全的测试覆盖率是无法实现的，因此通过特定方法选择测试覆盖率：

Необходимо балансировать между количеством тестов, стоимостью и скоростью разработки.
需要平衡测试数量、成本和开发速度。

12. Повторяемость тестового сценария. Автоматизированное тестирование. Регрессионное тестирование.
测试场景的可重复性。自动化测试。回归测试。

Повторяемость - все написанные тесты всегда будут выполняться однообразно.
重复性 - 所有编写的测试将始终以相同的方式执行。

Автоматическое тестирование - тестирование с помощью программных средств, аналогично ручному тестированию.
自动化测试 - 使用软件工具进行测试，与手动测试相似。

Регрессионное тестирование - собирательное название для всех видов тестирования программного обеспечения, направленных на обнаружение ошибок в уже протестированных участках исходного кода.
回归测试 - 是针对软件的所有测试类型的统称，旨在发现已经测试过的源代码部分中的错误。
Такие ошибки - когда после внесения изменений в программу перестает работать то, что должно было продолжать работать - называют регрессионными ошибками.
这些错误是指在对程序进行更改后，原本应继续工作的部分停止工作，这种错误称为回归错误。
Регрессионные тесты удобно автоматизировать и запускать после каждого изменения/добавления участка кода, проверяя, что не сломалось ничего из ранее работающего.
回归测试可以方便地自动化，并在每次更改/添加代码段后运行，以检查以前正常工作的部分是否仍然正常。

Задачи регрессионного тестирования:
回归测试的任务：

13. Цели и задачи интеграционного тестирования. Алгоритм интеграционного тестирования. Стратегии интеграции.
集成测试的目标和任务。集成测试算法。集成策略。

Интеграционное тестирование - вид тестирования, при котором на соответствие требований проверяется интеграция модулей, их взаимодействие между собой, а также интеграция подсистем в одну общую систему.
集成测试 - 一种测试类型，检查模块的集成及其相互之间的交互，以及子系统集成到一个整体系统中的符合性。

Стратегии интеграции
集成策略

Алгоритмы интеграции:
集成算法：

14. Тестирование системы целиком - системное тестирование.
14. 整个系统的测试——系统测试。

Системное тестирование ПО - это тестирование ПО, выполняемое на полной, интегрированной системе, с целью проверки соответствия системы исходным требованиям.
软件系统测试 - 在完整集成系统上进行的软件测试，目的是检查系统是否符合初始要求。
Системное тестирование относится к методам тестирования черного ящика, и, тем самым, не требует знаний о внутреннем устройстве системы.
系统测试属于黑盒测试方法，因此不需要对系统内部结构的了解。

Задача: проверка как функциональность системы с точки зрения пользователя, так и нефункциональные характеристики.
任务： 从用户的角度检查系统的功能性以及非功能性特征。

При этом выявляются дефекты, такие как неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии использования, отсутствующая или неверная функциональность, неудобство использования и т.д.
此过程中识别出缺陷，例如系统资源的错误使用、用户级数据的未预见组合、与环境的不兼容、未预见的使用场景、缺失或错误的功能、使用不便等。
Для минимизации рисков, связанных с особенностями поведения системы в той или иной среде, во время тестирования рекомендуется использовать окружение максимально приближенное к тому, на которое будет установлен продукт после выдачи.
为最小化与系统在特定环境中的行为特性相关的风险，建议在测试期间使用尽可能接近于产品发布后将要安装的环境。

Включает несколько фаз:
包括几个阶段：

15. Тестирование возможностей, стабильности, отказоустойчивости, совместимости.
功能、稳定性、容错性和兼容性测试。

Относится к нефункциональному тестированию.
属于非功能性测试。

Тестирование возможностей - минимальная нагрузка, состоящая из корректных и реальных данных, проверка возможностей и функционала системы
能力测试 - 最小负载，由正确的实际数据组成，检查系统的能力和功能。

Тестирование стабильности - добавляем нагрузку, данные все ещё корректные.
稳定性测试 - 增加负载，数据仍然是正确的。
Проверяем как система работает в более-менее реальных условиях
检查系统在比较真实的条件下如何工作。

Тестирование отказоустойчивости - пытаемся все сломать к чертям. Некорректные данные, большая нагрузка, сбои питания, восстановление после отказа и т.д.
容错测试 - 尝试将一切都搞砸。不正确的数据、大负载、断电、故障恢复等。

Тестирование совместимости - запуск с различными версиями библиотек, на различном окружении. Смотрим как система со всем этим работает.
兼容性测试 - 使用不同版本的库，在不同环境下运行。观察系统如何处理这一切。

16. Тестирование производительности - CARAT.
性能测试——CARAT。

CARAT - подход к нагрузочному тестированию
CARAT - 负载测试的一种方法

17. Альфа и Бета тестирование. Приемочное тестирование.
Alpha 和 Beta 测试。验收测试。

Альфа и бета-тестирование являются частью системного тестирование. Проводятся пользователями.
阿尔法和贝塔测试是系统测试的一部分。由用户进行。

Альфа-тестирование - имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком.
阿尔法测试 - 由常规开发人员模拟与系统的实际工作，或者由潜在用户/客户与系统的实际工作。

Бета-тестирование - в некоторых случаях выполняется распространение предварительной версии (в случае проприетарного программного обеспечения иногда с ограничениями по функциональности или времени работы) для некоторой большей группы лиц с тем, чтобы убедиться, что продукт содержит достаточно мало ошибок.
贝塔测试 - 在某些情况下，将预发布版本（在专有软件的情况下，功能或运行时间可能有限制）分发给更大群体，以确保产品包含的错误足够少。
Иногда бета-тестирование выполняется для того, чтобы получить обратную связь о продукте от его будущих пользователей.
有时，贝塔测试是为了从未来的用户那里获得对产品的反馈。

Приемочное тестирование - формальный процесс тестирования, который проверяет соответствие системы требованиям и проводится с целью: определения удовлетворяет ли система приемочным критериям; вынесения решения заказчиком или другим уполномоченным лицом принимается приложение или нет.
验收测试 - 一种正式的测试过程，用于检查系统是否符合要求，其目的在于：确定系统是否满足验收标准；由客户或其他授权人员决定是否接受该应用程序。

18. Статическое тестирование. Рецензия, технические анализ, сквозной контроль.
静态测试。审查、技术分析、全流程控制。

Статическое тестирование - анализ артефактов разработки программного обеспечения, таких как требования или программный код, проводимый без исполнения этих программных артефактов.
静态测试 - 对软件开发工件（如需求或程序代码）进行分析，而无需执行这些程序工件。
В процессе статического тестирования, программные продукты рассматриваются оцениваться вручную, проводятся ревью или с помощью набора инструментов, сам код при это не запускается.
在静态测试过程中，软件产品被手动审查和评估，可以进行评审或使用一组工具，而不运行代码。
Проводится перед динамическим тестированием и соответственно ошибки найденные на этом этапе обходятся нам дешевле.
在动态测试之前进行，因此在此阶段发现的错误成本较低。

Рецензирование (Review) - оценка состояния продукта или проекта с целью установления расхождений с запланированными результатами и для выдвижения предложений по совершенствованию.
评审 - 评估产品或项目的状态，以确定与计划结果的差异，并提出改进建议。

Технический анализ - проверка продукта на соответствие и практическую пригодность.
技术分析 - 检查产品的合规性和实用性。

Сквозной контроль - представляет собой один из видов формального пересмотра артефактов методом “мозгового штурма”, который может проводиться на любом этапе разработки.
横向控制 - 一种正式审查工件的方式，通过“头脑风暴”方法，可以在开发的任何阶段进行。
Это дружественная встреча разработчиков, тщательно спланированная, с ясно определенными целями, повесткой дня, продолжительностью и составом участников.
这是开发人员之间的友好会议，经过精心计划，明确的目标、议程、持续时间和参与者组成。

19. Статическое тестирование. Инспекции.
静态测试。检查。

Статическое тестирование - анализ артефактов разработки программного обеспечения, таких как требования или программный код, проводимый без исполнения этих программных артефактов. В процессе статического тестирования, программные продукты рассматриваются оцениваться вручную, проводятся ревью или с помощью набора инструментов, сам код при это не запускается. Проводится перед динамическим тестированием и соответственно ошибки найденные на этом этапе обходятся нам дешевле.
静态测试(Статическое тестирование) 是在不执行软件开发工件（例如需求或程序代码）的情况下进行的分析。在静态测试过程中，软件产品被手动评估、审查或使用一组工具，但代码本身并不运行。它是在动态测试之前进行的，因此，在此阶段发现的错误成本较低。

Инспекция ПО - это статическая проверка соответствия программы заданным спецификациями, проводится путем анализа различных представлений результатов проектирования (документации, требований, спецификаций, схем или исходного кода программы) на процессах ЖЦ.
软件检查(Инспекция ПО) 是对程序是否符合给定规范的静态检查；它是通过分析生命周期过程中设计结果的各种表示（文档、需求、规范、图表或程序源代码）来进行的。

Четко определенные шаги:
明确定义的步骤：

Шаги 4-7 являются одной сессией и могут повторяться
步骤 4-7 为一个会话，可以重复

Роли инспекторов могут быть выбраны из следующих:
可以从以下角色中选择检查员角色

20. Статическое тестирование. Статический анализ кода.
静态测试。代码静态分析。

Цель статического тестирования - нахождение дефектов в коде или моделях ПО.
静态测试的目标 - 找到代码或软件模型中的缺陷。

Фактически статический анализ - это исследование ПО с помощью специальных инструментов без его запуска, при динамическом тестировании ПО требуется запуск кода.
实际上，静态分析是使用专门工具对软件进行研究，而不运行软件；而在动态测试中需要运行代码。

Статический анализ выявляет дефекты, которые сложно найти при динамическом тестировании.
静态分析能够识别在动态测试中难以发现的缺陷。

Преимущества статического анализа:
静态分析的优点：

21. Выбор тестового покрытия с помощью анализа эквивалентности. Анализ граничных значений.
通过等价类分析选择测试覆盖率。边界值分析。

Тестовое покрытие - это одна из метрик оценки качества тестирования, представляющая собой плотность покрытия тестами требований либо исполняемого кода.
测试覆盖率 - 这是评估测试质量的指标之一，表示测试对需求或可执行代码的覆盖密度。
Полное тестовое покрытие недостижимо из-за большого (возможно бесконечного) количество значений, которые могут быть поданы на вход.
由于可能存在大量（甚至无穷多）可以输入的值，因此完全测试覆盖率是无法实现的。

Требуется выбирать для тестирования специфические значения / комбинации, которые определяет в итоге конечный набор тестов -> тестовое покрытие.
需要选择特定的值/组合进行测试，从而最终确定一个有限的测试集 -> 测试覆盖率。
Один из способов - эквивалентное разбиение + анализ граничных значений.
其中一种方法是等价划分 + 边界值分析。

Эквивалентное разбиение - если вывод системы одинаковый, то входящие значения - в одной эквивалентной области.
等价划分 - 如果系统的输出相同，则输入值属于同一等价区间。
Определяет партиции эквивалентности: наборы значений, для которых поведение системы определено как одинаковое (с точки зрения требований например)
定义等价划分：一组值，其系统行为被定义为相同（例如，从需求的角度来看）。
В каждой партиции проверяется только одно значение (может быть выбрано произвольно).
在每个划分中仅检查一个值（可以任意选择）。 Также применяется вместе с анализом граничных значений.
它还与边界值分析一起使用。

Недостаток: мы можем сказать, что два значения принадлежат к одной партиции, а на самом деле система возьмет и поведет себя по-разному, но мы это не проверим - упущенный баг.
缺点：我们可能会说两个值属于同一划分，但实际上系统可能会表现出不同的行为，而我们无法验证这一点 - 这就是漏掉的缺陷。Так что тестировать одно значение - не самый хороший вариант. Если тесты автоматизированы, выполняются быстро и наборы значений конечен - лучше протестировать все.
所以测试一个值并不是最好的选择。如果测试是自动化的、执行快速且值集是有限的，最好测试所有值。

Анализ граничных значений - определение партиций эквивалентности включает в себя определение граничных значений партиции. Это могут быть конкретные значения или бесконечные (обычно не учитываются).
边界值分析 - 确定等价划分包括确定划分的边界值。这些可以是特定值或无穷大值（通常不考虑）。

Базовы подход (протестировать на границах, на приграничных значениях и на каком-нибудь значении из области)
基本方法（在边界值、临近边界值和区间内的某个值上进行测试）。

Недостатки: не всегда легко определить границы (легко: int значения, нелегко: номер телефонов), спецификация не всегда описывает граничные значения, длину поля.
缺点：并非总是容易确定边界（易于确定：int 值，难以确定：电话号码），而且规范并不总是描述边界值和字段长度。

22. Выбор тестового покрытия с помощью таблицы решений.
通过决策表选择测试覆盖率。

Тестовое покрытие - это одна из метрик оценки качества тестирования, представляющая собой плотность покрытия тестами требований либо исполняемого кода.
测试覆盖率 - 这是评估测试质量的指标之一，表示测试对需求或可执行代码的覆盖密度。
Полное тестовое покрытие недостижимо из-за большого (возможно бесконечного) количество значений, которые могут быть поданы на вход.
由于可能存在大量（甚至无穷多）可以输入的值，因此完全测试覆盖率是无法实现的。

Одним из способов определения какие комбинации значений надо проверить - таблица решений.
确定需要检查哪些值组合的方法之一是决策表。
Можно сказать: один из вариантов составления тест-кейсов. Состоит из (input) Условия и (output) Действия - берутся из требований, по факту - реакция системы.
可以说，这是制定测试用例的一种选择。它由（输入）条件和（输出）动作组成，源自需求，实际上是系统的反应。

Таблица помогает определить минимальное количество тестов, покрывающее все возможные варианты комбинаций исходных условий. Используется в системах со сложной логикой, представляет собой описание конечного автомата.
此表有助于确定覆盖所有可能的输入条件组合的最小测试数量。它用于具有复杂逻辑的系统，描述了有限状态机。

Пример проверки поля “Пароль”. Т - true, F - False, - можно не проверять, V - ок, X - не ок
“密码”字段检查示例。T - 真，F - 假，- 可不检查，V - 可以，X - 不可以

Условия          
Состоит из 12 и больше символов T F T F T
Содержит буквы и цифры T T F F T
Не совпадает с предыдущим T — — — F
Деиствия          
Пароль действительный V X X X X

Упрощение (сокращение количества комбинаций) произошло за счет того, что условие “не совпадает с предыдущим” можно не проверять, если одно из предшествующих условий false.
简化（减少组合数量）是因为如果先前的条件之一为假，则可以不检查条件“与前一个不匹配”。

23. Выбор тестового покрытия с помощью диаграммы состояний и таблицы переходов.
通过状态图和转换表选择测试覆盖率。

Тестовое покрытие - это одна из метрик оценки качества тестирования, представляющая собой плотность покрытия тестами требований либо исполняемого кода.
测试覆盖率 - 这是评估测试质量的指标之一，表示测试对需求或可执行代码的覆盖密度。
Полное тестовое покрытие недостижимо из-за большого (возможно бесконечного) количество значений, которые могут быть поданы на вход.
由于可能存在大量（甚至无穷多）可以输入的值，因此完全测试覆盖率是无法实现的。

Одним из способов определения какие комбинации значений надо проверить - таблица переходов. Описывает смену состояний системы. Определены все события, которые возникают во время работы приложения, и как приложение реагирует на эти события.
确定需要检查哪些值组合的方法之一是状态转移表。它描述了系统状态的变化。定义了在应用程序运行期间发生的所有事件，以及应用程序如何对这些事件做出反应。

Пример диаграммы состояний
状态图示例

Ноды - состояния, над стрелками - события (то что заставляет систему сменить состояние) / действия (было инициировано сменой состояния). По идее диаграмма не закончена, так как не все состояния имеют пути до точки выхода.
节点 - 状态，箭头上方 - 事件（使系统改变状态的原因）/ 动作（由状态变化引发）。实际上，图表并不完整，因为并非所有状态都有通往出口的路径。

По полученной диаграмме состояний можно составить таблицу переходов.
根据得到的状态图，可以构建转移表。

Таблица переходов состоит из четырех столбцов:
转移表由四列组成：

Текущее состояние Событие Действие Следующее состояние
null giveinfo startPay Timer Made
null pay Money — null
null print — null
null giveTicket   null
null cancel   null
null PayTimerExpires 1 null

… Продолжение таблицы … … 表格继续 ..

Для заполнения таблицы переходов берутся все состояния и все события / действия, далее применяется декартово произведение (сочетание каждого с каждым).
填充转移表时，获取所有状态和所有事件/动作，然后应用笛卡尔积（每个与每个的组合）
Каждая пара состояние + событие / действие - одна строка в таблицы.
每对状态 + 事件/动作都是表中的一行。
Если такое событие / действие для данного состояния невозможно, в следующее состояние вносится текущее состояние (в примере так, но вообще это не совсем корректно) или “Неопределенно” (так корректнее).
如果对于该状态，事件/动作是不可行的，则在下一个状态中输入当前状态（在示例中如此，但这并不完全正确），或者“未定义”（这样更正确）。

Можно ограничиться тестирование валидных комбинаций (переход в состояние определен), но если есть время - стоит покрыть тестами и невалидные (переход в “Неопределенно”) кейс - негативное тестирование.
可以限制测试有效组合（状态转移已定义），但如果有时间，值得测试无效组合（转移到“未定义”状态）- 负面测试。

24. Выбор тестового покрытия с помощью функционального тестирования.
通过功能测试选择测试覆盖率。

Функциональное тестирование проводится на основе сценариев использования системы, соответственно проверяются функции системы, начиная с интерфейса пользователя.
功能测试是在系统使用场景的基础上进行的，因此从用户界面开始检查系统的功能。
Какой-то устоявшийся функционал может автоматизироваться, при добавлении нового функционала он изначально проверяется вручную, далее может быть также автоматизирован.
某些成熟的功能可以实现自动化，当添加新功能时，首先手动检查，然后也可以自动化。

Например:
例如： У нас есть список, по которому можно делать поиск. И на это у нас есть автоматизированные тесты. Тут программист решил сделать ещё фильтрацию по тегам.
我们有一个可以搜索的列表，并且为此有自动化测试。在这里，程序员决定添加基于标签的过滤功能。

Сначала он проверяет в ручную, что фильтрация происходит, а уже после пишет автоматизированные тесты, чтобы удостовериться в своей правоте.
他首先手动检查过滤功能是否正常，然后再编写自动化测试以确保其正确性。

Одной из программ для функционального тестирования web-сайтов является Selenium
用于网站功能测试的程序之一是 Selenium。

25. Библиотека JUnit. Класс junit.framework.Assert.
JUnit库。junit.framework.Assert类。

JUnit - это open-source фреймворк (где-то пишут что библиотека) для модульного тестирования. Последняя версия является 5
JUnit是一个开源框架（有些地方称为库）用于单元测试。最新版本是5。

Возможности JUnit:
JUnit的功能：

Класс junit.framework.Assert - предоставляет методы для тестирования и сравнения объектов. Например, через assertEquals(1, getNum()) можно проверить что значение переданное совпадает с запланированным результатом.
类junit.framework.Assert提供用于测试和比较对象的方法。例如，通过assertEquals(1, getNum())可以检查传递的值是否与预期结果匹配。

Пример шаблона для теста:
测试的示例模板：

@Test
public void checkSomething() {
    assertAll(
        () -> assertEquals(1, getNum()),
        () -> assertTrue(true)
    );
}

assertAll - нужен для того, чтобы выполнились все ассерты, даже если один из них фейланется.
assertAll - 用于确保所有断言都执行，即使其中一个失败。

26. Библиотека JUnit. Основные аннотации для исполнения тестов.
JUnit库。执行测试的主要注解。

JUnit - это open-source фреймворк (где-то пишут что библиотека) для модульного тестирования. Последняя версия является 5
JUnit是一个开源框架（有些地方称为库）用于单元测试。最新版本是5。

Возможности JUnit:
JUnit的功能：

27. Библиотека JUnit. Дополнительные возможности, запуск с параметрами.
JUnit库。附加功能，带参数执行。

JUnit - это open-source фреймворк (где-то пишут что библиотека) для модульного тестирования. Последняя версия является 5
JUnit是一个开源框架（有些地方称为库）用于单元测试。最新版本是5。

Возможности JUnit:
JUnit的功能：

Дополнительные возможности:
附加功能：

Например, аннотации @Test можно задать дополнительные параметры. Указать класс исключения @Test(expected = NullPointerException.class) и тестировать метод на исключения.
例如，@Test注解可以设置额外的参数。指定异常类@Test(expected = NullPointerException.class)并对方法进行异常测试。

Указать таймаут: @Test(timeout = 1) значит тест будет завален, если выполняется больше 1 мс
指定超时：@Test(timeout = 1)意味着如果测试执行超过1毫秒，则测试将失败。

Также можно группировать тесты, это делается с помощью классов. Каждый класс = 1 группа. Чтобы сделать подгруппу, создается класс внутри другого класса.
还可以对测试进行分组，这通过类来实现。每个class = 1组。要创建子组，可以在另一个类内部创建类。

Параметризованные тесты
参数化测试

Значит тест будет у нас с определенными входными параметрами, они могут быть считаны например из CSV файла или перечислены в коде вручную.
这意味着我们的测试将具有特定的输入参数，这些参数可以从CSV文件读取或在代码中手动列出。

@ParametrizedTest 
@ValueSource(ints = {1, 2, 3, 4}) - где ints - указывается тип 
public void test(int arg){
    ...
}

28. Анализ эквивалентности с использованием JUnit.
使用JUnit进行等价类分析。

Анализ эквивалентности: вместо тестирования всех возможных значений определяются группы входных параметров, которые одинаково влияют на систему. В каждой группе выделяются граничные значения, для которых составляются тестовые сценарии.
等价类分析： 与其测试所有可能的值，不如确定对系统产生相同影响的输入参数组。在每组中，识别边界值，并为这些值编写测试场景。

Поскольку для каждой группы граничных значений результат воздействия на систему будет схожий, можно использовать параметризованные тесты.
由于每组边界值对系统的影响结果相似，因此可以使用参数化测试。

Но все равно JUnit не предоставляет возможности выполнить анализ эквивалентности на входных значениях, это задача уже разработчика тестов.
但JUnit仍然不提供在输入值上执行等价类分析的功能，这是测试开发者的任务。

@ParametrezideTest 
@ValuesSource(ints = {-1, 0, 1, Integer.MAX_VALUE}) 
void test (int num) { 
    assertTrue(Alg.checkIsNegative(num));
}

29. Тестирование алгоритмов с использованием JUnit.
使用JUnit进行算法测试。

JUnit - это open-source фреймворк (где-то пишут что библиотека) для модульного тестирования. Последняя версия является 5
JUnit是一个开源框架（有些地方称为库）用于单元测试。最新版本是5。

Возможности JUnit:
JUnit的功能：

Для тестирования алгоритмов удобнее всего использовать @ParametrizedTest проверяя пары входных и выходных значений. Ещё в этом случае удобно считывать данные из файла, что не изменять код, а только подавать значения (методом черного ящика) @CSVFileSource(files = “file.csv”)
要测试算法，最方便的是通过检查输入和输出值对来使用@ParametrizedTest。同样在这种情况下，可以很方便地从文件中读取数据，而无需更改代码，而仅提供值（使用黑盒方法）@CSVFileSource(files = “file.csv”)

Для тестирования алгоритма в изоляции от зависимостей, можно применять заглушки. Их можно реализовать средствами языка, однако удобнее использовать специальные библиотеки, облегчающие их написание, например Mockito.
要独立于依赖项来测试算法，可以使用存根。它们可以使用语言来实现，但使用特殊的库更方便，使它们更容易编写，例如 Mockito。

@ParametrizedTest 
@ValueSource(ints = 0) 
public void test (int result) {
    Student student = Mockito.mock(Student.class) 
    Mockito.when(student.getDolgs()).thenReturn(result); 
    assertEquals(“Обучается”, ISU.getStatus(student)) 
}

30. Модульное тестирование доменной модели с использованием JUnit.
使用JUnit对领域模型进行单元测试。

Задача модульного тестирования является проверка работоспособности модуля, изолированного от других модулей. Так как в доменной модели модули обычно связаны во время исполнения, целесообразно использовать заглушки, для реализации которых служит библиотека Mockito
单元测试的任务是验证模块的功能，模块应与其他模块隔离。由于在领域模型中，模块在执行时通常是相互关联的，因此使用存根是合理的，Mockito库可用于实现这些存根。

В остальном тестирование модуля доменной модели с точки зрения написания кода не очень отличается от тестирования алгоритма - если результаты работы модуля хорошо описываются таблицей решений или парами входных и выходных значений, целесообразно использовать параметризованные тесты.
除此之外，从代码编写的角度来看，领域模型模块的测试与算法测试并没有太大区别——如果模块的工作结果可以很好地用决策表或输入和输出值对来描述，那么使用参数化测试是合理的。

Помимо этого, часто целесообразно не создавать инстанции тестируемого модуля в каждом отдельном тесте, а тестировать одну инстанцию, которая инициализируется в методе с аннотацией @BeforeAll и деинициализируется в методе с аннотацией @АfterAll
此外，通常不必在每个单独的测试中创建被测试模块的实例，而是可以测试一个实例，该实例在带有注解@BeforeAll的方法中初始化，并在带有注解@AfterAll的方法中反初始化。

Часто доменная модель предполагает обработку пользовательских (или стандартных) исключений. Для этого в JUnit существует метод assertThrows, который принимает ссылку на класс исключения и анонимную функцию или инстанцию Executable. И возвращает полученное исключение, параметры которого можно проверять в дальнейшем.
领域模型通常需要处理用户（或标准）异常。为此，JUnit提供了assertThrows方法，该方法接受异常类的引用和匿名函数或Executable实例，并返回捕获到的异常，后续可以检查该异常的参数。

@Test
void throwsOnInvalidPhoneNumber() {
    ContactBook contactBook = Mockito.mock(ContactBook.class);
    Mockito.when(contactBook.getNumberByName("Mom")).thenReturn("abcdefg");
    Phone phone = new Phone(contactBook);
    Exception exception = assertThrows(IllegalCharacterInNumberException.class, () -> {
        phone.call("Mom”);
    });
    String expectedMessage = "Illegal character 'a', the phone number should contain only digits, or ’+’ characters";
    String actualMessage = exception.getMessage();
    assertTrue(actualMessage.contains(expectedMessage));
}

31. Система Selenium. Архитектура, основные команды написания сценариев.
Selenium系统。架构与编写脚本的主要命令。

Система Selenium - набор средств автоматизации
Selenium系统 - 一套自动化工具

Предназначен для тестирования web-приложений. Является кроссбраузерным (использует драйвера браузеров, чтобы с ними взаимодействовать. Обычно для корректной работы ещё нужно, чтобы версия вашего браузера совпадала с версией драйвера иначе будет ошибка при попытке запуска).
用于测试Web应用程序。它是跨浏览器的（使用浏览器驱动程序与浏览器进行交互。通常，为了正确工作，您的浏览器版本必须与驱动程序版本相匹配，否则在启动时会出现错误）。

Позволяет разрабатывать сценарии на многих языках:
允许在多种语言上开发脚本：

Selenium Grid - позволяет запускать тесты на разных машинах в разных браузерах да и к тому же параллельно. В нем присутствует HUB и NODE.
Selenium Grid - 允许在不同的机器上以并行方式在不同的浏览器中运行测试。它包含HUB和NODE。

HUB - это центральная точка, которая принимает запросы и направляет их к NODE. Так скажем командный пункт. В GRID может быть ТОЛЬКО ОДИН хаб.
HUB - 这是一个中心点，接收请求并将其转发到NODE。可以说它是指挥中心。在GRID中只能有一个HUB。

NODE - selenium инстанс, который запускает команды, из HUB’a. Они могут запускаться на разных операционных системах с разными браузерами.
NODE - 是一个Selenium实例，它从HUB执行命令。它们可以在不同操作系统上使用不同浏览器运行。

Selenium WebDriver - это программная библиотека для управления браузерами.
Selenium WebDriver - 是一个用于控制浏览器的程序库。

WebDriver представляет собой семейство драйверов для различных браузеров плюс набор клиентских библиотек для этих драйверов на разных языках программирования.
WebDriver是针对不同浏览器的一组驱动程序及其在不同编程语言中的客户端库。

HTTP клиент шлет запрос к веб драйверу, он превращает их в веб сокетные и шлет браузеру. Браузер это дело обрабатывает
HTTP客户端向WebDriver发送请求，WebDriver将其转换为WebSocket请求并发送给浏览器。浏览器处理该请求。

Selenium IDE - расширение для браузера. Позволяет тречить состояние тестов. Записывать действия.
Selenium IDE - 是一个浏览器扩展。它允许跟踪测试的状态。可以录制操作。

Основные команды:
基本命令：

32. Система Selenium. Assertion & Verification. Команды.
Selenium系统。断言与验证。命令。

Система Selenium - набор средств автоматизации
Selenium系统 - 一套自动化工具

Предназначен для тестирования web-приложений. Является кроссбраузерным (использует драйвера браузеров, чтобы с ними взаимодействовать. Обычно для корректной работы ещё нужно, чтобы версия вашего браузера совпадала с версией драйвера иначе будет ошибка при попытке запуска).
用于测试Web应用程序。它是跨浏览器的（使用浏览器驱动程序与浏览器进行交互。通常，为了正确工作，您的浏览器版本必须与驱动程序版本相匹配，否则在启动时会出现错误）。

Позволяет разрабатывать сценарии на многих языках:
允许在多种语言上开发脚本：

Assertion and Verification: Эти команды используются для проверки содержимого элемента интерфейса. Можно проверить текст страницы, присутствие элемента, наличие его атрибутов.
这些命令用于检查界面元素的内容。可以检查页面文本、元素的存在性及其属性的存在性。 Если падает Verification - тест ПРОДОЛЖАЕТСЯ
如果验证失败 - 测试继续 Если падает Assertion - тест ФЕЙЛИТСЯ
如果断言失败 - 测试失败

Команды Verification:

Команды Assertion (те же самые):

33. Система Selenium. Команды wait.
Selenium系统。等待命令。

Система Selenium - набор средств автоматизации
Selenium系统 - 一套自动化工具

Предназначен для тестирования web-приложений. Является кроссбраузерным (использует драйвера браузеров, чтобы с ними взаимодействовать. Обычно для корректной работы ещё нужно, чтобы версия вашего браузера совпадала с версией драйвера иначе будет ошибка при попытке запуска).
用于测试Web应用程序。它是跨浏览器的（使用浏览器驱动程序与浏览器进行交互。通常，为了正确工作，您的浏览器版本必须与驱动程序版本相匹配，否则在启动时会出现错误）。

Позволяет разрабатывать сценарии на многих языках:
允许在多种语言上开发脚本：

Команды wait:

34. Система Selenium. Selenium RC, WebDriver, Grid.
Selenium系统。Selenium RC、WebDriver和Grid。

Selenium - это инструмент для автоматизированного управления браузерами. Наиболее популярной областью применения Selenium является автоматизация тестирования веб-приложений.
Selenium是用于自动化浏览器控制的工具。其最常见的用途是自动化测试Web应用程序。

Selenium WebDriver

Selenium RC

Аббревиатура RC в названии этого продукта расшифровывается как Remote Control, то есть это средство для «удалённого» управления браузером. Эта версия с функциональной точки зрения значительно уступает WebDriver. Сейчас она находится в законсервированном состоянии, не развивается и баги не исправляются. Всем, кто сталкивается с ограничениями Selenium RC, предлагается переходить на использование WebDriver
RC是Remote Control的缩写，意指“远程控制”浏览器。这一版本在功能上远不如WebDriver。目前，Selenium RC已停止开发和维护，bug不再修复。遇到Selenium RC限制的用户建议迁移到WebDriver。

Selenium Grid

Selenium IDE - плагин к браузеру Firefox (и не только - прим. Автора т.к. есть для Chrome), который может записывать действия пользователя, воспроизводить их, а также генерировать код для WebDriver или Selenium RC. В котором выполняются те же самые действия. В общем, это «Selenium-рекордер».
Selenium IDE是Firefox浏览器的插件（现也支持Chrome等浏览器）。它可以记录用户的操作、回放操作，并生成用于WebDriver或Selenium RC的代码，执行相同的操作。总的来说，它是“自动化测试记录器”。

35. Язык XPath. Основные конструкции, оси.
XPath语言。主要结构与轴。

XPath - это язык запросов к элементам XML-документа.
XPath 是用于查询XML文档元素的语言。

Основные конструкции:
主要语法结构：

Выражение Результат
div Выбирает все узлы с именем “div”
/ Выбирает от корневого узла
// Выбирает узлы от текущего узла, соответствующего выбору, независимо от их местонахождения
. Выбирает текущий узел
.. Выбирает родителя текущего узла
@ Выбирает атрибуты

ОСИ - это базы языка XPath. Для некоторых осей существуют сокращенные обозначения.
轴 - XPath语言的基础。某些轴有简写形式。

Системные функции:
系统函数

36. Язык XPath. Системные функции.
XPath语言。系统函数。

XPath - это язык запросов к элементам XML-документа.
XPath 是用于查询XML文档元素的语言。

Основные конструкции:
主要语法结构：

Выражение Результат
div Выбирает все узлы с именем “div”
/ Выбирает от корневого узла
// Выбирает узлы от текущего узла, соответствующего выбору, независимо от их местонахождения
. Выбирает текущий узел
.. Выбирает родителя текущего узла
@ Выбирает атрибуты

ОСИ - это базы языка XPath. Для некоторых осей существуют сокращенные обозначения.
轴 - XPath语言的基础。某些轴有简写形式。

Системные функции:
系统函数

37. Язык XPath. Функции с множествами.
XPath语言。集合函数。

38. Язык XPath. Строковые, логические и числовые функции.
XPath语言。字符串、逻辑和数字函数。

39. Apache JMeter. Архитектура, Элементы тестового плана. Последовательность выполнения.
Apache JMeter。架构、测试计划元素。执行顺序。

Архитектура
架构

Тестовый план: 测试计划
Тестовый план является основным модулем организации тестирования в JMeter и определяет все элементы тестирования, которые необходимо выполнить. Он состоит из нескольких элементов, каждый из которых отвечает за свою функцию. 测试计划是JMeter中组织测试的核心单元，定义了所有需要执行的测试元素。它由多个元素构成，每个元素负责不同的功能。

Порядок выполнения

  1. Конфигурационные элементы
    配置要素
  2. Препроцессоры (Pre-Processors)
    预处理器
  3. Таймеры (Timers)
    定时器
  4. Семплеры (Sampler)
    采样器
  5. Постпроцессоры (Post-Processors)
    后处理器
  6. Assertions
    断言

40. Apache Jmeter. Дополнительные возможности. Распределенное тестирование.
Apache JMeter。附加功能。分布式测试。

Дополнительные возможности:
附加功能：

Распределенное тестирование:
分布式测试： Один компьютер не всегда может эмулировать необходимую в тестовых целях нагрузку, в связи с чем возникает необходимость генерации тестовой нагрузки с нескольких узлов.
一台计算机无法总是模拟测试所需的负载，因此需要通过多个节点生成测试负载。

Для этого необходимо:
为此需要：

ВНИМАНИЕ! При ответах на вопросы 21-40 обязательно использование примера (ов).
注意！回答21-40题时，需要举例。

41*. Область деятельности тестирования безопасности. Риски безопасности. Цифровые активы (digital assets). Методы доступа и обеспечения безопасности. Политики безопасности
安全测试的范围。安全风险。数字资产。访问和安全方法。安全政策

Область деятельности:
领域活动：

Риски безопасности - отдельная группа рисков в разработке и эксплуатации ПО:
安全风险 - 软件开发和操作中的独立风险组：

Цифровые активы
数字资产

Типичные методы доступа:
典型访问方法：

Обеспечение безопасности:
安全保障：

Политики безопасности
安全政策

Примеры: 示例：

42*. Тестирование безопасности. Практически используемые методы. Безопасный код. Основные подходы. Common Weakness Enumeration 安全测试。使用的实用方法。安全代码。基本方法。常见弱点枚举

Как и тестирование в целом, не может найти все дефекты (уязвимости) безопасности
安全测试与整体测试一样，无法发现所有缺陷（安全漏洞）

Безопасный код
安全编码

Статические анализаторы и статическое тестирование позволяют найти основные дефекты
静态分析器和静态测试可以找到主要缺陷

CERT Top 10 Secure Coding Practices:
CERT十大安全编码实践：

Common Weakness Enumeration
常见弱点枚举（CWE）

Общая база, уязвимости отсортированы по системам, языкам программирования
总库，漏洞按系统和编程语言排序

43*. Fuzzy testing (Фаззинг). Типы фаззинга
模糊测试（Fuzzing）。模糊测试的类型

Нечеткое тестирование.
模糊测试

Фаззинг - это метод автоматического тестирования программного обеспечения, который заключается в предоставлении некорректных, неожиданных или случайных данных в программу и ее функции.
模糊测试是自动化软件测试的一种方法，它通过向程序及其函数提供不正确、意外或随机的数据来进行测试。
В процессе тестирования отслеживается поведение программы, например, чтобы она не выбрасывала исключений, не пыталась завершиться с ошибкой или не возникло утечки памяти.
在测试过程中，跟踪程序行为，例如确保它不会抛出异常、不会尝试以错误结束或不会出现内存泄漏。

Типы:
模糊测试类型：

44*. Penetration Testing. Тестирование на проникновение. Dynamic Application Security Testing (DAST) Tools

Penetration testing (тестирование на проникновение) - метод оценки безопасности компьютерных систем или сетей средствами моделирования атаки злоумышленника.
渗透测试 - 一种评估计算机系统或网络安全的方法，通过模拟攻击者的攻击来进行测试。

Примером могут служить: 例如： Auth, ddos, password steal и т.д.

DAST Tools - это средства для динамического тестирования безопасности приложения.
DAST工具 - 用于动态应用程序安全测试的工具。
Они выполняют автоматическое сканирование, которое имитирует вредоносные внешние атаки с попытками эксплуатации распространенных уязвимостей.
它们执行自动扫描，模拟恶意的外部攻击，试图利用常见漏洞。
Их задача - обнаружить незапланированные результаты раньше, чем это сделает злоумышленник.
它们的任务是尽早发现未预期的结果，防止攻击者利用这些结果。
Чтобы обнаружить уязвимости, средства DAST проверяют все токи доступа по HTTP, а также моделируют случайные действия и работу пользователей.
为了发现漏洞，DAST工具会检查所有HTTP访问令牌，并模拟随机行为和用户操作。

Незаконно это использовать не для себя. Иначе только с письменного разрешения!
如果不是为了自己使用，则是非法的！否则，必须获得书面许可！

ПО:

Примеры:
示例：

45*. Организация тестов безопасности в циклах и типах разработки. Тестирование общих механизмов безопасности.
按开发周期和类型组织安全测试。测试常见的安全机制。

Организация тестов безопасности в цикле разработки
在开发周期中组织安全测试

Особенности при последовательной разработке:
顺序开发的特点：

Особенности при итеративной или инкрементальной разработке:
迭代或增量开发的特点：

Тестирование общих механизмов:
对通用机制的测试：