Виды интеграционного тестирования. Особенности монолитного и инкрементального тестирования. Преимущества проведения интеграционного тестирования

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

20.1. Задачи и цели интеграционного тестирования

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

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

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

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

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

20.2. Организация интеграционного тестирования

20.2.1. Структурная классификация методов интеграционного тестирования

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

восходящее тестирование ;
монолитное тестирование ;
нисходящее тестирование .

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

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

Рис. 20.1.

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

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

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

Монолитное тестирование имеет ряд серьезных недостатков.

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

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

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

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

Задачи и цели интеграционного тестирования

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

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

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

Синицын С.В., Налютин Н.Ю. Верификация программного обеспечения

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

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

Перевод: Анна Радионова

Существует много видов ПО тестов. Практики BDD можно применять в любых аспектах тестирования, но BDD фреймворки используются далеко не во всех типах тестов. Поведенческие сценарии, по сути, являются функциональными тестами - они проверяют, что тестируемый продукт работает корректно. Для тестирования производительности могут использоваться инструменты, в то время как BDD фреймворки не предназначены для этих целей. Задача данной статьи, в основном, состоит в описании роли BDD автоматизации в Пирамиде Тестирования. Прочитайте статью BDD 101: Manual Testing для того, чтобы понимать как BDD применяется при ручном тестировании. (Всю информацию по BDD можно найти на странице Automation Panda BDD page)

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

Тем не менее, BDD практики могут применяться для юнит-тестов. Каждый юнит-тест должен быть направлен на основную составляющую: один вызов, единичная вариация, определенная комбинация ввода; на поведение .В дальнейшем при разработке спецификация поведения фичи четко отделяет юнит тесты от тестов более высокого уровня. Разработчик функционала также ответственен за написание юнит-тестов, в то время как за интеграционные и end-to-end тесты несет ответственность другой инженер. Спецификация поведения является, своего рода, джентльменским соглашением о том, что юнит-тесты будут являться отдельной сущностью.

Интеграционное и End-to-End тестирование

Тестовые BDD фреймворки наиболее ярко проявляют себя на интеграционных и end-to-end уровнях тестирования .

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

Given a user is logged into the social media site
When the user writes a new post
Then the user"s home feed displays the new post
And the all friends" home feeds display the new post

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

Длительные End-to-End тесты

Термины часто понимаются разными людьми по-разному. Когда люди говорят “end-to-end тесты,” они подразумевают продолжительные последовательные тесты: тесты, которые покрывают различное поведение продукта одно за другим . Это утверждение заставляет содрогнуться приверженцев BDD, т.к это противоречит основному правилу BDD: один сценарий, одно поведение. Конечно, с помощью BDD фреймворков можно составлять длительные end-to-end тесты, но нужно хорошо подумать, стоит ли это делать и как именно.

Существует пять основных принципов написания длительных end-to-end сценариев в BDD:

Не стоит беспокоиться на этот счет . Если BDD процесс поставлен правильно, то каждое отдельное поведение уже полностью покрыто тестовыми сценариями. Каждый сценарий должен покрывать все классы эквивалентности вводимых и выводимых данных. Таким образом, длительные end-to-end сценарии будут являться, в основном, дублированием тестового покрытия. Вместо того, чтобы тратить время на разработку, лучше отказаться от автоматизации длительных end-to-end сценариев, как от тех, которые не представляют большой ценности и уделить больше времени ручному и исследовательскому тестированию .
Объединить существующие сценарии в новые . Каждая When-Then пара представляет собой индивидуальное поведение. Шаги из существующих сценариев могут быть переопределены в другие сценарии и для этого потребуется лишь незначительный рефакторинг. Это нарушает хорошие практики Gherkin и может привести к появлению длительных сценариев, но это наиболее практичный способ переиспользовать шаги для обширных end-to-end сценариев. Большинство BDD фреймворков не поддерживают пошаговый порядок, а если поддерживают, то шаги должны быть переписаны, чтобы код работал. (Этот подход является наиболее практичным, но менее традиционным .)
Встраивайте проверки в Given и When шаги . Данная стратегия позволяет избежать дуплицирования When-Then пар и убедиться, что проверки производятся. Корректность каждого шага проверяется на протяжении всего процесса с помощью Gherkin текста. Однако, может потребоваться ряд новых шагов.
Воспринимайте последовательность поведений как уникальное отдельное поведение . Это наилучший способ обдумывания длительных end-to-end сценариев, т.к. он усиливает поведенческое мышление. Продолжительный сценарий имеет ценность только в том случае, если он расценивается как уникальное поведение. Сценарий должен быть написан с целью подчеркнуть эту уникальность. В противном случае это не тот сценарий, который стоит использовать. Такие сценарии часто являются декларативными и высокоуровневыми.
Не используйте BDD фреймворки и пишите тесты исключительно с помощью средств автоматизации . Gherkin предназначен для совместной работы в отношении поведения, в то время как продолжительные end-to-end тесты решают проблемы интенсивности работы QA. Бизнес может предоставить поведенческие спецификации, но никогда не станет писать end-to-end тесты. Переписывание поведенческих спецификаций в длинные end-to-end сценарии может блокировать разработку. Гораздо лучшим решением является сосуществование: приемочные тесты могут быть написаны при помощи Gherkin, а продолжительные end-to-end тесты - средствами программирования. Для автоматизации обоих наборов тестов можно использовать одну и ту же базу кода, у них могут быть единые модули поддержки и даже методы определения шагов.

Выберите подход, наиболее подходящий вашей команде.

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

1. Интегративные тесты

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

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

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

2. Адаптивные тесты

