Тестирование-книга. Ю. Н. Артеменко Научный редактор
 Скачать 6.27 Mb.
|
|
Тестирование на этапе планирования На этом этапе пока еще тестируются не программы — "тестируются" идеи. К их анализу привлекаются специалисты по маркетингу, руководи тели проекта, главные конструкторы и специалисты по анализу человечес кого фактора. А вот члены группы тестирования участвуют в этой работе очень редко. (В главе 13 рассказывается о том, какую полезную работу могут выполнять специалисты по тестированию на этапе планирования продукта.) Группа аналитиков читает черновики проектных документов. Затем она; собирает информацию, которая может оказать помощь в их оценке и даль нейшем планировании. Для этого существует несколько стандартных спо собов: сравнительный анализ, дискуссионные группы и обследование объекта. Результаты каждой из этих процедур могут привести к значитель ному пересмотру существующих планов. Глава 3: Типы тестов ... 59 При анализе и оценке требований к продукту и его функциональных характеристик специалисты прежде всего пытаются выяснить следующее. • Адекватны ли эти требования? Действительно ли именно такой продукт компания хочет создать? • ПОЛНЫ ли они? Не упущены ли какие-нибудь еще полезные или даже жизненно необходимые функции? Нельзя ли ослабить какие- либо из перечисленных требований? • Совместимы ли требования между собой? Требования к продукту (и его функции) могут оказаться логически или психологически несовместимыми. Логическая несовместимость означает их противо речивость, а психологическая — концептуальные разногласия (разоб равшись с одной из функций, пользователь может не понять другую). • Выполнимы ли они? Не требуется ли для нормальной эксплуатации продукта более быстрое аппаратное обеспечение, больший объем памяти, более высокая пропускная способность, большее разреше ние (и т.д.), чем указано в документации? • Разумны ли они? К сожалению, качество продукта и его рентабель ность стоят по разную сторону баррикад: с одной стороны — про изводительность продукта, его надежность и нетребовательность к ресурсам, а с другой — время и стоимость его разработки. Найдено ли самое оптимальное соответствие между всеми этими характери стиками? Не требуется ли от продукта абсолютная безупречность, молниеносная работа и готовность конкурировать с программным обеспечением, которого еще нет и в проекте, — и все это на ком пьютерах i286? Отдельные из тих требований вполне достижимы, но не одновременно и не для одного и того же продукта. Поэтому одним из ключевых вопросов планирования является правильная расста новка приоритетов. • Поддаются ли они тестированию? Насколько легко можно будет определить, соответствует ли инженерно-проектная документация требованиям к программному продукту. Если вам нужно будет выполнить анализ требований к продукту, опи райтесь на перечисленные выше вопросы. О других важных проблемах и соображениях на эту тему можно почитать у Данна (Dunn, 1984), Гауса и Вейнберга (Gause & Weinberg, 1989) и в документе ANSI/IEEE Standard 830. Ну а теперь, выяснив, что прежде всего интересует группу аналитиков, Давайте перейдем к более подробному обсуждению методов их работы. 60 Часть I: Основы Сравнительный анализ существующих программных продуктов Чтобы выполнить сравнительный анализ продуктов, специалист выяс няет, какие похожие продукты уже имеются на рынке и чем продукт его фирмы будет от них отличаться. Что поможет выиграть в конкурентном соревновании? Какие функции имеющихся продуктов необходимо вклю чить и в свой? Для такого анализа необходимы или рабочие копии конкурирующих продуктов, или, по крайней мере, их демонстрационные версии или опи сания, если ничего больше достать не удастся. Составляется перечень их функций, их сильных и слабых сторон и тех характеристик, которые отме чаются в прессе и профессиональных изданиях как достоинства и недостат ки этих продуктов. Продукты разделяются по занимаемым ими сегментам рынка или по специфическим назначениям. Затем составляется детальный отчет обо всех конкурирующих продуктах, включая и те, которые только собираются появиться на рынке. В отчет включается четко структурирован ное описание каждого продукта, и такое же описание составляется для будущего продукта компании. На основании отобранных таким образом данных можно ответить на ключевые вопросы проводимого анализа. На сколько конкурентоспособен разрабатываемый продукт? Почему потенци- альные пользователи захотят купить именно его? Вначале такой анализ ведет к расширению требований к продукту и его функциональных характеристик. Специалисту хочется реализовать в нем все лучше, что имеется у конкурентов, воплотить в нем сотни почерпну- тых им замечательных идей. Но тут наступает самое время вспомнить о здравом смысле. Реализация всех этих идей стоит слишком дорого и не может быть выполнена в реальные сроки. Кроме того, они основаны на различных концепциях и просто не уживутся в одной программе. Но даже если отобрать из них только совместимые с выбранной концепцией, про граммный продукт, имеющий столько функций (пусть даже самых распрек расных), будет таким сложным и громоздким, что едва ли кому-нибудь понравится. (За дополнительной информацией по этому вопросу обратитесь к книгам Рубенштейна и Херша (Rubenstein & Hersh, 1984) и Нормана (Norman, 1988)). Бывает, что специалисты игнорируют проблемы совместимости функ-, ций и сложности программного продукта. Они составляют длинный список удачных идей конкурентов. Сам по себе этот список может быть очень полезным, но если рассматривать его как требования к продукту, тогда его нужно очень серьезно сократить. И помогут отобрать самое существенное два следующих метода: дискуссионные группы и обследование объекта. Глава 3: Типы тестов ... 61 Дискуссионные группы Каждый продукт предназначается для определенного сегмента рынка. Целью данного метода анализа является определение ключевых требований этого сегмента. Для этого аналитик отбирает небольшую группу людей, которые, по его мнению, являются наиболее типичными представителями нужного сегмента рынка. Члены группы не знают друг друга. Аналитик предлагает им обсу дить определенную тему. (Тем может быть и несколько, но очень немно го.) Он может направлять дискуссию, задавая наводящие вопросы и концентрируя внимание группы на заданной теме, а может и не участво вать в обсуждении вовсе. Если аналитик не умеет грамотно направлять дис куссию, он может нанять для этого соответствующего специалиста. Его цель — выяснить реакцию рынка на предложенную идею, но ни в коем случае ни в чем не убеждать членов группы. Такая дискуссия может осветить самые различные аспекты обсуждаемой проблемы. Аналитик может понять, чего пользователи хотят от данного типа продуктов, как они его используют, какие функции для них наиболее важны. Можно сконцентрировать группу и на одной конкретной функции продукта или на одной цели его применения. Можно использовать группу для генерации идей еще до детального планирования, а можно проанали зировать ее реакцию на элементы уже готового плана. Обследование объекта Каждый продукт предназначается для полной или частичной автомати зации выполнения некоторой задачи, возможно, очень сложной. Чтобы как можно четче представить себе эту задачу, аналитик выполняет обследова ние объекта автоматизации. Он наблюдает людей за работой, беседует с ними, пытается выявить все, в чем продукт может помочь своим будущим пользователям. Аналитик спрашивает себя, в чем же конкретно состоит изучаемая им задача. Как люди выполняют ее без проектируемого продук та? Какова последовательность их действий? Почему она именно такая? В какой момент работнику нужна каждая конкретная информация и для чего? Что особенно сильно замедляет его работу, и почему эта проблема не решена до сих пор? Работа специалиста по обследованию является частью проектирования продукта и жизненно необходима для разработки как его пользовательского интерфейса, так и внутренней структуры. Хотя обследование объекта может быть выполнено и после определения требований к продукту, по его результатам эти требования могут быть сильно изменены. Более подробную информацию об анализе задания путем обследования автоматизируемого объекта можно найти в книгах Бейлей (Bailey, 1989), 62 Часть I: Основы Карда, Морана и Ньюэлла (Card, Moran & Newell, 1983), Хеландера (Helander, 1991, особенно глава 38), Нормана и Дрейпера (Norman & Draper, 1986, часть IV), Рубенштейна и Херша (Rubenstein & Hersh, 1984). Кроме того, ряд интересных примеров приведен в книге Бейкера и Баксто- на (Baecker & Buxton, 1987). Стадии проектирования На этапе проектирования группа соответствующих специалистов реша ет, как будут реализованы запланированные возможности продукта. Они разрабатывают внешний дизайн программного продукта (то, каким будет продукт с точки зрения пользователя) и его внутреннюю структуру. Обе эти составляющие тесно взаимосвязаны и проектируются одновременно. Разрабатывая проект, специалисты опираются на требования к продук ту. Если этого документа нет, если он неполон или постоянно меняется, им приходится планировать функции продукта самим. По классической модели разработки программного обеспечения коди рование начинается только по завершении проектирования. Это, конечно, не касается прототипа, который создается в рамках проектирования для анализа будущего продукта. Впрочем, на практике довольно значительная часть кода прототипа может оказаться в конечном продукте. На этапе проектирования могут быть написаны и некоторые низкоуровневые проце дуры — те, к которым предъявляются наиболее строгие требования по скорости и потреблению ресурсов. Существуют и альтернативные подходы к проектированию, мы поговорим о них в главах 12 и 14. Хорошими учебниками по проектированию программного обеспечения являются книги Йордана (Yourdon, 1975), Джонса (Jones, 1979) и Майерса (Myers, 1976). Внешний дизайн Описание внешнего дизайна программного продукта включает полное описание его пользовательского интерфейса, в частности, все экранные и печатные формы. Иногда, если работа выполняется под конкретного заказ чика, внешний дизайн программного продукта могут определять его пользователи. Они сами пишут часть проектных документов в тех терми нах, которые им понятны. В процессе разработки продукта его внешний дизайн может многократ но изменяться, поскольку при кажущейся второстепенности именно эта часть системы имеет ключевое значение. Кого будет интересовать, что программный код продукта безупречен, если какая-то часть интерфейса вызывает у пользователей затруднения, путает их, ведет к ошибкам, раздра жает или является недостаточно гибкой и функциональной — не делает Глава 3: Типы тестов ... 63 того, что, по мнению пользователей, она обязательно должна уметь. Однако работая над внешним дизайном, нужно понимать, что даже в наиболее тщательно продуманной системе в процессе ее эксплуатации все равно обнаружатся некоторые недостатки. Чтобы лучше познакомиться с вопросом, можно прочесть интересную, несмотря на то что она написана еще в 1973 году, работу Мартина (Martin), более недавнее исследование Хеландера (Helander, 1991), а также класси ческие работы Бейкера и Бакстона (Baecker & Buxton, 1987), Карда, Мора на и Ньюэлла (Card, Moran & Newell, 1983) и Рубенштейна и Херша (Rubenstein & Hersh, 1984). Внутренняя структура Описание внутренней структуры программного продукта определяет набор будущих программных модулей (программную архитектуру), структу ру, взаимосвязи и принципы хранения и обработки данных (организацию данных) и алгоритмы работы программы. Проектирование программной архитектуры Как правило, каждую задачу можно разбить на четкие подзадачи, кото рые, в свою очередь, тоже можно разбить на еще меньшие элементы и т.д. Такое разбиение, называемое декомпозицией, выполняется до тех пор, пока не будут выделены достаточно самостоятельные элементы, которые мож но реализовать в виде отдельных программных модулей или процедур. Обычно сложные программные продукты реализуются в виде системы — набора связанных между собой полноценных программ. Такие програм мы часто называют процессами, особенно если они работают параллельно. (Не следует путать это понятие с одноименным термином Windows. — Примеч. ред.) Хотя процессы могут работать и независимо, как правило, они взаимодействуют между собой. Например, они могут использовать одни и те же данные, или один из них может выполнять определенные задания по запросу другого. Документация, определяющая принципы и правила взаимодействия процессов системы, называется протоколом. В описании программной ар хитектуры системы определяются ее основные компоненты и использую щиеся для их взаимодействия коммуникационные протоколы. Как и любые другие программы, процессы поддаются декомпозиции. Разбиение программы на модули называют модульной декомпозицией. Под модулем в данном случае понимают часть кода, которая может рассматри ваться как независимое целое и имеет единственную точку входа. В терми нологии программиста этому определению соответствуют процедуры и Функции 1 . Обычно модуль реализует либо одно конкретное задание, либо четко определенную группу заданий, для выполнения которых другие мо- 64 Часть I. Основы дули могут его вызывать. Вызывающий модуль передает вызываемому для обработки некоторые данные, а тот, в свою очередь, возвращает результат. Хорошим введением в логическое и структурное проектирование может служить книга Йордана (Yourdon, 1975). После нее можно прочесть книгу Йордана и Константайна (Yourdon & Constantine, 1979). Проектирование организации данных Разработчик структуры данных должен ответить на следующие принци пиальные вопросы. • Какие данные обрабатывает программа и какова их структура? Обрабатываемые программой данные могут быть достаточно просты ми, как переменные различных типов, а могут представлять собой огромные массивы взаимосвязанной информации, которые тщатель- но анализируются и организуются в реляционные базы данных. • Как осуществляется доступ к данным? Данные могут храниться в памяти или на постоянных носителях, и доступ к ним может осуще- ствляться просто по имени или через определенные специально для этого написанные функции. Данные могут быть общедоступными, или же их чтение и изменение может строго регулироваться. • Каковы принципы наименования данных? Применяются ли в данной разработке определенные соглашения об именах? Должны ли имена. быть достаточно понятными, чтобы программист, который будет осу ществлять сопровождение продукта в дальнейшем, мог по ним понять назначение данных. • Как хранятся данные? Определенные данные будут храниться на постоянном носителе. В каком формате они будут храниться? Как к ним будет осуществляться доступ? Какие для этого понадобятся дополнительные программные средства? Из рассказа о проектировании программной архитектуры неявно следо вало, что программный продукт прежде всего анализируется с точки зре ния его функций, а уже затем — обрабатываемых данных. На самом же деле код и данные представляют собой единое целое. Например, модули, обращающиеся к одним и тем же данным, оказываются связанными самым тесным образом, даже если они выполняют над этими данными совершен но разные операции. Если структура данных меняется, все обращающие ся к ним модули приходится переписывать. Вот почему очень полезно строить концепцию программы с позиций обрабатываемых ею данных. С этой точки зрения программа — это нечто, что последовательно преобразует данные, от входной информации через ряд промежуточных стадий до выходной информации, которая может, Глава 3: Типы тестов ... 65 например, представлять собой сгенерированный по запросу пользователя отчет. Модули же рассматриваются как функциональные элементы, необ ходимые для различных операций, выполняемых над данными: один мо дуль нужен для ввода информации, другой выполнит над ней конкретные вычисления, а третий выведет результат. Таким образом, модули могут характеризоваться входными и выходными данными и возникать по мере потребности в их преобразовании. При таком анализе выявляются те свя зи между программными единицами, которые при изучении продукта толь ко с функциональной точки зрения могли бы быть утеряны. Сравнительный анализ различных методологий проектирования можно найти у Бергланда (Bergland, 1981). О разработке структур данных расска зывается в книгах Гейна и Сарсона (Gane & Sarson, 1979) и Йордана и Константайна (Yourdon & Constantine, 1979). А об ориентированном на данные подходе к тестированию можно прочесть у Бейзера (Beizer, 1990). Описание алгоритмов Проектирование программного продукта не заканчивается описанием программных модулей и организации данных. Нужно еще продумать, как именно будут реализовываться поставленные задачи. Обычно это делается программистами. Они выбирают оптимальные алгоритмы и описывают (иногда довольно подробно) последовательность логических шагов, необ ходимых для выполнения каждой задачи. Хорошим учебником по преобразованию высокоуровневых задач в про граммный код может служить книга Йордана (Yourdon, 1975). Моделирование Чтобы лучше представить себе будущий программный продукт, на этапе проектирования может быть разработан его прототип — программная мо дель всего продукта или его части. Прототип строится очень быстро и с минимумом затрат. Его очень легко менять, и он не выполняет никакой реальной работы. Иногда моделирование выполняется не только для внешнего дизайна, но и для внутренней структуры системы. При нисходящем проектировании система разбивается на несколько самостоятельных процессов или модулей, они, в свою очередь, разбиваются на меньшие модули и т.д. В том же порядке выполняется и их кодирование: сначала пишутся модули более высокого уровня, а затем те, которые они вызывают. Однако бывает и так, что подпрограммы нижних уровней в значительной мере определяют всю разработку. Например, системе может потребоваться низкоуровневый об работчик прерывания, вся работа которого выполняется за 60 микросекунд. Этот обработчик разумнее всего будет написать заранее, чтобы убедиться, что это вообще возможно. В случае неудачи другие модули придется пере проектировать. 66 Часть I: Основы Как правило, прототип создается для оценки функциональности буду щей системы и ее пользовательского интерфейса. Это исключительно по лезная технология: когда люди получают возможность собственноручно поэкспериментировать с системой или ее прототипом, их требования зна чительно изменяются. Идеи, которые в спецификации казались просто блестящими, в работающей модели могут утратить всю свою привлекатель ность. (Мартин и Мак-Клер (Martin & mcClure, 1983), Вассерман и Шью- мейк (Wasserman & Shewmake, 1985)). Мартин и Мак-Клер настоятельно рекомендуют писать прототипы на том же языке, на котором будет реализован конечный продукт: если про тотип окажется удачным, то конечный продукт может разрабатываться прямо на его основе. Однако, на наш взгляд, так поступать не стоит, и вот почему. • Многие языки или системы разработки не подходят для создания быстрого и дешевого прототипа. • Хороший совет дали в своих книгах Брукс (Brooks, 1975) и Керни- ган и Плугер (Kernigan & Plauger, 1974). Они рекомендуют отложить первый черновик программы и начать ее разработку с чистого ли ста. Особенно это касается прототипа. Ведь от него не требуется хорошая внутренняя организация. Он может работать медленно и неэффективно, а то и вообще неправильно. Согласитесь, что такая программа не лучшая основа для хорошей разработки. Да и разра ботчики прототипа будут чувствовать себя гораздо свободнее, если будут думать только о скорости и не беспокоиться, что допущенные ими ошибки и неверные решения впоследствии затруднят програм мирование. Вопросы моделирования интерфейса, стратегий оценки проекта и тех нологий его разработки обсуждаются в книгах Де Грейса и Стала (DeGrace & Stahl, 1990), Хеландера (Helander, 1991), Рубенштейна и Херша (Rubenstein & Hersh, 1984), Оулда (Ould, 1990) и Шнейдермана (Schneiderman, 1987). Тестирование на этапе проектирования На этапе проектирования, как и на этапе планирования, кода еще нет, поэтому и здесь тестируются только идеи. Однако на этот раз идеи гораз до лучше формализованы и описаны намного подробнее, чем в первона чальных планах. Анализируя проектные документы, специалисты должны составить очень четкое представление о работе будущей системы. Специ алисты по тестированию могут и не участвовать в работе группы аналити ков, однако для планирования системы будущих тестов такое участие очень полезно. (На совещаниях группы аналитиков специалистам по тестирова- Глава 3: Типы тестов ... 67 нию лучше всего быть пассивными участниками и высказываться только в случае необходимости.) На этапе проектирования в центре внимания ана литиков должны быть следующие вопросы. • Действительно ли проект хорош? Будет ли на его основе создан эффективный, компактный, хорошо тестируемый и легкий в сопро вождении и модернизации продукт? • Соответствует ли проект требованиям? Проект должен быть формализованным выражением требований, представленных в доку ментации этапа планирования. • Полон ли проект? Описывает ли проект все взаимосвязи между модулями и данными, передачу данных между модулями, условия работы каждого модуля и их реализацию. • Достаточно ли он реалистичен? Удовлетворяют ли имеющиеся системные ресурсы (как аппаратные, так и программные) потребно стям проекта? Сможет ли программный продукт работать достаточ но быстро, достаточно быстро извлекать информацию из баз данных и ее обрабатывать? Удачно ли выбраны инструментальные средства разработчиков? • Хорошо ли описана в проекте подсистема обработки ошибок? При нисходящем проектировании особенно велико искушение оставить вопросы обработки ошибок на потом — как самые незначительные. И когда наступает это "потом", о подобных элементах часто вооб ще забывают, или же из-за нехватки времени они проектируются наспех, поверхностно и в результате — плохо. Все возможные усло вия возникновения ошибок должны быть самым тщательным обра зом продуманы и описаны в проекте. Важно правильно определить уровень, на котором обрабатывается каждая из ошибок, чтобы ее возникновение в одном модуле не вело к ошибкам в других. О многих возможных ошибках проектирования и критериях оценки проектных документов рассказывается в книгах Данна (Dunn, 1984) и Фридмана и Вейнберга (Freedman & Weinberg, 1982). Об анализе проекта можно также почитать и у Бейзера (Beizer, 1990). Совещания аналитиков Обычно целью совещаний, проводимых при анализе проектных доку ментов, является не решение проблем, а прежде всего их выявление. В совещании должна участвовать небольшая группа сотрудников — около семи человек. В эту группу не должны входить авторы проекта. аналитики заранее читают документы и на совещании критикуют их и задают друг другу вопросы. Во многих компаниях проект вообще не счи- 68 Часть I: Основы тается завершенным, пока на него не будет составлена формальная рецен-| зия (разумеется, одобрительная). Таким образом, проект перерабатывает-; ся и снова анализируется до тех пор, пока он не будет одобрен группой аналитиков. Совещания этой группы могут быть трех типов: обзорные, ин спекционные и рецензионные. • Обзорное совещание. На таком совещании проектировщики демонстри руют модель программы. Шаг за шагом они показывают, что делает программа с тестовыми данными, предложенными аналитиками. Такая демонстрация позволяет увидеть, как взаимодействуют между собой различные части системы, и выявить ее недостатки: неудобные ре жимы, избыточность функций или пропущенные детали. • Инспекционное совещание. На таком совещании специалисты под робно анализируют каждый элемент проекта или его отдельный аспект: обработку ошибок, соответствие ранее выработанным стан дартам, эффективность реализации конкретной функции и т.д. • Рецензионное совещание. К этому совещанию аналитики готовят список возникших у них вопросов. Они делятся своими соображе ниями и выделяют элементы проекта, которые показались им неточ ными или сомнительными. Цель этого совещания — сформировать список всех выявленных проблем и убедиться, что каждую из них проектировщики правильно поняли. Решение выявленных проблем в задачи совещания не входит. Идеальное рецензионное совещание должно направляться опытным в этом деле специалистом и обязательно записываться. Такой специалист- организатор находит подходящее помещение, ведет совещание, останавли вает говорящих, когда они прерывают друг друга или отклоняются от темы, и готовит итоговый отчет. Он следит за тем, чтобы от обсуждения проблем аналитики не переходили к обсуждению способов их решения. Это будет сделано позднее меньшей группой специалистов и вне рецензионного со вещания. Специальный персонал записывает все важные замечания и с помощью проекторов или другой аналогичной техники выводит их на большой экран, где они видны каждому участнику совещания. Любой, кому покажется, что записывающий упустил нечто важное, может попросить отобразить эту ин формацию. Обязательно должно фиксироваться каждое достигнутое согла шение. Записаны должны быть и все вопросы, которые остались открытыми до следующего совещания. Такая техника проведения совеща ний исключительно способствует их продуктивности, особенно когда мне ния аналитиков очень сильно расходятся. Некоторые группы тестирования специально обучают свой персонал ведению и протоколированию таких совещаний. Это прекрасная идея, Глава 3: Типы тестов ... 69 поскольку хороших специалистов в этом деле очень мало. Подробнее о технике проведения совещаний можно узнать из книг Дойла и Страуса (Doyle & Straus, 1976), Фридмана и Вейнберга (Freedman & Weinberg, 1982) и Гауса и Вейнберга (Gause & Weinberg, 1989). Анализ псевдокода Псевдокод (структурированный русский) — это искусственный язык, комбинирующий конструкции реального языка программирования с опи саниями действий на русском языке. Например, следующее описание из главы 1 представляет собой псевдокод. IF АSСII_КОД_ВВЕДЕННОГО_СИМВОЛА меньше 48 (48 — это ASCII-код для 0) THEN отвергнуть символ как недопустимый ELSE IF АSСII_КОД_ВВЕДЕННОГО_СИМВОЛА больше 57 (57 — это ASCII-код для 9) THEN отвергнуть символ как недопустимый ELSE это цифра, принять ее. Когда процесс проектирования подходит к разработке наиболее подроб ных документов, такая форма описания логики программы оказывается очень удобной и многие проектировщики с удовольствием ею пользуются. Если для описания программы пользоваться достаточно строго форма лизованной версией псевдокода, это описание можно будет проанализиро вать с помощью специальной программы — анализатора псевдокода. Эта программа выявит модули, которые ни разу не вызываются, составит спи сок всех обращений к каждому модулю и выполнит другую полезную ра боту. Если в вашей компании принято очень детально проектировать про граммные средства, обратитесь к работе Данна (Dunn, 1984) — в ней вы найдете описания некоторых полезных инструментальных средств. Тестирование "стеклянного ящика" на стадии кодирования И вот наконец наступает этап кодирования: программист пишет про граммы и сам их тестирует. Мы предполагаем, что вы знаете, что такое кодирование, и поэтому не описываем его процесс в этой книге. Зато достойна описания технология тестирования, которая применяет- ся на этом этапе. Эта технология называется тестированием "стеклянного ящика " (glass box) — иногда ее еще называют тестированием "белого ящика " white box) в противоположность классическому понятию "черного ящика" black box). 70 Часть I: Основы При тестировании "черного ящика" программа рассматривается как объект, внутренняя структура которого неизвестна. Тестировщик вводит данные и анализирует результат, но, как именно работает программа, он не знает. Подбирая тесты, специалист ищет интересные с его точки зрения входные данные и условия, которые могут привести к нестандартным ре зультатам. Интересны для него прежде всего те представители каждого класса входных данных, на которых с наибольшей вероятностью могут про явиться ошибки тестируемой программы. При тестировании "стеклянного ящика" ситуация совершенно иная. Тестировщик (как правило, это программист) разрабатывает тесты, основы ваясь на знании исходного кода, к которому он имеет полный доступ. В результате он получает следующие преимущества. • Направленность тестирования. Программист может тестировать программу по частям, разработать специальные тестовые подпрог- раммки, которые вызывают тестируемый модуль и передают ему ин тересующие программиста данные. Отдельный модуль гораздо легче протестировать именно как "стеклянный ящик". • Полный охват кода. Программист всегда может определить, какие именно фрагменты кода работают в каждом тесте. Он видит, какие еще ветви кода остались непротестированными и может подобрать условия, в которых они будут выполнены. В этой и одиннадцатой главе мы еще вернемся к тому, как отслеживать степень охвата программного кода проведенными тестами. • Управление потоком. Программист всегда знает, какая функция должна выполняться в программе следующей и каким должно быть ее текущее состояние. Чтобы выяснить, работает ли программа так, как он думает, программист может включить в нее отладочные ко манды, отображающие информацию о ходе ее выполнения, или воспользоваться для этого специальным программным средством, называемым отладчиком. (Отладчик может делать очень много по лезных вещей: отслеживать и менять последовательность выполне ния команд программы, показывать содержимое ее переменных и их адреса в памяти и многое другое.) • Отслеживание целостности данных. Программисту известно, какая часть программы должна изменять каждый элемент данных. Отсле живая состояние данных (с помощью того же отладчика), он может выявить такие ошибки, как изменение данных не теми модулями, их неверная интерпретация или неудачная организация. Программист может и самостоятельно автоматизировать тестирование. Об автома тизированном тестировании мы еще поговорим с вами в главе 11. Глава 3: Типы тестов ... 71 • Внутренние граничные точки. В исходном коде видны те граничные точки программы, которые скрыты от взгляда "извне". Например, для выполнения определенного действия может быть использовано несколько совершенно различных алгоритмов, и, не заглянув в код, невозможно определить, какой из них выбрал программист. Еще одним типичным примером может быть проблема переполнения буфера, используемого для временного хранения входных данных. Программист сразу может сказать, при каком количестве данных буфер переполнится, и ему не нужно при этом проводить тысячи тестов. • Тестирование, определяемое выбранным алгоритмом. Для тестиро вания обработки данных, использующей очень сложные вычисли тельные алгоритмы, могут понадобиться специальные технологии. В качестве классических примеров можно привести преобразование матрицы и сортировку данных. Тестировщику нужно точно знать, какие алгоритмы используются, и обратиться к специальной литера туре. Тестирование "стеклянного ящика" мы рассматриваем как часть про цесса программирования. Программисты выполняют эту работу постоянно, они тестируют каждый модуль после его написания, а затем еще раз пос ле интеграции его в систему. Этому их учат еще в учебных заведениях. В большинстве учебников по тестированию именно этому его виду отводит ся основная роль. Однако в этой книге мы уделяем основное внимание тестированию "черного ящика", и именно ему посвящают большую часть времени все профессиональные тестировщики. (Отдельную и достаточно специфичес кую область тестирования представляют собой СУБД для мэйнфреймов. Об их тестировании лучше рассказывают такие авторы, как Бейзер (Beizer), Хетзел (Hetzel) и Майерс (Myers).) Тестировщик "черного ящика" не изу чает исходный код программы — он исследует ее извне, работая с ней так, как это будет делать пользователь. И так же, как исследование программы изнутри позволяет выявить проблемы и критические точки, которых не видно извне, так и тестировщик "черного ящика" выявляет ошибки и недостатки, которые программист упускает. К вопросу о выборе метода тестирования мы еще вернемся в главе 12. А в следующих разделах мы поговорим об основных концепциях тестиро вания "стеклянного ящика", без знания которых вы не сможете считаться профессионалом в своем деле. 72 Часть I: Основы Структурное тестирование против функционального Структурное тестирование является одним из видов тестирования "стек лянного ящика". Его главной идеей является правильный выбор тестиру емого программного пути. В противоположность ему функциональное тестирование относится к категории тестирования "черного ящика". Каждая функция программы тестируется путем ввода ее входных данных и анализа выходных. При этом внутренняя структура программы учитывается очень редко. Более подробное описание этих двух технологий можно найти у Бей- зера (Beizer, 1984). Как указывает Данн (Dunn, 1984), хотя структурное тестирование и, имеет под собой гораздо более мощную теоретическую основу, большин ство тестировщиков предпочитают функциональное тестирование. Струк турное тестирование лучше поддается математическому моделированию, но это совсем не означает, что оно эффективнее. Каждая из технологий по- зволяет выявить ошибки, пропускаемые другой, в этом смысле их можно; назвать одинаково эффективными. Тестирование программных путей: критерии охвата Мы уже упоминали о путях выполнения программы — последователь ностях команд, которые она выполняет от старта до завершения. Объектом тестирования может быть не только полный путь, но и его отдельные уча стки. Как уже было сказано в главе 2, протестировать все возможные пути выполнения программы абсолютно нереально. Поэтому специалисты по тестированию выделяют из всех возможных путей те группы, которые нужно протестировать обязательно. Для отбора они пользуются специаль ными критериями, называемыми критериями охвата (coverage criteria). B отличие от нереальной идеи полного тестирования, эти критерии опреде- ляют вполне реальное (пусть даже и достаточно большое) количество тес- тов. Критерии охвата иногда называют логическими критериями охвата или критериями полноты. В этом разделе мы познакомимся с тремя критерия ми, которые используются тестировщиками чаще всего: критериями охва та строк, ветвлений и условий. Когда тестирование организовано в соответствии с этими критериями, о нем говорят как о тестировании путей. Критерий охвата строк — наиболее слабый из всех. Он требует, чтобы каждая строка кода была выполнена хотя бы один раз. И хотя это гораздо больше, чем утруждают себя выполнить многие программисты, для серьез ного тестирования программы этого далеко не достаточно. Если строка со держит оператор принятия решения, проверены должны быть все) управляющие решением значения. Для примера давайте рассмотрим следу ющий фрагмент кода. ] |