
- •1. Принципы организации тестового кода с использованием каркаса nUnitForms
- •2. Принципы организации тестового кода с использованием каркаса fest.
- •3. Понятие регрессионного тестирования
- •4. Интеграционное тестирование. Уровни, стратегии, их достоинства и недостатки
- •5. Принципы использования каркаса fitness
- •6. Основные принципы стратегии «Чистой комнаты»
- •7. Основные принципы подхода непрерывной интеграции
- •8. Этапы цикла построения по на примере Hudson
1. Принципы организации тестового кода с использованием каркаса nUnitForms
Принципы организации: 1) Подключение библиотек (using NUnit.Framework; using NUnit.Extensions.Forms;), 2) Перед объявлением класса употребляется специальная аннотация ([FrameFixture]), 3) Специальная аннотация для тестов ([Test]) 4) Специальные классы (ButtonTester buttonTest = new ButtonTester("button1"); TextBoxTester tbt = new TextBoxTester("textBox1");), 5) Проверка значений происходит средствами NUNIT (Assert.AreEqual(tbt["Text"], "pressCheckBox"); Assert.AreNotEqual; Assert.IsEmpty, Assert.IsFalse…), 6) Порядок написания тестов: Объявление формы -> Открытие -> Манипуляции над формой средствами GUI и проверка значений -> Закрытие формы (Form1 form = new Form1(); form.Show(); ButtonTester buttonTest = new ButtonTester("button1"); buttonTest.Click(); TextBoxTester tbt = new TextBoxTester("textBox1"); Assert.AreEqual(tbt["Text"], "pressButton"); form.Close();).
2. Принципы организации тестового кода с использованием каркаса fest.
Принципы организации: 1) Подключение библиотек (import org.fest.swing.annotation.GUITest; import org.fest.swing.fixture.FrameFixture; import org.fest.swing.junit.v4_5.runner.GUITestRunner;), 2) Перед объявлением класса употребляется специальная аннотация (@RunWith(GUITestRunner.class) public class MainFormTest {…), 3) Объявление Frame фикстуры (private FrameFixture frameFixture;), 4) Привзяка к нужной форме в @Before (@Before public void setUp() { frameFixture = new FrameFixture(new MainForm("Main form")); frameFixture.show();};), 5) Специальные аннотации для тестов (@GUITest @Test) 6) Команды-манипуляторы (frameFixture.radioButton("RB1").click();), 7) Специальные средства для тестирования (frameFixture.textBox("TB").requireText("Текст"); requireEmpty, requireVisible, requireFocused, requireItemsCount(2)), 8) Очистка Frame фикстуры в @After (@After public void tearDown() { frameFixture.cleanUp();}) 9) Возможность совмещать GUI тестирование с UNIT.
3. Понятие регрессионного тестирования
Р
егрессионное
тестирование
обычно выполняется после Smoke-теста,
т.е. после того, как система непрерывной
интеграции выполнит сборку проекта и
тест «здоровья» билда. Smoke
testing
означает обобщенный метод тестирования
путем запуска и оценки общих изменений
и результатов без погружения в детали.
Назначение
регрессионного тестирования –
подтвердить, что последние изменения
кода не повлияли на существующую
функциональность. Регрессионные тесты
– это не новые тесты, это полный или
частичный набор уже существующих и
ранее запускавшихся тестов. Такое
тестирование подтверждает, что старый
код с новыми изменениями продолжает
работать. Регрессионные
тесты требуются,
когда: 1)
Изменились требования и код приведен
в соответствие с новыми требованиями,
2)
Добавлены новые возможности в продукт,
3)
Выполнен фиксинг функциональных
дефектов, 4)
Выполнен фиксинг дефектов производительности
и т.д. (Рис. Структура регр. тестирования)
Retset
All -
один из методов для регрессионного
теста, при котором весь пакет существующих
тестов перезапускается повторно. Это
очень дорого, т.к. Требует много времени
и ресурсов. Regression
Test Selection
- Альтернативный
вариант
– выбор группы тестов для повторного
выполнения Такие тесты делятся на две
категории: 1)
Reusable Test Cases, 2)
Obsolete Test Cases. Prioritization
of Test Cases:
Приоритезация тестовых наборов зависит
от критичности функций, частоты их
использования, важности для пользователя.
Приоритезация позволяет значительно
снизить объем набора регрессионных
тестов.