Файл: Принципы и понятия теста ПО.pdf

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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