Обложка канала

Протестировал. Страница 12

1808 @sqaunderhood
Открыть

Фильтрованный контент о тестировании и качестве ПО.

  • Протестировал

    На мой взгляд, в коммерческом тестировании сейчас преобладают тесты, дизайн которых был сделан вручную. Все эти статьи, доклады на конференциях о преимуществах автоматизированного тестирования упускают (намеренно или нет - не понятно), что в большинстве случаев автоматизация это выполнение "ручных" тесткейсов с помощью компьютера. С таким подходом при изменении требований к ПО переделывать прийдется как "ручные" тесткейсы так и автотесты. В моём понимании автоматические тесты это те, которые автоматически сгененируют тесткейсы, выполнят их и сделают вердикт о том, прошёл тест или нет. И тема таких тестов мало где затрагивается или не затрагивается вовсе. Изредка можно наткнуться на робкую попытку отечественных тестировщиков использования тестирования с помощью моделей (обычно это конечный автомат) или статью "как я открыл для себя тестирование с помощью свойств". На фоне таких попыток доклад о тестировании сайтов с помощью сетей Петри выглядит лучиком в тёмном царстве.

    Если есть возможность, не пишите тесты. Генерируйте их.
    #непишитетесты
    Алексей Родионов — Тестирование на основе сетей Петри

    Ближайшая конференция: Heisenbug 2019 Moscow — 5-6 декабря 2019, Москва Подробности и билеты: http://bit.ly/2Jg11AN Применение математического аппарата для с...

    YouTube

  • Протестировал

    Теперь на Гитхабе на одной странице собраны самые популярные среди проектов топики (aka теги). Есть и официальный для тестирования ПО - "testing". Как вы думаете какой проект в топе? (Спойлер: это GoogleChrome/puppeteer).

  • Протестировал

    Интересная статья о выявлении регрессии в результатах тестов на производительность в проекте Skia. Если у вас большое количество тестов на производительность и много поддерживаемых платформ, то количество измерений получается огромным (в Skia для каждого коммита 40,000 измерений). Оценивать такие результаты вручную затруднительно. Можно сделать границы значений для каждого теста (как в chromium), но такое решение не всегда будет работать и вы будете получать ложно-положительные срабатывания. Автор предлагает такое решение:

    - собрать все серии результатов для фиксированного набора коммитов (в Skia это обычно 100-250 изменений)
    - нормализовать серии результатов для каждого теста, чтобы среднее значение стало равно 0 и стандартное отклонение 1.0
    - сгруппировать нормализованные серии результатов с помощью knn (метод k ближайших соседей)
    - для каждой группы вычислить коэффициент регрессии и сравнивать значение коэффициента с каким-то эмпирическим числом, специфичным для проекта и тем самым автоматически выявлять регрессии.

    https://bitworking.org/news/2014/11/detecting-benchmark-regressions

    Если вы знаете другие способы автоматической оценки результатов - поделитесь или в чате @sqaunderhood_chat

  • Реклама

  • Протестировал

    Чеклист для оценки работодателя

    После того как собеседование закончено обычно начинается самый интересная часть - вопросы к будущему работодателю. Это ваша возможность узнать больше о компании, процессах разработки, о том, какую роль играет отдел тестирования в разработке, кто отвечает за качество продукта, как часто случаются переработки и т.д. И эту возможность не стоит упускать! Вопросы желательно продумать заранее и подобрать их таким образом, чтобы выудить максимум информации из интервьюеров до вашего трудоустройства. Пусть это будет небольшим аудитом компании или проекта с вашей стороны. Для начала можно использовать список вопросов перечисленных ниже и понемногу добавлять свои.

    - какое соотношение ручного и автоматизированного тестирования?
    - используют ли практики XP (непрерывная интеграция, непрерывная поставка и т.д.)?
    - какой тестовый фреймворк используют? Если нестандартный, то по каким причинам?
    - кто заказчик тестирования?
    - кто отвечает за качество продукта?
    - соотношение количества разработчиков и тестировщиков в проекте
    - группа тестирования отдельная доя каждого проекта или единственная и "шарится" между ними
    - есть ли требования в проекте или они неявные?
    - средний pass rate у тестов?

    Если интервьюеры владеют терминологией CMMI, то можно уточнить к какому уровню зрелости они сами относят свою компанию. Скорее всего придется поверить на слово, потому что в России не так много оценщиков по CMMI и я не знаю сертифицированные российские компании.

  • Протестировал

    Богатый список с чатами и каналами о тестировании.

  • Протестировал

    Конспекты

    У меня редко получается выбраться на конференции, но я всегда изучаю материалы с них в поисках полезной и новой информации. Знакомство с докладами начинаю с расписания, в котором читаю описания и темы докладов и выбираю те из них те, которые мне интересны. Потом для выбранных тем ищу слайды и если по слайдам понятно о чем речь и новой информации нет, то видео я уже не смотрю. Для оставшихся докладов я смотрю видеозапись на скорости 1.25 или 1.5. Исключение составляют доклады, записанные Стасом Фоминым (http://0x1.tv/), которые он выкладывает уже "ускоренными". Даже при таком подходе уходит очень много времени на просмотр всех видео. Поэтому я обрадовался инциативе (https://github.com/docops-hq/conf) вести конспекты докладов и выкладывать их на Гитхабе. Сейчас там есть конспекты докладов Highload-2018 и Moscow Python 2019, может в будущем появятся конспекты и с конференций о тестировании.

  • Протестировал

    hypothesis - одна из самых популярных библиотек на Питоне для тестирования свойств (aka property-based testing). hypothesis поддерживает множество стратегий и расширений для генерации данных, но отстутствовала возможность генерации данных на основе грамматик. Хотя автор и описал такую идею ещё в 2015 году, но желающих написать код не было. В начале этого года поддержку грамматик в формате EBNF добавили с помощью библиотеки lark и в будущем есть планы сделать поддержку ANTLR и ABNF. Я обновил все свои грамматики, которые я использовал для тестирования для использования в hypothesis и выложил на Гитхаб. Пользуйтесь.

  • Протестировал

    ​​Возможно вы сталкивались с таким термином как "core dumped", например "Segmentation fault (core dumped)". Это обычно последнее что мы видим, когда программа упала. Вы когда-нибудь задумывались о том, что это означает?

    В 1945 году у одного из создателей ЭНИАКа, одного из первых в мире компьютеров, возникла идея запоминающего устройства в виде матрицы ферритовых сердечников и к середине 1950-х память на магнитных сердечниках получила широкое распространение.

    Память на магнитных сердечниках — запоминающее устройство, хранящее информацию в виде направления намагниченности небольших ферритовых сердечников, обычно имеющих форму кольца. Ферритовые кольца расставлялись в прямоугольную матрицу и через каждое кольцо проходило (в зависимости от конструкции запоминающего устройства) от двух до четырёх проводов для считывания и записи информации. Память на магнитных сердечниках была основным типом компьютерной памяти с середины 1950-х и до середины 1970-х годов, когда Intel выпустила память DRAM на полупроводниковой микросхеме.

    Английский термин "core dump" буквально переводится как «распечатка содержимого сердечников»: на ранних компьютерах, дамп означал принтерную распечатку содержимого памяти на магнитных сердечниках. Дамп памяти (core dump) — содержимое рабочей памяти одного процесса, ядра или всей операционной системы. Также может включать дополнительную информацию о состоянии программы или системы, например значения регистров процессора и содержимое стека. Многие операционные системы позволяют сохранять дамп памяти для отладки программы. Как правило, дамп памяти процесса сохраняется автоматически, когда процесс завершается из-за критической ошибки (например, из-за ошибки сегментации).

  • Протестировал

    - H16: Most practitioners agree that requirement coverage is more important than code coverage (average Likert score = 4.00)
    - H17: Most respondents agree or strongly agree that test cases should be well modularized (average Likert score = 4.62)
    - H18: More than 96% of the respondents agree that test cases should be readable and understandable
    - H19: 57.42% of the respondents agree or strongly agree that test code should be simpler than the tested code, while 16.41% indicate their disagreement or strong disagreement (average Likert score = 4.20)
    - H20: Most practitioners agree or strongly agree that test code should be designed with maintainability in mind (average Likert score = 4.16)
    - H21: More than 190 practitioners agree or strongly agree that traceability links should be maintained between test cases, code and requirements (average Likert score = 3.97)
    - H22: A total of 215 respondents agree or strongly agree that a test case should attempt to break a functionality (average Likert score = 4.11)
    - H23: The majority of respondents agree that testing even the simplest things is valuable (average Likert score = 3.89)
    - H24: Add new testcases for fixed bugs (average Likert score = 4.40)
    - H25: Most of our respondents agree that assertions are a crucial part of test code and can be helpful in detecting subtle errors (average Likert score = 4.51)
    - H26: A large number of our respondents (i.e., 200) agree or strongly agree that commenting test code with common errors and possible causes is a good idea (average Likert score = 3.98)
    - H27: Most practitioners we survey agree that a good test case should be deterministic and produce the same output every time it is run (average Likert score = 4.07)
    - H28: Almost all our respondents agree that test cases should be side effect free
    - H29: Several common testing frameworks like JUnit provide the functionality of adding tags to test cases. Most of our respondents agree or strongly agree that the use of such tags to indicate, for example, fast or slow tests, is helpful (average Likert score = 3.93)

    Полный текст статьи - "Practitioners’ Views on Good Software Testing Practices"

    Меня немного удивил результат для гипотезы H24. Я знаю о такой практике, но не думал, что так много людей считают её правильной. Если так получилось, что тесты пропустили баг, то лучше сделать постмортем, попытаться понять что не так в ваших тестах, процессах или требованиях и что нужно сделать чтобы этого не повторилось в будущем. Систематическое создание теста для исправленного бага будет делать ваше тестирование бессистемным.

  • Протестировал

    Мнение тестировщиков о хороших практиках

    Нашёл интересную статью в которой авторы провели опрос тестировщиков из крупных компаний (ФБ, Майкрософт, Гугл, Линкедин) и популярных opensource проектов на Гитхабе. Результаты они объединили и получился отчёт в виде гипотез и соответствующих им баллов (от 1 до 5, "strongly disagree, disagree, neutral, agree, and strongly agree to 1, 2, 3, 4, and 5, respectively") по шкале Лайкерта. Так, например, первая гипотеза получила 3.93 балла по шкале Лайкерта и это означает общий ответ "согласен". Ниже я привел все гипотезы и количество баллов.

    - H1: In general, practitioners advice that a test case should be specific, i.e., it should try to test only one functionality (average Likert score = 3.93)
    - H2: Most respondents express that test cases should be selfcontained with no or minimal dependency on other test cases present in a suite (average Likert score = 3.95)
    - H3: Almost all of our respondents strongly agree (140 respondents) or agree (107 respondents) that it is important for test cases to check both normal and exceptional flow (average Likert score = 4.47)
    - H4: Boundary value analysis refers to testing at the boundaries between partitions of the input space, which include both valid and invalid values (average Likert score = 4.24)
    - H5: Well commented, named and designed test cases may serve as a good reference documentation (average Likert score = 3.93)
    - H6: A large number of respondents agree that test cases should be small whereas some are neutral or even disagree with this hypothesis (average Likert score = 3.85)
    - H7: In general, practitioners confirm that large test cases are hard to understand and maintain (average Likert score = 3.73)
    - H8: Practitioners agree that large test cases can be useful to detect difficult-to-find bugs (average Likert score = 3.59)
    - H9: Most practitioners are of the opinion that a test suite should contain a good mix of many short and a few large test cases (average Likert score = 3.97)
    - H10: Test cases can often become long and hard to manage and this increased complexity of test cases can lead to bugs in the test code. (average Likert score = 4.04)
    - H11: Code Coverage, Necessary but Insufficient (average Likert score = 3.97)
    - H12: Practitioners in general agree that coverage information can be leveraged to understand shortcomings of current test cases to write new tests (average Likert score = 3.97)
    - H13: In general, practitioners agree that a higher coverage does not mean that a test suite can detect more bugs (average Likert score = 4.02)
    - H14: Single test case should have a small footprint (i.e., the amount of code it executes) (average Likert score = 3.92)
    - H15: Testcase that is designed to maximize coverage is often long, not understandable and brittle (i.e., breaks easily) (average Likert score = 3.50)

    см. следующий пост

  • Протестировал

    ​​В разработке ПО важно приоритезировать баги до их начала работы с ними и для этого применяют так называемый "триаж" (фр. triage, сортировка). Так называется процесс сортировки задач или багов в соответствии с бизнес-приоритетами. После него становится понятно в каком порядке разработчики должны брать задачи из баг-трекера и ресурсы команды используются максимально эффективно. Изначально триаж начали применять врачи в военное время, чтобы обеспечить своевременное оказание медицинской помощи максимальному числу пострадавших в оптимальном объёме. Они распределяли пострадавших и больных на группы, исходя из нуждаемости в первоочередных и однородных мероприятиях в конкретной обстановке.

    На фотографии виден процесс триажа в госпитале Франции во время Первой мировой войны

  • Протестировал

    ​​Одной из фич PostgreSQL, которую мне довелось тестировать, было расширение для оптимизации запросов по стоимости выполнения. Расширение aqo при помощи методов машинного обучения улучшает оценку количества строк, что способствует выбору лучшего плана и ускорению запросов (но не всегда и не для всех).

    Для тестирования модуля я сделал автотест, который запускал SQL запросы нужного нам типа сначала для обучения, а потом уже непосредственно для тестирования модуля. При каждом запуске тест сохранял параметры планировщика: время планирования и выполнения запроса, ошибку оценки количества строк и другие. После этого тест проверял, что параметры планировщика с машинным обучением как минимум не хуже стандартного планировщика. Сначала я попробовал для оценки успешности теста использовать статистические методы. Но чем больше я погружался в нюансы работы модуля, тем меньше я был уверен, что тест правильно оценивает собранные цифры. Поэтому для большей уверенности я начал строить графики для визуализации результатов теста. И как потом оказалось не зря - в ходе тестирования нашел запросы с которыми aqo некорректно рассчитывал время.

    Вспомнил я эту историю с тестированием расширения для PostgreSQL когда узнал про квартет Энскомба. Энскомб смог продемонстрировать четыре набора данных, у которых были одинаковые статистические характеристики. У каждого из двумерных наборов данных по каждой переменной совпадают средние значения, оценки дисперсии, они имеют одинаковые коэффициенты корреляции между переменными, а также уравнения линейной регрессии, построенные с помощью метода наименьших квадратов. Но несмотря на такую «статистическую идентичность», мы видим, что это совсем разные наборы с точки зрения выбора модели, описывающей данные. Поэтому будет не лишним сделать визуализацию данных, если нет уверенности в правильной оценке математическими методами.

  • Протестировал

    ​​Майкрософт опубликовала исходный код калькулятора из Windows. Интересно в этой новости не сам факт публикации исходного кода компонента Windows, а то, что вместе с кодом выложили и тесткейсы для ручного тестирования, которые они выполняют перед каждым релизом.

    https://github.com/Microsoft/calculator/blob/master/docs/ManualTests.md

  • Протестировал

  • Протестировал

    Проект PostgreSQL известен понятной и удобной документацией. Но какой бы документация ни была хорошей, она не заменит вам хорошего учебника. Компания Postgres Professional спонсирует и участвует в создании учебников по PostgreSQL и они доступны бесплатно в электронном виде. А ещё они ищут человека, который разбирается в устройстве СУБД и готов заняться тестированием фич коммерческого форка PostgreSQL (ЗП у них и вправду выше средней по рынку). У нас в России не так компаний, занимающихся разработкой СУБД. Это Яндекс с noSQL СУБД ClickHouse и закрытой SQL СУБД, Mail.Ru с Tarantool, СУБД ЛИНТЕР (уверен, что вы про такую даже не слышали) и упомянутая компания Postgres Professional с форком PostgresSQL. Компанию PostgresPro в это ряду выгодно отличает то, что это небольшая компания со всеми свойственными этому плюсами.

  • Реклама

  • Протестировал

    Объяснение, что такое баги, от симпатичной девушки, далекой от разработки

    Предположим Ты собралась погулять с кем-то, но неожиданно оказалось, что нужно сменить туфли. Туфли Ты сменила, но в связи с этим пришлось полностью переодеться вплоть до смены трусов.

    Причина, почему пришлось переодеться - баг, который всегда является следствием изменений, направленных на улучшение.

    Смена туфель - это разработка новой функциональности. А то, что пришлось полностью переодеться, - это рефакторинг для исправления багов, потому что смена туфлей сделала полностью неподходящей текущую одежду.

  • Протестировал

    История фаззинга

    Первые официально опубликованные результаты исследований, посвящённые тестированию поведения программ при использовании псевдослучайных внешних данных, проводились в начале 80-х годов XX века в Юго-Западном исследовательском институте в Сан-Антонио и в Техасском университете в Далласе. При этом, по воспоминаниям Джеральда Вайнберга, работавшего в НАСА на проекте «Меркурий» по запуску первого человека в космос, в 50-х годах XX века тестирование разрабатываемого программного обеспечения проводилось на пачках перфокарт, вынутых из мусорных корзин или случайно перемешанных. В 1970 году была представлена работа, в которой описывается метод псевдослучайной генерации по заданной грамматике синтаксически корректных программ для тестирования компиляторных фронтендов. В 1983 году Стив Кэппс разработал инструмент The Monkey для тестирования программы MacPaint. Через специальный программный интерфейс инструмент подключался к программе и с высокой скоростью, как будто компьютером управляла злая обезьяна, генерировал псевдослучайные последовательности нажатий клавиш на клавиатуре и воздействий на манипулятор «мышь». Фактически The Monkey является первым известным примером промышленного инструмента тестирования программы на устойчивость к ошибочным внешним данным программы.

    Термин «фазз» (англ. fuzz – неточный, расплывчатый) впервые упомянут в названии исследовательского проекта «Operating System Utility Program Reliability – The Fuzz Generator», который проводился в Висконсинском университете в Мадисоне с 1988 года под руководством профессора Барта Миллера. В статье, посвящённой описанию предложенного метода и результатам исследования, рассказывается, что на идею исследования техники случайного отрицательного тестирования программ натолкнула ситуация, когда один из авторов подключился по телефонной линии с использованием модема к удалённой компьютерной системе в ночь, когда был ураган с дождём. Дождь сильно влиял на качество связи и приводил к тому, что на вход утилитам командной строки подавались неправильные аргументы в связи со случайно внедрёнными неправильными символами. Подобный шум из-за влияния дождя на линию был ожидаем, но совершенно неожиданным наблюдением стало то, что получение на вход некорректных аргументов командной строки приводило к аварийному завершению утилит операционной системы. Данное наблюдение натолкнуло авторов исследования на идею автоматического тестирования программ путём генерации псевдослучайных внешних данных, или фаззинга. Авторы исследования описывают свой метод не как замену тестированию или формальной верификации, а как недорогой механизм обнаружения ошибок с целью увеличения надёжности системы в целом. При этом использовался очень грубый показатель корректности: программа считалась повреждённой, если в процессе её исполнения происходило аварийное завершение работы программы или обнаруживалось её зависание. Если представить программу как сложный конечный автомат, то предложенный механизм можно описать как случайный обход пространства состояний этого конечного автомата с целью поиска неопределённых состояний. #история

  • Протестировал

    ​​CodeDefenders - онлайн-игра, объясняющая принцип работы мутационного тестирования. Перед началом игры нужно выбрать код, представленный классами на Java, и роль, Защитник (Defender) или Атакующий (Attacker). Играть можно одному, устроить дуэль или битву с большим количеством участников (я так понял в битве нет ограничений по количеству игроков). После старта игры вам показывают код и если вы играете в роли Атакующего, то расставляете мутантов, если Защитника, то пытаетесь выявить мутантов, расставленных другими игроками. После каждого добавленного мутанта вам говорят пойман он или нет. По-моему довольно забавно, но быстро надоедает. Хотя, если посмотреть на таблицу с лучшими игроками, то кому-то эта игрушка пришлась по душе.