Тестирование черного ящика. Б. Бейзер (2004) (1186170), страница 10
Текст из файла (страница 10)
Индикатором того, что в процессе возникли проблемы, служит возникновение расхождения между формальным процессом (то есть задокумецтированным процессом) н тем, что фактически делают люди. В таких случаях я встаю на сторону программистов н тестнровщщ<ов, идуп<их своим путем, а не тех умников, которые этот процесс придумали. Если процесс игнорируют, то это, скорее всего, потому, что он не работает, а не потому, что программисты — закостенелые ретрограды. Большинство людей, хотя и не все, если нм указать более эффективный способ сделать что-либо и обеспечить инструментами и навьшами, необходимыми для работы, будут следовать этому новому пуз и. Процессом перестают руководствоваться в случае, если он ущербен, если существуют преграды для его использования или если нс хватает необходимых ресурсов (то есть навыка, времени, инструментов).
1.4.2. Десять„„и одна заповедь управления процессом В таком разчеле во множестве разных книг вы можете найти тщательно разработанные наборы блок-схем процедур с таннственныл< образом обозначенными прямоугольниками и стрелками различных видов и ею<лей, входящими в эти прямоугольники и выходя<ними из них во всех направлениях.
Я не собираюсь здесь этого делать, поскольку усвоил одно еретическое правилсс блок-схемы и модели процесса ничего не значат. Они ничего не значат, поскольку провал или успех процесса разработки программного обеспечения никоим образом не определяются моделью дашюго процесса. Культурные, этнические, прикладные и национальные особенности оказывают гораздо большее влияние на процесс, нежели грандиозные теории процессов. Утверждение «Процесс А лучше процесса Б» равносильно утверждению «Японский язык лучше тагальского». Говорить, что рецензирование предварительного проектирования должно предварять кодирование, то же самое, что говорить: «В предложении глаголы должны идти вперсди существительных». Специфичес<сне особенности языка, а также порядок слов очень важны для гово- 1 4.
Процесс разработки программного обеспечения 41 рящего на этом язьпсе, а также для тех, кто занимается переводами с одного языка на другой, но не онп определяют способность носителя языка к общению. Итак, мы не будем рассматривать модель водопада (КОУС70( нлн спиральную модель (ВОЕН861, пошаговую детализацию, нисходящую стратегию, восходящую стратегию и все такое прочее.
Ниже приводятся составляюсцис, которые вам надо искать в любом эффективном процессе, подобно тому, как вы ищете существительные, глаголы н другие части речи в разговорном языке, но без указания, в каком порядке они должны быть скомпонованы, чтобы получился осмысленный процесс. Дорожная карта процесса. Необходимо понимать в каждый момент времени, на какой стадии процесса находитесь вы и ваша программа. Если вы предпочитаете блок-схемы процесса — это очень хорошо, но некоторые люди отдают прел- почтение комментариям и спискам.
Грамотная дорожная карта процесса разбивает процесс на элементарные шаги, которые лепсо понять н контролировать. Она достаточно детальна, чтобы вы нтш кто-ннбуль друго!с мог легко сориентироваться в ней, но эта детализация не чрезмерна и не подавляет индивидуальность и творческое начало. Управление процессом. Управление процессом нс подразумевает жесткого соблюдения детально расписанного графика, как пе означает оно н тоталитаризма н подавления индивидуальности. Управление процессом подразумевает наличие эффективных механизмов, при помоппз которых все участники процесса могут получать инфорлсацию, касающуюся улучшения тех частей процесса, в которых они напрямую задействованы.
Управление процессом включает в себя обратную связь, обучение н широкий круг возможностей, и направлено на создание атмосферы в коллективе, в которой люди будут стремиться улучписть себя, свой продукт и мир вокруг. Количественные измерения и метрики.
Мы имеем дело с инженерной наукой, а не с искусством, и потому объективность — требование, необходимое лля управления процессом. В инженерной науке количественные измерения являются залогом объективности. В компьютерных науках количественные измерения опираются главныч образом на метрики (ВЕГсь94, ЕЕ(лГТ91, СКАЕЗ87, СссАО92, МОЕЕ93, УЛЗЯЕ90, 21)ВЕ94]. Контроль конфигурации так жс стар, как Имхотеп, великий строитель пирамид. Он означает, что н любой момент времени мы можем проверить результат нашего труда (программу, требования илн, скажем, тестовгпй комплект) и узнать: кто, что, где, когда, зачем и как. Конфигурация всего, с чем планируется палыче работать, должна контролироваться, а все, что не контролируется, просто не входит в наш продукт.
Требования. Что мы создаем? Все в курсе? Все имеют в виду одно н то же? Злесь я настаиваю на документировании, поскольку человеческая память ненадежна. 17рослеживаемость требований. Оттсуда взялись требования? Если, как часто бывает, требования изменяются в процессе разработки программы, на какие другие требования это повлияет? Нрослеживаемость означает, что требования находят свое отражение в компонентах программного обеспечения и наоборот.
Однако не требуйте и не ожидайте взаимно однозначного соответствия, так как требования и компоненты не отображаются в стиле «один к одному . 42 Глава 1 ° Введение Стратегические тонкости. Для кого разрабатывается данное программное обеспечение? Что ожидают заказчики и пользователи от программы, кроме обычной практичности? Не станет ли эта программа кошмаром для пользователя? Будет ли она вне конкуренции? Улучшит ли она нашу репутацию? Принесет ли она большой доход? Будет ли она самой быстрой? Существуют сотни таких стратегических задач, и руководство определяет относительную важность каждой из нпх. Без подобного руководства (желательно заданного в количественной форме) невозможно определить цели проектирования нли понять, когда эти цели достигнуты.
Критерии соотве>пствин требованиям. Как мы узнаем, что продукт удовлетворяет требованиям? Как выбрать объективпью критерии соответствия требованиям так, чтобы они были связаны с каждым требованием по отдельности и со всеми вместе? Ответственность. Кто и за что отвечает. Критерии завершенности. Как узнать, когда данная часть программного обеспечения (ПО) будет готова к переходу на следую>цую стадию процесса разработки? Что является реальным, объективнь>ь> признаком завершенности? Критерий готовности.
Как узнать, когда данная часть ПО будет удовлетворять условиям, не<>бходимым для перехода к следующей стадии процесса разработки? Полобное описание вовсе пе избыточно. Компонент программы может пройти через множество стадий или использоваться множеством других компонентов, каждьш из которых имеет свои критерии готовности. Как правило, критерий завершенности компонента является объединением всех критериев готовности для этого компонента. Анализ. Анализ — это инженерный процесс, при помощи которого проектирование «наполняется» требованиями (получает полные требования как входной набор данных).
Он может быть полностью интуитивным или полностью формальным. Интуитивный анализ, зачастук> действенный, не может, однако, быть с легкостью воспринят другими лк>льми, и, следовательно, какой-либо формальный, часто математический анализ необходим, лаже просто для памяти. Проектирование. Это все, что касается сути дела, не так ли? Проектирование должно предварять программирование нли, по крайней мере, проводиться одновременно с ним. Инженеры, прежде чем строить, занимаются проектированием, поскольку это уменьшает риск. Проектные ошибки — это ошибки на бумаге, и обходятся они гораздо дешевле, нежели сваренная сталь или скомпилированный код. Проверка соответствия проекта.
Как нам убедиться в том, что проект будет работать, если мы раньше ничего подобного не разрабатывали? Проверка соответствия проекта — это совсем нс то же самое, что проверка соответствия реализации проекта. Мосты рушатся из-за плохих, не прошедших проверки проектов, а не из-за плохих материалов и неквалифицированной рабочей силы. Чем новее проект, тем важнее его проверить перед началом конструирования.
Проверка соответствия производится с помощью моделей, прототипов и инспектирования проектирования. Программирование. Написание кода в соответствии с проектом и тестирование его с целью убедиться, что мы создали именно то, что и собирались создать. 1.5. Вопросы для самопроверки 43 Каменщик проверяет горизонтальность своей кладки с помощью уровня, а программист — с помощью тестов.
Интеграции. Единое целое по своим возможностям существенно больше, чем сумма отдельных частей. Только у тривиальных, модельных программ уровень сложности системы эквивалентен сумме уровней сложности ее составляющих. Архитектор тратит не меньше времени на придание зданию законченного вида, чем на цродумывание шагов по его возведению. Об интеграции не стоит и говорить, если не суц!ествует плана интеграции и соответствуюгцих тестов интеграции, будь то объединение двух низкоуровневых поди ро< рамм или нескольких сотен квазиавтономных систем. Тестирование: Тестирование требуется везде, где работают люди. Тестирование — это основная составляющая самоуважения и гордости за свое мастерство. Механик, который не проверяет результат свой работы микрометром, или негодяй, или дурак.
Программист, поиском ошибок которого занимаются впоследствии только другие лкцги, не уважает себя, за исключением, возможно, странной гордости за быстрое клевание огромного количества непроверенных и полных ошибок программ. 1.5. Вопросы для самопроверки Дайте определение следующих терминов: анализ, поведенческое тестирование, тестирование черного ящика, слепота, ошибка, свободный от ошибок, вариант, чистый тест, случайная корректность, комбинаторный, гипотеза о компетентном программисте, компонент, ошибка компонента, тестирование компонента, контроль конфигурации, проверка соответствия проекта, грязный тсст, эффективная стратегия, эффективный тест, критерии готовности, среда, критерии завершенности, не пройденный тест, отказ, опровергаемый, искаженность, дефект, характеристика, конечное состояние, функциональное тестирование, тестирование прозрачного ящика, гибридная стратегия, начальное состояние, ввод, интеграция, ошибка интеграции, тестирование интеграции, интерфейс, отрицательный тест, объект, наблюдаемый, оракул, итог, соответствие итогов, пройденный тест, парадокс цесющида, ошибка производительности, положительный тест, управление процессом, программирование, прототип, цель тестирования, обеспечение качества, контроль качества, требования, анализ требований, црослеживаемость требований, критерий соответствия требованиям, ошибка потери ресурсов, действенный тест, ошибка безопасности, система программного обеспечения, спецификация, состояние, структурное тестирование, подтест, симптом, система, системная ошибка, системное тестирование, тест, проектирование теста, сценарий теста, стратегия тестирования, тестовый комплект, тестируемый проект, протестированный, тестирование, методы тестирования, модуль, ошибка модуля, тестирование модуля, ~ ~ровсрка соответствия, критерий соответствия, тестирование белого ящика.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
