Предположение об ошибке тестирование

Замечено,
что
некоторые
люди
по
своим
качествам
оказываются
прекрасными
специалистами
по
тестированию
программ.
Они
обладают
умением
«выискивать»
ошибки
и
без
привлечения
какой-либо
методологии
тестирования
(такой,
как
анализ
граничных
значений
или
применение
функциональных
диаграмм).

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

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

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

1. Сортируемый
список
пуст.

2. Сортируемый
список
содержит
только
одно
значение.

3. Все
записи
в
сортируемом
списке
имеют
одно
и
то
же значение.

4. Список
уже
отсортирован.

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

1) существует
только
один
вход
в
таблицу,
в
которой
ведется
поиск;

2) размер
таблицы
есть
степень
двух
(например,
16);

3) размер
таблицы
меньше
или
больше
степени
двух
(например,
15
или
17).

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

1. Допускает
ли
программа
«пробел»
в
качестве
ответа?

2. Запись
типа
2
(ответ)
появляется
в
наборе
записей
типа
3
(студент).

3. Запись
без
2 или
3 в
последней
колонке
появляется
не
как
начальная
запись
(название).

4. Два
студента
имеют
одно
и
то
же
имя
или
номер.

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

6. Поле
числа
вопросов
имеет
отрицательное
значение.

Для
команды
DISPLAY
из
предыдущего
раздела
целесообразно
рассмотреть
следующие
тесты
метода
предположения
об
ошибке:

1. DISPLAY
100

(неполный
второй
операнд).

2. DISPLAY
100.
(неполный
второй
операнд).

3. DISPLAY
100

10А42
(слишком
большое
значение
операнда).

4. DISPLAY
000

0000FF
(нули
слева).

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #

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

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

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

— Историю работы приложения в прошлом.

— Наиболее вероятные типы дефектов, допускаемых при разработке.

— Типы дефектов, которые были обнаружены в схожих приложениях.

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

Получается, что предугадывание ошибки — это когда тест аналитик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку.

Например, в программе я вижу: «для подтверждения заказа введите свой номер телефона в формате +7(…)… ….» И я, как тестировщик, начинаю думать: «А если не вводить телефон?», «А если ввести в формате не +7, а просто 8? «, и так далее. Это и есть предугадывание ошибки.

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

Уже знакомая нам игра с молокозаводом

Возьмем объекты, которые нам необходимо построить. Например, каким образом можно сломать курятник на этапе покупки?

  1. Можно попробовать поставить его на другой объект
Ставим на другой объект
Ставим на другой объект

2. Или за границу доступного поля

Ставим за границу доступного поля
Ставим за границу доступного поля

3. За границей поля тоже не получается.. А давайте попробуем поставить на воду? Вдруг разработчики не учли этот момент?

Ставим на воду
Ставим на воду

Тоже никак, все работает как надо… Ладно поставим пока курятник на место. Теперь попробуем проверить, все ли нормально с его работой.

4. В курятник можно покупать и сажать кур. А что если попробовать вместо кур поместить коров?

Размещаем корову в курятник
Размещаем корову в курятник

5. Или попробовать кур поместить на территорию вне курятника

Размещаем кур вне курятника
Размещаем кур вне курятника

6. Или попробовать зайти в магазин, пока покупаем кур

Заходим в магазин во время покупки кур
Заходим в магазин во время покупки кур

«Ладно, видимо не в этот раз» — говорим мы себе и закрываем игру…

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

А теперь посмотрим на примере сайта

Возьмем один из элементов сайта — форму регистрации. Посмотрим на нее внимательно и подумаем, как мы можем ее «сломать».

Форма регистрации на сайте
Форма регистрации на сайте

Мне на ум приходят вот какие варианты:

  1. Указать e-mail c несуществующим доменом на конце.
  2. Указать e-mail без знака «@».
  3. Заполнить поле «Пароль» без использования обязательных символов. Например, если программа требует, чтобы в пароле были заглавные и строчные буквы, то пробуем ввести пароль без использования заглавных букв.
  4. В поле «Пароль еще раз» ввести символы отличные от символов в поле «Пароль».
  5. Снять галочку «Я принимаю условия Пользовательского соглашения».
  6. Ввести неверные символы с картинки.
  7. Оставить одно поле незаполненным.

________________________________

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

________________________________

В предугадывании ошибок нет четкой и логической схемы, которая позволила бы нам составить тест-кейсы. Т.е. нельзя сказать, что сделав сначала Шаг №1, затем Шаг №2 и т.д. мы на выходе получим готовые проверки с максимально полным покрытием.
Наоборот, эта техника основывается на опыте тестировщика и на его умении думать креативно и деструктивно.

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

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

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

— Историю работы приложения в прошлом.

— Наиболее вероятные типы дефектов, допускаемых при разработке.

— Типы дефектов, которые были обнаружены в схожих приложениях.

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

Получается, что предугадывание ошибки — это когда тест аналитик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку.

Например, в программе я вижу: «для подтверждения заказа введите свой номер телефона в формате +7(…)… ….» И я, как тестировщик, начинаю думать: «А если не вводить телефон?», «А если ввести в формате не +7, а просто 8? «, и так далее. Это и есть предугадывание ошибки.

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

Уже знакомая нам игра с молокозаводом

Возьмем объекты, которые нам необходимо построить. Например, каким образом можно сломать курятник на этапе покупки?

  1. Можно попробовать поставить его на другой объект

Ставим на другой объект

Ставим на другой объект

2. Или за границу доступного поля

Ставим за границу доступного поля

Ставим за границу доступного поля

3. За границей поля тоже не получается.. А давайте попробуем поставить на воду? Вдруг разработчики не учли этот момент?

Ставим на воду

Ставим на воду

Тоже никак, все работает как надо… Ладно поставим пока курятник на место. Теперь попробуем проверить, все ли нормально с его работой.

4. В курятник можно покупать и сажать кур. А что если попробовать вместо кур поместить коров?

Размещаем корову в курятник

Размещаем корову в курятник

5. Или попробовать кур поместить на территорию вне курятника

Размещаем кур вне курятника

Размещаем кур вне курятника

6. Или попробовать зайти в магазин, пока покупаем кур

Заходим в магазин во время покупки кур

Заходим в магазин во время покупки кур

«Ладно, видимо не в этот раз» — говорим мы себе и закрываем игру…

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

А теперь посмотрим на примере сайта

Возьмем один из элементов сайта — форму регистрации. Посмотрим на нее внимательно и подумаем, как мы можем ее «сломать».

Форма регистрации на сайте

Форма регистрации на сайте

Мне на ум приходят вот какие варианты:

  1. Указать e-mail c несуществующим доменом на конце.
  2. Указать e-mail без знака «@».
  3. Заполнить поле «Пароль» без использования обязательных символов. Например, если программа требует, чтобы в пароле были заглавные и строчные буквы, то пробуем ввести пароль без использования заглавных букв.
  4. В поле «Пароль еще раз» ввести символы отличные от символов в поле «Пароль».
  5. Снять галочку «Я принимаю условия Пользовательского соглашения».
  6. Ввести неверные символы с картинки.
  7. Оставить одно поле незаполненным.

________________________________

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

________________________________

В предугадывании ошибок нет четкой и логической схемы, которая позволила бы нам составить тест-кейсы. Т.е. нельзя сказать, что сделав сначала Шаг №1, затем Шаг №2 и т.д. мы на выходе получим готовые проверки с максимально полным покрытием.
Наоборот, эта техника основывается на опыте тестировщика и на его умении думать креативно и деструктивно.

Замечено,
что
некоторые
люди
по
своим
качествам
оказываются
прекрасными
специалистами
по
тестированию
программ.
Они
обладают
умением
«выискивать»
ошибки
и
без
привлечения
какой-либо
методологии
тестирования
(такой,
как
анализ
граничных
значений
или
применение
функциональных
диаграмм).

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

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

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

1. Сортируемый
список
пуст.

2. Сортируемый
список
содержит
только
одно
значение.

3. Все
записи
в
сортируемом
списке
имеют
одно
и
то
же значение.

4. Список
уже
отсортирован.

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

1) существует
только
один
вход
в
таблицу,
в
которой
ведется
поиск;

2) размер
таблицы
есть
степень
двух
(например,
16);

