Привет! Меня зовут Лена, и я тестировщица. Очень много времени я посвятила тестированию десктопа - библиотек, интерфейсов, приложений, программных комплексов, и даже программно-аппаратных комплексов! Мне сказали что тема актуальная, а информации по ней мало, так зачем пропадать знаниям?

Буду делиться понемногу тем, что я выношу из своего опыта и тем, что где-то когда-то зацепила из чужого. Долгое время я не решалась что-то писать потому, что на самом деле всё уже написано до нас - есть учебники, статьи в википедии, лучшие практики для разработчиков. Когда я что-то хочу узнать, это в принципе легко гуглится, но как понять что тебе хотеть узнать, если это область, в которой ты впервые и не можешь понять пока, какие вопросы задавать гуглу? Ну что такое, вот я хочу рассказать как устроен рабочий стол? Так проще дать людям учебник про линукс с нуля (ну да, там не будет Win, и сравнения с Mac, но какая-то база...). Что внутри программы? Ну, есть учебники для программистов, для проектирования ПО.

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

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

Но попробуйте посчитать, каким количеством десктопных приложений вы пользуетесь ежедневно. Почту многим удобнее получать в почтовом клиенте, например в outlook. Мессенджеры тоже удобнее установить прямо на компьютер (telegram, skype, slack, twi... о, нет, конечно twitter это уже не десктоп, это веб-клиент). Огромное количество людей ежедневно открывают веб-браузеры (да, браузер это тоже десктопное приложение, очень любопытная задача для тестирования), играют в локальные игры, создают документы и презентации в офисных приложениях, сохраняют отсканированные документы, распаковывают архивные файлы, качают торренты, защищаются антивирусами, читают книги.

Как тестировщик, я пользуюсь ещё бОльшим количеством приложений на своём компьютере, например утилитами командной строки, дебаггерами, программами для записи и редактирования скриншотов и действий, приложениями для удалённого доступа, гипервизором, проксирующим ПО.

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

Всё перечисленное нужно кому-то тестировать, и кто-то это делает, и этот кто-то - тестировщики (иногда тестировщиками бывают разработчики, а иногда пользователи, но у них в этот момент роль тестировщиков).

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

Какие признаки у десктопного ПО, чтобы вы не спутали его с чем-то другим, например с веб-клиентом?
Я выделила несколько:

- программа устанавливается на ОС (устанавливается - это когда создаются директории для библиотек и прочих файлов ПО, создаются конфиги (nix), ветка в реестре (win), при установке происходит инициализация - применение настроек программы именно для этой ОС на этом компьютере)

- программа может работать в изолированной среде (у неё могут не быть доступны какие-то функции, но в общем и целом что-то делать будет можно). отключите интернет, и если программа осталась полезна - 99% что это десктопная программа

- настройки программы будут работать для этого компьютера (или для этого профиля пользователя на этом компьютере)
воот... так что twitter или steam это не десктоп, даже если у них есть иконка на рабочем столе, это веб-клиенты, и работают они с помощью веб-браузера

Обычно при тестировании многоплатформенных десктопных приложений мы выбираем тестовое окружение не только по статистической распространённости, но по семейству ОС (Windows, Unix, Linux, MacOS…), их версиям, архитектуре (х86, х64, ARM64…). Но когда у вашего ПО есть графический интерфейс и нужен особый упор на его тестирование, я рекомендую учитывать в выборе тестовых условий особенности графических оболочек (Desktop Environment)

DE - среда рабочего стола (desktop environment) - обеспечивает отображение окон, пиктограмм, панелей (списки программ, трей…) и взаимодействие с ними (click, drag-n-drop и тд)

В Windows за графический интерфейс отвечает Explorer, в MacOS - Aqua, последнее время стали актуальны программы с GUI для Unix, у них есть свои особенности, которые стоит покрыть тестированием.

Начнём с того, что в Unix/Linux есть два основных фреймворка, на основе которых созданы DE - это Qt и GTK.

Зоопарк юниксовых графических интерфейсов в ОС, которые поддерживаются разрабатываемыми приложениями, можно и нужно ограничить устанавливаемыми по умолчанию, а это обычно MATE, GNOME, KDE (различных версий, кстати), остальное считаем экзотическими случаями.

