Тестирование программного обеспечения является неотъемлемой частью жизненного цикла разработки программного обеспечения. Прочитайте эту статью чтобы узнать основные понятия и различные шаги тестирования программного обеспечения
Жизненный цикл разработки программного обеспечения – это процедурный процесс в разработке программного продукта. Этот процесс осуществляется серией шагов, которые объясняют в целом идею, лежащую в основе разработки программного продукта.
Классификация жизненного цикла процесса разработки программного обеспечения происходит следующим образом:
Тестирование программного обеспечения является важным этапом жизненного цикла продукта, так как это будет определять, правильно ли работает продукт и является ли он эффективным в соответствии с требованиями клиентов.
Ошибка: ошибка или заблуждение - это человеческое действие, которое производит неправильный или неверный результат.
Дефект (баг, неисправность): сбой в системе или продукте, который может привести к сбою или неисправности компонента.
Отказ: это разница между фактическим и ожидаемым результатом.
Риск: риск - это фактор, который может привести к отрицательным результатам или возможности убытка, или ущерба.
Таким образом, тестирование программного обеспечения - это процесс поиска дефектов/ошибок в системе, которые происходят из-за ошибок в программе, которые могут привести к выходу из строя результирующего продукта. Короче говоря, тестирование программного обеспечения имеет различные цели и задачи, которые часто включают в себя:
Основной функцией тестирования является обнаружение ошибок для того, чтобы раскрыть их и обнаружить. Область включает в себя выполнение кода в различных средах, а также изучение аспектов кода - делает ли программа то, что должна делать и функционирует ли в соответствии со спецификациями?
Рекомендуется начинать тестирование с начальных стадий разработки программного обеспечения. Это не только помогает в исправлении ошибок, перед последним этапом, но также уменьшает переделки поиске ошибок на начальных стадиях. Это экономит время и является экономически эффективным. Тестирование программного обеспечения - это непрерывный процесс, который потенциально бесконечен, но может быть остановлено, из-за отсутствия времени или бюджета. Для этого требуется достижение максимальной прибыли с хорошим качеством продукта, в рамках ограничения времени и денег. Тестер должен следовать некоторым процедурным способам, посредством которых он может делать выводы. Чтобы помочь тестерам выполнять эту повседневную деятельность, есть базовый набор, который осуществляется в виде контрольных перечней.
Дефекты и отказы: как мы уже обсуждали ранее, дефекты возникают не только из-за ошибок кодирования, но наиболее часто из-за пробелов в нефункциональных требованиях, таких как удобство использования, тестируемость, масштабируемость, ремонтопригодность, производительность и безопасность. Отказы возникают в результате отклонения между фактическим и ожидаемым результатом. Но не все дефекты приводят к сбоям. Дефект может обернуться неудачей из-за изменений в окружающей среде или изменения конфигурации системных требований.
Входные комбинации и предпосылки: Тестирование всех комбинаций входов и начального состояния (предпосылки), не представляется возможным. Это означает что достаточно сложно найти большое количество нечастых дефектов.
Статический и динамический анализ: статическое тестирование не требует исполнения кода для обнаружения дефектов, а при динамических испытаниях, программный код выполняется, лишь для того чтобы продемонстрировать результаты тестов.
Верификация и Валидация: тестирование программного обеспечения проводится с учетом этих двух факторов.
Обеспечение качества ПО: тестирование программного обеспечения является важной частью обеспечения качества. Обеспечение качества - это деятельность, которая подтверждает пригодность продукта, заботу о качестве товара и обеспечение соблюдения требований заказчика.
Типы тестирования программного обеспечения - это группа контрольных мероприятий, направленных на тестирование компонента или системы, ориентированной на определенную цель тестирования; нефункциональные требования, такие как удобство использования, тестируемость и надежность. Различные виды тестирования используются с общей целью нахождение дефектов этого конкретного компонента.
Тестирование программного обеспечения классифицируется на два основных типа: ручное и автоматизированное тестирование.
Инструкции по сценарию тестирования:
Уровни тестирования программного обеспечения жизненного цикла включают в себя:
Другими видами тестирования программного обеспечения являются:
Ручное тестирование - трудоемкий процесс. Автоматизация тестирования предполагает автоматизировать ручной процесс. Автоматизация тестирования - это процесс написания компьютерной программы в виде скриптов для тестирования, который обычно делается вручную. Некоторыми популярными средствами автоматизации являются Winrunner, Quick Test Professional (QTP), LoadRunner, SilkTest, Rational Robot, и т. д. Средства автоматизации также включает в себя сервисные инструменты, такие как TestDirector и многие другие.
Существуют различные методики тестирования доступные для разработки и тестирования программного продукта. Этими моделями являются:
В процессе тестирования программного обеспечения можно произвести различные артефакты, такие как:
Тест план: документ, описывающий полный объем работы по тестированию. Тест план – может быть использован для проверки и обеспечения того, чтобы продукт или система соответствует проектной спецификации.
Прослеживаемость матрицы: Это таблица, которая сопоставляет или разрабатывает документы для тестовых документов. Это подтверждает, что результаты теста верны, а также используется для изменения тестов, когда исходные документы будут изменены.
Тестовый случай: Прецедент и стратегия испытаний используются для проверки работоспособности отдельных компонентов, которые интегрированы с получением полученного продукта. Эти тест-кейсы разрабатываются с целью оценки применения способности или особенности.
Тестовые данные: при множественных наборах значений или данных, используемых для тестирования те же функциональные возможности той или иной функции в тест-кейсах, тест ценностей и переменчивой окружающей среды, компоненты собраны в отдельных файлах и хранятся в качестве тестовых данных.
Сценарий тестирования: тестовый сценарий представляет собой сочетание теста, процедуры тестирования и данных испытаний.
Тестовый набор: это сборник тестовых случаев.
Процесс тестирования программного обеспечения осуществляется в следующей последовательности, для того чтобы найти недостатки в программном обеспечении системы:
Ниже приведены примеры тестирования:
Тестирование программного обеспечения для входа на страницу системы:
цель: пользователь должен иметь возможность перейти на главную страницу.
Предпосылки:
Тест 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) система сбрасывает данные текстовых полей идентификатора пользователя и пароля, когда пользователь нажимает на кнопку «Отмена».
Поиск дефекта или неисправности на начальных этапах разработки программного обеспечения не только экономит время и деньги, но также является эффективным с точки зрения безопасности и доходности. По мере продвижения вперед в направлении разных уровнях программного обеспечения, он становится трудным и утомительным, чтобы вернуться для поиска проблем на начальные стадии программного обеспечения. Затраты также повышаются. Таким образом, рекомендуется начинать тестирование с начальной стадии жизненного цикла разработки программного обеспечения.
Наряду с типами, существуют различные методы тестирования программного обеспечения. Существует порядок, который будет следовать при нахождении ошибки в заявке. Эта процедура сочетается с жизненным циклом в виде бага, в зависимости от тяжести и приоритета ошибки. Этот жизненный цикл известен как ошибка жизненного цикла.
Когда программное обеспечение находится на стадии разработки и после того, как система готова к использованию возникает необходимость измерения программного обеспечения. Хотя трудно измерить такое абстрактное ограничение, но без этого не обойтись. Элементы, которые не могут быть измерены, должны быть под контролем. Есть некоторые важные аспекты пользы от измерения программного обеспечения:
Метрика программного обеспечения поможет избежать таких подводных камней, как:
Даст ответы на такие вопросы как:
Оно помогает в оценке качества программного обеспечения, затрат и усилий, оценки, сбора данных, оценки производительности и эффективности.
Некоторыми общими метриками программного обеспечения являются:
Короче говоря, измерение программного обеспечения нужно для контроля и совершенствования программного обеспечения системы. Программное обеспечение подлежит изменениям, по отношению к изменяющимся условиям окружающей среды, различным потребностям пользователей, а также вопросами конфигурации и совместимости. Это дает толчок к развитию более новых и обновленных версий программного обеспечения. Но также должен быть какой-нибудь источник легкого возвращения к старым версиям и эффективной на них работы.
Тестирование программного обеспечения - это хорошая возможность карьерного роста для тех, кто заинтересован в индустрии программного обеспечения. Видео тестирование игр является ответвлением тестирования программного обеспечения. Есть много отраслей промышленности, специализирующихся в этой области. Вам даже могут платить, чтобы вы испытывали видеоигры.
Тестирование программного обеспечения - это действительно огромное поле и точные знания имеют решающее значение для обеспечения качества разработанного программного обеспечения. Я надеюсь, что это учебное пособие по тестированию программного обеспечения должно дать вам ясное представление о различных видах тестирования программного обеспечения, методологий и различных стратегий тестирования.
Андрей Колесов
Вряд ли имеет смысл говорить о важности тестирования в общем процессе разработки ПО, ведь давно известно, что реализация каждого этапа жизненного цикла приложений является необходимым условием для появления качественного программного продукта. Но, сказав слова о равенстве всех видов работ, нужно признать: в течение всей истории разработки ПО - а она насчитывает более 50 лет - тестирование выступало в роли падчерицы, которой достается самая трудоемкая, рутинная и непрестижная работа * . Далеко за примерами ходить не нужно: авторские права разработчиков закреплены законодательством, их имена можно при желании легко узнать. А что нам известно о тех, кто тестирует приложения, и это при том, что именно на их долю приходится в среднем около трети затрат по созданию ПО?
Впрочем, в последнее время ситуация заметно меняется, и здесь можно выделить две основные тенденции. Первая - растет понимание необходимости промышленных методов тестирования, в частности с применением специальных средств автоматизации. Вторая - идет поиск возможностей для оптимизации затрат на выполнение данных работ с точки зрения общей организации бизнеса, в том числе с использованием модели аутсорсинга.
Нужно отметить парадоксальную ситуацию: при обилии методической литературы и курсов по проектированию и кодированию ПО наблюдается практически полное отсутствие материалов по тестированию и отладке! Как сказал известный американский автор книг по разработке ПО Джон Роббинс: "Даже если у вас есть специальное образование, бьюсь об заклад, что вы никогда не сталкивались со специальным курсом, посвященным отладке" (см. PC Week/RE, № 9/2004, с. 61).
Однако ситуация несколько меняется, одним из свидетельств чего являются проведенные в конце февраля в Москве компанией "Аплана" при поддержке московского представительства IBM практические семинары "Эффективная организация процессов тестирования в ходе разработки и сопровождения корпоративных систем". Тема оказалась настолько актуальной, что Центр технологий IBM не смог вместить всех желающих в один день, поэтому семинар пришлось проводить дважды. Изначально мероприятие было ориентировано на ИТ-подразделения корпораций, ведущие собственные внутрифирменные разработки, однако большой интерес к нему проявили и специализированные фирмы - создатели заказного и тиражируемого ПО. В общей сложности в семинарах приняли участие более 80 руководителей и специалистов корпоративных и ведомственных центров разработки и внедрения, а также ИТ-компаний.
Следует подчеркнуть, что, хотя в качестве инструментальной базы использовались продукты IBM Rational, основной акцент семинара был сделан на организационные и методические вопросы тестирования в контексте общего процесса разработки ПО и бизнес-функционирования предприятий в целом. Во многом именно такой подход предопределил активное участие специалистов в данном мероприятии.
Особенности организации тестирования
В первую очередь нужно отметить, что вопросы тестирования следует рассматривать в контексте всего жизненного цикла ПО, начиная от разработки ТЗ и заканчивая сопровождением приложений. Как известно, тестирование - это процедура обнаружения дефектов (ошибок) ПО до его промышленного использования. Очевидно, что трудоемкость такой работы связана с количеством самих ошибок, в связи с чем надо четко выделить основные причины их появления:
Есть еще один важный момент. Тестирование, в свою очередь, является лишь составляющей частью отладки - процесса доводки ПО после его написания до эксплуатационного состояния. Процесс этот включает две основные процедуры: обнаружение ошибок (тестирование) и поиск и устранение их причин. Однако, даже учитывая все возможные взаимосвязи этих работ (например, поиск причин ошибок требует проведения специального дополнительного тестирования), нужно подчеркнуть, что тестирование является достаточно автономным, независимым этапом жизненного цикла ПО. При этом подчеркнем, что повышение качества разработки (которое обратно пропорционально количеству ошибок в приложении) напрямую снижает затраты на устранение ошибок, но на объем тестирования влияет совсем не так сильно: его нужно проводить в любом случае и желательно "по полной программе".
Понятно также, что организация и методика тестирования в значительной степени зависят от целевого назначения разработки: коробочный продукт, заказной проект или внутрифирменный. И тут стоит еще раз обратить внимание на то, что прошедшие семинары были адресованы в первую очередь разработчикам ИТ-подразделений заказчиков. Объяснение этому простое: во-первых, объем разработок, выполняемых в таких компаниях и в специализированных ИТ-фирмах, по крайней мере соизмерим; во-вторых, в силу ряда причин задачи тестирования при выполнении внутрифирменных проектов достаточно специфичны и очень актуальны.
Говоря об особенностях процедур тестирования в ИТ-подразделениях, наверное, надо выделить три основных, весьма противоречивых аспекта.
Общие вопросы тестирования
Программа мероприятия включала как методические аспекты организации процессов тестирования, так и практические рекомендации по их применению. Ключевая идея в целом выглядит достаточно очевидной: повышение качества тестирования ПО при сохранении разумного уровня затрат на его проведение должно обеспечиваться за счет современных промышленных методов (организационных и технических) выполнения этих работ.
В ряде докладов специалистов компании "Аплана" речь, в частности, шла о типовых ситуациях, подкрепленных реальными примерами того, как можно уменьшить затраты на реализацию программных проектов (в том числе за счет выбора оптимальной конфигурации оборудования) и снизить бизнес-риски, правильно организовав процессы тестирования и использования соответствующих автоматизированных средств.
Рамки статьи не позволяют изложить вопросы применения конкретных инструментов детально. Более полезным сейчас представляется рассмотреть некоторые общие вопросы классификации задач тестирования. Они обсуждались в одном из докладов, но, как мне показалось, некоторые важные моменты в нем не были затронуты. Поэтому далее я приведу свои соображения, опираясь на мнение выступивших на семинаре экспертов.
Тестирование пронизывает весь жизненный цикл ПО, начиная от проектирования и заканчивая неопределенно долгим этапом эксплуатации. Эти работы напрямую связаны с задачами управления требованиями и изменениями, ведь целью тестирования является как раз возможность убедиться в соответствии программ заявленным требованиям.
Тестирование - процесс пошаговый. Наверное, имеет смысл разделить проверку работоспособности программ в ходе непосредственного написания кода (самим программистом) и после завершения основного этапа кодирования (скорее всего, специальными тестировщиками). Тут можно вспомнить о золотом правиле программирования: написание каждых 20-30 строк кода (тем более законченных процедур, функций) должно сопровождаться проверкой их работоспособности, хотя бы в каком-то основном режиме. В то же время нужно подчеркнуть и важное различие в проведении тестирования в ходе кодирования и по его завершении: в первом случае продолжать написание программы (а также запуск других тестовых примеров) желательно только после устранения ошибки, во втором осуществляется пакетное выполнение серии текстов с простой фиксацией их результатов.
Тестирование - процесс также итерационный. После обнаружения и исправления каждой ошибки обязательно следует повторение тестов, чтобы убедиться в работоспособности программы. Более того, для идентификации причины обнаруженной проблемы может потребоваться проведение специального дополнительного тестирования. При этом нужно всегда помнить о фундаментальном выводе, сделанном профессором Эдсжером Дейкстрой в 1972 г: "Тестирование программ может служить доказательством наличия ошибок, но никогда не докажет их отсутствие!".
Различные виды тестирования можно классифицировать и по следующим основным характеристикам (хотя любая категоризация является достаточно условной).
Функциональное и нагрузочное тестирование. Работы первого вида можно отнести к традиционным - проверка ПО на соответствие требованиям по функционалу *** . В последние годы заметно возросла актуальность относительно новых задач, таких, например, как анализ совместимости разрабатываемого продукта с различными программными и аппаратными платформами, приложениями и пр. Второй тип обычно связывают с задачами оценки производительности и масштабирования, но на самом деле он затрагивает гораздо более широкий круг проблем; выявление узких мест в коде программы, обнаружение "утечек" ресурсов и т. д.
Компонентное и интеграционное тестирование. Очевидно, что первый вид тестирования выполняется на более ранних этапах разработки (по мере создания законченных модулей), второй - на завершающем этапе. Принципиальное их различие заключается в том, что компонентное в основном базируется на методах "белого ящика" (учета внутренней логики и структуры программы), а интеграционное - на методах "черного ящика" (знание только внешних спецификаций). Соответственно существенная часть работы по проведению тестирования в первом случае ложится на проектировщиков и разработчиков ПО, во втором - на независимых тестеров.
Ручное и автоматизированное тестирование. По мере повышения сложности проекта доля задач, решаемых с помощью автоматизированных методов (использование скриптов, программ-имитаторов и пр.), неуклонно растет. Подавляющее число задач нагрузочного тестирования может решаться исключительно с их помощью.
Наверное, имеет смысл выделить тестирование текущей конфигурации системы и тестирование с учетом ее возможного развития. Анализ возможных проблем в будущем чаще всего связывается сегодня с задачами масштабирования, например повышения нагрузки на систему в результате увеличения числа пользователей. Хотя конечно же тут нужно иметь в виду более широкий круг вопросов, в частности перспективы смены платформы. Хотелось бы при этом подчеркнуть, что оценка масштабирования может (и должна!) производиться не только с помощью тестирования реального приложения, но и методами системного моделирования на уровне общей структуры ПО (о таком подходе в последние годы что-то стали забывать!).
Решение проблемы - центры тестирования
Как уже было сказано, ведущую роль в вопросах тестирования играют методология и организационная составляющая. Что же касается инструментария, то его роль в этом процессе вторична и выбор того или иного продукта для автоматизации задач тестирования определяется уже в зависимости от целей и специфики проекта, существующих предпочтений заказчика, бюджета. На рынке сейчас представлен целый спектр средств автоматизированного тестирования, в котором лидируют IBM Rational, Mercury, Segue, Compuware.
В рамках семинара специалистами компании "Аплана" рассматривались возможности автоматизированного тестирования на примере средств тестирования IBM Rational, которые в настоящее время получили значительное распространение среди российских разработчиков (см. врезку "Методология и инструментарий IBM Rational"). Обсуждались также различные сценарии их применения при создании ПО корпоративного уровня. Среди конкретных программных продуктов особое внимание было уделено наиболее популярной сегодня системе IBM Rational Robot.
Однако, несмотря на важность применения правильных методов и инструментов, возможно, более актуальным является изменение общего позиционирования работ по тестированию в общей структуре процесса разработки. В частности, это подразумевает необходимость выделения тестирования в отдельную услугу, реализуемую на внутрифирменном уровне или в режиме аутсорсинга.
"Аплана", специализируясь на разработке заказного ПО, осознала необходимость такого подхода на собственном опыте. В компании в соответствии с общепринятыми стандартами управления качеством была изначально сформирована собственная служба, которую год назад преобразовали в Центр тестирования, не только обеспечивающий решение внутренних задач своей фирмы, но и предоставляющий услуги внешним организациям.
Моделям взаимодействия клиентов с Центром тестирования и рассмотрению конкретных проектов было посвящено отдельное выступление на семинаре и, судя по реакции слушателей, такие предложения заинтересовали многих. И это не случайно, поскольку аутсорсинг услуг по тестированию является пока достаточно новым. Перечислим основные возможные модели взаимодействия:
В заключение стоит отметить еще один любопытный момент: проведя семинары, компания "Аплана" одной из первых в нашей стране фактически объявила о продвижении нового вида услуг в области разработки ПО. Первопроходцы же довольно часто попадают в двойственное положение. Так и на этом семинаре: бесплатный курс консалтинга и обучения пришлось дать не только потенциальным заказчикам, но и конкурентам...
* Не забывая о значимости вопросов тестирования, нужно помнить о том, что один из классиков современных методов разработки ПО, голландский профессор Эдсжер Дейкстра еще в конце 60-х годов прошлого столетия обосновал необходимость применения методов структурного программирования, исходя именно из задачи снижения трудозатрат на тестирование.
** Специфика тестирования заключается еще и в том, что в отличие от других этапов разработки ПО, имеющих достаточно формальные критерии их окончания, данный процесс, в общем случае, бесконечен. Ведь, как известно, "каждая последняя найденная ошибка является на самом деле предпоследней". Правильно определить реально необходимый объем тестирования - это отдельная непростая задача.
*** Говоря о тестировании, надо также обязательно упомянуть о важности верификации ПО (систематической процедуры проверки правильности). Тонкое различие между этими понятиями заключается в том, что тестирование базируется на возможности сравнения полученных результатов с эталонными. Однако есть достаточно большой класс задач, когда эталонных данных попросту нет. Классический пример такого варианта - построение сложных математических моделей с решением десятков тысяч дифференциальных уравнений, хотя аналогичные ситуации возникают и тогда, когда имеешь дело с бизнес-приложениями. В этом случае требуется включение в ПО дополнительных функций и проведение специальных исследований, чтобы у пользователя появилась уверенность (пусть даже не 100-%), что программа действительно работает правильно.
| Методология и инструментарий IBM Rational |
| Общая методология разработки ПО Rational Unified Process выделяет довольно большой набор видов тестирования (см. рисунок). Их можно с известной долей условности разделить следующим образом: Функциональное тестирование (Function testing)
IBM Rational TestManager необходим на всех этапах тестирования, предоставляет в распоряжение команды общие средства планирования, проектирования, исполнения и анализа тестов с использованием единой панели управления. Данный продукт имеет собственное хранилище данных, что обеспечивает более качественное управление версиями. Любой инструмент тестирования ПО, обладающий собственным API, не сложно интегрировать в единую систему, при этом может поддерживаться большинство исполняющих платформ тестирования. IBM Rational PurifyPlus включает три инструмента, предназначенных для анализа в режиме реального времени приложений и компонентов, разработанных с помощью Visual C/C++, C#, VB, VB .NET, Java, Java .NET. Purify обеспечивает автоматическое выявление ошибок, связанных с памятью, при этом выделяются источник и расположение ошибки. Если доступен исходный код, то его можно исправить непосредственно из Purify. Запатентованная технология Object Code Insertion позволяет выявлять ошибки доступа к памяти не только в исходном коде, но и в двоичных программных компонентах (DLL, объекты COM/DCOM, ODBC). PureCoverage - средство автоматического определения непротестированного кода. Quantify выполняет оценку производительности, определяя узкие места приложений и компонентов, как с исходным кодом, так и без него. Встроенные средства анализа данных помогают проводить сравнение результатов тестовых прогонов для различных вариантов кода. IBM Rational Robot - средство создания, изменения и выполнения автоматизированных тестов Интернет-приложений, ERP-систем и клиент-серверных решений. С его помощью обеспечивается объектно-уровневая поддержка при создании приложений на различных средствах разработки. Сценарии функциональных тестов генерируются в среде SQABasic, синтаксически совместимой с VB; встроенный редактор позволяет расширить сценарии тестов необходимыми процедурами и логическими условиями. Предусмотрена возможность создания специализированных тестов для различных типов программных объектов. Для формирования скриптов используется собственный Си-подобный язык. IBM Rational TestFactory - инструмент автоматической генерации скриптов тестирования посредством всестороннего анализа запущенного приложения для выявления дефектов надежности. Поскольку в программах имеется огромное число путей выполнения, проблема заключается в том, чтобы создать тесты, которые проверяют полный функционал приложения за минимальное число шагов. IBM Rational XDE Tester - специализированный инструмент для тестирования Java-приложений (J2EE, J2SE, SWT, AWT/JFC) и Web-приложений (HTML, DHTML, XML, JavaScript, апплеты Java). Текстовые сценарии пишутся на Java, технология ScriptAssure обеспечивает проверку достоверности динамических данных. Среда тестирования реализована в оболочке Eclipse, при этом имеется возможность встраивания инструмента в WebSphere Studio и Rational XDE Developer. |
В этом разделе мы опишем различные виды тестирования программного обеспечения. Различные виды тестирования ПО проводятся для достижения разных целей при тестировании программного приложения. Вы также можете прочитать о различных методах тестирования программного обеспечения, которые могут быть связаны с различными видами тестирования ПО. Наши помогут Вам стать специалистом в данной области.
Этот вид тестирования ПО является неформальным и неструктурированным и может выполняться любым заинтересованным лицом, без ссылок на какие-либо тестовые сценарии или тестовые документы.
Лицо, проводящее Ad-hoc-тестирование, хорошо понимает рабочие процессы приложения, при этом пытается найти дефекты и взломать ПО . Специальные проверки предназначены для обнаружения дефектов, которые не были обнаружены в существующих тестовых случаях.
Приемочное тестирование — это формальный вид тестирования программного обеспечения, который выполняется конечным потребителем, когда разработчики предоставили запрашиваемые услуги. Целью этого тестирования является проверка соответствия ПО
бизнес-требованиям потребителей и требованиям, представленным ранее. Приемочные тестирования обычно документируются в начале работы (в agile) и помогают тестировщикам и разработчикам улучшить свои знания и умения в данной области.
При тестировании доступности цель тестирования заключается в определении, можно ли легко получить доступ к содержимому веб-сайта людям с ограниченными возможностями. Включает в себя различные проверки, такие как проверка цвета и контраста (для людей с дальтонизмом), размер шрифта для слабовидящих, четкий и лаконичный текст, который легко читать и понимать.
Agile Testing — это вид тестирования программного обеспечения, который учитывает гибкий подход и методы разработки программного обеспечения. В среде разработки Agile тестирование является неотъемлемой частью разработки ПО и выполняется параллельно с написанием кода. Agile тестирование позволяет проводить постепенное написание кода и его тестирование.
Тестирование API — это вид тестирования, который похож на модульное тестирование. Каждый из программных интерфейсов API тестируется в соответствии со спецификацией API. Тестирование API в основном выполняется командой тестировщиков. Требует понимания как функциональности API, так и наличия хороших навыков в программировании.
Это подход к тестированию, который использует инструменты тестирования и / или программирование для запуска тестовых примеров с использованием программного обеспечения или специально разработанных тестовых утилит. Большинство автоматизированных средств представляют собой средства записи и воспроизведения, однако есть инструменты, которые требуют написания обширных сценариев или программирования для автоматизации тестовых сценариев.
Другими словами, «парное тестирование» — это тестирование методом «черного ящика» и метод тестирования, при котором для каждого входа тестируется пара входных данных, что помогает тестировать работу ПО, как и ожидалось, со всеми возможными комбинациями ввода.
Это формальный вид тестирования программного обеспечения, который выполняется конечными потребителями перед выпуском или передачей программного обеспечения пользователям. Успешное завершение бета-тестирования означает согласие пользователя с программным обеспечением.
Тестирование черного ящика — это вид тестирования программного обеспечения, когда от тестировщиков не требуется знать кодировку или внутреннюю структуру программного обеспечения. Метод тестирования «черного ящика» основан на тестировании ПО с различными входами и сравнении результатов с ожидаемыми.
Вид тестирования программного обеспечения, который проводится для проверки того, что более новая версия программного обеспечения может успешно работать поверх предыдущей версии ПО и что новая версия программного обеспечения прекрасно работает со структурой таблиц, структурами данных и файлами, созданными предыдущей версии ПО.
Тестирование граничных значений — это вид тестирования, основанный на концепции «агрегации ошибок на границах». Тестирование проводится методом тщательного тестирования дефектов в граничных значениях. Если в поле принимается значение от 1 до 100, то тестирование выполняется для значений 0, 1, 2, 99, 100 и 101.
Это один из подходов интеграционного тестирования. Метод тестирования «большой взрыв» основывается на том, что все или большинство модулей разрабатываются и затем соединяются вместе.
Интеграционное тестирование Снизу вверх — это метод интеграционного тестирования, в котором тестирование начинается с меньших частей или подсистем системы, и заканчивается полным охватом всей программной системы. Интеграционное тестирование Снизу вверх начинается с небольших частей программного обеспечения и в конечном итоге масштабируется с точки зрения размера, сложности и полноты.
Является методом тестирования белого ящика для разработки тестовых сценариев для тестирования кода для каждого условия ветвления. Применяется во время модульного тестирования.
Это один из подвидов тестирования совместимости, выполняемый командой тестирования. Тестирование совместимости браузера выполняется для веб-приложений в комбинациях с различными браузерами и операционными системами.
Тестирование на совместимость является одним из видов тестов, выполняемых группой тестировщиков. Тестирование совместимости проверяет, можно ли запускать программное обеспечение на другом оборудовании, операционной системе, базах данных, веб-серверах, серверах приложений, аппаратных периферийных устройствах, эмуляторах, различной конфигурации, процессоре, различных браузерах и различных версиях браузеров и т.д.
Этот тип тестирования программного обеспечения выполняется разработчиками. Тестирование компонентов выполняется после завершения модульного тестирования. Компонентное тестирование включает в себя тестирование группы единиц как кода вместе в целом, а не тестирование отдельных функций и методов.
Тестирование покрытия условий — это методика тестирования, используемая во время модульного тестирования, где разработчик тестирует все условия, такие как if, if-else, case и т. д. в тестируемом модуле кода.
Тестирование может быть выполнено методом статического тестирования и динамического тестирования. Динамическое тестирование — это подход к тестированию, когда тестирование может быть выполнено только при извлечении кода.
Это методика тестирования, которая используется в модульном тестировании. Цель тестирования покрытия решения состоит в том, чтобы осуществить и проверить каждый блок принятия решения в коде, например. If, if-else, case.
Сквозное тестирование выполняется командой тестировщиков, и основное внимание уделяется тестированию сквозных потоков. Прямо от создания заказа до составления отчетов или создания заказа до возврата товара и т. д. и проверки. Сквозное тестирование обычно направлено на то, чтобы имитировать реальные сценарии жизни и их воплощение. Сквозное тестирование включает в себя тестирование потока информации между приложениями.
Исследовательское тестирование — это неофициальный вид тестирования, проводимый для изучения ПО, в то же время ищущего ошибки или поведение приложения, которое кажется неочевидным. Тестирование обычно проводится тестировщиками, но может быть сделано другими заинтересованными лицами, а также бизнес-аналитиками, разработчиками, конечными пользователями и т. д., которые заинтересованы в изучении функций программного обеспечения и в то же время ищут ошибки или поведение, которое кажется неочевидным.
Эквивалентное разбиение также называется разделением эквивалентности. Разделение на классы — это методика тестирования программного обеспечения, а не вид тестирования сам по себе. Тестирование методом эквивалентного разбиения используется в тестах черного ящика и серого ящика. Эквивалентное разбиение классифицирует тестовые данные в классы эквивалентности как положительные классы эквивалентности и отрицательные классы эквивалентности, — такая классификация гарантирует тестирование как положительных, так и отрицательных условий.
Функциональное тестирование — формальный тип тестирования, выполняемый тестировщиками. Функциональное тестирование сосредоточено на тестировании программного обеспечения на основе документа о состоянии, случаев и требований. Функциональное тестирование является типом тестирования «черного ящика» и не требует знаний внутренней работы программного обеспечения, в отличие от тестирования «белого ящика».
Fuzz testing или fuzzing — это методика тестирования программного обеспечения, которая включает тестирование с непредвиденными или случайными исходными данными. Программное обеспечение тестируется на предмет ошибок или сообщений об ошибках, которые появляются из-за ошибок при вводе данных.
Этот вид тестирования ПО направлен на тестирование графический интерфейса пользователя ПО, который должен соответствовать требованиям, указанным в макетах GUI и детально разработанных документах. Например, проверка длины и емкости полей ввода, указанных в форме, типе предоставленного поля ввода. Некоторые поля формы могут отображаться как раскрывающийся список или набор переключателей. Таким образом, GUI-тестирование обеспечивает элементы графического интерфейса программного обеспечения в соответствии с утвержденными макетами GUI, подробными проектно-техническими документами и функциональными требованиями. Большинство инструментов автоматизации функциональных тестов работают с возможностями записи и воспроизведения графического интерфейса. Это ускоряет запись сценариев и увеличивает затраты на обслуживание скриптов.
Тестирование стеклянного ящика — еще одно название для тестирования белого ящика. Тестирование стеклянных ящиков — это метод тестирования, который включает в себя тестирование отдельных утверждений, функций и т. д. Модульное тестирование является одним из методов тестирования стеклянного ящика.
Этот вид тестирования программного обеспечения выполняется группой тестировщиков ПО. Цель Gorilla тестирования состоит в том, чтобы использовать одну или несколько функциональных возможностей полностью или исчерпывающе, если несколько человек испытывают одни и те же функции.
Также известный как тестирование Золотого пути, этот вид тестирования фокусируется на успешном прохождении тестов, которые не приведут к ошибкам.
Интеграционное тестирование является одним из наиболее распространенных и важных видов тестирования программного обеспечения. После того, как отдельные подразделения или компоненты будут проверены разработчиками как работающие, группа тестировщиков проведет тесты, которые проведут тестирование связи между этими единицами / компонентами или несколькими устройствами / компонентами. Существуют различные подходы к интеграционному тестированию, а именно: интеграционное тестирование сверху вниз, интеграционное тестирование снизу вверх и комбинация этих двух тестов Sand witch.
Тестирование интерфейса необходимо, когда программное обеспечение обеспечивает поддержку одного или нескольких интерфейсов, таких как «Графический интерфейс пользователя», «Интерфейс командной строки» или «Интерфейс прикладного программирования», чтобы взаимодействовать со своими пользователями или другим программным обеспечением. Интерфейсы служат средой для ПО, чтобы принимать входные данные от пользователя и предоставлять выходные данные пользователю. Подход к тестированию интерфейса зависит от типа тестируемого интерфейса, такого как GUI или API или CLI.
Тестирование интернационализации — это вид тестирования, который выполняется группой тестировщиков ПО, чтобы проверить, насколько программное обеспечение может поддерживать интернационализацию, т.е. использование разных языков, разных наборов символов, двухбайтовых символов и т. д. Например: Gmail — это веб-приложение, который используется людьми для работы с разными языками, одиночными или многобайтными наборами символов.
Тестирование на основе ключевого слова — это скорее автоматизированный подход к тестированию программного обеспечения, чем сам вид тестирования. Тестирование на основе ключевых слов известно как тестирование на основе действий или тестирование на основе таблиц.
Нагрузочное тестирование — это вид нефункционального тестирования. Нагрузочное тестирование проводится для проверки поведения ПО в условиях нормальной и сверхпиковой нагрузки. Нагрузочное тестирование обычно выполняется с использованием автоматизированных средств тестирования. Нагрузочное тестирование предназначено для поиска уязвимых мест или проблем, которые мешают ПО выполнять свои задачи в соответствии с его максимальными рабочими нагрузками.
Тестирование локализации — вид тестирования программного обеспечения, выполняемого тестировщиками ПО, при этом виде тестирования программное обеспечение, как ожидается, адаптируется к определенному языку, оно должно поддерживать конкретный язык, принимать ввод в этой конкретной локали, отображать шрифт, время, дату, валюту и т. д., относящиеся к определенному языку. Например, многие веб-приложения позволяют выбирать язык, например, английский, французский, немецкий или японский. Поэтому, если локаль определена или настроена в конфигурации программного обеспечения, ожидается, что программное обеспечение будет работать, как и ожидалось, с заданным языком / локалью.
Этот вид подхода к тестированию ПО, который показывает поведение ПО при взломе. Другими словами, это функциональный и нефункциональный тест, который предназначен для взлома ПО, введя неправильные данные, такие как некорректная дата, время или строку, или загрузив бинарный файл, когда предполагается загрузка текстового файла или ввести огромную текстовую строку для полей ввода и т. д. Это также положительный тест на наличие ошибки.
Большинство программных продуктов созданы для удовлетворения функциональных и нефункциональных требований. Нефункциональные требования: производительность, удобство использования, локализация и т. д. Существует множество видов тестирования, таких как тестирование на совместимость, локализацию, удобство, которые выполняются для проверки нефункциональных требований.
— это методика тестирования ПО, которую могут выполнять тестировщики ПО, разработчики или бизнес-аналитики. Как следует из названия, два человека работают вместе, один занимается тестированием и другой контролирует и записывает результаты тестирования. Парное тестирование может также выполняться в комбинации тестировщика-разработчика, тестировщика-бизнес-аналитика или комбинации аналитик-бизнес-разработчик. Объединение тестировщиков и разработчиков в парном тестировании помогает быстрее обнаруживать дефекты, определять основную причину, исправлять и тестировать исправление.
Является одним из видов тестирования ПО и частью инженерной деятельности, которая выполняется для проверки некоторых атрибутов качества ПО, таких как стабильность, надежность, доступность. Тестирование производительности выполняется командой разработчиков. В отличие от функционального тестирования, тестирование производительности выполняется для проверки нефункциональных требований. Тестирование производительности проверяет, насколько хорошо ПО работает в ожидаемых и максимальных рабочих нагрузках. Существуют различные варианты или подтипы производительности, такие как нагрузочное тестирование, стресс-тестирование, объемное тестирование, тестирование на выдержку и тестирование конфигурации.
Является одним из видов тестирования безопасности. Тестирование проникновения проводится для проверки того, как защищенное программное обеспечение и его среда (оборудование, операционная система и сеть) подвергаются атакам со стороны внешнего или внутреннего злоумышленника. Нарушитель может быть человеком / хакером или вредоносными программами. Pentest использует методы насильственного вторжения (путем грубой силы атаки) или использования уязвимости для получения доступа к ПО или данным, или оборудованию с целью разоблачения способов кражи, манипулирования или повреждения данных, файлов ПО или конфигурации. Тестирование безопасности — это способ этичного взлома: опытный тестировщик безопасности будет использовать те же методы и инструменты, что и хакер, но намерение тестировщика — идентифицировать уязвимость и исправить ее до того, как настоящий хакер или вредоносная программа использует уязвимость в своих целях.
— это вид тестирования ПО, который выполняется тестировщиками ПО в качестве функциональных регрессионных тестов, а разработчики — в виде единичных регрессионных тестов. Целью регрессионных тестов является выявление дефектов, которые были введены для исправления дефектов или внедрения новых функций. Регрессионные тесты являются идеальными вариантами для автоматизации тестирования.
Это тип повторного тестирования, который выполняется тестировщиками ПО как часть проверки исправления дефекта. Например, тестировщик проверяет исправление дефекта. Как только тестировщик проверит исправление дефекта как успешное, тестировщик затем повторно протестирует или проверит ту же функцию, выполнив тестовые примеры, которые были неудачны ранее.
Является одним из видов тестирования ПО и другого подхода к тестированию программного обеспечения. При тестировании на основе рисков требования и функциональность тестируемого ПО имеют приоритет как критический, высокий, средний и низкий. В этом подходе тестируются все критические и высокоприоритетные случаи, за ними следует средние. Функциональность с низким приоритетом или с низким уровнем риска тестируется в конце или может вообще не тестироваться, в зависимости от временных рамок.
Это вид тестирования, который выполняется тестировщиками ПО для проверки, является ли новая сборка, предоставленная командой разработчиков, достаточно стабильной, т. е. работают так ли основные функции, как ожидается, для проведения дальнейшего или подробного тестирования. Smoke тестирование предназначено для обнаружения дефектов «show stopper», которые могут препятствовать тестированию приложения в деталях. Smoke тестирование также известно как тестирование проверки сборки.
Является одним из видов тестирования ПО, выполняемого специализированной группой тестировщиков ПО. Цель тестирования защищенности — обеспечить защиту программного обеспечения от внешних или внутренних угроз со стороны людей и вредоносных программ. Тестирование защищенности в основном проверяет, насколько хорош механизм авторизации программного обеспечения, насколько сильна аутентификация, как программное обеспечение поддерживает конфиденциальность данных, как программное обеспечение поддерживает целостность данных, какова доступность программного обеспечения в случае атаки на программное обеспечение хакеров и вредоносных программ. Для тестирования безопасности необходимо наличие хороших знаний приложений, технологий, сетей, инструментов тестирования безопасности. С увеличением числа веб-приложений тестирование защищенности стало более важным, чем когда-либо.
Это вид тестирования, который выполняется в основном тестировщиками, а также в некоторых проектах разработчиками. Тестирование работоспособности — это быстрая оценка ПО, среды, сети, внешних систем, и проверка программной среды на стабильность, достаточную для начала всестороннего тестирования. Тесты на работоспособность являются узкими, и в большинстве случаев не документируются.
Представляет собой нефункциональный тест, предназначенный для тестирования одного из атрибутов качества ПО, то есть «Масштабируемость». Тест масштабируемости не ориентирован только на одну или несколько функций ПО, а не на производительность ПО в целом. Тестирование масштабируемости обычно выполняется командой разработчиков. Цель тестирования масштабируемости — проверить способность ПО увеличиваться с увеличением пользователей, увеличивать транзакции, увеличивать размер базы данных и т. д. Не обязательно, чтобы производительность ПО возрастала с увеличением конфигурации оборудования. Тесты масштабируемости помогают выяснить, как гораздо большую рабочую нагрузку ПО может поддерживать с расширением базы пользователей, транзакций, хранения данных и т.д.,
Является нефункциональным тестом, предназначенным для тестирования одного из атрибутов качества ПО, то есть «Стабильности». Тестирование стабильности фокусируется на тестировании стабильного ПО, когда оно подвергается нагрузкам на приемлемых уровнях, пиковым нагрузкам, нагрузкам, генерируемым в пиках с большим количеством обрабатываемых данных. Тестирование масштабируемости будет включать в себя выполнение различных видов тестов производительности, таких как нагрузочное тестирование, стресс-тестирование, тестирование спайков, тестирование выдержки.
— это форма тестирования, в подходах которой, используются пошаговые руководства для оценки правильности результатов. В статическом тестировании программный код не выполняется, а пересматривается для синтаксиса, комментирования, соглашения об именах, размера функций / методов и т. д. Статическое тестирование обычно имеет контрольные списки, по которым оцениваются результаты. Статическое тестирование может применяться для тестирования требований, дизайнов, а также для тестовых примеров с использованием таких подходов, как обзоры или пошаговые руководства.
Является одним из видов тестирования производительности, при котором ПО подвергается пиковым нагрузкам, чтобы наблюдать за тем, как программное обеспечение будет вести себя при пиковой нагрузке. Стресс-тестирование также проверяет поведение ПО при недостатке ресурсов, таких как процессор, память, пропускная способность сети, дисковое пространство и т. д. Стресс-тестирование позволяет проверить такой атрибут качества, как надежность.
Включает в себя несколько видов тестирования ПО, которые позволят проверить программное обеспечение в целом (программное обеспечение, аппаратное обеспечение и сеть) в соответствии с требованиями, для которых он был создан. Для завершения тестирования системы выполняются различные виды тестов (GUI-тестирование, функциональное тестирование, регрессионное тестирование, тестирование дыма, нагрузочное тестирование, стресс-тестирование, тестирование безопасности, стресс-тестирование, ad-hoc тестирование и т. д.).
Является одним из видов тестирования производительности, когда ПО подвергается нагрузке в течение значительного периода времени, тестирование на выдержку может продолжаться в течение нескольких дней или даже нескольких недель. Тестирование на выдержку — это тип тестирования, который проводится для выявления ошибок, приводящих к дегенерации производительности ПО при продолжении использования. Испытания на выдержку широко применяются для электронных устройств, которые, как ожидается, будут работать непрерывно в течение нескольких дней или месяцев или лет без перезагрузки. С растущим количеством веб-приложений тестирование на выдержку приобрело большое значение, поскольку доступность веб-приложений крайне важна для поддержки и успеха бизнеса.
Известный как SIT (вкратце), является видом тестирования, проводимого командой тестировщиков ПО. Как следует из названия, в фокус тестирования системной интеграции попадают проверка ошибок, связанных с интеграцией между различными приложениями, службами, приложениями сторонних поставщиков и т. д. В рамках SIT проверяются сквозные сценарии, для которых требуется ПО для взаимодействия (Отправлять или получать данные) с другими приложениями вверх, вниз, со сторонними приложениями.
Это вид тестирования, который выполняется разработчиками ПО. Модульное тестирование следует методу тестирования белых полей, где разработчик будет тестировать модули исходного кода, такие как операторы, ветви, функции, методы, интерфейс в ООП (объектно-ориентированное программирование). Модульное тестирование обычно включает в себя разработку драйверов. Модульные тесты — идеальные варианты для автоматизации. Автоматизированные тесты могут выполняться как единичные регрессионные тесты для новых версий или новых версий ПО. Существует множество полезных фреймов, таких как Junit, Nunit и т. д., которые могут сделать модульное тестирование более эффективным.
Является типом тестирования ПО, которое выполняется, чтобы понять, насколько ПО удобно для пользователя. Цель тестирования удобства использования заключается в том, чтобы позволить конечным пользователям использовать ПО, наблюдать за их поведением, эмоциональным откликом (понравилось ли пользователям использование программного обеспечения или они подчеркнули его использование и т. Д.) и собрать их отзывы о том, как ПО может быть более удобным для пользователя.
Приемочное тестирование пользователя является обязательным для любого проекта. Оно выполняется клиентами / конечными пользователями ПО. Приемочное тестирование позволяет специалистам от клиента тестировать ПО в соответствии с реальными бизнес-сценариями или реальными сценариями и проверять соответствие ПО их бизнес-требованиям.
Является нефункциональным видом тестирования, выполняемым группой инженеров по производительности. Тестирование объема — один из видов тестирования производительности. Тестирование объема выполняется для того, чтобы проверить ПО на надежность при работе с различными размерами данных, которые принимаются и обрабатываются программным обеспечением. Например, если вы собираетесь тестировать слово Microsoft, то проверка объема будет заключаться в том, чтобы увидеть, может ли MS Word открыть, сохранить и работать с файлами разных размеров (от 10 до 100 МБ).
Включает выявление ПО, оборудования или сети, уязвимости, которые могут быть использованы хакерами и другими вредоносными программами, похожими на вирусы или черви. Тестирование на уязвимость является ключом к обеспечению безопасности и доступности по. С ростом числа хакеров и вредоносных программ, тестирование уязвимостей имеет решающее значение для успеха бизнеса.
Тестирование методом белого ящика также известно как тестирование прозрачного или стеклянного ящика. Тестирование белого ящика — это метод тестирования ПО, который предназначен для тестирования ПО со знанием внутренней работы ПО. Этот метод используется в модульном тестировании, которое обычно выполняется разработчиками ПО. Тестирование «белого ящика» предназначено для тестирования кода, тестов, ветвей, пути, решений и потока данных в тестируемой программе. Тестирование белого ящика и тестирование «черного ящика» дополняют друг друга, поскольку каждый из подходов к тестированию может выявить определенную категорию ошибок.
Хочу отметить, что помогут познакомиться с данными методами тестирования наши .
Запишитесь прямо сейчас или закажите звонок с бесплатной консультацией!
Тестирование программного обеспечения - процесс исследования программного обеспечения (ПО) с целью получения информации о качестве продукта.
Введение
Существующие на сегодняшний день методы тестирования ПО не позволяют однозначно и полностью выявить все дефекты и установить корректность функционирования анализируемой программы, поэтому все существующие методы тестирования действуют в рамках формального процесса проверки исследуемого или разрабатываемого ПО.
Такой процесс формальной проверки или верификации может доказать, что дефекты отсутствуют с точки зрения используемого метода. (То есть нет никакой возможности точно установить или гарантировать отсутствие дефектов в программном продукте с учётом человеческого фактора, присутствующего на всех этапах жизненного цикла ПО).
Существует множество подходов к решению задачи тестирования и верификации ПО, но эффективное тестирование сложных программных продуктов - это процесс в высшей степени творческий, не сводящийся к следованию строгим и чётким процедурам или созданию таковых.
С точки зрения 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) обеспечение ситуации спокойного и самостоятельного выполнения заданий испытуемыми; сохранение нейтрального отношения к тестируемым, уход от подсказок и помощи;
4) соблюдение исследователем методических указаний по обработке полученных данных и интерпретации результатов, которыми сопровождается каждый тест или соответствующее задание;
5) предупреждение распространения полученной в результате тестирования психодиагностической информации, обеспечение ее конфиденциальности;
6) ознакомление испытуемого с результатами тестирования, сообщение ему или ответственному лицу соответствующей информации с учетом принципа «Не навреди!»; в этом случае возникает необходимость решения серии этических и нравственных задач;
7) накопление исследователем сведений, полученных другими исследовательскими методами и методиками, их соотнесение друг с другом и определение согласованности между ними; обогащение своего опыта работы с тестом и знаний об особенностях его применения.
Выделяют также несколько типов тестов, каждому из которых сопутствуют соответствующие процедуры тестирования.
Тесты способностей позволяют выявить и измерить уровень развития тех или иных психических функций, познавательных процессов. Такие тесты чаще всего связаны с диагностикой познавательной сферы личности, особенностей мышления и обычно называются также интеллектуальными.
К ним относятся, например, тест Равена, тест Амтхауэра, соответствующие субтесты теста Векслера и т.д., а также тесты-задания на обобщение, классификацию и множество других тестов исследовательского характера.
Тесты достижений ориентированы на выявление уровня сформированности конкретных знаний, умений и навыков и как меры успешности выполнения, и как меры готовности к выполнению некоторой деятельности. В качестве примеров могут служить все случаи тестовых экзаменационных испытаний. На практике обычно применяются «батареи» тестов достижений.
Личностные тесты предназначены для выявления свойств личности испытуемых. Они многочисленны и разнообразны: существуют опросники состояний и эмоционального склада личности (например, тесты тревожности), опросники мотивации деятельности и предпочтений, определения черт характера личности и отношений.
Имеется группа тестов, называемых проективными, которые позволяют выявить установки, неосознаваемые потребности и побуждения, тревоги и состояние страха.
Применение тестов всегда связано с измерением проявления того или иного психологического свойства и оценкой уровня его развития или сформированности. Поэтому важное значение имеет качество теста. Качество теста характеризуется критериями его точности, т.е. надежностью и валидностью.
Надежность теста определяется тем, насколько получаемые показатели являются стабильными и насколько они не зависят от случайных факторов. Разумеется, речь идет о сравнении показаний одних и тех же испытуемых. Это значит, что надежному тесту должна быть свойственна согласованность показателей тестирования, полученных при повторном тестировании, и можно быть уверенным в том, что тест выявляет одно и то же
свойство. Применяются разные способы проверки надежности тестов.
Один способ – это только что упомянутое повторное тестирование: если результаты первого и через определенное время проводимого повторного тестирования покажут наличие достаточного уровня корреляции, то это будет свидетельствовать о надежности теста. Второй способ связан с применением другой эквивалентной формы теста и наличием высокой корреляции между ними. Возможно и применение третьего способа оценки надежности, когда тест допускает его расщепление на две части и одна
и та же группа испытуемых обследуется с применением обеих частей теста. Надежность теста показывает, насколько точно измеряются психологические параметры и насколько высокой может быть мера доверия исследователя к полученным результатам.
Валидность теста отвечает на вопрос о том, что именно выявляет тест, насколько он пригоден для выявления того, для чего он предназначен. Например, тесты способностей нередко выявляют несколько иное: натренированность, наличие соответствующего опыта или, наоборот, его отсутствие. В таком случае тест не отвечает требованиям валидности.
В психодиагностике выделяют разные виды валидности. В простейшем случаеь валидность теста обычно определяется путем сопоставления полученных в результате тестирования показателей с экспертными оценками о наличии данного свойства у исследуемых (текущая валидность или валидность «по одновременности»), а также путем анализа данных, полученных в результате наблюдения за обследуемыми в различных ситуациях их жизни и деятельности, и их достижений в соответствующей области.
Вопрос о валидности теста может быть решен еще и сравнением его данных с показателями, полученными с помощью методики, связанной с данной методикой, валидность которой считается установленной.
Изучение продуктов деятельности – это исследовательский метод, который позволяет опосредованно изучать сформированность знаний и навыков, интересов и способностей человека на основе анализа продуктов его деятельности. Особенность этого метода заключается в том, что исследователь не вступает в контакт с самим человеком, а имеет дело с продуктами его предшествующей деятельности или размышлениями о том, какие
изменения произошли в самом испытуемом в процессе и в результате его включенности в некоторую систему взаимодействий и отношений.
