Анализ и выявление причин возникновения ошибок - Не ошибается лишь тот, кто ничего не делает!

ществляется не пассивная фиксация брака в производстве, а про филактика его возникновения.

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

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

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

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

К настоящему времени сложились разнообразные методы контроля качества, которые можно разбить на две группы:

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

2.Ревизия (проверка) – проверка, осуществляемая контро лером, которая должна соответствовать содержанию карты кон троля технологического процесса.

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

тодов контроля; обеспечении взаимодействия всех элементов системы контро

ля качества продукции;

разработке методов и систематическом проведении анализа брака и дефектов.

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

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

К разрушающим методам относятся следующие испытания:

–испытания на растяжение и сжатие;

–испытания на удар;

–испытания при повторно переменных нагрузках;

–испытания твердости.

		Таблица 4.3

№	Классификационный	Виды технического контроля
п/п	признак

1	По назначению	Входной (продукции от поставщиков);
		производственный;
		инспекционный (контроль контроля).

2	По стадиям	Операционный (в процессе
	технологического	изготовления);
	процесса	приемочный (готовой продукции).

3	По методам контроля	Технический осмотр (визуальный);
		измерительный;
		регистрационный;
		статистический.
4	По полноте охвата	Сплошной;
	контролем	выборочный;
	производственного	летучий;
	процесса	непрерывный;
		периодический.

№	Классификационный	Виды технического контроля
п/п	признак

5	По механизации	Ручной;
	контрольных	механизированный;
	операций	полуавтоматический;
		автоматический.
6	По влиянию на ход	Пассивный контроль (с остановкой
	обработки	процесса обработки и после обработки);
		активный контроль (контроль во время
		обработки и остановка процесса при
		достижении необходимого параметра);
		активный контроль с автоматической
		подналадкой оборудования.

7	По измерению	Измерение действительных отклонений;
	зависимых и	измерение предельных отклонений с
	независимых	помощью проходимых и непроходимых
	допустимых	калибров.
	отклонений

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

9	По влиянию на	Разрушающий;
	возможность	неразрушающий.
	последующего
	использования

К неразрушающим методам принадлежат:

–магнитные (магнитографические методы);

–акустические (ультразвуковая дефектоскопия);

–радиационные (дефектоскопия с помощью рентгеновских

игамма лучей).

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

4.4.3. Статистические методы контроля качества

Различаются две области применения статистических мето дов в производстве (рис. 4.8):

при регулировании хода технологического процесса с целью удержания его в заданных рамках (левая часть схемы);

при приемке изготовленной продукции (правая часть схемы).

Статистические методы

УКП

Статистический анализ точности и стабильности технологических процессов и качества продукции

Статистическое

регулирование технологических процессов

Статистический

контроль

продукции

Статистические методы оценки качества продукции

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

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

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

1. Расслаивание (стратефикация).

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

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

Применение различных способов расслаивания зависит от конкретных задач. В производстве часто используется способ, на зываемый 4М, учитывающий факторы, зависящие от: человека (man); машины (machine); материала (material); метода (method).

То есть расслаивание можно осуществить так:

– по исполнителям (по полу, стажу работы, квалификации и т.д.);

– по машинам и оборудованию (по новому или старому, мар ке, типу и т.д.);

– по материалу (по месту производства, партии, виду, качест ву сырья и т.д.);

– по способу производства (по температуре, технологическо му приему и т.д.).

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

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

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

2.Графическое представление данных широко применяется

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

А. График, представляющий собой ломанную линию (рис. 4.9), применяется, например, для выражения изменения каких либо данных с течением времени.

Выручка (в млн. руб)

Аппроксимация,

выражающая

тенденцию

Финансовый год

Рис. 4.9. Пример «ломанного» графика и его аппроксимации

Б. Круговой и ленточный графики (рис. 4.10 и 4.11) приме няются для выражения процентного соотношения рассматривае мых данных.

Рис. 4.10. Пример кругового графика

Соотношение составляющих себестоимости производства: 1 – себестоимость производства продукции в целом; 2 – косвенные расходы; 3 – прямые расходы и т.д.

Рис. 4.11. Пример ленточного графика

На рисунке 4.11 показано соотношение сумм выручки от про дажи по отдельным видам изделий (A,B,C), видна тенденция: из делие B перспективно, а A и C – нет.

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

График строится следующим образом:

1)откладываются значения параметра (например, объем сбыта) по месяцам (за период одного года) с января по декабрь

исоединяются отрезками прямой (ломаная линия 1 на рис. 4.12);

2)вычисляется кумулятивная сумма за каждый месяц

истроится соответствующий график (ломаная линия 2 на рис. 4.12);

3)вычисляются итоговые значения (меняющийся итог)

истроится соответствующий график. За меняющийся итог в дан ном случае принимается итог за год, предшествующий данному месяцу (ломаная линия 3 на рис. 4.12).

Рис. 4.12. Пример Z8образного графика

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

их достижения.

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

50
1
40
30
20
10
3	4	5	6	7	8
				2
Рис. 4.13. Пример столбчатого графика

Где:

1 – число стимулов к покупке;

2 – стимулы к покупке;

3 – качество;

4 – снижение цены;

5 – гарантийные сроки;

6 – дизайн;

7 –доставка;

8 – прочие.

Если упорядочить стимулы к покупке по частоте их проявления

ипостроить кумулятивную сумму, то получим диаграмму Парето.

3.Диаграмма Парето.

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

Рис. 4.14. Пример диаграммы Парето

Где:

1 – ошибки в процессе производства;

2 – некачественное сырье;

3 – некачественные орудия труда;

4 – некачественные шаблоны;

5 – некачественные чертежи;

6 – прочее; А – относительная кумулятивная (накопленная) частота, %;

n – число бракованных единиц продукции.

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

4. Причинно:следственная диаграмма (рис. 4.15).

1	2	2	1
3
4
5			6

а) пример условной диаграммы, где: 1 – факторы (причины); 2 – большая «кость»; 3 – малая «кость»; 4 – средняя «кость»; 5 – «хребет»;

6 – характеристика (результат).

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

Рис. 4.15. Примеры причинно8следственной диаграммы

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

Рассмотрим форму причинно следственной диаграммы на рис. 4.15 (она называется еще «рыбий скелет» или диаграмма Исикавы).

Порядок составления диаграммы:

1.Выбирается проблема для решения – «хребет».

2.Выявляются наиболее существенные факторы и условия, влияющие на проблему – причины первого порядка.

3.Выявляется совокупность причин, влияющих на существен ные факторы и условия (причины 2 , 3 и последующих порядков).

4.Анализируется диаграмма: факторы и условия расставля ются по значимости, устанавливаются те причины, которые

вданный момент поддаются корректировке.

5.Составляется план дальнейших действий.

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

				Таблица 4.4

№ интервала	Измеренные	Частота	Накопленная	Накопленная
значения	частота	относительная
		частота

На основании контрольного листка строится гистограмма (рис. 4.16) или при большом количестве измерений кривая рас: пределения плотности вероятностей (рис. 4.17).

Рис. 4.16. Пример представления данных в виде гистограммы

Рис. 4.17. Виды кривых распределения плотности вероятностей

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

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

какова ширина распределения по отношению к ширине допуска; каков центр распределения по отношению к центру поля допуска;

какова форма распределения. В случае, если

а) форма распределения симметрична, то имеется запас по полю допуска, центр распределения и центр поля допуска совпа дают – качество партии в удовлетворительном состоянии;

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

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

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

д) ситуация аналогична предыдущей, аналогичны и меры воздействия;

е) в распределении 2 пика, хотя образцы взяты из одной пар тии. Объясняется это либо тем, что сырье было 2 х разных сортов, либо в процессе работы была изменена настройка станка, либо в 1 партию соединили изделия, обработанные на 2 х разных стан ках. В этом случае следует производить обследование послойно;

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

6. Диаграмма разброса (рассеяния) применяется для выяв ления зависимости (корреляции) одних показателей от других или для определения степени корреляции между n парами дан ных для переменных x и y:

(x1,y1), (x2,y2), …, (xn, yn).

Эти данные наносятся на график (диаграмму разброса), и для них вычисляется коэффициент корреляции по формуле

r =

δky

δ x × δ y

∑ xi × yi /n −

r =

i−1

∑ xi /n −

∑ yi /n −

i−1

δ x =

∑ xi /n −

2 ,

i−1

δ y =

∑ yi /n −

2 ,

i−1

где

δky – ковариация;

δх, δy – стандартные отклонения случайных переменных x и у; n – размер выборки (количество пар данных – хi и уi);

x и y – среднеарифметические значения хi и уi cоответственно. Рассмотрим различные варианты диаграмм разброса (или по

лей корреляции) на рис. 4.18:

Рис. 4.18. Варианты диаграмм разброса

В случае:

а) можно говорить о положительной корреляции (с ростом x увеличивается y);

б) проявляется отрицательная корреляция (с ростом x уменьшается y);

в) при росте x y может как расти, так и уменьшаться, гово рят об отсутствии корреляции. Но это не означает, что между ни ми нет зависимости, между ними нет линейной зависимости. Очевидная нелинейная (экспоненциальная) зависимость пред ставлена и на диаграмме разброса г).

Коэффициент корреляции всегда принимает значения в интер вале –1 ≤ r ≤ 1, то есть при r > 0 – положительная корреляция, при r = 0 – нет корреляции, при r < 0 – отрицательная корреляция.

Для тех же n пар данных (x1, y1), (x2, y2), …, (xn, yn) можно ус тановить зависимость между x и y. Формула, выражающая эту зависимость, называется уравнением регрессии (или линией рег рессии), и ее представляют в общем виде функцией

у = а + bх.

Для определения линии регрессии (рис.4.19) необходимо ста тистически оценить коэффициент регрессии b и постоянную a. Для этого должны быть выполнены следующие условия:

1)линия регрессии должна проходить через точки (x,y) сред них значений x и y;

2)сумма квадратов отклонений от линии регрессии значе ний y по всем точкам должна быть наименьшей;

3)для расчета коэффициентов а и b используются формулы

	n		n	n	n
a =	∑y1	∑xi2 − ∑xi ∑xi yi
i−1	i−1	i−1	i−1	,
	n	n
		n∑xi2 − (∑xi )2
			i−1	i−1
		n		n	n
b =	n∑xi yi − ∑xi	∑yi	.
i−1	i−1	i−1

			n	n
		n∑xi2 − (∑xi )2
			i−1	i−1

то есть уравнением регрессии можно аппроксимировать ре альные данные.

Рис. 4.19. Пример линии регрессии

7. Контрольная карта.

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

Рис. 4.20. Пример контрольной карты

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

ВКГ = + 3δ, НКГ = – 3δ,

	1	n
δ =	∑(xi −		)2 .
x
n
	i=1

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

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

Контрольной картой можно также подтвердить улучшение процесса.

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

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

Информация о контрольных картах содержится и в междуна родных стандартах ИСО 7870, ИСО 8258.

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

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

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

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

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

Таким образом, целями применения контрольных карт могут быть: выявление неуправляемого процесса; контроль за управля емым процессом; оценивание возможностей процесса.

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

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

Необходимо иметь в виду, что процесс может быть в состоя нии статистического регулирования и давать 100% брака. И на оборот, может быть неуправляемым и давать продукцию, на 100% отвечающую техническим требованиям.

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

Существуют следующие виды контрольных карт:

1. Контрольные карты для регулирования по количествен ным признакам (измеренные величины выражаются количест венными значениями):

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

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

2. Контрольные карты для регулирования по качественным признакам:

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

б) контрольная карта pn (количество брака), применяется в случаях, когда контролируемым параметром является число де фектных изделий при постоянном объеме выборки n. Практичес ки совпадает с картой p;

в) контрольная карта c (число дефектов на одно изделие), ис пользуется, когда контролируется число дефектов, обнаруживае мых среди постоянных объемов продукции (автомобили – одна или 5 транспортных единиц, листовая сталь – один или 10 листов);

г) контрольная карта n (число дефектов на единицу площа ди), используется, когда площадь, длина, масса, объем, сорт не постоянны и обращаться с выборкой как с постоянным объемом невозможно.

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

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

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

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

Основными принципами применения ФСА являются:

1)функциональный подход к объекту исследования;

2)системный подход к анализу объекта и выполняемых им функций;

3)исследование функций объекта и их материальных носи телей на всех стадиях жизненного цикла изделия;

4)соответствие качества и полезности функций продукции затратам на них;

5)коллективное творчество.

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

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

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

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

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

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

Цель функционально стоимостного анализа заключается в раз витии полезных функций объекта при оптимальном соотношении между их значимостью для потребителя и затратами на их осуще ствление, то есть в выборе наиболее благоприятного для потребите ля и производителя, если речь идет о производстве продукции, ва рианта решения задачи о качестве продукции и ее стоимости. Мате матически цель ФСА можно записать следующим образом:

ПС

______ = max, где

ПС – потребительная стоимость анализируемого объекта, вы раженная совокупностью его потребительных свойств (ПС = Σnci); З – издержки на достижение необходимых потребительных

свойств.

Источник

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

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

Признание своих ошибок — шаг к саморазвитию, на пути к нему вам также поможет наш бесплатный личный план.

Скачайте бесплатный PDF-план «Английский для саморазвития»

Скоро на имейл вам придет письмо с инструкцией. А пока запишитесь на бесплатное онлайн-занятие с преподавателем и получите в подарок еще 2 урока.

Скоро на имейл вам придет письмо с инструкцией. А в течение часа мы позвоним и подберем удобное время занятия. Продуктивного дня 🙂

Ой, произошла ошибка обработки. Попробуйте еще раз чуть позднее.

Ой, произошла ошибка обработки. Скорее всего, такой имейл или телефон уже зарегистрирован.

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

What was I trying to do initially? — Что я изначально пытался сделать?
What went wrong? — Что пошло не так?
When did it go wrong? — Когда все пошло не так?
Why did it go wrong? — Почему все пошло не так?

Why did I set this goal in the first place? — Почему я вообще поставил эту цель?
Did I dedicate enough time to making that goal happen? — Уделял ли я этой цели достаточно времени?
Did I set smaller goals to help make my big goal seem more realistic? — Ставил ли я маленькие цели, которые бы помогли сделать достижение большой цели более реалистичным?
What things, either in or outside of my control, got in my way? — Какие вещи, находящиеся вне моего контроля или подконтрольные мне, помешали мне достичь цели?

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

How will I prevent the same failure in the future? — Как я предотвращу такой же провал в будущем?
What did I learn about myself during this experience? — Что я узнал о себе во время этого опыта?
What are 3 key takeaways from this failure? — Какие 3 ключевых урока я вынесу из этого провала?

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

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

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

Подумать, чему провал меня научил. Важно уделять внимание своему самочувствию, потому что оно напрямую влияет на продуктивность. И еще правильно формулировать цель и делить ее на промежуточные подцели.

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

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

Факап найт — популярный формат среди предпринимателей, которые уверены, что нужно обязательно несколько раз как следует провалиться, прежде чем у вас получится построить успешный бизнес. Соберите друзей или коллег, подготовьте презентацию с главными провалами 2021 года и расскажите о них с выводами в конце и (желательно) с шуточками. На таких мероприятиях всегда душевная атмосфера, ведь провалы объединяют больше, чем успехи и достижения. Здорово узнать, что мы все не идеальны и порой ошибаемся.

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

