Способы тестирования программного обеспечения. Процесс тестирование программного обеспечения

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

Введение

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

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

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

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

· Надёжность

· Сопровождаемость

· Практичность

· Эффективность

· Мобильность

· Функциональность

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

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

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

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

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

· Функциональное тестирование (functional testing)

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

· Тестирование производительности (perfomance/stress testing)

· Тестирование стабильности (stability/load testing)

· Тестирование удобства использования (usability testing)

· Тестирование интерфейса пользователя (UI testing)

· Тестирование безопасности (security testing)

· Тестирование локализации (localization testing)

· Тестирование совместимости (compatibility testing)

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

· Тестирование чёрного ящика (black box)

· Тестирование белого ящика (white box)

· Тестирование серого ящика (gray 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 testing)

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

Модульное тестирование (юнит-тестирование) - тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция. Часто модульное тестирование осуществляется разработчиками ПО.

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

Системное тестирование - тестируется интегрированная система на её соответствие требованиям.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Регрессио́нное тести́рование (англ. regression testing, от лат. regressio - движение назад) - собирательное название для всех видов тестирования программного обеспечения, направленных на обнаружение ошибок в уже протестированных участках исходного кода. Такие ошибки - когда после внесения изменений в программу перестает работать то, что должно было продолжать работать, - называют регрессионными ошибками (англ. regression bugs).

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

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

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

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

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

«Фундаментальная проблема при сопровождении программ состоит в том, что исправление одной ошибки с большой вероятностью (20-50%) влечет появление новой. Поэтому весь процесс идет по принципу "два шага вперед, шаг назад".

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

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

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

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

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

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

Покрытие кода - мера, используемая при тестировании программного обеспечения. Она показывает процент, насколько исходный код программы был протестирован. Техника покрытия кода была одной из первых методик, изобретённых для систематического тестирования ПО. Первое упоминание покрытия кода в публикациях появилось в 1963 году.

Критерии

Существует несколько различных способов измерения покрытия, основные из них:

· Покрытие операторов - каждая ли строка исходного кода была выполнена и протестирована?

· Покрытие условий - каждая ли точка решения (вычисления истинно ли или ложно выражение) была выполнена и протестирована?

· Покрытие путей - все ли возможные пути через заданную часть кода были выполнены и протестированы?

· Покрытие функций - каждая ли функция программы была выполнена

· Покрытие вход/выход - все ли вызовы функций и возвраты из них были выполнены

Для программ с особыми требованиями к безопасности часто требуется продемонстрировать, что тестами достигается 100 % покрытие для одного из критериев. Некоторые из приведённых критериев покрытия связаны между собой; например, покрытие путей включает в себя и покрытие условий и покрытие операторов. Покрытие операторов не включает покрытие условий, как показывает этот код на Си:

printf("this is ");

printf("a positive integer");

Если здесь bar = −1, то покрытие операторов будет полным, а покрытие условий - нет, так как случай несоблюдения условия в операторе if - не покрыт. Полное покрытие путей обычно невозможно. Фрагмент кода, имеющий n условий содержит 2n путей; конструкция цикла порождает бесконечное количество путей. Некоторые пути в программе могут быть не достигнуты из-за того, что в тестовых данных отсутствовали такие, которые могли привести к выполнению этих путей. Не существует универсального алгоритма, который решал бы проблему недостижимых путей (этот алгоритм можно было бы использовать для решения проблемы останова). На практике для достижения покрытия путей используется следующий подход: выделяются классы путей (например, к одному классу можно отнести пути отличающиеся только количеством итераций в одном и том же цикле), 100 % покрытие достигнуто, если покрыты все классы путей (класс считается покрытым, если покрыт хотя бы один путь из него).

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

Практическое применение

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

Степень покрытия кода обычно выражают в виде процента. Например, «мы протестировали 67 % кода». Смысл этой фразы зависит от того какой критерий был использован. Например, 67 % покрытия путей - это лучший результат чем 67 % покрытия операторов. Вопрос о связи значения покрытия кода и качеством тестового набора ещё до конца не решён.

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

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

Введение

В среднем тестирование отнимает 50% времени и 50% стоимости от общей сметы проекта (обязательно учитывайте это, закладывая бюджет). В больших компаниях (Intel, IBM, Microsoft) за каждым разработчиком закреплен личный тестировщик. Прошло то время, когда эту работу выполнял второсортный программист, которого еще не подпускали к самостоятельному кодированию (мол, прежде чем допускать свои ошибки, сначала пусть учатся на чужих). Сегодня тестировщик - это высококвалифицированный и хорошо оплачиваемый специалист, в услугах которого нуждаются тысячи фирм и который никогда не сидит без работы.

