Тестирование программного обеспечения. Учебное пособие — Блог веб-программиста

Содержание

Лекция 10. Тестирование программных продуктов

 

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

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

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

В литературе имеется несколько различных определений понятия “тестирование”. Будем использовать следующее:

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

Часто тестирование программы в соответствии с этим определением называют динамическим тестированием, а статический анализ, не требующий выполнения программы (просмотр, инспекция), – статическим тестированием.

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

Определение. Методы тестирования – это совокупность правил, регламентирующих последовательность шагов по тестированию.

Определение. Критерии тестирования – соображения, позволяющие судить о достаточности проведенного тестирования.

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

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

Результативным (удачным) считается тест, прогон которого привел к обнаружению ошибки. Из данного свойства теста вытекает важное следствие: тестирование – процесс деструктивный (обратный созидательному, конструктивному). Именно этим объясняется, почему многие считают его трудным. Большинство людей склонны к конструктивному процессу созидания объектов и в меньшей степени – к деструктивному процессу.

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

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

Программный продукт, как объект тестирования, имеет ряд особенностей, которые отличают процесс тестирования программного обеспечения от традиционного, исторически ранее появившегося “аппаратного” тестирования:

· отсутствиеполностью определенного единого эталона, которому должны соответствовать все результаты тестирования проверяемой программы;

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

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

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

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

Это определяет необходимость применения экономичных и эффективных методов тестирования.

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

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

· относительно невысокая степень формализации критериев завершения процесса тестирования и оценки качества тестирования.

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

 

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

На практике приходится применять ряд значительно различающихся методов и критериев тестирования.

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

Сформулируем основные принципы тестирования:

· Описание предполагаемых значений выходных данных или результатов должно быть неотъемлемой частью теста.

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

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

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

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

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

· Не следует выбрасывать тесты, даже если программа уже не нужна.

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

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

Предыдущая17181920212223242526272829303132Следующая


Дата добавления: 2015-08-26; просмотров: 1108;


ПОСМОТРЕТЬ ЕЩЕ:

Данный тренинг предназначен для продвинутых пользователей, которые хотят открыть для себя новую перспективную сферу деятельности – тестирование программного обеспечения. Участники тренинга освоят базовые умения и навыки в сфере тестирования ПО:

  • Введение в тестировании ПО.

    Основы функционального тестирования.

  • Web- и Standalone-проекты как направления тестирования. Основы общих видов тестов.
  • Описание дефектов.
  • Системы менеджмента дефектов.
  • Жизненный цикл проекта. Уровни тестирования. Тестовая отчетность.

 

 

Блок 1. Введение в тестирование ПО
  • Место тестирования в процессе разработки ПО
  • Понятия «Тестирование», «Обеспечение качества» и «Контроль качества»
  • Этапы разработки ПО и участники этого процесса
  • Ответственность QA Менеджера, QA Инженера
Блок 2. Работа с дефектами: Описание и структура дефектов
  • Описание и структура дефектов
  • Основные ошибки описания дефектов и как их избежать
  • Правила выставления критичности
Блок 3. Работа с дефектами: Жизненный цикл дефектов
  • Жизненный цикл дефектов
  • Системы управления дефектами
Блок 4. Тестовая документация и артефакты тестирования
  • Тестовая документация: Acceptance Sheet, Test Survey, Check List
  • Test Cases: структура и детализация
  • Тестовая отчетность
  • Тестовая отчетность
Блок 5. Тестирование – какое оно бывает?
  • Обзор и назначение основных типов тестирования
  • Виды технического тестирования
  • Кроссбраузерное и кроссплатформенное тестирование
Блок 6. Подходы к тестированию
  • Уровни тестирования (типы по покрытию)
  • Подходы к тестированию – как находить дефекты
  • Тестовые активности
Блок 7. Жизненный цикл проекта
  • Модели ЖЦП
  • Виды тестирования в зависимости от этапов жизненного цикла проекта
Блок 8. Заключительная консультация по курсу
  • Определение уровня подготовленности слушателей и индивидуальная обратная связь
  • Рекомендации по составлению резюме, прохождению собеседований, поиску работы

 

Записаться на аудиторный тренинг «Основы тестирования ПО»

Тестирование программного обеспечения: автоматизация

Что такое автоматизация тестирования и в каких случаях она может оказаться полезной?

Автоматизация тестирования: зачем это нужно? Грамотно написанные и отлаженные автотесты позволят оперативно провести регрессионное тестирование функциональности продукта, а у тестировщиков будет время на тестирование новой функциональности, на интуитивный, творческий анализ работы приложения

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

Автотесты: мифы и реальность. Способны ли автотесты полностью заменить ручное тестирование? Инструмент — наше всё? Написал автотесты один раз, и можно использовать их до скончания века?

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

Использование AutoIt для автоматизации тестирования программных продуктов:

Применение AutoIt для тестирования GUI-приложений.

Вступительная статья и небольшой практикум.

AutoIt: чтение конфигурации автотеста. Пример создания конфигурационного файла автотеста и работа с ним в AutoIt.