Книга «Почему» научит правильно анализировать данные и определять причинно-следственные связи там, где они есть. Делимся интересными мыслями из нее.

Восприятие и умозаключения

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

Мы получаем знания о причинах двумя основными путями:

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

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

Доверие к причинному восприятию может нас подвести. Источник

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

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

Время

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

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

Причинная зависимость не всегда может быть оправдана. Источник

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

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

Корреляция

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

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

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

Корреляция не обязательно означает причинную зависимость. Источник

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

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

Без вариации нет корреляции

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

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

Без вариации нет корреляции. Источник

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

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

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

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

Ошибка отбора

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

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

Данные отбора должны быть репрезентативными. Источник

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

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

Предвзятость подтверждения

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

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

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

Предвзятость подтверждения. Источник

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

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

По материалам книги «Почему».
Обложка поста отсюда.

Как сделать анализ ошибок, чтобы сделать все ваши модели лучше

Перевод

Ссылка на автора

От Pexel s

Введение

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

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

Анализ ошибок

Что это такое?

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

https://imgs.xkcd.com/comics/machine_learning.png

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

Правильный способ сделать анализ ошибок

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

Процесс анализа ошибок

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

Ошибки уровня данных

Это тип анализа ошибок, который, вероятно, является наиболее распространенным, и большинство людей делают. Я хотел бы начать с рассмотрения ошибок модели в масштабе всех данных.

Чрезмерная фитинг / Под облегать

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

Кривая обучения от Scikit-Learn

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

Потенциальные исправления:

Если переопределение, то регуляризация L1 или L2 или больше данных
Если подгонка, то более сложная модель или больше функций

Распределение прогноза

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

Потенциальные исправления:

Удаление выбросов из данных
Использование другой функции стоимости

Ошибки уровня группы

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

За / Под Предсказаниями

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

Потенциальные исправления:

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

Большие средние ошибки

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

Потенциальные исправления:

К-стратифицированная перекрестная проверка для обеспечения групповых наблюдений в каждом расколе
Методы передискретизации при отсутствии данных
Сбор данных — это отсутствие данных

Индивидуальные ошибки

Теперь мы приступаем к мельчайшим деталям. Как только мы выполнили весь анализ ошибок более высокого уровня, пришло время погрузиться в ошибки каждого наблюдения. Мне нравится делать это, просматривая 20 лучших ошибок из моих прогнозов. В отличие от анализов более высокого уровня, у меня нет предложений по типичным ошибкам, которые вы можете найти. Вы должны пройти наблюдения и посмотреть на данные и прогноз и определить, был ли прогноз действительным. Иногда модель делала хороший прогноз, и цель этого наблюдения была просто шаткой. Это ошибки, с которыми мы можем жить. Если вы не думаете, что наблюдение кажется разумным, спросите себя, почему. Какую информацию упустила модель, которая должна была помочь ей сделать лучший прогноз? Пройдите несколько наблюдений в поисках закономерностей того, что может быть причиной ошибок. Вы можете найти что-то, что вы пропустили, прежде чем вы могли бы исправить. Вы можете обнаружить, что иногда ваша модель просто портится, и нет никаких причин, чтобы вы могли это увидеть. С этого момента вы либо продолжаете настраивать свою модель, решаете получить больше данных или считаете свою модель хорошей.

Реализуйте это

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

Найти ошибки
Создайте гипотезу о том, что может исправить ошибки
Проверка гипотезы
Повторение

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

Если у вас есть какие-либо вопросы о том, как сделать эффективный анализ ошибок, оставьте мне комментарий ниже, и я отвечу!

Источник

Текст работы размещён без изображений и формул.
Полная версия работы доступна во вкладке «Файлы работы» в формате PDF

Информационной системой считается инфраструктура предприятия, которая задействована в управлении информационными и документальными потоками, которые поступают в предприятие.[1]

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

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

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

Данные системы включают в себя некоторые подсистемы, которые работают в едином информационном пространстве и поддерживают соответствующие направления деятельности.[5, 29с]

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

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

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

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

Сбор информации представляет собой процесс исследования накоплений и записей, которые сформированы программным продуктом для их последующего анализа

Выделяется два вида сбора: активный и пассивный.

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

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

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

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

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

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

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

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

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

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

Алгоритм анализа ошибок условно состоит из четырёх этапов и выглядит таким образом:

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

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

Третий этап представляет собой передачу консолидированной информации, которая получается в результате анализа данных о рабочей станции, программном обеспечении, ошибке и отчёте пользователя, на рассмотрение администратора.[3]

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

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

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

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

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

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

Список литературы

Верников, Г.Г. Корпоративные информационные системы: не повторяйте пройденных ошибок [Электронный ресурс] : URL : https://www.klerk.ru/soft/articles/3011/ (Дата обращения: 10.01.2021).

Кошкарова, А.А. Анализ корпоративных информационных систем / А. А. Кошкарова, А. Ж. Амиров, С. Н. Попов. — Текст : непосредственный // Молодой ученый. — 2016. — № 9 (113). — С. 63-66. — [Электронный ресурс] : URL : https://moluch.ru/archive/113/29461/ (Дата обращения: 10.01.2021).

Крайнов, А.Ю., Смагин, А. А. Разработка комплекса анализа ошибок в корпоративных информационных системах [Электронный ресурс] : URL : https://www.bestreferat.ru/referat-413488.html (Дата обращения: 10.01.2021).

Медведенко, С.А. Анализ корпоративных информационных систем [Электронный ресурс] : URL : https://revolution.allbest.ru/management/00480529_0.html (Дата обращения: 10.01.2021).

Федорова, Г.Н. Информационные системы, Учебник, Москва, Издательский центр «Академия», 2013.-199с.

Яковлев, В.П. Основы корпоративных информационных систем, учебное пособие, Санкт-Петербург, 2016. -84с.

Источник

Какие существуют методы анализа и локализации ошибки

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

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

Существует три основных способа тестирования:

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

Функциональное или аналитическое тестирование

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

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

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

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

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

Тест граничных значений

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

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

Локализация ошибок

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

Процесс локализации ошибок состоит из следующих трех компонент:

Получение на машине тестовых результатов.

Анализ тестовых результатов и сверка их с эталонными.

Выявление ошибки или формулировка предположения о характере и месте ошибки в программе.

Технология отладки автоматизированного рабочего места

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

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

1) Отладка программы производилась следующим образом:

2) Запуск программы с набором тестовых входных данных и выявление наличия ошибок.

3) Выделение области программы, в которой может находиться ошибка.

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

Новая прогонка программы. Если работа программы прервалась до обработки контрольной точки, значит, ошибка произошла раньше. Контрольная точка переносится, и процесс отладки возвращается к шагу 2.

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

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

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

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

7. Локализация ошибок

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

Процесс локализации ошибок состоит из следующих трех компонент:

1. Получение на машине тестовых результатов.

2. Анализ тестовых результатов и сверка их с эталонными.

3. Выявление ошибки или формулировка предположения о характере и месте ошибки в программе.

По принципам работы средства локализации разделяются на 4 типа :

1. Аварийная печать.

2. Печать в узлах.

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

ПЕЧАТЬ В УЗЛАХ включается в работу в выбранных программистом местах программы; после осуществления печати значений данных переменных продолжается выполнение отлаживаемой программы.

СЛЕЖЕНИЕ производится или по всей программе, или на заданном программистом участке. Причем слежение может осуществляться как за переменными (арифметическое слежение), так и за операторами (логическое слежение). Если обнаруживается, что происходит присваивание заданной переменной или выполнение оператора с заданной меткой, то производится печать имени переменной или метки и выполнение программы продолжается. Отличием от печати в узлах является то, что место печати может точно и не определяться программистом (для арифметического слежения); отличается также и содержание печати.

ПРОКРУТКА производится на заданных участках программы, и после выполнения каждого оператора заданного типа (например, присваивания или помеченного) происходит отладочная печать.

По типам печатаемых значений (числовые и текстовые или меточные) средства разделяются на арифметические и логические.

7.2. Классификация средств локализации ошибок

Ниже дана классификация средств локализации.

ТИПЫ СРЕДСТВ ЛОКАЛИЗАЦИИ ОШИБОК :

СРЕДСТВА ЛОКАЛИЗАЦИИ:

1. Аварийная печать (арифметическая).

1.1. Специальные средства языка.

1.2. Системные средства.

2. Печать в узлах (арифметическая).

2.1. Обычные средства языка.

2.2. Специальные средства языка.

3. Слежение (специальные средства).

4. Прокрутка (специальные средства).

8. Технология отладки программы автоматизации учета движения товаров на складе малого предприятия

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

1. Просмотр текста программы и прокрутка с целью обнаружения явных синтаксических и логических ошибок.

2. Трансляция программы (транслятор выдает сообщения об обнаруженных им ошибках в тексте программы).

3. Тестирование. Тестирование проводилось посредством ввода исходных данных, с дальнейшей их обработкой, выводом результатов на печать и экран. Результаты работы программы сравнивались заданными в техническом задании.

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

Отладка программы производилась по следующему алгоритму :

1. Прогонка программы с набором тестовых входных данных и выявление наличия ошибок.

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

3. Новая прогонка программы. Если работа программы прервалась до обработки контрольной точки, значит, ошибка произошла раньше. Контрольная точка переносится, и процесс отладки возвращается к шагу 2.

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

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

В качестве тестовых входных данных использовалась последовательность частотных выборок, генерируемых имитатором в режиме 1. (Каждому интервалу соответствует фиксированное значение выборок.)

Итоговый тест по дисциплине «Поддержка и тестирование программных модулей»

Является ли программа аналогом математической формулы?

Варианты ответов

Да
Нет
Математические формулы и программы не сводятся друг к другу

Вопрос 2

Какие подходы используются для обоснования истинности программ?

Варианты ответов

использование аналогий
эксперимент над программой
доказательство программы
формальный и интерпретационный

Вопрос 3

Отметьте верные утверждения

Варианты ответов

тестирование – процесс поиска ошибок
в фазу тестирования входят поиски и исправление ошибок
отладка – процесс локализации и исправления ошибок

Вопрос 4

Зачем нужна спецификация тестирования?

Варианты ответов

для формирования команды тестировщиков
для разработки тестового набора
для понимания смысла программы

Вопрос 5

Варианты ответов

выполнение программы в уме
пошаговое выполнение
метод контрольных точек и анализа трасс

Вопрос 6

Зачем нужен Log-файл?

Варианты ответов

для изучения результатов тестирования в режиме on-line
для фиксации результатов прогона test-suite
для записи комментариев после прогона тестов

Вопрос 7

Варианты ответов

разработка тестового набора
прогон программы на тестовом наборе
доказательство правильности программы
анализ результатов тестирования

Вопрос 8

Варианты ответов

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

Вопрос 9

Что такое управляющий граф программы (УГП)?

Варианты ответов

множество операторов программы.
граф, вершины которого кодируют операторы программы, а дуги — управления (порядок исполнения) операторов
множество операторов управления

Вопрос 10

Варианты ответов

множество связанных дуг УГП
последовательность вершин и дуг УГП с фиксированными начальной и конечной вершиной
последовательность ветвей УГП с фиксированными начальной вершиной первой ветви и конечной вершиной последней ветви пути

Вопрос 11

Варианты ответов

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

Вопрос 12

Возможно ли тестирование программы на всех допустимых значениях параметров?

Варианты ответов

да, всегда
никогда
возможно в отдельных случаях

Вопрос 13

Какие предъявляются требования к идеальному критерию тестирования?

Варианты ответов

достаточность
достижимость
полнота
проверяемость

Вопрос 14

Какие классы критериев тестируемости известны

Варианты ответов

структурные критерии
мутационные критерии
функциональные критерии
сценарные критерии
стохастические критерии

Вопрос 15

Варианты ответов

сценарный критерий
такого критерия не существует
критерий «черного ящика»

Вопрос 16

Варианты ответов

критерий тестирования команд
критерий тестирования ветвей
критерий тестирования циклов
критерий тестирования путей

Вопрос 17

Варианты ответов

не проверяется соответствие со спецификацией
не проверяется соответствие со спецификацией, не зафиксированное в структуре программы
не проверяются ошибки в структурах данных

Вопрос 18

Варианты ответов

тестирование пунктов спецификации
тестирование классов входных данных
тестирование классов выходных данных
тестирование функций
тестирование правил

Вопрос 19

Варианты ответов

не проверяется соответствие со спецификацией
не проверяются ошибки, требования к которым не зафиксированы в спецификации
не проверяются ошибки в структурах данных, требования к которым не зафиксированы в спецификации

Вопрос 20

Варианты ответов

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

Вопрос 21

Варианты ответов

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

Вопрос 22

Какие существуют разновидности уровней тестирования?

Варианты ответов

модульное
интеграционное
структурное
системное
регрессионное

Вопрос 23

Какие задачи у модульного тестирования?

Варианты ответов

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

Вопрос 24

На основе каких принципов строятся тесты для модульного тестирования?

Варианты ответов

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

Вопрос 25

Варианты ответов

построение УГП (управляющего графа программы)
выбор тестовых путей
генерация тестов, соответствующих выбранным тестовым путям

Вопрос 26

Варианты ответов

статические
динамические
методы реализуемых путей

Вопрос 27

Варианты ответов

Регрессионное тестирование
монолитное тестирование
нисходящее тестирование
восходящее тестирование

Вопрос 28

Варианты ответов

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

Вопрос 29

Варианты ответов

тесты оперируют пользовательским или другими внешними интерфейсами
структура проекта тестируется на уровне подсистем
тестированию подлежит система в целом
тестирование осуществляется по методу «черного ящика»

Вопрос 30

Варианты ответов

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

Вопрос 31

Варианты ответов

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

Вопрос 32

Какие типы дефектов выявляются при системном и регрессионном тестировании

Программные ошибки. Методы отладки

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

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

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

Локализация — это определение оператора/операторов программы, выполнение которого вызвало нарушение вычислительного процесса.

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

В соответствии с этапом обработки, на котором появляются ошибки, различают ошибки компиляции, ошибки компоновки, ошибки выполнения (рис. 5.1) [7].

Рис. 5.1. Группы программных ошибок

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

Ошибки компоновки — ошибки, обнаруженные компоновщиком (редактором связей) при объединении модулей программы. Ошибки компоновки связаны с проблемами, обнаруженными при разрешении внешних ссылок. Например, предусмотрено обращение к подпрограмме другого модуля, а при объединении модулей данная подпрограмма не найдена или не стыкуются списки параметров.

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

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

Причины ошибок выполнения очень разнообразны, а потому их

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

• ошибки определения данных;
• логические ошибки;
• ошибки накопления погрешностей.

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

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

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

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

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

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

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

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

Методы отладки программного обеспечения можно классифицировать следующим образом [7]:

• метод ручного тестирования;
• метод индукции;
• метод дедукции;
• метод обратного прослеживания.

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

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

Метод дедукции работает по следующему алгоритму. Сначала формируют множество причин, которые могли бы вызвать данное проявление ошибки. Затем, анализируя причины, исключают те, которые противоречат имеющимся данным. Если все причины исключены, то необходима дополнительная информация об ошибке и следует выполнить дополнительное тестирование исследуемого фрагмента. В противном случае наиболее вероятную гипотезу пытаются доказать. Если гипотеза объясняет полученные признаки ошибки, то ошибка найдена, иначе — проверяют следующую причину.

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