Когда вам скажут, что жизненный цикл продукта состоит из проектирования, реализации, тестирования и поддержки - не верьте! Тестирование сопровождает проект всю его жизнь - от момента рождения до самой смерти. Проектировщик закладывает механизмы самодиагностики и вывода "телеметрической" информации. Разработчик тестирует каждую запрограммированную им функцию (тестирование на микроуровне). Бета-тестеры проверяют работоспособность всего продукта в целом. У каждого из них должен быть четкий план действий, в противном случае тестирование провалится, еще не начавшись.

В идеале для каждой функции исходного кода разрабатывается набор автоматизированных тестов, предназначенных для проверки ее работоспособности. Лучше всего поручить эту работу отдельной группе программистов, поставив перед ними задачу: разработать такой пример, на котором функция провалится. Вот, например, функция сортировки. Простейший тест выглядит так. Генерируем произвольные данные, прогоняем через нее и если для каждого элемента N условие N <= N + 1 (N >= N + 1 для сортировки по убыванию) истинно, считаем, что тест пройдет правильно. Но ведь этот тест неправильный! Необходимо убедиться, что на выходе функции присутствуют все исходные данные и нет ничего лишнего! Многие функции нормально сортируют десять или даже тысячу элементов, но спотыкаются на одном или двух (обычно это происходит при сортировке методом деления напополам). А если будет ноль сортируемых элементов? А если одна из вызываемых функций (например, malloc), возвратит ошибку - сможет ли тестируемая функция корректно ее обработать? Сколько времени (системных ресурсов) потребуется на сортировку максимально возможного числа элементов? Неоправданно низкая производительность - тоже ошибка!

Существует два основных подхода к тестированию - черный и белый ящики. "Черный ящик" - это функция с закрытым кодом, проверка которого сводится к тупому перебору всех комбинаций аргументов. Очевидно, что подавляющее большинство функций не могут быть протестированы за разумное время (количество комбинаций слишком велико). Код белого ящика известен и тестировщик может сосредоточить свое внимание на пограничных областях. Допустим, в функции есть ограничение на предельно допустимую длину строки в MAX_LEN символов. Тогда следует тщательно исследовать строки в MAX_LEN - 1, MAX_LEN и MAX_LEN + 1 символов, поскольку ошибка "в плюс-минус один байт" - одна из самых популярных.

Тест должен задействовать все ветви программы, чтобы после его выполнения не осталось ни одной незадействованной строчки кода. Соотношение кода, который хотя бы раз получил выполнение, к общему коду программы, называется покрытием (coverage) и для его измерения придумано множество инструментов - от профилировщиков, входящих в штатный комплект поставки компиляторов, до самостоятельных пакетов, лучшим из которых является NuMega True Coverage.

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

Всегда транслируйте программу с максимальным уровнем предупреждений (для Microsoft Visual C++ это ключ /W4), обращая внимание на все сообщения компилятора. Некоторые, наиболее очевидные ошибки обнаруживаются уже на этом этапе. Сторонние верификаторы кода (lint, smatch) еще мощнее и распознают ошибки, с которыми трансляторы уже не справляются.

Регистрация ошибок

Завалить программу - проще всего. Зафиксировать обстоятельства сбоя намного сложнее. Типичная ситуация: тестировщик прогоняет программу через серию тестов. Непройденные тесты отправляются разработчику, чтобы тот локализовал ошибку и исправил баги. Но у разработчика эти же самые тесты проходят успешно! А, он уже все переделал, перекомпилировал с другими ключами и т.д. Чтобы этого не происходило, используйте системы управления версиями - Microsoft Source Safe или никсовый CVS.

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

Самыми коварными являются "плавающие" ошибки, проявляющиеся с той или иной степенью вероятности - девятьсот прогонов программа проходит нормально, а затем неожиданно падает без всяких видимых причин. Эй, кто там орет, что такого не бывает? Машина, дескать, детерминирована, и если железо исправно, то баг либо есть, либо нет. Ага, разбежались! Многопоточные приложения и код, управляющий устройствами ввода/вывода, порождают особый класс невоспроизводимых ошибок, некоторые из которых могут проявляться лишь раз в несколько лет! Вот типичный пример:

f1() {int x = strlen(s); s[x] = "*"; s = 0;} // поток 1

f2() {printf("%s\n", s);} // поток 2

Листинг 1. Пример плавающей ошибки.

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

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

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

Рисунок 1. Вот к чему приводят ошибки проектирования при загрузке системы реальными данными.

Бета-тестирование

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

