UML-моделирование для базового тестирования моделей
У меня есть несколько вопросов, касающихся моделирования моей проблемы. Я работаю над дипломным проектом по тестированию на основе моделей. Хотелось бы также узнать с экспертной точки зрения, правильно ли я отношусь к моделированию своего сценария. Я моделирую пользовательский интерфейс приложений Android, прохожу их, генерирую тестовые случаи и генерирую тестовые коды для фреймворка эспрессо.
Я бы в простоте объяснил способ моделирования тестируемой системы и генерации тестового кода для тестовых случаев. (Я пишу алгоритмы для генерации кода Android также). Я генерирую код для платформы тестирования эспрессо Android. Структура эспрессо всегда должна сначала найти элемент для взаимодействия. Это делается с помощью метода "OnView()", передающего в него такие параметры, как withId(R.id.title) или withText("Hello"), чтобы найти элемент с заданным Id или Text соответственно. Затем мы присоединяем то, что фреймворк называет ViewActions или ViewMatchers, для взаимодействия с элементами путем выполнения действий или выполнения утверждений соответственно. Ниже приведен пример теста-эспрессо, который находит текстовое представление с текстом "Lucky button", нажимает на него и проверяет, отображается ли оно.
@Test
public void test () {
onView(withText(“Lucky Button”)) //ViewMatcher
.perform(click()) // ViewAction .check(matches(isDisplayed())); // ViewAssertion
Простой случай Давайте возьмем приложение для Android с двумя экранами. Экран A и экран B. Каждый экран содержит различные элементы. Например, TextView(Textlabel), ImageView(метка изображения) и т. Д. Я использую диаграмму состояний для описания состояний, в которых может находиться экран. Для каждого состояния существует диаграмма действий, которая описывает тесты, которые должны быть выполнены на элементах, например TextView,ImageView. Мы группируем каждый набор тестов по дорожкам и представляем тестовые действия с активными действиями. Но есть входная информация, которая необходима. Например, действие Activity может быть вызвано isVisible для проверки видимости панели инструментов, которая находится в дорожке панели инструментов ToolBarDesign. Чтобы выполнить это действие, нам нужна информация на панели инструментов, чтобы сначала найти ее и проверить ее видимость. Я делаю это, предоставляя необходимую информацию о переходах действий или состояний. Ниже приведен пример диаграммы состояний и диаграммы действий, описывающих сценарий.
Эта диаграмма состояний имеет 2 состояния. А переход от MainActivity к NewNote - это триггер openNewNote с действием в формате свободного текста. Действие freetext содержит необходимую информацию, которую я обрабатываю и извлекаю в моей Java-среде для генерации фрагмента кода, подобного приведенному выше. Во фреймворке я сначала выбираю элемент с идентификатором title, а затем выполняю метод click. Также в состоянии MainActivity содержится диаграмма подзадач, как описано ранее. На этой подгруппе действий мы даем возможность моделирующему человеку (которого мы считаем человеком, обладающим знаниями о структуре эспрессо) написать действия для тестирования. Ниже приведен пример диаграммы активности для MainActivity, на которой тестируются панель инструментов приложения и экран входа в систему.
Панель инструментов переходит к действию isVisible с начального узла. На переходе мы сделаем описание, как объяснено выше, на переходе на диаграмме состояний. Здесь мы получаем действие freetext "withText:Lucky Button, соответствия,isDisplayed" и затем обрабатываем его в нашей среде для получения кода.
@Test
public void test () {
onView(withText(“Lucky Button”)) //ViewMatcher
.check(matches(isDisplayed())); // ViewAssertion
Вопросы. Пока это работает для команды, так как программисты - те, кто моделирует. Я предоставлю документацию для моделирования системы. Я хотел бы спросить, является ли это допустимым способом моделирования и может быть описано в моем исследовании. А также, если у вас есть какие-либо комментарии или предложения.
1 ответ
Не вдаваясь в глубокие детали, я бы рекомендовал вернуться на один шаг назад и начать шире:
- Определите более формально, что представляет собой тестируемая система (SUT) в вашем случае: входы, выходы, требования, соотносящие входы и выходы. Примерами могут быть конечный автомат, диаграмма действий и т. Д.
- Определите более формально то, что вам нравится моделировать: параллельную реализацию SUT, которая является вашей тестовой моделью (TM). Это обычно абстрактно и действительно только в некоторой ограниченной области поведения SUT. В вашем случае диаграммы последовательности и активности.
- Отношение соответствия: Каково формальное определение, что SUT соответствует TM? Как эти две модели SUT и TM сравниваются?
- Какова теория, которая может формально и автоматически доказать отношение соответствия? Это также дает ответ на инструменты, необходимые для автоматизации.
Лучший способ начать это упражнение на примерах:
- Разберитесь во всех демонстрационных примерах, по крайней мере, с помощью одного из крупных MBT-инструментов: Microsoft Spec Explorer, Conformiq Designer ...
- Пример вашего примера в одном из них примерно.
- Посмотрите, как они используют UML. Я рекомендую вам UML-расширение Spec Explorer, которое фокусируется на генерации входных данных и сценариях, а не на поведении - аналогично вашему приложению.
- Понимать теорию, лежащую в основе этих инструментов: символическое выполнение, чередование симуляций, сценарии и т. Д.
Если вы ответите на эти вопросы, у вас также будет ответ, если ваш подход верен или имеет какие-либо ошибки, на которые я не могу ответить из того, что вы представили.