3) размер
таблицы
меньше
или
больше
степени
двух
(например,
15
или
17).

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

1. Допускает
ли
программа
«пробел»
в
качестве
ответа?

2. Запись
типа
2
(ответ)
появляется
в
наборе
записей
типа
3
(студент).

3. Запись
без
2 или
3 в
последней
колонке
появляется
не
как
начальная
запись
(название).

4. Два
студента
имеют
одно
и
то
же
имя
или
номер.

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

6. Поле
числа
вопросов
имеет
отрицательное
значение.

Для
команды
DISPLAY
из
предыдущего
раздела
целесообразно
рассмотреть
следующие
тесты
метода
предположения
об
ошибке:

1. DISPLAY
100

(неполный
второй
операнд).

2. DISPLAY
100.
(неполный
второй
операнд).

3. DISPLAY
100

10А42
(слишком
большое
значение
операнда).

4. DISPLAY
000

0000FF
(нули
слева).

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • Суть методики
  • Особенности
  • Что требуется, чтобы эффективно (пред)угадывать ошибки
  • Примеры
  • Преимущества и недостатки методики

Что это

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

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

Особенности

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

Методика направлена на поиск багов, не поддающихся другим методикам черного ящика. Поэтому стандартно выполняется уже после них.

Частыми ошибками в приложениях (следовательно, наиболее вероятными ошибками в тестируемом приложении) являются, например:

  • Ввод некорректных (невалидных) параметров и символов
  • Например, ввод пробела в “цифровые” поля, где это недопустимо
  • Ошибка-исключение null pointer exception
  • Деление на ноль
  • Превышение максимального количества передаваемых файлов
  • И подобные «типичные пользовательские» ошибки

Итак, цель предугадывания — найти ошибки, которые трудно “выловить” другими методиками черного ящика. Готовятся тест-кейсы, направленные на области наиболее вероятных ошибок; по возможности покрываются все проблемные места; но без избыточности.

Методика, разумеется, не является идеальной, способной обеспечить высокое качество — ведь она основана на интуиции, поэтому ограничена по умолчанию, зависит от умений и, главное, опытности QA-инженера. Она вовсе не гарантирует высокого покрытия, и должна сочетаться с другими методиками, дополнять их.

Что нужно, чтобы хорошо угадывать ошибки

  • Интуиция тестировщика
  • И его знание продукта
  • Опыт прошлых проектов
  • Чек-лист
  • Риск-репорты 
  • Знание типичных проблем с интерфейсом
  • Идеальное знание общих принципов тестирования
  • Результаты предыдущих тестов
  • Характерные ошибки, случавшиеся ранее

Примеры предугадывания ошибок

Пример 1 

В приложении есть функция ввода номера телефона клиента, и он должен быть стандартной длины, то есть 10 цифр. Методика предугадывания ошибок в данном случае может проверить, например:

  • Что случится, если ввести не цифру, а букву или пробел
  • Если ввести только 8 цифр
  • Если оставить поле пустым
  • Если ввести не 10, а 12 цифр

Если такие невалидные значения введены, и функция ведёт себя как ожидается — то есть показывает ошибку, она расценивается как не имеющая багов; в противном случае заводится баг, и функция передается разработчикам, чтобы те устранили баг.

Пример 2

Счет на банковской карте настроен так, что принимает только суммы от 5000 до 7000 рублей (так нужно клиенту). Действуя по методике предугадывания ошибок, подбираем значения ввода, пытаясь добиться наибольшего покрытия:

Значение Результат 
6000 ОК
5500 ОК
4000 Ошибка
7200 Ошибка
7400 Ошибка
8000 Ошибка
Пустое Ошибка
100$ Ошибка
… и так далее

Преимущества и недостатки методики

Преимущества

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

Недостатки

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

***

Раздел: Тестирование > Техники тест дизайна

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

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

  • Эквивалентное Разделение (Equivalence Partitioning — EP). Как пример, у вас есть диапазон допустимых значений от 1 до 10, вы должны выбрать одно верное значение внутри интервала, скажем, 5, и одно неверное значение вне интервала — 0.
  • Анализ Граничных Значений (Boundary Value Analysis — BVA). Если взять пример выше, в качестве значений для позитивного тестирования выберем минимальную и максимальную границы (1 и 10), и значения больше и меньше границ (0 и 11). Анализ Граничный значений может быть применен к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.
  • Причина / Следствие (Cause/Effect — CE). Это, как правило, ввод комбинаций условий (причин), для получения ответа от системы (Следствие). Например, вы проверяете возможность добавлять клиента, используя определенную экранную форму. Для этого вам необходимо будет ввести несколько полей, таких как «Имя», «Адрес», «Номер Телефона» а затем, нажать кнопку «Добавить» — эта «Причина». После нажатия кнопки «Добавить», система добавляет клиента в базу данных и показывает его номер на экране — это «Следствие».
  • Предугадывание ошибки (Error Guessing — EG). Это когда тест аналитик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку. Например, спецификация говорит: «пользователь должен ввести код». Тест аналитик, будет думать: «Что, если я не введу код?», «Что, если я введу неправильный код? «, и так далее. Это и есть предугадывание ошибки.
  • Исчерпывающее тестирование (Exhaustive Testing — ET) — это крайний случай. В пределах этой техники вы должны проверить все возможные комбинации входных значений, и в принципе, это должно найти все проблемы. На практике применение этого метода не представляется возможным, из-за огромного количества входных значений.

Наверх

1. Тестирование ПО Лекция 5. Методики тестирования

ШТАНЮК А.А., 2019

2. Позитивные и негативные тесты

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

3. «Черный ящик»

ВХОД
ВЫХОД

4. «Черный ящик»

• Не знаем/Игнорируем устройство тестируемого объекта
• Можем управлять входными параметрами
• Среда, в которой проводим эксперименты, может считаться входным
параметром
• Можем измерять выходные параметры

5. Шаги

1.
2.
3.
4.
5.
Изучение спецификаций и требований
Выбор входных значений
Определение ожидаемых выходных
значений
Исполнение тестов
Сравнение полученных результатов с
ожидаемыми

6. Стратегии

Число тестов определяется числом входов и диапазоном входных данных
Перебор всех вариантов (по диапазону), как правило, невозможен!
Стратегии уменьшения числа тестов:
1. Классы эквивалентности
2. Граничные условия

7. Классы эквивалентности

Если от двух тестов ожидается одинаковый результат – они эквивалентны
Группа тестов представляет класс эквивалентности если:
• Все тесты предназначены для выявление одной и той же ошибки
• Если один тест выявит ошибку, то и остальные это сделают
• Если один из тестов не выявит ошибку, то и остальные этого не сделают
Дополнительные практические критерии:
Тесты включают значения одних и тех же входных данных
Для проведения теста выполняются одни и те же операции программы
В результате тестов формируются значения одних и тех же выходных данных
Ни один из тестов не вызывает выполнения конкретного блока обработки
ошибок либо выполнение этого блока вызывается всеми тестами

8. Классы эквивалентности

Программа классификации треугольников
Классы эквивалентности по корректным входным данным:
• Равнобедренные треугольники
• Равносторонние треугольники
• Прямоугольные треугольники
• Просто треугольники
Классы эквивалентности по некорректным входным данным:
• Отрезки не образуют треугольник
• Числа больше sizeof(int)
• Строка, содержащая буквы

9. Классы эквивалентности

Программа, говорящая дату следующего дня
Классы эквивалентности по корректным входным данным:
День от 1 до 27
Последний день месяца
Последний день года
28 февраля високосного года
Классы эквивалентности по некорректным входным данным:
Месяц > 12
День > 31
Неверная строка

10. Классы эквивалентности

Построение классов эквивалентности – субъективный процесс
Общие рекомендации:
• Не забывайте о классах некорректных данных
• Формируйте классы в виде таблицы или плана
• Определите диапазоны числовых значений входных данных
• Проанализируйте варианты выбора из списков и меню
• Поищите переменные значения которых должны быть равными
• Поищите классы значений, зависящих от времени
• Выявите группы переменных, совместно участвующих в конкретных вычислениях
• Посмотрите на какие действия программа отвечает эквивалентными событиями
• Продумайте варианты среды тестирования

11. Граничное тестирование

