Канер С. Тестирование программного обеспечения

Подождите немного. Документ загружается.

84 Часть I: Основы

20 часов работы бета-тестировщика для компании-

разработчика вовсе не бесплатны. Вам или другому сотруднику

компании приходится тратить на каждого из них от 4 до 8

часов, вербуя новых людей, давая им консультации и отвечая на

их вопросы. Кроме того, нужно писать для них инструкции и

разрабатывать вопросники.

Однако в определенных ситуациях бета-тестировщики работают с про-

дуктом гораздо более основательно. Вот какими могут быть их мотивации.

• Пользователю очень нужен ваш продукт, даже если он и не надежен,

а других подобных продуктов на рынке нет.

• Вы достаточно платите. Обычно в качестве платы за бета-тестиро-

вание пользователь получает или бесплатную копию продукта, или

значительную скидку. Если продукт дорогой, этого достаточно. Но

если речь идет о программе, предназначенной для доступа к важной

информации, и в этой программе происходит сбой, потеря данных

может обойтись пользователю гораздо дороже стоимости программ-

ного продукта.

• Вы даете пользователю выгодную гарантию. Например, вы обещае-

те, что в случае сбоя программы сотрудник вашей компании бес-

платно введет потерянные данные.

Здесь мы привели лишь краткий обзор процедуры бета-тестирования, а

подробное ее описание вы найдете в главе 13.

Тестирование целостности готового продукта

и тестирование распространяемых копий

С завершением тестирования последней бета-версии готового программ-

ного продукта возможные проблемы не заканчиваются. Ведь нужно еще

убедиться, что он в целости и сохранности попадет к клиенту. Нередко и

на этом этапе случаются всевозможные неприятности: например, компании

отсылают пользователям пустые или инфицированные диски.

Для тестирования распространяемых копий вы собираете все, что будет

отправлено пользователю или производителю, проверяете, все ли на мес-

те и в порядке, и делаете архивные копии. Только после этого продукт

отправляется по назначению.

Комплект дисков проверить проще всего: нужно просто выполнить их

двоичное сравнение с последней версией продукта. Не пренебрегайте этой

процедурой, даже если для создания дисков вы пользовались уже проверен-

Глава 3: Типы тестов ... 85

ной копией. Такое сравнение обойдется вам гораздо дешевле, чем отправ-

ка пользователям новой партии, если что-то будет не так.

Мы настоятельно рекомендуем включить в эту процедуру тестирования

еще и проверку на вирусы. Если программное обеспечение поставляется в

сжатом виде, не останавливайтесь на тестировании сжатых файлов: устано-

вите программу, запустите ее, перезапустите компьютер и убедитесь, что он

не заражен. Имейте в виду, что за заражение вирусами пользователь может

подать на вас в суд.

Тестирование целостности программного продукта — работа более об-

стоятельная. Это ваш последний шанс что-либо изменить перед тем, как

выпустить свое детище в жизнь. Тестировщик старается спрогнозировать

все жалобы и критические замечания, которые могут появиться в прессе и

поступить от пользователей в ближайшие несколько месяцев. Этим может

заниматься ведущий специалист, который не участвовал в данной разработ-

ке, или даже сотрудник независимого агентства. В его задачи не входит

поиск ошибок. Напротив, он предполагает, что и системное и функцио-

нальное тестирование проведены самым тщательным образом. Специалист

внимательно сравнивает программу с пользовательской документацией и

документами, в которых описаны требования к продукту. Кроме того, он

может выполнить сравнение с конкурирующими продуктами.

В рамках тестирования целостности продукта выполняется и анализ

маркетинговых материалов — ведь возможности программы обязательно

должны соответствовать рекламе. Потому и рекламная копия, и все печат-

ные и электронные рекламные материалы перед публикацией должны

подвергнуться самой строгой проверке.

Тестирование целостности программного продукта лучше поручить не

команде, а одному человеку. Для однопользовательской программы сред-

ней сложности на это уйдет около двух недель.

Окончательная приемка и сертификация

Если ваша компания разрабатывает программное обеспечение по кон-

тракту, для его приемки клиенты должны будут провести собственные

тесты. Если продукт невелик, тестирование может быть неформальным.

Однако для большинства проектов процедура приемочного тестирования

заранее согласовывается и фиксируется в контрактных документах. Поэто-

му, прежде чем передать программу клиенту, нужно убедиться, что она

абсолютно безупречно проходит серию приемочных тестов. Обычно при-

емочное тестирование занимает не более одного дня и не является особен-

но тщательным. Как подготовить и провести формальное приемочное

тестирование, подробно рассказывает Бейзер (Beizer, 1984). Хорошим учеб-

ником по разработке приемочных тестов является книга Перри (Perry,

1986). Особенно полезной эта книга может быть для тех, кто разрабатывает

приемочные тесты совместно со своим клиентом.