Рассмотрим категории программных ошибок, которые встречаются наиболее часто.

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

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

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

Некорректная обработка ошибок. Правильно определив ошибку, программа должна выдать о ней сообщение. Отсутствие такого сообщения является ошибкой в работе программы.

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

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

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

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

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

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

Источник

КУРСОВАЯ РАБОТА

По дисциплине «Бухгалтерская финансовая отчетность»

студентки 12 группы

на тему «Влияние ошибок на бухгалтерскую отчетность и порядок их исправления»

Направление подготовки 080100 – ЭКОНОМИКА

Профиль 4 — Бухгалтерский учет, анализ и аудит

Научный руководитель

Санкт-Петербург 2015 год

Оглавление

ВВЕДЕНИЕ…………………………………………………………………………………………………………….. 3

НОРМАТИВНО-ПРАВОВОЕ РЕГУЛИРОВАНИЕ ПОРЯДКА ИСПРАВЛЕНИЯ ОШИБОК В БУХГАЛТЕРСКОМ УЧЕТЕ И ОТЧЕТНОСТИ……………………………………………………………………. 5

1.1 Понятие ошибок и их классификация…………………………………………………………………………….. 5

1.2 Причины возникновения ошибок и методы их выявления………………………………… 9

1.3 Нормативное регулирование исправления ошибок и ответственность за нарушение правил ведения учета………………………………………………………………………………………………………………………………… 13

ВЛИЯНИЕ ОШИБОК НА ФОРМИРОВАНИЕ ОТЧЕТНОСТИ И СПОСОБЫ ИХ ИСПРАВЛЕНИЯ………………………………………………………………………………………………………………………………………. 18

2.1 Влияние ошибок на бухгалтерскую отчетность и способы исправления допущенных ошибок в учетных регистрах…………………………………………………………………………………………………………………. 18

2.2 Способы исправления ошибок в бухгалтерской отчетности…………………………… 23

ЗАКЛЮЧЕНИЕ……………………………………………………………………………………………………. 28

БИБЛИОГРАФИЧЕСКИЙ СПИСОК…………………………………………………………………….. 30

ВВЕДЕНИЕ

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

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

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

Согласно Положению по бухгалтерскому учету “Бухгалтерская отчетность организации” (ПБУ 4/99) бухгалтерская отчетность должна отвечать критериям достоверности и полноты. Для обеспечения данных требований она не должна содержать ошибок как при ведении бухгалтерского учета в течении отчетного года, так и при составлении отчетности.

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

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

Объектом данной работы является бухгалтерская отчетность в РФ. Данной проблемой занималось множество заслуженных деятелей РФ в экономической области. Это, конечно, Соколов Я. В., написавший книгу Бухгалтерская (финансовая) отчетность», Шеремет А. Д. «Бухгалтерский учет и анализ».

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

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

1. НОРМАТИВНО-ПРАВОВОЕ РЕГУЛИРОВАНИЕ ПОРЯДКА ИСПРАВЛЕНИЯ ОШИБОК В БУХГАЛТЕРСКОМ УЧЕТЕ И ОТЧЕТНОСТИ

1.1 Понятие ошибок и их классификация

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

В соответствии с ПБУ 22/2010 «Исправление ошибок в бухгалтерском учете и отчетности» ошибкой является неправильное отражение или неотражение фактов хозяйственной деятельности в бухгалтерском учете или бухгалтерской отчетности организации. Налоговый Кодекс РФ в статье 81 главы 13 «Внесение изменений в налоговую декларацию» определяет ошибку как неотражение или неполное отражение факта хозяйственной жизни.

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

Классифицировать виды бухгалтерских ошибок можно по нескольким признакам.

В соответствии с ПБУ 22/2010 ошибки бывают:

Существенные
Несущественные

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

Является ошибка существенной или нет согласно п. 3 ПБУ 22/2010 каждая организация определяет самостоятельно. Критериями являются их величина и соотношение со соответствующей статьей бухгалтерской отчетности. Уровень существенности может быть выражен в абсолютном или относительном выражении. Уровень существенности ошибки прописывается в учетной политике.

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

Организация может ориентироваться на Кодекс об административных правонарушениях РФ. В статье 15.11 «Грубое нарушение правил ведения бухгалтерского учета и представления бухгалтерской отчетности» указано, что ошибка является грубой, если она искажает статью в отчетности более чем на 10% и занижает налоговую базу не менее чем на 10%.

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

Существуют и другие классификации допущенных ошибок.

Е.Н. Домбровская в своей книге «Бухгалтерская (финансовая) отчетность» разделяет ошибки по характеру возникновения:

Преднамеренные
Непреднамеренные

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

В книге «Бухгалтерская (финансовая) отчетность» доктор экономических наук Соколов Я. В. определил три вида искажений бухгалтерской отчетности:

Бухгалтерская отчетность была фальсифицирована, если она объективно отражает финансовое положение организации, но не отвечает требованиям нормативно-правовых актов;
Бухгалтерская отчетность была вуалирована, если она необъективно отражает финансовое положение организации, но отвечает требованиям нормативных документов;

О фактах неприменения правил бухгалтерского учета организация должна сообщать в пояснительной записке к отчетности с соответствующим объяснением.[3]

Бухгалтерская отчетность была вуалирована и фальсифицирована, если она необъективно отражает финансовое состояние компании и не отвечает требованиям нормативных и правовых документов.

Четвертую группу ошибок можно классифицировать по характеру неточности.

Арифметические ошибки
Методологические ошибки

Методологические ошибки появляются вследствие неправильного применения правил ведения бухгалтерского учета.

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

По времени возникновения ошибки делятся на:

Ошибки текущего года

Могут быть выявлены до окончания отчетного года, либо после окончания, но до даты подписания отчетности.

Ошибки прошлых лет

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

Несущественные ошибки, которые были обнаружены после даты подписания бухгалтерской отчетности.
Существенная ошибка, выявленная после даты подписания бухгалтерской отчетности, но до даты представления такой отчетности.

В соответствии с Федеральным Законом от 06.12.11 N 402-ФЗ о бухгалтерском учете обязательный экземпляр составленной годовой бухгалтерской (финансовой) отчетности представляется не позднее трех месяцев после окончания отчетного периода. [4]

Существенная ошибка, выявленная после представления бухгалтерской отчетности, но до даты ее утверждения;
Существенная ошибка, выявленная после утверждения бухгалтерской отчетности;

Для ОАО этим периодом будет являться период после 30 июня года, следующего за отчетным. Для ООО – после 30 апреля года, следующего за отчетным.

Существенная ошибка была допущена до начала самого раннего из представленных в бухгалтерской отчетности за текущий отчетный год предшествующих отчетных периодов.

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

1.2 Причины возникновения ошибок и методы их выявления

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

В соответствии с ПБУ 22/2010 возникновение непреднамеренных ошибок обусловлено:

Неправильным применением законодательства РФ о бухгалтерском учете и (или) нормативных правовых актов по бухгалтерскому учету;

Искажения в бухгалтерской отчетности часто встречаются из-за незнания правил учета. Например, с поставщиком был заключен договор купли-продажи, по которому товары должны оплачиваться после их реализации. В месяце поставки полученные товары не были отражены организацией, хотя по статье 223 п. 1 Гражданского кодекса РФ «Момент возникновения права собственности у приобретателя по договору» право собственности у приобретателя вещи по договору возникает с момента ее передачи, если иное не предусмотрено законом или договором.[5]

Неправильным применением учетной политики организации;

В качестве примера можно привести выбор ФИФО в качестве метода оценки материально-производственных запасов при их выбытии, если в учетной политике прописан метод по средней себестоимости.

Неточностями в вычислениях;

Арифметические ошибки, счетные, а также ошибки округления.

Неправильной классификацией или оценкой фактов хозяйственной деятельности;

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

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

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

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

Наиболее эффективным методом выявления искажений является инвентаризация.

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

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

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

Еще один способ выявления ошибок – сверка выборочных показателей бухгалтерской отчетности с другими.

Приведем несколько примеров:

Разница между предшествующим и отчетным годом в строке 1180 «Отложенные налоговые активы» баланса должна быть равна строке «Изменения отложенных налоговых активов» отчета о финансовых результатах;
Разница между предшествующим и отчетным годом в строке 1370 «Нераспределенная прибыль (непокрытый убыток)» баланса должна быть равна строке 2400 «Чистая прибыль (убыток)» отчета о финансовых результатах;
В налоговой декларации строка 010 Листа 02 «Доходы от реализации» должна быть равна строке 2110 «Выручка» Отчета о финансовых результатах;
В налоговой декларации строка 030 Листа 02 «Расходы, уменьшающие сумму доходов от реализации» должна состоять из суммы строк отчета о финансовых результатах: 2120 «Себестоимость продаж», 2210 «Коммерческие расходы», 2220 «Управленческие расходы».

Также, к приведенным методам обнаружения ошибок следует добавить мнение независимых аудиторов и специалистов. Ежегодная аудиторская проверка является требованием налоговых органов, обязательным для многих организаций. В соответствии с Федеральным законом от 30.12.2008 N 307-ФЗ «Об аудиторской деятельности» обязательный аудит отчетности производится в следующих случаях:

Организационно-правовой формой организации является акционерное общество;
Ценные бумаги организации обращаются на организованных торгах;
Если организация является кредитной организацией, бюро кредитных историй, организацией, являющейся профессиональным участником рынка ценных бумаг, страховой организацией, клиринговой организацией, обществом взаимного страхования, организатором торговли, негосударственным пенсионным или иным фондом, акционерным инвестиционным фондом, управляющей компанией акционерного инвестиционного фонда, паевого инвестиционного фонда или негосударственного пенсионного фонда (за исключением государственных внебюджетных фондов);[7]
Объем выручки за предшествующий год превышает 400 миллионов рублей, а сумма активов превышает 60 миллионов рублей. Под данное правило не попадают государственные и муниципальные учреждения;
Организация предоставляет и (или) публикует консолидированную бухгалтерскую отчетность.

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

1.3 Нормативное регулирование исправления ошибок и ответственность за нарушение правил ведения учета

Основным стандартом, регулирующим порядок исправления ошибок в бухгалтерском учете и отчетности, является ПБУ 22/2010. Данный документ регулирует правила исправления ошибок и порядок раскрытия информации об этих ошибках.

Штрафы и санкции при неисправлении ошибок регулируют кодекс об административных правонарушениях и налоговый кодекс.

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

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

искажение сумм начисленных налогов и сборов не менее чем на 10 процентов;
искажение любой статьи (строки) формы бухгалтерской отчетности не менее чем на 10 процентов.

Проверяющие органы для подтверждения достоверности отчетности могут затребовать:

заключение аудиторов;
договоры;
первичные документы;
счета-фактуры.

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

если нарушения совершены в течение одного налогового периода — взыскание штрафа в размере 10 тыс. руб.;
если нарушения совершены в течение более одного налогового периода — штраф в размере 30 тыс. руб.;
если нарушения повлекли занижение налоговой базы — штраф в размере 20% суммы неуплаченного налога, но не менее 40 тыс. руб.

Под грубым нарушением правил учета доходов и расходов и объектов налогообложения понимается:

отсутствие первичных документов;
отсутствие счетов — фактур;
отсутствие регистров бухгалтерского или налогового учета;
систематическое (два раза и более в течение календарного года) несвоевременное или неправильное отражение на счетах бухгалтерского учета, в регистрах налогового учета и в отчетности хозяйственных операций, денежных средств, материальных ценностей, нематериальных активов и финансовых вложений. Под систематическим нарушением понимается нарушение, совершенное в течение календарного года два раза и более.[8]

Санкции за неуплату или недоплату налога предусмотрены статьей 122 Налогового кодекса РФ.

По данной статье штраф составляет 20% от суммы недоимки. Также налоговым инспектором может быть установлено, что налог был не уплачен умышленно. В этом случае штраф составит 40% от неуплаченной суммы.

Кроме того, к сумме недоимки и штрафу за каждый календарный день просрочки организации придется заплатить пени. Они составляют 1/300 ставки рефинансирования ЦБ РФ.

Если имеется переплата по налогу, то согласно статье 78 НК РФ предприятие может:

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

Если организация намеренно уклоняется от уплаты налогов и сборов, то в данном случае может возникнуть не только административная, но и уголовная ответственность. В соответствии со статьей 199 Уголовного кодекса РФ уклонение от уплаты налогов и сборов путем непредставления налоговой декларации или иных документов, представление которых в соответствии с законодательством Российской Федерации о налогах и сборах является обязательным, либо путем включения в налоговую декларацию или такие документы заведомо ложных сведений, совершенное в крупном размере наказывается: штрафом в размере от ста тысяч до трехсот тысяч рублей или в размере заработной платы или иного дохода осужденного за период от одного года до двух лет, либо арестом на срок до шести месяцев, либо лишением свободы на срок до двух лет с лишением права занимать определенные должности или заниматься определенной деятельностью на срок до трех лет или без такового.[9]

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

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

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

Порядок проведения аудиторской проверки регулируется Федеральным законом от 30.12.2008 N 307-ФЗ «Об аудиторской деятельности». Итогом деятельности аудитора является аудиторское заключение, которое подтверждает или не подтверждает достоверность отчетности. Однако на практике налоговые органы часто доначисляют налоги не зависимо от результатов аудиторской проверки. Организация после обнаружения нарушений налоговыми органами оставляет за собой право доказать достоверность отчетности в суде.

2. ВЛИЯНИЕ ОШИБОК НА ФОРМИРОВАНИЕ ОТЧЕТНОСТИ И СПОСОБЫ ИХ ИСПРАВЛЕНИЯ

2.1 Влияние ошибок на бухгалтерскую отчетность и способы исправления допущенных ошибок в учетных регистрах

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

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

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

Рассмотрим влияние основных видов ошибок на содержание отчетных форм.

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

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

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

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

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

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

Корректурный способ исправления ошибок.

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

Сторнирование бухгалтерских записей (способ сторно).

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

Например: на расчетный счет поступил платеж от покупателя на сумму 100 руб.

По этой операции была составлена проводка:

Д 51 К 60 – 100

В данной проводке был неправильно указан корреспондирующий счет. Вместо счета 60 «Расчеты с поставщиками и подрядчиками» должен быть указан счет 62 «Расчеты с поставщиками и подрядчиками».

Для исправления ошибки составляют такую же проводку, но красными чернилами, либо со знаком «минус».

Д 51 К 60 – -100

Затем составляют правильную проводку:

Поступили денежные средства на расчетный счет от покупателя:

Д 51 К 62 — 100

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

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

Д 20 К 70 – -1000

Д 50 К 70 – 1000

Затем составляется бухгалтерская справка, подтверждающая данные операции. Пример заполнения бухгалтерской справки представлен в приложении на Рисунке 1.

Способ дополнительной проводки.

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

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

Например: Поступили материалы от поставщика на сумму 200 руб.

Д 10 К 60 – 100

Для исправления ошибки составляют дополнительную проводку на сумму разницы 200 – 100 = 100 руб.

Д 10 К 60 – 100

Для данного метода также необходимо составить бухгалтерскую справку на сумму дополнительной проводки.

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

