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: Приоритезация тестовых наборов зависит от критичности функций, частоты их использования, важности для пользователя. Приоритезация позволяет значительно снизить объем набора регрессионных тестов.