- •Анализ правильности проектной информации Основные проблемы и виды анализа проектной информации
- •Тестирование проектной информации и его состаных частей
- •Основные подходы к контролю за возникновением ошибки
- •Основные 15 категорий тестов для тестирования системы по
- •Методы отладки
- •Классификация ошибок
Тестирование проектной информации и его состаных частей
Практика разработки програмнного изделия выделяет 2 стратегии тестирования программ
стратегия черного ящика (тестирование с управлением по данным по входу/выходу игнорируют внутреннюю структуру программ, а целью тестирования является выявление обстоятельств, при котором поведение программы не соответствует её спецификациям. При таком подходе обнаружение всех ошибок в программе может быть достигнуто только путем исчерпывающего тестирования, т.е. только тогда, когда в качестве тестовых наборов используются все возможные наборы исходных данных)
стратегия белого ящика
Появились понятия результативного (оценивается числом ошибок за один прогон) и эффективного (подмножество всех возможных тестов, которые имеют наивысшую вероятность обнаружения большинства ошибок программы) тестов.
Для получения эффективного набора тестов при стратегии черного ящика обычно используются следующие методы:
метод эквививалентного разбиения (состоит в разбиении входной области программы на конечное число классов эквивалентности, при котором каждый тест некоторого класса эквивалентности в смысле обнаружения ошибок эквивалентен любому другому классу ). Классы эквивалентности стоятся на основе анализа входных данных или входных условий спецификаций, в которых и опредлена вся входная инфорация.
метод граничных значения (дополненный анализом граничных значений входных условий и анализов выходных условий методом эквивалентного разбиения, т.е. если для конкретного класса эквивалентности при использовании метода эквивалетного разбиения требовался один тест, то в нашем случае необходимо построить тест для границы области и чуть-чуть выходя за границу области. Аналогично строятся тесты, покрывающие cграницы и классы эквивалентности выходных условий).
Главным недостатком этих 2 методов является то, что они не рассматривают комбинации входных условий.
функциональные диаграммы (был разработан IBM (реализация причинно-следственных связей, дающая побочных эффект, проверка полноты и однозначности спецификаций, реализованных на втором этапе программного обеспечения)и предсталяет собой формальный язык, на котором транслируются спецификации, написанные на ествественном языке осуществляется в несколько этапов. Для уменьшения грамосткости и трудоемкости спецификаций разбивается все рабочее поле на участки)
гипотеза ошибок
Лекция №2 26.01.12
Покрытие – когда в программе должен работать хотя бы один раз каждый оператор.
Анализ ошибок показывает, что подавляющее число ошибок обусловлено плохой организацией разработки ПО на всех этапах разработки ПО и на всех стадиях.
выбор оптимальной технологии и использование мощных инструментальных средств, позволяющих контролировать сам процесс разработки, где процесс разработки регламентирует некоторые действия, позволяющие избежать ошибки
Основные подходы к контролю за возникновением ошибки
выбор инструментальных средств
проведение методов контроля на каждом этапе разработки
программно-целевой метод (тесты ориентированы на конкретные целевые направления)
Тестирование связано с тотальным контролем, начиная от тестирования отношений пользователя и заказчика тестирование целей внешних спецификаций, проекта системы, проектируемых программ и спецификаций интерфейса модулей, в т.ч. и исходный код носит название комплексного тестирования.
Основная задача комплексного тестирования – установить взаимнооднозначное соответствие между процессами разработки ПИ и его тестирование. При проверке модулей ставится задача найти противоречия между модулями программы и спецификациями их интерфейсов. При тестирование функций противоречие ищется в виде несоответствия программ своим внешним спефикациям. При тестировании системы проверяется в целом несоответствие заданной техническим заданием требование к программе и т.д.
Наиболее важный этап тестирования – выбор способа сборки из отдельных модулей программы, поскольку именно здесь возникают наиболее сложные и уловимые ошибки на стыке сборки. Именно в этой части тестирования определяется форма написания теста модуля, типы средств, используемые при тестировании, порядок тестирования модулей и методы локализации ошибок и их исправление.
В этом отношении известно 2 подхода:
монолитное тестирование (предусматривает проверку всей программы или комплекса программ целиков)
пошаговое тестирование (каждый модуль последовательно подключается к уже оттестированному модулю)
Монолитное тестирование более трудоемкое
При пошаговое тестировании ошибки в межмодульных интерфейсах обнаруживаются раньше, чем при монолитном тестировании (т.е. тестирование проводится сразу с первого шага , тогда как при монолитном тестировании тестирование начинается на последнем шаге)
При пошаговом тестировании менее трудоемка и отладка программы
Качество тестирования при пошаговом подходе выше, чем при монолитном, это связано с тем, что оттестированные модули в ряде случаев могут выступать как заглушки
Затраты машинного времени при монолитном тестировании в большинстве случаев меньше, чем при пошаговом.
Монолитное тестирование создает хорошие предпосылки для распараллеливания работ, особенно в начальной фазе тестирования
Тестирование функции (Проверка функций)
Тестирование системы - является наиболее сложным и трудоемким и наиболее важным среди всех этапов комплексного тестирования, т.к. именно на этом этапе проверяется полнота и идентичность проектируемой системы. Основное назначение этого этапа - сопоставить результаты тестирования с заданными целями. Тестирование не ограничивается только проверкой взаимосвязанных программных модулей, а тестируются в основном те целевые функции или те целевые установки, которые характеризуют программное изделие как изделие производственно-технического назначения, а объектом системы являются требования к ПИ, тест программы на язык программирования и комплект пользовательской документации.
