Отладка и тестирование программ: основные подходы и ограничения (Основные методы тестирования)

Содержание:

Введение

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

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

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

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

В своей курсовой работе, я использовал литературу:

1) Тестирование и отладка программ для профессионалов будущих и настоящих, Автор этой книги Пласкин М.А, выпущена в 2013 году издательством:

БИНОМ. Лаборатория знаний

2) Методы тестирования программного обеспечения, Автор этого учебного пособия И.В Степанченко, выпущена в 2006 году, издательством:

РПК политехник

3) Тестирование программного обеспечения (На русском языке), авторы этой книги Cem Kaner, Jack L. Falk, выпущена в 1999 году, издательством:

ДиаСофт

Цель данной курсовой работы является:

1) Рассказать об основных методах тестирований

2) Рассмотреть тестирование программного обеспечения на основе методов черного и белого ящика

3) Провести анализ ошибок

1. Основные методы тестирования

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

Перед началом тестирования следует установить цели, которые должны быть получены в ходе тестирования. В частности, набор тестов должен быть полон с точки зрения выбранных критериев полноты тестирования. Независимо от применяемых критериев разработка тестов должна вестись систематически, по определенной методике. (М.а, 2013)^[1]

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

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

Необходимость этого подчеркивал логик в работе: «Проблема может быть охарактеризована как факт или группа фактов, которые не имеют приемлемого объяснения, которые кажутся необычными или которые не удается подогнать под наши представления или предположения. Очевидно, что если что-нибудь подвергается сомнению, то об этом должна иметься какая-то предварительная информация. Если нет предположений, то не может быть и неожиданных результатов».^[2]

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

К сожалению, исполнения этого в целом правильного принципа не всегда возможна в силу трех факторов:

1) ресурсы разработки, недостаточны;

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

3) необходим высокий уровень ведения разработки; (И.В, 2006)^[3]

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

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

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

Работа программирующей организации или ее руководителя оценивается по их способности производить программы в течение заданного времени и определенной стоимости. Одна из причин такой системы оценок состоит в том, что временные показатели легко измерить, но в то же время чрезвычайно трудно количественно оценить надежность программы. Именно поэтому в процессе тестирования программирующей организации трудно быть объективной, потому что тестирование в соответствии с данным определением может быть рассмотрено как средство уменьшения вероятности соответствия программы заданным временным параметрам. Как и ранее, из сказанного не следует, что программирующая организация не может найти свои ошибки; тестирование в определенной степени может пройти успешно. Мы утверждаем здесь лишь то, что экономически более целесообразно выполнение тестирования каким-либо объективным, независимым подразделением. В некоторых организациях подобная практика существует, но только на этапах комплексной отладки. Подобный способ тестирования чрезвычайно сложно реализовать из-за организационных трудностей. (И.В, 2006)^[5]

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

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

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

Необходимо проверить программу на побочные эффекты.

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

Недопустимо ради упрощения тестирования изменять программу.

Тестировать вы будете уже другую программу.

После изменений в программе необходимо повторное тестирование.

Чтобы исправить ошибку, мы вносим изменения в программу. Нельзя гарантировать, что, исправив одну ошибку, мы не внесем другую. Вероятность внесения новой ошибки при исправлении старой оценивается в 20–50%. Для особо сложных систем эта вероятность может быть значительно выше. (М.а, 2013)^[6]

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

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

Для тестирования большого программного обеспечения требуется большой творческий потенциал по сравнению с её проектированием, так как, нельзя дать гарантию, что построенный текст сможет обнаруживать все ошибки. (И.В, 2006)^[7]

Разработка тестов

Характеристики хорошего теста:^[8]

1. Вероятность обнаружение тестом ошибок
2. Набор тестов не должен быть избыточным
3. Тест должен быть лучшим в категории
4. Тест не должен быть сильно простым или сложным

(Cem Kaner, 1999)

Минимально грубое тестирование^[9] – это критерий покрытия решений, условий по проверке циклов

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

(М.а, 2013)

Проектирование теста включается в этапы:^[10]

1. Понять цель теста
2. Входные значения
3. Предполагаемые выходные значения
4. Выполнить тест и записать результат
5. Анализировать результат

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

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

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

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

Обоснованная вероятность выявления ошибок - цель этого тестирования является, выявление ошибок.

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

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

Не слишком сложный и не слишком простой – если объединить два теста, можно сэкономить время, но не переусердствуйте – огромный и сложный тест трудно понять. Кроме трудоемкости у сложных тестов есть свои недостатки. После первого недопустимого значения работоспособность программы выйти из-под контроля.^[11] (Cem Kaner, 1999)

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

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

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

Следует помнить, что задача тестирования заключается не в показе правильно работы программы, а в выявление ошибок. (И.В, 2006)^[12]

Безмашинное тестирование^[13] – для начинающих программистов тестирование подразумевает непременный прогон программы на компьютере.

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

1. Сухая прокрутка

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

Program p;

Var k, n: integer;

Sum: integer;

Begin

Writeln (‘Я считаю сумму квадратов чисел от 1 до 5’);

N: = 5;

Sum: = 0;

For k: = 1 to n do

Sum: = sum + k*k;

Writeln (‘Сумма квадратов чисел от 1 до ‘, n,’=’, sum)

End. {P}

Трассировочная таблица выглядит так:^[14] (М.а, 2013)

n	sum	k
5
	0
		1
	1
		2
	5
		3
	14
		4
	30
		5
	55

2) Символическая прокрутка – в этом варианте не нужно подставлять значения переменных. Вместо этого нужно много анализировать ход программы.

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

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

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

5) Искусственное внесение ошибок в программу – мощный прием, с психологической точки зрения. После внесения в программу искусственных ошибок, этот психологический стопор снимается.

Некорректное поведение программы проявляется с достаточной очевидностью^[16] - тут есть над чем подумать, неверные выходные данные на экране или бумаги, тестировщик может пропустить.

1) Разрабатывая тест, нужно подробно описать выходные данные и реакцию программы.

2) Нужно постараться выполнять тесты так, чтобы объём выходных данных был минимален.

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

Классы эквивалентности – группа тестов, это класс эквивалентности, если есть условия

1) Все тесты нужны для выявления одинаковой ошибки.

2) Если один из тестов выявит ошибку, остальные тоже выявят её

3) Если один из тестов не выявит ошибки, остальные тоже не выявят её. В результате всех тестов выявляется значение одних и тех же выходных данных. (Cem Kaner, 1999)

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

Пример:

Program p;

Var a, b, c: integer:

Begin

Repeat

Read (a);

B: = b + 1;

C: = c + a

Until a=0;

Writeln(c/b)

End.

По принципу 5 (Искусственное внесение ошибок в программу), перед тем как начать тестировать программу, нужно сформулировать цель тестирования.

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

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

Выделение классов входных и выходных данных в задаче не очевидно. Упорядоченность не важна. Проверка длины последовательности имеет значение. (М.а, 2013)^[17]

Поиск классов эквивалентности - Поиск классов эквивалентности, это процесс субъективный. Два челове­ка, анализирующих одну и ту же программу, составят различные классы. Однако постарайтесь все же выявить больше классов эквивалентности: это сэкономит время в дальнейшем и сделает тестирование более эффективным. Вот несколько рекомендаций для поиска классов эквивалентности: (Cem Kaner, 1999)^[18]

1) Не забывайте о классах, охватывающих верны и неверные входные данные

2) Организуйте формируемые классы, в виде таблицы

3) Определите диапазоны числовых значений

4) Анализируйте возможные результаты

5) Поищите переменные, значения должны быть равными

6) Найти классы значений, зависящих от времени

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

8) Какие действия программа отвечает эквивалентными событиями

9) Продумать варианты окружения.

Не забывайте о классах, недопустимых входных данных^[19] - часто недопустимые входные данные вызывают в программе разнообразные ошибки. Поэтому, чем больше выделите типов неверного ввода, тем больше ошибок будет обнаружено. Существует как минимум 4 вида класса:

1) Допустим ввод чисел от 1 до 99

2) Любое число меньше 1 слишком мало

3) Любое число больше 99 слишком много

4) Если введена нечисловая информация, она не принимается.

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

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

(Cem Kaner, 1999)

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

Вот ряд примеров:

1) Если допустимы значения от 1 до 99, для тестирования допустимых данных можно выбрать 1 и 99, а для тестирования недопустимых — О и 100.

