Я занимаюсь тестированием десктоп приложений на базе Windows и в данный момент слежу за качеством одной отечественной ММОРПГ. Со временем я оброс некоторыми тулзами, позволяющими улучшить процессы ручного тестирования. В данной статье не хочу трогать полноценную автоматизацию (зависящую от ЯП, игрового движка и желания куашника лезть в эти дебри), а больше рассказать про ПО, которым я сам пользуюсь и которое не так часто всплывает в подобных темах (зачастую упор на мобилках и вэбе).
Virtual Box
Когда использовать: инсталляционное тестирование.
По данным Steam на апрель 2021 наиболее популярной ОСью является Windows 10 64 bit (92.38%). Следом за ней идут Windows 7 64 bit (2.33%) и Windows 8.1 64 bit (1.08%). Среди языков наиболее популярные: английский (39.27%), упрощенный китайский (18.83%) и русский (11.18%). Если с языками в рамках одной ОСи и можно поиграться, то иметь несколько разных ОСей на одной машине и переключаться между ними, прогоняя тесты, – удовольствие, скажем честно, на любителя.
Здесь нам и приходят на помощь средства виртуализации, где имхо самым простым и удобным будет Virtual Box. Позволяет прямо здесь и сейчас раскатать несколько образов систем разных разрядностей, языков, объемов ПЗУ и ОЗУ. Создать клон виртуальной машины или сделать снимок системы, к которому можно откатываться после прогона тестов. Образы виртуального диска можно копипастить и использовать на разных физических машинах. Из минусов, в виртуалку не прокинуть видеокарту, в Virtual Box данного функционала попросту нет. link_virtualbox
NetBalancer и Tmeter
Когда использовать: стресс тестирование.
То, что замечательно работает при 500 Мбит, может быть абсолютно неюзабельным при 1 Мбит. Как проводить подобные тесты? Можно, конечно, понизить пропускную способность сетевой карты средствами windows, урезав, скажем, значение до 10 Мбит и поиграть с дуплексом. Или потыкаться в настройках роутера. Но хочется все же более точных цифр и статистики.
Решение для богатых - NetBalancer. Решение для чуть менее богатых – Tmeter. Оба приложения позволяют редактировать скорость всего трафика или выставить ограничения на конкретный процесс, задавать правила и фильтры, отображать кол-во полученных и посланных байт в риалтайме. Оба выводят виджет с графиками, имеют приятный интерфейс и гибкую настройку.
Преимущество, на мой взгляд, у NetBalancer`а – есть возможность выбрать запущенное приложение и сохранить всю его статистику по трафику с указанием времени. Но да, за него придется немного забашлять разрабам. Tmeter бесплатный, но со статистикой у него похуже: подробного и посекундного сбора у него нет, только общие цифры. Небольшая оговорка: следует помнить, что все эти проверки синтетические и могут отличаться от реальных условий.
link_netbalancer и link_tmeter
AutoHotKey
Когда использовать: когда угодно.
Простейшая автоматизация рутинных процессов. Как быстро заполнять поля или отправить в игровой чат тысячу сообщений нажатием одной кнопки? Или воспроизвести последовательность действий, не прожимая кучу кнопок? Ответ - быстрый и ч0ткий AutoHotkey. link_ahk Например, можно зафиксировать шаблон баг репорта с заранее подготовленным форматированием:
^+v::
sendinput, *Краткое описание проблемы:*
sendinput, {ENTER}
sendinput, {ENTER}
sendinput, *Шаги воспроизведения:*
sendinput, {ENTER}
sendinput, 1.
sendinput, {ENTER}
sendinput, *Фактический результат:*
sendinput, {ENTER}
sendinput, {ENTER}
sendinput, *Ожидаемый результат:*
sendinput, {ENTER}
sendinput, {ENTER}
sendinput, *Окружение:*
sendinput, {ENTER}
sendinput, {ENTER}
sendinput, *Комментарий:*
sendinput, {ENTER}
sendinput, -
return
При нажатии сочетания клавиш ctrl+shift+v поле будет выглядеть так:
Если не лень, можно заморочиться и писать целые сценарии, кликая мышью по координатам и нажимая различные клавиши/сочетания клавиш (но мы же понимаем, что это такое и лучше юзать нормальную автому).
Process monitor и DebugView
Когда использовать: когда угодно/анализ данных для баг репорта.
Допустим, вы запускаете игру и ловите синий экран смерти. С чего начать диагностику? Безусловно, пойдем изучать журнал windows и тыкать клиентские логи приложения. Но в дополнение к этому я бы выделил сразу две тулзы: Process monitor и DebugView. Первая выводит список всех процессов с указанием времени, позволяет сохранить их в табличку в csv/xml. Быстро, просто и удобно. Вторая перехватывает и выводит на экран, либо сохраняет в файл, вызовы OutputDebugString и DbgPrint, которые изначально заложил в код разработчик. Обычно применяется в том случае, когда проблема невоспроизводима на машине разработчика, а встроенный логгер по какой-либо причине неприменим (напр., по причине падения приложения или его отсутствия). Разработчик обильно обкладывает проблемное место отладочной печатью и отправляет приложение тестировщику, который воспроизводит ошибку и возвращает логи обратно — через несколько итераций проблема обычно находится. (за корректировку описания спасибо @AndreyDmitriev) link_prmonitor и link_debugview
MSI Afterburner
Когда использовать: когда угодно/нагрузочное тестирование.
Как быстро понять, привели ли изменения в проекте к улучшению производительности и увеличению кол-ва кадров в секунду? А если бы еще можно было подключить к этой программе свои скрипты – так вообще была бы сказка. Ну так есть такое! MSI Afterburner. Можно вывести на экран не просто кол-во кадров, а всю инфу с нагрузкой на железо (ОЗУ, ЦПУ, ГПУ, ?М?Г?У?). А также поиграться с настройкой видюхи! Вольтаж, память, регулировка скорости вентиляторов и кучу всякого разного. Еще раз отмечу, что MSI Afterburner позволяет запускать сторонние приложения на свои события. Так, например, я делаю питонячим скриптом скрины экрана в местах, где ФПС значительно проседает. link_msiab
Intel Graphics Perfomance Analyzers
Когда использовать: когда графическое приложение в конкретном месте безбожно тормозит.
Не совсем для всех и каждого. Приложение подойдет для мониторинга производительности программ с упором на графическую составляющую. Включает в себя целый список программных средств: GPA System Analyzer, Frame Analyzer, Trace Analyzer. Позволяет запустить прилажку, поставить ее на «паузу», захватить фрейм, собрать по нему объемную информацию и передать на анализ, скажем, техартистам, которые уже и будут заниматься оптимизацией. Еще никогда процесс сбора подобной информации не был так прост. Кому захочется почитать подробнее, вот хорошая статья на русском. link_intel_gpanalyzers
Самописные тулзы
Когда использовать: когда угодно.
Не хотел трогать автоматизацию, но считаю, что стоит упомянуть о самописных тулзах, которые можно использовать каждый день и на всех этапах тестирования. Отправка запросов, работа с БД, парсинг json`ов, анализ любых внутренних данных – в свои тулзы можно запихнуть все, что нужно и все, что угодно. Вариаций может быть масса. Я же использую Python и библиотеку pysimplegui, у которой есть отличный cookbook с примерами. А с помощью auto-py-to-exe легко и просто гуишка упаковывается в исполняемый файл.
Отладочные команды для куа отдела – это, конечно, круто. Но GUI оболочка под них (какой бы она не была) зарекомендовала себя как инструмент не только для куа, но и для ГД, арта, звука, продюсеров и других отделов. Конечно, можно попросить сделать это прогеров и потратить их время, но можно сделать все это и самостоятельно.
Разумеется, это не полный список, но и время у всех нас не резиновое. Скидывайте в комментарии ваши рабочие инструменты, интересно почитать, где и что можно усовершенствовать и дополнить. И спасибо за внимание!
AndreyDmitriev
Вот не особо придираясь к аццкому жаргону типа «гуишка для куашника», тем не менее не могу не придраться к описанию DebugView, ибо эта «тулза» вовсе не «позволяет смотреть в риалтайме на события системы во время использования приложения» и уж тем более не отвечает на вопрос «что думает винда о том, как ты бьешь орков в вове». Скорее она отвечает на вопрос «о чём думал разработчик насчёт тех мест, где что-то могло пойти не так». Этот инструмент перехватывает и выводит на экран (ну либо в файл сохраняет) вызовы OutputDebugString и DbgPrint, которые изначально заложил в код разработчик и больше ничего. В тестировании обычно применяется в том случае, когда проблема невоспроизводима на машине разработчика, а встроенный логгер по какой-либо причине неприменим (по причине падения приложения или нет его вообще) тогда разработчик обильно обкладывает проблемные места отладочной печатью и отправляет приложение тестировщику, который его гоняет и логи возвращает обратно — через несколько итераций проблема обычно находится. По хорошему после обнаружения проблемы отладочную печать надо отключить.
Volnyii Автор
Не знал, как описать вывод содержимого, спасибо за развернутый ответ! С помощью dv я репортил несколько багов и, например, наблюдал в выводе, что на определенных событиях, якобы, физически от видеокарты отключается один из мониторов (хотя на деле это было не так).
p.s. исправил содержимое статьи, чтобы не вводить в заблуждение других интересующихся