- •Надежность, свойства надежности.
- •Показатели надежности компьютерных систем.
- •Показатели надежности невосстанавливаемых объектов.
- •Показатели надежности восстанавливаемых объектов.
- •Эффективность компьютерных систем.
- •Требования к программному продукту и их свойства.
- •Надежность программного обеспечения. Особенности по по сравнению с аппаратурой.
- •Основные причины появления ошибок в по.
- •Основные процессы жизненного цикла разработки по.
- •Вспомогательные процессы жизненного цикла разработки по.
- •Модели надежности по.
- •Сложность по.
- •Модель Джелинского-Моранды, Шика-Волвертона.
- •Геометрическая модель.
- •Статистическая модель Миллса.
- •Модель Нельсона.
- •Способы обеспечения надежности по.
- •Основные стандарты оценки качества.
- •Гост 28195-99.
- •Внутренние метрики надежности по.
- •Тестирование методами «черного, белого и серого ящиков».
- •Процесс разработки тестовых случаев. Свойства тестовых случаев.
- •Эквивалентирование и анализ граничных значений.
- •Ошибка. Свойства ошибки.
- •Правила составления отчетов об ошибках.
- •Жизненный цикл ошибки. Системы документирования ошибок.
- •Приемочный тест, критерии его непрохождения. Критическое и углубленное тестирование.
- •Использование контрольных перечней в углубленном тестировании.
- •Специфика тестирования веб-приложений.
- •Тестирование инсталляции по.
- •Тестирование безопасности по.
- •Виды уязвимостей по.
- •Тестирование производительности по
- •Тестирование usability по.
- •Автоматизация модульного тестирования.
- •Достоинства и недостатки автоматизированного тестирования.
- •Необоснованные ожидания от автоматизированного тестирования.
- •Требования, предъявляемые к автоматизированным тестам.
- •Метод «Play&Record» в автоматизированном тестировании.
- •Метод «Data-driven» в автоматизированном тестировании.
- •Метод «Keyword-driven» в автоматизированном тестировании.
- •Возможности Selenium ide.
- •Возможности Selenium rc
- •Возможности системы TestComplete.
- •Процессы, окна, элементы управления в TestComplete.
- •Проекты и элементы TestComplete.
- •Скрипты в TestComplete.
Внутренние метрики надежности по.
Метрика – метод измерения и шкала измерения некоторого свойства программного средства.
Внутренние метрики – метрики, измеряющие соответствие свойства программных средств. Они изменяются в процентах разработки на основе спецификаций требований, резервов проектирования, исходного кода или другой документации. Внутрении метрики дают возможность оценить качество промежуточного программного продукта, предсказывающая качество конечного продукта.
Тестирование методами «черного, белого и серого ящиков».
Тестирование (по Майерсу) процесс исполнения программы с целью обнаружения ошибок
(ГОСТ ИСО 12919 – 2000) – порядок проверки ПОна соответствие его требованиям качеству.
Тестирование может:
1. Обнаружить ошибки 2. Показать соответствие функций программы ее назначению, Т.Р. проверка правильности работы функциональным требованиям
3. Отображает надежность как индикатор качества программы
Тестирование не может: Показать отсутствие ошибок
Тест (тестовый случай, testcase) – алгоритм проверки некоторого функционала программы.
Тест состоит из двух частей: что надо сделать и с чем сравнивать
К разработке тестов существует несколько походов
По методу черного ящика:
Методы, которые рассматривает ПО как черный ящик, называются функциональными методами, а тестирование – функциональным.
По принципу белого ящика: Тестирование белого ящика используется для тестирования структуры ПО и ее логики
По принципу серого ящика: Принцип серого заключается во всех средствах функционального автоматизированного тестирования.
Процесс разработки тестовых случаев. Свойства тестовых случаев.
После появления первой версии требований тестировщики приступают к разработке тестовых случаев. Руководители разрабатывают тестовый план. Тестовый план – документ, согласно которому будут проводиться все действия по тестированию. В нем описывается перечень тестируемых компонент, нетестируемых компонент, ресурсы (человеческие и аппаратные), график тестирования, стратегия и виды тестирования, риски тестирования. Риски – ситуации, которые могут сорвать график тестирования.
Для разработки тестовых случаев необходима следующая документация:
- требования;
- тестовый план;
- пожелания заказчика;
- график выхода версий ПО;
- непроектная документация.
Тестовые случаи оформляются в виде таблицы:
№ | № треб | назв функционала | посл-ть действий | Ожид-й рез-т | тест пройден?
| | | | |
При проектировании тестов необходимо учитывать верную, стандартную программу и нестандартную. Верная последовательность – критическое тестирование; неверная – углубленный тест, расширенный (extend test). Приемочный тест (smoke test) –быстрая проверка основного функционала новой версии программы.
Свойства тестовых случаев:
1) Каждый тестовый случай должен иметь четко поставленную цель.
2) Для каждого теста должна быть определена среда тестирования.Благодаря этому можно рассчитывать что при каждом прогоне этот тест будет выдавать один т тот же результат.
3) Каждый тестовый случай должен давать строго определенный рез-тат(для однозначности трактовки прохождения теста)
4) Тестовый случай должен проверять минимальный функционал(чем мельче тесты, тем удобнее пользоваться)
5) Тестовые случаи долны организовываться в иерархию(тестовые сценарии).
6) Послед-сть тестов в иерархии должна быть удобной для использования, что позволит в каждый конкретный момент времени работать с одним уровнем системы.
7) Начинать с админа.
8) Тестовый случай должен обладать высокой вероятностью обнаружения ошибки.Для этого тестеры должны стать на позицию конструктивного разрушения.Нельзя делать предположения. Тестовый случай д.б. воспоизводимым. Тестовый случай не д.б. избыточным.