Принципы и понятия теста ПО

Содержание:

Введение

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

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

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

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

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

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

1. Теория теста ПО

1.1 Принципы и понятия теста ПО

Тест ПО (software test) - это процесс анализа или использования ПО для выявления дефектов и ошибок.

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

Согласно определению, тест предполагает "анализ" или "эксплуатацию" программного продукта. Деятельность, связанная с тестированием, сопряженная с анализом результатов разработки ПО, называется статическим тестированием (static testing). Статическое тестирование означает тщательную проверку кода программы, сквозной контроль и тестирование программы без непосредственного запуска на компьютере, т.е. проверку за столом (desk checks). Тестовая же деятельность, в которой используется продукт программы называется динамическим тестированием (dynamic testing). Статические и динамические тесты зачастую дополняют друг друга, и каждый из них использует свой подход по выявлению огрехов и дефектов.

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

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

Аксиомы тестирования ПО

Первая – Хорош тот тест, в котором высока вероятность нахождения ошибки.

Эта аксиома является фундаментальным принципом тестирования.

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

Вечная экономическая дилемма: как выбрать конечное число тестов, которое дает максимальную отдачу (вероятность нахождения ошибок) для данных затрат

Третья – Необходимая часть любого теста – описание ожидаемых выходных данных

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

1.2 Этапы теста ПО

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

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

Есть несколько подходов к формулировке стратегии тестирования:

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

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

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

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

Определение объема тестовой работы

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

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

Тестирование в начале именно требований с высшим приоритетом.

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

Применять разбитие на эквивалентные классы и анализ граничных значений для того что бы снижать трудозатраты на тестирование

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

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

Определение подхода к тестам

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

Стадия формулировки условий

Стадия проекта системы

Стадии теста проекта программ, программного кода, модульного теста и комплексных испытаний

Системные испытания

Приемочные испытания

Регрессионный тест

Способы тестирования должны отражаться в документах, содержащих планы проведения испытаний.

Определение критериев теста и контрольных точек качества продукции.

Существует пять типажей критериев, которые можно определить перед началом системного теста:

Критерий входа. Описывает, что необходимо сделать перед тестом.

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

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

Критерий успешного/неудачного прохождения теста. Каждое тестирование дает уже известные результаты.

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

Определение стратегии автоматизации.

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

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

1.3 Задачи и цели тестов ПО

Цели тестов:

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

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

Выполнить максимально полное тестирование приложения за короткий срок.

Задачи тестов:

Удостовериться, что система выполняет временные условия отклика клиента и сервера.

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

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

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

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

Пользоваться инструментами автоматизированного тестирования лишь там, где это может быть целесообразно.

Проводить тесты так, чтобы можно было не только находить, но и предотвращать дефекты.

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

1.4 Комплексный тест ПО

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

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

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

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

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

1.5 Восходящее и нисходящее, а также целостное тестирование

Восходящие тесты – замечательный способ отсечения и локализации ошибок в коде. Обнаруженная лишь в одном модуле ошибка, указывает что проблема конкретно в нем, ради нахождения истока этой ошибки вам не придется обыскивать весь код. И раз уж ошибка появляется именно при совместной работе двух заранее протестированных модулей, значит, дело именно в их интерфейсе. Еще одним из преимуществ восходящего тестирования является то, что программист, который выполняет такое тестирование сосредотачивается на конкретной области (одном-единственном модуле, обмене или передаче информации между парой конкретных модулей и так далее). Благодаря такому способу само тестирование проходит куда более тщательно и чаще выявляет ошибки.

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

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

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

Одним из главных плюсов этой стратегии является то, что необходимость в написании «лишнего» кода отпадает. Во многом из-за этого часть руководители выбирают такой способ в надежде сэкономить временной ресурс - они думают, что проще будет спрограммировать один большой набор тестов и одним лишь им (набором) проверить систему полностью за один раз. Конечно, такое рассуждение ошибочно, и сейчас я объясню почему же.

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

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

• Тяжело организовывать надлежащий «ремонт» ошибок. Если самим написанием программы заняты несколько программистов (Зачастую так и бывает в крупных системах), но при этом еще и непонятно, в каком же модуле ошибка, кто будет искать её, и править? Один из программистов будет показывать на другого, тот в свою очередь, выяснив, что конкретно его код здесь ни при чем, снова полезет к первому, и в итоге весь процесс заметно замедлится, если вовсе не остановится из-за неразберихи.

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

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

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

При использовании такого подхода возникают несколько сложностей.

Первая, когда тестируемый модуль вызывает модуль более низкоуровневый.

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

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

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

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

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

2. Стратегии тестирования ПО

2.1 Стратегия Сэндвича

Тест при помощи метода Сэндвича (sandwich – бутерброд, англ.) заключает в себе объединение нисходящего и восходящего подходов. Сам метод заключается в попытке совместить плюсы от работы обоих подходов, избегая при этом их недостатков. Использование этого метода подразумевает то, что начинается одновременно и восходящий тест, и нисходящий, сверху и снизу соответственно. В итоге чего оба подхода «встречаются» где-то в середине, в точке, которая заранее зависит от выбранной тестовой программы, и которую необходимо определить. К примеру, если разработчик представит эту систему в виде нескольких уровней, необходимых для применения нисходящего метода, то все прочее он может выполнить с помощью восходящего.

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

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

Модифицированный метод сэндвича.

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

2.2 Стратегия «белой коробки»

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

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

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

1. Гарантия того, что все независимые пути в модуле проверены как минимум один раз.

2. Проверка всех логических решений на то, истинны они или же ложны.

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

4. Исследование каркаса внутренних данных для проверки их достоверности.

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

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

Методы теста, основывающиеся на белом ящике:

Ввод неверных значений. Если вводятся неверные значения, тестирующий принуждает коды возврата к показу ошибок, а сам наблюдает за тем, как отреагирует код. Популярным методом является замена alloc() функцией, которая возвращает значение NULL в 10% случаев с целью выяснения, сколько сбоев будет в результате. Еще, такую стратегию можно назвать тестом с ошибочными вводными данными. При тестированиях такого рода проверка обработка данных проверяется как на верных, так и на неверных. Сами тестирующие могут подбирать значения, проверяющие определенный диапазон входных/выходных настроек, и еще те значения, которые выходят за границу диапазона.

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

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

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

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

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

Анализ покрытия. В выборе аналитического инструмента нужно, чтобы группа тестирования изучила сам тип покрытия, нужный приложению. Метод покрытия операторов еще называют С1, что еще и может означать покрытие узлов. Такие тестирования определят, все ли исполняемые операторы были протестированы. Метод такого тестирования зачастую использует программу протокола (profiler – профайлер) производительности.

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

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

2.3 Стратегия «черной коробки»

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

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

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

Неверная или пропущенная функциональность

Ошибки интерфейса

Проблемы удобства использования

Методы тестирования на основе Автоматизированные инструменты

Ошибки в структурах данных или ошибки доступа к внешним базам данных

Проблемы снижения производительности и другие ошибки производительности

Ошибки загрузки

Ошибки многопользовательского доступа

Ошибки инициализации и завершения

Проблемы сохранения резервных копий и способности к восстановлению работы

Проблемы безопасности

Методы тестирования на основе стратегии черного ящика

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

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

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

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

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

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

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

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

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

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

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

3.0 Методы отладки ПО

программный обеспечение тестирование отладка

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

- Ручное тестирование;

- Метод дедукции;

- Метод индукции;

- Обратное прослеживание.

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

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

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

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

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

3.1 Методы и средства получения доп. информации

Для получения дополнительной информации об ошибке можно выполнить добавочные тесты или использовать специальные методы и средства:

Отладочный вывод

Интегрированные средства отладки

Независимые отладчики

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

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

Интегрированные средства отладки включают в себя большинство современных средств программирования (Delphi, Builder C++, Visual Studio и прочие) которые обеспечивают наиболее эффективную отладку. Они позволяют:

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

Предусматривать точки остановки.

Выполнять программу до оператора, указанного курсором.

Отображать содержимое любых переменных при пошаговом выполнении.

Отслеживать поток сообщений и так далее.

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

Аналогично поступают при «зависании» компьютера.

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

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

Заключение

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

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

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

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

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

Список использованных источников

1. Бейзер Б. Тестирование черного ящика. Технологии функционального тестирования программного обеспечения и систем [текст] / Б. Бейзер; - Питер, 2004, 320 с. ISBN 5-94723-698-2.
2. Брауде Э.Д. Технология разработки программного обеспечения [текст] / Э.Д. Брауде; - Питер, 2004, 656 с. ISBN 5-94723-663-X.
3. Винниченко И.В. Автоматизация процессов тестирования [текст] / И. В. Винниченко; - Питер, 2005, 208 с. ISBN 5-469-00798-7.
4. Канер С. Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений [текст] / С. Канер; - ДиаСофт, 2001, 544 с, ISBN 966-7393-87-9.
5. Калбертсон Р. Быстрое тестирование [текст] / Р. Калбертсон, К. Браун, Г. Кобб; - Вильямс, 2002, 384 с. ISBN 5-8459-0336-X.
6. Коликова Т.В. Основы тестирования программного обеспечения. Учебное пособие [текст] / Т.В. Коликова, В.П. Котляров; - Интуит, 2006, - 285 с. ISBN 5-85582-186-2.
7. Касперски К. Техника отладки программ без исходных текстов [текст] / К. Касперски; - БХВ-Петербург, 2005, 832 с. ISBN 5-94157-229-8.
8. Макгрегор Д. Тестирование объектно-ориентированного программного обеспечения. Практическое пособие [текст] / Д. Макгрегор, Д. Сайкс; - ТИД «ДС», 2004, 432 с. ISBN 966-7992-12-8.
9. Плаксин М. Тестирование и отладка программ - для профессионалов будущих и настоящих [текст] / М. Пласкин; - Бином. Лаборатория знаний, 2007, - 168 с. ISBN 978-5-94774-458-3.
10. Роберт М. Быстрая разработка программ: принципы, примеры, практика [текст] / М. Роберт, Д. Ньюкирк; - Вильямс, 2004, 752 с. ISBN 5-8459-0558-3.
11. Фолк Д. Тестирование программного обеспечения [текст] / Д. Фолк, Е. К. Нгуен, С. Канер; - Диасофт, 2003 , 400 с. ISBN 966-7393-87-9.
12. Элфрид Д. Автоматизированное тестирование программного обеспечения. Внедрение, управление и эксплуатация [текст] / Элфрид Д., Джефф Р., Джон П.;- Лори, 2003, ISBN 5-85582-186-2.