Канер С. Тестирование программного обеспечения

Подождите немного. Документ загружается.

364 Часть III: Управление проектами и группами

Серьезнейшим недостатком метода водопада является то, что все клю-

чевые конструкторские решения должны быть приняты на этапе, когда

сотрудники еще не составили полного представления о продукте. В значи-

тельной степени оно формируется в ходе разработки, а до ее начала легко

ошибиться в оценках сложности или наилучшего способа реализации от-

дельных функций. Еще мало изучены конкурирующие программы. Еще не

сформировано четкое представление о разрабатываемом продукте — реаль-

ном, а не планируемом, поскольку, только поработав с программой доста-

точно долгое время, можно как следует оценить ее сильные и слабые

стороны, почувствовать ее характер. Все это станет возможно только пос-

ле создания первой работающей версии продукта.

Каковы же возможности руководителя проекта, который близок к за-

вершению, но не укладывается в сроки, если проект разрабатывается по

методу водопада?

• Функциональность. К этому моменту все требования к продукту уже

давно сформированы, спецификация готова, и если продукт нахо-

дится на тестировании, то и кодирование также завершено. Поэто-

му удаление функций в общем случае незначительно сокращает

время или стоимость разработки.

Если одна из функций спроектирована или реализована настолько

плохо, что всю работу необходимо переделать, тогда ее удаление из

продукта может пойти на пользу проекту. Однако, если от неудач-

ной функции зависят другие части продукта, сделать это уже не так

просто.

• Деньги. Поскольку спецификация полностью готова, ничего не стоит

подключить к проекту дополнительных программистов. Получив

четкое и ясное представление о поставленной задаче, они могут

сходу приступать к кодированию.

• Дата выпуска. Когда проделано столько подготовительной работы,

жалко от чего-либо отказываться. Поэтому, часто, когда все функ-

ции программы уже закодированы, принимается решение продлить

сроки разработки и провести все запланированное тестирование.

• Надежность. Если все функции уже написаны, подключен допол-

нительный персонал, а проект по-прежнему не укладывается в сро-

ки, остается только прекратить тестирование и выпустить продукт

как есть, со всеми оставшимися в нем ошибками. В этом случае

давление на тестировщиков невероятно возрастает, у них остаются

считанные дни на то, чтобы либо доказать, что продукт не готов к

выпуску, либо подтвердить, что в нем нет слишком серьезных оши-

бок. Последнее, впрочем, лишь предположение, базирующееся на

том факте, что подобных ошибок не выявлено в течение последних

дней.

Глава 13: Объединяющая 365

Итак, если проект разрабатывается по методу водопада и не укладыва-

ется в график, его руководитель может подключить дополнительный пер-

сонал, отложить дату выпуска или выпустить некачественный продукт.

Защитники этого метода утверждают, что многих неприятностей мож-

но избежать, если программисты с самого начала проанализируют требо-

вания и проектную документацию и тщательно спланируют свою работу.

Если же какую-либо из задач не продумать заранее, ее решение в дальней-

шем будет связано с большими проблемами. Тщательность предваритель-

ного планирования особенно важна в тех случаях, когда продукт

разрабатывается для одного пользователя или когда значительную часть

продукта составляет аппаратное обеспечение, которое невероятно дорого

перепроектировать.

Эволюционный метод

При эволюционном подходе к разработке программного продукта фун-

кции добавляются к нему последовательно, одна за другой.

Любая программа может обладать минимумальным количеством функ-

ций, а может быть напичкана всем, что только пришло в голову програм-

мисту. При эволюционном подходе продукт развивается в направлении от

первой крайности ко второй. Это значит, что вначале продумывается суть

будущей программы, ее идеология и основные задачи. Затем программис-

ты пишут ядро программы, спроектированное таким образом, чтобы ее

легко можно было расширять, добавляя все новые и новые возможности.

Набор функций ядра минимален, однако они все же составляют независи-

мую программу, готовую к тестированию. Ядро тестируется и отлаживает-

ся как полноценный продукт до тех пор, пока не получится вполне

стабильная программа.

Затем программисты добавляют к продукту новые функции — по одной

или небольшими связанными группами. После каждого такого добавления

программа проходит новый цикл тестирования и исправляется до тех пор,

пока снова не станет достаточно стабильной.

Процесс добавления функций и отладки программы продолжается до

тех пор, пока не получится достаточно приемлемый продукт. Это означа-

