Тест реферат – : , — BestReferat.ru

Введение

МосковскийЭнергетическийИнститут

СангаджиевЮрий Олегович

11.12.2011

Оглавление

 

Введение……………………………………………………………………………………………………………………………………

2

История развития тестирования программного обеспечения……………………………………………………….

5

Классификации тестирования……………………………………………………………………………………………………..

7

Черный, белый, серый ящики………………………………………………………………………………………………….

8

По объекту тестирования…………………………………………………………………………………………………………

9

Тестирование интерфейса пользователя………………………………………………………………………………

9

Тестирование локализации………………………………………………………………………………………………….

9

Тестирование производительности………………………………………………………………………………………

9

Нагрузочное тестирование…………………………………………………………………………………………………

10

Юзабилити-тестирование…………………………………………………………………………………………………..

18

По степени автоматизации…………………………………………………………………………………………………….

21

По степени изолированности компонентов……………………………………………………………………………

24

По времени проведения тестирования…………………………………………………………………………………..

27

Обзорсред автоматизации тестирования. …………………………………………………………………………………

30

BUGS — the Bug Genie………………………………………………………………………………………………………………

33

Bugzilla ………………………………………………………………………………………………………………………………….

33

JIRA ……………………………………………………………………………………………………………………………………….

34

Trac……………………………………………………………………………………………………………………………………….

35

HP LoadRunner, HP QuickTest Professional, HP Quality Center…………………………………………………….

36

Выводы…………………………………………………………………………………………………………………………………

38

Выводы…………………………………………………………………………………………………………………………………….

39

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

Такой процесс формальной проверки или верификации может доказать, что дефекты отсутствуют с точки зрения используемого метода. (То есть нет никакой возможности точно установить или гарантировать отсутствие дефектов в программном продукте с учётом человеческого фактора, присутствующего на всех этапах жизненного цикла ПО).

Существует множество подходов к решению задачи тестирования и верификации ПО, но эффективное тестирование сложных программных продуктов — это процесс в высшей степени творческий, не сводящийся к следованию строгим и чётким процедурам или созданию таковых.

С точки зрения ISO 9126, Качество (программных средств) можно определить как совокупную характеристику исследуемого ПО с учётом следующих составляющих:

Функциональность — Набор атрибутов характеризующий, соответствие функциональных возможностей ПО набору требуемой пользователем функциональности. Детализируется следующими подхарактеристиками (субхарактеристиками):

Пригодностью для применения

Корректностью (правильностью, точностью)

Способностью к взаимодействию (в частности сетевому)

Защищенностью

Надёжность — Набор атрибутов, относящихся к способности ПО сохранять свой уровень качества функционирования в установленных условиях за определенный период времени. Детализируется следующими подхарактеристиками (субхарактеристиками):

Уровнем завершенности (отсутствия ошибок)

Устойчивостью к дефектам

Восстанавливаемостью

Доступностью

Готовностью

Практичность (применимость) — Набор атрибутов, относящихся к объему работ, требуемых для исполнения и индивидуальной оценки такого исполнения определенным или предполагаемым кругом пользователей. Детализируется следующими подхарактеристиками (субхарактеристиками):

Понятностью

Простотой использования

Изучаемостью

Привлекательностью

Эффективность — Набор атрибутов, относящихся к соотношению между уровнем качества функционирования ПО и объемом используемых ресурсов при установленных условиях. Детализируется следующими подхарактеристиками (субхарактеристиками):

Временной эффективностью

Используемостью ресурсов

Сопровождаемость — Набор атрибутов, относящихся к объему работ, требуемых для проведения конкретных изменений (модификаций). Детализируется следующими подхарактеристиками (субхарактеристиками):

Удобством для анализа;

Изменяемостью

Стабильностью

Тестируемостью

Мобильность — Набор атрибутов, относящихся к способности ПО быть перенесенным из одного окружения в другое. Детализируется следующими подхарактеристиками (субхарактеристиками):

Адаптируемостью

Простотой установки (инсталляции)

Сосуществованием (соответствием)

Замещаемостью

Более полный список атрибутов и критериев можно найти в стандарте ISO 9126 Международной организации по стандартизации. Состав и содержание документации, сопутствующей процессу тестирования, определяется стандартом IEEE 829-1998 Standard for Software Test Documentation.

Для того чтобы обеспечить надлежащее качество программным продуктам сегодня применяются некоторые виды тестирования:

1)Модульное тестирование

2)Системное тестирование

3)Регрессионное тестирование

4)Интеграционное тестирование

5)Юзабилити тестирование

6)Атестационное тестирование

7)Альфа и Бета – тестирование

8)Еще какое то

Но прежде чем рассмотреть классификацию тестирование обратимся к истории развития тестирования ПО.

История развития тестирования программногообеспечения

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

В1960-х много внимания уделялось «исчерпывающему» тестированию, которое должно проводиться с использованием всех путей в коде или всех возможных входных данных. Было отмечено, что в этих условиях полное тестирование ПО невозможно, потому что, во-первых, количество возможных входных данных очень велико, во-вторых, существует множество путей, в-третьих, сложно найти проблемы в архитектуре и спецификациях. По этим причинам «исчерпывающее» тестирование было отклонено и признано теоретически невозможным.

Вначале 1970-х тестирование ПО обозначалось как «процесс, направленный на демонстрацию корректности продукта» или как «деятельность по подтверждению правильности работы ПО». В зарождавшейся программной инженерии верификация ПО значилась как «доказательство правильности». Хотя концепция была теоретически перспективной, на практике она требовала много времени и была недостаточно всеобъемлющей. Было решено, что доказательство правильности — неэффективный метод тестирования ПО. Однако, в некоторых случаях демонстрация правильной работы используется и в наши дни, например, приемо-сдаточные испытания. Во второй половине 1970-х тестирование представлялось как выполнение программы с намерением найти ошибки, а не доказать, что она работает. Успешный тест — это тест, который обнаруживает ранее неизвестные проблемы. Данный подход прямо противоположен предыдущему. Указанные два определения представляют собой «парадокс тестирования», в основе которого лежат два противоположных утверждения: с одной стороны, тестирование позволяет убедиться, что продукт работает хорошо, а с другой — выявляет ошибки в ПО, показывая, что продукт не работает. Вторая цель тестирования является более продуктивной с точки зрения улучшения качества, так как не позволяет игнорировать недостатки ПО.

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

требования, код, архитектуру, сами тесты. «Традиционное» тестирование, существовавшее до начала 1980-х, относилось только к скомпилированной, готовой системе (сейчас это обычно называется системное тестирование), но в дальнейшем тестировщики стали вовлекаться во все аспекты жизненного цикла разработки. Это позволяло раньше находить проблемы в требованиях и архитектуре и тем самым сокращать сроки и бюджет разработки. В середине 1980-х появились первые инструменты для автоматизированного тестирования. Предполагалось, что компьютер сможет выполнить больше тестов, чем человек, и сделает это более надежно. Поначалу эти инструменты были крайне простыми и не имели возможности написания сценариев на скриптовых языках.

Вначале 1990-х в понятие «тестирование» стали включать планирование, проектирование, создание, поддержку и выполнение тестов и тестовых окружений, и это означало переход от тестирования к обеспечению качества, охватывающего весь цикл разработки ПО. В это время начинают появляться различные программные инструменты для поддержки процесса тестирования: более продвинутые среды для автоматизации с возможностью создания скриптов и генерации отчетов, системы управления тестами, ПО для проведения нагрузочного тестирования. В середине 1990-х с развитием Интернета и разработкой большого количества веб-приложений особую популярность стало получать «гибкое тестирование» (по аналогии с гибкими методологиями программирования).

В2000-х появилось еще более широкое определение тестирования, когда в него было добавлено понятие «оптимизация бизнес-технологий»

(en:business technology optimization, BTO). BTO направляет развитие информационных технологий в соответствии с целями бизнеса. Основной подход заключается в оценке и максимизации значимости всех этапов жизненного цикла разработки ПО для достижения необходимого уровня качества, производительности, доступности.

