Выбор стратегии тестирования

Сначала принимается принципиальное решение, какие методологии тестирования будут использоваться: регрессионное или стохастическое; «черного ящика» или «белого ящика»; восходящее или нисходящее. Выбор конкретной методологии тестирования влечет за собой некоторые особенности в применении правил тестирования программных продуктов. Например, в компании решением руководства компании принята следующая стратегия тестирования для всех проектов: регрессионное тестирование для программного продукта в целом (полное прохождение тестпланов), программные объекты – строго «черные ящики», нисходящее тестирование для многомодульных программных продуктов. Соответственно, все дальнейшие шаги по тестированию должны определяться данным решением.

Стратегия тестирования программных продуктов основывается на применении определенных правил тестирования, которые (правила) охватывают все без исключения стороны работы программного продукта в заданной среде. Далее в данном документе собрано большинство из всех когда-либо использовавшихся наиболее эффективных правил тестирования. Каждая группа тестов направлена на «отлов» определенной группы ошибок. Все эти правила тестирования апробированы практикой во многих компаниях и хорошо себя зарекомендовали. Применение всех нижеуказанных правил тестирования к программному продукту – залог выявления 100% ошибок в данном программном продукте. Каждый тестер должен помнить это и стараться, как можно полнее применять нижеуказанные правила тестирования.

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

Если программный продукт создается по заказу конкретного клиента, тогда клиент может принимать в его проектировании самое непосредствен­ное участие. Он предоставляет подробную спецификацию с описанием своих требований и собственного видения продукта, а разработчик соглашается все это реализовать. В таком случае качество будет означать точное соответствие спецификации клиента. У большинства разработчиков программного обеспечения таких грамотные и обстоятельных клиентов нет. Для них критерием качества служит не соответствие спецификации, и то, насколько пользователи удовлетворены программным продуктом и сопутствующими услугами компании.

Дизайн - дизайном, но если конечный результат пользо­вателю не правится, значит, его качество не на высоте. И не важно, что пользователь ознакомился со спецификацией и согласился с ней или даже сам ее составил, Если, в конечном счете, продукт его не удовлетворяет, то только это и будет иметь для него значение.

Еще одной составляющей качества является надежность программного продукта. А надежность его тем выше, чем реже в нем происходят сбои, особенно такие, которые влекут за собой потерю данных и другие непри­ятные последствия,

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

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

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

Главное, что тестировщик может сделать для улучшения качества про­граммы, — это выявить ее недостатки, сбои в се работе и явные ошибки. Если руководитель проекта примет решение в последний момент добавить какую-нибудь очень важную функцию, это тоже может способствовать повышению качества, даже, несмотря на то, что от этого программа станет менее надежной. Ни надежность, ни функциональность не могут быть абсолютными, и ее качество, в конечном счете, означает разум­ный баланс между этими двумя характеристиками. Оставшаяся часть этой главы посвящена недостаткам и ошибкам про­грамм. Как их выявить и как определить степень их серьезности? Что такое программная ошибка? Одним из распространенных определений программной ошибки явля­ется расхождение между программой и ее спецификацией. Не пользуйтесь этим определением. Расхождение между программой и ее спецификацией является ошибкой тогда, и только тогда, когда спецификация существует и она правильна. Программа, которая соответствует плохой спецификации, и сама никуда не годится. Поэтому следующие два определения более точны,

• Если программа не делает того, чего пользователь от нее вполне обоснованно ожидает, значит, налицо программная ошибка.

• Не существует ни абсолютного определения ошибок, ни точного критерия наличия их в программе. Можно лишь сказать, насколько программа не справляется со своей задачей, — это исключительно субъективная характеристика.

Конечно, второе определение не касается таких явных ошибок, как ошибки вычислений по точно известным формулам. Бывает довольно сложно убедить программиста, что недостаток пользовательского интерфейса является ошибкой или что эта ошибка очень серьезна или даже в том, что тестировщик вообще имеет право заниматься такими воп­росами, Но пользователи жалуются на подобные ошибки не меньше, чем на очевидные сбои.

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

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

С программой может быть трудно (или даже невозможно) работать по множеству причин, связанных с пользовательским интерфейсом (графическим, командной строкой или другими видами, например, голосовой). Эти ошибки объединяются под названием "ошибки пользо­вательского интерфейса".

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

Функциональные недостатки имеют место, если программа не делает того, чего должна, выполняет одну из своих функций плохо или не полно­стью, Хотя функции программы подробно описываются в ее спецификации, окончательное представление о том, что программа долж­на делать, существует только в умах ее пользователей. Функциональные недостатки есть, абсолютно у всех программ, поскольку ожидания пользователей — вещь субъективная: у разных пользователей они различны. Оправдать их все просто невозможно, а попытка этого добиться может привести лишь к усложнению и потере концептуальной целостности программного продукта. Однако во многих случаях функциональный недостаток вполне очевиден — проблема налицо. И когда ожидания пользователей вполне разумны и обоснованны, эту проблему без колебаний можно на­звать ошибкой.

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

Насколько сложно пользователю разобраться в том, как работать с программой? Откуда вообще он об этом узнает? Как обстоит дело с экран­ными инструкциями и подсказками'' Достаточно ли их? Поняты ли они? Имеется ли в программе интерактивная справка и может ли пользователь в случае затруднений найти в ней реальную помощь. Насколько коррект­но программа сообщает пользователю о его ошибках и объясняет. Как их исправить? Нет ли в программе элементов, которые могут раздражать пользователя, сбивать его с юлку или просто выглядеть неуклюже

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

Насколько легко потеряться в вашей программе? Нет ли в ней непонят­ных команд или таких, которые легко спутать между собой? Какие ошибки чаще всего делает пользователь, на что он тратит больше всего времени почему?

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

Чего в программе не хватает? Не заставляет ли программа выполнять некоторые действия странным, неестественным или крайне неэффектив­ным способом? Нельзя ли привести ее в соответствие с привычным стилем работы пользователя? Допускает ли она хотя бы некоторую степень на­стройки?

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

В интерактивном программном обеспечении очень важна скорость. Плохо, если v пользователя создается впечатление, что программа работа­ет медленно, если он чувствует задержки в ее реакции (особенно если конкурирующие программы работают ощутимо быстрее).

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

Большинство программ, так или иначе, формируют выходные данные: отображают информацию на экране, печатают ее или сохраняют в файлах. Получаете ли вы то, что хотите? Правильно ли формируются отчеты, на­глядны ли диаграммы и достаточно ли отчетливо они выглядят на бумаге? Сохраняются ли данные в формате, доступном и для других аналогичных программ? Обладает ли программа достаточной гибкостью, чтобы можно было подстраивать ее под нужды конкретного пользователя?

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

Процедуры обработки ошибок — это очень важная часть программы. Но, к сожалению, в них тоже очень часто встречаются ошибки. Кроме того, как правильно определить ошибку, программа не всегда выдает о ней достаточно информативное сообщение.

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

Простейшими граничными условиями являются числовые (такие, как в примере из первой главы). Но существует и много других граничных ситуаций. Любой аспект работы программы, к которому применимы понятия больше или меньше, раньше или позже, первый или последний, короче или длиннее, обязательно должен быть проверен на границах диапазона. Внутри диапазонов программа обычно работает прекрасно, а вот на их границах порой случаются самые неожиданные отклонения.

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

Программирование даже самых простых арифметических операций всегда чревато ошибками. Нечего и говорить о сложных формулах и расче­тах. Ошибки округления являются самыми распространенными. После нескольких промежуточных вычисле­ний может оказаться, что 2 + 2 = -1, даже если на промежуточных этапах не было логических ошибок. К этой категории относятся и ошибки, вызванные неправильным выбо­ром алгоритма. Сюда можно отнести неправильные формулы, формулы, неприменимые к обрабатываемым данным, неверные способы разбиения сложных выражений на более простые элементы.

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

Бывает, что при выполнении какой-либо функции программы сбой происходит только однажды — при самом первом обращении к этой фун­кции. На экране может появиться искаженное изображение или странная информация. Возможно, неверно выполнятся расчеты, запустятся беско­нечные циклы или операционная система выдаст сообщение о нехватке памяти, Причиной такого поведения программы может быть отсутствие файла с инициализационной информацией. После первого же запуски про­грамма считывает такой файл, и дальше все будет в порядке. Такую ошибку невозможно повторить (точнее, для ее повторения нужно установить новую копию программы). Но не стоит думать, что ошибка, проявляющаяся только при первом запуске программы, безвредна, ведь это будет первое, с чем столкнется каждый новый пользователь.

Иногда, программируя процесс, связанный с последовательными пре­образованиями информации, разработчики забывают о том, что пользова­тель может вернуться к исходным данным и изменить их. Насколько корректно поведет себя программа в такой ситуации? Позволит ли она внести нужные изменения и не будет ли из-за этого потеряна вся выполненная работа? Что увидит пользователь при возвра­щении к исходному состоянию программы, свои данные или стандартные значении, которыми программа инициализирует переменные при запуске?

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

Если по логике программы вслед за первым действием должно быть выполнено второе, а она выполняет третье, значит, в управлении потоком допущена ошибка. Такие ошибки трудно пропустить: В худшем случае в работе программы произойдет сбой, а при менее серьезной ошибке она просто "забредет не туда",

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

Один модуль может передавать данные другому или даже. Другой про­грамме, Некоторые данные могут передаваться между модулями множество раз, и на каком-то этапе они могут быть разрушены или неверно интерпретированы. Изменения, внесенные одной из частей программы, могут по­теряться или достичь не всех частей системы, где они важны.

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

Классическая ситуация гонок описывается так. Предположим, в систе­ме ожидаются два события, А и Б. Первым может произойти любое из них. Но если первым произойдет событие А, выполнение программы продол­жится, а если первым наступит событие Б, то в работе программы произой­дет сбой. Программист полагал, что первым всегда должно быть событие А, и не ожидал, что В может, выиграв гонки.

Тестировать ситуации гонок довольно сложно. Наиболее типичны они для систем, где параллельно выполняются взаимодействующие процессы и потоки, а также для многопользовательских систем реального времени. Ошибки в таких системах трудно воспроизвести, и на их выявление обычно требуется очень много времени.

Перегрузки

Программа может не справляться с повышенными нагрузками. Напри­мер. Она может не выдерживать интенсивной и длительной эксплуатации или не справляться со слишком большими объемами данных. Кроме того, сбои могут происходить из-за нехватки памяти или отсутствия других не­обходимых ресурсов. У каждой программы свои пределы. Вопрос в том, соответствуют ли реальные возможности и требования программы к ресур­сам ее спецификации, и как программа себя поведет при перегрузках.

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

Программы могут посылать устройствам неверные данные, игнориро­вать их сообщения об ошибках, пытаться использовать устройства, которые заняты или вообще отсутствуют. Даже если нужное устройство просто сло­мано, программа должна понять это, а не сбоить при попытке к нему обратиться,

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

Бывает, что старые ошибки вдруг всплывают снова из-за того, что про­грамма скомпонована с устаревшей версией одной из подпрограмм. Поэто­му версии всех составляющих проекта обязательно должны централизованно контролироваться. Кроме того, следует убедиться, что правильны все появляющиеся на экране сообщения об авторских правах, названии и номере версии программного продукта.

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

Сама по себе документация не является программным обеспечением, но все же это часть продукта. И если она плохо написана, пользователь может подумать, что и сама программа не намного лучше.

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

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

Под ошибкой в технологическим процессе тестирования понимается неправильность, погрешность или искажение объекта или процесса. Это искажение определяется по сравнению с известным правильным (неискаженным) состоянием, описанном в дизайне, тестплане, вспомогательных документах, стандартах Windows и Unix, стандартах сред программирования, стандартах компаний, требованиях заказчика и т. п. В отдельных сложных случаях тестирования продукта, когда правильное (неискаженное) состояние объекта (или процесса) принципиально неизвестно, необходимо внести соответствующие поправки в дизайн и тестплан, либо создать дополнительный документ, разъясняющий эту проблему и указывающий на пути ее преодоления. В любом случае, при тестировании необходимо активно решать возникающие проблемы и акцентировать внимание на неясностях и неопределенностях в выявлении баг. Главная задача тестера при выявлении баг заключается в том, чтобы обратить внимание девелоперов, дизайнера и проджект менеджера на проблему.