Жаль, но не думаю, что эта книга стоит времени на перевод.
Прочтения - да. Поэтому только начало книги:
Секция 1: Что такое тестирование доменов?Секция состоит из 2 глав:
- Введение в тестирование доменов
- резюме ключевых технических концепций
Мы предлагаем вам прочесть введение перед чтением остальной книги. После этого вы могли бы продолжить читать:
- Следующую главу, которая представляет собой короткое обсуждение ключевых терминов и концепций этой книги.
- Секцию 2, которая детально описывает схему тестирования доменов (одна глава на задачу).
- секцию 3, которая содержит список примеров.
Главы о ключевых технических концепциях и о схеме предоставляют фоновую информацию, которая поможет понять примеры. Если вы сначала перейдете к примерам, иногда они будут сразу весьма полезны вам
в оригинале какая-то метафора со сливками.
Секция 1. Часть 1: Введение в тестирование доменовсуть тестирования доменов в том, что вы делите домен (набор значений) на поддомены (классы эквивалентности) и выбираете представителей каждого поддомена для ваших тестов.
- Сходно с анализом классов эквивалентности. Два значения принадлежат к одному классу эквивалентности, если программа обрабатывает их одинаковым образом.
Тестирование только пары представителей каждого класса позволяет вам существенно снизить количество тестов.
- выбор представителей является риском. Риск в этой книге понимается как возможность программы выдать сбой. Посмотрите на значения, которые. скорее всего, приведут программу к сбою. Такие значения чаще всего лежат на границе классов. Хороший набор представителей позволит вам сохранить набор тестов небольшим без увеличения риска пропуска багов.
Простые примеры границ вводят в заблуждение. Две границы могут быть эквивалентны в некоторых отношениях, и отличаться в других. Поэтому тестировщики должны создавать альтернативные, разные наборы классов эквивалентности. процес разбиения требует воображения, опыта и упражнений (знание продукта тоже поможет).
пример серии испытанийУже давно мы начали книгу Testing Computer Software (kaner, 1988) ч простого примера, иллюстрирующего эту технику. начнем работу с этого примера и сейчас:
Вам дали программу с таким описанием:
Программа создана для сложения двух чисел, которые вы введете. каждое число должно состоять из одной или двух цифр. программа отображает то, что вы ввели и сумму. Нажмите после каждого числа. Для запуска программы наберите ADDER.
В книге описан такой пример:
- Начните с простых тестов, раскрывающих, как программа работает с разными переменными:
2 + 3 Программа вообще работает?
99 + 99 99 действительно верхняя граница?
-9 + -99 Допустимы ли отрицательные значения?
- Дошли до проверки простых, очевидных рисков:
0+0 Программа работает с нулями?
-99 + -99 Обрабатывает ли программа двузначные числа из трех символов?
100 + 100 Как будут обработаны трехзначные числа за границей?
-100 + -100
+
Что будет, если ничего не ввести?
123456 + 0 Как много цифр она воспримет?
- Проверьте входной фильтр, гарантирующий, что программа принимает только легитимные числа. Примеры:
1.2 + 5 Разделитель точка? Если она отклонит это, как насчет 1.0 или 1.?
A + b Буквы?
/ + 1
или
1+ : ASCII соды цифр начинаются от 48(0) до 57(0). ASCII 47 это / а ASCII 58 это :
1 Попробуйте ввести произвольное количество пробелов в начале и в конце.
- Рассмотрите обработку пользовательских действий во время ввода чисел, такую как:
- Время ожидания между цифрами. Это таймаут?
- Повторное редактирование чисел после перед вводом. У вас есть возможность переполнить строку ввода, если программа хранит все, что вы вводите до нажатия (Сейчас мы должны называть эту входную строку, как буфер ввода и считаем этот тест слишком простым для переполнения буфера).
- Рассмотрите возможные значения результатирующей переменной:
- Если программа держит входные значения в виде byte, то их размерность может быть от -128 до + 12. Тесты, сумма в которых выходит за эти границы, может вызвать переполнение.
Следующий пример ставит несколько точек, с которыми, вы, вероятно, знакомы:
- Когда тестируется часть программы, которая хранит и обрабатывает данные, вы должны учитывать:
- Пользовательский интерфейс: По, которое поддерживает получение и ввод данных от пользователя и отображает результаты.
- Хранилище: как программа хранит данные?
- Вычисление и результатирующие переменные: Вычисления, которые производятся с данными и переменные, которые хранят результат вычислений.
- последствия: Как данные будут использованы и как это использование повлияет на них.
Большинство (а может и все) спецификации (или требования или пользовательские истории) двусмысленны и неполны. Для получения большего количества информации вы, вероятно, должны понять это и прибегнуть к стратегиям активного изучения:
- Задавать вопросы.
- Читать внешние материалы.
- Проводить тесты, выходящие за рамки спецификаций
В этой книге мы называем это дополнительным сбором информации, исследовательским тестированием, термином, который с тех пор завоевал некоторую популярность.
- каждая простая часть программы (например, ввод и сложение двух чисел) может быть протестирована многими путями с многими значениями:
- Не пытайтесь спроектировать и запустить все тесты сразу. Начните с простых тестов и увеличивайте сложность по мере того, как программа становится более стабильной- Не пытайтесь провести каждый тест. Посмотрите на способы организации тесты в группы, такие, что все тесты в них нет смысла запускать.
- Посмотрите на граничные значения или другие, которые, вероятно, ведут к сбою программы.
- Подумайте в терминах риска. представьте пути, которыми программа может прийти к сбою. Для каждого пути которые, возможно, сработают, если программа будет сбоить подобным образом.
В 1988 мы представили и объяснили эти идеи тестирования, но не поместили этот список в единую структуру. Мы думаем, что это распространённая проблема. Многие авторы описывают технику, но не исследуют весь ее процесс. Они останавливаются после описания того, что, на их взгляд, было самой важной частью.