86 Часть I: Основы

Сертификация всегда выполняется сторонней фирмой — независимой

или работающей на вашего клиента. Сертификационное тестирование

может быть как коротким и поверхностным, так и более тщательным. По

контракту оно может выполняться вместо приемочного тестирования. При

этом уровень сертификационного тестирования и стандарты, которым дол-

жны соответствовать программа и процесс ее разработки обязательно дол-

жны быть записаны в контракте. Если же сертификация проводится по

желанию компании-разработчика, например, из маркетинговых соображе-

ний, тогда она сама и определяет, какие провести тесты.

Примеры тестов, проводимых при функциональном и

системном тестировании

Чтобы более наглядно пояснить суть описанного в предыдущих разде-

лах функционального и системного тестирования, приведем примеры тес-

тов, выполняемых на этом этапе.

Сверка со спецификацией

Проверяется соответствие разработанной программы каждому слову в

спецификации.

Правильность

Правильно ли программа выполняет нужные вычисления и формирует

отчеты?

Лабораторные испытания

Специалист по тестированию нанимает нескольких человек из числа

будущих пользователей и наблюдает за их работой с продуктом. Фактичес-

ки бета-тестирование является попыткой получить тот же результат с мень-

шими затратами. Но поскольку вы не являетесь непосредственным

свидетелем того, что происходит, и не можете давать тестировщикам зада-

ния, бета-тестирование гораздо менее эффективно, чем лабораторные ис-

пытания.

Граничные условия

Проверьте реакцию программы на граничные значения входных дан-

ных. Введите данные, в ответ на которые она сформирует максимальные

или минимальные выходные значения.

Производительность

Обзаведитесь хорошим секундомером и измерьте время выполнения

программой различных задач, особенно тех, которые пользователь будет

выполнять чаще всего.

Глава 3: Типы тестов ... 87

Переходы между режимами

Правильно ли программа переходит из состояния в состояние? Это

особенно важно для приложений, позволяющих параллельно выполнять

несколько различных действий или переключаться между режимами, не

завершая их работу. Что, если попытаться распечатать редактируемую таб-

лицу или сформировать по ней отчет? Что, если во время подготовки от-

чета ввести в таблицу новые данные?

Эксплуатация в реальном режиме

Попробуйте поработать с программой в том же режиме, в каком с ней

будут работать реальные пользователи. Выполните с ее помощью реальную

работу. Вы будете очень удивлены, увидев, сколько ошибок выявляет та-

кое тестирование. Недостатки, которых при формальном тестировании вы

не заметили вовсе или посчитали их незначительными, в реальной работе

могут оказаться очень серьезными.

Нагрузочные испытания

При нагрузочных испытаниях (load testing) проверяется реакция програм-

мы на предельные условия эксплуатации.

•

Тестирование на максимальный объем входных данных. Какое макси-

мальное задание окажется вашей программе по плечу? Компилято-

ру можно предложить откомпилировать очень большую программу,

текстовому процессору — открыть огромный текстовый файл. В

интерактивной программе можно попробовать непрерывно вводить

очень большой объем информации, чтобы проверить, насколько

надежен ее входной буфер. (Для того чтобы быстрее реагировать на

действия пользователя, программы часто сохраняют информацию о

нажатиях клавиш в небольшом буфере, а когда пользователь на се-

кунду приостанавливается, обрабатывают его содержимое.) Нужно

посмотреть, как поведет себя программа в ответ на нестандартные

данные, например, как компилятор или текстовый процессор посту-

пят с абсолютно пустым файлом.

• Испытания в утяжеленном режиме. Как реагирует программа на

резкое увеличение активности? Например, можно проверить, как

поведет себя текстовый процессор, если пользователь будет вводить

текст со скоростью 120 слов в минуту. Если максимально допусти-

мая активность пользователя оговорена в спецификации, нужно

проверить, действительно ли программа хорошо справляется с ука-

занной нагрузкой.

•

Анализ требований к ресурсам. Необходимо изучить требования про-

граммы к двум важным ресурсам компьютера — оперативной памяти

88 Часть I: Основы

и дисковому пространству. Если в спецификации записаны ограни-

чения на использование этих ресурсов, необходимо удостовериться,

что ни при каких условиях программа не занимает больше памяти

и дискового пространства, чем ей положено.

Многопользовательская и многозадачная

работа

Если ваш продукт представляет собой сложную многозадачную или

многопользовательскую систему, его тестирование значительно усложняет-

ся. Необходимо проверить, как он справляется с параллельным выполне-

нием нескольких задач и как координируются действия нескольких

пользователей. Типичным примером таких систем являются многопользо-

вательские системы управления базами данных, где несколько пользовате-

лей, сидящих за различными и, возможно, даже достаточно удаленными

компьютерами, могут одновременно вводить данные в одну и ту же табли-

