реферат - модели тестирования (775495), страница 2

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 2)

При оценке уровня завершенности испытаний ПС и достоверности полученных результатов часто возникают серьезные затруднения. Отметим следующие из них:

1) большинство ПС являются уникальными и либо не имеют аналогов для сравнения характеристик, либо имеют аналоги, характеристики которых неизвестны;

2) отсутствие общепринятых показателей, а также методов расчета требуемых и фактических значений приводит к тому, что в ТЗ на разработку ПС требования к характеристикам ПС либо фактически отсутствуют (в количественном выражении), либо не претендуют на полноту.

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

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

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

Критерий интенсивности обнаружения ошибок. Если считать, что во время одного эксперимента обнаруживается не более одной ошибки и каждая ошибка до начала следующего эксперимента устраняется, то можно предположить, что при благоприятном ходе отладки и испытания кривая зависимости: N = 1 — п/К, где п — количество обнаруженных и устраненных ошибок; К. — . количество экспериментов, будет асимптотически стремиться к единице (кривая 1 на рис. 17). Кривая 2 свидетельствует о неблагополучном ходе процесса.

Тогда в качестве критерия прекращения испытаний можно принять, например, следующее условие: N > 0,95 при обнаружении в последних двухстах экспериментах не более трех несущественных ошибок.

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

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

- исходное количество дефектов в программе; - общее количество дефектов, которое может проявиться за время эксплуатации ПС; — средняя наработка на отказ в начале испытаний;

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

Скорость обнаружения и устранения дефектов, измеряемая относительно времени функционирования программы, пропорциональна интенсивности отказов. Коэффициент пропорциональности B=n/m называется коэффициентом уменьшения дефектов.

Количество зарегистрированных отказов т зависит от суммарного времени функционирования программы следующим образом:

Значение средней наработки на отказ также зависит от суммарного времени функционирования:

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

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

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

3.Модель зрелости тестирования

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

Консультант по вопросам тестирования Терри Везерил в 2001 году одним из первых сравнил существующие модели зрелости тестирования [1] и выделил шесть моделей:

Testability Maturity Model (TMM);

Software Testing Maturity Model (TMMSW);

Test Process Improvement (TPI);

Test Organization Maturity (TOM);

Testing Assessment Program (TAM);

Proposed Evaluation and Test SW-CMM Key Process Areas (SW-CMM KPA).

Затем в некоторые модели были внесены принципиальные изменения; так, модель ТОМ (ее создала и развивает компания Gerrard Consulting) предлагает обновленный набор метрик, описывающих непосредственно процесс тестирования (длительность тестовых итераций, соотношение тестовых сценариев и функциональных требований и др.), которые собираются и анализируются на этапе описания существующего процесса.

Среди шести моделей зрелости тестирования программного обеспечения практики и консультанты выделяют две: TMMSW, разработанную в Технологическом институте штата Иллинойс, и TPI, предложенную в компании Sogeti. Обе модели получили распространение в первую очередь благодаря своей простоте, а также предлагаемым практикам внутренних аудитов, которые могут производиться специалистами компании, вставшей на путь процессных улучшений. Рассмотрим структуру моделей зрелости тестирования программного обеспечения на примере модели TMM.

Модель TMMSW является наиболее интересной для применения, поскольку наряду с простотой понимания и использования практик позволяет организациям собственными силами проводить оценки (assessment) и постепенно приближаться к поставленным целям развития, контролируя промежуточные результаты.

Модель TMMSW разработана группой специалистов под руководством Илен Барнштейн в 1996 году как расширение и дополнение к модели SW-CMM. К ее преимуществам можно отнести соответствие уровней зрелости процессов тестирования программного обеспечения и уровней зрелости процессов разработки в модели SW-CMM. Также модель TMMSW может быть использована в интеграции с CMMI, рекомендациями ISO-9001 и стандартом ISO/IEC Std 12207, которые позволяют пройти формальную сертификацию и при постоянном контроле в виде аудитов и переаттестаций оставаться на заданном уровне качества. С одной стороны, эта особенность TMMSW позволяет внедрять процессные изменения в подразделении тестирования программного обеспечения в формате выделенного проекта меньшего масштаба, чем внедрение CMMI во всей организации (что экономит средства и обеспечивает прозрачность); с другой стороны, при таком подходе исключаются затраты на адаптацию и сопряжение нескольких моделей.

Заключение.

Главная цель тестирования — показать, что приложение соответствует требованиям.

Литература :

1. Уокер Ройс. Управление проектами по созданию программного обеспечения. М.: Лори, 2002.

2. Г. Майерс. Надежность программного обеспечения. М.: Мир, 1980.

14

Характеристики

Список файлов реферата