В мире разработки программного обеспечения Джем Канер должен получить высшее признание за его вклад в тестирование программного обеспечения (я опишу вклад Канера в другом посте). В своей первой книге Тестирование компьютерного программного обеспечения Канер объясняет, как тестировать программу [1]. Как ни странно, это единственное описание того, как кто-то на самом деле тестирует программное обеспечение [2]. Нелегко поставить себя на карту, чтобы объяснить, как вы думаете, и нести ответственность за свой мыслительный процесс. Я создал сокращенную версию описания Канера в этом посте. Обратите внимание, что в некоторых случаях я сокращал предложения, но в большинстве случаев я скопировал его точный текст. Чтобы по-настоящему оценить его работу, я настоятельно рекомендую прочитать его книгу.
Если вы тестировщик, это дает отличное представление о значении тестирования. Если вы блогер, автор или руководитель, вам стоит попробовать написать аналогичный отчет о том, как вы тестируете программное обеспечение.
Обратите внимание, что первое издание этой книги было написано в 1988 году. С тех пор идеи Канера о тестировании претерпели эволюцию. Однако это описание тестирования не изменилось и, скорее всего, не изменится в будущем. Для всех тестировщиков и разработчиков возможность такого тестирования является важной первой целью.
Первый цикл тестирования
Вам предоставили программу и следующее ее описание:
Программа предназначена для сложения двух чисел, которые вы вводите. Каждый номер должен состоять из одной или двух цифр. Программа отобразит ваши записи, а затем распечатает сумму. Нажимайте ‹Enter› после каждого числа. Чтобы запустить программу, введите ADDER.
Шаг 1. Начните с очевидного и простого теста
Ознакомьтесь с программой. Достаточно ли он стабилен, чтобы его можно было протестировать?
Добавить 2 + 3
Отчеты о проблемах с первого теста
Программа вернула 5, но….
1. Ошибка дизайна: Ничего не показывает, что это за программа.
…
4. Ошибка кодирования: сумма (5) не совпадает с другими отображаемыми числами.
Шаг 2. Сделайте заметки о том, что еще нужно проверить
Сделайте заметки о том, что еще нужно проверить. Группы тестов, называемые сериями тестов, например, действительные входные данные будут повторно использоваться каждый раз, когда появляется новая версия программного обеспечения.
Допустимые значения: 99 + 99, -99 + -99.
Используйте граничные условия. 99 и 100 являются граничными случаями для двузначных чисел.
Не повторяйте тесты в том же классе. 2 + 3 и 3 + 4 можно считать одним классом.
Нет волшебных формул для граничных условий или тестовых классов.
Ваша задача - проанализировать программу с другой точки зрения, нежели точка зрения программиста. Это поможет вам найти классы, граничные условия, критические тесты и, следовательно, ошибки, которые она пропустила.
Убедитесь, что вы протестировали все стороны границы.
Шаг 3. Проверьте допустимые случаи и посмотрите, что произойдет.
Создайте еще несколько серий - 1. недопустимые значения 2. числа, которые вы вводите, а затем редактируете
Шаг 4. Проведите тестирование "на лету"
Когда у вас закончатся официально запланированные тесты, продолжайте тестирование. Запускайте новые тесты, думая о них…. Доверяй своим инстинктам. Попробуйте любой тест, который покажется многообещающим, даже если он похож на другие, которые уже проводились.
Эта программа быстро вылетела. На этом этапе вместо того, чтобы тратить время на тесты, которые могут устареть с новой версией, попробуйте несколько исследовательских тестов. например, 100 + 100, ‹Enter› + ‹Enter›, 123456 + 0
Сдавайте отчеты о проблемах и, возможно, напишите о них краткую записку.
Шаг 5. Кратко опишите, что вы знаете о программе и ее проблемах.
Напишите список пунктов, в которых резюмируйте свои мысли о программе.
- Коммуникационный стиль программы предельно лаконичен.
- Программа не работает с отрицательными числами. ….
- ……………….
Возможно, причина ошибок в том, что программист пытается сделать программу действительно быстрой или очень маленькой. Вы можете узнать это, только поговорив с программистом.
На этом этапе Канер проводит отличный анализ того, как хранение суммы и хранение входных данных могут привести к ошибкам.
Второй цикл тестирования
Шаг 1. Перед проведением любого тестирования внимательно просмотрите ответы на отчеты о проблемах, чтобы увидеть, что нужно сделать, а что нет.
1. Проблема с дизайном: нет названия программы на экране.
Решение: не будет исправлено
…..
4. Ошибка: сумма (5) не совпадает с другими отображаемыми числами.
Разрешение: фиксированное
Программисты не добавили обработку ошибок и числа от -10 до -99 не обрабатываются. Вы модифицируете тесты, чтобы использовать однозначные отрицательные числа.
Пока программисты заняты, вы можете протестировать остальную часть программы. Измените свои тесты для работы с программой в ее текущем состоянии. Не ждите, чтобы проверить свои «лучшие тесты».
Шаг 2. Просмотрите комментарии о проблемах, которые не решаются. Они могут предложить дальнейшие тесты
7. Ошибка. Вылетает при вводе не цифр.
Решение Не проблема. Комментарий: «Не делай этого».
Хороший способ найти наихудшие (лучшие) примеры неправильного поведения ошибки - это свести ее к простейшим и самым важным элементам.
Что, если программа выйдет из строя с персонажами, которые люди ожидали бы работать? Попробуйте провести мозговой штурм по таким случаям. например, знак плюса, конечные пробелы, клавиша удаления, возврат. Во время мозгового штурма не ограничивайтесь тем, что имеет смысл. Создайте список, в котором ничего не пропустите.
Шаг 3. Вытащите свои записи из прошлого раза, добавьте к ним новые и начните тестирование.
Заманчиво начать с новых сложных, блестящих тестовых примеров, о которых вы только что подумали. Не надо. Начните с тех друдж-тестов, которые подтверждают, что программа все еще может складывать 2 и 2, но не получить 5.… Сначала проверьте основы.
Попробуй все из формальной серии ... Все работает.
Вы заметили, что программа говорит Нажмите Ctrl-C для выхода после каждого добавления. Поскольку программист сказал, что скорость программы является проблемой, проблема - это ошибка.
10. Ошибка дизайна: написание «Нажмите Ctrl-C для выхода» на экране после каждого результата тратит много машинного времени ……
Вы проверяете однобайтовые суммы. Все работает. 'Ну что ж'.
Не переставай думать. Некоторые из ваших тестов обнаруживают проблемы, и чем больше вы уделяете внимания хитрости, тем больше вы их обнаружите.
Вы проверяете недопустимые символы, те, которые имеют значение, и все они приводят к сбою программы. Отправьте отчет о проблеме.
Что будет в последующих циклах тестирования
По мере развития вы будете создавать более формальные серии тестов и будете следовать им каждый раз, когда программа возвращается к вам. После того, как несколько версий программы последовательно пройдут все тесты в серии, вы, вероятно, будете использовать только несколько из этих тестов в последующих циклах. На всякий случай попробуйте повторно выполнить каждый тест в том, что, по вашему мнению, является последним циклом. Перед этим зачем запускать тесты, которые программа может пройти?
По мере того, как программа приближается к завершению, вы будете использовать более строгие тесты. Вы бы предпочли сначала провести самые сложные тесты, но о многих из них не вспомните, пока не протестируете программу какое-то время и не узнаете ее причуд.
Помимо использования тестов для выявления новых ошибок, вы будете искать способы возобновить рассмотрение проблем, которые, как вам сказали, не будут устранены, но которые вы считаете важными. Вы не выиграете каждую битву, и это не должно быть вашей целью. Попытки исправить программу могут принести гораздо больше вреда, чем пользы. Ближе к дате релиза некоторые проблемы лучше оставить в покое. Ваша цель - убедиться, что серьезность проблемы ясно понимается всеми, кто имеет право голоса в том, как ее следует решать.
Как уже упоминалось, описание в книге Канера намного более детально. В целом книга - отличный инструмент для изучения тестирования.
Примечания
- Канер Джем, Фальк Джек, Нгуен Хунг Куок, «Тестирование компьютерного программного обеспечения», второе издание, 1993 г., глава 1, «Пример серии тестов».
- Есть две книги, написанные разработчиками, которые хорошо объясняют их взгляды, особенно в отношении того, что может пойти не так: Ежедневное создание сценариев с Ruby Брайана Марика и Экстремальные приключения программирования на C # Рона Джеффриса. В сообществе Ruby есть несколько хороших книг о различных компромиссах при разработке кода, например, книги Расс Олсен или Сэнди Мец.