цу. Для тестирования такой системы нужно организовать ее эксплуатацию

в реальном режиме, привлечь для работы большое количество людей и тех-

ники и, возможно, написать специальные программы, имитирующие одно-

временный ввод данных. Более подробное обсуждение этого вопроса

можно найти в книге Бейзера (Beizer, 1984).

Обработка ошибок

Программа должна корректно реагировать на неправильные, нестандар-

тные или не предусмотренные документацией действия пользователей.

Постарайтесь сделать как можно больше ошибок и своими глазами посмот-

реть на каждое описываемое в документации сообщение. Может быть, вы

столкнетесь с сообщениями об ошибках, которых в документации нет.

Проводя такое тестирование, вы соберете наибольший урожай ошибок,

поскольку этой части программы обычно уделяется меньше всего внима-

ния.

Защита

Сложно ли неавторизированному пользователю получить доступ к си-

стеме? Что для этого нужно? О тестировании защиты программного обес-

печения немного рассказывается у Бейзера (Beizer, 1990) и более подробно

— у Фернандеса (Fernandez, 1981).

Совместимость и преобразование форматов

данных

Два программных продукта называют совместимыми (compatible), если

они могут работать с одними и теми же файлами данных или если они

благополучно сосуществуют в оперативной памяти компьютера и работают,

Глава 3: Типы тестов ... 89

не мешая друг другу. Поэтому, получив задание проверить программы на

совместимость, обязательно выясните, о какой именно совместимости идет

речь.

Если две программы не могут непосредственно работать с данными друг

друга, это еще не значит, что они абсолютно несовместимы. Возможно, что

пользователи смогут воспользоваться специальными конвертерами — про-

граммами-посредниками, преобразующими данные из одного формата в

другой.

Одной из самых распространенных ситуаций, требующих конвертиро-

вания данных, является выпуск новой версии программы. В этом случае

новая программа должна уметь определить, что предложенные ей данные

сохранены в формате предыдущей версии, и самостоятельно выполнить их

преобразование. Кроме того, программы одного класса часто умеют читать

и сохранять данные в формате друг друга. Это позволяет пользователям

совершенно безболезненно переходить с одной программы на другую или

даже эксплуатировать их совместно.

Аппаратные конфигурации

Очень важно, чтобы программа успешно работала на компьютерах са-

мых разнообразных конфигураций. Даже если программа ориентирована на

конкретную модель процессора, все равно в системах, где ей придется

работать, периферийные устройства будут различны. Поэтому вам нужно

выявить те устройства, с которыми программа должна быть совместима, но

на деле не работает.

Установка и обслуживание

Вместе с программным продуктом обычно поставляется и программа

его установки. Она автоматизирует процесс интеграции продукта в систе-

му и его настройки для нужд конкретного пользователя. Работает ли эта

программа? Насколько она проста и удобна? Сколько времени в среднем

требуется на установку?

Если программу будет устанавливать не пользователь, а специалист,

например сотрудник фирмы-дилера, возникает и еще несколько вопросов,

связанных с ее обслуживанием. Например, если произойдет сбой програм-

мы, как быстро квалифицированный специалист сможет устранить его

последствия или установить заплатку?

Эффектные тесты

Есть среди тестов и такие, которые служат не для реальной работы, а

Для того, чтобы произвести впечатление на публику. Их проводят перед

зрителями (например, администрацией, пришедшей посмотреть, как идет

работа), чтобы показать, как "ужасно нестабильна" программа и как про-

фессиональны тестировщики.

90 Часть I: Основы

По-настоящему эффектный тест должен быть очень простым и приво-

дить к немедленному сбою. Как подбирать такие тесты, сказать сложнее.

Здесь приходится основываться на своем собственном профессиональном

опыте, знании слабых мест программиста, операционной системы и резуль-

татах тестирования аналогичных продуктов.

Сопровождение

Значительная часть средств, которые компания затрачивает на про-

граммный продукт, уходит уже после завершения его разработки. Вот ка-

кие данные приводят в своем учебнике Мартин и Мак-Клер (Martin &

mcClure, 1984).

На сопровождение программного обеспечения затрачивается 67% его

общей стоимости. Распределяется эта сумма так.

• 20% бюджета сопровождения тратится на исправление ошибок

• 25% уходит на адаптацию продукта к новому аппаратному обеспе-

чению и новой программной среде

• 6% тратится на исправление документации

• 4% тратится на повышение производительности

• 42% тратится на внесение изменений и усовершенствований

• 3% на другие нужды

На этапе сопровождения программного продукта в вашей работе не

будет ничего особенного — вы будете делать то же самое, что уже делали

в конце разработки во время функционального и системного тестирования.

Если у вас есть серия регрессионных тестов, которые к тому же еще и

частично автоматизированы, вам остается только повторять их после каж-

