Структура приложения.
Автоматизация регрессионного тестирования
По стандарту, установленному нашим проектом, на выполнение ручного регрессионного тестирования одного элемента уделяется 0,5ч/ч (человеко-час). Максимальное количество членов команды, которое может быть задействовано в ручном регрессионном тестировании, ограничивается общим количеством людей в команде, выделяемых для проведения данного вида тестирования, и для нашего проекта составляет не более 4… Читать ещё >
Структура приложения. Автоматизация регрессионного тестирования (реферат, курсовая, диплом, контрольная)
Тестируемый программный продукт работает с телекоммуникационными сетями нового поколения. Имеет следующие функции: конфигурация, настройка, изменение и оптимизация параметров сетей беспроводного доступа.
Клиентская часть реализует пользовательский интерфейс, формирует запросы к серверу и обрабатывает ответы от него. Основой клиентской части в тестируемом программном продукте является программная платформа Microsoft Silverlight.
Серверная часть получает запрос от клиента, выполняет операции, после этого формирует отчет и отправляет его клиенту. В текущем продукте сервер написан на языке Java. При этом весь функционал ПО, используемые плагины и библиотеки также находятся на стороне сервера. Основная работа в процессе автоматического тестирования будет проходить с плагинами при использовании библиотек сервера.
Процесс регрессионного тестирования
Прежде, чем приступать к описанию процесса регрессионного тестирования, следует обратить внимание, на что затрачиваются ресурсы во время верификации элементов проверки соответствия.
Для того, чтобы выполнить регрессионное тестирование, тестировщику необходимо иметь файл с описанием конфигурации в формате XML (созданный во время ручного тестирования элемента проверки соответствия) и отчет с результатами проведения проверки соответствия на текущей конфигурации. Отчет имеет удобную форму, в которой сообщается о тестируемых объектах конфигурации и соответствующих им сообщениях после проведения тестирования. Таким образом, задачей тестировщика является запуск тестируемого приложения, загрузка файла конфигурации, запуск определенного элемента проверки соответствия, сравнение полученных результатов с имеющимся отчетом и анализ этих данных.
По стандарту, установленному нашим проектом, на выполнение ручного регрессионного тестирования одного элемента уделяется 0,5ч/ч (человеко-час). Максимальное количество членов команды, которое может быть задействовано в ручном регрессионном тестировании, ограничивается общим количеством людей в команде, выделяемых для проведения данного вида тестирования, и для нашего проекта составляет не более 4 человек.
Ручное регрессионное тестирование проверки соответствия. В начальной версии 2.0 тестируемого программного продукта не производилось регрессионное тестирование проверки соответствия, т.к. не было необходимых файлов с описанием конфигураций, участвующих в процессе тестирования элементов проверки соответствия, и отчетов ее выполнения. В течение года члены команды, в зависимости от своей деятельности, выполняли обычное тестирование элементов проверки соответствия. На один тест тестировщик, исходя из стандартов проекта, может потратить 2,5ч/ч.
В следующей версии 2.1 тестируемого программного продукта не только появились новые элементы проверки соответствия, но и образовалась база из файлов и отчетов проведенных тестов на проверку соответствия в предыдущей версии программного обеспечения.
В текущей версии 2.2 тестируемого приложения увеличилось количество тестов для регрессионного тестирования, и также прибавились новые элементы, структуры которых будут покрыты тестировщиками в течение жизненного цикла этой версии.
Таким образом, можно сделать вывод о том, что количество тестов, участвующих в регрессионном тестировании элементов проверки соответствия, с каждой версией становится все больше и больше, а значит количество времени, затрачиваемое на данную деятельность, также растет.
Если в версии продукта 2.1 регрессионное тестирование элементов проверки соответствия занимало не более 37 дней рабочего времени (md, «man-days»; единица измерения производительности трудящегося) инженера по тестированию в год, то для версии продукта 2.2 это заняло бы более 60 рабочих дней в год при его обычном выполнении дважды за версию одним человеком и в три раза меньше в условиях работы трех членов команды. Несмотря на то, что регрессионное тестирование является одним из самых важных видов тестирования любого программного продукта, проект не может позволить себе затрачивать столь значительные ресурсы. Это также стало одной из причин проявления интереса к автоматизации регрессионного тестирования элементов проверки соответствия.