Меню
Главная
Авторизация/Регистрация
 
Главная arrow Информатика arrow Информационные системы и технологии на предприятиях

Тестирования программ и систем

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

Основные виды работ по тестированию:

o верификация результатов разработки программного продукта на каждом этапе жизненного цикла;

o составление плана тестирования и подготовки тестов для проверки отдельных элементов разработанной программы и программы в целом;

o управление выполнением тестов и анализ результатов тестирования;

o повторное тестирование.

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

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

Тестирование составляет от ЗО до 50 % трудоемкости работ по созданию кода.

Исторически первым разновидностью тестирования было отладка - проверка программного объекта на наличие в нем ошибок для их устранения. При этом могут вноситься новые ошибки.

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

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

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

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

o идентификация множества функциональных требований;

o идентификация внешних функций в реализации программного обеспечения и построение последовательностей функций соответственно использование их в ПО;

o идентификация множества входных данных каждой функции и определение направлений их изменения;

o построение тестовых наборов и сценариев тестирования функций;

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

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

Методы доказательства правильности программ появились еще в 80-е годы. Техника символьного выполнения включает моделирование выполнения кода, используя символы вместо переменных данных.

Проверка - проверка соответствия реализации системы спецификациям результатов проектирования и описания компоненты,

Проверка - проверка соответствия созданного ПО потребностям и требованиям заказчика. Это дорогостоящий процесс, что обеспечивает высокое качество программного кода. Валидация позволяет подтвердить, что программное обеспечение является корректной реализацией исходных условий в системе и производится после завершения каждого этапа разработки этого обеспечения.

Ошибки и причины их появления на этапах жизненного цикла

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

o ошибочной спецификации или пропущенной требования (спецификация точно не отражает предположение пользователя);

o наличие требования, которую невозможно выполнить на этой аппаратуре и ПО;

o ошибки в проекте программы (к примеру, базу данных спроектировано без защиты от несанкционированного доступа пользователя, а защита нужна);

o ошибки в алгоритме.

Ошибки в ПО можно классифицировать в соответствии с их распределением по этапам жизненного цикла и источников их возникновения:

1) непреднамеренное отклонение от разработчиков рабочих стандартов или планов реализации;

2) спецификации функциональных и интерфейсных требований без соблюдения стандартов разработки;

3) несовершенная организация процесса разработки.

Ошибки могут возникать во время разработки программного обеспечения на различных этапах жизненного цикла. Рассмотрим подробнее эти этапы.

1. Этап анализа требований. В определении входного концепции системы и описания входных требований заказчика возникают ошибки аналитиков, когда они формулируют спецификации верхнего уровня и строят концептуальную модель ПрО.

Характерные ошибки:

o неадекватность описания спецификациям требований конечных пользователей;

o некорректность спецификации взаимодействия программного обеспечения со средой функционирования или с пользователями;

o несоответствие требований заказчика отдельным и общим свойствам программного обеспечения;

o некорректность описания функциональных характеристик;

o необеспеченность инструментальными средствами поддержки всех аспектов реализации требований заказчика и т.д.

2. Этап проектирования компонент. Ошибки во время проектирования компонент могут возникать при описании алгоритмов, логики управления, структур данных, интерфейсов, логики моделирование потоков данных, форматов ввода-вывода и т.д. В основе этих ошибок лежат дефекты спецификаций аналитиков и ошибок проектировщиков.

Ошибки могут возникать при:

o определение интерфейса пользователя со средой;

o описания функций (неадекватности формулировок в проекте цели и задач отдельных компонентов, выявляемых при проверке проекта);

o определение процесса обработки информации или связей между процессами (следствие некорректного определения взаимосвязей компонентов и процессов);

o определение данных и их структур для отдельных компонент и программного обеспечения, что в целом некорректно заданы;

o описания алгоритмов модулей и их логики, что некорректно определены в представленном проекте модуля;

o определение условий возникновения возможных ошибок в программе;

o нарушение принятых для проекта стандартов и технологий.

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

Характерные ошибки:

o бесконтрольность допустимости значений входных и выходных параметров, деление на 0 и т.п.;

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

o нарушение стандартов кодирования (неадекватные комментарии, нерациональное выделение модулей и компонентов и т.п.);

o использование одного имени для обозначения нескольких объектов или нескольких имен для обозначения одного объекта;

o несогласованное внесение изменений в программу несколькими разработчиками.

4. Этап тестирования. На этом этапе ошибки допускают тестировщики, а также программисты, осуществляя сбор, тестирование и выбор некорректных тестовых наборов и сценариев тестирования и т.п.

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

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

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

Тестовую проверку можно провести также путем добавления к программе, проверяется, дополнительных операторов, которые будут сигнализировать о ходе ее выполнения и получения результатов.

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

Виды тестирования программ с целью проверки:

o полноты функций;

o согласованности интерфейсов;

o структуры программы;

o исчисления и корректности выполнения функций;

o правильности функционирования в заданных условиях;

o надежности выполнения программ;

o эффективности защиты от сбоев аппаратуры и необнаруженных ошибок;

o удобства применения и сопровождения.

Много типов тестов готовит сам заказчик для проверки работы ИС. Структура и содержание тестов зависят от вида элемента - модуль, компонент, группа компонент, подсистема или система. Некоторые тесты связанные с необходимостью проверить, работает ИС согласно проекту, удовлетворены требования заказчика.

Команда тестировщиков

Для проведения тестирования создается специальная команда тестировщиков. За функциональные тесты отвечает разработчик, а заказчик больше влияет на составление испытательных и установочных тестов.

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

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

В состав команды тестировщиков входят также пользователи. Они оценивают полученные результаты и удобство использования, а также высказывают свое мнение относительно принципа работы системы на начальных этапах проекта.

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

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

Типичные причины, которые могут обусловить необходимость изменений:

o выявление дефектов функционирования ИС при эксплуатации, не найденных на этапе тестирования (изменения, за которые несет ответственность разработчик);

o выяснения заказчиком во время эксплуатации ИС, требования к системе были выражены недостаточно или неполно, и поэтому она не соответствует отдельным требованиям заказчика (изменения, за которые несет ответственность постановщик задачи);

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

Как свидетельствуют эксперты, процесс внесения изменений достаточно дорогой - оценки его стоимости достигают 60-80 % от общей стоимости разработки.

Виды сопровождения:

o корректирующую - внесение корректив для устранения ошибок, которые были найдены после передачи системы в эксплуатацию;

o адаптивное - адаптация продукта к изменившимся обстоятельствам использования после передачи системы в эксплуатацию;

o предупредительное - деятельность по обеспечению адаптивного сопровождения на старте разработок.

 
< Предыдущая   СОДЕРЖАНИЕ   Следующая >
 
Предметы
Агропромышленность
Банковское дело
БЖД
Бухучет и аудит
География
Документоведение
Естествознание
Журналистика
Инвестирование
Информатика
История
Культурология
Литература
Логика
Логистика
Маркетинг
Математика, химия, физика
Медицина
Менеджмент
Недвижимость
Педагогика
Политология
Политэкономия
Право
Психология
Региональная экономика
Религиоведение
Риторика
Социология
Статистика
Страховое дело
Техника
Товароведение
Туризм
Философия
Финансы
Экология
Экономика
Этика и эстетика
Прочее