ет, что, если необходимо, его уже можно продавать, хотя и остается еще

множество нереализованных функций, которые могли бы сделать его бо-

лее конкурентоспособным. Но и без них продукт представляет собой по-

лезную программу, которая вполне удовлетворит многих потенциальных

пользователей.

Дальше все зависит от наличия времени и денег. Если разработку про-

дукта можно продолжить, его возможности постепенно расширяются все

тем же эволюционным методом: добавили функцию — отладили програм-

му, добавили следующую — опять отладили. Благодаря такой стратегии

366 Часть III: Управление проектами и группами

компания постоянно имеет полноценную и стабильную программу, даль-

нейшее усовершенствование которой можно прекратить в любой момент,

зная, что вся наиболее важная работа уже выполнена. Со временем про-

грамма вырастает в надежный и полезный продукт с богатыми возможно-

стями.

При методе водопада группа тестирования находится в состоянии по-

стоянной неопределенности. Как составить реальный календарный план

работ, когда никому не известно, сколько еще в программе ошибок и

сколько времени понадобится на их поиск и устранение? При эволюцион-

ном подходе все гораздо определеннее. Как минимум последняя отлажен-

ная версия продукта всегда готова к выпуску, а в новой версии добавлена

только одна функция, так что область поиска ошибок достаточно локали-

зована.

Последним преимуществом эволюционного подхода является его гиб-

кость: по ходу работы и по мере углубления понимания продукта требова-

ния к нему можно пересматривать, а это значит, что в конечном счете

продукт получается более совершенным.

Вот что можно сделать, если проект, реализуемый эволюционным ме-

тодом, выбивается из графика.

• Функциональность. Как только сформирован минимальный набор

функций, образующих приемлемый продукт, от остального можно

спокойно отказаться. Раз программисты не проектируют новых

функций до тех пор, пока не наступает время их добавления, такой

отказ не будет означать, что значительный объем работы по проек-

тированию и написанию документации проделан зря.

• Деньги. Вместо того чтобы отказаться от добавления новых функ-

ций, можно реализовать их быстрее, подключив дополнительные

ресурсы. Узким местом в этом случае станет проектирование про-

дукта, поскольку подключить новых конструкторов гораздо сложнее,

чем исполнителей.

• Дата выпуска. Главная мощь эволюционного подхода заключается

в том, что он предоставляет руководству невероятные возможности

контроля за графиком работ. Дата завершения проекта свободно

может переноситься в ту или иную сторону в зависимости от требо-

ваний момента. И нередко руководитель решает выпустить продукт

вовремя, не добавляя в него оставшийся десяток функций. При

этом, когда бы ни было принято решение о выпуске, сделать это

можно буквально в течение нескольких недель, ведь продукт всегда

стабилен.

• Надежность. Продукты, разрабатываемые эволюционным путем,

всегда очень надежны. Поскольку после добавления каждой новой

Глава 13: Объединяющая 367

функции продукт полностью отлаживается, основные усилия по

тестированию приходятся на начало проекта. Когда руководство

решает прекратить разработку и выпустить программу в свет, необ-

ходим лишь незначительный объем завершающего тестирования,

чтобы подтвердить ее готовность. При этом, даже если такое реше-

ние принимается раньше срока или до того, как все задуманное

будет полностью реализовано, нет риска, что выпущенная программа

будет содержать серьезные ошибки.

Затраты на тестирование продукта при эволюционном подходе довольно

велики, поскольку оно начинается очень рано. Однако ближе к концу

разработки объем тестирования гораздо меньше, чем при методе водопада,

что несколько уравнивает расходы. К тому же не приходится тратить вре-

мя на планирование тестов и тестирование тех функций, от реализации

которых руководство откажется в случае цейтнота.

Однако в реализации эволюционного метода разработки существуют и

сложности. Одна из них заключается в том, что программистам приходится

совмещать написание нового кода с отладкой старого. Если разработка не

укладывается в сроки, у них возникает искушение вместо исправления

ошибок быстро программировать новые функции. Однако делать этого ни

в коем случае нельзя, поскольку прогресс получается только кажущимся.

Ошибки будут накапливаться, и это сведет на нет все преимущества выб-

ранной стратегии. В результате руководителю проекта придется делать

выбор между выпуском некачественного продукта и переносом даты завер-

шения проекта.

При выборе эволюционного подхода неопытным руководителем суще-

ствует определенный риск. Руководителю может показаться, что, поскольку