Например, бухгалтером были ошибочно списаны материалы на нужды основного производства на счет 23 «Вспомогательное производство»:

Д 23 К 10 – 1000

Для исправления неправильной корреспонденции счетов была составлена обратная проводка и сделана правильная запись:

Д 10 К 23 – 1000

Д 20 К 10 – 1000

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

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

2.2 Способы исправления ошибок в бухгалтерской отчетности

Порядок исправления ошибок после окончания отчетного года отражен в ПБУ 22/2010 «Исправление ошибок в бухгалтерском учете и отчетности». В соответствии с данным положением выявленные ошибки и их последствия подлежат обязательному исправлению.[10] Порядок исправления ошибок и их влияние на текущий период зависит от времени их обнаружения. Поэтому целесообразно разделить ошибки на:

Ошибки прошлого года, выявленные до даты подписания годовой отчетности за прошлый год;

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

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

Несущественные ошибки, выявленные после даты подписания бухгалтерской отчетности;

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

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

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

Существенные ошибки, выявленные после 31 марта, но до даты утверждения отчетности;

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

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

Например, встречаются ситуации, когда отчетность должна быть предоставлена налоговым органам и органам статистики, но фактически она еще не утверждена и не проверена аудиторами. Законом об акционерных обществах предусмотрено, что годовое общее собрание акционеров проводится в сроки, устанавливаемые уставом общества, но не ранее чем через 2 и не позднее чем через 6 месяцев после окончания финансового года. Таким образом, годовое общее собрание акционеров может быть проведено в период с 1 марта и по 30 июня года, следующего за отчетным.[11] Предположим, что общее собрание акционеров было назначено на 20 апреля. 15 мая была проедена аудиторская проверка в ходе которой были обнаружены существенные ошибки и были исправлены с помощью дополнительных записей за декабрь отчетного года. По результатам аудиторской проверки была составлена пересмотренная бухгалтерская отчетность и она была отправлена в налоговые органы.

Существенные ошибки, выявленные после утверждения бухгалтерской отчетности;

Если бухгалтерская отчетность была подтверждена и сдана в налоговые органы и органы статистики, то исправление таких ошибок происходит в отчетном периоде с использованием счета 84 «Нераспределенная прибыль (непокрытый убыток)».

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

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

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

Существует три варианта уточнений, которые вносятся в налоговые декларации:

Уменьшающие налоговую базу и сумму налоговых обязательств перед бюджетом;

Например, если в первоначальной декларации по налогу на имущество среднегодовая стоимость имущества, облагаемого налогом, была завышена;

Увеличивающие налоговую базу и сумму налоговых обязательств перед бюджетом;

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

Не затрагивающие налоговую базу и сумму налоговых обязательств перед бюджетом;

Например, если уточняются показатели, отраженные в справочных разделах.

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

Существенные ошибки, допущенные до начала самого раннего из представленных в бухгалтерской отчетности за текущий отчетный год предшествующих отчетных периодов.

В этом случае нужно скорректировать вступительные сальдо по соответствующим статьям отчетности на начало самого раннего из представленных отчетных периодов с использованием корреспондирующего счета 84 «Нераспределенная прибыль (непокрытый убыток)».

В отчетности корректировке подлежат вступительные сальдо по статьям активов, обязательств и капитала. Например, если ошибка была допущена в 2010 году, а обнаружена в 2013 году, то необходимо пересчитать вступительное сальдо на начало 2011 года, 2012 года и 2013 года. Сведения о пересчитанных суммах необходимо отразить в пояснительной записке к отчетности за 2013 год.

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

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

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

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

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

Налоговый кодекс РФ. Российской Федерации, часть первая: федеральный закон РФ от 31 июля 1998 г. № 146 — ФЗ .// СПС Консультант;
Гражданский кодекс Российской Федерации, часть первая: федеральный закон РФ от 30 ноября 1994 г. № 51 — ФЗ .// СПС Консультант;
Уголовный кодекс РФ Российской Федерации, часть первая: федеральный закон РФ от 13 июня 1996 г. № 63 — ФЗ .// СПС Консультант;
Кодекс Российской Федерации об административных правонарушениях: Федеральный закон от 30.12.2001 г. № 195-ФЗ;
О бухгалтерском учете: Федеральный закон от 6 декабря 2011 г. N 402-ФЗ;
Об аудиторской деятельности: Федеральный закон от 30.12.2008 N 307-ФЗ;
Приказ Минфина РФ от 29.07.1998 N 34н (ред. от 24.12.2010) «Об утверждении Положения по ведению бухгалтерского учета и бухгалтерской отчетности в Российской Федерации»;
Положение по бухгалтерскому учету «Бухгалтерская отчетность организации». ПБУ 4/99, утв. приказом Министерства финансов Российской Федерации от 6.07.99 № 43н;
Положение по бухгалтерскому учету «Учет основных средств». ПБУ 6/01, утв. приказом Министерства финансов Российской Федерации от 30.03.2001 №. 26н;
Положение по бухгалтерскому учету «Доходы организации». ПБУ 9/99, утв. приказом Министерства финансов Российской Федерации от 06.05.99 № 32н;
Положение по бухгалтерскому учету «Расходы организации». ПБУ 10/99, утв. приказом Министерства финансов Российской Федерации от 06.05.99 № 33н;
Положение по бухгалтерскому учету «Исправление ошибок в бухгалтерском учете и отчетности». ПБУ 22/2010, утв. приказом Министерства финансов Российской Федерации от 28.06.2010 N 63н;
Бухгалтерская (финансовая) отчетность организации: Учеб. пос. / под ред. О.А. Заббаровой — М.: ФБК-ПРЕСС, 2009. — 314 с.;
Бухгалтерская (финансовая) отчетность организации: Учеб. пос. / С.В. Уткина — М.: Ай Пи Эр Медиа, 2008. — 280 с.;
Бухгалтерский учет и анализ: Учеб. пос. / под ред. проф. А.Д. Шеремета — М.: ИНФРА -М, 2010. — 618 с.;
Бухгалтерская (финансовая) отчетность: Учеб. пос. / под ред. проф. Я.В. Соколова — М.: Магистр, 2009. — 479 с.;
Бухгалтерская (финансовая) отчетность: Учеб. пос. / Е.Н. Домбровская. — М.: ИНФРА -М, 2012. — 280 с.;
Бухгалтерская (финансовая) отчетность: Учеб. пос. / Е. Н. Домбровская. — М.: ИНФРА -М, 2012. — 199 с.;
Бухгалтерская (финансовая) отчетность: Учеб. пос. / Я. В. Соколов. – М.: Магистр, 2009. – 454 с.;
Дегальцева Ж.В. Исправление ошибок в бухгалтерском финаносовом учете и отчнетности // Научный журнал КубГАУ. – 2013. — №86(02).

[1] Положение по бухгалтерскому учету «Исправление ошибок в бухгалтерском учете и отчетности». ПБУ 22/2010, утв. приказом Министерства финансов Российской Федерации от 28.06.2010 N 63н.

[2] Бухгалтерская (финансовая) отчетность: Учеб. пос. / Е. Н. Домбровская. — М.: ИНФРА -М, 2012. — 199 с.

[3] Бухгалтерская (финансовая) отчетность: Учеб. пос. / Я. В. Соколов. – М.: Магистр, 2009. – 454 с.

[4] О бухгалтерском учете: Федеральный закон от 6 декабря 2011 г. N 402-ФЗ.

[5] Гражданский кодекс РФ. Часть первая.

[6] Приказ Минфина РФ от 29.07.1998 N 34н (ред. от 24.12.2010) «Об утверждении Положения по ведению бухгалтерского учета и бухгалтерской отчетности в Российской Федерации».

[7] Об аудиторской деятельности: Федеральный закон от 30.12.2008 N 307-ФЗ.

[8] Налоговый кодекс РФ. Часть первая.

[9] Уголовный кодекс РФ.

[10] Положение по бухгалтерскому учету «Исправление ошибок в бухгалтерском учете и отчетности». ПБУ 22/2010, утв. приказом Министерства финансов Российской Федерации от 28.06.2010 N 63н

[11] Дегальцева Ж.В. Исправление ошибок в бухгалтерском финаносовом учете и отчнетности // Научный журнал КубГАУ. – 2013. — №86(02). 4 с.

Скачать: kursovaya.rar

Источник

Под организацией проведения тестирования понимается::

– выделение объектов тестирования,

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

– подготовка тестов, их выполнение и поиск разного рода ошибок и дтказов в компонентах и в системе в целом;

– служба проведения и управление процессом тестирования.

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

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

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

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

Классификация ошибок.Международный стандарт ANSI/IEEE–729–83 разделяет все ошибки в разработке программ на следующие

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

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

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

Отказ может быть результатом следующих причин:

– ошибочная спецификация или пропущенное требование, т.е. спецификация точно не отражает того, что предполагал пользователь;

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

– проект программы может содержать ошибки (например, база данных спроектирована без защиты от несанкционированного доступа пользователя, а требуется защита);

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

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

Ошибки на этапах ЖЦ тестирования. Приведенные типы ошибок распределяются я по этапам ЖЦ и им соответствуют такие источники их возникновения:

– непреднамеренное отклонение разработчиков от рабочих стандартов или планов реализации;

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

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

Рассмотрим этапы тестирования, определенные в соотвествии с рекомендациями стандарта ISO/IEC 12207, и приведем типы ошибок, которые обнаруживаются на каждом из них.

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

Характерными ошибками этого этапа являются:

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

– некорректность спецификации взаимодействия ПО со средой функционирования или с пользователями;

– несоответствие требований заказчика к отдельным и общим свойствам ПО;

– некорректность описания функциональных характеристик;

– необеспеченность инструментальными средствами поддержки всех аспектов реализации требований заказчика и др.

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

– определением интерфейса пользователя со средой;

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

– определением процесса обработки информации и взаимодействия между процессами (результат некорректного определения взаимосвязей компонентов и процессов);

– некорректным заданием данных и их структур при описании отдельных компонентов и ПС в целом;

– некорректным описанием алгоритмов модулей;;

– определением условий возникновения возможных ошибок в программе;

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

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

– безконтрольность в допустимости значений входных параметров, индексов массивов, параметров циклов, выходных результатов, деления на 0 и др.;

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

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

– использование одного имени для обозначения разных объектов или разных имен для обозначения одного объекта, плохая мнемоника имен;

– несогласованное внесение изменений в программу разными разработчиками и др.

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

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

Все ошибки, которые возникают в программах, принято подразделять на следующие классы [12, 23]:

– логические и функциональные ошибки;

– ошибки вычислений и времени выполнения;

– ошибки ввода–вывода и манипулирования данными;

– ошибки интерфейсов;

– ошибки объема данных и др.

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

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

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

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

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

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

Анализ типов ошибок в программах является необходимым условием создания планов тестирования и методов тестирования для обеспечения правильности ПО.

На современном этапе развития средств поддержки разработки ПО (CASE–технологии, объектно–ориентированные методы и средства проектирования моделей и программ) проводится такое проектирование, при котором ПО защищается от наиболее типичных ошибок и тем самым предотвращается появление программных дефектов.

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

– идентификация изъянов в технологиях проектирования и программирования;

– взаимосвязь изъянов процесса проектирования и допускаемых человеком ошибок;

– классификация отказов, изъянов и возможных ошибок, а также дефектов на каждом этапе разработки;

– сопоставление ошибок человека, допускаемых на определенном этапе разработки, и дефектов в объекте, как следствий ошибок спецификации проекта, моделей программ и т.д.);

– проверка и защита от ошибок на всех этапах ЖЦ, а также обнаружение дефектов на каждом этапе разработки;

– сопоставление дефектов и отказов в ПО для разработки системы взаимосвязей и методики локализации, сбора и анализа информации об отказах и дефектах;

– разработка подходов к документированию процессов и испытания ПО.

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

Приведем следующую классификацию типов отказов:

– аппаратный, при котором общесистемное ПО не работоспособно;

– информационный, вызванный ошибками во входных данных и передаче данных по каналам связи, сбое устройств ввода (следствие аппаратных отказов);

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

– программный при наличии ошибок в компонентах и др.

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

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

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

Анализ некорректное, пропущенное или неясное требование

требований

некорректный или непонятная трансляция

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

системы

некорректная или неясная спецификация проекта

Проектирование

программ ошибочная интерпретация проекта системы

некорректная документация

Выполнение ошибочная интерпретация проекта системы

программ

некорректный сиснтаксис или семантика

неполные тесты процедур (или с дефектами)

Интеграционное

тестирование новые ошибки в проверенных элементах

Системное

тестирование

некорректные тесты процедур или компонент

некорректная пользовательская документация

Сопровождение слабо отражен человеческий фактор

новые ошибки в старых правильных объектах

измененные требования

Рис. 7.2. Виды ошибок на этапах ЖЦ

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

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

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

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

Фирма IВМразработала подход к классификации ошибок, называемый ортогональной классификацией дефектов [23]. Подход предусматривает разбиение ошибок по категориям с ответственностью разработчиков за них.

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

Ортогональная классификация дефектов IBM Таблица 7.1

Контекст ошибки	Классификация дефектов
Функция	Ошибки интерфейсов конечных пользователей ПО, вызванные аппаратурой или связаны с глобальными структурами данных
Интерфейс	Ошибки во взаимодействии с другими компонентами, в вызовах, макросах, управляющих блоках или в списке параметров
Логика	Ошибки в программной логике, неохваченной валидацией, а также в использовании значений переменных
Присваивание	Ошибки в структуре данных или в инициализации переменных отдельных частей программы
Зацикливание	Ошибки, вызванные ресурсом времени, реальным временем или разделением времени
Среда	Ошибки в репозитории, в управлении изменениями или в контролируемых версиях проекта
Алгоритм	Ошибки, связанные с обеспечением эффективности, корректности алгоритмов или структур данных системы
Документация	Ошибки в записях документов сопровождения или в публикациях

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

Фирма Hewlett–Packard использовала классификацию Буча, установив процентное соотношение ошибок, обнаруживаемых в ПО на разных стадиях разработки (рис. 7.3) [14]. в управлении данными

в коде

11% 6%

в документации

в вычислениях 19%

18%

5% в требованиях

в логике 32 % 5% в аппаратуре

в интеграции

Рис.7.3 Процентное соотношение ошибок при разработке ПО

Методы тестирования ПО МЕТОДЫ ПОИСКА ОШИБОК

Содержание лекции Определимся, кто несет ответственность за качество системы Изучим методы поиска ошибок Задания

Качество vs ответственность От кого зависит качество системы? Кто несет ответственность за качество системы?

Классификация по знанию внутренней системы

Разработка через тестирование

Преимущества 1. Возможность убедиться, что приложение пригодно для тестирования 2. Автоматизированные тесты покрывают все пути исполнения 3. Разработчик продумывает детали интерфейса до реализации 4. Тесты заставляют делать свой код более приспособленным для тестирования 5. Модульное тестирование способствует формированию четких и небольших интерфейсов 6. Несмотря на то, что при разработке через тестирование требуется написать большее количество кода, общее время, затраченное на разработку, обычно оказывается меньше 7. Тесты защищают от ошибок. Поэтому время, затрачиваемое на отладку, снижается многократно 8. Устранение дефектов на более раннем этапе разработки, препятствует появлению хронических и дорогостоящих ошибок, приводящих к длительной и утомительной отладке в дальнейшем 9. Тесты позволяют производить рефакторинг кода без риска его испортить. При внесении изменений в хорошо протестированный код риск появления новых ошибок значительно ниже 10. Уверенность в том, что изменения не нарушит существующую функциональность, придает уверенность разработчикам и увеличивает эффективность их работы 11. Разработка через тестирование способствует более модульному, гибкому и расширяемому коду. 12. Тесты могут использоваться в качестве документации. Хороший код расскажет о том, как он работает, лучше любой документации.

