что такое голден тестирование
Для чего нужны «золотые сигналы» мониторинга и SRE?
Прим. перев.: То, что сегодня принято называть SRE (Site Reliability Engineering — «обеспечение надежности информационных систем»), включает в себя большой спектр мероприятий по эксплуатации программных продуктов, направленных на достижение ими необходимого уровня надежности. Мониторинг — одно из ключевых мероприятий, а «золотые сигналы» образуют главные метрики, которые должны в нём учитываться. Не найдя на Хабре ни одного материала про них, мы решили перевести небольшую заметку от авторов платформы для управления инцидентами (VictorOps), дающую представление общее представление об этом подходе.
Эффективный site reliability engineering (SRE) опирается на глубокое понимание базовой инфраструктуры сервиса и архитектуры. Повышение прозрачности состояния приложения и инфраструктуры — это только начало проактивной работы над созданием надежных систем. При этом наилучшей отправной точкой для мониторинга состояния систем считаются так называемые «четыре золотых сигнала» (four golden signals) SRE. Наладив эти четыре базовых метода мониторинга, можно переходить к дальнейшему повышению прозрачности системы.
Повышение прозрачности вкупе с эффективными методами совместной работы позволяет командам SRE оперативно отслеживать работу систем и принимать меры для устранения последствий инцидентов, повышая общую эффективность методов мониторинга и оповещения. Золотые сигналы SRE помогают командам выявлять любые потенциальные слабые места в надежности, позволяя сосредоточиться над устранением проблем в инфраструктуре. Давайте же исследуем взаимосвязь между методами мониторинга и командами SRE и посмотрим, какое влияние золотые сигналы оказывают на процесс.
Мониторинг и SRE
В III части нашего DevOps-словаря мы исследовали интернет, пытаясь найти определение SRE. Согласно соответствующей статье в Wikipedia, «Ben Treynor, основатель Site Reliability Team в Google [говорит], что SRE — „это то, что получается, когда software engineer занимается тем, что раньше называлось эксплуатацией“». SRE сочетает задачи и возможности программной инженерии с проблемами эксплуатации IT и помогает находить решения для вопросов, связанных с надежностью. Понятно, что команды SRE должны мониторить свои сервисы для выявления областей, в которых можно повысить надежность.
Именно в этом и заключается задача мониторинга применительно к командам SRE. Он занимает лишь небольшую часть в создании высокопрозрачных систем, однако это важный элемент для понимания состояния приложений и инфраструктуры. Четыре золотых сигнала мониторинга и SRE обеспечивают базовый уровень прозрачности в отношении надежности всего, что вы создаете. Достигнув комфортного уровня наблюдаемости состояния золотых сигналов, можно использовать эту дополнительную информацию для более углубленного анализа с помощью инструментов для мониторинга.
Теперь, когда мы определились с важностью мониторинга золотых сигналов SRE, давайте обратимся к реальным метрикам, составляющим их.
Четыре золотых сигнала мониторинга
В начале пути по совершенствованию усилий по мониторингу бывает непросто понять, с чего следует начинать. Четыре золотых сигнала SRE и мониторинга впервые были приведены в книге Google о SRE, и в настоящее время активно используются многими командами. С них отлично начинать, поскольку они помогают выделить основные метрики, которые следует отслеживать всегда.
Итак, давайте рассмотрим золотые сигналы и разберемся, почему их мониторинг является неотъемлемым элементом в обеспечении надежности любой системы.
1. Задержка (Latency)
Сколько времени занимает обработка запроса? Определите ориентир для задержек, типичных для успешных запросов, и сравните его с задержками для неуспешных запросов. Отслеживание задержек, вызванных ошибками, позволяет решить любые вопросы, связанные со скоростью выявления инцидента и реакции на него.
2. Трафик (Traffic)
Этот сигнал не требует особых пояснений. Какое влияние на систему оказывает количество пользователей или число транзакций, проходящих через сервис? В зависимости от функциональности сервиса измерение трафика может существенно отличаться от компании к компании. Отслеживая взаимодействие с реальными пользователями и трафик, можно лучше понять, как конечные пользователи воспринимают сервис, и получить представление о том, как системы ведут себя в условиях стресса.
3. Ошибки (Errors)
Конечно, каждая команда должна следить за ошибками. Независимо от того, вызваны ли ошибки заданной вручную логикой или автономны (вроде неудавшегося HTTP-запроса), SRE-команды должны отслеживать их. Многие SRE-команды используют специальное ПО для управления инцидентами для оповещений о критических ошибках, поиска их причин и проведения работ по устранению последствий.
4. Насыщенность (Saturation)
Каждая команда должна следить за загруженностью своей системы. Важно задать метрику для насыщенности, которая бы означала, что сервис достиг максимума своих возможностей. Большинство сервисов начинают терять производительность еще до того, как загрузка достигнет 100%, поэтому понимание функциональности вашей собственной системы важно для определения ориентира насыщенности, который имеет смысл.
Установив правила мониторинга и оповещений для четырех золотых сигналов, вы охватите большинство ключевых инцидентов в системе. Однако чтобы приступить с созданию проактивной системы для мониторинга и SRE, придется копнуть еще глубже.
Прим. перев.: Как пример иллюстрации dashboard’а с графиками «золотых сигналов» приведём результат соответствующей конфигурации мониторинга для Kubernetes из этой статьи от Sysdig:
Прим. перев.: А вот более наглядное представление о золотых сигналах от Denise Yu, которую можно использовать как удобную памятку:
Проактивный SRE выходит за рамки золотых сигналов
Мониторинг золотых сигналов — отличное начало для анализа инцидентов в сервисе, однако его не достаточно. Опытные команды SRE проактивно изучают свои системы с помощью многочисленных дополнительных методов. Проводя организованные испытания на подготовительных этапах и в production, команды SRE активно изучают свои системы и используют получаемую информацию для повышения надежности сервисов.
Chaos Engineering
Хаос-инжиниринг — это дисциплина, применяемая командами для испытания своих систем с целью упреждающего обнаружения слабых мест и уязвимостей. Вручную вводя хаос в сервис, можно посмотреть, как именно система реагирует на различные обстоятельства.
Прим. перев.: Подробнее о таком подходе читайте в статье «Chaos Engineering: искусство умышленного разрушения» (часть 1 и часть 2).
Игровые дни (Game Days)
В то время как хаос-инжиниринг направлен на понимание системы, игровые дни помогают понять персонал. Они используются для проверки устойчивости команды, когда речь идет о реагировании на инциденты и устранении их последствий. Результаты игровых дней можно использовать для разработки более эффективных процессов или определения потребности в новых инструментах, повышающих эффективность персонала.
Синтетический мониторинг
Синтетический мониторинг позволяет командам создавать искусственных пользователей и имитировать их поведение с помощью сервиса. Можно задать определенные поведенческие паттерны и понаблюдать за тем, как система ведет себя в условиях данной нагрузки. Синтетический мониторинг — отличный метод для детального тестирования и определения надежности конкретных сервисов в рамках всей системы.
Любая команда, стремящаяся визуально отслеживать состояние системы, обязана следить за золотыми сигналами SRE. Но представление о состоянии и общей надежности системы — вовсе не то же самое, что работа над повышением ее надежности. В современной экосистеме высокораспределенных систем и стремительного развертывания перед командами SRE стоит непростая задача. Золотые сигналы мониторинга и SRE могут стать той отправной точкой, с которой начнется дальнейшее совершенствование в рамках SRE.
Фундаментальная теория тестирования
В тестировании нет четких определений, как в физике, математике, которые при перефразировании становятся абсолютно неверными. Поэтому важно понимать процессы и подходы. В данной статье разберем основные определения теории тестирования.
Перейдем к основным понятиям
Тестирование программного обеспечения (Software Testing) — проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.
Цель тестирования — проверка соответствия ПО предъявляемым требованиям, обеспечение уверенности в качестве ПО, поиск очевидных ошибок в программном обеспечении, которые должны быть выявлены до того, как их обнаружат пользователи программы.
Для чего проводится тестирование ПО?
Принципы тестирования
QC (Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта.
К задачам контроля качества относятся:
К задачам обеспечения качества относятся:
Верификация и валидация — два понятия тесно связаны с процессами тестирования и обеспечения качества. К сожалению, их часто путают, хотя отличия между ними достаточно существенны.
Верификация (verification) — это процесс оценки системы, чтобы понять, удовлетворяют ли результаты текущего этапа разработки условиям, которые были сформулированы в его начале.
Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.
Пример: когда разрабатывали аэробус А310, то надо было сделать так, чтобы закрылки вставали в положение «торможение», когда шасси коснулись земли. Запрограммировали так, что когда шасси начинают крутиться, то закрылки ставим в положение «торможение». Но вот во время испытаний в Варшаве самолет выкатился за пределы полосы, так как была мокрая поверхность. Он проскользил, только потом был крутящий момент и они, закрылки, открылись. С точки зрения «верификации» — программа сработала, с точки зрения «валидации» — нет. Поэтому код изменили так, чтобы в момент изменения давления в шинах открывались закрылки.
Документацию, которая используется на проектах по разработке ПО, можно условно разделить на две группы:
Этапы тестирования:
Программный продукт проходит следующие стадии:
Требования
Требования — это спецификация (описание) того, что должно быть реализовано.
Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.
Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.
Атрибуты отчета о дефекте:
Жизненный цикл бага
Severity vs Priority
Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.
Градация Серьезности дефекта (Severity):
Градация Приоритета дефекта (Priority):
Тестовые среды
Основные фазы тестирования
Основные виды тестирования ПО
Вид тестирования — это совокупность активностей, направленных на тестирование заданных характеристик системы или её части, основанная на конкретных целях.
Автор книги «A Practitioner’s Guide to Software Test Design», Lee Copeland, выделяет следующие техники тест-дизайна:
Методы тестирования
Тестирование белого ящика — метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.
Согласно ISTQB, тестирование белого ящика — это:
Тестирование чёрного ящика — также известное как тестирование, основанное на спецификации или тестирование поведения — техника тестирования, основанная на работе исключительно с внешними интерфейсами тестируемой системы.
Согласно ISTQB, тестирование черного ящика — это:
Тестовая документация
Тест план (Test Plan) — это документ, который описывает весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков.
Тест план должен отвечать на следующие вопросы:
Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.
Тестовый сценарий (test case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Атрибуты тест кейса:
Golden Master Testing: сложный вид рефакторинга
Просмотр шаблонов должен быть простым. На самом деле они должны быть настолько простыми, что для них нет смысла вычислять показатель сложности. В успешных приложениях, однако, это часто не так. Логика незаметно проникает в шаблоны, в то время как все внимание сосредоточено на какой-то чрезвычайной ситуации в другом месте.
Рефакторинг шаблонов может быть затруднен, когда их тестовое покрытие мрачно, что в большинстве случаев. И это правильно! Зачем беспокоиться о тестировании чего-то, что будет регулярно меняться и не должно содержать никакой логики?
Хитрость заключается в том, чтобы найти способ поставить стену за спиной, когда вы решите, что вам действительно нужно переместить логику из шаблонов в более подходящие места в вашем приложении.
Пример из реального мира
Это дает нам возможность изучить технику Golden Master с использованием реального кода, а не крошечного синтетического примера, который заставляет читателя задуматься, как перенести урок в реальный производственный код.
Изучение треков
Внимательно изучив кодовую базу, вы обнаружите большие модели, большие контроллеры и сложные представления. Например, контроллеры и представления совместно используют огромное количество переменных экземпляра.
Все это говорит о том, что могут отсутствовать абстракции и неназванные понятия, которые могли бы облегчить рассуждение о базе кода.
StatsController иллюстрирует это. Файл имеет длину более 450 строк. Он содержит 37 методов, только 17 из которых являются действиями контроллера.
Действия бывают двух видов:
Пары key=value используются для отображения диаграмм в ответах HTML. Шаблоны для них выполняют некоторые вычисления, устанавливают некоторые локальные переменные и отображают целый ряд переменных экземпляра, которые были вычислены в контроллере.
Также они дублируются.
В этом упражнении мы возьмем два очень actions_visible_running_time_data.html.erb шаблона — actions_visible_running_time_data.html.erb и actions_running_time_data.html.erb — и actions_running_time_data.html.erb все различия на один уровень вверх в контроллер. Наконец, мы удалим одно из представлений.
Подожди, что ты имеешь в виду потяните вещи в контроллер? Разве контроллер уже не слишком большой?
Кроме того, он содержит даже больше дублирования, чем шаблоны.
Это распространенное затруднение при рефакторинге. Очень часто акт рефакторинга делает вещи временно хуже. Это добавляет дублирование и сложность. Иногда может показаться, что вы переносите грязный код из одного мусорного ящика в другой. Но тогда вы вдруг обнаружите полезную абстракцию, позволяющую свернуть сложность.
Эти абстракции трудно определить, когда логика распространена. Как только все будет в контроллере, мы сможем лучше понять, что мы решаем.
Стена на спине
И так это началось…
Ой, подожди. Это не так. Мы должны убедиться, что у нас есть хорошие тесты.
Выполнение rake test занимает около 20 минут. Это слишком медленно, чтобы быть полезным для рефакторинга. Мы можем сузить это до только тестов, которые охватывают конечные точки данных диаграммы.
Самый простой способ выяснить, к каким тестам это относится — raise ‘hell’ из шаблонов erb мы ищем для рефакторинга:
Это занимает 5:17 секунд. Это не быстро, но подойдет.
Нам понадобятся лучшие тесты.
Блаженное невежество
Действия в StatsController выглядят очень сложными. Если мы напишем тесты, которые делают ошибочные или неполные предположения, мы можем ввести ошибки регрессии при рефакторинге.
Было бы менее утомительно и подвержено ошибкам просто предполагать, что то, что происходит сейчас, это именно то, что должно происходить. Если бы мы могли просто зафиксировать полный вывод key=value для конечной точки диаграммы, ее можно скопировать / вставить в тест и использовать в качестве подтверждения.
Нам даже не придется понимать, что происходит!
Характеристический тест является временной мерой. Вы, возможно, никогда не передадите его в систему контроля версий, это просто для того, чтобы вывести вас из-под контроля. Иногда вы сможете заменить его на более качественные тесты. В других случаях, например, с этими представлениями, тест будет просто упрощать представления, а затем его можно полностью удалить.
Характеризуя взгляды
Настроить
Данные о приборах генерируются относительно сегодняшней даты, поэтому вам, вероятно, потребуется изменить значение Timecop на что-то через неделю или две в будущем, чтобы запустить тесты.
Затем фактически вызовите действия контроллера:
Скопируйте received файл поверх approved файла и повторите тест, чтобы убедиться, что он пройден.
Насколько хороши эти тесты?
Это зависит от того, насколько хороши данные. У треков есть фиксаторы, и в результате мы имеем более одного пункта данных в диаграммах, поэтому давайте предположим, что все в порядке.
Рефакторинг (наконец-то!)
Мы сделаем это по одному. Вот представление времени выполнения действий :
Контроллер добавил http://test.host к сгенерированным URL. Мы можем заставить его возвращать только путь, передав ему параметр :only_path => true :
Следующие изменения еще проще. Для каждого интерполированного значения убедитесь, что контроллер устанавливает переменную экземпляра для окончательного значения:
Удалите неиспользованный шаблон и отпразднуйте.
Тогда возьмите лопату, немного пахнущих солей и приготовьтесь атаковать этого контролера. Это, однако, тема для другого поста (скоро, не волнуйтесь.)
Flutter: Golden tests — compare Widgets with Snapshots
Testing is very important to deliver apps with the best quality. In this article, I’d like to tell about one of the less known features of Widget test — Golden tests.
What is Golden test?
Golden tests are basically Widget tests. A special mather compares your widget with an image file and expects that it looks the same.
Golden files are image files that were created from a manually verified widget.
How to create Golden test?
For the sake of example let’s create a golden test for Flutter’s “Hello World” app.
In Flutter project test folder we create golden_widget_test.dart with the following code:
As you see, you start creating your Golden test as a usual Widget test by pumping your widget.
Once the widget is pumped, it is compared with the image:
How to generate Golden files?
Now it is time to generate these manually verified images. If you’d like to generate images for all your Golden tests (or update old ones), run:
the main.png file should appear in your project test folder. Do not forget to add it to version control.
For only one particular test you can run:
How to run tests?
You can run tests now as normal unit tests to verify that generated Golden files match your widget.
Complete Sample
Golden tests are helpful to check that your widgets look as expected. It doesn’t have to be the whole screen. You can create your Golden test for a part of UI as well. If in a while you change your UI, don’t forget to generate new images 😉
ksheremet/golden_test
Contribute to ksheremet/golden_test development by creating an account on GitHub.
Underhood
When you generate images, LocalFileComparator (the default Golden File comparator) is used to create/update the files on disk to match the rendering. When you run a test, LocalFileComparator loads the image file from the local file system and performs a simplistic byte-to-byte comparison of the encoded PNGs. It returns true if there is an exact match. Even though your files represent the same pixels, but are encoded differently, the test will fail.
You can override default comparator by implementing yours. For this, your comparator needs to extend class GoldenFileComparator. Then you assign an instance of that class to goldenFileComparator. The code snippet looks like this:
Introduction to golden testing
Published on December 4, 2017
Golden tests are like unit tests, except the expected output is stored in a separate file. I learned about them in 2010 from Max Grigorev at ZuriHac.
Let’s say you want to test Python’s json module. One way to do that would be to encode an object and compare the result to a reference string:
Alternatively, you could create a file with contents
and read it to know the expected output:
The file example1.json is called a golden file.
Here are some advantages of golden tests over ordinary unit tests:
If the expected output is large in size, it may be impractical to put it inside the source code.
No need to escape quotes or binary data in the expected output.
When you add a new test, your testing framework can generate the missing golden file from the current output of the function.
It is best if you can write down the expected output without looking at the actual output, but it is not always possible. The output may be too big to type it character by character, or it may be hard to predict. For instance, in the json example, you couldn’t tell in advance whether there would be spaces between array elements or not. So often what you do is launch an interactive interpreter (if your language of choice even has one), run the function, and then copy-paste its output into the test code.
This process can be easily automated if you use golden files.
The expected output can be automatically updated.
Say you changed your json module to replace some of the spaces with newlines to make the output more aesthetically pleasing. You have 40 test cases that need updating. Can you imagine doing this by hand?
With golden tests, you can tell your test framework to update all golden files from the current outputs, then check git diff to ensure that all changes are valid, and commit them.
If some of your tests suddently started failing, you can use diff or other such tools to compare the golden file to the actual file and figure out what exactly changed. Perhaps your testing framework could even show the diff automatically on test failure?
While advantages 1-2 are automatic, 3-5 require special support from your testing framework. The rest of this article will be focused on a Haskell testing framework tasty and its add-on package for golden tests, tasty-golden.
Basic usage
To illustrate how tasty-golden works, consider this yaml-to-json conversion module:
Because JSON contains quotes and YAML spans multiple lines, it is not very practical to store them as string literals in the source code file. Instead, you will keep them both in files.
Note that the name “golden file” only refers to the file containing the output, not the input. There is no requirement that the input is stored in a file or that there even is any “input” at all; but in practice it is often convenient to store them both in files so that there is an input file for every output file and vice versa.
This is all the code you need to support one, two, or a thousand test cases. When run, this code will:
Now run your test suite (note: in a proper cabalized project, you’d run cabal test or stack test instead):
tasty-golden realized that this is a new test case because the golden file was absent, so it went ahead and initialized the golden file based on the function’s output. You can now examine the file to see if it makes sense:
If you are happy with it, check in both input and output files to git. This is important so that your collaborators can run the tests, but it also helps when dealing with failing tests, as you’ll see next.
Dealing with test failures
Occasionally, your tests will fail. A test that cannot fail is a useless test.
A golden test fails when the actual output does not match the contents of the golden file. You then need to figure out whether this is a bug or an intentional code change.
Let’s say you decide that the output of yamlToJson should end with a newline.
The new function definition is
Now run the test suite:
Now, because your golden file is tracked by git, you can examine the differences between the old and new golden files with git diff :
Because this is the change you expected, you can now commit the updated file to git.