продукт развивается со временем, нет нужды проводить тщательное началь-

ное планирование. Это огромная ошибка. Успех всей разработки зависит от

гибкости ядра и продуманности основных концепций. А для достижения

гибкости необходимо даже более тщательное планирование, чем при методе

водопада, ведь должны быть предусмотрены все возможные способы и

направления расширения продукта. Если же ядро разработано неудачно,

при добавлении каждой новой функции программы его придется переде-

лывать, а это сведет на нет все преимущества выбранного подхода. Кроме

того, в конце разработки может оказаться, что не хватает одной из важней-

ших функций, без которых продукт не будет полноценным, и придется

добавлять ее, отодвигая дату выпуска.

Не всегда правильно понимают суть эволюционного метода сотрудни-

ки группы маркетинга. Рекламируя продукт, они нередко анонсируют те

его функции, которых в конечном варианте может не оказаться. Нет нужды

говорить, что такого быть ни в коем случае не должно.

368 Часть III: Управление проектами и группами

У руководства есть и еще один способ завалить проект, разрабатывае-

мый эволюционным методом. Если не начать тестирование продукта сра-

зу же, как только будет готово его ядро (а такое может случиться, если все

тестировщики заняты на другом проекте, выбивающемся из графика), бу-

дет нарушена вся стратегия. К тому времени, когда к ядру начнут подклю-

чаться новые функции, оно еще не будет полностью отлажено. С ростом

сложности продукта тестировщикам и программистам крайне сложно будет

наверстать упущенное и привести очередную версию к состоянию полной

стабильности. В результате получится нечто похожее на плохо организован-

ный проект, разрабатываемый по методу водопада: тестирование начато

достаточно поздно, продукт очень нестабилен, и к тому же спецификация

все время пересматривается, к программе добавляются все новые и новые

функции, когда и старые еще работают кое-как. Приходится подключать к

тестированию дополнительные ресурсы, его стоимость непомерно возрас-

тает, а проект все равно выбивается из графика, и качество результата

оставляет желать лучшего.

При любом подходе к разработке от группы тестирования зависит очень

многое. Но при эволюционном методе у нее больше всего возможностей

завалить работу, и этот риск обязательно следует учитывать.

Модель разработки и тестирование

Как следует разобравшись в выбранной руководителем проекта модели

разработки, следует проанализировать ее влияние на процесс тестирования.

Вот что означает для тестировщиков выбор метода водопада.

•

Как можно раньше проанализируйте пользовательский интерфейс.

Можно воспользоваться для этого прототипами программы.

•

Как можно раньше начните разработку тестового плана. Это по-

зволит критически проанализировать спецификацию (или ее черно-

вики) и выявить возможные проблемы, связанные с тестированием

будущего продукта.

•

Нельзя приступить к тестированию раньше, чем продукт будет к

нему готов. Проблема в том, что, если проектирование и кодирова-

ние продукта затянется, тестирование тоже будет начато позже сро-

ка. Поэтому следует тщательно продумать свои действия в такой

ситуации. Во-первых, вы отвечаете за то, чтобы сформированная

группа квалифицированных тестировщиков не простаивала. С одной

стороны, она должна приступить к работе, как только продукт бу-

дет готов. С другой стороны, если программа не будет достаточно

стабильна, ее придется вернуть программистам на доработку, а те-

стировщиков загрузить другой работой, которая позволит ускорить

Глава 13: Объединяющая 369

процесс в дальнейшем. Например, они могут заняться автоматиза-

цией тестов или формированием дополнительных файлов тестовых

данных. Необходимо также разработать эффективную стратегию

подключения к проекту дополнительных людей, если в последнюю

минуту придется прибегнуть к такому варианту. Многие простые, но

рутинные операции можно поручить неквалифицированному или не

имеющему опыта работы с данной программой персоналу, повысив

тем самым отдачу от основного состава группы. Однако задачи для

подключаемых людей должны быть определены заранее, и вся схе-

ма действий должна быть достаточно продумана, поскольку, когда

сроки начнут сильно поджимать, времени на это уже не будет.

• Тестирование - это наиболее ответственный этап разработки.

К моменту начала тестирования программа уже практически полно-

стью написана. После прекращения поиска ошибок она сразу же

выходит в свет. Если проект достаточно велик для подключения

нескольких тестировщиков, подумайте о том, чтобы назначить одно-

го-двух человек для постоянного выполнения неформального тести-