Тестирование значений лежащих на границе классов эквивалентности,
т.к. там выше вероятность возникновения ошибки
int safe_add( int a, int b )
{
int c = a + b ;
if ( a >= 0 && b >= 0 && c < 0 )
{
fprintf ( stderr, «Overflow!n»);
}
if ( a < 0 && b < 0 && c >= 0 )
{
fprintf ( stderr, «Underflow!n»);
}
return c;
}

12. Граничное тестирование

• Определяем границу класса эквивалентности
• Проверяем значения, лежащие ровно на границе
• Проверяем значения лежащие максимально близко к границе с обоих
сторон
Пример:
При покупке более 100 единиц товара дается скидка 5%. Нужно
проверить:
• 100
• 99
• 101

13. Преимущества и недостатки «ЧЯ»

Преимущества:
• Тестирование с точки зрения пользователя
• Не требует специальных знаний (например конкретного языка
программирования)
• Позволяет найти проблемы в спецификациях
• Можно создавать тесты параллельно с кодом
• Тестировщик может быть отделен от разработчиков

14. Преимущества и недостатки «ЧЯ»

Недостатки:
Эффективность зависит от выбора конкретных тестовых
значений
Необходимость наличия четких и полных спецификаций
Невозможность сконцентрироваться на особо сложных
частях кода
Трудность локализации причины дефекта
Возможность не протестировать часть кода

15. «Белый ящик»

• Используем знание об устройстве тестируемого объекта
• В случае ПО – имеем полный доступ к тестируемому коду
Стадии применения:
• Unit-тестирование
• Интеграционное тестирование

16. Шаги

Представляем программу в виде графа

17. Шаги

Создаем тестовые сценарии чтобы:
• Попасть в каждое ветвление
• Пройти хоть раз через все вершины
• Пройти всеми возможными путями
• Пройти через вновь добавленные участки
• Пройти через известные проблемные участки

18. Метрики

Покрытие кода (code coverage) – мера измерения оттестированости
имеющегося программного кода
Microsoft Visual Studio 2010(C++, C#)
DevPartner (C#, Java)
Codecov из Intel Compiler (C, C++, Fortran)
Jtest (Java)
Devel::Cover (Perl)
PHPUnit (PHP)
Coverage (Python)
CoverMe (Ruby)

19. Преимущества и недостатки

Преимущества:
• Позволяет найти «скрытые» в коде дефекты
• Позитивные побочные эффекты (например, обучение команды)
• Нахождение проблем производительности
• Более надежное разбиение на классы эквивалентности
• Как правило, ускорение цикла нахождение-исправление
Недостатки:
• Не найдем пропущенное в коде
• Дорого

20. Сравнение «ящиков»

Критерий
Черный Ящик
Белый Ящик
Основной уровень
применимости
Приемочное
тестирование
Юниттестирование
Ответственный
Независимый
тестировщик
Разработчик
Знание
программирования
Не обязательно
Необходимо
Знание
реализации
Не обязательно
Необходимо
Знание сценариев
использования
Необходимо
Не обязательно
Основа тестовых
сценариев
Спецификации
Код

21. «Серый» ящик

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

22. Выбор входных значений

Бессистемный выбор входных значений не позволит найти большое
количество дефектов. Необходимо использование методов для выбора
набора входных значений.
Основные методы выбора входных значений:
• Перебор всех возможных значений
• Случайные входные данные
• Предугадывание ошибки
• Построение графов «причина-следствие»
• Использование классов эквивалентности
• Исследование граничных значений

23. Метод перебора

Перебираем все возможные значения входных параметров
Последовательный перебор всех возможных комбинаций входных
значений
Попарный перебор. Перебираем комбинации пары 2х входных
параметров. Работаем в предположении что параметры попарно
зависимы. На практике находит ~80% функциональных дефектов
низкого уровня

24. Случайные входные данные

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

25. Предугадывание

Составление тестовых сценариев на основании опыта предыдущего тестирования
Используйте знания о известных проблемных местах вашего продукта
Знайте распространенные ошибки программирования и пишите тесты для их
поиска
◦ Некорректная работа с памятью: переполнение, чтение за пределами, утечки памяти
◦ Отсутствие обработки некорректных входных данных
◦ Ошибки работы с типами данных: переполнение, приведение, приближение
◦ Ошибки многопоточности: deadlock, data race
◦ Отсутствие инициализации/сброса переменных
◦ Недостаток привилегий, недоступность ресурсов
◦ ….

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

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

-aвтомaтический, когда обучаемый
выполняет задание в непосредственном
диалоге с ЭВМ, результаты сразу переносятся
в блок обработки; 
-полуaвтомaтический, когда
задания выполняются письменно, а ответы
со специальных бланков вводятся в ЭВМ
(решения не проверяются); 
-aвтоматизированный, когда
задания выполняются письменно, решения
проверяются преподавателем, а в ЭВМ вводятся
результаты проверки.

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

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

“Aвтоматический” вариант применяется
на кафедре “ВТ и САПР” в СибАДИ . По подробней
об этом будет сказано дальше.

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

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

Также к достоинствам можно отнести 
простоту входа-выхода в систему; удобный 
интерфейс; минимaльность информации,
необходимой для регистрации студентa 
(Ф.И.О., группа, № зачетной книжки, пароль);
возможность aвтоматической 
(ручной) проверки прaвильности данных
студентами ответов преподавателем в
любое время; сохранность данных в системе
(в течении любого необходимого периода
времени); индивидуaльность тестирования
(студент вводит свой пароль, без которого
никто другой войти и выполнить тестирование
за него не сможет).

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

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

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

Вопросы и задачи заносятся в банк, как правило, вместе
с несколькими 
(обычно 5-10) вариантами ответов. Эти вaрианты
сообщаются студенту одновременно с формулировкой
задания, и он должен выбрать из них верный. 
Возможно, что полным правильным ответом
является набор некоторого количества
приведенных вариантов.

Банк ответов. Содержит
прaвильные ответы к каждому заданию, компьютер
сверяет данный студентом ответ с содержанием
банка.

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

Формирование задания.
В соответствии с указаниями преподавателя 
этот блок создает сценарий проверочной 
работы для каждого студента, случайным 
образом выбирая из банка вопросов
определяемое преподавателем количество заданий по каждой теме.

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

Блок управления. Обеспечивает
нормальное функционирование системы проверки знаний и позволяет
вводить в процессе работы необходимые
коррективы.

Блок формирования оценок.
Осуществляет сравнение ответа студента
с содержанием банка ответов,
и в соответствии с выбранным 
режимом оценивания, фиксирует оценку
ответа в баллах.

Протоколы, статистика. Записывает
в память компьютера фамилию студента,
дату экзамена, распределение набранных 
баллов.

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

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

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

Раньше при старой
системе проведения экзамена по курсу 
“Информатика” требовалось довольно
много времени для опроса всех студентов. В настоящее время
теоретической частью экзамена является
тестирование. Для охвата всей темы в тесте
предлагается 30-40 вопросов. По окончании
проведения контроля оценку ставит сама
машина.

Метод компьютерного тестирования вот
уже несколько лет применяется в курсе
“Теории вероятности и математической
статистики”. На практическом занятии
после обсуждения определений, формул
и типовых задач студенты начинают самостоятельную
работу с тестами. 
Тестирование рассчитано на 40 минут. При
такой организации работы преподаватель
выступает в роли консультанта, имеет
возможность обсудить практически с каждым
наиболее трудные моменты и ошибки. За
отведенное время студент успевает разобрать
10-15 задач вместо обычных 3-4.

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

Задания предлагаются, как 
правило, с ответами в “закрытой 
форме”, когда нужно выбрать один
из нескольких предложенных ответов 
или в “открытой форме”, когда 
нужно вставить пропущенное слово. В этом случае, когда ответ однозначен,
он оценивается по двухбалльной системе
— 1 или 0, если задание имеет несколько
правильных ответов, возможны три оценки
-0, 0.5 и 1. 
Введение в тест заданий с многовариантными
ответами развивает у студента потребность
в поиске разных путей решения задачи,
что необходимо для достижения основной
цели обучения в вузе — умения самостоятельно
выбирать способ выполнения поставленной
задачи.

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

По мнению исследователей
такой методики раздел курса считается 
проработанным, если выполнено 70% заданий.

Необходимо заметить,
что тесты, создаваемые с привлечением компьютерных технологий
или же без них, должны быть максимально
просты в использовании (особенно на ЭВМ),
и не требовали специальной подготовки
для работы на компьютере.

2. Традиционные 
формы педагогического контроля

Методы обучения в их традиционных вaриантах
иногда подразделены на методы преподавания,
методы учения и методы контроля .

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

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

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

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

Перечисленные методы диагностирования
успеваемости учащихся имеют определенные
недостатки. Рaссмотрим некоторые из них . 
Могут возникать трудности, связанные
с особенностями преподавательской работы: 
— довольно часто проявляются несовпадение
требований разных преподавателей, отличия
в их уровне строгости при оценке одного
и того же ответа; 
— различие в профессиональной квалификации; 
— при организации текущих проверок знaний
большого числа студентов, когда оценивание
проводится, главным образом, лишь по формальным
критериям, наблюдается загруженность
преподавателя рутинной мало творческой
работой, связанной с большим объемом
информaции, которую требуется подготовить,
обрaботать и проанализировать за относительно
короткий промежуток времени; 
— возможная небеспристрастность преподавателя
(по психологическим и иным причинам) к
оценке ответов некоторых студентов; 
— иногда оценки, выставляемые студентам,
оказываются недостоверными из-за опасения
преподавателя, что они будут использованы
для оценивания работы самого преподaвaтеля. 
Трудности, связанные со спецификой традиционной
формы проверки знаний. 
Такие, как отсутствие четко сформулированных
стандартов знаний и конкретно очерченных
объемов умений, достаточных для каждой
положительной оценки 
(часто преподаватель мучается с вопросом:
«Какую оценку поставить — «неуд»
или все же можно оценить как «удовлетворительно»?”). 
Трудности, связанные со студентами: использование
шпаргалок, списывание, 
«взаимопомощь» на экзамене, что искажает
достоверность оценки знаний студентов
и мешает преподавателю объективно взглянуть
на качество своей педагогической работы. 
Отсутствие объективных критериев оценки
и эффективных механизмов сравнения результатов
обучения по данной дисциплине (специальности)
в различных 
ВУЗах, что особенно актуально для выработки
верной стратегии подготовки кадров. Принятая,
преимущественно, методика приема экзаменов
по 3-4 вопросам в билете не позволяет оценить
полноту освоения материала и провоцирует
списывание.

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

3. Формирование 
оценочной шкалы тестового контроля

При создании тестов возникают 
определенные трудности в части формирования шкалы оценок
правильности выполнения заданий студентами
.

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

В существующих системах
тестирования предполагается, что преподаватель-
экзaменатор зaранее выбирает определенную
шкaлу оценок, т.е. устанавливает, например,
что, если испытуемый набирает от 31 до
50 баллов, то он получает оценку “отлично”,
от 25 до 30 баллов -”хорошо”, от 20 до 24 — 
“удовлетворительно”, менее 20 — “неудовлетворительно”.

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

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

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

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

Методы тестирования ПО МЕТОДЫ ПОИСКА ОШИБОК

Методы тестирования ПО МЕТОДЫ ПОИСКА ОШИБОК

Содержание лекции Определимся, кто несет ответственность за качество системы Изучим методы поиска ошибок Задания

Содержание лекции Определимся, кто несет ответственность за качество системы Изучим методы поиска ошибок Задания

Качество vs ответственность От кого зависит качество системы? Кто несет ответственность за качество системы?

Качество vs ответственность От кого зависит качество системы? Кто несет ответственность за качество системы?

Классификация по знанию внутренней системы

Классификация по знанию внутренней системы

Разработка через тестирование

Разработка через тестирование

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

Преимущества 1. Возможность убедиться, что приложение пригодно для тестирования 2. Автоматизированные тесты покрывают все пути исполнения 3. Разработчик продумывает детали интерфейса до реализации 4. Тесты заставляют делать свой код более приспособленным для тестирования 5. Модульное тестирование способствует формированию четких и небольших интерфейсов 6. Несмотря на то, что при разработке через тестирование требуется написать большее количество кода, общее время, затраченное на разработку, обычно оказывается меньше 7. Тесты защищают от ошибок. Поэтому время, затрачиваемое на отладку, снижается многократно 8. Устранение дефектов на более раннем этапе разработки, препятствует появлению хронических и дорогостоящих ошибок, приводящих к длительной и утомительной отладке в дальнейшем 9. Тесты позволяют производить рефакторинг кода без риска его испортить. При внесении изменений в хорошо протестированный код риск появления новых ошибок значительно ниже 10. Уверенность в том, что изменения не нарушит существующую функциональность, придает уверенность разработчикам и увеличивает эффективность их работы 11. Разработка через тестирование способствует более модульному, гибкому и расширяемому коду. 12. Тесты могут использоваться в качестве документации. Хороший код расскажет о том, как он работает, лучше любой документации.

Слабые места 1. 2. 3. 4. 5. 6. 7. Существуют задачи, которые невозможно решить

Слабые места 1. 2. 3. 4. 5. 6. 7. Существуют задачи, которые невозможно решить Прохождение функциональных тестов Поддержка от руководства Модульные тесты обычно пишутся теми же, кто пишет тестируемый код Ложное ощущение надежности Тесты сами по себе являются источником накладных расходов Сложно определить покрытие тестами: неудачные архитектура, дизайн или стратегия тестирования приводят к большому количеству непройденных тестов, важно их все исправить в индивидуальном порядке. Простое удаление, отключение или поспешное изменение их может привести к необнаруживаемым пробелам в покрытии тестами.

Разработка тестов МЕТОДЫ ПОИСКА ОШИБОК

Разработка тестов МЕТОДЫ ПОИСКА ОШИБОК

Где искать тесты? ● Тщательное изучение и анализ требований (описания функции, модуля, спецификации, и

Где искать тесты? ● Тщательное изучение и анализ требований (описания функции, модуля, спецификации, и т. д. ). ● Декомпозиция требованийфункций. ● Выявление всех условий, входных и выходных данных (что) ● Анализ поведения (как) ● Использование различных техник для выделения определенных тестов ● Использование накопленных знаний о выполненных проектах (оттестированных продуктах) ● Интуиция ● Анализпросмотр выявленных тестов и добавление новых

Проблемы, которые придется решить ● ● ● Искать все ошибки или грубейшие? Если не

Проблемы, которые придется решить ● ● ● Искать все ошибки или грубейшие? Если не все, то как установить порог допустимости ошибки? Когда завершать тестирование? Что делать, если сроки поджимают и/или нет ресурсов на дальнейшее тестирование? Где остановиться в документировании тестов? Изменять тест или следовать первоначальной инструкции?

Классы эквивалентности (partitioning, equivalent analysis) ● Анализируем входные и выходные данные: ○ правильные классы

Классы эквивалентности (partitioning, equivalent analysis) ● Анализируем входные и выходные данные: ○ правильные классы эквивалентности (корректные входные данные) ○ неправильные классы эквивалентности (ошибочные входные данные)

Лучшие представители ● Какие значения тестировать внутри класса эквивалентности? ● Используем предположения: ○ Множество

Лучшие представители ● Какие значения тестировать внутри класса эквивалентности? ● Используем предположения: ○ Множество возможных значений непрерывно ○ Значения могут быть спроецированы на числовую ось, мы всегда можем определить, что из двух значений одно больше, а другое меньше или они одинаковы

Разберем пример Программа: INPUT < 10 ÞРезультат: сообщение об ошибке 10 <= INPUT <

Разберем пример Программа: INPUT

Выводы: Типы ошибок: ● Программа не принимает числовые значения как факт ○ ● Написали

Выводы: Типы ошибок: ● Программа не принимает числовые значения как факт ○ ● Написали

Анализ граничных значений (Boundary Value Testing) ● Идентифицировать граничные значения для каждого входного значения

Анализ граничных значений (Boundary Value Testing) ● Идентифицировать граничные значения для каждого входного значения (класса эквивалентности) ○ на границе ○ значение, меньшее граничного ( «у границы» ’below point’) ○ значение, большее граничного ( «за границей» ’above point’) Примеры: ➢ Область корректных значений: [-1. 0, 1. 0] -> тесты для -1. 0, -1. 001, 1. 001 ➢ Максимальная длина слова – 5 символов — > тесты для 4, 5, 6 ➢ Область выходных значений: минимум расхода 0. 00, максимум 2000 -> подбираем входные данные для того, чтобы получить на выходе 0. 00, 2000. 01, -0. 01

В задаче: INPUT < 10 10 <= INPUT < 25 25 <= INPUT Проецируем

В задаче: INPUT

Граничные значения Для точки: Z -> Z-1, Z, Z+1 Для отрезка: [x, y] ->

Граничные значения Для точки: Z -> Z-1, Z, Z+1 Для отрезка: [x, y] -> x-1, x, y, y+1 А для такого интервала значений: (х, у) ?

Выбор значений ● ● Значение в пределах класса является лучшим представителем Граничные значения часто

Выбор значений ● ● Значение в пределах класса является лучшим представителем Граничные значения часто будут лучшими представителями Могут быть лучшие представители, которые не будут граничными значениями Могут быть выделены лучшие представители в классах, значения которых не будут очевидно сравнимы (больше-меньше)

Как тестируем? ● Классы эквивалентности: некорректные значения ○ Тестировать одно некорректное значение за раз

Как тестируем? ● Классы эквивалентности: некорректные значения ○ Тестировать одно некорректное значение за раз для того, чтобы проверить, что система идентифицирует его корректно. ● Классы эквивалентности: корректные значения ○ Как ?

Стратегии работы с новым кодом ТАБЛИЦЫ РЕШЕНИЙ (DECISION TABLE TESTING)

Стратегии работы с новым кодом ТАБЛИЦЫ РЕШЕНИЙ (DECISION TABLE TESTING)

Этапы построения таблицы 1. 2. 3. 4. 5. Определить/записать все условия Посчитать количество возможных

Этапы построения таблицы 1. 2. 3. 4. 5. Определить/записать все условия Посчитать количество возможных комбинаций условий Запомнить комбинации Записать действия Убрать лишние комбинации (схлопывание таблицы)

Пример: светофор (SQA DAYS 14 - ЕЛЕНА СТАШЕНКО)

Пример: светофор (SQA DAYS 14 — ЕЛЕНА СТАШЕНКО)

Автомобиль находится перед светофором, определить его дальнейшие действия Условия: ØГорит ли красный? Y N

Автомобиль находится перед светофором, определить его дальнейшие действия Условия: ØГорит ли красный? Y N ØГорит ли желтый? Y N ØГорит ли зеленый? Y N Количество комбинаций: Ø 2*2*2 = 8

1. Определить список возможных условий и их значения

1. Определить список возможных условий и их значения

2. Определить список всех возможных действий (ожидаемых результатов для условий)

2. Определить список всех возможных действий (ожидаемых результатов для условий)

3. Определить все значения для условий ( «да» «нет» или более 2 х

3. Определить все значения для условий ( «да» «нет» или более 2 х значений) и их уникальные комбинации, которые приводят к выполнению ожидаемых результатов связанных с этим правилом

4. Создать тест кейс для каждого правила (столбца) – как минимум один, если условия

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

Дополнительные условия

Дополнительные условия

Метод предугадывания ошибок тестирование

Убрать лишние комбинации

Убрать лишние комбинации

Убрать лишние комбинации

Убрать лишние комбинации

Стратегии работы с новым кодом ФУНКЦИОНАЛЬНЫЕ ДИАГРАММЫ (CAUSE-EFFECT GRAPHING)

Стратегии работы с новым кодом ФУНКЦИОНАЛЬНЫЕ ДИАГРАММЫ (CAUSE-EFFECT GRAPHING)

Что это и зачем? ● Предлагает способ перевода спецификаций, написанных на естественном языке, на

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

Алгоритм действий 1. Разбить внешние спецификации на отдельные функции, которые будут тестироваться (декомпозиция функциональных

Алгоритм действий 1. Разбить внешние спецификации на отдельные функции, которые будут тестироваться (декомпозиция функциональных требований) 2. Идентифицировать явные и неявные причины (условия на входе) и присвоить каждой из них уникальный номер 3. Идентифицировать явные и неявные эффекты (действия на выходе) и присвоить каждому из них уникальный номер 4. Перевести семантику спецификации в граф «причина-следствие» (Boolean cause-effect graphing) 5. Добавить информацию о невозможных комбинациях причинэффектов 6. Построить таблицу решений (бинарные значения) 7. Записать тест кейс для каждого столбца

Пример Requirements for Calculating Car Insurance Premiums: For females less than 65 years of

Пример Requirements for Calculating Car Insurance Premiums: For females less than 65 years of age, the premium is $500 For males less than 25 years of age, the premium is $3000 For males between 25 and 64 years of age, the premium is $1000 For anyone 65 years of age or more, the premium is $1500

Причины (Causes) – входные условия 1. Пол: мужской 2. Пол: женский 3. Возраст: <25

Причины (Causes) – входные условия 1. Пол: мужской 2. Пол: женский 3. Возраст: =25 and = 65

Следствия (Effects) – выходные результаты 100. Премия = $1000 101. Премия = $3000 102.

Следствия (Effects) – выходные результаты 100. Премия = $1000 101. Премия = $3000 102. Премия = $1500 103. Премия = $500

Причина: 1. Пол: мужской and 3. Возраст: < 25 Следствие: 101: Премия = $3000

Причина: 1. Пол: мужской and 3. Возраст:

Причина: 1. Пол: мужской and 4. Возраст: >=25 and < 65 Следствие: 100: Премия

Причина: 1. Пол: мужской and 4. Возраст: >=25 and

Причина: 1. Пол: мужской and 5. Возраст: >= 65 or 2. Пол: женский and

Причина: 1. Пол: мужской and 5. Возраст: >= 65 or 2. Пол: женский and 5. Возраст: >= 65 Следствие: 102: Премия = $1500

Причина: 2. Пол: женский and 3. Возраст: < 25 or 2. Пол: женский and

Причина: 2. Пол: женский and 3. Возраст: =25 and

Причина: 1. Пол: мужской and 5. Возраст: >= 65 or 2. Пол: женский and

Причина: 1. Пол: мужской and 5. Возраст: >= 65 or 2. Пол: женский and 5. Возраст: >= 65 Следствие: 102: Премия = $1500

Преобразование в таблицу решений Test Cases 1 (мужской) 2 (женский) 3 (< 25) 4

Преобразование в таблицу решений Test Cases 1 (мужской) 2 (женский) 3 (= 25 and = 65) 1 1 0 0 2 1 0 0 1 0 3 1 0 0 0 1 4 0 1 0 0 1 5 0 1 1 0 0 6 0 1 0 100 (1000$) 101 (3000$) 102 (1500$) 103 (500$) 0 1 0 0 0 0 0 1

Особенности применения ф. диаграмм 1. Требуется трансляция спецификации в булевскую логическую сеть 2. Обнаружение

Особенности применения ф. диаграмм 1. Требуется трансляция спецификации в булевскую логическую сеть 2. Обнаружение неполноты и неоднозначности в исходных спецификациях 3. Применение функциональных диаграмм не обеспечивает построение всех полезных тестов, которые могут быть определены: a. Как пример: метод неадекватно исследует граничные условия 4. Лучше отделять анализ граничных значений от метода функциональных диаграмм (иначе граф существенно усложняется) 5. Наиболее трудным при реализации метода является преобразование диаграммы в таблицу решений

Стратегии работы с новым кодом ДРУГИЕ МЕТОДЫ

Стратегии работы с новым кодом ДРУГИЕ МЕТОДЫ

Метод предположение об ошибке (Error guessing) ● Этот метод в значительной степени является интуитивным

Метод предположение об ошибке (Error guessing) ● Этот метод в значительной степени является интуитивным ● Тест инженер использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку ● Перечислить в некотором списке возможные ошибки или ситуации, в которых они могут появиться, а затем на основе этого списка написать тесты

Requirements-Driven Testing Проверяем каждое требованиезапрос, которое описано или озвучено анализ требований: выявление неоднозначностей, неточностей,

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

Задания 1. Классы эквивалентности 2. Граничные значения 3. Таблица решений 4. Функциональные диаграммы

Задания 1. Классы эквивалентности 2. Граничные значения 3. Таблица решений 4. Функциональные диаграммы

1. Выполнить разбиение на классы эквивалентности 1. 1 Password – длина не меньше 8

1. Выполнить разбиение на классы эквивалентности 1. 1 Password – длина не меньше 8 символов, максимум 16. Может состоять из латинских букв и цифр, а также могут быть использованы символы только из списка «!» , «_» , «? » , «#» . При этом пароль должен обязательно содержать, как минимум, одну заглавную букву и одну цифру. 1. 2 Значение для ‘Product ID’ должно содержать 5 символов, первые два из них должны быть обозначениями из списка допустимых значений (A 1 or A 2 or B 1 or B 2), остальные три — уникальным числовым значением.

Определить граничные значения 2. 1 Корректные значения X - целые значения от -2 до

Определить граничные значения 2. 1 Корректные значения X — целые значения от -2 до 10 2. 2 Максимальное длина вводимого значения равна 20 символам

3. Составить таблицу решений 3. 1 Страховая компания предоставляет страховку клиентам, достигшим 18 -ти

3. Составить таблицу решений 3. 1 Страховая компания предоставляет страховку клиентам, достигшим 18 -ти летнего возраста. Если стаж водителя составляет от 2 -х до 6 -ти лет, предоставляется скидка 20%. Если стаж водителя более шести лет, скидка 30% 3. 2 Любому посетителю салона красоты «Жасмин» может быть присвоена одна из категорий: «Клиент» , «Клиент категории А» , «Клиент категории Б» , «Клиент категории С» в зависимости от количества посещение салона. Категория «Клиент» присваивается посетителю, на счету которого 3 посещения и более. Категория «Клиент категории А» присваивается посетителю, на счету которого 10 посещений и более. Категория «Клиент категории Б» присваивается посетителю, на счету которого 20 посещений и более. Категория «Клиент категории С» присваивается посетителю, на счету которого 30 посещений и более.

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

3. Составить таблицу решений 3. 2 Система скидок магазина Скидки предоставляются покупателям, которые приобрели накопительную карту магазина. Изначально карта имеет тип “Standard” c нулевым балансом. При покупке товара и предъявлении карты при оплате, сумма покупок зачисляется на баланс карты. Величина скидки зависит от общей суммы покупок на карте покупателя и от типа карты. Для карты тип “Standard” скидки составляют: ● 5%, если общая сумма покупок на карте от 20000 руб до 40000 руб включительно, ● 10%, если сумма на карте больше, чем 40000 руб. Магазин меняет карту типа “Standard” на карту типа “Silver Card”, если накопительная сумма покупателя на карте типа “Standard” становится равной или больше 50000 руб. Для карты тип “Silver Card” скидки составляют: ● 10%, если сумма на карте от 50000 руб до 70000 руб включительно, ● 20%, если сумма на карте больше, чем 70000 руб. Магазин меняет карту типа “Silver Card” на карту типа “Gold Card”, если накопительная сумма покупателя на карте типа “Silver Card” становится равной или больше 100000 руб. Для карты типа “Gold Card” скидки составляют: ● 20%, если сумма на карте от 100000 руб до 150000 руб включительно, ● 30%, если сумма на карте больше, чем 150000 руб. Магазин меняет карту типа “Gold Card” на карту типа “VIP Card”, если накопительная сумма покупателя на карте типа “Gold Card” становится равной или больше 200000 руб. Для карты типа “VIP Card” скидки составляют: 30%, если сумма на карте больше, чем 200000 руб

4. Применить метод функциональных диаграмм 4. 1 Для банкомата банка «ТТТ» реализовано ПО, которое

4. Применить метод функциональных диаграмм 4. 1 Для банкомата банка «ТТТ» реализовано ПО, которое автоматизирует такие функции как выдача денег, выдча справки о балансе (доступные средства на карте), выдача распечатки с 10 ю последними операциями по карте, оплата услуг по мобильной связи Проанализирйте спецификацию для функции «Обработка запроса на снятие суммы с карты» и примените метод функциональных диаграмм для создания тест кейсов. Разработать и описать тест-кейсы в матрице (xls-file). ● Спецификация для функции «Обработка запроса на снятие суммы с карты» : Если карта типа «кредитная» (K) или «дебетовая» (D), то банкомат выдает деньги клиенту при условии, что запрашиваемая сумма (X) не превышает сумму доступных средств на карте клиента (S). Если карта типа «кредитная» , то банкомат выдает деньги и в случае, если запрашиваемая сумма превышает сумму доступных средств на карте, но не выходит за рамки допустимого превышения кредита (L). В случае, если карта не является «кредитной» или «дебетовой» или же запрашиваемая сумма превышает сумму доступных средств на карте для дебетовой карты или же запрашиваемая сумма превышает сумму доступных средств на карте и выходит за рамки допустимого превышения кредита для кредитовой карты, тогда выдается сообщение о том, что деньги не могут быть выданы и деньги не выдаются.

Метод предугадывания ошибок тестирование

Методы тестирования ПО МЕТОДЫ ПОИСКА ОШИБОК

Методы тестирования ПО МЕТОДЫ ПОИСКА ОШИБОК

Содержание лекции Определимся, кто несет ответственность за качество системы Изучим методы поиска ошибок Задания

Содержание лекции Определимся, кто несет ответственность за качество системы Изучим методы поиска ошибок Задания

Качество vs ответственность От кого зависит качество системы? Кто несет ответственность за качество системы?

Качество vs ответственность От кого зависит качество системы? Кто несет ответственность за качество системы?

Классификация по знанию внутренней системы

Классификация по знанию внутренней системы

Разработка через тестирование

Разработка через тестирование

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

Преимущества 1. Возможность убедиться, что приложение пригодно для тестирования 2. Автоматизированные тесты покрывают все пути исполнения 3. Разработчик продумывает детали интерфейса до реализации 4. Тесты заставляют делать свой код более приспособленным для тестирования 5. Модульное тестирование способствует формированию четких и небольших интерфейсов 6. Несмотря на то, что при разработке через тестирование требуется написать большее количество кода, общее время, затраченное на разработку, обычно оказывается меньше 7. Тесты защищают от ошибок. Поэтому время, затрачиваемое на отладку, снижается многократно 8. Устранение дефектов на более раннем этапе разработки, препятствует появлению хронических и дорогостоящих ошибок, приводящих к длительной и утомительной отладке в дальнейшем 9. Тесты позволяют производить рефакторинг кода без риска его испортить. При внесении изменений в хорошо протестированный код риск появления новых ошибок значительно ниже 10. Уверенность в том, что изменения не нарушит существующую функциональность, придает уверенность разработчикам и увеличивает эффективность их работы 11. Разработка через тестирование способствует более модульному, гибкому и расширяемому коду. 12. Тесты могут использоваться в качестве документации. Хороший код расскажет о том, как он работает, лучше любой документации.

Слабые места 1. 2. 3. 4. 5. 6. 7. Существуют задачи, которые невозможно решить

Слабые места 1. 2. 3. 4. 5. 6. 7. Существуют задачи, которые невозможно решить Прохождение функциональных тестов Поддержка от руководства Модульные тесты обычно пишутся теми же, кто пишет тестируемый код Ложное ощущение надежности Тесты сами по себе являются источником накладных расходов Сложно определить покрытие тестами: неудачные архитектура, дизайн или стратегия тестирования приводят к большому количеству непройденных тестов, важно их все исправить в индивидуальном порядке. Простое удаление, отключение или поспешное изменение их может привести к необнаруживаемым пробелам в покрытии тестами.

Разработка тестов МЕТОДЫ ПОИСКА ОШИБОК

Разработка тестов МЕТОДЫ ПОИСКА ОШИБОК

Где искать тесты? ● Тщательное изучение и анализ требований (описания функции, модуля, спецификации, и

Где искать тесты? ● Тщательное изучение и анализ требований (описания функции, модуля, спецификации, и т. д. ). ● Декомпозиция требованийфункций. ● Выявление всех условий, входных и выходных данных (что) ● Анализ поведения (как) ● Использование различных техник для выделения определенных тестов ● Использование накопленных знаний о выполненных проектах (оттестированных продуктах) ● Интуиция ● Анализпросмотр выявленных тестов и добавление новых

Проблемы, которые придется решить ● ● ● Искать все ошибки или грубейшие? Если не

Проблемы, которые придется решить ● ● ● Искать все ошибки или грубейшие? Если не все, то как установить порог допустимости ошибки? Когда завершать тестирование? Что делать, если сроки поджимают и/или нет ресурсов на дальнейшее тестирование? Где остановиться в документировании тестов? Изменять тест или следовать первоначальной инструкции?

Классы эквивалентности (partitioning, equivalent analysis) ● Анализируем входные и выходные данные: ○ правильные классы

Классы эквивалентности (partitioning, equivalent analysis) ● Анализируем входные и выходные данные: ○ правильные классы эквивалентности (корректные входные данные) ○ неправильные классы эквивалентности (ошибочные входные данные)

Лучшие представители ● Какие значения тестировать внутри класса эквивалентности? ● Используем предположения: ○ Множество

Лучшие представители ● Какие значения тестировать внутри класса эквивалентности? ● Используем предположения: ○ Множество возможных значений непрерывно ○ Значения могут быть спроецированы на числовую ось, мы всегда можем определить, что из двух значений одно больше, а другое меньше или они одинаковы

Разберем пример Программа: INPUT < 10 ÞРезультат: сообщение об ошибке 10 <= INPUT <

Разберем пример Программа: INPUT < 10 ÞРезультат: сообщение об ошибке 10 <= INPUT < 25 ÞРезультат: печать “Hello” 25 <= INPUT ÞРезультат: сообщение об ошибке Типы ошибок: ● Программа не принимает числовые значения как факт ○ ● Написали <= 25 вместо < 25 ○ ● Проверяется любым числом Определяется только на границе Опечатка: написали 52 вместо 25 ○ Определяется и на границе в том числе

Выводы: Типы ошибок: ● Программа не принимает числовые значения как факт ○ ● Написали

Выводы: Типы ошибок: ● Программа не принимает числовые значения как факт ○ ● Написали <= 25 вместо < 25 ○ ● Проверяется любым числом Определяется только на границе Опечатка: написали 52 вместо 25 ○ Определяется и на границе в том числе Граничное значение проверяет все 3 типа ошибок Значение не на границе проверяет только 1 тип ошибок

Анализ граничных значений (Boundary Value Testing) ● Идентифицировать граничные значения для каждого входного значения

Анализ граничных значений (Boundary Value Testing) ● Идентифицировать граничные значения для каждого входного значения (класса эквивалентности) ○ на границе ○ значение, меньшее граничного ( «у границы» ’below point’) ○ значение, большее граничного ( «за границей» ’above point’) Примеры: ➢ Область корректных значений: [-1. 0, 1. 0] -> тесты для -1. 0, -1. 001, 1. 001 ➢ Максимальная длина слова – 5 символов — > тесты для 4, 5, 6 ➢ Область выходных значений: минимум расхода 0. 00, максимум 2000 -> подбираем входные данные для того, чтобы получить на выходе 0. 00, 2000. 01, -0. 01

В задаче: INPUT < 10 10 <= INPUT < 25 25 <= INPUT Проецируем

В задаче: INPUT < 10 10 <= INPUT < 25 25 <= INPUT Проецируем на числовую ось: Результат: сообщение об ошибке Результат: печать “Hello” Результат: сообщение об ошибке

Граничные значения Для точки: Z -> Z-1, Z, Z+1 Для отрезка: [x, y] ->

Граничные значения Для точки: Z -> Z-1, Z, Z+1 Для отрезка: [x, y] -> x-1, x, y, y+1 А для такого интервала значений: (х, у) ?

Выбор значений ● ● Значение в пределах класса является лучшим представителем Граничные значения часто

Выбор значений ● ● Значение в пределах класса является лучшим представителем Граничные значения часто будут лучшими представителями Могут быть лучшие представители, которые не будут граничными значениями Могут быть выделены лучшие представители в классах, значения которых не будут очевидно сравнимы (больше-меньше)

Как тестируем? ● Классы эквивалентности: некорректные значения ○ Тестировать одно некорректное значение за раз

Как тестируем? ● Классы эквивалентности: некорректные значения ○ Тестировать одно некорректное значение за раз для того, чтобы проверить, что система идентифицирует его корректно. ● Классы эквивалентности: корректные значения ○ Как ?

Стратегии работы с новым кодом ТАБЛИЦЫ РЕШЕНИЙ (DECISION TABLE TESTING)

Стратегии работы с новым кодом ТАБЛИЦЫ РЕШЕНИЙ (DECISION TABLE TESTING)

Этапы построения таблицы 1. 2. 3. 4. 5. Определить/записать все условия Посчитать количество возможных

Этапы построения таблицы 1. 2. 3. 4. 5. Определить/записать все условия Посчитать количество возможных комбинаций условий Запомнить комбинации Записать действия Убрать лишние комбинации (схлопывание таблицы)

Пример: светофор (SQA DAYS 14 - ЕЛЕНА СТАШЕНКО)

Пример: светофор (SQA DAYS 14 — ЕЛЕНА СТАШЕНКО)

Автомобиль находится перед светофором, определить его дальнейшие действия Условия: ØГорит ли красный? Y N

Автомобиль находится перед светофором, определить его дальнейшие действия Условия: ØГорит ли красный? Y N ØГорит ли желтый? Y N ØГорит ли зеленый? Y N Количество комбинаций: Ø 2*2*2 = 8

1. Определить список возможных условий и их значения

1. Определить список возможных условий и их значения

2. Определить список всех возможных действий (ожидаемых результатов для условий)

2. Определить список всех возможных действий (ожидаемых результатов для условий)

3. Определить все значения для условий ( «да»  «нет» или более 2 х

3. Определить все значения для условий ( «да» «нет» или более 2 х значений) и их уникальные комбинации, которые приводят к выполнению ожидаемых результатов связанных с этим правилом

4. Создать тест кейс для каждого правила (столбца) – как минимум один, если условия

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

Дополнительные условия

Дополнительные условия

Убрать лишние комбинации

Убрать лишние комбинации

Убрать лишние комбинации

Убрать лишние комбинации

Стратегии работы с новым кодом ФУНКЦИОНАЛЬНЫЕ ДИАГРАММЫ (CAUSE-EFFECT GRAPHING)

Стратегии работы с новым кодом ФУНКЦИОНАЛЬНЫЕ ДИАГРАММЫ (CAUSE-EFFECT GRAPHING)

Что это и зачем? ● Предлагает способ перевода спецификаций, написанных на естественном языке, на

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

Алгоритм действий 1. Разбить внешние спецификации на отдельные функции, которые будут тестироваться (декомпозиция функциональных

Алгоритм действий 1. Разбить внешние спецификации на отдельные функции, которые будут тестироваться (декомпозиция функциональных требований) 2. Идентифицировать явные и неявные причины (условия на входе) и присвоить каждой из них уникальный номер 3. Идентифицировать явные и неявные эффекты (действия на выходе) и присвоить каждому из них уникальный номер 4. Перевести семантику спецификации в граф «причина-следствие» (Boolean cause-effect graphing) 5. Добавить информацию о невозможных комбинациях причинэффектов 6. Построить таблицу решений (бинарные значения) 7. Записать тест кейс для каждого столбца

Пример Requirements for Calculating Car Insurance Premiums: For females less than 65 years of

Пример Requirements for Calculating Car Insurance Premiums: For females less than 65 years of age, the premium is $500 For males less than 25 years of age, the premium is $3000 For males between 25 and 64 years of age, the premium is $1000 For anyone 65 years of age or more, the premium is $1500

Причины (Causes) – входные условия 1. Пол: мужской 2. Пол: женский 3. Возраст: <25

Причины (Causes) – входные условия 1. Пол: мужской 2. Пол: женский 3. Возраст: <25 4. Возраст: >=25 and < 65 5. Возраст: >= 65

Следствия (Effects) – выходные результаты 100. Премия = $1000 101. Премия = $3000 102.

Следствия (Effects) – выходные результаты 100. Премия = $1000 101. Премия = $3000 102. Премия = $1500 103. Премия = $500

Причина: 1. Пол: мужской and 3. Возраст: < 25 Следствие: 101: Премия = $3000

Причина: 1. Пол: мужской and 3. Возраст: < 25 Следствие: 101: Премия = $3000

Причина: 1. Пол: мужской and 4. Возраст: >=25 and < 65 Следствие: 100: Премия

Причина: 1. Пол: мужской and 4. Возраст: >=25 and < 65 Следствие: 100: Премия = $1000

Причина: 1. Пол: мужской and 5. Возраст: >= 65 or 2. Пол: женский and

Причина: 1. Пол: мужской and 5. Возраст: >= 65 or 2. Пол: женский and 5. Возраст: >= 65 Следствие: 102: Премия = $1500

Причина: 2. Пол: женский and 3. Возраст: < 25 or 2. Пол: женский and

Причина: 2. Пол: женский and 3. Возраст: < 25 or 2. Пол: женский and 4. Возраст: >=25 and < 65 Следствие: 103: Премия = $500

Причина: 1. Пол: мужской and 5. Возраст: >= 65 or 2. Пол: женский and

Причина: 1. Пол: мужской and 5. Возраст: >= 65 or 2. Пол: женский and 5. Возраст: >= 65 Следствие: 102: Премия = $1500

Преобразование в таблицу решений Test Cases 1 (мужской) 2 (женский) 3 (< 25) 4

Преобразование в таблицу решений Test Cases 1 (мужской) 2 (женский) 3 (< 25) 4 (>= 25 and < 65) 5 (>= 65) 1 1 0 0 2 1 0 0 1 0 3 1 0 0 0 1 4 0 1 0 0 1 5 0 1 1 0 0 6 0 1 0 100 (1000$) 101 (3000$) 102 (1500$) 103 (500$) 0 1 0 0 0 0 0 1

Особенности применения ф. диаграмм 1. Требуется трансляция спецификации в булевскую логическую сеть 2. Обнаружение

Особенности применения ф. диаграмм 1. Требуется трансляция спецификации в булевскую логическую сеть 2. Обнаружение неполноты и неоднозначности в исходных спецификациях 3. Применение функциональных диаграмм не обеспечивает построение всех полезных тестов, которые могут быть определены: a. Как пример: метод неадекватно исследует граничные условия 4. Лучше отделять анализ граничных значений от метода функциональных диаграмм (иначе граф существенно усложняется) 5. Наиболее трудным при реализации метода является преобразование диаграммы в таблицу решений

Стратегии работы с новым кодом ДРУГИЕ МЕТОДЫ

Стратегии работы с новым кодом ДРУГИЕ МЕТОДЫ

Метод предположение об ошибке (Error guessing) ● Этот метод в значительной степени является интуитивным

Метод предположение об ошибке (Error guessing) ● Этот метод в значительной степени является интуитивным ● Тест инженер использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку ● Перечислить в некотором списке возможные ошибки или ситуации, в которых они могут появиться, а затем на основе этого списка написать тесты

Requirements-Driven Testing Проверяем каждое требованиезапрос, которое описано или озвучено анализ требований: выявление неоднозначностей, неточностей,

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

Задания 1. Классы эквивалентности 2. Граничные значения 3. Таблица решений 4. Функциональные диаграммы

Задания 1. Классы эквивалентности 2. Граничные значения 3. Таблица решений 4. Функциональные диаграммы

1. Выполнить разбиение на классы эквивалентности 1. 1 Password – длина не меньше 8

1. Выполнить разбиение на классы эквивалентности 1. 1 Password – длина не меньше 8 символов, максимум 16. Может состоять из латинских букв и цифр, а также могут быть использованы символы только из списка «!» , «_» , «? » , «#» . При этом пароль должен обязательно содержать, как минимум, одну заглавную букву и одну цифру. 1. 2 Значение для ‘Product ID’ должно содержать 5 символов, первые два из них должны быть обозначениями из списка допустимых значений (A 1 or A 2 or B 1 or B 2), остальные три — уникальным числовым значением.

Определить граничные значения 2. 1 Корректные значения X - целые значения от -2 до

Определить граничные значения 2. 1 Корректные значения X — целые значения от -2 до 10 2. 2 Максимальное длина вводимого значения равна 20 символам

3. Составить таблицу решений 3. 1 Страховая компания предоставляет страховку клиентам, достигшим 18 -ти

3. Составить таблицу решений 3. 1 Страховая компания предоставляет страховку клиентам, достигшим 18 -ти летнего возраста. Если стаж водителя составляет от 2 -х до 6 -ти лет, предоставляется скидка 20%. Если стаж водителя более шести лет, скидка 30% 3. 2 Любому посетителю салона красоты «Жасмин» может быть присвоена одна из категорий: «Клиент» , «Клиент категории А» , «Клиент категории Б» , «Клиент категории С» в зависимости от количества посещение салона. Категория «Клиент» присваивается посетителю, на счету которого 3 посещения и более. Категория «Клиент категории А» присваивается посетителю, на счету которого 10 посещений и более. Категория «Клиент категории Б» присваивается посетителю, на счету которого 20 посещений и более. Категория «Клиент категории С» присваивается посетителю, на счету которого 30 посещений и более.

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

3. Составить таблицу решений 3. 2 Система скидок магазина Скидки предоставляются покупателям, которые приобрели накопительную карту магазина. Изначально карта имеет тип “Standard” c нулевым балансом. При покупке товара и предъявлении карты при оплате, сумма покупок зачисляется на баланс карты. Величина скидки зависит от общей суммы покупок на карте покупателя и от типа карты. Для карты тип “Standard” скидки составляют: ● 5%, если общая сумма покупок на карте от 20000 руб до 40000 руб включительно, ● 10%, если сумма на карте больше, чем 40000 руб. Магазин меняет карту типа “Standard” на карту типа “Silver Card”, если накопительная сумма покупателя на карте типа “Standard” становится равной или больше 50000 руб. Для карты тип “Silver Card” скидки составляют: ● 10%, если сумма на карте от 50000 руб до 70000 руб включительно, ● 20%, если сумма на карте больше, чем 70000 руб. Магазин меняет карту типа “Silver Card” на карту типа “Gold Card”, если накопительная сумма покупателя на карте типа “Silver Card” становится равной или больше 100000 руб. Для карты типа “Gold Card” скидки составляют: ● 20%, если сумма на карте от 100000 руб до 150000 руб включительно, ● 30%, если сумма на карте больше, чем 150000 руб. Магазин меняет карту типа “Gold Card” на карту типа “VIP Card”, если накопительная сумма покупателя на карте типа “Gold Card” становится равной или больше 200000 руб. Для карты типа “VIP Card” скидки составляют: 30%, если сумма на карте больше, чем 200000 руб

4. Применить метод функциональных диаграмм 4. 1 Для банкомата банка «ТТТ» реализовано ПО, которое

4. Применить метод функциональных диаграмм 4. 1 Для банкомата банка «ТТТ» реализовано ПО, которое автоматизирует такие функции как выдача денег, выдча справки о балансе (доступные средства на карте), выдача распечатки с 10 ю последними операциями по карте, оплата услуг по мобильной связи Проанализирйте спецификацию для функции «Обработка запроса на снятие суммы с карты» и примените метод функциональных диаграмм для создания тест кейсов. Разработать и описать тест-кейсы в матрице (xls-file). ● Спецификация для функции «Обработка запроса на снятие суммы с карты» : Если карта типа «кредитная» (K) или «дебетовая» (D), то банкомат выдает деньги клиенту при условии, что запрашиваемая сумма (X) не превышает сумму доступных средств на карте клиента (S). Если карта типа «кредитная» , то банкомат выдает деньги и в случае, если запрашиваемая сумма превышает сумму доступных средств на карте, но не выходит за рамки допустимого превышения кредита (L). В случае, если карта не является «кредитной» или «дебетовой» или же запрашиваемая сумма превышает сумму доступных средств на карте для дебетовой карты или же запрашиваемая сумма превышает сумму доступных средств на карте и выходит за рамки допустимого превышения кредита для кредитовой карты, тогда выдается сообщение о том, что деньги не могут быть выданы и деньги не выдаются.

Понравилась статья? Поделить с друзьями:
  • Предположение об ошибке черный ящик
  • Предположение о нормальном распределении случайной ошибки
  • Предположение мать всех ошибок кто сказал
  • Предполагает ли совершение врачебной ошибки причинение вреда пациенту
  • Предохранитель для сброса ошибок форд мондео 3