Тестирование и исправление ошибок в программном коде ис в процессе эксплуатации

Предупреждение,
обнаружение, исправление ошибок,
обеспечение устойчивости к ошибкам.
Тестирование, доказательство, контроль,
испытание, аттестация, отладка.

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

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

Все
принципы и методы разработки надежного
программного обеспечения можно разбить
на четыре группы:

4.
Обеспечение устойчивости к ошибкам.

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

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

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

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

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

Контроль
– попытка найти ошибки, выполняя программу
в тестовой, или моделируемой, среде.

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

Аттестация
– авторитетное подтверждение правильности
программы. При тестировании с целью
аттестации выполняется сравнение с
некоторым заранее определенным
стандартом.

Отладка
– не является разновидностью тестирования.
Хотя слова “отладка” и “тестирование”
часто используются как синонимы, под
ними подразумеваются разные виды
деятельности. Тестирование – деятельность,
направленная на обнаружение ошибок;
отладка направлена на установление
точной природы известной ошибки, а затем
– на исправление этой ошибки. Эти два
вида деятельности связаны – результаты
тестирования являются исходными данными
для отладки.

Тестирование
модуля, или автономное тестирование –
контроль отдельного программного
модуля, обычно в изолированной среде.
Тестирование модуля иногда включает
также математическое доказательство.

Тестирование
сопряжений – контроль сопряжений между
частями системы (модулями, компонентами,
подсистемами).

Тестирование
внешних функций – контроль внешнего
поведения системы, определенного
внешними спецификациями.

Комплексное
тестирование – контроль и испытание
системы по отношению к исходным целям.
Комплексное тестирование является
процессом испытания, если выполняется
в среде реальной, жизненной.

Тестирование
приемлемости – проверка соответствия
программы требованиям пользователя.

Тестирование
настройки – проверка соответствия
каждого конкретного варианта установки
системы с целью выявить любые ошибки,
возникшие в процессе настройки системы.

8.2.
Базовые правила тестирования.

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

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

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

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

Необходимая
часть всякого теста – описание ожидаемых
выходных данных или результатов. Одна
из самых распространенных ошибок при
тестировании состоит в том, что результаты
каждого теста не прогнозируются до его
выполнения. Ожидаемые результаты нужно
определять заранее, чтобы не возникла
ситуация, когда “глаз видит то, что
хочет увидеть”. Чтобы совсем исключить
такую возможность, лучше разрабатывать
самопроверяющиеся тесты, либо пользоваться
инструментами тестирования, способными
автоматически сверять ожидаемые и
фактические результаты.

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

Готовьте
тесты как для правильных, так и для
неправильных входных данных. Многие
программисты ориентируются в своих
тестах на “разумные” условия на
входе, забывая о последствиях появления
непредусмотренных или ошибочных входных
данных. Однако многие ошибки, которые
потом неожиданно обнаруживаются в
работающих программах, проявляются
вследствии никак не предусмотренных
действий пользователя программы. Тесты,
представляющие неожиданные или
неправильные входные данные, часто
лучше обнаруживают ошибки, чем “правильные”
тесты.

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

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

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

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

Никогда
не изменяйте программу, чтобы облегчить
ее тестируемость. Часто возникает
соблазн изменить программу, чтобы было
легче ее тестировать. Например,
программист, тестируя модуль, содержащий
цикл, который должен повторяться 100 раз,
меняет его так, чтобы цикл повторялся
только 10 раз.

Рекомендуемый
подход к методам отладки аналогичен
особенностям проектирования и включает
в себя следующие этапы:

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

2.
Разработайте план. Следующий шаг –
построить одну или несколько гипотез
об ошибке и разработать план проверки
этих гипотез.

3.
Выполните план. Следуя своему плану,
пытайтесь доказать гипотезу. Если план
включает несколько шагов, нужно проверить
каждый.

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

Еще
одна трудность при отладке – такое
состояние, когда все идеи зашли в тупик
и найти местоположение ошибки кажется
просто невозможно. Это означает, что Вы
либо смотрите не туда, куда нужно, и
следует еще раз изучить симптомы и
построить новую гипотезу, либо подозрения
правильные, но разум уже не способен
заметить ошибку. Если кажется, что именно
так и есть , то лучший принцип – “утро
вечера мудренее”. Переключите внимание
на другую деятельность, и пусть над
задачей работает Ваше подсознание.
Многие программисты признают, что самые
трудные свои задачи они решают во время
бритья или по дороге на работу.

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