дого изменения программы. И не забывайте, что сделанные на этом этапе

изменения, как и всякие другие, чреваты побочными эффектами. Поэто-

му проявите предусмотрительность и обязательно проверьте не только

измененный фрагмент, но и всю программу в целом.

Адаптационное тестирование

Этот вид тестирования выполняется только на этапе сопровождения,

когда программа переносится с одной аппаратной или программной плат-

формы на другую. Если программа должна работать на нескольких типах

компьютеров, нужно проверить ее совместимость с каждым из них. Вот

краткое описание стратегии такого тестирования.

• Общее функционирование. Выполните серию регрессионных тестов.

Если ее у вас нет, разработайте набор тестов, выполняющих каждую

Глава 3: Типы тестов ... 91

из основных функций программы. При этом постарайтесь хотя бы

частично проверить программу как на граничных, так и на основ-

ных данных. Если какая-то из функций плохо совместима с новой

платформой, то, скорее всего, она не будет работать вообще, так что

не стоит опасаться, что возникшие проблемы останутся незамечен-

ными. Как правило, при переносе программы на другую платформу

тесты на общее функционирование она проходит вполне успешно.

Поэтому не стоит тратить на них слишком много времени.

• Клавиатура. Если у компьютера специфическая клавиатура, в рабо-

те с ней могут быть небольшие отклонения от стандарта. Поэтому

нужно обязательно нажать каждую клавишу, и к тому же в различ-

ных ситуациях. Особое внимание обратите на управляющие клави-

ши — <Shift>, <Alt> и т.п.

• Терминал. Проверьте, как программа работает с новым терминалом.

Как отображается графика? Если программа работает в текстовом

режиме, то все ли символы отображаются правильно, нет ли про-

блем с цветом, подчеркиванием или подсветкой?

• Номер версии и идентификация системы. Если номер версии про-

граммы изменился, убедитесь, что он нигде не остался старым. Если

при запуске программа идентифицирует аппаратуру или операцион-

ную систему, убедитесь, что она делает это правильно.

• Диски. Емкость и формат дисков могут сильно отличаться. Убеди-

тесь, что программа правильно работает с файлами, размер которых

кратен 2. Если новая система поддерживает размер дисков, которо-

го не поддерживала старая, попробуйте поработать с таким большим

диском.

•

Обработка ошибок операционной системой. Как действует операци-

онная система в таких ситуациях, как ошибка доступа к диску?

Позволит ли она прикладной программе самой обработать эту ситу-

ацию и выдать корректное сообщение или просто остановит про-

грамму и сообщит о системной ошибке? А как сам программный

продукт защищает пользователя от ошибок и странностей операци-

онной системы?

• Установка. При установке программного продукта инсталляционной

программе может потребоваться определить аппаратную и программ-

ную конфигурацию системы. Убедитесь, что она делает это правиль-

но. Протестируйте программу установки как можно тщательнее.

Выполните установку продукта в системах с различной конфигура-

цией, в сети и на отдельном компьютере, попробуйте установить его

поверх предыдущей версии.

92 Часть I: Основы

• Совместимость. Предположим, что на исходном компьютере ваша

программа была совместима с программой Икс. Если программа Икс

также была перенесена на новый компьютер, остались ли они совме-

стимы?

• Интерфейс. В различных графических средах (Windows, Mac,

AmigaDOS, Motif и т.п.) действуют различные соглашения о пользо-

вательском интерфейсе. Перейдя в новую среду, программа должна

выглядеть в ней достаточно естественно.

• Другие изменения. Поинтересуйтесь у программиста, какие еще из-

менения он вносил в программу для ее адаптации, и как следует их

протестируйте.

Если программный продукт впервые адаптируется к новой платформе,

не рассчитывайте на быстрый успех. Тестирование может занять у вас

четверть того времени, которое вы потратили на разработку. Перенос на

следующую платформу может пройти и быстрее, особенно если эти плат-

формы достаточно совместимы.

Глава

Программные

ошибки

Назначение этой главы

Главной задачей тестировщика является поиск и документирование оши-

бок. Найденные ошибки исправляются, решаются описанные тестировщи-

ком проблемы, и тем самым улучшается качество программного

продукта. В этой короткой главе мы определим понятия качества и

программных ошибок, а также расскажем о том, какими бывают про-

граммные ошибки и как они классифицируются. Зная своего противни-

ка, вы сможете бороться с ним более целенаправленно.

Более подробно программные ошибки описываются в приложении, где

кроме основной классификации, разделяющей все возможные ошибки на

13 категорий, рассматривается около 400 их видов.

Библиография

Хорошими пособиями для изучения вопросов качества программных про-

дуктов и классификации возможных ошибок являются книги Деминга

(Deming, 1982), Фейгенбаума (Feigenbaum, 1991), Ишикавы (Ishikawa,

1985) и Джурана (Juran, 1989).

