Тестирование-книга. Ю. Н. Артеменко Научный редактор
 Скачать 6.27 Mb.
|
|
Ошибки, связанные с обработкой граничных условий Простейшими граничными условиями являются числовые (такие, как в примере из первой главы). Но существует и много других граничных си туаций. Любой аспект работы программы, к которому применимы понятия больше или меньше, раньше или позже, первый или последний, короче или длиннее, обязательно должен быть проверен на границах диапазона. Внутри диапазонов программа обычно работает прекрасно, а вот на их границах порой случаются самые неожиданные отклонения. Ошибки вычислений Программирование даже самых простых арифметических операций всегда чревато ошибками. Нечего и говорить о сложных формулах и расче тах. Одними из самых распространенных среди математических ошибок являются ошибки округления. После нескольких промежуточных вычисле ний может оказаться, что 2 + 2 = -1, даже если на промежуточных этапах не было логических ошибок. 98 Часть I: Основы К этой категории относятся и ошибки, вызванные неправильным выбо ром алгоритма. Сюда можно отнести неправильные формулы, формулы, неприменимые к обрабатываемым данным, неверные способы разбиения сложных выражений на более простые элементы. В случае алгоритмичес кой ошибки код в точности выполняет то, что имел в виду программист, — он правильно закодировал неверную идею. Начальное и последующие состояния Бывает, что при выполнении какой-либо функции программы сбой происходит только однажды — при самом первом обращении к этой фун кции. На экране может появиться искаженное изображение или странная информация. Возможно, неверно выполнятся расчеты, запустятся беско нечные циклы или операционная система выдаст сообщение о нехватке памяти. Причиной такого поведения программы может быть отсутствие файла с инициализационной информацией. После первого же запуска про грамма создаст такой файл, и дальше все будет в порядке. Получается, что такую ошибку невозможно повторить (точнее, для ее повторения нужно установить новую копию программы). Но не стоит думать, что ошибка, проявляющаяся только при первом запуске программы, безвредна: ведь это будет первое, с чем столкнется каждый новый пользователь. Иногда, программируя процесс, связанный с последовательными пре образованиями информации, разработчики забывают о том, что пользова телю может понадобиться вернуться к исходным данным и изменить их. Насколько корректно поведет себя программа в такой ситуации? Позволит ли она внести нужные изменения и не будет ли из-за этого потеряна вся выполненная пользователем работа? Что увидит пользователь при возвра щении к исходному состоянию программы: свои данные или стандартные значения, которыми программа инициализирует переменные при запуске? Ошибки управления потоком Если по логике программы вслед за первым действием должно быть выполнено второе, а она выполняет третье, значит, в управлении потоком допущена ошибка. Такие ошибки трудно пропустить: в худшем случае в работе программы произойдет сбой, а при менее серьезной ошибке она просто "забредет не туда". Ошибки передачи или интерпретации данных Один модуль может передавать данные другому или даже другой про грамме. Некоторые данные могут передаваться между модулями множество раз, и на каком-то этапе они могут быть разрушены или неверно интерпре- Глава 4: Программные ошибки 99 тированы. Изменения, внесенные одной из частей программы, могут по теряться или достичь не всех частей системы, где они важны. Ситуация гонок Классическая ситуация гонок описывается так. Предположим, в систе ме ожидаются два события, А и Б. Первым может произойти любое из них. Но если первым произойдет событие А, выполнение программы продол жится, а если первым наступит событие Б, то в работе программы произой дет сбой. Программист полагал, что первым всегда должно быть событие А, и не ожидал, что Б может выиграть гонки. Тестировать ситуации гонок довольно сложно. Наиболее типичны они для систем, где параллельно выполняются взаимодействующие процессы и потоки, а также для многопользовательских систем реального времени. Ошибки в таких системах трудно воспроизвести, и на их выявление обычно требуется очень много времени. Перегрузки Программа может не справляться с повышенными нагрузками. Напри мер, она может не выдерживать интенсивной и длительной эксплуатации или не справляться со слишком большими объемами данных. Кроме того, сбои могут происходить из-за нехватки памяти или отсутствия других не обходимых ресурсов. У каждой программы свои пределы. Вопрос в том, соответствуют ли реальные возможности и требования программы к ресур сам ее спецификации и как программа себя поведет при перегрузках. Аппаратное обеспечение Программы могут посылать устройствам неверные данные, игнориро вать их сообщения об ошибках, пытаться использовать устройства, которые заняты или вообще отсутствуют. Даже если нужное устройство просто сло мано, программа должна понять это, а не сбоить при попытке к нему обратиться. Контроль версий Бывает, что старые ошибки вдруг всплывают снова из-за того, что про грамма скомпонована с устаревшей версией одной из подпрограмм. Поэто му версии всех составляющих проекта обязательно должны Централизованно контролироваться. Кроме того, следует убедиться, что правильны все появляющиеся на экране сообщения об авторских правах, 1 0 0 Часть I: Основы названии и номере версии программного продукта. Обязательной провер ке подлежат десятки мелких деталей. Обычно контроль версий программы и ее исходного кода осуществля ется группой контроля качества (Quality Assurance). Но, на наш взгляд, это скорее задача группы тестирования. Документация Сама по себе документация не является программным обеспечением, но все же это часть программного продукта. И если она плохо написана, пользователь может подумать, что и сама программа не намного лучше. Хотя подробное рассмотрение ошибок документации не входит в задачи этой книги, в главе 10 мы поговорим о ее тестировании. Ошибки тестирования Если программист допускает по полторы ошибки на каждую строку программного кода, то сколько их допускает тестировщик на каждый тест? Обнаружение ошибок, допущенных тестировщиками, — дело обычное. Конечно, если таких ошибок будет слишком много, вы быстро потеряете доверие остальных членов команды. Но нужно иметь в виду, что иногда ошибки тестировщика отражают проблемы пользовательского интерфейса: если программа заставляет пользователя делать ошибки, значит, с ней что- то не так. Конечно, многие ошибки тестирования вызваны просто невер ными тестовыми данными. 5 Глава Документирование и анализ ошибок Назначение этой главы Вероятность исправления ошибки зависит от того, как ее задокументи ровать. В этой главе вы научитесь составлять отчеты, позволяющие наи более эффективно взаимодействовать с руководителем проекта и программистом. Примечание Приведенная в этой главе форма отчета наиболее функциональна на бу маге. В тех компаниях, где принимаются рукописные отчеты, они затем вводятся в базу данных, и дальнейший процесс их обработки и анализа автоматизирован. Отчеты об ошибках и проблемах не всегда составляются тестировщика ми. Иногда такие отчеты поступают от сотрудников группы технической поддержки, группы документирования, а также продавцов, бета-тести- ровщиков и пользователей. Поэтому в данной главе используется обоб щенное понятие составитель отчета. Обзор В этой и следующей главах описывается эффективная и проверенная вре менем система документирования и дальнейшего отслеживания проблем и ошибок, выявляемых группой тестирования программного обеспечения. В данной главе подробно рассказывается о каждом поле составляемо го в рамках этой системы отчета о проблеме. Следующая глава посвя щена системе в целом и тому, как ее модифицировать в соответствии с требованиями конкретной компании. Поэтому, чтобы лучше понять назначение и дальнейшую судьбу каждого поля отчета, можно загляды вать и в главу 6. Итак, сейчас вам предстоит: • познакомиться со структурой типичного отчета об ошибке; освоить наиболее эффективный стиль составления отчета об ошибке; научиться анализировать воспроизводимую ошибку; познакомиться со стратегией поиска способа воспроизведения ошибки. 1 0 2 Часть I: Основы Если отчет об ошибке недостаточно четкий и понятный, программист не сможет ее исправить. Поэтому документированию ошибок необходимо уделять самое серьезное внимание: отчет должен составляться быстро, но при этом его тон и содержание должны максимально способствовать реше нию выявленной проблемы. Целью составления отчета об ошибке является ее исправление. Если вы хотите, чтобы найденная ошибка была быстро и надежно ис правлена, прежде всего сделайте следующее. • Объясните, как воспроизвести ошибку или проблемную ситуацию. Программисты игнорируют отчеты об ошибках, которых не могут увидеть своими глазами. • Тщательно проанализируйте ошибку, чтобы описать ее предельно кратко. Слишком пространное описание проблемы затрудняет по нимание ее сути. Кроме того, встретив длинный отчет, программист подумает, что речь идет о чем-то сложном, и с большой вероятно стью отложит его рассмотрение. • Составьте полный, понятный и непротиворечивый отчет. Если отчет путает программиста или недостаточно отчетливо и ясно со ставлен, он едва ли послужит хорошей мотивацией для устранения ошибки. Отчет следует составлять немедленно Обнаружив ошибку, следует сразу же составить о ней отчет. Хотя в нем довольно много граф, не стоит откладывать его заполнение, написав лишь короткие заметки. Очень важно, чтобы во время составления отчета все, о чем вы пишете, было у вас перед глазами, особенно это касается описания процедуры воспроизведения ошибки. Отчет ни в коем случае нельзя состав лять по памяти, иначе очень легко ошибиться — программист не сможет повторить ситуацию и отложит отчет. Эта проблема довольно типична: тестировщики жалуются, что программисты постоянно игнорируют их от четы, утверждая, что не могут воспроизвести ошибку. На самом же деле причина в неаккуратности самих тестировщиков. Столкнувшись с проблемой в работе программного обеспечения, сразу же составьте о ней полный отчет. Глава 5: Документирование и анализ ошибок 1 0 3 Структура отчета о проблеме Во всех компаниях, занимающихся разработкой и тестированием про граммного обеспечения, форма отчета о проблеме одна и та же. Разумеет ся порядок и названия его полей могут несколько отличаться, но представленная в нем информация неизменна. На рис. 5.1 показана фор ма отчета, которую предлагаем мы, а далее подробно описываются все ее поля. Программа Если тестируемый программный продукт состоит из нескольких про грамм или же компания разрабатывает несколько программных продуктов одновременно, следует обязательно указать, в какой именно программе обнаружена ошибка. Выпуск и версия В отчете обязательно должно быть указано, к какой именно версии программного кода он относится. Например, идентификатор версии может быть таким: 1.01д. Он означает, что речь идет о пятой (д) черновой версии выпуска программы номер 1.01. Поскольку программа все время находится в процессе усовершенство вания, программист может не найти ошибку в ее текущей версии. В этом случае он посмотрит, с какой версией работал тестировщик, и обратится к ней, чтобы все-таки воспроизвести ошибку и гарантировать, что она ис правлена. Кроме того, наличие в отчетах номеров версий тестируемых программ позволяет избежать путаницы с уже исправленными и повторно выявлен ными ошибками. Если программисту попадет в руки отчет об ошибке, которую он уже исправил, без номера версии программы будет трудно определить, в чем дело — ведь это может быть как старый отчет, так и новый, означающий, что ошибка исправлена плохо или не полностью. Тип отчета В графе Тип отчета указывается тип обнаруженной проблемы. 1. Ошибка кодирования. Программа ведет себя не так, как должна по мнению тестировщика. Например, если программа утверждает, что 2 + 2 = 3, то это явная ошибка кодирования. Программист же в от вет на отчет о такой ошибке вполне может написать Соответствует проекту. Глава 5: Документирование и анализ ошибок 1 0 5 2. Ошибка проектирования. Программа соответствует проектной доку ментации, но в определенном вопросе тестировщик с этой докумен тацией не согласен. Так особенно часто случается с элементами пользовательского интерфейса. На отчете данного типа программист не может написать Соответствует проекту, и если он считает, что проект верен, тогда он пишет Не согласен с предложением. 3. Предложение. Отчет такого типа не означает, что в программе что- то не так. В нем описывается идея, реализация которой, по мнению тестировщика, может улучшить программу. 4. Расхождение с документацией. Программа ведет себя не так, как описано в руководстве или интерактивной справке. В этом случае в отчете следует указать, в каком именно документе и на какой стра нице найдено несоответствие. При этом в отчете вовсе не утвержда ется, что ошибка именно в документации, а не в самой программе. Отчеты о расхождении с документацией обязательно должны совме стно рассматриваться программистом и автором документа ции. О функциях программы, которые вообще нигде не описаны, также следует составлять отчеты данного типа. 5. Взаимодействие с аппаратурой. Проблемы этого рода связаны с не удачным взаимодействием программы и определенного вида аппа ратного обеспечения. Если причина неудачи заключается в неисправности устройства, отчет о ней составлять не нужно. Одна ко если программа не может работать ни с одной платой или устрой ством конкретного типа — это уже проблема, которую следует документировать. 6. Вопрос. Программа делает что-то, чего тестировщик не ожидает или не понимает. Отчет-вопрос стоит составить при любых сомнениях. Если они окажутся основанными на действительной ошибке, про граммист ее исправит. Если же программист откажется исправить ошибку или его объяснение не покажется вам достаточно разумным, можно будет составить отчет об ошибке проектирования. Степень важности В этой графе тестировщик указывает, насколько, по его мнению, серь езна выявленная проблема. К сожалению, для определения степени важности проблемы не суще ствует строгого критерия. Бейзер (Beizer, 1984, с. 20), например, предлагает шкалу от 1 (незначительная ошибка, например грамматическая) до 10 (фа тальная, вызывающая сбои в других системах, войны, убийства и т.д.). Однако при этом Бейзер не считает значительными недостатки, которые вызывают у пользователя раздражение или заставляют его терять время. 1 0 6 Часть I: Основы Такой взгляд на вещи свойствен многим программистам. Но на деле имен но такие субъективные характеристики влияют на впечатление пользовате ля о программе. А во сколько, по-вашему, обойдется раздражение пользователей, выраженное в появившихся в прессе обзорах? Можно ска зать только одно — у каждой конкретной компании могут быть свои кри терии важности ошибок. В дальнейшей судьбе выявленных тестировщиком ошибок существует одна четкая тенденция: самые незначительные из них часто не исправля ются. Но так быть не должно. Хотя грамматические ошибки и не влияют на функционирование программы, они подрывают доверие пользователя к программному продукту. Учтите, что пользователь видит такие ошибки. Нам приходилось сталкиваться с продавцами, которые критиковали хоро шие и надежные продукты, демонстрируя их самые незначительные недо статки. Поэтому, если в программе множество мелких и незначительных ошибок, составьте о них единый отчет, привлекающий внимание разработ чиков к их количеству, а в графе описания проблемы Степень важности напишите Серьезная. Приложения К отчету о найденной ошибке можно приложить дискету с тестовыми данными или программу, эмулирующую действия пользователя, при кото рых проявляется данная ошибка. Можно приложить распечатки, копии экрана или собственные дополнительные пояснения. Проще говоря, все, что поможет программисту разобраться в ситуации и понять вашу точку зрения, следует передать ему вместе с отчетом и перечислить в графе Приложения, чтобы эти материалы случайно не затерялись. Проблема В этой графе суть проблемы формулируется очень коротко — в одной- двух строчках. Но при этом описание должно быть и достаточно информа тивным, чтобы прочитавший его сотрудник смог сразу составить себе четкое представление о проблеме. Именно по нему он будет искать нуж ный отчет, если захочет возвратиться к нему повторно. Кроме того, следует иметь в виду, что в сводных перечнях ошибок, как правило, будут присут ствовать всего несколько полей: Номер отчета, Степень важности, возмож но Тип отчета и Проблема. Если по этому короткому описанию проблема покажется менее серьез ной, чем есть на самом деле, существует риск, что руководитель проигно рирует отчет. Но и слишком сгущать краски тоже нельзя, иначе вы прослывете паникером. Глава 5: Документирование и анализ ошибок 107 Даже если две проблемы очень похожи, в отчетах их краткие описания ни в коем случае не должны совпадать. В графе Проблема не следует рассказывать, как воспроизвести ошибку. Примером хорошего описания может быть такая строчка: "Сбой програм мы при попытке сохранения файла под недопустимым именем". Можете ли вы воспроизвести проблемную ситуацию? Ответом может быть |