рования. Цель работы такого сотрудника — каждую неделю находить

пару настолько серьезных ошибок или недостатков, что выпустить с

ними продукт просто невозможно. Во время исправления этих оши-

бок остальная часть группы будет последовательно "прочесывать"

программу в соответствии с планом. Эта тактика особенно хорошо

зарекомендовала себя на больших и серьезных проектах, где она

позволяет сэкономить очень много времени. (Предупреждение: ни-

когда не откладывайте документирование серьезных ошибок, прибе-

регая их на случай, если за неделю не удастся выявить ничего

серьезного. Такие вещи могут очень дорого вам обойтись, особенно

если кто-нибудь об этом узнает. Никогда этого не делайте. Никог-

да об этом даже не думайте.)

А вот каковы следствия выбора эволюционного метода.

•

Планируйте рано начать тестирование. Как только будет сформи-

рован базовый набор функций программы, необходимо будет при-

ступить к тестированию ее надежности.

•

Планируйте периодическое проведение анализа функциональности и

удобства программы. Если только что добавленная часть програм-

мы покажется вам неудачной, у вас будут все шансы добиться ее из-

менения.

•

Планируйте разработку тестового плана параллельно с тестирова-

нием. Заранее разработать его не удастся — ведь не будет ни пред-

мета тестирования, ни даже спецификации.

370 Часть III: Управление проектами и группами

Глава 13: Объединяющая 371

•

Планируйте выполнить самую серьезную часть тестирования как

можно раньше. Никогда не откладывайте критические тесты "на

потом". Руководитель проекта может в любое время остановить

разработку, и они так и останутся невыполненными. Такое действи-

тельно случается: двоим авторам этой книги приходилось выпускать

продукты за три месяца до запланированного срока.

Затраты на качество

Затраты на качество продукта — это затраты на предотвращение оши-

бок, их поиск и исправление. С точки зрения бизнеса деньги вкладываются

в тестирование потому, что выпуск продукта с ошибками в конечном сче-

те обходится дороже. Если удастся доказать, что определенный вид тести-

рования сэкономит компании деньги, его финансирование вам обеспечено.

Продумав, как согласовать работу своей команды с общей стратегией

разработки продукта, вы, возможно, захотите включить в свой план рабо-

ты, которые обычно в компании не практикуются. Например, в компании

может быть не принято, чтобы тестировщики анализировали внешний

дизайн продукта, или же им может не выделяться для этого достаточно

времени. Другими примерами подобных нестандартных работ может быть

анализ записей группы поддержки пользователей, автоматизация тестов,

выполнение рутинной работы низкоквалифицированными тестировщика-

ми или вообще непрофессионалами, подключаемыми к работе в крайних

случаях, тестирование на совместимость с широким диапазоном внешних

устройств или организация бета-тестирования. В каждом случае вам при-

дется доказывать руководству, что проведение соответствующих работ по-

зволит предотвратить серьезные потери или затраты в будущем.

Чем больше вам известно о затратах компании, связанных с качеством

программного продукта, тем больше у вас шансов доказать необходимость

новых тестовых процедур. Обычно эти затраты подразделяются на четыре

категории (Кампанелла (Campanella, 1990)).

•

Затраты на предотвращение ошибок: все расходы на предотвраще-

ние ошибок в программном обеспечении и документации.

• Затраты на исправление программы: стоимость работ по тестиро-

ванию и всего остального, что делается компанией для поиска оши-

бок.

•

Стоимость сбоев, происходящих в стенах компании: расходы из-за

ошибок, обнаруживаемых в процессе разработки и тестирования

продукта.

•

Стоимость сбоев, происходящих вне компании: расходы из-за оши-

бок, обнаруживаемых (обычно пользователями) после выпуска про-

дукта.

372 Часть III: Управление проектами и группами

Примеры каждого из этих четырех видов затрат приведены на рис. 13.2.

Исследования Фейгенбаума (Feigenbaum, 1991) показали, что типичная

компания тратит на предотвращение ошибок от 5 до 10 процентов общих

затрат на качество, еще 20—25 процентов уходит на исправление програм-

мы, и оставшиеся 65—75 процентов суммы "съедают" последствия внутрен-

них и внешних сбоев.

Глава 13: Объединяющая 373

Группы контроля качества обычно систематически собирают всю ин-

формацию о соответствующих затратах. Если получить к ней доступ не

удается, не отчаивайтесь. Многое можно выяснить у сотрудников группы

