Файл: Этапы разработки, тестирования и ввода в эксплуатацию мобильных приложений (Каскадная модель разработки программной системы).pdf

Основные процессы

Заказ;

Поставка; Разработка;

Эксплуатация; Сопровождение

Документирование;

Управление конфигурацией;

Обеспечение качества;

Верификация;

Аттестация;

Совместный анализ;

Аудит;

Разрешение проблем

Управление проектами;

Создание инфраструктуры проекта;

Усовершенствова-ние;

Обучение

Рисунок 4 – Структура жизненного цикла программных средств

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

Глава 2. Тестирование и отладка программной системы

2.1. Виды тестирования

Функциональное тестирование.

Проверка функциональности (тестирование методом «черного ящика») представляет собой определенную проверку соответствия определенной программной системы некоторым требованиям, которые были заявлены в ее спецификации. В процессе функционального тестирования могут выполняться как операции полного тестирования заявленной функциональности, так и выполнение проверки только базовой функциональности конечной программной системы.

Тестирование «белого ящика» (white box) представляет собой использование операций тестирования на соответствие программной системы некоторым требованиям с учетом знаний внутренней структуры реализации программной системы (при наличии исходного кода и технической спецификации)^[17].

Тестирование «черного ящика» (black box) представляет собой тестирование на соответствие программной системы заявленным требованиям без знания внутренней структуры реализации программной системы.

Системное тестирование.

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

Тестирование производительности.

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

Нагрузочное тестирование.

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

Стресс тестирование.

Стресс тестирование представляет собой тестирование, которое предназначено для выполнения проверки полной работоспособности программной системы при наличии нестандартных нагрузок и для выявления максимально возможного пика программной системы, при котором программная система будет работать правильно и без сбоев^[18]. Так же стресс тестирование используется для выявления результатов, при которых программная система переходит в нерабочее состояние, т.е. выходит из строя.

Регрессионное тестирование.

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

Модульное тестирование.

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

Тестирование безопасности.

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

Тестирование локализации.

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

Юзабилити тестирование.

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

2.2. Тестирование надежности

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

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

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

Надежность и правильность программной системы.

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

1. Число ошибок в программной системе представляет собой определенную величину «ненаблюдаемую», наблюдаются не сами возникающие ошибки, а результат их проявления в конечной программной системе.

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

3. Ошибки могут быть компенсированы между собой, так что после устранения некоторой ошибки программная система может начать «работать хуже», но это не будет свидетельствовать о конечной надежности программной системы.

4. Надежность характеризуется частотой проявления возможных ошибок, но не их количества; в то же время хорошо является известным, что ошибки могут проявляться с разной частотой: множество ошибок будут неопределенными после нескольких месяцев и даже лет конечной эксплуатации программной системы, но, с другой стороны, нетрудно найти примеры, когда одна ошибка может привести к неверному выполнению программной системы при любых исходных данных, т.е. к некоторой нулевой надежности^[20].

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

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

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

В качестве примера рассмотрим метод восходящего тестирования.

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

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

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

2.3. Организация процесса тестирования

Тестирование программной системы одновременно проводится по нескольким направлениям:

1. Проверка кода (review): в процессе которой тестер просматривает визуально исходный код программной системы и ищет в нём имеющиеся ошибки, а так же выполняет поиск различных несоответствий программного кода и требований, предъявляемых к нему. Под требованиями к программному коду понимается определенный стандарт, которого должны придерживаться разработчики программной системы, реакция на те или иные действия со стороны среды воздействия на программную систему, поведение программной системы в различных ситуациях [16].