Boundary Value Testing

Вступление

Boundary Value Testing (техника анализа граничных значений) наиболее известная и простая техника тест дизайна, призванная  помогать рядовому тестировщику выбирать наиболее эффективные значения для тестирования. Эта техника применима на всех уровнях тестирования - unit, integration, system, and system-integration test levels.

Подход

Шаги использования техники анализа граничных значений:

1. Определите диапазон значений (как правило это класс эквивалентности).
2. Определите границы диапазонов.
3. На каждую границу создайте 3 тест кейса - один, проверяющий значение границы, второй на значение ниже границы и третий на значение выше границы.

"выше" и "ниже" границы значения относительные. Например, если мы говорим о границе 6$, то значение "ниже" будет 5$, а значение "выше" 7$. А если мы говорим о границе 6.00$, то значение "ниже" будет 5.99$, а значение "выше" 6.01$.

Примечание: значение "ниже" или "выше" границы может быть другим классом эквивалентности. В этом случае нет смысла создавать дубликаты тест кейсов.

Опять же, будем разбирать эту технику тест дизайна на примерах.

Equivalence Class Testing

Вступление

Equivalence Classes (Класс эквивалентности) – это входные (а иногда и выходные) данные, которые обрабатываются приложением одинаково или обработка которых приводит к одному и тому же результату.

Equivalence Class Testing (Тестирование классами эквивалентности) это техника тест дизайна способная резонно уменьшить количество ваших тест-кейсов. Использовать ее можно на всех уровнях тестирования - unit, integration, system, and system-integration test levels.

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

Подход

Использовать эту технику достаточно просто, правила такие:

1. Определите классы эквивалентности.
2. На каждый класс эквивалентности сделайте хотя бы 1 тест-кейс.

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

Использование классов эквивалентности будем рассматривать на примерах.

Пример 1. Одна сущность.



Представим, что мы тестируем модуль для HR, который определяет брать на работу кандидата или нет, базируясь на возрасте кандидата. Условия такие:

• 0–16 : Не нанимать
• 16–18 : Можем нанять только на part time
• 18–55 : Можем нанять на full time
• 55–99 : Не нанимать

Стоит ли в этом случае применять exhaustive testing, т.е. должны ли мы протестировать модуль на всех возможных входных данных, на всех возрастах: 0, 1, 2, 3, 4, 5, 6, 7, 8, ..., 97, 98, 99? Если бы имели на это ресурсы, то это был бы неплохой вариант. Либо в случае если девелопер реализовал модуль как нижепередставленный код, то пожалуй тоже бы пришлось тестировать все возраста.

        If (applicantAge == 0) hireStatus="NO";
        If (applicantAge == 1) hireStatus="NO";
        …
        If (applicantAge == 14) hireStatus="NO";
        If (applicantAge == 15) hireStatus="NO";
        If (applicantAge == 16) hireStatus="PART";
        If (applicantAge == 17) hireStatus="PART";
        If (applicantAge == 18) hireStatus="FULL";
        If (applicantAge == 19) hireStatus="FULL";
        …
        If (applicantAge == 53) hireStatus="FULL";
        If (applicantAge == 54) hireStatus="FULL";
        If (applicantAge == 55) hireStatus="NO";
        If (applicantAge == 56) hireStatus="NO";
        …
        If (applicantAge == 98) hireStatus="NO";
        If (applicantAge == 99) hireStatus="NO";

К счастью, наши родные девелоперы так код не пишут (по крайней мере как правило :)). На самом деле для этого модуля мы, как правило, увидим примерно такой код:

If (applicantAge > 0 && applicantAge <=16)
                  hireStatus="NO";
    If (applicantAge > 16 && applicantAge <=18)
                  hireStatus="PART";
    If (applicantAge > 18 && applicantAge <=55)
                  hireStatus="FULL";
    If (applicantAge > 55 && applicantAge <=99)
                  hireStatus="NO";

Поэтому явно видно, что не стоит тестировать все значения 0, 1, 2, ... 14, 15, 16. Более разумно будет протестировать диапазоны каждого условия, что собственно и есть наши классы эквивалентности.:

1. Класс эквивалентности NO: 0-16.
2. Класс эквивалентности PART: 17-18.
3. Класс эквивалентности FULL: 19-55.
4. Класс эквивалентности NO: 56-99.

Вспомним правила - после определения классов эквивалентности мы должны создать тест кейс с любым значением из диапазона класса эквивалентности. Итого у нас 4 позитивных тест кейса вместо 100. Неплохая оптимизация.

Так же не стоит забывать о не валидных диапазонах, добавим классы эквивалентности и для них:

1. (-100) – (-1). Значнеие (-100) было взято наугад, по поводу подобных границ лучше консультироваться с девелоперами.
2. 100-1000. Значнеие (1000) было взято наугад, по поводу подобных границ лучше консультироваться с девелоперами.
3. 0.1-0.9. Выбрано любое дробное значение входящее в валидный диапазон.
4. Символы.
5. Пустой ввод.
6. ...

Вот собственно и всё. Осталось на каждый класс эквивалентности создать тест-кейс.

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

Для этого лучше рассмотреть следующий пример.

Тест дизайн

Заметил, что в рунете очень мало информации по тест дизайну и решил попробовать исправить эту ситуацию :)
Подтолкнула меня на это книга Lee Copeland "A Practitioner'S Guide To Software Test Design". Так что первые техники тест дизайна я буду описывать из нее:

• Boundary Value Testing
• Equivalence Class Testing
• Decision Table Testing
• State-Transition Testing
• Pairwise Testing
• Domain Analysis Testing
• Use Case Testing

Примеры применения этих техник в большинстве случаев будут взяты из книги, ибо брать свои рабочие примеры не могу, а выдумывать лень ;)

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

Лично мне эти техники помогли под другим углом посмотреть на тестирование, считаю что более правильным, надеюсь и вам они чем то помогут.

Привет!

Всем привет!
Наконец то завел себе блог, всех кого интересует тестирование прошу в гости - надеюсь нам будет чему друг у друга поучиться.