Педагогические науки/4.Стратегические направления реформирования системы образования

К.э.н. Стебеняева Т.В., к.т.н. Лазарева Л.Ю., методист Юрятина Н.Н.

АНО ДПО Институт стандартов международного учета и управления,

Москва, Россия

Сравнительный анализ стратегий

модульного тестирования при экспертизе

электронных образовательных ресурсов

Основной тенденцией реформирования российской системы образования является использование на всех уровнях образовательной практики новых форм представления дидактического контента знаний. Сегодня одной из наиболее развитых и эффективных форм такого рода являются электронные образовательные ресурсы (ЭОР), функционирующие в информационно-образователь-ных средах (ИОС) высших учебных заведений (ВУЗов), а так же всевозможные их вариации. Под ЭОР будем понимать самостоятельный пакет прикладных программ (ППП), объединенных специальным программным обеспечением (ПО) в законченный информационный продукт, предназначенный для длительного хранения и многократного использования в образовательном процессе. В соответствии с ГОСТ Р 52653-2006 под ЭОР понимается «образовательный ресурс, представленный в цифровой форме и включающий в себя структуру, предметное содержание и метаданные о них, а также данные, информацию, программное обеспечение, необходимые для его использования в учебном процессе» [1]. В этом же документе вводится понятие «дидактический контент», под которым понимается определенным образом структурированное предметное содержание конкретной образовательной дисциплины, используемое в образовательном процессе. Дидактический контент и формы его представления являются основой ЭОР.

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

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

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

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

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

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

1) сверху вниз, или нисходящее тестирование;

2) снизу вверх, или восходящее тестирование.

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

Проиллюстрируем стратегию нисходящего тестирования следующим примером. Допустим, что выбранный нами для проведения экспертизы ЭОР содержит 12 модулей. При этом Модуль 1 является головным, Модули 2-4 - образуют иерархию модулей первого уровня; Модули 5-9 - иерархию модулей второго уровня, а Модули 10-12 - иерархию модулей третьего уровня. Для простоты дальнейшего изложения предположим, что взаимосвязь отдельных модулей друг с другом имеет только межуровневый характер. Другими словами модули одного уровня не связаны между собой.

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

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

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

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

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

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

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

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

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

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

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

3) подтверждение правильности подхода, положенного в основу разработки тестируемого программного продукта;

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

Вместе с тем стратегия нисходящего тестирования и экспертной оценки ПО модулей ЭОР не лишена определенных недостатков.

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

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

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

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

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

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

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

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

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

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

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

Таблица 1

Достоинства и недостатки использования стратегий

нисходящего и восходящего тестирования и инструментария модульного тестирования для экспертизы ЭОР

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

На основании представленных результатов можно сделать два вывода:

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

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

Исследование выполнено при финансовой поддержке Российского гуманитарного научного фонда, проект №13-06-00006а «Методология экспертной оценки качества электронных образовательных ресурсов».

Литература:

1. ГОСТ Р 52653-2006 «Информационно-коммуникационные технологии в образовании. Термины и определения». – М.: Стандартинформ, 2007. – 12с.

2. Иванов Д.А. Экспертиза в образовании. – М.: Издательский центр «Академия», 2008. – 336 с.

3. Новикова Т.Г. Экспертиза инновационной деятельности в образовании: монография. – М.: АПКиППРО, 2005. – 290 с.

4. Lazareva L.U., Stebenyaeva T.V., Yudinova V.V. International experience of expert assessment of quality electronic educational resources: methods and techniques. // 1st International Scientific Conference «Science progress in European countries: new concepts and modern solutions»: Volume 2. Papers of the 1st International Scientific Conference (Volume 1). March 28, 2013, Stuttgart, Germany. – 156 p. Pp.67-69.