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

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

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

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 предупредительное - деятельность по обеспечению адаптивного сопровождения на старте разработок.

 
< Пред   СОДЕРЖАНИЕ   След >