Шаг 2. Составим заметки о том, что еще должно быть протестировано

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

Входные данные	Ожидаемый результат	Замечания
99 + 99	198	Пара наибольших чисел, которые может складывать программа.
-99 + -99	-198	В документации не сказано, что нельзя складывать отрицательные числа.
99 + -14	85	Большое первое число может повлиять на интерпретацию программой второго.
-38 + 99	61	Проверим сложение отрицательного числа с положительным.
56 + 99	155	Проверим, не влияет ли слишком большое второе число на интерпретацию первого.
9 +9	18	9 является наибольшим числом из одной цифры.
0 + 0	0	Программы часто сбоят на нулях.
0 + 23 -78 + 0	23 -78	Программа может особым образом обрабатывать 0, поэтому его нужно проверить и в виде первого, и в виде второго слагаемого.

РИСУНОК 1.4.   Тест на допустимые входные данные

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

Эти тесты охватывают все допустимые входные данные программы — пары чисел, которые ей полагается складывать правильно.

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

Количество возможных тестов (39601) вычисляется так. В допустимом диапазоне от -99 до 99 всего 199 чисел. Любое из них может стоять на первом месте и любое — на втором. Всего получается 199² = 39601 пар чисел. Заметьте, что такое количество тестов выходит даже без учета любых чуть более сложных действий пользователя, как, например, нажатия клавиши <BackSpace>. Если же допустить использование клавиш редактирования, количество возможных тестов вырастет многократно. Задача определения количества возможных тестов относится к области математики, именуемой комбинаторным анализом. Обычно задача эта не сложная — необходимые формулы можно найти в любом учебнике по теории вероятности или комбинаторике.

Если вы проверяете комбинацию 2 + 3, а затем 3 + 4, ваши тесты хотя и не в точности одинаковы, но очень близки. Оба они проверяют, как реагирует программа на пару однозначных положительных чисел. И если программа пройдет первый тест, наиболее вероятно, что она пройдет и второй. Поэтому из огромного количества возможных тестов нужно выбирать только наиболее важные.

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

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

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

Глава 1: Пример серии тестов       25

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

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

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

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

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

Шаг 3. Проверим допустимые значения и посмотрим, что происходит

Серия тестов, приведенных на рис. 1.4, охватывает только допустимые значения входных данных программы. На следующем этапе тестирования можно создать такую же серию тестов для недопустимых значений. Еще одна серия тестов может быть предназначена для проверки редактирования чисел: вы вводите значение, затем изменяете его и только после этого нажимаете <Enter>. Однако прежде всего выполните простейшие тесты, приведенные на рис. 1.4.

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

Программу тестируют потому, что она может не работать.

Можно убить уйму времени на разнообразные тесты, подсказанные вашей фантазией, а затем обнаружить, что программа не может сложить 2 и 3. Вот результаты теста нашей программы-примера.

•   Положительные числа и 0 обрабатываются прекрасно.

•   Не работает ни один тест с отрицательными числами. После ввода второй цифры компьютер просто "зависает". (Он игнорирует клавиатурный ввод, и его приходится перезапускать.) Вы попробовали сложить 9 и -9, чтобы посмотреть, не примет ли программа однозначные отрицательные числа, но после нажатия клавиши <Enter> компьютер "завис". Очевидно, программа не ожидает отрицательных чисел.

Шаг 4. Немного тестирования в режиме "свободного полета"

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

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

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

Как видно из рис. 1.5, программа никуда не годится: она "зависает" при малейшей провокации. Вы больше времени тратите на перезапуски компьютера, чем на тестирование.

Глава I: Пример серии тестов          27

Тест	Чем он интересен	Замечания
100 + 100	Граничное условие: числа больше максимального допустимого значения (99)	Программа приняла 10. Когда вы ввели второй 0, чтобы получилось 100, программа повела себя так, как будто вы нажали <Enter>. Так же было и со вторым числом 100. В результате по окончании теста на экране было следующее: ?10 ?10 20
<Enter>+<Enter>	Что происходит при отсутствии введенных данных?	Когда вы нажали <Enter>, программа напечатала 10 - последнее введенное вами число. То же было и после второго нажатия <Enter>, и в качестве суммы программа напечатала 20.
123456 + 0	Введем побольше цифр	Программа приняла первые две цифры и проигнорировала остальные - так же, как было с числом 100. В будущей версии программа будет принимать большие числа: как она должна будет тогда реагировать на подобные ситуации?
1,2 + 5 А + b	Попробуем с десятичными знаками Недопустимые символы	Реакция на десятичный разделитель такая же, как и на <Enter>. Когда вы нажали <Enter> после <А> программа "зависла". Для продолжения тестирования вам пришлось перезапустить компьютер.
<Ctrl+A>+<Ctrl+B> <Ctrl+C>+<Ctrl+D> <F1>+<Esc>	Управляющие символы и функциональные клавиши часто являются источниками проблем.	Для всех комбинаций клавиш, кроме <Ctrl+C>, программа отобразила графические символы, затем, после нажатия <Enter>, "зависла". Нажатие <Ctrl+C> привело к завершению программы и выходу в операционную систему.

РИСУНОК 1.5. Дальнейшие исследовательские тесты

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

Шаг 5. Подведем итоги тому, что мы узнали о программе и ее недостатках

Эта последняя работа — только для вас. Она не всегда необходима, но часто оказывается очень полезной.

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

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

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

Очень полезно для начала записать свои итоговые впечатления о программе. Вот они.

•    У программы очень ограниченный интерфейс.

•   Программа не работает с отрицательными числами. Наибольшая сумма, которую она может вычислить, —  198, а наименьшая — 0.

•   Третий вводимый символ (например, третью цифру в числе 100) программа интерпретирует как нажатие <Enter>.

•    Пока вы не нажмете <Enter>, любые вводимые вами символы воспринимаются как допустимые.

•   Программа не проверяет, действительно ли вы ввели число, прежде чем нажали <Enter>. Если вы ничего не ввели, программа использует последнее число, введенное ранее.

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

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

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

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

Глава 1: Пример серии тестов  29

Хранение суммы

Допустимыми могли бы быть суммы от -198 до 198. Но программа работает только с положительными числами, поэтому в ней возможны суммы от 0 до 198.

Если хранить только положительные числа, то хватит и одного байта (8 битов). Это стандартная и очень удобная единица хранения данных, вмещающая положительные числа от 0 до 255. Если программист хотел выбрать для хранения суммы наименьший возможный размер переменной и при этом не считал необходимой обработку отрицательных чисел, байт был идеальным решением.

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

Подобные сбои обычно выражаются в том, что числа, которые больше чем 127, интерпретируются как отрицательные. Скорее всего, то же будет и с нашей программой. В следующей серии тестов следует обратить внимание на большие суммы — граничными будут значения 127 и 12.8. Серия тестов на рис. 1.4 уже включает большую сумму (99 + 99), поэтому новые тесты понадобятся только в случае, если этот программа пройдет правильно. Рядом с этим примером стоит приписать замечание, чтобы отследить неверный результат.

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

Хранение входных данных

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

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

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

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

Символ ASCII-код / 47 0 48 1 49 2 50 3 51 4 52 5 53 6 54 7 55 8 56 9 57 : 58 А 65 b 98

РИСУНОК 1.6.  ASCII-коды цифр (и нескольких других символов)

IF   АSСII_КОД_ВВЕДЕННОГО_СИМВОЛА   меньше    48
(48    —  это   ASCII-код    для   0)

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

ELSE    IF    АSСII_КOД_ВВЕДЕНН0Г0_СИМВ0ЛА    больше    57
(57    —   это   ASCII-код   для   9)

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

ELSE    это    цифра,    принять    ее.

Посмотрим теперь, из-за чего этот код может сработать неправильно. Вот шесть наиболее распространенных ошибок программистов.

