Методы и стандарты тестирования программного обеспечения

2. МЕТОДЫ ОТЛАДКИ ПО

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

- Ручное тестирование;

- Прологи;

- Снижения;

- Обратная трассировка.

• Метод ручного тестирования.

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

• Метод пролога.

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

• Метод снижения.

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

• Метод обратной трассировки.

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

 

3. СТАНДАРТЫ ТЕСТИРОВАНИЯ ПО

1. СТАНДАРТ ГОСТ Р 12119-2000 «ИТ. ПАКЕТЫ ПРОГРАММ. ТРЕБОВАНИЯ К КАЧЕСТВУ И ТЕСТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИ»

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

Стандарт устанавливает:

- требования к пакетам  программ (требования к их качеству);

- инструкции по испытанию  пакета программ на соответствие  его установленным требованиям  (инструкции по тестированию, в  частности по тестированию третьей  стороной).

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

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

Пользователями настоящего стандарта являются:

a) поставщики, когда они:

1) определяют требования  к пакету программ;

2) проектируют формат  для описания продуктов;

3) оценивают собственные  продукты;

4) выпускают декларации  о соответствии (Руководство ИСО/МЭК  22 [1]);

5) обращаются за сертификатами  или знаками соответствия (Руководство  ИСО/МЭК 23 [2]);

b) органы по сертификации, которые хотят применять схему  сертификации третьей стороной (международные,  региональные или национальные) (Руководство ИСО/МЭК 16 [3], Руководство  ИСО/МЭК 28 [4] и Руководство ИСО/МЭК  44 [5]);

c) испытательные лаборатории,  которые желают соблюдать инструкции  по тестированию при проведении  тестирования для выдачи сертификата  или знака соответствия (Руководство  ИСО/МЭК 25 [6]);

d) аккредитующие органы, проводящие аккредитацию органов  по сертификации и испытательных  лабораторий (Руководство ИСО/МЭК 40 [7] и Руководство ИСО/МЭК 58 [8]);

2. СТАНДАРТ ГОСТ Р ИСО/МЭК 12207-2012 «ИТ. ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ»

Один из базовых стандартов в области ИТ – стандарт ISO/IEC 12207:2008 Systems and Software Engineering – Software Life Cycle Processes. Его российский аналог, ГОСТ Р ИСО/МЭК 12207:2010 «Системная и программная инженерия. Процессы жизненного цикла программных средств», введен в действие весной 2012 года.

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

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

Термины и определения  относящиеся к тестированию, выбранные из стандарта ИСО/МЭК 12207-2010

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

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

4.51 тестовое покрытие (test coverage): Степень, с которой данный тест проверяет требования для системы или программного продукта

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

Технические процессы

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

если он не используется при оказании услуги.

Технические процессы состоят из следующих процессов:

a) определение требований  правообладателей (специальный случай  процесса определения требований  правообладателей, приведенного в  [18]);

b) анализ системных  требований (специальный случай  процесса анализа требований);

c) проектирование архитектуры  системы (специальный случай процесса  проектирования архитектуры, приведенного  в [18]);

d) процесс реализации (специальный  случай процесса реализации элементов  системы, приведенного в [18] и  далее разработанного в разделе  7 настоящего стандарта как процесса  реализации программных средств);

e) процесс комплексирования  системы (специальный случай процесса  комплексирования, приведенного в  [18]);

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

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

h) процесс поддержки  приемки программных средств  (процесс, который способствует  достижению результатов процесса  передачи, приведенного в [18]);

i) процесс функционирования  программных средств (специальный  случай процесса функционирования, приведенного в [18]);

j) процесс сопровождения  программных средств (специальный  случай процесса сопровождения,  приведенного в [18]);

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

Далее представлены несколько пунктов выбранные из стандарта:

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

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

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

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

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

В результате успешного  осуществления анализа системных требований:

a) устанавливается определенная  совокупность системных функциональных  и нефункциональных требований, описывающих проблему, подлежащую решению;

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

c) системные требования  анализируются на корректность  и тестируемость;

d) осмысливается воздействие  системных требований на среду применения;

e) требования расставляются  по приоритетам, утверждаются и обновляются;

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

g) оцениваются изменения  базовой линии по стоимости,  графикам работ и воздействию технических решений;

h) системные требования  доводятся до сведения всех  участвующих сторон и включаются  в базовую линию.

6.4.2.3.2.1 Системные требования  должны оцениваться на основе  перечисленных ниже критериев:

a) прослеживаемость потребностей по приобретению;

b) согласованность с  потребностями по приобретению;

c) тестируемость;

d) осуществимость архитектурного  проекта системы;

e) осуществимость функционирования  и сопровождения. 
 6.4.5.3.2 Готовность к тестированию. Данный вид деятельности состоит из решения следующих задач:

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