Качество

Если программный продукт создается по заказу конкретного клиента,

тогда клиент может принимать в его проектировании самое непосредствен-

ное участие. Он предоставляет подробную спецификацию с описанием

своих требований и собственного видения продукта, а разработчик согла-

шается все это реализовать. В таком случае качество будет означать точное

соответствие спецификации клиента.

94 Часть I. Основы

У большинства разработчиков программного обеспечения

таких грамотных и обстоятельных клиентов нет.

Для них критерием качества служит не соответствие

спецификации, а то, насколько пользователи удовлетворены

программным продуктом и сопутствующими услугами

компании.

Спецификация — спецификацией, но если конечный результат пользо-

вателю не нравится, значит, его качество не на высоте. И не важно, что

пользователь ознакомился со спецификацией и согласился с ней или даже

сам ее составил. Если в конечном счете продукт его не удовлетворяет, то

только это и будет иметь для него значение.

Еще одной составляющей качества является надежность программного

продукта. А надежность его тем выше, чем реже в нем происходят сбои,

особенно такие, которые влекут за собой потерю данных и другие непри-

ятные последствия.

Хотя надежность программы исключительно важна, она не является

единственным критерием ее качества, и не правы те тестировщики, кото-

рые так думают. Если программа не позволяет пользователю выполнить

что-то, что он считает важным, пользователь не будет ею доволен. А если

пользователь недоволен, значит, качество программы нельзя назвать высо-

ким.

Итак, качество программы определяется:

• возможностями, благодаря которым она понравится пользователю;

• недостатками, которые вынуждают пользователя приобрести другую

программу.

Главное, что тестировщик может сделать для улучшения качества про-

граммы, — это выявить ее недостатки, сбои в ее работе и явные ошибки.

Если руководитель проекта примет решение в последний момент добавить

какую-нибудь очень важную функцию, это тоже может способствовать

повышению качества, даже несмотря на то, что от этого программа станет

менее надежной. Ни надежность, ни функциональность программы не

могут быть абсолютными, и ее качество в конечном счете означает разум-

ный баланс между этими двумя характеристиками. (Подробнее данный

вопрос рассматривает в своей книге Джуран (Juran, 1989).)

Оставшаяся часть этой главы посвящена недостаткам и ошибкам про-

грамм. Как их выявить и как определить степень их серьезности?

Глава 4: Программные ошибки 95

Что такое программная ошибка?

Одним из распространенных определений программной ошибки явля-

ется расхождение между программой и ее спецификацией. Не пользуйтесь

этим определением.

Расхождение между программой и ее спецификацией является

ошибкой тогда, и только тогда, когда спецификация существует

и она правильна.

Программа, которая соответствует плохой спецификации, и сама никуда

не годится. Поэтому следующие два определения более точны.

• Если программа не делает того, чего пользователь от нее вполне

обоснованно ожидает, значит, налицо программная ошибка (Майерс

(Myers, 1976, с. 6)).

• Не существует ни абсолютного определения ошибок, ни точного

критерия наличия их в программе. Можно лишь сказать, насколько

программа не справляется со своей задачей, — это исключительно

субъективная характеристика (Бейзер (Beizer, 1984, с. 12)).

Конечно, второе определение не касается таких явных ошибок, как

ошибки вычислений по точно известным формулам. Майерс вообще ис-

ключил из своего определения ошибки, связанные с человеческим факто-

ром. Очевидно, что это совершенно самостоятельная группа ошибок,

требующая специфического подхода к их анализу и устранению. Бывает

довольно сложно убедить программиста, что недостаток пользовательско-

го интерфейса является ошибкой или что эта ошибка очень серьезна или

даже в том, что тестировщик вообще имеет право заниматься такими воп-

росами. Но пользователи жалуются на подобные ошибки не меньше, чем

на очевидные сбои.

Категории программных ошибок

В этой главе описываются 13 категорий, охватывающих все возможные

ошибки в программном обеспечении. Несколько отличающуюся, но также

очень полезную классификацию предлагает в своей книге Бейзер (Beizer,

1990).

Ошибки пользовательского интерфейса

С программой может быть трудно (или даже невозможно) работать по

множеству причин. Мы объединили их все под названием "ошибки пользо-

вательского интерфейса". Вот несколько разновидностей таких ошибок.

96 Часть I: Основы

Функциональность

Функциональные недостатки имеют место, если программа не делает

того, что должна, выполняет одну из своих функций плохо или не полно-

стью. Хотя функции программы достаточно подробно описываются в ее

спецификации, окончательное представление о том, что программа долж-

на делать, существует только в умах ее пользователей.

Функциональные недостатки есть абсолютно у всех программ,

поскольку ожидания пользователей — вещь субъективная: у

разных пользователей они различны. Оправдать их все просто

невозможно, а попытка этого добиться может привести

лишь к усложнению и потере концептуальной целостности

программного продукта.

Однако во многих случаях функциональный недостаток вполне очеви-

ден. Если предусмотренную программой задачу трудно выполнить, если она

решается неуклюже или при определенных обстоятельствах вообще не

может быть решена — проблема налицо. И когда ожидания пользователей

вполне разумны и обоснованны, эту проблему без колебаний можно на-

звать ошибкой.

Взаимодействие программы с пользователем

Насколько сложно пользователю разобраться в том, как работать с

программой? Откуда вообще он об этом узнает? Как обстоит дело с экран-

ными инструкциями и подсказками? Достаточно ли их? Понятны ли они?

Имеется ли в программе интерактивная справка и может ли пользователь

в случае затруднений найти в ней реальную помощь? Насколько коррект-

но программа сообщает пользователю о его ошибках и объясняет, как их

исправить? Нет ли в программе элементов, которые могут раздражать

пользователя, сбивать его с толку или просто выглядеть неуклюже?

Организация программы

Насколько легко потеряться в вашей программе? Нет ли в ней непонят-

ных команд или таких, которые легко спутать между собой? Какие ошиб-

ки чаще всего делает пользователь, на что он тратит больше всего времени

и почему?

Пропущенные команды

Чего в программе не хватает? Не заставляет ли программа выполнять

некоторые действия странным, неестественным или крайне неэффектив-

ным способом? Нельзя ли привести ее в соответствие с привычным стилем

Глава 4: Программные ошибки 97

работы пользователя? Допускает ли она хотя бы некоторую степень на-

стройки?

Производительность

В интерактивном программном обеспечении очень важна скорость.

Плохо, если у пользователя создается впечатление, что программа работа-

ет медленно, если он чувствует задержки в ее реакции (особенно если

конкурирующие программы работают ощутимо быстрее).

Выходные данные

Большинство программ так или иначе формируют выходные данные:

отображают информацию на экране, печатают ее или сохраняют в файлах.

Получаете ли вы то, что хотите? Правильно ли формируются отчеты, на-

глядны ли диаграммы и достаточно ли отчетливо они выглядят на бумаге?

Сохраняются ли данные в формате, доступном и для других аналогичных

программ? Обладает ли программа достаточной гибкостью, чтобы можно

было подстраивать ее под нужды конкретного пользователя?

Обработка ошибок

Процедуры обработки ошибок — это очень важная часть программы.

Но, к сожалению, в них тоже очень часто встречаются ошибки. Кроме того,

правильно определив ошибку, программа не всегда выдает о ней достаточно

информативное сообщение.

Ошибки, связанные с обработкой граничных условий

Простейшими граничными условиями являются числовые (такие, как в

примере из первой главы). Но существует и много других граничных си-

туаций. Любой аспект работы программы, к которому применимы понятия

больше или меньше, раньше или позже, первый или последний, короче или

длиннее, обязательно должен быть проверен на границах диапазона. Внутри

диапазонов программа обычно работает прекрасно, а вот на их границах

порой случаются самые неожиданные отклонения.

Ошибки вычислений

Программирование даже самых простых арифметических операций

всегда чревато ошибками. Нечего и говорить о сложных формулах и расче-

тах. Одними из самых распространенных среди математических ошибок

являются ошибки округления. После нескольких промежуточных вычисле-

ний может оказаться, что 2 + 2 = -1, даже если на промежуточных этапах

не было логических ошибок.

98 Часть I: Основы

К этой категории относятся и ошибки, вызванные неправильным выбо-

ром алгоритма. Сюда можно отнести неправильные формулы, формулы,

неприменимые к обрабатываемым данным, неверные способы разбиения

сложных выражений на более простые элементы. В случае алгоритмичес-

кой ошибки код в точности выполняет то, что имел в виду программист,

— он правильно закодировал неверную идею.

Начальное и последующие состояния

Бывает, что при выполнении какой-либо функции программы сбой

происходит только однажды — при самом первом обращении к этой фун-

кции. На экране может появиться искаженное изображение или странная

информация. Возможно, неверно выполнятся расчеты, запустятся беско-

нечные циклы или операционная система выдаст сообщение о нехватке

памяти. Причиной такого поведения программы может быть отсутствие

файла с инициализационной информацией. После первого же запуска про-

грамма создаст такой файл, и дальше все будет в порядке. Получается, что

такую ошибку невозможно повторить (точнее, для ее повторения нужно

установить новую копию программы). Но не стоит думать, что ошибка,

проявляющаяся только при первом запуске программы, безвредна: ведь это

будет первое, с чем столкнется каждый новый пользователь.

Иногда, программируя процесс, связанный с последовательными пре-

образованиями информации, разработчики забывают о том, что пользова-

телю может понадобиться вернуться к исходным данным и изменить их.

Насколько корректно поведет себя программа в такой ситуации? Позволит

