Лекция
Привет, Вы узнаете о том , что такое интеграционное тестирование , Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое интеграционное тестирование , квалификационное тестирование, испытания комплексов программ , настоятельно рекомендую прочитать все из категории Качество и тестирование программного обеспечения. Quality Assurance..
Для оценивания характеристик и испытаний программных средств на различных этапах жизненного цикла в качестве методологической основы целесообразно использовать рекомендации стандарта ISO 14598:1-6 — Оценивание программного продукта. Процесс оценивания ПС в стандарте представлен как совокупность действий, выполняемых в кооперации заказчиком и оценщиком — испытателем. Потенциальными заказчиками оценивания ПС могут быть разработчики, поставщики, покупатели, пользователи ПС, производители систем обработки информации, а также третейские испытательные лаборатории программных продуктов. Для получения наибольшего эффекта от результатов испытаний рекомендуется, чтобы оценивание было насколько возможно:
объективным — результаты оценивания должны базироваться на реальных фактах, не окрашенных чувствами или мнениями испытателей;
повторяемым — повторное оценивание тождественного продукта для тождественной спецификации тем же испытателем должно давать те же результаты, что и при первичном оценивании;
воспроизводимым — оценивание того же продукта для той же спецификации различными специалистами должно давать те же результаты, как и при предыдущем испытании;
— беспристрастным — исполнители процесса оценивания должны относиться непредубежденно к любому конкретному результату.
Общую схему процессов оценивания характеристик комплексов программ составляют (рис. 14.1):
Формализация исходных требований для оценки программного средства:
определение целей испытаний и оценивания качества на промежуточных и завершающих этапах ЖЦ ПС;
идентификация типа программного средства;
идентификация потребителей результатов оценивания;
выделение особенностей модели оценивания и состава требуемых характеристик качества
Формализация принципов оценивания характеристик и испытаний программного средства:
селекция характеристик программного средства и типизация требований для измерений и испытаний;
установление уровней приоритета характеристик и атрибутов качества;
выделение критериев для экспертизы и сравнения характеристик качества с требованиями
*
Проектирование процессов оценивания и испытаний характеристик программного средства:
разработка планов проведения оценки характеристик программного средства в соответствии с потребностью пользователей и этапами жизненного цикла;
проектирование процессов оценивания характеристик и испытаний программного средства
Реализация процессов и использование результатов оценивания характеристик программного средства:
выполнение испытаний для оценки реальных значений характеристик программного средства;
сравнение результатов испытаний с критериями требуемых характеристик программного средства;
оценка и обобщение результатов испытаний характеристик программного средства
Рис. 14.1
формализация исходных требований для оценки значений характеристик программного средства, определение целей испытаний, идентификация потребителей результатов испытаний;
формализация принципов и особенностей оценивания при проведении экспертиз, измерений и испытаний характеристик программного средства, выделение критериев для сравнения полученных характеристик с требованиями;
планирование и проектирование процессов оценивания характеристик в жизненном цикле программного средства в соответствии с потребностями пользователей этих характеристик;
реализация процессов испытаний, измерений и оценивания достигнутого качества программного продукта, сравнение результатов испытаний с требованиями; оформление и использование результатов.
В первой части стандарта представлена концепция планирования и управления процессами оценивания характеристик программ, а также их связь с процессами управления жизненным циклом ПС (по ISO 12207). При подготовке к испытаниям рекомендуется структурировать технологию и процедуры применения конкретного ПС с целью последовательного детального оценивания групп функциональных характеристик или отдельных атрибутов качества на этапах жизненного цикла.
Решение о проведении оценивания характеристик ПС может быть принято в процессе разработки и всего ЖЦ. Если такое решение принято на начальном этапе разработки, то появляется возможность встроить в процессе разработки тесты и средства измерения для испытаний. Это обеспечивает максимальный успех в удовлетворении всех требований относительно результатов оценивания характеристик ПС и минимизирует риск ошибок в экстремальных, незапланированных ситуациях. Когда заказчиком является разработчик ПС, ранний контакт с оценщиком для испытания или экспертизы может помочь разработчику учесть некоторые специальные требования со стороны испытателя. Для очень больших, сложных проектов ПС разработчику должно быть выгодным иметь детальную кооперацию с оценщиком характеристик во время всего процесса разработки продукта для минимизации продолжительности и стоимости процесса испытаний. Обязанностьюзаказчика испытаний должно быть:
— установить его необходимые легальные права для выполнения испытаний ПС;
предоставить испытателю информацию, необходимую для идентификации и описания программного средства и компонентов;
установить начальные требования и вступить в переговоры с испытателем для выработки реальных оценочных требований;
требования к испытаниям следует подчинять соответствующим регламентирующим документам и стандартам;
установить требования к конфиденциальности информации, передаваемой на испытания;
при необходимости обеспечить поддержку испытателю, включая обучение и доступ к подходящим документам;
гарантировать своевременную поставку испытателю описания и компонентов ПС, включая документацию и другие материалы;
информировать испытателя о любых возможных факторах, которые могут обесценить результаты испытаний.
Испытателю следует проанализировать технические ограничения, относящиеся к измерениям или верификациям, заданным в спецификации оценивания, и документировать подходящий метод. Метод оценивания — это процедура, описывающая действие, выполняемое испытателем при получении результата специфицированного измерения, экспертизы или верификации для системы, компоненты или ПС. Когда метод оценивания описывается на основе программного инструментария, данный инструментарий должен быть идентифицирован в плане и методике испытаний. При этом обязанности оценщика — испытателя включают:
проверить легальные права заказчика на систему и ПС для оценивания, для чего испытатель может потребовать соответствующие документы от заказчика;
хранить конфиденциальность обо всей информации, передаваемой заказчиком, включая тексты ПС, записи результатов и отчет об испытаниях;
предоставить квалифицированный и обученный персонал для выполнения испытаний;
обеспечить инструментарий и технологию оценивания;
выполнить испытания в соответствии с оценочными требованиями и спецификацией заказчика;
хранить записи любой работы, выполняемой при оценивании, которые воздействуют на результаты;
— обеспечить наглядность проведения испытаний для наблюдения заказчиком и своевременную передачу отчета об оценивании заказчику.
Оценочные требования должны содержать общее описание области применения ПС и состоять из перечня требований к характеристикам. Должна быть указана относительная значимость (приоритет) конкретных характеристик в требованиях. Для каждого положения в оценочных требованиях должна быть представлена спецификация информации, содержащейся в компонентах ПС.
Спецификация оценивания — испытаний должна определять область экспертизы и измерения различных компонентов продукта, передаваемого на оценивание. Уровень детализации в спецификации испытаний должен быть таким, чтобы на ее основе гарантировались повторяемость и воспроизводимость испытаний. Заказчик должен представить описание оцениваемого продукта. Целью такого описания является определить область оценивания и идентификацию тех компонентов, которые рассматриваются как часть продукта, в отличие от компонентов ПС, на которые только ссылаются для облегчения понимания функций продукта. Это должно позволить разложить оценочные требования на субхарактеристики. Затем испытатель должен специфицировать методы измерения и экспертизы, предназначенные для анализа характеристик, субхарактеристик и атрибутов качества выбранных компонентов. Оценщик должен выполнять верификацию спецификации оценивания в соответствии с требованиями, установить, что компоненты, перечисленные в описании продукта, содержат всю необходимую информацию для выполнения оценивания в соответствии с требованиями.
План испытаний или экспертизы характеристик программных продуктов должен состоять из разделов:
введение — постановка задачи и цели оценивания — испытаний;
методология обеспечения объективности испытаний характеристик ПС;
выделенные для проекта характеристики и атрибуты качества и безопасности ПС по стандарту ISO 9126:1-4 и другим стандартам;
требуемое качество ПС и достоверности процессов испытаний;
расписание выполнения работ по испытаниям характеристик ПС;
распределение обязанностей и ответственности специалистов при оценивании характеристик и атрибутов качества;
анализ и использование результатов испытаний;
содержание и оформление отчетов по выполнению испытаний;
дополнительные требования по технике, инструментальным средствам и методам обслуживания испытаний, по соответствию стандартам и организационной поддержке измерений и экспертиз.
Испытатель должен обеспечить входные данные для процесса оценивания: предопределенные спецификации оценивания; методы и инструментарий. Процесс оценивания — испытаний рекомендуется в стандарте из следующих действий:
анализ оценочных требований, при котором выделяются для идентификации реальные требования заказчика на испытания;
спецификация процессов и возможных результатов, при которой вырабатывается спецификация оценивания на основе требований и описания программного продукта, предоставляемых заказчиком;
проект процессов испытаний, при котором вырабатывается план на основе спецификации оценивания, компонентов ПС и методов, предлагаемых испытателем;
процесс выполнения плана оценивания, который состоит из моделирования, экспертизы, измерения и испытания компонентов ПС в соответствии с планом, с использованием программного инструментария, а также действия, осуществляемые испытателем, которые фиксируются и результаты заносятся в отчет;
заключение по оцениванию, которое состоит в предоставлении отчета о результатах испытаний компонентов и ПС.
В процессе испытаний может потребоваться использование программных инструментов для сбора обработанных данных или для осуществления интерпретации промежуточных данных. Штат оценщиков должен быть обучен пользоваться соответствующими инструментами. При оценивании должны быть получены, зафиксированы и предъявлены заказчику следующие данные:
требования, которые описывают цели оценивания, в частности, требуемая критичность и безопасность испытанного продукта;
спецификация оценивания, которая определяет весь анализ и выполняемые измерения, и все компоненты ПС, которые должны анализироваться и измеряться;
план оценивания, который описывает операционные процедуры, необходимые для выполнения спецификации оценивания, в частности, все методы и инструменты, используемые при оценивании;
записи об оценивании, которые состоят из плана оценивания и детальных действий оценщика при выполнении плана;
отчет по оцениванию характеристики, который содержит требования, спецификацию оценивания, результаты измерений и анализа, а также любую другую информацию, необходимую для возможности повторения или воспроизведения оценивания, а также обобщенный отчет заказчику.
Цель заключения состоит в обзоре отчета об испытаниях и передаче данных оценивания заказчику. Следует организовывать совместный обзор и анализ отчета заказчиком и испытателем. Заказчику следует дать возможность сделать комментарии по отчету. Если такие комментарии сделаны, то их следует внести в специальный раздел отчета, после чего он должен быть передан испытателю и заказчику.
С позиций разных потребителей результатов измерения и оценивания качества ПС построены третья, четвертая и пятая части стандарта ISO 14598:1-6 — соответственно для:
разработчиков — оценивание внутренних и внешних характеристик качества (ч. 3);
оперативных пользователей — измерение внешних метрик и метрик в использовании (ч. 4);
заказчиков и испытателей — определение метрик в использовании (ч. 5).
В каждой части выделены и детализированы подобные разделы: особенности и потребности конкретных пользователей в результатах испытаний и номенклатуре требуемых характеристик ПС; концепция проведения испытаний и оценивания качества; определение требований к процессам испытаний характеристик программ; идентификация характеристик и атрибутов качества ПС для конкретных пользователей результатов испытаний.
Результаты оценки характеристик предлагается отражать с позиции: процессов жизненного цикла; продуктов и их компонентов; функционирования и применения ПС. Требования к процессам оценивания рекомендуется структурировать на главные (функциональные), организационные, проектные, а также выделять внутренние и внешние метрики качества и их измерение, ориентируясь на субхарактеристики и их атрибуты в соответствующих частях стандарта ISO 9126:1-4. Реализация процессов испытаний программного продукта по требованиям стандарта должна проводиться квалифицированными и аттестованными специалистами, независимыми от разработчиков проекта, процессов создания ПС и его компонентов, однако коррелированно с этапами жизненного цикла конкретного проекта в соответствии с применяемой адаптированной версией стандарта ISO 12207.
Обращается внимание на целесообразность учета и использования истории развития и изменений эксплуатационных требований заказчиков-потребителей к определенному проекту и функциональному назначению ПС. В отчете об испытаниях рекомендуется представлять характеристики качества в соответствии с номенклатурой и мерами субхарактеристик и атрибутов, адаптированными к назначению, функциям и особенностям конкретного проекта ПС и потребителей результатов измерений.
Конфиденциальность всех компонентов и документов испытаний ПС должна защищаться оценщиком. Требования конфиденциальности охватывают многие аспекты оценочной работы: включая получение, управление, хранение и передачу всей информации, касающейся характеристик продукта. Конфиденциальность промежуточных данных испытаний должна защищаться, так же как и конфиденциальность оригиналов компонентов и документов. Испытатель должен приложить усилия, чтобы предотвратить любые случайные, ошибочные или злоумышленные модификации этих данных.
Характеристики качества функционирования программных средств зависят не только от их внутренних свойств, но и от свойств внешней среды, в которой они применяются (см. ISO 12119). Для сокращения неопределенностей и прямых ошибок при оценивании качества ПС необходимо до начала испытаний определить основные параметры внешней среды, при которых должен функционировать комплекс программ с требуемыми характеристиками при оценивании его качества и эксплуатации.
Для этого заказчик и разработчик совместно должны структурировать, описать и согласовать модель внешней среды и ее параметры в среднем, типовом режиме применения ПС, а также в наиболее вероятных и критических режимах, в которых должны обеспечиваться требуемые характеристики качества функционирования ПС. Такая модель должна отражать и фиксировать характеристики:
внешних потоков информации, в том числе их распределение по видам источников, характеристикам качества данных и возможности их дефектов;
интенсивность и структуру типовых сообщений от оперативных пользователей и администраторов и их необходимую квалификацию, отражающуюся вероятностью ошибок и качеством выдаваемой информации;
возможных негативных и несанкционированных воздействий от внешней среды при применении ПС;
необходимые характеристики вычислительных средств, на которых предназначено функционировать комплексу программ с требуемым качеством.
При сопоставлении результатов оценивания характеристик качества с требованиями технического задания и спецификаций разработчик или поставщик обязан удовлетворять требования заказчиков только в пределах согласованных параметров модели внешней среды. Оценивание качества ПС за этими пределами должно дополнительно согласовываться испытателями с разработчиком. При этом невыполнение требований может квалифицироваться как их расширение за пределы, ограниченные контрактом, и не учитываться при оценивании заказчиком характеристик качества ПС, или как дополнительные работы, подлежащие соответствующему финансированию со стороны заказчика, для доработки программ с целью удовлетворения этих требований.
Внутренние квалификационные испытания качества программных средств (испытания главного конструктора), которые зачастую совмещаются с завершением комплексной отладки, должны оформляться документально и являются основанием при предъявлении ПС заказчику на квалификационные испытания для завершающего оценивания характеристик качества программного продукта (см. ISO 12207, ISO 15504, ISO 16326). Разработчик должен реализовать и оценить проект, комплекс программ, тесты, результаты тестирования и документацию для пользователя, учитывая:
полноту охвата испытаниями всех требований спецификаций к компонентам и к ПС в целом;
согласованность с требуемыми заказчиком и ожидаемыми результатами применения ПС;
возможность интеграции и тестирования ПС в составе системы;
возможность функционирования и сопровождения версий ПС в соответствии с требованиями контракта.
Любые испытания ограничены допустимым количеством и объемом проверок, а также длительностью работы комиссии испытателей, поэтому не могут гарантировать абсолютную проверку качества продукта. Для повышения достоверности определения и улучшения оценивания характеристик ПС после внутренних испытаний комплекс программ целесообразно передавать некоторым пользователям на опытную эксплуатацию в типовых условиях. Это позволяет более глубоко оценить эксплуатационные характеристики созданного комплекса и устранить некоторые дефекты и ошибки. Опытную эксплуатацию целесообразно проводить разработчиками с участием испытателей-заказчиков и некоторых пользователей, назначаемых заказчиком. Результаты и характеристики качества опытной эксплуатации после испытаний главного конструктора могут учитываться при проведении заказчиком квалификационных испытаний для их сокращения.
В лекции 13 рассмотрены этапы тестирования компонентов и ПС в целом с позиции последовательного увеличения функциональной сложности тестов и взаимодействия с объектами внешней среды. При этом не учитывались организационные этапы испытаний в соответствии со стандартами и их подотчетность разработчикам-поставщикам и заказчикам. Этапы и процессы квалификационного тестирования ПС с целью формального удостоверения для заказчика достигнутых характеристик качества комплекса программ и его компонентов в составе системы регламентированы в стандартах ISO 12207, ISO 15504. В них выделены три основных, функциональных этапа реализации квалификационного тестирования и испытаний (рис. 14.2):
— квалификационное тестирование функциональных компонентов и ПС в целом вне аппаратуры системы;
интеграция и тестирование программного средства в целом в составе аппаратуры системы;
квалификационное тестирование и полные испытания системы в комплексе с программным средством.
Рис. 14.2
Квалификационное тестирование функциональных компонентов и ПС в целом выполняется для того, чтобы продемонстрировать заказчику, что реализованы все требования контракта и достигнуто необходимое качество функционирования комплекса программ. Квалификационное тестирование должно покрывать все требования к компонентам в спецификации требований к ПС и в спецификациях требований к интерфейсам. Тестирование компонентов для каждой конфигурации должно показать, что полностью удовлетворены требования к компонентам, которые должны быть реализованы в данной конфигурации. Ответственными за квалификационное тестирование компонентов не должны быть лица, осуществившие выполнение рабочего проекта или программирование соответствующего компонента. Это не исключает возможность оказания помощи в проведении квалификационного тестирования со стороны лиц, выполнявших рабочий проект или программы, например, путем предоставления тестовых вариантов, основанных на знании ими внутренней реализации компонента или ПС.
Разработчик должен определить и зарегистрировать процесс подготовки к тестированию, тестовые варианты, сценарии и процедуры, которые должны использоваться для квалификационного тестирования компонента и проследить соответствие между тестовыми вариантами и требованиями контракта. Он должен подготовить тестовые данные, необходимые для выполнения тестовых вариантов, и предварительно уведомить представителя заказчика о времени и месте проведения квалификационного тестирования. Если испытание компонента должно быть засвидетельствовано представителем заказчика, то до его проведения разработчик должен проверить тестовые варианты и тестовые процедуры, чтобы гарантировать, что они полны и точны и что ПС готово для проведения тестирования в присутствии представителя заказчика. Результаты этих проверок должны быть зарегистрированы в файлах разработки ПС, а тестовые варианты и процедуры соответствующим образом модифицированы для устранения выявленных дефектов. Следует выполнить все необходимые изменения в ПС, предварительно уведомив об этом представителя заказчика, осуществить повторное тестирование в необходимом объеме, модифицировать файлы разработки ПС и другие программные продукты, основываясь на результатах интеграции и тестирования модулей и компонентов.
Результаты этих действий должны быть включены в отчет для заказчика о проведенных разработчиком предварительных испытаниях.
Интеграция и тестирование ПС в составе аппаратуры системы содержит их объединение, тестирование полученного в результате комплекса с целью определения, работают ли они вместе, как требуется по контракту, и должно продолжать этот процесс до тех пор, пока интеграция и тестирование не будут выполнены для всех компонентов программ и аппаратуры. Тестовые варианты должны покрывать все аспекты системного уровня и требуемые характеристики качества проекта. Разработчик должен выполнить необходимые корректировки программ, принять участие в повторном тестировании в необходимом объеме и модифицировать файлы разработки ПС и другие программные компоненты, основываясь на результатах интеграционного тестирования.
Квалификационное тестирование системы и программного про-дукта в целом выполняется, чтобы продемонстрировать представителю заказчика, что удовлетворены все требования технического задания и характеристики качества соответствуют условиям контракта. Оно должно покрывать все требования в спецификациях системы и подсистем, а также требования к интерфейсу с внешней средой. Испытания должны включать тестирование на объектной вычислительной системе или на альтернативной модели системы, одобренной представителем заказчика. Разработчик должен участвовать в разработке и регистрации процесса подготовки к тестированию, тестовых вариантов, сценариев и тестовых процедур, которые нужно использовать для полного испытания системы, и в прослеживании соответствия между тестовыми вариантами и требованиями к характеристикам качества системы. Каждое проверяемое требование должно соответствовать конкретным обоснованным характеристикам системы, иметь уникальный для проекта идентификатор, чтобы можно было провести тестирование и проследить его выполнение с помощью объективного теста. Для каждого требования должны выбираться квалификационные методы для подсистем и компонентов ПС, которые необходимо прослеживать в требованиях к системе. Степень детализации требований следует выбирать, учитывая в первую очередь те характеристики качества, которые внесены в условия приемки системы, и отдавать приоритет тем из них, которые заказчик требует обеспечить обязательно.
Все полученные результаты должны быть включены в отчет о тестировании ПС и системы. Если квалификационное тестирование системы должно быть засвидетельствовано представителем заказчика, то до его проведения разработчик должен проверить тестовые варианты и тестовые процедуры, чтобы гарантировать, что они полны и точны и что система готова для проведения тестирования в присутствии представителя заказчика. Испытания должны быть выполнены в соответствии с утвержденными заказчиком тестовыми вариантами, сценариями и процедурами.
Оценивание качества программного продукта при квалификационных, приемо-сдаточных испытаниях проводится комиссией заказчика, в которой участвуют руководитель (главный конструктор) разработки и некоторые ведущие разработчики или аттестованная сертификационная лаборатория. Комиссия при испытаниях должна руководствоваться следующими документами (см. рис. 14.2):
— утвержденными заказчиком и согласованными с разработчиком контрактом, техническим заданием и спецификациями требований на ПС;
действующими государственными и ведомственными стандартами на жизненный цикл и испытания программ, на технологическую и эксплуатационную документацию, а также стандартами де-факто, согласованными с заказчиком для использования, — профилем стандартов и нормативных документов;
Программой испытаний по всем требованиям контракта, технического задания и спецификаций;
методиками испытаний, охватывающими каждый раздел требований технического задания, спецификаций и Программы испытаний;
комплектом адекватной эксплуатационной и технологической документации на комплекс программ.
Программа испытаний является планом проведения серии экспериментов и должна разрабатываться с позиции допустимой минимизации объема тестирования в процессе проведения испытаний для проверки выполнения требований технического задания и соответствия предъявленной документации. Программа испытаний, методики их проведения и оценки результатов, разработанные совместно заказчиком и разработчиком, должны быть согласованы и утверждены. Они должны содержать уточнения и детализацию требований технического задания и спецификаций для данного ПС, а также гарантировать корректную проверку всех заданных характеристик качества. Об этом говорит сайт https://intellect.icu . Программа испытаний должна содержать следующие четко сформулированные разделы:
объект испытаний, его назначение и перечень основных документов, определивших его разработку;
цель испытаний с указанием всех требований технического задания, характеристик и атрибутов качества, подлежащих проверке, и ограничений на проведение испытаний;
собственно Программу испытаний, содержащую проверку комплектности спроектированного ПС в соответствие с техническим заданием и план проведения тестирования для проверки по всем разделам технического задания и дополнительных требований, формализованных отдельными решениями разработчиков и заказчика;
методики испытаний, однозначно определяющие все понятия проверяемых характеристик качества, условия и сценарии тестирования, инструментальные средства, используемые для испытаний;
методики обработки и оценки результатов тестирования по каждому разделу Программы испытаний.
Методика испытаний должна содержать: описание организации процесса тестирования, тестовые варианты, сценарии и процедуры, которые используются при испытаниях отдельного компонента или ПС в целом. Каждый тест должен иметь уникальный для данного проекта идентификатор; должны быть представлены инструкции для проведения тестирования; описание аппаратуры и ПС для реализации тестирования, а также инструкции для повторного тестирования. Кроме того, должны быть приведены ссылки на проверяемые требования, указаны условия выполнения (конфигурация аппаратуры и компонентов ПС), входные данные, эталонные и ожидаемые результаты, критерии оценки качества результатов, процедура проведения тестирования для каждого тестового варианта, допущения и ограничения.
План испытаний ПС должен описывать порядок квалификационного тестирования компонентов и подсистем, тестовую внешнюю среду, которая будет использоваться при тестировании, идентифицировать выполняемые тесты и указывать план-график тестовых действий. Для каждой предполагаемой тестовой реализации должны быть указаны: используемые версии аппаратных средств; интерфейсное оборудование; дополнительные внешние устройства; генераторы тестовых сообщений; устройства синхронизации тестов. Кроме того, в документе должны быть представлены план-график тестирования и матрица трассирования тестов к требованиям спецификаций на ПС или на его компоненты, а также субподрядчики, принимающие участие в тестировании, их роль и ответственность.
Большой объем разнородных данных, получаемых при испытаниях крупномасштабных ПС, и разнообразие возможных способов их обработки, интерпретации и оценки приводят к тому, что важнейшими факторами становятся методики обработки и оценки результатов, а также протоколы проверки по пунктам Программы испытаний. В соответствии с методиками испытаний средства автоматизации должны
продолжение следует...
Часть 1 14 ИНТЕГРАЦИЯ, КВАЛИФИКАЦИОННОЕ ТЕСТИРОВАНИЕ И ИСПЫТАНИЯ КОМПЛЕКСОВ ПРОГРАММ
Часть 2 14.3. Средства для испытаний и определения характеристик сложных комплексов программ
Часть 3 14.4. Оценивание надежности и безопасности функционирования сложных программных средств -
Часть 4 - 14 ИНТЕГРАЦИЯ, КВАЛИФИКАЦИОННОЕ ТЕСТИРОВАНИЕ И ИСПЫТАНИЯ КОМПЛЕКСОВ ПРОГРАММ
Комментарии
Оставить комментарий
Качество и тестирование программного обеспечения. Quality Assurance.
Термины: Качество и тестирование программного обеспечения. Quality Assurance.