Исчерпывающее тестирование

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

Ответ тут краток: «никак», вы никогда это не узнаете. Но на программном рынке есть продукты, которые могут вам посодействовать. Эти средства анализа степени покрытия выслеживают Исчерпывающее тестирование программку при тестировании и регистрируют, какие строчки были выполнены, а какие нет. Эти средства дают общее представление о том, как исчерпающей является процедура тестирования, но не стоит ждать, что степень покрытия составит 100 %.

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

int test(int a, int b) {

return a / (a + b)

}

На теоретическом уровне эта функция, состоящая из 3-х строк, имеет 1000000 логических состояний Исчерпывающее тестирование, 999999 из которых будут работать верно, а одно – некорректно (когда а + b равно нулю). Если вам понятно только то, что данная строчка программки выполнена, то вам придется идентифицировать все вероятные состояния программки. К огорчению, это очень непростая неувязка. Так непростая, что "пока вы ее решите, солнце перевоплотится в прохладную Исчерпывающее тестирование глыбу".

Подсказка 65: Тестируйте степень покрытия состояний, а не строк текста программки

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

Когда тестировать

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

Большая часть процедур тестирования должно производиться автоматом. Принципиально увидеть, что под термином «автоматически» мы имеем в виду и автоматическую интерпретацию Исчерпывающее тестирование результатов теста. Более тщательно этот нюанс рассматривается в разделе "Всесущая автоматизация".

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

% make test

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

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

Кольцо сжимается

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

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

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

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

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

Другие разделы, относящиеся к этой теме:

• Мой начальный текст съел кот Мурзик

• Отладка

• Несвязанность и Исчерпывающее тестирование закон Деметера

• Реорганизация

• Программка, которую просто тестировать

• Всесущая автоматизация

Вопросы для обсуждения

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

Трудно ли проверить логику приложения независимо от графического интерфейса? Что можно Исчерпывающее тестирование сказать о графическом интерфейсе? О связывании?

Все эти сочинения

Лучше выцветшие чернила, чем хорошая память.

Китайская пословица

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

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

Эти мысли не Исчерпывающее тестирование отличаются оригинальностью и новизной; мысль о супружеском союзе программки и документации к ней возникает уже в работе Доналда Кнута о грамотном программировании и в утилите JavaDoc конторы Sun. Мы желаем уменьшить противоречие меж программкой и документацией и заместо этого считать их 2-мя зрительными представлениями одной и той же модели (см. "Всего только Исчерпывающее тестирование зрительное представление"). По сути мы желаем пойти чуть-чуть далее и применить все наши прагматические принципы к документации так, как мы применяем их к программкам.

Подсказка 67: Считайте естественный язык одним из языков программирования

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

Подсказка 68: Встраивайте документацию в проект, а не накручивайте ее сверху

Начнем с внутренней документации.

Комменты в программке

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

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

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

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

Имена переменных должны выбираться верно и со смыслом. К примеру, имя foo, не имеет смысла, так же как doit либо manager, либо stuff. «Венгерский» стиль именования (в каком вы кодируете информацию о Исчерпывающее тестирование типе переменной в самом ее имени) очень нежелателен в объектно-ориентированных системах. Не запамятовывайте, что вы (и те, кто идет за вами) будут читать текст программки много сотен раз, но писать ее будут только пару раз. Не спешите, и напишите connectionPool заместо ср.

Имена, вводящие в заблуждение, еще ужаснее Исчерпывающее тестирование, чем глупые. Приходилось ли вам слышать, как кто-либо разъясняет несоответствия в унаследованном тексте программки типа: "Подпрограмма с именованием getData по сути записывает данные на диск"? Человечий мозг будет временами все путать – это именуется эффектом Струпа [Str35]. Вы сможете поставить на для себя последующий опыт, чтоб узреть эффект схожих помех Исчерпывающее тестирование. Возьмите несколько цветных ручек и напишите ими наименования цветов диапазона. Но при всем этом заглавие цвета должно быть написано только ручкой другого цвета. Вы может написать слово «синий» зеленоватым цветом, слово «коричневый» – красноватым и т. д. (В качестве кандидатуры имеется набор цветов диапазона, уже помещенный на наш Исчерпывающее тестирование web-сайт www.pragmaticprogrammer.com.) Как вы написали наименования цветов, постарайтесь как можно резвее произнести вслух заглавие цвета, которым написано каждое слово. В определенный момент вы собьетесь и станете читать наименования цветов, а не сами цвета. Имена очень важны для восприятия, а имена, вводящие в заблуждение, заносят кавардак в программку.

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

/**

* Отыскать пиковое (наивысшее) значение в обозначенном интервале дат

* @param aRange Range of dates to search for data.

* @param aThreshold Minimum value to consider.

* @return Исчерпывающее тестирование the value, or null if no value found

* greater than or equal to the threshold.

*/

public Sample findPeak(Date Range aRange, double aThreshold);

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

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

Хронология конфигураций. Для этого предусмотрены системы управления начальным текстом программки (см. "Управление начальным текстом"). Но, полезно включить информацию о дате последнего конфигурации и сотруднике, который занес это изменение [52].

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

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

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

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

При наличии широких комментариев инструментальные средства, подобные JavaDoc [URL 7] и DOC++ [URL 21], могут извлекать и форматировать их для автоматического сотворения документации на уровне API. Это является одним из определенных примеров более универсальной методики, которой мы пользуемся, – исполняемые документы.

Исполняемые документы

Представим, что есть спецификация, которая перечисляет Исчерпывающее тестирование столбцы в таблице базы данных. Тогда мы получим отдельный набор команд SQL для сотворения реальной таблицы в базе данных и, по всей вероятности, некоторую структуру записи на языке программирования для хранения содержимого строчки в таблице. Одна и та же информация повторяется трижды. Стоит поменять один из этих Исчерпывающее тестирование 3-х источников – и два других немедля устареют. Это очевидное нарушение принципа DRY.

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

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

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

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

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

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

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

Аналогичным образом можно генерировать документацию на уровне API из начального текста программки, пользуясь инструментальными средствами, такими как JavaDoc и DOC++. Моделью является начальный текст программки: компилироваться может одно зрительное Исчерпывающее тестирование представление модели; другие представления созданы для вывода на печать либо просмотра на web-странице. Наша цель – работа над моделью (непринципиально, является ли эта модель самой программкой либо же любым другим документом), и мы должны достигнуть того, чтоб все эти представления обновлялись автоматом (см. "Всесущая автоматизация").

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

Технические писатели

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

Это является ошибкой. То, что программеры не составляют такие документы, совсем не значит, что мы можем поступиться прагматическими принципами. Мы желаем, чтоб писатели восприняли те же главные принципы, что и прагматики, – соблюдали принципы DRY, ортогональности, также концепцию "модель-визуальное представление", применяли автоматизацию и Исчерпывающее тестирование сценарии.


ishodnie-dannie-k-zadache.html
ishodnie-dannie-k-zadaniyu-8.html
ishodnie-dannie-obekti-proizvodstva-i-tehnologicheskie-processi-proizvodstva-produkcii-na-onpl-dlya-vipolneniya-kursovoj-raboti.html