terminy_testa

Термины, на которые следует особо обратить внимание при подготовке к тесту

1. аварийный тест

2. аккредитация

3. архитектура ПС

4. архитектурный подход к разработке программ

5. валидация

6. верификация

7. взвешенные методы на класс WMC

8. виды документации на программное средство

9. виды метрик и шкал для измерения показателей качества

10. внешнее описание ПС

11. восходящая разработка структуры программ

12. восходящее тестирование

13. вырожденный тест

14. высота дерева наследования DIT

15. государственный метрологический контроль

16. детерминированное тестирование !!

17. добровольная сертификация

18. единство измерений

19. жизненный цикл программного средства

20. задачи модульного тестирования

21. законодательная метрология

22. измерение

23. интеграционное тестирование

24. информационная сложность

25. калибровка

26. каскадная модель ЖЦ

27. качество ПС

28. класс точности

29. количество детей NOC

30. коллектив параллельно действующих программ

31. комплекс автономно выполняемых программ

32. конструктивный подход к разработке программ

33. контроль внешнего описания (статический просмотр, пользовательский контроль)

34. корректность

35. критерии качества ПС

36. лицензирование

37. метод измерения

38. метрологическая служба

39. метрологическое обеспечение

40. метрология

41. минимальность вычислений

42. модели надежности

43. надежность

44. недостаток связности в методах LСOM

45. нисходящая разработка структуры программ

46. нисходящее тестирование

47. нормативные документам по обеспечению единства измерений

48. объект метрологии

49. обязательная сертификация

50. основной тест

51. особенности работы с вещественными типами данных

52. отклик для класса RFC

53. оценивание

54. оценка затрат на тестирование (в значении что дороже, что дешевле. Без формул)

55. планирование тестирования

56. полная корректность программы

57. порядковая шкала измерений

58. правильность измерений

59. предмет метрологии

60. предсказание

61. прикладная метрология

62. программное средство

63. программный модуль

64. профиль стандартов жизненного цикла программного средства

65. проход участков

66. процесс обеспечения качества ПС

67. процессы ЖЦ

68. прочность модуля

69. разработка определения требований к ПС (управляемая пользователем, контролируемая пользователем и независимая от пользователя)

70. рутинность модуля

71. ручная проверка

72. связанность модуля

73. секционированная абстракция

74. секция данных

75. сертификация

76. сертификация систем качества

77. сильно склеенные лексемы

78. синтез программ

79. система качества

80. системное тестирование

81. сквозной контроль

82. склеенные лексемы

83. случайные ошибки

84. смежный контроль

85. спецификация программного модуля

86. спиральная модель ЖЦ

87. способы получения эталонных значений теста

88. средства метрологии

89. средство измерений

90. стандартизация

91. статический контроль

92. статическое тестирование

93. стохастическое

94. сцепление между классами объектов СВО

95. сцепление модуля

96. теоретическая метрология

97. тест граничных значений

98. тестирование

99. тестирование "белого ящика"

100. тестирование "черного ящика"

101. тестирование интеграций

102. тестирование нетривиальных классов программ

103. тестирование правильности

104. тестирование элементов

105. технология разработки программных средств

106. точности проверки

107. функциональная корректность модулей

108. цельная программа

109. цикломатическая сложность

110. частичная корректность программы

111. эволюционная модель ЖЦ

112. экономический эффект внедрения ПС

113. эталон единицы величины

114. этапы методов тестирования класса

В тести будут задания дать определение или выбрать вариант ответа.

Расчетные задачи (взять калькулятор)

Анализ программного кода

Желаю удачи!!!!

1-b 2-a 4-ac 5-a 7-c 8-a 9-b 10-b 11-a 12-c 13-b 14-a 15-b 16-a 17-b 18-b 19-c

1. Аварийный тест. Тест проверяет реакцию программы на возникновение разного рода аварийных ситуаций в программе, в частности вызванных неправильными исходными данными, то есть проверяется диагностика, выдаваемая программой, а также окончание ее работы или, может быть, попытка исправления неверных исходных данных (разработчики реальных программ знают, что пользователи подобны шаловливому ребенку, играющему в отсутствие старших с телевизором или магнитофоном).

2. Аккредитация — в общем случае это процесс, в результате которого приобретается официальное подтверждение соответствия качества предоставляемых услуг некоему стандарту.

