понедельник, 27 января 2014 г.

Ещё раз об "уровнях тестирования"

Я немного писал тут - http://18delphi.blogspot.ru/2013/11/gui_9423.html

Разовью тему.

Многие говорят "ах надо тестировать". (Ещё больше людей говорит конечно - "тестировать незачем" :-) Но этот пост не для них)

Зададимся вопросом - "а что именно тестировать"?

Попробую выделить "слои тестирования" и "подходящие инструменты".

Варианты следующие:

1. Тестируем "базовые классы" и "структуры данных". Тут для использования подходит "голый DUnit" (http://dunit.sourceforge.net/) и  "атомарные тесты" - http://18delphi.blogspot.ru/2013/04/blog-post_2326.html и http://programmingmindstream.blogspot.ru/2013/11/tdd_28.html. Не забываем про "пред- и пост-условия".

2. Тестировать надо классы с "параметризованным входом" (входные mock'и). Тут подходит вот какая надстройка над DUnit - http://18delphi.blogspot.ru/2013/04/blog-post_7108.html, а также - "использование эталонов" - http://18delphi.blogspot.ru/2013/04/blog-post_8791.html

3. Тестировать надо "пользовательские истории" ("базовых классов"). Тут подходит вот что - http://roman.yankovsky.me/?p=1355. Может быть также можно тестировать и "прецеденты приложения", но Роман эту тему пока не развил.

4. Тестировать надо "отдельностоящие компоненты". Тут подходит вот что - http://programmingmindstream.blogspot.ru/2014/01/openctf-component-test-framework.html

5. Тестировать надо "прецеденты приложения". Тут подходит вот что - http://18delphi.blogspot.ru/2013/11/gui.html и http://18delphi.blogspot.ru/2013/11/gui-back-to-basics_22.html и http://18delphi.blogspot.ru/2013/11/gui-dunit.html

6. Тестировать надо GUI-приложение как "чёрный" ("серый") ящик ("Честное" нажимание на "кнопки"). Тут подходит - TestComplete (http://smartbear.com/products/qa-tools/automated-testing-tools/). Ну и не забываем про - http://programmingmindstream.blogspot.ru/2014/01/blog-post_626.html (там про "серый ящик" в частности написано).

7. Тестировать надо GUI-приложение как "реальный пользователь" ("автоматам" мы не доверяем). Что тут? Тут - РУЧНОЕ ТЕСТИРОВАНИЕ. "Никаких инструментов"... Единственный инструмент это что-то вроде RequisitePro (http://www-03.ibm.com/software/products/ru/reqpro/) и написание HLTC (www.qualitytesting.info/forum/topics/low-and-high-level-test-cases?commentId=2064344%3AComment%3A427950&xg_source=activity http://pic.dhe.ibm.com/infocenter/rqmhelp/v2r0/index.jsp?topic=/com.ibm.rational.test.qm.doc/topics/c_testcases.html http://www.sqaforums.com/showflat.php?Number=663587) для "живых тестеров".

Вот как-то так...

Развить тему?

P.S. Что ещё хочу сказать?

ПРЕДПОЧТИТЕЛЬНОСТЬ тестов возрастает при движении от 7-го пункта к 1-му.

Почему?

Потому что СЛОЖНОСТЬ тестов возрастает в ОБРАТНОМ порядке - при движении от 1-го пункта к 7-му.

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

Есть ОДНО (очень важное) ИСКЛЮЧЕНИЕ - если "подобный тест" УЖЕ НАПИСАН. Тогда - уровень теста - НЕ ВАЖЕН. Надо взять УЖЕ СУЩЕСТВУЮЩИЙ тест и попытаться АДАПТИРОВАТЬ его к "новому тестируемому случаю".

Комментариев нет:

Отправить комментарий