Правила описания дефектов

Главная / Правила описания дефектов

Правила описания дефектов

Что пишут в блогах

• История одного бага: алгоритм работы Microsoft Windows приводил к тому, что обновление в Second Life могло вывести из строя принтер.

Онлайн-тренинги

Что пишут в блогах (EN)

Разделы портала

Про инструменты

Лучшие вакансии

Пример регламента по работе с дефектами на проекте для статьи Alien bugs или пришельцы из мира дефектов, Павел Новик, ЗАО «Технологии качества», бренд A1QA

I. Описание полей, принципы заполнения

Заводя дефект, заполняется следующие 8 полей:

  • Приоритет;
  • Тема;
  • Описание;
  • Компоненты;
  • Проявляется в версиях;
  • Окружение;
  • Исправить в версиях;
  • Вложение;
  • II. Подробнее про заполнение каждого из них:

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

  • Блокирующий – тестирование значительной части функциональности вообще недоступно.
  • Критический – не работает важная часть одной какой-либо функции либо не работает значительная часть, но имеется workaround, позволяющий продолжить тестирование.
  • Важный – не работает важная часть одной какой-либо функции, но при выполнении специфических условий, либо есть workaround, позволяющий продолжить ее тестирование либо не работает не очень значительная часть какой-либо функции. Также относится к дефектам с высокими visibility – обычно не сильно влияющие на функциональность дефекты дизайна, которые, однако, сразу бросаются в глаза.
  • Желательный – часто ошибки GUI, которые не влияют на функциональность, но портят юзабилити или внешний вид. Также незначительные функциональные дефекты, либо которые воспроизводятся на определённом устройстве.
  • Незначительный – почти всегда дефекты на GUI -опечатки в тексте, несоответствие шрифта и оттенка и т.п.
  • Тема – краткое (в пределах 20 слов) описание ошибки, состоит из трех частей: :

  • – обычно описание функциональной части где найден дефект.
  • – отвечает на вопрос «В чем заключается дефект?» — из этой части должно быть четко понятно, что случилось – возникла ошибка, отсутствует кнопка, произошло «зависание» или что-то еще. Кроме того, должно быть указано, где именно встретили ошибку – какая-то форма, поле и т.п.
  • – отвечает на вопрос «На что влияет дефект?» — особенно важно для дефектов с высоким приоритетом.
  • Описание – самое большое поле, предназначенное для подробного описания проблемы. Состоит из следующих частей:

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

    Проявляется в версиях – указывается версия билда, в котором был найден дефект.

    Окружение – указывается устройство и версия iOS (опционально несколько), на которых воспроизводится дефект.

    Исправить в версиях – указывается версия билда, в котором должен быть исправлен дефект.

    Вложение – логи, скриншоты или видео при необходимости, которые помогут понять путь воспроизведения дефекта и в чём его суть. Необходимо прикладывать для всех заводимых дефектов (для всех функциональных дефектов обязательно необходимо прикладывать логи).

    III. Общие правила заведения дефектов:

    Перед тем, как регистрировать ошибку в баг-трекер, необходимо провести как минимум три основных действия:

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

    Возможные состояния и резолюции описаны в Jira, a также дополнительно приведены на скриншоте ниже.

    software-testing.ru

    Правила описания результатов в баг-репорте

    В нашей постоянной рубрике «QA советы новичкам» очень важная тема: правила описания результатов в баг-репорте.

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

    Документировать дефекты необходимо для:

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

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

    В этой статье детально разбираются правила описания фактического ( Actual result ) и ожидаемого результатов ( Expected result ), которые являются обязательными полями при оформлении баг репорта.

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

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

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

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

    Фактический результат – это наблюдаемое или генерируемое поведение компонента или системы во время тестирования. Здесь описывается, что было получено в результате прохождения всех шагов баг репорта. Стоит отметить, что принцип «Что? Где? Когда?», который используется при кратком описании дефекта (Bug summary), также используется и для описания фактического результата. Этот принцип общеизвестный – сначала нужно написать «что», а уже потом «в каком месте» и «при каких условиях». Ключевое отличие описания дефекта и фактического результата состоит в более детальном написании последнего. В то же время не стоит использовать сложные предложения. Сложносочинённые и сложноподчинённые предложения, причастные и деепричастные обороты усложняют восприятие текста. Чем проще будет построено предложение, тем лучше. Также при необходимости возможно разбиение текста на несколько предложений.

    training.qatestlab.com

    Распространенные ошибки начинающих тестировщиков

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

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

    1. Неинформативные названия дефектов

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

    Итак, первое, что следует понимать о заголовке дефекта: он должен описывать суть проблемы. Чаще всего при помощи предложения, построенного по правилам английского, русского (или другого вашего рабочего) языка. Вспомним грамматику. Что такое предложение?

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

    В целом краткое описание (summary) дефекта должно отвечать на вопрос: «Что не так?» или, другими словами, «А проблема-то в чем?». В самом названии должно содержаться достаточно информации, чтобы можно было составить представление об этом, прочитав только заголовок. Именно для того, чтобы это было понятно хотя бы приблизительно, как раз и необходимо в названии ответить на эти три подвопроса:

    • «Что?» — как минимум должно быть описано то самое поведение программы, которое мы считаем некорректным, несоответствующим требованиям/стандартам/ожиданиям. Грубо говоря, это симптом.
    • «Где?» — в какой части продукта или системы (в каком модуле, на какой странице, с какой фичей)? Назовем это локацией.
    • «Когда?» — то есть при каких условиях воспроизводится дефект. Это триггер.
    • Рассмотрим некоторые примеры названий дефектов с точки зрения того, дают ли они нам представление о сущности проблемы.

      «Incorrect Site Search».
      О чем нам это говорит? Можно понять только то, что дефект связан с определенным функционалом, а именно с поиском по сайту. Это ответ на вопрос «Где?». Но что именно не так с поиском? В чем заключается некорректное поведение? Загадка. При каких условиях воспроизводится дефект? Тоже загадка.

      Другое summary того же бага: «The result of the action of the empty site search».
      Уже теплее. Можно понять, с каким функционалом связан дефект и даже каковы условия его воспроизведения. Но о том, что именно происходит не так — ни слова. «Просто the result» — какой-то результат, без всякой конкретики. А ведь это самое вкусное!

      Чтобы понять, в чем проблема, нужно прочитать описание полностью, да еще и попробовать воспроизвести. При пустом поисковом запросе перед списком товаров появляется секция с названиями категорий, и в ней одна картинка слишком большая, что нарушает UI. Кратко в summary это можно описать так:
      «After empty search request too large image is shown in “category-view” div».

      К этому багу нужно приложить скриншот, конечно.

      И вот еще один пример:
      «comment».
      Да, даже и так бывает. Одно слово, намекающее на область функционала.

      Вот так было бы понятнее:
      «Fatal error:463 on attempt to post review at product description page».

      «broken layout».
      Здесь описан симптом, некое некорректное поведение, так что такое описание можно считать ответом (хотя и очень приблизительным) на вопрос «Что (происходит)?». Но где именно это происходит? На какой-то конкретной странице? На любой странице? Непонятно. А что надо сделать, чтобы «верстка поползла»? Ни одного намека.

      Правильное краткое описание этого же бага:
      “On 150% zoom images at all pages are superimposed”.

      И еще пример:
      «Регистрация с невалидным адресом электронной почты«.

      Возможно, название подошло бы для тест-кейса. Понятно, с какой фичей связан дефект (регистрация), известен и триггер — «невалидный эмэйл» (конечно, важно уточнить в подробном описании: «невалидный» — это какой?). Но баг-то в чем?

      Более корректно было описать так:
      «Возможна регистрация с невалидным адресом электронной почты».
      Или
      «При регистрации не происходит валидация адреса электронной почты».

      Несколько подсказок, как написать хорошее summary для дефекта

      Коротко, но не слишком.
      Не забываем, что summary — это все-таки краткое описание, так что писать небольшое эссе на тему в этом поле тоже не стоит. В большинстве случаев вам хватит примерно 7-10 слов (не считая предлогов). Но не стоит вдаваться в другую крайность — 1-3 словами вы не сможете описать ситуацию достаточно ясно.

      Избавляйтесь от слов-паразитов , не лейте воду.
      Вот пример: «The opening of each new image when viewed on a new tab» .
      Многабукаф, а в итоге описан только симптом, и то невнятно.

      А суть здесь в том, что каждая картинка при клике на нее открывается в новой вкладке, что, разумеется, неудобно и не соответствует разумным ожиданиям пользователя. Это можно сказать короче и точнее: «On click each image opens in a new tab».
      Еще бы уточнить, в каком разделе сайта это происходит (точно не во всех), и было бы вообще отлично.

      Еще пример:
      «На сайте зайдя в раздел покупок, выдаетcя ошибка при попытке оставить отзыв».
      «Подъезжая к сией станции. у меня слетела шляпа». Не умея использовать деепричастные обороты, не стоит этого делать. И вообще лучше избегать громоздких конструкций.

      «На сайте» — просто ни о чем. Все дефекты, которые заводят в этом проекте, касаются именно этого сайта, так зачем повторять это в названии дефекта?
      Сокращаем:
      «Ошибка при попытке оставить отзыв в разделе покупок» — кстати, какая? Неплохо бы обозначить ее хоть как-то — класс, код. Полный текст сообщения об ошибке, конечно, приводить в summary бага необязательно.

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

      2. Отсутствие ожидаемых результатов

      Когда тестировщик заносит дефект, конечно, у него/нее обычно есть какое-то представление о том, как должно быть правильно. Но вот загвоздка — разработчики, как и все остальные люди, не обладают телепатией! И если ожидаемые результаты не описаны явно, то всегда есть вероятность, что возникнет непонимание.
      Кроме того, есть и другой риск. Разработчик может сделать собственные выводы о том, как же должно быть правильно, затем «исправить» и отправить на верификацию. Тут начнутся споры: «Исправлено!» — «Не исправлено!» — «Но вот же, здесь поменяли!» — «Так вообще не это было нужно!». В итоге — потрачено время, силы, нервы нескольких людей.
      Гораздо проще сразу объяснить, какого результата вы ожидаете. Даже если кажется, что это очевидно и всем понятно и так. Один из законов Мэрфи гласит: «Всё, что может быть понято неправильно, будет понято неправильно.» Особенно начинающим тестировщикам советую ввести это в привычку: всегда прописывать ожидаемые результаты явно. (Еще лучше, если вы можете подкрепить это ссылкой на конкретное требование.)

      3. Невнятные шаги воспроизведения

      Как бы банально это ни звучало, шаги лучше описывать пошагово. Одна строчка — один шаг. Можно нумеровать, можно не нумеровать, это по желанию. Но не стоит писать одним длинным абзацем, нагромождая when, while, which, then и тому подобное. Глядя на такое длинное и сложное предложение, воспроизвести дефект очень сложно. Даже простую ситуацию можно запутать, описав ее, например, так:
      «When purchasing products, when you press a button to buy, pop-up window, which when pressed to continue shopping, throws on the orders page»
      Эту ситуацию можно было бы описать так:
      “Continue shopping” button redirects to “Orders” page”
      Разумеется, эта кнопка не должна перекидывать на страницу заказа, покупатель должен оставаться там же, где и был, чтобы, собственно, продолжать покупки. Эти детали уже можно описать в Description.

      4. Скриншот вместо фактического результата

      Добавлять скриншоты к дефектам, особенно описывающим проблемы пользовательского интерфейса, конечно, очень полезно. Но! Скриншот не заменяет внятного текстового описания.
      «Фактический результат: «Запрос не прошел валидацию (см. скриншот)«

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

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

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

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

      www.luxoft-training.ru

      Обследование стен зданий. Описание основных дефектов, повреждений и трещин стен

      Стены зданий обследуют следующими методами:

    • визуально (когда об их общем состоянии судят по характеру трещин и искривлению линий фасадов);
    • приборами;
    • путем вскрытия и отбора проб.
    • При обследовании стен определяются следующие параметры и характеристики:

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

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

    • трещины на поверхности панелей;
    • отличие размеров панелей от проектных;
    • разрыв связей между панелями внутренних и наружных стен;
    • коррозия закладных деталей в местах стыков;
    • разрушение стыков;
    • разрушение защитного слоя;
    • неправильность армирования;
    • неудовлетворительные теплозащитные и звукоизоляционные качества;
    • повышенная водо- и воздухопроницаемость;
    • конструктивные недостатки стыков, дефекты монтажа.
    • Обследование стен начинают с выявления конструктивной схемы здания, назначения стен (ограждающая, несущая, самонесущая), прочностных характеристик материала, типов соединения стен (стеновых панелей) с другими несущими конструкциями: фундаментами, колоннами, перекрытиями и т. д.
      С помощью геодезических приборов определяют отклонения стен от вертикали, местные выпучивания, горизонтальность стыков и швов. Измеряют толщину швов стыков и трещин. Относительные горизонтальные отклонения (к высоте этажа) для кирпичных и железобетонных стен не должны превышать 1/500, облицованных естественным камнем 1/700, витражи 1/1000. Влажность материала стен находят отбором проб из разных слоев конструкции стен, в случае ее многослойности. Пробы нумеруют, взвешивают и помещают в термостат, где они высушиваются при температуре (110 ± 5)°С до постоянного веса. Сравнивают влажность стенового материала с допускаемой по нормам.

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

      Дефекты и повреждения стен зданий

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

        Трещины стен

        Трещины в стенах появляются вследствие:

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

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

        Важную информацию о состоянии стен дает анализ трещин в стенах. По поверхностным трещинам в кирпичных стенах можно судить о степени износа и прочности материала стены и самой стены в целом. При хорошем состоянии стен (износ до 20%) кладка монолитная, не имеет видимых изменений, камни и раствор сохраняют прочность, сцепление камней с раствором не нарушено. При удовлетворительном состоянии (износ от 20 до 40%) местами наблюдается разделение кладки на отдельные камни вследствие начинающейся потери сцепления с раствором, однако раствор еще сохраняет свою прочность. При плохом состоянии кладки (износ 40…60%) наблюдается ее прогрессирующее ослабление; потеря раствором прочности; появление волосяных трещин, выпадение или разрушение камней; выпирание отдельных мест стены. Перегрузка участков стен при удовлетворительном состоянии кладки проявляется в появлении трещин в вертикальных и горизонтальных швах. При плохом состоянии кладки трещины от перегрузки идут через камни. Особенно сильно снижение несущей способности проявляется при наличии горизонтальных трещин в простенках и вертикальных в перемычечных конструкциях. Трещины появляются не только от недостаточной несущей способности стен, но и из-за плохого состояния других конструкций: оснований, фундаментов и т.п. Контроль за поведением трещин ведется с помощью маяков, тензометров и др.

        lidermsk.ru

        Смотрите так же:

        • Ошибка 51 в реестре Как исправить ошибки REGISTRY_ERROR типа "синий экран" (0x00000051) Совместима с Windows 2000, XP, Vista, 7, 8 и 10 Признаки ошибок REGISTRY_ERROR типа "синий экран" Появляется ошибка “REGISTRY_ERROR” и окно активной программы вылетает. Отображается сообщение "STOP Ошибка 0x51: […]
        • Реестр usbstor Как отключить или включить USB порты в Windows Иногда возникает необходимость отключить USB порты на компьютере или ноутбуке, чтобы ограничить доступ по подключению флешек, жестких дисков и других USB-устройств. Отключение портов USB поможет предотвратить подключение каких-либо […]
        • Ошибки реестра операционной системы Оптимизация Windows с помощью CCleaner (Часть 2). Исправление проблем реестра Windows Снова здравствуйте! Это вторая статья из серии «Оптимизация Windows с помощью CCleaner». Первую часть можно найти здесь. Сегодня, продолжая серию статей о возможностях CCleaner’а, я расскажу о еще одной […]
        • Реестр общего доступа Профиль | Отправить PM | Цитировать Если же вы забыли свой пароль на форуме, то воспользуйтесь данной ссылкой для восстановления пароля. milligan, Конфигурация компьютера\Административные шаблоны\Сеть\Сетевые подключения\Брандмауэр Windows\Профиль домена -> Брандмауэр Windows: […]
        • Инвентаризационная комиссия созданная на основании приказа директора Научиться разрабатывать и оформлять акт. Материалы и оборудование:персональныйкомпьютер, программа Microsoft Word. Образовательные результаты, заявленные во ФГОС 3+: - оформлять документацию в соответствии с нормативной базой, в т. ч. используя информационные технологии; - осуществлять […]
        • Идём в реестр Редактируем меню создания файлов "Проводника" Windows Настраиваем и корректируем под свои нужды контекстное меню "Проводника", в частности, подменю создания новых файлов и папок. В контекстном меню "Проводника" Windows есть подменю создания новых файлов и папок. Однако пользы от него […]
        • Как войти в реестр xp Как открыть реестр в Windows 7 и 8? Реестр в операционной системе Windows или системный реестр — это иерархически построенная база данных параметров и настроек в большинстве ОС Microsoft Windows. В нем содержится различная информация и настройки для аппаратного и программного […]
        • Заявление на htc HTC и Google объявили о подписании соглашения о сотрудничестве ПЕКИН, 21 сен — РИА Новости, Анна Раткогло. Тайваньский производитель смартфонов и планшетов HTC (High Tech Computer Corporation) в четверг объявил о подписании соглашения по сотрудничеству с американской корпорацией Google […]