Для наглядности набросала табличку и добавила в неё нераспространённых примеров для тех, кто тестирует приложения под ОС российского производства. Если у вас есть возможность уделить побольше времени тестированию, можно взять условно Ubuntu и проверять ваше приложение с разными DE, которые доступны в репозиториях для Ubuntu, использующими разные интерфейсы.

Коварная ОС - FreeBSD она поставляется без графической оболочки и пользователи склонны к установке разнообразнейших рабочих столов, поэтому тестовых вариантов становится ещё больше.

KDE - разработка коммерческой компании, выкидывается в опенсорс, исторически ЖРАЛА много оперативки и сейчас мало распространена, больше для примера (да-да, это её патчили в известной легендарной копипасте)
GNOME на GTK - сразу чистый опенсорс, сейчас почти везде в опенсорсных ОС
fly и MATE - могут быть важными DE не только из-за широты распространения в мире, но и потому что используются в российских ОС Astra и ALT linux
кроме того есть ещё очень много других примеров, гуглятся по “среда рабочего стола” и DE

дальше я понемногу расскажу - а что, собственно, тестировать относительно DE

Рабочие столы могут работать с приложениями, чей GUI написан на отличных от них интерфейсах, например приложение на Qt может работать в среде на GTK, для этого должны быть доустановлены библиотеки Qt

Проблемы могут возникать на стыке такого взаимодействия, когда GUI программы работает с чем-то внешним на другом интерфейсе. Например рабочий стол написан с использованием GTK, ваше тестируемое приложение тоже, а трей, в котором ваше приложение может показывать своё состояние и из которого могут выбрасываться служебные сообщения, сделан на Qt

Некоторое время колебалась, с чего продолжить. По идее продолжать нужно с того, каким образом мы тестируем запуск нашего приложения, тема суровая, немаленькая, но уводит от DE на уровень ниже, в работу с памятью и хранением. Эту тему пока отложу, а начну об окнах.

Первое что нужно сказать - при тестировании окон у нас появляется помощь от разработчиков операционных систем и API. Чтобы ПО вписалось в ОС, соответствовало требованиям безопасности, стилю и принципам разработки под конкретную ОС, разработчики выпускают рекомендации.

Вот примеры
Microsoft
Лучшие практики https://docs.microsoft.com/ru-ru/windows/apps/get-started/best-practices
Они бывают не только про GUI, а вот про документирование https://docs.microsoft.com/en-us/style-guide/welcome/ или безопасность https://docs.microsoft.com/en-us/security/zero-trust/zero-trust-overview
GNOME style guide https://developer.gnome.org/hig/
KDE https://develop.kde.org/hig/
MacOS https://developer.apple.com/design/human-interface-guidelines/platforms/designing-for-macos/

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

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

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

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

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

Когда для приложения выбирается язык разработки, учитывается наличие удобных решений и фреймворков, удобные качественные готовые библиотеки, подходящие для приложения (например у JavaScript есть хорошие библиотеки для web, а у С++ для desktop). Я к тому что это чужой код.

Обычно начинающие тестировщики при тестировании окон руководствуются только своим пользовательским опытом и пониманием удобства. Предлагаю узнавать какие фреймворки и библиотеки берут разработчики и поизучать, чтобы понять общую концепцию, какие у окон приложения могут быть свойства и что можно проверить.
Примеры, как это выглядит
.NET https://docs.microsoft.com/ru-ru/dotnet/desktop/winforms/?view=netdesktop-6.0
wxWidgets https://docs.wxwidgets.org/3.2/modules.html

продолжение ниже 🔽

И вдогонку длинный текст о моих любимых проверках

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

Триггером для проверки может служить
- изменение требований для окон,
- переход на новую версию средств разработки (фреймворка, компилятора и тп),
- переписывание интерфейса с нуля,
- самое начало разработки,
- добавление поддержки новой ОС,
- какие-то другие значимые изменения.

Например мы можем узнать, что начиная с Windows10 меню Пуск на рабочем столе становится отдельной программой (в старших версиях за него отвечал Explorer), а значит нужно проверить что наше приложение продолжает правильно работать из этого меню.

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

Итак, что я люблю проверять:

Способы запуска основного окна приложения, симлинки-шоткаты, вызов из других приложений, запуск из командной строки)