3. Архитектура ПС - это его строение как оно видно (или должно быть видно) из-вне его, т.е. представление ПС как системы, состоящей из некоторой совокупности взаимодействующих подсистем. В качестве таких подсистем выступают обычно отдельные программы. Разработка архитектуры является первым этапом борьбы со сложностью ПС, на котором реализуется принцип выделения относительно независимых компонент.

Основные задачи разработки архитектуры ПС:

• Выделение программных подсистем и отображение на них внешних функций (заданных во внешнем описании) ПС;

• определение способов взаимодействия между выделенными программными подсистемами.

С учетом принимаемых на этом этапе решений производится дальнейшая конкретизация и функциональных спецификаций.

4. Архитектурный подход к разработке программы представляет собой модификацию восходящей разработки, при которой модульная структура программы формируется в процессе программирования модуля. Но при этом ставится существенно другая цель разработки: повышение уровня используемого языка программирования, а не разработка конкретной программы. Это означает, что для заданной предметной области выделяются типичные функции, каждая из которых может использоваться при решении разных задач в этой области, и специфицируются, а затем и программируются отдельные программные модули, выполняющие эти функции. Так как процесс выделения таких функций связан с накоплением и обобщением опыта решения задач в заданной предметной области, то обычно сначала выделяются и реализуются отдельными модулями более простые функции, а затем постепенно появляются модули, использующие ранее выделенные функции. Такой набор модулей создается в расчете на то, что при разработке той или иной программы заданной предметной области в рамках конструктивного подхода могут оказаться приемлемыми некоторые из этих модулей. Это позволяет существенно сократить трудозатраты на разработку конкретной программы путем подключения к ней заранее заготовленных и проверенных на практике модульных структур нижнего уровня. Так как такие структуры могут многократно использоваться в разных конкретных программах, то архитектурный подход может рассматриваться как путь борьбы с дублированием в программировании. В связи с этим программные модули, создаваемые в рамках архитектурного подхода, обычно параметризуются для того, чтобы усилить применимость таких модулей путем настройки их на параметры.

5. Валидация. Ключевым моментом в валидации является сверка выставленных требований с необходимыми для достижения определённой (поставленной) цели требованиями. Если же эта цель и есть конечное требование, то возникает циклическая проблема (планирование плана или проблема инициализации). Сверка требований может происходить на их полноту и/или точность.

Валидация: Подтверждение на основе представления объективных свидетельств того, что требования, предназначенные для конкретного использования или применения, точно и в полном объёме предопределены, а цель достигнута.

6. Верификация – Процесс определения соответствия программного обеспечения предназначению.

7. Взвешенные Методы Класса (WMC) определены как сумма методов класса и предназначены, чтобы посчитать общую сложность методов в данном классе. Такой показатель может использоваться для вычисления количества внутренних методов одного класса и сложности внутренних методов класса.

8. Виды документации на ПО

Существует четыре основных типа документации на ПО:

• архитектурная/проектная — обзор программного обеспечения, включающий описание рабочей среды и принципов, которые должны быть использованы при создании ПО

• техническая — документация на код, алгоритмы, интерфейсы, API

• пользовательская — руководства для конечных пользователей, администраторов системы и другого персонала

• маркетинговая

9. Шкалы. В зависимости от характеристик и особенностей применяемых метрик им ставятся в соответствие различные измерительные шкалы.

• Номинальной шкале соответствуют метрики, классифицирующие программы на типы по признаку наличия или отсутствия некоторой характеристики без учета градаций.

• Порядковой шкале соответствуют метрики, позволяющие ранжировать некоторое характеристики путем сравнения с опорными значениями, т.е. измерение по этой шкале фактически определяет взаимное положение конкретных программ.

• Интервальной шкале соответствуют метрики, которые показывают не только относительное положение программ, но и то, как далеко они отстоят друг от друга.

• Относительной шкале соответствуют метрики, позволяющие не только расположить программы определенным образом и оценить их положение относительно друг друга, но и определить, как далеко оценки отстоят от границы, начиная с которой характеристика может быть измерена.

10. Внешнее описание ПС = спецификация качества ПС + функциональная спецификация ПС

Таким образом, внешнее описание определяет, что должно делать ПС и какими внешними свойствами оно должно обладать.

