Аннотация

Программное обеспечение играет все более важную роль в сложных системах, особенно для высокотехнологичных приложений, задействованных в важных областях, таких как транспорт, финансовый менеджмент, связь, биомедицинские приложения и так далее. Для этих систем такие характеристики, как эффективная работа, отказоустойчивость , безопасность и защищенность должны быть гарантированы структурой программного обеспечения, качество использования которого приобретает все большее значение с промышленной точки зрения. Основная проблема заключается в том, что сложность задач, которые должно выполнять программное обеспечение, часто растет быстрее, чем сложность аппаратного обеспечения. Кроме того, в отличие от аппаратного обеспечения, программное обеспечение не может сломаться или износиться, но может выйти из строя в течение своего жизненного цикла (динамические дефекты) [1] . Проблемы программного обеспечения, по сути, должны решаться с помощью инструментов обеспечения качества, таких как управление конфигурацией , процедуры тестирования, системы отчетности о качестве данных и так далее. В этом контексте в статье предлагается новый подход к автоматизированному тестированию программного обеспечения как вспомогательное средство для максимизации покрытия плана тестирования в пределах доступного времени, а также для повышения надежности и качества программного обеспечения при использовании [3] . В данной статье будет представлен метод, сочетающий ускоренные автоматизированные тесты для исследования регрессии программного обеспечения и переполнения памяти, чтобы гарантировать как высокое качество программного обеспечения, так и сокращение времени тестирования. Тестирование программного обеспечения будет проводиться с использованием тестовых последовательностей, воспроизводящих реальные условия эксплуатации и ускоренный уровень нагрузки. Кроме того, исследование направлено на определение некоторых параметров жизненного цикла программного обеспечения и демонстрацию общности предлагаемого метода.

1. Введение

К программной системе часто предъявляются противоречивые требования: она должна быть надёжной в применении и в то же время соответствовать потребностям рынка, предлагая конкурентоспособные цены [1, 2]. В этом контексте процесс тестирования, включающий количественное планирование, отслеживание и автоматизацию, играет основополагающую роль. Тестирование надёжности программного обеспечения сочетает в себе использование количественных показателей надёжности с эксплуатационными профилями (профилями использования системы), которые помогают разработчикам в реализации тестирования. Важным нововведением стало бы внедрение ускорения автоматизированного тестирования для сокращения времени и стоимости разработки, не вызывая в системе сбоев, отличных от тех, которые мы хотим проанализировать.

Неадекватное и неэффективное тестирование является причиной многих проблем, связанных с надежностью программного обеспечения, с которыми сталкиваются пользователи компьютеров. С другой стороны, сложность современных программных пакетов затрудняет исчерпывающее тестирование. Тем не менее, автоматизированное тестирование может помочь повысить эффективность процесса тестирования, чтобы выявить области программы, склонные к сбоям. Автоматизированное тестирование может применяться в больших частях многих приложений, снижая нагрузку на перегруженных тестировщиков. Еще несколько лет назад разработчики считали тестирование программного обеспечения второстепенным видом деятельности по сравнению с этапом разработки; сегодня же во многих областях применения тестирование представляет собой отправную точку для разработки продукта, а его стоимость часто сопоставима со стоимостью разработки продукта. Фактически, было подсчитано, что тестирование программного обеспечения, способное обнаруживать ошибки в исходном коде, занимает более 50% разработки программного обеспечения. Время и стоимость могут быть значительно сокращены за счет использования автоматизированных генераторов тестов [4].

Среди видов деятельности, позволяющих обнаруживать несоответствия и потенциальные сбои на различных этапах создания программного продукта, верификация и валидация реализации программного обеспечения играет основополагающую роль. С этой целью были выпущены некоторые стандарты и руководства, касающиеся программного обеспечения как ключевого компонента, который вносит вклад в поведение и производительность системы; некоторые примеры представлены международным стандартом ISO/IEC 9126 [5], который определяет модель качества для программного продукта, чтобы удовлетворить заказчика путем оптимизации продукта, и стандартом IEEE 1012 [6] для верификации и валидации программного обеспечения, который пытается установить общую структуру для всех видов деятельности и задач в поддержку этапов жизненного цикла программного обеспечения. В частности, среди различных этапов, усилия по улучшению качества связаны с этапами верификации и валидации [3, 7]; эти виды деятельности определяют, соответствуют ли продукты данного вида деятельности требованиям и удовлетворяет ли программное обеспечение предполагаемому использованию и потребностям заказчика. Верификация и валидация - это деятельность в производстве программного обеспечения, которая позволяет снизить производственные затраты и, в то же время, повысить надежность программного обеспечения. Верификация — это процесс оценки программного обеспечения для определения соответствия продуктов данной фазы разработки условиям, заданным в начале этой фазы. Валидация — это процесс проверки соответствия программного обеспечения требованиям [6]. В рамках верификации и валидации проводится интеграционное тестирование, выявляющее дефекты в интерфейсах и взаимодействии между интегрированными компонентами (модулями); постепенно увеличивающиеся группы протестированных программных компонентов, соответствующих элементам архитектурного проекта, интегрируются и тестируются до тех пор, пока программное обеспечение не станет работать как единая система.

Важно помнить, что утечки и повреждение памяти считаются критическими ошибками программного обеспечения, которые существенно влияют на доступность и безопасность системы. Утечки и переполнение памяти в языке программирования «C» называются нежелательным увеличением занимаемой программой памяти. Потребление памяти программой в значительной степени увеличивается из-за непреднамеренного её потребления. Это также означает, что память программы повреждается, что приводит к ошибке. Некоторые из этих ошибок не являются критическими, но могут вызвать серьёзные проблемы для программы. При наличии утечки памяти система может перестать функционировать и может нарушить некоторые файлы операционной системы. Переполнение памяти также известно как переполнение стека или переполнение буфера. При возникновении такой ошибки программа может завершиться, особенно при сохранении за пределами лимита [8-10]. В результате программа может выдать неверные результаты, что приводит к сбою в работе программы и операционной системы. В этом случае утечки памяти, вызванные недоступностью некоторой выделенной памяти, могут кумулятивно ухудшить общую производительность системы, увеличивая подкачку памяти или, в худшем случае, вызывая сбой программы. Системная память, выделенная процессами, управляется разработчиком с помощью набора правил; эти правила часто оптимизированы для многих приложений, но не для всех [2]. Чтобы оценить утечки памяти во время регрессионного тестирования, автоматический тест программного обеспечения, предложенный в этой статье, можно классифицировать как динамический тест [4], способный стимулировать тестируемое программное обеспечение с ускоренным во времени уровнем нагрузки. С этой целью мы рассмотрели список процессов, которые необходимо наблюдать, и для каждого из них выбраны два параметра для анализа: частные байты и рабочий набор, как определено в разделе 2. В этой статье предлагается подход, который одновременно учитывает выполнение регрессионных тестов и оценку переполнения памяти; Целью является демонстрация снижения затрат на тестирование и повышения надежности программного обеспечения с точки зрения среднего времени до отказа (MTOF) [11-14]. Параметр среднее время до отказа, позволяющий оценить сбой системы из-за переполнения, определён в разделе 2. Его оценка для конкретных задач и приложений представлена ​​в разделе 3. Автоматический мониторинг этого параметра во время регрессионного тестирования можно рассматривать как вспомогательное средство для программного продукта, позволяющее планировать правильные операции по обслуживанию и снижать затраты.

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

Далее, после описания основных этапов метода автоматизированного тестирования, показаны предлагаемые усовершенствования, подкрепленные подробным рассмотрением экспериментальных данных.

2. Предлагаемая методология испытаний

В литературе существует несколько известных методик тестирования программного обеспечения общего назначения [15, 16]. Такие методы следуют структурному или функциональному подходу, также идентифицируемым как подход "белого ящика" и "черного ящика" соответственно. Предлагаемая методика может быть классифицирована как подход "черного ящика", где тестируемое программное обеспечение должно быть проверено с помощью подходящего изученного набора входных данных, ожидаемые выходные данные которых известны только на основе функциональных спецификаций. В дополнение к подходу "черного ящика" мы предлагаем метод тестирования с наборами тестов, хорошо отражающими поведение системы в полевых условиях, в соответствии с блок-схемой, показанной на Рис. 1. Можно заметить, что «параметры теста» и «статистическое распределение полевых данных» являются входами; «результаты теста», «ожидаемые результаты», «среднее время до отказа (MTOF)» и «конечные результаты» являются выходами [17, 19]. «Тестируемое программное обеспечение» является объектом анализа, а «генерация тестовых случаев» [20-23], «выполнение тестовых случаев», «обработка входных данных», «мониторинг занятой памяти» и «сравнение» являются действиями.

Подход к тестированию программного обеспечения основан на динамической псевдослучайной генерации, которая смешивает предварительные параметры теста, полученные из результатов тестов, и статистическое распределение полевых данных. Комбинация возможных переменных и, следовательно, эволюция состояний является случайной и представляет тестовый случай. Предлагаемая методика использует преимущества псевдослучайности, направленной на увеличение количества тестовых последовательностей и, в то же время, на лучшее моделирование возможных реальных условий; она позволяет изменять тестовые последовательности без изменения программного кода благодаря своим высоким характеристикам гибкости. Генератор тестовых случаев создает практически неограниченные последовательности, которые могут быть повторены на тестируемом программном обеспечении. Как входы, так и выходы могут иметь размер около 100 КБ. Результаты тестов, представленные выходными данными тестируемого программного обеспечения, сравниваются с ожидаемыми результатами, полученными из тестовых случаев, в конце фазы тестирования; конечные результаты позволяют получить информацию о качестве использования тестируемого программного обеспечения и новые данные для динамической генерации тестовых случаев. Подробные шаги, касающиеся сравнения полученных и ожидаемых результатов, показаны на Рис. 2. Если различий между полученными и ожидаемыми значениями нет, тест останавливается; в противном случае необходимо отследить неисправность, и программное обеспечение должно вернуться к команде разработчиков для анализа и исправления ошибки; впоследствии тест должен быть проведен снова. Также существует возможность обнаружения неясных значений, таких как неоднозначности, которые должны быть решены вручную путем повторения неоднозначных последовательностей.

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

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

• Приватные байты (Private bytes): этот параметр отображает количество байт, зарезервированных исключительно для конкретного процесса. Если происходит утечка памяти, это значение будет неуклонно расти.
• Рабочий набор (Working set): представляет текущий размер области памяти, используемой процессом для данных, потоков и т.д. Размер рабочего набора растет и уменьшается по мере того, как Диспетчер виртуальной памяти (VMM) может разрешить. Поскольку он показывает память, которую процесс выделил и освободил в течение своей жизни, когда рабочий набор слишком велик и не уменьшается правильно, это обычно указывает на утечку памяти.

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

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

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

Важно подчеркнуть, что насыщение доступной памяти из-за утечек памяти является распространенной причиной сбоя программного обеспечения. Утечка памяти — это явление постоянного занятия памяти, которое возникает, когда модуль выделяет память, но никогда ее не освобождает. Это поведение, повторяющееся с течением времени, истощает доступный размер памяти и вызывает блокировку системы (аварийную остановку) [25, 26].

Программный модуль характеризуется утечкой памяти, если по крайней мере одна из операций (или последовательность операций), которые он выполняет, страдает от утечек памяти. После теста часть памяти, занятая программой, страдающей от этой причины сбоя, может быть минимальной (несколько КБ); явление, как правило, не заметно при единичном тесте, но может стать значительным при многократном повторении одних и тех же тестовых последовательностей. Этот тип проблемы можно изучить с помощью метода автоматизированного тестирования, предложенного в этой работе; фактически, повторяя тестовую последовательность и отслеживая тенденцию занятой памяти во время теста, возможна оценка наличия утечек памяти. Полезно, поэтому, ввести параметр Среднее Время до Отказа (Mean Time To Overflow, MTOF), определяемый как отношение размера доступной памяти к среднему увеличение занятости памяти за установленный интервал времени. В зависимости от значения среднего увеличение занятости памяти за установленный интервал времени , оцениваемого в КБ в день, час или последовательность, мы можем выразить среднее время до отказа в количестве дней, часов или последовательностей до исчерпания ресурсов памяти и, следовательно, до коллапса системы (аварийной остановки системы).

Для сложной системы, где задействованы независимые памяти для операционных функций, уравнение может быть изменено, и определяется Системное Среднее Время до Отказа (System Mean Time To Overflow):

3. Валидация методики

Обоснованность предложенного подхода проверяется путем рассмотрения промышленного приложения, состоящего из многофункциональной распределительной автозаправочной станции [27], как показано на рисунке 3.

Для этого приложения программный комплекс играет фундаментальную роль во всех видах деятельности, связанных с управлением автозаправочной станцией. В нашем случае и в его полной версии примерно 40 000 модулей и 5 000 000 строк кода определяют сложность программного комплекса, способного управлять такими важными видами деятельности, как продажа топлива и его хранение с помощью Системы управления раздаточными колонками (Dispenser Management System, DMS), и всеми операциями, требующими использования Системы оплаты по картам (Card Payment System, CPS).

