Главные вкладки
Тестирование ИС
Материалы к занятиям по МДК "Тестирование ИС"
Скачать:
| Вложение | Размер |
|---|---|
 1_ponyatie_testirovaniya_1.pptx | 120.34 КБ |
| 2_modeli_razrabotki_po.pptx | 303.05 КБ |
| 3_standarty_reglamentiruyushchie_protsess_testirovaniya.pptx | 67.28 КБ |
| 4_staticheskoe_i_dinamicheskoe_testirovanie.pptx | 873.59 КБ |
Предварительный просмотр:
Подписи к слайдам:
Тестирование ПО процесс анализа программного средства и сопутствующей документации с целью выявления дефектов и повышения качества продукта.
Основные «эпохи тестирования» Период Характеристики 50–60-е годы XX века Фактически тестирование представляло собой отладку программ. Существовала концепция так называемого «исчерпывающего тестирования — проверки всех возможных путей выполнения кода со всеми возможными входными данными. 70-е годы XX века - тестирование позволяет удостовериться, что программа соответствует требованиям; - тестирование позволяет определить условия, при которых программа ведёт себя некорректно 80-е годы XX века произошло ключевое изменение места тестирования в разработке ПО: вместо одной из финальных стадий создания проекта тестирование стало применяться на протяжении всего цикла разработки. Появление первых элементарных попыток автоматизировать тестирование.
Основные «эпохи тестирования» Период Характеристики 90-е годы XX века произошёл переход от тестирования как такового к более всеобъемлющему процессу, который называется «обеспечение качества», охватывает весь цикл разработки ПО и затрагивает процессы планирования, проектирования, создания и выполнения тест-кейсов, поддержку имеющихся тест-кейсов и тестовых окружений. нулевые годы XXI века Появление гибких методологий разработки и таких подходов, как «разработка под управлением тестированием. Автоматизация тестирования уже воспринималась как обычная неотъемлемая часть большинства проектов. Современный этап гибкие методологии и гибкое тестирование, глубокая интеграция с процессом разработки, широкое использование автоматизации, колоссальный набор технологий и инструментальных средств, кросс-функциональность команды.
Тестирование ПО представляет собой один из возможных способов оценки его качества. Процесс тестирования является составной частью процесса верификации
Понятие верификации и валидации Verification – какая-либо проверка. Validation – придание чему-либо законной силы. Верификация – подтверждение того, что определенные требования реализованы в программе Валидация – подтверждение того, что функции, обеспечиваемые системой при ее использовании, соответствуют требованиям заказчика, т.е. система способна реализовывать свое предназначение.
Отличия верификации и валидации Верификация Валидация Делаем ли мы продукцию правильно? Произвели ли мы правильный продукт? Вся ли функциональность была реализована? Верно ли функциональность была реализована? Верификация предшествует валидации: она включает в себя полную проверку правильности написания, производства и прочего сотворения. Случается уже после верификации — это оценка качества произведенного продукта. Проводят разработчики. Проводят тестировщики. Статистический тип анализа: сравнение с установленными требованиями к продукту. Динамический тип анализа: продукт тестируется в эксплуатации для выяснения его соответствия нормам. Объективная оценка: выносится на основе соответствия определенным стандартам. Субъективная оценка: личная оценка, которую ставит специалист-тестировщик.
тестирование отвечает на вопрос «Как это сделано?» или «Соответствует ли поведение разработанной программы требованиям?», верификация – «Что сделано?» или «Соответствует ли разработанная система требованиям?», валидация – «Сделано ли то, что нужно?» или «Соответствует ли разработанная система ожиданиям заказчика?». Отличия верификации и валидации
Принципы тестирования Тестирование показывает наличие дефектов, но не доказывает, что их нет. Тестирование необходимо начинать как можно раньше в ЖЦ разработки системы Полное или исчерпывающее тестирование невозможно. Парадокс пестицида. Дефекты скапливаются в небольшом количестве модулей. Тестирование напрямую зависит от объекта, который подвергается испытаниям. Заблуждение об отсутствии ошибок в системе.
Группа обеспечения качества ПО ( Quality Assurance Team , QA team ): • Специалист по контролю качества - член проектной группы –осуществляет взаимодействие с разработчиками, менеджером программы и специалистами по безопасности и сертификации –отслеживает общее качество ПО, –соответствие ПО стандартам и спецификациям. • Специалисты по тестированию – участник команды разработчиков; –определяет стратегию тестирования, тест-требования и тест-планы для каждого этапа проекта; –выполняет тестирование системы, собирает и анализирует отчеты о прохождении тестирования. • Разработчики (программисты) – выполняют юнит -тестирование. Участники тестирования
Предварительный просмотр:
Подписи к слайдам:
Предварительный просмотр:
Подписи к слайдам:
характеристики качественного тестирования наличие целей тестирования на каждом уровне тестирования; любому процессу разработки соответствует свой процесс тестирования; возможность рецензирования документации тестировщиками начиная с самых первых версий; анализ требований и написание тестов начинается одновременно с деятельностью разработчиков или раньше.
Как измерить качество? Трансцендентный взгляд Качество нельзя измерить, его можно только увидеть и почувствовать Продуктовый взгляд Внутренние характеристики определяют качество Пользовательский взгляд: Цель и применение Качество это то, что лучше подходит пользователю в контексте применения Ценностный взгляд: рентабельность Соответствие цены и производительности Производственный взгляд: процесс Соответствие спецификации, строгое соблюдение процесса
стандарты, относящиеся к тестированию и качеству ПО: IEEE 12207/ISO/IEC 12207-2008 Software Life Cycle Processes (ГОСТ Р ИСО/МЭК12207—2010); ISO/IEC 25010:2011 Systems and software engineering -- Systems and software Quality Requirements and Evaluation ( SQuaRE ) -- System and software quality models (ГОСТ Р ИСО/МЭК 25010—2015); IEEE 829-1998 Standard for Software Test Documentation ; IEEE 1008-1987 (R1993, R2002) Standard for Software Unit Testing ; ISO/IEC 25051:2014 Information Technology. Software Packages – Quality Requirements and Testing (ГОСТ Р ИСО/МЭК 25051—2017); ISO/IEC 20000-1:2018. Information technology -- Service management (ГОСТ Р ИСО/МЭК 20000-1—2013 старая)
IEEE 12207/ISO/IEC 12207-2008 Software Life Cycle Processes описывает общую структуру процессов жизненного цикла программных средств. В рамках стандарта определены процессы, активности и задачи, которые актуальны при разработке, тестировании, поставке, приобретении, применении, сопровождении и завершении использования программного продукта.
ISO/IEC 25010:2011 Systems and software engineering -- Systems and software Quality Requirements and Evaluation ( SQuaRE ) -- System and software quality models нацеливает на то, чтобы учитывать три разные точки зрения при рассмотрении качества ПО: точку зрения разработчиков, которые воспринимают внутреннее качество ПО; точку зрения руководства и аттестации ПО на соответствие сформулированным к нему требованиям, в ходе которой определяется внешнее качество ПО; точку зрения пользователей, ощущающих качество ПО при использовании.
IEEE 829-1998 Standard for Software Test Documentation описывает требования к артефактам (документам) тестирования
Основные артефакты тестирования согласно IEEE 829 Артефакт Описание Тестовый план ( test plan) Основной документ, связывающий разработку тестов и тестирование с задачами проекта. Определяет необходимые виды тестирования, техники, проверяемую функциональность, критерии оценки полноты тестов и критерии выхода, а также график тестирования
Основные артефакты тестирования согласно IEEE 829 Артефакт Описание Тестовые сценарии ( test case) Сценарии проведения отдельных тестов. Каждый тестовый сценарий предназначен для проверки определенных свойств некоторых компонентов системы в определенной конфигурации
Основные артефакты тестирования согласно IEEE 829 Артефакт Описание Описания тестовых процедур ( test procedure specifications) Тестовые процедуры могут быть представлены в виде скриптов или программ, автоматизирующих запуск тестовых сценариев (автоматизированное тестирование), или в виде инструкций для человека, следуя которым можно выполнить те же сценарии (ручное тестирование)
Основные артефакты тестирования согласно IEEE 829 Артефакт Описание Отчеты о дефектах ( test incident reports, или bug reports) Описание ошибок, обнаруженных при выполнении тестов, с указанием всех условий, необходимых для их проявления Итоговый отчет о тестировании ( test summary report ) Отчет, аккумулирующий общую информацию по результатам тестов, включающий достигнутое тестовое покрытие и общую оценку качества компонентов тестируемой системы
IEEE 1008-1987 (R1993, R2002) Standard for Software Unit Testing подробно описывает процедуру подготовки модульных тестов, процессы выполнения и оценки результатов.
Основные процессы, которые регламентирует стандарт: планирование – определение используемых методов тестирования необходимых ресурсов, критериев полноты тестов и критерия выхода; определение проверяемых требований и ограничений; уточнение, корректировка и детализация планов; разработка набора тестов; выполнение тестов; проверка достижения критерия выхода с последующей оценкой полноты тестирования по специально выбранным критериям; оценка затрат ресурсов и качества протестированных модулей
ISO/IEC 25051:2014 Information Technology. Software Packages – Quality Requirements and Testing определяет требования к описанию программного продукта и пользовательской документации. стандарт содержит требования, предъявляемые к программам и данным, а также инструкции по испытаниям программных продуктов на соответствие заданным требованиям. описание продукта согласно стандарту должно быть таким, чтобы потенциальные покупатели могли без труда оценить пригодность для них данного продукта ещё до его приобретения.
ISO/IEC 20000-1:2018. Information technology -- Service management определяет требования к управлению и обслуживанию IT-сервисов. Цель – обеспечение качества сервиса (системы) на приемлемом уровне.
Контрольные вопросы Какие характеристики качественного тестирования вам известны? Какими стандартами регламентируется процесс тестирования? С каких трёх точек зрения согласно ISO 9126 может быть оценено качество программного продукта? Что описывает стандарт IEEE 829? Какие основные процессы составляют Unit-тестирование согласно IEEE 1008? Что описывает стандарт ISO 20000?
Предварительный просмотр:
Подписи к слайдам:
Какие взгляды существуют на качество продукта? Вспомни! Результативность, производительность, удовлетворенность, свободу от риска и покрытие контекста Модель качества продукта Функциональная пригодность, уровень произво-дительности , совместимость, удобство пользования, надежность, защищенность, сопровождаемось и переносимость (мобильность) Модель качества при использовании
Установить соответствие между требованиями и их составляющими 1. Общие требования А. Процедуры тестирования В. Отчет об отклонениях 2. Требования к плану тестирования С. График D. Цель 3.Требования к описанию процедуры тестирования E. Описание контрольных примеров F. Согласованность 4. Требования к результатам тестирования G. Оценка результатов тестирования H. Людские ресурсы 1-D,F; 2-C,H; 3-A,E; 4-B,G
Можем ли мы протестировать только работающий продукт или можем начать его тестирование еще до запуска?
ВИДЫ ТЕСТИРОВАНИЯ ПО ЗАПУСКУ КОДА
Динамическое тестирование (dynamic testing ) тестирование с запуском кода на исполнение . Основная идея этого вида тестирования состоит в том, что проверяется реальное поведение (части) приложения.
включает в себя тестирование ПО в режиме реального времени путем предоставления входных данных и изучения результата поведения программы. осуществляется с помощью ручного или автоматического выполнения заранее подготовленного набора тестов. является частью процесса валидации программного обеспечения. Динамическое тестирование (dynamic testing )
Преимущества рассматривает всю функцио-нальность приложения, поэ -тому качество соответствует самым высоким стандартам. приложение тестируется с точки зрения пользователя, что повышает качество ПО. обнаружение сложных ошибок, которые могли ускользнуть на этапе анализа кода. м ожет быть автоматизировано с помощью специальных инструментов. Недостатки занимает много времени. высокая стоимость проведения тестирования. найденные баги обнаруживаются позже в жизненном цикле разработки. Динамическое тестирование (dynamic testing )
Динамические тесты не могут быть исполнены, пока не написан код!
тестирование без запуска кода на исполнение . Статическое тестирование начинается на ранних этапах жизненного цикла ПО и является, соответственно, частью процесса верификации. Статическое тестирование ( static testing )
поиск потенциальных дефектов в программном обеспечении. обнаружение и устранение ошибок и дефектов в различных сопроводительных документах (например, спецификации требований к программному обеспечению). Статическое тестирование ( static testing )
Можно поделить статическое тестирование на 2 типа: Обзоры (Review). Проверка обычно используется для поиска и устранения ошибок или неясностей в документах. Статический анализ ( Static Analysis). Код, написанный разработчиками, анализируется на наличие структурных дефектов, которые могут привести к ошибкам. Статическое тестирование ( static testing )
Обзоры делятся на: Неформальные. При неофициальном рассмотрении создатель документов показывает содержание документов аудитории. Каждый присутствующий высказывает свое мнение, что позволяет выявить недостатки на ранней стадии. Сквозные просмотры. Выполняются опытным человеком или экспертом для проверки отсутствия дефектов, с целью предупреждения возникновения проблем на этапе разработки или тестирования. Экспертная оценка. Означает проверку документов для выявления и исправления дефектов. В основном это делается в команде. Инспектирование ПО. Это проверка документа вышестоящим органом, например, проверка требований к программному обеспечению.
Статический анализ Статический анализ включает оценку качества кода, написанного разработчиками. Для анализа кода и сравнения его со стандартом используются разные инструменты. Статический анализ хорошо помогает найти такие ошибки, как: — неиспользуемые переменные, — мертвый код, — бесконечные циклы, — переменные с неопределенными значениями, — неправильный синтаксис.
Статический анализ Целью анализа является наиболее раннее выявление ошибок и потенциальных проблем в программном продукте. Как правило, код ревью выполняется самим разработчиком.
Статическое тестирование ( static testing ) В рамках этого подхода тестированию могут подвергаться: Документы (требования, тест-кейсы , описания архитектуры приложения, схемы баз данных и т.д.). Графические прототипы (например, эскизы пользова-тельского интерфейса). Код приложения (что часто выполняется самими программистами в рамках аудита кода ( code review ), являющегося специфической вариацией взаимного просмотра в применении к исходному коду). Параметры (настройки) среды исполнения приложения. Подготовленные тестовые данные.
Статическое тестирование Преимущества Недостатки Процесс статического тестирования может занимать много времени, так как в основном он выполняется вручную. Препятствует обнаружению уязвимостей, представленных в среде выполнения. Снижает стоимость фикса найденных багов, Отзывы помогают улучшить функционирование процесса, что также помогает команде избежать подобных дефектов и багов. Повышает информированность о различных проблемах качества программного обеспечения. Улучшает обмен критической и важной информацией между членами команды. Существенно сокращаются усилия по исправлению ошибок.
Сравнение Динамическое тестирование Статическое тестирование Этап Выполнение программного кода Направленность Этап разработки ПО Стоимость исправления багов Цель Число дефектов
Динамическое тестирование Статическое тестирование Этап Валидация Верификация Выполнение программного кода Требует Не требует Направленность Обеспечивает функциональность продукта Ориентировано на предотвращение дефектов Этап разработки ПО Более поздние этапы Ранние этапы Стоимость исправления багов Высокая Низкая Цель Сравнение реального поведения программы с ожидаемым Предотвращение дефектов ПО Число дефектов Обнаруживается меньшее число дефектов Обнаруживается большее число дефектов
Вывод Статическое тестирование требует много времени на бурные дискуссии и встречи. Однако оно помогает предотвращать появления дефектов на последних этапах разработки продукта. Поэтому статическое тестирование по праву считается важным шагом на пути к разработке ПО без ошибок. Но и динамическое тестирование не менее важно. Благодаря непосредственному выполнению тестов программного обеспечения (проверки функционального поведения, производительности, надежности и других важных аспектов) команда может проверить и подтвердить качество и эффективность ПО.