ли она внести нужные изменения и не будет ли из-за этого потеряна вся

выполненная пользователем работа? Что увидит пользователь при возвра-

щении к исходному состоянию программы: свои данные или стандартные

значения, которыми программа инициализирует переменные при запуске?

Ошибки управления потоком

Если по логике программы вслед за первым действием должно быть

выполнено второе, а она выполняет третье, значит, в управлении потоком

допущена ошибка. Такие ошибки трудно пропустить: в худшем случае в

работе программы произойдет сбой, а при менее серьезной ошибке она

просто "забредет не туда".

Ошибки передачи или интерпретации данных

Один модуль может передавать данные другому или даже другой про-

грамме. Некоторые данные могут передаваться между модулями множество

раз, и на каком-то этапе они могут быть разрушены или неверно интерпре-

Глава 4: Программные ошибки 99

тированы. Изменения, внесенные одной из частей программы, могут по-

теряться или достичь не всех частей системы, где они важны.

Ситуация гонок

Классическая ситуация гонок описывается так. Предположим, в систе-

ме ожидаются два события, А и Б. Первым может произойти любое из них.

Но если первым произойдет событие А, выполнение программы продол-

жится, а если первым наступит событие Б, то в работе программы произой-

дет сбой. Программист полагал, что первым всегда должно быть событие А,

и не ожидал, что Б может выиграть гонки.

Тестировать ситуации гонок довольно сложно. Наиболее типичны они

для систем, где параллельно выполняются взаимодействующие процессы и

потоки, а также для многопользовательских систем реального времени.

Ошибки в таких системах трудно воспроизвести, и на их выявление обычно

требуется очень много времени.

Перегрузки

Программа может не справляться с повышенными нагрузками. Напри-

мер, она может не выдерживать интенсивной и длительной эксплуатации

или не справляться со слишком большими объемами данных. Кроме того,

сбои могут происходить из-за нехватки памяти или отсутствия других не-

обходимых ресурсов. У каждой программы свои пределы. Вопрос в том,

соответствуют ли реальные возможности и требования программы к ресур-

сам ее спецификации и как программа себя поведет при перегрузках.

Аппаратное обеспечение

Программы могут посылать устройствам неверные данные, игнориро-

вать их сообщения об ошибках, пытаться использовать устройства, которые

заняты или вообще отсутствуют. Даже если нужное устройство просто сло-

мано, программа должна понять это, а не сбоить при попытке к нему

обратиться.

Контроль версий

Бывает, что старые ошибки вдруг всплывают снова из-за того, что про-

грамма скомпонована с устаревшей версией одной из подпрограмм. Поэто-

му версии всех составляющих проекта обязательно должны

Централизованно контролироваться. Кроме того, следует убедиться, что

правильны все появляющиеся на экране сообщения об авторских правах,

100 Часть I: Основы

названии и номере версии программного продукта. Обязательной провер-

ке подлежат десятки мелких деталей.

Обычно контроль версий программы и ее исходного кода осуществля-

ется группой контроля качества (Quality Assurance). Но, на наш взгляд, это

скорее задача группы тестирования.

Документация

Сама по себе документация не является программным обеспечением, но

все же это часть программного продукта. И если она плохо написана,

пользователь может подумать, что и сама программа не намного лучше.

Хотя подробное рассмотрение ошибок документации не входит в задачи

этой книги, в главе 10 мы поговорим о ее тестировании.

Ошибки тестирования

Если программист допускает по полторы ошибки на каждую строку

программного кода, то сколько их допускает тестировщик на каждый тест?

Обнаружение ошибок, допущенных тестировщиками, — дело обычное.

Конечно, если таких ошибок будет слишком много, вы быстро потеряете

доверие остальных членов команды. Но нужно иметь в виду, что иногда

ошибки тестировщика отражают проблемы пользовательского интерфейса:

если программа заставляет пользователя делать ошибки, значит, с ней что-

то не так. Конечно, многие ошибки тестирования вызваны просто невер-

ными тестовыми данными.

Глава

Документирование

и анализ ошибок

Назначение этой главы

Вероятность исправления ошибки зависит от того, как ее задокументи-

ровать. В этой главе вы научитесь составлять отчеты, позволяющие наи-

более эффективно взаимодействовать с руководителем проекта и

программистом.

Примечание

Приведенная в этой главе форма отчета наиболее функциональна на бу-

маге. В тех компаниях, где принимаются рукописные отчеты, они затем

вводятся в базу данных, и дальнейший процесс их обработки и анализа

автоматизирован.

Отчеты об ошибках и проблемах не всегда составляются тестировщика-

ми. Иногда такие отчеты поступают от сотрудников группы технической

поддержки, группы документирования, а также продавцов, бета-тести-

ровщиков и пользователей. Поэтому в данной главе используется обоб-

щенное понятие составитель отчета.

