![]() Главная страница Случайная страница КАТЕГОРИИ: АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника |
Обнаружение и отслеживание дефектов
Цель тестирования заключается в нахождении дефектов. Однако недостаточно толь ко отыскать дефекты. Об их наличии должным образом должны быть оповещены разработчики, чтобы они смогли эти дефекты устранить, а сведения о результатах выполненных ими исправлений доводятся до заинтересованных служб с тем, чтобы график разработки программного продукта не нарушался. Любые неэффективные действия при оповещении о дефектах, об их отслеживании, устранении и контроле приводят к потере времени.
В связи со сказанным выше, следующие два вида деятельности считаются основ ными при выявлении дефектов. Первым из них является прогон тестов в соответст вии с планом проведения испытаний для выяснения, имеются ли какие-либо расхож дения между ожидаемыми и фактическими результатами тестирования. Вторым ви дом деятельности является качественное документирование в системе отслеживания дефектов всех отклонений, обнаруженных во время тестирования. Хорошее качество документации важно по двум причинам — во-первых, разработчикам нужна достовер ная и надежная информация для того, чтобы снять все порождаемые неисправностя ми проблемы, и, во-вторых, тестировщики должны иметь возможность воспроизве сти проблемы, чтобы убедиться, что внесенные изменения устранили дефект. Систе ма, применяемая для документирования и отслеживания дефектов, представляет со бой важное инструментальное средство тестирования программного обеспечения. Несколько последующих разделов посвящаются изучению системы отслеживания дефектов, анализу состояний дефектов, изменению состояний дефектов и изучению других важных аспектов документирования и отслеживания дефектов.
Определение состояний дефектов
В главе 1 отмечалось, что дефектом является ошибка в рабочем документе, таком как технические требования, план проведения испытаний или программный код. Дефект остается необнаруженным до тех пор, пока рабочий продукт не будет подвергнут пе ресмотру или не будет выполнен прогон программы, во время которого программа выдаст ожидаемые результаты.
После нахождения дефект подвергается анализу с целью определения, представ ляет ли он неисправность теста, ошибку в программном коде или дефект в проектных спецификациях. Если источником проблемы является тест, а не программный код, то тест должен быть исправлен, а обнаруженный дефект " проигнорирован". Проверяет ся также, насколько серьезен дефект: принадлежит ли рассматриваемый дефект к категории катастрофических, подлежащих обязательному устранению перед постав кой программного продукта? Является ли возникшая проблема настолько серьезной, что она существенно снижает функциональные возможности программного продук та, но при этом все еще остаются открытыми обходные пути, позволяющие продол жать процессы тестирования и разработки? Либо же эта проблема не настолько кри тична, что ее решение нельзя отложить до будущих выпусков программного про дукта?
Программный код, содержащий обнаруженный дефект, должен быть направлен разработчикам для исправлений. Нужно внимательно следить за стадиями исправле ния, чтобы не потерять из виду сам дефект. Один из эффективных способов отеле-
живания дефекта состоит в четком определении явных состояний, которые может принимать дефект на пути от его обнаружения до завершающего тестирования. Каж дое состояние должно быть недвусмысленным и обладать набором определений критериев входа и выхода из испытания.
В таблице 5.1 показан пример определения состояний дефекта. Названия состоя ний в каждой компании могут быть свои, возможны также дополнительные состоя ния, которые не указаны в этой таблице. В ней показан обобщенный набор названий и состояний, который, возможно, стоит использовать как отправную точку при создании системы отслеживания дефектов " с нуля".
Таблица 5.1. Определение категории дефекта
Отслеживание дефекта на протяжении его жизненного цикла, от его обнаружения до устранения и проверки правильности исправления, показывает, что он меняет свое состояние в соответствии с некоторым набором правил. На рис. 5.2 приведен пример изменения состояний дефекта. Дефект обнаруживается во время пересмотра или в процессе системных испытаний и попадает в систему отслеживания дефектов, будучи в состоянии " новый". Ему присваивается уровень серьезности, после чего он передается на рассмотрение в группу анализа дефектов. Группа анализа дефектов (известная в некоторых кругах как группа контроля за внесением изменений в техни ческую документацию) определяет, нужно ли исправлять дефект в рамках текущего выпуска или отложить это до будущих версий. Если группы разработчиков и тести-ровщиков провели дальнейший анализ уже после того, как дефект был зафиксирован, и пришли к заключению, что в программный код не содержит каких-либо проблем,
|