Отчет по производственной практике в компании "Software Technologies"

  Министерство  образования и  науки Российской Федерации

  Федеральное агентство по образованию

  Государственное образовательное  учреждение

  высшего профессионального  образования

  Таганрогский  Технологический  Институт

  Южного  Федерального Университета

  Факультет автоматики и вычислительной техники

  Кафедра САиТ 
 
 
 
 
 
 
 

  Отчет по производственной практике. 
 
 
 
 
 
 

  Выполнила студентка гр. А-156:

  Галатенко Виктория 
 

  Руководитель  практики :

  Шевченко  О.В. 
 
 
 
 
 

  Таганрог

  2010г.

 

1. Описание предметной области.

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

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

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

       Как одна из основных фаз процесса разработки программного продукта (Дизайн приложения – Разработка кода – Тестирование), тестирование характеризуется достаточно большим вкладом в суммарную трудоемкость разработки продукта. Широко известна оценка распределения трудоемкости между фазами создания программного продукта: 40%-20%-40% , из чего следует, что наибольший эффект в снижении трудоемкости может быть получен прежде всего на фазах проектирования и тестирования. Поэтому основные вложения в автоматизацию или генерацию кода следует осуществлять, прежде всего, на этих фазах.

     Рассмотрим  более подробно процесс работы отдела тестирования.

     Отдел тестирования является одним из функциональных подразделений компании (рис 1).

Рисунок 1. 

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

     Как правило, команда по тестированию программного продукта состоит из следующих ролей:

• Руководитель  группы тестирования (Test manager) – представляет ключевую роль тестировщика в рабочей группе, несет ответственность за организацию процесса тестирования в проекте, планирование и контроль действий по тестированию.

• Тест аналитик (Test analyst) – несет ответственность за формирование тестовых спецификаций, и анализ итогов тестирования.
• Тест разработчик (Test developer) – несет ответственность за разработку автоматизированных тестов, предусмотренных в плане тестирования, установку и сопровождение инфраструктуры тестирования, создание стенда для проведения тестирования в соответствии с планом тестирования.
• Исполнитель тестов (Test operator) -  несет ответственность за фактическое исполнение тестов и документирование выявленных дефектов.

     Приведенные роли могут совмещаться внутри группы тестирования.

     Рассмотрим  структуру отдела более подробно. Отдел тестирования состоит из руководителя отдела тестирования и нескольких тестировщиков, их количество может изменяться в  зависимости от масштабов проекта (рис 2).

     Рисунок 2.

     Целью работ по тестированию является выявление и исправление ошибок в программном продукте до того, как он попадет к конечному пользователю.

     Выявленные в ходе тестирования ошибки полностью описываются и документируются. Полная документация, созданная в ходе тестирования, сохраняется и сдается в архив по завершении проекта.

     Далее перечислена документация, создаваемая  в ходе процесса тестирования.

      План  тестирования (Test plan).

     Цель плана тестирования – обеспечить полноту процесса тестирования.

     План  тестирования разрабатывается на основе технического задания - требований к продукту.

     В плане тестирования описываются  способы, виды и критерии тестирования для всех требований, необходимые ресурсы и порядок выполнения тестирования.

     План  тестирования согласуется со всеми  ключевыми членами рабочей группы и утверждается менеджером проекта.

     Тестовые спецификации (test case specifications)

     Цель  тестовых спецификации – дать полное определение тестов.

     Тестовые  спецификации разрабатываются на основе плана тестирования и технического проекта.

     Тестовые процедуры (Test-Procedure Specifications)

     Цель  тестовых процедур – определить набор  последовательных действий для полного  тестирования определенного набора требований для определенного тестируемого элемента. Тестовая процедура определяет действия для выполнения набора тестовых спецификаций.

      Отчет тестирования (Test incident report)

     Отчет тестирования имеет целью документировать  описание ошибок (дефектов) возникших в результате тестирования.

      Итоговый  отчет тестирования (Test summary report)

     Итоговый  отчет тестирования имеет целью  документировать результат исполнения плана тестирования. Итоговый отчет тестирования выпускается для каждой выпускаемой версии разрабатываемого программного обеспечения.

     Содержание  каждого из вышеперечисленных документов приведено в приложении. 
 
 
 
 
 
 

 

      2. Предметная схема бизнес-процессов с выделением функции для решения поставленной задачи.

     Представление о ходе процесса тестирования программного продукта могут дать сценарии.(рис. 3, 4, 5, 6).

     Процесс тестирования начинается с разработки плана тестирования на основе технического задания, так как тестирование направлено на выявление проблем, связанных с несоответствием разрабатываемого программного продукта требованиям.

План разрабатывается руководителем отдела тестирования. Содержание плана тестирования приведено в приложении 1.

Далее разработанный план должен быть согласован и утвержден(рис 3). 

 

      Рисунок 3.

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

     Тестовые  спецификации утверждаются руководителем отдела тестирования, руководитель проекта утверждает порядок приемо-сдаточных процедур (рис.4).

      Рисунок 4.

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

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

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

     Рисунок 5. 

     Рисунок 6.

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

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

Рассмотрим  модульное тестирование более подробно.

     Модульное тестирование - это тестирование программы на уровне отдельно взятых модулей, функций или классов.

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

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

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

 Являясь  по способу исполнения структурным  тестированием или тестированием  "белого ящика", модульное тестирование характеризуется степенью, в которой тесты выполняют или покрывают логику программы (исходный текст).