|
|||||||
АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция |
Конфигурационное управление проектами в области ИСИтак, конфигурационное управление имеет дело с меняющимися в процессе продуктами, состоящими из наборов файлов. Такие продукты принято называть единицами конфигурационного управления (configuration management items). Вот примеры: 1. пользовательская документация; 2. проектная документация; 3. исходные тексты ПО; 4. пакеты тестов; 5. инсталляционные пакеты ПО; 6. тестовые отчеты. 7. Управление версиями файлов. Поскольку программисты имеют дело с огромным количеством файлов, многие файлы в один момент могут быть необходимы нескольким людям и важно, чтобы все они постоянно составляли единую, как минимум, компилирующуюся версию продукта, необходимо, чтобы была налажена работа с файлами с исходным кодом. Также может быть налажена работа и с другими типами файлов. В этой ситуации файлы оказываются самыми младшими (по иерархии включения) элементами конфигурационного управления. Управление версиями составных конфигурационных объектов. Понятие "ветки" проекта. Одновременно может существовать несколько версий системы – и в смысле для разных заказчиков и пр. (так сказать, в большом, настоящем смысле), и в смысле одного проекта, одного заказчика, но как разный набор исходных текстов. V1.0 – ветвь, соответствующая выпущенному релизу. Управление сборками Итак, почему же процедура компиляции и создания exe dll файлов по исходникам проекта – такая важная процедура? Потому что она многократно в день выполняется каждым разработчиком на его собственном компьютере, с его собственной версией проекта. Стандартизация качества. С точки зрения тестирования ПО нас интересует в этих стандартах стандартизация качества (как контекст тестирования) – сначала выпускаемой продукции, а потом и процессов по ее разработке. Здесь срабатывает идея о том, что качественного результата не создать без качественного процесса. Обеспечение качества является более общим контекстом для тестирования. Методы обеспечения качества ПО. Не претендуя на абсолютную полноту, перечислим различные способы контроля качества, используемые на практике при разработке ПО. Тестирование – это проверка соответствия между реальным поведением программы и ее ожидаемым поведением в специально заданных, искусственных условиях. Разберем это определение по частям. Виды тестирования. Не претендуя на полноту, выделим следующие виды тестирования. · Модульное тестирование - тестируется отдельный модуль, в отрыве от остальной системы. Интеграционное тестирование – две и более компонент тестируются на совместимость. · Системное тестирование – это тестирование всей системы в целом, как правило, через ее пользовательский интерфейс. · Регрессионное тестирование – тестирование системы в процессе ее разработки и сопровождение на регресс. · Нагрузочное тестирование – тестирование системы на корректную работу с большими объемами данных. · Стрессовое тестирование – тестирование системы на устойчивость к непредвиденным ситуациям. Этот вид тестирования нужен далеко не для каждой системы, так как подразумевает высокую планку качества. · Приемочное тестирование – тестирование, выполняемое при приемке системы заказчиков.
Между программистами и тестеровщиками необходим специальный интерфейс общения. Ведь ошибок находится много, их исправление требует времени, и их исправления разработчиками тестеровщики должны удостовериться, что они действительно исправлены. Как правило, описание ошибки в системе контроля ошибок имеет следующие основные атрибуты: ответственного за ее проверку – тестеровщика, который ее нашел и который проверяет, что исправления, сделанные разработчиком, действительно устраняют ошибку;ответственного за ее исправление – разработчика, которому ошибка отправляется на исправление; состояние, например, ошибка найдена, ошибка исправлена, ошибка закрыта, ошибка вновь проявилась и т.д.
Поиск по сайту: |
Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Студалл.Орг (0.003 сек.) |