Тестирование-книга. Ю. Н. Артеменко Научный редактор
 Скачать 6.27 Mb.
|
|
Поищите фрагменты руководства, отражающие неудачную конст рукцию программы. Если технический писатель не смог достаточно просто и понятно описать какой-либо аспект работы программы, не спишите его осуждать. Возможно, все дело в самой программе. Например, в ней может быть неудачный набор опций, сбивающих пользователя с толку и противоречащих друг другу. Трудно ожидать, что их описание будет понятным. В этом случае проблема адресует ся не техническому писателю, а руководителю проекта — о ней не обходимо составить отчет как об ошибке проектирования. Если же дело все же в руководстве и вы можете предложить простое и чет кое описание группы опций или возможностей, сделайте это. Одна ко не стоит тратить часы на переписывание разделов руководства — это работа технического писателя, свой же вариант стоит предло жить тогда, когда он кажется вам очень удачным и это не занимает у вас слишком много времени. Встретив непоследовательное объяснение, проще всего обвинить автора документации. Но помните, что автор может просто аккуратно описать неудачную функцию программы. Поэтому лучше начать с предположения, что технический писатель компетентен и плохой текст указывает на недостатки самой программы. Глава 10: Тестирование документации 2 5 9 Пересмотренные версии руководства С новыми версиями руководства следует поработать так же, как и с первой, — с акцентом на его точности и эффективности. Поскольку вы будете узнавать об изменениях в программе задолго до технического писа- хеля, сообщайте ему об этом в своих комментариях. Пересмотренных версий руководства может быть достаточно много. В одной из них автор наведет красоту, подправит стиль и внесет последние организационные изменения. Вам же не стоит обращать внимание на по добные вещи — гораздо важнее сконцентрироваться на точности руковод ства и его соответствии концепции продукта. Придет время, и технический писатель сам исправит все неаккуратности, неловкие фразы и т.п. Бета-версия руководства Это будет последняя версия руководства, которую вы увидите. (Точнее, вы прочтете ее еще раз после внесения последних изменений, предложен ных после бета-тестирования.) В тех компаниях, которые не организуют бета-тестирования, последней тестировщикам поступает версия руковод ства, написанная после запрещения дальнейших изменений пользователь ского интерфейса. Бета-тестировщики не работают в вашей компании. Они, скорее, пользователи, эксплуатирующие продукт так, как будто купили его окон чательный выпуск. В их отчетах отражаются трудности, с которыми они столкнулись в процессе эксплуатации, предложения по улучшению продук та и конечно же найденные ошибки. Эти отчеты обязательно следует про анализировать самым тщательным образом, чтобы внести изменения как в программу, так и в документацию. До этого момента и вы, и программисты, и технические писатели, и сотрудники группы маркетинга только предполагали, как пользователи от реагируют на продукт и как они его поймут. Некоторые из этих предполо жений окажутся неверными. Отдельные аспекты программы, казавшиеся разработчикам такими естественными и понятными, пользователи не пой мут или не примут. Значительная часть изменений вносится в руководство именно после бета-тестирования, когда становится известно, что же на самом деле оказалось непонятным пользователям. Пользователи часто жалуются, что документация не является задачно- ориентированной. (Сор (Sohr, 1983); Шнейдерман (Schneiderman, 1987).) В заданно-ориентированном руководстве перечисляется набор задач, которые Можно выполнить с помощью программного продукта, и рассказывается, как это сделать. Все функции программы описываются с точки зрения их применения для конкретных практических целей. В противоположность 2 6 0 Часть II: Приемы и технологии тестирования этому в функционально-ориентированном руководстве функции программы описываются сами по себе, нередко просто в алфавитном порядке. Каждый аспект продукта описывается в отдельном разделе и как можно более пол но. Брокман (Brockmann, 1990) полагает, что, хотя задачно-ориентирован- ное руководство гораздо длиннее, оно и значительно эффективнее. Если продукт настолько многофункционален, что с его помощью можно выполнять тысячи различных заданий, писать задачно-ориентированное руководство нет никакого смысла — автор его просто никогда не закончит. Одно это еще не означает, что руководство по такому продукту должно быть полностью функционально-ориентированным. На практике чаще все го принимается компромиссное решение, когда в руководство, базирующе еся на описании функций продукта, включаются инструкции по решению ряда наиболее важных или популярных задач. Познакомившись с отзыва ми бета-тестировщиков, технический писатель может добавить в руковод ство дополнительные примеры и иллюстрации, предметные указатели или изменить его организацию. Пользователи высказывают в адрес документации и много других заме чаний. Однако тестировщику важно сохранять правильную позицию в от ношении этой критики, понимая, что настоящая причина проблем может быть вовсе не в руководстве, а в неудачном интерфейсе или функциональ ной структуре самого продукта. Производство Главной целью тестировщика документации в процессе ее производства является точность информации. В группе тестирования обязательно имеется сотрудник, отвечающий за литературное редактирование и верстку документации. Разумеется, если вы заметите орфографическую ошибку или сдвинутый заголовок, вас только поблагодарят, но, вообще, это не ваша работа. Если продукт должен быть выпущен сразу по завершении разработки и тестирования программного обеспечения, производство документации необходимо начать как минимум за 8 (а лучше за 14) недель до окончания работ. В течение всех этих недель программа будет изменяться. Из-за этого некоторые разделы руководства придется удалять или переписывать. Кро ме того, некоторые ошибки, которые предполагалось исправить, могут Глава 10: Тестирование документации 261 остаться неисправленными, и это тоже повлечет за собой переделку соот ветствующих фрагментов руководства. Важно понимать, что все желаемые изменения внесены быть не могут. Часто автор будет ограничиваться лишь минимальными правками — толь ко чтобы сохранить достоверность информации, но не больше. Если хотите, чтобы в документацию были внесены дополнительные изменения, можете помочь техническому писателю сократить их стоимость, самостоятельно продумав текст соответствующего фрагмента. С того момента, как руководство поступает в производство, это уже не просто организованный набор слов. Теперь это набор страниц, каждая из которых представляет собой отдельный объект, с собственным оформлени ем, содержанием, возможно, иллюстрациями. На этом этапе изменения текста обходятся очень дорого, и едва ли автор согласится на корректиров ки, затрагивающие более одной страницы. С другой стороны, изменения, затрагивающие только одну строку или абзац, пока еще внести несложно. Поэтому, если изменения совершенно необходимы, продумайте, как свести их к минимуму и подобрать такие формулировки, которые не изменят размера корректируемой строки или абзаца. Формально продумывание формулировок не входит в ваши обязанно сти. Ваше дело — передать техническому писателю записку с описанием проблемы, и он сам должен решить, вносить ли изменения в текущий вы пуск руководства, и если да, то какие именно. Руководитель может даже попросить вас ограничиться этими своими обязанностями и не тратить лишнего времени. Но поскольку жизненные ситуации не укладываются в формальные рамки, в отдельных случаях вы вполне можете поучаствовать в продумывании необходимых изменений, особенно если они очень важ ны и не займут у вас слишком много времени. Еще одним важным объектом вашего внимания будет предметный ука затель книги. И начать с ним работать лучше как можно раньше. Читая руководство, обращайте внимание на описываемые в нем ключевые поня тия и проверяйте, включены ли они в указатель. Если нет, сообщайте об этом техническому писателю. Завершающая проверка указателя выполняется после завершения рабо ты над текстом книги и подготовки ее к печати. Эта работа поручается либо тестировщику, либо одному из редакторов. Вполне может оказаться, что в окончательной версии предметного указателя отсутствуют ссылки на какую-либо одну главу или они основываются на ее предыдущей версии. Поэтому как минимум необходимо проверить по две записи указателя на каждые пять страниц книги. (Это значит, что можно проверить два элемен- 2 6 2 Часть II: Приемы и технологии тестирования та индекса со ссылками на страницы 1-5, два со ссылками на страницы 5— 10 и т.д.) Постпроизводственная стадия В некоторых компаниях руководство не печатается до тех пор, пока не будет завершена работа над программным обеспечением. В таких случаях постпроизводственная стадия тестирования просто отсутствует. (У техни ческих писателей еще остается кое-какая работа, например, они вычиты вают первый распечатанный экземпляр книги, но тестировщики этим не занимаются.) Если компания отправляет руководство в печать еще до завершения работы над программным обеспечением, в обязанности технического пи сателя может входить составление и еще двух документов. Первый из них, печатное приложение, состоит из поправок, советов по разрешению проблем и описаний дополнительных функций продукта. Этот документ отправля ется в печать за несколько дней до того, как начнется размножение дисков. Информация, которая появится в течение этих нескольких дней, в него не попадет и будет помещена прямо на дистрибутивный диск в виде файла README. Кроме проверки точности информации приложения и README-фай- ла, вашей работой на этой стадии будет подбор советов по решению про блем. Потенциальным кандидатом для этого является любая отложенная ошибка. Если ее можно описать в позитивном тоне и посоветовать пользо вателю что-нибудь полезное, следует включить это описание в раздел раз решения проблем. Интерактивная справка Большая часть того, что рассказывалось в этой главе о руководстве пользователя, применимо и к интерактивной справке. Сказанное можно дополнить лишь несколькими замечаниями. • Точность. Точность и достоверность интерактивной справки необ ходимо проверить так же тщательно, как и точность руководства. Как правило, текст справочных файлов не блещет литературными достоинствами, не слишком хорошо продуман и протестирован и не особенно уважается пользователями. • Библиография. Автором лучшей книги, которую нам приходилось читать об интерактивной справке, является Хортон (Horton, 1990). • Гипертекстовые связи. Если в интерактивной справке имеются ги перссылки, все их необходимо проверить. Может оказаться, что одна Глава 10: Тестирование документации 2 6 3 и та же ссылка в нескольких местах справки указывает на разные страницы или же просто содержимое страницы, на которую указы вает ссылка, не соответствует ее названию. • Указатель. Если в интерактивной справке имеются содержание и указатель, их тоже необходимо проверить. Каждая строчка указате ля должна открывать правильную страницу справки. • Еще об указателе. Кроме элементарной правильности указателя, важно проверить и его содержание. Имеются ли в нем ссылки на каждую страницу справки? Не пропущены ли важные понятия или вопросы? Удачно ли подобраны названия элементов указателя? Если пользователь не сможет найти нужную информацию, едва ли он захочет в дальнейшем пользоваться такой справкой. • Стиль. Мало кто из пользователей последовательно читает всю справку от начала до конца. Как правило, к ней обращаются за ответом на конкретный вопрос, за инструкциями по решению неко торой задачи или информацией о полученном сообщении об ошиб ке. В такой ситуации читатель справки обычно нетерпелив или даже нервничает или раздражен. Поэтому от справки требуется большая четкость и простота изложения, чем от печатного руководства. (Же лательно, чтобы уровень читабельности текста был около 5.) Кроме того, хорошая справка должна быть задачно-ориентированной, пользователь ожидает найти в ней нечто полезное, что он сразу же сможет выполнить. Встретив запутанный или сложный текст, сооб щите о нем как о проблеме. Глава Инструментальные средства тестировщика Назначение этой главы Теперь читателю предстоит познакомиться с программными средствами, автоматизирующими процедуру тестирования "черного ящика", узнать, чем они могут быть полезны и каковы пределы их возможностей. Речь пойдет не о конкретных программах, а о классах подобных средств. Библиография В поиске подходящих программных средств могут помочь два известных каталога: Testing Tools Reference Guide: A catalog of Software Quality Support Tools, публикуемый Software Quality Engineering (800-423-8378, 3000-2 Hartley Road, Jacksonville, FL 32257) и Programmer's Shop (800-421- 8006, 90 Industrial Park Road, Hingham, MA 02043). Немало полезной информации м о ж н о почерпнуть из книг таких авторов, как Гласе (Glass, 1992), Бейзер (Beizer, 1990), Андриоле (Andriole, 1986), Данн (Dunn, 1984) и Де Милло (DeMillo, 1981). Обзорные статьи и опи сания конкретных программных средств печатаются во многих журналах. К ним нередко прилагаются CD с описываемыми п р о г р а м м а м и и их последними версиями. Обзор В этой главе обсуждаются следующие вопросы: • Базовые инструменты тестировщика. • Автоматизация приемочного и регрессионного тестирования. • Технологии и инструменты тестирования соответствия стандартам. • Средства для тестирования "стеклянного ящика". 11 Глава 11: Инструментальные средства тестировщика 2 6 5 Базовые инструменты тестировщика Вот каковы основные инструменты тестировщика: • Персональный компьютер, терминал или рабочая станция. Никог да не пренебрегайте помощью компьютера — обращайтесь к нему каждый раз, когда в этом возникает потребность. Значительно повышает производительность одновременная работа с двумя компьютерами, на одном из которых запущена тестируемая программа, а другой служит для регистрации проблем и корректировки плана тестирования. • Хороший текстовый процессор. Вам необходима программа, позво ляющая вводить и редактировать руководства, планы тестирования, отчеты, записи и письма. Пользоваться ею вы будете так активно, что стоит потратить время на выбор самого оптимального продукта. • Процессор планов. Эта программа специально предназначена для составления и реорганизации иерархических структур, и она гораз до лучше справляется с этой работой, чем обычный текстовый про цессор. С ее помощью удобно составлять планы тестирования, списки функций, подробные отчеты о состоянии и списки задач. Мы предпочитаем пользоваться именно отдельными процессорами планов, а не их ограниченными версиями, включаемыми в тексто вые процессоры. Выбирая такой продукт, прежде всего обратите внимание на функции группировки, сортировки и реорганизации информации. • Электронная таблица. Эта программа незаменима для работы с тестовыми таблицами. • Утилиты сравнения файлов. Подобных программ достаточно мно го: они сравнивают пару файлов, сообщают, найдены ли различия, и если да, показывают их список. Лучшие из них генерируют пере чень изменений, которые необходимо внести в один из файлов, чтобы получить другой. Простейшие утилиты сравнения файлов нередко поставляются в комплекте операционных систем. Однако если вам встретится про грамма, более подходящая для решения именно ваших задач, стоит на нее потратиться. Утилиты могут предназначаться для разных целей: сравнения двоичных файлов (объектного кода, графики, сжатых данных и т.п.) и сравнения текста. От их назначения зави сит то, в каком виде будут представлены результаты сравнения. 2 6 6 Часть II: Приемы и технологии тестирования • Просмотровики файлов. Такие программы позволяют просматривать данные, хранящиеся в файлах самых разнообразных форматов. • Конвертеры файлов. Эти утилиты преобразовывают файлы данных (текстовые, графические и т.п.) из одного формата в другой. Напри мер, текст может быть преобразован из формата одного текстового процессора в формат другого. • Утилиты для создания копий экрана. Эти утилиты позволяют сохра нить содержимое экрана или текущего окна в файле на диске. Воз можно, вам понадобится даже несколько таких программ, поскольку некоторые из них несовместимы с отдельными типами программно го обеспечения. Копии экрана полезны как для анализа ошибок и поиска их источника, так и для того, чтобы показать ошибку про граммисту. Нередко проще предоставить ему копию экрана, чем описывать его содержимое на словах. • Утилиты для поиска текста. С помощью такой утилиты можно найти в объектном коде программы текстовые строки. Простейшие из них просто прочесывают программный файл и записывают в от дельном текстовом файле все содержащиеся в нем строки ASCII. В результате получается список всего встроенного в программу текста и сообщений об ошибках. Возможно, программист или руководитель проекта будет убеждать вас, что не стоит тратить времени на подоб ную работу, поскольку весь текст хранится в файлах ресурсов. Од нако это утверждение не мешает проверить, поскольку программист может все же вставить в программу парочку коротких сообщений, особенно о критических ошибках. • Устройства видеозаписи (VCR). Весь вывод на экран можно запи сать на видеопленку. Для этого нужен обычный видеомагнитофон и специальная видеоплата с соответствующим выходом. (Имейте в виду, что платы NTSC не сохраняют на ленте весь экран VGA.) Для тестирования неустойчивых программ с трудноуловимыми ошибка ми записывающие устройства просто незаменимы. Они невероятно облегчают поиск и воспроизведение ошибок, а если ошибку невоз можно воспроизвести, видеозапись подтверждает, что она все же произошла, и сохраняет точную хронологию событий. Обычно это го достаточно, чтобы программист мог проанализировать ситуацию и выявить причину сбоя. Однако, несмотря на всю полезность этого инструмента, его приме нения может стать для тестировщика сущим бедствием. В восторге от таких возможностей, руководитель проекта может требовать, что бы видеозапись прилагалась к каждой выявленной ошибке, а это уже серьезно затормозит вашу работу. Поэтому придерживайтесь золотой Глава 11: Инструментальные средства тестировщика |