Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Tehnprogr_lec1,2.docx
Скачиваний:
0
Добавлен:
01.04.2025
Размер:
175 Кб
Скачать
☆

Тестирование проектной информации и его состаных частей

Практика разработки програмнного изделия выделяет 2 стратегии тестирования программ

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

  • стратегия белого ящика

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

Для получения эффективного набора тестов при стратегии черного ящика обычно используются следующие методы:

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

  • метод граничных значения (дополненный анализом граничных значений входных условий и анализов выходных условий методом эквивалентного разбиения, т.е. если для конкретного класса эквивалентности при использовании метода эквивалетного разбиения требовался один тест, то в нашем случае необходимо построить тест для границы области и чуть-чуть выходя за границу области. Аналогично строятся тесты, покрывающие cграницы и классы эквивалентности выходных условий).

Главным недостатком этих 2 методов является то, что они не рассматривают комбинации входных условий.

  • функциональные диаграммы (был разработан IBM (реализация причинно-следственных связей, дающая побочных эффект, проверка полноты и однозначности спецификаций, реализованных на втором этапе программного обеспечения)и предсталяет собой формальный язык, на котором транслируются спецификации, написанные на ествественном языке осуществляется в несколько этапов. Для уменьшения грамосткости и трудоемкости спецификаций разбивается все рабочее поле на участки)

  • гипотеза ошибок

Лекция №2 26.01.12

Покрытие – когда в программе должен работать хотя бы один раз каждый оператор.

Анализ ошибок показывает, что подавляющее число ошибок обусловлено плохой организацией разработки ПО на всех этапах разработки ПО и на всех стадиях.

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

Основные подходы к контролю за возникновением ошибки

  • выбор инструментальных средств

  • проведение методов контроля на каждом этапе разработки

  • программно-целевой метод (тесты ориентированы на конкретные целевые направления)

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

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

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

В этом отношении известно 2 подхода:

  • монолитное тестирование (предусматривает проверку всей программы или комплекса программ целиков)

  • пошаговое тестирование (каждый модуль последовательно подключается к уже оттестированному модулю)

  1. Монолитное тестирование более трудоемкое

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

  3. При пошаговом тестировании менее трудоемка и отладка программы

  4. Качество тестирования при пошаговом подходе выше, чем при монолитном, это связано с тем, что оттестированные модули в ряде случаев могут выступать как заглушки

  5. Затраты машинного времени при монолитном тестировании в большинстве случаев меньше, чем при пошаговом.

  6. Монолитное тестирование создает хорошие предпосылки для распараллеливания работ, особенно в начальной фазе тестирования

Тестирование функции (Проверка функций)

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]