Claw.ru | Рефераты по информатике, программированию | Автоматизированное тестирование при разработке ПО Автоматизированное тестирование при разработке ПО | Категория реферата: Рефераты по информатике, программированию | Теги реферата: сообщение на тему, написание дипломной работы | Добавил(а) на сайт: Carjov. Предыдущая страница реферата | 1  2  3 | Следующая страница реферата	Разработка	Подсистемы	Функциональность, степень проверки компонентов
Функциональное	Разработка	Система в целом	Соответствие функциональным требованиям ТЗ
Регрессионное	Разработка, сопровождение	Система в целом	Проверка качества внесения изменений
Нагрузочное	Разработка, сопровождение	Система в целом	Оценка статистических характеристик системы, соответствие ТЗ, ТТХ, подбор конфигурации оборудования
Стрессовое	Разработка, сопровождение	Система в целом	Корректность работы системы при предельных нагрузках

Когда понятно, что и зачем нужно тестировать, и есть план действий, самое время задуматься о том, как это сделать эффективнее, быстрее и более качественно. Современное ПО -- это сложный объект, и вручную с ним справляться трудно и дорого. К тому же при "ручном" тестировании результаты каждого выполнения тестов пропадают, и их трудно повторить. Для того чтобы увеличить объем проверок и повысить качество тестирования, обеспечить возможность повторного использования тестов при внесении изменений в ПО применяют средства автоматизации тестирования. К их числу относятся средства автоматизации функционального и нагрузочного тестирования клиент-серверных и Web-приложений: Rational TestStudio, Mercury LoadRunner, Segue SilkPerformer, а также менее популярные продукты фирм Compuware, CA, Empirix, RadView Software и др.

Тестированием надо заниматься не только постоянно, но и систематично. Если не забывать, что это процесс обнаружения ошибок, то стоит потребовать от разработчика, чтобы он периодически силами специально созданных групп проводил так называемые "review", или "структурные просмотры" проектных материалов и аудит исходных кодов программ. Заказчик вправе договориться с разработчиком о предъявлении подобных материалов или о не очень глубоком контроле хода такого процесса. Он заинтересован в том, чтобы в организации разработчика были поставлены процессы. В этом случае заказчик может быть уверен, что качество разрабатываемого ПО контролируется и обеспечивается в ходе разработки. Именно на это направлены известная модель технологической зрелости СММ (Capability Maturity Model, www.sei.cmu.edu/cmmi/orgdocs/conops.html) и стандарт ISO 15504.

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

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

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

План тестирования определяется международным стандартом IEEE 829-1983. В нем должны быть предусмотрены как минимум три раздела содержащие, следующие описания: