Cтраница 2
Когда дело доходит до последнего спина, группа разработчиков должна повторно выполнить тестирование внешних функций параллельно с комплексным тестированием. [16]
Если вы не сформулировали цели вашего продукта или если эти цели не измеримы, вы не можете выполнить комплексное тестирование. [17]
Ошибки, связанные с неправильным функционированием ИВС, могут быть выявлены в результате тестирования спецификаций данной версии на всех уровнях, автономного и комплексного тестирования компонент ПО, статического и динамического тестирования программно-информационного обеспечения. Область поиска причин ошибок целесообразно сузить за счет генерации входных данных, соответствующих ситуации, зафиксированной в момент нарушения нормального процесса функционирования ИВС. Для этого ИВС должен располагать соответствующими средствами сбора и обработки статистических данных о качестве функционирования, фиксации дополнительных детальных сведений о состоянии и режиме работы ТС, программного и информационного обеспечения при возникновении ошибочных ситуаций. [18]
Комплексное тестирование системы - такая особая и такая важная работа, что в будущем возможно появление компаний, специализирующихся в основном на комплексном тестировании систем, разработанных другими. [19]
Разработка каждой очереди занимает от 3 до 5 лет, согласно существующему опыту программных разработок ( САПР, АСУ и др.) - Результат разработки каждой версии программного обеспечения - это законченный программный продукт, который прошел полный цикл поэлементного и комплексного тестирования, а также опытного и промышленного внедрения. Кроме того, он должен быть снабжен всей необходимой документацией. Весь период создания конкретной очереди программного обеспечения подразделяется на стадии и этапы выполнения отдельных видов работ. В процессе их проведения осуществляется проверка соответствия предварительных результатов предъявленным целям и требованиям. Перечислим основные стадии работ по созданию программного обеспечения СППР: обоснование необходимости разработки новой версии ( очереди), разработка технического задания на создание программного обеспечения ( или ее части), разработка эскизного и технического проектов, рабочей документации и ввод в действие. [20]
Тестирование всегда должна выполнять внешняя группа, которая в некотором смысле стоит особняком от программиста и проекта. Комплексное тестирование всегда должно выполняться. [21]
Комплексное тестирование является процессом контроля, если оно выполняется в моделируемой среде, и процессом испытания, если выполняется в среде реальной, жизненной. [22]
Комплексное тестирование, вероятно, самая непонятная форма тестирования. Во всяком случае, комплексное тестирование не является тестированием всех функций полностью собранной системы; тестирование такого типа называется тестированием внешних функций. [23]
Кодирование сверху вниз подразумевает использование нисходящего тестирования вновь закодированных модулей с уже отлаженными модулями верхних уровней, при этом еще не разработанные модули нижних уровней имитируются специальными подыгрывающими подпрограммами - заглушками. Тестированием последнего модуля завершается комплексное тестирование всего ПО. [24]
При комплексном тестировании часто начинают с простых тестов, приберегая более сложные тесты к концу. Так делать не нужно, потому что комплексное тестирование приходится на самый конец цикла разработки, так что на отладку и исправление найденных ошибок остается мало времени. Поскольку сложные тесты часто обнаруживают более сложные для исправления ошибки, измените последовательность: начните с самых трудных тестов, а затем переходите к более простым. [25]
Нужно, чтобы тесто-вик думал так же, как пользователь или покупатель, а это предполагает доскональное понимание того, для чего система будет применяться. Поэтому возникает вопрос, кто же должен выполнять комплексное тестирование, и в частности кто должен проектировать тесты. Во всяком случае, этого не должны делать программисты или организации, ответственные за разработку системы. Группа тестирования системы должна быть независимой организацией и должна включать профессиональных специалистов по комплексному тестированию систем, несколько пользователей, для которых система разрабатывалась, основных аналитиков и проектировщиков системы и, возможно, одного или двух психологов. Очень важно включить самих проектировщиков системы. Это не противоречит аксиоме, согласно которой невозможно тестировать свою собственную систему, поскольку система прошла через много рук после того, как ее описали архитектор или проектировщик. В действительности проектировщик и не пытается тестировать собственную систему; он ищет расхождения между окончательной версией и тем, что он первоначально - возможно, год или два назад - имел в виду. Для комплексного тестирования желательно также иметь информацию о рынке или пользователях, уточняющую предположения о конфигурации и характере применения системы. [26]
Имитаторы играют важную роль при тестировании внешних функций и комплексном тестировании диалоговых систем и систем реального времени, но, очевидно, значительный объем тестирования должен быть выполнен и в реальной обстановке. Есть, однако, ситуации, когда при комплексном тестировании приходится полагаться только на имитацию. Здесь приходилось полагаться на имитацию, поскольку тестирование в реальной обстановке могло быть выполнено только в условиях настоящей войны. [27]
Тестирование модулей ( или тестирование блоков) выполняется с отдельными компонентами автономно. При объединении отдельных компонентов в подсистемы или системы проводится комплексное тестирование темы с целью проверки правильной совместной работы ее составных частей. При комплексном тестировании особое внимание обычно уделяется взаимодействию компонентов. В противоположность этому при системном тестировании вся система в целом обычно рассматривается как некоторый черный ящик; поведение этой системы исследуют, не вникая в подробности отдельных ее компонентов и взаимодействия между ними. Назначением приемочных испытаний является проверка пригодности системы для эксплуатации; такие испытания обычно проводятся под контролем поставщика системы. [28]
Либо в требованиях к продукту, либо в требованиях к проекту должны быть перечислены задачи, определяющие удобство обслуживания ( сопровождения) системы. Все сервисные средства системы, например программы выдачи дампов памяти, программы трассировки, диагностических сообщений - все это нужно проверять при комплексном тестировании. Все документы, описывающие внутреннюю логику, следует проанализировать глазами обслуживающего персонала, чтобы понять, как быстро и точно можно указать причину ошибки, если известны только некоторые ее симптомы. Все средства, обеспечивающие сопровождение и поставляемые вместе с системой, также должны быть проверены. [29]
Более сложные средства, кроме этого, накапливают статистические сведения о конкретной программе в базе данных или в файле. Хотя это и не обязательно при автономном тестировании, поскольку обычно все тесты модуля выполняются почти одновременно, зато важно при тестировании внешних функций или комплексном тестировании системы, которое растягивается на несколько недель или даже месяцев. Накопленная статистика позволяет определить, какие элементы алгоритма еще не проверялись достаточное число раз. [30]