11. Восходящая разработка структуры программы заключается в том что сначала строится модульная структура программы в виде дерева. Затем поочередно программируются модули программы, начиная с модулей самого нижнего уровня - листьев дерева ее модульной структуры. Программирование проводится в таком порядке, чтобы для каждого программируемого модуля были уже запрограммированы все модули, к которым он может обращаться. После того, как все модули программы запрограммированы, производится их поочередное тестирование и отладка в таком же восходящем порядке, в каком велось их программирование.

12. Восходящее Тестирование. В восходящем тестировании, применяемом обычно для небольших программ, сначала тестируют отдельные периферийные блоки, а затем переходят к тестированию центральной части, которая, разумеется, взаимодействует только с отлаженными уже блоками

13. Вырожденный тест Проверяет внешние функции, например обращение к программе

14. Высота дерева DIT. DIT определяется как максимальная длина пути от листа до корня дерева наследования классов. это длина максимального пути от данного класса до корневого класса в иерархии классов.

15. Государственный метрологический контроль. Государственный метрологический контроль осуществляются только в сферах, установленных Законом. Поэтому разрабатываемые, производимые, поступающие по импорту и находящиеся в эксплуатации средства измерений делятся на две группы:

• предназначенные для применения и применяемые в сферах распространения ГМК и Н. Эти средства измерений признаются годными для применения после их испытаний и утверждения типа и последующих первичной и периодической поверок;

• не предназначенные для применения и не применяемые в сферах распространения ГМК и Н. За этими средствами измерений надзор со стороны государства (Госстандарта России) не проводится

ГМК в сфере обеспечения обороны страны предполагает проведение поверки средств измерений, применяемых при разработке, производстве и испытаниях оружия и военной техники, а также средств измерений военного назначения при их выпуске из производства.

16. Детерминированное тестирование - тестирование программ, при котором контролируется каждая комбинация исходных эталонных данных и соответствующая ей комбинация результатов функционирования программ. Полное детерминированное тестирование практически нереализуемо.

17. Добровольная сертификация применяется для удостоверения качества ИС и/или ПСс целью повышения их конкурентоспособности, расширения сферы использования и получения дополнительных экономических преимуществ. Экономическими целями сертификации могут быть большие тиражи изделий при производстве, большая длительность жизненного цикла с множеством версий, увеличение прибыли разработчиков и поставщиков ИС, сокращение претензий пользователей.

18. Единство измерений - состояние измерений, при котором их результаты выражены в узаконенных единицах величин и погрешности измерений не выходят за установленные границы с заданной вероятностью. Правовой основой обеспечения единства измерений в России является закон РФ от 27.04.1993 N 4871-1 "Об обеспечении единства измерений".

19. Жизненный цикл программного средства - это весь период его разработки и эксплуатации (использования), начиная с момента возникновения его замысла и кончая прекращением всех видов его использования. Жизненный цикл охватывает довольно сложный процесс создания и использования программного средства Этот процесс может быть организован по-разному для разных классов программных средств и в зависимости от особенностей коллектива разработчиков.

20. Задачи и цели модульного тестирования. Каждая сложная программная система состоит из отдельных частей – модулей, выполняющих ту или иную функцию в составе системы. Для того, чтобы удостовериться в корректной работе системы в целом, необходимо вначале протестировать каждый модуль системы в отдельности. В случае возникновения проблем это позволит проще выявить модули, вызвавшие проблему, и устранить соответствующие дефекты в них. Такое тестирование модулей по отдельности получило называние модульного тестирования (unit testing).

Для каждого модуля, подвергаемого тестированию, разрабатывается тестовое окружение, включающее в себя драйвер и заглушки, готовятся тест-требования и тест-планы, описывающие конкретные тестовые примеры.

Основная цель модульного тестирования – удостовериться в соответствии требованиям каждого отдельного модуля системы перед тем, как будет произведена его интеграция в состав системы.

При этом в ходе модульного тестирования решаются четыре основные задачи.

1. Поиск и документирование несоответствий требованиям – это классическая задача тестирования, включающая в себя не только разработку тестового окружения и тестовых примеров, но и выполнение тестов, протоколирование результатов выполнения, составление отчетов о проблемах.

