Comments 15
Хотелось бы подробнее узнать о тестирование утечек памяти. Не хватило этой инфы
После завершения ресурсоемких задач приложение (и его дочерние процессы) должно освободить ОЗУ. До фонового режима, или полностью, если оно закрыто.
Если в процессе работы было занято 2Гб оперативки, то после завершения эти 2Гб должны освободиться.
Ну и в режиме "простоя" потребление памяти не должно расти.
"в то же время, когда приложение "задыхается" от её нехватки"
Не понял, что вы имеете в виду.
Если приложение до начала обработки изображения занимало 100Мб, то, в идеальных условиях, после окончания обработки оно должно занимать те же 100Мб.
Если процесс отъел всю доступную ОЗУ и не осовобождает ресурсы после выполнения операции - снимаю дамп и отправляю разработчику. Он уже под отладчиком разберется, что, куда и почему.
1536x864 (10.91%)
Это ноутбуки с 1920*1080 при scale 125% ?
Тстирование установки я бы рекомендовал именно на голую ОС. То есть на ту, где тестируемое приложение вообще не устанавливалось. Потому что совсем не факт, что при удалении приложения всё подчищается корректно (папки, ключи в реестре, библиотеки и т.д.). Виртуалки идеально для этого подходят;
Если есть работа с дробными числами, то в языковых настройках рекомендую проверить работу с обоими вариантами разделителя целой и дробной частей (точка и запятая). Встречал проблемы при вводе дробей в приложениях и при запуске командных файлов с дробями;
Вызов сторонних приложений надо тщательно проверять (если он есть, конечно). Офис, графика, pdf и т.д;
Комбинации клавиш надо также проверять. Особенно если есть компоненты, у которых есть быстрый вызов. Интересные явления возникают если у 2-х резидентов одинаковые комбинации клавиш задействованы :)
В результате начинается использование виртуальной памяти, что замедляет производительность из-за более медленного доступа к данным.
Тут требуется уточнить, мне кажется.
Десктопные приложения в принципе с самого начала работы используют виртуальную память, которую операционная система им выделяет, а не оперативную память напрямую. Приложение может запросить больше памяти, чем физически доступный объём оперативной памяти в системе, и операционная система может вполне себе выделить этот объём. Она потому и называется виртуальной, что где хранить страницы памяти, в оперативной памяти или на диске (в свопе), решает операционная система, приложение обычно не может сказать "хочу столько-то физической оперативной памяти". Начинает тормозить обычно в случае, когда происходит активный обмен страницами между оперативной памятью и диском, что для самого приложения должно быть прозрачно. И основная причина - приложению требуется иметь доступ к бОльшему объему памяти, чем операционная система позволяет разместить в данный момент в оперативной памяти (либо потому,что другим приложениям она тоже требуется, либо потому, что приложение хочет больше, чем доступно физической памяти).
Интересно было бы узнать про подход к автоматизации если такой имеется.
Ещё вспомнилось:
Если предусмотрена одновременная работа нескольких экземпляров, то надо проверить работу каждого экземпляра. А если такой режим непредусмотрен, то тем более надо проверять как будет выглядеть для пользователя запуск 2-го экземпляра. И как после неудачной попытки повторного запуска будет работать первый экземпляр;
Взаимодействие с устройствами обязательно проверить на ситуацию когда устройство в системе заявлено, а по факту недоступно. Приложение должно корректно обрабатывать эту ситуацию, а не выпадать в осадок.
По оперативной памяти. На windows есть 32\64 bit приложения. У них разное выделение памяти под операции в приложении. Сейчас скорее всего пишутся на 64. Но все же
Особенности тестирования десктопных приложений