Анализ граничных значений

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

1) строятся тесты для границ области и тесты для данных, выходящих за границы области на минимальное значение;

2) для дискретных значений строятся тесты для минимального и максимального значения и тесты для данных, меньших минимального и больших максимального значения;

3) если данные – упорядоченное множество (линейный массив, таблица, файл), то следует проверить

а) пустое множество;

б) множество с минимальным количеством данных;

в) множество с максимальным количеством данных;

г) первый и последний элемент этого множества.

4) выделяются граничные условия с учетом особенностей конкретной задачи и строятся для них тесты.

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

Массивы

При построении тестов для задач с массивами необходимо проверять следующие граничные условия:

1) массив не содержит ни одного элемента;

2) массив содержит минимальное количество элементов;

3) массив содержит максимальное количество элементов;

4) хотя бы один из элементов массива имеет минимальное значение;

5) хотя бы один из элементов массива имеет максимальное значение.

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

Работа с файлами

При тестировании задач, связанных с чтением данных из файла или записи в файл проверяются следующие условия: правильность имени файла, наличие файла на диске, корректность выполнения функции чтения или записи, для входного файла - отсутствие в нем данных, для выходного - запись в файл с максимальным количеством записей (если длина файла ограничена). Проверяется работа с первой и последней записью файла. Обязательно должны тестироваться ситуации, когда файл может оказаться привязанным к определенному диску или каталогу. Как правило, в таких программах работает функция поиска, она также должна быть протестирована. Если для данных файла выполняется сортировка или отбор по заданным критериям, то проверяются те же условия, что и для массива.

Предположение об ошибке

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

Программные ошибки

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

1) программная ошибка — это расхождение между программой и ее спецификацией, причем тогда и только тогда, когда спецификация существует и она правильна;

2) программная ошибка — это ситуация, когда программа не делает того, чего пользователь от нее вполне обоснованно ожидает.

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

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

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

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

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

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

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

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

Ситуация гонок. Предположим, в системе ожидаются два события: А и Б. Если первым наступит событие А, то выполнение программы продолжится, а если событие Б, то в работе программы произойдет сбой. Разработчики предполагают, что первым всегда должно быть событие А, и не ожидают, что Б может выиграть гонки и наступить раньше. Такова классическая ситуация гонок.

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

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

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

Тестирование документации

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

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

Следует помнить, что тестировщик одинаково не имеет права требовать изменений как в руководстве к ПП, так и в самом ПП. Обязанность тестировщика — выявить проблему, а что с ней делать, решать не ему. В частности, у тестировщика нет никакого права требовать стилистических изменений текста. Он может предложить такие изменения, но технический писатель вправе оставить все как есть и не обязан доказывать тестировщику, что поступает правильно. Для взаимодействия с техническими писателями формальная система отслеживания проблем обычно не применяется. Большинство комментариев вносится прямо в копию руководства.

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