Шаг 11. Компиляция модуля. Работа над созданием модуля в определенном смысле завершается компиляцией, но это уже и следующий этап разработки — начало тестирования модуля, так как компилятор проведет контроль синтаксиса и частично семантики исходной программы. [c.144]
Тестирование модуля. Целью тестирования модуля является обнаружение различий между логической схемой модуля и его интерфейсом и их внешними спецификациями. Тестирование модуля начинается после его отладки. [c.172]
Тестирование модуля может проводиться произвольным образом, без определенного плана. Другой, научный подход, когда тестирующий программу с осторожностью выбирает необходимую тестовую информацию, внимательно составляет набор вопросов для тестирования и тщательно проводит сам тест. [c.172]
Критической частью работы по тестированию модуля являются пропуск проверочной программы и проверка получаемых результатов. Общей ошибкой проектирования тестовых программ являются большие затраты времени для обнаружения ошибок, а также то, что до получения действительного вывода важно получить ожидаемый вывод каким-нибудь возможным способом. [c.175]
После завершения тестирования модулей (может быть некоторой совокупности модулей) производится их интеграция с параллельной проверкой межмодульного интерфейса. [c.176]
Основные принципы тестирования модуля. [c.187]
В чем причины того, что тестирование модуля не позволяет выявить все ошибки [c.187]
Этот раздел описывает тестирование модуля. Составляется список всех ситуаций, которые необходимо проверить для определения правильности выполнения модулем заданной функции, например проверить, что модуль для пустой или полной таблицы идентификаторов работает так же, как и для частично заполненной . В некоторых случаях может быть составлено описание реальных тестовых данных как по входам, так и по ожидаемым выходам, но в большинстве случаев приходится обращаться к тестовому файлу, в котором хранятся контрольные примеры и требуемые результаты прогона тестов. В этом же разделе следует представить любую другую релевантную информацию о тестировании (например, о том, что тестирование модуля более высокого уровня приводит к проверке и данного модуля, или о том, что необходимо использование специального драйвера для автономной проверки модуля). [c.289]
Проведено тестирование модуль работает правильно, за исключением аварийных ситуаций [c.291]
Реализация (включая кодирование, тестирование модулей, сборку [c.46]
Стадия реализации. Она включает написание программных кодов, тестирование модулей, сборку, тестирование собранного продукта, а также завершение планирования тестов и пользовательской документации. [c.129]
Стадия тестирования модулей [c.222]
Повторное тестирование модуля. [c.222]
Подготовка документа по результатам тестирования модуля. [c.222]
В начале профессиональной диагностики (модуль D диагностической системы) проводится психологическое тестирование Стиль руководства . Руководителям предлагается ответить на 18 вопросов, высвеченных на экране, в течение 15 мин. После разъяснения они самостоятельно подсчитывают результаты тестирования. [c.235]
В группе с главным программистом последний руководит ее работой. Он назначается из числа наиболее опытных и знающих программистов и выполняет все конструкторские задачи, разрабатывает программы для наиболее важных модулей, проводит интеграцию и тестирование. Он также выступает в качестве первоначального связующего звена с организацией пользователя и другими группами, участвующими в проекте. Это позволяет сократить число связей при разработке проекта и в значительной мере уменьшить количество ошибок связи. [c.43]
Система проектируется как совокупность формально самостоятельных составных частей — модулей. Модули разрабатываются и тестируются с учетом удовлетворения частных задач и требований на их реализацию. Если в процессе тестирования достигается заданная степень надежности модулей системы, то можно переходить к их интеграции и испытаниям системы в целом. Если в процессе тестирования обнаруживаются ошибки в составных частях или в системе в целом, то, обрабатывая информацию об ошибке, устанавливают породившую ее причину. По результатам подобных исследований проводится доработка составных частей или системы в целом, цель которой — устранение предполагаемых или установленных причин появления ошибок. [c.99]
Все цели должны быть поставлены в достаточных количественных оценках для последующего получения оценки по проекту в целом. Один из процессов тестирования, представленный в этом разделе, включает в себя испытание модуля на достижение целей. Каждая цель должна быть достаточно детальной, чтобы могли осуществляться процессы проектирования, но не должна предполагать конкретного проектного решения. [c.114]
Программисты обычно не имеют достаточной подготовки и опыта по этому виду проектирования. Они должны быть опытными в использовании языков программирования, методов организации вычислительных процессов, теории и практики компиляции, тестирования и отладки. В связи с этим было бы разумно использовать программистов в качестве проектировщиков модулей, предназначенных для средств отладки, компиляции и обнаружения ошибок, но вряд ли целесообразно поручать им разработку внешних спецификаций операционной системы, где они выступают не более чем пользователи. [c.116]
Внутренняя связность модулей, обладая чувствительностью к ошибкам, влияет также на степень адаптируемости программы, сложность организации тестирования отдельных модулей и возможность использования модуля в другом контексте и других программах. [c.132]
Другие принципы обеспечения независимости. Кроме внутренней и внешней связности, степень независимости модуля определяется и другими факторами. Например, размер модуля оказывает определенное влияние на независимость и читаемость программы, а также на сложность организации тестирования. Можно написать программу, отвечающую критериям максимальной внутренней и минимальной внешней связности, в качестве одного огромного модуля. Однако в целях снижения числа взаимосвязей между операторами программы и данными целесообразно разделить программу на некоторое количество самостоятельных модулей. Как правило, модуль должен состоять из 10—100 выполняемых операторов на языке высокого уровня. [c.135]
Для разрешения этой проблемы алгоритм модуля дополняется схемами тестирования по соответствующим признакам, областям действия, полноте и приемлемости. Выбор необходимых схем производится путем просмотра кода модуля с целью выяснения всех возможных предположений, касающихся входных данных, которые имеются в проектируемом модуле, с последующим рассмотрением этих проверок каждый раз, когда вызывается модуль. Аналогичные действия должны быть предприняты и по выходным данным модуля. [c.145]
Проверка. Заключительным шагом в процессе проектирования и кодирования модуля является проверка его логики. Проверка перед действительным выполнением программ на машине выполняется людьми. Очередной раздел будет посвящен тестированию, т. е. проверке логики при помощи выполнения программы на машине. [c.147]
Далее должны быть описаны данные, отмечены основные структуры и вид обработки данных. Это описание должно содержать хорошо подобранные примеры, иллюстрирующие функции и наиболее важные их видоизменения, что будет в дальнейшем полезно при тестировании. Каждый модуль должен иметь тестовые данные, описываемые вместе с модулями. [c.152]
Таким образом, тестирование программ одиночного модуля позволяет узнать о наличии ошибок, а отладка призвана определить причину этих ошибок. Поэтому отладка и тестирование представляют собой две различные частично перекрываемые стадии контроля. В этой связи затраты времени на тестирование должны быть разделены на отладку и собственно тестирование одиночного модуля с тем, чтобы подчеркнуть, что обе стадии нуждаются в выполнении. [c.170]
Получение полного набора тестовых комбинаций для модуля может показаться трудоемким, но никто и никогда не утверждал, что проверка легко осуществима. Следуя перечисленным выше шагам выбора тестовых комбинаций, придем к принципиально спроектированной программе тестирования с высоким уровнем обнаружения ошибок. Этот процесс займет больше времени, чем случайный процесс подбора тестовых комбинаций, но если он ведет к возможности обнаружения одной—двух дополнительных ошибок, то стоит пренебречь потерей времени скрупулезного подбора программы тестирования. [c.175]
Очередным этапом тестирования является написание и контроль проверочных программ. Физическая форма проверочной программы в определенной мере диктуется методом проведения интеграции, рассмотренным ранее. Сам процесс написания проверочных программ прост и сводится к написанию небольших программ вызова проверяемых модулей, подключению их на пропуск тестовых комбинаций и документированию результатов пропуска. С целью уменьшения объемов выдаваемых результатов признается лучшим вариантом программирование контроля выходных результатов в программе формирования обращения к модулю там, где это возможно. [c.175]
При проектировании функционального теста внешнюю спецификацию рекомендуется разделить на частные внешние функции а затем тщательно проверить каждую из. них. Для этих целей могут использоваться подходы, рассмотренные для случая тестирования единичного модуля. Они могут быть распространены на все входные условия и режимы, а также на все границы входных и выходных потоков данных. Эти способы обеспечивают также проверку программы на предмет ее поведения на функциональных границах и при появлении недействительных (ошибочных) или неожиданных данных на входе. . [c.176]
Как ив случае тестирования единичного модуля, каждый тест должен быть документирован с тем, чтобы при необходимости иметь возможность повторить его. В этом есть прямой смысл, так как возможные изменения на высшем уровне контроля могут потребовать повторной проверки всех низших уровней проверки. [c.176]
Группа разработки работает одновременно с группой интеграции, т. е. завершает разработку очередных модулей и их тестирование. Завершенные компоненты передаются для интеграции. Когда готов последний уровень системы, группа разработчиков должна провести функциональное тестирование системы. После появления очередной версии системы группа разработки должна изъять все предыдущие версии из употребления. Это обеспечивает использование всеми заинтересованными организациями последней версии системы. [c.178]
Тестирование модуля включает проведение определен ного объема работ проектирование набора тестовых -комбинаций на основе анализа внешних Спецификаций и программы модуля написание программы тестирования-и ее проверку и выполнение- программы тестирования Расемотр>ш содержание этих работ. " [c.173]
Трудозатраты на разработку выглядят слишком низкими. В совокупности с запараллеливанием разработки, программирования и тестирования модулей это дополнительное свидетельство очень тревожного положения дел. [c.173]
Функционирование всех узлов автомобиля Saturn — от тормозов до надувающихся при аварии воздушных подушек — контролируется тремя-шестью компьютерными модулями. Их диагностическое тестирование входит в обязанности специального инженера, который работает через интрасеть Saturn. Однажды ему удалось менее чем через два часа после первого сообщения о неисправности выявить ее причину, таившуюся в компьютерном модуле управления трансмиссией. Компания немедленно связалась с поставщиком, который перепрограммировал модули и вернул их на конвейер так скоро, что это даже не вызвало задержки производства. [c.297]
Прирост запасов образуется также в результате приобретения компанией сырья и материалов для производства или перепродажи. Поскольку стратегия Досса заключалась в том, чтобы закрепить за собой нишу рынка и получить дополнительную прибыль в результате тестирования и отбраковки комплектующих и изготовления электронных модулей, он планировал произвести вновь созданную стоимость на 420 тыс. долл., также увеличивающую объем запасов. Снижение же последнего обеспечивается ускорением реализации готовой продукции. [c.249]
Использование библиотек. Для улучшения построения программ, ускорения их отладки и тестирования важным средством является использование библиотек программ Одним из источников библиотечных программ является выполнение программистами требований универсальности разработки Универсальность — это независимость прог рам мы от конкретного набора данных. Опытные программисты знают, что придание программе универсальности позволяет в дальнейшем сохранить силы и сделает прог рамму более устойчивой по отношению к изменениям. Ре комендуется всегда писать модули программ с таким расчетом, чтобы за счет незначительных изменений или улучшений сделать программу полезной еще где-нибудь При таком исполнении универсальные программы могут быть каталогизированы в библиотеку программ для использования в других программах. [c.151]
Если программа неверно работает, то она должна отлаживаться. Следовательно, отладка всегда должна начинаться с некоторых доказательств неудачности программы. Если кажется, что программа работает верно, то она должна быть подвергнута контролю тестами. Часто после тестирования программа модуля возвращается на стадию отладки для устранения ошибок. [c.170]
Проектирование программы тестирования — процесс творческий, требующий аналитичёскЬгб мышления Одна-. ко существует определённый наборГ.простцх правил, которые позволяют получить разумное множество, проверочных тестов. Эти правила базируются на рассмотрении программы модуля как черного ящика и использовании , внешних спецификаций модуля для построения тестов далее на базе изучения программы, модуля строятся-дополнительные тесты. Эти действия выполняются за четыре шага, i [c.173]
Первый шаг программы тестирования предполагает рассмотрение модуля в качестве черного ящика и получает проверочные тесты путем обработки входных данных , модуля. Если модуль содержит целое число различных,, входных значений, то необходимо разработать тестовые. комбинации для каждого из них. При некотором множест- [c.173]
План построения определяет номера составных частей, их содержание, графическое построение и функциональные характеристики, В идеальном случае каждая очеред -ная составная часть отличается от предыдущей на одия модуль. Такой подход в полном объеме реализует понятие непрерывной интеграции системы, а это позволяет всегда выполнять тестирование легче, позволяет вернуться к любым новым функциям, после подсоединения Которых система ведет себя неправильно. Описываемый подход был использован при создании ОС/360. [c.177]