Файл: Основы алгоритмизации и программирования.pdf

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

2. Выбор и обоснование стратегии автоматизации.

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

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

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

2.1. Цели и задачи тестирования программного обеспечения

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

Задачи тестирования:

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

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

2.2. Методологии тестирования ПО

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

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

Рис. 1. Каскадная модель.

V model – как и в случаи с каскадной моделью, методика основана на последовательности выполнения. Однако главным отличием является то, что тестирование идет параллельно со стадией разработки. Согласно этой методике тестирование можно начинать, как только становиться доступно статическое тестирование, что помогает предотвратить появление ошибок на поздней стадии разработки. Рисунок 2, изображенный ниже показывает принцип модели, которые разделены на две части.

Рис 2. V model

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

Рис 3. Инкрементная модель.

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

Рис. 4. Спиральная модель.

2.3. Комплексное тестирование программного обеспечения

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

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

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

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

2.4. Нисходящее и восходящее тестирование

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

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

Рис. 5. Методика нисходящего тестирования.

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

Рис. 5 Методика восходящего тестирования.

К преимуществам можно отнести сохранение и последовательное развитие данных.

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

3. Стратегия тестирования и отладки программного обеспечения

3.1. Метод Сандвича

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

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