Тестирование. план_конспект_лекции_тестирование. Лекции 1 Дисциплина мдк. 05. 03 Тестирование информационных систем Тема 3 Отладка и тестирование информационных систем Занятие 1 Организация
 Скачать 79 Kb.
|
|
ПЛАН ЛЕКЦИИ №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) - процесс поиска, локализации и исправления ошибок в программе. Термин «отладка» в отечественной литературе используется двояко: для обозначения активности по поиску ошибок (собственно тестирование), по нахождению причин их появления и исправлению, или активности по локализации и исправлению ошибок. Тестирование - это процесс выполнения ПО системы или компонента в условиях анализа или записи получаемых результатов с целью проверки (оценки) некоторых свойств тестируемого объекта. Тестирование - это процесс анализа пункта требований к ПО с целью фиксации различий между существующим состоянием ПО и требуемым (что свидетельствует о проявлении ошибки) при экспериментальной проверке соответствующего пункта требований. Тестирование - это контролируемое выполнение программы на конечном множестве тестовых данных и анализ результатов этого выполнения для поиска ошибок. Целью проектирования тестовых вариантов является систематическое обнаружение различных классов ошибок при минимальных затратах времени и стоимости. Тестирование обеспечивает: Обнаружение ошибок. Демонстрацию соответствия функций программы ее назначению. Демонстрацию реализации требований к характеристикам программы. Отображение надежности как индикатора качества программы. Тестирование не может показать отсутствие дефектов (оно может показывать только присутствие дефектов). Важно помнить это утверждение при проведении тестирования. Тестирование - важная часть любой программы контроля качества, а зачастую и единственная. Это печально, так как разнообразные методики совместной разработки позволяют находить больше ошибок, чем тестирование, и в то же время обходятся более чем вдвое дешевле в расчете на одну обнаруженную ошибку. Каждый из отдельных этапов тестирования (блочное тестирование, тестирование компонентов и интеграционное тестирование) обычно позволяют найти менее 50% ошибок. Комбинация этапов тестирования часто приводит к обнаружению менее 60% ошибок. . Учебная Задача Тестирование — это выполнение программы с целью обнаружения факта наличия в программе ошибки. Отладка — определение места ошибки и внесение исправлений в программу. Качество программного обеспечения (Software Quality) - это совокупность характеристик программного обеспечения, относящихся к его способности удовлетворять установленные и предполагаемые потребности. Обеспечение качества (Quality Assurance - QA) - это совокупность мероприятий, охватывающих все технологические этапы разработки, выпуска и эксплуатации программного обеспечения (ПО) информационных систем, предпринимаемых на разных стадиях жизненного цикла ПО для обеспечения требуемого уровня качества выпускаемого продукта. Контроль качества (Quality Control - QC) - это совокупность действий, проводимых над продуктом в процессе разработки для получения информации о его актуальном состоянии в разрезах: "готовность продукта к выпуску", "соответствие зафиксированным требованиям", "соответствие заявленному уровню качества продукта". Тестирование программного обеспечения (Software Testing) - это одна из техник контроля качества, включающая в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis). Верификация (verification) - это процесс оценки системы или её компонентов с целью определения, удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа. Т.е. выполняются ли наши цели, сроки, задачи по разработке проекта, которые были определены в начале текущей фазы. Валидация (validation) - это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе. План Тестирования (Test Plan) - это документ, который описывает весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения. Тест дизайн (Test Design) - это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы), в соответствии с определенными ранее критериями качества и целями тестирования. Тестовый случай (Test Case) - это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части. Баг/Дефект Репорт (Bug Report) - это документ, описывающий ситуацию или последовательность действий, приведшую к некорректной работе объекта тестирования с указанием причин и ожидаемого результата. Тестовое Покрытие (Test Coverage) - это одна из метрик оценки качества тестирования, представляющая из себя плотность покрытия тестами требований либо исполняемого кода. Детализация Тест-Кейсов (Test Case Specification) - это уровень детализации описания тестовых шагов и требуемого результата, при котором обеспечивается разумное соотношение времени прохождения к тестовому покрытию. Время Прохождения Тест Кейса(Test Case Pass Time) - это время от начала прохождения шагов тест-кейса до получения результата теста. Учебная задача В зависимости от потребностей проекта команда может включать участников с различными ролями. При этом на практике часто бывает, что один человек одновременно выполняет несколько ролей, если имеет необходимые навыки и знания для исполнения обязанностей. Аккаунт-менеджер - менеджер по работе с клиентами, специалист, который работает с клиентами компании и обеспечивает их лояльность. Аккаунт-менеджер обеспечивает выполнение всех необходимых клиенту задач, находит к каждому заказчику индивидуальный подход, поддерживает с ним хорошие отношения (даже после того, как все заказы уже выполнены), предлагает ему новые услуги и продукты. Иными словами, профессия аккаунт-менеджера обязывает ее представителя сделать все возможное, чтобы клиент был счастлив, работал с компанией всегда и всем ее рекомендовал. Менеджер проекта (Project manager, руководитель проекта, проектменеджер; сокращенно - PM, ПМ, РП) - лицо, ответственное за управление проектом. Менеджер проекта несет ответственность за достижение целей проекта в рамках бюджета, в срок и с заданным уровнем качества. Системный аналитик (аналитик) является “мостиком” между заказчиком и членами команды. Переводит пожелания заказчика в формат точно описанных технических заданий. Системный архитектор (архитектор) проектирует разрабатываемую систему на самом верхнем уровне и принимает ключевые решения по поводу технологий и методологий разработки. Активно занимается исследованиями и экспериментами, рисует многочисленные диаграммы и документирует архитектурные решения. Программист (разработчик) пишет код на языках программирования, т.е. непосредственно кодирует логику работы программы. Также является ее первым пользователем и тестировщиком. Непосредственно отвечает за то, что программа работает и работает правильно (в соответствии с техническим заданием). Ведущий программист (технический лидер, техлид) - программист, который с технической точки зрения принимает решения о формате реализации функционала и координирует работу команды разработчиков. QA-специалист - специалист, который обеспечивает качество продукта (тестирует, контролирует и управляет качеством продукта). SDET-специалист (контроль качества, автоматизация тестирования) - специалист, который проверяет и отвечает за качество продукта. Пишет код для автоматизации процесса тестирования на разных языках программирования. Помогает команде разработки с точки зрения технических вопросов, вопросов архитектуры и построения приложения QA lead (ведущий специалист по управлению и контролю качества) - QA-специалист, который руководит командой тестирования. Тимлид — лидер команды, обеспечивающий достижение проектных целей посредством организации работы команды, состоящей из сотрудников различных направлений компании, а также отвечающий за развитие участников команды, построение коммуникаций (как внутри, так и извне), дисциплину и управление составом команды. Домашнее задание: Повторить материалы лекции Подготовиться к устному опросу |