В комментариях к одной из моих статей про базовые команды Linux shell для тестировщиков справедливо заметили, что в ней не было указано применение команд в процессе тестирования. Я подумал, что лучше поздно, чем никогда, поэтому решил рассказать историю Backend QA-инженера Вани, который столкнулся с неожиданным поведением сервиса и попытался разобраться, где именно случилась ошибка.
Рубрика «Тестирование IT-систем» - 7
Как Иван ошибку в бэкенде локализовывал
2020-09-09 в 7:55, admin, рубрики: bash, debug, gdb, linux, networks, strace, tcpdump, Блог компании FunCorp, дебаггинг, сети, тестирование, Тестирование IT-систем, Тестирование веб-сервисов
Я 20 лет наслаждаюсь разнообразием архитектур и хочу поделиться мыслями
2020-09-09 в 7:07, admin, рубрики: .net, ASP, C#, orm, архитектура приложений, базы данных, Программирование, Тестирование IT-систем
Сначала хотел написать комментарий к статье "Я десять лет страдал от ужасных архитектур в C#...", но понял две вещи:
- Слишком много мыслей, которыми хочется поделиться.
- Для такого объёма формат комментария неудобен ни для написания, ни для прочтения.
- Давно читаю Хабр, иногда комментирую, но ни разу не писал статей.
- Я не силён в нумерованных списках.
Disclaimer: я не критикую @pnovikov или его задумку в целом. Текст качественный (чувствуется опытный редактор), часть мыслей разделяю. Архитектур много, но это нормально (да, звучит как название корейского фильма).
Однако давайте по порядку. Сначала моё мнение о том, что влияет на архитектуру, потом про спорные моменты в статье об «исправлении архитектур». Ещё расскажу о том, что у нас хорошо работает — может, пригодится кому-нибудь.
Читать полностью »
Я десять лет страдал от ужасных архитектур в C# приложениях — и вот нашел, как их исправить
2020-09-01 в 14:01, admin, рубрики: .net, .net core, ASP, C#, reinforced, архитектура приложений, базы данных, Программирование, Тестирование IT-систем
Я второй десяток лет участвую в разработке приложений для бизнеса на .NET и каждый раз вижу одни и те же проблемы — быдлокод и беспорядок. Месиво из сервисов, UoW, DTO-шек, классов-хелперов. В иных местах и прямой доступ в базу данных руками, логика в статических классах, километровые портянки конфигурации IoC.
Когда я был молодым и резвым мидлом — я тоже так писал. Потом бил кулаком в стену с криками: "Хватит! В следующий раз сделаю по-другому". Следующий раз действительно начинался "по-другому" — с холодной головой и строгим подходом к архитектуре — а на выходе все равно получалась та же субстанция, лучше на пару миллиметров.
Однако, эволюция — беспощадная штука: моя последняя система показалась мне более-менее близкой к идеалу. Сложность не сильно росла, скорость разработки не падала довольно долго, в систему худо-бедно въезжают новые сотрудники. Эти результаты я взял за основу, улучшил и теперь анонсирую вам свою новую разработку: Reinforced.Tecture.
Моделирование отказоустойчивых кластеров на базе PostgreSQL и Pacemaker
2020-08-27 в 11:47, admin, рубрики: highavailability, pacemaker, postgesql, postgresql, postgresql replication, virtualbox, Администрирование баз данных, Блог компании ДомКлик, Тестирование IT-системВведение
Некоторое время назад передо мной поставили задачу разработать отказоустойчивый кластер для PostgreSQL, работающий в нескольких дата-центрах, объединенных оптоволокном в рамках одного города, и способный выдержать отказ (например, обесточивание) одного дата-центра. В качестве софта, который отвечает за отказоустойчивость, выбрал Pacemaker, потому что это официальное решение от RedHat для создания отказоустойчивых кластеров. Оно хорошо тем, что RedHat обеспечивает его поддержку, и тем, что это решение универсальное (модульное). С его помощью можно будет обеспечить отказоустойчивость не только PostgreSQL, но и других сервисов, либо используя стандартные модули, либо создавая их под конкретные нужды.
К этому решению возник резонный вопрос: насколько отказоустойчивым будет отказоустойчивый кластер? Чтобы это исследовать, я разработал тестовый стенд, который имитирует различные отказы на узлах кластера, ожидает восстановления работоспособности, восстанавливает отказавший узел и продолжает тестирование в цикле. Изначально этот проект назывался hapgsql, но со временем мне наскучило название, в котором только одна гласная. Поэтому отказоустойчивые базы данных (и float IP, на них указывающие) я стал именовать krogan (персонаж из компьютерной игры, у которого все важные органы дублированы), а узлы, кластеры и сам проект — tuchanka (планета, где живут кроганы).
Сейчас руководство разрешило открыть проект для open source-сообщества под лицензией MIT. README в скором времени будет переведен на английский язык (потому что ожидается, что основными потребителями будут разработчики Pacemaker и PostgreSQL), а старый русский вариант README я решил оформить (частично) в виде этой статьи.
Как цветные полосы стали самым популярным тестовым паттерном для ТВ
2020-08-24 в 7:39, admin, рубрики: Блог компании Билайн Бизнес, Работа с видео, старое железо, ТВ, телевидение, телевизор, Тестирование IT-систем, тестирование ТВ, тестовые полосы
Вы не знаете имён Норберта Ларки (Norbert D. Larky) и Дэвида Холмса (David D. Holmes), но почти наверняка тысячи раз видели результат их работы. Этот результат видели все люди, оставлявшие телевизор включенным на любом кабельном канале без трансляций по 24 часа в сутки. А иногда его можно было увидеть, когда на канале возникали неполадки и требовалось чем-то заполнить время трансляции. В начале 1950-х Ларки и Холмс изобрели один из самых известных тестовых паттернов, известных миру. Он вам знаком — это таблица из ярких цветных полос, которые сложно не заметить. Сегодня мы расскажем вам о ней и о других телевизионных тестовых паттернах.
Читать полностью »
Так ли безопасен ваш iPhone? Обзор уязвимостей и тайных ходов в iOS
2020-08-03 в 9:16, admin, рубрики: iOS, Блог компании RUVDS.com, взлом, информационная безопасность, Лайфхаки для гиков, разработка под iOS, Тестирование IT-систем
Пользовательские данные не являются разменной монетой. Компания Apple потратила значительные усилия для того, чтобы заслужить себе репутацию, стойко отбиваясь от ФБР и прочих представителей силовых структур, ищущих возможность произвольного сбора данных владельцев iPhone.
В 2016 г. Apple отказалась ослабить защиту iOS для того, чтобы ФБР могла разблокировать iPhone стрелка из Сан-Бернардино. Завладев смартфоном Сайеда Фарука и промахнувшись десять раз с набором четырехзначного PIN кода, правоохранители тем самым заблокировали смартфон. Тогда в ФБР потребовали, чтобы Apple создала специальную ОС, в которой возможно подобрать код безопасности методом перебора...Читать полностью »
Отслеживание ошибок в приложении React с помощью Sentry
2020-07-20 в 7:27, admin, рубрики: devops, React, Sentry, отладка, Тестирование IT-систем, Тестирование веб-сервисов
Сегодня я расскажу вам об отслеживании ошибок в реальном времени в приложении React. Приложение внешнего интерфейса обычно не используется для отслеживания ошибок. Некоторые компании часто откладывают отслеживание ошибок, возвращаясь к нему после документации, тестов и прочего. Однако, если вы можете изменить свой продукт в лучшую сторону, то просто сделайте это!
«Подготовка к собеседованию QA» starter pack или самая большая шпаргалка вопросов-ответов по тестированию
2020-07-18 в 10:59, admin, рубрики: Карьера в IT-индустрии, начало карьеры, Тестирование IT-систем, Тестирование веб-сервисов, Тестирование мобильных приложений, тестирование по, Учебный процесс в IT
163 страницы смеси ответов на вопросы с реальных собеседований, перевода интересного контента с зарубежных ресурсов и агрегации материала с отечественных.
Читать полностью »
Ты добавил всего две строчки. Почему на это ушло два дня?
2020-07-15 в 9:53, admin, рубрики: Программирование, Проектирование и рефакторинг, строки кода, Тестирование IT-систем, усилияНа первый взгляд вопрос кажется разумным, но он делает некоторые ужасные предположения:
- строки кода = усилие
- строки кода = значение
- все строки кода равны
Ничто из этого не является истинным.
Почему исправление, которое кажется таким простым, заняло два дня?
Читать полностью »
Тестировать больше и лучше: Закончился разбор аварийного полета Boeing Starliner
2020-07-13 в 8:07, admin, рубрики: Boeing Starliner, decision coverage, quality assurance, испытания, космические происшествия, космонавтика, Научно-популярное, пилотируемая космонавтика, Тестирование IT-систем, тестирование поNASA и Boeing закончили анализ декабрьского полета Boeing Starliner. Напомню, в первом беспилотном испытательном пуске нового корабля программу полета получилось выполнить только частично, сорвалась стыковка с МКС, продолжительность миссии пришлось сократить до двух суток, и при этом корабль дважды едва не был потерян окончательно. Отчет не опубликован полностью, но известно, что 80 рекомендаций в очередной раз подчеркивают важность тщательного и качественного тестирования.
Послеполетное обслуживание Boeing Starliner, фото NASA/Bill Ingalls
Читать полностью »