<<
>>

Тестирование потоков данных программных модулей

  В графах потока данных значения объектов связаны с обрабатывающими узлами, в которых эти значения вычисляются. При применении графов потока данных узел может быть использован для представления нескольких различных вычислений и, таким образом, может иметь несколько различных объектов, ассоциированных с исходящими связями.
Обычная практика - размещение имен объектов на связях, исходящих из таких узлов. При таком использовании эти имена характеризуются значениями исходящих связей. Поскольку исходящие из одного узла связи являются входящими по отношению к следующему узлу, они отражаются значениями входящих связей. Узел выбора данных вычисляет специальную функцию значения входящей связи для использования в исходящей связи. Входящие связи узла данных должны быть помечены условием предиката, при котором выбирается данная входящая связь. Его значение выбирает объект данных, соответствующий входящей связи. Обрабатывающий узел с одной или более входящими связями формируется, по крайней мере, с одной исходящей связью. Входящие связи обозначаются именами данных. Исходящая связь обозначает вычисленную функцию этих объектов данных. Запоминающие узлы при последующей обработке должны уточняться, какое именно значение переменной используется.
Тестирование потоков данных можно разделить на два этапа - рис. 2.7. Первый этап тестирования состоит в анализе узлов обработки данных, определяющих значения предикатов в операторах выработки логических решений при взаимодействии элементов в модуле программ. Эти решения влияют на изменения маршрутов обработки информации, что сближает в этой части метод тестирования потоков данных с тестированием структуры модуля.
Второй этап - тестирование подграфа обработки данных на соответствие заданным требованиям. Оно состоит в проверке вычислений по аналитическим формулам, или определение численных зна - чений результатов решения задач, в зависимости от числовых или логических значений исходных данных [2, 3, 23].
Если сделать отдельно модель потока данных и модель потока управления, каждая приведет к различным тестам, и при таком подходе не будет значительного перекрытия созданных тестов. Поэтому полезно помещать модель потока управления внутрь модели потока данных. Повторяющиеся процедуры в модели, большей частью определяются потоками данных.




ляет рассматривать программу в виде мультиграфа, заданного структурой передач управления (потоком управления) и графом преобра- зования данных, участвующих в вычислениях (поток данных). Пересечение потоков управления и потоков данных осуществляется в узлах ветвления: проверки условий и циклов. Совместный анализ потоков управления и данных позволяет проверять корректность областей определения переменных на маршрутах исполнения программы. Последствия ошибок данных в модуле могут проявляться как малые изменения некоторых переменных в процессе вычислений, и как полное искажение или отсутствие на выходе требующихся величин.
Тестирование программного модуля целесообразно проводить на упорядоченных наборах данных с учетом степени их влияния на выходные результаты. С этой позиции для последующего анализа целесообразно выделить два вида обработки данных: способный полностью изменять область определения результатов и изменяющий результаты в пределах некоторой ограниченной области определения
[2, 3].
Первому виду обработки соответствуют исходные данные в критических точках (узлах) и на границах областей изменения переменных. При таких критических значениях может изменяться маршрут исполнения программы, вследствие чего возможно наибольшее изменение результатов. Поэтому обычно тестирование обработки данных, прежде всего, направлено на проверку исполнения программ при значениях переменных, влияющих на выбор маршрута и логику функционирования программ (стратегия областей).
Граничные условия - это ситуации, возникающие в непосредственной близости к границам областей изменения обрабатываемых переменных. Число таких критических значений каждой переменной может быть на несколько порядков меньше, чем число значений по всей внутренней части области изменений этой величины. Большин - ство критических значений (предикатов) может существенно влиять на результаты и подлежит наиболее тщательному тестированию. В этой части тестирование обработки данных по содержанию близко к тестированию структуры (потока управления) программы. При этом виде тестирования маршруты формируются в процессе анализа и обработки данных на последовательных операторах условий в тексте программы. Сочетания исходных данных в тестах непосредственно влияют на степень охвата тестированием участков программы модуля. Путем сопоставления проверенных маршрутов с маршрутами, выделенными по графу программы при различных критериях можно оценивать полноту тестирования потока управления модуля и приблизительную его корректность.
Второму виду обработки соответствуют данные в ограничен - ной или неограниченной области определения, которая может делиться на некоторое множество сопрягающихся областей (подобла - стей). Изменение данных в пределах такой области не влияет на маршрут исполнения программы. Поэтому для проверки функционирования программы из всего множества значений достаточно использовать при тестировании только несколько значений внутри и вблизи границ области. Количество величин, используемых для тестирова - ния при обработке этого вида, может быть на несколько порядков меньше полного числа значений каждой переменной в области. В процессе такого тестирования проверяется точность осуществляемых вычислений, правильность размерности обрабатываемых величин, корректность формирования логических величин и т.д. При этом тестирование должно охватывать всю область изменения каждой обрабатываемой переменной и каждой результирующей величины.
Процессы формирования и тестирования модели потоков данных (без циклов) представлены на рис. 2.7. Тестирование с применением графовых моделей программных модулей способно обеспечивать высокое и управляемое качество модулей. Оно состоит из двух технологических этапов, построения и анализа графовой модели для подготовки тестирования и этапа планирования, реализации и исполнения тестов для выявления дефектов и ошибок в программе. При планировании тестирования на основе объединенной графовой модели потоков управления и данных подготавливаются исходные данные требований и эталонов и обобщенный граф модели модуля. Эти дан - ные используются для определения предикатов и переменных пра- вильных маршрутов исполнения программы и описаний тестов. Маршруты формируются в соответствии с заданной стратегией и критерием выделения и упорядочивания маршрутов.
Подготовка тестов потоков данных модуля начинается с проверки корректности его спецификации, идентификации входных переменных и констант, присвоение каждой входной переменной имени и создание для нее входного узла. Текст программы модуля преобра - зуется так, чтобы каждой вычисляемой функции соответствовало одно предложение. Создается структура компонента, начиная с элементов, которые зависят от входных переменных и от результатов предыдущих функций, пока не охвачены все. Производится проверка промежуточных функций, является ли их упорядочение необходимым или просто удобным, можно ли упростить модель, удаляя промежуточные узлы или, добавляя промежуточные узлы и подграфы для сложных вычислений. Следует зарегистрировать модель потока данных - поименованный набор узлов - функций, их связей и подграфов данных, которые отражают их обработку.
Планирование и реализация тестирования модуля с использованием графов потоковых моделей программ начинается с формирования задания, эталонов и ограничений для планирования тести - рования программного модуля (см. рис.2.7). На основе подготовленного графа программного компонента должно производиться выделение циклических подграфов для автономного тестирования, использование предикатов и маршрутов с циклами для формирования набора тестов и выполнение их тестирования. После этого целесообразно осуществлять выбор маршрутов тестирования по узлам и порожденным ими сложным вычислительным подграфам, и активизирование тестирования порожденных подграфов. В результате возможно преобразование объединенной графовой модели к ациклическому виду. В этой модели производится выделение маршрутов по выбранному критерию и упорядочение выделенных маршрутов графа по выбран - ной стратегии ациклического графа исполнения программы. Далее целесообразно провести анализ и исключение нереализуемых маршрутов графа по противоречивым условиям в предикатах или на гра - ничных значениях переменных. Оставшийся список предикатов и выделенных маршрутов используется для предсказания и записи ожидаемых итогов тестирования маршрутов, формирования набора тестов и реализации тестирования, по выбранным маршрутам и подграфам. Это позволяет оценивать полное число тестов использованных для тестирования выделенных маршрутов с учетом значений эталонов и ограниченных ресурсов, а также степень покрытия модуля тестами, проконтролировать результаты тестирования, выделенные дефекты и ошибки. При этом должна быть проведена оценка качества программного модуля и допустимости его применения в проектируемом комплексе, подтверждена корректность значений результатов в промежуточных узлах, циклах и подграфах.
Тестиро 
<< | >>
Источник: Липаев В.В.. Экономика производства программных продуктов.. 2011

Еще по теме Тестирование потоков данных программных модулей:

  1. Разработка программного обеспечения. Затраты, связанные с качеством программного обеспечения, в группе компаний Raytheon’s Electronic Systems
  2. Организация рациональных материальных потоков в непоточном производстве Основы упорядочения материальных потоков
  3. Модуль Arc-SDM для ArcView
  4. ПРИЛОЖЕНИЕ 5 Рекомендуемое МЕТОД ОПРЕДЕЛЕНИЯ МОДУЛЯ УПРУГОСТИ
  5. 4.5. СБОР ДАННЫХ 4.5.1. Общее понятие о данных
  6. Информационное н программное обеспечение
  7. Липаев В.В.. Экономика производства программных продуктов., 2011
  8. Финансовые потоки
  9. Программная реализация
  10. 3.2. Специализированные программные средства и среды проектирования
  11. Программно-целевые методы
  12. Глава 13. ПСИХОЛОГИЧЕСКОЕ ТЕСТИРОВАНИЕ
  13. ПОТОК В СИСТЕМЕ
  14. Выбор программного обеспечения ГИС
  15. Искусство создавать потоки
  16. ПРОБЛЕМЫ ИНТЕЛЛЕКТУАЛИЗАЦИИ СТАТИСТИЧЕСКОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ М. М. Лери
  17. Потоки услуг
  18. Информационные потоки и системы в логистике
  19. Готовность программно-технической среды
  20. Свойства доверенной программно-технической среды