Исследования
методов отладки вначале концентрировались
на сравнении отладки в пакетном и
диалоговом режимах, причем большинство
исследований приходило к выводу, что
диалоговый режим предпочтительнее.
Однако более поздняя работа показала,
что, вероятно, наилучший способ отладки
– просто читать программу и изо всех сил
стараться вникнуть в алгоритм, хотя это
требует усердия и собранности.

Читайте также:  ОПИСАНИЕ КОДОВ ОШИБОК DTC

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

После
того, как точно установлено, где находится
ошибка, надо ее исправить. Самая большая
трудность на этом шаге – суметь охватить
проблему целиком; самая распространенная
неприятность – устранить только некоторые
симптомы ошибки. Избегайте “экспериментальных”
исправлений; они показывают, что Вы еще
недостаточно подготовлены к отладке
этой программы, поскольку не понимаете
ее.

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

По
самой своей природе исправления всегда
имеют некоторое отрицательное влияние
на структуру программы и легкость ее
чтения. Тот факт, что они делаются в
условиях жесткого давления, усиливает
это влияние. Опыт показывает, что при
исправлении довольно высока вероятность
внесения в программу новой ошибки
(обычно от 20 до 50).
Из этого следует, что отладка должна
выполняться лучшими программистами
проекта.

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

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

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

2.
Как и когда ошибка была обнаружена?
Поскольку мы только что добились
значительного успеха, почему бы нам не
воспользоваться приобретенным опытом?

3.
Почему эта ошибка не была обнаружена
при проектировании, контроле или на
предыдущей фазе тестирования?

4.
Что следовало сделать при проектировании
или тестировании, чтобы предупредить
появление этой ошибки или обнаружить
ее раньше?

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

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

Одним из основных
методов оценки качества программного
обеспечения является тестирование.

Два главных закона
теории тестирования программных
продуктов:

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

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

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

Для определения
количественных и/или качественных
характеристик, свойств продукции при
ее функционировании в реальной среде
и/или моделировании среды функционирования
проводят испытание программы.

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

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

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

Основными видами
испытания являются предварительные,
приемочные и эксплуатационные испытания,
включая опытную эксплуатацию.

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

При тестировании
информационной системы, были выявлены
ошибки:

Данные ошибки были
устранены. Было доказано, что программа
корректно выполняет предусмотренные
и поставленные задачи, т.е. программа
соответствует необходимым требованиям.

Соседние файлы в папке Маковеева И

Тестирование и исправление ошибок в программном коде ис в процессе эксплуатации

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Давно известно: как вы лодку назовете – так она и поплывет. Это в полной мере применимо к такому известному инструменту как Тестирование и исправление информационной базы, название выбрано крайне неудачно, так как предполагает, что использовать представленные в нем возможности следует при возникновении проблем с информационной базой и исправлении ошибок. На самом деле это не так. Любой имеющий опыт работы с “серьезными” СУБД найдет в этом списке привычные ему инструменты обслуживания баз данных, которые следует применять регулярно для поддержания высокой производительности сервера. Но речь сейчас не о них, а о начинающих, либо имеющих к 1С опосредованное отношение.

Тестирование и исправление ошибок в программном коде ис в процессе эксплуатации

Проверка логической целостности информационной базы проверяет и исправляет логические ошибки в структурах таблиц

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

Реиндексация таблиц информационной базы

Начнем с того, что такое индексы и для чего они нужны. Если рассматривать базу данных логически – то это некая совокупность связанных друг с другом таблиц, которые в свою очередь содержат какие-либо данные. Физически таблицы хранятся на диске в виде страниц и чем больше размер таблицы, тем большее количество страниц она будет содержать.

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

Тестирование и исправление ошибок в программном коде ис в процессе эксплуатации

Но ведь это чудовищно неэффективно, скажет внимательный читатель и будет прав. Что же делать? К счастью, все уже давно придумано. Хранение данных в СУБД можно сравнить с библиотекой, где таблицы – это залы библиотеки, а страницы – стеллажи. И когда вам нужна какая-то книга библиотекарь ведь не обходит физически все стеллажи, а сразу идет куда надо и приносит вам то, что вы просили. Чтобы быстро искать книги в библиотеках существуют каталоги, где книги перечислены в упорядоченном виде, и каждая карточка содержит сведения о том, где именно хранится тот или иной экземпляр.