Был спланирован и реализован тестовый набор, который воспроизводит последовательность, которая будет рекурсивно повторяться на сервисной станции. Его размер составляет около 8 МБ, и он состоит из 590 строк кода. Такой тестовый набор, показанный на рисунке 4, включает реальные операции с подключением к Системе оплаты по картам, который включает следующие проверки:

• a) Вход в систему, чтение параметров карты, обновление или создание журнала;
• b) Проверка ограничений на покупку и действительности карты;
• c)Случайный выбор доступной колонки;
• d)Выбор продукта и его выдача (на основе статистического распределения реальных продуктов);
• e)Случайный отказ от операции или выход из системы, закрытие журнала.

Тестовый набор позволяет воспроизвести 13 100 тестовых случаев, сгенерированных в соответствии с предлагаемой методикой тестирования, описанной в Разделе 2, без каких-либо изменений в тестируемом системном программном обеспечении.

Затем тестовый набор повторяется, выполняя 2233 продаж за 40 часов, в среднем примерно 56 продаж/час; что в четыре раза больше, чем условия в полевых условиях (около 14 продаж/час), которые выполняются для каждой POS-системы (точки продажи). Тестовый набор стимулирует множество активностей: взаимодействие между программным обеспечением и контроллером, симулятор колонок, который воссоздает взаимодействие между системой, клиентом и подключением к сервисному центру нефтяной компании для управления картами лояльности, кредитными и дебетовыми картами. Только внешние аппаратные устройства, колонки и аппаратная подсистема DMS, имитируются.

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

Тенденция занятой памяти растет линейно со временем и количеством продаж; мы предполагаем, что продажи распределены равномерно в течение рассматриваемого интервала времени теста. Если производительность компьютеров известна, изменение памяти можно оценить в байтах/час как разность максимальной (15 609 856 байт) и минимальной (9 732 096 байт) выделенной памяти тестируемого приложения, делённая на продолжительность последовательности в часах.

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

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

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

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

Тестируемое программное обеспечение также имеет контроллер базы данных, в котором собирается вся информация, введенная клиентом или используемым пользовательским интерфейсом. База данных сохраняется на двух разных дисках (основном и вторичном); и Система управления базами данных (СУБД) выполняет ее реконструкцию. Во время теста тенденция занятой памяти контроллером базы данных наблюдается с помощью измерения приватных байтов и рабочего набора, как показано на графиках на Рис. 6 синей и желтой линиями соответственно.

Тенденция памяти кажется постоянной, за исключением наличия некоторых мгновенных пиков во время выполнения реконструкции базы данных. Каждый раз, когда выполняется реконструкция, среднее увеличение занятости памяти занимает около 35 МБ/день, как показано на рисунке 6.

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

Итак, Среднее Время до Переполнения программного обеспечения теперь уменьшилось до 24 дней. MTOF, являясь индексом, способным оценить сбой программного обеспечения, может рассматриваться как параметр для оценки надежности программного обеспечения и, как следствие, для планирования правильного обновления системы и качества в использовании в соответствии со стандартом ISO/IEC 9126.

В качестве дополнительного преимущества предложенный подход позволяет изменять уровень нагрузки, тестируя таким образом программное обеспечение на высоком уровне нагрузки за наименьшее время тестирования. Это может привести к обнаружению ошибок, не обнаруженных при низких уровнях нагрузки, увеличивая охват тестового плана. Например, за 15 рабочих дней мы можем реализовать 12 600 тестовых циклов (35 тестовых последовательностей/час), если мы реализуем ускоренные автоматизированные тесты, вместо 5 040 циклов (14 тестовых последовательностей/час, как предлагается полевыми данными) без ускоренных тестов и 600 циклов (~5 тестовых последовательностей/час) при ручном тестировании. Эти соображения суммированы в Таблице 1 и изображены на Рис. 7, где автоматизированные тесты сравниваются с традиционными (ручное тестирование).

4. Выводы

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

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

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

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

Литература