Уронив программу (или добившись от нее выдачи неверных данных), бета-тестер должен суметь воспроизвести сбой, т.е. выявить наиболее короткую последовательность операций, приводящую к ошибке. А сделать это ой как непросто! Попробуй-ка вспомнить, какие клавиши были нажаты! Что? Не получается?! Су... Используйте клавиатурные шпионы. На любом хакерском сайте их навалом. Пусть поработают на благо народа (не вечно же пароли похищать). Шпионить за мышью намного сложнее - приходится сохранять не только позицию курсора, но координаты всех окон или задействовать встроенные макросредства (по типу Visual Basic"a в Word"е). В общем, мышь - это саксь и маст дай. Нормальные бета-тестеры обходятся одной клавиатурой. Полный протокол нажатий сокращает круг поиска ошибки, однако с первого раза воспроизвести сбой удается не всегда и не всем.

В процессе тестирования приходится многократно выполнять одни и те же операции. Это раздражает, ненадежно и непроизводительно. В штатную поставку Windows 3.x входил клавиатурный проигрыватель, позволяющий автоматизировать такие операции. Теперь же его приходится приобретать отдельно. Впрочем, такую утилиту можно написать и самостоятельно. В этом помогут функции FindWindow и SendMessage.

Тестируйте программу на всей линейке операционных систем: Windows 98, Windows 2000, Windows 2003 и т.д. Различия между ними очень значительны. Что стабильно работает под одной осью, может падать под другой, особенно если она перегружена кучей конфликтующих приложений. Ладно, если это кривая программа Васи Пупкина (тут на пользователя можно и наехать), но если ваша программа не уживается в MS Office или другими продуктами крупных фирм, бить будут вас. Никогда не меняйте конфигурацию системы в процессе тестирования! Тогда будет трудно установить, чей это баг. Хорошая штука - виртуальные машины (VM Ware, Microsoft Virtual PC). На одном компьютере можно держать множество версий операционных систем с различной комбинацией установленных приложений - от стерильной до полностью захламленной. При возникновении ошибки состояние системы легко сохранить на жесткий диск, обращаясь к нему впоследствии столько раз, сколько потребуется.

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

Методы

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

Методы можно разделить на статические и динамические.

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

Динамические техники следующие:

1. Тестирование методом белого ящика. Это подробное исследование внутренней логики и структуры программы. При этом необходимо знание исходного кода.
2. Тестирование методом черного ящика. Данная техника не требует каких-либо знаний о внутренней работе приложения. Рассматриваются только основные аспекты системы, не связанные или мало связанные с ее внутренней логической структурой.
3. Метод серого ящика. Сочетает в себе предыдущие два подхода. Отладка с ограниченным знанием о внутреннем функционировании приложения сочетается со знанием основных аспектов системы.

Прозрачное тестирование

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

Тестирование программ методом белого ящика обладает следующими преимуществами:

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

Недостатки:

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

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

Основные разновидности:

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

2) отладка ветвления имеет целью исследование каждой опции (истинной или ложной) каждого оператора управления, который также включает в себя объединенное решение;

3) тестирование основного пути, которое позволяет тестировщику установить меру логической сложности процедурного проекта для выделения базового набора путей выполнения;

4) проверка потока данных - стратегия исследования потока управления путем аннотации графа информацией об объявлении и использовании переменных программы;

5) тестирование циклов - полностью сосредоточено на правильном выполнении циклических процедур.

Поведенческая отладка

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

Преимущества такого подхода:

• эффективность для большого сегмента кода;
• простота восприятия тестировщиком;
• перспектива пользователя четко отделена от перспективы разработчика (программист и тестировщик независимы друг от друга);
• более быстрое создание теста.

Тестирование программ методами черного ящика имеет следующие недостатки:

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

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

1) эквивалентное разбиение, которое может уменьшить набор тестовых данных, так как входные данные программного модуля разбиваются на отдельные части;

2) краевой анализ фокусируется на проверке границ или экстремальных граничных значений - минимумах, максимумах, ошибочных и типичных значениях;

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

4) графы причинно-следственных связей - методика, основанная на создании графов и установлении связи между действием и его причинами: тождественность, отрицание, логическое ИЛИ и логическое И - четыре основных символа, выражающие взаимозависимость между причиной и следствием;

5) проверка ортогональных массивов, применяемая к проблемам с относительно небольшой областью ввода, превышающей возможности исчерпывающего исследования;

6) тестирование всех пар - техника, набор тестовых значений которой включает все возможные дискретные комбинации каждой пары входных параметров;

Тестирование методом черного ящика: примеры

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

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

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

Какое количество тестов необходимо произвести, чтобы проверить все возможные значения для 4 окон флажка и одного двухпозиционного поля, задающего время в секундах? На первый взгляд расчет прост: 4 поля с двумя возможными состояниями - 24 = 16, которые необходимо умножить на число возможных позиций от 00 до 99, то есть 1600 возможных тестов.

