Тестирование инф.систем. Ответы на вопросы к лекциям Понятие тестирования программного обеспечения

• Название: Ответы на вопросы к лекциям Понятие тестирования программного обеспечения
• Анкор: Тестирование инф.систем
• Дата: 14.11.2022
• Размер: 0.52 Mb.
• Имя файла: otvet na lec..docx
• Тип: Лекция; #786886
• страница: 13 из 15

Уровень модульного тестирования (Unit Test layer).

Под автоматизированными тестами на этом уровне понимаются модульные или компонентные тесты, которые чаще всего пишут разработчики программного продукта. Такие тесты позволяют начать тестирование на ранней стадии разработки проекта. Более того, разработчики используют их для проверки исправлений дефектов. Количество тестов на уровне модульного тестирования увеличивается за счет разработки новых модулей и тестов для них.

Уровень функционального тестирования (Functional Test Layer non-

UI).

Не всю бизнес логику приложения можно протестировать через слой GUI. Иногда бизнес-логика скрыта от пользователя, и это является особенностью реализации. Но тестирование бизнес-логики все равно необходимо. В таком случае для команды тестирования реализуется доступ напрямую к функциональному слою, что обеспечивает возможность тестировать бизнес-логику приложения, минуя пользовательский интерфейс.

Уровень тестирования через пользовательский интерфейс (GUI Test Layer).

На данном уровне есть возможность тестировать не только интерфейс пользователя, но также и функциональность, выполняя операции, которые вызывают бизнес-логику приложения. Такие тесты, как правило, более эффективны, чем тестирование функционального слоя напрямую, так как функциональность тестируется посредством эмуляции действий конечного пользователя через графический интерфейс.

Идеальной является ситуация, когда автоматизация тестирования выполнена на всех трех указанных выше уровнях.

15.Какие из инструментов, используемых для автоматизации тестирования, вам известны?

Оптимальность инструмента автоматизации определяется следующими ключевыми моментами:

1. 
   время, требуемое на поддержку скриптов. Если небольшой скрипт, который осуществляет нажатие на определенную кнопку, придется полностью переписать, в случае простого изменения целевой кнопки, то инструмент, вероятнее всего, не будет удобен. Необходимо подбирать такой инструмент, который позволяет выносить переменные в начало скриптов и при необходимости просто заменять их значения. Еще более удобным вариантом является возможность описать наборы кнопок, меню и прочие подобные элементы как отдельные классы;
   
2. 
   способность распознавать элементы управления в разрабатываемом приложении. Если большинство элементов не
   

распознается с помощью выбранного инструмента, то необходимо поискать специальные модули или плагины, которые обеспечат такую возможность. Если не удается отыскать что-либо подходящее, то придется отказаться от выбранного инструмента, т.к. он не обеспечит удобство написания автоматизированных тестов. Здесь хорошо работает правило: чем больше элементов управления способен распознать выбранный инструмент, тем меньше времени потребуется на создание и поддержание работоспособности автотестов;

3. 
   удобство написания новых тестов. Очень важно знать, имеется ли у инструмента возможность поддержки ООП, насколько удобно писать код, а также насколько он читаем. Важную роль играет удобство среды разработки и порог вхождения (насколько сложно новому специалисту по автоматизации освоить инструмент, если он никогда ранее с ним не работал).
   

16. 
    Что необходимо учитывать при выборе инструмента автоматизации тестирования?
    

Зачастую выбирают несколько инструментов для тестирования функций приложения. Существует большое количество всевозможных инструментов, поддерживающих различные языки и технологии разработки и позволяющих наиболее удобно осуществлять проверки тех или иных аспектов работы разрабатываемой системы.

16. 
    Важны ли особенности разрабатываемой системы при выборе инструмента автоматизации тестирования?
    

Оптимальность инструмента автоматизации определяется следующими ключевыми моментами:

4. 
   время, требуемое на поддержку скриптов. Если небольшой скрипт, который осуществляет нажатие на определенную кнопку, придется полностью переписать, в случае простого изменения целевой кнопки, то инструмент, вероятнее всего, не будет удобен. Необходимо подбирать такой инструмент, который позволяет выносить переменные в начало скриптов и при необходимости просто заменять их значения. Еще более удобным вариантом является возможность описать наборы кнопок, меню и прочие подобные элементы как отдельные классы;
   
5. 
   способность распознавать элементы управления в разрабатываемом приложении. Если большинство элементов не
   