Целесообразность адаптивного контроля вытекает из необходимости рационализации традиционного тестирования. Каждый учитель понимает, что хорошо подготовленному ученику нет необходимости давать легкие и очень легкие задания. Потому что слишком высока вероятность правильного решения. К тому же, легкие материалы не обладают заметным развивающим потенциалом. Симметрично, из-за высокой вероятности неправильного решения нет смысла давать трудные задания слабому ученику. Известно, что трудные и очень трудные задания снижают учебную мотивацию многих учащихся. Нужно было найти сопоставимую, в одной шкале, меру трудности заданий и меру уровня знаний. Эта мера была найдена в теории педагогических измерений. Датский математик Г. Раш назвал эту меру словом «логит» (1). После появления компьютеров эта мера легла в основу методики адаптивного контроля знаний, где используются способы регулирования трудности и числа предъявляемых заданий, в зависимости от ответа учеников. При успешном ответе следующее задание ЭВМ подбирает более трудным, при неуспешном - легким. Естественно, этот алгоритм требует предварительного опробования всех заданий, определения их меры трудности, а также создания банка заданий и специальной программы.

Использование заданий, соответствующих уровню подготовленности, существенно повышает точность измерений и минимизирует время индивидуального тестирования до, примерно, 5 - 10 минут Адаптивное тестирование позволяет обеспечить компьютерную выдачу заданий на оптимальном, примерно 50%-ом уровне вероятности правильного ответа, для каждого ученика.

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

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

Истоки адаптивного подхода можно проследить с момента возникновения педагогических трудов Коменского, Песталоцци и Дистервега, которых объединяют идеи природосообразности и гуманности обучения. В центре их педагогических систем был Ученик. Например, в малоизвестной у нас работе А. Дистервега (2) «Дидактические правила» (Киев, 1870 г.) можно прочитать такие слова: «Преподавай сообразно природе… Учи без пробелов… Начинай преподавание с того, на чем остановился ученик… Прежде чем приступить к преподаванию, нужно исследовать точку исхода… Без знания того, на чем остановился ученик, невозможно порядочно обучить его». Недостаточная информированность о реальном уровне знаний учащихся и естественные различия в их способностях усвоить предлагаемые знания стали главной причиной появления адаптивных систем, основанных на принципе индивидуализации обучения. Этот принцип трудно реализуем в традиционной, классно-урочной форме.

До появления первых компьютеров наиболее известной системой, близкой к адаптивному обучению, была так называемая «Система полного усвоения знаний». О ней уже писалось в УШ № 26/99.

3. Так называемые «критериально-ориентированные тесты»

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

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

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

Споры ведутся вокруг двух главных вопросов:

1) правильности содержания теста, что означает безошибочность формулировок его заданий, предметно-научная обоснованность, допустимость теста для проверки интересующих знаний в данной группе испытуемых. При аргументации в пользу того или иного теста педагоги-предметники опираются на понятийный аппарат, язык принципы и вообще на знания преподаваемой ими учебной дисциплины. В таких случаях говорят о тестах с содержательно-ориентированной интерпретацией результатов (4). Это так называемый случай Domain Referenced Testing, что можно перевести как соотнесение знаний по результатам теста со знаниями, полный перечень которых представлен в генеральной совокупности (domain).

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

Второй вид тестов связан с ориентацией на такие конкретные цели и задачи, как, например, проверка уровня усвоения сравнительно короткого перечня требуемых знаний, умений и навыков, выступающих в качестве заданного стандарта или критерия усвоения. Например, для аттестации выпускников образовательных учреждений важно иметь такие задания, которые позволяют делать вывод о минимально допустимой компетентности выпускников. За рубежом их так и называют: Minimum Competency Tests. При проверке минимально допустимого уровня знаний содержание заданий носит принципиально облегченный характер. Поскольку такие задания должны выполнять все выпускники, допущенные учебным заведением к аттестации, здесь невозможно трудно говорить о тестах, как методе объективного и эффективного измерения испытуемых с разным уровнем подготовленности, в строгом смысле понятия «тест». Этот подход выработан для органов управления образованием, стоящих перед необходимостью в короткое время проверить состояние образования в большом количестве учебных заведений, и не позволять последним опускаться ниже предельно допустимого уровня требований.

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

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

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

Литература

Rasch, G. Probabilistic Models for Some Intelligence and Attainment Tests. With a Foreword and Afteword by B.D. Wright. The Univ. of Chicago Press. Chicago & London, 1980. 199 рр. Для более точного восприятия смысла понятия «логит» может быть полезными некоторые формализмы. По существу, Г.Раш ввел две меры: «логит уровня знаний» и «логит уровня трудности задания». Первую он определил как натуральный логарифм отношения доли правильных ответов испытуемого, на все задания теста, к доле неправильных ответов, а вторую - как натуральный логарифм другого отношения - доли неправильный ответов на задание теста к доле правильных ответов на тоже задание, по множеству испытуемых.
Дистервег А.«Дидактические правила» (Киев, 1870 г.)
См., например, статью: Аванесов В.С. «Образовательные стандарты нуждаются в изменении». УШ, № 46, декабрь 1998г.
Нlively W.(Ed). Domain Referenced Testing. Educational Technology Publications. Englewood Cliffs, N-J, 1974.
Berk R.A. (Ed). A Guide to Criterion - Referenced Test Construction. The John Hopkins Univ. Press, Baltimore, 1984.

20.1. Задачи и цели интеграционного тестирования

20.2. Организация интеграционного тестирования

20.2.1. Структурная классификация методов интеграционного тестирования

восходящее тестирование ;
монолитное тестирование ;
нисходящее тестирование .

Рис. 20.1.

Монолитное тестирование имеет ряд серьезных недостатков.

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

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

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