Процесс выполнения программы с намерением найти ошибки
Тестирование (testing) — процесс выполнения программы (или части программы) с намерением (или целью) найти ошибки.
Доказательство (proof) — попытка найти ошибки в программе безотносительно к внешней для программы среде.
Контроль (verification) — попытка найти ошибки, выполняя программу в тестовой, или моделируемой, среде.
Испытание (validation) — попытка найти ошибки, выполняя программу в заданной реальной среде.
Аттестация (certification) — авторитетное подтверждение правильности программы. При тестировании с целью аттестации выполняется сравнение с некоторым заранее определенным стандартом.
Отладка (debugging) не является разновидностью тестирования. Хотя слова «отладка» и «тестирование» часто используются как синонимы, под ними подразумеваются разные виды деятельности.
Тестирование модуля, или автономное тестирование ( module testing , unit testing ), — контроль отдельного программного модуля, обычно в изолированной среде (т. е. изолированно от всех остальных модулей). Тестирование модуля иногда включает также математическое доказательство.
Тестирование сопряжений ( integration testing ) — контроль сопряжений между частями системы (модулями, компонентами, подсистемами).
Тестирование внешних функций (external function testing) — контроль внешнего поведения системы, определенного внешними спецификациями.
Комплексное тестирование ( system testing ) — контроль и/или испытание системы по отношению к исходным целям. Комплексное тестирование является процессом контроля, если оно выполняется в моделируемой среде, и процессом испытания, если выполняется в среде реальной, жизненной.
Тестирование приемлемости ( acceptance testing ) — проверка соответствия программы требованиям пользователя.
Тестирование настройки ( installation testing ) — проверка соответствия каждого конкретного варианта установки системы с целью выявить любые ошибки, возникшие в процессе настройки системы.
Аксиомы (принципы) тестирования
u Хорош тот тест, для которого высока вероятность обнаружить ошибку
u Одна из самых сложных проблем при тестировании — решить, когда нужно его закончить.
u Не нужно тестировать свою собственную программу.
u Необходимая часть всякого теста — описание ожидаемых выходных данных или результатов.
u Избегайте невоспроизводимых тестов, не тестируйте «с лету».
u Готовьте тесты как для правильных, так и для неправильных входных данных.
u Детально изучите результаты каждого теста.
u По мере того как число ошибок, обнаруженных в некотором компоненте программного обеспечения, увеличивается, растет относительная вероятность существования в нем необнаруженных ошибок.
u Поручайте тестирование самым способным программистам.
u Проект системы должен быть таким, чтобы каждый модуль подключался к системе только один раз.
u Никогда не изменяйте программу, чтобы облегчить ее тестирование.
u Тестирование, как почти всякая другая деятельность, должно начинаться с постановки целей.
Приведем еще раз три наиболее важных принципа тестирования.
1. Тестирование — это процесс выполнения программ с целью обнаружения ошибок.
2. Хорошим считается тест, который имеет высокую вероятность обнаружения еще не выявленной ошибки.
3. Удачным считается тест, который обнаруживает еще не выявленную ошибку.
Рисунок 8 График соотношения между обнаруженными и необнаруженными ошибками
Модель Шумана
Модель Шумана строится на основе нескольких критериев:
¾ общее число команд в программе на машинном языке постоянно;
¾ в начале компоновочных испытаний число ошибок равно некоторой постоянной величине, и по мере исправления ошибок их становится меньше. В ходе испытаний программы новые ошибки не вносятся;
¾ ошибки изначально различимы, по суммарному числу исправленных ошибок можно судить об оставшихся;
¾ интенсивность отказов программы пропорциональна числу остаточных ошибок.
(1)
где I -- общее число машинных команд, которое предполагается постоянным в рамках этапа тестирования.
где С -- некоторая постоянная, t - время работы программы без отказов.
(2)
(3)
(4)
где Ai - количество ошибок на i - ом прогоне
Тогда .(5)
(6)
(7)
Из соотношений (6) и (7) найдем неизвестный параметр С и М:
(8)
(9)
Получив неизвестные M * и C * , можно рассчитать надежность программы по формуле (2).
Пример 1.
Программа содержит 2 000 командных строк, из них, до начала эксплуатации (после периода отладки), 15 командных строк содержат ошибки. После 20 дней работы обнаружена 1 ошибка. Найти среднее время безошибочной работы программы и интенсивность отказов программы при коэффициенте пропорциональности, равном 0,7.
Презентация на тему: " Тестирование программных средств Тема 11. Тестирование – процесс выполнения программы с намерением найти ошибки Цель проверяющего (тестовика) заставить." — Транскрипт:
1 Тестирование программных средств Тема 11
2 Тестирование – процесс выполнения программы с намерением найти ошибки Цель проверяющего (тесто вика) заставить программу сбиться. Роль тестирования состоит в том, чтобы определить местонахождение немногочисленных ошибок, оставшихся в хорошо спроектированной программе.
3 Основные определения Тестирование (testing) процесс выполнения программы (или части программы) с целью найти ошибки. Доказательство (proof) попытка найти ошибки в программе безотносительно к внешней для программы среде. Большинство методов доказательства предполагает формулировку утверждений о поведении программы и затем вывод и доказательство математических теорем о правильности программы. Доказательства могут рассматриваться как форма тестирования, хотя они и не предполагают прямого выполнения программы. Контроль (verification) попытка найти ошибки, выполняя программу в тестовой, или моделируемой, среде.
4 Испытание (validation) попытка найти ошибки, выполняя программу в заданной реальной среде. Аттестация (certification) авторитетное подтверждение правильности программы. При тестировании с целью аттестации выполняется сравнение с некоторым заранее определенным стандартом. Отладка (debugging) - не является разновидностью тестирования. Хотя слова «отладка» и «тестирование» часто используются как синонимы, под ними подразумеваются разные виды деятельности. Тестирование деятельность, направленная на обнаружение ошибок; отладка направлена на установление точной природы известной ошибки, а затем на исправление этой ошибки. Эти два вида деятельности связаны результаты тестирования являются исходными данными для отладки.
5 Тестирование модуля, или автономное тестирование (module testing, unit testing) контроль отдельного программного модуля, обычно в изолированной среде (т. е. изолированно от всех остальных модулей). Тестирование модуля иногда включает так же математическое доказательство. Тестирование сопряжений (integration testing) контроль сопряжений между частями системы (модулями, компонентами, подсистемами). Тестирование внешних функций (external function testing) контроль внешнего поведения системы, определенного внешними спецификациями. Основные определения
6 Комплексное тестирование (system testing) контроль и/или испытание системы по отношению к исходным целям. Комплексное тестирование является процессом контроля, если оно выполняется в моделируемой среде, и процессом испытания, если выполняется в среде реальной, жизненной. Тестирование приемлемости (acceptance testing) проверка соответствия программы требованиям пользователя. Тестирование настройки (installation testing) проверка соответствия каждого конкретного варианта установки системы с целью выявить любые ошибки, возникшие в процессе настройки системы. Основные определения
7 Экономика тестирования Тестирование программы как «черного ящика» ВХОД ВЫХОД Сложности создания исчерпывающего теста: 1) нельзя создать тест, гарантирующий отсутствие ошибок; 2) разработка таких тестов противоречит экономическим требованиям. Тестируется входная информация Тестируется выходная информация
8 Тестирование программы как «белого ящика» Сложности проведения исчерпывающего тестирования маршрутов: 1) Число не повторяющих друг друга маршрутов в программе - астрономическое. 2) Хотя исчерпывающее тестирование маршрутов является полным тестом, и хотя каждый маршрут программы может быть проверен, сама программа будет содержать ошибки. ВХОД ВЫХОД Тестируется внутреннее содержание программы
9 Тестирование программы как «белого ящика» П ричины ошибок: 1) Исчерпывающее тестирование маршрутов не может дать гарантии того, что программа соответствует описанию. 2) Программа может быть неверной в силу того, что пропущены некоторые маршруты. 3) Исчерпывающее тестирование маршрутов не может обнаружить ошибок, появление которых зависит от обрабатываемых данных.
10 Аксиомы (принципы) тестирования 1) Хорош тот тест, для которого высока вероятность обнаружить ошибку. 2) Одна из самых сложных проблем при тестировании - решить, когда нужно его закончить. 3) Не нужно тестировать свою собственную программу. 4) Необходимая часть всякого теста - описание ожидаемых выходных данных (результатов). 5) Избегайте невоспроизводимых тестов, не тестируйте «с лету».
11 6) Готовьте тесты как для правильных, так и для неправильных входных данных. 7) Детально изучите результаты каждого теста. 8) Если число ошибок растет, то растет вероятность обнаружения ошибок. Аксиомы тестирования
12 9) Поручайте тестирование самым способным программистам. 10) Проект системы должен быть таким, чтобы каждый модуль подключался к системе только один раз. 11) Никогда не изменяйте программу, чтобы облегчить ее тестирование. 12) Тестирование, как и всякая другая деятельность, должна начинаться с постановки целей. Аксиомы тестирования
13 Философия тестирования Чтобы ориентироваться в стратегиях проектирования тестов, рассматривают два крайних подхода, находящихся на границах спектра.
14 Тестирование модулей Причины тестирования модулей: 1) Появляется возможность управлять комбинаторикой тестирования, поскольку первоначально внимание концентрируется на небольших модулях программы. 2) Облегчается задача отладки программы, т.е. обнаружение места ошибки и исправление текста программы. 3) Допускается параллелизм, что позволяет одновременно тестировать несколько модулей. Цель тестирования модулей сравнение функций, реализуемых модулем, со спецификациями его функций или интерфейса.
15 Пошаговое тестирование Подходы к комбинированию модулей 1) Пошаговый метод тестирования или сборки. 2) Монолитный метод («большого удара») при тестировании и сборке программы. 12 3
16 Восходящее тестирование Процесс повторяется до тех пор, пока не будет достигнута вершина.
17 Нисходящее тестирование Процесс повторяется до тех пор, пока не будут собраны и проверены все модули.
18 Нисходящее тестирование Достоинства: 1) метод совмещает тестирование модуля, тестирование сопряжений и частично тестирование внешних функций. 2) когда модули ввода-вывода уже подключены, тесты можно готовить в удобном виде 3) выгоден, когда есть сомнения относительно осуществимости программы в целом или когда в проекте программы могут оказаться серьезные дефекты. 4) отсутствие необходимости в драйверах; вместо драйверов вам просто следует написать «заглушки».
19 Недостатки: 1)модуль редко тестируется досконально сразу после его подключения. 2) он может породить веру в возможность начать программирование и тестирование верхнего уровня программы до того, как вся программа будет полностью спроектирована. Нисходящее тестирование
20 Метод «большого скачка» В соответствии с этим методом каждый модуль тестируется автономно. По окончании тестирования модулей они интегрируются в систему все сразу. Заглушки и драйверы необходимы для каждого модуля. Модули не интегрируются до самого последнего момента, а это означает, что в течение долгого времени серьезные ошибки в сопряжениях могут остаться необнаруженными.
21 Метод сандвича Тестирование методом сандвича представляет собой компромисс между восходящим и нисходящим подходами. При использовании этого метода одновременно начинают восходящее и нисходящее тестирование, собирая программу как снизу, так и сверху и встречаясь в конце концов где-то в середине.
22 Метод сандвича Метод сандвича сохраняет такое достоинство нисходящего и восходящего подходов, как начало интеграции системы на самом раннем этапе.
23 Модифицированный метод сандвича В модифицированном методе сандвича нижние уровни также тестируются строго снизу вверх. Модули верхних уровней сначала тестируются изолированно, а затем собираются нисходящим методом. Таким образом, модифицированный метод сандвича также представляет собой компромисс между восходящим и нисходящим подходами.
Многие организации, занимающиеся созданием программного обеспечения, до 50% средств, выделенных на разработку программ, тратят на тестирование, что составляет миллиарды долларов по всему миру в целом. И все же, несмотря на громадные капиталовложения, знаний о сути тестирования явно не хватает и большинство программных продуктов неприемлемо ненадежно даже после «основательного тестирования».
О состоянии дел лучше всего свидетельствует тот факт, что большинство людей, работающих в области обработки данных, даже не может правильно определить слово «тестирование», и это на самом деле главная причина неудач.
«Тестирование – процесс, подтверждающий правильность программы и демонстрирующий, что ошибок в программе нет. Основной недостаток подобного определения заключается в том, что оно совершенно неправильно; фактически это почти определение антонима слова «тестирование». Читатель с некоторым опытом программирования уже, вероятно, понимает, что невозможно продемонстрировать отсутствие ошибок в программе. Поэтому определение описывает невыполнимую задачу, а так как тестирование зачастую все же выполняется с успехом, по крайней мере с некоторым успехом, то такое определение логически некорректно. Правильное определение тестирования таково: Тестирование – процесс выполнения программы с намерением найти ошибки.
Невозможно гарантировать отсутствие ошибок в нетривиальной программе; в лучшем случае можно попытаться показать наличие ошибок. Если программа правильно ведет себя для солидного набора тестов, нет основании утверждать, что в ней нет ошибок; со всей определенностью можно лишь утверждать, что не известно, когда эта программа не работает. Конечно, если есть причины считать данный набор тестов способным с большой вероятностью обнаружить все возможные ошибки, то можно говорить о некотором уровне уверенности в правильности программы, устанавливаемом этими тестами.
Психологические эксперименты показывают, что большинство людей, поставив цель (например, показать, что ошибок нет), ориентируется в своей деятельности на достижение этой цели. Тестовик подсознательно не позволит себе действовать против цели, т. е. подготовить тест, который выявил бы одну из оставшихся в программе ошибок. Поскольку мы все признаем, что совершенство в проектировании и кодировании любой программы недостижимо и поэтому каждая программа содержит некоторое количество ошибок, самым плодотворным применением тестирования будет найти некоторые из них. Если мы хотим добиться этого и избежать психологического барьера, мешающего нам действовать против поставленной цели, наша цель должна состоять в том, чтобы найти как можно больше ошибок. Сформулируем основополагающий вывод:
Если ваша цель – показать отсутствие ошибок, вы. их найдете не слишком много. Если же ваша цель – показать наличие ошибок, вы найдете значительную их часть. Надежность невозможно внести в программу в результате тестирования, она определяется правильностью этапов проектирования. Наилучшее решение проблемы надежности – с самого начала не допускать ошибок в программе. Однако вероятность того, что удастся безупречно спроектировать большую программу, бесконечно мала. Роль тестирования состоит как раз в том, чтобы определить местонахождение немногочисленных ошибок, оставшихся в хорошо спроектированной программе. Попытки с помощью тестирования достичь надежности плохо спроектированной программы совершенно бесплодны.
2.6.2 Виды и методы тестирования
Тестирование программы методом «черного ящика».
Одним из способов изучения поставленного вопроса является исследование стратегии тестирования, называемой стратегией «черного ящика», тестированием с управлением по данным или тестированием с управлением по входу-выходу. При использовании этой стратегии программа рассматривается как «черный ящик». Иными словами, такое тестирование имеет целью выяснение обстоятельств, в которых поведение программы не соответствует спецификации. Тестовые же данные используются только в соответствии со спецификацией программы (т. е. без учета знаний о ее внутренней структуре). При таком подходе обнаружение всех ошибок в программе является критерием исчерпывающего входного тестирования. Последнее может быть достигнуто, если в качестве тестовых наборов использовать все возможные наборы входных данных. Если такое испытание представляется сложным, то еще сложнее создать исчерпывающий тест для большой программы.
Построение исчерпывающего входного теста невозможно. Это подтверждается двумя аргументами: во-первых, нельзя создать тест, гарантирующий отсутствие ошибок; во-вторых, разработка таких тестов противоречит экономическим требованиям.
Тестирование программы методом «белого ящика»
Стратегия «белого ящика», или стратегия тестирования, управляемого логикой программы, позволяет исследовать внутреннюю структуру программы, В этом случае тестирующий продукт получает тестовые данные путем анализа логики программы. Сравним способ построения тестов при данной стратегии с исчерпывающим входным тестированием стратегии «черного ящика». Непосвященному может показаться, что достаточно построить такой набор тестов, в котором каждый оператор исполняется хотя бы один раз; нетрудно показать, что это неверно. Не вдаваясь в детали, укажем лишь, что исчерпывающему входному тестированию может быть поставлено в соответствие исчерпывающее тестирование маршрутов. Подразумевается, что программа проверена полностью, если с помощью тестов удается осуществить выполнение программы по всем возможным маршрутам ее потока (графа) передач управления. Последнее утверждение имеет два слабых пункта. Первый из них состоит в том, что число не повторяющих друг друга маршрутов в программе — астрономическое. Второй слабый пункт утверждения заключается в том, что, хотя исчерпывающее тестирование маршрутов является полным тестом и хотя каждый маршрут программы может быть проверен, сама программа будет содержать ошибки. Это объясняется следующим образом. Во-первых, исчерпывающее тестирование маршрутов не может дать гарантии того, что программа соответствует описанию. Например, вместо требуемой программы сортировки по возрастанию случайно была написана программа сортировки по убыванию. В этом случае ценность тестирования маршрутов невелика, поскольку после тестирования в программе окажется одна ошибка, т. е. программа неверна.
Во-вторых, программа может быть неверной в силу того, что пропущены некоторые маршруты. Исчерпывающее тестирование маршрутов не обнаружит их отсутствия.
При восходящем подходе программа собирается и тестируется «снизу вверх». Только модули самого нижнего уровня тестируются изолированно, автономно. После того как тестирование этих модулей завершено, вызов их должен быть так же надежен, как вызов встроенной функции языка или оператор присваивания. Затем тестируются модули, непосредственно вызывающие уже проверенные. Эти модули более высокого уровня тестируются не автономно, а вместе с уже проверенными модулями более низкого уровня. Процесс повторяется до тех пор, пока не будет достигнута вершина. Здесь завершается и тестирование модулей, и тестирование сопряжений программы. При восходящем тестировании для каждого модуля необходим драйвер: нужно подавать тесты в соответствии с сопряжением тестируемого модуля. Одно из возможных решений — написать для каждого модуля небольшую ведущую программу. Тестовые данные представляются как «встроенные» непосредственно в эту программу переменные и структуры данных, и она многократно вызывает тестируемый модуль, с каждым вызовом передавая ему новые тестовые данные. Имеется и лучшее решение: воспользоваться программой тестирования модулей - это инструмент тестирования, позволяющий описывать тесты на специальном языке и избавляющий от необходимости писать драйверы. Здесь отсутствуют проблемы, связанные с невозможностью или трудностью создания всех тестовых ситуаций, характерные для нисходящего тестирования. Драйвер как средство тестирования применяется непосредственно к тому модулю, который тестируется, где нет промежуточных модулей, которые следует принимать во внимание. Не существует также и трудностей с незавершенностью тестирования одного модуля при переходе к тестированию другого, потому что при восходящем тестировании с применением нескольких версий заглушки нет сложностей с представлением тестовых данных.
Нисходящее тестирование (называемое также нисходящей разработкой) не является полной противоположностью восходящему, но в первом приближении может рассматриваться как таковое. При нисходящем подходе программа собирается и тестируется «сверху вниз». Изолированно тестируется только головной модуль. После того как тестирование этого модуля завершено, с ним соединяются (на пример, редактором связей) один за другим модули, непосредственно вызываемые им, и тестируется полученная комбинация. Процесс повторяется до тех пор, пока не будут собраны и проверены все модули. Нисходящий метод имеет как достоинства, так и недостатки по сравнению с восходящим. Самое значительное достоинство — то, что этот метод совмещает тестирование модуля, тестирование сопряжений и частично тестирование внешних функций. С этим же связано другое его достоинство: когда модули ввода-вывода уже подключены, тесты можно готовить в удобном виде. Нисходящий подход выгоден также в том случае, когда есть сомнения относительно осуществимости программы в целом или когда в проекте программы могут оказаться серьезные дефекты. Преимуществом нисходящего подхода очень часто считают отсутствие необходимости в драйверах.
Тестирование - один из важнейших этапов контроля качества разрабатываемого ПО.
Автоматическое тестирование является его составной частью. Оно использует программное обеспечение для проверки выполнения проводимых тестов, что помогает в большинстве случаев сократить время тестирования иупростить его процесс.
q Когда стоит начинать автоматизированное тестирование, чтобы оно принесло пользу проекту?
q Есть что автоматизировать
q Есть тест план
q Написаны тесты для ручного тестирования
q Есть инструмент для автоматизированного тестирования
q Просчитана величина реальной пользы от внедрения автоматизированного тестирования
q Есть необходимость автоматизированного тестирования (требование заказчика, состояние проекта)
q Глен Маерс : Тестирование это процесс выполнения программ с намерением найти ошибки
q Пол Йоргенсен : Тестирование сфокусировано на ошибках и сбоях. Тест - выполнение действий над ПО с целью найти ошибки или продемонстрировать работоспособность
q Обобщенное определение тестирования
q Тестирование - процесс проверки соответствия заявленных к продукту требований и реально реализованной функциональности
q Задачи автоматизации процесса тестирования :
q Процесс автоматизации функционального тестирования программного обеспечения обеспечивает получение прямых финансовых выгод за счет экономии ресурсов, а также повышение качества выполняемых работ по тестированию ПО
q Цели автоматизации процесса тестирования:
q Процесс автоматизации функционального тестирования программного обеспечения обеспечивает получение прямых финансовых выгод за счет экономии ресурсов, а также повышение качества выполняемых работ по тестированию ПО
q Автоматизированное тестирование ПО позволяет разработчикам применять подходы, известные им по задачам разработки, для решения вопросов тестирования
q Проектным менеджерам автоматизация тестирования дает инструмент для интеграции специалистов заказчика в процесс приемочного тестирования и приемки продукта
a. Возможность непрерывного/циклического выполнения тестов
b. Строгая последовательность выполняемых шагов
c. Увеличение производительности в сравнении с ручным тестированием в разы
d. Автоматизация длинных последовательностей
e. Автоматизация операций, требующих тяжелых вычислений
a. Требуют достаточно времени для создания скриптов (не всегда оправдываются)
b. Необходимость постоянного сопровождения (обновления) тестов
c. Тесты выполняют запрограммированную последовательность действий, они не имеют интеллекта
Продолжая отдавать должное вопросам психологии в процессе тестирования, мы можем определить набор витальных (читай, чертовски жизненных) принципов тестирования. Многие из них покажутся очевидными, что, однако, не мешает зачастую ими пренебрегать. Вот они, а дальше – подробное их рассмотрение:
1. Обязательная часть тестирования – определение ожидаемого результата;
2. Программистам следует избегать тестирования их собственных программ (и участков кода);
3. Организациям, создающие программы, следует избегать тестирования их собственных программ;
4. Процесс тестирования должен включать в себя тщательную проверку результатов каждого теста;
5. Тест-кейсы должны быть составлены как для корректных и ожидаемых входных условий, так и для некорректных и неожидаемых;
6. Исследование Системы на предмет того, что она не делает того, что должна, — лишь пол дела. Вторая часть – разобраться в том, чего недолжного она делает;
7. Избегайте одноразовых тест-кейсов, только если сама программа не является одноразовой. Одноразовые тест-кейсы для одноразовых программ. В остальных случаях следует избегать таковых;
8. Не занимайтесь процессом тестирования с предустановкой, что вы не найдете ошибок;
9. Вероятность наличия ошибок в определенной части Системы пропорционально количеству уже найденных здесь ошибок;
10. Тестирование – это вызов вашим творческим и интеллектуальным способностям. Тестирование – это невероятно творческое и интеллектуальное занятие.
Принцип 1: обязательная часть тестирования – определение ожидаемого результата
Этот принцип, который типа очевидный, когда его упускают из вида, является причиной наиболее частых ошибок в процессе тестирования. Тут снова вмешивается психология. Если заранее не разобраться с тем, как должен выглядеть результат, то нечто похожее на правду, но таковым не являющееся, будет воспринято как корректный результат. Ведь «мы видим то, что хотим видеть». Другими словами, несмотря на разрушительную природу тестирования, где-то в глубине души мы все еще храним желание увидеть корректный результат. Но с этим нужно решительно бороться. Например, путем поощрения подробного заблаговременного исследования всех выходных данных и ожидаемых результатов. А это значит, что тест-кейс должен содержать два компонента:
— описание входных данных
— точное описание корректных выходных данных для указанных входных данных.
Проблемы могут возникнуть тогда, когда мы встречаем нечто, что не имеет приемлемого описания, что выглядит странным, что не согласуется с нашими ожиданиями или предубеждениями. При встрече с чем-то подобным нам нужно иметь хотя бы какие-то обобщенные представления, поскольку если не будет даже их, легко вообще пропустить потенциальные проблемы. Нет ожидания – нет сюрпризов.
Принцип 2: программистам следует избегать тестирования их собственных программ (и участков кода)
Каждый писатель знает – или должен знать – что редактировать свою собственную работу – это плохая идея. Они знают, что именно должна сказать, к примеру, определенная глава книги, и поэтому могут не увидеть то, что она говорит нечто другое. И они как-то не хотят искать ошибки в своей работе. То же можно сказать и об авторах программных продуктов.
Еще одна проблема связана со сменой фокуса. В то время, как при дизайне и написании кода программист настроен созидательно, перенастроиться на разрушительную волну может быть очень сложно.
Каждый домовладелец знает, что снимать обои очень трудно. Но если эти обои еще и ты сам вешал — это невыносимо удручает. Аналогично и с ПО, большинство программистов не могут протестировать свои программы эффективно, поскольку они не могут произвести ментальные перестройки, способствующие выявлению ошибок. Более того, подсознательный страх перед наказанием со стороны коллег, руководителей, клиентов или владельцев может приводить к избеганию ошибок.
И еще одна проблема: программа может содержать ошибки, которые вызваны непониманием поставленных задач или спецификации. И если это так, то сам процесс тестирования может включать в себя производные этого непонимания.
Это не значит, что путь тестирования собственных программ для программиста закрыт. Просто лучше (эффективнее), чтобы это делал кто-то другой. Разработчики могут быть полезными участниками команды тестирования, когда проводится оценка спецификации и самого программного кода.
И еще. Речь не шла о процессе дебаггинга. В этом случае автор кода является наиболее эффективным участником процесса.
Принцип 3: организациям, создающим программы, следует избегать тестирования их собственных программ
Аргументы такие же, что и для предыдущего принципа. Организация, создающая ПО, во многих смыслах как человек: имеет психологические проблемы. Более того, в нашем лучшем из миров работа организации или ее менеджеров часто оценивается способностью производить программы в установленные сроки и за определенную стоимость. Причиной этому то, что эти величины легко описать количественно, в противоположность надежности, которую оценить в цифрах может быть сложно. Отсюда — организациям-разработчикам сложно быть эффективными в тестировании собственных продуктов. Эта оценка может проводится на основе соблюдения графиков работ и расходов.
Следует сказать и тут, что участие организации в процессе тестирования собственных продуктов не обязательно является бессмысленным. Здесь мы говорим, что наиболее удачно с экономической точки зрения выполнять такую работу независимой стороной.
Принцип 4: процесс тестирования должен включать в себя тщательную проверку результатов каждого теста
Это очевидно, но это часто упускается. Мы знакомы с большим количеством случаев, когда ошибку не удавалось обнаружить даже тогда, когда ее симптомы были четко различимы в выходных списках (результатах). Если выразится по-другому, ошибки, которые находят в последующих тестах, часто не замечают в результатах предшествующих тестов.
Принцип 5: тест-кейсы должны быть составлены как для корректных и ожидаемых входных условий, так и для некорректных и неожидаемых
Это естественная и здравая тенденция – концентрироваться на допустимых и ожидаемых условия в процессе тестирования. Пренебрегать недопустимыми и неожиданными условиями также естественно, но не также здраво. Много ошибок может выявится, когда программный продукт используется неким новым или неожиданным путем. Невозможно определить все сценарии, какими пользователь будет работать с продуктом, однако что-то отличное от спокойного, привычного течения программы, кажется, имеет все шансы на успех (в деле поиска ошибок).
Принцип 6: исследование Системы на предмет того, что она не делает, что должна, — лишь пол дела. Вторая часть – разобраться в том, чего недолжного она делает
Это следствие предыдущего принципа. Программу нужно проверить еще и на предмет нежеланных сторонних эффектов. Например, ПО для расчета заработанной платы, которая выдает зарплатный чек корректно, все еще содержит ошибки, если она также выдает дополнительные чеки для несуществующих работников, или она переписывает первую запись в персональном деле.
Принцип 7: одноразовые тест-кейсы для одноразовых программ, в остальных случаях следует избегать таковых тестов
Эта проблема, кажется, часто проявляется в различных системах для тестирования программ. Типичная практика – сидеть у компьютера и разрабатывать тесты на лету, и далее проводить эти тест-кейсы в программе. Суть в том, что тест-кейсы представляют собой ценные инвестиции, которые в рамках конкретного окружения могут исчезнуть, как только процесс тестирования будет завершен. И всякий раз, когда возникнет необходимость в повторном тестировании ПО (в регрессионном тестировании или при улучшении системы), тест-кейсы могут потребовать новой разработки. Это дополнительная, сложная работа, встречаясь с которой тест-инженер может волить избегать ее. Так получается, что последующие усилия на работу редко столь же объемны и качественны сколь объемны и качественны первоначальные. И если, к примеру, изменение функциональности влечет за собой ошибки, вновь разработанные тесты могут их не обнаружить.
Принцип 8: не занимайтесь процессом тестирования с предустановкой, что вы не найдете ошибок
Частая ошибка менеджеров проекта и маленький звоночек к тому, что кто-то определяет процесс тестирования некорректно. Например, как процесс демонстрации, что программа работает правильно. Мы принимаем другое определение (хотя догадываемся, что есть ребята, которые так не делают) – это процесс выполнения программы со стойким намерением найти ошибки. Мы утверждаем: это очевидно, что разработать программный продукт, совершенно не содержащий ошибок, невозможно. Даже после качественно выполненного процесса тестирования и исправления ошибок, уместно предполагать, что ошибки все еще существуют; просто их пока не нашли.
Принцип 9: вероятность наличия ошибок в определенной части Системы пропорционально количеству уже найденных здесь ошибок
Может показаться, что эта штука сомнительна, но такой феномен наблюдается во многих программах. На пальцах это вот как: предположим, что программа состоит из модулей А и Б. В модуле А было найдено 5 ошибок, а в модуле Б – всего лишь одна. И если модуль А еще не подвергся тщательному тестированию, тогда принцип говорит: вероятность найти еще больше ошибок в модуле А выше, нежели вероятность найти еще больше ошибок в модуле Б.
Другой способ проиллюстрировать указанный принцип такой: ошибки имеют волю к объединению в группы, и в типичном случае, определенные программные блоки больше подвержены ошибочности, нежели другие. Хотя это похоже на магию… ничем не подкрепленную магию. Она может быть полезна, поскольку дает некое понимание и обратную связь в процессе тестирования. Если какой-то участок программы кажется больше подверженным ошибкам, нежели другие участки, этот феномен намекает нам, что лучше бы нам потестировать здесь чуточку дольше. И это вопрос об инвестициях.
Читайте также: