Тестирование-книга. Ю. Н. Артеменко Научный редактор
 Скачать 6.27 Mb.
|
|
ББК 32.973 К 81 Канер Сэм и др. К 81 Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений: Пер. с англ./Сэм Канер, Джек Фолк, Енг Кек Нгуен. — К.: Издательство «ДиаСофт», 2001. — 544 с. ISBN 966-7393-87-9 Книга именитых специалистов в области разработки программного обеспече ния посвящена одному из наиболее важных и нетривиальных аспектов в рамках процесса создания сложных программных систем. Книгу отличает, прежде всего, привязка к условиям реального мира на примерах известных компаний-разработ чиков, находящихся в Силиконовой долине. Подробно рассматривается широкий спектр вопросов: от организации процесса тестирования до собственно тестиро вания проекта, кода, документации и т.д. Для специалистов в области разработки программного обеспечения. ББК 32.973 Научное издание Канер Сэм и др. ТЕСТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ. ФУНДАМЕНТАЛЬНЫЕ КОНЦЕПЦИИ МЕНЕДЖМЕНТА БИЗНЕС-ПРИЛОЖЕНИЙ Главный редактор Ю.Н.Артеменко Научный редактор О.В.Здир Литературный редактор А.В.Штин Переводчик О.В.Здир Верстка Т.Н.Артеменко Главный дизайнер О.А.Шадрин Н/К Сдано в набор 13.03.01. Подписано в печать 13.05.01. Формат 60x84/16. Бумага офсет ная. Гарнитура Таймс. Печать офсетная. Усл.печл. 40.80. Усл.кр.отт. 40.80 Тираж 3000 экз. Заказ № 1-78. Издательство «ДиаСофт», Киев-55, а/я 100, тел./факс (044) 212-1254. e-mail: books@diasoft.kiev.ua, http://www.diasoft.kiev.ua. Authorized translation from the English language edition published by International Thomson Computer Press. Copyright © 1999 All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from the Publisher. Russian language edition published by DiaSoft Ltd. Copyright © 2001 Лицензия предоставлена издательством International Thomson Computer Press, подразделение International Thomson Publishing Inc. Все права зарезервированы, включая право на полное или частичное воспроизведение в какой бы то ни было форме. ISBN 966-7393-87-9 (рус.) © Перевод на русский язык. Издательство «ДиаСофт», 2001 ISBN 1-85032-847-1 (англ.) © International Thomson Publishing Press, 1999 © Оформление. Издательство «ДиаСофт», 2001 Свидетельство о регистрации 24729912 от 11.03.97. Гигиеническое заключение № 77.99.6.953.П.438.2.99 от 04.02.1999 Оглавление Часть I. Основы 19 Глава 1. Пример серии тестов 20 Первый цикл тестирования 20 Второй цикл тестирования 32 Что дальше? 37 Глава 2. Желаемое и действительное в жизни тестировщика 38 Полностью протестировать программу невозможно 39 Цель тестировщика — проверка правильности программы? 46 Итак, для чего же тестируют программы? 49 Глава 3. Типы тестов и их роль в процессе разработки программного обеспечения 50 Обзор стадий разработки 55 Стадии планирования 57 Тестирование на этапе планирования 58 Стадии проектирования 62 Тестирование на этапе проектирования 66 Тестирование "стеклянного ящика" на стадии кодирования 69 Регрессионное тестирование 80 Тестирование "черного ящика" 80 Сопровождение 90 Глава 4. Программные ошибки 93 Качество 93 Что такое программная ошибка? 95 Категории программных ошибок 95 Глава 5. Документирование и анализ ошибок 101 Отчет следует составлять немедленно 102 Структура отчета о проблеме 103 Каким должен быть отчет о проблеме 113 Анализ воспроизводимой ошибки 116 Методика анализа воспроизводимой ошибки 119 Поиск способа воспроизведения ошибки 122 6 Тестирование программного обеспечения Часть II. Приемы и технологии тестирования 129 Глава 6. Система отслеживания проблем 130 Основное назначение системы отслеживания проблем 134 Задачи системы 135 Процесс отслеживания проблемы 135 Пользователи системы отслеживания проблем 144 Реализация базовых функций системы отслеживания проблем.... 158 Дополнительные замечания о документировании проблем 169 Терминология 178 Глава 7. Разработка тестов 180 Характеристики хорошего теста 182 Классы эквивалентности и граничные условия 183 Тестирование переходов между состояниями 193 Условия гонок и другие временные зависимости 194 Нагрузочные испытания 196 Прогнозирование ошибок 196 Тестирование функциональной эквивалентности: автоматизация, анализ чувствительности и случайный ввод .....197 Регрессионное тестирование: успешно ли исправлена ошибка .... 204 Регрессионное тестирование: стандартная серия тестов 205 Выполнение тестов 206 Глава 8. Тестирование принтеров и других устройств 2 0 8 Общие вопросы конфигурационного тестирования 209 Тестирование печати 211 Глава 9. Адаптационное тестирование 2 3 7 Изменен ли исходный код? 238 Привлекайте к работе специалистов, свободно владеющих языком 239 Встроен ли текст в программный код? 239 Перевод длиннее исходного текста 239 Наборы символов 240 Клавиатура 240 Фильтрация ввода 241 Загрузка, сохранение, импорт и экспорт символов основного и расширенного набора ASCII 241 Язык и операционная система 242 Клавиши вызова 242 Сборные сообщения 242 Оглавление 7 Идентификаторы сообщений об ошибках 243 Правила переноса 243 Правописание 243 Порядок сортировки 243 Преобразование текста к верхнему и нижнему регистру 244 Правила подчеркивания 244 Принтеры 244 Размеры бумаги 244 Процессоры и видео 244 Форматы данных и опции настройки 245 Единицы измерения 245 Изображения, связанные с конкретной культурой 246 Выходные данные, связанные с конкретной культурой 246 Совместимость с местными продуктами 246 Не будьте наивными 246 Автоматизированное тестирование 247 Глава 10. Тестирование документации 2 4 8 Хорошая документация 249 Цели тестировщика документации 251 Как тестирование документации повышает надежность программного продукта 252 Назначьте технического редактора 254 Работа с руководством в процессе его разработки 254 Интерактивная справка 262 Глава 1 1 . Инструментальные средства тестировщика 2 6 4 Базовые инструменты тестировщика 265 Автоматизация приемочного и регрессионного тестирования 267 Стандарты 277 Тестирование "стеклянного ящика" 280 Глава 12. Планирование и документация 2 8 4 Общее назначение тестового плана: продукт или инструмент? .... 286 Цели, преследуемые при планировании тестов и разработке документации 288 Тесты каких типов следует фиксировать в плановых документах .. 296 Стратегия разработки компонентов тестового плана 300 Компоненты плана тестирования 307 Документирование тестовых материалов 339 Заключение 355 8 Тестирование программного обеспечения Часть III. Управление проектами и группами 357 Глава 13. Объединяющая .. 3 5 8 Чем приходится поступаться разработчикам программного обеспечения 360 Модели разработки программного обеспечения 362 Затраты на качество 371 Последовательность этапов проекта 373 Проектирование продукта 381 Реализация базовых функций 388 Почти альфа 389 Альфа 392 Пре-бета 404 Бета 405 Замораживание пользовательского интерфейса 415 Подготовка к финальному тестированию 418 Последняя проверка целостности 423 Выпуск : 425 После выпуска 426 Глава 14. Управление группой тестирования 4 2 8 Роль группы тестирования 430 Группа тестирования — не избавление программистов 434 Альтернатива: независимые тестовые агентства 435 Советы по планированию 439 Персонал 447 Приложение. Распространенные программные ошибки .... 4 5 3 Ошибки пользовательского интерфейса 455 Обработка ошибок 486 Ошибки, связанные с граничными условиями 490 Ошибки вычислений 493 Начальное и последующие состояния 496 Ошибки управления потоком 500 Ошибки обработки или интерпретации данных 515 Ситуации гонок 523 Повышенные нагрузки 527 Аппаратное обеспечение 531 Контроль версий и идентификаторов 536 Ошибка выявлена и забыта 542 Предисловие Тестирование программного обеспечения — это книга, написанная профес сионалами для профессионалов. Что такое тестирование потребительских и деловых программ в условиях, приближенных к боевым, мы знаем не понаслышке, поскольку выполняли эту работу для самых известных про изводителей программного обеспечения Кремниевой Долины. Лежащее перед вами руководство разрабатывалось для наших собственных сотрудни ков. О том, как тестировать программные продукты, от которых требуется повышенная надежность, написано немало хороших книг. От надежного функционирования определенных типов программного обеспечения может зависеть успех бизнеса — работы финансовых или промышленных компа ний — или даже... человеческая жизнь. Поэтому на его самое тщательное проектирование, разработку и тестирование не жалеют ни времени, ни денег. Сотрудникам тестовых групп предоставляется полный доступ к ис ходному коду программ, причем на столько времени, сколько потребуется для его подробного изучения. Сверхнадежное программное обеспечение можно сравнить с "Роллс- ройсом" — роскошно, но дорого. Однако не все программное обеспечение таково, и дело не только в его цене. Тестирование программных продук тов для среднего бизнеса, академических учреждений и личного пользова ния проводится в более сжатые сроки и скромнее оплачивается, но их качество вполне удовлетворяет требованиям рынка — это полезные и на дежные программы, многими из которых производители могут заслужен но гордиться. Так как же организовать тестирование программных продуктов, чтобы его результаты можно было назвать сверхнадежными? И как удается груп пам тестирования обычного потребительского ПО в условиях сжатых сро ков, малочисленной команды и ограниченных средств выпускать прекрасные и вполне конкурентоспособные продукты? Обо всем этом вы узнаете из книги Тестирование программного обеспечения. Чего в этой книге нет Часто авторы книг утверждают, что для успешного тестирования необ ходимо, чтобы все было по правилам: документация, включающая необхо димые для разработки спецификации была полной и своевременной, при проектировании и написании кода применялась правильная и самая совре менная методология и т.д. 10 Тестирование программного обеспечения Эта книга — о тестировании в условиях, когда те, с кем вы работаете, не следуют, не хотят и не должны следовать правилам. На деле при разработке программного обеспечения бюджет всегда слишком мал, сотрудников не хватает, согласия между ними для выработ ки единой линии добиться трудно, а работа при этом должна быть выпол нена "на вчера". Качество большого продукта зависит от работы каждого, кто его проек тирует, программирует, тестирует и документирует. Никакие стандарты и спецификации, никакой контроль и отслеживание изменений не гаранти руют качества продукции. Все зависит только от людей — их работоспособ ности, мастерства и умения работать в команде. Только это определяет результат, а никак не правила. У команды разработчиков имеется определенное видение будущего продукта, горячее желание осуществить задуманное и понимание того, что во многом работа будет делаться методом проб и ошибок. К тому време ни, когда каждый аспект разработки прорисуется до деталей, будет сфор мирована рабочая версия проекта, которую смогут понять и охватить целиком один-два ведущих специалиста. Эта версия и называется специфи кацией. Спецификация не выгравирована на камне: позднее она не раз еще будет пересматриваться и усовершенствоваться, пока не будет достигнута полная согласованность со всей системой. И выполняя тестирование, вы тоже примете участие в этой работе. В реальной жизни изменения вносятся в продукт даже в самом конце разработки. Если, например, программа разрабатывается на продажу, ваши пользователи — потенциальные пользователи — ни на какую спецификацию не соглашались. И если конкурент создает нечто более привлекательное, отвечать приходится быстро. Как часто приходится отказываться от внесения в программу полезных дополнительных возможностей из-за нехватки времени. И часто первая рабочая версия фрагмента, которую никак нельзя назвать профессиональ ной, остается последней, поскольку переписывать ее некогда. Бывает, что программист "втихаря" по собственной инициативе все же выполнит нуж ную работу и без предупреждения внесет в проект значительные измене ния. Такая работа делается не по обязанности, сверх положенных 40 часов в неделю. Она может значительно улучшить проект, а может и серьезно его дестабилизировать на некоторое время. Но каким бы ни был результат, личная инициатива всегда направлена на улучшение проекта. Изменения в конце разработки есть всегда, и они нужны. Главное — справиться с ними с минимумом потерь. Не стоит разводить бюрократию, Предисловие 11 пытаясь запретить такие изменения. Профессионализм сотрудников груп пы тестирования заключается в том, чтобы принять реальность такой, как она есть, не жалуясь и не пытаясь бороться с ней запретами, и успешно закончить тестирование продукта вместе с внесенными изменениями. Для кого предназначена эта книга Эта книга предназначена для того, кто выполняет тестирование про граммного кода, обычно написанного кем-то другим. В ней обсуждаются вопросы и решения, которые на наш взгляд интересны и полезны такому человеку. Поэтому рассказ наш не академичен, в нем не затрагиваются такие классические темы, как доказательства правильности программного кода. Мы постарались больше уделить внимания темам, не характерным для учебников, как, например, межличностные взаимоотношения и корпо ративная политика. Судить о работе других людей приходится даже начи нающему тестировщику — в этом суть тестирования. За высказывание своих суждений тестировщики нередко подвергаются нападкам со стороны разработчиков. (Бывает, что и заслуженно.) Поскольку группа тестирования работает с программой последней и ее результаты у всех на виду, ее ответ ственность всегда оказывается больше возможностей — положение поли тически самое невыгодное. Решения этой проблемы у нас нет. Однако мы готовы поделиться своим опытом в том, как повысить эффективность ра боты и избежать некоторых неприятных моментов и ошибок. Поговорим мы также и об управлении проектом. Оценка, планирование и составление календарного плана работ по тестированию программного продукта — задача не из легких, ведь конечная точка фактически не опре делена. Всегда остаются тесты, которые еще полезно было бы провести, и риск, связанный с отказом от их выполнения. Специалист по тестированию должен это хорошо понимать и принимать во внимание при планировании работ. Например, можно отложить важный тест, чтобы в совершенстве выполнить другую часть работы, а потом обнаружить, что времени на от ложенный тест уже нет. В результате, пытаясь выполнить работу лучше, вы на самом деле сделаете ее хуже. К сожалению, ситуация эта очень типич на. Поэтому в нашей книге много внимания уделено вопросам эффектив ности и правильной расстановки приоритетов. Бывает, что при тестировании программного продукта приходится иметь дело с ошибками, допущенными еще на стадии проектирования. Програм ма может в точности соответствовать спецификации, но, если специфика ция содержит ошибки, такая программа, увы, для работы не годится. Часто в литературе, посвященной вопросам надежности программного обеспечения и методикам его тестирования, совсем не уделяется внимания пользовательскому интерфейсу программ. Ее авторы считают, что этим 12 Тестирование программного обеспечения вопросом должен заниматься специалист по анализу человеческого факто ра. Мы же с этим абсолютно не согласны. (И даже имеющийся в нашем коллективе специалист по анализу человеческого фактора с этим не согла сен.) Ведь надежность системы зависит от того, насколько хорошо работают вместе все ее составляющие, включая и людей, которые используют програм му. Задача специалиста по тестированию — выявить все проблемы, которые могут возникнуть при работе с продуктом, и сделать все возможное для улучшения его качества. Помните, что вы тестируете не просто програм му, вы тестируете систему человек-компьютер, и отчеты о ненадежности или неэффективности взаимодействия между человеком и компьютером не менее важны, чем остальные. Вы один из немногих специалистов, анали зирующих продукт во всех деталях, причем непосредственно перед его пре доставлением пользователю. И поэтому кто же, как не вы, сможет выявить и устранить подобные проблемы. Прочитав разделы нашей книги, посвященные пользовательскому ин терфейсу, вы не станете в этом вопросе специалистом — книга не претен дует на абсолютную полноту освещения этой темы. Может быть, некоторые из ваших предложений будут неверны. Но все же предоставьте отчеты и на тему интерфейса. Они очень важны. И некоторые из них обязательно помогут улучшить конечный продукт. Программное обеспечение, к которому предъявляются повышенные требования по надежности При создании определенных типов программного обеспечения отступ ление программистов и управляющего персонала от стандартизированной методологии абсолютно недопустимо. Например, программы, управляющие ядерным реактором, должны быть специфицированы и документированы самым тщательным образом. И в случае их сбоя отчеты о тестировании становятся юридическими документами. Для тестирования таких проектов выделяются огромные средства и этим занимаются очень большие группы специалистов, называемые группами гарантии качества (Quality Assurance). Для обучения сотрудников таких групп больше подойдут другие книги — строго академического характера. Но даже на таких проектах в конце работы часто подключаются груп пы приемки, бюджеты которых мизерны, а сроки предельно коротки. Сотрудники таких групп не участвуют в разработке и часто из-за недостат ка времени не могут по-настоящему серьезно протестировать продукт. Если Предисловие 13 вы работаете именно в таких условиях, эта книга будет для вас полезнее, чем традиционные учебники. Можно ли назвать эту книгу учебником? Мы принимали на работу множество специалистов по тестированию, но еще ни разу не встречали выпускника компьютерного факультета, который узнал бы что-нибудь полезное о тестировании из университетского курса. Организациями Association for Computing Machinery (Ассоциация вы числительной техники) и IEEE Computer Society (Компьютерное сообще ство IEEE) недавно был опубликован документ Computing Curricula 1991 (рекомендованный учебный план компьютерных факультетов), который в значительной степени определит содержание университетских учебных программ в области компьютерных наук на все следующее десятилетие. Время, отводимое на изучение технологий тестирования, обычно составляет несколько часов на четырехгодичный курс. В документе Computing Curricula предлагается ввести необязательный курс под названием Advanced Software Engineering (Продвинутый курс разработки программного обеспечения), вклю чающий среди прочих и темы тестирования, но идеи о специальном кур се тестирования в этом руководстве нет. Итак, не похоже, что в ближайшие десять лет выпускники компьютер ных факультетов университетов будут хоть что-нибудь знать о тестирова нии программных продуктов. Но почему бы этот пробел не заполнить колледжам? Associate of Sciences (Ассоциация наук), у которой есть несколько курсов по тестиро ванию, дополненных вводным курсом программирования и управления проектами, вполне могла бы с этим справиться. К тому же стартовая зара ботная плата специалистов по тестированию достаточно высока. Так что, по нашему мнению, колледжам стоит подумать о подготовке таких специ алистов — это дело как раз для них. Работая над последним изданием этой книги, мы внесли в нее много дополнений, рассчитанных именно на студентов колледжей — тех, которым никогда не приходилось бывать с тестовых лабораториях. Надеемся также, что книга будет полезна тем колледжам, которые захотят включить в свои программы курс тестирования делового программного обеспечения. 14 Тестирование программного обеспечения Структура книги и принятые в ней соглашения Сначала несколько замечаний о структуре книги Эта книга представляет собой учебное пособие. В вопросах, которым она посвящена, многие из ее читателей будут новичками. Будут ее читать и опытные специалисты, обучившиеся своему делу на практике и никогда еще не читавшие подобных учебников. Планируя структуру книги, имен но на таких читателей мы и ориентировались. Представленная в книге информация разделена по степени сложности, чтобы читатель мог осваивать ее постепенно. Вместо того чтобы пытаться осветить все стороны вопроса в одном разделе, мы сначала рассказываем о его сути, а в следующих разделах предлагаем дополнительные сведения, позволяющие понять его глубже или изучить подробнее. |