Методы проектирования программных систем
Основные требования к качеству программного обеспечения, характеристика дефектов. Проектирование на основе структур баз данных (информационно-логические, концептуальные и физические методики). Особенности и этапы тестирования программного продукта.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | реферат |
| Язык | русский |
| Дата добавления | 08.12.2015 |
| Размер файла | 40,0 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ БЮДЖЕТНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ «ФИНАНСОВЫЙ УНИВЕРСИТЕТ ПРИ ПРАВИТЕЛЬСТВЕ РОССИЙСКОЙ ФЕДЕРАЦИИ»
Кафедра прикладная информатика
КОНТРОЛЬНАЯ РАБОТА
по дисциплине: "Программная инженерия"
МЕТОДЫ ПРОЕКТИРОВАНИЯ ПРОГРАММНЫХ СИСТЕМ
МОСКВА
2015 год
Оглавление
программный дефект логический информационный
1. Практические соображения. Требования к качеству программного обеспечения. Характеристика дефектов
2. Объектно-ориентированное проектирование. Проектирование на основе структур данных
3. Процесс тестирования. Практические соображения. Тестовые работы
Список литературы
1. Практические соображения. Требования к качеству программного обеспечения. Характеристика дефектов
Факторы влияния
На планирование, управление и выбор SQM-действий и техник оказывают влияние различные факторы, среди которых:
* Область применения системы, в которой будет работать программное обеспечение (критичное для безопасности ), критичное для бизнеса и т.п.)
* Системные и программные требования
* Какие компоненты используются в системе - коммерческие (внешние) или стандартные (внутренние)
* Какие стандарты программной инженерии применимы в заданном контексте
* Каковы методы и программные инструменты, применяемые для разработки и сопровождения, а также для обеспечения качества и совершенствования (продукта и процессов, прим. автора)
* Бюджет, персонал, организация проектной деятельности, планы и расписания для всех процессов
* Кто целевые пользователи и каково назначение системы
* Уровень целостности системы
Информация об этих факторах влияет на то, как именно будут организованы и документированы процессы SQM, какие SQM-работы будут отобраны (стандартизированы в рамках проекта, команды, организационной единицы, организации, прим. автора), какие необходимы ресурсы и каковы ограничения, накладываемые в отношении усилий, направляемых на обеспечение качества.
Гарантоспособность
В случаях, когда сбой системы может привести к крайне тяжелым последствиям (такие системы иногда называют в англоязычных источниках “high confidence” или “high integrity system”, в русском языке к ним иногда применяют название “системы повышенной надежности”, “высокой доступности” и т.п.), общая (совокупная) гарантоспособность системы (как сочетания аппаратной части, программного обеспечения и человека) является главным и приоритетным требованием качества, по отношению к основной функциональности . Гарантоспособность (dependability) программного обеспечения включает такие характеристики, как защищенность от сбоев (fault-tolerance), безопасность использования (safety - безопасность в контексте приемлемого риска для здоровья людей, бизнеса, имущества и т.п.), информационная безопасность или защищенность (security - защита информации от несанкционированных операций, включая доступ на чтение, а также гарантия доступности информации авторизованным пользователям, в объеме заданных для них прав), а также удобство и простота использования (usability). Надежность (reliability) также является критерием, который может быть определен в терминах гарантоспособности (см. стандарт ISO/IEC 9126-1:2001 “Software Engineering - Product Quality, Part 1: Quality Model”). В обсуждении данного вопроса существенную роль играет обширная литература по системам повышенной надежности. При этом, применяется терминология, пришедшая из области традиционных механических и электрических систем (в т.ч. не включающих программное обеспечение) и описывающая концепции опасности, рисков, целостности систем и т.п. SWEBOK приводит ряд источников, где подробно обсуждаются эти вопросы.
Уровни целостности программного обеспечения
Уровень целостности программного обеспечения определяется на основании возможных последствий сбоя программного обеспечения и вероятности возникновения такого сбоя. Когда важны различные аспекты безопасности (применения и информационной безопасности), при разработке планов работ в области идентификации возможных очагов аварий могут использоваться техники анализа опасностей (в контексте безопасности использования, safety) и анализа угроз (в информационной безопасности, security). История сбоев аналогичных систем может также помочь в идентификации наиболее полезных техник, направленных на обнаружение сбоев и оценки качества программного обеспечения. Уровни целостности (например, градации целостности) предлагаются, в частности, стандартом IEEE 1012-98 “IEEE Standard for Software Reviews”.
При более детальном рассмотрении целостности программного обеспечения в контексте конкретных проектов, необходимо уделять специальное внимание (выделяя соответствующие ресурсы и проводя необходимые работы) не только SQM-процессам (особенно, формальным, включая аудит и аттестацию), но и аспектам управления требованиями (в части критериев целостности), управления рисками (включая планирование рисков как на этапе разработки, так и на этапе эксплуатации и сопровождения системы), проектирования (которое, для повышения гарантоспособности, в обязательном порядке предполагает глубокий анализ и проверку планируемых к применению архитектурных и технологических решений, часто, посредством создания пилотных проектов, демонстрационных стендов и т.п.) и тестирования (для обеспечения всестороннего исследования поведенческих характеристик системы, в том числе с эмуляцией рабочего окружения/конфигурации, в которых система должна использоваться в процессе эксплуатации).
Характеристика дефектов
SQM-процессы обеспечивают нахождение дефектов. Описание характеристик дефектов играет основную роль в понимании продукта, облегчает корректировку процесса или продукта, а также информирует менеджеров проектов и заказчиков о статусе (состоянии) процесса или продукта. Существуют множество таксономий (классификации и методов структурирования) дефектов (сбоев). На сегодняшний день нет четкого консенсуса по этому вопросу и SWEBOK приводит некоторые источники, освещающие его более подробно, упоминая, в частности, стандарт IEEE 1044-93 “IEEE Standard for the Classification of Software Anomalies”. Характеристика дефектов (аномалий) также используется в аудите и оценках, когда лидер оценки часто представляет для обсуждения на соответствующих встречах список аномалий, сформированный членами оценочной команды.
На фоне эволюции (и появления новых) методов проектирования и языков, наравне с новыми программными технологиями, появляются и новые классы дефектов. Это требует огромных усилий по интерпретации (и корректировке) ранее определенных классов дефектов (сбоев). При отслеживании дефектов инженер интересуется не только их количеством, но и типом. Данный аспект (а именно, распределение дефектов по типам) особенно важен для определения наиболее слабых элементов системы, с точки зрения используемых технологий и архитектурных решений, что приводит к необходимости их углубленного изучения, создания специализированных пилотных проектов, дополнительной проверки концепции (proof of concept, POC - часто применяемый подход при использовании новых технологий), привлечения сторонних экспертов и т.п. SWEBOK отмечает, что сама по себе информация, без классификации, часто бывает просто бесполезна для обнаружения причин сбоев, так как для определения путей решения проблем необходима их группировка по соответствующим типам. Вопрос состоит в определении такой таксономии дефектов, которая будет значима для инженеров и организации, в целом.
SQM обеспечивает сбор информации на всех стадиях разработки и сопровождения программного обеспечения. Обычно, когда мы говорим “дефект”, мы подразумеваем “сбой”, в соответствии с определением, представленным ниже. Однако, различные культуры и стандарты могут предполагать различное смысловое наполнение этих терминов. Частичные определения понятий такого рода (из стандарта IEEE 610.12-90 “ IEEE Standard Glossary of Software Engineering Terminology ”) выглядят следующим образом:
* Ошибка (error): “Отличие … между корректным результатом и вычисленным результатом < полученным с использованием программного обеспечения>”
* Недостаток (fault): “Некорректный шаг, процесс или определение данных в компьютерной программе”
* Сбой (failure): “ результат, полученный в результате недостатка”
* Человеческая/пользовательская ошибка (mistake): “Действие человека, приведшее к некорректному результату”
Данные понятия достаточно детально рассматриваются в области знаний SWEBOK “Тестирование программного обеспечения”.
При обсуждении данной темы, под дефектом (defect) понимается результат сбоя программного обеспечения. Модели надежности строятся на основании данных о сбоях, собранных в процессе тестирования программного обеспечения или его использования. Такие модели могут быть использованы для предсказания будущих сбоев и помогают в принятии решения о прекращении тестирования.
По результатам SQM-работ, направленных на обнаружение дефектов, выполняются действия по удалению дефектов из исследуемого продукта. Однако, этим дело не ограничивается. Есть и другие возможные действия, позволяющие получить полную отдачу от результатов выполнения соответствующих SQM-работ. Среди них - анализ и подведение итогов (резюмирование) , использование техник количественной оценки (получение метрик) для улучшения продукта и процесса, отслеживание дефектов и удаления их из системы (с управленческим и техническим контролем проведения необходимых корректирующих действий, прим. автора). Улучшение процесса рассматривается более детально в области знаний SWEBOK “Процесс программной инженерии”. В свою очередь источником информации для улучшения процесса, в частности, является SQM-процесс.
Данные о несоответствиях и дефектах, найденных в процессе реализации соответствующих техник SQM, должны фиксироваться для предотвращения их потери. Для некоторых техник (например, технической оценки, аудита, инспекций), присутствие регистратора (recorder) - обязательно, именно для фиксирования такой информации, наравне с вопросами (в том числе, требующими дополнительного рассмотрения, прим. автора) и принятыми решениями. В тех случаях, когда используются соответствующие средства автоматизации, они могут обеспечить и получение необходимой выходной информации о дефектах (например, сводную статистику по статусам дефектов, ответственным исполнителям и т.п., прим. автора). Данные о дефектах могут собираться и записываться в форме запросов на изменения (SCR, software change request) и могут, впоследствии, заноситься в определенные типы баз данных (например, в целях отслеживания кросс-проектной/исторической статистики для дальнейшего анализа и совершенствования процессов, прим. автора), как вручную, так и в автоматическом режиме из соответствующих средств анализа (ряд современных средств проектирования и специализированных инструментов позволяют анализировать код и модели с применением соответствующих метрик, значимых для обеспечения качества продуктов и процессов, прим. автора). Отчеты о дефектах направляются управленческому звену организации/организационной единицы или структуры.
2. Объектно-ориентированное проектирование. Проектирование на основе структур данных
Объектно-ориентированное проектирование - это поступательный итеративный процесс. Граница между объектно-ориентированным анализом и проектированием расплывчата и построение проекта программного изделия состоит из ряда циклов, в которых уточняются описания классов и взаимодействия между ними, разрабатываются реализующие их программы, проводится их отладка и тестирование и по результатам каждого этапа уточняются рабочие документы предыдущих этапов, дорабатываются описания классов и программы. Эти циклы повторяются до получения требуемого результата.
С учетом имеющихся инструментальных средств класс TXSet может быть построен на основе класса Array из библиотеки CLASSLIB, т.е. это множество может быть интерпретировано массивом. Массив представляет собой упорядоченную совокупность однотипных элементов, в то же время данные могут принадлежать различным типам и каждому тип соответствует свой набор характеристик. Это противоречие можно преодолеть, если элементами массива TXSet будут указатели на экземпляры данных.
Чтобы использовать указатели на экземпляры данных как элементы массива, все классы, определяющие типы данных, должны быть образованы из общего базового класса.
Пусть требуется обеспечить возможность использования числовых скалярных данных и массивов (векторов и прямоугольных матриц), а также данных типа строк и массива строк. Естественно определить для каждого такого типа свой класс: TDScal, TDArray, TDString, TDStringArray. В каждом из этих классов должно быть поле идентификатора данного ident, поле описания данного head и, возможно, поле flags, представляющее собой набор битов, дополняющих описание данного. Может оказаться удобным иметь и поля, содержащие количество знаков при представлении скаляра или элементов массивов (width) и количество цифр в дробной части для представления чисел (dec). Все эти данные можно объединить в классе TData, базовом для остальных классов данных. Таким образом, вместо одного класса “данное”, выделенного на этапе анализа, появилось пять классов. После этого следует вернуться к этапу анализа и оформить рабочие документы анализа для новых классов.
Аналогичным образом следует уточнить состав и определения остальных классов, выбранных на этапе анализа.
После определение перечня классов следует разработать семантику каждого класса - определить состав и назначение методов класса. При этом также может возникнуть необходимость выделения новых классов и, следовательно, повторение отдельных частей этапа анализа и новое уточнение ранее описанных классов.
Таким образом, процесс объектно-ориентированного проектирования состоит из циклического выполнения четырех основных шагов:
- определение классов и объектов на определенном уровне абстракции.
- определение семантики классов.
- определение (идентификация) связей между классами и объектами.
- реализация классов.
На каждом повторении этого цикла уточняются описания классов и перерабатываются проектные документы.
Одной из наиболее трудоемких и сложных задач при создании информационных систем является проектирование Базы данных, как основы подсистемы представления и обработки данных. Организация данных требует предварительного моделирования предметной области, т. е. построения инфологической модели данных, главным назначением которой является систематизация разнообразной информации и отражение ее свойств по содержанию, структуре, объему, связям, динамике с учетом удовлетворения информационных потребностей всех категорий пользователей.
Информационно-логическая (инфологическая) модель отражает предметную область в виде совокупности информационных объектов и их структурных связей. Основой для построения инфологической модели Базы данных является формализованное описание данных предметной области, которые рассматриваются как совокупность информационных объектов, содержащих наборы реквизитов и структурных связей этих объектов. Предметная область включает объекты (клиенты, счета клиентов, документы, операции и т. д.), их свойства и характеристики, взаимодействия и процессы над ними.
База данных рассматривается как совокупность моделей данных, описывающих логическую структуру и физическую организацию данных на машинных носителях, находящихся под управлением СУБД. Проектирование состоит в построении комплекса взаимосвязанных моделей данных. На рис условно отображены этапы процесса проектирования Базы данных.
Процесс проектирования Базы данных начинается с постановки задачи и выявления объектов, процессов или сущностей предметной области. Например, объектами могут быть предприятия, вкладчики, банки. Для каждого из объектов выбирается набор характеризующих его свойств (полей, реквизитов). Для предприятия - наименование, адрес, расчетный счет, название банка и пр., для вкладчика - фамилия, имя, отчество, адрес, паспортные данные, место работы и пр. Затем в процессе анализа определяется информационная потребность каждой задачи, которую составляют входные и результатные документы, и определяется периодичность решения задач.
Работа проектировщиков Базы данных в значительной степени зависит от качества инфологической модели. Инфологическая модель создается для того, чтобы на ее основе можно было построить модель данных, т. е. она должна учитывать особенности реализации выбранной СУБД. На основе инфологической модели строятся концептуальная, логическая и физическая модели. Отсюда вытекают основные этапы, на которые разбивается процесс проектирования базы данных информационной системы.
Концептуальное проектирование - сбор, анализ и редактирование требований к данным. Для этого осуществляются следующие мероприятия:
· обследование предметной области, изучение ее информационной структуры;
· выявление всех фрагментов, каждый из которых характеризуется пользовательским представлением, информационными объектами, связями между ними и процессами;
· моделирование и интеграция всех представлений.
Результат данного этапа - концептуальная модель, инвариантная к структуре Базы данных, часто представляется в виде модели «сущность-связь».
Логическое проектирование - преобразование требований к данным в структуры данных. Результат - СУБД-ориентированная структура Базы данных и спецификации прикладных программ. На этом этапе часто моделируют Базы данных применительно к различным СУБД и проводят сравнительный анализ моделей.
Физическое проектирование - определение особенностей хранения данных, методов доступа и т. д.
Физическая база данных нужна разработчикам информационной системы для разработки кода, а проектировщикам - для проверки их идей. Проектировщики и разработчики могут работать как с одной и той же схемой, так и с разными схемами. В процессе разработки проекта, как правило, создается несколько версий схемы Базы данных, поэтому обязательно ведется журнал изменений. Построение логической и физической моделей данных является основной частью проектирования Базы данных.
Проектирование Базы данных имеет свои особенности на всех стадиях и этапах проектирования.
I этап. Подготовка Технического задания (постановка задачи). Включает сбор материалов в процессе обследования и оформление Технического задания. Выполняется следующий комплекс работ:
* определение экономической целесообразности и технической возможности создания Базы данных;
* выявление состава, содержания и характеристик хранимой информации на основе результатов обследования предметной области;
* определение оценок, количественных характеристик информационных объектов и структурных связей между ними на основе результатов анализа информационных потребностей приложений;
* построение инфологической (информационно-логической) модели предметной области, определяющей совокупность информационных объектов, их атрибутов и структурных связей, динамику их изменения и характеристику информационных потребностей пользователя;
* предварительная оценка вариантов разработки Базы данных;
* оценка возможности использования СУБД и выбор СУБД.
По результатам выполнения этапа создаются Технико-экономическое обоснование проектирования Базы данных (ТЭО) и Техническое задание (ТЗ).
II этап. Технический проект. Результаты разработок и проектных решений оформляются в виде технического проекта. На данном этапе выполняются следующие работы:
* составление и уточнение инфологической модели;
* логическое проектирование (составление концептуальной схемы);
* физическое проектирование (распределение по уровням памяти, выбор методов доступа, определение размеров файлов и т. д.);
* проектирование и представление данных для приложений;
* проектирование программного обеспечения, включая СУБД.
III этап. Рабочий проект. Детализуются решения технического проекта. Выполняется следующий комплекс работ:
* разработка программных средств и сервисных программ;
* настройка СУБД и приложений в соответствии с выбранными параметрами;
* разработка контрольного примера;
* разработка должностных технологических инструкций для пользователей.
IV этап. Внедрение проекта (эксплуатация и отладка). Выполнятся проверка проектных решений и их доводка, при необходимости дорабатывается технология работы с Базой данных, пользователями, выполняется перераспределение обязанностей, устанавливаются категории и иерархия доступа пользователя к данным.
3. Процесс тестирования. Практические соображения. Тестовые работы
Концепции, стратегии, техники и измерения тестирования должны быть объединены в единый процесс тестирования как деятельности по обеспечению качества.
Процесс тестирования поддерживает работы по тестированию и определяет “правила игры” для членов команды тестирования - от планирования тестов до оценки их результатов. Хотя, в большинстве современных методов разработки, в частности, гибких (agile) подходов, тестирование выходит на передний план и является одной из базовых практик, многостороннее тестирование и, тем более, прогнозирование на основе полученных результатов, часто подменяется отдельными работами в этой области, не позволяющими добиться необходимых параметров качества (что, кстати, ясно показывают уже упоминавшиеся результаты исследований Standish Group [Chaos, 2004]). Только в том случае, если тестирование рассматривать как один из важных процессов всей деятельности по созданию и поддержке программного обеспечения, можно добиться оценки стоимости соответствующих работ и, в конце концов, соблюсти те ограничения, которые определены для проекта.
Практические соображения
Программирование без персоналий. Очень важным компонентом успешного тестирования является совместное стремление участников проекта обеспечить необходимое качество продукта. Менеджеры играют ключевую роль в организации этой деятельности и на стадии разработки и в процессе сопровождения программных систем.
Руководства по тестированию. Работы по тестированию могут руководствоваться различными соображениями и критериями - от управления рисками до специфицированных сценариев работы программных систем. В любом случае, желательно, исходя из ресурсов, количественных оценок и других характеристик, обеспечить использование различных техник тестирования для многосторонней оценки и улучшения качества получаемого продукта.
Управление процессом тестирования. Работы по тестированию, ведущиеся на разных уровнях, должны быть организованы в единый (однозначно интерпретируемый) процесс, на основе учета 4 элементов и связанных с ними факторов: людей (в том числе, в контексте организационной структуры и культуры), инструментов, регламентов и количественных оценок (измерений). Стандарт жизненного цикла IEEE, ISO/IEC, ГОСТ Р 12207 не выделяет деятельность по тестированию в качестве самостоятельного процесса, однако, рассматривает соответствующие принципы работ по тестированию как неотъемлемую часть процессов жизненного цикла и сопровождения программных систем. В другом распространенном стандарте IEEE 1074 деятельность по тестированию также объединена с другими оценочными работами как интегральная часть полного жизненного цикла.
Документирование тестов и рабочего продукта Документация - составная часть формализации процесса тестирования. Существует стандарт IEEE 829-98 “Standard for Software Test Documentation”, предоставляющий прекрасное описание тестовых документов, их связей между собой и с процессом тестирования. Среди таких документов могут быть:
· План тестирования
· Спецификация процедуры тестирования
· Спецификация тестов
· Лог тестов
Документирование тестов, в случае его формального ведения, должно быть актуальным. В противном случае, как и любые другие документы, документация по тестированию ляжет “мертвым грузом”. В то же время, деятельность по тестированию, в случае отсутствия соответствующих регламентов и результатов (в том числе, исторических, для разных проектов), сложно поддается оценке для прогнозирования и, тем более, улучшению - в общем контексте улучшения процессов. Если компания-разработчик не ведет соответствующей документации по тестированию, говорить о сертификации или оценке по тем или иным моделям или стандартам (CMMI, ISO, SixSigma и т.п.) - просто не представляется возможным. А это уже вопрос доверия заказчиков, не имевших опыта работы с конкретной компанией-разработчиком.
Внутренние и независимые команды тестирования Формализация процесса тестирования может включать и организационную формализацию команд(ы) тестирования. В нее могу входить как члены проектной команды, в частности, разрабатывающие код, так и внешние лица и группы. В идеале - желательно иметь как внутреннюю команду тестирования, так и внешнюю группу тестирования (обеспечения качества). Соответствующие организационные решения принимаются на основе стоимостных характеристик проекта, доступных ресурсов, анализа стоимости тестирования, как такового, организационной культуры и т.п.
Оценка стоимости и усилий, а также другие измерения процесса Ряд метрик, связанных с оценкой ресурсов, необходимых для тестирования, как и оценка эффективности тестирования на разных этапах и уровнях, основывается на точке зрения и практиках менеджмента проекта (подразделения, компании…) и используется для оценки и улучшения (оптимизации) процесса тестирования. Разные техники, концепции и модели тестирования требуют разных затрат - по времени и необходимым ресурсам. Результат - стоимость тестирования, как затратная составляющая проекта. Понимание соответствия между стоимостью/усилиями, необходимыми для той или иной формы тестирования является обязательной частью современного управления проектами разработки программного обеспечения.
Окончание тестирования Очень важным аспектом тестирования является решение о том, в каком объеме тестирование достаточно и когда необходимо завершить процесс тестирования. Тщательные измерения, такие как достигнутое покрытие кода тестами или охват функциональности, безусловно, очень полезны. Однако, сами по себе они не могут определить критериев достаточности тестирования. Принятие решения об окончании тестирования также включает рассмотрение стоимости и рисков, связанных с потенциальными сбоями и нарушениями надёжности функционирования тестируемой программной системы. В то же время, стоимость самого тестирования также является одним из ограничений, на основе которых принимается решение о продолжении тех или иных связанных с проектом работ (с частности, тестирования) или об их прекращении. Cм. также 1.2.1 “Критерии отбора тестов/критерии адекватности тестов, правила прекращения тестирования”.
Повторное использование и шаблоны тестов Доведение тестов до конца и обеспечение сопровождения программной системы необходимо каждый фрагмент системы тестировать систематическим образом, повторно используя наработанные тесты. Общий репозиторий тестовых активов должен находиться под контролем системы конфигурационного управления, с тем, чтобы любые изменения в требованиях или дизайне могли быть отражены в используемых наборах тестов, в том числе, с точки зрения их расширения новыми тестами, если этого требуют соответствующие изменения.
Шаблоны тестов конструируются на основе тестовых решений, наработанных для проверки определенных ситуаций или типовых фрагментов программных систем. Такие шаблоны должны быть документированы с учетом повторного использования, включая прозрачные возможности их адаптации под специфику программных решений, к которым такие шаблоны применяются.
Планирование Также как и другие аспекты управления проектами, работы по тестированию должно планироваться заранее. Как минимум, на уровне организации соответствующего процесса. Ключевые аспекты планирования тестовой деятельности включают:
· координацию персонала
· управление оборудованием и другими средствами, необходимыми для организации тестирования
· планирование обработки нежелательных результатов (т.е. является управлением определенными видами рисков)
В случае одновременной поддержки и сопровождения нескольких версий программной системы или нескольких систем, необходимо уделять особое внимание планированию времени, усилий и ресурсов, связанных с проведением работ по тестированию. Данная позиция перекликается с вопросами управления портфелями проектов с точки зрения общего управления проектами.
Генерация сценариев тестирования Создание тестовых сценариев основывается на уровне и конкретных техниках тестирования. Тесты должны находиться под управлением системы конфигурационного управления и описывать ожидаемые результаты тестирования.
Разработка тестового окружения Используемое для тестирования окружение должно быть совместимо с инструментами программной инженерии (будут рассматриваться позднее как тема самостоятельной области знаний). Это окружение должно обеспечивать разработку и контроль тестовых сценариев, ведение журнала тестирования, и возможности восстановления ожидаемых и отслеживаемых результатов тестирования, самих сценариев, а также других активов тестирования.
Выполнение тестов Выполнение тестов должно содержать основные принципы ведения научного эксперимента:
· должны фиксироваться все работы и результаты процесса тестирования
· форма журналирования таких работ и их результатов должна быть такой, чтобы соответствующее содержание было понятно, однозначно интрепретируемой и повторяемо другими лицами (не теми, кто первоначально проводил тестирование)
· тестирование должно проводиться в соответствии с заданными и документированными процедурами
· тестирование должно производиться над однозначно идентифицируемой версией и конфигурацией программной системы
Ряд вопросов выполнения тестов и других работ по тестированию освещен в стандарте IEEE 1008-87.
Анализ результатов тестирования
Для определения успешности тестов их результаты должны оцениваться, анализироваться. В большинстве случаев, “успешность” тестирования подразумевает, что тестируемое программное обеспечение функционирует так, как ожидалось и в процессе работы не приводит к непредусмотренным последствиям. Не все такие последствия обязательно являются сбоями, они могут восприниматься как “помехи”. Однако, любое непредусмотренное поведение может стать источником сбоев при изменении конфигурации или условий функционирования системы, поэтому требуют внимания, как минимум, с точки зрения идентификации причин таких помех. Перед устранением обнаруженного сбоя, необходимо определить и зафиксировать те усилия, которые необходимы для анализа проблемы, отладки и устранения. Это позволит в дельнейшем обеспечить большую глубину измерений, а, соответственно, в перспективе, иметь возможность улучшения самого процесса тестирования. В тех случаях, когда результаты тестирования особенно важны, например, в силу критичности обнаруженного сбоя, может быть сформирована специальная группа анализа (review board).
Отчёты о проблемах/журнал тестирования
Во многих случаях, в процессе тестовой деятельности ведётся журнал тестирования, фиксирующий информацию о соответствующих работах: когда проводится тест, какой тест, кем проводится, для какой конфигурации программной системы (в терминах параметров и в терминах идентифицируемой версии контекста конфигурационного управления) и т.п. Неожиданные или некорректные результаты тестов могут записываться в специальной подсистеме ведения отчетности по сбоям (problem¬reporting system, обеспечивая формирование базы данных, используемой для отладки, устранения проблем и дальнейшего тестирования. Кроме того, аномалии (помехи), которые нельзя идентифицировать как сбои, также могут фиксироваться в журнале и/или системе ведения отчетности по сбоям. В любом случае, документирование таких аномалий снижает риски процесса тестирования и помогает решать вопросы повышения надежности самой тестируемой системы. Отчёты по тестам могут являться входом для процесса управления изменениями и генерации запросов на изменения (change request) в рамках процессов конфигурационного управления (см. далее соответствующую область знаний “Software Configuration Management”).
Отслеживание дефектов
Сбои, обнаруженные в процессе тестирования, чаще всего порождаются дефектами и ошибками, присутствующими в тестируемой программной системе (также они могут быть следствием поведения операционного и/или тестового окружения). Такие дефекты могут (и, чаще всего, должны) анализироваться для определения момента и места первого появления данного дефекта в системе, какие типы ошибок стали причиной этих дефектов (например, плохо сформулированные требования, некорректный дизайн, утечки памяти и т.д.) и когда они могли бы быть обнаружены впервые. Вся эта информация используется для определения того, как может быть улучшен сам процесс тестирования и насколько критична необходимость таких улучшений.
Список литературы
1. Программная инженерия. «Качество программного обеспечения». Сергей Орлик
2. Норенков. «Основы автоматизированного проектирования»
3. Липаев В.В. «Программная инженерия». 2008 г.
Размещено на Allbest.ru
Подобные документы
Изучение различных видов тестирования программного обеспечения. Выявление в программной системе скрытых дефектов до того, как она будет сдана заказчику. Тестирование методом черного ящика. Требования, предъявляемые к процессу тестирования больших систем.
курсовая работа [3,0 M], добавлен 19.11.2009Реализация программного средства "Действия над матрицами". Разработка кода программного продукта на основе готовой спецификации на уровне модуля. Использование инструментальных средств на этапе отладки программного модуля. Выбор стратегии тестирования.
отчет по практике [296,1 K], добавлен 19.04.2015История развития и виды тестирования программного обеспечения. Инсталляционное, регрессионное, конфигурационное, интеграционное, локализационное, модульное тестирование. Методы сокращения трудоемкости модульного тестирования разрабатываемого приложения.
курсовая работа [309,5 K], добавлен 16.12.2015Оснащенность предприятия системным программным обеспечением, используемым для организации производственного процесса. Проектирование, внедрение и эксплуатация системного и прикладного программного обеспечения. Тестирование и отладка программного продукта.
отчет по практике [272,2 K], добавлен 29.12.2014Проектирование базы данных, информационной подсистемы PLC-Tester, модуля тестирования и web-приложения. Разработка логической структуры программного продукта и общие требования к техническому обеспечению. Запуск программы и описание тестовых прогонов.
дипломная работа [3,2 M], добавлен 30.06.2011Анализ существующего программного обеспечения. Этапы создания проекта. Концептуальное, логическое и физическое проектирование базы данных. Структура программного продукта. Руководство программиста и оператора. Тестирование программного продукта.
курсовая работа [586,4 K], добавлен 26.06.2015Основные области проектирования информационных систем: базы данных, программы (выполнение к запросам данных), топология сети, конфигурации аппаратных средств. Модели жизненного цикла программного обеспечения. Этапы проектирования информационной системы.
реферат [36,1 K], добавлен 29.04.2010Общее описание разрабатываемого программного обеспечения, требования к его функциональности и сферы практического применения. Выбор инструментальных средств разработки. Проектирование структур баз данных и алгоритмов, пользовательского интерфейса.
дипломная работа [3,1 M], добавлен 19.01.2017Разработка алгоритма поставленной задачи и реализация средствами автоматизированного проектирования. Составление программного продукта на основе готовой спецификации на уровне модуля, проведение его тестирования, использование инструментальных средств.
контрольная работа [257,5 K], добавлен 01.05.2015Программная и техническая характеристика информационных систем предприятия. Требования к информационной и программной совместимости. Проектирование программного обеспечения с использованием специализированных программных пакетов. Разработка базы данных.
отчет по практике [1,3 M], добавлен 11.04.2019
