Тестирование-книга. Ю. Н. Артеменко Научный редактор
 Скачать 6.27 Mb.
|
|
Тестирование "черного ящика" Когда кодирование завершено, программа передается группе тестирова ния. Вы ищете ошибки, составляете о них отчеты, затем получаете новую Глава 3: Типы тестов ... 81 версию программы и снова ищете ошибки. Вы находите старые ошибки, не замеченные на первом этапе, и новые, появившиеся после доработки. Вот как Мартин и Мак-Клер (Martin & mcClure, 1983) подытожили собранные Боэмом (Boehm) данные об эффективности исправления найденных оши бок. • Если для исправления ошибки нужно изменить не более десяти операторов, вероятность того, что это будет сделано правильно с первого раза, составляет 50%. • Если для исправления ошибки нужно изменить около пятидесяти операторов, вероятность того, что это будет сделано правильно с первого раза, составляет 20%. Проблема не только в том, что программист может не исправить ошиб ку до конца. Гораздо хуже другое — то, что исправления могут иметь по бочные эффекты. Исправление одной ошибки может привести к появлению другой. А бывает и так, что одна ошибка скрывает другую, которая прояв ляется только после ее устранения. К сожалению, программисты часто концентрируются только на поставленной перед ними проблеме и, решив ее, считают свою работу сделанной — регрессионного тестирования, пусть даже самого поверхностного, они не выполняют. Учитывая все сказанное, приготовьтесь тестировать одну и ту же про грамму много-много раз. На ранних стадиях тестирования исправленные версии программы могут поступать каждые несколько часов или дней. Поэтому среди специалистов распространена практика не принимать новую версию, пока не будет самым тщательным образом протестирована преды дущая. Такое полное тестирование очередной версии с составлением ито гового отчета обо всех известных проблемах и всех найденных в этой версии ошибках называют полным циклом. Руководители проектов часто рассчитывают ограничиться двумя цикла ми тестирования: в первом выявить все ошибки, а во втором убедиться, что все они исправлены. Но на самом деле для тестирования может понадо биться порядка восьми циклов, а если на каждом из них тестировать про грамму менее тщательно — тогда от 20 до 30. Стандартная процедура тестирования "черного ящика" В этом разделе описывается стандартная последовательность событий, свойственная тестированию "черного ящика" в мире персональных компь ютеров. В мире мейнфреймов все иначе. Друзья, работающие в банках, рассказывают, что они приступают к разработке тестов задолго до офици ального начала тестирования. 82 Часть I: Основы Планирование Как и всякая работа, тестирование программного продукта начинается с планирования: определяется стратегия, разрабатываются серии тестов, распределяются между сотрудниками задания. Начинать планирование можно сразу после того, как команда проектировщиков выработает требо вания к программному продукту. Однако чаще подробное планирование начинается на первом цикле тестирования, когда перед вами готовый про граммный продукт. О разработке тестов мы с вами поговорим в главе 7, а в главе 12 обсудим составление общего плана тестирования. Приемочное тестирование При поступлении каждой новой версии программного продукта тести- ровщики прежде всего проверяют, достаточно ли она стабильна. Если она "обрушивается" при малейшей провокации, возиться с ней не стоит. Такое первое беглое тестирование называют приемочным или квалификационным. Лучше всего, если приемочные тесты будут стандартизированы. Тогда их копии можно передать программистам, чтобы те проводили их сами и не сдавали вам программы раньше времени. Это позволит избежать возвра тов тестировщиками неработающих программ — моментов, психологичес ки неприятных для обеих сторон. Приемочные тесты должны быть короткими. В них должны проверяться только основные функции и основные данные. Если программа не прой дет даже такой тест, вы с полной уверенностью сможете утверждать, что эта ее версия никуда не годится. Во многих компаниях приемочные тесты частично автоматизированы с помощью специального программного обеспечения, выполняющего тести рование "черного ящика". Проверка стабильности программы Насколько стабильна полученная вами версия программы? Сколько циклов тестирования она выдержит — четыре или 24? Вас могут попросить оценить стабильность программы для составления календарного плана работ, оценить стоимость услуг по ее тестированию сторонним агентством или оценить качество программного продукта, который компания собира ется купить и распространять. В этом случае ваша задача состоит не в поиске ошибок, а в определе нии самых ненадежных частей программы. Если вам кажется сомнитель ным какой-нибудь особенно сложный элемент, тогда рассчитывайте, что тестирование будет долгим. Начните с изучения прилагаемого к програм ме руководства — в нем должны быть описаны все функции программы, а если повезет, еще и приведены простые и наглядные примеры. Проведите еще несколько тестов, на которых, как вам кажется, программа должна Глава 3: Типы тестов ... 83 сбоить. В конце такого оценочного тестирования у вас должно сложиться определенное представление о том, с чем вы имеете дело: сколько в про грамме ошибок и насколько тяжело будет ее протестировать. К сожалению, мы не сможем сказать, как транслировать это представление в человеко- часы — вам придется полагаться только на собственный опыт и професси ональное чутье. Обычно предварительная оценка стабильности программы занимает около недели. Если для тестирования всех ее функций этого времени не достаточно, проверьте часть из них. Но обязательно включите в свой отчет обзор каждого раздела руководства. И не стоит рассчитывать разобраться с программой меньше чем за неделю, если только она не элементарна и если это не очередная версия продукта, который вы много раз протестировали. Функциональное и системное тестирование, сверка и аттестация продукта Когда программный продукт готов и протестирован, он должен прой ти ряд завершающих тестов. Прежде всего, он должен быть еще раз сверен с наиболее подробными и близкими к нему проектными документами. В частности, должно быть проведено функциональное тестирование, при кото ром продукт сверяется с внешней спецификацией. Затем программа сверяется с опубликованной печатной документацией — пользовательскими {тестирование целостности) и системными {систем ное тестирование) требованиями. Эти две процедуры носят название атте стационного тестирования. В разговорах о тестировании вы можете встретиться с одним из попу лярных терминов — Independent Verification and Validation (IV&V — неза висимая сверка и аттестация). Он означает сверочное и аттестационное тестирование, проводимое независимым агентством. Более подробное описание процедуры сверки и аттестации можно найти у Андриоле (Andriole, 1986) и в документе IEEE Standard for Software Verification and Validation Plans (ANSI/IEEE Standard 1012-1986). Бета-тестирование И вот наконец вы подтверждаете, что программа достаточно стабильна и документация в порядке. Это значит, что наступило время для обратной связи с пользователями — бета-тестирования. На этом этапе с программой работают ее потенциальные пользователи. они эксплуатируют программу и присылают или высказывают вам свои замечания. Поскольку бета-тестировщики знают, что в программе могут оставаться еще очень серьезные ошибки, они не работают с ней полный день — на 20 часов тестирования у них уходит около трех недель. 84 Часть I: Основы 20 часов работы бета-тестировщика для компании- разработчика вовсе не бесплатны. Вам или другому сотруднику компании приходится тратить на каждого из них от 4 до 8 часов, вербуя новых людей, давая им консультации и отвечая на их вопросы. Кроме того, нужно писать для них инструкции и разрабатывать вопросники. Однако в определенных ситуациях бета-тестировщики работают с про дуктом гораздо более основательно. Вот какими могут быть их мотивации. • Пользователю очень нужен ваш продукт, даже если он и не надежен, а других подобных продуктов на рынке нет. • Вы достаточно платите. Обычно в качестве платы за бета-тестиро вание пользователь получает или бесплатную копию продукта, или значительную скидку. Если продукт дорогой, этого достаточно. Но если речь идет о программе, предназначенной для доступа к важной информации, и в этой программе происходит сбой, потеря данных может обойтись пользователю гораздо дороже стоимости программ ного продукта. • Вы даете пользователю выгодную гарантию. Например, вы обещае те, что в случае сбоя программы сотрудник вашей компании бес платно введет потерянные данные. Здесь мы привели лишь краткий обзор процедуры бета-тестирования, а подробное ее описание вы найдете в главе 13. Тестирование целостности готового продукта и тестирование распространяемых копий С завершением тестирования последней бета-версии готового программ ного продукта возможные проблемы не заканчиваются. Ведь нужно еще убедиться, что он в целости и сохранности попадет к клиенту. Нередко и на этом этапе случаются всевозможные неприятности: например, компании отсылают пользователям пустые или инфицированные диски. Для тестирования распространяемых копий вы собираете все, что будет отправлено пользователю или производителю, проверяете, все ли на мес те и в порядке, и делаете архивные копии. Только после этого продукт отправляется по назначению. Комплект дисков проверить проще всего: нужно просто выполнить их двоичное сравнение с последней версией продукта. Не пренебрегайте этой процедурой, даже если для создания дисков вы пользовались уже проверен- Глава 3: Типы тестов ... 85 ной копией. Такое сравнение обойдется вам гораздо дешевле, чем отправ ка пользователям новой партии, если что-то будет не так. Мы настоятельно рекомендуем включить в эту процедуру тестирования еще и проверку на вирусы. Если программное обеспечение поставляется в сжатом виде, не останавливайтесь на тестировании сжатых файлов: устано вите программу, запустите ее, перезапустите компьютер и убедитесь, что он не заражен. Имейте в виду, что за заражение вирусами пользователь может подать на вас в суд. Тестирование целостности программного продукта — работа более об стоятельная. Это ваш последний шанс что-либо изменить перед тем, как выпустить свое детище в жизнь. Тестировщик старается спрогнозировать все жалобы и критические замечания, которые могут появиться в прессе и поступить от пользователей в ближайшие несколько месяцев. Этим может заниматься ведущий специалист, который не участвовал в данной разработ ке, или даже сотрудник независимого агентства. В его задачи не входит поиск ошибок. Напротив, он предполагает, что и системное и функцио нальное тестирование проведены самым тщательным образом. Специалист внимательно сравнивает программу с пользовательской документацией и документами, в которых описаны требования к продукту. Кроме того, он может выполнить сравнение с конкурирующими продуктами. В рамках тестирования целостности продукта выполняется и анализ маркетинговых материалов — ведь возможности программы обязательно должны соответствовать рекламе. Потому и рекламная копия, и все печат ные и электронные рекламные материалы перед публикацией должны подвергнуться самой строгой проверке. Тестирование целостности программного продукта лучше поручить не команде, а одному человеку. Для однопользовательской программы сред ней сложности на это уйдет около двух недель. Окончательная приемка и сертификация Если ваша компания разрабатывает программное обеспечение по кон тракту, для его приемки клиенты должны будут провести собственные тесты. Если продукт невелик, тестирование может быть неформальным. Однако для большинства проектов процедура приемочного тестирования заранее согласовывается и фиксируется в контрактных документах. Поэто му, прежде чем передать программу клиенту, нужно убедиться, что она абсолютно безупречно проходит серию приемочных тестов. Обычно при емочное тестирование занимает не более одного дня и не является особен но тщательным. Как подготовить и провести формальное приемочное тестирование, подробно рассказывает Бейзер (Beizer, 1984). Хорошим учеб ником по разработке приемочных тестов является книга Перри (Perry, 1986). Особенно полезной эта книга может быть для тех, кто разрабатывает приемочные тесты совместно со своим клиентом. 86 Часть I: Основы Сертификация всегда выполняется сторонней фирмой — независимой или работающей на вашего клиента. Сертификационное тестирование может быть как коротким и поверхностным, так и более тщательным. По контракту оно может выполняться вместо приемочного тестирования. При этом уровень сертификационного тестирования и стандарты, которым дол жны соответствовать программа и процесс ее разработки обязательно дол жны быть записаны в контракте. Если же сертификация проводится по желанию компании-разработчика, например, из маркетинговых соображе ний, тогда она сама и определяет, какие провести тесты. Примеры тестов, проводимых при функциональном и системном тестировании Чтобы более наглядно пояснить суть описанного в предыдущих разде лах функционального и системного тестирования, приведем примеры тес тов, выполняемых на этом этапе. Сверка со спецификацией Проверяется соответствие разработанной программы каждому слову в спецификации. Правильность Правильно ли программа выполняет нужные вычисления и формирует отчеты? Лабораторные испытания Специалист по тестированию нанимает нескольких человек из числа будущих пользователей и наблюдает за их работой с продуктом. Фактичес ки бета-тестирование является попыткой получить тот же результат с мень шими затратами. Но поскольку вы не являетесь непосредственным свидетелем того, что происходит, и не можете давать тестировщикам зада ния, бета-тестирование гораздо менее эффективно, чем лабораторные ис пытания. Граничные условия Проверьте реакцию программы на граничные значения входных дан ных. Введите данные, в ответ на которые она сформирует максимальные или минимальные выходные значения. Производительность Обзаведитесь хорошим секундомером и измерьте время выполнения программой различных задач, особенно тех, которые пользователь будет выполнять чаще всего. Глава 3: Типы тестов ... 87 Переходы между режимами Правильно ли программа переходит из состояния в состояние? Это особенно важно для приложений, позволяющих параллельно выполнять несколько различных действий или переключаться между режимами, не завершая их работу. Что, если попытаться распечатать редактируемую таб лицу или сформировать по ней отчет? Что, если во время подготовки от чета ввести в таблицу новые данные? Эксплуатация в реальном режиме Попробуйте поработать с программой в том же режиме, в каком с ней будут работать реальные пользователи. Выполните с ее помощью реальную работу. Вы будете очень удивлены, увидев, сколько ошибок выявляет та кое тестирование. Недостатки, которых при формальном тестировании вы не заметили вовсе или посчитали их незначительными, в реальной работе могут оказаться очень серьезными. Нагрузочные испытания При нагрузочных испытаниях (load testing) проверяется реакция програм мы на предельные условия эксплуатации. • Тестирование на максимальный объем входных данных. Какое макси мальное задание окажется вашей программе по плечу? Компилято ру можно предложить откомпилировать очень большую программу, текстовому процессору — открыть огромный текстовый файл. В интерактивной программе можно попробовать непрерывно вводить очень большой объем информации, чтобы проверить, насколько надежен ее входной буфер. (Для того чтобы быстрее реагировать на действия пользователя, программы часто сохраняют информацию о нажатиях клавиш в небольшом буфере, а когда пользователь на се кунду приостанавливается, обрабатывают его содержимое.) Нужно посмотреть, как поведет себя программа в ответ на нестандартные данные, например, как компилятор или текстовый процессор посту пят с абсолютно пустым файлом. • Испытания в утяжеленном режиме. Как реагирует программа на резкое увеличение активности? Например, можно проверить, как поведет себя текстовый процессор, если пользователь будет вводить текст со скоростью 120 слов в минуту. Если максимально допусти мая активность пользователя оговорена в спецификации, нужно проверить, действительно ли программа хорошо справляется с ука занной нагрузкой. • Анализ требований к ресурсам. Необходимо изучить требования про граммы к двум важным ресурсам компьютера — оперативной памяти 88 Часть I: Основы и дисковому пространству. Если в спецификации записаны ограни чения на использование этих ресурсов, необходимо удостовериться, что ни при каких условиях программа не занимает больше памяти и дискового пространства, чем ей положено. Многопользовательская и многозадачная работа Если ваш продукт представляет собой сложную многозадачную или многопользовательскую систему, его тестирование значительно усложняет ся. Необходимо проверить, как он справляется с параллельным выполне нием нескольких задач и как координируются действия нескольких пользователей. Типичным примером таких систем являются многопользо вательские системы управления базами данных, где несколько пользовате лей, сидящих за различными и, возможно, даже достаточно удаленными компьютерами, могут одновременно вводить данные в одну и ту же табли цу. Для тестирования такой системы нужно организовать ее эксплуатацию в реальном режиме, привлечь для работы большое количество людей и тех ники и, возможно, написать специальные программы, имитирующие одно временный ввод данных. Более подробное обсуждение этого вопроса можно найти в книге Бейзера (Beizer, 1984). |