Читайте также:  Коды ошибок в Valorant

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

Тестирование и исправление ошибок в программном коде ис в процессе эксплуатации

По мере работы с программой эффективность индексов снижается, особенно если вы активно удаляли или добавляли данные. Также индексы могут подвергаться фрагментации. Если снова сравнить с библиотекой, то за день работы посетители перепутали несколько ящиков, а работники библиотеки карточки новых книг поставили в конец и забыли убрать отсутствующие. Но все равно поиск по такому каталогу окажется быстрее, чем обход всех стеллажей в зале. А что нужно сделать, чтобы вернуть поиску прежнюю эффективность? Правильно, навести порядок в каталоге. Именно этим и занимается реиндексация, которая заново формирует индексы таблиц базы данных и устраняет их фрагментацию, что важно, если вы используете обычные жесткие диски или недорогие SSD.

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

Проверка логической целостности информационной базы

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

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

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

Тестирование и исправление ошибок в программном коде ис в процессе эксплуатации

Тестирование и исправление ошибок в программном коде ис в процессе эксплуатации

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

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

Как часто нужно запускать эту проверку? Время от времени, особенно в файловых базах с обязательным изучением лога проверки, чем раньше вы узнаете о возможных проблемах в структуре данных и устраните их – тем лучше.

Проверка ссылочной целостности информационной базы

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

Тестирование и исправление ошибок в программном коде ис в процессе эксплуатации

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

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

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

Тестирование и исправление ошибок в программном коде ис в процессе эксплуатации

В данном случае это нормально (Конфигурация Розница 2.3), так как конкретный экземпляр оборудования подключен именно к конкретному рабочему месту и передавать эти данные куда-то еще лишено особого смысла.

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

Тестирование и исправление ошибок в программном коде ис в процессе эксплуатации

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

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

Теперь о частичной потере данных объектов. К ним могут относиться элемент подчиненного справочника без владельца или движение без регистратора. Мы можем либо удалить такие объекты, либо создать связанные с ними. Чаще всего такие объекты имеет смысл удалять, особенно если это движения, хотя если это элемент справочника, владелец которого потерян, то в ряде случаев имеет смысл создать владельца.

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

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

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

Пересчет итогов

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

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

Тестирование и исправление ошибок в программном коде ис в процессе эксплуатации

Немного сложнее с регистрами накопления, записи в них содержат только сведения о движениях, скажем, такого-то числа в такое-то время на склад пришло 10 позиций некоторой номенклатуры, затем тем же днем продали 1 шт, потом 3 шт, за ней снова 5 шт и после еще 1 шт. При этом ряд вопросов, которые могут нас интересовать гораздо шире. Нас могут интересовать остатки на произвольный момент времени, либо обороты за некоторый период.

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

Читайте также:  Не удалось выполнить проверку обновлений код ошибки 3 0x80080005 system level

Тестирование и исправление ошибок в программном коде ис в процессе эксплуатации

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

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

Сжатие таблиц информационной базы

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

Тестирование и исправление ошибок в программном коде ис в процессе эксплуатации

Какой практический смысл этой операции? Да особо никакого, фрагментация данных от этого не уменьшится, а скорее всего даже увеличится. Единственный смысл сжатия базы – это если вы удалили из нее значительный объем данных и теперь просто оптимизируете общее занимаемое место.

Когда следует выполнять данное действие? Только если вы удалили из базы значительный объем данных, ну или если размер файла базы для вас критичен.

Реструктуризация таблиц информационной базы

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

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

И как раз-таки после реструктуризации будет уместно выполнить сжатие. Так как данные перемещать уже не надо, а пустое пространство уже сосредоточено в одном месте.

Как часто следует запускать? По необходимости, в том случае если вы изменили набор метаданных.

Пересоздание автономной конфигурации

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

Проверка логической целостности расширений конфигурации

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

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

Заключение

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

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

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

1.       О тестировании и исправлении базы с информацией

2.       Виды проверок и режимы тестирования

3.       Параметры вызова тестирования информационной базы из консоли

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

О тестировании и исправлении базы с информацией

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

Чтобы запустить тестирование информационной базы в системе 1С следует выполнить такие действия по порядку:

1.     Провести запуск нужной базы с информацией в режиме 1С, как конфигуратора;

2.     В верхней вкладке с меню кликнуть на пункт «Администрирование»;

3.     Из всего, избрать «Тестирование и исправление», после чего пройдёт запуск нужного нам окна с настройками для конкретной базы с информацией.

Далее представлено окно вида данной процедуры в системе 1С со всеми настройками:

Тестирование и исправление ошибок в программном коде ис в процессе эксплуатации

Oкно Тестирования и исправления информационной базы

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

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

Окно «Тестирования и исправления информационной базы» предусматривает исполнение одного из перечисленных действий с базой:

·        только проведение тестирования информационной базы;

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

Всё действие процесса по тестированию и исправлению базы с информацией можно разделить на пошаговое выполнение, где существуют следующие варианты возможностей:

·        задание конкретного времени на проведения теста и внесение правок;

·        сохранять все параметры во время проведения теста, между его этапами;

·        если тест был прерван, то можно начать его продолжение с того этапа, когда он был остановлен;

·        тест и внесение правок по требованию, из строки с командами.

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

Виды проверок и режимы тестирования

Сделаем более детальный обзор возможных настроек, которые находятся в окне «Тестирование и исправление информационной базы», а именно поля «Проверки и режимы», в нём записываются те проверки. Режимы тестирования, которые будет проходить конкретная база с информацией и бывают следующие:

·        «Проверка логистической целостности базы» – если отмечена эта проверка, то она состоит в том, что база с информацией будет проверена на соответствие по логистике и её структуре, после выполнение проверки будут внесены правки по организации файлов внутри базы;

·        «Пересчёт итогов» – эта проверка означает то, что итоги в 1С (внутри регистров по накоплениям и регистрам по бухгалтерии) будут подлежать пересчёту и сверке, что будет способствовать увеличению производительности внутри системы;

·        «Реиндексация таблиц информационной базы» – наличие данной проверки означает то, что внутри таблиц будут изменены индексы, что также будет способствовать увеличению производительности системы;

·        «Сжатие таблиц информационной базы» – в случае, когда отмечена данная проверка, будет проведено сжатие и уменьшение размеров базы данных, так как обычно в системе 1С, если удалить файлы, то они будут лишь помечены на удаление, а не удалены, а именно процедура сжатия удаляет все бесполезные файлы, в полном объёме, из базы;

·        «Проверка ссылочной целостности информационной базы» – этот пункт в тестировании информационной базы означает, что она будет проверена на отсутствие некорректных и неисправных ссылок. Если такие были найдены, то исправить предлагается следующими тремя путями:

1.     «Очищать ссылки» – все неисправные ссылки внутри базы будут удалены;

2.     «Не изменять» – ошибки будут выведены, но никаких перемен проводиться не будет;

3.     «Создавать объекты» – на нужных местах ошибок будут созданы пустые документы, которые, в последствии, в которые пользователь будет сам вносить правки и редактировать.

·        «Реструктуризация таблиц информационной базы» – операция, которая создаёт все таблицы внутри информационной базы с данными заново, данная операция занимает много времени.

Параметры вызова тестирования информационной базы из консоли

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

·        «/IBName» – запускает нужную базу с информацией по её наименованию (имени);

·        «/N» – параметр, который отвечает за имя конкретного юзера;

·        «/P» – пароль юзера, который отвечает его имени пользователя;

·        «/UC» – код доступа, который даёт право подключения к базе с информацией, в случае, если на ней установлен блокировщик;

·        «/IBCheckAndRepair» – параметр, который производит запуск теста и исправлений базы;

·        «UseStartPoint» – параметр, при помощи которого можно продолжить тестирование базы с информацией в случае, когда предыдущий сеанс теста был прерван;

·        «TimeLimit:hhh:mm» – параметр, при помощи которого можно ограничить по времени проведение данной процедуры.

В этом тексте был описан процесс проведения тестирования и исправления информационной базы в системе 1С, был проведён анализ всех возможных тестов и прописано, какие правки возможны, а также описано отличие проведения данных операций для файлового формата базы и клиент-серверного.

Специалист компании «Кодерлайн»

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *