Что такое workaround в тестировании
workaround
Смотреть что такое «workaround» в других словарях:
workaround — (n.) by 1987, from WORK (Cf. work) (v.) + AROUND (Cf. around) … Etymology dictionary
Workaround — A workaround is a bypass of a recognized problem in a system. A workaround is typically a temporary fix that implies that a genuine solution to the problem is needed. Frequently workarounds are as creative as true solutions, involving outside the … Wikipedia
Workaround — Unter einem Workaround (englisch für: [um etwas] herum arbeiten bzw. in etwa Abhilfe) versteht man die Umgehung eines bekannten Problems innerhalb eines technischen Systems durch eine Hilfskonstruktion. Es ist eine provisorische Lösung, die die… … Deutsch Wikipedia
Workaround — Un workaround ou work around (avec un trait d’union), anglicisme signifiant littéralement « travail autour », parfois traduit en solution de rechange ou de contournement[1], est, notamment en informatique, le contournement d’un bug ou… … Wikipédia en Français
Workaround — Обходной приём, или Workaround обходное решение проблемы, выявленной в системе (в простонародии «костыль»). Обходной приём обычно является временным исправлением, подразумевающим, что требуется подлинное решение проблемы. Очень часто обходные… … Википедия
Workaround — Notbehelf; Behelfslösung; Umgehungslösung * * * Workaround [dt. »ein Problem angehen«], das Überarbeiten von fehlerhafter Hard oder Software, bei der aber der Fehler nicht beseitigt, sondern nur ein Lösungsweg angegeben wird, den Fehler zu… … Universal-Lexikon
workaround — An ingenious, undocumented way to solve a problem. ► “One workaround is to print a business letter on plain stock and then photocopy it onto the letterhead.” (MacWorld, Dec. 1994, p.135) … American business jargon
workaround — noun /ˈwɜː(ɹ)k.əɹaʊnd/ a) A means of overcoming some obstacle, especially an obstacle consisting of laws, regulations, or constraints. b) A procedure or a temporary fix that bypasses a problem and allows the user to continue working until a… … Wiktionary
workaround — n. manner of bypassing a problem caused by a bug without correcting the bug itself (Computers) … English contemporary dictionary
workaround — noun Computing a method for overcoming a problem or limitation in a program or system … English new terms dictionary
workaround — /ˈwɜkəraʊnd/ (say werkuhrownd) noun Chiefly Computers Colloquial a temporary means of bypassing or avoiding a particular problem without addressing its cause … Australian-English dictionary
Как на русский перевести workaround
так чтобы одним словом, и не «костыль», а допустимо для упоминания в деловой переписке.
Временное решение проблемы первым заработавшим способом :>
Кроме костыля нет аналогов в одно слово.
и не «костыль», а допустимо для упоминания в деловой переписке
Будь мужиком, начни употреблять «костыль», и, возможно, в ближайшем будущем это будет вполне допустимо.
решение, хак, околоработа, враппер, абстракция, переопределение, обход, обходник, переходник, заплатка, накладка, прокладка, способ, метод, затычка
«подпорка» ещё (подпереть)
Wiki говорит «обходное решение», так же «временное решение» и «костыль».
не «костыль», а допустимо для упоминания в деловой переписке
а что так с костылем? костыль он и есть костыль. вполне распространенное слово в переписке, в т.ч. в деловой, особенно если дела связаны с ИТ.
Используй прямой смысловой перевод: временное решение.
Не прямой, ибо workaround не обязан быть временным. Особенно когда workaround’ит чужое приложение.
«Работа не волк, работа — ворк, а волк — гулять.»
Не прямой, ибо workaround не обязан быть временным. Особенно когда workaround’ит чужое приложение.
Так ведь нет ничего более постоянного, чем временное.
А если серьёзно, то надо тогда разделять два понятия, которые в английском языке называются одним словом.
Если workaround применяется ввиду ошибки, пусть и в чужом приложении, вполне можно сказать «временное решение».
А в ситуации «an application we use outputs data in one format and we need it in another format, so here’s a workaround for that», можно сказать просто «решение». Или подходящее к ситуации понятие, например, «конвертер».
Я что-то пропустил и байпас уже стал русским словом? По теме: с контекстом было бы понятнее
workaround
Смотреть что такое «workaround» в других словарях:
workaround — (n.) by 1987, from WORK (Cf. work) (v.) + AROUND (Cf. around) … Etymology dictionary
Workaround — A workaround is a bypass of a recognized problem in a system. A workaround is typically a temporary fix that implies that a genuine solution to the problem is needed. Frequently workarounds are as creative as true solutions, involving outside the … Wikipedia
Workaround — Unter einem Workaround (englisch für: [um etwas] herum arbeiten bzw. in etwa Abhilfe) versteht man die Umgehung eines bekannten Problems innerhalb eines technischen Systems durch eine Hilfskonstruktion. Es ist eine provisorische Lösung, die die… … Deutsch Wikipedia
Workaround — Un workaround ou work around (avec un trait d’union), anglicisme signifiant littéralement « travail autour », parfois traduit en solution de rechange ou de contournement[1], est, notamment en informatique, le contournement d’un bug ou… … Wikipédia en Français
Workaround — Обходной приём, или Workaround обходное решение проблемы, выявленной в системе (в простонародии «костыль»). Обходной приём обычно является временным исправлением, подразумевающим, что требуется подлинное решение проблемы. Очень часто обходные… … Википедия
Workaround — Notbehelf; Behelfslösung; Umgehungslösung * * * Workaround [dt. »ein Problem angehen«], das Überarbeiten von fehlerhafter Hard oder Software, bei der aber der Fehler nicht beseitigt, sondern nur ein Lösungsweg angegeben wird, den Fehler zu… … Universal-Lexikon
workaround — An ingenious, undocumented way to solve a problem. ► “One workaround is to print a business letter on plain stock and then photocopy it onto the letterhead.” (MacWorld, Dec. 1994, p.135) … American business jargon
workaround — noun /ˈwɜː(ɹ)k.əɹaʊnd/ a) A means of overcoming some obstacle, especially an obstacle consisting of laws, regulations, or constraints. b) A procedure or a temporary fix that bypasses a problem and allows the user to continue working until a… … Wiktionary
workaround — n. manner of bypassing a problem caused by a bug without correcting the bug itself (Computers) … English contemporary dictionary
workaround — noun Computing a method for overcoming a problem or limitation in a program or system … English new terms dictionary
workaround — /ˈwɜkəraʊnd/ (say werkuhrownd) noun Chiefly Computers Colloquial a temporary means of bypassing or avoiding a particular problem without addressing its cause … Australian-English dictionary
Фундаментальная теория тестирования
В тестировании нет четких определений, как в физике, математике, которые при перефразировании становятся абсолютно неверными. Поэтому важно понимать процессы и подходы. В данной статье разберем основные определения теории тестирования.
Перейдем к основным понятиям
Тестирование программного обеспечения (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) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Атрибуты тест кейса:
Бойтесь уязвимостей, воркэраунды приносящих. Часть 1: FragmentSmack/SegmentSmack
Всем привет! Меня зовут Дмитрий Самсонов, я работаю ведущим системным администратором в «Одноклассниках». У нас более 7 тыс. физических серверов, 11 тыс. контейнеров в нашем облаке и 200 приложений, которые в различной конфигурации формируют 700 различных кластеров. Подавляющее большинство серверов работают под управлением CentOS 7.
14 августа 2018 г. была опубликована информация об уязвимости FragmentSmack
(CVE-2018-5391) и SegmentSmack (CVE-2018-5390). Это уязвимости с сетевым вектором атаки и достаточно высокой оценкой (7.5), которая грозит отказом в обслуживании (DoS) из-за исчерпания ресурсов (CPU). Фикс в ядре для FragmentSmack на тот момент предложен не был, более того, он вышел значительно позже публикации информации об уязвимости. Для устранения SegmentSmack предлагалось обновить ядро. Сам пакет с обновлением был выпущен в тот же день, оставалось только установить его.
Нет, мы совсем не против обновления ядра! Однако есть нюансы…
Как мы обновляем ядро на проде
Тем не менее работы всё равно много, и она может занимать несколько недель, а при возникновении каких-либо проблем с новой версией — до нескольких месяцев. Злоумышленники это прекрасно понимают, поэтому нужен план «Б».
FragmentSmack/SegmentSmack. Workaround
К счастью, для некоторых уязвимостей такой план «Б» существует, и называется он Workaround. Чаще всего это изменение настроек ядра/приложений, которые позволяют минимизировать возможный эффект или полностью исключить эксплуатацию уязвимостей.
В случае с FragmentSmack/SegmentSmack предлагался такой Workaround:
«Можно изменить дефолтные значения 4MB и 3MB в net.ipv4.ipfrag_high_thresh и net.ipv4.ipfrag_low_thresh (и их аналоги для ipv6 net.ipv6.ipfrag_high_thresh и net.ipv6.ipfrag_low_thresh) на 256 kB и 192 kB соответственно или ниже. Тесты показывают от небольшого до значительного падения использования CPU во время атаки в зависимости от оборудования, настроек и условий. Однако может быть некоторое влияние на производительность из-за ipfrag_high_thresh=262144 bytes, так как только два 64K-фрагмента могут одновременно уместиться в очереди на пересборку. Например, есть риск, что приложения, работающие с большими UDP-пакетами, поломаются».
Сами параметры в документации ядра описаны так:
На продакшен-сервисах больших UDP у нас нет. В LAN фрагментированный трафик отсутствует, в WAN есть, но не значительный. Ничто не предвещает — можно накатывать Workaround!
FragmentSmack/SegmentSmack. Первая кровь
Первая проблема, с которой мы столкнулись, заключалась в том, что облачные контейнеры порой применяли новые настройки лишь частично (только ipfrag_low_thresh), а иногда не применяли вообще — просто падали на старте. Стабильно воспроизвести проблему не удавалось (вручную все настройки применялись без каких-либо сложностей). Понять, почему падает контейнер на старте, тоже не так-то просто: никаких ошибок не обнаружено. Одно было известно точно: откат настроек решает проблему с падением контейнеров.
Почему недостаточно применить Sysctl на хосте? Контейнер живёт в своём выделенном сетевом Namespace, поэтому по крайней мере часть сетевых Sysctl-параметров в контейнере может отличаться от хоста.
Как именно применяются настройки Sysctl в контейнере? Так как контейнеры у нас непривилегированные, изменить любую настройку Sysctl, зайдя в сам контейнер, не получится — просто не хватит прав. Для запуска контейнеров наше облако на тот момент использовало Docker (сейчас уже Podman). Докеру через API передавались параметры нового контейнера, в том числе нужные настройки Sysctl.
В ходе перебора версий выяснилось, что API Docker не отдавало все ошибки (по крайней мере, в версии 1.10). При попытке запустить контейнер через “docker run” мы, наконец-то, увидели хоть что-то:
write /proc/sys/net/ipv4/ipfrag_high_thresh: invalid argument docker: Error response from daemon: Cannot start container : [9] System error: could not synchronise with container process.
Значение параметра не валидное. Но почему? И почему оно не валидное только иногда? Выяснилось, что Docker не гарантирует порядок применения параметров Sysctl (последняя проверенная версия — 1.13.1), поэтому иногда ipfrag_high_thresh пытался выставиться на 256K, когда ipfrag_low_thresh ещё был 3M, то есть верхняя граница была ниже, чем нижняя, что и приводило к ошибке.
На тот момент у нас уже использовался свой механизм доконфигуривания контейнера после старта (заморозка контейнера через cgroup freezer и выполнение команд в namespace контейнера через ip netns), и мы добавили в эту часть также прописывание Sysctl-параметров. Проблема была решена.
FragmentSmack/SegmentSmack. Первая кровь 2
Не успели мы разобраться с применением Workaround в облаке, как стали поступать первые редкие жалобы от пользователей. На тот момент прошло несколько недель с начала применения Workaround на первых серверах. Первичное расследование показало, что жалобы поступали на отдельные сервисы, и не на все серверы данных сервисов. Проблема вновь обрела крайне неопределённый характер.
В первую очередь мы, конечно, попробовали откатить настройки Sysctl, но это не дало никакого эффекта. Различные манипуляции с настройками сервера и приложения тоже не помогли. Помог reboot. Reboot для Linux столь же противоестественен, сколь он был нормальным условием для работы с Windows в былые дни. Тем не менее он помог, и мы списали всё на «глюк в ядре» при применении новых настроек в Sysctl. Как же это было легкомысленно…
Через три недели проблема повторилась. Конфигурация этих серверов была довольно простой: Nginx в режиме прокси/балансировщика. Трафика немного. Новая вводная: на клиентах с каждым днём увеличивается количество 504-х ошибок (Gateway Timeout). На графике показано число 504-х ошибок в день по этому сервису:
Все ошибки про один и тот же бекенд — про тот, который находится в облаке. График потребления памяти под фрагменты пакетов на этом бекенде выглядел следующим образом:
Это одно из самых ярких проявлений проблемы на графиках операционной системы. В облаке как раз в это же время была пофикшена другая сетевая проблема с настройками QoS (Traffic Control). На графике потребления памяти под фрагменты пакетов она выглядела точно так же:
Предположение было простым: если на графиках они выглядят одинаково, то и причина у них одинаковая. Тем более, что какие-либо проблемы с этим типом памяти случаются чрезвычайно редко.
qdisc fq 2c6c: parent 1:2c6c limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 refill_delay 40.0ms
Sent 454701676345 bytes 491683359 pkt (dropped 464545, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
1024 flows (1021 inactive, 0 throttled)
0 gc, 0 highprio, 0 throttled, 464545 flows_plimit
«464545 flows_plimit» — это и есть пакеты, дропнутые из-за превышения лимита очереди одного соединения, а «dropped 464545» — это сумма всех дропнутых пакетов этого шедулера. После увеличения длины очереди до 1 тыс. и рестарта контейнеров проблема перестала проявляться. Можно откинуться в кресле и выпить смузи.
FragmentSmack/SegmentSmack. Последняя кровь
Во-первых, спустя несколько месяцев после анонса уязвимостей в ядре, наконец, появился фикс для FragmentSmack (напомню, что вместе с анонсом в августе вышел фикс только для SegmentSmack), что дало шанс отказаться от Workaround, который доставил нам довольно много неприятностей. Часть серверов за это время мы уже успели перевести на новое ядро, и теперь надо было начинать с начала. Зачем мы обновляли ядро, не дожидаясь фикса FragmentSmack? Дело в том, что процесс защиты от этих уязвимостей совпал (и слился) с процессом обновления самого CentOS (что занимает ещё больше времени, чем обновление только ядра). К тому же SegmentSmack — более опасная уязвимость, а фикс для него появился сразу, так что смысл был в любом случае. Однако, просто обновить ядро на CentOS мы не могли, потому что уязвимость FragmentSmack, которая появилась во времена CentOS 7.5, была пофикшена только в версии 7.6, поэтому нам пришлось останавливать обновление до 7.5 и начинать всё заново с обновлением до 7.6. И так тоже бывает.
Во-вторых, к нам вернулись редкие жалобы пользователей на проблемы. Сейчас мы уже точно знаем, что все они связаны с аплоадом файлов от клиентов на некоторые наши серверы. Причём через эти серверы шло очень небольшое количество аплоадов от общей массы.
Как мы помним из рассказа выше, откат Sysctl не помогал. Помогал Reboot, но временно.
Подозрения с Sysctl не были сняты, но на этот раз требовалось собрать как можно больше информации. Также крайне не хватало возможности воспроизвести проблему с аплоадом на клиенте, чтобы более точечно изучить, что происходит.
Анализ всей доступной статистики и логов не приблизил нас к пониманию происходящего. Остро не хватало возможности воспроизвести проблему, чтобы «пощупать» конкретное соединение. Наконец, разработчикам на спецверсии приложения удалось добиться стабильного воспроизведения проблем на тестовом устройстве при подключении через Wi-Fi. Это стало прорывом в расследовании. Клиент подключался к Nginx, тот проксировал на бекенд, которым являлось наше приложение на Java.
Диалог при проблемах был такой (зафиксирован на стороне Nginx-прокси):
При этом сеть на этот сервер приходит в виде Vlan-теггированного трафика, которое тоже добавляет свои поля в пакеты:
А ещё этот трафик может фрагментироваться (тот самый небольшой процент входящего фрагментированного трафика, о котором мы говорили при оценке рисков от Workaround), что тоже меняет содержание хидеров:
Ещё раз: пакеты инкапсулированы Vlan-тегом, инкапсулированы туннелем, фрагментированы. Чтобы точнее понять, как это происходит, проследим маршрут пакета от клиента до Nginx-прокси.
Нет, таких пакетов на сервере не было. Таким образом, проблема должна быть раньше. Есть ли пакеты со снятым только Vlan-инкапсулированием?
0xx390x2xx — это IP-адрес клиента в hex-формате.
32:4 — адрес и длина поля, в котором записан SCR IP в Tunnel-пакете.
Есть ли фрагменты пакетов без снятого Vlan- и Tunnel-инкапсулирования?
tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
Эта магия покажет нам все фрагменты, включая последний. Наверное, то же можно зафильтровать по IP, но я не пытался, поскольку таких пакетов не очень много, и в общем потоке легко нашлись нужные мне. Вот они:
Это два фрагмента одного пакета (одинаковый ID 53652) с фотографией (видно слово Exif в первом пакете). По причине того, что на этом уровне пакеты есть, а в склеенном виде в дампах — нет, то проблема явно со сборкой. Наконец-то этому есть документальное подтверждение!
Декодер пакетов не выявил никаких проблем, препятствующих сборке. Пробовал тут: hpd.gasmi.net. Сначала, при попытке туда что-то запихать, декодеру не нравится формат пакета. Оказалось, что там были какие-то лишние два октета между Srcmac и Ethertype (не относящиеся к информации о фрагментах). После их удаления декодер заработал. Однако никаких проблем он не показал.
Как ни крути, кроме тех самых Sysctl ничего больше не нашлось. Оставалось найти способ выявления проблемных серверов, чтобы понять масштаб и принять решение о дальнейших действиях. Достаточно быстро нашёлся нужный счётчик:
Он же есть в snmpd под OID=1.3.6.1.2.1.4.31.1.1.16.1 (ipSystemStatsReasmFails).
«The number of failures detected by the IP re-assembly algorithm (for whatever reason: timed out, errors, etc.)».
Среди группы серверов, на которых изучалась проблема, на двух этот счётчик увеличивался быстрее, на двух — медленнее, а ещё на двух вообще не увеличивался. Сравнение динамики этого счётчика с динамикой HTTP-ошибок на Java-сервере выявило корреляцию. То есть счётчик можно было ставить на мониторинг.
Наличие надёжного индикатора проблем очень важно, чтобы можно было точно определить, помогает ли откат Sysctl, так как из предыдущего рассказа мы знаем, что по приложению это сразу понять нельзя. Данный индикатор позволил бы выявить все проблемные места в продакшене до того, как это обнаружат пользователи.
После отката Sysctl ошибки по мониторингу прекратились, таким образом причина проблем была доказана, как и то, что откат помогает.
Мы откатили настройки фрагментации на других серверах, где загорелся новый мониторинг, а где-то под фрагменты выделили даже больше памяти, чем было до этого по умолчанию (это была udp-статистика, частичная потеря которой не была заметна на общем фоне).
Самые главные вопросы
Почему у нас на L3-балансировщике фрагментируются пакеты? Большинство пакетов, которые прилетают от пользователей на балансировщики, — это SYN и ACK. Размеры этих пакетов небольшие. Но так как доля таких пакетов очень велика, то на их фоне мы не заметили наличие больших пакетов, которые стали фрагментироваться.
Причиной стал поломавшийся скрипт конфигурации advmss на серверах с Vlan-интерфейсами (серверов с тегированным трафиком на тот момент в продакшене было очень мало). Advmss позволяет донести до клиента информацию о том, что пакеты в нашу сторону должны быть меньшего размера, чтобы после приклеивания к ним заголовков туннеля их не пришлось фрагментировать.
Почему откат Sysctl не помогал, а ребут помогал? Откат Sysctl менял объём памяти, доступной для склеивания пакетов. При этом, судя по всему сам факт переполнения памяти под фрагменты приводил к торможению соединений, что приводило к тому, что фрагменты надолго задерживались в очереди. То есть процесс зацикливался.
Ребут обнулял память и всё приходило в порядок.
Можно ли было обойтись без Workaround? Да, но велик риск оставить пользователей без обслуживания в случае атаки. Конечно, применение Workaround в результате привело к возникновению различных проблем, включая торможение одного из сервисов у пользователей, но тем не менее мы считаем, что действия были оправданы.
Большое спасибо Андрею Тимофееву (atimofeyev) за помощь в проведении расследования, а также Алексею Кренёву (devicex) — за титанический труд по обновлению Centos и ядер на серверах. Процесс, который в данном случае несколько раз пришлось начинать с начала, из-за чего он затянулся на много месяцев.