Реферат Отчет по производственной практике в компании Software Technologies
Работа добавлена на сайт bukvasha.net: 2015-10-28Поможем написать учебную работу
Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
от 25%
Подписываем
договор
Министерство образования и науки Российской Федерации
Федеральное агентство по образованию
Государственное образовательное учреждение
высшего профессионального образования
Таганрогский Технологический Институт
Южного Федерального Университета
Факультет автоматики и вычислительной техники
Кафедра САиТ
Отчет по производственной практике.
Выполнила студентка гр. А-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.
Из всех вышеперечисленных работ наиболее трудоемкий и ответственный процесс-это построение тестовых наборов и тестовых случаев. В зависимости от вида тестирования и критерия оценки его эффективности, построение тестовых наборов может быть организовано различными способами.
Тестирование можно разделить на модульное тестирование(тестируются модули на соответствии их своей спецификации), интеграционное(тестирование взаимодействия между модулями) и системное(тестирование пользовательских сценариев).
Рассмотрим модульное тестирование более подробно.
Модульное тестирование - это тестирование программы на уровне отдельно взятых модулей, функций или классов.
Цель модульного тестирования состоит в выявлении локализованных в модуле ошибок в реализации алгоритмов, а также в определении степени готовности системы к переходу на следующий уровень разработки и тестирования. Модульное тестирование проводится по принципу "белого ящика", то есть основывается на знании внутренней структуры программы, и часто включает те или иные методы анализа покрытия кода.
Модульное тестирование обычно подразумевает создание вокруг каждого модуля определенной среды, включающей заглушки для всех интерфейсов тестируемого модуля. Некоторые из них могут использоваться для подачи входных значений, другие для анализа результатов, присутствие третьих может быть продиктовано требованиями, накладываемыми компилятором и сборщиком.
На уровне модульного тестирования проще всего обнаружить дефекты, связанные с алгоритмическими ошибками и ошибками кодирования алгоритмов, типа работы с условиями и счетчиками циклов, а также с использованием локальных переменных и ресурсов. Ошибки, связанные с неверной трактовкой данных, некорректной реализацией интерфейсов, совместимостью, производительностью и т.п. обычно пропускаются на уровне модульного тестирования и выявляются на более поздних стадиях тестирования.
Являясь по способу исполнения структурным тестированием или тестированием "белого ящика", модульное тестирование характеризуется степенью, в которой тесты выполняют или покрывают логику программы (исходный текст).
Тесты, связанные со структурным тестированием, строятся на основе потока управления. В этом случае элементы, которые должны быть покрыты при прохождении тестов, определяются на основе структурных критериев тестирования. К ним относятся вершины, дуги, пути управляющего графа программы (УГП), условия, комбинации условий и т. п.
3. Формирование критериев и выбор математической модели.
Управляющий граф программы(УГП) – это структурная модель программы, которая показывает связь между ее элементами. В модели вершины графа – операторы разветвления и объединения; дуги – операторы обработки и передачи данных. На рисунке 7 изображен упрощенный пример УГП.
Рисунок 7.
Тестирование программы по некоторому критерию означает покрытие множества компонентов программы по элементам или по связям. То есть, 100% покрытие тестами кода программы означает, что каждый оператор (строка кода) должен быть выполнен хотя бы один раз.
При тестировании систем, поведение которых определяется не только последним обращением к ним, а и предшествующей историей работы, то есть зависит от внутреннего состояния системы, необходимо строить тесты, покрывающие как можно больше разнообразных комбинаций внутренних данных системы. Если представить тестовый случай как покрытие ветви программы(на графе ветвь программы изображается в виде дуги),то обход всех дуг графа даст 100% покрытие ветвей программы, но не даст 100% тестирования комбинаций .
Если рассматривать в качестве примера граф, изображенный на рисунке 7, то последовательность обхода дуг графа a b c b f e g d e g даст стопроцентное покрытие операторов кода программы.
Однако можно заметить, что ,например, комбинация переходов bg в такой последовательности не встречается. Это означает, что не все комбинации данных будут протестированы, и неверная работа программы при обработке такой комбинации не будет выявлена.
При значительных объемах кода или сложной структуре модуля существует большая вероятность того, что многие комбинации данных не будут учтены тестировщиком при построении тестовых наборов и ошибки не будут выявлены, что в дальнейшем значительно затруднит интеграционное и системное тестирование программного продукта и приведет к снижению его качества.
Задача построения тестового набора, охватывающего все возможные комбинации, может быть решена методом полного перебора, однако при большом количестве операторов ветвления это приводит к комбинаторному взрыву.
Таким образом, при тестировании многих программных продуктов возникает проблема построения такого набора тестов, который бы максимально полно охватывал комбинации данных, обрабатываемых программой, и при этом исключал многократное покрытие одних и тех же наборов данных.
3. Оптимизация процесса построения тестовых наборов.
Для решения сформулированной проблемы требуется алгоритм, позволяющий на основе управляющего графа программы строить тестовый набор, который будет охватывать все комбинации данных. Также этот тестовый набор должен допускать как можно меньше повторений тестовых случаев, так как на выполнение тестов нужно много времени, а сроки проекта всегда ограничены.
В качестве такого алгоритма хорошо подходит алгоритм построения последовательностей Де Брейна. Этот алгоритм позволяет строить кратчайшую последовательность переходов, охватывающую все их возможные комбинаци. Краткость генерируемой последовательности является важным аспектом, так как на выполнение тестов нужно много времени, а сроки проекта всегда ограничены.
Перед тем, как описать алгоритм, следует привести некоторые определения.
Эйлеровым путем графа G(V,E) называется путь e1,e2…et, такой, что каждое ребро появляется ровно 1 раз., то есть t=|E|.
Граф называется Эйлеровым, если он имеет замкнутый Эйлеровый путь, и полуэйлеровым, если существует Эйлеров путь, не являющийся замкнутым.
Рассмотрим процесс построения графа де Брейна на основе управляющего графа программы.
1. Исходный граф программы преобразуется в граф Де Брейна, то есть таким образом, что каждая дуга становится вершиной.
2. Везде, где в исходном графе одна дуга входит в вершину, а вторая дуга выходит из этой вершины, в графе Де Брейна строится дуга из вершины 1 в вершину 2. Например, на исходном управляющем графе программы, изображенном слева на рисунке 8, дуга «а» входит в вершину, из которой выходит дуга «b», на графе Де Брейна справа дуга соединяет вершины «а» и «b».
3. После того, как граф Де Брейна построен, следует обойти все его ветви, записывая пройденные вершины. Для Эйлерова графа это будет Эйлеров путь.
Для графа, изображенного на рисунке 8 справа, получим последовательность обхода дуг управляющего графа программы a b c b f e c b g d e f e g.
Такая последовательность может служить основой для построения тестовых наборов, обеспечивающих максимальное покрытие комбинаций данных, избегая при этом излишнего дублирования.
Предложенный алгоритм может быть реализован в виде тестовых скриптов для сокращения доли ручного тестирования.
4. Формы документов.
Ниже представлено содержание документов, создаваемых в процессе тестирования программного обеспечения.
Алгоритм преобразования входных документов в выходные представлен в виде сценариев в разделе 2.
План тестирования (Test plan)
План тестирования должен включать в себя следующие разделы:
| Название раздела | Описание |
| Введение (Introduction) | В разделе приводятся ссылки на исходные документы, описываются общий подход, обеспечивающий полноту тестирования, описываются требования к итерационности разработки на основе снижения рисков и стоимости проведения полного тестирования. |
| Тестируемые требования (Requirements to be tested) | Приводятся тестируемые требования (указываются ссылки на требования). Устанавливаются правила идентификации и прослеживаемости документов для гарантированного тестирования всех запланированных требований. |
| Не тестируемые требования (Requirements not to be tested) | Описываются требования (указываются ссылки), для которых не планируются проведение тестирования. |
| Методы тестирования (Approach) | Основной раздел плана. Включает следующую информацию по всем группам требований, планируемых к тестированию: · Ссылка на требования (идентификатор требования) · Метод тестирования: указывается общий способ тестирования (подход к тестированию), тип тестирования (ручное или автоматизированное), при необходимости дается обоснование специальных методов тестирования · критерий успешности тестов · требования к среде тестирования · требуемые ресурсы · ссылка на тестовую спецификацию (идентификатор тестовой спецификации) |
| Требования к среде тестирования (Environmental needs) | Указываются общие требования к установке стенда, инструментальным средствам, среде тестирования, требования к разработке дополнительных программ (имитационных, управляющих, поддерживающих) и пр. |
| Требуемые Ресурсы (Staffing and Training Needs) | Указываются общие потребности в персонале с учетом уровня квалификации, необходимость обучения для проведения тестирования, требования к времени тестирования |
| Этапы тестирования (Schedule) | Указывается этапы тестирования в связи с этапами разработки и указанием видов тестирования: модульное тестирование, интеграционное тестирование, комплексное тестирование, системное тестирование, опытная эксплуатация (beta – тестирование). |
| Критерии тестирования (Pass criteria) | Указываются критерии завершения тестирования на различных этапах тестирования. В качестве стандартного критерия завершения тестирования принимается достижение заданного уровня плотности ошибок |
Тестовые спецификации (test case specifications)
Для каждой тестовой спецификации указываются следующие разделы:
| Название раздела | Описание |
| Идентификатор (Identifier) | Указывается идентификатор тестовой спецификации, приводимый в плане тестирования. |
| Тестируемый элемент (test item) | Указывается модуль, подсистема или приводится ссылка на описание элемента в техническом проекте. |
| Описание входа (Input Specification) | Описание входной информации, источников информации, условий ввода. |
| Описание выхода (Output Specification) | Описание ожидаемой выходной информации или ожидаемой реакции, полностью идентифицирующей корректность работы тестируемого элемента |
| Метод тестирования (Approach Refinements) | Указывается способ тестирования (детальное описание). |
| Требования к среде тестирования (Environmental needs) | Указываются специальные требования к среде тестирования для данного теста |
| Процедурные требования (Special Procedural Requirements) | Описываются специальные требования к тестовой процедуре, которая будет выполнять данный тест |
| Взаимозависимости (Intercase dependences) | Указываются взаимозависимости между тестовыми спецификациями |
Тестовые процедуры (Test-Procedure Specifications)
| Название раздела | Описание |
| Идентификатор тестовой процедуры (Identifier) | Указывается идентификатор тестовой процедуры |
| Цель (Purpose) | Приводится цель тестовой процедуры. Даются ссылки на исполняемые тестовые спецификации (идентификаторы). |
| Специальные требования (Special Requirements) | Указываются специальные требования, которые необходимо выполнить для обеспечения работы тестовой процедуры. |
| Установка (Set Up) | Указываются предварительные действия, которые необходимы для установки и запуска тестовой процедуры. |
| Процедурные действия (Procedure steps) | Последовательность шагов, выполняемая при проверке тестируемого элемента для ручного тестирования. Для автоматического тестирования указывается ссылка на программу тестирования. |
| Критерии оценки результата | Указываются критерии оценки результатов выполнения тестовой процедуры |
Отчет тестирования (Test incident report)
.
| Название раздела | Описание |
| Идентификатор отчета (Identifier) | Указывается уникальный идентификатор, присвоенный отчету о тестировании |
| Тестируемый элемент (Test element) | Указывается тестируемый элемент, включая версию элемента. |
| Тестовая процедура (Test Procedure) | Дается ссылка на тестовую процедуру (идентификатор). |
| Тестовая спецификация (Test Case) | Дается ссылка на тестовую спецификацию (идентификатор). |
| Описание ошибки (Defect Description) | Дается детальное описание фактического результата выполнения теста по сравнению с ожидаемым в соответствии с тестовой спецификацией |
| Оценка серьезности | Указывается оценка тестировщиком степени серьезности ошибки |
Итоговый отчет тестирования (Test summary report)
| Название раздела | Описание |
| Идентификатор отчета (Identifier) | Указывается уникальный идентификатор, присвоенный отчету |
| Резюме (Summary) | Приводится ссылка на оттестированную подсистему (систему) и ее версию. Приводится ссылка на план тестирования или часть плана (главы) для которого выпускается отчет. Приводятся итоговые данные по полноте тестирования в соответствии с планом и результирующие данные по уровню не исправленных ошибок. |
| Отклонения (Variances) | Указывается все отклонения принятые в тестовых спецификациях и тестовых процедурах относительно плана тестирования. Приводятся причины или обоснования принятых отклонений. |
| Оценка полноты тестирования (Comprehensiveness Assessment) | Проводится оценка полноты тестирования. Дается список пунктов плана, которые выполнены не полностью. Приводятся причины неполного тестирования. |
| Суммарные результаты (Summary Results) | Дается общее описание неразрешенных ошибок. |
| Оценка (Evaluation) | Приводится общая оценка результатов тестирования по всем элементам тестирования (полнота тестирования, плотность неразрешенных ошибок) |