2) Если программа выписывает чеки на суммы от $1 до $99, то нужно попробовать выписать чек на отрицательную сумму, на $0, на $100.

3) Если программа рисует линии длиной от одной точки до 4 сантимет­ров, попробуйте нарисовать одну точку и линию длиной ровно 4 сантиметра.

4) Если сумма входных значений должна равняться 180, введите значения, дающие в сумме 179, 180 и 181.

5) Когда программа получает определенное количество входных данных, попробуйте ввести в точности необходимое количество, на единицу "меньшее и на единицу большее.

6) Если программа принимает ответы В, С и D, попробуйте ввести А и Е.

7) отправьте на печать файл перед и сразу после того, как принтер напечатает еще задание.

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

Анализируя границы диапазонов значений, обязательно учтите все возможные выходные данные. Проанализируйте каждый элемент распечат­ки или изображения на экране.^[20] (Cem Kaner, 1999)

Тестирование переходов между состояниями^[21] – если набор предлагаемых изменяется, это означает изменение состояния программы. Самый просто пример - меню. После запуска программы, имеется одна перечень команд. После того как выбрали одну их них состояние программы меняется и в меню появляются команды. Кроме того, на экране меняется информация: форма водных данных, просмотров.

Обязательно нужно протестировать каждую команду в меню. Команда 15 может быть доступная в режиме открываемой по команде 14 и по команде 27.

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

1) Тестируйте более вероятные последовательности действий пользователей.

2) Если предположить, что действия пользователя в одном ре­жиме могут воздействовать на представление данных или набор предоставляемых программой в другом режиме, про­ тестируйте эту зависимость.

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

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

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

Нагрузочные испытания – важно протестировать ограничения возможностей программного продукта. Нужно проверить размеры файлов, с которыми работает программа. Откройте максимальное количество файлов и другие данные. Если программа не справится с большим числом, которое пользователь может ввести, нужно составить отчет об ошибке. Если программа спокойно справляется и с очень маленькими и очень большими значениями параметров, возможно, что ограничений нет. (Cem Kaner, 1999)

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

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

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

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

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

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

4) Для отладки последовательностей на принтере можно перенаправить вывод в файл и то же самое сделать в эталонной программе, распечатав в ней точно такой же документ. Затем оба файла можно сравнить — они должны быть одинаковы.

Обязательно включайте в отчеты об ошибках выходные данные, полученные от обеих программ. Они очень важны для поиска причины ошибки.^[22] (Cem Kaner, 1999)

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

2 Тестирование программного обеспечения

Тестирование “Черного ящика”

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

Мартин и Мак-Клер (Martin & mcClure, 1983) подытожили собранные Боэмом (Boehm) данные об эффективности исправления найденных оши­бок.

• Если для исправления ошибки нужно изменить не более десяти операторов, вероятность того, что это будет сделано правильно с первого раза, составляет 50%.

• Если для исправления ошибки нужно изменить около пятидесяти операторов, вероятность того, что это будет сделано правильно с первого раза, составляет 20%.^[23]

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

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

тест для программы будет в любом случае неполным. Главной целью стратегии проектирования является уменьшение этой «неполноты» тестирования, насколько это возможно.^[24] (И.В, 2006)

тестирования функций^[25]- требуют набор тестов, чтобы был выполнен хотя бы один тест для любой из функций, использованной программой. (М.а, 2013)

Тестирования классов входных данных^[26]-это тестирование требует группировать входные данные, разделить их на группы, так чтобы все данные из одной группы, были равны с точки зрения проверки программы

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

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

Во-вторых, нужно пытаться разбить область программы на число классов эквивалента так, чтобы каждый тест был эквивалентен любому другому тесту этого класса. ^[27] (И.В, 2006)

Как и все программные обеспечения, тестирование начинается со стадии планирования, обдумываются стратегии, серии тестов и распределение между сотрудниками задачи. Планирование начинается сразу, после того как проектировщики выдают программные требования. ^[28]

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

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

Когда программное обеспечение готово и протестировано, он должен пройти еще ряд последних тестов.

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

Бета-тестирование – подтверждение, что программа достаточно стабильна. На этом этапе с программой начинают работать её потенциальные пользователи.

