Полный текст:
В данной работе описывается процесс разработки программного обеспечения в той же последовательности, в какой он проходит и в жизни. Параллельно описывается и технологии тестирования, соответствующие каждой стадии разработки. В реферате особое внимание будет уделено следующим вопросам:
• Стадии разработки
• Стадии планирования
• Тестирование на этапе планирования
• Стадии проектирования
• Тестирование на этапе проектирования
• Тестирование "стеклянного ящика" на стадии кодирования
• Регрессионное тестирование
• Тестирование "черного ящика"
• Сопровождение
Серьезные программные продукты редко разрабатываются специалистами-одиночками: обычно этим занимаются группы людей, иногда довольно многочисленные. В такой группе, называемой командой разработчиков, у каждого сотрудника своя роль. В работах Канера С., Фолка Д., Нгуена К. Е. [1] рассматривается стандартный набор функций, выполняемых членами команды разработчиков, и предполагается, что каждая роль принадлежит отдельному сотруднику. На практике в большинстве маленьких компаний сотрудники часто выполняют по нескольку функций.
• Руководитель проекта отвечает за качество программного продукта, планирование работ и составление бюджета разработки.
• Проектировщиков продукта может быть несколько и среди них следующие.
Разработчик архитектуры определяет общую внутреннюю структуру кода и данных, принципы обмена данными между связанными программами и их совместного использования, а также стратегию разработки совместно и повторно используемых модулей. Разработчик архитектуры может также составлять план тестирования "стеклянного ящика" на самом верхнем уровне, анализировать технические обзоры всех спецификаций и разрабатывать тесты для приемки продукта (проверяющие соответствие кода техническим требованиям).
Специалист по анализу предметной области должен понимать, чего хотят пользователи и как это выразить в терминах, понятных программисту или другому разработчику.
Специалист по эргономике, должен иметь психологическое образование, и знать, как спроектировать программу, чтобы она была полезной и удобной, и как тестировать продукт (или его прототип) на соответствие этим качествам.
Программист пользовательского интерфейса специализируется на создании пользовательского интерфейса программ. Обычно это профессиональный программист, который разбирается в оконной архитектуре и компьютерной графике.
Пользовательский интерфейс — это часть программы, предоставляющая пользователю информацию (в виде графики, текста, звука, в печатном виде и т.п.) и получающая от него ответные данные (через клавиатуру, мышь и другие устройства ввода), которые затем передаются для обработки основной программе. Эту часть программы часто называют слоем представления и получения данных.
Ведущие программисты часто занимаются разработкой той части спецификации (технического задания), которая относится к внутренней структуре продукта.
Менеджер по маркетингу отвечает за соответствие продукта долгосрочной стратегии и имиджу своей компании, а также за маркетинговую деятельность, продолжающуюся после выпуска продукта (рекламу, выпуск и распространение новых версий, обучение продавцов и дилеров). В большинстве компаний менеджер по маркетингу отвечает также и за рентабельность продукта. Он определяет требования рынка, а также те функции и возможности, от которых зависит его конкурентоспособность.
Представитель группы технической поддержки - это член или руководитель группы, непосредственно контактирующей с пользователями. Сотрудники этой группы анализируют жалобы пользователей, отвечают на их вопросы и предоставляют им необходимую информацию.
• Технические писатели — это члены группы документирования, разрабатывающие руководство пользователя и интерактивную справку.
• Тестировщики также считаются членами команды разработчиков.
• В разработке специфических проектов принимают участие и другие специалисты: по компьютерной графике, надежности, защите, аппаратному обеспечению, а также юристы, бухгалтера и т.д.
Познакомившись с основными исполнителями, необходимо перейти к обзору самого процесса.
Обзор стадий разработки
Согласно Канеру С., Фолку Д., Нгуену К. Е. [1] процесс разработки программного продукта можно разделить на несколько стадий. Сначала его придумывают, затем создают, анализируют результат, устраняют его недостатки, затем продукт попадает к пользователям, которые его эксплуатируют, а сотрудники отдела маркетинга компании анализируют пользовательский спрос. Когда продукт займет свое место на рынке, разработчики придумывают, как его усовершенствовать, вносят изменения и т.д. Могут быть выпущены десятки новых версий, после чего продукт, наконец, устареет и будет заменен принципиально новым. Весь путь продукта, начиная от появления у авторов самой идеи и заканчивая его заменой, называется жизненный цикл
Пять основных этапов жизненного цикла программного продукта[1].
• Планирование
• Проектирование
• Кодирование и написание документации
• Тестирование и исправление недостатков
• Сопровождение (после выпуска) и усовершенствование
В книге Мартина и Мак-Клера [2] приведены цифры об относительной стоимости каждой их этих стадий.
Стадии разработки Производственная стадия
Анализ требований 3% Промышленное производство
Спецификация 3% и сопровождение 67%
Проектирование 5%
Кодирование 7%
Тестирование 15%
По результатам исследований Мартина и Мак-Клера, сопровождение программного продукта после его выпуска обходится дороже всего. На втором месте по стоимости стоит тестирование — на него приходится 45% всей стоимости разработки. В процессе сопровождения продукта при исправлении ошибок и внесении усовершенствований значительная часть затрат тоже приходится на тестирование.
Продукт тестируют и исправляют практически на каждом этапе его жизненного цикла. При этом, чем дальше продвигается работа, тем быстрее растет стоимость тестирования.
- На этапе разработки технических требований стоимость внесения изменений в документацию относительно невысока. Но после написания кода ситуация резко меняется: любое изменение проектной документации влечет за собой затраты и на переработку кода, часто гораздо более значительную, чем может показаться при оценке количества изменений в спецификации.
• Когда программист сам находит свою ошибку и сам ее исправляет, это не влечет больших затрат. Такая ошибка никого не задерживает и не мешает ничьей работе.
• До выпуска программы ошибку исправить гораздо дешевле, чем после того, когда патч или новую версию приходится высылать каждому пользователю — и это еще в лучшем случае, так как может потребоваться и непосредственный выезд сотрудника компании к заказчику.
Рис.1 Стоимость поиска и исправления ошибок в программном обеспечение
В 1976 г. Боэм [3] опубликовал итоговые данные анализа затрат на тестирование программных продуктов, проведенного в компаниях IBM, GTE и TRW. Из них следует, что чем позднее обнаруживается ошибка, тем дороже обходится ее исправление. Как показано на (рис.1), стоимость исправления ошибок растет экспоненциально: легче всего это делать на стадии планирования, а по мере перехода к проектированию, кодированию, тестированию и сопровождению она значительно увеличивается.
Стадии планирования
В команде планирования программного продукта должны быть ведущие инженеры, персонал, отвечающий за маркетинг и продажи, и руководители проекта. Эта команда вырабатывает общие характеристики продукта. В результате ее работы на свет появляется всего несколько документов, определяющих дальнейшую разработку.
Определение целей
Планирование начинается с формирования общего видения продукта. Составляемый при этом документ не отличается детальностью. В нем может быть описан пользовательский интерфейс, требования к надежности программного продукта и его производительности. В этом же документе определяется предполагаемая стоимость продукта и затраты на его разработку. Он разрабатывается, прежде всего, для того, чтобы поставить перед командой разработчиков конкретную цель. При этом конечный результат может не соответствовать первоначальному описанию.
Анализ требований
Требования к программному продукту, вырабатываемые на этом этапе, должны быть выполнены обязательно. Они носят функциональный характер, а как реализовать их практически — это уже решают разработчики. Перечень требований может охватывать стоимость будущего продукта, его производительность, надежность, а также некоторые элементы пользовательского интерфейса. То, насколько подробно все это описывается, зависит от специфики разработки.
Определение функциональных характеристик программного продукта
Функциональные характеристики - перечень функций будущего программного продукта. Примером модели для разработки функциональных характеристик может быть документ IEEE Software Requirements Specification (руководство IEEE по определению требований к программному обеспечению, стандарт ANSI/IEEE 830-1984)[4].
Тестирование на этапе планирования
На этом этапе пока еще тестируются не программы — "тестируются" идеи. К их анализу привлекаются специалисты по маркетингу, руководители проекта, главные конструкторы и специалисты по анализу человеческого фактора.
Группа аналитиков читает черновики проектных документов. Затем она собирает информацию, которая может оказать помощь в их оценке и дальнейшем планировании. Для этого существует несколько стандартных способов: сравнительный анализ, дискуссионные группы и обследование объекта. Результаты каждой из этих процедур могут привести к значительному пересмотру существующих планов. При анализе и оценке требований к продукту и его функциональных характеристик специалисты, прежде всего, пытаются выяснить следующее.
• Адекватны ли эти требования? Действительно ли именно такой продукт компания хочет создать?
• Полны ли они? Не упущены ли какие-нибудь еще полезные или даже жизненно необходимые функции? Нельзя ли ослабить какие- либо из перечисленных требований?
• Совместимы ли требования между собой? Требования к продукту (и его функции) могут оказаться логически или психологически несовместимыми. Логическая несовместимость означает их противоречивость, а психологическая — концептуальные разногласия (разобравшись с одной из функций, пользователь может не понять другую).
• Выполнимы ли они? Не требуется ли для нормальной эксплуатации продукта более быстрое аппаратное обеспечение, больший объем памяти, более высокая пропускная способность, большее разрешение (и т.д.), чем указано в документации?
• Поддаются ли они тестированию? Насколько легко можно будет определить, соответствует ли инженерно-проектная документация требованиям к программному продукту.
Выяснив, что, прежде всего, интересует группу аналитиков, можно перейти к рассмотрению методов их работы.
Дискуссионные группы
Каждый продукт предназначается для определенного сегмента рынка. Целью данного метода анализа является определение ключевых требований этого сегмента. Дискуссия может осветить самые различные аспекты обсуждаемой проблемы. Аналитик может понять, чего пользователи хотят от данного типа продуктов, как они его используют, какие функции для них наиболее важны.
Обследование объекта
Каждый продукт предназначается для полной или частичной автоматизации выполнения некоторой задачи, возможно, очень сложной. Чтобы как можно четче представить себе эту задачу, аналитик выполняет обследование объекта автоматизации. Работа специалиста по обследованию является частью проектирования продукта и жизненно необходима для разработки, как его пользовательского интерфейса, так и внутренней структуры.
Хотя обследование объекта может быть выполнено и после определения требований к продукту, по его результатам эти требования могут быть сильно изменены.
Стадии проектирования
На этапе проектирования группа соответствующих специалистов решает, как будут реализованы запланированные возможности продукта. Они разрабатывают внешний дизайн программного продукта (то, каким будет продукт с точки зрения пользователя) и его внутреннюю структуру. Обе эти составляющие тесно взаимосвязаны и проектируются одновременно. Разрабатывая проект, специалисты опираются на требования к продукту. Если этого документа нет, если он неполон или постоянно меняется, им приходится планировать функции продукта самим.
Внешний дизайн
Описание внешнего дизайна программного продукта включает полное описание его пользовательского интерфейса, в частности, все экранные и печатные формы. В процессе разработки продукта его внешний дизайн может многократно изменяться, поскольку при кажущейся второстепенности именно эта часть системы имеет ключевое значение.
Внутренняя структура
Описание внутренней структуры программного продукта определяет набор будущих программных модулей (программную архитектуру), структуру, взаимосвязи и принципы хранения и обработки данных (организацию данных) и алгоритмы работы программы.
Проектирование программной архитектуры
Как правило, каждую задачу можно разбить на четкие подзадачи, которые, в свою очередь, тоже можно разбить на еще меньшие элементы и т.д. Такое разбиение, называемое декомпозицией, выполняется до тех пор, пока не будут выделены достаточно самостоятельные элементы, которые можно реализовать в виде отдельных программных модулей или процедур.
Обычно сложные программные продукты реализуются в виде системы — набора связанных между собой полноценных программ. Такие программы часто называют процессами, особенно если они работают параллельно. Хотя процессы могут работать и независимо, как правило, они взаимодействуют между собой. Например, они могут использовать одни и те же данные, или один из них может выполнять определенные задания по запросу другого. Документация, определяющая принципы и правила взаимодействия процессов системы, называется протоколом. В описании программной архитектуры системы определяются ее основные компоненты и использующиеся для их взаимодействия коммуникационные протоколы. Как и любые другие программы, процессы поддаются декомпозиции. Разбиение программы на модули называют модульной декомпозицией. Под модулем в данном случае понимают часть кода, которая может рассматриваться как независимое целое и имеет единственную точку входа. В терминологии программиста этому определению соответствуют процедуры и функции. Обычно модуль реализует либо одно конкретное задание, либо четко определенную группу заданий, для выполнения которых другие модули могут его вызывать. Вызывающий модуль передает вызываемому для обработки некоторые данные, а тот, в свою очередь, возвращает результат.
Проектирование организации данных
Разработчик структуры данных должен ответить на следующие принципиальные вопросы.
•Какие данные обрабатывает программа и какова их структура?
Обрабатываемые программой данные могут быть достаточно простыми, как переменные различных типов, а могут представлять собой массивы взаимосвязанной информации, которые тщательно анализируются и организуются в реляционные базы данных.
• Как осуществляется доступ к данным? Данные могут храниться в памяти или на постоянных носителях, и доступ к ним может осуществляться просто по имени или через определенные специально для этого написанные функции. Данные могут быть общедоступными, или же их чтение и изменение может строго регулироваться.
• Каковы принципы наименования данных? Применяются ли в данной разработке определенные соглашения об именах? Должны ли имена быть достаточно понятными, чтобы программист, который будет осуществлять сопровождение продукта в дальнейшем, мог по ним понять назначение данных.
• Как хранятся данные? Определенные данные будут храниться на постоянном носителе. В каком формате они будут храниться? Как к ним будет осуществляться доступ? Какие для этого понадобятся дополнительные программные средства?
Описание алгоритмов
Проектирование программного продукта не заканчивается описанием программных модулей и организации данных. Необходимо продумать, как именно будут реализовываться поставленные задачи. Обычно это делается программистами. Они выбирают оптимальные алгоритмы и описывают последовательность логических шагов, необходимых для выполнения каждой задачи.
Моделирование
Чтобы лучше представить себе будущий программный продукт, на этапе проектирования может быть разработан его прототип — программная модель всего продукта или его части. Прототип строится очень быстро и с минимумом затрат. Его очень легко менять, и он не выполняет никакой реальной работы.
Иногда моделирование выполняется не только для внешнего дизайна, но и для внутренней структуры системы. При нисходящем проектировании система разбивается на несколько самостоятельных процессов или модулей, они, в свою очередь, разбиваются на меньшие модули и т.д. В том же порядке выполняется и их кодирование: сначала пишутся модули более высокого уровня, а затем те, которые они вызывают. Однако бывает и так, что подпрограммы нижних уровней в значительной мере определяют всю разработку.
Как правило, прототип создается для оценки функциональности будущей системы и ее пользовательского интерфейса. Это полезная технология: когда люди получают возможность собственноручно поэкспериментировать с системой или ее прототипом, их требования значительно изменяются.
Тестирование на этапе проектирования
На этапе проектирования, как и на этапе планирования, кода, еще нет, поэтому и здесь тестируются только идеи. Однако на этот раз идеи гораздо лучше формализованы и описаны намного подробнее, чем в первоначальных планах. Анализируя проектные документы, специалисты должны составить очень четкое представление о работе будущей системы. Специалисты по тестированию могут и не участвовать в работе группы аналитиков, однако для планирования системы будущих тестов такое участие очень полезно. На этапе проектирования в центре внимания аналитиков должны быть следующие вопросы.
• Действительно ли проект хорош? Будет ли на его основе создан эффективный, компактный, хорошо тестируемый и легкий в сопровождении и модернизации продукт?
• Соответствует ли проект требованиям? Проект должен быть формализованным выражением требований, представленных в документации этапа планирования.
• Полон ли проект? Описывает ли проект все взаимосвязи между модулями и данными, передачу данных между модулями, условия работы каждого модуля и их реализацию.
• Достаточно ли он реалистичен? Удовлетворяют ли имеющиеся системные ресурсы (как аппаратные, так и программные) потребностям проекта? Сможет ли программный продукт работать достаточно быстро, достаточно быстро извлекать информацию из баз данных и ее обрабатывать? Удачно ли выбраны инструментальные средства разработчиков?
• Хорошо ли описана в проекте подсистема обработки ошибок? Все возможные условия возникновения ошибок должны быть самым тщательным образом продуманы и описаны в проекте. Необходимо правильно определить уровень, на котором обрабатывается каждая из ошибок, чтобы ее возникновение в одном модуле не вело к ошибкам в других.
Совещания аналитиков
Обычно целью совещаний, проводимых при анализе проектных документов, является не решение проблем, а прежде всего их выявление. В совещании должна участвовать небольшая группа сотрудников — около семи человек. В эту группу не должны входить авторы проекта. Аналитики заранее читают документы и на совещании критикуют их и задают друг другу вопросы. Во многих компаниях проект не считается завершенным, пока на него не будет составлена формальная рецензия. Таким образом, проект перерабатывается и снова анализируется до тех пор, пока он не будет одобрен группой аналитиков. Совещания этой группы могут быть трех типов: обзорные, инспекционные и рецензионные. Специальный персонал записывает все важные замечания и с помощью проекторов или другой аналогичной техники выводит их на большой экран, где они видны каждому участнику совещания. Любой, кому покажется, что записывающий упустил нечто важное, может попросить отобразить эту информацию. Обязательно должно фиксироваться каждое достигнутое соглашение. Записаны должны быть и все вопросы, которые остались открытыми до следующего совещания. Такая техника проведения совещаний исключительно способствует их продуктивности, особенно когда мнения аналитиков очень сильно расходятся. Некоторые группы тестирования специально обучают свой персонал ведению и протоколированию таких совещаний.
Анализ псевдокода
Псевдокод (структурированный русский) — это искусственный язык, комбинирующий конструкции реального языка программирования с описаниями действий на русском языке. Когда процесс проектирования подходит к разработке наиболее подробных документов, такая форма описания логики программы оказывается удобной и многие проектировщики ею пользуются. Если для описания программы пользоваться достаточно строго формализованной версией псевдокода, это описание можно будет проанализировать с помощью специальной программы — анализатора псевдокода. Эта программа выявит модули, которые ни разу не вызываются, составит список всех обращений к каждому модулю и выполнит другую полезную работу.
Тестирование "стеклянного ящика" на стадии кодирования
На этапе кодирования программист пишет программы и сам их тестирует. На данном этапе применяется технология с названием тестированием "стеклянного ящика" — иногда ее еще называют тестированием "белого ящика в противоположность классическому понятию "черного ящика".
При тестировании "черного ящика" программа рассматривается как объект, внутренняя структура которого неизвестна. Тестировщик вводит данные и анализирует результат, но, как именно работает программа, он не знает. Подбирая тесты, специалист ищет интересные с его точки зрения входные данные и условия, которые могут привести к нестандартным результатам.
При тестировании "стеклянного ящика" ситуация совершенно иная. Тестировщик (как правило, это программист) разрабатывает тесты, основываясь на знании исходного кода, к которому он имеет полный доступ. В результате он получает следующие преимущества.
• Направленность тестирования. Программист может тестировать программу по частям, разработать специальные тестовые подпрограмма, которые вызывают тестируемый модуль и передают ему интересующие программиста данные. Отдельный модуль гораздо легче протестировать именно как "стеклянный ящик".
• Полный охват кода. Программист всегда может определить, какие именно фрагменты кода работают в каждом тесте. Он видит, какие еще ветви кода остались непротестированными и может подобрать условия, в которых они будут выполнены.
• Управление потоком. Программист всегда знает, какая функция должна выполняться в программе следующей и каким должно быть ее текущее состояние. Чтобы выяснить, работает ли программа так, как он думает, программист может включить в нее отладочные команды, отображающие информацию о ходе ее выполнения, или воспользоваться для этого специальным программным средством, называемым отладчиком.
• Отслеживание целостности данных. Программисту известно, какая часть программы должна изменять каждый элемент данных. Отслеживая состояние данных (с помощью отладчика), он может выявить такие ошибки, как изменение данных не теми модулями, их неверная интерпретация или неудачная организация.
• Тестирование, определяемое выбранным алгоритмом. Для тестирования обработки данных, использующей очень сложные вычислительные алгоритмы, могут понадобиться специальные технологии. Тестировщику нужно точно знать, какие алгоритмы используются, и обратиться к специальной литературе.
Тестирование "стеклянного ящика" рассматривается как часть процесса программирования. Программисты выполняют эту работу постоянно, они тестируют каждый модуль после его написания, а затем еще раз после интеграции его в систему [1].
Однако необходимо заметить, что методу «черного ящика» посвящают большую часть времени все профессиональные тестировщики. Тестировщик "черного ящика" не изучает исходный код программы — он исследует ее извне, работая с ней так, как это будет делать пользователь. И так же, как исследование программы изнутри позволяет выявить проблемы и критические точки, которых не видно извне, так и тестировщик "черного ящика" выявляет ошибки и недостатки, которые программист упускает.
Структурное тестирование против функционального
Структурное тестирование является одним из видов тестирования "стеклянного ящика". Его главной идеей является правильный выбор тестируемого программного пути.
В противоположность ему функциональное тестирование относится к категории тестирования "черного ящика". Каждая функция программы тестируется путем ввода ее входных данных и анализа выходных. При этом внутренняя структура программы учитывается очень редко.
Как указывает Данн [5], хотя структурное тестирование и имеет под собой гораздо более мощную теоретическую основу, большинство тестировщиков предпочитают функциональное тестирование. Структурное тестирование лучше поддается математическому моделированию, но это совсем не означает, что оно эффективнее. Каждая из технологий позволяет выявить ошибки, пропускаемые другой, в этом смысле их можно назвать одинаково эффективными.
Тестирование программных путей: критерии охвата
Как уже упоминалось, пути выполнения программы — последовательностях команд, которые она выполняет от старта до завершения. Объектом тестирования может быть не только полный путь, но и его отдельные участки.
Известно, что протестировать все возможные пути выполнения программы абсолютно нереально. Поэтому специалисты по тестированию выделяют из всех возможных путей те группы, которые нужно протестировать обязательно. Для отбора они пользуются специальными критериями, называемыми критериями охвата. В отличие от нереальной идеи полного тестирования, эти критерии определяют вполне реальное (пусть даже и достаточно большое) количество тестов. Критерии охвата иногда называют логическими критериями охвата или критериями полноты. В книга Канера С., Фолка Д., Нгуена К. Е.[1] описаны три критерия, которыми используются тестировщиками чаще всего: критериями охвата строк, ветвлений и условий. Когда тестирование организовано в соответствии с этими критериями, о нем говорят как о тестировании путей.
Критерий охвата строк - наиболее слабый из всех. Он требует, чтобы каждая строка кода была выполнена хотя бы один раз. Для серьезного тестирования программы этого далеко не достаточно. Если строка содержит оператор принятия решения, проверены должны быть все управляющие решением значения.
Иногда охват ветвлений называют полным охватом кода. Но термин этот некорректен: как показал Бейзер [6] охват ветвлений не может претендовать на полноту тестирования, поскольку в лучшем случае позволяет обнаружить половину имеющихся в программе ошибок.
Более строгим является критерий охвата условий. По этому критерию следует проверить все составляющие каждого логического условия.
Тестирование путей программы считается завершенным, когда выбранный критерий охвата полностью выполнен. Для автоматизации этого процесса разработаны программы, анализирующие программный код и вычисляющие количество подлежащих тестированию путей, а затем подсчитывающие, сколько их уже проверено. Такие программы называют средствами мониторинга охвата. Хотя критерии охвата очень полезны, одного только тестирования путей недостаточно для эффективного выявления ошибок.
Тестирование частей против тестирования целого
Любая система разрабатывается по частям — как набор процессов или модулей. Можно, таким образом, и проводить тестировать — сначала отдельные части, а потом уже их взаимодействие. Такая стратегия называется восходящей. Выяснив, что отдельные элементы программы в порядке, специалист приступает к тестированию их совместной работы. И тут может возникнуть ситуация, что вместе они работать отказываются.
Тестирование совместной работы программных модулей называют интеграционным. В ходе такого тестирования модули сначала объединяются в пары, потом в большие блоки, пока наконец все модули не будут объединены в единую систему.
Восходящее тестирование — это хороший способ локализации ошибок. Если ошибка обнаружена при тестировании единственного модуля, то очевидно, что она содержится именно в нем — для поиска ее источника не нужно анализировать код всей системы. А если ошибка проявляется при совместной работе двух предварительно протестированных модулей, значит, дело в их интерфейсе. Еще одним преимуществом восходящего тестирования является то, что выполняющий его программист концентрируется на очень узкой области (единственном модуле, передаче данных между парой модулей и т.п.). Благодаря этому тестирование проводится более тщательно и с большей вероятностью выявляет, ошибки.
Главным недостатком восходящего тестирования является необходимость написания специального кода-оболочки, вызывающего тестируемый модуль. Если он, в свою очередь, вызывает другой модуль, для него нужно написать заглушку. Заглушка — это имитация вызываемой функции, по возвращающая те же данные, но ничего больше не делающая.
Написание оболочек и заглушек замедляет работу, а для конечного продукта они абсолютно бесполезны. Но написанные однажды, эти элементы могут использоваться повторно при каждом изменении программы. Хороший набор оболочек и заглушек — это очень эффективный инструмент тестирования.
В противоположность восходящему тестированию, стратегия целостного тестирования предполагает, что до полной интеграции системы ее отдельные модули не проходят особо тщательного тестирования.
Преимуществом такой стратегии является то, что нет необходимости в написании дополнительного кода. Поэтому многие руководители выбирают этот способ из соображений экономии времени — они считают, что лучше разработать один обширный набор тестов и с его помощью за один раз проверить всю систему. Но такое представление совершенно ошибочно, и вот почему.
• Очень трудно, выявить источник ошибки. Это главная проблема. Поскольку ни один из модулей не проверен как следует, в большинстве из них есть ошибки. Получается, что вопрос не столько в том, в каком модуле произошла обнаруженная ошибка, сколько в том, какая из ошибок во всех вовлеченных в процесс модулях привела к полученному результату. И когда накладываются ошибки нескольких модулей, ситуацию может быть гораздо труднее локализовать и повторить.
Кроме того, ошибка в одном из модулей может блокировать тестирование другого. Как протестировать функцию, если вызывающий ее модуль не работает? Если не написать для этой функции программу-оболочку, придется ждать отладки модуля, а это может затянуться надолго.
• Трудно организовать исправление ошибок. Если программу пишут несколько программистов (а именно так и бывает в больших системах), и при этом неизвестно, в каком модуле ошибка, появляется проблема, кто будет ее искать и исправлять. Из за этого будет сильно страдать скорость разработки.
• Процесс тестирования плохо автоматизирован. То, что на первый взгляд кажется преимуществом целостного тестирования — отсутствие необходимости писать оболочки и заглушки, — на самом деле оборачивается его недостатком. В процессе разработки программа ежедневно меняется, и ее приходится тестировать снова и снова. А оболочки и заглушки помогают автоматизировать этот однообразный труд.
Поскольку большинство руководителей проектов отнюдь не глупы, когда кто-нибудь из них выбирает целостное тестирование, предполагается, что в своем конкретном случае он видит такие преимущества этого подхода, о которых просто не упоминает.
Нисходящее тестирование против восходящего
Существует и еще один принцип организации тестирования, при котором программа так же, как и при восходящем способе, тестируется не целиком, а по частям. Только направление движения меняется — сначала тестируется самый верхний уровень иерархии модулей, а от него тестировщик постепенно спускается вниз. Такая технология называется нисходящей (top-down). Обе технологии — и нисходящую и восходящую — называют также инкрементальными.
При нисходящем тестировании отпадает необходимость в написании оболочек, но заглушки остаются. По мере тестирования заглушки по очереди заменяются на реальные модули.
Мнения специалистов о том, какая из двух инкрементальных стратегий тестирования более эффективна, сильно расходятся. Йордан [8] доказывает, что гораздо лучше нисходящее тестирование, а Майерс [9] утверждает, что, хотя у обоих подходов есть свои преимущества и недостатки, в целом восходящее тестирование лучше. По мнению же Данна [5] эти способы примерно эквивалентны.
На практике вопрос выбора стратегии тестирования обычно решается просто: каждый модуль по возможности тестируется сразу после его написания, в результате последовательность тестирования одних частей программы может оказаться восходящей, а других — нисходящей.
Статическое тестирование против динамического
При статическом тестировании программный код вообще не выполняется — он тестируется только путем логического анализа.
Две описанные выше базовые стратегии — тестирование "черного ящика" и тестирование "стеклянного ящика" — являются динамическими. Программа запускается, вводятся данные, и программист или тестировщик анализирует результат. Разница только в том, на какой информации основывается подбор тестов.
Для статического анализа существует множество инструментальных средств. Самое известное из них — компилятор. Встретив синтаксическую ошибку или недопустимую операцию, компилятор выдает соответствующее сообщение. Ряд полезных сообщений выдает и компоновщик — о повторяющихся именах переменных и других объектов, ссылках на необъявленные переменные и функции. Статический анализ программы может выполняться и людьми. Они читают исходный код, обсуждают его, и, как правило, находят достаточно много ошибок. Примеры такой работы.
• Обзорные, инспекционные и рецензионные совещания. Это точно такие же совещания, какие проводятся для анализа проекта программного продукта. Майерс [9] предлагает для них очень полезный список контрольных вопросов. Он утверждает, что для выявления ошибок обзорные совещания не менее полезны, чем динамическое тестирование специалистом, который не является автором кода программы.
• Работа за столом. Статический анализ программного кода может выполняться и в одиночку. Специалист читает и анализирует программный код. Если он не может понять, что делает конкретный фрагмент программы, он может поработать и за компьютером, но большую часть времени проводит за столом. Он работает дольше, чем обычно длятся совещания, и анализирует гораздо большие объемы кода. Этот вид тестирования может выполнять как сам автор программного кода, так и кто-то другой — в любом случае оно будет очень полезным.
Вычитывать программный код (как собственный, так и чужой) — работа скучная, и многие специалисты не любят заниматься ей. В пользу этой процедуры положительно высказывается Бейзер [6], также он советует ускорить работу за счет игнорирования синтаксиса и всего того, что может сделать компилятор.
Одним из полезных результатов чтения программного кода может быть заключение о том, достаточно ли он прост и логичен. Если код трудно читать, то очень вероятно, что программист недостаточно четко видит задачу. И, кроме того, даже если в такой программе и нет ошибок, в дальнейшем могут возникнуть большие сложности с ее модернизацией.
Соответствие стандартам
У каждой компании могут быть свои стандарты, определяющие, сколько в коде должно быть комментариев, какой максимальной длины могут быть отдельные модули, должен ли программист строго следовать соглашениям об именах переменных и функций и каковы эти соглашения. Анализ соответствия кода таким стандартам прекрасно поддается автоматизации.
Программная статистика
Существует практика анализировать сложность программного кода с помощью статистических вычислений. Тамре Л [10] и Канер С., Фолк Д., Нгуен К. Е. [1] относятся к этому весьма скептически. На их взгляд, такой математический анализ интересен разве что с теоретической точки зрения, практическая же его полезность весьма ограничена. Некоторые руководители требуют, чтобы программисты перерабатывали код, пытаясь добиться "приемлемого", по их мнению, коэффициента сложности. Но на практике это может привести разве что к замедлению работы и появлению лишних ошибок и проблем.
Намеренные ошибки: псевдоотладка и мутационное тестирование
Одной из довольно специфических технологий тестирования программ является псевдоотладка. В программу намеренно внедряется ряд ошибок. По мнению Вейнберга [11] программист, зная наверняка, что в программе есть ошибки, будет гораздо тщательнее ее тестировать.
Но главное назначение этой технологии — оценить эффективность проводимых тестов. Если внедрить в программу 100 ошибок, а затем провести тестирование, в результате которого будет выявлено только 20 из них, значит, в программе останется еще около 80% невыявленных ошибок.
Еще одним способом проверки адекватности проводимых тестов является мутационное тестирование. В программу вносится маленькое изменение, называемое мутацией. В процессе тестирования результат такого изменения должен обязательно проявиться. Если же этого не случится, это может означать, что тесты подобраны неудачно.
Анализ производительности
Для анализа производительности программного продукта можно применять технологию как "черного" так и "стеклянного ящика". Однако вторая из них дает лучшие результаты, поскольку позволяет с помощью дополнительных программных средств фиксировать время выполнения отдельных модулей, прохождения конкретных путей или скорость обработки специфических типов данных.
Одной из целей выполнения анализа производительности является ее увеличение. Если выявить модули, которые выполняются чаще или дольше остальных, их можно переработать и тем самым повысить скорость работы всей системы.
Группы тестирования обычно работают с программой как с "черным ящиком". Они сравнивают производительность последовательных версий программы, и, если обнаруживают, что после последней доработки она замедлилась, это является для них сигналом о возможной ошибке.
Производительность программного продукта анализируют и еще с одной целью — для выяснения его конкурентоспособности: если имеющиеся на рынке аналогичные программы работают значительно быстрее, придется "ускорить" и свою.
Регрессионное тестирование
Основной работой тестировщиков является регрессионное тестирование. У этого термина два значения, объединенных идеей повторного использования разработанных тестов.
- Тестировщик провел тест, обнаружили ошибку и программист ее исправил. Тестировщик снова проводит тот же тест, чтобы убедиться, что ошибки больше нет. Это и есть регрессионное тестирование. Можно провести несколько вариаций исходного теста, чтобы как следует проверить исправленный фрагмент программы. В данном случае задача регрессионного тестирования состоит в том, чтобы убедиться, что выявленная ошибка полностью исправлена программистом и больше не проявляется.
В некоторых коллективах в набор регрессионных тестов включают каждую найденную ошибку, даже если она исправлена уже давным-давно. Каждый раз, когда в программу вносится изменение, все эти тесты проводятся снова. Особенно важно провести такое обстоятельное тестирование, если программа изменяется спустя достаточно длительное время или новым программистом. Исправления очень чувствительны к таким изменениям, поскольку в тексте программы, если только они не задокументированы самым тщательным образом, выглядят как непонятные или неудачные фрагменты.
- Второй пример применения регрессионного тестирования. После выявления и исправления ошибки проводится стандартная серия тестов, но уже с другой целью: убедиться, что исправляя одну часть программы, программист не испортил другую. В этом случае тестируется целостность всей программы, а не исправление одной ошибки.
При инкрементальном тестировании основой автоматизации проведения регрессионных тестов служат разработанные заглушки и оболочки. А для автоматизации регрессионного тестирования "черного ящика" можно воспользоваться программами перехвата и воспроизведения ввода.
Тестирование "черного ящика"
Когда кодирование завершено, программа передается группе тестирования. Ищутся ошибки, составляются о них отчеты, затем тестировщики получают новую версию программы и снова ищут ошибки. Находятся старые ошибки, не замеченные на первом этапе, и новые, появившиеся после доработки. Мартином и Мак-Клером [2] были сделаны выводы на основе собранных Боэмом [3] данных об эффективности исправления найденных ошибок.
• Если для исправления ошибки нужно изменить не более десяти операторов, вероятность того, что это будет сделано правильно с первого раза, составляет 50%.
• Если для исправления ошибки нужно изменить около пятидесяти операторов, вероятность того, что это будет сделано правильно с первого раза, составляет 20%.
Проблема не только в том, что программист может не исправить ошибку до конца. Гораздо хуже другое — то, что исправления могут иметь побочные эффекты. Исправление одной ошибки может привести к появлению другой. А бывает и так, что одна ошибка скрывает другую, которая проявляется только после ее устранения. К сожалению, программисты часто концентрируются только на поставленной перед ними проблеме и, решив се, считают свою работу сделанной — регрессионного тестирования, пусть даже самого поверхностного, они не выполняют.
Стандартная процедура тестирования "черного ящика"
Тестирование программного продукта начинается с планирования: определяется стратегия, разрабатываются серии тестов, распределяются между сотрудниками задания. Начинать планирование можно сразу после того, как команда проектировщиков выработает требования к программному продукту. Однако чаще подробное планирование начинается на первом цикле тестирования, когда перед тестировщиками готовый программный продукт.
Приемочное тестирование
Канером С., Фолком Д., Нгуеном К. Е. дано определение приемочного тестирования: «При поступлении каждой новой версии программного продукта тестировщики прежде всего проверяют, достаточно ли она стабильна. Если она "обрушивается" при малейшей провокации, возиться с ней не стоит. Такое первое беглое тестирование называют приемочным или квалификационным»[1].
Наилучший вариант, если приемочные тесты будут стандартизированы. Тогда их копии можно передать программистам, чтобы те проводили их сами и не сдавали тестировщикам программы раньше времени. Это позволит избежать возвратов тестировщиками неработающих программ — моментов, психологически неприятных для обеих сторон.
Приемочные тесты должны быть короткими. В них должны проверяться только основные функции и основные данные. Во многих компаниях приемочные тесты частично автоматизированы с помощью специального программного обеспечения, выполняющего тестирование "черного ящика".
Функциональное и системное тестирование, сверка и аттестация продукта
Когда программный продукт готов и протестирован, он должен пройти ряд завершающих тестов. Прежде всего, он должен быть еще раз сверен с наиболее подробными и близкими к нему проектными документами. В частности, должно быть проведено функциональное тестирование, при котором продукт сверяется с внешней спецификацией.
Затем программа сверяется с опубликованной печатной документацией — пользовательскими (тестирование целостности) и системными (системное тестирование) требованиями. Эти две процедуры носят название аттестационного тестирования. В разговорах о тестировании можно встретиться с одним из популярных терминов — Independent Verification and Validation (IV&V — независимая сверка и аттестация). Он означает сверочное и аттестационное тестирование, проводимое независимым агентством.
Более подробное описание процедуры сверки и аттестации можно найти в документе IEEE Standard for Software Verification and Validation Plans (ANSI/IEEE Standard 1012-1986) [7].
Бета-тестирование
Когда тестировщик подтверждает, что программа достаточно стабильна и документация в порядке, наступает время для обратной связи с пользователями - бета-тестированием.
На этом этапе с программой работают ее потенциальные пользователи. Они эксплуатируют программу и присылают или высказывают тестировщикам свои замечания. Поскольку бета-тестировщики знают, что в программе могут оставаться еще очень серьезные ошибки, они не работают с ней полный день — на 20 часов тестирования у них уходит около трех недель. В определенных ситуациях бета-тестировщики работают с продуктом гораздо более основательно. Вот какими могут быть их мотивации.
• Пользователю очень нужен продукт, даже если он и не надежен, а других подобных продуктов на рынке нет.
• Компания достаточно платит. Обычно в качестве платы за бета-тестирование пользователь получает или бесплатную копию продукта, или значительную скидку. Если продукт дорогой, этого достаточно. Но если речь идет о программе, предназначенной для доступа к важной информации, и в этой программе происходит сбой, потеря данных может обойтись пользователю гораздо дороже стоимости программного продукта.
• Компания дает пользователю выгодную гарантию. Тестирование целостности готового продукта и тестирование распространяемых копий
С завершением тестирования последней бета-версии готового программного продукта возможные проблемы не заканчиваются. Необходимо еще убедиться, что он в целости и сохранности попадет к клиенту. Для тестирования распространяемых копий тестировщик собирает все, что будет отправлено пользователю или производителю, проверяете, все ли на месте и в порядке, и делаете архивные копии. Только после этого продукт отправляется по назначению.
Тестирование целостности программного продукта — работа более обстоятельная. Тестировщик старается спрогнозировать все жалобы и критические замечания, которые могут появиться в прессе и поступить от пользователей в ближайшие несколько месяцев. Этим может заниматься ведущий специалист, который не участвовал в данной разработке, или даже сотрудник независимого агентства. В его задачи не входит поиск ошибок. Напротив, он предполагает, что и системное и функциональное тестирование проведены самым тщательным образом. Специалист внимательно сравнивает программу с пользовательской документацией и документами, в которых описаны требования к продукту. Кроме того, он может выполнить сравнение с конкурирующими продуктами.
В рамках тестирования целостности продукта выполняется и анализ маркетинговых материалов - возможности программы обязательно должны соответствовать рекламе. Потому и рекламная копия, и все печатные и электронные рекламные материалы перед публикацией должны подвергнуться самой строгой проверке.
Окончательная приемка и сертификация
Если компания разрабатывает программное обеспечение по контракту, для его приемки клиенты должны будут провести собственные тесты. Если продукт небольшой, тестирование может быть неформальным. Однако для большинства проектов процедура приемочного тестирования заранее согласовывается и фиксируется в контрактных документах. Приемочное тестирование занимает не более одного дня и не является особенно тщательным.
Сертификация всегда выполняется сторонней фирмой — независимой или работающей на клиента. Сертификационное тестирование может быть как коротким и поверхностным, так и более тщательным. По контракту оно может выполняться вместо приемочного тестирования. При этом уровень сертификационного тестирования и стандарты, которым должны соответствовать программа и процесс ее разработки обязательно должны быть записаны в контракте. Если же сертификация проводится по желанию компании-разработчика, например, из маркетинговых соображений, тогда она сама и определяет, какие провести тесты.
Примеры тестов, проводимых при функциональном и системном тестировании
Чтобы более наглядно пояснить суть описанного в предыдущих разделах функционального и системного тестирования, приведем примеры тестов, выполняемых на этом этапе.
Сверка со спецификацией
Проверяется соответствие разработанной программы каждому слову в спецификации.
Правильность
Правильно ли программа выполняет нужные вычисления и формирует отчеты?
Лабораторные испытания
Специалист по тестированию нанимает нескольких человек из числа будущих пользователей и наблюдает за их работой с продуктом. Фактически бета-тестирование является попыткой получить тот же результат с меньшими затратами. Но поскольку тестировщик не являетесь непосредственным свидетелем того, что происходит, и не можете давать бета- тестировщикам задания, бета-тестирование гораздо менее эффективно, чем лабораторные испытания.
Граничные условия
Проверяется реакция программы на граничные значения входных данных. Вводятся данные, в ответ на которые она сформировывает максимальные или минимальные выходные значения.
Производительность
Измеряется время выполнения программой различных задач, особенно тех, которые пользователь будет выполнять чаще всего.
Переходы между режимами
Правильно ли программа переходит из состояния в состояние? Это особенно важно для приложений, позволяющих параллельно выполнять несколько различных действий или переключаться между режимами, не завершая их работу.
Эксплуатация в реальном режиме
Тестировщик должен поработать с программой в том же режиме, в каком с ней будут работать реальные пользователи. Выполнить с ее помощью реальную работу. Такое тестирование выявляет много ошибок. Недостатки, которых при формальном тестировании тестировщики не заметили или посчитали их незначительными, в реальной работе могут оказаться очень серьезными.
Нагрузочные испытания
При нагрузочных испытаниях проверяется реакция программы на предельные условия эксплуатации.
• Тестирование на максимальный объем входных данных. Тестировщику необходимо посмотреть, как поведет себя программа в ответ на нестандартные данные.
• Испытания в утяжеленном режиме. Тестировщик должен проверить, как реагирует программа на резкое увеличение активности?
• Анализ требований к ресурсам. Тестировщику необходимо изучить требования программы к двум важным ресурсам компьютера — оперативной памяти и дисковому пространству. Если в спецификации записаны ограничения на использование этих ресурсов, нужно удостовериться, что ни при каких условиях программа не занимает больше памяти и дискового пространства, чем ей положено.
Многопользовательская и многозадачная работа
Если продукт представляет собой сложную многозадачную или многопользовательскую систему, его тестирование значительно усложняется. Тестировщикам необходимо проверить, как он справляется с параллельным выполнением нескольких задач и как координируются действия нескольких пользователей. Типичным примером таких систем являются многопользовательские системы управления базами данных, где несколько пользователей, сидящих за различными и, возможно, даже достаточно удаленными компьютерами, могут одновременно вводить данные в одну и ту же таблицу. Для тестирования такой системы нужно организовать ее эксплуатацию в реальном режиме, привлечь для работы большое количество людей и техники и, возможно, написать специальные программы, имитирующие одновременный ввод данных. Более подробное обсуждение этого вопроса можно найти в книге Бейзера [6].
Обработка ошибок
Программа должна корректно реагировать на неправильные, нестандартные или не предусмотренные документацией действия пользователей.
Защита
Сложно ли неавторизированному пользователю получить доступ к системе? Что для этого нужно? О тестировании защиты программного обеспечения рассказывается у Бейзера (Beizer, 1990) [6].
Совместимость и преобразование форматов данных
Два программных продукта называют совместимыми, если они могут работать с одними и теми же файлами данных или если они благополучно сосуществуют в оперативной памяти компьютера и работают, не мешая друг другу.
Если две программы не могут непосредственно работать с данными друг друга, это не значит, что они абсолютно несовместимы. Возможно, что пользователи смогут воспользоваться специальными конвертерами — программами-посредниками, преобразующими данные из одного формата в другой.
Одной из самых распространенных ситуаций, требующих конвертирования данных, является выпуск новой версии программы. В этом случае новая программа должна уметь определить, что предложенные ей данные сохранены в формате предыдущей версии, и самостоятельно выполнить их преобразование. Кроме того, программы одного класса часто умеют читать и сохранять данные в формате друг друга. Это позволяет пользователям совершенно безболезненно переходить с одной программы на другую или даже эксплуатировать их совместно.
Аппаратные конфигурации
Очень важно, чтобы программа успешно работала на компьютерах самых разнообразных конфигураций. Даже если программа ориентирована на конкретную модель процессора, все равно в системах, где ей придется работать, периферийные устройства будут различны.
Установка и обслуживание
Вместе с программным продуктом обычно поставляется и программа его установки. Она автоматизирует процесс интеграции продукта в систему и его настройки для нужд конкретного пользователя. Работает ли эта программа? Насколько она проста и удобна? Сколько времени в среднем требуется на установку?
Если программу будет устанавливать не пользователь, а специалист, например сотрудник фирмы-дилера, возникает и еще несколько вопросов, связанных с ее обслуживанием. Например, если произойдет сбой программы, как быстро квалифицированный специалист сможет устранить его последствия?
Эффектные тесты
Есть среди тестов и такие, которые служат не для реальной работы, а для того, чтобы произвести впечатление на публику. Их проводят перед зрителями (например, администрацией, пришедшей посмотреть, как идет работа), чтобы показать, как "ужасно нестабильна" программа и как профессиональны тестировщики.
По-настоящему эффектный тест должен быть очень простым и приводить к немедленному сбою. Как подбирать такие тесты, сказать сложнее. Здесь приходится основываться на профессиональном опыте тестировщика, знании слабых мест программиста, операционной системы и результатах тестирования аналогичных продуктов.
Сопровождение
Значительная часть средств, которые компания затрачивает на программный продукт, уходит уже после завершения его разработки. Такие данные приводят в своем учебнике Мартин и Мак-Клер [2]. На сопровождение программного обеспечения затрачивается 67% его общей стоимости. Распределяется эта сумма так.
• 20% бюджета сопровождения тратится на исправление ошибок
• 25% уходит на адаптацию продукта к новому аппаратному обеспечению и новой программной среде
• 6% тратится на исправление документации
• 4% тратится на повышение производительности
• 42% тратится на внесение изменений и усовершенствований
• 3% на другие нужды
На этапе сопровождения программного продукта в работе тестировщика не будет ничего особенного — он будет делать то же самое, что уже делал в конце разработки во время функционального и системного тестирования. Если у тестировщика есть серия регрессионных тестов, которые к тому же еще и частично автоматизированы, ему остается только повторять их после каждого изменения программы. И не забывать, что сделанные на этом этапе изменения, могут иметь побочные эффекты. Поэтому необходимо обязательно проверять не только измененный фрагмент, но и всю программу в целом.
Адаптационное тестирование
Этот вид тестирования выполняется только на этапе сопровождения, когда программа переносится с одной аппаратной или программной платформы на другую. Если программа должна работать на нескольких типах компьютеров, нужно проверить ее совместимость с каждым из них. Краткое описание стратегии такого тестирования.
•Общее функционирование. Выполняется серия регрессионных тестов. Тестировщик должен постараться хотя бы частично проверить программу, как на граничных, так и на основных данных. Если какая-то из функций плохо совместима с новой платформой, то, скорее всего, она не будет работать вообще. Как правило, при переносе программы на другую платформу тесты на общее функционирование она проходит вполне успешно. Поэтому тестировщику не стоит тратить на них, слишком много времени.
• Клавиатура. Если у компьютера специфическая клавиатура, в работе с ней могут быть небольшие отклонения от стандарта. Поэтому тестировщику нужно обязательно нажать каждую клавишу, и к тому же в различных ситуациях.
• Терминал. Необходимо проверить, как программа работает с новым терминалом. Как отображается графика? Если программа работает в текстовом режиме, то все ли символы отображаются правильно, нет ли проблем с цветом, подчеркиванием или подсветкой?
• Номер версии и идентификация системы. Если номер версии программы изменился, тетсировщику нужно убедиться, что он нигде не остался старым. Если при запуске программа идентифицирует аппаратуру или операционную систему,нужно убедиться, что она делает это правильно.
• Диски. Емкость и формат дисков могут сильно отличаться. Тестировщику необходимо убедиться, что программа правильно работает с файлами, размер которых кратен 2. Если новая система поддерживает размер дисков, которого не поддерживала старая, нужно попробовать поработать с таким большим диском.
• Обработка ошибок операционной системой. Как действует операционная система в таких ситуациях, как ошибка доступа к диску? Позволит ли она прикладной программе самой обработать эту ситуацию и выдать корректное сообщение или просто остановит программу и сообщит о системной ошибке? А как сам программный продукт защищает пользователя от ошибок и странностей операционной системы?
• Установка. При установке программного продукта инсталляционной программе может потребоваться определить аппаратную и программную конфигурацию системы. Тестировщику необходимо убедиться, что она делает это правильно.
• Интерфейс. В различных графических средах (Windows, Mac, и т.п.) действуют различные соглашения о пользовательском интерфейсе. Перейдя в новую среду, программа должна выглядеть в ней достаточно естественно.
• Другие изменения. Тестировщик должен узнать у программиста, какие еще изменения он вносил в программу для ее адаптации, и после этого протестировать ее.
Если программный продукт впервые адаптируется к новой платформе, не надо рассчитывать на быстрый успех. Тестирование может занять у специалистов четверть того времени, которое было потрачено на разработку. Перенос на следующую платформу может пройти и быстрее, особенно если эти платформы достаточно совместимы.
СВОДНАЯ ТАБЛИЦА ТИПОВ ТЕСТОВ И ИХ КРАТКАЯ ХАРАКТЕРИСТИКА
Тестирование на этапе планирования
"Тестируются" идеи. К их анализу привлекаются специалисты по маркетингу, руководители проекта, главные конструкторы и специалисты по анализу человеческого фактора.
Производится на этапе планирования. Им занимаются специалисты по маркетингу, руководители проекта, главные конструкторы и специалисты по анализу человеческого фактора.
Тестирование на этапе проектирования
На этапе проектирования, как и на этапе планирования, кода еще нет, поэтому и здесь тестируются только идеи. Однако на этот раз идеи гораздо лучше формализованы и описаны намного подробнее, чем в первоначальных планах. Анализируя проектные документы, специалисты должны составить очень четкое представление о работе будущей системы.
Производится на этапе проектирования. Им занимаются аналитики, специалисты по тестированию привлекаются в случае необходимости.
Тестирование стеклянного ящика на стадии кодирования (динамическая стратегия)
На этапе кодирования программист пишет программы и сам их тестирует. Тестировщик (как правило, это программист) разрабатывает тесты, основываясь на знании исходного кода. Тестирование "стеклянного ящика" рассматривается как часть процесса программирования. Программисты выполняют эту работу постоянно, они тестируют каждый модуль после его написания, а затем еще раз после интеграции его в систему
Производится на этапе кодирования и написания документации. Выполняется программистами.
Тестирование черного ящика (динамическая стратегия)
При тестировании "черного ящика" программа рассматривается как объект, внутренняя структура которого неизвестна. Тестировщик вводит данные и анализирует результат, но, как именно работает программа, он не знает. Подбирая тесты, специалист ищет интересные с его точки зрения входные данные и условия, которые могут привести к нестандартным результатам. Методу «черного ящика» посвящают большую часть времени все профессиональные тестировщики. Тестировщик "черного ящика" не изучает исходный код программы — он исследует ее извне, работая с ней так, как это будет делать пользователь. И так же, как исследование программы изнутри позволяет выявить проблемы и критические точки, которых не видно извне, так и тестировщик "черного ящика" выявляет ошибки и недостатки, которые программист упускает
Производится на этапе тестирования и исправления недостатков, сопровождения (к примеру, выход новой версии). Выполняется специалистами по тестированию.
Структурное тестирование
Является одним из видов тестирования "стеклянного ящика". Его главной идеей является правильный выбор тестируемого программного пути.
Производится на этапе кодирования. Выполняется программистами.
Функциональное тестирование
Функциональное тестирование относится к категории тестирования "черного ящика". Каждая функция программы тестируется путем ввода ее входных данных и анализа выходных. При этом внутренняя структура программы учитывается очень редко. Структурное тестирование и имеет под собой гораздо более мощную теоретическую основу, но большинство тестировщиков предпочитают функциональное тестирование. Структурное тестирование лучше поддается математическому моделированию, но это совсем не означает, что оно эффективнее. Каждая из технологий позволяет выявить ошибки, пропускаемые другой, в этом смысле их можно назвать одинаково эффективными.
Производится на этапе тестирования и исправления недостатков, сопровождения. Выполняется специалистами по тестированию.
Тестирование программных путей
Объектом тестирования может быть не только полный путь, но и его отдельные участки. Специалисты по тестированию выделяют из всех возможных путей те группы, которые нужно протестировать обязательно. Для отбора они пользуются специальными критериями, называемыми критериями охвата. Хотя критерии охвата очень полезны, одного только тестирования путей недостаточно для эффективного выявления ошибок.
Производится на этапе тестирования и исправления недостатков. Выполняется специалистами по тестированию.
Восходящая стратегия тестирования
Тестируются сначала отдельные части, а потом уже их взаимодействие. Хороший способ локализации ошибок. Главным недостатком восходящего тестирования является необходимость написания специального кода-оболочки, вызывающего тестируемый модуль. Если он, в свою очередь, вызывает другой модуль, для него нужно написать заглушку. Эту технологию тестирования также называют инкрементальной.
Производится на этапе тестирования и исправления недостатков. Выполняется специалистами по тестированию.
Интеграционное тестирование
Тестирование совместной работы программных модулей.
Производится на этапе тестирования и исправления недостатков. Выполняется специалистами по тестированию.
Целостное тестирование
Стратегия целостного тестирования предполагает, что до полной интеграции системы ее отдельные модули не проходят особо тщательного тестирования. Преимуществом такой стратегии является то, что нет необходимости в написании дополнительного кода. Но есть также и ощутимые недостатки (более подробно в реферате)
Производится на этапе тестирования и исправления недостатков. Выполняется специалистами по тестированию.
Нисходящая стратегия тестирования
Программа так же, как и при восходящем способе, тестируется не целиком, а по частям. Только направление движения меняется — сначала тестируется самый верхний уровень иерархии модулей, а от него тестировщик постепенно спускается вниз. Такая технология называется нисходящей. Эту технологию тестирования также называют инкрементальной.
Производится на этапе тестирования и исправления недостатков. Выполняется специалистами по тестированию.
Статистическое тестирование
При статическом тестировании программный код вообще не выполняется — он тестируется только путем логического анализа.
Производится на этапе тестирования и исправления недостатков. Выполняется специалистами по тестированию.
Псевдоотладка
В программу намеренно внедряется ряд ошибок. Назначение этой технологии — оценить эффективность проводимых тестов.
Производится на этапе тестирования и исправления недостатков. Выполняется специалистами по тестированию.
Мутационное тестирование
В программу вносится маленькое изменение, называемое мутацией. В процессе тестирования результат такого изменения должен обязательно проявиться. Если же этого не случится, это может означать, что тесты подобраны неудачно.
Производится на этапе тестирования и исправления недостатков. Выполняется специалистами по тестированию.
Регрессионное тестирование
Основная работой тестировщиков . У этого термина два значения, объединенных идеей повторного использования разработанных тестов
Производится на этапе тестирования и исправления недостатков, сопровождения. Выполняется специалистами по тестированию.
Приемочное тестирование
При поступлении каждой новой версии программного продукта тестировщики, прежде всего, проверяют, достаточно ли она стабильна. Приемочные тесты должны быть короткими. В них должны проверяться только основные функции и основные данные. Во многих компаниях приемочные тесты частично автоматизированы с помощью специального программного обеспечения, выполняющего тестирование "черного ящика".
Производится на этапе тестирования и исправления недостатков, сопровождения. Выполняется специалистами по тестированию.
Аттестационное тестирование
Включает в себя тестирование целостности (программа сверяется с опубликованной печатной документацией — пользовательскими и системными требованиями) и системное тестирование.
Производится в конце этапа тестирования и исправления недостатков и на этапе сопровождения. Выполняется специалистами по тестированию.
Бета- тестирование
С программой работают ее потенциальные пользователи. Они эксплуатируют программу и присылают или высказывают тестировщикам свои замечания.
Производится на этапе тестирования и исправления недостатков. Выполняется потенциальными пользователями.
Тестирование целостности программного продукта
Тестировщик старается спрогнозировать все жалобы и критические замечания, которые могут появиться в прессе и поступить от пользователей в ближайшие несколько месяцев. В его задачи не входит поиск ошибок. Специалист внимательно сравнивает программу с пользовательской документацией и документами, в которых описаны требования к продукту. Кроме того, он может выполнить сравнение с конкурирующими продуктами.
Производится на этапе сопровождения. Выполняется специалистами по тестированию.
Системное тестирование
Систе?мное тести?рование програ?ммного обеспече?ния — это тестирование программного обеспечения, выполняемое на полной, интегрированной системе, с целью проверки соответствия системы исходным требованиям. Системное тестирование относится к методам тестирования чёрного ящика.
Производится на этапе тестирования и исправления недостатков. Выполняется специалистами по тестированию.
Окончательное приемочное тестирование (заказчиками)
Для большинства проектов процедура приемочного тестирования заранее согласовывается и фиксируется в контрактных документах. Приемочное тестирование занимает не более одного дня и не является особенно тщательным.
Производится на этапе сопровождение. Выполняется заказчиком.
Сертификационное тестирование
Сертификационное тестирование может быть как коротким и поверхностным, так и более тщательным. По контракту оно может выполняться вместо приемочного тестирования. При этом уровень сертификационного тестирования и стандарты, которым должны соответствовать программа и процесс ее разработки обязательно должны быть записаны в контракте.
Производится на этапе сопровождения. Выполняется специалистами по тестированию компании- разработчика, либо специалистами независимой компании.
Адаптационное тестирование
Этот вид тестирования выполняется только на этапе сопровождения, когда программа переносится с одной аппаратной или программной платформы на другую.
Производится на этапе сопровождения. Выполняется
специалистами по тестированию.
Эффектные тесты
Служат не для реальной работы, а для того, чтобы произвести впечатление на публику. Их проводят перед зрителями (например, администрацией, пришедшей посмотреть, как идет работа), чтобы показать, как "ужасно нестабильна" программа и как профессиональны тестировщики.
Производится на этапе тестирования и исправления недостатков, сопровождения. Выполняется
специалистами по тестированию.
Примеры тестов, проводимых при функциональном и системном тестировании
Сверка со спецификациейПравильностьЛабораторные испытанияГраничные условияПроизводительностьПереходы между режимамиЭксплуатация в реальном режимеНагрузочные испытанияМногопользовательская и многозадачная работаОбработка ошибокЗащитаСовместимость и преобразование форматов данныхЭффектные тестыУстановка и обслуживаниеАппаратные конфигурацииПодробное описание, самих тестов, в реферате.
Производится на этапе тестирования и исправления недостатков. Выполняется специалистами по тестированию.
Заключение
От надежного функционирования определенных типов программного обеспечения может зависеть успех бизнеса — работы финансовых или промышленных компаний — или даже человеческая жизнь. Поэтому на его самое тщательное проектирование, разработку и тестирование не жалеют ни времени, ни денег. Сотрудникам тестовых групп предоставляется полный доступ к исходному коду программ, причем настолько времени, сколько потребуется для его подробного изучения.
Однако не все программное обеспечение таково, и дело не только в его цене. Тестирование программных продуктов для среднего бизнеса, академических учреждений и личного пользования проводится в более сжатые сроки и скромнее оплачивается, но их качество вполне удовлетворяет требованиям рынка — это полезные и надежные программы, многими из которых производители могут заслуженно гордиться.
Задача специалиста по тестированию — выявить все проблемы, которые могут возникнуть при работе с продуктом, и сделать все возможное для улучшения его качества. Необходимо помнить, что тестируется не просто программа, а тестируется систему человек-компьютер, и отчеты о ненадежности или неэффективности взаимодействия между человеком и компьютером не менее важны, чем остальные. Тестировщик один из немногих специалистов, анализирующих продукт во всех деталях, причем непосредственно перед его предоставлением пользователю.
Тестировщики часто жалуются, что их подключают к процессу разработки слишком поздно, когда все принципиальные решения уже приняты. На самом же деле работа для тестировщика есть с самого начала — он может вносить полезные предложения на каждом этапе разработки. Например, на этапе разработки спецификации тестировщик может проводить анализ логической правильности спецификации, ее выполнимости, полезности отдельных решений и тестируемости программного продукта.
Продукт тестируют и исправляют практически на каждом этапе его жизненного цикла. Для каждого этапа существуют различные типы тестов. Игнорирование использования различных стратегий тестирования может, привести к печальным результатам. Так как, чем дальше продвигается работа, тем быстрее растет стоимость тестирования. Стоимость исправления ошибок растет экспоненциально: легче всего это делать на стадии планирования, а по мере перехода к проектированию, кодированию, тестированию и сопровождению она значительно увеличивается.
Список используемой литературы
1) Канер С., Фолк Д., Нгуен К. Е. Тестирование программного обеспечения. Фундаментальные концепции менеджмент бизнес- приложений. ДиаСофт, 2001г., 544 стр.
2) Martin J. , McClure C. Diagramming Technique for Analysts and Programmers. PrenticeHall,- 1985.
3) Боэм Б., Браун Дж., Каспар Х. и др. Характеристики качества программного обеспечения. /Пер. с англ. М.: Мир, 1987. - 208 с
4) IEEE Software Requirements Specification (руководство IEEE по определению требований к программному обеспечению, стандарт ANSI/IEEE 830-1984).
5) Dunn. Software Defect Removal. - 1984
6) Beizer B. Software System Testing and Quality Assurance - 1990
7) IEEE Standard for Software Verification and Validation Plans (ANSI/IEEE Standard 1012-1986)
8) Yourdon Е. Techniques of program structure and design - 1975
9) Myers G. The Art of Software Testing – 1979
10) Тамре Л. Введение в тестирование программного обеспечения. : Пер. с англ. — М.: Издательский дом "Вильяме", 2003. — 368 с.
11) Weinberg J. Quality Software Management: Anticipating Change? - 1997