1. Reliability Analysis Center, Introduction to Software Reliability: A State of the Art Review, Reliability Analysis Center (RAC), 1996.
2. D. Musa, Introduction to software reliability engineering and testing. Proceedings of the 8th International Symposium on Software Reliability Engineering, 1997.
3. A. Birolini, Reliability Engineering – Theory and Practice, Springer-Verlag3-540-40287-X, 2004.
4. E. Diaz, J. Tuyo, R. Blanco, Automated software testing using a metaheuristic technique based on tabu search. Proceedings of 18th IEEE International Conference on Automated Software Engineering, 2003, pp. 310–313.
5. ISO/IEC 9126: Information technology – software product evaluation – quality characteristics and guidelines for their use, 2001.
6. ANSI / IEEE Std. 1012, IEEE Standard for Software Verification and Validation Plans, 1986.
7. ANSI / IEEE St. 829, Standard for Software test documentation, 1998.
8. M. Rinard, C. Cadar, D. Dumitran, D.M. Roy, T. Leu, A dynamic technique for eliminating buffer overflow vulnerabilities (and other memory errors). Proceedings of the 20th Annual Computer Security Applications Conference, Tucson, Arizona, USA, December 6-10 2004.
9. H. Gunes Kayack, A. Nur Zincir-Heywood, M. Heywood, Evolving successful stack overflow attacks for vulnerability testing. Proceedings of the 21st Annual Computer Security Applications Conference, Tucson, Arizona, USA, December 5-9, 2005.
10. Y. Wiseman, L. Isaacson, E. Lubowicz, Eliminating the threat of kernel stack overflows. IEEE St. 2008, July 13-15, 2008, Las Vegas, Nevada, USA, 2008.
11. ]V.V. Mazalov, M. Tamaki, S.V. Vinnichenko, Optimal computer memory allocation for the poisson flows, Automation and Remote Control (ISSN: 0005-1179) 69 (9) (2008) 1510–1511.
12. B.R. Cooper, M.K. Solomon, The average time until bucket overflow, ACM Transactions on Database Systems 9 (3) (September 1984) 392–408.
13. G. Copeland, T. Keller, R. Krishnamurthy, M. Smith, The case for safe RAM, Proceedings of the fifteenth International Conference on Very Large Data Bases, Amsterdam, 1988.
14. P.S. Mayni, M.R. Fraternal, Recurrence times of buffer overflow in jackson networks, Proceedings of the 29th Conference on Decision and Control Honolulu, Hawaii, December 1990.
15. H. Freeman, Software testing. IEEE Instrumentation & Measurement Magazine 5 (3) (September 2002) 48–50.
16. G. Betta, D. Capiglione, A. Pietrosanto, P. Sommella, A statistical approach for improving the performance of a testing methodology for measurement software, IEEE Transactions on Instrumentation and Measurement 57 (6) (June 2008) 1118–1126.
17. M.A. Bailey, T.E. Moyers, S. Ntafos, An application of random software testing, IEEE MILCOM, Conf. Rec., vol. 3, November 1995, pp. 1098–1202.
18. C.C. Ntafos, On comparisons of random, partition, and proportional partition testing, IEEE Transactions on Software Engineering 27 (10) (October 2001) 949–960.
19. W. Lingfeng, K.C. Tan, Software testing for safety critical applications, IEEE Instrumentation & Measurement Magazine 8 (2) (March 2005) 38–47.
20. I. Burnstein, Practical software testing: a process-oriented approach, Springer-Verlag, New York, 2003, ISBN: 978-3-387-95131-8.
21. D. Galin, Software Quality Assurance: From Theory to Implementation, Pearson Addison Wesley, Harlow, England, 2004.
22. S.M. Phadke, Quality Engineering Using Robust Design, Prentice-Hall, Englewood Cliffs, NJ(13745-1679), 1989.
23. S. Stoica, Robust test methods applied to functional design verification, Proceedings of IEEE International Test Conference, September 1999, pp. 848–857.
24. M. Catelani, L. Ciani, V.L. Scarano, A. Bachoccola, A novel approach to automated testing to increase software reliability, Proceedings of IEEE International Instrumentation and Measurement Technology Conference, Vancouver, Canada, May 12-15 2008.
25. S. Roohi Shabrin, B. Devi Prasad, D. Prabu, R.S. Pallavi, P. Revathi, Memory leak detection in distributed system, Proceedings of World Academy of Science, Engineering and Technology, 1307-6884vol. 16, November 2006.
26. M. Grottke, K.S. Trivedi, Fighting bugs: remove, retry, replicate, and rejuvenate, Computer 40 (7) (February 2007) 107–109.
27. M. Catelani, L. Ciani, V.L. Scarano, A. Bachoccola, An automatic test for software reliability: the evaluation of the overflow due to memory leaks as failure cause, Proceedings of 16th IMERO Symposium TCA, Florence, Italy, September 2008.