Добавлен: 08.11.2023
Просмотров: 538
Скачиваний: 11
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Сами же динамические плагины представлены двумя файлами (в папке «Plugins»):
-
NewWin.dll (создание множества различных дочерних MDI-окон, одного класса) -
About.dll (единственное MDI-окно, эмулирующее диалоговое окно «О программе»).
Заметим, что эти плагины имеют собственные внешние ресурсы в папке «Plugins\Res».
Если добавить плагин «NewWin.dll» в папку «Plugins», то увидим следующие изменения. Этот плагин создает несколько различных окон с цитатами Владимира Маяковского. При этом, первое окно центрируется, а последующие располагаются по диагонали, со смещением.
Если изменить размеры текущего окна, то следующее окно тоже изменится соответственно, только на отступы это не повлияет.
Хотя это и не принципиально, но мы ограничили количество одновременно открытых окон, при превышении которых будет выдано предупреждение. Поскольку это обычное окно, а не диалог, то оно может менять фокус, размеры и местоположение. При этом размеры окна сохраняются, но, при открытии, оно всегда центрируется.
Благодаря наличию внешних ресурсов у плагинов, все эти окна полностью настраиваются. Можно менять практически все, вплоть до пиктограмм, пунктов меню, «горячих» и Alt-клавиш для них. Не говоря уже о файлах изображений и тексте в окнах.
20.04.23
Разработка тестовых наборов и тестовых сценариев
Для разработки тестовых сценариев и выполнения тестов используются системыуправления тестированием, существенно повышающие производительность тест-дизайнеров и тестировщиков, а также обеспечивающие видимость уровня качества приложений среди всех участников проекта.
Тестовые сценарии неразрывно связаны с требованиями, изменения в которых должны своевременно отражаться в тестовой документации, что позволяет сделать система управления жизненным циклом разработки приложений, при помощи механизма трассировок.
При выполнении теста тестировщик отмечает результат прохождения одного шага или всего тестового сценария, прикрепляет обнаруженные ошибки и другую вспомогательную информацию: скриншоты, дампы, логи и т.п.
Тестовые сценарии удобно объединять в тест-планы назначению:
-
тестирование релиза, то есть очередной версии продукта; -
тестирование развертывания; -
тестирование удобства использования; -
конфигурационное тестирование; -
тестирование безопасности и т.п.
Зачастую ручное тестирование превращается в рутину и занимает значительное время, что отрицательно сказывается на скорости выпуска релизов. Автоматизация тестирования позволяет:
-
высвободить ресурсы для проведения более сложных видов тестирования; -
снизить количество дефектов, доходящих до стадии контроля качества; -
ускорить выпуск релизов.
Сведение результатов автоматических и ручных тестов в системе управления качеством, позволяет всем участникам проекта видеть уровень качества очередного релиза, контролировать его изменение и опираться на эту информацию при планировании своей работы.
Получение результатов тестирования и их анализ.
Получение результатов тестирования напрямую зависит от средств тестирования. В моем случае это был встроенный в 1С механизм отладки и система контроля ошибок.
Перед получением результата программа проходит несколько уровней:
-
Тестирование компонентов — тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция. Часто тестирование компонентов осуществляется разработчиками программного обеспечения. -
Интеграционное тестирование — тестируются интерфейсы между компонентами, подсистемами или системами. При наличии резерва времени на данной стадии тестирование ведётся итерационно, с постепенным подключением последующих подсистем. -
Системное тестирование — тестируется интегрированная система на её соответствие требованиям. -
Альфа-тестирование — имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком. -
Бета-тестирование — в некоторых случаях выполняется распространение предварительной версии (в случае проприетарного программного обеспечения иногда с ограничениями по функциональности или времени работы) для некоторой большей группы лиц с тем, чтобы убедиться, что продукт содержит достаточно мало ошибок. Иногда бета-тестирование выполняется для того, чтобы получить обратную связь о продукте от его будущих пользователей.
Часто для свободного и открытого программного обеспечения стадия альфа-тестирования характеризует функциональное наполнение кода, а бета-тестирования — стадию исправления ошибок.
21.04.23
Разработка проколов тестирования
Целью моего сегодняшнего дня является разработка протоколов тестирования.
Протоколы по каждому тесту должны содержать информацию, достаточную для повторения теста. Данная информация должна включать:
-
план тестирования или технические требования (спецификацию) к тестированию, содержащие контрольные примеры (для каждого контрольного примера указаны его цели); -
все результаты, связанные с контрольными примерами, включая все ошибки, выявленные при выполнении теста; -
штат персонала, вовлеченного в тестирование.
Отчет о тестировании
В отчете о тестировании должны быть суммированы цели и результаты тестирования (описанные в протоколах тестирования для каждого теста). Отчет о тестировании должен иметь следующую структуру.
-
Обозначение продукта. -
Вычислительные системы, использованные при тестировании (технические средства, программные средства и их конфигурация). -
Использованные документы (включая их обозначения). -
Результаты тестирования описания продукта, документации пользователя, программ и данных. -
Перечень несоответствий требованиям. -
Перечень несоответствий рекомендациям либо перечень не учтенных в продукте рекомендаций, либо формулировка того, что продукт не был протестирован на соответствие рекомендациям. -
Дата окончания тестирования.
Когда продукт, который уже был протестирован, тестируется, тогда выполняются следующие требования.
22.04.23
Оформление документации на программные средства
Программная документация является неотъемлемым компонентом программного продукта и должна оформляться в соответствии с Единой системой программной документации (ЕСПД - ГОСТ серии 19). В рамках учебных работ допускается заключать всю содержательную часть программной документации в единый «отчёт по программе», при этом формальные требования к оформлению такого отчёта соответствуют требованиям к отчёту по НИР. Программная документация, кроме формальных документов (спецификация, ведомость держателей подлинников, формуляр и др.), включает:
-
Техническое задание (назначение, область применения программы, требования, предъявляемые к программе). -
Текст программы (запись программы с необходимыми комментариями). -
Описание программы (сведения о логической структуре и функционировании программы). -
Пояснительная записка (схема алгоритма, общее описание алгоритма и/или функционирования программы, обоснование принятых решений). -
Эксплуатационные документы.
Программный документ «Пояснительная записка» составляется на стадии эскизного или технического проектов программы. Как правило, на стадии рабочего проекта не используется.
К эксплуатационным документам относят:
-
Описание применения (сведения о назначении программы, области применения, применяемых методах, классе решаемых задач, ограничениях для применения, минимальной конфигурации технических средств). -
Руководство системного программиста (сведения для проверки, обеспечения функционирования и настройки программы на условия конкретного применения). -
Руководство программиста (сведения для эксплуатации программы). -
Руководство оператора (сведения для обеспечения общения оператора с вычислительной системой в процессе выполнения программы). -
Описание языка (описание синтаксиса и семантики языка). -
Руководство по техническому обслуживанию (сведения для применения тестовых и диагностических программ при обслуживании технических средств).
Основная часть программной документации составляется на стадии рабочего проекта. Необходимость того или иного документа определяется на этапе составления технического задания. Допускается объединять отдельные виды документов. Эксплуатационный документ «Описание языка» включается в программную документацию, если разработанный программный продукт реализует некий язык программирования, управления заданиями, организации вычислительного процесса и т. П. Эксплуатационный документ «Руководство по техническому обслуживанию» включается в программную документацию, если разработанный программный продукт требует использования тестовых или диагностических программ.