1.Процедура линейного поиска – это:
1) просмотр массива с конца
2) просмотр массива с середины
3) сравнение эталона осуществляется с элементом, расположенным в середине массива
4) последовательный просмотр всех элементов массива и сравнение их с эталоном
2.Процедура поиска делением пополам заключается:
1) в просмотре массива с конца до середины
2) в просмотре массива с середины
3) в сравнении эталона с элементом, расположенным в середине массива
4) в последовательном просмотре всех элементов массива и сравнении их с эталоном
3.Дан алгоритм сортировки: определяется минимальный элемент сред всех и меняется местами с первым и т. д., начиная со второго. Вид сортировки:
1) метод прямого включения
2) метод прямого выбора
3) пузырьковый метод
4) с помощью «дерева»
4.Деструктивность процесса тестирования проявляется в следующем:
1) тест удачный, если обнаружена ошибка
2) тест удачный, если проведен без ошибок
Сергей Махетов — Kafka Тестирование и эксплуатация в условиях ограниченных ресурсов
3) тест неудачный, если обнаружена еще не выявленная ошибка
4) тест неудачный, если все задания некорректны
5.Тестирование программы как черного ящика заключается в следующем:
1) знаем, какие данные будут на выходе
2) не знаем, какие данные подаем на входе
3) анализ входных данных и результатов работы программы
4) управляем логикой программы, используя ее внутреннюю структуру
6.Формальный аргумент – это:
1) конкретное значение, присвоенное этой переменное вызывающей программой
2) переменная в вызываемой программе
3) строка, которая пишется в скобках функции
4) строка, которая пишется в скобках процедуры
7.Фактический аргумент – это:
1) конкретное значение, присвоенное этой переменной вызывающей программой
2) переменная в вызываемой программе
3) строка, которая пишется в скобках функции
4) строка, которая пишется в скобках процедуры
8.Писать #include нужно для:
1) подключения файла, содержащего макроопределения для работы функций из стандартной библиотеки ввода-вывода
2) позволяет дать в программе макроопределения (или задать макросы)
3) переопределения не только константы, но и целых программных конструкций
4) замены каждого параметра в строке лексем на соответствующий аргумент макровызова
9.Обращение к функции форматного ввода имеет вид:
1) scanf(, , , …, )
2) printf ((, , , …, )
3) scanf(, , , …, )
4) printf (, , , …, )
10.Идентификатором будет:
1) schetchik get_line a12 Param1_ab
2) %ab 12abc –x schetchik
3) ab 12abc –x schetchik
4) * ab 12abc –x schetchik
11.Тестирование программы – это:
1) оценивание ресурсов компьютера, на котором будет работать программа
2) перевод проекта в форму программы для конкретного компьютера
3) системный подход к построению алгоритма с использованием декомпозиции и синтеза
4) процесс исполнения программы с целью выявления ошибок
ТЕСТИРОВАНИЕ vs РАЗРАБОТКА (куча базированных примеров)
12.Инспекция при тестировании – это:
1) надзор за изменением состояний переменных
2) отслеживание логических ошибок
3) набор процедур и приемов обнаружения ошибок
4) надзор за соответствием типов и атрибутов переменных
13.Граничные условия в тестах – это:
1) ситуации, возникающие на, выше или ниже границ входных и выходных классов эквивалентности
2) тестовые задания, имеющие наивысшую вероятность обнаружения ошибок
3) выход индексов заданий за пределы допустимых
4) начальные и конечные условия границы применимости теста
14.Если данные размещены на внешнем носителе, то доступ к ним возможен:
1) моментальный
2) прямой
3) последовательный
4) выборочный
15.Если данные размещены в оперативной памяти, то доступ к ним возможен:
1) прямой
2) параллельный
3) последовательный
4) выборочный?
Источник: 4cht.com
Тестирование производительности и использования ресурсов компьютеров программными продуктами
Оценивание ресурсной эффективности состоит в измерении количественных характеристик: временной эффективности и используемости динамических ресурсов ЭВМ комплексом программ. При этом предполагается, что в контракте, техническом задании и спецификации требований зафиксированы и утверждены требуемые значения этих характеристик и их приоритетов. При тестировании производительности должны применяться промышленные нагрузки, что позволяет предсказать поведение программного комплекса и системы при реальной эксплуатации. Средства, обеспечивающее тестирование производительности, должны позволять оценивать влияние перегрузок.
Оценивание перегрузок — это процесс тестирования работоспособности вычислительных машин при обработке большого потока данных с целью выяснения того, когда и где программный комплекс выйдет из строя под высокой нагрузкой. Эти допустимые пределы должны быть определены в системных требованиях к программному комплексу, где также должна определяться реакция системы на перегрузки. Данный вид тестирования необходим для систем, работающих с максимальной спроектированной нагрузкой, для проверки того, что они динамически функционируют в соответствии с требованиями.
Адекватное проведение динамического тестирования программного комплекса на перегрузки, при использовании ручных методов подготовки тестов — дорого, трудоемко, неточно и занимает много времени. Выделение значительных ресурсов для тестирования требует больших затрат, и трудно организовать совместную работу необходимого числа пользователей и компьютеров. Необходимы средства автоматизированного тестирования, которые включают имитаторы нагрузки и позволяют тестировщикам динамически имитировать виртуальных пользователей или объектов, одновременно работающих с целевым программным продуктом.
Для измерения характеристик временной эффективности необходимы инструментальные средства, встроенные в операцион ную систему или в соответствующий комплекс программ. Эти средства должны в динамике реального функционирования программного комплекса регистрировать:
- • загрузку вычислительной системы функционирующими программами;
- • значения интенсивности потоков данных для обработки от конкретных внешних абонентов;
- • длительность исполнения типовых заданий при реализации конкретных функций;
- • характеристики функционирования устройств ввода/вывода;
- • время ожидания результатов (отклика) на функциональные задания пользователей или системы;
- • заполнение памяти обмена с внешними абонентами в различных режимах применения программного комплекса.
Значения этих характеристик зависят не только от свойств и функций комплекса программ, но также от особенностей архитектуры и операционной системы компьютера. Регулярная регистрация и обобщение таких данных позволяет выявлять ситуации, негативно влияющие на функциональную пригодность, надежность и другие важные характеристики программного комплекса. Существует особый вид тестов для проверки удовлетворения специфических требований, предъявляемых к параметрам производительности. При этом может производиться динамическое тестирование с целью достижения реальных (достижимых) возможностей по производительности, и функционирования программ с повышением нагрузки.
При высокой интенсивности поступления исходных данных может нарушаться временной баланс между длительностью решения требуемой совокупности задач программным комплексом в реальном масштабе времени, и производительностью компьютера при решении этих задач. Также возможно нарушение баланса между имеющейся в компьютере памятью и памятью, необходимой для хранения всей поступившей и обрабатываемой информации. Для выявления подобных ситуаций и определения характеристик программного комплекса в условиях недостаточности ресурсов компьютера проводятся испытания при высокой, но допустимой, в соответствие с требованиями, интенсивности поступления исходных данных.
При использовании комплексом программ производительности и памяти реализующем компьютером менее чем на 50%, разработчик может практически не учитывать эти ограничения и сопутствующие риски. Закономерным является стремление разработчиков программ применять, особенно для систем реального времени, встроенные объектные компьютеры с предельным использованием их технических характеристик. Опыт создания программ реального времени позволяет утверждать, что практически невозможно использовать производительность объектного компьютера более чем на 95%, и почти всегда целесообразно ограничиваться на уровне 80 — 90%, так как иначе, затраты на разработку программного комплекса могут значительно увеличиться. Для оценивания характеристик использования производительности при тестировании крупных программных продуктов должны быть измерены:
- • реальные значения интенсивностей поступающих исходных данных и заданий на вызов функциональных программ, а также распределения вероятностей этих интенсивностей для различных источников и типов заданий;
- • длительности автономного решения отдельно каждой функциональной задачи, обрабатывающей исходные данные или включаемой внешними заданиями, а также периодически;
- • загрузка компьютера в нормальном режиме поступления сообщений и заданий, а также вероятность перегрузки заданиями различных типов и возможные распределения длительностей перегрузки в реальных условиях;
- • влияние пропуска в обработке заданий или сообщений каждого типа и снижения темпа решения определенных задач на функциональную пригодность и другие важные характеристики программного комплекса.
Перечисленные задачи могут быть решены экспериментально в процессе тестирования завершенного разработкой программного комплекса, однако при этом велик риск, что производительность компьютера окажется недостаточной для решения заданной совокупности задач в реальном времени, что отразится на качестве использования системы. Поэтому при оценивании требуется принимать специальные меры для создания реальных, а также контролируемых, наиболее тяжелых по загрузке условий функционирования комплекса программ и внешней среды. Такие критические ситуации могут быть в значительной степени предотвращены в процессе разработки комплекса программ путем расчета длительностей исполнения компонентов по тексту программ, и объединения этих характеристик в соответствии со структурой всего комплекса программ.
Для корректного оценивания предельной пропускной способности системы с данным программным комплексом необходимо измерять следующие характеристики реализации функциональных программ в процессе разработки:
- • экстремальные значения длительностей их исполнения и маршруты, на которых эти значения достигаются;
- • среднее значение длительности исполнения каждой функциональной группы программ на всем возможном множестве маршрутов и его дисперсию;
- • распределение вероятностей и значений длительности исполнения функциональных групп программ.
Для оценивания ресурсной эффективности, при подготовке технического задания и спецификаций требований следует согласовывать с заказчиком модель и характеристики внешней среды, в которой будет применяться комплекс программ, а также динамику приема и передачи данных. Для определения использования комплексами программ временных ресурсов компьютеров полезно применять рекомендации стандарта ISO 14756. Стандарт ориентирован на динамическое оценивание: программных комплексов, операционных систем и вычислительных комплексов, включающих аппаратные и программные средства.
По результатам квалификационного тестирования и испытаний могут быть решены задачи динамического оценивания ресурсной эффективности программного комплекса, что позволяет анализировать факторы, определяющие необходимую пропускную способность компьютера, и разрабатывать меры для приведения ее в соответствие с потребностями. Если предварительно в процессе проектирования производительность системы не оценивалась или определялась слишком грубо, то, велик риск, что доработки будут большими или может понадобиться заменить компьютер на более быстродействующий. Это обусловлено, как правило, «оптимизмом» разработчиков, что приводит к занижению интуитивных оценок длительностей решения функциональных задач и возможных предельных интенсивностей потоков внешней информации.
Источник: ozlib.com
ЛЕКЦИЯ 13. Лекция 13 верификация, тестирование и оценивание корректности программных компонентов
Единственный в мире Музей Смайликов
Самая яркая достопримечательность Крыма
Скачать 200.7 Kb.
13.4. Процессы тестирования структуры программных компонентов
- верификацией — последовательным прослеживаниемсверху вниз реализации требований к системе и ПС программными компонентами нижних уровней;
- определением полноты покрытия тестамиих структуры и проверками выполнения исходных требований к ПС и его компонентам.
Покрытие тестами может оцениваться по степени охвата тестированием набора требований к программе или по покрытию тестами структуры программы. Прослеживание и покрытие тестами набора требований к программам трудно формализовать и оценить их влияние на достигаемую корректность ПС. Имеющийся опыт показывает, что такой анализ вполне доступен для неформального анализа, но относительно слабее влияет на корректность, чем недостаточное тестирование структуры программ. Поэтому ниже внимание сосредоточено на оценивании тестирования и корректности структурного покрытия программ.
Анализ и оценивание покрытия тестами структуры программ позволяет выявить дефекты и ошибки, угрожающие наиболее тяжелыми последствиями при функционировании ПС. Ограниченные ресурсы трудоемкости и времени на тестирование сложных комплексов программ для обеспечения их максимальной корректности приводят к необходимости рационального использования доступных ресурсов, прежде всего, для устранения самых опасных ошибок.
Тестирование фрагментов структуры программы не гарантирует полное отсутствие ошибок в них, однако существенно снижает их вероятность. Пропущенные при тестировании фрагменты структуры заведомо могут содержать невыявленные ошибки, которые негативно отражаются на корректности программ. Таким образом, тестирование структурного покрытия программ является необходимым условием обеспечения их относительной корректности, однако оно недостаточно для полного обеспечения корректности их функционирования. В то же время тестирование и покрытие тестами структуры программ наиболее доступно формализации для оценивания достигаемой относительной корректности и вероятности отсутствия ошибок в программе и позволяет устранять наиболее опасные ошибки, угрожающие отсутствием или полным искажением требуемых результатов на выходе ПС.
На практике при отсутствии упорядоченного анализа потоков управления некоторые маршруты в программе оказываются пропущенными при тестировании (до 50%), поэтому первая задача, которая должна решаться при тестировании структуры программ, — это получение информации о полной совокупности реальных маршрутов исполнения в каждой программе и ее структурной сложности. Такое представление покрытия программы позволяет упорядоченно контролировать достигнутую проверку
392
13.4. Процессы тестирования структуры программных компонентов
маршрутов и, в некоторой степени, предохраняет от случайного пропуска отдельных нетестировавшихся маршрутов и их элементов.
Полное структурное покрытие программы тестами определяется числом взаимодействующих компонентов, числом связей между компонентами и сложностью их взаимодействия. Структурная сложность и корректность программного модуля зависит не столько от размера программы (числа строк текста), сколько от числа отдельных путей-маршрутов ее исполнения, существующих в программе. В пределе для обеспечения полной структурной корректности все маршруты возможной обработки данных должны быть проверены при создании программы, и тем самым определяют сложность ее тестирования.
В ряде случаев подтверждена достаточно высокая адекватность использования структурной сложности программ для оценки трудоемкости тестирования, вероятности невыявленных ошибок и затрат на разработку программных модулей и компонентов в целом. Сложность тестирования структуры программных модулей можно оценивать по числу маршрутов, необходимых для их проверки, или более полно — по суммарному числу условий, которое необходимо задать в тестах для исполнения всех маршрутов программы. Анализ критериев тестирования, тестовых покрытий и выделение тестируемых маршрутов удобно проводить, используя графовые модели программ. При планировании тестирования структуры программ возникают, прежде всего, две задачи: формирование критериев выделения маршрутов для тестирования и выбор стратегий упорядочения выделенных маршрутов.
Критерии выделения маршрутов для тестирования соответствуют критериям определения структурной сложности программных модулей. В основном используются следующие критерии:
Xj — покрытие графа программы минимальным количеством маршрутов, охватывающих каждую дугу графа хотя бы один раз;
Х2 — выделение всех линейно независимых маршрутов, отличающихся хотя бы одной дугой в маршруте от остальных;
Х3 — выделение маршрутов при всех возможных комбинациях дуг, входящих в маршруты.
Планировать тестирование можно по одному из критериев или используя последовательно более жесткие критерии выделения маршрутов, при которых возрастают соответственно объем и сложность тестирования.
393
Лекция 13. Верификация, тестирование и оценивание корректности компонентов
К значительному возрастанию числа маршрутов обычно приводят циклы в программах.
Стратегии упорядочения маршрутов. Показатель важности маршрута для тестирования программы и для оценивания ее корректности может учитывать сложность маршрута и тестов для его проверки: число операторов, условных переходов и циклов в маршруте; частость его исполнения при рабочем функционировании ПС; сложность получения соответствующих эталонных данных. В первую очередь для установления корректности программы целесообразно производить проверку основной группы маршрутов с экстремальными значениями выбранного показателя сложности в пределах ресурсов, выделенных для тестирования. При имеющихся ограничениях ресурсов некоторая часть маршрутов может оказаться непроверенной и характеризует достигнутую корректность данной программы по выбранному критерию.
- стратегия 1 учитывает число строк текста программы в выделенных маршрутах или расчетную длительность их исполнения при функционировании программы;
- стратегия 2 анализирует число альтернатив или условных переходов, определяющих образование каждого маршрута;
- стратегия 3 базируется на использовании вероятности исполнения маршрутов при реальном функционировании программы.
При стратегии 2 приоритет отдается маршрутам, наиболее сложным по числу анализируемых условий. Такая стратегия предпочтительна при тестировании логических программ с небольшим объемом вычисле-
394
13.4. Процессы тестирования структуры программных компонентов
ний. При обеих стратегиях на завершающие этапы тестирования остаются простые по вычислениям или по логике маршруты, которые отражают потенциальную, структурную некорректность программы. Это соответствует традиционной стратегии многих разработчиков программ подготавливать вначале тесты с возможно большим охватом вычислительных или логических компонентов программы и скорейшим достижением по возможности высокого уровня их корректности.
При упорядочении маршрутов по стратегии 3 основная сложность состоит в оценке и учете вероятностей ветвления в условных переходах и переключателях, а также числа исполнения циклов. Их значения должны указываться разработчиками программ, что достаточно трудоемко и субъективно. Тем не менее такая стратегия позволяет наиболее детально планировать тестирование и оценивать предельный уровень корректности программ.
Эффективность тестирования определяется полнотой проверки программного модуля или вероятностью наличия невыявленных ошибок в зависимости от затрат ресурсов: на создание тестов, исполнение программ и анализ результатов тестирования. Затраты в значительной степени зависят от суммарной сложности формирования тестов, проверяющих маршруты исполнения программы.
На каждой дуге графа программы между условными переходами производятся вычисления и преобразования переменных, объем которых может изменяться в широких пределах. Для упрощения анализа и оценивания тестирования структуры программ предположим, что длительность и сложность вычислений на дугах графов программ одинаковы и относительно невелики. Некоторые вершины графа программы могут образовываться в результате схождения дуг без последующего ветвления. Такие вершины не влияют на число маршрутов, и их можно обобщать с ближайшей последующей вершиной, в которой происходит ветвление. При этих предположениях сложность теста, проверяющего каждый /-й маршрут, в первом приближении пропорциональна числу дуг графа программы, входящих в этот маршрут, или числу Etусловий, которые необходимо задать в тесте.
Экспериментально подтверждена адекватность использования структурной сложности программ для оценки трудоемкости тестирования, а также вероятности наличия невыявленных ошибок и затрат на разработку программных модулей в целом. Сложность тестирования ПМ
395
Лекция 13. Верификация, тестирование и оценивание корректности компонентов
можно оценивать по числу маршрутов Мх, необходимых для их проверки, или более полно по суммарному числу условий Ех, которое необходимо задать в тестах для прохождения всех маршрутов программы, выделенных по Х-му критерию:
- маршруты исполнения преимущественно вычислительной части программы и преобразования непрерывных переменных;
- маршруты принятия логических решений и преобразования логических переменных.
My /;
x=2jZ, u V (13.2)
13.4. Процессы тестирования структуры программных компонентов
Расчет показателя сложности тестирования программного модуля по такой схеме имеет значительную неопределенность из-за произвола в выборе числа значений яи(в основном особых точек) при варьировании исходных данных в тесте. В то же время доля вычислительной части во многих сложных ПС относительно невелика.
Второй вид маршрутов является результатом функционирования схем принятия решений и преобразования логических переменных. Для логических переменных отсутствует сильная корреляционная связь между соседними значениями, и каждое изменение переменной может определять разные области результирующих значений. Такое преобразование переменных обеспечивается алгоритмами со сложной логической структурой, содержащей ряд проверок логических условий, циклов для поиска и селекции переменных, а также логические преобразования переменных. В результате в программе образуется множество маршрутов обработки исходных данных, которые определяют сложность структуры программы.
Структурная сложность программного модуля может быть рассчитана по числу маршрутов Мхв программе и сложности каждого /-го маршрута Е(. Эти показатели в совокупности определяют минимальную сложность £*-тестов для проверки программного модуля (13.1), а следовательно, трудоемкость его разработки и тестирования и вероятность пропуска логической ошибки в программе. Программные модули являются наиболее массовыми компонентами в ПС и требуют для тестирования суммарно наибольших затрат ресурсов. Затраты на тестирование каждого модуля прямо пропорциональны сложности, которая зависит от его структуры и объема вычислений /,. При тестировании программного модуля необходимо задать и проанализировать число значений параметров:
Суммарные затраты ресурсов на тестирование модуля пропорциональны значению его сложности Вхи, с учетом удельных затрат на создание каждого теста — с, определяются выражением:
397
Лекция 13. Верификация, тестирование и оценивание корректности компонентов
Значение множителя с зависит от степени автоматизации процесса тестирования и генерации тестов. В высокоавтоматизированных системах сокращаются затраты ручного труда на подготовку и анализ тестовых данных, однако увеличиваются затраты на машинное время, необходимое для генерации тестов и для автоматической обработки результатов тестирования. В зависимости от этих факторов значения множителя с могут различаться в несколько раз, и их следует экспериментально определять для каждой системы автоматизации тестирования.
Сложность тестирования программ, содержащих циклы. Наличие циклов в программе способно резко увеличивать сложность их тестирования. Полное, исчерпывающее тестирование должно охватывать проверку каждого маршрута в цикле при всех возможных итерациях цикла и при всех сочетаниях циклов с маршрутами ациклической части программы. Предположим для простоты, что число маршрутов в нижней ациклической части программы равно Мъ = 1. Тогда полное множество маршрутов М состоит из полной совокупности всех маршрутов Мхв верхней ациклической части программы и группы маршрутов М2, в которой к каждому маршруту из Мхприсоединено 1..2..3. итерации (витка) цикла. При этом на каждой итерации выполняется, по крайней мере, один из внутренних маршрутов тела цикла.
Например, для графа, имеющего один цикл, требующего исполнения пяти итераций (витков) с тремя внутренними маршрутами, а также содержащего Mi = 10 ациклических маршрутов, проходящих через цикл, суммарное число маршрутов для исчерпывающего тестирования равно М = (3 х 5) х 10 = 150. При возрастании любого из сомножителей (числа независимых ациклических маршрутов, проходящих через цикл, числа внутренних маршрутов тела цикла или числа его итераций) пропорционально растет их произведение, а следовательно, и сложность тестирования. Поэтому исчерпывающее тестирование реальных сложных программ с циклами может быть практически невозможно.
На сложность тестирования цикла оказывают влияние его структура и два параметра: число маршрутов в теле цикла и число итераций цикла. В динамике реального исполнения простейшего цикла между его итерациями могут существовать зависимости, по крайней мере, трех видов’.
— на разных итерациях цикла исполняются независимо все возможные маршруты тела цикла;
- на всех итерациях цикла исполняется один и тот же маршрут тела цикла или некоторая определенная их последовательность;
- на разных итерациях цикла в силу наличия семантических связей исполняется подмножество реализуемых маршрутов тела цикла, зависящее от данных или от номера итерации.
Для оценки сложности структурного тестирования ациклических логических программ с простейшими циклами целесообразно уточнить критерии проверки. По первому критерию ациклическая часть программы покрывается минимальным числом маршрутов, в которые входят маршруты, проходящие через цикл, размыкающие его и образующие минимальное покрытие тела цикла.
Кроме того, к покрытию добавляется маршрут, содержащий замыкающую дугу цикла. По второму критерию ациклическая часть программы проверяется количеством тестов, равным сложности ациклической части программы. При этом к каждому такому маршруту присоединяются все примыкающие к нему циклы. Проверка каждого цикла осуществляется одним маршрутом, содержащим столько итераций, какова сложность тела цикла, а тело цикла покрывается линейно независимыми маршрутами.
399
Лекция 13. Верификация, тестирование и оценивание корректности компонентов
При таких оценках определяющими факторами являются полнота проверки тела цикла, условий его замыкания и размыкания. При этих критериях сложность цикла наиболее просто оценить, представив его эквивалентным ациклическим подграфом. Например, при втором критерии эквивалентным циклу с одной точкой входа и одной точкой выхода будет линейный подграф, содержащий последовательно соединенные все линейно независимые маршруты тела цикла, связывающие его точку входа с точкой выхода. Такой эквивалентный ациклический подграф добавляется к каждому маршруту в покрытии ациклической части графа по этому критерию.
При применении вложенных циклов со сложной структурой и с большим числом ветвлений в теле цикла сложность тестирования резко возрастает и повышается вероятность сохранения в программе необнаруженных ошибок. Однако циклы с простейшей структурой приводят к относительно небольшому увеличению суммарной сложности тестов. Поэтому в процессе проектирования программ необходимо в максимальной степени упрощать циклические компоненты в структуре, которые во многих случаях определяют достигаемую корректность программных модулей при их тестировании.
Выражение (13.3) целесообразно использовать для выявления сложных модулей, требующих наибольших затрат на тестирование, и для рационального распределения ограниченных ресурсов тестирования модулей при создании крупномасштабных комплексов программ. Некоторые модули могут оказаться недостаточно протестированными из-за их высокой сложности и необходимости больших затрат, которые всегда ограничены. Ограниченность ресурсов на тестирование программных модулей приводит к целесообразности выравнивания их структурной сложности и выделения затрат на проверку в соответствии со сложностью каждого модуля. Особенно сложные модули следует делить на более мелкие и простые и так перестраивать их структуру, чтобы сокращалось суммарное число маршрутов в каждом отдельном модуле и их длина.
Сложность тестирования программных компонентов (функциональных групп программ) определяется суммарной сложностью модулей и межмодульных связей по управлению и по информации. Каждый модуль должен тестироваться автономно до включения в группу программ и частично в составе группы. Затраты на тестирование модулей в составе
400
13.5. Примеры оценок сложности тестирования программ
группы программ должны учитывать относительные суммарные затраты на тестирование всех входящих модулей с коэффициентом dk 5 6 7
Источник: topuch.com