Тестирование-книга. Ю. Н. Артеменко Научный редактор
 Скачать 6.27 Mb.
|
|
Глава 13: Объединяющая 3 9 3 та над файлами данных — шаблонами, примерами, мультимедиа, трансля ционными таблицам для драйверов и т.п. Если в компании принято начинать тестирование только после готов ности альфа-версии и между этим рубежом и выпуском продукта остается очень мало времени, руководитель проекта может сознательно объявить о готовности альфа-версии, когда до этого еще явно далеко. Отнеситесь к такому его поступку с пониманием — ведь это фактически его единствен ный шанс спасти проект, вовремя начав тестирование. Виноват здесь не он, а навязанная ему модель разработки. Маркетинговая деятельность после завершения альфа-версии С этого момента обычно начинается работа над упаковкой продукта и маркетинговой литературой. Собственно говоря, работа эта может начать ся несколько раньше или несколько позже — главное, чтобы к выпуску все было готово. Анализ дизайна упаковки и проверка всей маркетинговой литературы на техническую точность входит в обязанности отдела тестирования. Разуме ется, речь не идет о тоне или стиле изложения либо о маркетинговой на правленности информации. Вы отвечаете только за техническую сторону вопроса. Как правило, большинство дат календарного плана отсчитываются от предполагаемой даты выпуска продукта. Это касается и всех маркетинго вых материалов, хотя их стараются разработать как можно позже, чтобы в них отражалось реальное состояние программы на момент выпуска, кото рое может отличаться от первоначально запланированного. То же самое относится и к руководству пользователя: его отправляют в печать заблагов ременно, поскольку дело это долгое, однако не настолько рано, чтобы его информация оказалась недостоверной. Необходимо учитывать тесную взаимосвязь сроков разработки различ ных составляющих проекта. Если сроки разработки программы затягивают ся, должны быть вовремя перенесены все даты, связанные с датой выпуска продукта. Для этого руководитель проекта должен вовремя получать от вас четкие и ясные отчеты о состоянии продукта и объеме оставшейся части работ по тестированию. Документирование после завершения альфа-версии Первый черновик справочной системы и руководства пользователя обычно бывает готов вскоре после завершения альфа-версии. Вам необхо димо будет их прочесть и проанализировать, а также протестировать по ним программу, поэтому заранее зарезервируйте для этого время. (Если спра вочная система очень проста, она может разрабатываться и несколько 3 9 4 Часть III: Управление проектами и группами позже, чтобы меньше пришлось переделывать в случае изменения програм мы.) Тестирование после завершения альфа-версии Во многих компаниях тестирование начинается именно с этого време ни. Однако лучше начать пораньше, чтобы к моменту готовности альфа- версии работа уже шла полным ходом. Вспомните кривую стоимости исправления ошибок. Чем дальше продвигается работа над проектом, тем эта стоимость выше. В то же время ошибку, найденную достаточно рано, легко исправить, и эти исправления незначительно отражаются на других составляющих продукта и других частях программы. На ранних стадиях тестирования вашей целью является поиск всех наиболее очевидных про блем в каждой области программы. На этом этапе тестирование еще до вольно поверхностное, обзорное, без углубления в детали. Как только в руках у вас окажется первый черновик руководства пользователя, можно будет приступать к его тестированию, точнее, к тес тированию программы по этому руководству, поскольку все, о чем говорит ся в руководстве, необходимо будет выполнить за компьютером. Каждый пример, каждая упомянутая клавиша или команда, каждый способ работы или решения определенной задачи, каждое утверждение и его очевидные следствия — все должно быть скрупулезно проверено. Первые пару циклов тестирования вам придется работать с очень неста бильной программой, так что выполнить все сказанное в полном объеме будет невозможно. Тем не менее, будет найдено множество ошибок и проблем, и у вас останется достаточно времени на их обдумывание. В те чение первого полного цикла тестирования должно быть сделано следующее. • Начните с активного наступления. В ходе первого цикла тестиро вания будут написаны десятки или сотни отчетов, охватывающих все основные аспекты программы и документации, работу всех програм мистов и технических писателей. Ваша деятельность должна быть видимой, а ее производительность не оставлять сомнений. В исправ лении найденных ошибок должны быть задействованы все. • Изучите продукт. Хотя вы и не станете опытным пользователем, каждая функция программы должна быть вами опробована. • План тестирования должен быть готов к представлению руководи телю проекта. Это не значит, что план необходимо полностью за вершить и проработать все его детали. Этот документ развивается во времени, по мере тестирования он все время углубляется, расширя ется и корректируется в соответствии с меняющимся состоянием программы. Составление плана и само тестирование никогда не должны рассматриваться как отдельные процессы. Глава 13: Объединяющая 3 9 5 • Поднимите вопросы о структуре и интерфейсе продукта. Если в этой области имеются проблемы, их необходимо обсудить как мож но раньше — как только вы составите первое впечатление о продук те и хоть немного его поэксплуатируете. Если что-то покажется вам явно неудобным или непонятным, сразу же составляйте соответству ющий отчет. • Протестируйте руководство. Проверьте каждый факт и его след ствия. После этого передайте техническому писателю копию руко водства с пометками. Еще одну такую же копию оставьте себе — вам еще не раз придется с ней сверяться. • Оцените общее качество продукта. • Сформируйте собственное впечатление о стабильности каждой основной области программы. Выделите наиболее слабые из них и укажите руководству, какие функции еще не готовы к тестиро ванию. • Оцените надежность программы. Сколько циклов тестирования потребуется для ее отладки? Сколько ошибок предполагается найти? (Конечно же в первый раз эти оценки будут более чем приблизительными. Но от проекта к проекту вы будете набирать ся опыта и сможете оценивать ситуацию все более точно.) Вот первое, что следует сделать после завершения альфа-версии про граммы. • Получите утвержденный руководителем проекта список поддержи ваемых устройств. Включите этот список в план тестирования. • Начните первый цикл тестирования устройств. К концу альфа- этапа должен быть пройден как минимум один полный цикл этого вида тестирования. • Начните формирование комплекса регрессионных тестов. Эти тес ты будут выполняться в начале каждого цикла тестирования про граммы или ее части. Набор регрессионных тестов периодически должен пересматриваться и обновляться. Некоторые области про граммы будут нуждаться в особенно тщательном тестировании, 'особенно те, в которые вносился целый ряд изменений, наклады вающихся одно на другое. Такие латаные-перелатанные фрагмен ты программы всегда самые ненадежные, поэтому их все следует знать и раз за разом повторять для них обстоятельные регресси онные тесты до тех пор, пока вы не убедитесь в их полной ста бильности. • Пересмотрите потребности в ресурсах и опубликуйте календарный план работ. Еще раз продумайте список задач своей группы, оцени- 3 9 6 Часть III: Управление проектами и группами те сроки их выполнения и необходимое количество людей. Черно вик этого списка может быть уже опубликован, однако после пер вого предварительного цикла тестирования у вас наверняка возникнут новые соображения. Теперь, имея некоторый опыт рабо ты с программой, можно составить не просто предварительный на бросок, а документ, которого вы будете придерживаться в дальнейшем. Поэтому список задач должен быть полным, т.е. в нем не должно быть ничего, что не будет выполнено, и при этом ни одна важная часть работы не должна быть упущена. На выполнение от дельной задачи из этого списка должно уходить от половины дня до недели. Назначьте каждой задаче конкретные сроки. Это нелегкая работа, но она очень важна. Именно по календарному плану руко водитель проекта сможет в дальнейшем сверять реальное продвиже ние работы. По мере продвижения работ альфа-этапа будет расширяться тестовый план и углубляться тестирование. • По мере необходимости разрабатывайте и публикуйте приемочные тесты. (Приемочный тест — это набор тестов, который должен быть пройден очередной версией программы перед началом нового цикла тестирования.) Во многих компаниях до того, как будет готова бета-версия, программа принимается на тестирование в любом со стоянии, независимо от того, прошла ли она приемочные тесты. Это не мешает разработать и опубликовать такие тесты заранее, просто не следует настаивать на их прохождении программой до оговорен ного срока. • Подготовьте и заполните рабочие списки и схемы. Среди них мо гут быть следующие документы. • Перечень всех списков, таблиц, схем и т.п. Какие виды записей планируется вести в ходе тестирования? Какие виды тестов пла нируется проводить и какие искать ошибки, не включенные ни в один из рабочих документов? Чтобы проверить, все ли возможные виды ошибок охвачены планом тестирования, воспользуйтесь приложением к этой книге. Данный перечень поможет вам в формировании исчерпывающего списка задач, выполнение которых будет означать, что программа полностью протестирована. Полезен он будет и при составлении календарного плана, распределении ресурсов и планировании бюд жета. * Диаграммы входных граничных условий. * Диаграммы выходных граничных условий. Глава 13: Объединяющая 3 9 7 • Список функций, включающий стратегии поиска ошибок управ ления потоком (например, ошибок начальных состояний), описа ния возможностей и последствий переходов между состояниями, повторного входа в состояния или выхода из состояний без вы полнения требуемых действий (например, ввода запрошенных данных). • Список всех сообщений об ошибках. • Тестовые матрицы конфигураций устройств. • Таблицы сравнительных данных для тестирования производитель ности программы (в сравнении с другими ее версиями или про дуктами конкурентов). • Описания нагрузочных тестов. • Стратегии тестирования потоков данных и последствий измене ния существующих данных. • Таблицы, в которых описываются функции каждой клавиши в каждой области программы. (Если по всей программе клавиши работают одинаково, эти таблицы будут несложными. Однако данный факт необходимо проверить, поскольку то, что так ска зал руководитель проекта или программист, еще не значит, что так и есть на самом деле.) • Стратегии поиска условий гонок, проблем, связанных с обменом сообщениями, общими данными, прерываниями, а также других проблем, которые не могут быть обнаружены путем простого линейного тестирования. • Матрицы зависимостей между входными данными или опциями. • Диаграммы использования памяти функциями программы. Это исследовательские средства, в которых вовсе не обязательно воз никнет потребность. Они бывают полезны при разработке про грамм, для которых требования к памяти являются важной характеристикой, или при поиске невоспроизводимых ошибок. • И многое другое. В приложении к книге приведен длинный пе речень ошибок. Прочитайте его, чтобы убедиться, что планом - тестирования охватываются все ошибки, которые могут встретить ся в вашей программе. • Не пытайтесь выполнить все сразу. Чередуйте разработку тестовых материалов с непосредственным поиском ошибок. Что бы вы ни делали, всегда оставляйте для этого время. Даже к концу альфа-этапа вся перечисленные материалы готовы не будут. Разрабатывайте их постепенно, сначала прорабатывая структуру списков и таблиц, а затем, по мере освоения определенной области программы, запол- 3 9 8 Часть III: Управление проектами и группами няйте их информацией. Однако работа по подготовке тестовых ма териалов все же должна ощутимо продвигаться вперед, ведь это основа фундаментального тестирования. Кроме планирования и подготовительного тестирования на альфа-эта пе автоматизируются некоторые тесты. Прежде всего, это регрессионные тесты, которые могут либо полностью выполняться компьютером, либо автоматизироваться хотя бы частично. Автоматизация регрессионных тес тов позволит значительно сэкономить рабочее время: вместо того чтобы тратить его на бесконечное выполнение одних и тех же старых тестов, вы сможете посвятить его разработке и выполнению новых. • Архивируйте все нетривиальные файлы данных. Не забывайте со провождать файлы короткими заметками об их содержимом и назна чении. Не заставляйте себя или сотрудников каждый раз вспоминать, что именно находится в данном файле. При таком обилии информации, похожих версий одних и тех же данных, сход ных тестов, нечего полагаться на память. Иначе кончится тем, что придется разрабатывать некоторые тесты сначала. Если комментарии включаются прямо в файлы, подготовьте еще один документ с пе речнем всех имеющихся файлов и кратким описанием их назначе ния, чтобы все материалы, необходимые для проведения каждого теста, можно было быстро найти. • Архивируйте все повторно используемые пакетные файлы, файлы данных и сохраненные последовательности нажатий клавиш. Раз делите их на две группы. Самые важные из них, а также те, с кото рыми могут в дальнейшем работать другие сотрудники, сопроводите подробными комментариями, остальные — более краткими. • Подготовьте файлы данных для тестирования печати. Начните со стандартных файлов, которые подойдут для тестирования всех типов устройств. Потестируйте программу с их помощью, выводя инфор мацию как на принтер, так и на диск. Подготовьте пакетные фай лы, чтобы в следующий раз все эти тесты можно было выполнять автоматически и сравнивать выходные файлы различных версий программы или различных драйверов устройств. • Подготовьте конфигурационные тесты. Составьте полный список возможных составляющих операционной среды программы. В час тности, в него войдут версии операционных систем и дополнитель ного системного программного обеспечения. Количество возможных конфигураций, скорее всего, будет очень велико, так что придется подумать над разработкой нескольких всеохватывающих тестов, по зволяющих выявить имеющиеся проблемы с наибольшей вероятно стью. Достаньте необходимые модели внешних устройств (модемов, Глава 13: Объединяющая 3 9 9 мыши, видеоплат и т.п.) и начните подготовку соответствующих те стовых файлов. • Автоматизируйте приемочные тесты. Если каждый раз, когда будет готова очередная версия программы, планируется выполнять стандартную серию коротких тестов, их стоит автоматизировать. Ведь выполняться эти тесты будут множество раз, и не только тес- тировщиками, но и другими сотрудниками, в частности, программи стами. Для автоматизации этих тестов может потребоваться программное обеспечение для перехвата и воспроизведения клави атурного и иного ввода, перехвата выходной информации (в частно сти, изображения на экране) и выделения из нее важных фрагментов. Зафиксировав однажды результаты правильной работы программы, можно сравнивать их с результатами работы каждой новой версии. Имейте в виду, что коммерческие программы подоб ного рода нередко бывают полны ошибок, так что, приобретая их, требуйте у продавца месячную гарантию. В автоматизации тестирования, как и во всякой другой работе, имеют ся свои трудности и издержки. В среднем на автоматизацию теста уходит в 10 раз больше времени, чем на его создание и выполнение вручную. • Займитесь автоматизацией тестирования как можно раньше, иначе эта работа не окупится. • На самых ранних этапах тестирования лучше посвятить время не автоматизации тестов, а их выполнению. Этап предварительного поверхностного тестирования программы очень важен, и выявляе мые в его ходе ошибки лучше не откладывать "на потом". • Заранее автоматизированные тесты позволяют существенно повы сить производительность работы в самые напряженные периоды. • Не стоит автоматизировать тесты слишком рано, поскольку программа может настолько измениться, что вся работа окажется проделанной зря. • Однако приемочные тесты следует создать заранее, поскольку они будут выполняться так часто, что каждая минута их автоматизиро ванного выполнения позволит существенно сэкономить время. • Рано начатые работы по автоматизации могут вызвать политичес кие проблемы. На автоматизацию теста требуется так много време ни, что эта работа окупается только в случае, если он выполняется более десяти раз. Некоторые руководители проектов утверждают, что их чудесным продуктам достаточно и двух-трех циклов тестирова ния. И хотя в этом случае руководитель наверняка ошибается, такая 4 0 0 Часть III: Управление проектами и группами длительная подготовительная работа, как автоматизация, может за деть его лучшие чувства. (На самом же деле всегда планируйте про вести как минимум восемь циклов тестирования.) Несколько тестов все же можно автоматизировать заранее, но не слишком много, чтобы не было очевидных задержек в работе. Пожалуй, идея ясна. В конечном счете руководитель группы тестиро вания ориентируется на собственный опыт и обстоятельства конкретной работы. Глубина тестирования против охвата Тестирование программы должно выполняться тщательно и скрупулез но. Тестировщик концентрируется на одной проблеме или функции, посвя щает ее анализу и тестированию значительное время, затем переходит к следующей. Однако при такой технологии работы может оказаться, что одни части программы в конечном счете протестированы лучше, чем другие. |