Автоматизация в тестировании реферат
Обновлено: 05.07.2024
Программное обеспечение для автоматизации тестирования также может вводить тестовые данные в тестовую среду, сравнивать ожидаемые и фактические результаты и создавать подробные отчеты о тестах. Как правило, автоматизация тестирования требует значительных вложений денег и ресурсов.
Последовательные циклы разработки, особенно в крупных компаниях (Google, Facebook, Альфа-Банк, Газпром нефть и т.д.) потребуют многократного выполнения одного и того же набора тестов. Используя инструмент автоматизации тестирования, можно записать этот набор тестов и при необходимости воспроизвести его. После автоматизации набора тестов вмешательство человека не требуется. Это улучшило ROI автоматизации тестирования. Цель автоматизации – уменьшить количество тестовых примеров, которые нужно запускать вручную, а не полностью исключить ручное тестирование.
- Зачем нужна автоматизация?
- Какие тестовые случаи стоит автоматизировать?
- Процесс автоматизированного тестирования
- Выбор инструмента тестирования
- Определяем объем автоматизации
- Планирование, проектирование и разработка
- Выполнение теста
- Обслуживание автоматизированного тестирования
- Платформа для автоматизации
- Рекомендации для эффективной автоматизации тестирования
- Преимущества автоматизации тестирования
- Типы автоматизированного тестирования
- Как выбрать инструмент автоматизации?
- Инструменты автоматизации тестирования
- Ручное тестирование всех рабочих процессов, полей и негативных сценариев требует больше времени и денег (при определенных условиях).
- Сложно тестировать многоязычные сайты вручную.
- Не требует вмешательства человека. Запускаете и переходите к другим задачам.
- Увеличивает скорость выполнения тестов.
- Помогает увеличить охват тестированием.
- Ручное тестирование может наскучить, и следствиями станут потеря вовлеченности и появление ошибок.
- Высокие риски и сбои недопустимы – крайне актуально для банковской сферы.
- Тестовые сценарии, которые регулярно повторяются.
- Тестовые сценарии, которые очень сложны и утомительны для выполнения вручную.
- Тестовые примеры, отнимающие много времени.
- Новые тестовые примеры, которые не выполнялись вручную хотя бы один раз.
- Сценарии тестирования, требования к которым часто меняются.
- Тестовые примеры, которые выполняются на разовой основе.
В процессе автоматизации выполняются следующие шаги:
Выбор инструмента тестирования
Выбор средства тестирования во многом зависит от технологии, на которой построено тестируемое приложение. Например , QTP не поддерживает Informatica. Таким образом, QTP нельзя использовать для тестирования приложений Informatica . Хорошая идея – провести Proof of Concept of Tool (демонстрация практической осуществимости) на AUT.
Определяем объем автоматизации
- Функции, важные для бизнеса
- Сценарии с большим объемом данных
- Общие функции приложений
- Техническая осуществимость
- Частота повторного использования бизнес-компонентов
- Сложность тестовых случаев
- Возможность использовать одни и те же тестовые сценарии для кросс-браузерного тестирования
На этом этапе выполняются сценарии автоматизации. Сценариям необходимо ввести тестовые данные, прежде чем они будут запущены. После выполнения они предоставляют подробные отчеты об испытаниях.
Выполнение может быть выполнено с использованием инструмента автоматизации напрямую или с помощью инструмента управления тестированием, который вызовет инструмент автоматизации.
Пример: Центр качества – это инструмент управления тестированием, который, в свою очередь, вызывает QTP для выполнения сценариев автоматизации. Скрипты могут выполняться на одной машине или на группе машин. Для экономии времени тестирование можно проводить ночью.
Обслуживание автоматизированного тестирования
Этот этап автоматизированного тестирования проводится для проверки того, как работают новые функции, добавленные в программное обеспечение: нормально или нет. Сопровождение в автотестировании выполняется, когда добавляются новые сценарии автоматизации, и их необходимо проверять и поддерживать, чтобы повышать эффективность сценариев автоматизации с каждым последующим циклом выпуска.
- поддерживают последовательность тестирования;
- улучшают структурирование теста;
- позволяют использовать минимальное количество кода;
- уменьшают затраты на обслуживания кода;
- повышают удобство повторного использования;
- дают возможность нетехническим тестировщикам участвовать в кодировании тестов;
- помогают сократить срок обучения использованию инструмента;
- включают данные везде, где это необходимо.
- платформа автоматизации на основе данных;
- фреймворк автоматизации на основе ключевых слов;
- модульная платформа автоматизации;
- гибридная среда автоматизации.
- Объем автоматизации необходимо детально определить до начала проекта. Это позволит убедиться, что ожидания от автоматизации будут оправданы.
- Определите правильный инструмент автоматизации: инструмент не должен выбираться на основании его популярности, он должен соответствовать требованиям автоматизации на конкретном проекте.
- Выберите подходящий фреймворк.
- Стандарты создания сценариев. При написании сценариев для автоматизации необходимо соблюдать стандарты. Вот некоторые из них:
- cоздайте единые скрипты, комментарии и отступы кода;
- разработайте правила наименования тестовых сценариев;
- прикладывайте необходимые документы, если, например, сложно понять прохождение тестового сценария без скриншота и/или спецификации.
Преимущества автоматизации тестирования
- На 70% быстрее, чем при ручном тестировании.
- Более широкий тестовый охват функций приложения.
- Надежные в результаты.
- Обеспечивает согласованность тестовых моделей.
- Экономит время и деньги.
- Повышает точность.
- Позволяет исполнять процесс тестирования без вмешательства человека.
- Повышает эффективность .
- увеличивает скорость исполнения тестирования.
- Повторно использует тестовые скрипты.
- Позволяет тестировать часто и тщательно.
- Больший цикл выполнения может быть достигнут за счет автоматизации.
- Сокращает время выхода продукта на рынок
- Смоук тестирование
- Модульное тестирование
- Интеграционное тестирование
- Функциональное тестирование
- Проверка ключевых слов
- Регрессионное тестирование
- Тестирование на основе данных
- Тестирование черного ящика
- поддержка окружающей среды;
- легкость использования;
- тестирование базы данных;
- идентификация объекта;
- тестирование изображений;
- тестирование восстановления после ошибок;
- отображение объектов;
- используемый язык сценариев;
- поддержка различных типов тестирования, в том числе функционального, тестового управления, мобильного и т. д.;
- поддержка нескольких фреймворков тестирования;
- легко отлаживать сценарии программного обеспечения автоматизации;
- умение распознавать предметы в любой среде;
- обширные отчеты об испытаниях и их результаты;
- минимизация затрат на обучение выбранным инструментам.
Инструменты автоматизации тестирования
На рынке доступно множество инструментов для функционального и регрессионного тестирования. В следующих выпусках расскажем в пользу чего делают выбор наши практикующие специалисты.Это универсальный инструмент для автоматизации функциональных тестов пользовательского интерфейса, регрессионных тестов, тестов на основе данных и многого другого. Ranorex Studio включает простой в использовании интерфейс для автоматизации тестирования веб-приложений, настольных и мобильных приложений.
- Функциональный пользовательский интерфейс и сквозное тестирование на ПК, в Интернете и на мобильных устройствах
- Кроссбраузерное тестирование
- SAP, ERP, Delphi и унаследованные приложения.
- iOS и Android
- Запускайте тесты локально или удаленно, параллельно или распределяйте в Selenium Grid
- Надежная отчетность
«Самый быстрый путь к отказоустойчивым сквозным тестам – без кода, с кодированием или и тем, и другим. Testim позволяет создавать удивительно стабильные тесты без кода, которые используют наш ИИ, а также гибкость для экспорта тестов в виде кода. Такие клиенты, как Microsoft, NetApp, Wix и JFrog, ежемесячно проводят миллионы тестов на Testim.
Это инструмент тестирования программного обеспечения, используемый для регрессионного тестирования. Это инструмент тестирования с открытым исходным кодом, который предоставляет возможность воспроизведения и записи для регрессионного тестирования. Селен IDE поддерживает только Mozilla Firefox веб – браузер.
Это объектно-ориентированный инструмент автоматизированного функционального тестирования , способный выполнять автоматическое функциональное, регрессионное тестирование, тестирование на основе данных и тестирование графического интерфейса. Основные особенности этого инструмента:
- Он поддерживает несколько браузеров на разных платформах.
- Вместо того, чтобы использовать собственный сценарий поставщика, он использует полнофункциональный современный язык сценариев Ruby.
- Он поддерживает ваше веб-приложение независимо от того, на чем оно разработано.
Silk Test предназначен для выполнения функционального и регрессионного тестирования. Для приложений электронного бизнеса шелковый тест является ведущим продуктом для функционального тестирования. Это продукт поглощения Segue Software компанией Borland в 2006 году. Это объектно-ориентированный язык, как и C ++. Он использует концепцию объекта, классов и наследования. Его основная особенность включает
- Он состоит из всех файлов исходных скриптов.
- Он преобразует команды сценария в команды графического интерфейса. На одном компьютере команды могут выполняться на удаленном или хост-компьютере.
- Чтобы идентифицировать движение мыши вместе с нажатиями клавиш, можно запустить Silktest. Он может использовать как методы воспроизведения и записи, так и методы описательного программирования для получения диалогов.
- Он определяет все элементы управления и окна тестируемого приложения как объекты и определяет все атрибуты и свойства каждого окна.
Правильный выбор инструмента автоматизации, процесса тестирования и команда – основные составляющие успеха автоматизации. Для успешного тестирования ручные методы и автоматизация идут рука об руку.
Статья рассматривает один из самых важных этапов при разработке сложных программных систем – этап тестирования. Современные средства разработки позволяют быстро построить "каркас" приложения, но насколько это качественно? В статье описываются основные задачи тестирования, виды тестов и критерии тестирования. Приводятся рекомендации по построению процесса тестирования.
Тестирование - один из важнейших этапов проверки качества разработанного ПО.
Так сложилось, что ответ на вопрос о качестве ПО в большинстве случаев дает только его эксплуатация -- как говорится, "жизнь покажет". Вместе с тем заказчик вправе требовать от разработчика гарантий. Обилие неудачных попыток получить заказное ПО высокого качества вызывает у заказчиков законные вопросы: а возможно ли в принципе создавать качественное ПО? как этого добиться? что должен требовать заказчик от подрядчика, чтобы получить качественное ПО? как должен работать сам заказчик?
Для оценки качества ПО всегда применяется целый комплекс мер, среди которых тестирование ПО на предмет обнаружения ошибок - один из важнейших этапов.
1. С чего же начинается тестирование? Для его проведения необходимы объект тестирования - в данном случае ПО - и эталон, с которым этот объект сравнивается. ПО -это сложный объект, который меняется по составу и проверяемым свойствам на разных стадиях разработки. Важно понимать, что если разработчик и заказчик не сформулировали требования к ПО еще до начала его разработки, то, во-первых, заказчик вряд ли получит именно то, что хотел, и, во-вторых, ПО, которое он все-таки получит нельзя будет проверить, поскольку объект есть, а эталона нет.
Иначе говоря, тестирование ПО проводится на соответствие заранее определенным требованиям (по функциональности, производительности, безопасности и пр.). Поскольку объект тестирования сложный, необходим системный подход к тестированию, его организации и проведению.
Итак, первый вывод: надо четко определять требования к ПО в самом начале разработки, но не "требования вообще" типа "ПО должно работать", а требования, которые можно проверить. При этом требования к ПО подразделяются на функциональные (какие функции и с каким качеством должно реализовывать ПО) и нефункциональные (ограничения на время решения задачи, скорость доступа к данным, требования к занимаемым ресурсам и т. п.). У заказчика и разработчика должна быть возможность сравнить текущее функционирование системы с ее эталонным (ожидаемым) поведением. При этом рекомендуется использовать итеративный подход, так как раннее тестирование критичных областей значительно снижает риск неудачи и стоимость исправлений для всего проекта разработки ПО.
2. Неопытный заказчик всегда настроен на то, чтобы дать задание, а потом посмотреть конечный результат. Это самый верный способ получить некачественное ПО. Но низкое качество невыгодно обеим сторонам. Заказчику потому что заказанное им ПО нельзя использовать к тому моменту, когда оно уже нужно, и он теряет время и деньги, поскольку ПО должно работать на его бизнес, а оно не работает (т. е. не приносит денег), да еще и отбирает дополнительные ресурсы на доработку. Разработчику потому, что он теряет авторитет, дорабатывает ПО за свой счет (теряет деньги) и не может быстро переключиться на другого заказчика (теряет заказы). Гораздо эффективнее поэтапно осуществлять контроль над ходом отработки ПО. Именно такой подход приносит наибольший эффект и при разумной позиции заказчика будет наверняка положительно воспринят разработчиком. Для успешного проведения тестирования чрезвычайно важно тщательно спланировать эти работы. Рекомендуется использовать шаблоны документов, в том числе плана тестирования, разработанный в соответствии с требованиями международного стандарта IEEE 829-1983 Standard for Software Test Documentation.
Мы не будем в этой статье описывать весь технологический процесс создания ПО. Заметим только, что обсуждение технического задания, технического проекта, архитектуры системы с заказчиком -- это тоже часть процесса обнаружения ошибок и уточнения эталона. Одно из главных правил для разработчика -- надо очень плотно работать с заказчиком, тогда обе стороны будут лучше понимать, что происходит при создании ПО в каждый конкретный момент и как быстрее находить совместные решения.
3. И все же, что значит "поэтапное тестирование"? Заметим сразу, что многие заказчики не думают о том, что тестирование стоит денег и вообще затрат ресурсов и что за качество надо платить. Однако, осознав это, заказчик всегда должен понимать, за что именно он платит и как увидеть результаты.
Принято разделять тестирование по уровням задач и объектов на разных стадиях и этапах разработки ПО (см. таблицу):
тестирование частей ПО (модулей, компонентов) с целью проверки правильности реализации алгоритмов -- выполняется разработчиками;
функциональное тестирование подсистем и ПО в целом с целью проверки степени выполнения функциональных требований к ПО -- рекомендуется проводить отдельной группой тестировщиков, не подчиненной руководителю разработки;
нагрузочное тестирование (в том числе стрессовое) для выявления характеристик функционирования ПО при изменении нагрузки (интенсивности обращений к нему, наполнения базы данных и т. п.) -- для выполнения этой работы требуются высококвалифицированные тестировщики и дорогостоящие средства автоматизации экспериментов.
Покрытие ветвлений, функции
Функциональность, степень проверки компонентов
Система в целом
Соответствие функциональным требованиям ТЗ
Система в целом
Проверка качества внесения изменений
Система в целом
Оценка статистических характеристик системы, соответствие ТЗ, ТТХ, подбор конфигурации оборудования
Система в целом
Корректность работы системы при предельных нагрузках
Когда понятно, что и зачем нужно тестировать, и есть план действий, самое время задуматься о том, как это сделать эффективнее, быстрее и более качественно. Современное ПО -- это сложный объект, и вручную с ним справляться трудно и дорого. К тому же при "ручном" тестировании результаты каждого выполнения тестов пропадают, и их трудно повторить. Для того чтобы увеличить объем проверок и повысить качество тестирования, обеспечить возможность повторного использования тестов при внесении изменений в ПО применяют средства автоматизации тестирования. К их числу относятся средства автоматизации функционального и нагрузочного тестирования клиент-серверных и Web-приложений: Rational TestStudio, Mercury LoadRunner, Segue SilkPerformer, а также менее популярные продукты фирм Compuware, CA, Empirix, RadView Software и др.
Желательно, чтобы на этапах сборки, комплексной отладки и опытной эксплуатации разработчик фиксировал интенсивность обнаружения ошибок, -- тогда по характеру изменения этой интенсивности можно будет судить об изменении качества ПО и, например, о целесообразности его передачи в опытную или постоянную эксплуатацию. Наконец, необходимо проведение комплекса испытаний ПО на соответствие требованиям ТЗ или других нормативных документов, на возможность эффективно работать с ПО на основе использования программной документации, приемосдаточных и других видов испытаний, обеспечивающих заказчику уверенность в работоспособности созданного для него ПО.
Ну а что же между испытаниями, когда ПО еще только создается? И на этом этапе очень важно, чтобы деятельность по тестированию велась планомерно. Хотя тестирование - процесс достаточно творческий, его можно и нужно планировать. Это значит, что на каждом этапе работ должны быть выбраны критерий качества и критерий завершения тестирования. Первый нужен для того, чтобы тестировщик или группа тестировщиков понимали, что и на соответствие чему они проверяют. То есть, каковы объект и эталон и какие свойства объекта проверяются. Второй критерий помогает принять решение в случае, когда исчерпываются ресурсы, отведенные на тестирование, он отвечает на вопрос, при каких условиях тестирование может быть завершено.
План при тестировании действительно нужен. Ведь для проверки сложного объекта можно и нужно применять разные стратегии, позволяющие добиваться максимального результата при существующих ограничениях на ресурсы тестирования. Например, если проверить наиболее вероятные пути в программе, можно быть уверенным, что уж на них-то ПО будет работать верно. Кроме того, план тестирования позволяет заранее определить, что нужно подготовить для проведения тестирования. Скажем, многие разработчики ПО начинают готовиться к нагрузочным экспериментам только тогда, когда наступило время их проведения. А ведь заранее известно, что для таких экспериментов понадобится испытательный стенд (комплекс оборудования с установленным системным и прикладным ПО), и известно какой, потребуется наполненная исходными данными база данных, ее содержимое будет меняться, и эту базу иногда придется восстанавливать. Наконец, будет нужна информация, которую часто называют нормативной или справочной и которая должна храниться в составе ПО или в базах данных.
План тестирования определяется международным стандартом IEEE 829-1983. В нем должны быть предусмотрены как минимум три раздела содержащие, следующие описания:
что будет тестироваться (тестовые требования, тестовые варианты);
какими методами и насколько подробно будет тестироваться система;
план-график работ и требуемые ресурсы (персонал, техника).
Дополнительно описываются критерии удачного/неудачного завершения тестов, критерии окончания тестирования, риски, непредвиденные ситуации, приводятся ссылки на соответствующие разделы в основных документах проекта - план управления требованиями, план конфигурационного управления и т. п.
Как подготовиться к тестированию, что именно нужно для его проведения? Как мы уже выяснили, необходимы проверяемые требования, затем каждое из них связывается с одним или несколькими тестовыми требованиями. Далее логический набор тестовых требований группируется в тестовые сценарии, проверка которых позволит дать односложный ответ на вопрос, корректно ли осуществляется ввод, правильно ли работает та или иная бизнес-функция в системе. Этот результат понятен не только специалистам, но и конечному пользователю. Основные объекты автоматизации тестирования - системы, реализующие работу клиентской части. Ключевой особенностью тестирования клиент-серверных систем является возможность проверки корректности функционирования и удовлетворительного быстродействия системы через работу клиентской части. Таким образом, тщательно и всесторонне проверив эти возможности, мы получаем гарантию работоспособности системы для конечного пользователя. Еще один важный аспект организации работ -- хранение созданных тестов. Мы рекомендуем относиться к тестам так же, как и к исходному коду, т. е. нужно использовать версионные хранилища для возможности восстановления тестов предыдущих версий системы (MS SourceSafe, Rational ClearCase. ). Это пригодится на этапе сопровождения ПО и даст возможность повторного использования готовых тестов на нескольких версиях системы. Аналогично нужно относиться и к тестовым данным, создавая архивы, копии и версии содержимого БД.
Как проводить тестирование? Тестирование - это всегда эксперимент. Для его проведения нужна база. Как в любом эксперименте, при тестировании нужно где-то собирать накопленную информацию, обрабатывать результаты. Есть самое крупное разделение видов тестирования: статическое и динамическое. При статическом тестировании ПО не исполняется, а происходит анализ кода, структур данных. Динамическое тестирование, напротив, требует выполнения тестируемого ПО. Для этого нужны не только средства автоматизации тестирования, но и вспомогательные средства. Известно очень много средства построения и автоматической генерации тестов, средств мониторинга ресурсов во время выполнения тестов, средств измерения и визуализации результатов тестирования, средств статистической обработки результатов и т. п.
Ограниченный объем статьи не дает нам возможности подробно описать полный комплекс мероприятий для обеспечения уверенности заказчика в том, что ПО хорошо протестировано. Кроме того, всегда имеются особенности тестирования, специфичные для конкретного ПО. Не у всех разработчиков есть необходимые средства автоматизации тестирования. Многие заказчики используют для проведения тестирования независимые организации, поручая им аутсорсинг тестирования ПО. Они делают это ради большей уверенности в качестве создаваемого для них ПО, прежде всего в следующих ответственных областях:
системы массового обслуживания клиентов;
ввод в действие новых ERP-систем для оценки качества их работы в условиях сети и инфраструктуры заказчика в целом;
тестирование ПО при его сопровождении и развитии, поставке новых версий и релизов;
выбор серверов, на которых работает ПО, и т. п.
1. Агапов А. С., Зенин С. В., Михайловский Н. Э., Мкртумян А. А. Оценка и аттестация зрелости процессов создания и сопровождения программных средств и информационных систем (ISO/IEC TR 15504-CMM), Пер. с англ. Москва, "Книга и бизнес", 2001.
Разработка автоматизированной системы тестирования знаний ‘Русский .
2. Постановка задачи
Для заданного программного продукта (граф-программа решения квадратного уравнения, изображенная на рисунке 1) произвести комплексное фуцнкциональное и структурное тестирование.
Рисунок 1 — Алгоритм решения кубического уравнения
2.1 Описание объекта тестирования
Рассмотрим основные особенности графа:
1. Граф строится отображением управляющей структуры программы. В ходе отображения закрывающие скобки условных операторов и операторов циклов (end if; end loop) рассматриваются как отдельные (фиктивные) операторы.
2. Узлы (вершины) графа соответствуют в самом простом случае линейным участкам программы, включают один или несколько операторов программы.
3. Дуги графа отображают поток управления в программе (передачи управления между вершинами).
Дуга — это ориентированное ребро.
4. Различают операторные и предикатные узлы. Из операторного узла выходит одна дуга, а из предикатного — две дуги.
4. Предикатные узлы соответствуют простым условиям в программе. Составное условие программы отображается в несколько предикатных узлов. Составным называют условие, в котором используется одна или несколько булевых операций (OR, AND).
3 . Функциональное тестирование
3.1 Выбор метода тестирования
Модульное тестирование, или юнит-тестирование (англ. unit testing) — процесс, позволяющий проверить на корректность отдельные модули исходного кода программы.
Идея состоит в том, чтобы писать тесты для каждой нетривиальной функции или метода. Это позволяет достаточно быстро проверить, не привело ли очередное изменение кода к регрессии, то есть к появлению ошибок в уже оттестированных местах программы, а также облегчает обнаружение и устранение таких ошибок. В данной работе мы будем использовать юнит-тесты для проверки функциональных требований программы.
Для модульного тестирования необходимо использовать драйверы и заглушки.
Unit (Элемент) — наименьший компонент, который можно скомпилировать.
Драйверы — модули тестов, которые запускают тестируемый элемент.
Заглушки — заменяют недостающие компоненты, которые вызываются элементом и выполняют следующие действия:
3.2 Классификация ошибочных ситуаций
Модели ошибок описывают классы ошибок, которые можно сделать при разработке целевой программы. Классификация ошибочных ситуаций представлена в таблице Таблица 1.
Таблица 1 — Описание ошибочных ситуаций
Ошибки способа обработки аргументов
Целевая операция имеет несколько вариантов работы, выбор которых зависит от значений аргументов. Ошибка состоит в отсутствии одного из вариантов работы или в выборе ошибочного для некоторых значений аргументов.
- partition testing;
- тестирование граничных значений.
a. Операция вычисления абсолютной величины, работает по-разному для аргумента x >= 0 и для x 3.3 План модульного тестирования
Базой для модульного тестирования служат отдельные модули исходного кода программы. Пошаговый план модульного тестирования представлен в таблице 2.
Таблица 2 — План модульного тестирования
Название функционального модуля
Изображение на графе
3.4 Тестирование
3. 4.1 Локализация ошибочной области
Пр оцесс тестрования модуля начинается с локализации области, содержащей ошибку. Для этого проверим стандартную установку параметров тестирования, описанных выше: разрядность ЭВМ t=15, r=0; тестируемые параметры принадлежат диапазонам Х, Y.
Запустим процесс тестирования. Результат — пустой экран (Рисунок 2).
Рисунок 2 — Результат при t=15, r=0
Рисунок 3 — Результат при t=5, r=1
В рамках исходного окна выделяем новую рамку для того фрагмента домена, который обещает большое количество ошибок.
Переопределяем параметры окна, например, для нашего случая: Х[900;1100], Y[0;200] и запустим расчет.
В результате получится картина, представленная на рисунке 4Рисунок 4.
Рисунок 4 — Результат при Х[900;1100], Y[0;200]
Полученную фигуру отцентрируем, для этого сместим окно по координате TF на 20 градусов.
Получим фазовый портрет, представленный на рисунке Рисунок 5.
Рисунок 5 — Результат при LbX=920, RbX=1120, LbY=0, RbY=200
Теперь увеличим разрядную сетку ЭВМ: t=6, r=0, проведем испытания. Результаты представлены на рисунке 6.
Рисунок 6 — Результат при t=6, r=0
Теперь наведем окно поиска на перспективное скопление точек, представленных на рисунке 7Рисунок 7.
Рисунок 7 — Скопление точек
Эта процедура продолжается, пока параметр разрядности t не станет равен 15.
Примечание. Для больших t, т. е. , когда вектор ошибочных данных практически обнаружен, полезно распечатать координаты этой точки (Рисунок 8).
Рисунок 8 — Вывод точек
3. 4.2 Отладка программы
В ходе отладки вычислений в точке с координатами х=1021.95 444 572,у=0.0005 была обнаружена ошибка деления на ноль ( Рисунок 9).
Рисунок 9 — Исходный код программы. Подсвечена ошибка деления на ноль
3. 4.3 Заключение о типе и причине ошибки. Предложение по её исправлению.
В ходе выполнения лабораторной работы была выявлена ошибка деления на ноль, возникающая при значениях координаты X, близких к 1021.95 444 572.
Данная ошибка относится к классу ошибок способа обработки аргументов. Возможной причиной ошибки является недостаточная проработка алгоритма, в частности, упущена обработка исключительного случая. Исправление ошибки возможно с помощью удаления знаменателя из программного кода, либо написания проверочной ветки алгоритма с соотвтетствующей обработкой, то есть использования метода тестирования граничных значений.
3.5 Результаты модульного тестирования
тестирование программный граф
Результаты тестирования по каждому из модулей сведем в таблицу:
Таблица 3 — Результаты модульного тестирования
Название функционального модуля
Изображение на графе
4 . Структурное тестирование в вершинах ветвления
4.1 Описание метода структурного тестирования
Существо подхода — в проверке каждого пути, каждой ветви алгоритма.
Методы структурного тестирования:
1 Метод покрытия операторов.
Если отказаться полностью от тестирования всех путей, можно показать, что критерием покрытия является выполнение каждого оператора программы хотя бы один раз. Это необходимое, но недостаточное условие для приемлемого тестирования по принципу белого ящика.
2 Метод покрытия решений (покрытия переходов).
Согласно данному методу должно быть написано достаточное число тестов, такое, что каждое направление перехода должно быть реализовано, по крайней мере, один раз. Покрытие решений обычно удовлетворяет критерию покрытия операторов. Поскольку каждый оператор лежит на некотором пути, исходящем либо из оператора перехода, либо из точки входа программы, при выполнении каждого направления перехода каждый оператор должен быть выполнен.
3 Метод покрытия условий.
Записывается число тестов, достаточное для того, чтобы все возможные результаты каждого условия в решении выполнялись, по крайней мере, один раз.
4 Критерий решений (условий).
Критерий покрытия решений/условий требует такого достаточного набора тестов, чтобы все возможные результаты каждого условия в решении выполнялись, по крайней мере, один раз, все результаты каждого решения выполнялись, по крайней мере, один раз и, кроме того, каждой точке входа передавалось управление, по крайней мере, один раз.
5 Метод комбинаторного покрытия условий.
4.2 Постановка задачи структурного тестирования
Структурное тестирование программы предполагает знание исходного текста программы, либо спецификации программы в виде потокового графа управления.
Рассмотрим основные особенности потокового графа:
1. Граф строится отображением управляющей структуры программы. В ходе отображения закрывающие скобки условных операторов и операторов циклов (end if; end loop) рассматриваются как отдельные (фиктивные) операторы.
2. Узлы (вершины) потокового графа соответствуют линейным участкам программы, включают один или несколько операторов программы.
3. Дуги потокового графа отображают поток управления в программе (передачи управления между операторами).
Дуга — это ориентированное ребро.
4. Различают операторные и предикатные узлы. Из операторного узла выходит одна дуга, а из предикатного — две дуги.
4. Предикатные узлы соответствуют простым условиям в программе. Составное условие программы отображается в несколько предикатных узлов. Составным называют условие, в котором используется одна или несколько булевых операций (OR, AND).
При структурном тестировании программы используются так называемые структурные критерии, которые базируются на основных элементах графа управления программы: операторах, ветвях и путях.
Рассматривают 3 группы критериев:
- Тестирующие команды.
- Тестирующие ветви.
- Тестирующие пути.
Пусть вершина управляющего графа (уграфа) имеет три исходящих дуги, помеченных предикатами P1(X), P2(X), P3(X), как на рисунке 10.
Рисунок 10 -Граф управления Таблица 4 -План структурного тестирования
Название функционального модуля
Изображение на графе
Структурный анализ управляющих графов программ предполагает, что все объекты, из которых они составлены, прошли автономное тестирование и получили сертификат качества. Это означает, что каждый объект с заданной доверительной вероятностью не содержит ошибок в пределах своей области определения.
Существует два пути возникновения ошибок:
- Неверно составлены предикаты.
- Неверно организовано управление (неправильный граф программы).
Ошибки неверного употребления данных или организации межмодульного информационного интерфейса в технологии ГСП маловероятны, так как неправильное употребление данных должно быть установлено еще на этапе тестирования акторов, а при автоматической организации межмодульного информационного интерфейса ошибки такого рода исключены.
Значит, при тестировании в технологии ГСП необходимо проверять корректность графа управления вычислительным процессом, а также полноту и непротиворечивость используемых предикатов.
Рассмотрим условия ситуации естественного развития как частный случай некорректности графа управления.
Естественное развитие — запланированный режим работы вершины ветвления. В данном случае производится проверка на существование данных при которых управление переда? тся по одному из перечисленных направлений. В данном случае это
Формальная модель анализа уграфа программы основывается на исчислении предикатов первого порядка с сигнатурой, включающей отношения порядка. Это означает, что при построении предикатов используются алгебраические выражения, содержащие отношения порядка ( , =, > =).
При переходе от логических функций к множествам логические функции естественным образом заменяются на теоретико-множественные операции пересечения, объединения и дополнения. Поскольку предлагаемая формальная модель анализа уграфов основывается на теоретико-множественном анализе, то все логические выражения необходимо заменить на соответствующие операции на множествами.
Алгоритм метода структурного тестирования управляющих графов программы:
1. Записать исходное логическое выражение (проверяемый предикат).
2. Представить исходный предикат посредством базовых предикатов.
3. Заменить логические операции на теоретико-множественные.
4. Ввести индикаторные функции.
5. Записать решающую функцию для заданного в пункте 3 множества.
6. Для нахождения значений истинности сложного логического выражения применяется алгоритм оптимизации функции многих переменных, а задачу тестирования структуры программы сводится к оптимизационной задаче поиска минимума.
7. Если минимум функции меньше единицы, то логическое выражение выполняется хотя бы на одном наборе данных.
Построим теперь решающую функцию. Пусть задана система линейных уравнений:
Необходимо проверить ситуацию естественного развития для первого направления Ситуация естественного развития для первого направления описывается следующим логическим условием:
Предположим, существует такой Х, что вышеприведенная формула истинна, тогда истинны в отдельности предикаты и, т. е. :
Тогда условие естественного развития для первого направления будет иметь следующий вид:
Тогда, используя теоретико-множественные операции, можно представить данное условие в виде:
Построим решающую функцию для выражений, , введя индикаторные функции:
Рассчитаем данную модель в пакете Matlab. На рисунке 11 представлено изображение решающей функции в виде изолиний.
Рисунок 11 — Изолинии решающей функции
Из рисунка 2 видно, что существует большое количество точек, для которых решающая функция меньше 1. Следовательно, запирания первого направления нет.
4.4 Результаты структурного тестирования
В результате тестирования была изучена формальная модель структурного тестирования с использованием решающей функции. Решающая функция обеспечивает возможность нахождения ошибочных ситуаций с использованием алгоритмов оптимизации. Это гарантирует эффективность данного подхода. Найден вектор значений, удовлетворяющий данной ситуации.
Аналогичным образом проводится исследование ситуаций естественного развития, тупика и конкуренции для каждой вершины графа. Результаты структурного тестирования сведены в таблицу ниже.
Таблица 5 -Результаты структурного тестирования
Название функционального модуля
Изображение на графе
5 . Структурное тестирование маршрутов
5.1 Описание метода структурного тестирования маршрутов
Для построения множества маршрутов в технологии ГСП применяется алгоритм частичного перебора маршрутов (АЧП).
Алгоритм частичного перебора схем маршрутов Введем понятие свободных вершин графа. Свободными вершинами графа G относительно схемы маршрута S будем называть вершины графа, не содержащиеся в схеме маршрута S, т. е. L (S) = V (G)V (S), где V (G) и V (S) — соответственно вершины графа и схемы маршрута.
Алгоритм частичного перебора использует следующие правила:
1. Вершины графа кодируются символами упорядоченного множества любым способом, но так, чтобы корневая вершина имела наименьший код, а концевые — наибольшие значения.
2. На каждом шаге работы алгоритма для текущего состояния схемы маршрута Si ищется путь на орграфе перехода из последней вершины Si в любую свободную вершину схемы Si.
4. Если переход невозможен, то рассматривается следующая вершина списка свободных вершин и так до тех пор, пока не кончится список вершин.
7. Алгоритм завершает свою работу, если список свободных вершин корневой вершины исчерпан.
* Данная работа не является научным трудом, не является выпускной квалификационной работой и представляет собой результат обработки, структурирования и форматирования собранной информации, предназначенной для использования в качестве источника материала при самостоятельной подготовки учебных работ.
1. Анализ состояния вопроса.
1.1 Описание предметной области.
1.2 Анализ аналогов и прототипов.
1.3 Перечень задач подлежащих решению в процессе разработки.
1.4 Постановка задачи и разработка технического задания.
1.5 Требования к программе и программному изделию.
1.5.1 Требования к функциональным характеристикам.
1.5.2 Требования к составу и параметрам технических средств.
1.5.3 Требования к информационной и программной совместимости.
1.5.4 Требования к программной документации.
2. Разработка проекта системы.
2.1 Разработка структурной схемы системы.
2.2 Проектирование баз данных.
2.3 Разработка и описание рабочих алгоритмов.
2.4 Требования к системам передачи информации.
2.5 Описание технологии обработки информации.
2.6 Разработка интерфейса взаимодействия пользователя с системой.
4. Список использованной литературы.
1 Анализ состояния вопроса.
Описание предметной области
В последние годы в сфере образования наблюдается стремительное увеличение интереса к автоматизации контроля результатов обучения. Самым популярным видом такого контроля является тестирование, основанное на диалоге вычислительной системы с пользователем.
Также стоит отметить, что сегодня многие компании и некоммерческие организации достаточно часто сталкиваются с необходимостью проведения того или иного тестирования. Например, тестирование соискателей на открывшуюся в компании вакансию, или регулярное психологическое тестирование, которое позволяет выявить "климат" в офисе и определить людей, которые являются источниками напряжения и мешают нормально работать другим. А ведь еще есть тесты по технике безопасности, профессиональные тесты для подтверждения права заниматься той или иной деятельностью, различные аттестации и т. п. Для этого очень удобно использовать компьютерное тестирование. Это позволяет ускорить проведение опросов и существенно облегчить обработку результатов.
Для обработки результатов наиболее подходит централизованная схема организации системы, т.е. клиент-сервер. Причем клиентов одновременно может работать несколько. Данная схема позволяет проводить тестирование одновременно для нескольких людей, например, целой учебной группы, и по окончании процедуры последним тестирующимся получить конечную статистику.
Наилучшим применением схемы клиент-сервер будет реализация ее как в локальной, так и в глобальной сетях. Так, в локальной сети удобно проводить тестирование на лабораторном занятии в компьютерном классе сразу всей группы. Вариант с глобальной сетью подойдет для тестирования знаний и навыков при дистанционном обучении, получившем широкое распространение в последнее время, а также для тестирования знаний обучающихся, которые по некоторым причинам (например, по состоянию здоровья) не могут присутствовать в компьютерном классе или офисе. Актуальность использования глобальной сети в качестве среды передачи данных подтверждает также ее повсеместное распространение и доступность.
Существует пять разновидностей вопросов для тестовых наборов:
Одиночный выбор. Пользователю предоставляется возможность выбора из нескольких вариантов единственного верного.
Множественный выбор. Из нескольких вариантов выбирается несколько верных.
Свободный ввод. Пользователь вводит ответ в поле для ввода. Имеет известные сложности с обработкой результатов. С успехом может быть заменен другой разновидностью вопросов без ущерба для общих показателей.
Взаимодействующими сущностями, в порядке убывания иерархической значимости, являются:
Читайте также: