Методические рекомендации по выполнению практических работ профессионального модуля
 Скачать 2.97 Mb.
|
|
Список идей тестов. Внутренний рабочий документ группы тестирования, содер- жащий идеи по проверке не функциональных требований к системе, а также идеи о том Что и/или Как стоит еще проверить. Результаты тестирования. Документ, содержащий суммарную информацию о про- хождении тестов. Используется для анализа и сравнения с ожидаемыми результатами, позволяет провести детальную оценку качества тестируемого продукта и текущего статуса процесса тести- рования. Рекомендуется записывать и сохранять результаты тестирования для каждого этапа. Дефекты. Описание обнаруженных фактов несоответствия системы предъявляе- мым требованиям. Рекомендуется использовать специализированное инструментальное средство, которое позволяет передавать информацию об обнаруженных дефектах от тести- ровщиков к разработчикам, а в обратную сторону — сведения об устранении дефектов. А также формировать и отчеты о тенденциях изменения количества обнаруживаемых и устра- няемых дефектов. 47 Для грамотной организации тестирования имеет смысл использовать подходящие технологии, таких технологий существует целое множество, но в этом множестве можно вы- делить две основные группы: статическое и динамическое тестирование. Статическое тестирование — процесс, которые обычно ассоциируют с анализом про- граммного обеспечения, используется для верификации практически любого артефакта раз- работки: программного кода компонент, требований, системных спецификаций, функциональных спецификаций, документов проектирования и архитектуры программных систем и их компонентов. Статическое тестирование — единственный способ тестирования без запуска программного кода приложения. Динамическое тестирование — процесс тестирования, производимый над работающей системой или подсистемой, не может быть осуществлено без запуска программного кода приложения. Этапы динамического тестирования: запуск системы или подсистемы; вызов необходимых функциональных элементов или модулей; сравнение через графический интерфейс пользователя реального поведения системы с ожидаемым. Любая технология предполагает наличие набора методов, в тестировании обычно вы- деляют два самых распространенных метода: метод «черного ящика» и метод «белого ящика». Метод «черного ящика» (англ. Black-box testing), предполагает доступ к программно- му обеспечению только через те интерфейсы, которые доступны (или будут доступны) поль- зователю. Как правило, тестирование черного ящика ведется с использованием спецификаций или иных документов, описывающих требования к системе. Метод «белого ящика» (англ. White-box testing), предполагает доступ к исходному ко- ду программ. Разработчик тестов может писать код, который связан с библиотеками тести- руемого ПО. Это типично для юнит-тестирования (англ. unit testing), при котором тестируются только отдельные части системы. В некоторых случаях используется метод «серого ящика» (англ. Gray-box testing), представляющий собой нечто среднее между методами белого и черного ящиков. Разработ- чик тестов имеет доступ к исходному коду, но при непосредственном выполнении тестов доступ к коду, как правило, не требуется. Процесс тестирования должен когда-то закончиться, но при выборе момента оконча- ния тестирования необходимо руководствоваться некоторыми критериями. В теории тести- рования выделяется такое понятие как критерии покрытия, которые позволяют определить степень покрытия разрабатываемого продукта тестами. При тестировании функциональных требований можно выделить два типа покрытия: покрытие, основанное на спецификации, и покрытие, основанное на коде. Рассмотрим эти два типа подробнее. Покрытие, основанное на спецификации или требованиях (Specification-Based or Requirements-based Test Coverage). Этот критерий оценивает степень покрытия, принимая во внимание требования заказчика или системные спецификации. Основой может быть, напри- мер, таблица требований, use case модель и диаграмма состояний-переходов. Набор тестов должен покрывать все функциональные требования, иногда необходимо проверить только некоторый набор требований, в этом случае набор тестов должен покрывать именно эти функциональные требования. Данный критерий показывает в процентном отношении коли- чество покрытых тестами требований. Чаще всего используется при тестировании методом «черного ящика». Покрытие, основанное на коде (Code-Based Coverage). Этот критерий относится к потоку управления и потоку данных программы. Можно выделить следующие критерии по- крытия кода: Покрытие строк (Line Coverage) — мера измерения покрытия кода, указывающая про- центное отношение строк программы, затронутых тестами, к общему числу строк. Это очень не- точная метрика, так как даже стопроцентное покрытие по ней пропускает много ошибок. 48 Покрытие ветвей (Branch Coverage) — мера измерения покрытия кода, указываю- щая процентное отношение ветвей потока управления, затронутых тестами, в общем числе таких ветвей. Эта метрика надежней предыдущей, но и в ней стопроцентное покрытие не га- рантирует отсутствие ошибок. Покрытие путей (Path Coverage) — мера измерения, характеризующая процент всевозможных путей (и/или комбинаций ветвей), которые покрываются тестами. Однако, даже не смотря на стопроцентное покрытие (достичь которого практически нереально в коммерческих системах) все еще могут присутствовать скрытые ошибки. Метрики и критерии определяются в процессе разработки стратегии тестирования на- ряду с остальными составляющими процесса. Рассмотрим классификацию тестирования. Дело в том, что тесты существенно разли- чаются по задачам, которые с их помощью решаются и по используемой технике. По различ- ным категориям можно выделить несколько классификаций тестирования, рассмотрим наиболее значимые из них. Классификация по объектам (элементам) тестирования. Часто разделение на виды тестов по данному критерию называют разделением тестирования на уровни. Модульное тестирование (автономное или Unit-тестирование). На данном уровне тестируются по отдельности небольшие разработанные компоненты системы, максимально отделенные от других компонентов, но при этом пригодные для тестирования. Обычно про- водится сразу после разработки компонента, направлено на оценку соответствия его функ- циональности спроектированной архитектуре компонентов системы (Component Design). Комплексное тестирование (сборочное тестирование, Integration testing). На данном уровне тестируются объединенные элементы (компоненты или подсистемы) общей системы, направлено на проверку взаимодействия компонентов в соответствии с архитектурой системы (System Design). Тесты данного уровня обычно проверяют все интерфейсы взаимодействия меж- ду компонентами, определенные в системной архитектуре, до тех пор, пока все компоненты не будут разработаны, отлажены и проинтегрированы друг с другом в единую систему. Системное тестирование (System testing). На данном уровне тестируется разраба- тываемая система целиком, проверяется соответствие системным спецификациям (System specification), а также реализация всех функциональных и нефункциональных требований к разрабатываемой системе. Приемочное тестирование (приемо-сдаточное тестирование, Acceptance testing). На данном уровне производится тестирование завершенной системы заказчиком, конечным пользователем или соответствующим уполномоченным с целью определения соответствия системы требованиям заказчика и ее готовности к внедрению. На этом уровне оформляется процесс передачи продукта от разработчика заказчику. Операционное тестирование (Release testing). На данном уровне проверяется функ- ционирование системы в среде эксплуатации, оценивается соответствие требованиям пользо- вателя и выполнение роли, определенной в бизнес-модели (Business case или Business model) системы. Необходимо учитывать, что бизнес-модель также может содержать ошибки, поэтому очень важно провести операционное тестирование как финальный шаг валидации. Кроме это- го, тестирование в эксплуатации позволяет выявить и нефункциональные проблемы, такие как конфликт с другими системами, смежными в области бизнеса или в программных и электрон- ных окружениях, недостаточная производительность системы в среде эксплуатации. Рассмотрим основные типы тестирования. Инсталляционное тестирование (Installation testing). Проверяется корректность инсталляции и деинсталляции программного продукта в среде максимально приближенной к эксплуатационной. Позволяет проверить возможность инсталляции/деинсталляции продукта при различных условиях: новая инсталляция, обновление системы (upgrade), инсталляция по умолчанию, полная инсталляция, выборочная инсталляция. Конфигурационное тестирование (Configuration testing). Проверяется работоспо- собность при различных конфигурациях, предполагает тестирование работы системы на раз- 49 личных платформах: различных вариантах аппаратной конфигурации, версиях операционной системы и окружения. Тестирование интернационализации (Internationalization testing). Проверяется возможность быстрой локализации продукта под необходимую локаль потенциальных поль- зователей системы. Дымное тестирование (Smoke testing). Первый прогон программы, проверяется го- товность программы для проведения более обширного тестирования. Чаще всего тестируется основная бизнес-логика программы. Регрессионное тестирование (Regression testing). Повторное тестирование после внесения изменений в программный продукт или его окружение. Предполагается выявление потенциальных проблем, которые могли возникнуть в результате изменений, проверка ис- правления найденных ранее дефектов. Функциональное тестирование (Functional testing). Проверяется соответствие продукта функциональным требованиям и спецификациям. Тестирование графического интерфейса пользователя (User interface testing). Предполагается проверка работы интерфейса в целом и его отдельных компонентов, выпол- няется поиск ошибок функциональности посредством интерфейса. Тестирование удобства использования (Usability testing). Включает в себя тесты на человеческий фактор, эстетику интерфейса и его непротиворечивость, наличие и качество оперативной и контекстной помощи, руководств пользователя и учебных материалов. Тестирование производительности (Performance testing). Проверяется скорость работы системы (время отклика, частота транзакций) в имитационной и реальной средах, с целью установить реальную производительность программного продукта. Задания для самостоятельной работы Выполнить поставленные задачи. Программный продукт для тестирования выбирает- ся самостоятельно обучающимся. При этом один из них должен представлять установочный программный продукт, а другой web-интерфейс. Список рекомендуемой литературы 1. Базовые вопросы о тестировании. — Режим доступа: http://bugscatcher.net/ archives/2118. — Дата обращения: 20.06.2017. 2. Грегери Д. Гибкое тестирование. Практическое руководство для тестировщиков ПО и гибких команд. — М.: Вильямс, 2010. — 464 с. 3. Котляров В.П. Основы тестирования программного обеспечения. — М.: Интернет- Университет информационных технологий, Бином. Лаборатория знаний, 2006. — 200 с. 4. Липаев В.В. Тестирование компонентов и комплексов программ. Учебник. — М.: СИНТЕГ, 2010. — 400 с. 5. Функциональное тестирование. — Режим доступа: http://parallels.nsu.ru/docs/ Andrey_Polyanskiy-Lectures_about_QA.doc. — Дата обращения: 20.06.2017. 50 Практическая работа №18–20 Темы: Разработка плана по обеспечению надежности системы. Работы по обеспече- нию отказоустойчивости системы. Описание методов обеспечения надежности на различных этапах жизненного цикла ИС Задачи: 1. Определить понятия «надежности информационной системы», «отказоустойчи- вость информационной системы». 2. Выделить и дать краткую характеристику методов обеспечения надежности. 3. Применить один из методов обеспечения надежности на практическом примере. Теоретическое обоснование Качество информационной системы — это совокупность свойств системы, обу- словливающих возможность ее использования для удовлетворения определенных в соответ- ствии с ее назначением потребностей. Количественные характеристики этих свойств определяются показателями, которые необходимо контролировать и учитывать. Основными показателями качества информационных систем являются надежность, достоверность, безо- пасность, эффективность. Надежность — свойство системы сохранять во времени в установленных пределах значения всех параметров, характеризующих способность выполнять требуемые функции в заданных режимах и условиях применения. Надежность — важнейшая характеристика качества любой системы, поэтому разрабо- тана специальная теория — теория надежности. Теория надежности может быть определена как научная дисциплина, изучающая за- кономерности, которых следует придерживаться при разработке и эксплуатации систем для обеспечения оптимального уровня их надежности с минимальными затратами ресурсов. Надежность — комплексное свойство системы; оно включает в себя более простые свойства, такие как безотказность, ремонтопригодность, долговечность и т д. Безотказность — свойство системы сохранять работоспособное состояние в течение некоторого времени или наработки (наработка - продолжительность или объем работы сис- темы). Ремонтопригодность — свойство системы, заключающееся в приспособленности к предупреждению и обнаружению причин возникновения отказов, повреждений и поддержа- нию и восстановлению работоспособного состояния путем проведения технического обслу- живания и ремонтов. Долговечность — свойство системы сохранять при установленной системе техниче- ского обслуживания и ремонта работоспособное состояние до наступления предельного со- стояния, то есть такого момента, когда дальнейшее использование системы по назначению недопустимо или нецелесообразно. Показатель надежности — это количественная характеристика одного или несколь- ких свойств, определяющих надежность системы. В основе большинства показателей надеж- ности лежат оценки наработки системы, то есть продолжительности или объема работы, выполненной системой. Показатель надежности, относящийся к одному из свойств надежно- сти, называется единичным. Комплексный показатель надежности характеризует несколько свойств, определяющих надежность системы. На сегодняшний день разработано много конкретных практических способов повы- шения надежности информационных систем. Для обеспечения надежности технических средств чаще всего выполняется: 1) резервирование (дублирование) технических средств (компьютеров и их компонен- тов, сегментов сетей и т. д.); 51 2) использование стандартных протоколов работы устройств ИС; 3) применение специализированных технических средств защиты информации. Для обеспечения надежности функционирования программного комплекса ИС вы- полняется: 1) тщательное тестирование программ, опытное исполнение программы с целью обнару- жения в ней ошибок (обязательное условие эффективного тестирования — по крайней мере один раз выполнить все разветвления программы в каждом из возможных направлений); 2) использование стандартных протоколов, интерфейсов, библиотек процедур, лицен- зионных программных продуктов; 3) использование структурных методов для обеспечения надежной работы программ- ных комплексов (иерархическое построение программ, разбиение программ на сравнительно независимые модули и т.д.); 4) изоляция параллельно работающих процессов, в результате чего ошибки в работе одной программы не влияют на работу операционной системы и других программ. Надежность информационных систем не самоцель, а средство обеспечения своевре- менной и достоверной информации на ее выходе. Поэтому показатель достоверности функ- ционирования имеет для информационных систем главенствующее значение. Состояния объекта Исправность — состояние объекта, при котором он соответствует всем требова- ниям, установленным нормативно-технической документацией (НТД). Неисправность — состояние объекта, при котором он не соответствует хотя бы одному из требований, установленных НТД. Работоспособность — состояние объекта, при котором он способен выполнять за- данные функции, сохраняя значения основных параметров в пределах, установленных НТД. Неработоспособность — состояние объекта, при котором значение хотя бы одно- го заданного параметра, характеризующего способность выполнять заданные функции, не соответствует требованиям, установленным НТД. Переход объекта в различные состояния Повреждение — событие, заключающееся в нарушении исправности объекта при со- хранении его работоспособности. Отказ — событие, заключающееся в нарушении работоспособности объекта. Критерий отказа — отличительный признак или совокупность признаков, согласно которым устанавлива- ется факт отказа. Признаки (критерии) отказов устанавливаются НТД на данный объект. Восстановление — процесс обнаружения и устранения отказа (повреждения) с целью восстановления его работоспособности (исправности). Восстанавливаемый объект — объект, работоспособность которого в случае возникновения отказа подлежит восстановлению в рас- сматриваемых условиях. Невосстанавливаемый объект — объект, работоспособность которого в случае возникновения отказа не подлежит восстановлению в рассматриваемых условиях. Временные характеристики объекта Наработка — продолжительность или объём работы объекта. Объект может работать непрерывно или с перерывами. Во втором случае учитывается суммарная наработка. Нара- ботка может измеряться в единицах времени, циклах, единицах выработки и других едини- цах. В процессе эксплуатации различают суточную, месячную наработку, наработку до первого отказа, наработку между отказами, заданную наработку и т.д. Если объект эксплуатируется в различных режимах нагрузки, то, например, наработка в облегчённом режиме может быть выделена и учитываться отдельно от наработки при но- минальной нагрузке. Технический ресурс — наработка объекта от начала его эксплуатации до достижения предельного состояния. Обычно указывается, какой именно технический ресурс имеется в 52 виду: до среднего, капитального, от капитального до ближайшего среднего и т.п. Если кон- кретного указания не содержится, то имеется в виду ресурс от начала эксплуатации до дос- тижения предельного состояния после всех (средних и капитальных) ремонтов, т.е. до списания по техническому состоянию. Срок службы — календарная продолжительность эксплуатации объекта от её начала или возобновления после капитального или среднего ремонта до наступления предельного состояния. Эксплуатация объекта — это стадия его существования в распоряжении потребителя при условии применения объекта по назначению, что может чередоваться с хранением, транспортированием, техническим обслуживанием и ремонтом, если это осуществляется по- требителем. Срок сохраняемости — календарная продолжительность хранения и (или) транспор- тирования объекта в заданных условиях, в течение и после которой сохраняются значения установленных показателей (в том числе и показателей надёжности) в заданных пределах. Показатели надежности: 1. Вероятность безотказной работы — вероятность того, что в пределах заданной на- работки (времени или объема работы) не возникнет отказ. 2. Средняя наработка до отказа (Mean Time To Failure) — мат. ожидание наработки объекта до первого отказа. 3. Средняя наработка на отказ (Mean Time Between Failures) – отношение суммарной наработки к мат. ожиданию числа отказов в течении этой наработки. 4. Интенсивность отказов — плотность вероятности возникновения отказов. 5. Коэффициент готовности — вероятность того, что объект окажется в работоспо- собном состоянии в произвольный момент времени. 6. Средний срок службы. 7. Вероятность восстановления. Разработка ПС достигла такого уровня развития, что стало необходимо использовать инженерные методы, в том числе для оценивания результатов проектирования на этапах ЖЦ, контроля достижения показателей качества и метрического их анализа, оценки риска и сте- пени использования готовых компонентов для снижения стоимости разработки нового про- екта. Основу инженерных методов в программировании составляет повышение качества, для достижения которого сформировались методы определения требований к качеству, подходы к выбору и усовершенствованию моделей метрического анализа показателей качества, мето- ды количественного измерения показателей качества на этапах ЖЦ. Главная составляющая качества — надежность, которой уделяется большое внима- ние в области надежности технических средств и тех критических систем (реального време- ни, радарные системы, системы безопасности и др.), для которых надежность — главная целевая функция оценки их реализации. Как следствие, в проблематике надежности разрабо- тано более сотни математических моделей надежности, являющихся функциями от ошибок, оставшихся в ПС, от интенсивности отказов или частоты появления дефектов в ПС. На их основе производится оценка надежности программной системы. Качество ПО — предмет стандартизации. Стандарт ГОСТ 2844-94 дает определение качества ПО как совокупность свойств (показателей качества) ПО, которые обеспечивают его способность удовлетворять потребности заказчика в соответствии с назначением. Этот стандарт регламентирует базовую модель качества и показатели, главным среди них — на- дежность. Стандарт ISO/IEC 12207 определил не только основные процессы ЖЦ разработки ПС, но и организационные и дополнительные процессы, которые регламентируют инжене- рию, планирования и управления качеством ПС. Согласно стандарту на этапах ЖЦ должен проводиться контроль качества ПО: проверка соответствия требований проектируемому продукту и критериев их достижения; верификация и аттестация (валидация) промежуточных результатов ПО на этапах ЖЦ и измерение степени удовлетворения достигаемых отдельных показателей; 53 тестирование готовой ПС, сбор данных об отказах, дефектах и других ошибках, об- наруженных в системе; подбор моделей надежности для оценивания надежности по полученным результа- там тестирования (дефекты, отказы и др.); оценка показателей качества, заданных в требованиях на разработку ПС. Далее излагаются модели качества и надежности, а также способы их применения. Качество ПО — это относительное понятие, которое имеет смысл только при учете реальных условий его применения, поэтому требования, предъявляемые к качеству, ставятся в соответствии с условиями и конкретной областью их применения. Оно характеризуется тремя аспектами: качество программного продукта, качество процессов ЖЦ и качество со- провождения или внедрения (рис. 18.1). Рис. 18.1 |