технической поддержки, кое-что может рассказать руководство, а об ос-

тальном можно и догадаться. Проанализировав собранную информацию, вы

поймете, как повышение затрат на предотвращение и исправление ошибок

помогает уменьшить последствия внутренних и внешних сбоев, а значит и

снизить соответствующие расходы. На этой основе можно строить соб-

ственные аргументы в пользу проведения необходимых видов работ.

Последовательность

этапов проекта

Обычно руководитель проекта публику-

ет календарный план, важнейшие этапы

которого носят названия альфа и бета.

Первый из них завершается объявлением о

готовности альфа-версии программы, а вто-

рой — объявлением о готовности бета-вер-

сии. Точные определения этих состояний

разработки от компании к компании меня-

ются. В общем случае альфа-версия про-

граммы — это полностью завершенный,

хотя и еще полный ошибок, продукт, в то

время как бета-версия уже почти готова к

выпуску. Основные этапы проекта пред-

ставлены на рис. 13.3.

Разбиение разработки на этапы вовсе не

означает, что все поставленные задачи ре-

шаются последовательно, одна за другой.

Как раз наоборот, многие работы выполня-

ются параллельно, например, в то время

как одни части программы только пишутся,

другие уже могут тестироваться и описы-

ваться в руководстве пользователя. При

эволюционном методе разработки в то же

самое время может выполняться и разра-

ботка требований к продукту, создание его

прототипа и написание спецификации.

На рис. 13.4 (а, б, в и г) приведен наш

вариант календарного плана работ (разуме-

ется, без конкретных сроков).

374 Часть III: Управление проектами и группами

Глава 13: Объединяющая 375

376 Часть III: Управление проектами и группами

Глава 13: Объединяющая 377

378 Часть III: Управление проектами и группами

Глава 13: Объединяющая 379

380 Часть III: Управление проектами и группами

Глава 13: Объединяющая 381

Необходимо подчеркнуть, что это только пример, ни одна известная

нам компания не придерживается в точности этой схемы. В каждой ком-

пании определяются собственные базовые этапы разработки, но, как пра-

вило, они очень похожи на приведенные в этой книге, поскольку это

наиболее естественный и логичный порядок решения перечисленных стан-

дартных задач.

Далее в этой главе подробно анализируются приведенные таблицы и

рассказывается о том, какие работы по тестированию программного про-

дукта соответствуют каждому из перечисленных этапов. (Примечание:

многие из используемых в этой главе терминов определялись в главе 3.)

Проектирование продукта

Это самый первый этап разработки, на котором определяется, что же

будет представлять собой задуманный программный продукт. При проек-

тировании первым делом формулируются требования к продукту, а затем

разрабатывается его внутренняя и внешняя структура. Подробное описание

этого процесса можно найти у таких авторов, как Де Макро (De Macro,

1979), Гаус и Вейнберг (Gause & Weinberg, 1989), Гилб (Gilb, 1988), Голд

и Льюис (Gould & Lewis, 1985), Оулд (Ould, 1990), Вейнберг (Weinberg,

1982), Йордан (Yourdon, 1975), Йордан и Константайн (Yourdon &

Constantine, 1979).

Программирование на этапе проектирования

продукта

Приступая к проектированию программы, ее конструкторы или предста-

вители заказчика прежде всего определяют требования к программе и про-

думывают свои предложения по их реализации, оформляют все это в виде

отдельных документов, после чего составляется контракт. Только после

этого может начаться собственно программирование. Если разработка ве-

дется методом водопада, на этапе проектирования разрабатываются внут-

ренняя и внешняя спецификации. Более детальное планирование

внутренней и внешней структуры продукта может быть продолжено и по-

зднее.

Маркетинговая деятельность на этапе

проектирования продукта

В это же самое время в отделе маркетинга ведется активная исследова-

тельская работа. Ее цель — помочь конструкторам продукта в формирова-

нии его видения, собрав для этого максимум информации о требованиях

рынка и нуждах пользователей. Для этого из потенциальных пользователей

продукта формируются небольшие дискуссионные группы, которым пред-

382 Часть III: Управление проектами и группами

лагается обсудить его возможности, часто на примере прототипов програм-

мы.

Сотрудники отдела маркетинга могут провести опрос пользователей,

работавших либо с предыдущими версиями разрабатываемого продукта,

либо с другими аналогичными программами. Они расспросят пользовате-

лей о том, какие функции желательно было бы включить в программу, как