•   Если вместо оператора меньше программист поставит оператор меньше или равно, программа отвергнет 0 как недопустимый символ.

Чтобы найти эту ошибку, нужно проверить, как программа работает с нулем — цифрой с наименьшим кодом ASCII (48).

•   Если вместо меньше 48 программист напишет меньше 47, программа примет символ /, решив, что это цифра.

Чтобы найти эту ошибку, нужно проверить, как программа работает с символом / — символом, код которого на единицу меньше кода нуля.

Глава I: Пример серии тестов    31

•   Если программист допустит опечатку и вместо меньше 48 напишет меньше 38, программа примет не только символ /, но и девять других нецифровых символов с кодами от 38 до 47.

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

•   Теперь посмотрим на самую большую цифру — 9 (ASCII-код 57).
При работе с ней, вероятнее всего, может встретиться ошибка больше или равен 57 вместо равен 57. Если ввести 9, программа отвергнет этот символ как нецифровой.

Такой код неверно работает с одной-единственной цифрой — ее и нужно проверить.

•   Программист может захотеть записать второе условие иначе, как больше или равен 58, но по ошибке написать больше 58. Тогда программа примет за цифру двоеточие.

•   Еще одной опечаткой программиста может быть 75 вместо 57, тогда программа будет принимать за цифры все символы с кодами от 48 до 75. Эту ошибку можно обнаружить, проверив любой символ из указанного диапазона, но символа с граничным значением кода (двоеточия) будет вполне достаточно.

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

Из приведенных в таблице на рис. 1.6 символов два последних мы использовали, чтобы выяснить, как программа реагирует на нецифровые данные. Тест сработал, а программа — нет. Но как быть с шестью перечисленными типами ошибок? Одной проверкой буквы А их не выявить. А буква b вообще ничем не поможет. Так что проверять нужно граничные символы (/, 0, 9, и :), поскольку, повторюсь, самыми эффективными являются тесты именно граничных значений.

Первый цикл тестирования. Итоги

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

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

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

Второй цикл тестирования

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

1	Ошибка проектирования:	На экране нет названия программы.
	Резолюция:	Не будет исправлена.
2.	Ошибка проектирования:	На экране нет инструкций.
	Резолюция:	Не будет исправлена. Примечание: Замечание верное, но вывод инструкций замедлит работу программы.
3.	Ошибка проектирования:	Как остановить программу?
	Резолюция:	Исправлена. На экране отображается подсказка: "Для выхода нажмите <Ctrl+C>".
4.	Ошибка кодирования:	Сумма (5) выводится в стороне от слагаемых.
	Резолюция:	Исправлена.
5.	Ошибка кодирования:	Программа "зависает" на отрицательных числах.
	Резолюция:	Исправлена. Программа будет складывать и отрицательные числа.
6.	Ошибка кодирования:	Программа интерпретирует третий введенный символ как нажатие <Enter>.
	Резолюция:	В работе (еще не исправлена).
7.	Ошибка кодирования:	Сбой при вводе нечисловых данных.
	Резолюция:	Не проблема. Комментарий: "Не делайте этого".
8.	Ошибка кодирования:	Сбой при вводе управляющих символов.
	Резолюция:	Не проблема. Комментарий: "См. отчет 7".
9.	Ошибка кодирования:	Сбой при нажатии функциональных клавиш.
	Резолюция:	Не проблема. Комментарий: "См. отчет 7".

РИСУНОК 1.7.  Резолюции на отчетах первого цикла тестирования

Глава I: Пример серии тестов    33

Шаг 1. Прежде чем приступить к тестированию, внимательно прочтите резолюции программиста на ваших отчетах - вы узнаете, что нужно делать, а чего не нужно

Как видите, хорошо, что вы не разрабатывали тестов для проверки кода обработки ошибок: этого кода нет и не будет. Более того, хотя программа и будет теперь обрабатывать отрицательные числа, она будет обрабатывать их не все, а только до -9.

