Тестирование-книга. Ю. Н. Артеменко Научный редактор
 Скачать 6.27 Mb.
|
|
51 К некоторым темам этой главы мы больше возвращаться не будем. Поэтому, если вы хотите выглядеть перед коллегами профессиональ но достаточно грамотными, изучите ее как можно внимательнее. 4. Библиографические справки. Вопросам тестирования и разработки программного обеспечения посвящено много полезных книг. Чтобы помочь вам как можно лучше разобраться в каждом рассматрива емом вопросе, мы часто ссылаемся на такие издания. И в этой главе таких ссылок особенно много. Обычно писатели включают в свои книги библиографические ссылки для того, чтобы читатель мог познакомиться с альтернативным мне нием, или для того, чтобы продемонстрировать свою толерантность к чужим взглядам на вещи. Мы же пользуемся ссылками еще и для того, чтобы читатель мог углубить и расширить свои знания. Мы упоминаем только те издания, которые нравятся нам самим и кажутся полезными для изучения вопроса. Поэтому в одних разделах ссылок на дополнительную литературу много, а в других — совсем мало. Многие вопросы, освещенные в этой главе лишь концептуально, в сле дующих главах будут дополнены техническими подробностями, а потом снова будет сделан их обзор, но уже на более глобальном уровне (в главах 12 и 13). В главе 13 мы от начала до конца проанализируем весь процесс разработки программного обеспечения. На этот раз мы будем исходить из предположения, что основы вам уже хорошо знакомы, и сделаем упор на стратегические вопросы: как при ограниченных сроках и бюджете так организовать работы, чтобы максимально улучшить ка чество программного продукта. Замечание Материал этой главы изложен так, чтобы охватить как можно больше вопросов, не вдаваясь в подробности. Некоторым читателям она пока жется перегруженной новыми терминами и понятиями, а другим — самой скучной во всей книге. Те читатели, которые не осилили книгу до конца, говорили нам, что остановились именно здесь. Позвольте предложить вам несколько советов. • Прежде всего, не стоит беспокоиться, если вы не до конца поймете разницу между некоторыми терминами из области разработки про граммного обеспечения. Вам не нужно вникать во все детали рабо ты программистов, просто познакомьтесь с их терминологией, чтобы в дальнейшем вы смогли расспрашивать их о внутренней структуре программ и понимать их ответы. • Отнеситесь к этой главе как к ознакомительному обзору. Не вникая во все детали, постарайтесь получить общее представление о процес се разработки программного обеспечения и его тестирования и отме чайте для себя в уме самые важные моменты. В дальнейшем вы еще не раз будете возвращаться к этой главе за справками или уточне ниями. Имея это в виду, мы постарались структурировать ее материал самым тщательным образом, так что она даже напоминает справоч ник — в ней легко найти нужную информацию, даже если при пер вом прочтении вы ее пропустили вовсе. 52 Часть I: Основы • С т у д е н т а м , п л а н и р у ю щ и м в д а л ь н е й ш е м заниматься т е с т и р о в а н и е м п р о г р а м м н о г о о б е с п е ч е н и я , м ы б ы р е к о м е н д о в а л и п о д ы т о ж и т ь ин ф о р м а ц и ю этой главы, представив ее в виде с х е м ы , п о х о ж е й на п р и в е д е н н у ю н а р и с . 1 3 . 3 . Н е т р а т ь т е с л и ш к о м м н о г о в р е м е н и н а т е р м и н о л о г и ю р а з р а б о т ч и к о в , ограничьтесь теми понятиями, к о т о р ы е объяснит вам преподаватель. В дальнейшем для изучения главы 13 мы р е к о м е н д у е м сделать у ч е б н о е пособие в виде таблицы, представлен ной на рис. 13.4, и включить в н е г о материал этой главы. Обзор В этой главе мы описываем п р о ц е с с р а з р а б о т к и п р о г р а м м н о г о о б е с п е чения в той же последовательности, в к а к о й он п р о х о д и т и в ж и з н и . Параллельно мы описываем и технологии тестирования, соответствующие к а ж д о й стадии р а з р а б о т к и . Вот о б щ и й перечень разделов этой главы. • О б з о р стадий р а з р а б о т к и • Стадии планирования • Тестирование на этапе планирования • Стадии проектирования • Тестирование на этапе проектирования • Тестирование "стеклянного ящика" на стадии кодирования • Регрессионное тестирование • Тестирование " ч е р н о г о я щ и к а " • С о п р о в о ж д е н и е Серьезные программные продукты редко разрабатываются одиночками: обычно этим занимаются группы людей, иногда довольно многочисленные. В такой группе, называемой командой разработчиков (development team), у каждого сотрудника своя роль. Даже если вам приходилось создавать про граммы абсолютно самостоятельно или в паре с приятелем, это просто означает, что вы по очереди или одновременно выполняли функции всех необходимых членов команды. Давайте рассмотрим стандартный набор функций, выполняемых членами команды разработчиков, предположив для простоты, что каждая роль принадлежит отдельному сотруднику. Конечно, на практике в большинстве маленьких компаний сотрудники часто выпол няют по нескольку функций. • Руководитель проекта (project manager, также называемый software development manager или producer) отвечает за качество программно го продукта, планирование работ и составление бюджета разработ ки. Мы будем считать, что все отчеты проектировщиков и разработчиков непосредственно передаются ему. • Проектировщиков (designers) продукта может быть несколько и среди них следующие. Глава 3: Типы тестов ... 53 Разработчик архитектуры (architect) определяет общую внутрен нюю структуру кода и данных, принципы обмена данными меж ду связанными программами и их совместного использования, а также стратегию разработки совместно и повторно используемых модулей. Разработчик архитектуры может также составлять план тестирования "стеклянного ящика" на самом верхнем уровне, анализировать технические обзоры всех спецификаций и разра батывать тесты для приемки продукта (проверяющие соответ ствие кода техническим требованиям). Специалист по анализу предметной области (subject matter expert или software analyst) должен понимать, чего хотят пользователи и как это выразить в терминах, понятных программисту или другому разработчику. Специалист по анализу человеческого фактора, или специалист по эргономике (human factor analyst или ergonomist), имеет психологи ческое образование и знает, как спроектировать программу, что бы она была полезной и удобной, и как тестировать продукт (или его прототип) на соответствие этим качествам. Некоторые из специалистов настолько хорошо разбираются в вопросах проек тирования и программирования, что могут непосредственно раз рабатывать пользовательский интерфейс программ. Впрочем, таких специалистов гораздо меньше, чем считающих себя тако выми. Остальные же принимают участие в разработке пользова тельского интерфейса совместно с программистами. Программист пользовательского интерфейса (user interface programmer) специализируется на создании пользовательского интерфейса программ. Обычно это профессиональный програм мист, который разбирается в оконной архитектуре и компьютер ной графике, а в идеальном варианте еще и обладает знаниями в области когнитивной философии. Пользовательский интерфейс — это, по сути, часть программы, предоставляющая пользователю информацию (в виде графики, текста, звука, в печатном виде и т.п.) и получающая от него от ветные данные (через клавиатуру, мышь и другие устройства вво да), которые затем передаются для обработки основной программе. Эту часть программы часто называют слоем представления и полу чения данных. Именно ее и пишет программист пользовательско го интерфейса. В более широком смысле понятие пользовательского интерфей са включает также содержание информации, которой пользова- 54 Часть I: Основы тель обменивается с программой. Например, разработчик польза вательского интерфейса решает, какие опции нужно предоставить пользователю, как понятно их описать и в каком виде отобра- зить. Хотя многие программисты считают, что могут проектиро вать пользовательский интерфейс так же хорошо, как и реализовывать, на самом деле большинство из них нуждается в сотрудничестве со специалистом по эргономике. Ведущие программисты (lead programmers) часто занимаются разра- боткой той части спецификации (технического задания), которая относится к внутренней структуре продукта. Во многих коман- дах, строящих работу по принципу консенсуса, программиста разрабатывают архитектуру продукта сами. • Менеджер по маркетингу {product manager или product marketing manager) отвечает за соответствие продукта долгосрочной стратегии и имиджу своей компании, а также за маркетинговую деятельность продолжающуюся после выпуска продукта (рекламу, выпуск и рас пространение новых версий, обучение продавцов и дилеров). В боль- шинстве компаний менеджер по маркетингу отвечает также и за рентабельность продукта. Он определяет требования рынка, а также те функции и возможности, от которых зависит его конкурентоспо собность. В определении набора функций продукта и оборудования, с которым он должен быть совместим, менеджер по маркетингу также играет самую активную роль. • Представитель группы технической поддержки (technical support) — это член или руководитель группы, непосредственно контактирующей с пользователями. Сотрудники этой группы анализируют жалобы пользователей, отвечают на их вопросы и предоставляют им необ- ходимую информацию. На этапе создания продукта они участвуют в проектировании программы и разработке документации, стараясь сделать ее как можно понятнее и минимизировать количество звон ков, на которые им потом придется отвечать. • Технические писатели (writers) — это члены группы документирования (documentation group), разрабатывающие руководство пользователя и интерактивную справку. Их советы часто помогают сделать програм му более простой и понятной. • Тестировщики (testers) также считаются членами команды разработ чиков. • В разработке специфических проектов принимают участие и другие специалисты: по компьютерной графике, надежности, защите, аппа ратному обеспечению, а также юристы, бухгалтера и т.д. Глава 3: Типы тестов 55 Ну а теперь, познакомившись с основными исполнителями, давайте перейдем к обзору самого процесса. Обзор стадий разработки Процесс разработки программного продукта можно разделить на не сколько стадий. Сначала его придумывают, затем создают, анализируют результат, устраняют его недостатки, затем продукт попадает к пользова телям, которые его эксплуатируют, а сотрудники отдела маркетинга ком пании анализируют пользовательский спрос. Когда продукт займет свое место на рынке, разработчики придумывают, как его усовершенствовать, вносят изменения и т.д. Могут быть выпущены десятки новых версий, после чего продукт наконец устареет и будет заменен принципиально но вым. Весь этот нелегкий жизненный путь продукта, начиная от появления у авторов самой первой идеи и заканчивая его уходом со сцены, мы назы ваем жизненным циклом {life cycle). В жизненном цикле продукта множество этапов. Обычно их описыва ют последовательно, как если бы они шли строго друг за другом — закан чивается один и начинается другой, — но на самом деле они в значительной степени перекрываются. Мы тоже опишем эти этапы после довательно, а о том, как они пересекаются, расскажем несколько позже — в главах 12 и 13. Вот пять основных этапов жизненного цикла программного продукта. • Планирование • Проектирование • Кодирование и написание документации • Тестирование и исправление недостатков • Сопровождение (после выпуска) и усовершенствование В своей книге Software Maintenance (Сопровождение программного обеспе чения) Мартин и Мак-Клер (Martin & mcClure, 1983, стр. 24) привели от носительную стоимость каждой их этих стадий. Вот эти цифры. Стадии разработки Производственная стадия Анализ требований 3% Промышленное производство и сопровождение 67% Спецификация 3% Проектирование 5% Кодирование 7% Тестирование 15% Впервые эти цифры были опубликованы Зелковицем, Шоу и Генноном (Zelkowitz, Shaw & Gannon) в 1979 году. По результатам их исследований 56 Часть I: Основы и данным Мартина и Мак-Клера, сопровождение программного продукта после его выпуска обходится дороже всего. На втором месте по стоимос- ти стоит тестирование — на него приходится 45% всей стоимости разработ- ки. В процессе сопровождения продукта при исправлении ошибок и внесении усовершенствований значительная часть затрат тоже приходится на тестирование. Продукт тестируют и исправляют практически на каждом этапе его жизненного цикла. При этом чем дальше продвигается работа, тем быст- рее растет стоимость тестирования. • На этапе разработки технических требований стоимость внесения изменений в документацию относительно невысока. Но после напи сания кода ситуация резко меняется: любое изменение проектной документации влечет за собой затраты и на переработку кода, час то гораздо более значительную, чем может показаться при оценке количества изменений в спецификации. • Когда программист сам находит свою ошибку и сам ее исправляет, это не влечет больших затрат. Ему не нужно взаимодействовать с другими сотрудниками, не нужно ничего никому объяснять. Ему незачем вносить описание ошибок в общую базу данных, служащую для контроля за их исправлением, а тестировщикам и руководите лю не нужно осуществлять этот контроль. Такая ошибка никого не задерживает и не мешает ничьей работе. • До выпуска программы ошибку исправить гораздо дешевле, чем после того, когда "заплатку" или новую версию приходится высы лать каждому пользователю — и это еще в лучшем случае, ведь может потребоваться и непосред ственный выезд сотрудника ком пании к заказчику. В 1976 г. Боэм (Boehm) опубликовал итоговые данные анализа затрат на тес тирование программных продуктов, про веденного в компаниях IBM, GTE и TRW. Из них следует, что чем позднее обнаруживается ошибка, тем дороже обходится ее исправление. Как показано на рис. 3.1, стоимость исправления оши бок растет экспоненциально: легче все го это делать на стадии планирования, а по мере перехода к проектированию, ко дированию, тестированию и сопровож дению она значительно увеличивается. Глава 3: Типы тестов ... 57 разработка программного обеспечения для американских воздушных сил обошлась (для одного компьютера) в $75 в пересчете на одну программную инструкцию, а его сопровождение стоило уже $4 тыс. на инструкцию. Чем раньше найти и исправить ошибку, тем дешевле это обойдется. Подробное обсуждение стадий разработки программного обеспечения можно найти в работах Де Грейса и Стала (DeGrace & Stahl, 1990), Май- ерса (Myers, 1976) и Роутзейма (Roetzheim, 1991). А детальный анализ сто имости разработки приводили Боэм (Boehm, 1981), Джонс (Jones, 1991) и Волвертон (Wolverton, 1974). Стадии планирования В команде планирования программного продукта должны быть ведущие инженеры, персонал, отвечающий за маркетинг и продажи, и руководите ли проекта. Эта команда вырабатывает общие характеристики продукта. В результате ее работы на свет появляется всего несколько документов, оп ределяющих дальнейшую разработку. Определение целей Планирование начинается с формирования общего видения продукта. Составляемый при этом документ не отличается детальностью. В нем мо жет быть описан пользовательский интерфейс, требования к надежности программного продукта и его производительности. В этом же документе оп ределяется предполагаемая стоимость продукта и затраты на его разработ ку. Он разрабатывается прежде всего для того, чтобы поставить перед командой разработчиков конкретную цель. При этом конечный результат может не соответствовать первоначальному описанию. Анализ требований Требования к программному продукту, вырабатываемые на этом этапе, должны быть выполнены обязательно. Они носят функциональный харак тер, а как реализовать их практически — это уже решают разработчики. Перечень требований может охватывать стоимость будущего продукта, его производительность, надежность, а также некоторые элементы пользова тельского интерфейса. То, насколько подробно все это описывается, зави сит от специфики разработки. В требования к программному продукту или другие документы, выра батываемые на ранних стадиях планирования, включаются также и требо вания к аппаратному обеспечению. Чтобы не усложнять материал, в этой 58 Часть I: Основы главе мы не будем касаться таких специфических вопросов, как одновре- менная разработка аппаратного и программного обеспечения или периоди ческое повышение требований к аппаратному обеспечению в соответствии с его развитием. Будем исходить из предположения, что типы аппаратных средств, на которые ориентирован программный продукт, известны с само го начала разработки. Определение функциональных характеристик программного продукта Определение функциональных характеристик можно представить как мост между требованиями к программному продукту и будущими инженер но-проектными документами. Требования к продукту связаны прежде всего с маркетингом и важны именно для этого отдела. Инженеру же нужно нечто более определенное, полное и конкретное. Это "нечто" и есть фун кциональные характеристики, среди которых он найдет перечень функций будущего программного продукта и описание входных и выходных доку ментов. Способов реализаций этих функций данный документ не касает ся, только в самых необходимых случаях, когда это поможет понять документ, в нем может быть в общих чертах описана возможная реализа ция, но конечная внутренняя и внешняя структура продукта, скорее все го, окажется совсем иной. Прекрасной моделью для разработки функциональных характеристик может быть документ IEEE Software Requirements Specification (руководство IEEE по определению требований к программному обеспечению, стандарт ANSI/IEEE 830-1984). |