Тем не менее этот расчет ошибочен: мы можем определить, что двухпозиционное поле может также содержать пробел, т. е. оно состоит из двух буквенно-цифровых позиций и может включать символы алфавита, специальные символы, пробелы и т. д. Таким образом, если система представляет собой 16-битный компьютер, то получится 216 = 65 536 вариантов для каждой позиции, результирующих в 4 294 967 296 тестовых случаев, которые необходимо умножить на 16 комбинаций для флажков, что в общей сложности дает 68 719 476 736. Если их выполнить со скоростью 1 тест в секунду, то общая продолжительность тестирования составит 2 177,5 лет. Для 32 или 64-битных систем, длительность еще больше.

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

Эквивалентное разбиение

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

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

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

Например, в (1/x) 1/2 используется три последовательности данных, три эквивалентных разбиения:

1. Все положительные числа будут обрабатываться таким же образом и должны давать правильные результаты.

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

3. Ноль будет обрабатываться отдельно и даст ошибку «деление на ноль». Это раздел с одним значением.

Таким образом, мы видим три различных раздела, один из которых сводится к единственному значению. Есть один «правильный» раздел, дающий достоверные результаты, и два «неправильных», с некорректными результатами.

Краевой анализ

Обработка данных на границах эквивалентного разбиения может выполняться иначе, чем ожидается. Исследование граничных значений - хорошо известный способ анализа поведения ПО в таких областях. Эта техника позволяет выявить такие ошибки:

• неправильное использование операторов отношения (<,>, =, ≠, ≥, ≤);
• единичные ошибки;
• проблемы в циклах и итерациях,
• неправильные типы или размер переменных, используемых для хранения информации;
• искусственные ограничения, связанные с данными и типами переменных.

Полупрозрачное тестирование

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

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

• архитектурная модель;
• унифицированный язык моделирования (UML);
• модель состояний (конечный автомат).

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

Такие методы тестирования обладают следующими преимуществами:

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

Недостатки:

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

Другое название техники серого ящика - полупрозрачная отладка.

1) ортогональный массив - использование подмножества всех возможных комбинаций;

2) матричная отладка с использованием данных о состоянии программы;

3) проводимая при внесении новых изменений в ПО;

4) шаблонный тест, который анализирует дизайн и архитектуру добротного приложения.

тестирования ПО

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

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

Ниже приведены основные отличия трех динамических техник тестирования - дана таблица сравнения между тремя формами отладки ПО.

Аспект	Метод черного ящика	Метод серого ящика	Метод белого ящика
Наличие сведений о составе программы	Анализируются только базовые аспекты	Частичное знание о внутреннем устройстве программы	Полный доступ к исходному коду
Степень дробления программы
Кто производит отладку?	Конечные пользователи, тестировщики и разработчики	Конечные пользователи, отладчики и девелоперы	Разработчики и тестировщики
	Тестирование базируется на внешних внештатных ситуациях.	Диаграммы БД, диаграммы потока данных, внутренние состояния, знание алгоритма и архитектуры	Внутреннее устройство полностью известно
Степень охвата	Наименее исчерпывающая и требует минимума времени		Потенциально наиболее исчерпывающая. Требует много времени
Данные и внутренние границы	Отладка исключительно методом проб и ошибок	Могут проверяться домены данных и внутренние границы, если они известны	Лучшее тестирование доменов данных и внутренних границ
Пригодность для тестирования алгоритма

Автоматизация

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

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

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

Тестовые инструменты могут быть классифицированы по-разному. Следующее деление основано на поддерживаемых ими задачах:

• управление тестированием, которое включает поддержку управления проектом, версиями, конфигурациями, риск-анализ, отслеживание тестов, ошибок, дефектов и инструменты создания отчетов;
• управление требованиями, которое включает хранение требований и спецификаций, их проверку на полноту и многозначность, их приоритет и отслеживаемость каждого теста;
• критический просмотр и статический анализ, включая мониторинг потока и задач, запись и хранение комментариев, обнаружение дефектов и плановых коррекций, управление ссылками на проверочные списки и правила, отслеживание связи исходных документов и кода, статический анализ с обнаружением дефектов, обеспечением соответствия стандартам написания кода, разбором структур и их зависимостей, вычислением метрических параметров кода и архитектуры. Кроме того, используются компиляторы, анализаторы связей и генераторы кросс-ссылок;
• моделирование, которое включает инструменты моделирования бизнес-поведения и проверки созданных моделей;
• разработка тестов обеспечивает генерацию ожидаемых данных исходя из условий и интерфейса пользователя, моделей и кода, управление ими для создания или изменения файлов и БД, сообщений, проверки данных исходя из правил управления, анализа статистики условий и рисков;
• критический просмотр путем ввода данных через графический интерфейс пользователя, API, командные строки с использованием компараторов, помогающих определить успешные и неудавшиеся тесты;
• поддержка сред отладки, которая позволяет заменить отсутствующее оборудование или ПО, в т. ч. симуляторы оборудования на основе подмножества детерминированного выхода, эмуляторы терминалов, мобильных телефонов или сетевого оборудования, среды для проверки языков, ОС и аппаратного обеспечения путем замены недостающих компонентов драйверами, фиктивными модулями и др., а также инструменты для перехвата и модификации запросов ОС, симуляции ограничений ЦПУ, ОЗУ, ПЗУ или сети;
• сравнение данных файлов, БД, проверка ожидаемых результатов во время и по окончании тестирования, в т. ч. динамическое и пакетное сравнение, автоматические «оракулы»;
• измерение покрытия для локализации утечек памяти и некорректного управления ею, оценки поведения системы в условиях симулированной нагрузки, генерации нагрузки приложений, БД, сети или серверов по реалистичным сценариям ее роста, для измерения, анализа, проверки и отчета о системных ресурсах;
• обеспечение безопасности;
• тестирование производительности, нагрузки и динамический анализ;
• другие инструменты, в т. ч. для проверки правописания и синтаксиса, сетевой безопасности, наличия всех страниц веб-сайта и др.

Перспектива

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

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

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

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

Жизненный цикл разработки программного обеспечения – это процедурный процесс в разработке программного продукта. Этот процесс осуществляется серией шагов, которые объясняют в целом идею, лежащую в основе разработки программного продукта.

Классификация жизненного цикла процесса разработки программного обеспечения происходит следующим образом:

1. Планирование
2. Анализ
3. Дизайн
4. Разработка программного обеспечения
5. Реализация
6. Развертывание
7. Техническое обслуживание

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

Введение в тестирование программного обеспечения

Ошибка: ошибка или заблуждение - это человеческое действие, которое производит неправильный или неверный результат.

Дефект (баг, неисправность): сбой в системе или продукте, который может привести к сбою или неисправности компонента.

Отказ: это разница между фактическим и ожидаемым результатом.

Риск: риск - это фактор, который может привести к отрицательным результатам или возможности убытка, или ущерба.

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

1. Обнаружение дефектов
2. Обретение уверенности и предоставление информации об уровне качества
3. Предотвращение дефектов

Область применения тестирования программного обеспечения

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

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

Ключевые понятия

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

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

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

Верификация и Валидация: тестирование программного обеспечения проводится с учетом этих двух факторов.

1. Верификация: проверяет, разработан ли данный продукт согласно спецификации.
2. Валидация: проверяет, соответствует ли продукт требованиям клиентов.

Обеспечение качества ПО: тестирование программного обеспечения является важной частью обеспечения качества. Обеспечение качества - это деятельность, которая подтверждает пригодность продукта, заботу о качестве товара и обеспечение соблюдения требований заказчика.

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

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

Тестирование программного обеспечения классифицируется на два основных типа: ручное и автоматизированное тестирование.

Инструкции по сценарию тестирования:

• Black Box (черный ящик) тестирование
• White Box (белый ящик) тестирование
• Gray Box (серый ящик) тестирование

Уровни тестирования программного обеспечения жизненного цикла включают в себя:

• Модульное тестирование
• Интеграционное тестирование
• Системное тестирование
• Приемочное тестирования (альфа-тестирование и бета-тестирование)

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

• Функциональное тестирование
• Тестирование производительности (нагрузочное тестирование и стресс-тестирование)
• Дымовое тестирование
• Санитарное тестирование (проверка согласованности)
• Регрессионное тестирование
• Тестирование восстановления.
• Юзабилити-тестирование
• Тестирование на совместимость
• Тестирование конфигурации
• Исследовательское тестирование

Автоматизированное тестирование

Ручное тестирование - трудоемкий процесс. Автоматизация тестирования предполагает автоматизировать ручной процесс. Автоматизация тестирования - это процесс написания компьютерной программы в виде скриптов для тестирования, который обычно делается вручную. Некоторыми популярными средствами автоматизации являются Winrunner, Quick Test Professional (QTP), LoadRunner, SilkTest, Rational Robot, и т. д. Средства автоматизации также включает в себя сервисные инструменты, такие как TestDirector и многие другие.

Методологии тестирования программного обеспечения

Существуют различные методики тестирования доступные для разработки и тестирования программного продукта. Этими моделями являются:

• Каскадная модель
• V Модель
• Спиральная модель
• Рационального унифицированный процесс
• Гибкая модели
• Быстрая разработка приложений

Тестовые артефакты

В процессе тестирования программного обеспечения можно произвести различные артефакты, такие как:

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

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

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

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

Сценарий тестирования: тестовый сценарий представляет собой сочетание теста, процедуры тестирования и данных испытаний.

Тестовый набор: это сборник тестовых случаев.

