Поиск по сайту
Авторизация
Логин:
Пароль:
Забыли свой пароль?

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

Inefficiency and Ineffectiveness of Software Testing:
A Key Problem in Software Engineering
  Cem Kaner, Ph.D., J.D.

Большинство методов тестирования в текущем использовании были разработаны до 1980 года. Тогда значимые программы составляли менее 10 000 заявлений. В коммерческих средах, в которых развилась большая теория тестирования, программы были написаны на языке COBOL, языке, разработанном для понимания непрограммистами. В этих условиях эксперт по предмету может служить в качестве тестировщика, читать программу, идентифицировать все переменные и их наиболее интересные взаимодействия и отслеживать основные пути через программу. Эффективно проведенные вручную испытания, тщательно документированные, были лучшей практикой дня.

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

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

Упрощенные показатели охвата по-прежнему широко распространены. Их можно легко вычислить, но они являются плохими индикаторами. Рассмотрим проблему обеспечения наших границ - предотвращение ввоза бомб, опасных химических или биологических агентов или наркотиков. Даже если бы мы могли обеспечить границу, чтобы каждый вход (суда, автомобили, самолеты, пешеходы) приходил на укомплектованный контрольно-пропускной пункт, сколько мы могли бы искать? Достижение полного охвата заявлений - это вопрос о том, чтобы просить каждого въезжающего автомобиля или человека для идентификации. Вы поймаете некоторые проблемы таким образом, но это не то же самое, что искать корабль. Мы не можем все тщательно изучить, мы не можем полностью проверить все, но мы должны тщательно проверить некоторые вещи. Выбор правильных требует оценки человека и оценки риска.

• В большей степени полагайтесь на методы автоматизации большого объема.

• Переучивайте тестеров программного обеспечения, чтобы помочь им более эффективно сосредоточиться на рисках.

• Практические рекомендации по тестированию тестовой документации для предоставления только тех деталей, которые необходимы для разумной поддержки аудита и тестирования.

Принятие методов автоматизации большого объема

Методы большого объема выполняют тысячи (или миллиарды) тестов без вмешательства человека. Вот четыре примера методов, используемых в промышленности:

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

• При тестировании с произвольной регрессией мы повторно используем тесты, которые программа уже прошла в этой сборке. Выполняйте тесты в случайном порядке, проверяя, продолжает ли программа проходить их с течением времени. Этот стиль тестирования выявляет такие проблемы, как постепенное повреждение памяти и случайные ситуации, которые не отображаются с помощью отдельного теста, который начинается с компьютера в чистом состоянии и процесса тестирования, который очищается после каждого теста. Традиционное тестирование похоже на проверку ваших тормозов при первом запуске вашего автомобиля. RR походит на тестирование их после того, как вы ехали весь день. Ведущий производитель продуктов для автоматизации офиса в значительной степени полагается на это при тестировании прошивки. Они регулярно находят серьезные проблемы, которые трудно поймать традиционными методами, но это может вызвать серьезные прерывистые сбои в этой области.

• Государственное тестирование на основе модели может быть адаптировано аналогично случайной регрессии. В этом стиле тестирования вы начинаете с известного состояния, с модели, которая определяет, какие состояния вы можете достичь, как вы можете узнать, к какому из них вы пришли, и к каким состояниям вы можете перейти от каждого из них. Тестирование состояния, ориентированное на охват, гарантирует, что каждая переходная пара будет покрыта хотя бы один раз. Марковское тестирование основывается на ключевой теореме для цепей Маркова, что, если вы переходите случайным образом, вы достигнете каждой возможной пары перехода. Учитывая, что версия большого объема останавливается при сбое или после установленного (длинного) времени, а не после достижения критерия охвата. Сверхдолгие последовательности могут выявлять те же типы повреждения стека, утечки памяти, повреждение памяти, условия гонки (и т. Д.), Которые предоставляет случайная регрессия.

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

Автоматизация большого объема иногда просто покрывает гораздо более высокую долю тестов в хорошо понятном наборе (например, тестирование эквивалентности функций, где вы можете покрыть N% возможных комбинаций ввода). В других случаях он достигает рисков (повреждения памяти, ошибок синхронизации, неправильно смоделированных переходов состояния оборудования), которые не подходят ни в одной модели покрытия, поскольку они являются побочными эффектами тестов, а не явно запланированными фокусами тестов. Эти проблемы сложнее устранить, особенно если сбой происходит в поле, потому что их условия репликации сложны. Это не делает их менее серьезными, но менее легко найти с помощью традиционных методов с низким объемом.