studfiles.net

Тесты как метод исследования — реферат

 
 
 
 

Реферат

     по 
основам нравственности

     Особенности
общения детей с различными нарушениями 
в развитии 
 

     Тема:
Тесты как метод исследования.
 
 
 
 
 
 
 
 
 
 
 
 
 
 

     Преподаватель:
Сысоева Ю.В. 

     Выполнила:
Куликова Ю.В.

     Студентка
5 курса отделения логопедии 
 
 
 

Введение

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

        
Сила науки во многом зависит от совершенства
методов исследования, от того, насколько
они валидны и надежны, как быстро и эффективно
данная отрасль знаний способна воспринять
и использовать у себя все самое новое,
передовое, что появляется в методах других
наук. Там, где это удается сделать, обычно
наблюдается заметный прорыв вперед в
познании мира. [4]

     Тест
— (англ. test — проба, испытание, проверка)
– это ансамбль стандартизированных,
стимулирующих определенную форму активности,
часто ограниченных по времени выполнения
заданий, результаты которых поддаются
количественной (и качественной) оценке
и позволяют установить индивидуально-психологические
особенности личности.

     Тесты
— это стандартизированные методики
психодиагностики, позволяющие получить
сопоставимые количественные и качественные
показатели степени развитости изучаемых 
свойств. [6] 
 
 
 
 
 
 
 
 

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

     История
возникновения и 
развития метода теста.

     Возникновение
тестологических процедур было обусловлено
потребностью сопоставления (сравнения,
дифференциации и ранжиования) индивидов
по уровню развития или степени выраженности
различных психологических качеств.  
Основоположники тестирования — Ф.Гальтон,
Ч.Спирман, Дж.Каттел, А.Бине, Т.Симон. Сам
термин «умственный тест» придумал
Кеттел в 1890 г. Начало развития современной
тестологии массового применения тестов
на практике связано с именем французского
врача Бине, разработавшего в соавторстве
с Симоном метрическую шкалу умственного
развития, известную под названием «тест
Бине-Симона».  
          Термин «тест»
впервые ввёл американский психолог Дж.
Кеттел в 1890 году. Предложенная им серия
из 50 тестов фактически представляла программу
определения примитивных психофизиологических
характеристик: базирующихся на наиболее
разработанных в то время психологических
экспериментах (например, измерение силы
правой и левой рук посредством динамометра,
скорости реакции на звук, и т.д.) [5]

     Тесты
начали применяться в 1864 году Дж. Фишером
в Великобритании для проверки знаний
учащихся. Теоретические основы тестирования
были разработаны английским психологом
Ф. Гальтоном в 1883 году: применение серии
одинаковых испытаний к большому числу
индивидов, статистической обработке
результатов, выделение эталонов оценки.

     Французский
психолог А. Бине применил принципы тестологических
исследований к высшим психическим функциям
человека: в его серию тестов (1891) вошли
задания на испытание памяти, типа представления,
внимания, эстетические и этические чувства
и т.д. Первый стандартизированный педагогический
тест был составлен американским психологом
Э. Торнодайком. Развитие тестирования
было одной из причин, обусловивших проникновение
в психологию и педагогику математических
методов. Американский психолог К. Спирмен
разработал основные методы корреляционного
анализа для стандартизации тестов и объективного
измерения тестологических исследований.
Статистические методы Спирмена — применение
факторного анализа — сыграли большую
роль в дальнейшем развитии тестирования.
[6]

     Сущность 
тестов

     Широкому 
распространению, развитию и совершенствованию 
тестов способствовал целый ряд 
преимуществ, которые дает этот метод.

     -позволяют
дать оценку индивида в соответствии с
поставленной целью исследования;

     -обеспечивают
возможность получения количественной
оценки на основе квантификации качественных
параметров личности и удобство математической
обработки;

     -являются
относительно оперативным способом оценки
большого числа неизвестных лиц;

     -способствуют
объективности оценок, не зависящих от
субъективных установок лица, проводящего
исследование;

     -обеспечивают
сопоставимость информации, полученной
разными исследователями на разных испытуемых.

     -возможность
дифференцированного их применения (серии
стандартизированных тестов разрабатываются
применительно к различным возрастным
группам людей, уровню образования, жизненному
опыту и профессии).[2] 

Требования,
предъявляемые к 
тестам

     К
тестам, как методам точной психодиагностики
предъявляется ряд особых требований.

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

     2.Простота
формулировок и однозначность тестовых
заданий — в словесных и иных заданиях
теста не должно быть таких моментов, которые
могут по-разному восприниматься и пониматься
людьми.

     3.Ограниченное
время выполнения тестовых заданий — полное
время выполнения заданий психодиагностического
теста не должно превышать 1,5-2 часов, т.
к. сверх этого времени человеку трудно
сохранить свою работоспособность на
достаточно высоком уровне.

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

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

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

     Такими 
требованиями являются

     Валидность
— “полноценность”, “пригодность”, “соответствие”.
Есть несколько разновидностей валидности.

     Валидность
теоретическая — определяется по соответствию
показателей исследуемого качества, получаемых
с помощью данной методики, показателям,
получаемым с помощью других методик.
Теоретическую валидность проверяют по
корреляциям показателей одного и того
же свойства, получаемым при помощи различных
методик, опирающихся или исходящих из
одной и той же теории.

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

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

     Валидность
внешняя — примерно то же, что и эмпирическая
валидность, но тут речь идет о связи между
показателями методики и наиболее важными
внешними признаками, относящимися к поведению
испытуемого.

     Валидность
методики проверяется и уточняется в процессе
ее достаточно длительного использования.

     Критерии 
валидности:

     ·
Поведенческие показатели — реакции,
действия и поступки испытуемого 
в разных жизненных ситуациях.

     ·
Достижения испытуемого в различных 
видах деятельности: учебной, трудовой,
творческой и др.

     ·
Данные о выполнении различных контрольных 
проб и заданий.

     ·
Данные, полученные от других методик,
валидность которых или связь с данной
методикой считаются достоверно установленными.

     ·
Надежность — характеризует возможность 
получения с помощью данной методики
устойчивых показателей.

     Надежность 
психодиагностической методики можно 
установить двумя способами:

     ·
путем сравнения результатов, получаемых
по этой методике разными людьми

     ·путем
сравнения результатов, получаемых по
одной и той же методике в различных условиях.

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

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

     Стандартизированность
методики означает, что она должна применяться
всегда и везде одинаковым образом, от
начала ситуации до способа интерпретации
результатов.

     Сопоставимость
— т. е. оценки, получаемые при помощи
теста можно сравнивать друг с 
другом независимо от того, где, когда 
и кем они были получены. [4]

     Каждый 
тест, соответствующий критериям 
надежности, кроме набора заданий 
включает в себя следующие компоненты:

1) стандартная 
инструкция для испытуемого о 
цели и правилах выполнения 
заданий,  
2) ключ шкалирования — соотнесение пунктов
заданий со шкалами измеряемых качеств,
указывающее, какой пункт заданий к какой
шкале относится,  
3) кодировочный ключ, позволяющий подсчитать,
сколько баллов вносит в шкалу тот или
иной вариант ответа,

4) ключ 
интерпретации полученного индекса, 
представляющий собой данные 
нормы, 

с которыми
соотносится полученыный результат.

Составление
тестов строится по единой схеме:

определение
целей тестирования, составление 
тестов в черновом виде, апробация 
тестов на репрезентативной выборке 
испытуемых и исправление недостатков,
разработка шкалы измерений (на основе
качественных соображений и статистической
обработки результатов) и правил
интерпретации результатов.

     Правила
проведения тестирования,
обработки и интерпретации 
результатов

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

Для каждого 
теста должна быть обоснованная и 
выверенная процедура обработки 
и интерпретации результатов. Это 
позволяет избежать ошибок, возникающих 
на этом этапе тестирования. [4]

 

           
Недостатком стандартизированных тестов
является определенная возможность влияния
испытуемого на результаты тестирования
в соответствии с одобряемыми характерологическими
чертами личности. Эти возможности увеличиваются,
если обучаемые знают содержание теста,
а также методику оценки поведения и изучаемых
психологических качеств личности. Другим
недостатком стандартизированных тестов
является определенная трудность обеспечения
индивидуального подхода к испытуемым
в процессе тестирования. У людей с пониженной
стрессоустойчивостью, как отмечает А.Г.Шмелев,
возникают определенные нарушения саморегуляции,
они начинают волноваться, ошибаться в
элементарных для них вопросах. Вовремя
заметить такую реакцию на тест – задача,
которая по силам лишь квалифицированному
и добросовестному экспериментатору.

     Для
преодоления основного недостатка
большинства тестов применяются 
различные приемы:

  1. увеличение
    базовой выборки с целью повышения ее
    репрезентативности по большему числу
    параметров,

student.zoomru.ru

Реферат Тестирование ПО

скачать

Реферат на тему:

План:

    Введение

  • 1 Введение
  • 2 История развития тестирования программного обеспечения
  • 3 Тестирование программного обеспечения
  • 4 Уровни тестирования
  • 5 Статическое и динамическое тестирование
  • 6 Регрессионное тестирование
  • 7 Тестовые скрипты
  • 8 Тестирование «белого ящика» и «чёрного ящика»
    • 8.1 Покрытие кода
  • 9 Цитаты
  • Литература


Введение

Тести́рование програ́ммного обеспе́чения — процесс исследования программного обеспечения (ПО) с целью получения информации о качестве продукта.


1. Введение

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

Такой процесс формальной проверки или верификации может доказать, что дефекты отсутствуют с точки зрения используемого метода. (То есть нет никакой возможности точно установить или гарантировать отсутствие дефектов в программном продукте с учётом человеческого фактора, присутствующего на всех этапах жизненного цикла ПО).

Существует множество подходов к решению задачи тестирования и верификации ПО, но эффективное тестирование сложных программных продуктов — это процесс в высшей степени творческий, не сводящийся к следованию строгим и чётким процедурам или созданию таковых.

С точки зрения ISO 9126, Качество (программных средств) можно определить как совокупную характеристику исследуемого ПО с учётом следующих составляющих:

  • Надёжность
  • Сопровождаемость
  • Практичность
  • Эффективность
  • Мобильность
  • Функциональность

Более полный список атрибутов и критериев можно найти в стандарте ISO 9126 Международной организации по стандартизации. Состав и содержание документации, сопутствующей процессу тестирования, определяется стандартом IEEE 829-1998 Standard for Software Test Documentation.


2. История развития тестирования программного обеспечения

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

В 1960-х много внимания уделялось «исчерпывающему» тестированию, которое должно проводиться с использованием всех путей в коде или всех возможных входных данных. Было отмечено, что в этих условиях полное тестирование ПО невозможно, потому что, во-первых, количество возможных входных данных очень велико, во-вторых, существует множество путей, в-третьих, сложно найти проблемы в архитектуре и спецификациях. По этим причинам «исчерпывающее» тестирование было отклонено и признано теоретически невозможным.

В начале 1970-х тестирование ПО обозначалось как «процесс, направленный на демонстрацию корректности продукта» или как «деятельность по подтверждению правильности работы ПО». В зарождавшейся программной инженерии верификация ПО значилась как «доказательство правильности». Хотя концепция была теоретически перспективной, на практике она требовала много времени и была недостаточно всеобъемлющей. Было решено, что доказательство правильности — неэффективный метод тестирования ПО. Однако, в некоторых случаях демонстрация правильной работы используется и в наши дни, например, приемо-сдаточные испытания. Во второй половине 1970-х тестирование представлялось как выполнение программы с намерением найти ошибки, а не доказать, что она работает. Успешный тест — это тест, который обнаруживает ранее неизвестные проблемы. Данный подход прямо противоположен предыдущему. Указанные два определения представляют собой «парадокс тестирования», в основе которого лежат два противоположных утверждения: с одной стороны, тестирование позволяет убедиться, что продукт работает хорошо, а с другой — выявляет ошибки в ПО, показывая, что продукт не работает. Вторая цель тестирования является более продуктивной с точки зрения улучшения качества, так как не позволяет игнорировать недостатки ПО.