Процесс тестирование программного обеспечения

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

1. Создание плана тестирования
2. Дизайн тест-кейсов
3. Описание тестовых случаев
4. Обзор тестовых случаев
5. Выполнение теста
6. Изучение результатов тестов
7. Составление конечного обзора

Ниже приведены примеры тестирования:

Тестирование программного обеспечения для входа на страницу системы:

цель: пользователь должен иметь возможность перейти на главную страницу.

Предпосылки:

1. Программное обеспечение должно быть совместимо с операционной системой.
2. Должна появиться страница «ввода логина».
3. Текстовые поля идентификатора пользователя и пароля должны быть доступны с соответствующими метками.
4. Должны быть в наличии кнопки «Войти» и «Отмена» с соответствующими подписями.

Тест 1

Название теста: проверка требований пользовательского интерфейса.

Шаги/действия: Пользователь просматривает страницу, чтобы проверить, включает ли она в себя ID пользователя и пароль в текстовых полях с соответствующими наклейками. Кроме того, кнопки «Войти» и «Отмена» должны быть доступны с соответствующими подписями.

Ожидаемые результаты: экран отображает интерфейс пользователя согласно требованиям пользователя.

Тест 2

Название теста: Текстовое поле для идентификатора пользователя следует: 1) разрешить только буквенные символы {от a до z, и от A до Z}, 2) не разрешать специальные символы, такие как {"$","#","!","~","*",...}, 3) не разрешать цифровые символы {0-9}.

Шаги/действия: 1) Пользователь вводит числа в текстовое поле. 2) Пользователь вводит алфавитно-цифровые данные в текстовом поле.

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

Тест 3

Название теста: проверка функциональности текстового поля для пароля: 1) текстовое поле для пароля должно принять шесть или более символов. 2) данные должны отображаться в зашифрованном виде.

Шаги/действия: 1) Пользователь вводит только два символа в текстовом поле пароля. 2) Пользователь вводит более шести символов в текстовом поле пароля. 3) Пользователь проверяет отображаются ли данные в зашифрованном виде.

Ожидаемые Результаты: Когда пользователь вводит менее шести символов в текстовом поле пароль отображается сообщение об ошибке. Система принимает данные, когда пользователь входит более чем шесть символов в текстовом поле пароля. Система отображает данные в зашифрованном виде.

Тест 4

Название теста: проверка функциональности кнопки «Войти».

Шаги/действия: 1) Пользователь проверяет, включена или отключена кнопка «Войти». 2) Пользователь нажимает на кнопку «Войти» и ожидает, просмотра главной страницы приложения.

Ожидаемые результаты: 1) система отображает кнопку «Войти». 2) Система перенаправляет пользователя на главную страницу приложения, как только он нажимает на кнопку «Войти».

Тест 5

Название теста: проверка функциональности кнопки «Отмена».

Шаги/действия: 1) Пользователь проверяет, включена или отключена кнопка «Отмена». 2) Пользователь проверяет, сбрасываются ли текстовые поля ID пользователя и пароль при нажатии кнопки «Отмена».

Ожидаемые результаты: 1) система отображает кнопки «Отмена». 2) система сбрасывает данные текстовых полей идентификатора пользователя и пароля, когда пользователь нажимает на кнопку «Отмена».

Методы поиска неисправностей при тестировании программного обеспечения

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

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

Метрика программного обеспечения

Когда программное обеспечение находится на стадии разработки и после того, как система готова к использованию возникает необходимость измерения программного обеспечения. Хотя трудно измерить такое абстрактное ограничение, но без этого не обойтись. Элементы, которые не могут быть измерены, должны быть под контролем. Есть некоторые важные аспекты пользы от измерения программного обеспечения:

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

1. Перерасход средств
2. Определение, источника проблемы
3. Уточнение целей

Даст ответы на такие вопросы как:

1. Какова оценка каждого процесса деятельности?
2. Каково качество кода, который был разработан?
3. Как можно улучшить слаборазвитый код?

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

Некоторыми общими метриками программного обеспечения являются:

• Покрытие кода
• Цикломатическая сложность
• Сплоченность
• Связь
• Функция точечного анализа
• Время выполнения
• Источник строк кода
• Ошибка в строках кода

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

Тестирование программного обеспечения в качестве карьеры

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

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

Особым методом исследования управления, наиболее популярным в со­временных условиях и, пожалуй, достаточно эффективным является метод тестирования.

Существует множество определений теста. Тест - это удовлетворяющая критериям исследования эмпирико-аналитическая процедура. Очень общее определение. Но есть определения и более конкретные. Например: тест - это система высказываний, позволяющая получить объективное отражение реально существующих отношений между людьми, их свойств, признаков и количественных параметров.

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

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