Числа от -10 до 199 длиной в три символа она по-прежнему не обрабатывает, интерпретируя третий символ как нажатие клавиши <Enter>. Обратившись к разработанной ранее серии тестов на рис. 1.4, вы видите, что тесты с числами -99, -78 и -14 запускать не придется. Вместо -78 и -14 возьмите пару однозначных отрицательных чисел.

Очень часто программист просит протестировать остальную часть программы, в то время как он занимается исправлением уже найденных ошибок — и это разумно. Некоторые из запланированных тестов нет смысла проводить до исправления ошибки, с другими же вполне можно поработать. Если ждать, пока можно будет провести "лучшие" из тестов, можно оставить без внимания целые области программы, на которые потом уже не хватит времени. В нашем примере можно протестировать числа между -1 и -9 — так вы хоть и не полностью, но проверите, как работает сложение отрицательных чисел, вместо того чтобы опустить эту проверку вообще.

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

Шаг 2. Проанализируйте комментарии к ошибкам, которые не будут исправлены. Возможно, следует провести дополнительное тестирование

В нашей программе хуже всего обстоит дело с обработкой ошибок. Программист не собирается исправлять ситуацию. Как же быть?

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

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

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

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

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

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

 

•	Цифры, конечно.
•	И знак "минус".
•	Если можно нажимать "минус", то можно и "плюс".
•	Пробелы. Люди вводят перед числами пробелы, чтобы аккуратно выровнять их в столбик.
•	Если можно вводить пробелы перед числом, то должно быть можно и после него.
•	А как насчет арифметических операций, таких как  * и / (4/3, например)?
•	Знак доллара?
•	Знак процента?
•	Скобки - отрицательные числа часто заключают в скобки, как, например (1000) вместо -1000.
•	Клавиша <BackSpace> - что, если вы случайно ввели не тy цифру?
•	Клавиша <Delete>.
•	Клавиша <lnsert>. Вы ввели 1 и хотите вернуться и ввести 2, чтобы получить 21.
•	Клавиши управления курсором.

РИСУНОК 1.8. Мозговой штурм. Какие клавиши пользователь захочет нажать при вводе числа?

Глава 1: Пример серии тестов         35

Некоторые из идей в нашем списке явно неудачны. Например, если сказать программисту, что программа не обрабатывает 4/3 + 2, он только посмеется. Но для первой версии списка это не имеет значения. Прежде всего, важно ничего не пропустить. А что внести в отчет, вы решите чуть позже.

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

Вам страшно хочется начать с того замечательного и очень сложного теста, который вы только что придумали, не так ли? Не торопитесь. Сначала повторите старые и нудные тесты и убедитесь, что программа по-прежнему может сложить 2 и 2 и не получить при этом 5. С вероятностью 1:2 программа не сработает или в ней возникнут новые неполадки. Поэтому обязательно протестируйте все сначала.

Вы провели все "формальные" серии тестов (см. рис. 1.4), модифицировав несколько примеров для проверки однозначных отрицательных чисел. Программа все их успешно прошла.

По ходу дела вы заметили, что программа отображает подсказку "Для выхода нажмите <Ctrl+C>" после каждой операции сложения. На рис. 1.9 показано, что было на экране после сложения первых двух пар чисел.

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

10. Ошибка проектирования. На вывод на экран подсказки "Для выхода нажмите <Ctrl+C>" тратится лишнее компьютерное время. Поскольку одной из задач разработки является создание очень быстрой программы, это ошибка. Почему бы просто не написать "Для выхода нажмите <Ctrl+C>" внизу экрана сразу при запуске программы и никогда больше ничего не выводить в этой строчке? (И если это возможно, почему бы заодно не вывести также и заголовок программы и короткие инструкции?)

Среди ваших заметок есть напоминание проверить однобайтовые суммы. Это диапазон значений от -127 до 127 или от 0 до 255. Поскольку двузначных отрицательных чисел задавать нельзя, -127 в допустимый диапазон не попадает. Однако сложение 99 и 99 дает правильный результат, значит, все в порядке.

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