В 1980-х тестирование расширилось таким понятием, как предупреждение дефектов. Проектирование тестов — наиболее эффективный из известных методов предупреждения ошибок. В это же время стали высказываться мысли, что необходима методология тестирования, в частности, что тестирование должно включать проверки на всем протяжении цикла разработки, и это должен быть управляемый процесс. В ходе тестирования надо проверить не только собранную программу, но и требования, код, архитектуру, сами тесты. «Традиционное» тестирование, существовавшее до начала 1980-х, относилось только к скомпилированной, готовой системе (сейчас это обычно называется системное тестирование), но в дальнейшем тестировщики стали вовлекаться во все аспекты жизненного цикла разработки. Это позволяло раньше находить проблемы в требованиях и архитектуре и тем самым сокращать сроки и бюджет разработки. В середине 1980-х появились первые инструменты для автоматизированного тестирования. Предполагалось, что компьютер сможет выполнить больше тестов, чем человек, и сделает это более надежно. Поначалу эти инструменты были крайне простыми и не имели возможности написания сценариев на скриптовых языках.

В начале 1990-х в понятие «тестирование» стали включать планирование, проектирование, создание, поддержку и выполнение тестов и тестовых окружений, и это означало переход от тестирования к обеспечению качества, охватывающего весь цикл разработки ПО. В это время начинают появляться различные программные инструменты для поддержки процесса тестирования: более продвинутые среды для автоматизации с возможностью создания скриптов и генерации отчетов, системы управления тестами, ПО для проведения нагрузочного тестирования. В середине 1990-х с развитием Интернета и разработкой большого количества веб-приложений особую популярность стало получать «гибкое тестирование» (по аналогии с гибкими методологиями программирования).

В 2000-х появилось еще более широкое определение тестирования, когда в него было добавлено понятие «оптимизация бизнес-технологий» (en:business technology optimization, BTO). BTO направляет развитие информационных технологий в соответствии с целями бизнеса. Основной подход заключается в оценке и максимизации значимости всех этапов жизненного цикла разработки ПО для достижения необходимого уровня качества, производительности, доступности.


3. Тестирование программного обеспечения

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

По объекту тестирования:

  • Функциональное тестирование (functional testing)
  • Тестирование производительности (performance testing)
    • Нагрузочное тестирование (load testing)
    • Стресс-тестирование (stress testing)
    • Тестирование стабильности (stability / endurance / soak testing)
  • Тестирование удобства использования (usability testing)
  • Тестирование интерфейса пользователя (UI testing)
  • Тестирование безопасности (security testing)
  • Тестирование локализации (localization testing)
  • Тестирование совместимости (compatibility testing)

По знанию системы:

  • Тестирование чёрного ящика (black box)
  • Тестирование белого ящика (white box)
  • Тестирование серого ящика (grey box)

По степени автоматизации:

  • Ручное тестирование (manual testing)
  • Автоматизированное тестирование (automated testing)
  • Полуавтоматизированное тестирование (semiautomated testing)

По степени изолированности компонентов:

  • Компонентное (модульное) тестирование (component/unit testing)
  • Интеграционное тестирование (integration testing)
  • Системное тестирование (system/end-to-end testing)

По времени проведения тестирования:

  • Альфа-тестирование (alpha testing)
    • Тестирование при приёмке (smoke testing)
    • Тестирование новой функциональности (new feature testing)
    • Регрессионное тестирование (regression testing)
    • Тестирование при сдаче (acceptance testing)
  • Бета-тестирование (beta testing)

По признаку позитивности сценариев:

  • Позитивное тестирование (positive testing)
  • Негативное тестирование (negative testing)

По степени подготовленности к тестированию:

  • Тестирование по документации (formal testing)
  • Тестирование ad hoc или интуитивное тестирование (ad hoc testing)


4. Уровни тестирования

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

