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

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

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

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

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

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

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

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

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

Фон [ править ]

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

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

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

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

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

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

Разработка через тестирование
Дизайн для тестируемости (аналогично дизайну для тестирования в области оборудования)

Иерархия тестируемости [ править ]

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

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

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

Тестируемость требований [ править ]

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

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

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

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

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

См. Также [ править ]

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

Ссылки [ править ]

^ Шеллоуэй, Алан; Тротт, Джим (2004). Объяснение шаблонов дизайна, 2-е изд . п. 133 . ISBN 978-0321247148.
^ ^a ^b Родригес, Исмаэль; Ллана, Луис; Рабанал, Пабло (2014). «Общая теория тестируемости: классы, свойства, сложность и сокращение тестирования» . IEEE Transactions по разработке программного обеспечения . 40 (9): 862–894. DOI : 10.1109 / TSE.2014.2331690 . ISSN 0098-5589 .
^ a b Родригес, Исмаэль (2009). «Общая теория проверяемости». CONCUR 2009 - Теория параллелизма, 20-я Международная конференция, CONCUR 2009, Болонья, Италия, 1–4 сентября 2009 г. Материалы . С. 572–586. DOI : 10.1007 / 978-3-642-04081-8_38 . ISBN 978-3-642-04080-1.

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

[DesignPatternsExplained2ndEd-1] Шеллоуэй, Алан; Тротт, Джим (2004). Объяснение шаблонов дизайна, 2-е изд . п. 133 . ISBN 978-0321247148.

[RodriguezLlanaRabanal-2] Родригес, Исмаэль; Ллана, Луис; Рабанал, Пабло (2014). «Общая теория тестируемости: классы, свойства, сложность и сокращение тестирования» . IEEE Transactions по разработке программного обеспечения . 40 (9): 862–894. DOI : 10.1109 / TSE.2014.2331690 . ISSN 0098-5589 .

[Rodriguez-3] Родригес, Исмаэль (2009). «Общая теория проверяемости». CONCUR 2009 - Теория параллелизма, 20-я Международная конференция, CONCUR 2009, Болонья, Италия, 1–4 сентября 2009 г. Материалы . С. 572–586. DOI : 10.1007 / 978-3-642-04081-8_38 . ISBN 978-3-642-04080-1.

[1]