Вопросы Место задач управления функциональной безопасностью при решении задач реализации положений доктрины Industry 0
 Скачать 478.57 Kb.
|
|
18. Концептуальные основы тестирования: текущее состояние. Причины внесения изменений в системную модель «треугольник проекта» Треугольник проекта - системная модель, разработанная в 1994 году. Она подразумевала, что в проекте есть 3 ключевых фактора: 1) Деньги 2) Время 3) Область охвата Треугольник проекта также называют железным треугольником или тройным ограничением. Как его не назови, он сводится к одному: невозможно изменить бюджет, расписание или область охвата проекта, не повлияв, по крайней мере на один из других факторов. · Чтобы приблизить дату окончания (время), вы можете потратить больше ресурсов (деньги) или убрать некоторые возможности (область охвата), чтобы было меньше работы. · Чтобы сделать проект в рамках бюджета (затраты), вы можете не оплачивать сверхурочные и закончить проект позднее (время) либо сократить возможности продукта (область охвата). Качество — это четвертый элемент проектного треугольника. Оно находится в центре, и любое изменение сторон влияет на него. Тут важно помнить, что универсального стандарта качества не существует. Для каждого проекта качество определяется в нем самом. Для некоторых компаний важнейшей мерой качества является соблюдение рамок бюджета. Для других важнее вовремя вывести продукт на рынок. Руководителю проекта нужно знать, как качество определяется для организации и для самого проекта. В большинстве проектов по меньшей мере одна сторона треугольника фиксирована. Возможно, бюджет не обсуждается (знакомая ситуация, не правда ли?). Или, предположим, продукт непременно должен поступить в продажу к определенной дате. Вероятно, требуется и то, и другое. Если проблемной является фиксированная сторона, зачастую ясно, что нужно делать. Например, если вы обнаружите, что разработка компонента программного обеспечения займет больше времени, чем прогнозировалось, и вы подписали контракт, требующий предоставить этот компонент (область охвата), вам придется либо отодвигать дату окончания, либо привлекать дополнительные ресурсы, чтобы закончить проект вовремя. Если проблема не связана с фиксированной стороной, не стоит отчаиваться. В этом и заключается прелесть проектного треугольника — всегда можно что-то изменить. Например, если проект должен быть выполнен вовремя, а его область охвата расширилась, можно скорректировать затраты, добавив ресурсы. Если фиксированы все три стороны, не паникуйте. Да, проект проблемный, но по крайней мере мы знаем это, и это дает нам возможность пересмотреть его цели или стандарты качества. 19. Содержание подхода «Model Driven Architecture» Model Driven Architecture - стандарт посвященный вопросам проектирования архитектуры. Основная идея: система состоит из 4-ых неделимых компонентов, которые все зависят (крутятся) от цели: 1. Информация, которая будет использоваться для достижения цели 2. Обработка информации 3. Оборудование на котором будут реализовываться предыдущий компонент 4. Персонал, который будет разрабатывать систему и использовать Содержание MDA: В организации есть бизнес стратегия действий. Исходя из этой стратегии формируются бизнес-процессы и их архитектура – Бизнес-архитектура, реализация которой обеспечивает эту бизнес стратегию. Исходя из архитектуры бизнес-процессов формируется Архитектура приложений (архитектура ПО), которая будет поддерживать бизнес архитектуру, и Архитектура информации (архитектура хранения информации, БД, файлы и пр.). Архитектура приложений и информации формируют ИТ-инфраструктуру – комплекс программных и аппаратных средств, требуемых для реализации бизнес-процессов. Системы построенные по MDA являются закрытыми, т.е. можно определить вход (бизнес-стратегия, внешние источники данных т.д.). Проще говоря, можно определить устройство и границу, а также вход и выход. Закрытость – принципиальное требование MDA. 20. Основные подходы «классического тестирования». Ограничения подходов Подход 1: Тестированием занимается разработчик или менеджер. Разработчик имеет, что называется, «замыленный глаз» и проверяет только те функции, которые должны работать так, как он изначально задумал. Менеджер в силу своей нагрузки поверхностно смотрит, всё ли работает, не проверяя каждый модуль по-отдельности. Подход 2: Тестировщиков нанимают на стадии завершения. При тестировании системы в самом конце существенные ошибки на уровне архитектуры будут найдены слишком поздно. Это свободное интуитивное тестирование, что в свою очередь влечет за собой игнорирование ряда альтернативных пользовательских сценариев. Проект во время разработки претерпевал изменения, изначальная документация уже не соответствует конечному результату, что осложняет разбор баг-репортов Подход 3: Тестировщики проверяют все задачи разработчиков на предмет соответствия результата изначальной постановке задачи. Главный минус: подход бессистемный. Тестировщику надоедает каждый раз вручную проверять типичные задачи Подход 4: Тестировщики занимаются тест-дизайном. Проектирование и создание тестовых случаев будет проводиться с учетом специфики проекта и требований к нему Подход 5: Внедряется система управления тестированием. Когда компания растёт, необходимо хранить и систематизировать свои наработки. Внедряются системы хранения тест-кейсов и инструменты тестирования Подход 6: Появляется автоматизация тестирования. Разработчики и тестировщики пишут автотесты: unit-тесты и ui-тесты. То есть все регулярные проверки автоматизируются. Исключается человеческий фактор: забыл или было лень. Автотесты значительно сокращают временные расходы и повышают качество продукта. Подход 7: Усложняется иерархия, появляются новые роли в команде тестирования. Верхом эволюции тестирования можно назвать появление иерархии и узких специалистов: тест-менеджер, тест-лид, тест-аналитик, тест-дизайнер и так далее. Каждый человек отвечает за свой фронт работы. Ограничения подходов к тестированию: 1) необходимость чёткой формализации требования для того, чтобы создать программный продукт, причём качество определялось по большей части именно как степень соответствия созданного продукта предъявленным к нему требованиям. 2) разработчик и тестировщик не должны совмещать свою работу, ведь цель первого - доказать, что ошибки нет, а второго - доказать, что она есть, такое ограничение с одной стороны, требует привлекать больше кадров, с другой стороны это психологически верно и не позволяет разработчику принять возможную ошибку за хороший, правильный результат. 3) классические подходы не позволяют решить всех проблем, но всё равно стоит искать баланс между “классикой” и новыми подходами 21. Содержание альфа и бета-тестирования. Ограничения альфа-тестирования После того, как отдельные программные модули готовы, они объединяются в некое единое целое. Это еще не полнофункциональная программа, но она уже способна работать и выполнять, хотя бы частично, свои главные задачи. Такой вариант программы и называют Альфа-тестирование — это этап отладки и проверки альфа-версии программы, а люди, которые будут заниматься ее тестированием — альфа-тестерами. Это могут быть штатные тестировщики компании или люди, которые работают по договору, но это квалифицированные специалисты, умеющие работать со специализированным программным обеспечением и пользоваться специальными методиками. По окончании работы с альфа-версией выпускается бета-версия. Она представляет собой реально работающую версию программы с полным функционалом. И задача бета-тестов – оценить возможности и стабильность работы программы с точки зрения ее будущих пользователей. Поэтому на роль бета-тестеров приглашаются просто люди, имеющие опыт работы с программами такого типа или, что еще лучше, с предыдущей версией этой же программы. Может быть объявлено открытое бета-тестирование, когда на роль бета-тестеров приглашают всех желающих Преимущества альфа-тестирования: • Обеспечивает лучшее представление о надежности программного обеспечения на ранней стадии. • Помогает моделировать поведение пользователя и окружающую среду в режиме реального времени. • Обнаруживает много серьезных ошибок. • Дает возможность раннего обнаружения ошибок в отношении дизайна и функциональности. Ограничения альфа-тестирования: •Функциональность не может быть проверена на всю глубину, поскольку программное обеспечение все еще находится на стадии разработки. Иногда разработчики и тестировщики недовольны результатами альфа-тестирования Бета-тестирование может быть: • Закрытым: Программа тестируется в небольшой группе пользователей по приглашениям. • Открытым: Этот вариант позволяет протестировать приложение в большей группе и получить большой объем обратной связи. Любой пользователь сможет присоединиться к открытому бета-тестированию и отправить личный отзыв. 22. Концептуальные основы сценарного тестирования Благодаря тому, что проект испытывали на ранних стадиях жизненного цикла (на стадиях технического задания, разработки архитектуры, детального проектирования, кодирования, поэтапной сборки, тестирования интерфейсов, верификации программы) - возник сценарный подход к испытанию. Сценарное тестирование - это тестирование программного обеспечения, в котором используются сценарии: гипотетические истории, помогающие тестеру справиться со сложной проблемой или тестовой системой. Хороший сценарий - это достоверная, сложная, убедительная или мотивирующая история; результат которой легко оценить. Тесты по сценариям обычно отличаются от тестовых наборов тем, что тестовые наборы представляют собой отдельные этапы, тогда как сценарии охватывают несколько этапов. При сценарном тестировании используются 2 подхода: 1) Составление системных сценариев. В этом методе в качестве тестового сценария используются только те наборы реальных пользовательских действий, которые охватывают несколько компонентов (модулей) в системе. 2) Составление сценариев, основанных на вариантах использования. В этом методе основное внимание уделяется тому, как пользователь использует систему с различными ролями и средой. Сценарий - специально написанный текст, который описывает поведение моделируемой системы в форме последовательности выполняемых действий участником и самой системы. В пользу сценарного тестирования - сравнительная легкость планирования: - тест-кейсы можно легко поделить между различными тестировщиками или командами. - сценарии были заложены в планах верификации системы, подсистемы и плане валидации системы. 23. Содержание подхода «Ad hoc» тестирования. Примеры реализации подхода «Ad hoc» тестирование Свободное тестирование (ad-hoc testing) – это вид тестирования, который выполняется без подготовки к тестированию продукта, без определения ожидаемых результатов, проектирования тестовых сценариев. Это неформальное, импровизационное тестирование. Такой способ тестирования в большинстве случаев дает большее количество заведенных отчётов об ошибке. Это обусловлено тем, что тестировщик на первых шагах приступает к тестированию основной функциональной части продукта и выполняет как позитивные, так и негативные варианты возможных сценариев. Свободное тестирование это реакция на то что системы открыты и тестировщик не знает какие исходные данные могут оказаться на входе. Свободное тестирование можно разложить на 3 вида: • Buddy testing – процесс, когда 2 человека, как правило разработчик и тестировщик, работают параллельно и находят дефекты в одном и том же модуле тестируемого продукта. Такой вид тестирования помогает тестировщику выполнять необходимые проверки, а разработчику исправлять множество дефектов на ранних этапах. • Pair testing – процесс, когда 2 тестировщика проверяют один модуль и помогают друг другу. К примеру, один может искать дефекты, а второй их документировать. Таким образом, у одного тестера будет функция, скажем так, обнаружителя, у другого – описателя. • Monkey testing – произвольное тестирование продукта с целью как можно быстрее, используя различные вариации входных данных, нарушить работу программы или вызвать ее остановку (простыми словами – сломать). Из основных преимуществ свободного тестирования можно выделить: • Нет необходимости тратить время на подготовку документации. • Самые важные дефекты зачастую обнаруживаются на ранних этапах. • Часто применяется, когда берут нового сотрудника. С помощью этого метода, человек усваивает за 3 дня то, что, разбираясь с тестовыми случаями, разбирал бы неделю - это называется форсированное обучение новых сотрудников. • Возможность найти трудновоспроизводимые и трудноуловимые дефекты, которые невозможно было бы найти, используя стандартные сценарии проверок. 24. Концептуальные основы «исследовательского тестирования». Исследовательское тестирование (exploratory testing) — это одновременное изучение программного продукта, проектирование тестов и их выполнение. Это неформальный метод проектирования тестов, при котором тестировщик активно контролирует проектирование тестов и то, как эти тесты выполняются, и использует полученную во время тестирования информацию для проектирования новых тестов. Если каждый следующий тест, который выполняет тестировщик, выбирается по результатам предыдущего теста, это означает, что мы используем исследовательское тестирование. Когда следует применять исследовательское тестирование? - когда нужно обеспечить быструю обратную связь для нового продукта или новой функциональности продукта - когда нужно быстро ознакомиться с продуктом - когда уже были проведены основные виды тестирования и время позволяет разнообразить методы тестирования - когда нужно найти дефект, локализованный в определенном модуле в кратчайшие сроки - когда проверяется работа другого специалиста по тестированию - когда нужно изучить состояние конкретного риска для принятия решения о необходимости покрытия конкретной области тестами Предпосылки к использованию исследовательского тестирования в чистом виде: ● Мало времени: если тестовая документация написана, но времени на прохождение тестов уже нет, нужно выбирать наиболее критичные области приложения, которые реально протестировать за имеющееся время. Составить чек-лист с идеями и тестировать вокруг них. ● Сложности с требованиями: требований нет, они не полны или устарели и нет возможности их актуализировать. ● Небольшой проект: продукт маленький, и разработка тестовых сценариев займет больше времени, чем сам процесс тестирования. В пользу исследовательского тестирования: ● без предсказуемости и жесткой привязанности к фиксированной последовательности шагов можно найти больше дефектов. В основном это будут дефекты, не относящиеся к основной функциональности; ● не нужно тратить время на предварительное доскональное описание всех сценариев; ● не нужна поддержка тестовых сценариев; ● не происходит привыкание к тестовым сценариям, и их прохождение не происходит «не глядя»; ● не теряется цельное видение продукта; ● критические дефекты находятся быстрее; ● повышается скорость тестирования; ● можно сразу начинать тестировать продукт, даже если требований нет вообще. Кроме того, что это весело, это еще и значительная экономия времени, в сравнении с отдельным изучением документации и последующим тестированием; ● интереснее и креативнее. Тесты ограничиваются только фантазией проходящего и его глубиной знаний о продукте. 25. Область применимости методов «исследовательского тестирования». Ограничения «исследовательского тестирования» Область применимости: - Когда нужно обеспечить быструю обратную связь для нового продукта или новой функциональности продукта. - Когда нужно быстро ознакомиться с продуктом. - Когда уже были проведены основные виды тестирования и время позволяет разнообразить методы тестирования. - Когда нужно найти дефект, локализованный в определенном модуле в кратчайшие сроки. - Когда проверяется работа другого специалиста по тестированию. - Когда нужно изучить состояние конкретного риска для принятия решения о необходимости покрытия конкретной области тестами. Ограниченность исследовательского подхода: - Тестировщику с небольшим опытом будет испытывать трудности на первых этапах работ, из-за отсутствия наглядного представление о том, что и как тестировать. - Сложности в оценке тестового покрытия, а также в расчете временных затрат. - Требуется большое количество времени для изучения продукта. 26. Предпосылки совместного использования «исследовательского» и «сценарного» тестирования. Системное сочетание исследовательского и сценарного тестирования: Исследовательское тестирование — не означает полное отсутствие документации и хаос, а является мощным инструментом. Используя ранжирование типов тестирования от полностью исследовательского до полностью сценарного, можно подобрать оптимальный уровень документации для вашего проекта и сэкономить время. Сценарное и исследовательское тестирование являются полностью совместимыми и компенсируют недостатки друг друга. Можно покрыть детальными тестами сложные технические аспекты проекта и написать поверхностные чек-листы для пользовательского интерфейса. Использование исследовательского тестирование в дополнение к сценарному тестированию: 1. Тестировщики постоянно проходят одни и те же тестовые сценарии 2. При многократном прохождении одних и тех же тестов, например, при регрессионном тестировании. Тестировщики теряют концентрацию и начинают пропускать дефекты. В этом случае исследовательское тестирование помогает взглянуть на проект под новым углом и найти пропущенные дефекты. 3. Тестировщик отвлекается от шаблонных действий и чувствует себя в большей степени обычным пользователем. Это помогает найти дефекты, сильнее влияющие на конечного потребителя разрабатываемого продукта. 4. Пришел внезапный запрос на изменения - Времени на разработку новых сценариев нет, так как все заняты другими запланированными задачами или изменения потребуют переработать большую часть документации. В этой ситуации тестирование исследовательским методом может быть наиболее оптимальным. 5. Когда хочется перестраховаться - Продукт уже протестирован по сценариям, но всё еще хочется убедиться в том, что ничего не было упущено. 27. Содержание «регрессионного тестирования» Регрессионное тестирование - вид тестирования, направленный на проверку изменений, сделанных в приложении или окружающей среде (починка дефекта, слияние кода, миграция на другую ОС, базу данных или сервер приложения), для подтверждения того факта, что существующая ранее функциональность работает как и прежде. — Регрессионными могут быть как функциональные, так и нефункциональные тесты Для регрессионного тестирования обычно используются тест-кейсы, которые были написаны на ранних стадиях разработки и тестирования. Это дает гарантию того что, в новой версии приложения не повредили уже существующую функциональность. Регрессионное тестирование – это механизм проверки, который направлен на обнаружение различных проблем в уже проверенных участках программ. Делается это не для окончательного убеждения в отсутствии неработающих участков кода, а чтобы найти и исправить регрессионные ошибки. Под ними понимают баги, которые появляются не во время написания программы, а при добавлении новых участков кода или исправлении допущенных ранее промахов в синтаксисе кода. Есть несколько видов регрессионных тестов: ● Верификационные тесты. Проводятся для проверки исправления обнаруженного и открытого ранее бага. ● Тестирование верификации версии. Содержит принципы дымного тестирования и тестирование сборки: проверка работоспособности основной функциональности программы в каждой новой сборке. ● Непосредственно само регрессионное тестирование – повторное выполнение всех тестов, которые были написаны и проведены ранее. Они выполняются по уже существующим тест-кейсам независимо от того, были в ходе их прохождения найдены баги, или нет. ● Тестирование в новом билде уже исправленных багов в старых билдах. Это выполняется для того, чтобы проверить, не возобновило ли обновление билда старых дефектов |