распознается с помощью выбранного инструмента, то необходимо поискать специальные модули или плагины, которые обеспечат такую возможность. Если не удается отыскать что-либо подходящее, то придется отказаться от выбранного инструмента, т.к. он не обеспечит удобство написания автоматизированных тестов. Здесь хорошо работает правило: чем больше элементов управления способен распознать выбранный инструмент, тем меньше времени потребуется на создание и поддержание работоспособности автотестов;

6. 
   удобство написания новых тестов. Очень важно знать, имеется ли у инструмента возможность поддержки ООП, насколько удобно писать код, а также насколько он читаем. Важную роль играет удобство среды разработки и порог вхождения (насколько сложно новому специалисту по автоматизации освоить инструмент, если он никогда ранее с ним не работал).
   

16. 
    Можно ли обойтись только автоматизированным тестированием?
    

Наиболее часто в современной автоматизации тестирования используют Java-библиотеки для автоматизации тестирования (java-based test tools and libraries). Существует большое количество таких библиотек. В таблице 10 описаны наиболее известные из них.

Таблица 10 – Java-based test tools and libraries

Инструмент	Описание
Selenium	Selenium представляет собой набор различных программных инструментов, каждый из которых использует различный подход к поддержке автоматизации тестирования web-приложений на многих платформах.
Watij	Watij (произносится как «wattage») предназначается для тестирования web-приложений на Java. Это чистый Java API, созданные, чтобы обеспечить автоматизацию тестирования web-приложений с помощью реального браузера.
HtmlUnit	HtmlUnit – это «браузер» для программ на Java. Он моделирует HTML- документы и предоставляет API, что позволяет ссылаться на страниц, заполнять формы, кликать на ссылки и т.д. Имеется достаточно хорошая поддержка JavaScript, которая постоянно улучшается. Также он способен работать даже с достаточно сложными AJAX- библиотеками, эмулировать Firefox или Internet Explorer в зависимости от используемой конфигурации. Данный инструмент обычно используется для целей тестирования или для извлечения информации с web-сайтов. HtmlUnit не является инструментом unit-тестирования. Он лишь позволяет имитировать браузер и предназначен для использования с другими тестовыми фреймворками, например, такими, как JUnit или TestNG.

HttpUnit	Написан на Java и эмулирует определенные особенности поведения браузера, включая работу с формами, JavaScript, простую http- аутентификацию, файлы cookies и автоматический редирект на страницы. Позволяет рассматривать полученные страницы как текст, XML DOM, контейнеры форм, ссылок и таблиц. При использовании совместно с Junit довольно просто написать тесты, которые очень быстро проверят работоспособность web-сайта.
Jamaleon	Jameleon - это автоматизированная среда тестирования, которая может быть использована как техническими, так и нетехническими специалистами. Одна из основных особенностей – создание группы ключевых слов и тегов, которые представляют различные экраны приложения. Вся логика, которую необходимо автоматизировать для каждого конкретного экрана, может быть определена на Java и сопоставлена с этими ключевыми словами. Ключевые слова затем могут быть организованы вместе с разными наборами данных, чтобы сформировать тестовые скрипты без необходимости глубоко понимать, как работает приложение. Тест-скрипты затем используются для автоматизации тестирования и генерации тестовой документации.
JUnit	Junit – это простая основа для написания повторяемых тестов. Это пример архитектуры xUnit для модульного тестирования.
Abbot	Abbot – это простой фреймворк для модульного и функционального тестирования графических пользовательских интерфейсов на Java. Он облегчает генерацию действий пользователя и исследование состояний компонентов. Имеется поддержка записи и воспроизведения для любого Java-приложения.
Marathon	Marathon позволяет захватывать взаимодействия пользователя с приложениями, а также добавлять проверки, что выполняется корректное действие. Сгенерированный скрипт может быть подвержен рефакторингу (изменение с целью оптимизации). Можно прогонять сценарии вручную или интегрировать Marathon в процесс сборки для автоматического выполнения тестовых наборов.

Кроме представленных Java-фреймворков, существует огромное количество фреймворков и инструментов, ориентированных на другие языки

программирования, такие как: php, ruby, javascript, C#, javascript, python, perl и др.
19.Приведите пример предусловия к тесту.

20. 
    Приведите пример шагов теста.
    

20. 
    Почему важно привести систему к пригодному для тестирования состоянию как до, так и после выполнения теста?
    

20. 
    Какую дополнительную библиотеку обычно создают для автотестов?
    

20. 
    Можно ли совмещать негативные и позитивные проверки в рамках
    

одного теста?
24.Почему один тест должен подразумевать одну проверку?

25.Почему один шаг теста не должен содержать несколько действий?