Тестирование ПО (реферат) (548978), страница 5

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 5)

Они позволяютвыполнять тесты без прямого участия человека в течениепродолжительного времени, значительно увеличивая продуктивность иустраняя «тупое» повторение однообразных действий во время ручноготестирования. В то же время, любое малое изменение тестируемого ПОтребует перезаписи ручных тестов. Поэтому это первое поколениеинструментов не эффективно и не масштабируемо.Сценарии (Scripting) — форма программирования на языках, специальноразработанных для автоматизации тестирования ПО — смягчает многиепроблемы capture/playback tools.

Но разработкой занимаютсяпрограммисты высокого уровня, которые работают отдельно оттестировщиков, непосредственно запускающих тесты. К тому же скриптыболее всего подходят для тестирования GUI и не могут бытьвнедренными, пакетными или вообще каким-либо образом объединены всистему. Наконец, изменения в тестируемом ПО требуют сложныхизменений в соответствующих скриптах, и поддержка все возрастающейбиблиотеки тестирующих скриптов становится в конце концовнепреодолимой задачей.Data-driven testing — методология, которая используется в автоматизациитестирования. Особенностью является то, что тестовые скриптывыполняются и верифицируются на основе данных, которые хранятся вцентральном хранилище данных или БД.

Роль БД могут выполнятьODBC-ресурсы, csv или xls файлы и т.д. Data-driven testing — этообъединение нескольких взаимодействующих тестовых скриптов и ихисточников данных в фреймворк, используемый в методологии. В этомфреймворке переменные используются как для входных значений, так идля выходных проверочных значений: в тестовом скрипте обычнозакодированы навигация по приложению, чтение источников данных,ведение логов тестирования. Таким образом, логика, которая будетвыполнена в скрипте, также зависит от данных. Keyword-based автоматизация подразумевает разделение процессасоздания кейсов на 2 этапа: этап планирования и этап реализации.Одной из главных проблем автоматизированного тестирования являетсяего трудоемкость: несмотря на то, что оно позволяет устранить частьрутинных операций и ускорить выполнение тестов, большие ресурсы могуттратиться на обновление самих тестов.

Это относится к обоим видамавтоматизации. При рефакторинге часто бывает необходимо обновить имодульные тесты, и изменение кода тестов может занять столько же времени,сколько и изменение основного кода. С другой стороны, при измененииинтерфейса приложения необходимо заново переписать все тесты, которыесвязаны с обновленными окнами, что при большом количестве тестов можетотнять значительные ресурсы.Для автоматизации тестирования существует большое количествоприложений. Наиболее популярные из них:HP LoadRunner, HP QuickTest Professional, HP Quality Center Segue SilkPerformer IBM Rational FunctionalTester, IBM Rational PerformanceTester, IBM Rational TestStudio SmartBear Software TestCompleteИспользование этих инструментов помогает тестировщикамавтоматизировать следующие задачи:установка продукта создание тестовых данных GUI взаимодействие определение проблемыОднако автоматические тесты не могут полностью заменить ручноетестирование.

Автоматизация всех испытаний — очень дорогой процесс, ипотому автоматическое тестирование является лишь дополнением ручноготестирования. Наилучший вариант использования автоматических тестов —регрессионное тестирование.Автоматизация может принести как огромное облегчение всемтестировщикам, так и завалить работу всего отдела и отложить релиз, отпуск,и т.п.Смешанное/полуавтоматическоеВ этом виде тестирования ручной подход сочетается с автоматическим.Например, можно создать аккаунт с помощью программы (автоматически), апотом провести транзакцию вручную.По степени изолированности компонентовПо степени изолированности тестирование делится на 3 вида:Компонентное (модульное) тестированиеИнтеграционное тестированиеСистемное тестированиеКомпонентное тестированиеКомпонентное тестирование – процесс в программировании,позволяющий проверить на корректность отдельные модули исходного кодапрограммы.Идея состоит в том, чтобы писать тесты для каждой нетривиальнойфункции или метода.

Это позволяет достаточно быстро проверить, непривело ли очередное изменение кода к регрессии, то есть к появлениюошибок в уже оттестированных местах программы, а также облегчаетобнаружение и устранение таких ошибок.Цель модульного тестирования — изолировать отдельные частипрограммы и показать, что по отдельности эти части работоспособны.Этот тип тестирования обычно выполняется программистами.Модульное тестирование позже позволяет программистампроводить рефакторинг, будучи уверенными, что модуль по-прежнемуработает корректно (регрессионное тестирование).

Это поощряетпрограммистов к изменениям кода, поскольку достаточно легко проверить,что код работает и после изменений.Модульное тестирование помогает устранить сомнения по поводуотдельных модулей и может быть использовано для подхода к тестированию«снизу вверх»: сначала тестируются отдельные части программы, затемпрограмма в целом.Модульные тесты можно рассматривать как «живой документ» длятестируемого класса. Клиенты, которые не знают, как использовать данныйкласс, могут использовать юнит-тест в качестве примера.Поскольку некоторые классы могут использовать другие классы,тестирование отдельного класса часто распространяется на связанные с ним.Например, класс пользуется базой данных; в ходе написания тестапрограммист обнаруживает, что тесту приходится взаимодействовать сбазой.

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

В самом деле, это следует изпрактической невозможности трассировки всех возможных путейвыполнения программы, за исключением простейших случаев. Кроме того,происходит тестирование каждого из модулей по отдельности. Это означает,что ошибки интеграции, системного уровня, функций, исполняемых внескольких модулях не будут определены. Кроме того, данная технологиябесполезна для проведения тестов на производительность. Таким образом,модульное тестирование более эффективно при использовании в сочетании сдругими методиками тестирования.Тестирование программного обеспечения — комбинаторная задача.Например, каждое возможное значение булевской переменной потребуетдвух тестов: один на вариант TRUE, другой — на вариант FALSE.

Врезультате на каждую строку исходного кода потребуется 3-5 строктестового кода.Для получения выгоды от модульного тестирования требуется строгоследовать технологии тестирования во всём процессе разработкипрограммного обеспечения. Нужно хранить не только записи обо всехпроведённых тестах, но и обо всех изменениях исходного кода во всехмодулях. С этой целью следует использовать систему контроля версий ПО.Таким образом, если более поздняя версия ПО не проходит тест, которыйбыл успешно пройден ранее, будет несложным сверить исходный кодвариантов и устранить ошибку.

Также необходимо убедиться в неизменномотслеживании и анализе неудачных тестов. Игнорирование этого требованияприведёт к лавинообразному увеличению неудачных тестовых результатов.Некоторые языки имеют поддержку модульного тестирования на уровнесинтаксиса.

Это избавляет от необходимости выбирать к какому фреймворкупривязываться, и позволяет упростить перенос кода в другие проекты.Пример таких языков:CobraDИнтеграционное тестированиеИнтеграционное тестирование (англ. Integration testing, иногданазывается англ. Integration and Testing, аббревиатура англ. I&T) — одна изфаз тестирования программного обеспечения, при котором отдельныепрограммные модули объединяются и тестируются в группе. Обычноинтеграционное тестирование проводится после модульного тестирования ипредшествует системному тестированию.Интеграционное тестирование в качестве входных данных используетмодули, над которыми было проведено модульное тестирование, группируетих в более крупные множества, выполняет тесты, определённые в планетестирования для этих множеств, и представляет их в качестве выходныхданных и входных для последующего системного тестирования.Целью интеграционного тестирования является проверка соответствияпроектируемых единиц функциональным, приёмным и требованиямнадежности.

Тестирование этих проектируемых единиц — объединения,множества или группа модулей — выполняются через их интерфейс,используя тестирование «чёрного ящика».Системы непрерывной интеграцииДля автоматизации интеграционного тестирования применяются системынепрерывной интеграции (Continious Integration System, CIS).

Принципдействия таких систем состоит в следующем:1. CIS производит мониторинг системы контроля версий;2. При изменении исходных кодов в репозитории производитсяобновление локального хранилища;3. Выполняются необходимые проверки и модульные тесты;4. Исходные коды компилируются в готовые выполняемые модули;5. Выполняются тесты интеграционного уровня;6. Генерируется отчет о тестировании.Таким образом, автоматические интеграционные тесты выполняютсясразу же после внесения изменений, что позволяет обнаруживать и устранятьошибки в короткие сроки.Системное тестирование программного обеспеченияСистемное тестирование программного обеспечения — это тестированиепрограммного обеспечения (ПО), выполняемое на полной, интегрированнойсистеме, с целью проверки соответствия системы исходным требованиям.Системное тестирование относится к методам тестирования чёрного ящика,и, тем самым, не требует знаний о внутреннем устройстве системы.Основной задачей системного тестирования является проверка какфункциональных, так и не функциональных требований к системе в целом.При этом выявляются дефекты, такие как неверное использование ресурсовсистемы, непредусмотренные комбинации данных пользовательского уровня,несовместимость с окружением, непредусмотренные сценариииспользования, отсутствующая или неверная функциональность, неудобствоиспользования и т.д.

Для минимизации рисков, связанных с особенностямиповедения системы в той или иной среде, во время тестированиярекомендуется использовать окружение максимально приближенное к тому,на которое будет установлен продукт после выдачи.Можно выделить два подхода к системному тестированию:-на базе требований (requirements based)Для каждого требования пишутся тестовые случаи (test cases), проверяющиевыполнение данного требования.-на базе случаев использования (use case based)По времени проведения тестированияАльфа-тестирование (alpha testing) Тестирование новой функциональности (new feature testing) Регрессионное тестирование (regression testing)Бета-тестирование (beta testing)Аттестационное тестированиеАльфа-тестирование — имитация реальной работы с системойштатными разработчиками, либо реальная работа с системойпотенциальными пользователями/заказчиком.

Чаще всего альфатестирование проводится на ранней стадии разработки продукта, но внекоторых случаях может применяться для законченного продукта в качествевнутреннего приёмочного тестирования. Иногда альфа-тестированиевыполняется под отладчиком или с использованием окружения, котороепомогает быстро выявлять найденные ошибки. Обнаруженные ошибки могутбыть переданы тестировщикам для дополнительного исследования вокружении, подобном тому, в котором будет использоваться ПО.Бета-тестирование — в некоторых случаях выполняется распространениеверсии с ограничениями (по функциональности или времени работы) длянекоторой группы лиц, с тем чтобы убедиться, что продукт содержитдостаточно мало ошибок. Иногда бета-тестирование выполняется для того,чтобы получить обратную связь о продукте от его будущих пользователей.Регрессионное тестирование (англ.

Характеристики

Список файлов учебной работы