Я немного писал тут - 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-му.
Посему (при прочих равных), надо попытаться для начала написать тест "более низкого уровня", а потом (если "не получается") - повышать уровень.
Есть ОДНО (очень важное) ИСКЛЮЧЕНИЕ - если "подобный тест" УЖЕ НАПИСАН. Тогда - уровень теста - НЕ ВАЖЕН. Надо взять УЖЕ СУЩЕСТВУЮЩИЙ тест и попытаться АДАПТИРОВАТЬ его к "новому тестируемому случаю".
Разовью тему.
Многие говорят "ах надо тестировать". (Ещё больше людей говорит конечно - "тестировать незачем" :-) Но этот пост не для них)
Зададимся вопросом - "а что именно тестировать"?
Попробую выделить "слои тестирования" и "подходящие инструменты".
Варианты следующие:
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-му.
Посему (при прочих равных), надо попытаться для начала написать тест "более низкого уровня", а потом (если "не получается") - повышать уровень.
Есть ОДНО (очень важное) ИСКЛЮЧЕНИЕ - если "подобный тест" УЖЕ НАПИСАН. Тогда - уровень теста - НЕ ВАЖЕН. Надо взять УЖЕ СУЩЕСТВУЮЩИЙ тест и попытаться АДАПТИРОВАТЬ его к "новому тестируемому случаю".
Комментариев нет:
Отправить комментарий