Система - грецьке слово, буквально означає ціле, складене з частин. В іншому значенні - порядок, визначений правильним розташуванням частин та їх взаємозв'язками.
Система є безліч пов'язаних між собою елементів, що розглядається як ціле.
Системою є будь-який об'єкт, що має якісь властивості, що знаходяться в деякому заздалегідь заданому відношенні .
Система - відокремлена свідомістю частина реальності, елементи якої виявляють свою спільність у процесі взаємодії.
Структура – відносно стійка фіксація зв'язків між елементами системи.
Цілісність системи- це її відносна незалежність від середовища та інших аналогічних систем.
Емерджентність – незводність (ступінь незводності) властивостей системи до властивостей елементів системи.
Під поведінкою (функціонуванням) системи розумітимемо її дію в часі. Зміна структури системи у часі можна як еволюцію системи.
Мета системи - кращий для неї стан.
Цілеспрямована поведінка - Прагнення досягти мети.
Зворотний зв'язок - вплив результатів функціонування системи характер цього функціонування.
Кібернетика (давньогрец. kybernetike - «мистецтво управління») - галузь знання, суть якого була сформульована Н. Вінером як наука «про зв'язок, управління і контроль в машинах і живих організмах» у книзі «Кібернетика, або управління і зв'язок у тварині та машині »(1948).
Кібернетика займається вивченням систем будь-якої природи, здатних сприймати, зберігати та переробляти інформацію та використовувати її для управління та регулювання. При цьому кібернетика широко користується математичним методом і прагне отримання конкретних спеціальних результатів, що дозволяють як аналізувати такі системи (відновлювати їх пристрій на підставі досвіду поводження з ними), так і синтезувати їх (розраховувати схеми систем, здатних здійснювати задані дії).
У рамках кібернетики Вінера відбувся подальший розвиток системних уявлень, а саме:
1) типізація моделей систем;
2) виявлення значення зворотних зв'язків у системі;
3) підкреслення принципу оптимальності в управлінні та синтезі систем;
4) поняття інформації як загальної властивості матерії, усвідомлення можливості її кількісного опису;
5) розвиток методології моделювання взагалі і особливомашинного експерименту, тобто. математична експертиза з допомогою ЕОМ.
ВІДКРИТІ СИСТЕМИ 3
Стійкість 4
МОДЕЛІ, ФОРМАЛІЗАЦІЯ – 23
3. КЛАСИФІКАЦІЯ СИСТЕМ
У системному аналізі класифікація займає особливе місце з огляду на безліч критеріїв, які характеризують структуру системи, її призначення, особливості функціонування тощо. Найчастіше застосовуються при класифікації систем такі критерії.
За субстаціональною ознакою системи поділяються на три класи:
природні, що існують в об'єктивній дійсності (нежива та жива природа, суспільство). Приклади систем - атом, молекула, жива клітка, організм, населення, суспільство;
концептуальні, чи ідеальні системи, що відображають реальну дійсність, об'єктивний світ. Сюди відносять наукові теорії, Літературні твори, тобто. системи, що з різним ступенем повноти відображають об'єктивну реальність;
штучні, створені людиною задля досягнення конкретної мети (технічні чи організаційні).
При використанні системного аналізу для задач синтезу та аналізу складних систем управління використовують класифікацію систем за:
виду об'єкта – технічні, біологічні, організаційні та ін;
науковим напрямом – математичні, фізичні, хімічні та ін;
виду формалізації – детерміновані, стохастичні;
типу - відкриті та закриті;
складності структури та поведінки - прості та складні;
ступеня організованості – добре організовані, погано організовані (дифузні), з самоорганізацією.
Добре організовані системи -це такі, для яких можна визначити окремі елементи, зв'язки між ними, правила об'єднання у підсистеми та оцінити зв'язки між компонентами системи та її цілями. В цьому випадку проблемна ситуація може описуватися у вигляді математичних залежностей, які пов'язують мету та засоби її досягнення, так званих критеріїв ефективності чи оцінок функціонування. Вирішення завдань аналізу та синтезу в добре організованих системах здійснюється аналітичними методами. Приклади: опис роботи електронного пристрою за допомогою системи рівнянь, що враховують особливості роботи; аналітичні моделі об'єктів управління та ін.
Для відображення об'єкта, що досліджується, у вигляді добре організованої системи виділяють найбільш істотні фактори і відкидають другорядні. У добре організованих системах використовується переважно кількісна інформація. Погано організовані системи.Для таких систем характерним є відображення та дослідження не всіх компонентів, а лише деяких наборів макропараметрів та закономірностей за допомогою певних правил вибірки. Наприклад, при отриманні статистичних закономірностей їх переносять на поведінку систем із деякими показниками ймовірності. Характерним для цих систем є використання
багатокритеріальних завдань з численними припущеннями та обмеженнями. Приклади: системи масового обслуговування, економічні та організаційні системи.
У погано організованих системах використовується переважно якісна інформація, зокрема нечіткі множини.
Системи із самоорганізацією.Такі системи мають ознаки дифузних систем: стохастичність поведінки та нестаціонарність параметрів. У той же час вони мають чітко визначену можливість адаптації до зміни умов роботи. Приватним випадком системи з самоорганізацією управління технічними об'єктами є адаптивні системи з еталонними моделями чи ідентифікатором, які у дисципліні «Теорія автоматичного управління».
Існує ряд підходів до виділення систем за складністю та масштабом. Наприклад, для систем управління зручно користуватися класифікацією за кількістю (кількістю) елементів:
малі (10-103 елементів);
складні (104 107 елементів);
ультраскладні (108 – 1030 елементів);
суперсистеми (1030 – 10200 елементів).
Велика система – це завжди сукупність матеріальних та енергетичних ресурсів, засобів отримання, передачі та обробки інформації, людей, які приймають рішення на різних рівнях ієрархії.
В даний час для понять "складна система" і "велика система" використовують такі визначення:
складна система -впорядкована безліч структурно взаємопов'язаних і функціонально взаємодіючих різнотипних систем,які об'єднані структурно в цілісний об'єкт функціонально різнорідними взаємозв'язками задля досягнення заданих цілей у певних умовах;
велика система поєднує різнотипні складні системи.
Тоді визначення системи можна записати як Система - упорядкована безліч структурно взаємопов'язаних та функціонально
взаємодіючих однотипних елементівбудь-якої природи, об'єднаних у цілісний об'єкт, склад та межі якого визначаються цілями системного дослідження. Характерні рисивеликих систем:
значну кількість елементів;
взаємозв'язок та взаємодія між елементами;
ієрархічність структури управління;
наявність людини у контурі управління та необхідність прийняття рішень в умовах невизначеності.
Модель та моделювання систем: типи,
класифікація моделей
Модель об'єкта чи опис об'єкта, системи для заміщення (за певних умов пропозиціях, гіпотезах) однієї системи (тобто оригіналу) іншою системою для кращого вивчення оригіналу або відтворення будь-яких його властивостей.
Модель – результат відображення однієї структури (вивченої) на іншу (маловивчену).
Типи моделей 1) Пізнавальна модель форма організації та подання знань, засіб
поєднання нових та старих знань. Пізнавальна модель, як правило,
підганяється під реальність і є теоретичною моделлю.
2) Прагматична модель – засіб організації практичних дій, робочого подання цілей системи для її управління. Реальність у них підганяється під деяку прагматичну модель. Це зазвичай прикладні моделі.
3) Інструментальна модель засіб побудови, дослідження та/або використання прагматичних та/або пізнавальних моделей. Пізнавальні відображають існуючі, а прагматичні хоч і не існуючі, але бажані та, можливо, здійсненні відносини та зв'язки. За рівнем "глибини" моделювання моделі бувають:
емпіричні на основі емпіричних фактів, залежностей; теоретичні на основі математичних описів;
змішані, напівемпіричні на основі емпіричних залежностей та математичних описів.
Моделювання - універсальний метод отримання опису та використання знань.
Проблема моделювання складається з трьох завдань:
побудова моделі (це завдання менш формалізується і конструктивна, у тому сенсі, що немає алгоритму для побудови моделей); дослідження моделі (це завдання більш формалізується, є методи дослідження різних класів моделей);
використання моделі (конструктивне та конкретизоване завдання).
Лекція 9: Класифікація видів моделювання систем
Класифікація видів моделювання може бути проведена з різних підстав. Один із варіантів класифікації наведено на малюнку.
Мал. - приклад класифікації видів моделювання
Відповідно до класифікаційної ознаки повноти, моделювання ділиться на: повне, неповне, наближене.
При повному моделюванні моделі ідентичні об'єкту в часі та просторі.
Для неповного моделювання ця ідентичність не зберігається.
У основі наближеного моделювання лежить подоба, у якому деякі сторони реального об'єкта не моделюються зовсім. Теорія подібності стверджує, що абсолютна подоба можлива лише при заміні одного об'єкта іншим таким самим. Тому при моделюванні абсолютна схожість не має місця. Дослідники прагнуть того, щоб модель добре відображала лише досліджуваний аспект системи. Наприклад, з метою оцінки завадостійкості дискретних каналів передачі функціональна і інформаційна моделі системи можуть розроблятися. Для досягнення мети моделювання цілком достатня подієва модель,
описувана матрицею умовних ймовірностей переходів i символу алфавіту в j.
Залежно від типу носія та сигнатури моделі розрізняються такі види моделювання: детерміноване та стохастичне, статичне та динамічне, дискретне, безперервне та дискретно-безперервне.
Детермінованемоделювання відображає процеси, у яких передбачається відсутність випадкових впливів.
Стохастичне моделювання враховує імовірнісні процеси та події.
Статичне моделюванняслужить для опису стану об'єкта у фіксований час, а динамічний - на дослідження об'єкта у часі. При цьому оперують аналоговими (безперервними), дискретними та змішаними моделями.
Залежно від форми реалізації носія та сигнатури моделювання класифікується на уявне та реальне.
Уявне моделювання застосовується тоді, коли моделі не реалізовані в заданому інтервалі часу або відсутні умови для їхнього фізичного створення (наприклад, ситуація мікросвіту). Уявне моделювання реальних систем реалізується у вигляді наочного, символічного та математичного. Для представлення функціональних, інформаційних та подійних моделей цього виду моделювання розроблено значну кількість засобів та методів.
При наочному моделюванні з урахуванням уявлень про реальних об'єктах створюються наочні моделі, що відображають явища і процеси, які у об'єкті. Приклад таких моделей є навчальні плакати, малюнки, схеми, діаграми.
В основу гіпотетичногомоделювання закладається гіпотеза про закономірності перебігу процесу в реальному об'єкті, яка відображає рівень знань дослідника про об'єкт і базується на причиннонаслідкових зв'язках між входом і виходом об'єкта, що вивчається. Цей вид моделювання використовується, коли знань про об'єкт недостатньо для побудови формальних моделей. Аналогове моделювання ґрунтується на застосуванні аналогій різних рівнів. Для простих об'єктів найвищим рівнем є повна аналогія. З ускладненням системи використовуються аналогії наступних рівнів, коли аналогова модель відображає кілька (або лише одну) сторін функціонування об'єкта.
Макетування застосовується, коли процеси, що відбуваються в реальному об'єкті, не піддаються фізичному моделюванню або можуть передувати проведенню інших видів моделювання. В основі побудови
Уявних макетів також лежать аналогії, які зазвичай базуються на причиннонаслідкових зв'язках між явищами і процесами в об'єкті.
Символічне моделювання є штучним процесом створення логічного об'єкта, який заміщає реальний і виражає його основні властивості за допомогою певної системи знаків і символів.
В основі мовного моделювання лежить деякий тезаурус, який утворюється з набору понять досліджуваної предметної області, причому цей набір має бути фіксованим. Під тезаурусом розуміється словник, що відображає зв'язки між словами або іншими елементами даної мови, призначений для пошуку слів за їхнім змістом.
Традиційний тезаурус складається з двох частин: списку слів та стійких словосполучень, згрупованих за смисловими (тематичними) рубриками; алфавітного словника ключових слів, що задають класи умовної еквівалентності, вказівника відносин між ключовими словами, де для кожного слова вказані рубрики. Така побудова дозволяє визначити семантичні (смислові) відносини ієрархічного (рід/вид) та неієрархічного (синонімія, антонімія, асоціації) типу.
Між тезаурусом і традиційним словником є важливі відмінності. Тезаурус - словник, очищений від неоднозначності, тобто. у ньому кожному слову може відповідати лише поняття, хоча у звичайному словнику одному слову може відповідати кілька понять.
Якщо ввести умовне позначенняокремих понять, тобто. знаки, а також певні операції між цими знаками, можна реалізувати знакове моделювання і за допомогою знаків відображати набір
понять - складати окремі ланцюжки зі слів та речень. Використовуючи операції об'єднання, перетину та доповнення теорії множин, можна в окремих символах дати опис якогось реального об'єкта.
Математичне моделювання - це процес встановлення відповідності даному реальному об'єкту деякого математичного об'єкта, що називається математичною моделлю. У принципі, для дослідження характеристик будь-якої системи математичними методами, включаючи машинні, повинна бути обов'язково проведена формалізація цього процесу, тобто. побудовано математичну модель. Вид математичної моделі залежить як від природи реального об'єкта, і від завдань дослідження об'єкта, від необхідної достовірності та точності розв'язання задачі. Будь-яка математична модель, як і будь-яка інша, визначає реальний об'єкт з деяким ступенем наближення.
Для представлення математичних моделей можна використовувати різні форми записи. Основними є інваріантна, аналітична, алгоритмічна та схемна (графічна).
Інваріантна форма – запис співвідношень моделі за допомогою традиційної математичної мови безвідносно до методу розв'язання рівнянь моделі. У цьому випадку модель може бути представлена як сукупність входів, виходів, змінних станів та глобальних рівнянь системи. Аналітична форма - запис моделі як результату вирішення вихідних рівнянь моделі. Зазвичай моделі в аналітичній формі є явними виразами вихідних параметрів як функцій входів і змінних стану.
Для аналітичного моделювання характерним є те, що в основному моделюється лише функціональний аспект системи. При цьому глобальні рівняння системи, що описують закон (алгоритм) її функціонування, записуються у вигляді деяких аналітичних співвідношень (алгебраїчних, інтегродиференціальних, звичайно різницевих тощо) або логічних умов. Аналітична модель досліджується кількома методами:
аналітичним, коли прагнуть отримати у загальному вигляді явні залежності, що пов'язують шукані характеристики з початковими умовами, параметрами та змінними станами системи;
чисельним, коли, не вміючи вирішувати рівняння у загальному вигляді, прагнуть отримати числові результати за конкретних початкових даних (нагадаємо, такі моделі називаються цифровими);
якісним, коли, не маючи рішення у явному вигляді, можна знайти деякі властивості рішення (наприклад, оцінити стійкість рішення).
У В даний час поширені комп'ютерні методи дослідження характеристик процесу функціонування складних систем. Для реалізації математичної моделі на ЕОМ необхідно побудувати відповідний моделюючий алгоритм.
Алгоритмічна форма - запис співвідношень моделі та обраного чисельного методу розв'язання у формі алгоритму. Серед алгоритмічних моделей важливий клас становлять імітаційні моделі, призначені для імітації фізичних чи інформаційних процесів за різних зовнішніх впливів. Власне імітацію названих процесів називають імітаційним моделюванням.
При імітаційному моделюванні відтворюється алгоритм функціонування системи у часі - поведінка системи, причому імітуються елементарні явища, що становлять процес, зі збереженням їхньої логічної структури та послідовності протікання, що дозволяє за вихідними даними отримати відомості про стан процесу у певні моменти часу, що дають можливість оцінити характеристики системи . Основною перевагою імітаційного моделювання порівняно з аналітичною є можливість вирішення складніших завдань. Імітаційні моделі дозволяють досить просто враховувати такі фактори,
як наявність дискретних та безперервних елементів, нелінійні характеристики елементів системи, численні випадкові впливи та інші, які часто створюють труднощі під час аналітичних досліджень. В даний час імітаційне моделювання - найбільш ефективний методдослідження систем, а часто й єдиний практично доступний методотримання інформації щодо поведінки системи, особливо на етапі її проектування.
В імітаційному моделюванні розрізняють метод статистичних випробувань (Монте-Карло) та метод статистичного моделювання.
Метод Монте-Карло – чисельний метод, який застосовується для моделювання випадкових величин та функцій, імовірнісні характеристики яких збігаються з рішеннями аналітичних завдань. Складається у багаторазовому відтворенні процесів, що є реалізаціями випадкових величин і функцій, з подальшим обробленням інформації методами математичної статистики.
Якщо цей прийом застосовується для машинної імітації з метою дослідження характеристик процесів функціонування систем, схильних до випадкових впливів, то такий метод називається методом статистичного моделювання.
Метод імітаційного моделювання застосовується з метою оцінки варіантів структури системи, ефективності різних алгоритмів управління системою, впливу зміни різних параметрів системи. Імітаційне моделювання може бути покладено в основу структурного, алгоритмічного та параметричного синтезу систем, коли потрібно створити систему із заданими характеристиками за певних обмежень.
Комбіноване (аналітико-імітаційне) моделювання дозволяє об'єднати переваги аналітичного та імітаційного моделювання. При побудові комбінованих моделей проводиться попередня декомпозиція процесу Функціонування об'єкта на складові підпроцеси, і тих, де це можливо, використовуються аналітичні моделі, а інших підпроцесів будуються імітаційні моделі. Такий підхід дає можливість охопити якісно нові класи систем, які можуть бути досліджені з допомогою аналітичного чи імітаційного моделювання окремо.
Інформаційне ( кібернетичне) моделювання пов'язане з дослідженням моделей, у яких відсутня безпосередня подоба фізичних процесів, що відбуваються в моделях, реальних процесів. В цьому випадку прагнуть відобразити лише деяку функцію, розглядають реальний об'єкт як «чорну скриньку», що має ряд входів та виходів, і моделюють деякі зв'язки між виходами та входами. Отже, основу інформаційних (кібернетичних) моделей лежить відбиток деяких інформаційних процесів управління, що дозволяє оцінити поведінку
реальний об'єкт. Для побудови моделі в цьому випадку необхідно виділити досліджувану функцію реального об'єкта, спробувати формалізувати цю функцію у вигляді деяких операторів зв'язку між входом і виходом і відтворити дану функцію на імітаційній моделі, причому зовсім іншою математичною мовою і, природно, інший фізичної реалізації процесу. Приміром, експертні системи є моделями ЛПР.
Структурне моделювання системного аналізу базується на деяких специфічних особливостях структур певного виду, які використовуються як засіб дослідження систем або служать для розробки на їх основі специфічних підходів до моделювання із застосуванням інших методів формалізованого представлення систем (теоретико-множинних, лінгвістичних, кібернетичних тощо). ). Розвитком структурного моделювання є об'єктно-орієнтованемоделювання.
Структурне моделювання системного аналізу включає:
методи мережевого моделювання;
поєднання методів структуризації з лінгвістичними;
структурний підхід у напрямі формалізації побудови та дослідження структур різного типу(ієрархічних, матричних, довільних графів) на основі теоретико множинних уявлень та поняття номінальної шкали теорії вимірювань.
При цьому термін «структура моделі» може застосовуватися як до функцій, так і до елементів системи. Відповідні структури називаються функціональними та морфологічними. Об'єктно-орієнтоване моделювання поєднує структури обох типів в ієрархію класів, які включають як елементи, і функції.
У структурному моделюванні за останнє десятиліття сформувалася нова технологія CASE. Абревіатура CASE має двояке тлумачення, що відповідає двом напрямкам використання CASE-систем. Перше з них – Computer-Aided Software Engineering – перекладається як автоматизоване проектування програмного забезпечення. Відповідні CASE-системи часто називають інструментальним середовищем швидкої розробки програмного забезпечення (RAD - Rapid Application Development). Друге – Computer-Aided System Engineering – підкреслює спрямованість на підтримку концептуального моделювання складних систем, переважно слабоструктурованих. Такі CASE-системи часто називають системами BPR (Business Process Reengineering). В цілому
CASE-технологія є сукупністю методологій аналізу, проектування, розробки та супроводу складних автоматизованих систем, що підтримується комплексом взаємопов'язаних засобів автоматизації. CASE - це інструментарій для системних аналітиків, розробників та
МОСКІВСЬКійДЕРЖАВНИЙийуніверситеттехнологій та управління
(утворений у 1953 році)
Кафедра фізики та вищої математики
А.Р. Садикова
ТЕОРІЯ ПРИЙНЯТТЯ РІШЕННЯ.
ТЕОРІЯ СИСТЕМ І СИСТЕМНИЙ АНАЛІЗ
Навчально-практичний посібник
для студентів спеціальності 2202
всіх форм навчання
www. msta. ru
Москва - 2004 4093
© Садикова А.Р. Теорія ухвалення рішення. Теорія систем та системний аналіз. Навчальний посібник для студентів спеціальності 2202, усіх форм навчання. -МГУТУ, 2004 р.
Посібник містить короткий викладосновних теоретичних відомостей та конкретних методів прийняття рішень, необхідних для практичного застосуванняу професійній діяльності.
Розглянуті питання відповідають державним освітнім стандартам.
Конкретні питання та тести запропоновані у посібнику допоможуть студентам самостійно вивчити розділи «Методи прийняття рішень» та «Теорія систем та системний аналіз».
Посібник призначений для студентів, які навчаються за спеціальністю 2202.
Рецензенти: Доц. К.Т.М. Латишева Є.І., Доц. К.Т.М. Денискін Ю.Д.
Редактор: Свєшнікова Н.І.
© Московський державний університет технологій та управління, 2004
109004, Москва, Земляний вал, 73
Цілі та завдання дисципліни 4
1.1 Ухвалення рішень як вид людської діяльності 4
1.2 Математичні моделі прийняття рішень 6
питання для самоперевірки за розділом 9
Тест за розділом 9
2. ГлаваII. Математичні моделі оптимізації ресурсів та
прийняття рішень 10
2.1 Загальний випадок математичної постановки задачі оптимізації 10
2.2 Методи оптимізації та розподіл ресурсів на основі завдання
лінійного програмування 11
2.3 Методи багатопараметричної оптимізації у процесах
планування, управління та прийняття рішення 12
2.4 Завдання лінійного програмування в оперативному управлінні
виробництвом та прийняття рішень 14
питання для самоперевірки за розділом 17
Тест за розділом 17
3. ГлаваIII. Завдання нелінійного програмування у процесі оптимізації
ресурсів прийняття рішень 18
3.1 Аналітичні методи вирішення завдань безумовної оптимізації 19
3.2 Завдання умовної оптимізації та методи їх вирішення 20
питання для самоперевірки за розділом 21
Тест за розділом 21
4. ГлаваIV. Теоретико – ігрові моделі прийняття рішень 22
4.1 Матричні ігри 22
4.2 Позиційні ігри 25
4.3 Біматричні ігри 27
питання для самоперевірки за розділом 30
Тест за розділом 31
5. ГлаваV. Дослідження операцій 31
5.1 Динамічне програмування 31
5.2 Елементи теорії управління запасами 35
5.3 Теорія масового обслуговування 37
питання для самоперевірки за розділом 42
Тест за розділом 42
6. тест з дисципліни 42
7. Питання для самоперевірки 43
8. Словник основних понять 44
9. Література 45
10. Відповіді до тестів 46
Цілі та завдання дисципліни.
Теорія прийняття рішень.
Цілі – ознайомлення студентів із змістом завдання прийняття рішень, його місця та ролі у процесі управління. Поряд із освоєнням основних понять, вони вивчать базові, класичні завдання теорії прийняття рішень та методи їх вирішення, які є фундаментом для подальшого розвитку методів прийняття рішень, а також є практичним інструментом при вирішенні багатьох прикладних завдань управління.
Завдання: Мати уявлення про поняття – функція ухвалення рішення; процес ухвалення рішення; загальне завдання прийняття рішення та її зміст; методи зміни теорії прийняття рішень; основні завдання; методи розв'язання основних завдань.
Знати – основні поняття, методи та правила вирішення задач прийняття рішення. Набути навички вирішення завдань та оцінки правильності отриманих результатів.
Теорія систем та системний аналіз.
Цілі – вивчення та освоєння основних понять та законів теорії систем та системного аналізу.
Студент повинен знати:
Основні засади складання математичних моделей прийняття оптимальних рішень за умов конфлікту;
Математичний апарат теорії систем та системного аналізу: методи вирішення диференціальних та інтегральних рівнянь; комбінаторику; теорію ймовірності та математичну статистику;
Види та положення теорії ігор.
Дослідити найпростіші завдання теорії систем;
Знаходити зв'язок у завданнях аналізі систем із методами поняття кібернетики та інформатики;
Зводити найпростіші завдання теорії ігор задач лінійного програмування.
1. Поведінка
2. Розвиток
3. Стан
4. Функціонування
3. Що таке терми?
1. Імена та члени речень, певні об'єкти дослідження
2. Склад властивостей системи
3. Те, що пов'язує елементи у системі
4. Частина об'єкта, що має певну самостійність по відношенню до всього об'єкта
4. Що з наведеного нижче не входить у динамічний опис системи?
1. Процес
2. Функтори
3. Система
5. Який із принципів системного підходу передбачає необхідність дослідження об'єкта як складної сукупності складових його елементів?
1. Принцип мети
2. Принцип складності
3. Принцип цілісності
4. Принцип історизму
6. Що не стадія життєвого циклу?
1. Функціонування
2. Створення
3. Розвиток
4. Управління
7. Що таке системний аналіз?
1. Методологія вирішення проблем
2. Передача функцій управління технічним засобам
3. Загальна теорія систем
4. Сукупність наукових методів та практичних прийомів вирішення різноманітних проблем на основі системного підходу
8. Що наукової основою автоматизації?
1. Теорія автоматів
2. Філософія
3. Інформатика
4. Загальна теорія систем
9. Що таке принципи?
1. Система знань про деяку сферу реального світу
2. Сукупність властивостей системи
3. Встановлення відповідності між вимогами об'єктивних законів та суб'єктивною діяльністю
4. Склад елементів системи та зв'язків між ними
10. Що таке система?
1. Цілісна сукупність пов'язаних елементів
2. Частина об'єкта, що має певну самостійність по відношенню до всього об'єкта
3. Безліч об'єктів
4. Цілісна сукупність пов'язаних об'єктів
11. Які види зв'язків бувають?
1. Суттєві та несуттєві
2. З керуванням, без керування
3. Динамічні, статичні
4. Внутрішні, зовнішні
12. Що таке абстрактні системи?
1. Системи із матеріальними елементами
2. Системи, що складаються з абстрактних елементів, які не мають аналогів у реальному світі
3. Системи, що складаються з абстрактних елементів і мають аналоги в реальному світі
4. Системи із біологічними елементами
13. На які групи діляться системи по відношенню до середовища?
1. Природні, штучні
2. Статичні, динамічні
3. Відкриті, замкнуті
4. Активні, пасивні
14. Які основні етапи життєвого циклу Ви знаєте?
1. Створення, зростання зрілість, руйнування
2. Створення, функціонування, руйнування
3. Створення, налагодження, функціонування, руйнування
4. Створення, налагодження, функціонування
15. В рамках якої наукової дисципліни вирішуються добре структуровані проблеми?
1. Теорія прийняття рішень
2. Системний аналіз
3. Дослідження операцій
4. Теорія ігор
16. У межах якої наукової дисципліни вирішуються слабо структуризовані проблеми?
1. Теорія прийняття рішень
2. Системний аналіз
3. Дослідження операцій
4. Теорія ефективності
17. Що атрибут проблеми?
1. Місце та час виникнення проблеми
2. Складність
3. Масштаб (розміри невідповідності)
4. Важливість
18. У системному аналізі система будується для:
1. Вивчення складу елементів, що входять до неї
2. Виявлення проблеми
3. Визначення взаємодії з іншими системами
4. Виділення підсистем системи
19. Технологічна схема системного дослідження включає:
1. Визначення призначення системи, побудова системи, аналіз системи
2. Визначення мети дослідження, виявлення проблеми, вирішення проблеми
3. Загальний аналіз досліджуваної системи, виявлення проблеми, визначення напрямків та шляхів вирішення проблеми
4. Виявлення підсистем системи, виділення системи, аналіз системи
20. Необхідними компонентами системного аналізу є:
1. Надійність, проблемність, розв'язуваність, цілісність
2. Цілісність, якість, структурованість, модель
3. Мета, альтернативи, ресурси, критерій, модель
4. Безліч рішень, ресурси, модель
21. Які з аксіом є аксіомами теорії керування?
1. Наявність спостережуваності та керованості об'єкта управління
2. Наявність свободи дій керуючого органу при виробленні керуючих впливів
3. Наявність свободи вибору керуючих впливів з безлічі допустимих альтернатив та ресурсів для реалізації прийнятих рішень
4. Наявність мети та критерію ефективності управління
22. Система з керуванням це:
1. Система прийняття рішень
2. Система, у якій реалізується управління
3. Кібернетична система
4. Система вироблення керуючих впливів
23. Принципами управління є:
1. Оперативне управління, регулювання, планування
2. Ієрархічне управління, поточне управління, формальне управління
3. Централізоване управління, децентралізоване управління, комбіноване управління
4. Планування, оперативне управління, контроль
24. Функціями управління є:
1. Облік, контроль, планування, оперативне управління
2. Регулювання, прогнозування, організація, оцінка
3. Оцінювання, прогнозування, регулювання, формалізація
4. Планування, оперативне управління, організація, прогнозування, облік, контроль
25. Принцип необхідної різноманітності У.Р.Ешбі формулюється так:
1. Різноманітність об'єкта управління має бути більшою за різноманітність керуючої системи
2. Різноманітність керуючої системи має бути більшою за різноманітність об'єкта управління
3. Різноманітність керуючої системи має бути не меншою за різноманітність об'єкта управління
4. Різноманітність керуючої системи має бути меншою за різноманітність об'єкта управління
26. Завдання аналізу це:
1. Оптимізація системи
2. Оцінка ефективності функціонування системи
3. Виявлення структури системи та принципів її функціонування
4. Визначення складу параметрів та елементів системи
27. Завдання синтезу це:
1. Визначення структури та параметрів системи, виходячи із заданих вимог до показників ефективності її функціонування
2. Виявлення принципів побудови системи
3. Визначення оптимальних значень параметрів системи
4. Знаходження оптимальних принципів побудови системи
28. Визначити призначення шкал вимірів
1. Зіставлення значень якісних та кількісних характеристик об'єктів
2. Ототожнення альтернатив
3. Вимірювання станів об'єктів, процесів, явищ
4. Встановлення переваг характеристик порівнюваних об'єктів
29. Поняття «вимірювання» це:
1. Операція, яка даному спостережуваному стану об'єкта, процесу, явища ставить у відповідність певне позначення
2. Сукупність дій зі збору вихідних даних для оцінювання об'єктів
3. Отримання вихідних даних про об'єкт із використанням приладу
4. Сукупність правил щодо збору відомостей про стан об'єктів
30. Сутність завдання парного порівняння полягає у:
1. Визначення якісних характеристик порівнюваних об'єктів
2. Виявленні об'єкта з більшою корисністю
3. Виявлення найкращого з двох порівнюваних об'єктів
4. Визначення параметрів порівнюваних об'єктів
31. Завдання ранжирування полягає у:
1. Упорядкування об'єктів системи зі спадання (зростання) значення деякої ознаки
2. Присвоєння об'єктам системи рангу
3. Розстановці об'єктів системи за місцем та часом їх виникнення
4. Сортування об'єктів системи щодо збільшення частоти звернення до них
32. Сутність завдання класифікації полягає у:
1. Вимірювання параметрів системи за допомогою шкали класифікації
2. Віднесення заданого елемента системи до одного з підмножин
3. Упорядкування об'єктів системи
4. Присвоєння об'єктам системи певної кількісної ознаки
33. Сутність завдання чисельної оцінки полягає в:
1. Зіставлення системі одного чи кількох чисел
2. Вимірювання якісних характеристик об'єктів системи
3. Оцінка суттєвих характеристик системи
4. Оптимізації параметрів системи за вибраним критерієм
34. Завдання оцінювання називається експертизою, якщо воно:
1 . Вирішується за допомогою фахівців у досліджуваній галузі
2. Вирішується за допомогою консультантів
3. Вирішується за допомогою особи, яка приймає рішення
4. Вирішується за допомогою експертів
35. Які з цих етапів є етапами проведення експертизи?
1. Упорядкування безлічі результатів операції з їхньої переваги
2. Визначення корисності кожного результату
3. Перевірка отриманих оцінок на несуперечність шляхом порівняння оцінок переваг корисних результатів
4. Усунення протиріч в оцінках шляхом коригування будь-якого варіанту впорядкування результатів, чи корисностей, чи того й іншого разом
36. Які з наведених методів є методами якісного оцінювання систем?
1. Морфологічні методи
2. Методи векторної оптимізації
3. Методи типу сценаріїв
4. Метод типу «дерева цілей»
37. Яких із перелічених правил необхідно дотримуватися під час використання методу типу «мозкова атака»?
1. Не допускати критики будь-якої ідеї, не оголошувати її хибною та не припиняти обговорення
2. Бажано не висловлювати нетривіальні ідеї
3. Забезпечити більшу свободу мислення учасників «мозкового штурму» та висловлювання ними нових ідей
4. Вітаємо будь-які ідеї, навіть якщо вони спочатку здаються сумнівними або абсурдними
38. Метод типу сценаріїв дозволяє:
1. Допомогти досліднику скласти уявлення про проблему
2. Допомогти досліднику вирішити проблему
3. Отримати досліднику змістовні міркування щодо проблеми
4. Вивчити дослідником проблему з використанням ЕОМ
39. Які проблеми вирішуються з використанням методів експертних оцінок?
1. Проблеми, щодо яких є достатнє забезпечення інформацією
2. Проблеми, щодо яких немає достатнє забезпечення інформацією
3. Проблеми, щодо яких знань для впевненості та справедливості зазначених гіпотез недостатньо
4. Проблеми, щодо яких знань для впевненості та справедливості зазначених гіпотез достатньо
40. Які з перерахованих етапів є етапами експертизи?
1. Формування мети та розробка процедури експертизи
2. Формування групи експертів та проведення опитування
3 . Збір експертами статистичних даних
4. Аналіз та обробка інформації
41. Які з наведених процедур не є процедурами експертних вимірювань?
1. Метод Черчмена-Акоффа
2. Метод фон Неймана-Моргенштерна
3. Метод Лагранжа
4. Метод Терстоуна
42. Які з перерахованих процедур є процедурами Дельфи-метода?
1. Послідовність циклів «мозкової атаки»
2. Розробка індивідуальних опитувань на кшталт «сценарій»
3. Запровадження коефіцієнтів значимості думок експертів
4. Розробка програми послідовних індивідуальних опитувань
43. Які з перерахованих процедур не є складовими методу ^ PATTERN ?
1. Розгортання дерева цілей із рядом критеріїв для кожного рівня
2. Визначення експертами ваг критеріїв та коефіцієнтів значимості цілей
3. Виявлення зв'язків між рівнями дерева цілей
4. Визначення коефіцієнта зв'язку цілей
44. У чому полягає сутність морфологічних методів якісного оцінювання систем?
1. Систематичне знаходження всіх можливих варіантів вирішення проблеми комбінуванням виділених елементів або їх ознак
2. Систематичне знаходження всіх можливих варіантів реалізації системи комбінуванням виділених елементів або їх ознак
3. Систематичне знаходження найістотніших варіантів вирішення проблеми або реалізації системи комбінуванням виділених елементів або їх ознак
4. Систематичне знаходження всіх можливих варіантів побудови системи комбінуванням виділених елементів або їх ознак
45. Що предмет вивчення теорії прийняття рішень?
1. Закономірності побудови складних систем
2. Закономірності виділення та прийняття рішень
3. Закономірності переробки командної (керуючої) інформації
4. Закономірності переробки інформації стану на командну інформацію
46. Визначити основне завдання дослідження операцій
1. Кількісне та якісне обґрунтування рішень
2. Якісне обґрунтування рішень
3. Попереднє кількісне обґрунтування рішень
4. Попереднє якісне обґрунтування рішень
47. Операція в теорії прийняття рішень:
1. Процес виконання послідовності дій у системі
2. Етап функціонування системи, обмежений виконанням певної мети
3. Сукупність правил побудови системи
4. Етап функціонування системи
48. Некеровані характеристики системи:
1. Частина характеристик, які керуючий орган може змінювати за допомогою об'єкта управління та повинен враховувати під час виборів рішень
2. Частина характеристик, які керуючий орган може змінювати за допомогою об'єкта керування
3. Частина характеристик, які можуть змінювати об'єкт управління
4. Частина характеристик, які керуючий орган не може змінювати за допомогою об'єкта управління, але має враховувати під час виборів рішень
49. Керовані показники системи це:
1. Характеристики системи, які можуть змінюватися керуючим органом
2. Характеристики системи, які можуть змінюватись об'єктом управління
3. Обираються характеристики
4. Характеристики
50. Ухвалення рішення це:
1. Акт завдання значень керованих показників
2. Визначення складу керованих та некерованих характеристик системи
3. Визначення керуючим органом кількості, якості, місця та часу використання ресурсів для досягнення мети
4. Акт завдання значень некерованих характеристик
51. Допустимими називаються рішення:
1. Для яких визначено некеровані характеристики
2. Прийняті керуючим органом
3. Що задовольняють накладеним обмеженням
4. Для яких визначено керовані характеристики
52. Оптимальним називається рішення, яке:
1. Переважно інших рішень у сфері допустимих рішень
2. Переважно інших рішень з погляду певної ознаки
3. Є найкращим з погляду використання ресурсів системи
4. Має найкращі значення некерованих характеристик
53. Стратегією теорії прийняття рішень називається:
1. Сукупність некерованих характеристик, які приймаються до виконання операції
2. Сукупність керованих характеристик, що приймаються для виконання операції
3. Сукупність рішень, що приймаються для виконання операції
4. Рішення, що приймається для виконання операції
54. Сатісфакційний вибір у теорії прийняття рішень це:
1. Вибір безлічі рішень в галузі допустимих рішень
2. Вибір будь-якого рішення в галузі допустимих рішень
3. Вибір оптимального рішення
4. Вибір допустимих рішень
55. Вихід операції це:
1. Результат досягнення мети операції
2. Реалізація того чи іншого рішення
3. Ситуація, що склалася (прогнозована) на момент завершення операції
4. Заключний етап реалізації операції
56. Ефективність рішення це:
1. Властивість рішення відповідати меті операції
2. Властивість системи відповідати меті, поставленій перед системою
3. Властивість рішення, що полягає у досягненні мети операції
4. Сукупність дій щодо виділення значень керованих параметрів
57. Які терміни є синонімами терміна «ефективність»?
1. Результативність
2. Оптимальність
3. Пристосованість
4. Дієвість
58. Показник ефективності рішення:
1. Параметр, значення якого задовольняє допустиме рішення
2. Показники результатів операції, на основі яких формується критерій ефективності
3. Функції показників результатів операції, основі яких формується критерій ефективності
4. Критерій ефективності вирішення
59. Корисність результату операції це:
1. Числова обмежена функція
2. Дійсне число, що приписується результату операції та характеризує його перевагу в порівнянні з іншими показниками щодо мети
3. Показник результату операції, який служить для порівняння результатів
4. Дійсне число, що приписується результату операції
60. Функція корисності:
1. Лінійна функція визначення виду критерію ефективності
2. Числова обмежена функція, визначена на безлічі результатів
3. Порогова функція визначення виду критерію ефективності
4. Обмежена функція, що застосовується для оцінки ефективності рішень
61. Процедура визначення функції корисності включає такі етапи:
1. Виявлення показників результатів операції
2. Визначення безлічі допустимих результатів операції
3. Визначення корисностей результатів операції
4. Визначення корисності системи
62. Способами визначення функції корисності є такі:
1. Аналіз впливу результатів досліджуваної операції на операцію більше високого рівняієрархії
2. Експертні оцінки
3. Апроксимація
4. Інтерпретація
63. Критерій ефективності це:
1. Те, чому порівнюють рішення при виборі
2. Параметр, за допомогою якого порівнюються рішення при виборі
3. Захід, що виражає кількісно ефективність кожного рішення і служить основою для вибору одного з них
4. Характеристика, що виражає кількісно ефективність кожного рішення і служить основою для вибору одного з них
64. Цільова функція це:
1. Ефективність рішення
2. Математичне вираження критерію ефективності рішень
3. Один із способів запису критерію ефективності рішення
4. Результати оцінки ефективності рішення
65. Детермінована операція це:
1. Операція в якій для кожного рішення існує безліч наслідків операції з відомими законами розподілу
2. Операція, в якій для кожного рішення існує безліч наслідків операції
3. Операція, в якій для кожного рішення існує один певний результат операції
4. Операція в якій для кожного рішення існує один результат операції з відомим законом розподілу
66. Імовірнісна операція це:
1. Операція, в якій кожному рішенню ставиться у відповідність безліч результатів операції
2. Операція, в якій кожному рішенню ставиться у відповідність безліч результатів операції з відомими законами розподілу ймовірностей на результатах
3. Операція, в якій кожному рішенню ставиться у відповідність безліч результатів операції з невідомими законами розподілу ймовірностей на результатах
4. Операція в умовах ризику
67. Невизначена операція це:
1. Операція, у якій кожному рішенню відповідає певний результат із невідомим законом розподілу ймовірностей
2. Операція, в якій кожному рішенню можуть відповідати різні результати
3. Операція, в якій кожному рішенню ставиться у відповідність безліч результатів операції з відомими законами розподілу ймовірностей на результатах
4. Операція, в якій кожному рішенню можуть відповідати різні результати з невідомими законами розподілу ймовірностей на результатах
68. Які з перерахованих етапів становлять процес вироблення рішення?
1. Аналіз умов проведення операції
2. Побудова моделі функціонування системи під час проведення операції
3. Вибір оптимального рішення у рамках побудованої моделі
4. Формування прийнятого рішення
69. У чому суть методу комісій?
1. В організації роботи групи експертів шляхом відкритої дискусії
2. В організації роботи групи експертів шляхом закритої дискусії
3. У проведенні «мозкового штурму»
4. У всебічній оцінці явища, події, процесу, що вивчається
70. Основними властивостями експертів під час проведення групової експертизи мають бути:
1. Порядність
2. Компетентність
3. Креативність
Тест з предмету «Моделювання виробничих та економічних процесів»
Варіант №3 спеціальність 3706002
1. Список це – ….
Упорядкована інформація;
Структуровані дані;
Опис відомостей про об'єкт;
Сукупність об'єктів, упорядкованих за допомогою посилань.
Коротка характеристика властивостей об'єкта.
2. Чергою називається …
Список, який необхідно зменшити за будь-якими критеріями;
Довжина об'єкта поступово зменшується
Упорядкована сукупність об'єктів;
Об'єктивна можливість розв'язання задачі.
Список, що дозволяє реалізувати вибір першим із черги об'єкта, який був включений до списку раніше за інших;
3. На вигляд об'єкта розрізняють моделі:
Інформаційні процеси, технологічні процеси.
Технологічних процесів, комплексів робіт, підприємств, об'єднань та галузей.
Технологічні процеси, масові процеси.
Кореляційні процеси, комплекси робіт, інформаційні процеси.
Математичні процеси, оптимізаційні процеси.
4. Ефективність операції залежить від двох груп факторів:
Умови завдання та методу отримання.
Критерія ефективності та елементів вирішення.
Оцінки їх відповідності та ефективності операції.
Умов проведення операції та способу організації, параметрів операції.
Екстремального значення функції та ефективності операції.
5. Критерієм ефективності операції є:
Функція заданих умов та елементів вирішення.
Керовані та некеровані змінні.
Наявність обмежень.
Знаходження екстремального значення цільової функції.
Досягнення поставленої мети.
6. Процес прийняття рішень складається з ….. етапів
7. До керованих змінних відносять:
Можливі значення.
Елементи розв'язання задачі.
Величини, значення яких необхідно знайти у процесі розв'язання задачі.
Невідомі чинники.
Випадкові величини із відомими (певними) законами розподілу.
8. Процес математичного моделювання включає …. етапів (етапу)
9. Динамічне програмування – це
Завдання, які мають більшу розмірність та їх вирішення потребує складних обчислювальних дій.
Розв'язання багатовимірних та багатоетапних завдань.
Оптимізація цільових функцій будь-якого типу.
Блокове програмування.
Метод планування багатоступінчастого процесу, який може бути поділений на низку послідовних етапів.
10. Модель це …
Використання методів математики для найефективнішого вирішення завдань, що виникають у сфері економіки.
Опис реального об'єкта.
Явище чи об'єкт.
Подумки представляється чи матеріально реалізована система, яка, відображаючи чи відтворюючи об'єкт дослідження, здатна замінювати його отже її вивчення дає нову інформацію про цей об'єкт.
Віртуальне середовище.
11. Управління це….
Сигнали, спрямовані на зміну структури чи безлічі станів системи.
Така вхідна дія або сигнал, в результаті якого система поводиться заданим чином.
Структура ієрархічного складу.
Система, у якій існує ієрархія.
Взаємозв'язок елементів складної системи.
12. Системний аналіз – це …
Наука передбачає різні рішення.
Наука, що робить вибір зручних варіантів розв'язання задач.
Наука наступна аналітичному способумислення.
Наука, що займається проблемою ухвалення рішення в умовах аналізу великої кількості інформації різної природи.
Наука виконує всі вимоги моделі.
13. Завдання лінійного цілочисельного програмування (ЦПП) – це …
Завдання математичного програмування, у якій змінні можуть набувати значення, рівні 0 або 1.
Завдання обліку умов цілісності змінних.
Завдання, у якому враховуються різні показники праці.
Завдання математичного вигляду, що пропонує рішення під час використання 3-х змінних.
Завдання математичного програмування, у якому всі чи деякі змінні повинні набувати лише цілих чисел.
14. Транспортна мережа – це …
Сукупність вершин або вузлів і транспортних комунікацій, що з'єднують їх, або ланок.
Оперативне керування роботою транспорту.
Сукупність засобів та методів, планування мережевого графіка.
Система, що сприяє простому управлінню з виробництва.
Сукупність зв'язків, якими будується робота для підприємства.
15. Якщо дві задачі лінійного програмування мають взаємозв'язок, причому одне з них вихідне, а інше:
Транспортні.
Розподільча.
Подвійна.
Лінійна.
Диференційна.
16. Алгоритм вирішення транспортної задачі методом потенціалів складається із двох етапів:
Аналітичного та статистичного.
Попереднього та комплексного.
Комплексного та аналітичного.
Попереднього та загального.
Загального та групового.
17. Основна ідея вирішення лінійних цілих завдань методом відсікань, спочатку запропонована:
Дж. Данцигом, Д. Фулкерсоном та С. Джонсоном.
С. Джонсоном та М. Гауссом.
Жозефом Луї Лагранжом та Грувіцем.
Дж. Данцигом та Ніклаусом Віртом.
Жозефом Луї Лагранжом та Д. Фулкерсоном.
18. Метод гілок та кордонів вперше був запропонований для вирішення лінійних цілочисельних завдань:
Гурвіцем та Дж. Данцигом.
Вальдом та Жозефом Луї Лагранжем.
Д. Фулкерсон.
А. Дойгом.
А. Лендом та А. Дойгом.
19. Теорія масового обслуговування – це …
область прикладної математики, що займається аналізом процесів у системах виробництва, обслуговування, управління, у яких однорідні події повторюються багаторазово.
Математична постановка задачі вирішує низку виробничих проблем.
Область застосування, якою сфера обслуговування.
Наука, що вивчає потреби для підприємства.
Наука, що допомагає знайти відповідь на низку питань, що стосуються підприємства та планування на виробництві.
20. Метод Монте-Карло – це …
Метод вирішення завдань управління плануванням.
чисельний метод розв'язання математичних завдань з допомогою моделювання випадкових чисел.
Метод, який допомагає знайти відповідь двоїстості в задачах.
Один із методів розв'язання задач нелінійного програмування.
Спосіб створення моделі.
21. Головними елементами мережевої моделі є:
Залежність та очікування.
Фіктивна робота та події.
Робота та події.
Подія та очікування.
Робота та очікування.
22. За законом зміни вихідних змінних моделі класифікуються на:
Реальні, статичні, математичні, лінійні.
Динамічні, стаціонарні, економічні.
Лінійні, подвійні, транспортні, економічні.
Стаціонарні, нестаціонарні, динамічні, лінійні, нелінійні.
Транспортні, стаціонарні, лінійні, квадратичні.
23. Мережею називається -
Математичні засади мережевих методів.
Основою мережевих методів планування та управління.
Граф, що складається з вершин - "подій" та спрямованих дуг - "робіт" або "операцій".
Подання програми у вигляді мережної моделі або мережі, що відображає відношення порядку, що існує на багатьох операціях програми.
Орієнтований зв'язаний граф без контуру, в якому існує лише одна вершина, що не має вхідних дуг, і тільки одна вершина, що не має дуг, що виходять.
24. Метод динамічного програмування застосовується на вирішення задач:
Розподіл ресурсів, управління запасами, заміна ремонту обладнання.
Лінійні, подвійні.
Транспортні, ігри із природою.
Управління запасами, ігри з природою.
Розподіл ресурсів, подвійні завдання.
25. Розв'язання задачі включає наступні етапи:
Постановка задачі, системний підхід, системний синтез, розв'язання задачі.
Постановка задач, системний синтез, системний підхід, налагодження програми.
Постановка задач, системний підхід, системний.
Постановка задачі, системний синтез, розв'язання задачі.
Відповіді на тест 3
Нещодавно був на співбесіді на Middle QA на проект, котрий явно перевищує мої можливості. Приділив багато часу тому, чого взагалі не знав і мало часу повторенню простої теорії, а дарма.
Нижче основи основ для повторення перед співбесідою для Trainee and Junior: визначення тестування, якість, верифікація/валідація, цілі, етапи, тест план, пункти тест плану, тест дизайн, техніки тест дизайну, traceability matrix, test case, чек-лист, дефект, error/deffect/failure, баг репорт, severity vs priority, рівні тестування, види / типи, підходи до інтеграційного тестування, принципи тестування, статичне та динамічне тестування, дослідницьке / ad-hoc тестування, вимоги, життєвий цикл бага, стадії розробки програмного забезпечення, decision table, qa/qc/test engineer, діаграма зв'язків.
Всі зауваження, коригування та доповнення дуже вітаються.
Тестування програмного забезпечення- перевірка відповідності між реальною та очікуваною поведінкою програми, що здійснюється на кінцевому наборі тестів, обраному певним чином. У більш широкому сенсі, тестування - це одна з технік контролю якості, що включає активності з планування робіт (Test Management), проектування тестів (Test Design), виконання тестування (Test Execution) і аналізу отриманих результатів (Test Analysis).
Якість програмного забезпечення (Software Quality)- це сукупність параметрів програмного забезпечення, які належать до його здатності задовольняти встановлені та передбачувані потреби.
Верифікація (verification)- це процес оцінки системи або її компонентів з метою визначення, чи задовольняють результати поточного етапу розробки умов, сформованих на початку цього етапу. Тобто. чи виконуються наші цілі, терміни, завдання розробки проекту, визначені на початку поточної фази.
Валідація (validation)- це визначення відповідності розроблюваного ПЗ очікуванням та потребам користувача, вимогам до системи.
Також можна зустріти іншу інтерпретацію:
Процес оцінки відповідності продукту явним вимогам (специфікаціям) і є верифікація (verification), водночас оцінка відповідності продукту очікуванням та вимогам користувачів є валідація (validation). Також часто можна зустріти таке визначення цих понять:
Validation - 'is this the right specification?'.
Verification - 'is the system correct to specification?'.
Цілі тестування
Підвищити ймовірність того, що додаток, призначений для тестування, працюватиме правильно за будь-яких обставин.
Підвищити ймовірність того, що програма, призначена для тестування, буде відповідати всім описаним вимогам.
Надання актуальної інформації про стан продукту зараз.
Етапи тестування:
1. Аналіз продукту
2. Робота з вимогами
3. Розробка стратегії тестування
та планування процедур контролю якості
4. Створення тестової документації
5. Тестування прототипу
6. Основне тестування
7. Стабілізація
8. Експлуатація
Тест план (Test Plan)- це документ, що описує весь обсяг робіт із тестування, починаючи з опису об'єкта, стратегії, розкладу, критеріїв початку та закінчення тестування, до необхідного в процесі роботи обладнання, спеціальних знань, а також оцінки ризиків з варіантами їх вирішення.
Відповідає на запитання:
Що треба випробувати?
Що тестуватимете?
Як тестуватимете?
Коли тестуватимете?
Критерії початку тестування.
Критерії закінчення тестування.
Основні пункти тест плану
У стандарті IEEE 829 перераховані пункти, з яких повинен (нехай може) складатися тест-план:
a) Test plan identifier;
b) Introduction;
c) Test items;
d) Features to be tested;
e) Features not to be tested;
f) Approach;
g) Item pass/fail criteria;
h) Suspension criteria and resumption requirements;
i) Test deliverables;
j) Testing tasks;
k) Економічні потреби;
l) Responsibilities;
m) Staffing and training needs;
n) Schedule;
o) Risks and contingencies;
p) Approvals.
Тест дизайн– це етап процесу тестування ПЗ, на якому проектуються та створюються тестові сценарії (тест кейси), відповідно до визначених раніше критеріїв якості та цілей тестування.
Ролі, відповідальні за тест дизайн:
Тест аналітик – визначає «ЩО тестувати?»
Тест дизайнер – визначає «ЯК тестувати?»
Техніки тест дизайну
Еквівалентний Поділ (Equivalence Partitioning – EP). Як приклад, у вас є діапазон допустимих значень від 1 до 10, ви повинні вибрати одне правильне значення всередині інтервалу, скажімо, 5, і одне неправильне значення поза інтервалом - 0.
Аналіз Граничних Значень (Boundary Value Analysis – BVA).Якщо взяти приклад вище, як значення для позитивного тестування виберемо мінімальну і максимальну межі (1 і 10), і значення більше і менше меж (0 і 11). Аналіз Граничний значень може бути застосований до полів, записів, файлів, або до будь-яких сутностей, що мають обмеження.
Причина/Слідство (Cause/Effect - CE).Це, як правило, введення комбінацій умов (причин) для отримання відповіді від системи (Слідство). Наприклад, ви перевіряєте можливість додавати клієнта, використовуючи певну екранну форму. Для цього вам необхідно буде ввести кілька полів, таких як «Ім'я», «Адреса», «Номер Телефону», а потім натиснути кнопку «Додати» - це «Причина». Після натискання кнопки «Додати» система додає клієнта в базу даних і показує його номер на екрані - це «Слідство».
Передбачення помилки (Error Guessing – EG).Це коли тестувальник використовує свої знання системи та здатність до інтерпретації специфікації щодо того, щоб «передбачити» за яких вхідних умов система може видати помилку. Наприклад, специфікація каже: "користувач повинен ввести код". Тестувальник думатиме: «Що, якщо я не введу код?», «Що, якщо я введу неправильний код? ", і так далі. Це і є передбачання помилки.
Вичерпне тестування (Exhaustive Testing – ET)- Це крайній випадок. У межах цієї техніки ви повинні перевірити всі можливі комбінації вхідних значень, і в принципі це має знайти всі проблеми. На практиці застосування цього методу неможливо, через величезної кількостівхідних значень.
Попарне тестування (Pairwise Testing)- Це техніка формування наборів тестових даних. Сформулювати суть можна, наприклад, ось так: формування таких наборів даних, в яких кожне тестоване значення кожного з параметрів, що перевіряються хоча б один раз поєднується з кожним тестованим значенням всіх інших параметрів, що перевіряються.
Допустимо, якесь значень (податок) для людини розраховується на підставі її статі, віку та наявності дітей – отримуємо три вхідні параметри, для кожного з яких для тестів вибираємо якимось чином значення. Наприклад: стать - чоловіча або жіноча; вік – до 25, від 25 до 60, понад 60; наявність дітей – так чи ні. Для перевірки правильності розрахунків можна, звичайно, перебрати всі комбінації значень усіх параметрів:
| № | підлога | вік | діти |
|---|---|---|---|
| 1 | чоловік | до 25 | дітей немає |
| 2 | жінка | до 25 | дітей немає |
| 3 | чоловік | 25-60 | дітей немає |
| 4 | жінка | 25-60 | дітей немає |
| 5 | чоловік | старше 60 | дітей немає |
| 6 | жінка | старше 60 | дітей немає |
| 7 | чоловік | до 25 | діти є |
| 8 | жінка | до 25 | діти є |
| 9 | чоловік | 25-60 | діти є |
| 10 | жінка | 25-60 | діти є |
| 11 | чоловік | старше 60 | діти є |
| 12 | жінка | старше 60 | діти є |
А можна вирішити, що нам не потрібні поєднання значень всіх параметрів з усіма, а ми хочемо лише переконатися, що ми перевіримо всі унікальні пари значень параметрів. Тобто, наприклад, з точки зору параметрів статі та віку ми хочемо переконатися, що ми точно перевіримо чоловіка до 25, чоловіка між 25 і 60, чоловіка після 60, а також жінку до 25, жінку між 25 та 60, ну і жінку після 60. І так само для всіх інших пар параметрів. І таким чином, ми можемо отримати набагато менше наборів значень (у них є всі пари значень, щоправда, деякі двічі):
| № | підлога | вік | діти |
|---|---|---|---|
| 1 | чоловік | до 25 | дітей немає |
| 2 | жінка | до 25 | діти є |
| 3 | чоловік | 25-60 | діти є |
| 4 | жінка | 25-60 | дітей немає |
| 5 | чоловік | старше 60 | дітей немає |
| 6 | жінка | старше 60 | діти є |
Такий підхід приблизно і становить суть техніки pairwise testing - ми не перевіряємо всі поєднання всіх значень, але перевіряємо всі пари значень.
Traceability matrix - Матриця відповідності вимогам- це двовимірна таблиця, що містить відповідність функціональних вимог (functional requirements) продукту та підготовлених тестових сценаріїв (test cases). У заголовках колонок таблиці розташовані вимоги, а заголовках рядків - тестові сценарії. На перетині - відмітка, що означає, що вимога поточної колонки покрита тестовим сценарієм поточного рядка.
Матриця відповідності вимог використовується QA-інженерами для валідації покриття продукту тестами. МСТ є невід'ємною частиною тест-плану.
Тестовий сценарій (Test Case)- це артефакт, що описує сукупність кроків, конкретних умов і параметрів, необхідних для перевірки реалізації функції або її частини, що тестується.
Приклад:
Action Expected Result Test Result
(passed/failed/blocked)
Open page «login» Login page is opened Passed
Кожен тест кейс повинен мати 3 частини:
PreConditions Список дій, які призводять систему до стану придатного для проведення основної перевірки. Або перелік умов, виконання яких свідчить, що система перебуває у придатному щодо основного тесту стану.
Test Case Description Список дій, що переводять систему з одного стану в інший, для отримання результату, на підставі якого можна зробити висновок про задоволення реалізації, поставленим вимогам
PostConditions Список дій, що переводять систему в початковий стан (стан до проведення тесту - initial state)
Види Тестових Сценаріїв:
Тест кейси поділяються за очікуваним результатом на позитивні та негативні:
Позитивний тест кейс використовує тільки коректні дані і перевіряє, що програма правильно виконала функцію, що викликається.
Негативний тест кейс оперує як коректними так і некоректними даними (мінімум 1 некоректний параметр) і ставить за мету перевірку виняткових ситуацій (спрацьовування валідаторів), а також перевіряє, що функція, що викликається додатком, не виконується при спрацьовуванні валідатора.
Чек-лист (check list)- це документ, що описує, що має бути протестовано. При цьому чек-аркуш може бути абсолютно різного рівня деталізації. Наскільки детальним буде чек-лист залежить від вимог до звітності, рівня знання продукту співробітниками та складності продукту.
Як правило, чек-лист містить лише дії (кроки), без очікуваного результату. Чек-лист менш формалізований, ніж тестовий сценарій. Його доречно використовувати тоді, коли тестові сценарії будуть надмірними. Також чек-лист асоціюються із гнучкими підходами у тестуванні.
Дефект (він же баг)– це невідповідність фактичного результату виконання програми очікуваного результату. Дефекти виявляються на етапі тестування програмного забезпечення, коли тестувальник проводить порівняння отриманих результатів роботи програми (компонента або дизайну) з очікуваним результатом, описаним у специфікації вимог.
Error- Помилка користувача, тобто він намагається використовувати програму іншим способом.
Приклад - вводить літери на поля, де потрібно вводити цифри (вік, кількість товару тощо.).
У якісній програмі передбачені такі ситуації та видаються повідомлення про помилку (error message), з червоним хрестиком.
Bug (дефект)- Помилка програміста (або дизайнера або ще кого, хто бере участь у розробці), тобто коли в програмі щось йде не так як планувалося і програма виходить з-під контролю. Наприклад, коли ніяк не контролюється введення користувача, в результаті невірні дані викликають краші або інші "радості" у роботі програми. Або всередині програма побудована отже спочатку відповідає тому, що від неї очікується.
Failure- збій (причому не обов'язково апаратний) у роботі компонента, всієї програми чи системи. Тобто є такі дефекти, які призводять до збоїв (A defect caused the failure) і існують такі, які не призводять. UI-дефекти, наприклад. Але апаратний збій, що ніяк не пов'язаний із software, теж є failure.
Баг Репорт (Bug Report)- це документ, що описує ситуацію або послідовність дій, що призвела до некоректної роботи об'єкта тестування, із зазначенням причин та очікуваного результату.
Шапка
Короткий опис (Summary) Короткий опис проблеми, що явно вказує на причину та тип помилкової ситуації.
Проект (Project) Назва проекту, що тестується
Компонент програми (Component) Назва частини або функції продукту, що тестується
Номер версії (Version) Версія на якій було знайдено помилку
Серйозність (Severity) Найбільш поширена п'ятирівнева система градації серйозності дефекту:
S1 Блокуючий (Blocker)
S2 Критичний (Critical)
S3 Значний (Major)
S4 Незначний (Minor)
S5 Тривіальний (Trivial)
Пріоритет (Priority) Пріоритет дефекту:
P1 Високий (High)
P2 Середній (Medium)
P3 Низький (Low)
Статус (Status) Статус бага. Залежить від процедури та життєвого циклу бага (bug workflow and life cycle)
Автор (Author) Творець баг репорту
Призначений на (Assigned To) Ім'я співробітника, призначеного для вирішення проблеми
Оточення
ОС/Сервіс Пак і т.д. / Браузера + версія / ... Інформація про оточення, на якому було знайдено баг: операційна система, сервіс пак, для WEB тестування - ім'я та версія браузера і т.д.
…
Опис
Кроки відтворення (Steps to Reproduce) Кроки, якими можна легко відтворити ситуацію, що призвела до помилки.
Фактичний Результат (Result) Результат, отриманий після проходження кроків до відтворення
Очікуваний результат (Expected Result) Очікуваний правильний результат
Доповнення
Прикріплений файл (Attachment) Файл з логами, скріншот або будь-який інший документ, який може допомогти прояснити причину помилки або вказати на спосіб вирішення проблеми
Severity vs Priority
Серйозність (Severity) – це атрибут, що характеризує вплив дефекту на працездатність програми.
Пріоритет (Priority) - це атрибут, що вказує на черговість виконання завдання чи усунення дефекту. Можна сміливо сказати, що це інструмент менеджера з планування робіт. Що пріоритет, то швидше потрібно виправити дефект.
Severity виставляється тестувальником
Priority – менеджером, тимлідом чи замовником
Градація Серйозності дефекту (Severity)
S1 Блокуюча (Blocker)
Блокуюча помилка, що приводить додаток у неробочий стан, в результаті якого подальша робота з системою, що тестується, або її ключовими функціями стає неможлива. Вирішення проблеми необхідне для подальшого функціонування системи.
S2 Критична (Critical)
Критична помилка, неправильно працююча ключова бізнес логіка, дірка в системі безпеки, проблема, що призвела до тимчасового падіння сервера або деяка частина системи, що призводить до неробочого стану, без можливості вирішення проблеми, використовуючи інші вхідні точки. Вирішення проблеми необхідне для подальшої роботи з ключовими функціями системою, що тестується.
S3 Значна (Major)
Значна помилка, частина основної бізнес-логіки працює некоректно. Помилка не критична або є можливість для роботи з функцією, що тестується, використовуючи інші вхідні точки.
S4 Незначна (Minor)
Незначна помилка, що не порушує бізнес логіку частини програми, що тестується, очевидна проблема користувальницького інтерфейсу.
S5 Тривіальна (Trivial)
Тривіальна помилка, що не стосується бізнес логіки програми, погано відтворювана проблема, малопомітна за допомогою інтерфейсу користувача, проблема сторонніх бібліотек або сервісів, проблема, що не впливає на загальну якість продукту.
Градація Пріоритету дефекту (Priority)
P1 Високий (High)
Помилка має бути виправлена якнайшвидше, т.к. її наявність є критичною для проекту.
P2 Середній (Medium)
Помилка має бути виправлена, її наявність не критична, але вимагає обов'язкового рішення.
P3 Низький (Low)
Помилка має бути виправлена, її наявність не критична, і не вимагає термінового рішення.
1. Модульне тестування (Unit Testing)
Компонентне (модульне) тестування перевіряє функціональність та шукає дефекти в частинах програми, які доступні та можуть бути протестовані окремо (модулі програм, об'єкти, класи, функції тощо).
2. Інтеграційне тестування (Integration Testing)
Перевіряють взаємодію між компонентами системи після проведення компонентного тестування.
3. Системне тестування (System Testing)
Основним завданням системного тестування є перевірка як функціональних, і функціональних вимог у системі загалом. При цьому виявляються дефекти, такі як неправильне використання ресурсів системи, непередбачені комбінації даних рівня користувача, несумісність з оточенням, непередбачені сценарії використання, відсутня або неправильна функціональність, незручність використання і т.д.
4. Операційне тестування (Release Testing).
Навіть якщо система задовольняє всім вимогам, важливо переконатися в тому, що вона задовольняє потреб користувача і виконує свою роль у середовищі своєї експлуатації, як це було визначено у бізнес-моделі системи. Слід врахувати, що бізнес модель може містити помилки. Тому важливо провести операційне тестування як фінальний крок валідації. Крім цього, тестування в середовищі експлуатації дозволяє виявити і нефункціональні проблеми, такі як: конфлікт з іншими системами, суміжними в галузі бізнесу або програмних та електронних оточення; недостатня продуктивність системи серед експлуатації та інших. Вочевидь, що перебування подібних речей на стадії впровадження - критична і дорога проблема. Тому так важливо проведення не тільки верифікації, а й валідації з ранніх етапів розробки ПЗ.
5. Приймальне тестування (Acceptance Testing)
Формальний процес тестування, який перевіряє відповідність системи вимогам та проводиться з метою:
визначення чи задовольняє система приймальним критеріям;
винесення рішення замовником чи іншою уповноваженою особою приймається додаток чи ні.
Функціональне тестування (Functional testing)
Тестування інтерфейсу користувача (GUI Testing)
Тестування безпеки (Security and Access Control Testing)
Тестування взаємодії (Interoperability Testing)
Усі види тестування продуктивності:
o навантажувальне тестування (Performance and Load Testing)
o стресове тестування (Stress Testing)
o тестування стабільності чи надійності (Stability / Reliability Testing)
o об'ємне тестування (Volume Testing)
Тестування установки (Installation testing)
Тестування зручності користування (Usability Testing)
Тестування на відмову та відновлення (Failover and Recovery Testing)
Конфігураційне тестування (Configuration Testing)
Функціональне тестуваннярозглядає заздалегідь зазначену поведінку і ґрунтується на аналізі специфікацій функціональності компонента чи системи загалом.
Тестування інтерфейсу користувача (GUI Testing)- функціональна перевірка інтерфейсу на відповідність вимогам – розмір, шрифт, колір, consistent behavior.
Тестування безпеки- це стратегія тестування, яка використовується для перевірки безпеки системи, а також для аналізу ризиків, пов'язаних із забезпеченням цілісного підходу до захисту додатків, хакерів, вірусів, несанкціонованого доступу до конфіденційних даних.
Тестування взаємодії (Interoperability Testing)- це функціональне тестування, що перевіряє здатність програми взаємодіяти з одним і більше компонентами або системами і включає тестування сумісності (compatibility testing) і інтеграційне тестування
Тестування навантаження- це автоматизоване тестування, що імітує роботу певної кількості бізнес-користувачів на якомусь загальному (розділюваному ними) ресурсі.
Стресове тестування (Stress Testing)дозволяє перевірити наскільки додаток і система загалом працездатні за умов стресу і оцінити здатність системи до регенерації, тобто. до повернення до нормального стану після припинення дії стресу. Стресом у цьому контексті може бути підвищення інтенсивності виконання операцій до дуже високих значень або зміна аварійної конфігурації сервера. Також одним із завдань при стресовому тестуванні може бути оцінка деградації продуктивності, таким чином цілі стресового тестування можуть перетинатися з метою тестування продуктивності.
Об'ємне тестування (Volume Testing).Завданням об'ємного тестування є отримання оцінки продуктивності зі збільшенням обсягів даних у базі даних додатку
Тестування стабільності чи надійності (Stability/Reliability Testing).Завданням тестування стабільності (надійності) є перевірка працездатності програми при тривалому (багатогодинному) тестуванні із середнім рівнем навантаження.
Тестування установкиспрямовано на перевірку успішної інсталяції та налаштування, а також оновлення або видалення програмного забезпечення.
Тестування зручності користування- це метод тестування, спрямований на встановлення ступеня зручності використання, навченості, зрозумілості та привабливості для користувачів продукту, що розробляється в контексті заданих умов. Сюди також входить:
User eXperience (UX) - відчуття, яке випробовує користувач під час використання цифрового продукту, тоді як User interface - це інструмент, що дозволяє здійснювати інтеракцію «користувач - веб-ресурс».
Тестування на відмову та відновлення (Failover and Recovery Testing)перевіряє тестований продукт з точки зору здатності протистояти та успішно відновлюватися після можливих збоїв, що виникли у зв'язку з помилками програмного забезпечення, відмови обладнання або проблемами зв'язку (наприклад, відмова мережі). Метою даного виду тестування є перевірка систем відновлення (або дублюючих основний функціонал систем), які, у разі виникнення збоїв, забезпечать збереження та цілісність даних продукту, що тестується.
Конфігураційне тестування (Configuration Testing)- спеціальний вид тестування, спрямований на перевірку роботи програмного забезпечення при різних конфігураціях системи (заявлених платформах, драйверах, що підтримуються, при різних конфігураціях комп'ютерів і т.д.)
Димова (Smoke)тестування розглядається як короткий цикл тестів, що виконується для підтвердження того, що після складання коду (нового або виправленого) додаток, що встановлюється, стартує і виконує основні функції.
Регресійне тестування- це вид тестування спрямований на перевірку змін, зроблених у додатку або навколишньому середовищі(лагодження дефекту, злиття коду, міграція на іншу операційну систему, базу даних, веб-сервер або сервер програми), для підтвердження того факту, що існуюча раніше функціональність працює як і раніше. Регресійними можуть бути як функціональні, і дисфункції тести.
Повторне тестування- Тестування, під час якого виконуються тестові сценарії, що виявили помилки під час останнього запуску, для підтвердження успішності виправлення цих помилок.
У чому різниця між regression testing та re-testing?
Re-testing - перевіряється виправлення багів
Regression testing - перевіряється те, що виправлення багів, а також будь-які зміни в коді програми не вплинули на інші модулі ПЗ і не викликало нових багів.
Тестування складання або Build Verification Test- Тестування спрямоване на визначення відповідності, випущеної версії, критеріям якості для початку тестування. За своїми цілями є аналогом Димового Тестування, спрямованого на приймання нової версіїу подальше тестування чи експлуатацію. Вглиб воно може проникати далі, залежно від вимог якості випущеної версії.
Санітарне тестування- це вузькоспрямоване тестування достатнє для доказу того, що конкретна функція працює відповідно до заявлених у специфікації вимог. Є підмножиною регресійного тестування. Використовується для визначення працездатності певної частини програми після змін вироблених у ній чи навколишньому середовищі. Зазвичай виконується вручну.
Підходи до інтеграційного тестування:
Знизу нагору (Bottom Up Integration)
Усі низькорівневі модулі, процедури або функції збираються докупи і потім тестуються. Після чого збирається наступний рівень модулів щодо інтеграційного тестування. Даний підхід вважається корисним, якщо всі або практично всі модулі, що розробляється, готові. Також цей підхід допомагає визначити за результатами тестування рівень готовності програми.
Зверху донизу (Top Down Integration)
Спочатку тестуються всі високорівневі модулі і поступово один за одним додаються низькорівневі. Усі модулі нижчого рівня симулюються заглушками з аналогічною функціональністю, потім у міру готовності заміняються реальними активними компонентами. Таким чином, ми проводимо тестування зверху вниз.
Великий вибух ("Big Bang" Integration)
Усі або практично всі розроблені модулі збираються разом у вигляді закінченої системи або її основної частини, а потім проводиться інтеграційне тестування. Такий підхід дуже добрий для збереження часу. Проте якщо тест кейси та його результати записані не так, то сам процес інтеграції сильно ускладниться, що стане перепоною для команди тестування при досягненні основної мети інтеграційного тестування.
Принцип 1– Тестування демонструє наявність дефектів (Testing shows presence of defects)
Тестування може показати, що дефекти є, але не може довести, що їх немає. Тестування знижує ймовірність наявності дефектів, що у програмному забезпеченні, але, навіть якщо дефекти були виявлено, це доводить його коректності.
Принцип 2– Вичерпне тестування є недосяжним (Exhaustive testing is impossible)
Повне тестування з допомогою всіх комбінацій вводів і передумов фізично нездійсненно, крім виняткових випадків. Замість вичерпного тестування повинні використовуватися аналіз ризиків та встановлення пріоритетів, щоб точніше сфокусувати зусилля з тестування.
Принцип 3– Ранне тестування (Early testing)
Щоб знайти дефекти якомога раніше, активності з тестування повинні бути розпочаті якомога раніше в життєвому циклі розробки програмного забезпечення або системи, і повинні бути сфокусовані на певних цілях.
Принцип 4- Скупчення дефектів (Defects clustering)
Зусилля тестування повинні бути зосереджені пропорційно до очікуваної, а пізніше реальної щільності дефектів по модулях. Як правило, більша частина дефектів, виявлених при тестуванні або спричинили основну кількість збоїв системи, міститься в невеликій кількості модулів.
Принцип 5- Парадокс пестициду (Pesticide paradox)
Якщо ті самі тести будуть проганятися багато разів, зрештою цей набір тестових сценаріїв більше не знаходитиме нових дефектів. Щоб подолати цей “парадокс пестициду”, тестові сценарії повинні регулярно рецензуватися та коригуватися, нові тести мають бути різнобічними, щоб охопити всі компоненти програмного забезпечення,
або системи, і знайти якнайбільше дефектів.
Принцип 6– Тестування залежить від контексту (Testing is concept depending)
Тестування виконується по-різному, залежно від контексту. Наприклад, програмне забезпечення, в якому критично важлива безпека, тестується інакше, ніж сайт електронної комерції.
Принцип 7– Помилка про відсутність помилок (Absence-of-errors fallacy)
Виявлення та виправлення дефектів не допоможуть, якщо створена система не підходить користувачеві та не задовольняє його очікуванням та потребам.
Статичне та динамічне тестування
Статичне тестування відрізняється від динамічного тим, що виробляється без запуску програмного коду продукту. Тестування здійснюється шляхом аналізу програмного коду (code review) чи скомпільованого коду. Аналіз може проводитись як вручну, так і за допомогою спеціальних інструментальних засобів. Метою аналізу є раннє виявлення помилок та потенційних проблему продукті. Також до статичного тестування відноситься тестування специфікації та іншої документації.
Дослідницьке / ad-hoc тестування
Найпростіше визначення дослідницького тестування - це розробка та виконання тестів одночасно. Що є протилежністю сценарного підходу (з його наперед визначеними процедурами тестування, неважливо ручними або автоматизованими). Дослідницькі тести, на відміну від сценарних тестів, не визначені заздалегідь і не виконуються точно відповідно до плану.
Різниця між ad hoc та exploratory testing у тому, що теоретично, ad hoc може провести будь-хто, а для проведення exploratory необхідна майстерність та володіння певними техніками. Зауважте, що певні техніки це не тільки техніки тестування.
Вимоги– це специфікація (опис) те, що має бути реалізовано.
Вимоги описують те, що потрібно реалізувати, без деталізації технічного боку рішення. Що, а не як.
Вимоги до вимог:
Коректність
Недвозначність
Повнота набору вимог
Несуперечність набору вимог
Перевірюваність (тістопридатність)
Трасування
Розуміння
Життєвий цикл бага
Стадії розробки ПЗ- це етапи, які проходять команди розробників програмного забезпечення, перш ніж програма стане доступною для широкого кола користувачів. Розробка ПЗ починається з початкового етапу розробки (стадія «пре-альфа») і продовжується стадіями, на яких продукт доопрацьовується та модернізується. Фінальним етапом цього процесу стає випуск ринку остаточної версії програмного забезпечення («загальнодоступного релізу»).
Програмний продукт проходить такі стадії:
аналіз вимог до проекту;
проектування;
реалізація;
тестування продукту;
Використання та підтримка.
Кожній стадії розробки програмного забезпечення присвоюється певний порядковий номер. Також кожен етап має власну назву, яка характеризує готовність продукту на цій стадії.
Життєвий цикл розробки ПЗ:
Пре-альфа
Альфа
Бета
Реліз-кандидат
Реліз
Пост-реліз
Таблиця ухвалення рішень (decision table)– чудовий інструмент для упорядкування складних бізнес вимог, які мають бути реалізовані у продукті. У таблицях рішень подано набір умов, одночасне виконання яких має призвести до певної дії.