2. Поддержка разработки и рефакторинга низкоуровневой архитектуры системы и межмодульного взаимодействия – эта задача больше свойственна "легким" методологиям типа XP, где применяется принцип тестирования перед разработкой (Test-driven development), при котором основным источником требований для программного модуля является тест, написанный до самого модуля. Однако, даже при классической схеме тестирования модульные тесты могут выявить проблемы в дизайне системы и нелогичные или запутанные механизмы работы с модулем.

3. Поддержка рефакторинга модулей – эта задача связана с поддержкой процесса изменения системы. Достаточно часто в ходе разработки требуется проводить рефакторинг модулей или их групп – оптимизацию или полную переделку программного кода с целью повышения его сопровождаемости, скорости работы или надежности. Модульные тесты при этом являются мощным инструментом для проверки того, что новый вариант программного кода работает в точности так же, как и старый.

4. Поддержка устранения дефектов и отладки

21. Законодательная метрология включает совокупность взаимообусловленных правил и норм, направленных на обеспечение единства измерений, которые возводятся в ранг правовых положений (уполномоченными на то органами государственной власти), имеют обязательную силу и находятся под контролем государства.

22. Измерение ­- совокупность операций по нахождению значения физической величины с помощью специальных технических средств с учетом экспериментального сравнения данной физической величины с однородной физической величиной, значение которой принято за единицу.

23. Интеграционное тестирование - это тестирование архитектуры и низкоуровневых функциональных требований. Его еще называют тестированием архитектуры системы. ИТ включают в себя проверки всех возможных видов взаимодействий между программными модулями и элементами, которые определяются в архитектуре системы, – таким образом, ИТ проверяют полноту взаимодействий в тестируемой реализации системы. С другой стороны, результаты выполнения ИТ – один из основных источников информации для процесса улучшения и уточнения архитектуры системы, межмодульных и межкомпонентных интерфейсов. Т.е. с этой точки зрения интеграционные тесты проверяют корректность взаимодействия компонент системы.

24. Информационная сложность. Для исследования структуры и содержания дидактических единиц, предусмотренных образовательными стандартами, вводится понятие «информационная сложность».

Чтобы найти методы количественного выражения взаимосвязи между всеми понятиями. С этой целью нами вводится понятие «информационная сложность», позволяющее применить количественные методы теории информации для раскрытия сущности сложности.

25. Калибровка - совокупность операций, устанавливающих соотношение между значением величины, полученным с помощью данного средства измерений и соответствующим значением величины, определенным с помощью эталона с целью определения или подтверждения действительных метрологических характеристик этого средства измерений и (или) пригодности к применению средства измерений, не подлежащего государственному метрологическому контролю и надзору. Калибровка средств измерений – совокупность операций, выполняемых калибровочной лабораторией с целью определения и подтверждения действительных значений метрологических характеристик и/или пригодности средства измерений к применению в сферах, не подлежащих государственному метрологическому контролю и надзору в соответствии с установленными требованиями.

26. Каскадная модель жизненного цикла. КЖЦ (иногда называемый водопадным) основан на постепенном увеличении степени детализации описания всей разрабатываемой системы. Каждое повышение степени детализации определяет переход к следующему состоянию разработки

На первом этапе составляется концептуальная структура системы, описываются общие принципы ее построения, правила взаимодействия с окружающим миром, - определяются системные требования.

На втором этапе по системным требованиям составляются требования к программному обеспечению - здесь основное внимание уделяется функциональности программной компоненты, программным интерфейсам.

На третьем этапе на основе требований к программному обеспечению составляется детальная спецификация архитектуры системы - описываются разбиение системы по конкретным модулям, интерфейсы между ними, заголовки отдельных функций и т.п.

На четвертом этапе пишется программный код, соответствующий детальной спецификации, на пятом этапе выполняется тестирование - проверка соответствия программного кода требованиям, определенным на предыдущих этапах.

Особенность каскадного жизненного цикла состоит в том, что переход к следующему этапу происходит только тогда, когда полностью завершены все работы предыдущего этапа. То есть сначала полностью готовятся все требования к системе, затем по ним полностью готовятся все требования к программному обеспечению, полностью разрабатывается архитектура системы и так далее до тестирования.

27. Качество ПС предусматривает наблюдение за процессом разработки ПО с тем, - чтобы гарантировать соблюдение определенных нормативных процедур и стандартов.

