Тестирование-книга. Ю. Н. Артеменко Научный редактор
 Скачать 6.27 Mb.
|
|
Глава 2: Желаемое и действительное в жизни тест...43 Нельзя проверить каждую возможную последовательность выполнения команд программы При каждом сеансе работы программы можно отследить последователь ность выполнения ее операторов от запуска до завершения. Последователь ности могут отличаться фрагментами кода или их порядком. Для примера давайте снова обратимся к программе из первой главы. Ее можно запустить и немедленно остановить нажатием Чтобы проиллюстрировать проблему, приведем очень упрощенный пример. Представьте систему, у которой есть всего несколько состояний и вариантов перехода между ними, но которую, тем не менее, очень слож но протестировать. Пример этот основан на ошибке, выявленной при те стировании работы реальной программы. • Система запускается в состоянии 1. Это ее основное состояние, и она возвращается в него при каждой возможности. • Из состояния 1 она всегда переходит в состояние 2. • Из состояния 2 она может перейти в состояние 3 или 5. • Из состояния 3 она может перейти в состояние 4 или 5. • Из состояния 4 она может перейти в состояние 3, 5 или 6. • Из состояния 5 она может перейти в состояние 1, 4 или 6. • Из состояния 6 она может перейти в состояние 3 или 5. Всего шесть состояний — ну что тут тестировать? Но так кажется лишь на первый взгляд. На деле же команда тестирования обнаружила, что, если система, прежде чем добраться до состояния 6, тридцать раз перейдет из состояния 4 в состояние 5, произойдет сбой. Как вы думаете, сколько для нахождения этой ошибки понадобится поверить различных последователь ностей выполнения, если не предположить ее существование заранее? Ошибка эта была найдена в телефонной системе РВХ. В состоянии 1 телефон молчит. Когда телефон звонит (состояние 2), то либо его владелец поднимает трубку (состояние 3 — соединение), либо звонящий вешает трубку (состояние 5 — отключение). Ответив на звонок, владелец телефо на может нажать кнопку Hold (состояние 4) или повесить трубку (состоя ние 5). Пока звонящий ждет у телефона (или повесит трубку), владелец может ответить на другой звонок (состояние 6 — ожидание переключения на ждущую линию). Когда владелец повесит трубку, прекратив и текущий, и ожидающий разговоры, телефон вернется в состояние 1. 44 Часть I: Основы Телефон у оператора РВХ часто бывает занят, и оператор очень часто пользуется кнопкой удерживания линии Hold. Когда оператор нажимает кнопку Hold, компьютер помещает некоторую информацию во временное хранилище, называемое стеком. При возвращении к отложенному разгово ру компьютер удаляет эту информацию из стека. Когда оператор вешает трубку и телефон возвращается в пассивное состояние, программа очища ет весь стек на случай, если одна из подпрограмм забыла стереть свои данные. Когда звонивший по ожидающей линии вешает трубку, данные о звонке остаются в стеке. Если оператор повесит трубку до того, как повесят трубку тридцать звонивших, все будет в порядке. Но если тридцатый человек повесит трубку, когда оператор будет продолжать говорить, стек перепол нится и телефон оператора выйдет из строя. Большинство программ несравнимо сложнее этого примера со стеком и шестью состояниями. И когда мы говорим, что невозможно проследить все пути выполнения программного кода, — это лишь одно из многих "невоз можно" в работе специалиста по тестированию. Поэтому профессионалы тестирования полагаются на эвристические стратегии, которые позволяют не наверняка, но зато с наибольшей вероятностью локализовать и выявить ошибки программы, и в первую очередь наиболее существенные. Какое огромное количество путей выполнения существует в любой, даже самой простенькой программе, продемонстрировал в 1976 году Май- ерс (Myers). Он описал программу из сотни строк, допускавшую 10 18 воз можных путей выполнения. Для сравнения он заметил, что наша вселенная существует меньше времени — 4*10 17 секунд. В 1979 году Майерс описал еще более простую программу. В ней был цикл и несколько операторов IF. В большинстве языков программирования для ее реализации понадобилось бы не больше 20 строк кода. Путей выполнения у этой программы 100 триллионов. Самому быстрому тестировщику понадобится для их проверки миллион лет. Программы Майерса просты. Да, они были специально составлены таким образом, чтобы допускать множество последовательностей выполне ния, но, если для программы из двух десятков строк возможны 100 трил лионов путей, сколько же их возможно для текстового редактора из 5 тыс. строк, простой электронной таблицы из 20 тыс. строк или настольной издательской системы из 400 тыс. строк? Слишком много. И не только для тестировщика, но даже для автоматизирующей его работу программы. Очень важно понимать, что, как и в случае со входными данными, программа не будет протестирована полностью, если не будет проверен Глава 2: Желаемое и действительное в жизни тестировщика 45 каждый возможный путь ее выполнения. Любой пропущенный вами путь останется потенциальным источником проблем. Для серьезного тестирования путей выполнения программы необходи мо проанализировать ее листинг. Не заглянув в код, вы не получите реаль ного представления о ходе ее работы. Сколько бы вы ни работали с программой извне, всегда останется вероятность пропустить огромные фрагменты кода, которые останутся ни разу не выполненными просто потому, что вы даже не подозреваете об их существовании и не знаете, в какой ситуации они выполняются. Вот еще одно интересное обстоятельство. Предположим, что за опреде ленное вполне реальное время программу можно протестировать полнос тью. Решило бы это проблему? Отнюдь. В процессе тестирования обнаруживаются ошибки. После их исправления программу снова прихо дится полностью тестировать. Обнаруживаются новые ошибки. Цикл повто ряется. Он может повториться раз десять, пока программа будет наконец готова к продаже. Если вы полагаете, что можете полностью протестировать программу один раз — прекрасно. Но что вы думаете о возможности повторения этой процедуры десять раз? Двадцать? Тридцать ? Невозможно выявить все ошибки проектирования Программа соответствует спецификации, если она в точности делает то, что указано в спецификации, и больше ничего. Некоторые люди полагают, что если программа соответствует спецификации, значит она правильная. Но что, если в спецификации сказано, что 2 + 2 должно равняться 5? Что будет для программы ошибкой — точное соответствие неверной специфи кации или отклонение от нее? Как и все остальные произведения рук человеческих, спецификации часто содержат ошибки. Одни из них случайны (2 + 2 = 5), другие же являются результатами заблуждений проектировщиков. Именно с ошибка ми проектирования связаны очень многие недостатки пользовательского интерфейса. Но ошибка есть ошибка — и пользователю все равно, на ка кой стадии разработки она допущена. Поэтому, если программа разработа на по неверной спецификации, мы говорим, что она неверна. Как и любые другие проблемы, все ошибки пользовательского интер фейса выявить невозможно. Мы не знаем никого, кто утверждал бы, что может это сделать. И это еще одна из причин несостоятельности идеи о полном тестировании программ. 46 Часть I: Основы Правильность программы нельзя доказать логически Основой работы компьютера является логика. Программы пишутся на очень точных языках. Проанализировав логику программы, можно опреде лить ее состояние в любой точке кода и в любой момент времени. Конечно, сразу встанут проблемы времени и количества всевозможных условий. Но даже если их не учитывать — что именно можно проверить, анализируя программный код? Только соответствие программы специфи кации, но никак не правильность самой спецификации. И еще одно. Доказательства — они ведь тоже строятся человеком, а значит, могут содержать ошибки и упущения. Где гарантия, что логика того, кто анализирует программу, точнее логики ее автора? Итак, мы описали уже целый ряд проблем. На самом деле их еще боль ше. Времени всегда слишком мало, а необходимой работы — слишком много. Если вопрос выполнимости полного тестирования вас заинтересовал, обратитесь к работам Бейзера (Beizer, 1984) и Данна (Dunn, 1984). Цель тестировщика - проверка правильности программы? Тестирование часто определяют как процесс проверки правильности работы программы. • Это определение бессмысленно: невозможно так проверить програм му, чтобы сделать заключение, что она работает правильно. • Кроме того, оно ошибочно: программа не работает абсолютно пра вильно. • Оно заранее предполагает неудачу: если цель тестировщика — пока зать, что программа работает правильно, то он терпит неудачу каж дый раз, когда находит ошибку. • Опираясь на него, тестировщик действует неэффективно: если вы заранее настроились на то, что ошибок в программе нет, вероятность их найти значительно уменьшается. Давайте по очереди разберемся с каждым из этих утверждений. Невозможно проверить, что программа работает правильно Как мы с вами уже выяснили, невозможно полностью протестировать ни одну программу (если только она не абсолютно элементарна). Отсюда Глава 2: Желаемое и действительное в жизни тестировщика 47 непосредственно вытекает еще одно утверждение: невозможно проверить, что программа работает правильно. Сбой может произойти в любой из миллионов не проверенных вами ситуаций. Программа не работает правильно По примерным оценкам на обнаружение и исправление ошибок тратит ся от 40 до 80 процентов общей стоимости разработки программного обес печения. Такие огромные деньги компании платят не за то, чтобы убедиться, что программы работают. Они вынуждены тратить деньги пото му, что их программы не работают — в них есть ошибки, и владельцы компаний хотят, чтобы эти ошибки были исправлены. Как бы грамотно, по самым современным методикам, ни была организована разработка, ошиб ки остаются всегда. Сколько в программе ошибок? По оценкам Бейзера (Beizer), сделанным им в 1990 году, передаваемые на тестирование программы в среднем содержат от 1 до 3 ошибок на каж дые 100 исполняемых операторов. И хотя есть очень талантливые програм мисты, у которых ошибок мало, все же совсем без ошибок не работает никто. Текущие ошибки От 1 до 3 ошибок на 100 строк кода в программе остается тогда, когда программист сдает работу тестировщику, утверждая, что она проверена и ошибок в ней нет. Но сам Бейзер приводил количество ошибок, допускае мых им в ходе проектирования и написания программы, — 1,5 ошибок на 1 ис полняемый оператор. Сюда он включил все ошибки, в том числе и опечатки. Это значит, что, если каждый оператор записан в отдельной строке, на 10 строк кода приходится 150 ошибок. Большинство программистов сами исправляют 99% своих текущих ошибок. Не удивительно, что они полагают, что исправили все. Но 1% ошибок все же остается: найти их и есть ваша работа. Если программа работает неправильно, значит ли это, что тестирование выполнено плохо? Это прозвучит смешно, но в нашей практике встречались менеджеры, возмущавшиеся, что тестировщики все еще выявляют ошибки, когда сро- ки работ уже подходят к концу. Иногда их недовольство высказывалось в полушутливом тоне, а иногда выражалось и в прямых обвинениях: "Все 48 Часть I: Основы ошибки да ошибки! Когда же наконец вы подтвердите, что программа работает и мы можем ее продавать?" Столкнувшись с таким отношением, не стоит теряться. Убедиться, что программа работает — это мечта неопыт ных менеджеров, а вовсе не ваша задача. Не стоит приступать к тестированию с надеждой на отсутствие ошибок Для работы тестировщика очень важно то, как он настроен (Майерс, 1979). Если вы уверены, что в программе есть ошибки, вы будете искать их гораздо тщательнее, чем если скажете себе: "Это прекрасная программа, и она правильно работает, мне нужно просто в этом убедиться". Любой пси холог охотно подтвердит, что человек всегда видит только то, что хочет видеть. Поэтому, например, так трудно при чтении текста заметить в нем орфографические ошибки: ведь ум сразу корректирует увиденное глазами. Изучая работу различных исследователей ученые-психологи выявили ряд интересных закономерностей. Они обнаружили, что, если исследова тель подсчитывает количество определенных сигналов, регистрируемых не приборами, а его собственными органами восприятия, результаты подсче тов очень сильно зависят от его ожиданий (Green & Sweets, 1966). Напри мер, если исследователь предполагает, что сигналов будет мало, он может часть их просто не заметить. Если к влиянию собственных предположений исследователя добавляются еще и другие психологические факторы, напри мер, поощрение при одних результатах исследования и неприятности при других, результаты эти будут искажены еще сильнее. То же будет и с вами: если вы ожидаете, что программа полна ошибок, за выявление которых вас к тому же еще и поощряют, то обнаружите их множество. Несколько выявленных ошибок будут даже ложной тревогой. Но если вы думаете, что программа работает правильно, а заказчики еще и жалуются на каждую найденную ошибку и очень недовольны, если тре вога оказывается ложной — тогда вы пропустите много серьезных проблем. А вот еще одно наблюдение психологов: даже самые умные, опытные, аккуратные и ответственные экспериментаторы подсознательно пропускают те тесты, которые могут опровергнуть их теорию или создать сложности в дальнейшей работе. Если же пропустить тест невозможно, его результаты неверно интерпретируются, игнорируются или при их анализе допускаются ошибки (Rosenthal, 1966). Итак, чтобы лучше всего выполнить свою работу, нацельте себя на выявление максимального количества ошибок. Нужно считать программу плохой, желать, чтобы в ней произошел сбой, и концентрироваться на поиске ее самых слабых мест. Какой бы суровой ни казалась такая позиция, именно она наиболее эффективна. Глава 2: Желаемое и действительное в жизни тестировщика 49 Если вы хотите, чтобы программа работала, если вы этого ждете, то, скорее всего, вы увидите то, чего ждали, и пропустите имеющиеся ошибки. А рассчитывая найти ошибки, вы обязательно их найдете. Если за отчеты об ошибках вас ожидают неприятности, вы не только не составите нужных отчетов, но даже не заметите самих ошибок. Итак, для чего же тестируют программы? Всех ошибок все равно не найти. И вы никогда не сможете сказать с уверенностью, что программа работает правильно. Так зачем же ее тести ровать? Программу тестируют для того, чтобы найти в ней ошибки Смысл тестирования заключается в поиске проблем. Ваша цель — найти их как можно больше, и чем серьезнее найденные проблемы, тем лучше. Помните, что времени всегда очень мало, и старайтесь использовать его как можно эффективнее. Мы еще не раз с вами поговорим о том, как правильно спланировать работу и как расставить приоритеты (в частности, в главах 7, 8, 12, 13). Главное же, на что нужно опираться, можно сфор мулировать очень просто. Если тест позволил выявить проблему, значит, он успешный. А тест, не выявивший проблем, был потерей времени. Эту мысль подтверждает одна очень наглядная аналогия (Майерс, 1979). Представьте, что с вашим здоровьем что-то не в порядке. Вы приходите к врачу, и он проводит целый ряд анализов. Однако врач ничего не находит — он утверждает, что вы здоровы. Хороший ли он диагност? Если вы в самом деле больны, остается признать, что врач некомпетентен, а дорого стоящие анализы были пустой тратой сил, времени и денег. При тестиро вании диагност — это вы, а программа (абсолютно наверняка) — больной пациент. Так найдите же, что с ней не так! Ошибки ищут для того, чтобы их исправить Вконечном счете большинство найденных ошибок исправляют, и ка- чество программного продукта улучшается. Это и есть настоящая цель тестирования — согласитесь, что, несмотря на суровое обращение тестиров в с программой, она весьма благородна. 3 Глава Типы тестов и их роль в процессе разработки программного обеспечения Назначение этой главы Эта глава — обзорная. Вот какую информацию вы в ней найдете. 1. Терминология. Профессиональный словарь тестировщика содержит на звания десятков методов тестирования и разработки программ, а также названия самих тестов и выявляемых с их помощью проблем. 2. Обзор процесса разработки программного обеспечения. Тестировщи- ки часто жалуются, что их подключают к процессу разработки слиш ком поздно, когда все принципиальные решения уже приняты. На самом же деле работа для тестировщика есть с самого начала — он может вносить полезные предложения на каждом этапе раз работки. Например, на этапе разработки спецификации тестировщик может проводить анализ логической правильности спецификации, ее выполнимости, полезности отдельных решений и тестируемости про граммного продукта. 3. Описание ключевых типов тестов. В этой главе описываются основные типы тестов программного обеспечения, рассказывается, для чего предназначен каждый тест и сколько на него требуется времени. Здесь же вы найдете и некоторые полезные советы, помогающие провести описанные тесты более успешно. Глава 3: Типы тестов .. |