лекция качество программного обеспечения. 1 лекция. Качество программного обеспечения
 Скачать 24.23 Kb.
|
|
Качество программного обеспечения - это степень, в которой программное обеспечение обладает требуемой комбинацией свойств. Качество программного обеспечения - это совокупность характеристик программного обеспечения, относящихся к его способности удовлетворять установленные и предполагаемые потребности. Обеспечение качества - это совокупность мероприятий, охватывающих все технологические этапы разработки, выпуска и эксплуатации программного обеспечения (ПО) информационных систем, предпринимаемых на разных стадиях жизненного цикла ПО для обеспечения требуемого уровня качества выпускаемого продукта. Контроль качества - это совокупность действий, проводимых над продуктом в процессе разработки для получения информации о его актуальном состоянии в разрезах: "готовность продукта к выпуску", "соответствие зафиксированным требованиям", "соответствие заявленному уровню качества продукта". Тестирование программного обеспечения - это одна из техник контроля качества, включающая в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis). Верификация - это процесс оценки системы или её компонентов с целью определения, удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа. Т.е. выполняются ли наши цели, сроки, задачи по разработке проекта, которые были определены в начале текущей фазы. Валидация - это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе. План тестирования - это документ, который описывает весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения. Тест дизайн - это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы), в соответствии с определенными ранее критериями качества и целями тестирования. Тестовый случай - это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части. Баг/дефект репорт - это документ, описывающий ситуацию или последовательность действий, приведшую к некорректной работе объекта тестирования с указанием причин и ожидаемого результата. Тестовое покрытие - это одна из метрик оценки качества тестирования, представляющая из себя плотность покрытия тестами требований либо исполняемого кода. Детализация тест-кейсов - это уровень детализации описания тестовых шагов и требуемого результата, при котором обеспечивается разумное соотношение времени прохождения к тестовому покрытию. Время прохождения тест кейса - это время от начала прохождения шагов тест-кейса до получения результата теста. Качество программного обеспечения - это степень, в которой ПО обладает требуемой комбинацией свойств. Качество программного обеспечения - это совокупность характеристик ПО, относящихся к его способности удовлетворять установленные и предполагаемые потребности. Функциональность (Functionality) - определяется способностью ПО решать задачи, которые соответствуют зафиксированным и предполагаемым потребностям пользователя, при заданных условиях использования ПО. Т.е. эта характеристика отвечает то, что ПО работает исправно и точно, функционально совместимо соответствует стандартам отрасли и защищено от несанкционированного доступа. Надежность (Reliability) – способность ПО выполнять требуемые задачи в обозначенных условиях на протяжении заданного промежутка времени или указанное количество операций. Атрибуты данной характеристики – это завершенность и целостность всей системы, способность самостоятельно и корректно восстанавливаться после сбоев в работе, отказоустойчивость. Удобство использования (Usability) – возможность легкого понимания, изучения, использования и привлекательности ПО для пользователя. Эффективность (Efficiency) – способность ПО обеспечивать требуемый уровень производительности, в соответствии с выделенными ресурсами, временем и другими обозначенными условиями. Удобство сопровождения (Maintainability) – легкость, с которой ПО может анализироваться, тестироваться, изменяться для исправления дефектов для реализации новых требований, для облегчения дальнейшего обслуживания и адаптирования к имеющемуся окружению. Портативность (Portability) – характеризует ПО с точки зрения легкости его переноса из одного окружения (software/ hardware) в другое. Дефект, баг (defect, bug) – недостаток компонента или системы, который может привести к отказу определенной функциональности. Дефект, обнаруженный во время исполнения программы, может вызвать отказ отдельного компонента или всей системы. Сбой (failure) – несоответствие фактического результата (actual result) работы компонента или системы ожидаемому результату (expected result). Таким образом, баг существует при одновременном выполнении трех условий: известен ожидаемый результат; известен фактический результат; фактический результат отличается от ожидаемого результата. Всего существует несколько источников дефектов и, соответственно, сбоев: ошибки в спецификации, дизайне или реализации программной системы; ошибки использования системы; неблагоприятные условия окружающей среды; умышленное причинение вреда; потенциальные последствия предыдущих ошибок, условий или умышленных действий. Условно можно выделить пять причин появления дефектов в программном коде. Недостаток или отсутствие общения в команде. Зачастую бизнес-требования просто не доходят до команды разработки. У заказчика есть понимание того, каким он хочет видеть готовый продукт, но, если должным образом не объяснить его идею разработчикам и тестировщикам, результат может оказаться не таким, как предполагалось. Требования должны быть доступны и понятны всем участникам процесса разработки ПО. Сложность программного обеспечения. Современное ПО состоит из множества компонентов, которые объединяются в сложные программные системы. Многопоточные приложения, клиент-серверная и распределенная архитектура, многоуровневые базы данных – программы становятся все сложнее в написании и поддержке, и тем труднее становится работа программистов. А чем труднее работа, тем больше ошибок может допустить исполняющий ее человек. Изменения требований. Даже незначительные изменения требований на поздних этапах разработки требуют большого объема работ по внесению изменений в систему. Меняется дизайн и архитектура приложения, что, в свою очередь, требует внесения изменений в исходный код и принципы взаимодействия программных модулей. Такие текущие изменения зачастую становятся источником трудноуловимых дефектов. Тем не менее, часто меняющиеся требования в современном бизнесе – скорее правило, чем исключение, поэтому непрерывное тестирование и контроль рисков в таких условиях – прямая обязанность специалистов отдела обеспечения качества. Плохо документированный код. Сложно поддерживать и изменять плохо написанный и слабо документированный программный код. Во многих компаниях существуют специальные правила по написанию и документированию кода программистами. Хотя на практике часто бывает так, что разработчики вынуждены писать программы в первую очередь быстро, а это сказывается на качестве продукта. Средства разработки ПО. Средства визуализации, библиотеки, компиляторы, генераторы скриптов и другие вспомогательные инструменты разработки – это тоже зачастую плохо работающие и слабо документированные программы, которые могут стать источником дефектов в готовом продукте. Тестирование программного обеспечения – креативная и интеллектуальная работа. Разработка правильных и эффективных тестов – достаточно непростое занятие. Принципы тестирования, представленные ниже, были разработаны в последние 40 лет и являются общим руководством для тестирования в целом. Верификация (verification)– это процесс оценки системы или её компонентов с целью определения того, удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа. То есть выполняются ли задачи, цели и сроки по разработке продукта. Валидация (validation)– это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе. Тестирование – не изолированный процесс. Это часть модели жизненного цикла программного обеспечения (Software Development Life Cycle, SDLC). Именно поэтому выбор средств и методик тестирования будет напрямую зависеть от выбранной модели разработки. В этом разделе мы рассмотрим наиболее часто применяемые подходы к разработке программного обеспечения, а также популярные сегодня методологии и практики, такие как Agile и Scrum. Жизненный цикл программного обеспечения (также называемый циклом разработки) – это условная схема, включающая отдельные этапы, которые представляют стадии процесса создания ПО. При этом, на каждом этапе выполняются разные действия. Основные цели этого этапа убедиться, что вся запланированная функциональность действительно была реализована; проверить, что все отчеты об ошибках, поданные ранее, были, так или иначе, закрыты; завершение работы тестового обеспечения, тестового окружения и инфраструктуры; оценить общие результаты тестирования и проанализировать опыт, полученный в его процессе. Каскадная (водопадная) модель сейчас представляет, скорее, исторический интерес, т.к. в современных проектах практически не применима. Она предполагает однократное выполнение каждой из фаз проекта, которые, в свою очередь, строго следуют друг за другом. Очень упрощённо можно сказать, что, в рамках этой модели, в любой момент времени команде “видна” лишь предыдущая и следующая фаза. В реальной же разработке ПО приходится “видеть весь проект целиком” и возвращаться к предыдущим фазам, чтобы исправить недоработки или что-то уточнить. Классификация прототипов: Горизонтальные прототипы — моделирует исключительно UI, не затрагивая логику обработки и базу данных. Вертикальные прототипы — проверка архитектурных решений. Одноразовые прототипы — для быстрой разработки. Эволюционные прототипы — первое приближение эволюционной системы. Основные термины, которые используются в методологии: Владелец продукта (Product owner) — человек, который имеет непосредственный интерес в качественном конечном продукте, он понимает, как это продукт должен выглядеть/работать. Этот человек не работает в команде, он работает на стороне заказчика/клиента (это может быть как другая компания, так и другой отдел), но этот человек работает с командой. И это тот человек, который расставляет приоритеты для задач. Scrum-мастер — это человек, которого можно назвать руководителем проекта, хотя это не совсем так. Главное, что это человек настолько увлечённый данной методологией, что несет её принципы как своей команде, так и заказчику и, соответственно, следит за тем, чтобы все принципы Scrum соблюдались. Scrum-команда — это команда, которая принимает все принципы Scrum и готова с ними работать. Спринт — отрезок времени, который берется для выполнения определенного (ограниченного) списка задач. Рекомендуется брать 2-4 недели (длительность определяется командой один раз). Бэклог (backlog) — это список всех работ. Можно сказать, это ежедневник общего пользования. Различают 2 вида бэклогов: Product-бэклог и спринт-бэклог. 1. Product-бэклог — это полный список всех работ, при реализации которых мы получим конечный продукт. 2. Спринт-бэклог — это список работ, который определила команда и согласовала с Владельцем продукта на ближайший отчетный период (спринт). Задания в спринт-бэклог берутся из product-бэклога. Планирование спринта — это совещание, на котором присутствуют все (команда, Scrum-мастер, Владелец продукта). В течение этого совещания Владелец продукта определяет приоритеты заданий, которые он хотел бы увидеть выполненными по истечении спринта. Команда оценивает по времени, сколько из желаемого они могут выполнить. В итоге получается список заданий, который не может меняться в течение спринта и к концу спринта должен быть полностью выполнен. Жизненный цикл спринта Планирование спринта. В начале каждого спринта проводится планирование этого самого спринта. В планировании спринта участвуют заказчики, пользователи, менеджмент, владелец продукта, скрам мастер и команда. Планирование спринта состоит из двух последовательных митингов: 1) Планирование спринта, митинг первый. Участники: команда, владелец продукта, скрам мастер, пользователи, менеджмент Цель: Определить цель спринта (Sprint Goal) и Sprint Backlog -функциональность, которая будет разработана в течение следующего спринта для достижения цели спринта. Артефакт: Sprint Backlog 2) Планирование спринта, митинг второй. Участники: Скрам Мастер, команда Цель: определить, как именно будет разрабатываться определенная функциональность для того, чтобы достичь цели спринта. Для каждого элемента Sprint Backlog определяется список задач и оценивается их продолжительность. Артефакт: в Sprint Backlog появляются задачи Если в ходе спринта выясняется, что команда не может успеть сделать запланированное на спринт, то Скрам Мастер, Владелец Продукта и команда встречаются и выясняют, как можно сократить scope работ и при этом достичь цели спринта. Остановка спринта (по неожиданным причинам). Остановка спринта производится в исключительных ситуациях. Спринт может быть остановлен до того, как закончатся отведенные 30 дней. Спринт может остановить команда, если понимает, что не может достичь цели спринта в отведенное время. Спринт может остановить владелец продукта, если необходимость в достижении цели спринта исчезла. После остановки спринта проводится митинг с командой, где обсуждаются причины остановки спринта. После этого начинается новый спринт: производится его планирование и стартуются работы. Ежедневный митинг Scrum. Этот митинг проходит каждое утро в начале дня. Он предназначен для того, чтобы все члены команды знали, кто и чем занимается в проекте. Длительность этого митинга строго ограничена и не должна превышать 15 минут. Цель митинга — поделиться информацией. Он не предназначен для решения проблем в проекте. Все требующие специального обсуждения вопросы должны быть вынесены за пределы митинга. Скрам митинг проводит Скрам Мастер. Он по кругу задает вопросы каждому члену команды: • Что сделано вчера? • Что будет сделано сегодня? • С какими проблемами столкнулся? Скрам Мастер собирает все открытые для обсуждения вопросы в виде Action Items, например, в формате что/кто/когда, например: • Обсудить проблему с отрисовкой контрола. • Члены команды.. • Сразу после скрама. |