Слабые места 1. 2. 3. 4. 5. 6. 7. Существуют задачи, которые невозможно решить Прохождение функциональных тестов Поддержка от руководства Модульные тесты обычно пишутся теми же, кто пишет тестируемый код Ложное ощущение надежности Тесты сами по себе являются источником накладных расходов Сложно определить покрытие тестами: неудачные архитектура, дизайн или стратегия тестирования приводят к большому количеству непройденных тестов, важно их все исправить в индивидуальном порядке. Простое удаление, отключение или поспешное изменение их может привести к необнаруживаемым пробелам в покрытии тестами.

Разработка тестов МЕТОДЫ ПОИСКА ОШИБОК

Где искать тесты? ● Тщательное изучение и анализ требований (описания функции, модуля, спецификации, и т. д. ). ● Декомпозиция требованийфункций. ● Выявление всех условий, входных и выходных данных (что) ● Анализ поведения (как) ● Использование различных техник для выделения определенных тестов ● Использование накопленных знаний о выполненных проектах (оттестированных продуктах) ● Интуиция ● Анализпросмотр выявленных тестов и добавление новых

Проблемы, которые придется решить ● ● ● Искать все ошибки или грубейшие? Если не все, то как установить порог допустимости ошибки? Когда завершать тестирование? Что делать, если сроки поджимают и/или нет ресурсов на дальнейшее тестирование? Где остановиться в документировании тестов? Изменять тест или следовать первоначальной инструкции?

Классы эквивалентности (partitioning, equivalent analysis) ● Анализируем входные и выходные данные: ○ правильные классы эквивалентности (корректные входные данные) ○ неправильные классы эквивалентности (ошибочные входные данные)

Лучшие представители ● Какие значения тестировать внутри класса эквивалентности? ● Используем предположения: ○ Множество возможных значений непрерывно ○ Значения могут быть спроецированы на числовую ось, мы всегда можем определить, что из двух значений одно больше, а другое меньше или они одинаковы

Разберем пример Программа: INPUT

Выводы: Типы ошибок: ● Программа не принимает числовые значения как факт ○ ● Написали

Анализ граничных значений (Boundary Value Testing) ● Идентифицировать граничные значения для каждого входного значения (класса эквивалентности) ○ на границе ○ значение, меньшее граничного ( «у границы» ’below point’) ○ значение, большее граничного ( «за границей» ’above point’) Примеры: ➢ Область корректных значений: [-1. 0, 1. 0] -> тесты для -1. 0, -1. 001, 1. 001 ➢ Максимальная длина слова – 5 символов — > тесты для 4, 5, 6 ➢ Область выходных значений: минимум расхода 0. 00, максимум 2000 -> подбираем входные данные для того, чтобы получить на выходе 0. 00, 2000. 01, -0. 01

В задаче: INPUT

Граничные значения Для точки: Z -> Z-1, Z, Z+1 Для отрезка: [x, y] -> x-1, x, y, y+1 А для такого интервала значений: (х, у) ?

Выбор значений ● ● Значение в пределах класса является лучшим представителем Граничные значения часто будут лучшими представителями Могут быть лучшие представители, которые не будут граничными значениями Могут быть выделены лучшие представители в классах, значения которых не будут очевидно сравнимы (больше-меньше)

Как тестируем? ● Классы эквивалентности: некорректные значения ○ Тестировать одно некорректное значение за раз для того, чтобы проверить, что система идентифицирует его корректно. ● Классы эквивалентности: корректные значения ○ Как ?

Стратегии работы с новым кодом ТАБЛИЦЫ РЕШЕНИЙ (DECISION TABLE TESTING)

Этапы построения таблицы 1. 2. 3. 4. 5. Определить/записать все условия Посчитать количество возможных комбинаций условий Запомнить комбинации Записать действия Убрать лишние комбинации (схлопывание таблицы)

Пример: светофор (SQA DAYS 14 — ЕЛЕНА СТАШЕНКО)

Автомобиль находится перед светофором, определить его дальнейшие действия Условия: ØГорит ли красный? Y N ØГорит ли желтый? Y N ØГорит ли зеленый? Y N Количество комбинаций: Ø 2*2*2 = 8

1. Определить список возможных условий и их значения

2. Определить список всех возможных действий (ожидаемых результатов для условий)

3. Определить все значения для условий ( «да» «нет» или более 2 х значений) и их уникальные комбинации, которые приводят к выполнению ожидаемых результатов связанных с этим правилом

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

Дополнительные условия

Убрать лишние комбинации

Стратегии работы с новым кодом ФУНКЦИОНАЛЬНЫЕ ДИАГРАММЫ (CAUSE-EFFECT GRAPHING)

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

Алгоритм действий 1. Разбить внешние спецификации на отдельные функции, которые будут тестироваться (декомпозиция функциональных требований) 2. Идентифицировать явные и неявные причины (условия на входе) и присвоить каждой из них уникальный номер 3. Идентифицировать явные и неявные эффекты (действия на выходе) и присвоить каждому из них уникальный номер 4. Перевести семантику спецификации в граф «причина-следствие» (Boolean cause-effect graphing) 5. Добавить информацию о невозможных комбинациях причинэффектов 6. Построить таблицу решений (бинарные значения) 7. Записать тест кейс для каждого столбца

Пример Requirements for Calculating Car Insurance Premiums: For females less than 65 years of age, the premium is $500 For males less than 25 years of age, the premium is $3000 For males between 25 and 64 years of age, the premium is $1000 For anyone 65 years of age or more, the premium is $1500

Причины (Causes) – входные условия 1. Пол: мужской 2. Пол: женский 3. Возраст: =25 and = 65

Следствия (Effects) – выходные результаты 100. Премия = $1000 101. Премия = $3000 102. Премия = $1500 103. Премия = $500

Причина: 1. Пол: мужской and 3. Возраст:

Причина: 1. Пол: мужской and 4. Возраст: >=25 and

Причина: 1. Пол: мужской and 5. Возраст: >= 65 or 2. Пол: женский and 5. Возраст: >= 65 Следствие: 102: Премия = $1500

Причина: 2. Пол: женский and 3. Возраст: =25 and

Причина: 1. Пол: мужской and 5. Возраст: >= 65 or 2. Пол: женский and 5. Возраст: >= 65 Следствие: 102: Премия = $1500

Преобразование в таблицу решений Test Cases 1 (мужской) 2 (женский) 3 (= 25 and = 65) 1 1 0 0 2 1 0 0 1 0 3 1 0 0 0 1 4 0 1 0 0 1 5 0 1 1 0 0 6 0 1 0 100 (1000$) 101 (3000$) 102 (1500$) 103 (500$) 0 1 0 0 0 0 0 1

Особенности применения ф. диаграмм 1. Требуется трансляция спецификации в булевскую логическую сеть 2. Обнаружение неполноты и неоднозначности в исходных спецификациях 3. Применение функциональных диаграмм не обеспечивает построение всех полезных тестов, которые могут быть определены: a. Как пример: метод неадекватно исследует граничные условия 4. Лучше отделять анализ граничных значений от метода функциональных диаграмм (иначе граф существенно усложняется) 5. Наиболее трудным при реализации метода является преобразование диаграммы в таблицу решений

Стратегии работы с новым кодом ДРУГИЕ МЕТОДЫ

Метод предположение об ошибке (Error guessing) ● Этот метод в значительной степени является интуитивным ● Тест инженер использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку ● Перечислить в некотором списке возможные ошибки или ситуации, в которых они могут появиться, а затем на основе этого списка написать тесты

Requirements-Driven Testing Проверяем каждое требованиезапрос, которое описано или озвучено анализ требований: выявление неоднозначностей, неточностей, пропущенной информации и т. п. (можно использовать функциональные диаграмма) Отслеживаем все требования и их покрытие тестами ● список требований с идентификаторами и соответствующих тестов (Requirements Tracing Matrix) Для каждого требования должны быть разработаны тесты ●

Задания 1. Классы эквивалентности 2. Граничные значения 3. Таблица решений 4. Функциональные диаграммы

1. Выполнить разбиение на классы эквивалентности 1. 1 Password – длина не меньше 8 символов, максимум 16. Может состоять из латинских букв и цифр, а также могут быть использованы символы только из списка «!» , «_» , «? » , «#» . При этом пароль должен обязательно содержать, как минимум, одну заглавную букву и одну цифру. 1. 2 Значение для ‘Product ID’ должно содержать 5 символов, первые два из них должны быть обозначениями из списка допустимых значений (A 1 or A 2 or B 1 or B 2), остальные три — уникальным числовым значением.

Определить граничные значения 2. 1 Корректные значения X — целые значения от -2 до 10 2. 2 Максимальное длина вводимого значения равна 20 символам

3. Составить таблицу решений 3. 1 Страховая компания предоставляет страховку клиентам, достигшим 18 -ти летнего возраста. Если стаж водителя составляет от 2 -х до 6 -ти лет, предоставляется скидка 20%. Если стаж водителя более шести лет, скидка 30% 3. 2 Любому посетителю салона красоты «Жасмин» может быть присвоена одна из категорий: «Клиент» , «Клиент категории А» , «Клиент категории Б» , «Клиент категории С» в зависимости от количества посещение салона. Категория «Клиент» присваивается посетителю, на счету которого 3 посещения и более. Категория «Клиент категории А» присваивается посетителю, на счету которого 10 посещений и более. Категория «Клиент категории Б» присваивается посетителю, на счету которого 20 посещений и более. Категория «Клиент категории С» присваивается посетителю, на счету которого 30 посещений и более.

3. Составить таблицу решений 3. 2 Система скидок магазина Скидки предоставляются покупателям, которые приобрели накопительную карту магазина. Изначально карта имеет тип “Standard” c нулевым балансом. При покупке товара и предъявлении карты при оплате, сумма покупок зачисляется на баланс карты. Величина скидки зависит от общей суммы покупок на карте покупателя и от типа карты. Для карты тип “Standard” скидки составляют: ● 5%, если общая сумма покупок на карте от 20000 руб до 40000 руб включительно, ● 10%, если сумма на карте больше, чем 40000 руб. Магазин меняет карту типа “Standard” на карту типа “Silver Card”, если накопительная сумма покупателя на карте типа “Standard” становится равной или больше 50000 руб. Для карты тип “Silver Card” скидки составляют: ● 10%, если сумма на карте от 50000 руб до 70000 руб включительно, ● 20%, если сумма на карте больше, чем 70000 руб. Магазин меняет карту типа “Silver Card” на карту типа “Gold Card”, если накопительная сумма покупателя на карте типа “Silver Card” становится равной или больше 100000 руб. Для карты типа “Gold Card” скидки составляют: ● 20%, если сумма на карте от 100000 руб до 150000 руб включительно, ● 30%, если сумма на карте больше, чем 150000 руб. Магазин меняет карту типа “Gold Card” на карту типа “VIP Card”, если накопительная сумма покупателя на карте типа “Gold Card” становится равной или больше 200000 руб. Для карты типа “VIP Card” скидки составляют: 30%, если сумма на карте больше, чем 200000 руб

4. Применить метод функциональных диаграмм 4. 1 Для банкомата банка «ТТТ» реализовано ПО, которое автоматизирует такие функции как выдача денег, выдча справки о балансе (доступные средства на карте), выдача распечатки с 10 ю последними операциями по карте, оплата услуг по мобильной связи Проанализирйте спецификацию для функции «Обработка запроса на снятие суммы с карты» и примените метод функциональных диаграмм для создания тест кейсов. Разработать и описать тест-кейсы в матрице (xls-file). ● Спецификация для функции «Обработка запроса на снятие суммы с карты» : Если карта типа «кредитная» (K) или «дебетовая» (D), то банкомат выдает деньги клиенту при условии, что запрашиваемая сумма (X) не превышает сумму доступных средств на карте клиента (S). Если карта типа «кредитная» , то банкомат выдает деньги и в случае, если запрашиваемая сумма превышает сумму доступных средств на карте, но не выходит за рамки допустимого превышения кредита (L). В случае, если карта не является «кредитной» или «дебетовой» или же запрашиваемая сумма превышает сумму доступных средств на карте для дебетовой карты или же запрашиваемая сумма превышает сумму доступных средств на карте и выходит за рамки допустимого превышения кредита для кредитовой карты, тогда выдается сообщение о том, что деньги не могут быть выданы и деньги не выдаются.

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

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

2 этап —
локализация ошибки — определение
конкретного фрагмента, при выполнении
которого произошло отклонение от
предполагаемого вычислительного
процесса. Локализация может выполняться:

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

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

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

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

4 этап —
исправление ошибки — внесение
соответствующих изменений во все
операторы, совместное выполнение
которых привело к ошибке.

5 этап —
повторное тестирование — повторение
всех тестов с начала, так как при
исправлении обнаруженных ошибок часто
вносят в программу новые.

Следует иметь в
виду, что процесс отладки можно
существенно упростить, если следовать
основным рекомендациям структурного
подхода к программированию:

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

• выводить
пользователю вводимые им данные для
контроля и проверять их на допустимость
сразу после ввода;

• предусматривать
вывод основных данных во всех узловых
точках алгоритма (ветвлениях, вызовах
подпрограмм).

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

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

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

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

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

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

В жизненном цикле
КП можно выделить следующие виды
испытаний

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

-рабочей версии
КП, адаптированной к условиям конкретного
применения,

-версии
модернизированного КП при сопровождении.

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

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

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

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

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

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

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

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

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

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

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

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

Достоверность
испытаний: методическая и статистическая
достоверность; документирование
результатов испытаний: исходных и
отчетные документы при испытаниях
программ – техническое задание,
государственные и отраслевые стандарты,
программа испытаний, методики испытаний,
протоколы испытаний, акт испытаний.

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

Методическая
достоверность испытаний КП определяется
следующими факторами:

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

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

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

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

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

Документы:

ТЗ

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

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

-объект испытаний,
его назначение и перечень основных
документов, определивших его
разработку;

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

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

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

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

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

-указание методик,
в соответствии с которыми проводились
испытания, обработка и оценка результатов;

-условия проведения
тестирования и характеристика исходных
данных;

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

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

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

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

Виды программной
документации: проектная и эксплуатационная
документация. Документирование
интерактивного ПО. Государственные
стандарты в области документирования
ПО. Средства автоматизации документирования.

К программным
относят документы, содержащие сведения,
необходимые для разработки, сопровождения
и эксплуатации программного
обеспечения. Документирование
программного обеспечения осуществляется
в соответствии с Единой системой
программной документации (ГОСТ 19.XXX).
Так ГОСТ 19.101-77 устанавливает виды
программных документов для программного
обеспечения различных типов. Ниже
перечислены основные программные
документы по этому стандарту и указано,
какую информацию они должны содержать.

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

Ведомость
держателей подлинников (код вида
документа — 05) должна содержать список
предприятий, на которых хранятся
подлинники программных документов.
Необходимость этого документа
определяется на этапе разработки и
утверждения технического задания
только для программного обеспечения
со сложной архитектурой.

Текст программы
(код вида документа — 12) должен содержать
текст программы с необходимыми
комментариями. Необходимость этого
документа определяется на этапе
разработки и утверждения технического
задания.

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

Ведомость
эксплуатационных документов
(код вида документа — 20) должна содержать
перечень эксплуатационных документов
на программу, к которым относятся
документы с кодами: 30, 31, 32, 33, 34, 35, 46.
Необходимость этого документа также
определяется на этапе разработки и
утверждения технического задания.

Формуляр
(код вида документа — 30) должен содержать
основные характеристики программного
обеспечения, комплектность и сведения
об эксплуатации программы.

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

Руководство
системного программиста
(код вида документа — 32) должно содержать
сведения для проверки, обеспечения
функционирования и настройки программы
на условия конкретного применения.

Руководство
программиста
(код вида документа — 33) должно содержать
сведения для эксплуатации программного
обеспечения.

Руководство
оператора
(код вида документа — 34) должно содержать
сведения для обеспечения процедуры
общения оператора с вычислительной
системой в процессе выполнения
программного обеспечения.

Описание языка
(код вида документа — 35) должно содержать
описание синтаксиса и семантики языка.

Руководство по
техническому обслуживанию
(код вида документа — 46) должно содержать
сведения для применения тестовых и
диагностических программ при обслуживании
технических средств.

Программа и
методика испытаний
(код вида документа — 51) должны содержать
требования, подлежащие проверке при
испытании программного обеспечения,
а также порядок и методы их контроля.

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

Прочие документы
(коды вида документа — 90-99) могут
составляться на любых стадиях
разработки, т. е. на стадиях эскизного,
технического и рабочего проектов.
Допускается объединять отдельные
виды эксплуатационных документов,
кроме формуляра и ведомости. Необходимость
объединения указывается в техническом
задании, а имя берут у одного из
объединяемых документов.

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

На
этапе планирования разработки ПО
создаются планы и выбираются стандарты,
которые направляют этап разработки и
интегрированный этап. Его

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

1)
определение действий на этапах разработки
и интегрированном этапе, которые будут
посвящены определению системных
требований и уровня ПО;

2)
определение ЖЦ ПО, включая взаимодействие
между этапами, механизм взаимного
влияния этапов, критерии оценки ПО при
переходе от одного этапа к другому;

3)определение
среды ЖЦ, т.е. методы и инструментальные
средства, используемые на каждом этапе;

4)
формирование дополнительных замечаний
к ПО;

5)
рассмотрение стандартов разработки
ПО, соотношение их с системными целями
безопасности, относящиеся к разрабатываемому
ПО;

6)
разработка плана создания ПО;

7)
доработка и проверка плана создания
ПО.

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

-на основе
распределения системного анализа
(алгоритмизации) и разработки программ
по разным коллективам;

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

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

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

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

Одним из вариантов
организационной структуры коллектива
при создании крупных КП является
иерархическая структура, базирующаяся
на группах специалистов, каждая из
которых составляет специализированную,
так называемую «хирургическую бригаду».
Такая бригада решает достаточно
автономную функциональную задачу
и должна разработать и отладить группу
взаимодействующих программ с
достаточно четкой целью функционирования.
«Хирургическая бригада» рекомендуется
в составе 7…10 специалистов с различными
задачами и квалификацией. Во главе
бригады стоит «хирург», который
разрабатывает функциональные задачи
программ, составляет алгоритм, пишет
и отлаживает программы, готовит и
проверяет документацию. Он должен
обладать значительным системным
опытом, высокой математической и
программистской квалификацией и
талантом разработки и отладки сложных
КП. «Второй пилот» является дублером
и может выполнить любую часть работы,
но менее опытен. Он принимает участие
в разработке, обсуждении и оценке
компонент, создаваемых бригадой, в
качестве оппонента или ответчика по
альтернативным решениям, а также несет
ответственность за взаимодействие
с другими бригадами и с разрабатываемыми
ими группами программ.

«Администратор»
позволяет избавить «хирурга» от
множества технических и административных
функций как внутри бригады, так и по
взаимодействию с администрацией всей
организации. При этом «хирургу»
принадлежит определяющее слово по
важнейшим вопросам организации и
проведения работ. «Редактор» критикует
документацию, созданную «хирургом»,
дорабатывает ее, снабжает ссылками и
наблюдает за ее публикацией. «Адвокат
языка» обеспечивает «хирурга»
консультациями по применению языка в
трудных или запутанных ситуациях,
способствует получению более
эффективных программ. «Инструментальщик»
— опытный системный программист —
является создателем специализированных
технологических и служебных программ,
каталогизированных процедур,
библиотек макрокоманд для расширения
функций технологического обеспечения
по заказу «хирурга». «Наладчик»
разрабатывает системные тесты в
соответствии с назначением и функциями
создаваемой группы программ. Он планирует
последовательность тестирования,
подготавливает имитаторы исходных
данных для комплексной отладки,
регистрирует процесс проведения
отладки и ее результаты. Кроме того, в
бригаду входят 2…3 технических работника
для выполнения секретарских функций
и различных вспомогательных технических
работ.

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

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

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

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

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

Сопровождение
программного обеспечения связано с
внесением изменений в течение всего
времени использования программного
изделия. К причинам, определяющим
необходимость внесения изменений
в изделии, относятся:

• наличие ошибок
в используемом программном продукте;

• изменение
требований пользователя (расширение
или модификация);

• появление более
совершенных общесистемных программных
средств или технических устройств;

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

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

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

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

Задачи службы
сопровождения программного изделия

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

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

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

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

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

5. Контроль
правильности всех корректировок,
вносимых в изделие, и проверка
качества измененных программ.

6. Доведение до
пользователя информации о внесенных
изменениях.

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

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

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

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

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

Методика расчета при прогнозировании отказов программного обеспечения

Рассматриваемая модель основана на
следующих допущениях:

время до следующего отказа распределено
экспоненциально;

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

Согласно этим допущениям вероятность
безотказной работы программ как функция
времени t
i
равна:

P(t
i
)=exp(-
l
i

×

t
i
)
,
(1)

где l
i
=
С

×

(N-(i-1)).
(2)

Здесь С
– коэффициент пропорциональности;

N
– первоначальное
число ошибок программы.

В выражении (1) отсчет времени t
i
начинается от момента последнего(i
-1)
отказа программы, а значениеl
i
изменяется при прогнозировании разных
отказов.

Значения C

иN
в выражении (2) определяются по
экспериментально зафиксированным
интервалам времениD
t
i
между моментами возникновения отказов
в процессе отладки программы. На основе
методики максимума правдоподобия
значениеN
получают
как решение нелинейного уравнения:

где К
– число экспериментально
полученных интервалов между отказами.

Реально значение N
получают методом подбора, основываясь
на том, что это целое число.

Значение коэффициента пропорциональности
С
получают как:

.
(4)

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

Пример прогнозирования отказов программного обеспечения

Пусть в ходе отладки программы
зафиксированы интервалы времени D
t
1
=10,
D
t
2
=20,
D
t
3
=25
между отказами программы. ЗначенияD
t
могут определяться в единицах времени,
а могут – в числе прогонов программы
при тестировании. Определим вероятность
работоспособности программыP
(t
4
)=
exp
(-
l
4

×

t
4
)
,
т.е. отсутствия следующего, четвертого
отказа, начиная от момента устранения
третьего отказа и среднее времяТ
4
до следующего отказа программы.

Решаем уравнение (3) относительно N
методом перебора.

Для N
=4
имеем приК=3

Для N
=5

Наименьшую ошибку обеспечивает N
=4
,
откуда в соответствии с выражением (4):

Таким образом вероятность безотказной
работы в отсутствии 4-го отказа составляет

P
(t
4
)=
exp
(-0,02
×

t
4
)
, аT
4
=1/
l
4
=50
.

Напоминаем, что отсчет t
4
начинается после возникновения третьего
отказа и определяется в единицах времени
или в числе прогонов программы.

Пример
расчета звездообразной сети:

Локальная вычислительная сеть (ЛВС)
обычно включает в свой состав комплект
рабочих станций пользователя, рабочую
станцию администратора сети (может
использоваться одна из пользовательских
станций), серверное ядро (комплект
аппаратных серверных платформ с
серверными программами: файл-сервер,
WWW-сервер, сервер БД,
почтовый сервер и т.п.), коммуникационное
оборудование (маршрутизаторы, коммутаторы,
концентраторы) и структурированную
кабельную систему (кабельное оборудование).

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

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

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

Восстановление ограниченное – т.е. в
любой момент времени не может
восстанавливаться более, чем один
отказавший элемент, т.к. имеется одна
ремонтная бригада;

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

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

Установим в качестве критерия отказа
ЛВС отказ оборудования, входящего в
ядро сети: серверов, коммутаторов или
кабельного оборудования.

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

Надёжность звездообразной сети.

Отказы не влияют на отказ всей сети.
Надёжность ЛВС определяется надёжностью
центрального узла.

Примем, что рассматриваемая локальная
сеть включает один сервер, два коммутатора
и четырнадцать кабельных фрагментов,
относящихся к ядру сети. Интенсивность
отказов и восстановлений для них
приведены ниже, по-прежнему К Г =1-l/m.

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

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

Подсистема серверов:

l С =2*l 1 =2*10 -5 ;
К ГС =1-2*10 -4 ;m С = =0,1
1/ч.

Подсистема коммутаторов:

l к =2*10 -5 ;
К Гк =1-2*10 -3 ;m к =
1/ч.

Подсистема кабелей:

l л =14*10 -6 ;
К Гл =1-14*10 -6 ;m л =
1 1/ч.

Для всей сети:

l s =6,5*10 -5 ;
К Г s =1-2,4*10 -3 ;m s =0,027
1/ч.

Результат расчета:

Т=15 тыс. ч., К Г =0,998, Т В »37
ч.

Расчет стоимости ЛВС:

14 сетевых карт: 1500руб.

Кабель 1км: 2000руб.

Разъемы: 200руб.

Сервер: 50тыс. руб.

Всего: 2 53700 т. Руб.

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

Рис. 1. Стоимость устранения ошибок во встраиваемых системах

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

Самый лучший способ повысить качество ПО это стараться не допускать ошибок в процессе ввода исходного текста.
Первый шаг на пути предотвращения ошибок это осознание того, что ошибки действительно можно предотвратить. Больше всего препятствует контролю над ошибками распространенное убеждение в том, что ошибки неизбежны. Это заблуждение! Ошибки сами по себе не появляются их вносит в текст разработчик. Человеку свойственно ошибаться, так что даже самые лучшие программисты время от времени допускают ошибки, если у них есть такая возможность. Поэтому чтобы уменьшить число ошибок, надо сократить возможности их появления. Один из лучших способов здесь следование стандартам программирования, что ликвидирует благодатную почву для возникновения ошибок на первых этапах.
Стандарты программирования это специфичные для языка «правила», которые, если их соблюдать, значительно снижают вероятность внесения ошибок в процессе разработки приложения. Следовать стандартам программирования нужно на этапе написания программ, до их переноса в целевые платформы, при этом стандартизация должна существовать для всех языков. Поскольку большая часть разработчиков встраиваемых систем пользуется языком С, больше внимания уделим именно стандартам программирования на C, хотя такие же стандарты существуют и для других языков, включая С++ и Java.
Как правило, стандарты программирования делятся на две категории:
отраслевые стандарты программирования: правила, принятые всеми программистами на данном языке (например, запрет входа в цикл не через его заголовок).
специальные стандарты программирования: правила, соблюдаемые конкретной группой разработчиков, в рамках конкретного проекта, или даже единственным программистом. Существует три типа специальных стандартов, которыми может воспользоваться разработчик встраиваемой программной системы: внутренние стандарты, персональные стандарты и стандарты, определяемые целевой платформой.
Внутренние стандарты программирования это правила, которые специфичны для вашей организации или группы разработчиков. Так, уникальные для организации правила присвоения имен это пример внутренних стандартов программирования.
Персональные стандарты это правила, которые помогут вам избежать ваших наиболее частых ошибок. Каждый раз при появлении какой-либо ошибки программист должен проанализировать причину ее появления и выработать собственное правило, препятствующее повторному ее возникновению. Например, если в операторе условия вы часто пишете знак присваивания вместо знака проверки на равенство (т.е. «if (a=b)» вместо «if (a= =b)»), то вам необходимо создать для себя следующий стандарт: «Остерегаться применения знака присваивания в операторе проверки условия».
Стандарты, определяемые целевой платформой, это правила, нарушение которых в данной платформе может привести к появлению определенных проблем. Например, такими стандартами могут быть ограничения на использование памяти или размер переменных, налагаемые целевой платформой.
Чтобы лучше разобраться в том, что такое стандарты программирования и как они работают, познакомимся с ними на конкретных примерах. Рассмотрим следующую запись на языке С:
{
.
.
.
}
Здесь размер одномерного массива декларируется в списке аргументов функции. Это опасная конструкция, поскольку в языке С аргумент-массив передается как указатель на его первый элемент, и в разных обращениях к функции в числе ее фактических аргументов могут указываться массивы с разной размерностью. Создав такую конструкцию, вы предполагаете пользоваться буфером фиксированного размера на 80 элементов, считая, что именно такой буфер и будет передаваться функции, а это может привести к разрушению памяти. Если бы автор этого оператора следовал стандарту программирования «не объявлять размер одномерного массива в числе аргументов функции» (взятому из набора стандартов программирования на языке С одной из ведущих телекоммуникационных компаний), то этот текст выглядел бы следующим образом и проблем с разрушением памяти удалось бы избежать:
char *substring (char string, int start_pos, int length)
{
.
.
.
}
Стандарты программирования позволяют также избегать проблем, которые до момента портирования кода на другую платформу могут не проявляться. Например, следующий кусок кода будет исправно работать на одних платформах и порождать ошибки после переноса его на другие платформы:
#include
void test(char c) {
if(a }
if(islower(c)) {// Правильно
}
while (A }
while (isupper(c)) { // Правильно
}
}
Проблемы портации могут быть связаны с символьными тестами, в которых не используется функции ctype.h (isalnum, isalpha, iscntrl, isdigit, isgraph, islower, isprint, ispunct, isspace, isupper, isxdigit, tolower, toupper). Функции ctype.h для символьной проверки и преобразования прописных букв в строчные и наоборот работают с самыми разными наборами символов, обычно очень эффективны и гарантируют международную применимость программного продукта.
Лучший способ внедрить эти и другие стандарты программирования это обеспечить их автоматическое применение в составе какой-либо технологии программирования, вместе с набором целенаправленных отраслевых стандартов и механизмами создания и поддержки стандартов программирования, ориентированных на конкретную систему. При выборе подобной технологии необходимо сначала найти ответы на вопросы, среди которых следующие:
Применима ли она к данной программе и/или компилятору?
Содержит ли она набор отраслевых стандартов программирования?
Позволяет ли она создавать и поддерживать специальные стандарты программирования (включая стандарты, определяемые целевой платформой)?
Легко ли структурировать отчеты в соответствии с вашими групповыми и проектными приоритетами?
Насколько легко она интегрируется в существующий процесс разработки?
Блочное тестирование

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

Рис. 2. Простота нахождения ошибок при блочном тестировании

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

Рис. 3. Тестирование «черного ящика»

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

Рис. 4. Тестирование «белого ящика»

Оба вышеописанных процесса могут служить основой третьего, регрессивного тестирования. Сохранив тестовые наборы для «черного» и «белого» ящиков, можно использовать их для регрессивного тестирования на уровне блоков и контролировать целостность кода по мере того, как вы его модифицируете. Концепция регрессивного тестирования на этом уровне является новым оригинальным подходом. При выполнении регрессивного тестирования на уровне блоков можно сразу же после изменения вами текста определять, не появились ли новые проблемы, и устранять их немедленно после возникновения, тем самым препятствуя распространению ошибки по вышележащим уровням.
Главная проблема, связанная с блочным тестированием, заключается в том, что если не пользоваться технологиями автоматического блочного тестирования, проводить его трудно, утомительно и слишком долго. Рассмотрим вкратце причины, по которым включать неавтоматизированное блочное тестирование в сегодняшние процессы разработки трудно (если вообще возможно).
Первый этап блочного тестирования ПО встраиваемых систем заключается в создании такой среды, которая позволит запускать и тестировать интересующую функцию в хост-системе. Это требует выполнения следующих двух действий:
разработка программного текста, который будет запускать функцию,
написание фиктивных модулей, которые будут возвращать результаты вместо внешних ресурсов, к которым обращается функция и которые в текущий момент отсутствуют или недоступны.
Второй этап разработка тестовых наборов. Для полноты охвата конструктивных и функциональных особенностей функции необходимо создавать тестовые наборы двух типов: для «черного ящика» и для «белого ящика».
Основой разработки тестовых наборов для «черного ящика» должна стать спецификация функции. В частности, для каждой записи в спецификации должен быть создан хотя бы один тестовый набор, при этом желательно, чтобы эти наборы учитывали указанные в спецификации граничные условия. Проверять того, что некоторые входные параметры приводят к ожидаемым результатам, недостаточно; необходимо определить диапазон взаимосвязей входов и выходов, который позволит сделать вывод о корректной реализации указанных функциональных характеристик, и затем создавать тестовые наборы, полностью покрывающие данный диапазон. Можно также тестировать не указанные в спецификации и ошибочные условия.
Цель тестовых наборов для «белого ящика» обнаружить все скрытые дефекты путем всестороннего тестирования функции разнообразными входными параметрами. Эти наборы должны обладать следующими возможностями:
обеспечивать максимально возможное (100%) покрытие функции: как уже говорилось, такая степень покрытия на уровне блоков возможна, поскольку создавать наборы для тестирования каждой характеристики функции вне приложения гораздо проще (стопроцентное покрытие во всех случаях невозможно, но это цель, к которой надо стремиться);
выявлять условия краха функции.
Следует заметить, что самостоятельно создание подобных наборов, не владея технологиями их построения, невероятно тяжелое занятие. Чтобы создать эффективные тестовые наборы для «белого ящика», необходимо сначала получить полное представление о внутренней структуре функции, написать наборы, обеспечивающие максимальное покрытие функции, и найти совокупность входов, приводящих к отказу функции. Получить спектр покрытия, необходимый для высокоэффективного тестирования «белого ящика», возможно лишь при исследовании значительного числа путей прохода по функции. Например, в обычной программе, состоящей из 10000 операторов, имеется приблизительно сто миллионов возможных путей прохода; вручную создать тестовые наборы для проверки всех этих путей невозможно.
После создания тестовых наборов необходимо провести тестирование функции в полном объеме и проанализировать результаты с целью выявления причин ошибок, крахов и слабых мест. Необходимо иметь способ прогона всех тестовых наборов и быстрого определения, какие из них приводят к возникновению проблем. Необходимо также иметь инструмент измерения степени покрытия для оценки полноты тестирования функции и определения необходимости в дополнительных тестовых наборах.
При любых изменениях функции следует проводить регрессивное тестирование, чтобы убедиться в отсутствии новых и/или устранении предыдущих ошибок. Включение блочного регрессивного тестирования в процесс разработки позволит защититься от многих ошибок они будут обнаружены сразу же после возникновения и не смогут стать причинами распространения ошибок в приложении.
Регрессивное тестирование можно проводить двумя способами. Первый заключается в том, что разработчик или испытатель анализирует каждый тестовый набор и определяет, на работе которого из них может сказаться измененный код. Этот подход характеризуется экономией машинного времени за счет работы, проводимой человеком. Второй, более эффективный, заключается в автоматическом прогоне на компьютере всех тестовых наборов после каждого изменения текста. Данный подход гарантирует большую эффективность труда разработчика, поскольку он не должен тратить время на анализ всей совокупности тестовых наборов, для того чтобы определить, какие наборы следует прогонять, а какие нет.
Если вы сможете автоматизировать процесс блочного тестирования, то не только повысите качество тестирования, но и высвободите для себя значительно больше временных и материальных ресурсов, чем уйдёт на этот процесс. Если вы пишете программы на языке С, то для автоматизации блочного тестирования можете воспользоваться существующими технологиями. Чем больше процессов вы сможете автоматизировать, тем больше пользы вы получите.
При выборе технологии блочного тестирования сначала следует ответить на следующие вопросы:
Подходит ли эта технология для вашего текста и/или компилятора?
Может ли она автоматически создавать тестовые схемы?
Может ли она автоматически генерировать тестовые наборы?
Позволяет ли она вводить создаваемые пользователем тестовые наборы и фиктивные модули?
Автоматизировано ли регрессивное тестирование?
Имеется ли в ее составе технология или связь с технологией автоматического распознавания ошибки в процессе прогона?
Средства отладки, не меняющие режим работы программ

Из-за того, что операционные системы реального времени должны выполнять определенные задачи в условиях заранее определенных временных ограничений, временные соотношения превращаются в важнейший параметр, который разработчики должны учитывать при установке тестового ПО. Обычно в процессе исполнения программ возникает множество различных прерываний, и чрезвычайно необходимо, чтобы в момент возникновения прерывания приложение реагировало корректно. Ситуация еще более усложняется, когда несколько прерываний возникает сразу или когда в системе исполняется несколько приложений с несколькими взаимодействующими друг с другом тредами. По сути, это приложения с несколькими одновременными путями исполнения различные кодовые последовательности как бы исполняются в одно и то же время, даже если в системе всего один центральный процессор. Интересно заметить, что если бы эти приложения исполнялись в нескольких процессорах, то различные треды на практике были бы загружены в разные процессоры.
Если возникающие в приложениях реального времени ошибки проявляются во взаимодействиях между программой и прерываниями, то они будут в значительной мере чувствительны ко времени. В этом случае критически важно регистрировать порядок возникновения ошибок, поскольку это позволит разобраться в причинах и следствиях каждой ошибки. В этом как раз и кроется главная проблема отладки систем реального времени: существует достаточное количество трудновыявляемых ошибок, которые проявляются только при определенных временных соотношениях.
Эта проблема осложняется тем, что подобные ошибки не так-то просто воспроизводятся. Очень трудно воссоздать ситуацию с такими же временными соотношениями, что и приведшие к возникновению ошибки в реальной программе. Механизм отладки таких приложений должен быть максимально возможно щадящим. Любое вмешательство в ход исполнения программ может привести к изменению ее временных характеристик и отсутствию условий возникновения ошибок. Конечно, создание условий, при которых ошибки не возникают, это хорошо, но в данном случае это является препятствием отладке программы.
Теоретической основой проблемы отладки систем реального времени может послужить известный всем из курса физики принцип неопределенности немецкого физика Вернера Гейзенберга, согласно которому одновременно определить скорость и местоположение движущейся частицы невозможно. Гейзенберг считал, что, определяя координаты частицы, экспериментатор тем самым изменяет её местоположение, что не позволяет определить её координаты точно. Операция измерения влияет на измеряемый объект и искажает результаты измерения. Принцип неопределенности это одна из аксиом квантовой механики.
Применительно же к нашей теме, этот принцип означает, что отладка системы требует сбора информации о ее состоянии. Однако сбор информации о состоянии системы меняет ее временные характеристики и существенно затрудняет надежное воспроизведение условий возникновения ошибки.
Таким образом, суть этой проблемы в том, что нужно найти способ обнаружения ошибок реального времени и анализа поведения программы без влияния на существующие временные соотношения. Наверное, вашим первым порывом было бы обращение к отладчику, но отладчики, как правило, прерывают исполнение программы и, соответственно, изменяют ее временные характеристики. Малопригодны и системы моделирования, поскольку они не могут воссоздать временные характеристики реальных технических средств. Еще никто не создал такую систему моделирования, которая могла бы смоделировать режим реального времени; временные параметры можно определить, только загрузив программу в само железо.
Последнее требует наличия специального механизма для упрощенной регистрации состояния системы. Один из возможных и подходящих механизмов запись информации в оперативную память, поскольку такая операция выполняется чрезвычайно быстро. Один из способов применения этого механизма организация где-нибудь в памяти специального буфера и использование в вашей программе указателя на этот буфер. Указатель всегда ссылается на начало буфера. В программу вставляются операции записи в ячейку, определяемую указателем. После каждой операции записи значение указателя меняется соответствующим образом. Иногда полезно пользоваться кольцевым буфером (т.е. когда после записи в последнюю ячейку буфера указатель начинает показывать на начало буфера), что позволяет отслеживать ситуации, приводящие к возникновению проблемы. Необходимо при этом предусмотреть способ сохранения содержимого буфера после нормального или аварийного завершения программы, чтобы впоследствии иметь к нему доступ и проводить так называемую «посмертную отладку». Способ реализации зависит от аппаратных средств, обычно это можно сделать, если не выполнять повторную инициализацию (reset) оборудования.
Теперь вам нужен механизм чтения этой памяти. Здесь можно использовать и отладчик, и другие средства извлечения информации из оперативной памяти. В частности, можно написать простенькую программу, которая будет пересылать эти данные в файл или на принтер. Каким бы средством вы не пользовались, конечным этапом, вероятнее всего, будет ручной анализ содержимого буфера. Если ваш буфер кольцевой, то вам необходимо иметь точные сведения о значении указателя; события, которые стали началом последовательности, будут непосредственно перед указателем, события, которые возникли непосредственно перед крахом, будут сразу же после указателя.

Рис. 5. Последовательность событий в кольцевом буфере

Теперь ваша главная задача попытаться разобраться в последовательности данных, записанных в буфере. Эта задача аналогична исследованию причин катастрофы самолета по показаниям приборов, зарегистрированных «черным ящиком» самолета. Анализ характеристик программы в этом случае проводится после свершившегося события, что, естественно, гораздо меньше влияет на ее исполнение, чем контроль в течение работы.
Иногда бывает очень трудно восстановить приведшие к краху события, и четкого понятия о моменте возникновения ошибки нет. Только на выяснение причины ошибки могут уходить многие месяцы. В таких случаях для поиска ошибочного оператора можно воспользоваться логарифмическим методом отладки. В разных местах отлаживаемого кода расставляются маркеры (например, операторы типа exit), а перед ними операторы записи в память. Затем запускаете программу и ожидаете момента краха. В случае краха вы знаете, между какими маркерами он произошел. Этот метод позволяет выявлять и проблемы согласования по времени, поскольку он позволяет находить сегменты кода, в которых возникают нарушения временных соотношений.
Ещё одно решение это применение в качестве технологии отладки так называемых брандмауэров. Брандмауэр это точка в логическом потоке программы, в которой доказывается справедливость предположений, на которые опирается последующий код. Проверка этих предположений отличается от обычного контроля ошибок. Срабатывание брандмауэра представляет собой сигнал разработчику о том, что внутреннее состояние системы неустойчиво. Это может произойти, например, если ожидающая строго положительного аргумента функция получает нулевую или отрицательную величину. Неискушённым разработчикам большинство брандмауэров кажутся тривиальными и ненужными. Однако опыт разработки крупных проектов показывает, что по мере развития и совершенствования программных систем неявные предположения в отношении среды исполнения нарушаются все чаще и чаще. Во многих случаях даже сам автор затрудняется сформулировать, что представляют собой надлежащие условия исполнения того или иного участка кода.
Реализуемые внутри встраиваемых систем брандмауэры нуждаются в специальных средствах связи для передачи сообщений во внешний мир; обсуждение способа установления таких каналов передачи выходит за рамки настоящей статьи.
Заключение

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

1. M. Aivazis and W. Hicken. «C++ Defensive Programming: Firewalls and Debugging Information.» C++ Report (July-August 1999): 34 40.

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

Меры по обнаружению ошибок можно разбить на две подгруппы:

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

Пассивное обнаружение ошибок

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

Разрабатывая эти меры, мы будем опираться на следующие положения:

1. Взаимное недоверие.
Каждая из компонент должна предполагать, что все другие содержат ошибки. Когда она получает какие-нибудь данные от другой компоненты или из источника вне системы, она должна предполагать, что данные могут быть неправильными, и пытаться найти в них ошибки.
2. Немедленное обнаружение.
Ошибки необходимо обнаружить как можно раньше. Это не только ограничивает наносимый ими ущерб, но и значительно упрощает задачу отладки.
3. Избыточность.
Все средства обнаружения ошибок основаны на некоторой форме избыточности (явной или неявной).

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

1. Проверяйте атрибуты любого элемента входных данных. Если входные данные должны быть числовыми или буквенными, проверьте это. Если число на входе должно быть положительным, проверьте его значение. Если известно, какой должна быть длина входных данных, проверьте ее.
2. Применяйте «тэги» в таблицах, записях и управляющих блоках и проверяйте с их помощью допустимость входных данных. Тэг — это поле записи, явно указывающее на ее назначение.
3. Проверяйте, находится ли входное значение в установленных пределах. Например, если входной элемент — адрес в основной памяти, проверяйте его допустимость. Всегда проверяйте поле адреса или указателя на нуль и считайте, что оно неверно, если равно нулю. Если входные данные — таблица вероятностей, проверьте, находятся ли все значения между нулем и единицей.
4. Проверяйте допустимость всех вариантов значений. Если входное поле — код, обозначающий один из десяти районов, никогда не предполагайте, что если это не код ни одного из районов 1, 2,…, 9, то это обязательно код района 10.
5. Если во входных данных есть какая-либо явная избыточность, воспользуйтесь ею для проверки данных.
6. Там, где во входных данных нет явной избыточности, введите ее. Если ваша система использует крайне важную таблицу, подумайте о включении в нее контрольной суммы. Всякий раз, когда таблица обновляется, следует просуммировать (по некоторому модулю) ее поля и результат поместить в специальное поле контрольной суммы. Подсистема, использующая таблицу, сможет теперь проверить, не была ли таблица случайно испорчена, — для этого только нужно выполнить контрольное суммирование.
7. Сравнивайте, согласуются ли входные данные с какими-либо внутренними данными. Если на входе операционной системы возникает требование освободить некоторый блок памяти, она должна убедиться, что этот блок в данный момент действительно занят.

Когда разрабатываются меры по обнаружению ошибок, важно принять согласованную стратегию для всей системы (т.е. применить идею концептуальной целостности). Действия, предпринимаемые после обнаружения ошибки в программном обеспечении (например, возврат кода ошибки), должны быть единообразными для всех компонент системы. Это ставит вопрос о том, какие именно действия следует предпринять, когда ошибка обнаружена. Наилучшее решение — немедленно завершить выполнение программы или (в случае операционной системы) перевести ЦП в состояние ожидания. С точки зрения предоставления человеку, отлаживающему программу, например системному программисту, самых благоприятных условий для диагностики ошибок немедленное завершение представляется наилучшей стратегией. Конечно, во многих системах подобная стратегия бывает нецелесообразной (например, может оказаться, что приостанавливать работу системы нельзя). В таком случае используется метод регистрации ошибок.
Описание симптомов ошибки и «моментальный снимок» состояния системы сохраняется во внешнем файле, после чего система может продолжать работу. Этот файл позднее будет изучен обслуживающим персоналом. Такой метод использован в операционной системе OS/VS2MVS фирмы IBM. Каждая компонента содержит программу восстановления, которая перехватывает все случаи ненормального завершения и программные прерывания в этой компоненте и регистрирует данные об ошибке во внешнем файле.

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

Пример: система PRIME

Система PRIME-это мультипроцессорная система с виртуальной памятью, разработанная в Калифорнийском университете в Беркли. Ее упрощенная схема показана на рис. 4.1. Один из процессоров системы выделен в качестве центрального процессора и содержит центральный управляющий монитор (ССМ — central control monitor) — управляющую программу, которая распределяет страницы памяти и пространство на диске, назначает программы другим процессорам (проблемным процессорам) и регулирует пересылки всех межпроцессорных сообщений. Расширенный управляющий монитор (ЕСМ — extended control monitor) — это реализованная микропрограммно-управляющая программа, постоянно присутствующая в каждом процессоре и управляющая диспетчеризацией процессов, операциями ввода-вывода и посылки / получения.

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

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

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

Система PRIME содержит механизм посылки / получения, который позволяет процессу одного пользователя послать сообщение процессу другого пользователя. Для этого процесс-отправитель передает своему ЕСМ это сообщение и идентификатор процесса-получателя. ЕСМ добавляет идентификатор отправителя и передает сообщение ССМ. Тот передает сообщение ЕСМ процессора, содержащего процесс-получатель, а ЕСМ наконец передает сообщение указанному процессу пользователя. В этой последовательности выполняются три проверки с целью обнаружения ошибки. ССМ проверяет, правильный ли идентификатор процесса-отправителя добавлен ЕСМ; он может это сделать, поскольку известно, какому пользователю выделен процессор. ЕСМ адресата проверяет, тому ли процессору ССМ направил сообщение; он выполняет это, сравнивая идентификатор процесса в сообщении с идентификатором процесса, которому в данный момент выделен процессор. Третья проверка делается для обеспечения сохранности сообщения при транзите. ЕСМ-отправитель формирует для сообщения контрольную сумму и передает ее вместе с сообщением. ЕСМ-получатель вычисляет контрольную сумму доставленного сообщения и сравнивает с извлеченной из сообщения.

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

Активное обнаружение ошибок

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

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

Диагностический монитор можно реализовать как периодически выполняемую задачу (например, она планируется на каждый час) либо как задачу с низким приоритетом, которая планируется для выполнения в то время, когда система переходит в состояние ожидания. Как и прежде, выполняемые монитором конкретные проверки зависят от специфики системы, но некоторые идеи будут понятны из примеров. Монитор может обследовать основную память, чтобы обнаружить блоки памяти, не выделенные ни одной из выполняемых задач и не включенные в системный список свободной памяти. Он может проверять также необычные ситуации: например, процесс не планировался для выполнения в течение некоторого разумного интервала времени. Монитор может осуществлять поиск «затерявшихся» внутри системы сообщений или операций ввода-вывода, которые необычно долгое время остаются незавершенными, участков памяти на диске, которые не помечены как выделенные и не включены в список свободной памяти, а также различного рода странностей в файлах данных.

Иногда желательно, чтобы в чрезвычайных обстоятельствах монитор выполнял диагностические тесты системы. Он может вызывать определенные системные функции, сравнивая их результат с заранее определенным и проверяя, насколько разумно время выполнения. Монитор может также периодически предъявлять системе «пустые» или «легкие» задания, чтобы убедиться, что система функ — ционирует хотя бы самым примитивным образом.

Пример: программа обнаружения разрушений, разработанная фирмой TRW

Система защиты ресурсов фирмы IBM — это экспериментальная модификация операционной системы OS/360 для изучения проблем, связанных с системами защиты. Используя ее, корпорация TRW разработала монитор, действующий в заранее установленные интервалы времени и пытающийся обнаружить признаки того, что программа пользователя нарушила правила защиты.

Этот монитор проверяет много различных условий. Большинство из них характерно именно для OS/360 и поэтому интересны не для всех. В качестве некоторых примеров, можно, однако, указать, что монитор определяет, вся ли управляющая информация OS/3CO о задачах пользователя хранится в защищенной области памяти. Монитор также проверяет, всели программы пользователя выполняются в режиме задачи и вся ли память пользователя защищена от выборки соответствующим ключом защиты. Монитор контролирует правильность соблюдения очереди ожидающими операциями ввода-вывода и гарантирует, что точки входа для всех прерываний являются соответствующими входами OS/360 и что вся память супервизора надлежащим образом защищена. Как только обнаруживается какое-то несоответствие, немедленно выдается сообщение оператору.

Если предполагать, что в программном обеспечении какие-то ошибки все же будут, то лучшая (после предупреждения ошибок) стратегия — включить средства обнаружения ошибок в само про-граммное обеспечение.

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

{SITELINK-S405}Меры по обнаружению ошибок {/SITELINK}можно разбить на две под-группы: пассивные

попытки обнаружить симптомы ошибки в про-цессе «обычной» работы программного обеспечения и активные

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

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

Разрабатывая эти меры, мы будем опираться на следующее.

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

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

3. Избыточность.
Все средства обнаружения ошибок основаны на некоторой форме избыточности (явной или неявной).

Когда разрабатываются {SITELINK-S405}меры по обнаружению ошибок{/SITELINK}, важ-но принять согласованную стратегию для всей системы. Действия, предпринимаемые после обнаружения ошибки в программном обеспечении, должны быть единообразными для всех компонен-тов системы. Это ставит вопрос о том, какие именно действия следует предпринять, когда ошибка обнаружена. Наилучшее решение — немедленно завершить выполнение программы или (в случае операционной системы) перевести центральный про-цессор в состояние ожидания. С точки зрения предоставления че-ловеку, отлаживающему программу, например системному про-граммисту, самых благоприятных условий для диагностики оши-бок немедленное завершение представляется наилучшей стратегией. Конечно, во многих системах подобная стратегия бывает нецелесообразной (например, может оказаться, что при-останавливать работу системы нельзя). В таком случае использу-ется метод регистрации ошибок.
Описание симптомов ошибки и «моментальный снимок» состояния системы сохраняются во внеш-нем файле, после чего система может продолжать работу. Этот файл позднее будет изучен обслуживающим персоналом.

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

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

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

Диагностический монитор можно реализовать как периоди-чески выполняемую задачу (например, она планируется на каж-дый час) либо как задачу с низким приоритетом, которая плани-руется для выполнения в то время, когда система переходит в со-стояние ожидания. Как и прежде, выполняемые монитором конкретные проверки зависят от специфики системы, но некото-рые идеи будут понятны из примеров. Монитор может обследо-вать основную память, чтобы обнаружить блоки памяти, не вы-деленные ни одной из выполняемых задач и не включенные в си-стемный список свободной памяти. Он может проверять также необычные ситуации: например, процесс не планировался для выполнения в течение некоторого разумного интервала времени. Монитор может осуществлять поиск «затерявшихся» внутри си-стемы сообщений или операций ввода-вывода, которые необыч-но долгое время остаются незавершенными, участков памяти на диске, которые не помечены как выделенные и не включены в спи-сок свободной памяти, а также различного рода странностей в файлах данных.

Иногда желательно, чтобы в чрезвычайных обстоятельствах монитор выполнял диагностические тесты системы. Он может вы-зывать определенные системные функции, сравнивая их результат с заранее определенным и проверяя, насколько разумно время вы-полнения. Монитор может также периодически предъявлять сис-теме «пустые» или «легкие» задания, чтобы убедиться, что система функционирует хотя бы самым примитивным образом.

Значительная часть производственного процесса опирается на тестирование программ. Что это такое и как осуществляется подобная деятельность обсудим в данной статье.

Что называют тестированием?

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

Эффективность

То, насколько хорошо и быстро находятся ошибки, существенным образом влияет на стоимость и длительность разработки программного обеспечения необходимого качества. Так, несмотря на то, что тестеры получают заработную плату в несколько раз меньшую, чем программисты, стоимость их услуг обычно достигает 30 — 40 % от стоимости всего проекта. Это происходит из-за численности личного состава, поскольку искать ошибку — это необычный и довольно трудный процесс. Но даже если программное обеспечение прошло солидное количество тестов, то нет 100 % гарантии, что ошибок не будет. Просто неизвестно, когда они проявятся. Чтобы стимулировать тестеров выбирать типы проверки, которые с большей вероятностью найдут ошибку, применяются различные средства мотивации: как моральные, так и материальные.

Подход к работе

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

Что такое тест?

Это немаловажный аспект деятельности проверяющего, который необходим для успешного выявления недочетов программного кода. Они необходимы для того, чтобы контролировать правильность приложения. Что входит в тест? Он состоит их начальных данных и значений, которые должны получиться как результирующие (или промежуточные). Для того чтобы успешнее выявлять проблемы и несоответствия, тесты необходимо составлять после того, как был разработан алгоритм, но не началось программирование. Причем желательно использовать несколько подходов при расчете необходимых данных. В таком случае растёт вероятность обнаружения ошибки благодаря тому, что можно исследовать код с другой точки зрения. Комплексно тесты должны обеспечивать проверку внешних эффектов готового программного изделия, а также его алгоритмов работы. Особенный интерес предоставляют предельные и вырожденные случаи. Так, в практике деятельности с ошибками часто можно выявить, что цикл работает на один раз меньше или больше, чем было запланировано. Также важным является тестирование компьютера, благодаря которому можно проверить соответствие желаемому результату на различных машинах. Это необходимо для того, чтобы удостовериться, что программное обеспечение сможет работать на всех ЭВМ. Кроме того, тестирование компьютера, на котором будет выполняться разработка, является важным при создании мультиплатформенных разработок.

Искусство поиска ошибок

Программы часто нацелены на работу с огромным массивом данных. Неужели его необходимо создавать полностью? Нет. Широкое распространение приобрела практика «миниатюризации» программы. В данном случае происходит разумное сокращение объема данных по сравнению с тем, что должно использоваться. Давайте рассмотрим такой пример: есть программа, в которой создаётся матрица размером 50×50. Иными словами — необходимо вручную ввести 2500 тысячи значений. Это, конечно, возможно, но займёт очень много времени. Но чтобы проверить работоспособность, программный продукт получает матрицу, размерность которой составляет 5×5. Для этого нужно будет ввести уже 25 значений. Если в данном случае наблюдается нормальная, безошибочная работа, то это значит, что всё в порядке. Хотя и здесь существуют подводные камни, которые заключаются в том, что при миниатюризации происходит ситуация, в результате которой изменения становятся неявными и временно исчезают. Также очень редко, но всё же случается и такое, что появляются новые ошибки.

Преследуемые цели

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

Проверка в различных условиях

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

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

Тестирование ПО: виды

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

Завершение тестирования

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

Автоматизированное тестирование

Ранее считалось, что динамический анализ разработанного ПО — это слишком тяжелый подход, который неэффективно использовать для обнаружения дефектов. Но из-за увеличения сложности и объема программ появился противоположный взгляд. Автоматическое тестирование применяется там, где самыми важными приоритетами является работоспособность и безопасность. И они должны быть при любых входных данных. В качестве примера программ, для которых целесообразным является такое тестирование, можно привести следующие: сетевые протоколы, веб-сервер, sandboxing. Мы далее рассмотрим несколько образцов, которые можно использовать для такой деятельности. Если интересуют бесплатные программы тестирования, то среди них качественные найти довольно сложно. Но существуют взломанные «пиратские» версии хорошо зарекомендовавших себя проектов, поэтому можно обратиться к их услугам.

Avalanche

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

KLEE

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

Компьютеры Определение и принципы тестирования

просмотров — 190

ТЕСТИРОВАНИЕ ПРОГРАММНОГО ИЗДЕЛИЯ

Тестирование является одним из этапов жизненного цикла ПИ, направленным на повышение качественных характеристик. При создании типичного ПИ около 40% общего времени и более 40% общей стоимости расходуется на проверку (тестирование) разрабатываемой программы.

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

— отсутствие эталона (программы), которому должна соответствовать тестируемая программа;

— высокая сложность программ и принципиальная невозможность исчерпывающего тестирования;

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

Применительно к ПИ тестирование — это процесс многократного выполнения программы с целью обнаружения ошибок.

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

Программа тестируется для того, чтобы повысить уровень ее надежности, ᴛ.ᴇ. выявить максимальное число ошибок.

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

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

Принцип 1. Процесс тестирования более эффективен, если проводится не автором программы.

Из определения тестирования как процесса, направленного на выявление ошибок, ясно, что тестирование тем эффективней, чем больше ошибок выявлено. Тестовый прогон, в результате которого не выявлено ошибок, считается неудачным (неэффективным). Τᴀᴋᴎᴍ ᴏϬᴩᴀᴈᴏᴍ, тестирование — это процесс деструктивный (разрушительный). Именно этим и объясняется, почему многие считают его трудным. Особенно трудным и малоэффективным он является для самого автора программы, так как после выполнения конструктивной части при проектировании и написании программы ему трудно перестроиться на деструктивный образ мышления и, создав программу, тут же приступить к пристрастному выявлению в ней ошибок. Очевидно, что обнаружение недостатков в своей деятельности противоречит человеческой психологии.

Это не означает, что программист не может тестировать свою программу. Речь идет о повышении эффективности тестирования.

Все эти рассуждения не относятся к отладке, ᴛ.ᴇ. к исправлению уже известных ошибок. Она эффективнее выполняется самим автором программы.

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

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

Τᴀᴋᴎᴍ ᴏϬᴩᴀᴈᴏᴍ, тестовый набор данных должен включать два компонента: описание входных данных и описание точного и корректного результата͵ соответствующего набору входных данных.

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

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

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

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

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

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

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

Принцип 5. Необходимо проверять не только, делает ли программа то, для чего она предназначена, но и не делает ли она то, что не должна делать.

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

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

Это свойство ошибок группироваться объясняется тем, что части программы, где при тестировании обнаружено большее число ошибок, либо были слабо проработаны идеологически, либо разрабатывались программистами более низкой квалификации. К примеру, в одной из версий ОС/370 47% ошибок, обнаруженных пользователями в процессе первых лет эксплуатации (после полного ее тестирования), приходились на 4% модулей.

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

Итак, нужно помнить и знать, что:

— тестирование — это процесс многократного выполнения программы с целью выявления ошибок;

— тестовый прогон считается удачным, если он позволяет выявить ошибки, а тот тестовый набор эффективен, который имеет высокую вероятность обнаружения большего числа ошибок;

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