AutoIt: скрытые возможности. Рассмотрим простой пример: как ловить неожидаемые окна при тестировании GUI-приложений.

Python и AutoIt: cлужили два товарища. Python + AutoItX — отличная комбинация для надежных автотестов.

Применение Expect для автоматизации диалоговых сценариев:

Expect: автоматизация рутинных операций. Небольшой практикум на примере установки пакета в Solaris.

Expect.pm, Pexpect, empty. Наследники Expect вобрали в себя лучшие черты своего прародителя.

Другие статьи:

PowerShell: автоматизация тестирования GUI. В поставку оболочки входит больше сотни командлетов (cmdlets), облегчающих выполнение административных задач в среде Windows. В то же время, для автоматизации тестирования GUI потребуются дополнительные средства: командлеты, учитывающие специфику тестируемых приложений, либо прямое обращение к классам Microsoft .NET Framework.

Теория и практика тестирования ПО:

Введение | Подходы | Инструменты | Автоматизация | Модульные тесты | Ресурсы


Тестирование программного обеспечения — основные понятия и определения

Тестирование программного обеспечения (Software Testing) — проверка соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов, выбранном определенным образом. [IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004]В более широком смысле, тестирование — это одна из техник контроля качества, включающая в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis).

Верификация (Verification) — это процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа [IEEE]. Т.е. выполняются ли наши цели, сроки, задачи по разработке проекта, определенные в начале текущей фазы.

Валидация (Validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе [BS7925-1].

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

Тест дизайн (Test Design) — это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест кейсы), в соответствии с определёнными ранее критериями качества и целями тестирования.

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

Баг/Дефект Репорт (Bug Report) — это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.

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

Детализация Тест Кейсов (Test Case Specification) — это уровень детализации описания тестовых шагов и требуемого результата, при котором обеспечивается разумное соотношение времени прохождения к тестовому покрытию

Время Прохождения Тест Кейса (Test Case Pass Time) — это время от начала прохождения шагов тест кейса до получения результата теста.

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

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

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

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

Плюсы автоматизации:

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

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

3. Сокращение времени тестирования за счет быстрого выполнения – автоматизированный скрипт работает намного быстрее человека.

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

5.

Отчеты – автоматически рассылаемые и сохраняемые отчеты о результатах тестирования.

6. Сокращение времени тестирования за счет проведения тестов в нерабочее время.

Минусы:

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

2. Большие затраты на разработку и увеличение времени подготовки к тестированию – разработка автоматизированных тестов это сложный процесс, так как фактически идет разработка приложения, которое тестирует другое приложение. В сложных автоматизированных тестах также есть фреймворки (англ. framework – каркас: программное обеспечение, облегчающее объединение разных компонентов большого программного проекта), утилиты, библиотеки и прочее. Естественно, все это нужно тестировать и отлаживать, а это требует времени. Вносится новый «человеческий фактор» – за счет возможных ошибок, допущенных уже в разработке тестов.

3. Стоимость инструмента для автоматизации – в случае если используется лицензионное ПО, его стоимость может быть достаточно высока. Свободно распространяемые инструменты как правило отличаются более скромным функционалом и меньшим удобством работы.

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

Перечислим места, гденужно применять автоматизацию:

1. Труднодоступные места в системе (бэкенд процессы, логирование файлов, запись в БД).

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

3. Рутинные операции, такие как переборы данных (формы с большим количеством вводимых полей – автоматизировать заполнение полей различными данными и их проверку после сохранения).

4. Валидационные сообщения (автоматизировать заполнение полей некорректными данными и проверку на появление той или иной валидации).

5. Длинные end-to-end сценарии.

6. Проверка данных, требующих точных математических расчетов.

7. Проверка правильности поиска данных.

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

В тестировании используется такое понятие, как тестовый случай.

Тестовый случай, тест-кейс (test case) – это набор условий и/или переменных, с помощью которых тестировщик будет определять, насколько полно тестируемое приложение удовлетворяет предъявляемому к нему требованию.

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

· Базовые операции создания/чтения/изменения/удаления сущностей (так называемые CRUD операции — Create / Read / Update / Delete).

Пример: создание, удаление, просмотр и изменение данных о пользователе.

· Типовые сценарии использования приложения, либо отдельные действия.

Пример: пользователь заходит на почтовый сайт, листает письма, просматривает новые, пишет и отправляет письмо, выходит с сайта. Это так называемый end-to-end сценарий, который проверяет совокупность действий. Желательно использовать именно такие сценарии, так как они позволяют вернуть систему в состояние, максимально близкое к исходному, а значит – минимально влияющее на другие тесты.

· Интерфейсы работы с файлами и другие моменты, неудобные для тестирования вручную.

Пример: система создает некоторый xml файл, структуру которого необходимо проверить.

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

Предыдущая121122123124125126127128129130131132133134135136Следующая


Дата добавления: 2015-09-07; просмотров: 1076;


ПОСМОТРЕТЬ ЕЩЕ:

Добавить комментарий

Закрыть меню