Операционные системы. Задание. Техническое задание явля ется первым разделом курсовой работы. 1
 Скачать 0.67 Mb.
|
|
IF в Fortran IF ( Выражение) N 1 , N 2 , N 3 Критерий п. 1 подразумевает, что IF должен быть выпол- нен, в то время как п. 2 подразумевает различные наборы дан- ных, для того чтобы выполнились условия N 1 , N 2 , N 3 (т.е. пере- дачу на эти метки). В общем случае не существует единого программного кри- терия, определяющего «хорошо проверенную» программу. Тесно связаны с тестированием понятия «верификация» и «испытание». Испытание системы осуществляется посредством тестиро- вания. Цель такой проверки — показать, что система функцио- нирует в соответствии с разработанными на нее спецификация- ми. 53 Верификация заключается в выполнении доказательств, что программа удовлетворяет своим спецификациям. Современный процесс разработки программ не позволяет реализовать обе указанные концепции. Для ситуаций, не кон- тролируемых тестовыми данными, система, прошедшая испыта- ния, может дать неверные результаты. После проведения вери- фикации система работает правильно лишь относительно пер- воначальных спецификаций и допущений о поведении окру- жающей среды; формальные доказательства правильности про- грамм весьма сложны и слабо разработаны. Общий процесс создания правильных программ с помощью процедур испытания и верификации называется аттестацией. Различаются три вида отклонения системы от нормальной работы. Сбой системы — это явление, связанное с нарушением сис- темой установленных на нее спецификаций. Данные, при обработке которых правильными алгоритмами системы происходит сбой, называются выбросом. Исправление выброса можно предусмотреть в программе, так что не каждый выброс может приводить к сбою. Ошибка — это алгоритмический дефект, который создает выброс (программная ошибка). Различают понятия «правильная» и «надежная» программа. Правильная программа — это та, что удовлетворяет своим спе- цификациям. Что касается надежной программы, то она не обя- зательно является правильной, но выдает приемлемый результат даже в том случае, когда входные данные либо условия ее использования не удовлетворяют принятым допущениям. Есте- ственно стремление иметь «живую» (robustness) систему, т.е. систему, способную воспринимать широкий спектр входных данных при неблагоприятных условиях. Система является правильной, если в ней нет ошибок, а ее внутренние данные не содержат выбросов. Система называется надежной, если, несмотря на сбои, она продолжает удовлетво- рительно функционировать. Это особо видно на примере опера- ционной системы (ОС), включающей систему обработки сбоев. При обнаружении выброса такая система прекращает работу с 54 сохранением текущей информации и возможности продолжения работы после устранения выброса. 4.2 Организация испытаний программных изделий Под испытаниями понимают не отладку, призванную опре- делить, почему в программе возникает та или иная ошибка и устранить ее причины, а процесс установления самого факта наличия дефектов и расхождения между истинными свойствами программного изделия и его спецификациями. Нельзя сказать, что испытания программного изделия гарантируют обеспечение его качества. Обеспечение качества программного изделия включает помимо испытаний еще целый ряд других процедур (анализ эксплуатационных характеристик, использование «стан- дартных» методов проектирования и программирования, вос- станавливаемость после отказа, простота сопровождения, по- вторяемость результатов и др.) Однако испытания — важнейшая из этих процедур. Группа испытаний оказывает значительное влияние на ка- чественную сторону проектирования, используя такие воздейст- вия, как технические ревизионные комиссии, соглашения о тре- бованиях, спецификации и обзоры состояния проекта в различ- ных фазах. Однако группа испытаний не может нести ответст- венность за качество изделия, так как она не управляет процес- сом создания отдельных компонентов программного обеспече- ния. В задачи группы испытаний входит: − проведение испытаний; − выработка оценок; − участие в фазовых обзорах с целью влияния на ход раз- работок. 4.3 Виды испытаний программного изделия . Стадии испытаний В общем случае, испытания проводятся в несколько стадий, разделенных по времени. 55 К первой стадии относятся испытания класса A, которые проводятся в конце фазы программирования, после того как бу- дут отлажены и включены в систему все модули изделия. Этот процесс сопровождается системной отладкой, когда исправля- ются ошибки сопряжения модулей. Ко второй стадии относятся испытания класса B, когда осуществляется независимая (от группы разработки) проверка компонентов законченного изделия как отдельно, так и во взаи- модействии друг с другом. В идеальном случае испытания клас- са B начинаются после того, как разработчики объявляют, что изделие готово к передаче потребителю. В ходе испытаний класса B функционирование проверяется на соответствие требо- ваниям, спецификациям, документации и цели. Испытания класса C осуществляются после того, как группа испытаний рекомендует выпуск изделия и его распространение. Испытания класса C похожи на выборочный контроль в произ- водстве, поскольку с полки случайным образом выбирают эк- земпляр программного изделия и выполняют прогон программ, бегло анализируя результаты. Пример. Поскольку написание программы завершено, для проверки правильности работы программы выбран класс B (тес- тирование после разработки). Испытания класса A (тестирова- ние в процессе разработки) отвергаются, а класс C (предпро- дажное тестирование) не может быть выбран потому, что тести- руемая программа является учебной и не предназначена для продажи. 4.4 Режимы испытаний программ Испытания различаются в зависимости от того, кто их про- водит. Основная идея — независимость функции испытаний от функции разработки. Режим I испытаний подразумевает полный цикл деятельно- сти группы испытаний, включая планирование испытаний, разра- ботку тестов, их прогон и анализ результатов. Обычно эта проце- дура является высшей и наиболее строгой формой контроля и ис- пользуется для проверки универсальных программных изделий. 56 Режим II позволяет проводить ускоренные испытания из- делия, поскольку в этом случае группа испытаний несет ответ- ственность только за анализ результатов испытаний, а составле- ние плана и спецификаций испытаний, построение тестов и их прогон поручаются разработчикам. Режим III реализуется без участия группы испытаний. Этот режим используется лишь в случаях крайней необходимости, например при сильном нарушении сроков проектирования опытного образца, когда независимые испытания изделия или, по крайней мере, независимый контроль над испытаниями ис- ключаются. Для гарантии успеха в этом неблагоприятном слу- чае следует предусмотреть ввод в действие и поддержку такого изделия группой разработки. При этом качество программного изделия весьма сомнительно. Пример. Тестирование будет выполняться в режиме II (вы- полняется разработчиком, а выводы делает независимая группа), так как режим I (тестирование в отдельной организации) недос- тупен, режим III (тесты и выводы делает разработчик) также отвергается. 4.5 Категории испытания программного изделия Стадии испытания указывают на время проведения проверок, а режимы определяют тех, кто проводит. Категории испытаний устанавливают характер и назначение тестов. Продуманное деле- ние испытаний изделий на категории облегчает общение между различными функциональными группами и степень их участия в работе. На практике выделяют следующие категории испытаний. Демонстрация в действии. Во время демонстрации прого- няют специально подобранные тесты, обеспечивающие желае- мый результат. Тесты обычно подбираются и выполняются в рамках функции разработки во время испытаний класса A, что- бы убедить руководителей всех заинтересованных функцио- нальных групп в том, что изделие достигло определенного уровня завершенности. Аттестация. Аттестация призвана гарантировать способ- ность данного программного изделия правильно обрабатывать 57 реальные входные данные в условиях пользователя и давать верные результаты. Испытания этой категории проводятся для того, чтобы удовлетворить требования рынка сбыта и Заказчика, также для того, чтобы продемонстрировать совместимость или эксплуатационные качества изделия. Спецификация испытаний готовится группой поддержки, а аттестация проводится группой разработки по окончании испытаний класса A. Полная функциональная проверка. Цель этой категории испытаний — показать, что изделие обладает всеми функцио- нальными возможностями, указанными во внешних специфика- циях, и работает правильно. Если объектом испытания является новая версия существующего изделия, проверке подвергаются как новые, так и старые функциональные возможности изделия, отдельно и во взаимодействии друг с другом. Испытания этой категории включаются в состав испытаний классов A и B. Проверка новых свойств. Этим испытаниям подвергаются только новые версии существующих программных систем в це- лях оценки их новых функциональных качеств. Проверка новых свойств обычно проводится в рамках испытаний классов A и B и выполняется в тех случаях, когда изделие подвергается лишь незначительным изменениям. Эксплуатационные испытания. В результате этой про- верки оцениваются эксплуатационные характеристики про- граммного изделия, такие, как скорость выполнения операций, объем занимаемой памяти, пропускная способность, скорость пересылки данных, время транслирования, компоновки или ге- нерации, время реакции и условия взаимодействия с пользова- телем. Эксплуатационные свойства оцениваются в ходе испыта- ний классов A и B. Испытания надежности. Во время этих испытаний изде- лие ставится в условия, позволяющие оценить его способность к устойчивой работе или восстановлению после отказа. Обычно в ходе этих испытаний преднамеренно вносятся искусственно созданные ошибки, испытывают изделие в условиях непрерыв- ной работы в течение нескольких часов и проверяют все восста- новительные процедуры. Испытания надежности входят в со- став испытаний классов A и B. 58 Проверка устойчивости. Эти испытания призваны гаран- тировать правильность объединения программных изделий в систему. Они должны убедить всех в том, что взаимодействие различных программных средств не создает ошибочных ситуа- ций. В отношении отдельных изделий фиксируется среднее время между отказами. Проверка проводится в рамках испыта- ний классов A и B. Возвратная проверка. В эту категорию испытаний входит проверка новой версии или редакции изделия, подтверждающая, что ранее замеченные дефекты исправлены и исправления не привели к появлению новых ошибок. Возвратная проверка вхо- дит в состав испытаний классов A и B. Пусковые испытания. Эти испытания подтверждают, что ввод программного изделия в действие может быть осуществлен в полном соответствии с описанием, т.е. в отведенное для этого время, силами персонала, обученного соответствующим образом, с помощью технической документации и с помощью только тех средств, которые были предусмотрены в описании. Испытания проводятся на различных конфигурациях технических средств ЭВМ и обычно входят в состав испытаний классов A и B. Конфигурационные испытания. Эти испытания призваны гарантировать, что изделие правильно функционирует на всех конфигурациях вычислительной техники, которые были преду- смотрены проектом. В процессе этих испытаний создаются ми- нимальные базовые конфигурации и имитируются максималь- ные. Конфигурационные испытания выполняются в рамках ис- пытаний классов A и B. Стадии, режимы и категории испытаний наглядно можно представить в табличной форме по аналогии с таблицей из раз- дела 2.6.3.1 СТ. 4.6 Технология тестирования , классы эквивалентности Одним из способов изучения поставленного вопроса явля- ется исследование стратегии тестирования, называемой страте- гией черного ящика, тестированием с управлением по данным 59 или тестированием с управлением по входу-выходу. При ис- пользовании этой стратегии программа рассматривается как черный ящик. Иными словами, такое тестирование имеет целью выяснение обстоятельств, в которых поведение программы не соответствует ее спецификации. При таком подходе обнаруже- ние всех ошибок в программе является критерием исчерпываю- щего входного тестирования. Последнее может быть достигну- то, если в качестве тестовых наборов использовать все возмож- ные наборы входных данных. Стратегия белого ящика, или стратегия тестирования, управляемого логикой программы, позволяет исследовать внут- реннюю структуру программы. В этом случае тестирующий по- лучает тестовые данные путем анализа логики программы (к сожалению, здесь часто не используется спецификация про- граммы). Тестирование в данной курсовой работе должно выпол- няться по технологии черного ящика с использованием методо- логии эквивалентного разбиения. Разработка тестов методом эквивалентного разбиения осуществляется в два этапа: 1) выделение классов эквивалентности; 2) построение тестов. Классы эквивалентности выделяются путем выбора каждо- го входного условия (обычно это предложение или фраза в спе- цификации) и разбиением его на две или более группы. Для про- ведения этой операции используют таблицу, подобную табл. 4.1. Таблица 4.1 — Форма таблицы для перечисления классов эквивалентности Классы эквивалентности Входные условия Правильные Неправильные Отметим, что различают два типа классов эквивалентности: правильные классы эквивалентности, представляющие правиль- ные входные данные программы, и неправильные классы экви- валентности, представляющие все другие возможные состояния условий (т.е. ошибочные входные значения). Таким образом, 60 придерживаются одного из принципов необходимости сосредо- точивать внимание на неправильных или неожиданных условиях. Если задаться входными или внешними условиями, то вы- деление классов эквивалентности представляет собой в значи- тельной степени эвристический процесс. При этом существует ряд правил: 1. Если входное условие описывает область значений (на- пример, «целое данное может принимать значения от 1 до 999»), то определяются один правильный класс эквивалентности зна- чений (от 1 до 999) и два неправильных (значения целого данно- го, меньшие 1, и значения целого данного, большие 999). 2. Если входное условие описывает число значений (напри- мер, «в автомобиле могут ехать от одного до шести человек»), то определяются один правильный класс эквивалентности и два неправильных (ни одного и более шести). 3. Если входное условие описывает множество входных значений и есть основание полагать, что каждое значение про- грамма трактует особо (например, «известны способы передви- жения на АВТОБУСЕ, ГРУЗОВИКЕ, ТАКСИ, ПЕШКОМ или на МОТОЦИКЛЕ»), то определяется правильный класс эквива- лентности для каждого значения и один неправильный класс эквивалентности (например, «НА ПРИЦЕПЕ»). 4. Если входное условие описывает ситуацию «должно быть» (например, «первым символом идентификатора должна быть буква»), то определяется один правильный класс эквива- лентности (первый символ — буква) и один неправильный (пер- вый символ — не буква). 5. Если есть любое основание считать, что различные эле- менты класса эквивалентности трактуются программой неоди- наково, то данный класс эквивалентности разбивается на мень- шие классы эквивалентности. 4.7 Построение тестов Процесс построения тестов включает в себя: 1) назначение каждому классу эквивалентности уникально- го номера; 61 2) проектирование новых тестов, каждый из которых по- крывает как можно большее число непокрытых правильных классов эквивалентности до тех пор, пока все правильные клас- сы эквивалентности не будут покрыты тестами (только не об- щими); 3) запись тестов, каждый из которых покрывает один и только один из непокрытых неправильных классов эквивалент- ности до тех пор, пока все неправильные классы эквивалентно- сти не будут покрыты тестами. Причина покрытия неправильных классов эквивалентности индивидуальными тестами состоит в том, что определенные проверки с ошибочными входами скрывают или заменяют дру- гие проверки с ошибочными входами. Например, спецификация устанавливает «тип книги при поиске (ВЫЧИСЛИТЕЛЬНАЯ ТЕХНИКА, ПРОГРАММИРОВАНИЕ или ОБЩИЙ) и количе- ство (1—9999)». Тогда тест XYZ 0 отображает два ошибочных условия (неправильный тип книги и количество) и, вероятно, не будет осуществлять проверку коли- чества, так как программа может ответить «XYZ — НЕСУЩЕСТВУЮЩИЙ ТИП КНИГИ» и не проверять осталь- ную часть входных данных. Пример. Предположим, что при разработке компилятора для подмножества языка Фортран требуется протестировать синтаксическую проверку оператора DIMENSION. Специфика- ция приведена ниже. В спецификации элементы, написанные латинскими буквами, обозначают синтаксические единицы, ко- торые в реальных операторах должны быть заменены соответст- вующими значениями, в квадратные скобки заключены необяза- тельные элементы, многоточие показывает, что предшествую- щий ему элемент может быть повторен подряд несколько раз. Оператор DIMENSION используется для определения мас- сивов. Форма оператора DIMENSION: DIMENSION ad [, ad] … , где ad есть описатель массива в форме n(d[,d] … ), 62 где n — символическое имя массива, а d — индекс массива. Символические имена могут содержать от одного до шести сим- волов — букв или цифр, причем первой должна быть буква. До- пускается от одного до семи индексов. Форма индекса [lb:]ub, где lb и ub задают нижнюю и верхнюю границы индекса масси- ва. Граница может быть либо константой, принимающей значе- ния от –65534 до 65535, либо целой переменной (без индексов). Если lb не определена, то предполагается, что она равна едини- це. Значение ub должно быть больше или равно lb. Если lb опре- делена, то она может иметь отрицательное, нулевое или поло- жительное значение. Как и все операторы, оператор DIMENSION может быть продолжен на нескольких строках. (Конец спецификации). Первый шаг заключается в том, чтобы идентифицировать входные условия и по ним определить классы эквивалентности (табл. 4.2). Классы эквивалентности в таблице обозначены чис- лами. Таблица 4.2 — Классы эквивалентности Классы эквивалентности Входные условия Правильные Неправильные Число описателей массивов один (1), больше одного (2) ни одного (3) Длина имени массива 1—6 (4) 0 (5), больше 6 (6) Имя массива содержит буквы (7) и цифры (8) содержит другие символы (9) Имя массива начинается с буквы да (10) нет (11) Число индексов 1—7 (12) 0 (13), больше 7 (14) Верхняя граница константа (15), целая переменная (16) имя элемента мас- сива (17), что-то иное (18) Имя целой переменной содержит буквы (19) и цифры (20) состоит из других символов (21) Целая переменная начинается с буквы да (22) нет (23) 63 Классы эквивалентности Входные условия Правильные Неправильные Константа –65534..65535 (24) < –65534 (25), > 65535 (26) Нижняя граница определена да (27), нет (28) Верхняя граница по отношению к нижней границе больше (29), равна (30) меньше (31) Значение нижней границы < 0 (32), 0 (33), > 0 (34) Нижняя граница константа (35), целая переменная (36) имя элемента мас- сива (37), что-то иное (38) Оператор расположен на не- скольких строках да (39), нет (40) Следующий шаг — построение теста, покрывающего один или более правильных классов эквивалентности. Например, тест DIMENSION A(2) покрывает классы 1, 4, 7, 10, 12, 15, 24, 28, 29 и 40. Далее опре- деляются один или более тестов, покрывающих оставшиеся правильные классы эквивалентности. Так, тест DIMENSION A 12345 (I, 9, J4XXXX, 65535, 1 , KLM, * 100), BBB (–65534 : 100,0 : 1000,10 : 10,1: 65535) покрывает оставшиеся классы. Перечислим неправильные классы эквивалентности и соответствующие им тесты: (3) DIMENSION (5) DIMENSION (10) (6) DIMENSION A234567(2) (9) DIMENSION A.I(2) (11) DIMENSION 1A(10) (13) DIMENSION В (14) DIMENSION В (4,4,4,4,4,4,4,4) (17) DIMENSION B(4,A(2)) (18) DIMENSION B(4 „ 7) (21) DIMENSION C(I.,10) (23) DIMENSION C(10,1J) (25) DIMENSION D(–65535:1) Окончание табл. 4.2 64 (26) DIMENSION D(65536) (31) DIMENSION D(4:3) (37) DIMENSION D(A(2):4) (38) DIMENSION D(.:4) Эти классы эквивалентности покрываются 18 тестами. Хотя эквивалентное разбиение значительно лучше случайного выбора тестов, оно все же имеет недостатки (т.е. пропускает определен- ные типы высокоэффективных тестов). Следующие два метода — анализ граничных значений и использование функциональных диаграмм (диаграмм причинно-следственных связей cause-effect graphing) — свободны от многих недостатков, присущих экви- валентному разбиению. Результаты тестирования приводятся в заключении поясни- тельной записки к курсовому проекту, также даются рекоменда- ции по устранению ошибок, выявленных в результате тестиро- вания. |