Содержание
- 2. Тестирование (software testing) – деятельность, выполняемая для оценки и улучшения качества программного обеспечения. Эта деятельность, в
- 3. Термин подразумевает тестирование всегда предполагает выполнение тестируемой программы с заданными входными данными. При этом, величины, задаваемые
- 4. Для простых программ теоретически возможно столь большое количество тестовых сценариев, что исчерпывающее тестирование может занять многие
- 5. Многие предлагаемые техники тестирования отличаются друг от друга в том, как выбираются сценарии тестирования. Инженеры по
- 6. Хотя это не всегда легко, все же необходимо решить, какое наблюдаемое поведение программы будет приемлемо, а
- 7. статические (без выполнения кода) динамические (с выполнением кода) *Качество программного обеспечения” (Software Quality)
- 9. Основные понятия в области тестирования, базовые термины, ключевые проблемы и их связь другими областями деятельности и
- 10. IEEE Standard 610-90 (Standard Glossary of Software Engineering Terminology) 1.1 Терминология тестирования (Testing-Related Terminology)
- 11. Существующие термины: недостатки (faults), дефекты (defects), сбои (failures), ошибки (errors) SWEBOK: причина нарушения работы (недостаток или
- 12. Критерии отбора тестов могут использоваться как для создания набора тестов, так и для проверки, насколько выбранные
- 13. Тестирование – это наблюдение за выполнением программы, запущенной в целях тестирования с заданными параметрами, по заданному
- 14. Случай тестирования подразумевает успешность процедуры тестирования, если дефект найден. Это отличается от подхода в тестировании, когда
- 15. “Оракул” - любой агент (человек или программа), оценивающий поведение программы, формулируя вердикт - тест пройден (“pass”)
- 16. Теория тестирования выступает против необоснованного уровня доверия к серии успешно пройденных тестов. К сожалению, большинство установленных
- 17. Проблема автоматизированного тестирования связана с тем, что путь, по которому выполняются потоки работ тестируемой программной системы,
- 18. Степень легкости описания критериев покрытия тестами для заданной программной системы Возможность вероятность, возможность статистического измерения того,
- 19. Управление качеством Конструирование 1.3 Связь тестирования с другой деятельностью (Relationships of testing with other activities)
- 20. Уровень тестирования определяет “над чем” производятся тесты: над отдельным модулем, группой модулей или системой, в целом.
- 21. Позволяет проверить функционирование отдельно взятого элемента системы. Модуль системы определяется контекстом. IEEE 1008-87 “Standard for Software
- 22. Уровень тестирования является процессом проверки взаимодействия между программными компонентами/модулями (стратегии в классике: “сверху-вниз”, “снизу-вверх”) 2.1.2 Интеграционное
- 23. безопасность, производительность, точность, надежность тестируются интерфейсы к внешним приложениям, аппаратному обеспечению, операционной среде 2.1.3 Системное тестирование
- 24. Тестовые сценарии могут разрабатываться для проверки функциональных требований (функциональные тесты), для оценки нефункциональных требований Существуют такие
- 25. Проверяет поведение системы на предмет удовлетворения требований заказчика. Это возможно в том случае, если заказчик берет
- 26. Данные тесты проводятся с целью проверки процедуры инсталляции системы в целевом окружении. 2.2.2 Установочное тестирование (Installation
- 27. альфа (внутреннее пробное использование) бета (пробное использование с привлечением отобранных внешних пользователей) Отчеты об ошибках, поступающие
- 28. Проверка соответствия системы, предъявляемым к ней требованиям, описанным на уровне спецификации поведенческих характеристик 2.2.4 Функциональные тесты/тесты
- 29. Помогая идентифицировать причины сбоев, тестирование подразумевает и повышение надежности программных систем. Случайно генерируемые сценарии тестирования могут
- 30. Определение успешности регрессионных тестов (IEEE 610-90 “Standard Glossary of Software Engineering Terminology”) : “повторное выборочное тестирование
- 31. Специализированные тесты проверки удовлетворения специфических требований, предъявляемых к параметрам производительности. Особый подвид тестов, когда делается попытка
- 32. Тестированием производительности с целью достижения ее реальных (достижимых) возможностей производительности и выполнением программной системы c повышением
- 33. Единичный набор тестов, позволяющих сравнить две версии системы. 2.2.9 Сравнительное тестирование (Back-to-back testing)
- 34. Цель – проверка возможностей рестарта системы в случае непредусмотренной катастрофы (disaster), влияющей на функционирование операционной среды,
- 35. Если программное обеспечение создается для использования различными пользователями (в терминах “ролей”), данный вид тестирования направлен на
- 36. Цель – проверить, насколько легко конечный пользователь системы может ее освоить, включая не только функциональную составляющую
- 37. это не столько техника тестирования, сколько стиль организации процесса разработки, жизненного цикла, когда тесты являются неотъемлемой
- 38. FDD – Feature-Driven Development (разработка на основе функциональных возможностей). TDD может естественно рассматриваться как составная часть
- 39. 3.1 Техники, базирующиеся на интуиции и опыте инженера (Based on the software engineer’s intuition and experience)
- 40. Тесты основываются на опыте, интуиции и знаниях инженера, рассматривающего проблему с точки зрения имевшихся ранее аналогий.
- 41. Одновременное обучение, проектирование теста и его исполнение. Заранее не определяется в плане тестирования и такие тесты
- 42. Рассматриваемая область приложения разделяется на коллекцию наборов или эквивалентных классов, которые считаются эквивалентными с точки зрения
- 43. Тесты строятся с ориентацией на использование тех величин, которые определяют предельные характеристики тестируемой системы. Расширением этой
- 44. Таблицы представляют логические связи между условиями (могут рассматриваться в качестве “входов”) и действиями (могут рассматриваться как
- 45. Комбинация тестов для всех состояний и переходов между состояниями, представленных в соответствующей модели (переходов и состояний
- 46. Для спецификации, определенных с использованием формального языка, возможно автоматически создавать и тесты для функциональных требований. Могут
- 47. Тесты генерируются случайным образом по списку заданного набора специфицированных характеристик. 3.2.6 Случайное тестирование (Random testing)
- 48. Набор тестов строится исходя из покрытия всех условий и решений блок-схемы. В какой-то степени напоминает тесты
- 49. Отслеживается полный жизненный цикл величин (переменных) – с момента рождения (определения), на всем протяжении использования, вплоть
- 50. Является не столько техникой тестирования, сколько контролем структуры программы, представленной в виде дерева вызовов (например, sequence-диаграммы,
- 51. На уровне названия таких техник тестирования, они, действительно, ориентированы на ошибки. Точнее – на специфические категории
- 52. Направлены на обнаружение наиболее вероятных ошибок, предсказываемых, например, в результате анализа рисков. 3.4.1 Предположение ошибок (Error
- 53. Мутация – небольшое изменение тестируемой программы, произошедшее за счет частных синтаксических изменений кода (в частности, рефакторинга).
- 54. Базируется на условиях использования системы. Тестирование для оценки надёжности системы должно проводиться в таком тестовом окружении,
- 55. Базируется на условиях разработки системы. Соответствующие тесты (обозначаемые также аббревиатурой SRET от Software Reliability Engineered Testing)
- 56. Объектно-ориентированное тестирование Компонентно-ориентированное тестирование Web-ориентированное тестирование Тестирование на соответствие протоколам Тестирование систем реального времени 3.6 Техники,
- 57. Техники тестирования, строящиеся на основе спецификаций или кода часто называют функциональными или структурными, соответственно. Оба подхода
- 58. Тесты можно распределить по данным группам на основе используемой политики выбора или определения входных параметров тестов.
- 59. Измерения являются инструментом анализа качества. Измерение результатов тестирования касается оценки качества получаемого продукта – программной системы.
- 60. Измерения могут базироваться на размере программ (например, в терминах количества строк кода или функциональных точек) или
- 61. Эффективность тестирования может быть достигнута в случае, понимания типов дефектов найденных в процессе тестирования программной системы
- 62. классифицирует возможные программные “аномалии”. Стандарт IEEE 1044-93
- 63. Тестируемая программа может оцениваться на основе подсчета и классификации найденных дефектов. Для каждого класса дефектов можно
- 64. Статистические ожидания в отношении надежности программной системы (см. выше 2.2.5 “Достижение и оценка надежности ”) могут
- 65. Модели обеспечивают возможности прогнозирования надежности системы, базируясь на обнаруженных сбоях (2.2.5). Модели такого рода разбиваются на
- 66. Критерии “адекватности” тестирования, в ряде случаев, требуют систематического выполнения тестов для определенных набора элементов программы, задаваемых
- 67. Подход помогает классифицировать возможные ошибки и следующие за ними сбои, применяя в дальнейшем полученные результаты для
- 68. Получаемое в процессе тестирования мутаций (3.4.2) отношение “убитых” к общему числу сгенерированных мутантов помогает измерить эффективность
- 69. Возможные варианты интерпретации этого понятия – число тестов (данной техники), необходимых для обнаружения первого дефекта; отношение
- 70. Концепции, стратегии, техники и измерения тестирования должны быть объединены в единый процесс тестирования как деятельности по
- 71. Совместное стремление участников проекта обеспечить необходимое качество продукта. Менеджеры играют ключевую роль в организации этой деятельности
- 72. Работы по тестированию могут руководствоваться различными соображениями и критериями – от управления рисками до специфицированных сценариев
- 73. Работы по тестированию должны быть организованы в единый (однозначно интерпретируемый) процесс, на основе учета 4 элементов
- 74. IEEE 829-98 “Standard for Software Test Documentation”: План тестирования Спецификация процедуры тестирования Спецификация тестов Лог тестов
- 75. Формализация процесса тестирования может включать и организационную формализацию команд(ы) тестирования члены проектной команды, разрабатывающие код, внешние
- 76. Ряд метрик, связанных с оценкой ресурсов, необходимых для тестирования, как и оценка эффективности тестирования на разных
- 77. Тщательные измерения, такие как достигнутое покрытие кода тестами или охват функциональности, безусловно, очень полезны. Однако, сами
- 78. Доведение тестов до конца и обеспечение сопровождения программной системы необходимо каждый фрагмент системы тестировать систематическим образом,
- 79. Успешное управление тестовыми работами зависит от процессов конфигурационного управления (Software Configuration Management) 5.2 Тестовые работы (Test
- 80. координацию персонала управление оборудованием и другими средствами, необходимыми для организации тестирования планирование обработки нежелательных результатов (т.е.
- 81. Создание тестовых сценариев основывается на уровне и конкретных техниках тестирования. Тесты должны находиться под управлением системы
- 82. Используемое для тестирования окружение должно быть совместимо с инструментами программной инженерии (будут рассматриваться позднее как тема
- 83. должны фиксироваться все работы и результаты процесса тестирования форма журналирования таких работ и их результатов должна
- 84. Для определения успешности тестов их результаты должны оцениваться, анализироваться. В большинстве случаев, “успешность” тестирования подразумевает, что
- 85. В процессе тестовой деятельности ведётся журнал тестирования, фиксирующий информацию о соответствующих работах: когда проводится тест, какой
- 87. Скачать презентацию