История тестирования программного обеспечения отражает эволюцию разработки самого программного обеспечения. В течение длительного времени разработка программного обеспечения уделяла основное внимание крупномасштабным научным программам, а также программам министерства обороны, связанным с системами корпоративных баз данных, которые проектировались на базе универсальной ЭВМ или миникомпьютера.
Прикрепленные файлы: 1 файл
ФЕДЕРАЛЬНОЕ АГЕНСТВО ПО ОБРАЗОВАНИЮ
Московский государственный университет экономики, статистики и информатики
Кафедра Информационных технологий,
Естественнонаучных и математических дисциплин
по дисциплине: «Программная инженерия»
на тему: «Тестирование программного обеспечения. Уровни тестирования. Методы тестирования. Этапы тестирования. Виды тестирования»
Выполнил: студент 1 курса
Кузьмин Валентин Валентинович
Проверила: Александрова Вера Алексеевна
- Тестирование программного обеспечения……………………. ….5
- Уровни тестирования……………………..…………………… ……5
- Методы тестирования…………..……………………………… …. 8
- Восходящее тестирования………………..………………………… 8
- Нисходящее тестирование…………………..……………………… 9
- Метод большого скачка…………………………..…………………9
- Метод сандвича…………………………..………………………… .9
- Модифицированный метод сандвича………………………..……10
- Метод «Белого ящика»………………………. ……………………10
- Метод «Черного ящика»…………………….. …………………….11
Список использованной литературы…………………………………….19
Unit тесты в Python. Тестирование кода | Базовый курс. Программирование на Python
История тестирования программного обеспечения отражает эволюцию разработки самого программного обеспечения. В течение длительного времени разработка программного обеспечения уделяла основное внимание крупномасштабным научным программам, а также программам министерства обороны, связанным с системами корпоративных баз данных, которые проектировались на базе универсальной ЭВМ или миникомпьютера.
Тестовые сценарии записывались на бумагу. С их помощью проверялись целевые потоки управления, вычисления сложных алгоритмов и манипулирование данными. Окончательный набор тестовых процедур мог эффективно протестировать всю систему полностью. Тестирование обычно начиналось лишь после завершения плана–графика проекта и выполнялось тем же персоналом.
Появление персональных компьютеров способствовало стандартизации этой отрасли, поскольку приложения стали изначально создаваться для работы с общей операционной системой. Внедрение персональных компьютеров открыло новую эру и привело к быстрому и бурному росту коммерческих разработок. Коммерческие приложения жестко боролись за первенство и выживание. Пакетная обработка заменялась системами, работающими в реальном времени.
Тестирование систем реального времени потребовало другого подхода к проектированию тестирования из–за того, что рабочие потоки могли вызываться в любом порядке. Эта особенность привела к появлению огромного количества процедур тестирования, способных поддержать бесконечное число перестановок и сочетаний.
Подходит ли тебе программирование? Легко проверить
Долгое время программные ошибки рассматривали как простые неприятности. В связи со всеобщей компьютеризацией, все шире и шире захватывающей такие важные области, как управление системами жизнеобеспечения, медицинские приборы и сверхдорогую компьютерную аппаратуру, ошибки стало невозможно рассматривать как нечто имеющее значение только на этапах разработки.
- Тестирование программного обеспечения
Тестирование программного обеспечения (software testing) – это процесс анализа или эксплуатации программного обеспечения с целью выявления дефектов.
Слово процесс (process) используется для того, чтобы подчеркнуть, что тестирование это плановая, упорядоченная деятельность.
Тестирование предусматривает «анализ» или «эксплуатацию» программного продукта. Тестовая деятельность, связанная с анализом результатов разработки программного обеспечения, называется статическим тестированием (static testing). Статическое тестирование предусматривает проверку программных кодов, сквозной контроль и проверку программы без запуска па машине, то есть проверку за столом (desk checks). В отличие от этого, тестовая деятельность, предусматривающая эксплуатацию программного продукта, носит название динамического тестирования (dynamic testing). Статическое и динамическое тестирование дополняют друг друга, и каждый из этих типов тестирования реализует собственный подход к выявлению ошибок.
Важным понятием процесса тестирования является дефект (bug). Дефект – это программная ошибка – изъян в разработке программного продукта, который вызывает несоответствие ожидаемых результатов выполнения программного продукта и фактически полученных результатов. Дефект может возникнуть на стадии кодирования, на стадии формулирования требований или на стадии проектирования, либо же его причина может крыться в некорректной конфигурации или данных.
Отладка – это процесс выявления источников отказов, то есть ошибок, и внесение в программу соответствующих исправлений для их устранения.
- Уровни тестирования
Тестирование обычно производится на протяжении всей разработки и сопровождения на разных уровнях. Уровень тестирования определяет «над чем» производятся тесты: над отдельным модулем, группой модулей или системой, в целом. При этом ни один из уровней тестирования не может считаться приоритетным. Важны все уровни тестирования, вне зависимости от используемых моделей и методологий. Различают три уровня тестирования: модульное, интеграционное и системное тестирование.
Модульное тестирование (юнит–тестирование). Данный вид тестирования позволяет проверить на корректность отдельные модули исходного кода программы.
Идея состоит в том, чтобы писать тесты для каждой нетривиальной функции или метода. Это позволяет достаточно быстро проверить, не привело ли очередное изменение кода к регрессии, то есть к появлению ошибок в уже оттестированных местах программы, а также облегчает обнаружение и устранение таких ошибок.
Целью модульного тестирования является изоляция отдельных частей программы для того, чтобы показать, что по отдельности эти части работоспособны.
Модульное тестирование помогает устранить сомнения по поводу отдельных модулей и может быть использовано для подхода к тестированию «снизу вверх»: сначала тестируются отдельные части программы, затем программа в целом.
Как и любая технология тестирования, модульное тестирование не позволяет отловить все ошибки программы. В самом деле, это следует из практической невозможности трассировки всех возможных путей выполнения программы, за исключением простейших случаев. Кроме того, происходит тестирование каждого из модулей по отдельности.
Это означает, что ошибки интеграции, системного уровня, функций, исполняемых в нескольких модулях, не будут определены. Кроме того, данная технология бесполезна для проведения тестов на производительность. Таким образом, модульное тестирование более эффективно при использовании в сочетании с другими методиками тестирования.
Интеграционное тестирование. В данной фазе тестирования отдельные программные модули объединяются и тестируются в группе. Обычно интеграционное тестирование проводится после модульного тестирования и предшествует системному тестированию.
Интеграционное тестирование в качестве входных данных использует модули, над которыми было проведено модульное тестирование, группирует их в более крупные множества, выполняет тесты, определенные в плане тестирования для этих множеств, и представляет их в качестве выходных данных и входных для последующего системного тестирования.
Целью интеграционного тестирования является проверка соответствия проектируемых единиц функциональным, приемным и требованиям надежности. Тестирование этих проектируемых единиц – объединения, множества или группы модулей – выполняется через их интерфейс, с использованием тестирования «черного ящика». Для автоматизации интеграционного тестирования применяются системы непрерывной интеграции (Continuous Integration System, CIS).
Системное тестирование. Это тестирование программного обеспечения, выполняемое на полной, интегрированной системе, с целью проверки соответствия системы исходным требованиям. Системное тестирование относится к методам тестирования черного ящика, и, тем самым, не требует знаний о внутреннем устройстве системы.
Основной задачей системного тестирования является проверка как функциональных, так и не функциональных требований к системе в целом. При этом выявляются дефекты, такие как неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии использования, отсутствующая или неверная функциональность, неудобство использования и т.д. Для минимизации рисков, связанных с особенностями поведения системы в той или иной среде, во время тестирования используется окружение максимально приближенное к тому, на которое будет установлен продукт после выдачи.
Выделяют два подхода к системному тестированию:
– на базе требований (для каждого требования пишутся тестовые случаи, проверяющие выполнение данного требования);
– на базе случаев использования.
Подкатегориями системного тестирования являются альфа–тестирование и бета–тестирование.
Альфа–тестирование – имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями. Чаще всего альфа–тестирование проводится на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приемочного тестирования. Иногда альфа–тестирование выполняется под отладчиком или с использованием окружения, которое помогает быстро выявлять найденные ошибки.
Бета–тестирование – в некоторых случаях выполняется распространение предварительной версии (иногда с ограничениями по функциональности или времени работы) для некоторой большей группы лиц с тем, чтобы убедиться, что продукт содержит достаточно мало ошибок.
- Методы тестирования программного обеспечения
При восходящем тестировании программа собирается и тестируется снизу вверх. Модули самого нижнего уровня тестируются изолированно, автономно. После того как тестирование этих модулей завершено, вызов их должен быть так же надежен, как вызов встроенной функции языка или оператор присваивания.
Затем тестируются модули, непосредственно вызывающие уже проверенные. Эти модули более высокого уровня тестируются не автономно, а вместе с уже проверенными модулями более низкого уровня. Процесс повторяется до тех пор, пока не будет достигнута вершина. Здесь завершаются и тестирование модулей, и тестирование сопряжении программы.
При нисходящем тестировании программа собирается и тестируется сверху вниз. Изолировано тестируется только головной модуль. После того как тестирование этого модуля завершено, с ним соединяются один за другим модули, непосредственно вызываемые им, и тестируется полученная комбинация. Процесс повторяется до тех пор, пока не будут собраны и проверены все модули.
В соответствии с этим методом каждый модуль тестируется автономно. По окончании тестирования модулей они интегрируются в систему все сразу.
Метод большого скачка по сравнению с другими подходами имеет много недостатков и мало достоинств. Модули не интегрируются до самого последнего момента, а это означает, что в течение долгого времени серьезные ошибки в сопряжениях могут остаться необнаруженными. Он значительно усложняет отладку. Но все же, данный метод не всегда нежелателен.
Если программа мала и хорошо спроектирована, он может оказаться приемлемым. Однако для крупных программ метод большого скачка обычно губителен.
- Тестирование методом сандвича
Источник: www.referat911.ru
Словарь тестировщика: автотесты, юнит-тесты и другие важные слова
В прошлой статье про тестирование калькулятора мы занимались ручным тестированием. Это эквивалент любого другого ручного труда: может быть эффективно, но плохо масштабируется, и вообще это не инженерный подход.
А вот — инженерный. В этой статье разберём на базовом уровне основные подходы к инженерному тестированию.
Что такое автотесты
Автотесты — это тесты, которые выполняет компьютер, а не человек. Внутри автотест это тоже программа, цель которой — протестировать, как работает другая программа.
Автотест делается и работает так:
- Программист берёт часть программы, которую он тестирует, и прикидывает, какие данные она должна вернуть, если в неё попадут другие данные.
- Затем программист собирает нужные ему для тестов комбинации данных на вход и на выход, которые должны быть в идеальной ситуации.
- После этого он добавляет в тест специально неправильные данные и ожидаемый ответ в этом случае.
- Когда все проверочные данные готовы, он оборачивает их в код и пишет тест — программу-тестировщика, которая обращается к программе-жертве и смотрит, как та отреагирует на разные данные.
После этого тестировщики смотрят на тестовые и реальные результаты и делают вывод, правильно работает эта часть программы или нет.
Автотесты делятся по масштабам тестирования на юнит-тесты, сервисные тесты и интеграционные тесты.
Юнит-тесты
Юниты — это отдельные модули или части программы, каждый из которых отвечает за что-то своё.
Юнит-тесты проверяют работу отдельных юнитов: берут модуль и прогоняют его по всем своим тестам. Чем меньше и проще модуль, тем проще сделать юнит-тест и прогнать его по модулю. Модулем может быть что угодно — функция, метод класса, часть API и так далее.
Юнит-тесты — самые простые в обслуживании и написании. Работают быстро, проверяют модуль вдоль и поперёк, но есть нюанс: если в программе больше одного модуля, то просто протестировать их по одному недостаточно — они могут работать классно поодиночке, но вместе работать плохо. Чтобы проверить работу нескольких модулей вместе, делают сервисные тесты.
Сервисные тесты
Задача сервисного теста — протестировать работу нескольких модулей вместе: как они запускаются, передают друг другу данные и правильно ли решают свою общую задачу как одно целое.
Это уже сложнее, чем юнит-тесты, зато помогает понять, как модули работают вместе. Правда, не все используют сервисные тесты, а переходят сразу к интеграционным, но знать про них тоже полезно.
Интеграционные тесты
Эти тесты проверяют, как работают все модули сразу или даже как работает вся программа.
Интеграционные тесты — самые сложные, потому что если меняется что-то хотя бы в одном модуле, то, скорее всего, нужно будет переделать весь интеграционный тест. Это дорого и занимает много времени, поэтому в компаниях стараются делать так:
- писать побольше юнит-тестов, прям чтобы было много;
- сервисных тестов писать поменьше;
- а интеграционных — ещё меньше, в идеале один или два, и всё.
Минусы автотестов
Если бы всё можно сделать автотестами, которые не пропускают ни одной ошибки в программе, то в разработке ПО наступил бы идеальный мир. Но у автотестов тоже есть минусы.
Стоимость разработки. Так как автотест — это тоже программа, на её разработку тоже нужны время и деньги. Чем сложнее автотест, тем больше ресурсов на него нужно. Иногда проще разбить один большой тест на много тестов поменьше, чем разрабатывать огромную универсальную тест-машину.
Поддержка. Там, где разработка, там и поддержка ПО. Автотесты тоже нужно поддерживать в актуальном состоянии: следить за правильностью тестируемых параметров, текущими названиями классов и методов и версиями тестируемого софта.
Выбор тестов. Чтобы написать хороший автотест, нужно перед этим определиться, а что именно он будет тестировать. Иногда на это уходит столько же времени, сколько и на пару юнит-тестов, а иногда и больше. Если ошибиться на этом этапе, тест может сработать вхолостую и пользы для проекта не будет.
Вот пример: если бы мы автотестировали калькулятор, то мы бы могли сделать тесты с числами 1, 2, 3, 4, 5 … 9999. В нашей голове это максимальное значение, которое людям нужно в обычной жизни. Мы даже не подумаем, что кому-то в нашем калькуляторе понадобится число длиной 17 знаков. А ведь именно на таком числе наш калькулятор и сломался.
Умение программировать. Сейчас появляются инструменты, которые упрощают задачу тестировщика, но без знания алгоритмов пока ещё никуда. Чем лучше инженер по тестированию умеет программировать и строить в голове нужные алгоритмы для проверки, тем круче у него всё получается. Про это как раз в следующем разделе.
Где этому научиться
Можно прочитать нашу подборку книг для новичков — там книги идут по возрастанию сложности, и лучше читать их по порядку. А можно прийти в Практикум и полностью освоить профессию тестировщика за несколько месяцев. По времени будет столько же, а пользы в сто раз больше.
Источник: thecode.media
Методы тестирования ПО
Методы тестирования Восходящее тестирование Программа собирается и тестируется снизу вверх, только модули самого нижнего уровня тестируются изолированно или автономно. После их тестирования вызов их должен быть также надёжен, как вызов встроенной функции языка. Затем тестируются модули, вызывающие уже проверенные.
Эти модули тестируются не автономно, а вместе с уже протестированными. При восходящем тестировании для каждого модуля нужен драйвер. Нужно подавать тесты в соответствии с сопряжением модуля. Одно из возможных решений – написать для каждого модуля небольшую ведущую программу, тестовые данные представляются как встроенные в эту программу переменные.
Другое решение – использовать программу тестирования модулей, тесты написать на специальном языке и избавится от необходимости писать драйвер. Нисходящее тестирование (нисходящая разработка) Изолированно тестируется только головной модуль. После завершения тестирования этого модуля с ним соединяются модули, непосредственно вызываемые им, и тестируется полученная комбинация. Процесс повторяется до тех пор, пока не будет собраны все модули.
Возникают 2 проблемы 1. Что делать, когда тестируемый модуль вызывает модуль более низкого уровня, которого в данный момент еще не существует?
Рекомендуемые материалы
Вариан 24 — ДЗ №3 — Программирование на С++ с использованием классов
Объектно-ориентированное программирование (ООП)
699 290 руб.
Расчетно-графическая работа по курсу «Программирование». Семинар 2. Овладение навыками обработки символьных данных.. Вариант 22
Программирование и алгоритмизация
Расчетно-графическая работа по курсу «Программирование». Семинар 2. Обработка символьной информации. Вариант 18
Программирование и алгоритмизация
Расчетно-графическая работа по курсу «Программирование». Семинар 2. Обработка символьной информации. Вариант 17
Программирование и алгоритмизация
Вопросы и ответы из теста по 1С Платформе 8.3.
Информатика
Вариант 11 — ЛР №10 — Программирование с использованием библиотеки Qt
Объектно-ориентированное программирование (ООП)
299 149 руб.
- Метод совмещает тестирование модулей, тестирование сопряжений и частично тестирование внешних функций.
- Когда модули ввода/вывода уже подключены, тесты можно готовить в удобном виде.
Минусы метода
- Модуль редко тестируется досконально сразу после его подключения. Это связано с тем, что тестирование некоторых модулей требуют крайне сложных заглушек и пишутся простые заглушки, проверяя часть работоспособности модуля.
- Этот подход может породить веру в возможность начать программирование и тестирование верхнего уровня программы до того как вся программа будет полностью спроектирована.
Нисходящий подход выгоден в тех случаях, когда есть сомнения в осуществлении программы в целом.
Нормальный стиль проектирования структуры программы предполагает при окончании проектирования нижних уровней вернуться назад и поправить верхний уровень, внося в него усовершенствования и исправляя ошибки. Если головная часть программы запрограммирована и оттестирована, разработчик с трудом идет на его модификацию.
Модифицированный нисходящий метод
Еще один недостаток нисходящего метода – полнота тестирования. В методе также сложно проверять исключительные ситуации.
Модифицированный метод требует, чтобы каждый модуль прошел автономное тестирование перед подключением к программе. Этот метод решает перечисленные проблемы, но все равно нужны как драйверы, так и заглушки.
Метод большого скачка
Это самый распространенный подход в интеграции модулей. Каждый модуль тестируется автономно. По окончанию тестирования модулей они интегрируются в систему все сразу.
Метод имеет несколько недостатков и мало достоинств. Для каждого модуля необходима заглушка и драйверы, модули не интегрируются до самого последнего момента, а это означает, что в течение долгого времени серьезные ошибки в сопряжениях могут оставаться не обнаруженными.
Метод «сэндвича»
Это компромисс между восходящим и нисходящим тестированиями. При использовании этого метода одновременно начинают восходящее и нисходящее тестирования, собирая программу как сверху, так и снизу, встречаясь где-то посередине. Точка встречи зависит от конкретной программы и должна быть определена заранее.
Метод сохраняет достоинства восходящего и нисходящего подходов – начало интеграции системы на самом раннем этапе. Т.к. вершина программы вступает в строй рано как в нисходящем методе, на самом раннем этапе получается работающий каркас программы. Нижние уровни программы создаются восходящим методом, при этом снимаются те проблемы нисходящего метода, которые были связаны с невозможностью тестирования в глубине программы.
Модифицированные метод «сэндвича»
При тестировании методом «сэндвича» возникает также проблема, что и при нисходящем подходе, хотя здесь она стоит не так остро. Проблема в том, что невозможно досконально тестировать отдельные модули. Восходящий этап тестирования по методу «сэндвича» решает эту проблему для нижних уровней, но она может остаться для нижней половины верхней части программы. В модифицированном методе «сэндвича» нижний уровень тестируется строго снизу вверх, а модули верхних уровней тестируются изолированно, а затем собираются нисходящим методом. Т.о. модифицированный метод «сэндвича» также представляет собой компромисс между нисходящим и восходящим подходами.
Источник: studizba.com