они оценивают качество конкурирующих продуктов (и почему) и сколько

они могли бы заплатить за подобный продукт. Возможно, что в этой работе

потребуется и ваше участие.

Документирование на этапе проектирования продукта

Некоторые группы документирования на этом этапе помогают состав-

лять спецификации продукта.

Тестирование на этапе проектирования продукта

Если повезет, вам предложат проанализировать проектные документы,

как только они будут написаны. Это прекрасная возможность познакомить-

ся с продуктом и начать планирование собственной работы.

В главе 3 уже рассказывалось о том, какие недостатки может найти в

проектной документации тестировщик. Однако на деле тестировщики редко

высказывают какие-либо замечания. Они скорее пользуются предоставлен-

ной возможностью пораньше ознакомиться с программой. Если же вы все

же окажетесь активно вовлеченным в процесс проектирования, обратитесь

к книгам таких авторов, как Гаусс и Вейнберг (Gause & Weinberg, 1989) и

Фридман и Вейнберг (Freedman & Weinberg, 1982).

Если в компании строго соблюдается принцип водопада, рецензирова-

ние проектной документации пользовательского интерфейса может быть

для вас единственной возможностью изменить что-то в этой области. В

этом случае следует отнестись к делу со всей серьезностью и проанализи-

ровать проект продукта самым тщательным образом. Обратитесь в группу

технической поддержки за статистической информацией о расходах, свя-

занных с недостатками пользовательского интерфейса предыдущих разра-

боток компании. Это поможет доказать руководству, что время, которое вы

собираетесь потратить на анализ проектной документации, будет потраче-

но не зря.

Подготовка к автоматизации тестирования

Нередко самое важное, что вы можете сделать на этапе проектирования,

— это продумать, какой программный код поможет автоматизировать про-

цесс тестирования или сделать его более эффективным. Этот код может

быть включен прямо в продукт или написан в виде отдельных служебных

программ. Вовсе не обязательно, что все, о чем вы попросите, будет сде-

Глава 13: Объединяющая 383

лано. Но если высказать свои пожелания вовремя, т.е. на этапе проекти-

рования, да еще подкрепить их веской аргументацией, четко объяснив

назначение каждого средства, тогда у вас будут все шансы получить если

не все, то хотя бы часть задуманного. Вот несколько примеров подобного

инструментария.

• Автоматизация печати. Для этой цели вам потребуется возмож-

ность управления печатью из командной строки запуска программы.

Это означает, что программа должна принимать как минимум сле-

дующие параметры: имя файла, который необходимо распечатать,

имя выходного файла, если печать выполняется не на принтер, а в

файл, имя принтера (возможно, и его драйвер) и настроечную ин-

формацию (шрифт и разрешение печати). По окончании печати

программа должна немедленно завершать свою работу. Обладая та-

ким средством, можно сформировать пакетный файл, который запу-

стит программу, передаст ей всю необходимую для печати

информацию, сравнит результирующий файл с его предыдущей вер-

сией и напечатает результат, после чего запустит следующий тест. В

разделе главы 8 "Несколько полезных замечаний о тестировании

печати" этот вопрос рассматривается подробнее.

• Исследование памяти. Иногда исключительно полезной оказывается

возможность в любой точке программы нажать определенную кла-

вишу и получить информацию об использовании и содержимом

оперативной памяти. Информация эта может быть самой разной. В

одних случаях достаточно выяснить объем свободной памяти. В

других может потребоваться перечень свободных блоков памяти и их

размеров. Просто невероятно, сколько можно придумать новых те-

стов и сколько трудновоспроизводимых ошибок можно отловить

благодаря одному только знанию доступного объема памяти перед

началом определенного процесса, по его ходу и после завершения.

Тестировщики просто отказываются этому верить, пока не убедят-

ся на собственном опыте.

• Клавиши быстрого перемещения. Речь идет о скрытых командах,

позволяющих быстро переместиться в определенную точку програм-

мы. Это особенно полезно при тестировании некоторых игр.

• Копии экрана. Вам наверняка потребуется быстрый способ копиро-

вания содержимого экрана на принтер или в файл (а может быть, и

в последовательный порт, если данные анализируются в реальном

времени за другим компьютером). Утилита, копирующая экран,

должна обладать возможностью перехватывать не только изображе-

ние, но и текстовый курсор или указатель мыши. Одной из полез-

ных возможностей такого средства является сохранение копии