Часто для свободного/открытого ПО стадия альфа-тестирования характеризует функциональное наполнение кода, а бета-тестирования — стадию исправления ошибок. При этом как правило на каждом этапе разработки промежуточные результаты работы доступны конечным пользователям.


5. Статическое и динамическое тестирование

Описанные выше техники — тестирование белого ящика и тестирование чёрного ящика — предполагают, что код исполняется, и разница состоит лишь в той информации, которой владеет тестировщик. В обоих случаях это динамическое тестирование.

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

Также к статическому тестированию относят тестирование требований, спецификаций, документации.


6. Регрессионное тестирование

Основная статья: Регрессионное тестирование

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


7. Тестовые скрипты

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

8. Тестирование «белого ящика» и «чёрного ящика»

В терминологии профессионалов тестирования, фразы «тестирование белого ящика» и «тестирование чёрного ящика» относятся к тому, имеет ли разработчик тестов доступ к исходному коду тестируемого ПО, или же тестирование выполняется через пользовательский интерфейс либо прикладной программный интерфейс, предоставленный тестируемым модулем.

При тестировании белого ящика (англ. white-box testing, также говорят — прозрачного ящика), разработчик теста имеет доступ к исходному коду программ и может писать код, который связан с библиотеками тестируемого ПО. Это типично для юнит-тестирования (англ. unit testing), при котором тестируются только отдельные части системы. Оно обеспечивает то, что компоненты конструкции — работоспособны и устойчивы, до определённой степени. При тестировании белого ящика используются метрики покрытия кода.

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

При тестировании серого ящика разработчик теста имеет доступ к исходному коду, но при непосредственном выполнении тестов доступ к коду, как правило, не требуется.

Если «альфа-» и «бета-тестирование» относятся к стадиям до выпуска продукта (а также, неявно, к объёму тестирующего сообщества и ограничениям на методы тестирования), тестирование «белого ящика» и «чёрного ящика» имеет отношение к способам, которыми тестировщик достигает цели.

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


8.1. Покрытие кода

Основная статья: Покрытие кода

Покрытие кода, по своей сути, является тестированием методом белого ящика. Тестируемое ПО собирается со специальными настройками или библиотеками и/или запускается в особом окружении, в результате чего для каждой используемой (выполняемой) функции программы определяется местонахождение этой функции в исходном коде. Этот процесс позволяет разработчикам и специалистам по обеспечению качества определить части системы, которые, при нормальной работе, используются очень редко или никогда не используются (такие как код обработки ошибок и т.п.). Это позволяет сориентировать тестировщиков на тестирование наиболее важных режимов.

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

Как правило, инструменты и библиотеки, используемые для получения покрытия кода, требуют значительных затрат производительности и/или памяти, недопустимых при нормальном функционировании ПО. Поэтому они могут использоваться только в лабораторных условиях.


9. Цитаты

  • «Тестирование программ может использоваться для демонстрации наличия ошибок, но оно никогда не покажет их отсутствие.» — Дейкстра, 1970 г.

Литература

  • Лайза Криспин, Джанет Грегори Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд = Agile Testing: A Practical Guide for Testers and Agile Teams. — М.: «Вильямс», 2010. — 464 с. — (Addison-Wesley Signature Series). — 1000 экз. — ISBN 978-5-8459-1625-9
  • Канер Кем, Фолк Джек, Нгуен Енг Кек Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений. — Киев: ДиаСофт, 2001. — 544 с. — ISBN 9667393879
  • Калбертсон Роберт, Браун Крис, Кобб Гэри Быстрое тестирование. — М.: «Вильямс», 2002. — 374 с. — ISBN 5-8459-0336-X
  • Синицын С. В., Налютин Н. Ю. Верификация программного обеспечения. — М.: БИНОМ, 2008. — 368 с. — ISBN 978-5-94774-825-3
  • Бейзер Б. Тестирование чёрного ящика. Технологии функционального тестирования программного обеспечения и систем. — СПб.: Питер, 2004. — 320 с. — ISBN 5-94723-698-2

wreferat.baza-referat.ru

Отправить ответ

avatar
  Подписаться  
Уведомление о