Переобучение тестировщиков программного обеспечения

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

Тестирование программного обеспечения лучше всего понимается как эмпирическое исследование тестируемого продукта, сделанное для предоставления связанной с качеством информации заинтересованным сторонам.

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

Коммерческая инструкция по тестированию программного обеспечения не обязательно обеспечивает большую ценность. Задача состоит в том, что в трехдневном классе практически нет времени для практики, применения собственной среды тестера, персонализированного коучинга или развития навыков. Короткие курсы передают обзор области, возможно, придают энтузиазм учащимся, и могут предоставить некоторые хорошие примеры, но реальное включение материала в базу знаний и мастерскую базы тестера произойдет после того, как класс будет выполнен - ​​если это вообще произойдет.

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

Интернет и гибридные (онлайн-плюс-видео) подходы делают новый жизнеспособный подход к тестированию образования. Материалы, финансируемые NSF, на веб-сайте testingeducation.org/BBST иллюстрируют курс, разработанный в академическом отношении, который используется без роялти, у нескольких компаний, которые распространяли свои занятия в течение значительных периодов времени, использовали собственный персонал (например, диспетчер тестов) как фасилитатор курса, и попросите учащихся применить каждую новую технику или урок к своему текущему проекту.

Такие материалы доступны для общественности (включая DoD) бесплатно по лицензии Creative Commons. Как и в случае с программным обеспечением с открытым исходным кодом, которое бесплатно предоставляет программное обеспечение, но поддерживает плату, МО иногда может обратиться к поставщикам обучения за поддержкой в ​​обучении менеджеров по тестированию, чтобы руководить курсом, разрабатывать индивидуальные оценки или разрабатывать новые материалы (видео и печать) Для специализированных версий курса. Стоимость такой поддержки, вероятно, намного меньше, чем расходы на отправку персонала на внешнюю, коммерческую подготовку.

Повторная обработка тестовых документов

Обычно приходится писать огромные документы, описывающие все детали тестирования. Что касается отраслевых стандартов и предполагаемых передовых методов, это не меняется. В последнем проекте пересмотра IEEE 829 представлен длинный список очень подробных документов.

Это имеет некоторые преимущества, но имеет несколько рисков:

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

• Чем больше информации о реализации, которую мы храним в нашем описании тестового примера, тем больше вещей мы должны изменить, когда изменяется программное обеспечение. Тщательно детальная тестовая библиотека становится источником инерции проекта, затрат на обслуживание, которые препятствуют улучшению продукта.

• В начале разработки разумный тест может проверить одно значение для одного поля в качестве полного теста. Например, так мы проводим традиционное тестирование граничных значений. Если программное обеспечение нестабильно, узкополосные тесты обеспечивают более эффективную поддержку устранения неполадок. По мере стабилизации программы одиночные тесты отдельных полей могут быть с успехом объединены в те тесты, которые задают значения для многих полей одновременно. Комбинаторный взрыв возможных тестов для нескольких переменных, проверенных вместе, означает, что мы, вероятно, не можем найти время для запуска всех возможных тестов. Тем не менее, мы можем достичь большего за время, доступное, если мы сможем автоматизировать процесс генерации входных данных тестового случая и сравнения результата с поведением системы отсчета, продукта или модели. Документирование каждого из этих тестов создает взрыв затрат.

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

Нам нужен новый подход, который разработан с явным намерением обеспечить надлежащую отдачу от инвестиций.

• Разумеется, документация должна поддерживать аудиты, предоставлять отчеты для судебных и нормативных расследований - в той мере, в которой они имеют отношение к конкретному проекту.

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



Cem Kaner - профессор разработки программного обеспечения во Флоридском технологическом институте. Он также является ведущим автором Testing Computer Software (с Hung Quoc Nguyen & Jack Falk), уроками, извлеченными при тестировании программного обеспечения (с Джеймсом Бахом и Брет Петтихордом) и Bad Software (с Дэвидом Пелсом).