Учебное пособие санктПетербург 2015
 Скачать 3.34 Mb.
|
|
Методы оценки и измерения характеристик информационных систем s и – число операторов, входящее в 1 чел.-час. (для работ такого рода s и : 75- 85 ед./чел.-час.); k к – параметр квалификации служащего (зависит от стажа работы и принимает значение: со стажем до 2-х лет – 0,8; 2-3 года – 1,0; 3-5 лет – 1,1-1,2; 5-7 лет – 1,3- 1,4; более 7 лет – 1,5 -1,6). Значение Т а определяется по формуле: где s a примерно равно 20- 25 ед./чел.-час. Для расчета затрат на разработку ПО на основе блок-схемы используют формулу: где s п принимают равным 20- 25 ед./чел.-час. Необходимый труд на отладку ПО на компьюте- ре рассчитывают по формуле: где s отл = 4 - 5 ед./чел.-час. Для определения затрат труда на написание до- кументации по выполненным работам используют формулу: где Т др – труд на написание рукописных материалов: (s др = 15- 20 ед./чел.-час); Т до – труд на оформление документов: Рассчитанное значение Тпо требуется на пос- леднем шаге нормализовать с использованием уровня языка программирования: 129 Основы метрической теории программ где k кор – коэффициент уровня языка программирова- ния (k кор принимается равным 0,8 - 1,0). 5.6.2 Оценка технического уровня (качества) программного обеспечения Для оценки эффективности программного обес- печения предлагается использовать набор частных по- казателей, представленных в таблице 7: Таблица 7 - Набор частных показателей Показа- тель ка- чества Описание по- казателя Формула для расчета Описание пе- ременных Уровень организа- ционного обеспече- ния а) подготовка пер- вичных данных; б) их использова- ние; в) устойчивость к нарушениям; г) отношение ко- личества оптими- зационных задач к суммарному числу у п зависит от используемой методологии про- ектирования: с использованием автоматизирован- ного проектиро- вания у п = 1,0; на основе типо- вых проектных решений у п = 0,8; с использованием прототипов у п = 0,7; с использованием оригинального проектирования у п = 0,6; d – весовые пара- метры показате- лей уровня; у – оценка дан- ного показателя уровня Уровень техничес- кого обес- печения а) среднее значе- ние загрузки ком- пьютера в сутки; б) связь с перифе- рией; в) используемые средства отобра- жения Уровень матема- тического обеспече- ния а) тип компьюте- ра; б) информацион- ное обеспечение; в) используемая система програм- мирования. 130 Методы оценки и измерения характеристик информационных систем Для совместного использования вышеописанных показателей вводится соотношение с использованием весовых коэффициентов: Для весовых коэффициентов D существует при- нятые значения (таблица 8): Таблица 8 – Принятые значения для весовых коэффициентов D Число работни- ков пред- приятия Тип производства Вид обеспечения Организа- ционное Техничес- кое Матема- тическое D 1 D 2 D 3 До 2000 Индивидуальное Серийное Массовое 0,6 0,5 0,4 0,3 0,3 0,3 0,1 0,2 0,3 2000 – 8000 Индивидуальное Серийное Массовое 0,7 0,5 0,3 0,2 0,2 0,2 0,1 0,3 0,5 Свыше 8000 Индивидуальное Серийное Массовое 0,7 0,4 0,1 0,2 0,2 0,2 0,1 0,4 0,7 Трудности при количественном определении зна- чений показателей были сокращены с использованием балльных оценок. Для оценки технического уровня ПО предлагаются следующие баллы: 131 Основы метрической теории программ 132 Методы оценки и измерения характеристик информационных систем Таким образом, с учетом описанных выше мет- рик можно оценивать в автоматизированном режиме эффективность и качество программного обеспечения на различных этапах его создания. Рассмотренные в данном разделе метрики имеют большое значение как для процесса оценки качества ПО, так и для других направлений информатики. Описанные ги- потезы Холстеда были подтверждены на больших объемах данных и дали мощный толчок для развития идей лингвис- тического подхода в технических науках. Программометри- ка имеет значительное практическое значение, поскольку количественные метрики данного научного направления дают возможность на этапе проектирования оригинального ПО разрабатывать наилучшую структуру, соблюдать сроки разработки ПО, оценивать на ранних этапах трудоемкость, надежность, эффективность ПО, проводить процедуру тех- нико-экономического обоснования. 133 Введение 6. Тестирования программного обеспечения 6.1 Организация тестирования программного обеспечения Процесс тестирования программного обеспе- чения, наряду с процессом разработки, является ос- новным в деятельности любой компании, ведущей деятельность по созданию информационных сис- тем. Именно тестирование позволяет выявить недо- статки, ошибки и несоответствия между требовани- ями к разрабатываемому решению и его физическим воплощением – релизом. Очевидным является факт наличия прямой связи между процессом управле- ния требованиями и процессом тестирования. Свя- зано это с тем, что требования выражают ожидания потенциальных пользователей к конкретным харак- теристикам программной системы, поэтому могут использоваться для определения критериев успеш- ности выполнения тестов. К примеру, если в требо- ваниях к системе сказано, что показатель отклика интерфейса должен быть меньше четверти секунды, то в процессе тестирования это же значение будет являться критерием успешности. Если время откли- ка интерфейса по завершению теста меньше или равно указанному в требовании, значит оно удовлет- ворено, а, следовательно, тестируемое программное решение может иметь атрибут качества, которому присущ рассмотренный показатель. Как уже было сказано, на основе требований формируется реализация системы в виде програм- мных модулей (кода на языке программирования), которые в дальнейшем необходимо протестировать. В данном случае под процессом тестирования следу- 134 Методы оценки и измерения характеристик информационных систем ет понимать комплекс процедур, позволяющий опре- делить некорректное и незапланированное поведение системы и её компонентов. Далее, при успешном вы- полнении всех запланированных тестов, следует про- вести верификацию системы. Верификация позволит определить правильность работы системы и основы- вается на функциональных сценариях. Если система выполняет все возложенные на неё функции верно, значит можно говорить об успешной верификации. Последним этапов в процессе проверки разрабаты- ваемой системы является валидация. Валидация поз- воляет определить, соответствует ли система изна- чальным требованиям потенциальных пользователей (удалось ли реализовать то, что было нужно). Дру- гими словами, позволяет ли система достигать тех результатов, которых от неё ожидают. Рассмотренная схема приведена на рисунке 41. Рисунок 41 – Место тестирования в процессе разработки 135 Введение 6.2 Модель программной ошибки Любое некорректное поведение программной системы можно описать с помощью взаимосвязи трёх понятий: • fault; • error; • failure. Термин fault (неисправность) означает некое про- граммное несоответствие в коде, например, неправиль- ная конкатенация строк, при которой порядок операн- дов ошибочен и финальная строка оказывается не та- кой, какой её ожидают видеть. Термин Error (ошибка) описывает состояние программной системы, при котором проявляется Fault. Следует отметить, что Fault не всегда может привести к ошибочному состоянию системы и в таком случае считается латентной ошибкой (Latent Error). Это свя- зано с тем, что ошибочный модуль может не исполь- зоваться в обычных сценариях работы пользователей, поэтому в большинстве случаев не нарушает процесс функционирования. Примером Error можно считать выполнение операции конкатенации строк и запись результата в переменную. В свою очередь, под термином failure (отказ) понимается отклонение в нормальном, предус- мотренном режиме функционирования, которое приводит к нарушению ожиданий пользователей. Примером может служить неправильный формат телефонного номер, в котором код международной связи находится в конце, а не в начале, как этого требуют правила. Модель программной ошибки показана на ри- сунке 42. 136 Методы оценки и измерения характеристик информационных систем 6.3 Свойства тестов В соответствии с моделью программной ошибки необ- ходимо корректно планировать и разрабатывать тесты. Для того чтобы тест можно было считать правильно составлен- ным, необходимо обеспечение выполнения трёх свойств: • Reachability – тест должен выполнить место в исходном коде, где присутствует программная ошибка; • Corruption – при выполнении ошибки состояние программы должно испортиться с появлением сбоя; • Propagation – сбой должен распространиться дальше и вызвать неудачу в работе программы. Обеспечение этих свойств – одна из самых слож- ных проблем тестирования программного обеспечения, ради решения которой крупные компании выделяют серьёзные финансовые активы. 6.4 Классификация методов тестирования Существует большое количество методов тести- рования. Классификация основных из них приведена ниже: [тестирование .COM] 1. По знанию внутренностей системы: • черный ящик (black box testing); • серый ящик (grey box testing); • белый ящик (white box testing). 2. По объекту тестирования: • функциональное тестирование (functional testing); Рисунок 42 – Модель программной ошибки 137 Тестирования программного обеспечения • тестирование интерфейса пользователя (UI testing); • тестирование локализации (localization testing); • тестирование скорости и надежности (load/ stress/performance testing); • тестирование безопасности (security testing); • тестирование опыта пользователя (usability testing); • тестирование совместимости (compatibility testing). 3. По субъекту тестирования: • альфа-тестировщик (alpha tester); • бета-тестировщик (beta tester). 4. По времени проведения тестирования: • до передачи пользователю — альфа-тестирова- ние (alpha testing); – тест приемки (smoke test, sanity test или confidence test); – тестирование новых функциональностей (new feature testing); – регрессивное тестирование (regression testing); – тест сдачи (acceptance or certification test); • после передачи пользователю — бета-тестиро- вание (beta testing). 5. По критерию “позитивности” сценариев: • позитивное тестирование (positive testing); • негативное тестирование (negative testing). 6. По степени изолированности тестируемых компо- нентов: • компонентное тестирование (component testing); • интеграционное тестирование (integration testing); • системное (или энд-ту-энд) тестирование (system or end-to-end testing). 138 Методы оценки и измерения характеристик информационных систем 7. По степени автоматизированности тестирования: • ручное тестирование (manual testing); • автоматизированное тестирование (automated testing); • смешанное/полуавтоматизированное тестирова- ние (semi automated testing). 8. По степени подготовки к тестированию: • тестирование по документации (formal/ documented testing); • эд хок-тестирование (ad hoc testing). ЧЁРНЫЙ ЯЩИК (black box) Метод, основанный на незнании внутреннего ус- тройства объекта тестирования, называется «чёрным ящиком». Он также может называться поведенческим, так как идеи для проведения тестирования основыва- ются на предполагаемых паттернах (patterns) поведения пользователей. Объектом тестирования для данного ме- тода чаще всего являются системные компоненты пре- образования входных данных в фактический результат работы (код программы, схема базы данных). БЕЛЫЙ ЯЩИК (white box) В отличие от предыдущего метода, тестирование «белого ящика» основывается на знании об устройстве и логике работы тестируемого объекта. Таким образом, сценарии этого метода проектируются с целью тестиро- вания определённого компонента, а не паттерна поведе- ния. Также этот метод называют «стеклянным ящиком», «открытым ящиком» или «никаким ящиком». Объекта- ми тестирования для данного метода чаще всего высту- пают общеизвестные технологические решения, напри- 139 Тестирования программного обеспечения мер, алгоритмы кодирования, шифрования, архивации. Следует сказать, что тестирование базы данных её раз- работчиком выполняется по методу «белого ящика». СЕРЫЙ ЯЩИК (gray/grey box) Это подход, сочетающий элементы двух предыду- щих подходов: • использование паттернов поведения пользовате- лей; • использование знаний об устройстве тестируе- мого объекта. Пожалуй, является одним из самых частых методов, поскольку тестировщики должны обладать специфичес- ким набором знаний в каждой предметной области, что в большинстве случаев невозможно. В результате этого, процесс тестирования основывается на имеющихся зна- ниях и дополняется пользовательскими паттернами. ФУНКЦИОНАЛЬНОЕ ТЕСТИРОВАНИЕ (functional testing) Функциональное тестирование состоит в провер- ке соответствия заявленного функционала системы на работоспособность в указанных условиях и с указанны- ми параметрами. ТЕСТИРОВАНИЕ ИНТЕРФЕЙСА ПОЛЬЗОВАТЕЛЯ (UI (“ю-ай”) testing) Это тестирование, при котором проверяются эле- менты интерфейса пользователя. Проверка происходит исходя из заранее определённых параметров, в том чис- ле цветовое решение, расположение элементов управ- ления, корректность их работы и т.д. 140 Методы оценки и измерения характеристик информационных систем ТЕСТИРОВАНИЕ ЛОКАЛИЗАЦИИ (localization testing) Тестирование локализаций подразумевает про- верку контента и текстов программного средства на корректность перевода на сторонние языки. ТЕСТИРОВАНИЕ СКОРОСТИ И НАДЕЖНОСТИ (load/stress/performance testing) Это проверка поведения системы (или её отде- льных частей) при одновременном подключении и выполнении основных функций системы множеством пользователей. Подобное тестирование является до- вольно длительным и ресурсоёмким, так как требует привлечения аппаратных средств, а также инфраструк- туры для имитации пользователей. ТЕСТИРОВАНИЕ БЕЗОПАСНОСТИ (security testing) Безопасность тестируется в зависимости от типа системы с использованием специальных механизмов и стороннего программного обеспечения. Основным предназначением такого тестирования является обеспе- чение сохранности данных, невозможности поврежде- ния внутренних модулей системы, а также разграниче- ния прав доступа к системе. ТЕСТИРОВАНИЕ ОПЫТА ПОЛЬЗОВАТЕЛЯ (usability testing) Призвано объективно оценить опыт пользо- вателя (user experience), который будет работать с разрабатываемым интерфейсом. При юзабилити- тестировании также проверяется интуитивность интерфейса. Юзабилити-тестирование часто про- 141 Тестирования программного обеспечения водится путем привлечения группы потенциаль- ных пользователей с целью собрать впечатления от работы с системой. ТЕСТИРОВАНИЕ СОВМЕСТИМОСТИ (compatibility testing) Данный тип тестирования предназначен для про- верки работоспособности разрабатываемой системы на определённом типе аппаратного обеспечения с опре- делённым типом программного обеспечения. АЛЬФА-ТЕСТИРОВЩИК (alpha tester) Субъект тестирования, работающий в компании разработчике, который профессионально или непро- фессионально проводит тестирование. Альфа-тести- ровщиком может являться любой сотрудник компании, вне зависимости от его компетенции. БЕТА-ТЕСТИРОВЩИК (beta tester) Субъект тестирования, который не является сотруд- ником компании и которому предоставляется возмож- ность пользоваться новой системой до того, как она станет доступна всем остальным. Основным назначением такого человека является формирование мнения о системе, а так- же критическое формирование замечаний и пожеланий к ней. Иногда бета-тестирование оплачивается. НЕГАТИВНОЕ ТЕСТИРОВАНИЕ (negative testing) Негативное тестирование призвано выявить, раз- работать и выполнить сценарии тестирования, приводя- щие к потенциальной ошибке пользователя (error) или к потенциальному дефекту в системе (failure). 142 Методы оценки и измерения характеристик информационных систем ПОЗИТИВНОЕ ТЕСТИРОВАНИЕ (positive testing) Позитивное тестирование, в отличие от негатив- ного, призвано разработать и проверить сценарии пра- вильного использования системы пользователями. КОМПОНЕНТНОЕ ТЕСТИРОВАНИЕ (component testing) Компонентное тестирование анализирует компо- ненты системы на ошибки функционирования, ошибки разработки архитектуры, интерфейсов и т.д. В большей степени выполняется на начальных этапах тестирова- ния системы и влияет на остальные этапы тестирования, поскольку неработоспособность какого-либо компонен- та не позволяет выполнять тестирования более высокого уровня, в которых задействуется этот компонент. ИНТЕГРАЦИОННОЕ ТЕСТИРОВАНИЕ (integration testing) Интеграционное тестирование выполняется пос- ле компонентного, предназначено для проверки воз- можности взаимодействия нескольких компонентов системы, в рамках общих задач и процессов. |