28. Класс точности основная метрологическая характеристика прибора, характеризующая допустимые по стандарту значения основных и дополнительных погрешностей, влияющих на точность измерения.

29. Количество детей NOC (Number of children) Подклассы, которые непосредственно подчинены суперклассу, называются его детьми. Значение NOC равно количеству детей, то есть количеству непосредственных наследников класса в иерархии классов.

30. Коллектив параллельно действующих программ представляет собой набор программ, способных взаимодействовать между собой, находясь одновременно в стадии выполнения. Это означает, что такие программы, во-первых, вызваны в оперативную память, активизированы и могут попеременно разделять по времени один или несколько центральных процессоров, а во-вторых, осуществлять между собой динамические (в процессе выполнения) взаимодействия, на базе которых производиться их синхронизация. Обычно взаимодействие между такими процессами производится путем передачи друг другу некоторых сообщений.

31. Комплекс автономно выполняемых программ состоит из набора таких программ, что:

1. любая из них может быть запущена пользователем;

2. при выполнении активизированной программы другие программы не могут быть запущены, пока не закончит выполнение активизированная программа;

3. все программы этого набора применяются к одной и той же информационной среде.

32. Конструктивный подход к разработке программы представляет собой модификацию нисходящей разработки, при которой модульная древовидная структура программы формируется в процессе программирования модуля. Сначала программируется головной модуль, исходя из спецификации программы в целом, причем спецификация программы является одновременно и спецификацией ее головного модуля, так как последний полностью берет на себя ответственность за выполнение функций программы. В процессе программирования головного модуля, в случае, если эта программа достаточно большая, выделяются подзадачи (внутренние функции), в терминах которых программируется головной модуль. Это означает, что для каждой выделяемой подзадачи (функции) создается спецификация реализующего ее фрагмента программы, который в дальнейшем может быть представлен некоторым поддеревом модулей. Важно заметить, что здесь также ответственность за выполнение выделенной функции берет головной (может быть, и единственный) модуль этого поддерева, так что спецификация выделенной функции является одновременно и спецификацией головного модуля этого поддерева.

33. Контроль внешнего описания (статический просмотр, пользовательский контроль):

• статический просмотр предполагает внимательное прочтение текста внешнего описания разработчиком с целью проверка его полноты и непротиворечивости, а также выявления других неточностей и ошибок.

• смежный контроль спецификации качества сверху — это её проверка со стороны разработчика требований к ПС, а смежный контроль функциональной спецификации — это её проверка разработчиками требований к ПС и спецификации качества. Смежный контроль внешнего описания снизу — это его изучение и проверка разработчиками архитектуры ПС и текстов программ, а также разработчиками документации по применению и разработчиками комплекта тестов.

• пользовательский контроль внешнего описания выражает участие пользователя (заказчика) в принятии решений при разработке внешнего описания и его контроле. Если разработка требований к ПС велась под управлением пользователя, то пользовательский контроль внешнего описания, по существу, означает его смежный контроль сверху.

• ручная имитация выражает своеобразный динамический контроль внешнего описания, точнее говоря, функциональной спецификации ПС. Для этого необходимо подготовить исходные данные (тесты) и на основании функциональной спецификации осуществить имитацию поведения (работы) разрабатываемого ПС.

34. Корректность - Степень соответствия исходных программ, формальных видов языков программирования.

35. Критерии качества ПС - Проверки качества, когда программный продукт, сопровождающая документация и процесс разработки анализируются группой проверяющих. Эта группа ответственна за проверку соблюдения стандартов проекта, а также за соответствие документации этим стандартам. Любые отклонения от стандартов регистрируются и подаются на рассмотрение менеджеру проекта.

Автоматизированная оценка ПС, когда программный продукт и его документация проверяются специальной компьютерной программой, которая сопоставляет их с._ стандартами данного проекта. В такую автоматизированную проверку можно включить количественный контроль некоторых характеристик ПС.

36. ЛИЦЕНЗИРОВАНИЕ — мероприятия, связанные с предоставлением лицензий, переоформлением документов, подтверждающих наличие лицензий, приостановлением и возобновлением действия лицензий

37. Метод измерения – это способ экспериментального определения значения физической величины, т. е. совокупность используемых при измерениях физических явлений и средств измерений.

38. Метрологическая служба – совокупность субъектов деятельности и видов работ, направленных на обеспечение единства измерений.