Обзор

В этой и следующей главах описывается эффективная и проверенная вре-

менем система документирования и дальнейшего отслеживания проблем

и ошибок, выявляемых группой тестирования программного обеспечения.

В данной главе подробно рассказывается о каждом поле составляемо-

го в рамках этой системы отчета о проблеме. Следующая глава посвя-

щена системе в целом и тому, как ее модифицировать в соответствии

с требованиями конкретной компании. Поэтому, чтобы лучше понять

назначение и дальнейшую судьбу каждого поля отчета, можно загляды-

вать и в главу 6.

Итак, сейчас вам предстоит:

• познакомиться со структурой типичного отчета об ошибке;

освоить наиболее эффективный стиль составления отчета об ошибке;

научиться анализировать воспроизводимую ошибку;

познакомиться со стратегией поиска способа воспроизведения ошибки.

102 Часть I: Основы

Если отчет об ошибке недостаточно четкий и понятный, программист

не сможет ее исправить. Поэтому документированию ошибок необходимо

уделять самое серьезное внимание: отчет должен составляться быстро, но

при этом его тон и содержание должны максимально способствовать реше-

нию выявленной проблемы.

Целью составления отчета об ошибке является ее исправление.

Если вы хотите, чтобы найденная ошибка была быстро и надежно ис-

правлена, прежде всего сделайте следующее.

• Объясните, как воспроизвести ошибку или проблемную ситуацию.

Программисты игнорируют отчеты об ошибках, которых не могут

увидеть своими глазами.

•

Тщательно проанализируйте ошибку, чтобы описать ее предельно

кратко. Слишком пространное описание проблемы затрудняет по-

нимание ее сути. Кроме того, встретив длинный отчет, программист

подумает, что речь идет о чем-то сложном, и с большой вероятно-

стью отложит его рассмотрение.

• Составьте полный, понятный и непротиворечивый отчет. Если

отчет путает программиста или недостаточно отчетливо и ясно со-

ставлен, он едва ли послужит хорошей мотивацией для устранения

ошибки.

Отчет следует составлять немедленно

Обнаружив ошибку, следует сразу же составить о ней отчет. Хотя в нем

довольно много граф, не стоит откладывать его заполнение, написав лишь

короткие заметки. Очень важно, чтобы во время составления отчета все, о

чем вы пишете, было у вас перед глазами, особенно это касается описания

процедуры воспроизведения ошибки. Отчет ни в коем случае нельзя состав-

лять по памяти, иначе очень легко ошибиться — программист не сможет

повторить ситуацию и отложит отчет. Эта проблема довольно типична:

тестировщики жалуются, что программисты постоянно игнорируют их от-

четы, утверждая, что не могут воспроизвести ошибку. На самом же деле

причина в неаккуратности самих тестировщиков.

Столкнувшись с проблемой в работе программного обеспечения,

сразу же составьте о ней полный отчет.

Глава 5: Документирование и анализ ошибок 103

Структура отчета о проблеме

Во всех компаниях, занимающихся разработкой и тестированием про-

граммного обеспечения, форма отчета о проблеме одна и та же. Разумеет-

ся порядок и названия его полей могут несколько отличаться, но

представленная в нем информация неизменна. На рис. 5.1 показана фор-

ма отчета, которую предлагаем мы, а далее подробно описываются все ее

поля.

Программа

Если тестируемый программный продукт состоит из нескольких про-

грамм или же компания разрабатывает несколько программных продуктов

одновременно, следует обязательно указать, в какой именно программе

обнаружена ошибка.

Выпуск и версия

В отчете обязательно должно быть указано, к какой именно версии

программного кода он относится. Например, идентификатор версии может

быть таким: 1.01д. Он означает, что речь идет о пятой (д) черновой версии

выпуска программы номер 1.01.

Поскольку программа все время находится в процессе усовершенство-

вания, программист может не найти ошибку в ее текущей версии. В этом

случае он посмотрит, с какой версией работал тестировщик, и обратится к

ней, чтобы все-таки воспроизвести ошибку и гарантировать, что она ис-

правлена.

Кроме того, наличие в отчетах номеров версий тестируемых программ

позволяет избежать путаницы с уже исправленными и повторно выявлен-

ными ошибками. Если программисту попадет в руки отчет об ошибке,

которую он уже исправил, без номера версии программы будет трудно

определить, в чем дело — ведь это может быть как старый отчет, так и

новый, означающий, что ошибка исправлена плохо или не полностью.

Тип отчета

В графе Тип отчета указывается тип обнаруженной проблемы.

1. Ошибка кодирования. Программа ведет себя не так, как должна по

мнению тестировщика. Например, если программа утверждает, что

2 + 2 = 3, то это явная ошибка кодирования. Программист же в от-

вет на отчет о такой ошибке вполне может написать Соответствует

проекту.