Большую роль в исследовании при помощи тестирования играет конст­рукция теста.

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

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

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

Существуют правила формулировки высказываний. Они включают сле­дующие положения(схема 34 ).

А) высказывания должны быть короткими, не более одного придаточного предложения;

Б) понятны для всех без исключения исследуемых (респондентов);

В) в высказываниях не должно быть намека на правильный, одобряемый или ожидаемый ответ;

Г) структурированные ответы по каждому из высказываний желательно иметь с одним и тем же числом альтернатив (не менее 5 и не более 11);

Д) тест не может состоять целиком из предложений, в которых высказываются только позитивные или только негативные суждения;

е) в каждом высказывании теста следует утверждать что-нибудь одно.

При составлении теста необходимо учитывать его основные характерис­тики.

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

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

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

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

Тестирование.

Тестирование (англ. test - испытание, проверка) - эксперементальный метод психродиагностики, применяемый в эмпирических социологических исследованиях, а также метод измерения и оценки различных психологических качеств и состояний индивида.

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

Основоположники тестирования - Ф.Гальтон, Ч.Спирман, Дж.Каттел, А.Бине, Т.Симон. Сам термин "умственный тест" придумал Кеттел в 1890 г. Начало развития современной тестологии массового применения тестов на практике связано с именем французского врача Бине, разработавшего в соавторстве с Симоном метрическую шкалу умственного развития, известную под названием "тест Бине-Симона".

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

Тесты предъявляют требования:

Строгая формализация всех этапов тестирования,

Стандартизация заданий и условий их выполнения,

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

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

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

1) стандартная инструкция для испытуемого о цели и правилах выполнения заданий,

2) ключ шкалирования - соотнесение пунктов заданий со шкалами измеряемых качеств, указывающее, какой пункт заданий к какой шкале относится,

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

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

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

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

2) введение поправочных коэффициетнов с учетом характеристик выборки,

3)введение в практику тестирования невербального способа предъявления материала.

Тест состоит из двух частей:

а) стимулирующего материала (задача, инструкция или вопрос)

б) указаний относительно регистрации или интнграции полученых ответов.

Типичная для тестов стандартизация ситуации обеспечивает им в отличие от "свободного" наблюдения поведения большуюю объективность результатов.

Тесты классифицируются по разным признакам.

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

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

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

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

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

Разработка теста состоит из четырех этапов.

На первомэтапе развивается исходная концепция с формулировкой основных пунктов испытания или основных вопросов, носящих предварительный характер;

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

На третьем этапе тест проверяется повторно на той же самой популяции;

На четвертом - калибруется по отношению к возрасту, уровню образования и другим признакам популяции.

На всех этапах разработки теста необходимо учитывать:

а) диагностируемое свойство личности (размер, положение, индикатор) или только наблюдаемые его пpоявления (напpимеp, способности, уpовень знаний, темпеpамент, интеpесы, установки);

б) связанную с этим валидизацию метода, т.е. опpеделение того, насколько он измеpяет тpебуемое свойство;

в) величину выбоpки из популяции, на котоpой должна пpоводиться оценка метода;

г) стимулиpующий матеpиал (таблички, изобpажения, игpушки, фильмы);

д) влияние исследователя в пpоцессе инстpуктиpования, постановки задач, pазъяснений, ответов на вопpосы;

е) условия ситуации;

ж) такие фоpмы поведения испытуеого, котоpые свидетельствуют об измеpяемом свойстве;

з) шкалиpование pелевантных фоpм поведения;

и) сведение pезультатов по отдельным измеpяемым пунктам в общие значения (напpимеp, суммиpование ответов типа "Да");

к) фоpмулиpовку pезультатов в ноpмиpованной шкале оценок.

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

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

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

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

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

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

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

дним из видов эмпирических методов является тестирование.

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

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

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

При разработке первых тестов были выдвинуты два основных требования, которым должны удовлетворять «хорошие» тесты: валидность и надежность.

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

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

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

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

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

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

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

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

1) по особенностям используемых тестовых задач на тесты вербальные и тесты практические;

2) по формам процедуры обследования - на тесты групповые и индивидуальные;

3) по направленности - на тесты интеллекта и тесты личности;

4) в зависимости от наличия или отсутствия временных ограничений - на тесты скорости и тесты результативности;

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

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

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

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

Следующая разновидность тестов - индивидуально-ориентированные; они реализуют индивидуальный подход к диагностике психологических особенностей и поведения испытуемого.

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

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

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

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

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

Тесты скорости (англ. speed tests) - тип психодиагностических методик, в которых основным показателем продуктивности работы испытуемых является время выполнения (объем) задач тестовых. Такие тесты обычно включают большое количество однородных заданий (пунктов).

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

