Анализ причинно-следственных связей
Предоставить в отчете:
Исходники любой программы (например, своей лабораторной по программированию)
Документацию к этой программе (понятно, что документация будет маленькая и корявенькая, но уж как смогут)
В исходниках и документации должны соблюдаться:
- понятность - код отформатирован, переменные нормально поименованы, комментарии где надо, в документации описано как и зачем работает программа
- полнота - должна быть описана и реализована вся функциональность
- краткость - никакого дублирования кода (чтобы в функции все было вынесено), никаких лишних тривиальных комментариев (из разряда - инициализируем переменную нулем)
- безопасность - должны быть предусмотрены все ошибочные ситуации, которые должны отлавливаться и программа не должна падать
В документации также должно быть описано, как они в процессе разработки будут определять уровень качества (например, какие виды тестирования будут проводиться, каково будет покрытие кода тестами, приведен набор тестов).
Тестирование программного обеспечения
По объекту тестирования:
● Функциональное тестирование (functional testing)
это тестирование ПО в целях проверки реализуемости функциональных требований, то есть способности ПО в определённых условиях решать задачи, нужные пользователям. Функциональные требования определяют, что именно делает ПО, какие задачи оно решает.
|
|
|
Функциональные требования включают:
● Функциональная пригодность (англ. suitability).
● Точность (англ. accuracy).
● Способность к взаимодействию (англ. interoperability).
● Соответствие стандартам и правилам (англ. compliance).
● Защищённость (англ. security).
● Тестирование производительности (performance testing)
тестирование, которое проводится с целью определения, как быстро работает система или её часть под определённой нагрузкой. Также может служить для проверки и подтверждения других атрибутов качества системы, таких как масштабируемость, надёжность и потребление ресурсов.
○ Нагрузочное тестирование (load testing)
определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе
○ Стресс-тестирование (stress testing)
оценивает надежность и устойчивость системы в условиях превышения пределов нормального функционирования. Стресс-тестирование особенно необходимо для "критически важного" ПО, однако также используется и для остального ПО. Обычно стресс-тестирование лучше обнаруживает устойчивость, доступность и обработку исключений системой под большой нагрузкой, чем то, что считается корректным поведением в нормальных условиях.
|
|
|
○ Тестирование стабильности (stability / endurance / soak testing)
проверка работоспособности приложения при длительном тестировании со средним (ожидаемым) уровнем нагрузки.
● Юзабилити-тестирование (usability testing)
исследование, выполняемое с целью определения, удобен ли некоторый искусственный объект (такой как веб-страница, пользовательский интерфейс или устройство) для его предполагаемого применения
пользователю предлагают в «лабораторных» условиях решить основные задачи, для выполнения которых этот продукт разрабатывался, и просят высказывать во время выполнения этих тестов свои замечания.
● Тестирование интерфейса пользователя (UI testing)
● Тестирование безопасности (security testing)
оценка уязвимости программного обеспечения к различным атакам.
● Тестирование локализации (localization testing)
● Тестирование совместимости (compatibility testing)
метод, основной целью которого является обеспечение качественной работы конечного продукта с другим программным обеспечением.
По знанию системы:
● Тестирование чёрного ящика (black box)
|
|
|
Методы стратегии чёрного ящика
1.Эквивалентное разбиение.
2.Анализ граничных значений.
3.Анализ причинно-следственных связей.
4.Предположение об ошибке.
Эквивалентное разбиение
Разработка тестов этим методом осуществляется в два этапа: выделение классов эквивалентности и построение теста.
Классы эквивалентности выделяются путём выбора каждого входного условия, которые берутся с помощью технического задания или спецификации и разбиваются на две и более группы.
1.Если входное условие описывает область значений, например «Целое число принимает значение от 0 до 999», то существует один правильный класс эквивалентности и два неправильных.
2.Если входное условие описывает число значений, например «Число строк во входном файле лежит в интервале (1..6)», то также существует один правильный класс и два неправильных.
3.Если входное условие описывает ситуацию «должно быть», например «Первый символ должен быть заглавным», тогда один класс правильный и один неправильный.
4.Если есть основание считать, что элементы внутри одного класса эквивалентности могут программой трактоваться по-разному, необходимо разбить данный класс на подклассы.
|
|
|
Определение тестов:
1.Каждому классу эквивалентности присваивается уникальный номер.
2.Если еще остались не включенные в тесты правильные классы, то пишутся тесты, которые покрывают максимально возможное количество классов.
3.Если остались не включенные в тесты неправильные классы, то пишут тесты, которые покрывают только один класс.
Анализ граничных значений
Граничные условия — это ситуации, возникающие на высших и нижних границах входных классов эквивалентности.
Существует несколько правил:
1.Построить тесты с неправильными входными данными для ситуации незначительного выхода за границы области значений. Если входные значения должны быть в интервале [-1.0 .. +1.0], проверяем −1.000001, 1.000001.
2.Обязательно писать тесты для минимальной и максимальной границы диапазона.
3.Использовать первые два правила для каждого из входных значений (использовать пункт 2 для всех выходных значений).
4.Если вход и выход программы представляет упорядоченное множество, сосредоточить внимание на первом и последнем элементах списка.
Анализ причинно-следственных связей
Этапы построения теста:
1.Спецификация разбивается на рабочие участки.
2.В спецификации определяются множество причин и следствий. Под причиной понимается отдельное входное условие или класс эквивалентности. Следствие представляет собой выходное условие или преобразование системы. Здесь каждой причине и следствию присваивается номер.
3.На основе анализа семантического (смыслового) содержания спецификации строится таблица истинности, в которой последовательно перебираются всевозможные комбинации причин и определяются следствия для каждой комбинации причин.
Предположение об ошибке
Программист с большим опытом выискивает ошибки без всяких методов, но при этом он подсознательно использует метод предположения об ошибке. Данный метод в значительной степени основан на интуиции. Основная идея метода состоит в том, чтобы составить список, который перечисляет возможные ошибки и ситуации, в которых эти ошибки могли проявиться. Потом на основе списка составляются тесты.
● Тестирование белого ящика (white box)
Покрытие
По степени автоматизации:
● Ручное тестирование (manual testing)
● Автоматизированное тестирование (automated testing)
РЕФЕРАТ:
Ме́трика програ́ммного обеспе́чения (англ. software metric) — это мера, позволяющая получить численное значение некоторого свойства программного обеспечения или его спецификаций.
Набор используемых метрик включает:
● количество строк кода,
● количество ошибок на 1000 строк кода,
● степень покрытия кода тестированием,
● покрытие требований,
● количество классов и интерфейсов,
Дата добавления: 2018-04-05; просмотров: 388; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!