История Росии. реферат (31). Реферат дисциплина Инструментальные средства проектирования по. Часть 1(заочная инф 19) Тема Средства автоматизированного тестирования студент группы ин119(2) Ф. И. О
 Скачать 93.5 Kb.
|
|
Автономная некоммерческая образовательная организация высшего образования «Сибирский институт бизнеса и информационных технологий» РЕФЕРАТ Дисциплина: Инструментальные средства проектирования ПО. Часть 1(заочная_инф_19) Тема: Средства автоматизированного тестирования. Выполнил: студент группы ИН-119(2) Ф.И.О. Эсонова Мафтунахон Муродбек кизи Город: Омск Омск 2021 1. Общие понятия тестирования программ тестирование программное обеспечение Тестирование ПС - это процесс выполнения его программ на некотором наборе данных, для которых заранее известен результат, а также правило поведения этих программ. Тестирование проводится уже с программой, не имеющих ошибок. Целью тестирования является получение результатов по конкретным данным, а также контроль качества программы и убедиться в правильности работы ПС. Тестирование должно включать проверку всех ветвей программы и должно включать минимальный набор примеров. При тестировании нельзя предусмотреть такие всевозможные ситуации, но надо добиваться определенных результатов. У Г. Майерса сформулированы основные принципы организации тестирования: необходимой частью каждого теста должно являться описание ожидаемых результатов работы программы, чтобы можно было быстро выяснить наличие или отсутствие ошибки в ней; следует по возможности избегать тестирования программы ее автором, т.к. кроме уже указанной объективной сложности тестирования для программистов здесь присутствует и тот фактор, что обнаружение недостатков в своей деятельности противоречив человеческой психологии (однако отладка программы эффективнее всего выполняется именно автором программы); по тем же соображениям организация - разработчик программного обеспечения не должна "единолично" его тестировать (должны существовать организации, специализирующиеся на тестировании программных средств); должны являться правилом доскональное изучение результатов каждого теста, чтобы не пропустить малозаметную на поверхностный взгляд ошибку в программе; необходимо тщательно подбирать тест не только для правильных (предусмотренных) входных данных, но и для неправильных (непредусмотренных); при анализе результатов каждого теста необходимо проверять, не делает ли программа того, что она не должна делать; следует сохранять использованные тесты (для повышения эффективности повторного тестирования программы после ее модификации или установки у заказчика); тестирования не должно планироваться исходя из предположения, что в программе не будут обнаружены ошибки (в частности, следует выделять ;птя тестирования достаточные временные и материальные ресурсы); следует учитывать так называемый "принцип скопления ошибок": вероятность наличия не обнаруженных ошибок в некоторой части программы прямо пропорциональна числу ошибок, уже обнаруженных в этой части; 10) следует всегда помнить, что тестирование - творческий процесс, а не относиться к нему как к рутинному занятию. 2. Технические требования к тестированию Тестовые испытания программ представляют собой процесс, направленный на то, чтобы гарантировать их нормальную работу во всех предполагаемых практических ситуациях. При этом должны осуществляться два вида испытаний: на соответствие созданной программы поставленной задаче и на правильность её функционирования. Первый вид испытаний невозможно провести, если задача определена не полностью, нечётко и непоследовательно. Требование полноты включает в себя полное описание поставленной задачи, её функциональные требования, направленность в применении. Требование четкости означает, что как поставщик задачи, так и программист должен ясно представлять себе, чего они хотят добиться от программы. Требование последовательности включает недопустимость какой-либо неопределенности. Когда программная спецификация обладает свойствами полноты, чёткости и последовательности, то человек, проводящий испытания программы, может рассматривать её как «чёрный ящик», т.е. не заботясь о её структуре. Второй вид испытаний направлен на обеспечение и проверку выдачи правильных результатов программы относительно определённых входных данных. При этом проверяется правильность составления текста программы и по своей конструкции она должна соответствовать спецификации программы. 3. Тест. Тестовые данные Тест - набор данных, с помощью которого производится тестирование, он включает подмножество допустимых входов в программу. В технической диагностике тест - это последовательность наборов сигналов (исходных данных), которые подаются на вход изделия, и соответствующие им наборы эталонных правильных сигналов (результирующих данных), которые должны быть получены па выходе. Для каждого тестового набора указываются координаты (точки) ввода исходных данных и координаты (точки) контроля результатов. Кроме того, при тестировании необходимо задавать допуски на отклонение результирующих данных от эталонных, и пределах которых следует, что полученные результаты соответствуют эталонным. Степень отклонения получаемых результатов от эталонов используется для опенки качества изделий и соответствия их техническим требованиям. В ряде случаев процесс исполнения программ и получаемые результаты зависят от непредсказуемого изменения входных и промежуточных данных, а также от реального времени. Вследствие этого невозможно создать единственный универсальный метод тестирования и приходится применять ряд значительно различающихся категорий тестов. Каждая категория тестов отличается целевыми задачами, проверяемыми компонентами программы и методами оценки результатов. Только совместное и систематическое применение различных тестов тестирования позволяет достичь высокого качества функционирования программ. Выделяются три стадии тестирования: для обнаружения ошибок в программе, для диагностики и локализации причин обнаруженных искажений результатов, для контроля выполненных корректировок программ и данных. Основная цель тестирования для обнаружения ошибок - выявление всех отклонений результатов функционирования реальной программы от заданных эталонных значений. Задача состоит в обнаружении максимально числа ошибок, в качестве которых принимается любое отклонение от эталонов. Чем больше ошибок выявляется па этой стадии при каждой операции тестирования, тем выше эффективность тестов и обоснованность затри: па их выполнение. После этого тестирования применяется тестирование для диагностики и локализации причин возникновения ошибок. Основной целью здесь является выявление и оценивание причин появления ошибок. На этой стадии выбираются методы устранения ошибок, а также производится и самоустранение выявленных ошибок. На последней стадии производится контрольное тестирование. Основная цель его является подтверждение правильности выполненной корректировки программы Тестовые данныедля каждого теста должны обеспечивать проверку всех возможных условий возникновения ошибок. Первой целью любого тестирования является проверка на то, чтобы убедиться работает ли программа вообще. Такую проверку называют дымовым тестомТест, который проверяет основные ветви программы, должен обнаружить грубые ошибки. Нужно подбирать простые тестовые данные, которые облегчают ручной контроль результатов, В некоторых случаях надо «миниатюризировать» программу, т.е. сокращать объём данных по сравнению с реальными. Заключительные испытания должны обеспечить проверку всей программы в целом. Поэтому данные для этого теста должны быть как можно близкими к реальным при применении программы на этапе эксплуатации. Типы тестовых данных могут быть различными, но все они сводятся к трём основным: создаваемые программистом; реальные модифицированные; реальные в полном объеме. Каждый тест должен содержать определённый класс данных, который, в свою очередь, должен соответствовать: - вычислению вручную; - регистрации в книге или документации; - получению результатов на другом ПК. Тест является полным, если он удовлетворяет всем требованиям критериев тестирования. Полный тест называется успешным, если программа даёт правильные результаты при использовании этого теста. Критерий тестирования надёжен и эффективен, если каждая отыскиваемая ошибка обнаруживается при использовании полного теста. 4. Виды тестовых проверок Относительно тестовых данных можно выделить следующие виды тестовых проверок: 1. Проверка в нормальных условиях Данная проверка производится на основе данных, которые характерны для реальных условий функционирования программы. Результат такого теста - показ правильных результатов для характерньгх совокупностей данных. 2. Проверка в экстремальных условиях Тестовые данные при этой проверке должны включать граничные значения области изменения входных переменных, которые должны восприниматься программой как правильные данные. Здесь проводятся нулевые примеры: ввод цифр, имеющих нулевые значения, для символов - цепочка пробелов или нулей. 3. Проверка в исключительных ситуациях Для данной проверки значения данных подбирают так, чтобы они лежали за пределами допустимой области изменения. Данные должны содержать пробелы, цифры и буквы в разной последовательности и сочетании. 5. Объекты тестирования Объекты отладки и тестирования изменяются с поэтапным развитием npграмм от уровня алгоритмов до уровня завершенного эксплуатируемого и сопровождаемою программного средства. К каждому объекту на каждом этапе сопоставляется определенная категория тестов. Тестирование спецификаций проводится для проверки: полноты и согласованности функций программных компонентов; согласованности интерфейса в спецификациях программных компонентов. Тестирование программных модулей проводится для проверки: - структуры программного модуля, вычислений и преобразования данных программным модулем, полноты функций, выполняемых модулем. Тестирование функциональных групп программ проводится для проверки: структуры программного модуля, межмодульного интерфейса в группе программ; выполнения ограничений по использованию памяти и длительности исполнения группы программ; полноты решения функциональных задач группой программ. Тестирование комплекса программ при отладке проводится для проверки: полноты решения функциональных задач комплексом программ при типовых исходных данных; функционирования программ в критических ситуациях по условиям и логики решения задач; корректности использования ресурсов памяти и производительности вычислительной системы; параллельного исполнения программ; эффективности защиты от искажений исходных данных; определения надежности комплекса программ; оценки эффективности защиты от сбоев аппаратуры и не выявленных ошибок программ. Тестирование комплекса программ при испытаниях и при сопровождении проводится для проверки: - испытаний на соответствие комплекса программ техническому заданию; - удобства эксплуатации и взаимодействия человека с комплексом программ, - удобства установки и подготовки рабочей версии; - работы комплекса программ при конфигурациях оборудования; - корректности документов; - удобства сопровождения и модификации программ. 6. Виды тестирования Существует два основных вида тестирования: функциональное и структурное. При функциональном тестировании программа рассматривается как "черный ящик" (то есть ее текст не используется). Происходит проверка соответствия поведения программы ее внешней спецификации. Возможно ли при этом полное тестирование программы? Очевидно, что критерием полноты тестирования в этом случае являлся бы перебор всех возможных значений входных данных, что невыполнимо. Поскольку исчерпывающее функциональное тестирование невозможно, речь может идти о разработки методов, позволяющих подбирать тесты не "вслепую", а с большой вероятностью обнаружения ошибок в программе. При структурном тестировании программа рассматривается как "белый ящик" (т.е. ее текст открыт для пользования). Происходит проверка логики программы. Полным тестированием в этом случае будет такое, которое приведет к перебору всех возможных путей на графе передач управления программы (ее управляющем графе). Даже для средних по сложности программ числом таких путей может достигать десятков тысяч. Если ограничиться перебором только линейных не зависимых путей, то и в этом случае исчерпывающее структурное тестирование практически невозможно, т. к. неясно, как подбирать тесты, чтобы обеспечить "покрытие" всех таких путей. Поэтому при структурном тестировании необходимо использовать другие критерии его полноты, позволяющие достаточно просто контролировать их выполнение, но не дающие гарантии полной проверки логики программы. Но лаже если предположить, что удалось достичь полного структурного тестирования некоторой программы, в ней тем не менее, могут содержаться ошибки, т.к.: 1) программа может не соответствовать своей внешней спецификации, что в частности, может привести к тому, что в ее управляющем графе окажутся пропущенными некоторые необходимые пути; 2) не будут обнаружены ошибки, появление которых зависит от обрабатываемых данных (т.е. на одних исходных данных программа работает правильно; а на других - с ошибкой). Таким образом, ни структурное, ни функциональное тестирование не может быть исчерпывающим. Рассмотрим подробнее основные этапы тестирования программных комплексов. В тестировании многомодульных программных комплексов можно выделить 4 этапа: тестирование отдельных модулей; совместное тестирование модулей; тестирование функций программного комплекса (т.е. поиск различий между разработанной программой и ее внешней спецификацией); тестирование всего комплекса в целом (т.е. поиск несоответствия созданного программного продукта, сформулированным ранее целям проектирования, отраженным обычно в техническом задании). На первых двух этапах используются, прежде всего, методы структурного тестирования, т.к.: на последующих этапах тестирования эти методы использовать сложнее из-за больших размеров проверяемого программного обеспечения; - последующие этапы тестирования ориентированы на обнаружение ошибок различного типа, которые не обязательно связаны с логикой программы. При тестировании, как отдельных модулей, так и их комплексов должны быть решены две задачи: построение эффективного множества тестов; выбор способа комбинирования (сборки) модулей при создании тестируемого варианта программы. 7. Методы тестирования Структурное тестирование Поскольку исчерпывающее структурное тестирование невозможно, необходимо выбрать такие критерии его полноты, которые допускали бы их простую проверку и облегчали бы Целенаправленный подбор тестов. Наиболее слабым из критериев полноты структурного тестирования является требование хотя бы однократного выполнения (покрытия) каждого оператора программы. Более сильным критерием является так называемый критерий С1: каждая ветвь алгоритма (каждый переход) должна быть пройдена (выполнена) хотя бы один раз. Для большинства языков программирования покрытие переходов обеспечивает и покрытие операторов. Использование критерия покрытия условий может вызвать подбор тестов, обеспечивающих переход в программе, который пропускается при использовании критерия С1 (например, в программе на языке Паскаль, использующей конструкцию цикла WHILE x AND у DO... , применение критерия покрытия условий требует проверки обоих вариантов выхода из цикла: NOT x и NOT у ). С другой стороны покрытие условий может не обеспечивать покрытия всех переходов. Например, конструкция IF A AND В THEN... требует по критерию покрытия условий двух тестов (например, A=tme, B=false и А= false, B=trae), при которых может не выполняться оператор, расположенный в then - ветви оператора if. Практически единственным средством, предоставляемым современными системами программирования, является возможность определения частоты выполнения различных операторов программы (ее профилизации). Но с помощью этого инструмента поддержки тестирования можно проверить выполнение только слабейшего из критериев полноты - покрытие всех операторов. Правда, с помощью этого же инструмента можно проверить и выполнение критерия С1. Но для этого предварительно текст программы должен быть преобразован таким образом, чтобы все конструкции условного выбора (IF и CASE или SWITCH) содержали ветви ELSE или DEFAULT, хотя бы и пустые. В этом случае все ветви алгоритма, не выполнявшиеся на данном гесте будут "видимы" из таблицы частоты выполнения операторов преобразованной программы. Актуальной остается задача создания инструментальных средств, позволяющих: 1) накапливать информации о покрытых и непокрытых ветвях для всех использованных тестов; 2) выделять разработчику еще не покрытые при тестировании участки программы, облегчая выбор следующих тестов; 3) поддерживать более мощные критерии полноты структурного тестирования. Совместное тестирование модулей Известны два подхода к совместному тестированию модулей: пошаговое и монолитное тестирование. При монолитном тестировании сначала по отдельности тестируются все модули программного комплекса, а затем все они объединяются в рабочую программу для комплексного тестирования. При пошаговом тестировании каждый модуль для своего тестирования подключается к набору уже проверенных модулей. В первом случае для автономного тестирования каждого модуля требуется модуль -драйвер (то есть вспомогательный модуль, имитирующий вызов тестируемого модуля) и один или несколько модулей - заглушек (то есть вспомогательных модулей, имитирующих работу модулей, вызываемых из тестируемого). При пошаговом тестировании модули проверяются не изолированно друг от друга, поэтому требуются либо только драйверы, либо только заглушки. При сравнении пошагового и монолитного тестирования можно отметить следующие преимущества первого подхода: 1) меньшая трудоемкость (при монолитном тестировании требуются больше драйверов и заглушек, чем при пошаговом тестировании, когда требуются или только драйверы – если модули подключаются "снизу вверх ", - или только заглушки - если модули подключаются "сверху вниз"); 2) более раннее обнаружение ошибок в интерфейсах между модулями (их сборка начинается раньше, чем при монолитном тестировании); легче отладка, то есть локализация ошибок (они в основном связаны с последним in подключенных модулей); более совершенны результаты тестирования (более тщательная проверка совместного использования модулей). Есть преимущества и у монолитного тестирования: меньше расход машинного времени (хотя из-за большей сложности может потребоваться дополнительная проверка программы, и это преимущество будет сведено па нет); предоставляется больше возможностей для организации параллельной работы на начальном этапе тестирования. В целом более целесообразным является выбор пошагового тестирования. При его использовании возможны две стратегии подключения модулей: нисходящая и восходящая. Сверху - вниз (нисходящее тестирование) Нисходящее тестирование начинается с главного (или верхнего) модуля программы а выбор следующего подключаемого модуля происходит из числа модулей, вызываемых т уже протестированных. Одна из основных проблем, возникающих при нисходящем тестировании, - создание заглушек. Это тривиальная задача, т. к. как правило, недостаточно, чтобы в заглушке выполнялся вывод соответствующего информационного сообщения и возврат всегда одних и тех же значений выходных данных. Другая проблема, которую необходимо решать при нисходящем тестировании. Форма представления тестов в программе, так как, как правило, главный модуль получает входные данные не непосредственно, а через специальные модули ввода, которые при тестировании в начале заменяются заглушками. Для передачи в главный модуль разных тестов нужно или иметь несколько разных заглушек, или записать эти тесты в файл во внешней памяти и с помощью заглушки считывать их. Поскольку после тестирования главного модуля процесс проверки может продолжаться по-разному, следует придерживаться следующих правил: а) модули, содержащие операции ввода-вывода, должны подключаться к тестированию как можно раньше; б) критические (т.е. наиболее важные) для программы в целом модули также должны тестироваться в первую очередь. Основные достоинства нисходящего тестирования: уже на ранней стадии тестирования есть возможность получить работающий вариант разрабатываемой программы; быстро могут быть выявлены ошибки, связанные с организацией взаимодействие с пользователем. Кроме достоинств есть и проблемы, которые могут возникать при нисходящем тестировании: может оказаться трудным или даже невозможным построить один и тот же тест на входах разных модулей; не всегда окажется возможным легко оценить соответствие значений данных на входах разных модулей; результаты выполнения программы на построенном для проверки одного модуля тесте выводятся не им, а другими модулями, может оказаться трудным восстановление действительных результатов работы данного модуля; появляется соблазн совмещения нисходящего проектирования с тестированием, что, как правило, неразумно, т.к. проектирование - процесс итеративный и в нем неизбежен возврат на верхние уровни и исправление принятых ранее решений, что обесценивает результаты уже проведенного тестирования; может возникнуть желание перейти к тестированию модуля следующего уровня до завершения тестирования предыдущего по объективным причинам (необходимости создания нескольких версий заглушек, использования модулями верхнего уровня ресурсов модулей нижних уровней). Снизу - вверх (восходящее тестирование) При восходящем тестировании проверка программы начинается с терминальных модулей (т. е. тех, которые не вызывают не каких других модулей программы). Эти стратегия во многом противоположна нисходящему тестированию (в частности, преимущества становятся недостатками и наоборот). Нет проблемы выбора следующего подключаемого модуля - учитывается лишь то, чтобы он вызывал только уже протестированные модули. В отличие от заглушек драйверы не должны иметь несколько версий, поэтому их разработка в большинстве случаев проще (кроме того, использование средств автоматизации и отладки облегчает создание как раз драйверов, а не заглушек). Другие достоинства восходящего тестирования: - поскольку нет промежуточных модулей (тестируемый модуль является для рабочего варианта программы модулем самого верхнего уровня), нет проблем, связанных с возможностью или трудностью задания тестов, нет возможности совмещения проектирования с тестированием; нет трудностей, вызывающих желание перейти к тестированиюследующего модуля, не завершив проверки предыдущего. Основным недостатком восходящего тестирования является то, что проверка всей структуры разрабатываемого программного комплекса возможна только на завершающей стадии тестирования. Хотя однозначного вывода о преимущества той или иной стратегии пошагового тестирования сделать нельзя (нужно учитывать конкретные характеристики тестируемой прoграммы), в большинстве случаев более предпочтительным является восходящее тестирование. Функциональное тестирование Обзор методов проектирования тестов при функциональном тестировании начнем с метода эквивалентного разбиения. Т.к. нашей целью является построения множества гестов, характеризующегося наивысшей вероятностью обнаружения большинства ошибок в тестируемой программе, то тест из этого множества должен: 1) уменьшать (более чем на единицу) число других тестов, которые должны быть. Разработаны для достижения заранее поставленной цели "удовлетворительного" тестирования. 2) покрывать собой значительную часть других возможных тестов. Другими словами: 1) каждый тест должен заключать в себе проверку наибольшего числа задаваемых внешней спецификацией входных условии (ограничений па входные данные) для того, чтобы минимизировать общее число необходимых тестов; 2) необходимо разбить область значений входных данных на конечное число подобластей (которые будут называться классами эквивалентности), чтобы можно было полагать каждый тест, являющийся представителем некоторого класса, эквивалентным любому другому тесту этого класса (т.е. обнаруживающим одни и те же ошибки). В общем случае использование термина "класс эквивалентности" является здесь не вполне точным, т.к. выделенные подобласти могут пересекаться. Проектирование тестов по методу эквивалентного разбиения проводится в два этапа: - выделение по внешней спецификации классов эквивалентности; - построение множества тестов. Метод эквивалентного разбиения значительно лучше случайного подбора тестов, но имеет свои недостатки. Основной из них - пропуск определенных типов высокоэффективных тестов (т.е. тестов, характеризующихся большой вероятностью обнаружения ошибок). От этого недостатка во многом свободен метод анализа граничных условий. Под граничными условиями понимают ситуации, возникающие непосредственно на границе определенного в спецификации входного или выходного условия, выше или ниже ее. Метод анализа граничных условий отличается от метода эквивалентного разбиения следующим: - выбор любого представителя класса эквивалентности осуществляется таким образом, чтобы проверить тестом каждую границу этого класса; - при построении тестов рассматриваются не только входные условия, но и выходные (т. е. определенные во внешней спецификации ограничения на значения входных данных). Важность проверки границ выходных условий объясняется тем, что не всегда граничным значениям входных данных соответствуют граничные значения результатов работы программ. Анализ граничных условий - один из наиболее полезных методов проектирования тестов. Но он часто оказывается неэффективным из-за того, что граничные условия иногда едва уловимы, а их выявление весьма трудно. Общим недостатком двух рассмотренных выше методов функционального тестирования является то, что при их применении исследуются возможные комбинации входных условий. Следует, правда, заметить, что из-за весьма большого числа таких комбинаций, их анализ вызывает существенные затруднения. Но существует метод (метод функциональных диаграмм), позволяющий в этом случае систематическим образом выбрать высоко эффективные тесты. Полезным побочным эффектом этого метода является обнаружение неполноты и противоречивости во внешних спецификациях. Функциональная диаграмма- это текст на некотором формальном языке, с помощью которого транслируется спецификация, составленная на естественном или полуформальном языке. Метод функциональных диаграмм состоит из шести основных этапов. Па первом из них (необязательном) внешняя спецификация большого размера разбивается на отдельные участки. На втором этапе в спецификации выделяются причины и следствия, а на третьем анализируется семантическое содержание спецификации и она преобразуется в булевский граф, связывающий причины и следствия и называющийся функциональной диаграммой. На четвертом этапе функциональная диаграмма снабжается комментариями, которые задают ограничения на комбинации причин и следствий. На пятом этапе функциональная диаграмма преобразуется в таблицу решений. На шестом этапе производится анализ полученных решений. 8. Средства тестирования Под средствами тестирования понимают: Программы, которые помогают автоматизировать процесс испытаний. Пакет подпрограмм, входящих в некоторую программу. Хранение тестовых данных в целях их повторного тестирования. Среди других вспомогательных средств тестирования можно выделить: Генератор тестовых данных. Он формирует данные для использования в проверяемой программе. Программы-утилиты. Компаратор файлов - это программа, которая считывает два файла и выводит ка печать их различающие результаты. Программы-профилировщики. Они предназначены для отладки в тех случаях, когда надо выявить те участки программы, которые не были использованы Тестовый монитор - это программа, которая пересылает нужные данные т ими тестируемого модуля и накапливает выходные данные, выдаваемые на печать или записывающие в файл. |