Кроме того, существуют и тесты, ориентированные на социально-психологический норматив или общественно заданный объективный содержательный эталон (например, ШТУР - школьный тест умственного развития).

В последнее время все большую популярность приобретает выделившийся из лабораторного психологического экспериментаметод тестирования.
Термин "тест" (по-английски - задача, или проба) был введен в 1890 г. в Англии. Тесты получили широкое распространение в детской психологии после 1905 г., когда во Франции были разработаны серии тестов для определения одаренности детей, и в практике психодиагностики после 1910 г., когда в Германии была разработана серия тестов для профессионального отбора.

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

Наиболее распространенные варианты теста: тест-опросник, тест-задание, проективный тест.

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

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

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

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

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

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

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

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

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

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

Таким образом, порочным является не сам тест, а его неправильное использование.

Социометрия: исследование межличностных отношений в группе.

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

Социометрическая процедура может иметь целью:

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

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

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

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

Введение

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

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

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

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

· Надёжность

· Сопровождаемость

· Практичность

· Эффективность

· Мобильность

· Функциональность

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

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

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

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

· Функциональное тестирование (functional testing)

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

· Тестирование производительности (perfomance/stress testing)

· Тестирование стабильности (stability/load testing)

· Тестирование удобства использования (usability testing)

· Тестирование интерфейса пользователя (UI testing)

· Тестирование безопасности (security testing)

· Тестирование локализации (localization testing)

· Тестирование совместимости (compatibility testing)

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

· Тестирование чёрного ящика (black box)

· Тестирование белого ящика (white box)

· Тестирование серого ящика (gray 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 testing)

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

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

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

Системное тестирование — тестируется интегрированная система на её соответствие требованиям.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Регрессио́нное тести́рование (англ. regression testing, от лат. regressio — движение назад) — собирательное название для всех видов тестирования программного обеспечения, направленных на обнаружение ошибок в уже протестированных участках исходного кода. Такие ошибки — когда после внесения изменений в программу перестает работать то, что должно было продолжать работать, — называют регрессионными ошибками (англ. regression bugs).

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

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

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

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

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

Цитата

«Фундаментальная проблема при сопровождении программ состоит в том, что исправление одной ошибки с большой вероятностью (20-50%) влечет появление новой. Поэтому весь процесс идет по принципу "два шага вперед, шаг назад".

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

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

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

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

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

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

Покрытие кода — мера, используемая при тестировании программного обеспечения. Она показывает процент, насколько исходный код программы был протестирован. Техника покрытия кода была одной из первых методик, изобретённых для систематического тестирования ПО. Первое упоминание покрытия кода в публикациях появилось в 1963 году.

Критерии

Существует несколько различных способов измерения покрытия, основные из них:

· Покрытие операторов — каждая ли строка исходного кода была выполнена и протестирована?

· Покрытие условий — каждая ли точка решения (вычисления истинно ли или ложно выражение) была выполнена и протестирована?

· Покрытие путей — все ли возможные пути через заданную часть кода были выполнены и протестированы?

· Покрытие функций — каждая ли функция программы была выполнена

· Покрытие вход/выход — все ли вызовы функций и возвраты из них были выполнены

Для программ с особыми требованиями к безопасности часто требуется продемонстрировать, что тестами достигается 100 % покрытие для одного из критериев. Некоторые из приведённых критериев покрытия связаны между собой; например, покрытие путей включает в себя и покрытие условий и покрытие операторов. Покрытие операторов не включает покрытие условий, как показывает этот код на Си:

printf("this is ");

if (bar < 1)

printf("not ");

printf (" a positive integer ");

Если здесь bar = −1, то покрытие операторов будет полным, а покрытие условий — нет, так как случай несоблюдения условия в операторе if — не покрыт. Полное покрытие путей обычно невозможно. Фрагмент кода, имеющий n условий содержит 2n путей; конструкция цикла порождает бесконечное количество путей. Некоторые пути в программе могут быть не достигнуты из-за того, что в тестовых данных отсутствовали такие, которые могли привести к выполнению этих путей. Не существует универсального алгоритма, который решал бы проблему недостижимых путей (этот алгоритм можно было бы использовать для решения проблемы останова). На практике для достижения покрытия путей используется следующий подход: выделяются классы путей (например, к одному классу можно отнести пути отличающиеся только количеством итераций в одном и том же цикле), 100 % покрытие достигнуто, если покрыты все классы путей (класс считается покрытым, если покрыт хотя бы один путь из него).

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

Практическое применение

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

Степень покрытия кода обычно выражают в виде процента. Например, «мы протестировали 67 % кода». Смысл этой фразы зависит от того какой критерий был использован. Например, 67 % покрытия путей — это лучший результат чем 67 % покрытия операторов. Вопрос о связи значения покрытия кода и качеством тестового набора ещё до конца не решён.

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

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