WikiDer > Возможность тестирования программного обеспечения

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

Возможность тестирования программного обеспечения - это степень, в которой программный артефакт (т.е. программная система, программный модуль, требования или проектный документ) поддерживает тестирование в заданном контексте тестирования. Если тестируемость программного артефакта высока, то обнаруживать неисправности в системе (если они есть) с помощью тестирования проще.

Формально некоторые системы можно тестировать, а некоторые нет. Эта классификация может быть достигнута, если заметить, что для проверки функциональности тестируемой системы "S", которая принимает вход "I", вычислимый функциональный предикат «V» должно существовать так, чтобы ${displaystyle V (S, I)}$ истинно, когда S, заданный входом I, дает действительный вывод, иначе ложно. Эта функция "V" известна как функция проверки для системы со входом I.

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

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

Корреляцию «тестируемости» с хорошим дизайном можно увидеть, увидев, что код со слабой связностью, сильной связью, избыточностью и отсутствием инкапсуляции трудно тестировать.^[1]

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

Чтобы связать тестируемость с трудностью обнаружения потенциальных ошибок в системе (если они существуют) путем ее тестирования, релевантной мерой для оценки тестируемости является то, сколько тестовых примеров необходимо в каждом случае для формирования полного набора тестов (т. Е. набор тестов, такой, что после применения всех тестовых примеров к системе собранные выходные данные позволят нам однозначно определить, является ли система правильной или нет в соответствии с некоторой спецификацией). Если этот размер небольшой, то тестируемость высока. Исходя из этого показателя, иерархия проверяемости было предложено.^[2][3]

Задний план

Тестируемость, свойство, применяемое к эмпирической гипотезе, включает два компонента. Усилия и эффективность тестирования программного обеспечения зависят от множества факторов, включая:

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

Возможность тестирования программных компонентов

Тестируемость программных компонентов (модулей, классов) определяется такими факторами, как:

• Управляемость: степень, в которой возможно контролировать состояние тестируемого компонента (CUT), как это требуется для тестирования.
• Наблюдаемость: степень, в которой можно наблюдать (промежуточные и окончательные) результаты испытаний.
• Изоляемость: степень, в которой тестируемый компонент (CUT) может быть протестирован изолированно.
• Разделение проблем: Степень, в которой тестируемый компонент несет единственную четко определенную ответственность.
• Понятность: степень документированности или самоочевидности тестируемого компонента.
• Автоматизируемость: степень возможности автоматизации тестирования тестируемого компонента.
• Неоднородность: степень, в которой использование различных технологий требует параллельного использования различных методов и инструментов тестирования.

Тестируемость программных компонентов можно улучшить за счет:

• Разработка через тестирование
• Дизайн для проверки (похожий на дизайн для теста в области оборудования)

Иерархия тестируемости

Основываясь на количестве тестовых примеров, необходимых для создания полного набора тестов в каждом контексте (т. Е. Такого набора тестов, который, если он применяется к тестируемой реализации, то мы собираем достаточно информации, чтобы точно определить, является ли система правильной или неправильной. согласно некоторой спецификации) была предложена иерархия тестируемости со следующими классами тестируемости:^[2][3]

• Класс I: существует конечный полный набор тестов.
• Класс II: любой частичный уровень различения (т.е. любая неполная способность отличать правильные системы от неправильных) может быть достигнут с помощью конечного набора тестов.
• Класс III: существует счетный полный набор тестов.
• Класс IV: существует полный набор тестов.
• Класс V: все случаи.

Доказано, что каждый класс строго входит в следующий. Например, тестирование, когда мы предполагаем, что поведение тестируемой реализации можно обозначить детерминированным конечный автомат для некоторых известных конечных наборов входов и выходов и с некоторым известным числом состояний принадлежит Классу I (и всем последующим классам). Однако, если количество состояний неизвестно, то оно относится только ко всем классам, начиная с Класса II. Если тестируемая реализация должна быть детерминированным конечным автоматом, не удовлетворяющим спецификации для одной трассы (и ее продолжений), и ее количество состояний неизвестно, то она принадлежит только классам, начиная с Класса III. Тестирование темпоральных машин, в которых переходы запускаются, если входы производятся в пределах некоторого реально ограниченного интервала, принадлежит только классам, начиная с класса IV, тогда как тестирование многих недетерминированных систем относится только к классу V (но не всем, а некоторые даже относятся к классу I. ). Включение в класс I не требует простоты предполагаемой модели вычислений, поскольку некоторые примеры тестирования, включающие реализации, написанные на любом языке программирования, и реализации тестирования, определенные как машины, зависящие от непрерывных величин, оказались в классе I. случаи, такие как среда тестирования Мэтью Хеннесси под семантикой must и темпоральные машины с рациональными тайм-аутами относятся к Классу II.

Возможность тестирования требований

Требования должны соответствовать следующим критериям, чтобы их можно было тестировать:

• последовательный
• полный
• однозначный
• количественный (требование типа «быстрое время отклика» не может быть проверка / проверено)
• проверка / проверка на практике (проверка возможна не только в теории, но и на практике с ограниченными ресурсами)

Рассматривая требование как аксиомы, тестируемость можно трактовать через утверждение существования функции. ${displaystyle F_ {S}}$ (программное обеспечение) такое, что ввод ${displaystyle I_ {k}}$ генерирует вывод ${displaystyle O_ {k}}$, следовательно ${displaystyle F_ {S}: I o O}$. Следовательно, идеальное программное обеспечение генерирует кортеж ${displaystyle (I_ {k}, O_ {k})}$ который является набором ввода-вывода ${displaystyle Sigma}$, означает спецификацию.

Теперь сделайте тестовый ввод ${displaystyle I_ {t}}$, который генерирует вывод ${displaystyle O_ {t}}$, это тестовый набор ${displaystyle au = (I_ {t}, O_ {t})}$. Теперь вопрос в том, действительно ли ${displaystyle au in Sigma}$ или ${displaystyle au ot in Sigma}$. Если он есть в наборе, тестовый кортеж ${displaystyle au}$ проходит, иначе система не пройдет тестовый ввод. Следовательно, крайне важно выяснить: можем ли мы создать функцию, которая эффективно транслируется в понятие множества, или нет. индикаторная функция для набора спецификаций ${displaystyle Sigma}$.

По понятию, ${displaystyle 1_ {Sigma}}$ функция тестируемости для спецификации ${displaystyle Sigma}$.Существование должно быть не просто утверждено, оно должно быть строго доказано. Следовательно, очевидно, что без алгебраической непротиворечивости такая функция не может быть найдена, и поэтому спецификацию перестают называть проверяемой.

Смотрите также

• Тестируемость

использованная литература

• Роберт В. Биндер: Тестирование объектно-ориентированных систем: модели, шаблоны и инструменты, ISBN 0-201-80938-9
• Стефан Юнгмайр: Повышение тестируемости объектно-ориентированных систем, ISBN 3-89825-781-9
• Вандерлей Соуза: Абстрактные шаблоны проверяемости, ISSN 1884-0760
• Борис Байзер: [1], Методы тестирования программного обеспечения