Тестирование-книга. Ю. Н. Артеменко Научный редактор
 Скачать 6.27 Mb.
|
|
Поиск способа воспроизведения ошибки Как мы уже говорили, ошибка воспроизводима, если ее можно увидеть, выполнив описанные в отчете действия. Задача его составителя — объяс нить, как достичь определенного состояния программы и какие действия выполнить в нем для воспроизведения ошибки, а также рассказать, в чем она состоит. Чтобы точно знать, что проблема не вызвана последствиями какой-нибудь другой ошибки, найденной перед этим, лучше всего перезаг- Глава 5: Документирование и анализ ошибок 1 2 3 рузить компьютер, повторно запустить программу и воспроизвести пробле му "с чистого листа". Но бывает, что воспроизвести ошибку повторно не удается. Более того, иногда тестировщик вообще не знает, как именно он ее получил. Что де лать в этом случае? Прежде всего следует записать все, что вы помните: в чем состояла ошибка и что вы делали, перед тем как ее увидели. Кроме действий, непос редственно связанных с ее появлением, опишите и более ранние. Запишите каждую мелочь, которую сможете вспомнить. Затем спросите себя: "Поче му же эту ошибку трудно воспроизвести?" Многие тестировщики делают видеозаписи своей работы, тем более что это можно сделать средствами самого компьютера. Это помогает сэконо мить многие часы работы. Кроме того, если ошибку так и не удастся вос произвести, видеозапись послужит подтверждением, что она все-таки была. Кроме видеозаписей, некоторые тестировщики пользуются программами перехвата клавиатурного и иного ввода, с помощью которых впоследствии можно воспроизвести свои действия. В некоторых случаях все эти спосо бы только задерживают работу, но если программа полна трудновоспроиз- водимых ошибок, их значение невозможно переоценить. Если простое повторение действий пользователя не срабатывает, это еще ничего не значит. Существует множество ошибок, которые проявляют ся только при определенном сочетании условий, иногда весьма неожидан ных. Любая ошибка на самом деле воспроизводима. Вопрос только в том, как найти условия, которые ее вызывают. И иногда это проще сделать программисту, перед глазами которого программный код. Однако не сто ит опускать руки прежде времени. Вот несколько направлений поиска ис точника ошибки. Повышенная нагрузка Обычно тестировщик выполняет привычный тест очень быстро. Стол кнувшись с ошибкой, он повторяет выявивший ее тест, но уже гораздо медленнее и внимательнее. И если на этот раз ошибку повторить не уда ется, все дело может быть как раз в разнице скорости: в первый раз про грамму заставили работать быстрее, чем она может. Стоит попробовать снова выполнить тест с обычной скоростью — сделайте это несколько раз. Попробуйте увеличить нагрузку на компьютер или перейти на менее ско ростную машину. Пропущенные детали Если программа тестируется неформально, без строгого плана, тестиров щик может просто забыть, что именно он делал, или упустить какую-ни будь мелкую деталь, которая на самом деле была ключевой. Бывает, что 1 2 4 Часть I: Основы тестировщик просто, не глядя, нажимает какие попало клавиши — как тут разобрать, из-за чего произошел сбой? Но даже при плановом тестировании можно отвлечься и случайно выпол нить что-либо дважды или просто нажать не на ту клавишу. Причиной неудачи с воспроизведением ситуации может быть ваша собственная ошибка или слу чайное незапланированное действие. В этом случае нужно постараться как можно точнее вспомнить, до какого момента работы все шло по плану и где именно вы отвлеклись, чтобы максимально локализовать проблему. Ошибка пользователя: вы сделали вовсе не то, что думаете Разумеется, как пользователь программы тестировщик может просто- напросто ошибиться. Например, если исчезли нужные данные, это может означать не ошибку программы, а то, что вы их случайно удалили. Но предполагать собственную ошибку тестировщику следует в самую после днюю очередь. У этого вопроса есть еще один аспект. Тестировщик может допустить ошибку, которую очень часто будут допускать и пользователи программы. И если она реагирует на эту ошибку неадекватно или последствия разру шительны для данных, это уже серьезная проблема, о которой необходи мо составить отчет. Не игнорируйте такие ошибки, лучше тщательно проанализируйте происходящее и подумайте, как усовершенствовать про грамму, чтобы сделать ее более дружественной и надежной. Ошибка с разрушительными последствиями Бывает, что последствия ошибки настолько разрушительны, что ее не возможно сразу повторить, а может быть, вы и не захотите этого делать. Например, программа может разрушать файлы, выполнять запись в крити ческие области памяти, блокировать систему. Прежде чем приступить к воспроизведению ошибки, придется сначала восстановить работоспособ ность системы. Вот пример ситуации, связанной с подобной ошибкой. Пользователь присылает вам дискету с данными, при обработке которых программа сбо ит. Вы запускаете программу, и она разрушает данные на этой дискете. Ошибку удалось воспроизвести, но, чтобы сделать это еще раз, придется просить пользователя снова прислать данные. Чтобы избежать подобных проблем, перед воспроизведением ошибки следует всегда делать резервные копии данных. Никогда, никогда, никогда не работайте с исходными данными — только с копиями. Глава 5: Документирование и анализ ошибок 1 2 5 Ошибка, зависящая от объема памяти Сбой программы может происходить только при определенных услови ях, связанных с типом, объемом и структурой доступной памяти. В этом случае полезно вставить в программу отладочные сообщения об объеме доступной памяти при ее загрузке и в ключевые моменты выпол нения. Эти сообщения программа может выводить при нажатии определен ной клавиши, и иногда их даже оставляют в окончательной версии продукта для его дальнейшей поддержки. Ошибка, проявляющаяся только при первом запуске Первое, что делают после запуска очень многие программы, — это считывают с диска инициализационную информацию. Если при самом первом запуске программы инициализационные файлы не содержат нуж ной информации, программа может вести себя непредсказуемо. Однако при выходе программа сохранит в этих файлах корректные данные, и дальше все пойдет хорошо. Данная ошибка проявляется только однажды, и ее можно было бы считать безвредной, если бы не тот факт, что с ней стол кнется каждый пользователь. Еще одной сходной ошибкой может быть неправильная интерпретация программой собственной неинициализированной памяти. Например, про граммист может забыть инициализировать переменную сразу после ее со здания, и при обращении к ней программа использует содержимое переменной как осмысленное значение, что вызывает отклонения в ее работе. Через некоторое время переменная будет инициализирована и все пойдет правильно. Такая ошибка может проявляться при одной последова тельности выполнения программы и отсутствовать во всех других случаях. В данном случае вся проблема в том, как найти то состояние програм мы или данных, в котором проявляется ошибка. В первом из описанных случаев это проще — следует только еще раз установить исходную, ни разу не запускавшуюся копию программы. Во втором можно попробовать вос становить исходное состояние данных и вспомнить все действия, выпол нявшиеся с программой от ее запуска до завершения, даже если они никак между собой не связаны. Ошибка, связанная с разрушенными данными Если данные программы по какой-либо причине разрушены, это может вызвать сбой в ее работе. При этом неважно, в чем причина их разруше ния — это могла сделать сама программа, а может быть, дело в абсолютно внешних обстоятельствах. В любом случае программа может обнаружить разрушение данных и выдать вполне корректное сообщение об ошибке, а может повести себя совершенно непредсказуемо. Для воспроизведения 1 2 6 Часть I: Основы подобной ошибки необходимо снова запустить программу с теми же дан ными. Ошибка, являющаяся побочным эффектом другой проблемы Если в процедуре обработки ошибок имеется ошибка, восстановление после очередного сбоя может пройти неудачно. В этом случае может про изойти все что угодно, и в том числе новая ошибка. Для ее повторения понадобится воспроизвести причину первого сбоя. Нерегулярные аппаратные сбои Как правило, аппаратные проблемы, если уж они имеются, носят регу лярный характер. Например, микросхема памяти либо работает, либо нет. Но бывает, что из-за плохого контакта или случайного колебания напря жения происходит единовременный сбой, который больше не повторяется. В результате сбоя может, например, быть повреждена определенная область памяти, точнее, хранящиеся в ней данные или программный код. Однако не стоит торопиться с выводами. На аппаратный сбой ошибку следует списывать в самую последнюю очередь. Дата и время Программа, работа которой зависит от даты или времени, может выпол нять некоторые специфические действия в полночь, первого января или в конце февраля в високосный год. Общеизвестна "Проблема 2000 года" — возможность сбоев самых раз нообразных программ при переходе от 31 декабря 1999 года к 1 января 2000 года из-за ошибок, связанных с проверками попадания даты в определен ный диапазон, формированием даты по умолчанию и другими подобными моментами. Поэтому в любой программе, работающей с датами и временем, следует внимательно проверить значения, попадающие на границу суток, недели, месяца, года, високосного года и столетия. Зависимость от ресурсов В многозадачной системе ряд процессов могут совместно использовать ее ресурсы — процессор, внешние устройства, память и др. Пока один процесс печатает данные, другой должен ждать освобождения принтера. Если одному процессу выделено 90% всей памяти, другому придется обхо диться десятью. Поэтому в программе должны быть предусмотрены дей ствия, выполняемые в случае отсутствия необходимых ресурсов. Если здесь имеется ошибка, для ее воспроизведения потребуется восстановить состо- Глава 5: Документирование и анализ ошибок 1 2 7 яние среды выполнения — снова запустить программы, занимающие па мять, принтер, коммуникационный порт и т.п. Пауза между ошибкой и ее проявлением Если в программе происходит ошибка, вовсе не обязательно, что она сразу же проявится. Ее результаты могут оставаться скрытыми, возможно, ошибка должна будет повториться много раз, и видимый результат может проявиться при выполнении совсем другой, абсолютно правильной и ты сячу раз проверенной подпрограммы. Типичным примером подобной ситуации является переполнение стека или другой аналогичной структуры. Стек — это область памяти, зарезерви рованная для временного хранения данных. Программа помещает в него информацию, работает с ней, а после использования удаляет. Если одна из процедур забывает выполнять этот последний шаг, через какое-то время стек окажется переполненным и другая, вполне исправная процедура не сможет поместить в него данные. Переполнение стека часто вызывает се рьезный сбой программы. Чтобы повторить эту ошибку, нужно выполнить "провинившуюся" часть программы столько раз, сколько необходимо для переполнения сте ка. Если процедура, в которой происходит сбой, выдерживает тестирование, следует выяснить, какая из процедур выполнялась до нее. Особые фрагменты кода Тестируя программу извне, вы понятия не имеете, какие критические точки и граничные условия присутствуют в ее коде. Поэтому программист может иногда сэкономить вам часы и дни работы, мгновенно найдя ошиб ку, проявляющуюся только в очень специфических обстоятельствах. Однако в книге этот способ поиска причины ошибки не случайно стоит последним. Донимая программиста постоянными отчетами о невоспроизводимых ошибках, можно серьезно испортить с ним отношения. Он может подумать, что вы ленивый или неквалифицированный тестировщик и перекладыва ете на него собственную работу. Кто-то поэкспериментировал с вашим компьютером Такое случается. Вы проводили тестирование и вышли ненадолго. Пока вас не было, кто-то подошел к компьютеру, ввел некоторые данные, пора ботал с программой, выключил принтер. Это могла быть намеренная шутка. А может быть, шеф демонстрировал программу гостю и забыл вас предуп редить. Оставляя компьютер включенным, вы всегда рискуете, вернувшись, найти его в другом состоянии. Часть Приемы и технологии тестирования Глава 6. Система отслеживания проблем Глава 7. Разработка тестов Глава 8. Тестирование принтеров и других устройств Глава 9. Адаптационное тестирование Глава 10. Тестирование документации Глава 11. Инструментальные средства тестировщика Глава 12. Планирование и документация II Глава 6 Система отслеживания проблем Назначение этой главы В предыдущей главе рассказывалось о том, как составить отчет о вы явленной проблеме. Теперь вам предстоит узнать о дальнейшей судьбе этого отчета. В данной главе речь пойдет о структуре базы данных, являющейся основой системы отслеживания процесса исправления оши бок и решения иных проблем, выявляемых в ходе тестирования про г р а м м н о г о обеспечения. Основное внимание б у д е т направлено на рассмотрение потоков циркулирующей в системе информации и нуждам использующих ее людей. Приведенные формы и отчеты применяются в одной из вариантов реализации данной системы, но, разумеется, м о ж но разработать и другой ее вариант, более гибко отражающий специ фику работы конкретной компании. Примечание До сих пор под словом "вы" в этой книге имелся в виду начинающий те- стировщик. В этой главе ситуация меняется, и дальнейший рассказ об ращен у ж е не к новичку, а к профессионалу, готовому взять на себя руководство проектом. Предполагается, что читатель руководит группой тестирования и его слово в разработке системы отслеживания проблем имеет значительный вес. Однако и т е м , у кого е щ е нет столь серьез ного профессионального опыта, прочитать эту главу будет небезынтерес но. Ее материал охватывает множество аспектов работы специалистов группы тестирования и их взаимодействия с остальными сотрудниками компании и изложен на вполне доступном уровне д а ж е для новичка. Обзор Первая часть главы посвящена вопросам наиболее эффективного исполь зования системы отслеживания проблем. Глава 6: Система отслеживания проблем 1 3 1 • Она начинается с общего обзора преимуществ системы и организа ционных проблем, связанных с ее внедрением. • Затем рассматривается главная цель внедрения системы и ее основ ная задача. Мы видим ее в том, чтобы добиться исправления макси мально возможного числа ошибок. • Для достижения этой цели система должна решать определенный комплекс задач. Вы узнаете и об этих задачах, и о предъявляемых к системе требованиях. • Далее рассматривается весь процесс отслеживания и решения про блемы. Что происходит с отчетом после его составления? Как реша ется описанная в н е м проблема, как исправляется ошибка и как система помогает выполнить эту работу наиболее эффективно. • Не меньшего внимания, чем сама система, заслуживают и ее пользо ватели. С ней работают очень многие сотрудники компании, обраща ясь к ней по самым разным причинам. Какая информация им нужна и каковы должны быть средства ее получения? Какую информацию они вводят в систему? Без точных ответов на все эти вопросы нельзя спроектировать ни одно средство автоматизации работ. Во второй части главы рассматриваются некоторые подробности постро ения системы отслеживания проблем. • П р е ж д е всего, приводится подробное описание основных ф о р м и от четов, применяющихся в большинстве подобных систем. • Далее предлагается несколько способов организации ее структуры, позволяющих максимально повысить эффективность работы с каждым из отчетов и минимизировать возможные конфликты м е ж д у пользо вателями. • В последнем разделе приводится несколько важных советов по про ектированию интерактивной формы ввода отчета о проблеме. Отчет о проблеме представляет собой первый и наиболее очевидный результат работы тестировщика. Но в то же время он — только начало работы по решению проблемы, и от того, как будет организована эта ра бота, зависит эффективность всего процесса создания программного про дукта. Организационная часть процесса решения проблем может быть автома тизирована. Минимум, что можно сделать, — это хранить все отчеты в системе в электронном виде и по ним автоматически составлять сводные документы. Кроме того, в хорошей системе должны быть средства органи зации взаимодействия между сотрудниками, участвующими в процессе решения проблем и исправления ошибок. До сих пор во многих фирмах, занимающихся разработкой программного обеспечения, применяется бу мажная форма отчетности или системы, которые сами сотрудники счита ют чересчур уж примитивными. В то же время создать удобную и эффективную автоматизированную систему отслеживания проблем не так 1 3 2 Часть II: Приемы и технологии тестирования уж трудно, и даже для сравнительно небольших проектов она стоит усилий, которые придется на это затратить. В данной главе предполагается, что ваша компания достаточно велика, чтобы в ней имелись руководитель группы тестирования, менеджер по маркетингу, руководитель проекта и группа технической поддержки. Это предположение позволяет говорить о людях, чьи роли четко распределены, но вовсе не означает, что на практике сотрудников не может быть гораз до меньше. Группа из двух человек, один из которых пишет программу, а второй ее тестирует, может работать по точно такой же схеме. Какой бы маленькой фирма ни была, все равно имеет смысл внедрить в ней автома тизированную систему отслеживания проблем — хотя бы в некотором объеме. Выбор конкретной организации системы отслеживания проблем бази руется на нашем собственном опыте — мы описали систему, показавшую себя наиболее эффективной. В книге приводится главная форма ввода данных, ряд стандартных отчетов и некоторые замечания по реализации. Всего этого достаточно, чтобы написать собственную программу автомати зации описанных задач. А кроме чисто технических подробностей, из этой главы вы узнаете об основных целях создания системы отслеживания про блем, ее роли в работе компании и влиянии на качество конечного продук та. Автоматизированная система отслеживания проблем прежде всего реша ет вовсе не технические, а политические вопросы. Это мощное организа ционное средство со следующими возможностями. |