И пользователи понимают, что в бета-тестирование еще могу быть серьёзные ошибки. (Cem Kaner, 1999).

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

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

1. Нормальный условия (Средний класс)
2. Граничные (Экстремальные) условия
3. Исключительные (Выход за границу класса)^[29] (М.а, 2013)

Тестирование целостности готового продукта и тестирование копий^[30]

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

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

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

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

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

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

Для программы средней сложности уйдет около двух недель. (Cem Kaner, 1999)

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

Тестирование “Стеклянного(белого) ящика”

Эта технология называется “тестирование стеклянного ящики” или ее еще могут называть “Тестирование белого ящика”.^[31]

Тестирование “Черного ящика” программу рассматривали как, тестирование объекта у которого внутренняя структура неизвестна. При тестировании “Стеклянного ящика’ ситуация другая. Программист уже разрабатывает тесты на основе исходного кода, к которому у него есть доступ, в результате он имеет преимущества:

1. Направленность тестирования – программист может частями тестировать программу.
2. Полный охват кода – программист всегда определяет какие фрагменты работают в тексте.
3. Управление потоком – программист всегда знает, какая задача должна быть следующей и как она должна работать.
4. Отслеживание целостности данных – программисту всегда известно, какая часть должна изменять элемент данных.
5. Внутренние граничные точки – в исходном коде видны граничные точки, которые скрыты от взгляда
6. Тестирование выбранным алгоритмом – программисту нужно точно знать, какие алгоритмы используются, и обратиться к специальной литературе.

Тестирование ‘Стеклянного ящика” – это часть в процессе программирования. Программисты тестируют каждый модуль после его написания. (Cem Kaner, 1999)

В этом случае тестирующий получает тестовые данные путем анализа логики программы. Незнающему может показаться, что можно построить набор тестов, в котором каждый оператор исполняется хотя бы один раз; нетрудно показать, что это неверно. Подразумевается, что программа проверена полностью, с помощью тестирований можно осуществить выполнение этой программы по всем возможным путям ее потока передач управления^[32]. (И.В, 2006)

Структурное тестирование против функционального.^[33]

Структурное тестирование – это один из видов тестирования “стеклянного ящика”. Главная идея этого тестирования является правильным выбором тестирования программного пути.

Функциональное тестирование – это один из видов тестирования “Черного ящика”. Каждая функция тестируется вводом её входных данных и анализа выходных.

Тестирование частей против тестирования целого.

Можно тестировать - сначала отдельные части, а потом их взаимодействие. Такая стратегия называется восходящей.

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

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

Самым главным недостатком восходящего тестирования является необходимость написания кода оболочки

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

1. Очень трудно найти источник ошибки
2. Трудно организовать исправление ошибки (Cem Kaner, 1999)

В заключение можно отметить, что, исчерпывающее входное тестирование предпочтительнее исчерпывающего тестирования путей, ни то, ни другое не могут стать полезными стратегиями, потому что они невозможны. Поэтому реальным путем, который позволит создать хорошую, но, конечно, не абсолютную стратегию, является совмещение тестирования программы черного и белого ящиков.^[34] (И.В, 2006) Вывод: При написании программного обеспечения, программист должен не раз приходить к схемам ящиков.

Типы ошибок

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

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

1. Структурные ошибки
2. Ошибки компиляции
3. Ошибки периода выполнения

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

Ошибки компиляции – возникают из-за ошибки кода. (И.В, 2006)

Функциональность – функциональные недостатки бывают, когда программа не делает что должна.

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

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

Ошибки вычисления – самая основная ошибка, это ошибки округления. После промежуточных вычислений может оказаться, что 2+2=1. Даже если в этих этапах не было ошибок. (Cem Kaner, 1999)^[36]

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

Можно прийти к заключению, что все типы ошибок по первой классификации

При тестировании, приходится иметь дело с ошибками периода выполнения. (И.В, 2006)

Ошибки управлением потока^[37] – такие ошибки пропустить сложно, в самом плохом случае в работе произойдет сбой, а если ошибка менее серьёзна, то забредет не туда.

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

Перегрузки – Программа может не справляться с напряжением. Программного обеспечение может не выдерживать долгого использования. У каждой программы свои пределы. (Cem Kaner, 1999)

Программные ошибки классифицируют по нарушению логики на:^[38]

1. Синтаксические
2. Семантические
3. Прагматические

Синтаксические ошибки – заключаются в правописание или пунктуации. В качестве примеров синтаксических ошибок можно назвать:

1. Пропуск знака пунктуации
2. Несогласованность скобок
3. Пропуск скобок
4. Неверное написание слов
5. Отсутствие написание массива

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

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

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

1. Ошибка адресации – неправильная адресация данных
2. Ошибка ввода и вывода – возникает в процессе обмена данных
3. Ошибка вычисления
4. Ошибка интерфейса – несовпадение фактических и формальных параметров
5. Ошибка обращения к данным – возникает при обращении к данным
6. Ошибка описании данных –ошибка описания данных (И.В, 2006)

Анализ ошибок и их место проявления

На каком этапе работы может быть ошибка: ^[39]

1. При постановке задачи
2. При проектировании программы
3. При написании текста

Результаты анализа ошибок полезно заносить в отчет отладки. (М.а, 2013)

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

Если тестируемый программный продукт состоит из нескольких программ, то следует обязательно указать в какой из программ обнаружена та или иная ошибка.^[40] (Cem Kaner, 1999)

Первичное выявление ошибок^[41]

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

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

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

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

Можно прийти к выводу, что ручное тестирование, нужно проводить начальном этапе. (И.В, 2006)

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

Подробное описание проблемы и как её воспроизвести.

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

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

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

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

Главные цели анализа таковы:

1. Выявить серьёзные последствия проблемы.
2. Найти краткий путь к ее воспроизводству.
3. Найти альтернативный путь к этому результату.
4. Выявить связанные проблемы.

Наиболее серьёзные последствия проблемы

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

Сбой программы – это:

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

В непредусмотренном состоянии ошибки неминуемы. Часто случается, что блок ошибок сам содержит ошибку гораздо более серьёзную. Если программа сообщает об ошибке, искажает информацию или делает что либо, следует ждать дальнейших ошибок. ^[43] (Cem Kaner, 1999)

Кратчайший путь воспроизведения ситуации

Бывает такое, что воспроизвести ошибку не так-то просто. Но в любом случае, когда описываете путь её воспроизведения имейте в виду:^[44]

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

Уменьшая количество шагов, это упрощает область поиска источника ошибки. Благодаря этому ошибку в программе найти легче.

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

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

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

Связанные проблемы.

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

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

Выделение критического момента.

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

Выполняя каждый шаг воспроизведения ошибки, внимательно наблю­дайте за происходящем в программе, стараясь заметить любое отклонение, малейший намек на то, если что-то пойдет не так. Такие незначительные от­клонения легко пропустить, а между тем, они могут быть первыми симптомами анализируемой вами ошибки. Вот примеры симптомов. (Cem Kaner, 1999)

1. Сообщение об ошибках – нужно выяснить точно, в какой момент появилась эта ошибка.
2. Задержка обработки данных – всегда обращайте внимание на любые задержки и тщательно проверяйте полученные данные.
3. Мигание и обновление экрана – если экран вдруг, неожиданно мигнул, это может обозначать, что было обновлена обработка ошибок.
4. Перемещение курсора – курсор может переместиться в другое место. Это может быть сделано процедурой ошибки.
5. Несколько курсоров – если на экране появилось сразу два курсора, это означает, что программа находится в промежуточном состоянии или её работа нарушена.
6. Сдвинутый текст – текст на экране слегка сдвинуты. Может быть, сместилась только одна строка
7. Повторяющееся или пропущенные символы – компьютер печатает слово “ошииибка” вместо ошибка, это может быть опечаткой.
8. Горящий индикатор активности устройства – индикаторы активности имеются у многих устройств – они показывают, когда компьютер записывает данные в их память.^[45]

Отслеживание действий программы.

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

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

Это только два примера, они показывают, какие возможности раскрываются перед тестировщиком владеющим программированием.

Но не стоит тратить время на работу с отладчиком, очень много времени. Основная работа – это тестирование, а с отладчиком программист может поработать сам.

Еще одним способом анализа является распечатка её экранов и изменений в файле данных.