Права пользователя при запуске и работе, многопользовательский доступ

Место отображения - на рабочем столе, на разных рабочих пространствах (рабочих столах). Через приложение для удаленного доступа по разным протоколам (RDP-клиент, MacOS X по SSH и тп.) Бывает такая штука как публикация приложения, например в доменах под управлением Active Directory можно на сервере публиковать приложение, на клиентских машинах будет по ярлыку на рабочем столе открываться окно для работы пользователя

Позиционирование на экране монитора при первом запуске

Масштабируемость - окно может быть немасштабируемым, а у масштабируемого есть граничные значения (minsize, maxsize)

Адаптируемость к размерам окна, layout элементов - при изменении элементы (кнопки, поля, надписи) позиционируются правильно

Различные разрешения экранов

Различные темы (на большинстве ОС можно менять темы или устанавливать дневной-ночной режимы)

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

Поддержка режимов для слабовидящих, средств чтения с экрана и голосового ввода, когда ваши требования так хороши, что в их основе стоит принцип доступности

Порядок выведения основного окна и дочерних окон на экран, если открыты окна других приложений

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

Диалоговые окна могут содержать недостаточную, избыточную или непонятную для пользователя информацию, отображение критических событий или сообщений могут отличаться в разных средах

К тестированию отображения окон отнесу возможность или невозможность запуска нескольких экземпляров приложения и соответственно нескольких основных окон в одном профиле пользователя (это зависит от требований к вашему приложению, и больше не про графику, а про многопроцессность, но она тянет за собой и графику)

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

Запоминание пользовательских настроек окна, если это предусмотрено требованиями

Продолжение публикации 🔼

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

Особые проблемы могут доставлять окна, информация в которых динамически обновляется, например при подключении нового носителя информации

Поведение окна при выходе из спящего режима. Это практически неавтоматизируемый кейс, кроме неправильного поведения рабочего стола и отображения окон в этом кейсе часто вылезают ещё и другие проблемы с памятью.

Иногда на ОС вообще не устанавливается графический рабочий стол для экономии ресурсов или за ненадобностью. Пользователь работает в таком случае с командной строкой, терминалом ssh и особой реализацией в виде псевдографического интерфейса. О последнем и расскажу.

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

В чём особенности таких интерфейсов?

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

Управление в псевдографических интерфейсах происходит в основном или только с помощью клавиатуры.

Для реализации этих окон могут быть использованы специальные готовые программы и библиотеки, например whiptail, dialog, а это значит реализация ограничена тем, что в них заложено, наше ПО передаёт туда параметры и пользователь получает картинку.

Если у нас в тестировании псевдоокна для работы в терминале ssh или нативном приложении командной строки, то нужно проверять с разными ssh-клиентами и разными консольными приложениями. Набор может быть ограничен требованиями, а если нет, то для тестирования лучше брать несколько распространённых, к примеру putty, MobaXterm, openssh client, терминалы ОС из коробки, на Windows приложения cmd и PowerShell. Рекомендую поинтересоваться требованиями заранее.

Картинку можно сломать всегда с помощью плохо установленного разрешения в терминале. Поэтому хорошо бы проверять при стандартных разрешениях и по методу граничных значений.

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

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

PS. В современных BIOS (UEFI) интерфейс может быть графическим и даже работает мышь.

Утечки памяти. Компьютер обрабатывает данные небольшими частями. В оперативную память загружается некоторый объём данных, производятся операции, потом загружается следующий и тд. При этом оперативная память освобождается от уже ненужных данных. Иногда освобождения не происходит, данные загружаются и загружаются, память забивается, компьютер начинает дико тормозить, сыплются ошибки, аварийно завершаются программы. Помогает перезапуск сервиса.

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

Хороший метод для определения утечек ресурсов - НАДОЛГО запустить сервис с нагрузкой около 70% от максимальной. Он позволяет найти не только утечки памяти, дескрипторов, а также исчерпание дискового пространства, невысвобождение портов, если это сетевой сервис (когда он открывает новые порты, а потом их не закрывает и не переиспользует)

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

Маргарита Логунова написала статью про тестирование десктопных приложений, считаю что публикации конкурентов нужно распространять! https://habr.com/ru/articles/783404/