Тестирование программного обеспечения (Software Testing) - проверка соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов, выбранном определенным образом. [IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004] В более широком смысле, тестирование - это одна из техник контроля качества, включающая в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis).
Верификация (Verification) - это процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа [IEEE]. Т.е. выполняются ли наши цели, сроки, задачи по разработке проекта, определенные в начале текущей фазы.
Валидация (Validation) - это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе [BS7925-1].
План Тестирования (Test Plan) - это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.
Тест дизайн (Test Design) - это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест кейсы), в соответствии с определёнными ранее критериями качества и целями тестирования.
Тестовый случай (Test Case) - это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Баг/Дефект Репорт (Bug Report) - это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.
Тестовое Покрытие (Test Coverage) - это одна из метрик оценки качества тестирования, представляющая из себя плотность покрытия тестами требований либо исполняемого кода.
Детализация Тест Кейсов (Test Case Specification) - это уровень детализации описания тестовых шагов и требуемого результата, при котором обеспечивается разумное соотношение времени прохождения к тестовому покрытию
Время Прохождения Тест Кейса (Test Case Pass Time) - это время от начала прохождения шагов тест кейса до получения результата теста.
Цели тестирования:
* Обнаружение дефектов
* Повышение уверенности в уровне качества
* Предоставление информации для принятия решений
* Предотвращение дефектов
Принципы тестирования:
* Тестирование показывает наличие дефектов
Тестирование может показать наличие дефектов в программе, но не доказать их отсутствие. Тем не менее, важно составлять тест-кейсы, которые будут находить как можно больше багов. Таким образом, при должном тестовом покрытии, тестирование позволяет снизить вероятность наличия дефектов в программном обеспечении. В то же время, даже если дефекты не были найдены в процессе тестирования, нельзя утверждать, что их нет.
Невозможно провести исчерпывающее тестирование, которое бы покрывало все комбинации пользовательского ввода и состояний системы, за исключениям совсем уж примитивных случаев. Вместо этого необходимо использовать анализ рисков и расстановку приоритетов, что позволит более эффективно распределять усилия по обеспечению качества ПО.
Тестирование должно начинаться как можно раньше в жизненном цикле разработки программного обеспечения, и его усилия должны быть сконцентрированы на определенных целях.
Разные модули системы могут содержать разное количество дефектов – то есть, плотность скопления дефектов в разных элементах программы может отличаться. Усилия по тестированию должны распределяться пропорционально фактической плотности дефектов. В основном, большую часть критических дефектов находят в ограниченном количестве модулей. Это проявление принципа Парето: 80% проблем содержатся в 20% модулей.
Прогоняя одни и те же тесты вновь и вновь, Вы столкнетесь с тем, что они находят все меньше новых ошибок. Поскольку система эволюционирует, многие из ранее найденных дефектов исправляют и старые тест-кейсы больше не срабатывают.
Чтобы преодолеть этот парадокс, необходимо периодически вносить изменения в используемые наборы тестов, рецензировать и корректировать их с тем, чтобы они отвечали новому состоянию системы и позволяли находить как можно большее количество дефектов.
Выбор методологии, техники и типа тестирования будет напрямую зависеть от природы самой программы. Например, программное обеспечение для медицинских нужд требует гораздо более строгой и тщательной проверки, чем, скажем, компьютерная игра. Из тех же соображений, сайт с большой посещаемостью должен пройти через серьезное тестирование производительности, чтобы показать возможность работы в условиях высокой нагрузки.
Тот факт, что тестирование не обнаружило дефектов, еще не значит, что программа готова к релизу. Нахождение и исправление дефектов будут не важны, если система окажется неудобной в использовании, и не будет удовлетворять ожиданиям и потребностям пользователя.
Увеличение приемлемого уровня пользовательского доверия в том, что программа функционирует корректно во всех необходимых обстоятельствах.
* Корректное поведение; определяется из требований к продукту.
* Уровень доверия; наглядность, уровень остаточного обнаружения дефектов, требования к надёжности, что бы это всё ни значило.
* Необходимые обстоятельства - требование реального окружения; реалистичная среда тестирования (схожие наборы данных и т.п.).
Целью мониторинга тестирования является предоставление результата и обзора процесса тестирования. Информация отслежи вается вручную или автоматически и может быть использована для измерения критериев выхода, таких как покрытие. Метрики также могут быть использованы для оценки прогресса тестирования по сравнению с запланированным расписанием и бюджетом.
Контроль тестирования описывает любые направляющие или корректирующие действия, принятые как результат по полученной и собранной информаци и и значениям метрик. Контроль тестирования может затрагивать любые действия по тестированию, а так же воздействовать на другие действия и задачи жизненного цикла ПО.
Тестовый случай (Test Case) - это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Под тест кейсом понимается структура вида: Action > Expected Result > Test Result
Тестовый сценарий - последовательность тестовых случаев; состоит из набора входных значений, предусловий выполнения, ожидаемых результатов и постусловий, определяемых для покрытия определенных тестовых условий ( или тестового условия) или целей (цели) тестирования.
Тестовое Покрытие - это одна из метрик оценки качества тестирования, представляющая из себя плотность покрытия тестами требований либо исполняемого кода.
Тестовое Покрытие - это одна из метрик оценки качества тестирования, представляющая из себя плотность покрытия тестами требований либо исполняемого кода.
Полное покрытие невозможно. Для обеспечения более менее выского уровня используются:
* Эквивалентные разбиения * Таблицы решений * Таблицы переходов * Сценарии использования.
Автоматизированное тестирование (scripted testing): Выполнение тестов , реализуемое при помощи заранее записанной последовательности тестов.
Регрессионное тестирование (regression testing): Тестирование уже протестированной программы , проводящееся после модификации для уверенности в том , что процесс модификации не внес или не активизировал ошибки в областях , не подвергавшихся изменениям . Проводится после изменений в коде программного продукта или его окружения .
Интеграционное тестирование (integration testing): Тестирование , выполняемое для обнаружения дефектов в интерфейсах и во взаимодействии между интегрированными компонентами или системами .
Стратегии интеграции:
* Top-down
Вначале тестируются все высокоуровневые модули, и постепенно один за другим добавляются низкоуровневые. Все модули более низкого уровня симулируются заглушками с аналогичной функциональностью, затем по мере готовности они заменяются реальными активными компонентами.
* Bottom-up
Все низкоуровневые модули, процедуры или функции собираются воедино и затем тестируются. После чего собирается следующий уровень модулей для проведения интеграционного тестирования. Данный подход считается полезным, если все или практически все модули, разрабатываемого уровня, готовы. Также данный подход помогает определить по результатам тестирования уровень готовности приложения
* End-to-end
Еnd-to-end сценарий проверяет совокупность действий. Например, пользователь заходит на почтовый сайт, листает письма, просматривает новые, пишет и отправляет письмо, выходит с сайта. Такие сценарии могут быть очень сложными и иметь множество вариаций, поэтому данный вид тестирования выполняется обычно в самом конце и считается очень дорогим.
* Backbone Ромашка
* Big-bang
Все или практически все разработанные модули собираются вместе в виде законченной системы или ее основной части, и затем проводится интеграционное тестирование. Такой подход очень хорош для сохранения времени. Однако если тест кейсы и их результаты записаны не верно, то сам процесс интеграции сильно осложнится, что станет преградой для команды тестирования при достижении основной цели интеграционного тестирования
Системное тестирование (system testing): Процесс тестирования системы в целом с целью проверки того , что она соответствует установленным требованиям .
Нефункциональное тестирование.
CARAT -- подход к нагрузочному тестированию.
Приёмочное тестирование -- формальный процесс тестирования, который проверяет соответствие системы требованиям и проводится с целью:определения удовлетворяет ли система приемочным критериям; вынесения решения заказчиком или другим уполномоченным лицом принимается приложение или нет.
Альфа-тестирование — имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком.
Бета-тестирование — в некоторых случаях выполняется распространение предварительной версии (в случае проприетарного программного обеспечения иногда с ограничениями по функциональности или времени работы) для некоторой большей группы лиц с тем, чтобы убедиться, что продукт содержит достаточно мало ошибок. Иногда бета-тестирование выполняется для того, чтобы получить обратную связь о продукте от его будущих пользователей.
СТ -- анализ артефактов разработки программного обеспечения, таких как требования или программный код, проводимый без исполнения этих программных артефактов. В процессе статического тестирования, программные продукты рассматриваются оцениваются вручную, проводятся ревью или с помощью набора инструментов, сам код при этом не запускается. Проводится перед динамическим тестированием и соответственно ошибки найденные на этом этапе обходятся нам дешевле
Рецензирование (Review) -- оценка состояния продукта или проекта с целью установления расхождений с запланированными результатами и для выдвижения предложений по совершенствованию. Является одним из способов тестирования программных продуктов (в том числе кода).
Технический анализ -- проверка продукта на соответствие и практическую пригодность
Сквозной контроль ( walkthrough ) представляет собой один из видов формального пересмотра артефактов методом “мозгового штурма”, который может проводиться на любом этапе разработки. Это дружественная встреча разработчиков, тщательно спланированная, с ясно определенными целями, повесткой дня, продолжительностью и составом участников.
Инспекция ПО - это статическая проверка соответствия программы заданным спецификациями, проводится путем анализа различных представлений результатов проектирования (документации, требований, спецификаций, схем или исходного кода программ) на процессах ЖЦ.
Четко определенные шаги:
* Вход
* Планирование
* Обзор
* [Подготовка
* Обсуждение
* Переработка
* Выработка рекомендаций (follow up)]
* Выход
Программный анализ кода.
Tаблица решений (decision table): Таблица , отражающая комбинации входных данных и / или причин с соответствующими выходными данными и / или действиям ( следствиям ), которая может быть использована для проектирования тестовых сценариев .
Таблица состояний (state table): Таблица , показывающая конечные переходы для каждого состояния вследствие каждого возможного события , как для корректных , так и для некорректных переходов .
Анализ возможных сценариев и их тестирование.
assertEquals
assertTrue
@Test
@Before
@After
@Ignore
@Test: timeout, expected=exception
@RunWith: value=class -- определяет класс для запусков тестов; наследуются от Runner. @Parameters -- испольуется вместе c @RunWith(value=Parameterized.class) для задания параметров для тестов.
@RunWith(Parameterized.class)
public class FibonacciTest {
@Parameters
public static Collection<Object[]> data() {
return Arrays.asList(new Object[][] {
{ 0, 0 }, { 1, 1 }, { 2, 1 }, { 3, 2 }, { 4, 3 }, { 5, 5 }, { 6, 8 }
});
}
@Parameter // first data value (0) is default
public /* NOT private */ int fInput;
@Parameter(1)
public /* NOT private */ int fExpected;
@Test
public void test() {
assertEquals(fExpected, Fibonacci.compute(fInput));
}
}
Что это значит?
Метод черного и белого ящиков, таблицы. графы и прочее.
Что вы от нас хотите?
[ Firefox ] --- [ Selenium IDE ] --- import -+
|
[ Chrom ] ----+ [ Selenium Server ]
| |
[ Other web ] -+ |
| +------------------>[ Selenium WebDriver ]
+----------------------------^
Selenium IDE -- расширение браузера Firefox, которое позволяет записывать и воспроизводить действия пользователя в браузере.
Selenium WebDriver -- набор библиотек для различных языков программирования, позволяющих управлять браузером из программы, написанной на этом языке программирования.
Selenium Server -- может принимать команды с удалённой машины, где работает сценарий автоматизации, и исполнять их в браузере.
Selenium Grid -- несколько серверов Selenium могут образовывать распределённую сеть, которая называется Selenium Grid, что позволяет легко масштабировать стенд автоматизации.
Selenium RC -- прошлая версия WebDriver'а.
Xpath отпределяет путь в дереве XML структуры.
/ -- разделитель пути; первый элемент определяет путь от корня (/div -- множество div'ов на первом уровне от корня).
// -- определяет относительный путь (//div -- все div'ы в документе).
[] -- определяет предикат выборки, внутри можно использовать пути, функции и прочее.
| -- union множеств элементов, возвращённых Xpath (/div | //span)
Оси — это база языка XPath. Для некоторых осей существуют сокращённые обозначения.
* ancestor:: — Возвращает множество предков.
* ancestor-or-self::
* child:: — Возвращает множество потомков на один уровень ниже. Это название сокращается полностью, то есть его можно вовсе опускать.
* descendant:: — Возвращает полное множество потомков (то есть, как ближайших потомков, так и всех их потомков).
* parent:: — Возвращает предка на один уровень назад. Это обращение можно заменить на «..»
Строковые:
* string string(object?)
Возвращает текстовое содержимое элемента. По сути возвращает объединенное множество текстовых элементов на один уровень ниже. * string concat(string, string, string)
Объединяет две или более строк * number string-length(string?)
Возвращает длину строки. * boolean contains(string, string)
Возвращает истину, если первая строка содержит вторую, иначе возвращает ложь. * string substring(string, number, number?)
Возвращает строку вырезанную из строки начиная с указанного номера, и если указан второй номер — количество символов. * string substring-before(string, string)
Если найдена вторая строка в первой, возвращает строку до первого вхождения второй строки. * string substring-after(string, string)
Если найдена вторая строка в первой, возвращает строку после первого вхождения второй строки. * boolean starts-with(string, string)
Возвращает истину если вторая строка входит в начало первой, иначе возвращает ложь. * boolean ends-with(string, string)
Возвращает истину если вторая строка входит в конец первой, иначе возвращает ложь.
Логические: <, >, =, or, and, true(), false(), not(bool), boolean(object).
Числовые: +, -, *, div, mod, floor() и т.п.
Тестовый план:
● Thread Group
– Описывает пул пользователей для выполнения теста
– Количество, возрастание и пр..
● Семплеры
– Формируют запросы, генерируют результаты
– Большой набор встроенных протоколов (TCP, HTTP, FTP, JDBC, SOAP, JMS, SMTP, …..)
● Логические контроллеры
– Определяют порядок вызова семплеров
– Конструкции управления (if, loop, …)
– Управление потоком
● Слушатели
– Получают ответы
– Осуществляют доп. операции с результатами: просмотр, запись, чтение и др.
– Не обрабатывают данные! (в командной строке, нужен GUI)
● Таймеры
– Задержки между запросами
– Постоянные, в соответствии с законами
● Аssertion
– Проверяют результаты
● Элементы конфигурации
– Сохраняют предустановленные значения для семплеров
● Препроцессоры
– Изменяют семплеры в их контексте (HTML Link Parser)
● Постпроцессоры
– Применяются ко всем семплерам в одном контексте
Пордок выполнения.
* Конфигурационные элементы
* Препроцессоры (Pre-Processors)
* Таймеры (Timers)
* Семплеры (Sampler)
* Постпроцессоры (Post-Processors)
* Assertions
* Слушатели (Listeners)