Если содержимое очень быстро меняется, можно попробовать менее скоростной компьютер. (Cem Kaner, 1999)

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

Поищите дальнейшие ошибки.

Даже если не удалось найти на каком этапе в программе находится ошибка, все равно нужно продолжить тестировать и смотреть, как она ведет себя дальше. После найденной ошибки с большей вероятностью последуют и другие, и информация о последствиях первой ошибки может очень помочь программисту. Но не нужно забывать, что следующая найденная ошибка не обязательно является следствием предыдущей. Поэтому старайтесь тестировать её отдельно.^[46] (Cem Kaner, 1999)

Поиск способа воспроизведения ошибки.

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

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

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

Если простое повторение пользователя не срабатывает, это ничего не значит. Существует множество ошибок, которые проявляют­ся только при определенных условиях, иногда в неожиданных. Ошибка на самом деле воспроизводима. Вопрос только в том, как найти условия, которые ее вызывают. И это проще сделать программисту, перед глазами которого программный код. Вот направления поиска источника ошибки.^[47] (Cem Kaner, 1999)

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

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

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

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

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

Ошибки ввода-вывода – правильны ли файлы, соответствует ли формат спецификации, подходит ли размер буфера, размеру записи, открыты ли файлы. (И.В, 2006)

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

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

Ошибка пользователя^[49] - Тестировщик может просто-напросто ошибиться. Если исчезли нужные данные, это может означать не ошибку программы, а то, что вы их случайно удалили. Но предполагать собственную ошибку тестировщику следует в самую после­днюю очередь. Тестировщик может допустить ошибку, которую очень часто будут допускать пользователи программы. Если она реагирует на эту ошибку неадекватно или последствия разру­шительны для данных, это уже серьезная проблема, о которой нужно составить отчет. Нельзя игнорировать такие ошибки, лучше проанализируйте происходящее и подумайте, как усовершенствовать про­грамму, чтобы сделать ее более стабильной.

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

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

Ошибка появляется при первом запуске – когда программа загружается первый раз, программы начинают считывать с диска информацию. Если при первом запуске программы файлы не содержат нуж­ной информации, программа может вести себя неправильно. Но при выходе программа сохранит в этих файлах правильные данные, и дальше все пойдет как нужно. Данная ошибка проявляется только один раз. Еще одна подобная ошибка может быть в неправильной программе собственной неинициализированной памяти. Такая ошибка может проявляться при одной последовательности выполнения программы и отсутствовать во всех других случаях^[50]. (Cem Kaner, 1999)

Ошибка с разрушенными данными^[51] - если данные в программе разрушены, это может быть вызвать сбой в её работе. Программа может увидеть разрушение данных и выдать сообщение об ошибке, а может просто вести себя странно.

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

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

Зависимость от ресурсов – пока один процесс печатает данные, другой должен ждать освобождения принтера. Если первому процессу выделено 90 % оперативной памяти, второму процессу придется тратить оставшиеся 10 %.

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

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

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

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

Заключение

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

Главная цель тестирования заключается в обнаружении ошибок и в последствии теста, их устранение

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

Методы тестирования программного обеспечения [Книга] / авт. И.В Степанченко. - [б.м.] : РПК политехник, 2006.

Тестирование и отладка программ для профессионалов будущих и настоящих [Книга] / авт. М.а Пласкин. - [б.м.] : БИНОМ. Лаборатория знаний, 2013.

Тестирование программного обеспечения [Книга] / авт. Cem Kaner Jack L. Falk. - [б.м.] : ДиаСофт, 1999.

1. Пласкин М.А Тестирование программного обеспечения для профессионалов будущих и настоящих ст-12 ↑

2. Степанченко И. В. МЕТОДЫ ТЕСТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ: с-17 ↑

3. Степанченко И. В. МЕТОДЫ ТЕСТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ: с-17 ↑

4. Пласкин М.А Тестирование программного обеспечения для профессионалов будущих и настоящих ст-12 ↑

5. Степанченко И. В. МЕТОДЫ ТЕСТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ: с-18 ↑

6. Пласкин М.А Тестирование программного обеспечения для профессионалов будущих и настоящих ст-13 ↑

7. Степанченко И. В. МЕТОДЫ ТЕСТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ: с-21 ↑

