Вход

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

Рекомендуемая категория для самостоятельной подготовки:
Реферат*
Код 77766
Дата создания 2013
Страниц 25
Мы сможем обработать ваш заказ 25 января в 12:00 [мск]
Файлы будут доступны для скачивания только после обработки заказа.
1 440руб.
КУПИТЬ

Содержание

Оглавление
Введение 2
1. Тестирование в процессе разработки ПО 3
2. Организация управления тестированием и выявление основных проблем 16
Заключение 22
Список используемой литературы: 23

Фрагмент работы для ознакомления

Таким образом, заострим свое внимание на верификации.ВерификацияПостроение математической модели анализируемой системыПредставление проверяемых свойств в виде формального текста (называемого спецификация)Построение формального доказательства наличия или отсутствия у данной программы проверяемых свойств. Математическое моделирование представляет собой граф, где вершинами являются состояния, и изображают ситуации, в которых может находиться программа в разные моменты времени, и рѐбра которого могут иметь метки, изображающие действия.Рисунок 7 – Структура верификацииСпецификация – это описание свойств системы в виде формального текста, которая может выражать связь между вводными значениями или зависимость между свойствами системы. Построение доказательств, где существует два основных метода построения доказательств того, что модель соответствует спецификации [4]: -Modelchecking;-Логический вывод.Краш – тесты, основная задача которых выявить явное нарушение работы программы в некоторых сценариях действий пользователя и их предотвращение.Наращиваемый подход в тестированииДля эффективной работы тестер программного обеспечения должен:1. знать метод тестирования программного обеспечения;2. знать тестируемое приложение.В каждом новом тестировании тестер должен посвятить какое-то время изучениюприложения. Неопытный тестер должен также изучить методы тестирования, включая общие концепции тестирования и способ определения тестовых примеров. Основная задача заключается в составленииподходящего набора тестов, которые можно провести в сжатые сроки. Чтобы уложиться в эти сроки, тестирование приложения можно разделить на восемь последовательных стадий. На первых стадиях путемоценки точности результатов определяется, работает ли приложение в нормальныхусловиях. На последних стадиях предпринята попытка вывести систему из строя.Таблица 1 – Организация стадий тестирования ПОСтадииЦелиСтадия 1: ИзучениеОзнакомиться с приложениемСтадия 2: Базовый тестРазработать и реализовать простой тестовый примерСтадия 3: Анализ тенденцийОпределить, работает ли приложение так, как было задумано, когда еще нельзя предварительно оценить реальные результатыСтадия 4: ИнвентаризацияОпределить различные категории данных и создать тесты для каждого элемента категорииСтадия 5: Комбинирование элементов инвентарных списковСкомбинировать различные входные данныеСтадия 6: Граничные оценкиОценить поведение приложения при граничных значениях данныхСтадия 7: Ошибочные данныеОценить отклик системы на ввод неправильных данныхСтадия 8: Создание напряженийПопытаться вывести систему из строяСроки тестирования бывают очень короткие, так что возможности пройти через все стадии часто не бывает.Количество стадий тестирования, которое может провести один специалист, определяется затраченным на тестирование временем исходя из запланированной даты выпуска. После выполнения базового теста, если есть свободные тестеры, стадии можнопроходить одновременно.Разбиение на такие стадии, какинвентаризация, граничные оценки, ошибочные данные, создание напряжений всреде без труда можно применять к любым проектам тестирования.При тестировании реальных приложений, для определения и реализации полного набора тестовых примеров может оказаться недостаточно времени или других ресурсов. В такойситуации нужно определить, какие тесты наиболее важны и какие функции не будуттестироваться. Анализ степени риска поможет сконцентрировать усилия при тестировании на наиболее важных функциях приложения и выполнить наиболее уместныетесты. Тестеры, которым настолько «повезло», что их пригласили в проект, в которомпредоставляется достаточно времени для надлежащего тестирования, могут сделатьследующее.• Распланировать задачи тестирования.• Спроектировать тесты, используя методы, описанные в последующих главах.• Создать подходящую для проведения теста среду тестирования.• Оценить, приобрести и установить инструменты автоматического тестирования.• Написать соответствующую документацию, связанную с тестированием.Подключение тестера к проекту на очень поздней стадии, в особенности, когда сроки завершения проекта уже близки, не позволяет спланировать тестирование надлежащим образом, и ограничивает возможности приобретения полезных инструментов.В таких условиях нужно сконцентрироваться на разработке серии тестов, чтобы определить, правильно ли функционирует приложение.Стадия 1: Изучить приложение.Установить авторитетное лицо проектаСтадия 2: Определить базовый тестовый пример, для выполнения которого необходимо создать среду тестированияСтадия 3: Проанализировать тенденции, если сложно спрогнозировать результатыСтадия 4: Определить инвентарные списки. Исходя из списков, сгенерировать тестовые примерыСтадия 5: Скомбинировать данные из различных инвентарных списковСтадия 6: Сделать граничные оценкиСтадия 7: Создать тесты с ошибочными данными, чтобы попытаться вывести систему из строяСтадия 8: Создать напряжение в системных ресурсах. Определить, как система справляется с аварийными ситуациямиРисунок 8 – Стадии тестирования при сжатых срокахДаже когда близится выпуск продукта, тестеры могут оценить критичные компоненты приложения и подтвердить, что ключевые функции работают корректно. Естественно, тестеры могут обеспечить лучшую обратную связь, если в их распоряжении достаточно времени. При тестировании приложения в сжатые сроки можно выделить следующие основные этапы.Каждая стадия базируется на предыдущих. Основная тактика — определить наиболее типичный пользовательский сценарий и использовать эти данные в качестве базовых для создания дополнительных тестов. Изменяя за раз один параметр, тестер может убедиться, что каждое изменение влияет на приложение так, как было задумано.Иногда тестерам приходится выбирать, какие тесты будут заданы и выполнены,поскольку для тестирования всех функций не хватает времени. Анализ степени рискапомогает определить наиболее важные для тестирования области дажеперед созданием какого-либо тестового примера.ЗаключениеХорошая среда разработки программногообеспечения предполагает адекватное кадровое обеспечение и соответствующее время на такую деятельность, как тестирование программного обеспечения, а также руководство персоналом, который им занимается. Однако условия работы некоторыхтестеров никак нельзя назвать идеальными — зачастую необходимо изучить и протестировать новое приложение в нереальные сроки. Некоторые организации решаютвыпустить продукт к определенной дате и хотят, чтобы тестеры подтвердили пригодность продукта к использованию.Успешное тестирование, — как и качество программного обеспечения, — зависит от многих других дисциплин разработки ПО, включая:• конфигурационный менеджмент, чтобы иметь возможность следить, какая версия приложения в данный момент тестируется;• составление отчетов о неполадках, чтобы работать со списком спорных вопросов и проблем, найденных тестером;• управление внесением изменений, чтобы иметь возможность отслеживать, какие неполадки исправляются в текущем выпуске и чтобы сохранять список тех неполадок, которые не будут устранены в ближайшем будущем.Список используемой литературы:Барский, А.Б. Параллельные процессы в вычислительных системах. Планирование и организация [Текст]/ А.Б. Барский. – М.: Радио и связь,2006. – 256 с.Дастин Э., Рэшка Д., Пол Д. Автоматизированное тестирование программного обеспечения. Внедрение, управление и эксплуатация. М.: Лори, 2008.Калашников, В.И. Параллельное программирование [Текст]: учебн. пособие / В.И. Калашников.– Харьков: НТУ “ХПИ”, 2004. – 320 с.Качко, Е.Г. Параллельное программирование [Текст]: учебн. пособие / Е.Г. Качко. – Харьков: Изд-во «Форт», 2011. – 528 с.Кулямин В. В. Критерии тестового покрытия, основанные на структуре контрактных спецификаций // Труды ИСП РАН. Подход UniTESKСпособ отладки программного обеспечения [Текст] / С.Л. Харченко, Ю.Ш. Биглов и др. // ПТО.– 2009. – №11. – C. 12–18.Тестирование программного обеспечения. Блажко, А.Ю. Левченко, А.С. Пригожев//Проблемы программирования, 2010. № 2–3. Тестирование программного обеспечения. Wikipedia//http://ru.wikipedia.org/wiki/Тестирование_программного_обеспечения.Харченко, С.Л. Язык проектирования технического задания систем управления [Текст] / С.Л. Харченко // Восточно-Европейский журнал передовых технологий. – 2011. – № 1/3 (49). –С. 10–16.

Список литературы

Список используемой литературы:
1. Барский, А.Б. Параллельные процессы в вычислительных системах. Планирование и организация [Текст]/ А.Б. Барский. – М.: Радио и связь,2006. – 256 с.
2. Дастин Э., Рэшка Д., Пол Д. Автоматизированное тестирование программного обеспечения. Внедрение, управление и эксплуатация. М.: Лори, 2008.
3. Калашников, В.И. Параллельное программирование [Текст]: учебн. пособие / В.И. Калашников.– Харьков: НТУ “ХПИ”, 2004. – 320 с.
4. Качко, Е.Г. Параллельное программирование [Текст]: учебн. пособие / Е.Г. Качко. – Харьков: Изд-во «Форт», 2011. – 528 с.
5. Кулямин В. В. Критерии тестового покрытия, основанные на структуре контрактных спецификаций // Труды ИСП РАН. Подход UniTESK
6. Способ отладки программного обеспечения [Текст] / С.Л. Харченко, Ю.Ш. Биглов и др. // ПТО.– 2009. – №11. – C. 12–18.
7. Тестирование программного обеспечения. Блажко, А.Ю. Левченко, А.С. Пригожев// Проблемы программирования, 2010. № 2–3.
8. Тестирование программного обеспечения. Wikipedia// http://ru.wikipedia.org/wiki/Тестирование_программного_обеспечения.
9. Харченко, С.Л. Язык проектирования технического задания систем управления [Текст] / С.Л. Харченко // Восточно-Европейский журнал передовых технологий. – 2011. – № 1/3 (49). –С. 10–16.
Пожалуйста, внимательно изучайте содержание и фрагменты работы. Деньги за приобретённые готовые работы по причине несоответствия данной работы вашим требованиям или её уникальности не возвращаются.
* Категория работы носит оценочный характер в соответствии с качественными и количественными параметрами предоставляемого материала. Данный материал ни целиком, ни любая из его частей не является готовым научным трудом, выпускной квалификационной работой, научным докладом или иной работой, предусмотренной государственной системой научной аттестации или необходимой для прохождения промежуточной или итоговой аттестации. Данный материал представляет собой субъективный результат обработки, структурирования и форматирования собранной его автором информации и предназначен, прежде всего, для использования в качестве источника для самостоятельной подготовки работы указанной тематики.
© Рефератбанк, 2002 - 2022