Файл: Лекции 1 Дисциплина мдк. 05. 03 Тестирование информационных систем Тема 3 Отладка и тестирование информационных систем Занятие 1 Организация.doc
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 29.03.2024
Просмотров: 76
Скачиваний: 9
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
ПЛАН ЛЕКЦИИ №1
Дисциплина МДК.05.03Тестированиеинформационныхсистем
Тема 5.3.1. Отладка и тестирование информационных систем
Занятие 1: Организациятестированиявкоманде разработчиков
Цель занятия: Ознакомить студентов с основными понятиями тестирования информационных систем. Изучить основы организации тестирования в команде разработчиков.
Учебные задачи:
-
История становления тестирования -
Тестирование - способ обеспечения качества программного продукта. Принципы тестирования. -
Основные понятия тестирования -
Состав команды разработчиков
Учебная литература:
ХОД ЗАНЯТИЯ
-
Учебная задача
На протяжении десятилетий развития разработки ПО к вопросам тестирования и обеспечения качества подходили очень и очень по-разному. Можно выделить несколько основных «эпох тестирования».
В 50–60-х годах прошлого века процесс тестирования был предельно формализован, отделён от процесса непосредственной разработки ПО и «математизирован». Фактически тестирование представляло собой скорее отладку программ. Существовала концепция т.н. «исчерпывающего тестирования» — проверки всех возможных путей выполнения кода со всеми возможными входными данными. Однако очень скоро было выяснено, что исчерпывающее тестирование невозможно, т.к. количество возможных путей и входных данных очень велико, а также при таком подходе сложно найти проблемы в документации.
В 70-х годах фактически родились две фундаментальные идеи тестирования: тестирование сначала рассматривалось как процесс доказательства работоспособности программы в некоторых заданных условиях, а затем — строго наоборот: как процесс доказательства неработоспособности программы в некоторых заданных условиях. Это внутреннее противоречие не только не исчезло со временем, но и в наши дни многими авторами совершенно справедливо отмечается как две взаимодополняющие цели тестирования. Отметим, что «процесс доказательства неработоспособности программы» ценится чуть больше, т.к. не позволяет закрывать глаза на обнаруженные проблемы.
Итак, ещё раз самое важное, что тестирование «приобрело» в 70-е годы:
тестирование позволяет удостовериться, что программа соответствует требованиям;
тестирование позволяет определить условия, при которых программа ведёт себя некорректно.
В 80-х годах произошло ключевое изменение места тестирования в разработке ПО: вместо одной из финальных стадий создания проекта тестирование стало применяться на протяжении всего цикла разработки, что позволило в очень многих случаях не только быстро обнаруживать и устранять проблемы, но даже предсказывать и предотвращать их появление. В этот же период времени отмечено бурное развитие и формализация методологий тестирования и появление первых элементарных попыток автоматизировать тестирование.
В 90-х годах произошёл переход от тестирования как такового к более всеобъемлющему процессу, который называется «обеспечение качества» охватывает весь цикл разработки ПО и затрагивает процессы планирования, проектирования, создания и выполнения тест-кейсов, поддержку имеющихся тест-кейсов и тестовых окружений. Тестирование вышло на качественно новый уровень, который естественным образом привёл к дальнейшему развитию методологий, появлению достаточно мощных инструментов управления процессом тестирования и инструментальных средств автоматизации тестирования, уже вполне похожих на своих нынешних потомков.
В нулевые годы нынешнего века развитие тестирования продолжалось в контексте поиска всё новых и новых путей, методологий, техник и подходов к обеспечению качества. Серьёзное влияние на понимание тестирования оказало появление гибких методологий разработки и таких подходов, как «разработка под управлением тестированием ». Автоматизация тестирования уже воспринималась как обычная неотъемлемая часть большинства проектов, а также стали популярны идеи о том, что во главу процесса тестирования следует ставить не соответствие программы требованиям, а её способность предоставить конечному пользователю возможность эффективно решать свои задачи.
О современном этапе развития тестирования мы будем говорить на протяжении всего остального материала. Если же отметить вкратце основные характеристики, то получится примерно такой список: гибкие методологии и гибкое тестирование, глубокая интеграция с процессом разработки, широкое использование автоматизации, колоссальный набор технологий и инструментальных средств, кроссфункциональность команды (когда тестировщик и программист во многом могут выполнять работу друг друга).
-
Учебная задача
Тестирование - очень важный и трудоемкий этап процесса разработки программного обеспечения, так как он позволяет выявить подавляющее большинство ошибок, допущенных при составлении программ.
Поэтому первый вопрос, на который надо ответить, будет звучать так: в каком случае в программе есть ошибка?
| Программа содержит ошибку, если она ведет себя неразумно с точки зрения пользователя. |
Как определить разумность поведения программы?
Во-первых, естественно, программа должна быть верна синтаксически, т. е. при ее трансляции не должно быть ошибок. Текст, содержащий синтаксические ошибки, вообще не имеет права называться программой. Такая «программа» вообще никак себя не ведет.
Во-вторых, программа должна правильно решать поставленную перед ней задачу. То есть при вводе в нее корректных исходных данных она должна выдавать правильный результат. Какой именно результат считать правильным, надо уточнить у заказчика. Например, если вам заказывают программу для вычисления квадратного корня, то должна ли она выдавать оба корня (положительный и отрицательный) или только арифметический? Корень из нуля — это _0 или просто 0? Какова требуемая точность? Она всегда должна быть одна и та же или может меняться? Если меняться, то каким образом и по чьей инициативе? Надо ли выявлять периодические дроби? Как программа должна реагировать на отрицательное подкоренное выражение? А на предложение извлечь корень из a2? Вы можете предложить свои ответы на все эти вопросы. Но в данном случае важно не то, что думаете по этому поводу вы, а то, что думает по этому поводу ваш заказчик. Ваша задача — выявить и сформулировать все эти вопросы, а не придумывать на них свои собственные ответы. Для выявления и формулировки вопросов полезно не хвататься за клавиатуру сразу же, как только вам дадут задание на разработку программы, а сначала немножко подумать. Все эти вопросы все равно возникнут в процессе разработки программы. Но если их не оговорить заранее, ответы на них вы будете придумывать сами, и нет никакой гарантии, что они покажутся заказчику разумными.
В-третьих, программа не должна делать ничего лишнего. При вычислении квадратного корня не надо менять настройки операционной системы и исполнять вашу любимую мелодию.
В-четвертых, результат должен быть получен через разумное время при разумных затратах других ресурсов. Если программа при вычислении квадратного корня из числа выдает десятистраничную распечатку, в ней, наверное, что-то не так.
И наконец, в-пятых, программа должна разумно реагировать на ввод некорректных входных данных и на непредусмотренные заранее ситуации. Например, если программа вычисляет квадратный корень, а пользователь вместо подкоренного выражения ввел свою фамилию, то программа должна распознать, что введенная строка — не число1, и сообщить об этом пользователю на его родном языке, а не заканчивать работу аварийно. Если вы разработали программу для управления аэропортом, рассчитанную на то, что в небе могут быть одновременно не более 20 самолетов, а в какой-то момент их оказалось 21, ваша программа должна отреагировать на это неким разумным
образом. Например, сообщить о чрезвычайной ситуации диспетчеру и экипажу и передать этот борт диспетчеру для ручного ведения. Вариант, когда появление 21-го самолета приведет к тому, что программа потеряет один из ранее ведомых самолетов или просто отключится, совершенно недопустим.
Процесс разработки программного обеспечения предполагает три стадии тестирования:
автономное тестирование компонентов программного обеспечения;
комплексное тестирование разрабатываемого программного обеспечения;
системное или оценочное тестирование на соответствие основным критериям качества.
Для повышения качества тестирования рекомендуется соблюдать следующие основные принципы:
предполагаемые результаты должны быть известны до тестирования;
следует избегать тестирования программы автором;
досконально изучать результаты каждого теста;
необходимо проверять работу программы на неверных данных;
вероятность наличия необнаруженных ошибок в части программы пропорциональна числу ошибок, уже обнаруженных в этой части.
Формирование набора тестов имеет большое значение, поскольку тестирование является одним из наиболее трудоемких этапов (от 30 до 60 % общей трудоемкости) создания программного продукта. Существуют два принципиально разных подхода к формированию тестовых наборов – структурный и функциональный. Структурный подход базируется на том, что известны алгоритмы работы программы. В основе структурного тестирования лежит концепция максимально полного тестирования всех маршрутов программы. Функциональный подход основывается на том, что алгоритм работы программного обеспечения не известен. Тесты строят, опираясь на функциональные спецификации. Программа рассматривается как «черный 4 ящик», и целью тестирования является выяснение обстоятельств, в которых поведение программы не соответствует требованиям. Опытные отладчики обнаруживают ошибки путём сравнения шаблонов тестовых выходных данных с выходными данными тестируемых систем. Чтобы определить местоположение ошибки, необходимы знания о типах ошибок,
шаблонах выходных данных, языке и процессе программирования. Очень важны знания о процессе разработке программного обеспечения.
Качество программного продукта характеризуется набором свойств, определяющих, насколько продукт «хорош» с точки зрения заинтересованных сторон, таких как заказчик продукта, спонсор, конечный пользователь, разработчики и тестировщики продукта, инженеры поддержки, сотрудники отделов маркетинга, обучения и продаж. Каждый из участников может иметь различное представление о продукте и том, насколько он хорош или плох, то есть о том, насколько высоко качество продукта. Таким образом, постановка задачи обеспечения качества продукта выливается в задачу определения заинтересованных лиц, их критериев качества и затем нахождения оптимального решения, удовлетворяющего этим критериям. Тестирование является одним из наиболее устоявшихся способов обеспечения качества разработки программного обеспечения и входит в набор эффективных средств современной системы обеспечения качества программного продукта. С технической точки зрения тестирование заключается в выполнении приложения на некотором множестве исходных данных и сверке получаемых результатов с заранее известными (эталонными) с целью установить соответствие различных свойств и характеристик приложения заказанным свойствам. Отладка(debug, debugging) - процесс поиска, локализации и исправления ошибок в программе.
Термин «отладка» в отечественной литературе используется двояко: для обозначения активности по поиску ошибок (собственно тестирование), по нахождению причин их появления и исправлению, или активности по локализации и исправлению ошибок.
Тестирование - это процесс выполнения ПО системы или компонента в условиях анализа или записи получаемых результатов с целью проверки (оценки) некоторых свойств тестируемого объекта. Тестирование - это процесс анализа пункта требований к ПО с целью фиксации различий между существующим состоянием ПО и требуемым (что свидетельствует о проявлении ошибки) при экспериментальной проверке соответствующего пункта требований.
Тестирование - это контролируемое выполнение программы на конечном множестве тестовых данных и анализ результатов этого выполнения для поиска ошибок. Целью проектирования тестовых вариантов является систематическое обнаружение различных классов ошибок при минимальных затратах времени и стоимости.