8. Martin & McClure – 1983 – тестирование программного обеспечения - 182 стр ↑

9. Пласкин М.А Тестирование программного обеспечения для профессионалов будущих и настоящих ст-27 ↑

10. Степанченко И. В. МЕТОДЫ ТЕСТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ: с-72 ↑

11. Martin & McClure – 1983 – тестирование программного обеспечения - 183 стр ↑

12. Степанченко И. В. МЕТОДЫ ТЕСТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ: с-73 ↑

13. Пласкин М.А Тестирование программного обеспечения для профессионалов будущих и настоящих ст-53 ↑

14. Пласкин М.А Тестирование программного обеспечения для профессионалов будущих и настоящих ст-54 ↑

15. Пласкин М.А Тестирование программного обеспечения для профессионалов будущих и настоящих ст-55 ↑

16. Martin & McClure – 1983 – тестирование программного обеспечения - 183 стр ↑

17. Пласкин М.А Тестирование программного обеспечения для профессионалов будущих и настоящих ст-57 ↑

18. Martin & McClure – 1983 – тестирование программного обеспечения - 184 стр ↑

19. Martin & McClure – 1983 – тестирование программного обеспечения - 185 стр ↑

20. Martin & McClure – 1983 – тестирование программного обеспечения - 190 стр ↑

21. Martin & McClure – 1983 – тестирование программного обеспечения - 193 стр ↑

22. Martin & McClure – 1983 – тестирование программного обеспечения - 195 стр ↑

23. Martin & McClure – 1983 – тестирование программного обеспечения - 81 стр ↑

24. Степанченко И. В. МЕТОДЫ ТЕСТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ: с-38 ↑

25. Пласкин М.А Тестирование программного обеспечения для профессионалов будущих и настоящих ст-19 ↑

26. Пласкин М.А Тестирование программного обеспечения для профессионалов будущих и настоящих ст-19 ↑

27. Степанченко И. В. МЕТОДЫ ТЕСТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ: с-48 ↑

28. Martin & McClure – 1983 – тестирование программного обеспечения - 82-83 стр ↑

29. Пласкин М.А Тестирование программного обеспечения для профессионалов будущих и настоящих ст-19 ↑

30. Martin & McClure – 1983 – тестирование программного обеспечения - 84-85 стр ↑

31. Martin & McClure – 1983 – тестирование программного обеспечения - 69 стр ↑

32. Степанченко И. В. МЕТОДЫ ТЕСТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ: с-14 ↑

33. Martin & McClure – 1983 – тестирование программного обеспечения - 72 стр ↑

34. Степанченко И. В. МЕТОДЫ ТЕСТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ: с-16 ↑

35. Степанченко И. В. МЕТОДЫ ТЕСТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ: с-23 ↑

36. Martin & McClure – 1983 – тестирование программного обеспечения - 98 стр ↑

37. Martin & McClure – 1983 – тестирование программного обеспечения - 99 стр ↑

38. Степанченко И. В. МЕТОДЫ ТЕСТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ: с-24 ↑

39. Пласкин М.А Тестирование программного обеспечения для профессионалов будущих и настоящих ст-93 ↑

40. Martin & McClure – 1983 – тестирование программного обеспечения - 102 стр ↑

41. Степанченко И. В. МЕТОДЫ ТЕСТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ: с-27 ↑

42. Martin & McClure – 1983 – тестирование программного обеспечения - 109 стр ↑

43. Martin & McClure – 1983 – тестирование программного обеспечения - 116 стр ↑

44. Martin & McClure – 1983 – тестирование программного обеспечения - 120 стр ↑

45. Martin & McClure – 1983 – тестирование программного обеспечения - 120 стр ↑

46. Martin & McClure – 1983 – тестирование программного обеспечения - 121 стр ↑

47. Martin & McClure – 1983 – тестирование программного обеспечения - 123 стр ↑

48. Степанченко И. В. МЕТОДЫ ТЕСТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ: с-34 ↑

49. Martin & McClure – 1983 – тестирование программного обеспечения - 124 стр ↑

50. Martin & McClure – 1983 – тестирование программного обеспечения - 125 стр ↑

51. Martin & McClure – 1983 – тестирование программного обеспечения - 126 стр ↑