Добавлен: 07.11.2023
Просмотров: 84
Скачиваний: 5
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
-
Тестирование методом «серого ящика»
При тестировании методом «серого ящика» разработчик теста имеет доступ к исходному коду, но при непосредственном выполнении тестов доступ к коду, как правило, не требуется. Тестирование проводится так же, как и в методе «черного ящика», однако для построения тестов используются знания о внутреннем устройстве программы.
-
-
Автоматизированное и ручное тестирование
-
Автоматизированное тестирование
Автоматизированное тестирование использует программные средства для выполнения тестов и проверки корректности результатов выполнения, что упрощает тестирование и сокращает его длительность. Главное преимущество автоматизированного тестирования состоит в возможности повторного прогона тестов без участия человека.
Традиционный и наиболее популярный среди разработчиков способ состоит в организации автоматизации тестирования на уровне кода. Данный подход будет подробно рассмотрен при описании модульного тестирования. Автоматизированное тестирование на уровне кода часто критикуют за невозможность тестирования пользовательского интерфейса программы. Однако сторонники TDD показали, что при правильном использовании паттернов семейства MVC (Model-View-Controller) возможно организовать программную имитацию действий пользователя без использования GUI (Graphical User Interface). Этот подход позволяет организовать тестирование обработчиков действий пользователя, оставляя не покрытой тестами лишь часть, относящуюся к непосредственному отображению данных.
Второй способ автоматизации тестирования состоит в имитации действий пользователя с использованием специальных инструментальных средств (GUI-тестирование). Данный вид тестирования относится к тестированию методом «черного ящика».
Существуют четыре поколения инструментов и техник, предназначенных для организации GUI-тестирования.
-
Утилиты записи и воспроизведения (capture/playback tools) записывают действия во время ручного тестирования. В дальнейшем они позволяют воспроизвести ранее записанные действия без участия человека, значительно увеличивая продуктивность и устраняя повторение однообразных действий. Основным недостатком инструментальных средств данного поколения является то, что любое изменение расположения визуальных элементов программы приводит к необходимости повторной записи ручных тестов. -
Сценарий (scripting) - форма автоматизации тестирования с использованием специализированных скриптовых языков. Язык должен поддерживать эмуляцию действий пользователя и получение результатов действий. Разработкой тестов занимаются программисты, работающие отдельно от тестировщиков, непосредственно запускающие те6сты. Изменения в тестируемом ПО требуют внесения исправлений и в соответствующих скриптах. -
Data-driven testing - методология автоматизации тестирования, основанная на использовании в скриптах параметров выполнения тестов. Параметры, задающие логику работы тестов (например, входные значения и ожидаемые результаты), находятся в некотором внешнем хранилище. Подобный подход позволяет организовать выполнение сценариев с различными наборами входных параметров и повысить гибкость тестирования. -
При использовании keyword-based testing создается специализированный словарь ключевых слов, описывающих системные события (например, «Logon User»). С каждым ключевым словом связаны необходимые параметры (например: «UserID», «Password») и ожидаемые результаты. Для каждого ключевого слова должно быть задано описание. Данный подход позволяет писать функциональные тесты практически на естественном языке, не требуя от тестировщика навыков программирования.
Автоматизированные тесты, как правило, являются регрессионными (от лат. Regression - движение назад), т.е. направленными на обнаружение ошибок в уже протестированных участках исходного кода при внесении изменений.
Одной из главных проблем автоматизированного тестирования является его трудоемкость: несмотря на то, что оно позволяет устранить часть рутинных операций и ускорить выполнение тестов, большие ресурсы могут тратиться на обновление самих тестов. Тем не менее подобные инвестиции в большинстве случаев оправданны, так как ручное тестирование требует гораздо больше ресурсов.
-
Ручное тестирование
Ручное тестирование – это процесс поиска дефектов в работе программы, когда тестировщик проверяет работоспособность всех компонентов программы, как если бы он был пользователем. Часто, для точности проверки, тестировщик использует заранее заготовленный план тестирования, в котором отмечены наиболее важные аспекты работы программы.
Ручное тестирование – это ключевой этап разработки программного обеспечения. Тестер может не придерживаться строго плану тестирования, а отклоняться от него для более полного тестирования, приближенного к использованию программы обычным пользователем.
Крупные проекты придерживаются строгой методологии тестирования в целях выявления максимального количества дефектов. Системный подход к тестированию включает в себя несколько этапов:
1. Выбор методологии тестирования, приобретение необходимого оборудования (компьютеры, программное обеспечение), принятие людей на должность тестеров;
2. Составление тестов с описанием выполнения и ожидаемым результатом;
3. Передача наборов тестов тестерам, которые вручную выполняют тесты и записывают результаты;
4. Передача результатов тестов разработчикам в подробном докладе с описанием всех выявленных проблем для обсуждения и исправления дефектов.
Для тестирования могут быть использованы статический и динамический подходы. Динамические подход включает в себя запуск программного обеспечения. Статистическое тестирование включает в себя проверку синтаксис и другие особенности кода программы.
Тестирование может быть функциональным и не функциональным. Функциональное тестирование - это проверка рабочей области программного обеспечения. Не функциональное тестирование - проверка производительности, совместимости и безопасности тестируемой системы.
Ручное тестирование может применяться лишь к программам, имеющим ограниченное количество вариантов использования. При разработке сложных программных систем возможности ручного тестирования сильно ограничены, так как при внесении изменений в код требуется организовать повторное выполнение тестов. Тем не менее при ручном тестировании можно выявить чрезвычайно изощренные ошибки, что крайне сложно сделать с использованием автоматизированного тестирования.
-
-
Разработка через тестирование
7.1 Основные понятия TDD.
Разработка через тестирование (англ. test-driven development) — техника программирования, при которой модульные тесты для программы или её фрагмента пишутся до самой программы (англ. test-first development) и, по существу, управляют её разработкой. Является одной из основных практик экстремального программирования.
Ни один программист не считает работу над некоторым фрагментом кода завершенной, не проверив перед этим его работоспособность. Однако, если вы тестируете свой код, это не означает, что у вас есть тесты.
Тест – это процедура, которая позволяет либо подтвердить, либо опровергнуть работоспособность кода. Когда программист проверяет работоспособность разработанного им кода, он выполняет тестирование вручную. В данном контексте тест состоит из двух этапов: стимулирование кода и проверки результатов его работы. Автоматический тест выполняется иначе: вместо программиста стимулированием кода и проверкой результатов занимается компьютер, который отображает на экране результат выполнения теста: код работоспособен или код неработоспособен.
Методика разработки через тестирование(Test-Driven Development, TDD) позволяет получить ответы на вопросы об организации автоматических тестов и выработке определенных навыков тестирования.
«Чистый код, который работает» - в этой короткой, но содержательной фразе, кроется весь смысл методики разработки приложений через тестирование. Чистый код, который работает, - это цель, к которой стоит стремиться, и этому есть причины:
-
Это предсказуемый способ разработки программ. Разработчик знает, когда работу следует считать законченной, и можете не беспокоиться о длинной череде ошибок. -
У разработчика появляется шанс усвоить уроки, которые преподносит ему код. Если он воспользуется первой же идеей, которая пришла ему в голову, у него не будет шанса реализовать вторую, лучшую идею. -
Коллеги по команде могут рассчитывать на разработчика, а он, в, свою очередь, на них. -
Разработчику приятнее писать такой код.
Однако как мы можем получить чистый код, который работает? Очень многие силы мешают нам добиться этого, а иногда нам не удается получить даже код, который работает. Чтобы избавиться от множества проблем, мы будем разрабатывать код, исходя из автоматических тестов. Такой стиль программирования называется разработкой через тестирование. В рамках этой методики мы:
-
Пишем новый код только тогда, когда автоматический код не сработал. -
Удаляем дублирование.
Два столь простых правила на самом деле генерируют сложное индивидуальное и групповое поведение со множеством технических последствий:
-
Проектируя код, мы постоянно запускаем его и получаем представление о том, как он работает, это помогает нам принимать правильные решения. -
Мы самостоятельно пишем свои собственные тесты, так как мы не можем ждать, что кто-то другой напишет тесты для нас. -
Наша среда разработки должна быстро реагировать на небольшие модификации кода. -
Архитектура программы должна базироваться на использовании множества сильно связанных компонентов, которые слабо сцеплены друг с другом, благодаря чему тестирование кода упрощается.
Два упомянутых правила TDD определяют порядок этапов программирования:
-
Красный – напишите небольшой тест, который не работает, а возможно, даже не компилируется. -
Зеленый – заставьте тест работать как можно быстрее, при этом не думайте о правильности дизайна и чистоте кода. Напишите ровно столько кода, чтобы тест сработал. -
Рефакторинг – удалите из написанного вами кода любое дублирование.
Освоив TDD, разработчики обнаруживают, что они пишут значительно больше тестов, чем раньше, и двигаются вперед маленькими шагами, которые раньше могли показаться бессмысленными.
Заставив тест работать, мы знаем, что теперь тест работает , отныне и навеки. Мы стали на шаг ближе к завершению работы, чем мы были до того, как тест сработал. После этого мы заставляем второй тест работать, затем третий, четвертый и т.д. Чем сложнее проблема, стоящая перед программистом, тем меньшую область функциональности должен покрывать каждый тест.
Определенно существуют задачи, которые невозможно(по крайней мере, на текущий момент) решить только при помощи тестов. В частности, TDD не позволяет механически продемонстрировать адекватность разработанного кода в области безопасности данных и взаимодействия между процессами. Безусловно, безопасность основана на коде , в котором не должно быть дефектов, однако она основана также на участии человека в процедурах защиты данных. Тонкие проблемы, возникающие в области взаимодействия между процессами, невозможно с уверенностью воспроизвести, просто запустив некоторый код.
В 1999 году при своём появлении разработка через тестирование была тесно связана с концепцией «сначала тест» (англ. test-first), применяемой в экстремальном программировании, однако позже выделилась как независимая методология.
Экстрема́льное программи́рование (англ. Extreme Programming, XP) — одна из гибких методологий разработки программного обеспечения. Авторы методологии — Кент Бек, Уорд Каннингем, Мартин Фаулер и другие.
-
Требования
Разработка через тестирование требует от разработчика создания автоматизированных модульных тестов, определяющих требования к коду непосредственно перед написанием самого кода.
Тест содержит проверки условий, которые могут либо выполняться, либо нет. Когда они выполняются, говорят, что тест пройден. Прохождение теста подтверждает поведение, предполагаемое программистом. Разработчики часто пользуются библиотеками для тестирования (англ. testing frameworks) для создания и автоматизации запуска наборов тестов. На практике модульные тесты покрывают критические и нетривиальные участки кода. Это может быть код, который подвержен частым изменениям, код, от работы которого зависит работоспособность большого количества другого кода, или код с большим количеством зависимостей.
Среда разработки должна быстро реагировать на небольшие модификации кода. Архитектура программы должна базироваться на использовании множества сильно связанных компонентов, которые слабо сцеплены друг с другом, благодаря чему тестирование кода упрощается.
TDD не только предполагает проверку корректности, но и влияет на дизайн программы. Опираясь на тесты, разработчики могут быстрее представить, какая функциональность необходима пользователю. Таким образом, детали интерфейса появляются задолго до окончательной реализации решения.
Разумеется, к тестам применяются те же требования стандартов кодирования, что и к основному коду.
-
-
Цикл разработки через тестирование
Графическое представление цикла разработки, в виде блок-схемы (Приложение 1).
Приведенная последовательность действий основана на книге Кента Бека «Разработка через тестирование: на примере».