Тестирование ПО. Тестирование. Реферат актуальность. Основной всплеск интереса к теме тестирования пришёлся на 90е годы и начался в сша. Бурное развитие систем автоматизированной разработки
 Скачать 2.21 Mb.
|
|
ОПФ Организационно-правовая форма ОВД Основной вид деятельности GUI Разновидность пользовательского интерфейса, в котором элементы интерфейса (меню, кнопки, значки, списки и т. п.), представленные пользователю на дисплее, исполнены в виде графических изображений ИС Информационная система ИТ Информационные технологии 10 ВВЕДЕНИЕ Основной всплеск интереса к теме тестирования пришёлся на 90-е годы и начался в США. Бурное развитие систем автоматизированной разработки ПО (CASE-средств) и сетевых технологий привело к росту рынка производства ПО и к пересмотру вопросов обеспечения качества и надёжности разрабатываемых программ. Резко усилившаяся конкуренция между производителями ПО потребовала особого внимания к качеству создаваемых продуктов, т.к. теперь у потребителя был выбор: многие фирмы предлагали свои продукты и услуги по достаточно приемлемым ценам, а потому можно было обратиться к тем, кто разработает программу не только быстро и дёшево, но и качественно. Ситуация осложнилась тем фактом, что в настоящее время компьютеризации подвержены практически все области человеческой жизни. И вопрос о качестве ПО начинает приобретать особую важность: сегодня это уже не только комфорт от работы в той или иной программе, сегодня ПО управляет оборудованием в больницах, диспетчерскими системами в аэропортах, атомными реакторами, космическими кораблями и т.д. Осознав тот факт, что обеспечение высокого качества разрабатываемого ПО – это реальный путь «обойти» конкурентов, многие компании во всём мире вкладывают всё больше средств в обеспечение качества своих продуктов, создавая собственные группы и отделы, занимающиеся тестированием, или передавая тестирование своих продуктов сторонним организациям. Наиболее крупные компании, заботящиеся о своей репутации и желающие пройти сертификацию на высокий уровень CMMI (Capability Maturity Model Integration) создают свои собственные системы управления качеством (Quality Management System), направленные на постоянное совершенствование производственных процессов и постоянное повышение качества ПО. Сегодня тестирование стало обязательной частью процесса производства ПО. Оно направлено на обнаружение и устранение как можно большего числа ошибок. Следствием такой деятельности является повышение качества ПО по всем его характеристикам. Существующие на сегодняшний день методы тестирования программного обеспечения не позволяют однозначно и полностью устранить все дефекты и ошибки и установить корректность функционирования программного продукта. Поэтому, все существующие методы тестирования действуют в рамках формального процесса проверки исследуемого или разрабатываемого программного продукта. Такой процесс формальной проверки или верификации может доказать, что дефекты отсутствуют, с точки зрения используемого метода. То есть нет никакой возможности точно 11 установить или гарантировать отсутствие дефектов в программном продукте с учётом человеческого фактора, присутствующего на всех этапах жизненного цикла программного обеспечения. Существует множество подходов к решению задачи тестирования и верификации программного обеспечения, но эффективное тестирование сложных программных продуктов — это процесс в высшей степени творческий, не сводящийся к следованию строгим и чётким процедурам или созданию таковых. Конечной целью любого процесса тестирования является обеспечение такого ёмкого (совокупного) понятия как Качество, с учётом всех или наиболее критичных для данного конкретного случая составляющих. Тестирование программного обеспечения — попытка определить, выполняет ли программа то, что от неё ожидают. Как правило, никакое тестирование не может дать абсолютной гарантии работоспособности программы в будущем. Задачи тестирования программного обеспечения – снизить стоимость разработки путем раннего обнаружения дефектов. 12 1 ОПРЕДЕЛЕНИЕ ТЕСТИРОВАНИЯ В соответствие с IEEE Std 829-1983 Тестирование — это процесс анализа ПО, направленный на выявление отличий между его реально существующими и требуемыми свойствами (дефект) и на оценку свойств ПО [5]. По ГОСТ Р ИСО МЭК 12207-99 в жизненном цикле ПО определены среди прочих вспомогательные процессы верификации, аттестации, совместного анализа и аудита. Процесс верификации является процессом определения того, что программные продукты функционируют в полном соответствии с требованиями или условиями, реализованными в предшествующих работах. Данный процесс может включать анализ, проверку и испытание (тестирование). Процесс аттестации является процессом определения полноты соответствия установленных требований, созданной системы или программного продукта их функциональному назначению. Процесс совместного анализа является процессом оценки состояний и, при необходимости, результатов работ (продуктов) по проекту. Процесс аудита является процессом определения соответствия требованиям, планам и условиям договора. В сумме эти процессы и составляют то, что обычно называют тестированием. Тестирование основывается на тестовых процедурах с конкретными входными данными, начальными условиями и ожидаемым результатом, разработанными для определенной цели, такой, как проверка отдельной программы или верификация соответствия на определенное требование. Тестовые процедуры могут проверять различные аспекты функционирования программы — от правильной работы отдельной функции до адекватного выполнения бизнес-требований. При выполнении проекта необходимо учитывать, в соответствии с какими стандартами и требованиями будет проводиться тестирование продукта. Какие инструментальные средства будут (если будут) использоваться для поиска и для документирования найденных дефектов. Если помнить о тестировании с самого начала выполнения проекта, тестирование разрабатываемого продукта не доставит неприятных неожиданностей. А значит и качество продукта, скорее всего, будет достаточно высоким. 13 2 ЖИЗНЕННЫЙ ЦИКЛ ПРОДУКТА И ТЕСТИРОВАНИЯ Все чаще используются итеративные процессы разработки ПО, в частности, технологияRUP — Rational Unified Process. На рисунке 2.1 можно увидеть жизненный цикл продукта по RUP. При использовании такого подхода тестирование перестает быть процессом «на отшибе», который запускается после того, как программисты написали весь необходимый код. Работа над тестами начинается с самого начального этапа выявления требований к будущему продукту и тесно интегрируется с текущими задачами. И это предъявляет новые требования к тестировщикам. Их роль не сводится просто к выявлению ошибок как можно полнее и как можно раньше. Они должны участвовать в общем процессе выявления и устранения наиболее существенных рисков проекта. Для этого на каждую итерацию определяется цель тестирования и методы ее достижения. А в конце каждой итерации определяется, насколько эта цель достигнута, нужны ли дополнительные испытания, и не нужно ли изменить принципы и инструменты проведения тестов. В свою очередь, каждый обнаруженный дефект должен пройти через свой собственный жизненный цикл. Рисунок 2.1 - Жизненный цикл продукта по RUP Тестирование обычно проводится циклами, каждый из которых имеет конкретный список задач и целей. Цикл тестирования может совпадать с итерацией или соответствовать ее определенной части. Как правило, цикл тестирования проводится для конкретной сборки системы. Жизненный цикл программного продукта, который изображен на рисунке 2.2 состоит из серии относительно коротких итераций. Итерация — это законченный цикл разработки, приводящий к выпуску конечного продукта или некоторой его сокращенной версии, которая расширяется от итерации к итерации, чтобы, в конце концов, стать законченной системой. Каждая итерация включает, как правило, задачи планирования работ, анализа, проектирования, реализации, тестирования и оценки достигнутых результатов. Однако соотношения этих задач может существенно меняться. В соответствие с соотношением различных 14 задач в итерации они группируются в фазы. В первой фазе — Начало — основное внимание уделяется задачам анализа. В итерациях второй фазы — Разработка — основное внимание уделяется проектированию и опробованию ключевых проектных решений. В третьей фазе — Построение — наиболее велика доля задач разработки и тестирования. А в последней фазе — Передача — решаются в наибольшей мере задачи тестирования и передачи системы Заказчику. Рисунок 2.2 - Итерации жизненного цикла программного продукта Каждая фаза имеет свои специфические цели в жизненном цикле продукта и считается выполненной, когда эти цели достигнуты. Все итерации, кроме, итераций фазы Начало, завершаются созданием функционирующей версии разрабатываемой системы [6]. 15 3 МЕСТО ТЕСТИРОВАНИЯ В ПРОЦЕССЕ РАЗРАБОТКИ ПО Структура фирмы — разработчика программного обеспечения отражает этапы жизненного цикла программного средства. То или иное подразделение обеспечивает выполнение работ по одному или нескольким этапам жизненного цикла программного обеспечения. Аналитический отдел. Взадачи аналитического отдела входят: определение концепций и функционального направления развития программного продукта; проведение предпроектного обследования; определение функциональных возможностей системы; определение (совместно с разработчиками) технических требований к системе; описание бизнес-процессов предметной области в терминах, понятных разработчикам (постановки задач и спецификации на разработку); написание постановок задач и спецификаций на доработку программного средства при изменении законодательства, требований клиентов, расширении функциональных возможностей продукта; контроль процесса реализации новых возможностей в программных продуктах компании. Отдел документации. Часто данный отдел не выделяется в обособленную структуру, он может входить, например, в состав аналитического отдела. В задачи отдела входят написание технической документации для конечного пользователя, отслеживание изменений в программном средстве и актуализация в документации. Отдел разработки. Это ключевой отдел для фирмы. Если без остальных отделов зачастую можно обойтись, то без отдела разработки нельзя. В его задачи входят: определение (совместно с аналитиками) технических требований к системе; реализация базовых функций программного средства; расширение перечня функций программного средства (реализация доработок); исправление найденных ошибок; адаптация программного продукта для функционирования в других условиях (переход на новую СУБД, новый язык программирования и пр.); оптимизация программного продукта (увеличение быстродействия, надежности и пр.). Отдел технической поддержки (горячая линия). Осуществляет консультации пользователей по вопросам, связанным с установкой и эксплуатацией программного средства по различным каналам связи (телефон, почта, электронная почта). 16 Отдел тестирования. В задачи отдела входят: комплексный контроль качества; подготовка тестовой документации (планы тестирования и пр.); обнаружение и локализация ошибок в функционировании программных продуктов; фиксирование и отслеживание ошибок в функционировании программных средств; проверка соответствия документации программного продукта стандартам и реально реализованным функциям; участие в разработке и внедрении системы качества; автоматизация тестирования; оценка производительности разрабатываемых программных средств на различных программно-аппаратных платформах и их специфических конфигурациях. В некоторых компаниях на отдел тестирования возлагаются сборка и выпуск программного обеспечения (в некоторых компаниях этим занимается отдел разработки) [7]. Все отделы компании взаимодействуют между собой, данные взаимодействия упорядочены между собой и представляют производственные технологические процессы. Технологические про- цессы, как правило, регламентированы внутренними документами или внутрикорпоративными стандартами; в совокупности представляют собой технологический цикл производства про- граммного средства. Типичных технологических цепочек внутри компании — разработчика программного обеспечения большое множество. В качестве примера рассмотрим схему взаимодействия отдела тестирования программного обеспечения с другими отделами при обнаружении ошибки во время функционирования программного обеспечения у пользователя. 17 4 МЕТОДОЛОГИЯ ТЕСТИРОВАНИЯ В терминологии профессионалов тестирования (программного и некоторого аппаратного обеспечения), фразы «тестирование белого ящика» и «тестирование чёрного ящика» относятся к тому, имеет ли разработчик тестов доступ к исходному коду тестируемого программного обеспечения, или же тестирование выполняется через пользовательский интерфейс либо прикладной программный интерфейс, предоставленный тестируемым модулем. При тестировании методом белого ящика (white-box testing, также говорят — прозрачного ящика, оно же структурное тестирование), разработчик теста имеет доступ к исходному коду программ и может писать код, который связан с библиотеками тестируемого программного обеспечения. На рисунке 4.1 можно увидеть схематическое изображение данного метода. Рисунок 4.1 - Метод белого ящика Тесты создаются на основе знаний о структуре самой системы и о том, как она работает. Критерии полноты основаны на проценте элементов кода, которые отработали в ходе выполнения тестов. Для оценки степени соответствия требованиям могут привлекаться дополнительные знания о связи требований с определенными ограничениями на значения внутренних данных системы (например, на значения параметров вызовов, результатов и локальных переменных). При тестировании методом чёрного ящика, схему которого можно увидеть на рисунке 4.2, тестировщик имеет доступ к программному обеспечению только через те же интерфейсы, что и заказчик или пользователь, либо через внешние интерфейсы, позволяющие другому компьютеру либо другому процессу подключиться к системе для тестирования. Рисунок 4.2 - Метод черного ящика Тестирование черного ящика, нацеленное на проверку требований. Тесты для него и критерий полноты тестирования строятся на основе требований и ограничений, четко зафиксированных в спецификациях, стандартах, внутренних нормативных документах. Часто такое тестирование называется тестированием на соответствие (conformance testing). Частным случаем его является функциональное тестирование — тесты для него, а также используемые критерии полноты проведенного тестирования определяют на основе требований к функциональности. 18 Помимо методов тестирования «белый ящик» и «черный ящик» различают тестирование методом «серого ящика», схема которого изображена на рисунке 4.3. Рисунок 4.3 - Метод серого ящика В данном случае у человека, который разрабатывает тест кейсы, есть некоторая информация о внутренней структуре приложения или о деталях реализации. Данный метод применяется в последнее время чаще предыдущих. 19 5 УРОВНИ ТЕСТИРОВАНИЯ Существует классификация видов тестирования, которая основана на том уровне детализации работ проекта, на который оно нацелено. На рисунке 5.1 изображены уровни тестирования. Эти же разновидности тестирования можно связать с фазой жизненного цикла, на которой они выполняются. Модульное тестирование (Unit-testing) — уровень тестирования, на котором тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция. На этом уровне применяются методы «белого ящика». В современных проектах модульное тестирование («юнит-тестинг») осуществляется разработчиками [9]. Модульное тестирование предназначено для проверки правильности отдельных модулей, вне зависимости от их окружения. При этом проверяется, что если модуль получает на вход данные, удовлетворяющие определенным критериям корректности, то и результаты его корректны. Для описания критериев корректности входных и выходных данных часто используют программные контракты — предусловия, описывающие для каждой операции, на каких входных данных она предназначена работать, постусловия, описывающие для каждой операции, как должны соотноситься входные данные с возвращаемыми ею результатами, и инварианты, определяющие критерии целостности внутренних данных модуля. Основной недостаток модульного тестирования состоит в том, что проводить его можно, только когда проверяемый элемент программы уже разработан. Снизить влияние этого ограничения можно, подготавливая тесты (а это — наиболее трудоемкая часть тестирования) на основе требований заранее, когда исходного кода еще нет. Модульное тестирование является важной составной частью отладочного тестирования, выполняемого разработчиками для отладки написанного ими кода. Интеграционное тестирование (Integration testing) – уровень тестирования, на котором отдельные программные модули объединяются и тестируются в группе. Обычно интеграционное тестирование проводится после модульного тестирования (юнит-тесты для модулей должны быть выполнены и найденные ошибки исправлены) [9]. Интеграционное тестирование в качестве входных данных использует модули, над которыми было проведено модульное тестирование, группирует их в более крупные множества, выполняет тесты, определённые в плане тестирования для этих множеств, и представляет их в качестве выходных данных и входных для последующего системного тестирования. При этом проверяется, что в ходе совместной работы модули обмениваются данными и вызовами операций, не нарушая взаимных ограничений на такое взаимодействие, например, предусловий вызываемых операций. 20 Интеграционное тестирование выполняется разработчиками используется при отладке, но на более позднем этапе разработки. Системное тестирование (System testing) - это тестирование программного обеспечения, выполняемое на полной, интегрированной системе, с целью проверки соответствия системы исходным требованиям. Системное тестирование относится к методам тестирования «чёрного ящика», и, тем самым, не требует знаний о внутреннем устройстве системы. Системное тестирование выполняется через внешние интерфейсы программного обеспечения и тесно связано с тестированием пользовательского интерфейса (или через пользовательский интерфейс), проводимым при помощи имитации действий пользователей над элементами этого интерфейса. Частными случаями этого вида тестирования являются тестирование графического пользовательского интерфейса (Graphical User Interface, GUI) и пользовательского интерфейса Web-приложений (WebUI). Системное тестирование выполняется инженерами по тестированию. |