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