Ім'я файлу: КР ТЕСТУВАННЯ.docx
Розширення: docx
Розмір: 60кб.
Дата: 25.12.2020
скачати

МІЖРЕГІОНАЛЬНА

АКАДЕМІЯ УПРАВЛІННЯ ПЕРСОНАЛОМ



Факультет комп’ютерно-інформаційних технологій
КОНТРОЛЬНА РОБОТА

з дисципліни: «Тестування програмного забезпечення»

Варіант № 9
Прізвище та ініціали викладача: Дяченко Михаил Петрович

Виконавець: Гавриловський А.С.

Група: ВШЛ-8-20-М1ППі(1.6з)


Київ – 2020

Контрольна робота з дисципліни «Тестування програмного забезпечення»

Варіант № 9
Тема реферату: Ознаки внутрішньої і зовнішньої якості програмного забезпечення.




Тема реферату: Ознаки внутрішньої і зовнішньої якості програмного забезпечення.
Зміст

1. Якість програмного забезпечення.

1.1. Що таке якість?

1.2. Популярний погляд на якість.

1.3. Професійний підхід до якості.

1.4. Що таке якість програмного забезпечення?

1.5. Якість ПЗ по МакКолу.

2. Характеристики якості програмного забезпечення.

3. Види ліцензій на програмне забезпечення

4. Моделі відкритого програмного забезпечення.

Висновки


Використані джерела

1. Якість програмного забезпечення.

1.1. Що таке якість?

Основною проблемою в управлінні якістю є той факт, що визначення якості неясне і неоднозначне. Це викликано тим, що зазвичай термін «якість» розуміють неправильно. Причини:

  1. Якість – це не окрема ідея або поняття, а багатомірна і різнопланова концепція.

  2. Для будь-якого поняття і визначення існує декілька рівнів абстракції, наприклад, коли люди говорять про якість, одна частина розуміє під цим занадто широкий і розмитий смисл, а інша може вказувати на конкретне визначення.

  3. Термін «якість» є невід’ємною частиною нашого повсякденного спілкування, але загальноприйняте і професійне використання може сильно відрізнятись.


1.2. Популярний погляд на якість.

Загальноприйнята думка про якість – це дещо нематеріальне і «неосяжне» - про нього можуть вестись суперечки та дискусії, його можна критикувати і вихваляти, але зважити і виміряти неможливо. Вирази типу «хороша якість» і «погана якість» служать наглядним прикладом. Люди так кажуть про щось невизначене для них, що вони не можуть чітко охарактеризувати і визначити. Отже, люди сприймають і інтерпретують якість по різному. Якість не може бути контрольованою і керованою. Якість не може бути кількісно виміряна. Такий погляд різко контрастує з професійним підходом до управління якістю – якість чітко визначена величина, яку можна виміряти і проконтролювати, вона піддається управлінню і покращенню.

Інша популярна думка – якість нерозривно пов’язана з розкішшю, першим сортом і тонким смаком. Дорогий, досконально продуманий і технічно більш складний продукт розглядається як гарантія вищої якості ніж більш дешеві аналоги. За такою логікою Каділлак – якісна машина, а Шевроле – ні, незважаючи на надійність і кількість поломок. Якщо слідувати такому підходу, то якість обмежена визначеним класом дорогих продуктів. Недорогі продукти ж важко віднести до якісних.

1.3. Професійний підхід до якості.

Існують чіткі та зручні для роботи визначення.

В 1979 році Філ Кросбі визначив якість як «відповідність вимогам» ("conformance to requirements").

В 1970 році Юран і Гріна визначили якість як «придатність до використання» ("fitness for use"). Ці два визначення тісно пов’язані і добре узгоджуються.

Ще декілька визначень якості:

Уотс Хемпфрі – досягнення відмінного рівня придатності до використання;

Компанія IBM - якість, яка управляється ринковими потребами (“market - driven quality”). Критерій Белдріджа для організаційної якості - “якість, яка задається споживачем”

Визначення системи менеджменту якості ISO 9001 - ступінь відповідності наявних характеристик вимогам.

«Відповідність вимогам» припускає, що вимоги мають бути настільки чітко визначені, що вони не можуть бути зрозумілі і інтерпретовані некоректно. Пізніше, на етапі розробки, проводяться регулярні вимірювання розробленого продукту для визначення відповідності вимогам. Будь-які невідповідності розглядаються як дефекти – невідповідність якості. Наприклад, специфікація на деяку модель радіостанції може вимагати можливість приймати визначену частоту радіохвиль на відстані більше ніж за 30 км від джерела віщання. У випадку, якщо радіостанція не може виконати дану вимогу, вона не відповідає вимогам до якості і має бути визнаною негідною і неякісною. Виходячи з таких принципів, якщо Каділлак відповідає усім вимогам до машин Каділлак, то це якісна машина. Якщо Шевроле відповідає усім вимогам до машин Шевроле, то це теж якісна машина.

«Придатність до використання» приймає до уваги вимоги і очікування кінцевого користувача, який очікує, що продукт або надаваний сервіс буде зручним для нього. Однак різні користувачі можуть використовувати продукт по різному і це означає, що продукт має володіти максимально різноманітними варіантами використання. Згідно визначенню Юран кожен варіант використання – це характеристика якості і усі вони можуть бути класифіковані по категоріям в якості параметрів придатності до використання.

Ці два визначення якості по суті однакові. Різниця в тому, що варіант «придатність до використання» вказує на важливу роль вимог і очікувань замовника. Роль замовника, пов’язана з якістю, не може бути переоцінена. З точки зору замовника, якість продукту, який він придбав, складається з багатьох факторів: ціна, продуктивність, надійність і т.д.
Тільки замовник може розказати про якість, оскільки це єдине, що він дійсно купляє. Замовник не купляє продукт. Він купляє гарантії того, що усі його очікування до продукту будуть реалізовані.

1.4. Що таке якість програмного забезпечення?


Якщо спитати про це достатньо широку групу людей, які мають справу з розробкою, продажем або використанням ПЗ, можна отримати наступні відповіді:

  • Легко використовувати

  • Хороши продуктивність

  • Нема помилок

  • Не псує даних користувача при збоях

  • Можна використовувати на різних платформах

  • Може працювати 24 години на сутки і 7 днів на тиждень

  • Легко добавляти нові можливості

  • Задовольняє потреби користувача

  • Добре документовано

1.5. Якість ПЗ по МакКолу.


Першою широко відомою моделлю якості ПЗ стала запропонована в 1977 МакКолом та іншими модель. В ній характеристики якості розділені на три групи:

Фактори, які описують ПЗ з позицій користувача. Задаються вимогами.

Критерії, які описують ПЗ з позицій розробника. Задаються як цілі.

Метрики, які використовуються для кількісного описання і вимірювання якості.

Фактори якості, яких було виділено 11, групуються в три групи по різним способам роботи людей з ПЗ. Отримана структура відображується у вигляді трикутника МакКола

Критерії якості – це числові рівні факторів, поставлених як цілей при розробці. Об’єктивно оцінити або виміряти фактори якості безпосередньо важко. Тому МакКол ввів метрики якості, які з його точки зору легше виміряти і оцінити. Оцінки в його шкалі приймають значення від 0 до 10.




  • Зручність перевірки на відповідність стандартам (auditability)

  • Точність керування і обчислень (accuracy)

  • Ступінь стандартності інтерфейсів (communication commonality)

  • Функціональна повнота (completeness)

  • Однорідність використовуваних правил проектування і документації (consistency)

  • Ступінь стандартності форматів даних (data commonality)

  • Стійкість до помилок (error tolerance)

  • Ефективність роботи (execution efficiency)

  • Розширюваність (expandability)

  • Широта області потенційного використання (generality)

  • Незалежність від апаратної платформи (hardware independence)

  • Повнота протоколювання помилок та інших подій (instrumentation)

  • Модульність (modularity)

  • Зручність роботи (operability)

  • Захищеність (security)

  • Самодокументованість (selfdocumentation)

  • Простота роботи (simplicity)

  • Незалежність від програмної платформи (software system independence)

  • Можливість співвідношення проекту з вимогами (traceability)

  • Зручність навчання (training).

Кожна метрика впливає на оцінку деяких факторів якості. Числовий вираз фактору представляє собою лінійну комбінацію значень впливаючих на нього метрик. Коефіціенти цього виразу визначаються по різному для різних організацій, команд розробки, видів ПЗ та інше.

2. Характеристики якості програмного забезпечення.

Якість ПЗ має зовнішні й внутрішні характеристики.

До зовнішніх характеристик відносяться властивості, які усвідомлює користувач програми:

Коректність - відсутність/наявність дефектів у специфікації, проекті та реалізації системи.

Практичність - легкість вивчення і використання системи.

Ефективність - ступінь використання системних ресурсів. Ця характеристика враховує такі фактори, як швидкодія програми і необхідний їй обсяг пам'яті.

Надійність - здатність системи виконувати необхідні функції за певних умов; середній інтервал між відмовами.

Цілісність - здатність системи запобігати неавторизованому або некоректному доступу до своїх програм та даних.

Адаптованість - можливість використання системи без її зміни в тих галузях або середовищах, на які вона не була орієнтована безпосередньо.

Правильність - ступінь безпомилковості системи, особливо щодо виведення кількісних даних.

Живучість - здатність системи продовжувати роботу при введенні неприпустимих даних або в напружених умовах.

Внутрішні характеристики ПЗ:

Зручність супроводу - легкість зміни програмної системи з метою реалізації додаткових можливостей, підвищення швидкодії, виправлення дефектів тощо.

Гнучкість - можливий масштаб зміни системи з метою використання її в тих галузях або середовищах, на які вона не була безпосередньо орієнтована.

Портованість - легкість зміни системи з метою використання у середовищах, на які вона не була орієнтована безпосередньо.

Можливість повторного використання - масштабність і легкість використання частин системи в інших системах.

Зручність читання - легкість читання та розуміння вихідного коду системи, особливо на детальному рівні окремих операторів.

Тестованість - можливий ступінь виконання блокового і системного тестування програми та перевірки її відповідності вимогам.

Зрозумілість - легкість розуміння системи і на рівні загальної організації, і на детальному рівні окремих операторів.

3. Види ліцензій на програмне забезпечення.

Freeware - безкоштовні програми. Програми без обмеження на (некомерційне) використання. Охороняються авторським правом. Слід пам'ятати, що відсутність ціни ще не означає, що виробник дозволяє її вільно поширювати, він може це і забороняти. І буває, що якась програма безкоштовна тільки для домашнього, некомерційного використання, а при використанні її в організаціях потрібно заплатити.

Shareware - умовно-безкоштовні програми. Клас комерційних програм з безкоштовним періодом використання. Вимагають оплати для повнофункціонального використання. При такій моделі розповсюдження пропонується спочатку випробувати програму в дії, а потім оплатити її. Щоправда, "умовність" може лежати в дуже широких межах, від простого нагадування про необхідність заплатити за програму при кожному запуску до обмеженого терміну роботи і навіть блокування в неоплаченій версії найважливіших функцій, що робить неможливим використання програми за прямим призначенням.

Trial, trialware - пробне (оціночне) програмне забезпечення. Обмежено часом використання або кількісними характеристиками, а іноді й функціоналом. Термін перетинається з Shareware. Схоже на crippleware для класу умовно-безкоштовних програм.

Demo, demoware - демонстраційні програми. Мають велику кількість обмежень. Основна мета - не пробне використання, а демонстрація можливостей. Помітно більш обмежене порівняно з trialware.

Adware - рекламно-орієнтовані програми. Без обмежень функціональності, але з примусовим показом реклами, яка може підвантажуватися через Інтернет без відома користувача. Зазвичай включають модуль фонового завантаження реклами, що таїть у собі небезпеку несанкціонованого дистанційного контролю комп'ютера. Антивірусні програми часто класифікують даний механізм як "троянського коня".

Nagware, begware - основним обмеженням використання є примусове вікно діалогу, де повідомляється про те, що версія незареєстрована. Після оплати дане обмеження знімається. Ускладнює використання програми в пакетному режимі при автоматичній обробці інформації.

Public domain - вільні програми. Без обмежень на модифікацію та використання. Не охороняються авторським правом.

Betaware - попередня (тестова) бета-версія комерційного або некомерційного ПЗ. Можна використовувати безкоштовно, але часто обмежується періодом тестування.

Commercial - комерційне програмне забезпечення, яке продається за гроші, захищене різними законами.

Donateware, donationware - авторські програми. Для необов'язкової реєстрації програми потрібно сплатити пожертвування автору.

Open source - відкриті програми з вихідними текстами. Можуть накладатися обмеження на модифікацію та використання в комерційних цілях.

Linkware - автор програми просить вказувати посилання на сайті користувача, (якщо є) на свій сайт.

Registerware - для отримання та/або використання програми потрібно надати інформацію про себе (заповнити анкету).

Guiltware - різновид nagware. У програмі міститься явна згадка, що автор не отримав за неї грошей. Може й не передбачати реєстрації.

Crippleware - ключові можливості програми видалені. Немає обмежень на час використання. Після оплати надається повнофункціональна версія.

Abandonware - позаринкові програми. Як правило, це колишні комерційні програми, які з ряду причин перестають постачати на ринок. Їх поширює зазвичай власник авторських прав на безкоштовній основі, але з жорстким зобов'язанням заборони продавати і навіть без права подальшого безкоштовного тиражування.

Orphanware - різновид abandonware, коли автора не можна розшукати.

Cardware, postcardware - як компенсацію за надання програми автор просить надіслати йому листівку або електронний лист зі словами подяки. Ці листи використовуються авторами для реклами своїх робіт.

Liteware - "полегшений" варіант відповідної комерційної версії. Не обмежена часом використання, але обмежена функціоналом.

Hostageware - програми з функціональними, тимчасовими і кількісними обмеженнями. Розблоковуються після оплати.

Beerware - право на використання програми, а також отримання вихідних текстів в обмін на гроші, на які автор зможе купити собі пива.

Careware, charityware - стягується збір на благодійні цілі, або безпосередньо автору, або за вказаною адресою.

Requestware - автор просить користувача щось зробити в обмін на використання програми (надіслати листівку або електронного листа з подякою, внести пожертви на благодійні цілі тощо). Різновиди: postcardware, careware.

CDware - ПЗ на компакт-дисках, яке розповсюджується в рекламних цілях.

Spyware - програми-шпигуни. Несанкціоновано збирають інформацію про комп'ютер користувача і його дії. Нерідко маскуються під adware. Крім використання антивірусних програм найбільш ефективний спосіб боротьби - встановлення брандмауерів.

4. Моделі відкритого програмного забезпечення.


Розглянемо проблему охорони та використання ПЗ із урахуванням факту наявності різних видів ліцензій на нього, які кардинально змінюють підходи до специфікації і захисту авторських прав, і як наслідок - його використання - закрите і відкрите (вільне) ПЗ. Ці два типи ліцензій на ПЗ визначають модель використання, організаційну модель розробки (якість і технічні параметри програм), структуру витрат на різних етапах життєвого циклу програм, і, зрештою, на модель ринку ПЗ загалом.

     Існує дві моделі відкритості ПЗ:

     Закрите ПЗ (Proprietary software) - автор (або інший власник) утримує за собою низку прав, а користувач - лише обмежене право використання ПЗ. Зокрема, заборонено або закрито доступ до коду, заборонено внесення будь-яких змін, використання більш ніж на одному комп'ютері, тиражування та розповсюдження, перепродаж, копіювання тощо.

     Відкрите (вільне) ПЗ (Free/Open Source Software) - базовий набір майнових прав передається ("ліцензується") власникові кожного екземпляра програми. Користувач ПЗ отримує право та можливість використання програми для різних цілей, доступ до програмного коду, можливість копіювання (тиражування) і публічного поширення копій програми, а також можливість зміни і вільного поширення як оригінальної програми, так і зміненої; дозволено будь-які дослідження механізмів функціонування програми та можливість використання механізмів (принципів) функціонування і будь-яких довільних частин коду програми для створення інших програм та/або адаптації до потреб користувача без додаткової згоди автора (або іншого власника), обов'язкових грошових відрахувань тощо.

     Спираючись на аналіз ліцензій і враховуючи їх особливості, спробуємо дати коротку характеристику цих двох видів ПЗ.

     Для закритого ПЗ характерні такі основні несприятливі для користувача моменти, спричинені насамперед умовами закритого коду, за допомогою яких власники ПЗ впливають на ринок комп'ютерних програм:

  • Більшість закритих програм постачають користувачам без вихідного коду, тобто у формі, що допускає тільки експлуатацію програми, але не її вивчення, модифікацію.

  • Приховування вихідного коду спричиняє зростання асиметрії інформації про товар або послугу, зокрема про якість програмування. Власник, який приховує код, одержує переваги, пов'язані з якістю пропонованого користувачам ПЗ. Так, у випадку виявлення помилки вартість внутрішнього супроводу екземпляра програми на майбутніх етапах експлуатації може значно збільшитися.

  • Приховування вихідного коду спричиняє також монополізацію послуг із супроводу програм (виправлення помилок, розширення функціональності, інтеграція з іншими програмами і новим обладнанням).

     Право внесення змін належить до виняткових майнових прав автора, однак, що стосується випущених в обіг екземплярів програм, це право може бути обмежено (ст. 24 Закону України "Про авторське право і суміжні права" ). Все ж користувач, не маючи доступу до вихідного коду, але володіючи таким правом, мусить подолати серйозні технічні труднощі, щоб скористатися ним. У результаті на ринку надання таких послуг власник ПЗ може мати або має монополію.

  • Серйозним ексцесом закритого ПЗ є тенденція до "пропрієтаризації" ("антистандартизації") інтерфейсів.

     Інтерфейс - це спосіб взаємодії програм між собою, з обладнанням і з кінцевим користувачем (визначає взаємодію програми із системою, формат збереження або передачі даних, протокол (послідовність кроків) передачі даних, інтерфейс користувача (сукупність команд, якими користувач керує програмою, і повідомлень, що відображають її стан або результати роботи).

     Володіючи винятковим доступом до вихідного коду більш як однієї програми, власник може спонукати інших розробників ПЗ взаємодіяти з його нестандартним інтерфейсом або навмисне відхиляється від стандартів і таким чином створювати "власні інтерфейси". Розвиток ринку ПЗ, як правило, супроводжується стандартизацією інтерфейсів. Стандартизація інтерфейсів, що формує конкурентний ринок сумісних і взаємозамінних програм, вигідна для кінцевого користувача і, зрештою, для галузі загалом, однак може бути невигідна для компаній-монополістів, які домінують у деяких сегментах ринку ПЗ .

     Зазначене варто розуміти саме як ексцеси закритого ПЗ, як закономірні, логічні, але не обов'язкові наслідки його закритості, які можна скорегувати виробленням відповідних угод, наприклад, які передбачають обов'язкове постачання вихідного коду програми.

     Проблема "піратства" - це ще один ексцес, тісно пов'язаний із існуванням закритого ПЗ. Це серйозний руйнівний фактор функціонування ринку ПЗ загалом. Посилення державної боротьби з піратством в Україні призвело до сплеску попиту на відкрите ПЗ, яке через розподіл виняткових майнових прав припиняє можливість зловживань.

     Переваги відкритого ПЗ порівняно із закритим ПЗ найяскравіше виявляються в ситуації масової експлуатації програм цього типу .

     Наявність численних вже готових вільних програм. Замовлення на доопрацювання: модифікацію, адаптацію, локалізацію, документування існуючої програми, пакета або системи значно дешевше, ніж замовлення розробки "з нуля".

     Право введення в цивільний обіг додаткових екземплярів програм. Наявність цього права є важливим, оскільки дає змогу уникнути проблем, пов'язаних із ліцензуванням, і, як наслідок, користувач отримує право виготовляти та використовувати додаткові екземпляри програми.

     Наприклад, зміст ліцензії "GNU General Public License" (далі - GNU GPL) (один із видів ліцензії відкритого - вільного - ПЗ) свідчить, що користувач (ліцензіат), який придбав екземпляр програми, здобуває право на відтворення необмеженої кількості екземплярів програми або твору, що є похідним від програми, поширювати екземпляри програми на будь-якому носії, стягувати плату за передачу екземпляра програми, можна також за плату надавати послуги гарантійної підтримки програми. Програма, що вводиться в цивільний обіг під ліцензією GNU GPL, обов'язково супроводжується повним вихідним текстом чи пропозицією надати будь-якому користувачу за винагороду, яка не перевищує вартість виготовлення копії, повну копію вихідного тексту програми.

     Ліцензія "GNU General Public License" була розроблена благодійним фондом Free Sof­tware Foundation (далі - FSF), що сприяє роз­робці ПЗ із відкритим вихідним текстом. Усім авторам, які підтримують ідеї FSF, було рекомендовано включити в розроблені програми повідомлення про свої авторські права і про те, що користувач одержує доступ до програми на умовах ліцензії GNU GPL, а також її текст. Тобто кожен користувач разом із екземпляром програми одержує за ліцензією GNU GPL майнове право на неї, не виплачу­ючи за це правовласникові ніякої винагороди. Завдяки свободі відтворення, поширення і модифікації відкрите ПЗ називають також вільним (free software).

     Ліцензія GNU GPL - це варіант реалізації особливого порядку укладання авторського договору з масовим користувачем. Можливість його застосування передбачена в ст. 32 Закону України "Про авторське право і суміжні права". За своєю правовою природою ліцензія GNU GPL - договір приєднання за ст. 634 ЦК України: "Договором приєднання є договір, умови якого встановлені однією із сторін у формулярах або інших стандартних формах, який може бути укладений лише шляхом приєднання другої сторони до запропонованого договору в цілому. Друга сторона не може запропонувати свої умови договору" .

     На відміну від відкритого ПЗ, введення в цивільний обіг додаткових екземплярів закритого ПЗ дозволено за умови отримання додаткових ліцензій на кожен примірник комп'ютерної програми. Ліцензія на закрите ПЗ неподільна і не допускає одночасного її використання на декількох ЕОМ.

     Однак користувач закритого ПЗ, який правомірно володіє примірником комп'ютерної програми, має право без згоди автора або іншої особи, яка має авторське право на цю програму, виготовити одну копію комп'ютерної програми за умови, що ця копія призначена тільки для архівних цілей або для заміни правомірно придбаного примірника у випадку, якщо оригінал комп'ютерної програми буде втраченим, знищеним або стане непридатним для використання. При цьому копія комп'ютерної програми не може бути використана з іншою метою (ч. 2 ст. 24 Закону України "Про авторське право і суміжні права").

     Не зважаючи на вимоги ст. 24 Закону України "Про авторське право і суміжні права", можливі ситуації, коли право на виготовлення резервної копії заборонено договором. Тоді виникає питання про правомірність такої заборони.

     Право на модифікацію і доступ до вихідних текстів. Наявність цього права дає змогу уникнути "зв'язування" кінцевого користувача в плані вибору контрагента при замовленні або перезамовленні послуг. Будь-яку послугу із виправлення, адаптації, модифікації програми можна замовляти на конкурентному ринку.

     Проблема внесення до закритого ПЗ змін (модифікації) із метою забезпечення його функціонування на технічних засобах користувача, а також виправлення очевидних помилок допускається відповідно до ч. 1 ст. 24 Закону України "Про авторське право і суміжні права". Але особливо необхідно звернути увагу, на те, що застосування цієї норми можливе лише у випадку, якщо інше не передбачено угодою, тобто в угоді може бути заборонено вчинення таких дій.

     Що стосується відкритого ПЗ, то відповідно до ліцензії GNU GPL, ліцензіат має право модифікувати свій екземпляр або екземпляри програми цілком, або будь-яку її частину. Ліцензіат має право також виготовляти і поширювати екземпляри такого продукту, похідного від програми, або змінені екземпляри.

     Вважаємо за необхідне звернути увагу на питання декомпілювання комп'ютерної програми (ч. 3 ст. 24 Закону України "Про авторське право і суміжні права"). Декомпілювання - це технічний прийом, що включає перетворення комп'ютерної програми з об'єктного коду у вихідний текст для одержання інформації, необхідної для досягнення її взаємодії із незалежно розробленою комп'ютерною програмою. Право на декомпілювання комп'ютерної програми має особливо важливе значення для користувачів закритого ПЗ, бо згідно загального правила ПЗ надається тільки в об'єктивному коді при збереженні комерційної таємниці на вихідний текст. Що ж стосується відкритого ПЗ, то завдяки вільному доступу до вихідних текстів, користувач може не відчувати потреби в декомпілюванні ПЗ взагалі .

     Можливість переносу до іншого програмного або апаратного середовища, тобто модифікація, право на яку передбачають вільні ліцензії і технічну можливість якої забезпечує доступність вихідного коду, - це перенесення програми в інше програмне (під іншу операційну систему) або апаратне (на устаткування іншого типу) середовище. Більшість вільних програм доступні більш як для однієї операційної системи або апаратної платформи. Така можливість важлива, оскільки вона зменшує залежність кінцевого користувача від раніше прийнятих рішень у частині апаратного і ПЗ.

     2002 р. в Україні була розгорнута активна діяльність із "легалізації" ПЗ, зокрема того, що використовується у державних установах і державному секторі господарства. Необхідно пам'ятати, що основним одержувачем прибутку від легалізації є закордонні корпорації, виробники закритого ПЗ (наприклад, американська компанія Microsoft). Збільшуючи валовий національний продукт цих країн, ми ризикуємо стати ще менш конкурентоспроможними не тільки в економічному, а й у політичному плані .

     Розробники українського законопроекту "Про використання Відкритих стандартів даних та Вільного програмного забезпечення в державних установах і державному секторі господарства" [37; 38] пропонують широке запровадження, при підтримці держави, використання ПЗ із вільними кодами, що забезпечує масову доступність ліцензійного ПЗ (на відміну від нинішньої ситуації, коли ліцензійне ПЗ від монополістичного постачальника доступне або добре забезпеченим верствам населення, або воно контрафактне). Законопроект створює умови, що гарантують права авторів як "відкритого", так і "пропрієтарного" (закритого) ПЗ, зменшуючи мотивацію для неліцензійного використання ПЗ .

Висновки

Отже, визначення якості з точки зору замовника або користувача продукту:

Якість – це придатність до використання. Чи робить даний продукт те, що мені потрібно? Чи спрощує роботу? Чи можу я його використати так, як мені потрібно?

Точка зору розробника:

Якість – це відповідність специфікованим і забраним вимогам. Чи робить даний продукт усе те, що вказано у вимогах?

Проблема в тому, що специфіковані і забрані вимоги – це зазвичай частина реальних вимог і очікувань замовника.

Отже, якість – це відповідність реальним вимогам, явним і неявним. Дуже часто неявні вимоги настільки очевидні для замовника або користувача, що він навіть не припускає, що вони невідомі розробникам. На прикладі автомобілів: замовник може детально описати вимоги до дизайну, параметрам двигуна, оформленню салону, кольору кузова, але ніде не вказати, що шини мають бути круглими, а лобове скло – прозорим.

Замовник буде повністю задоволеним тільки тоді, коли куплений продукт буде повністю відповідати його реальним і життєвим вимогам – специфікованим і ні.


Використані джерела

1. Андон Ф.И., Коваль Г.И., Коротун Т.М. Основы инженерии качества программных систем. 2-е издание. — К.: Академпериодика, 2007. — 672 с.

2. Соммервилл Я. Инженерия программного обеспечения. — М.: Вильямс, 2002. — 624 с.

3. Канер С., Фолк Дж., Нгуен Х.К.. Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений. – К.: Диасофт, 2001. — 544 с.

1. Що не входить до класу помилок програмування?

  1. синтаксичні помилки;

  2. помилки компілятора;

  3. помилки часу виконання;

  4. логічні помилки;

  5. семантичні помилки

2. До обовязкових артефактів тестування не відноситься:

  1. чек-лист;

  2. план тестування;

  3. тести і тест-кейси;

  4. bug-report;


3. Вкажіть на правильний вид тест-кейсів

  1. повний

  2. негативний

  3. стресовий

  4. правильний

  5. неправильний


4. Що може перевірятись тестувальниами в документації на етапі розробки вимог до продукту?

1. несуперечливість вимог

2. правильність алгоритмів

3. орфографічні помилки

4. помилки в архітектурі

5. помилки у вимогах

5. Назвіть відмінність між емулятором і заглушкою

1. Емулятор, на відміну від заглушки, надає засоби обробки переданих до нього даних

2. Заглушка, на відміну від емулятора, надає засоби обробки переданих до неї даних

3. Обидва інструменти надають засоби для обробки даних, відправлених до них, але відрізняються по ефективності

4. Принципової різниці немає
6. Що з перерахованого є недоліками тестування методом "чорного ящика"

1. Важко знайти і відтворити помилки, що рідко зустрічаються

2. Вхідні дані тесту мають бути з великого простору вибірок

3. Потрібне знання специфіки реалізації програми

4. Неможливо знайти помилки, які взаємно компенсуються

5. Складність відстежування часу виконання команд

7. Вкажіть переваги низхідного інтеграційного тестування

1. Можна розробляти систему як в глибину, так і вширину

2. Можливість ранньої перевірки коректності високорівневої поведінки

3. Модулі можуть додаватися по одному, незалежно один від одного

4. Можливість ранньої перевірки коректності низькорівневої поведінки

8. Ким проводяться приймальні тести (вкажіть усі відповідні варіанти)?

1. Замовниками

2. Розробниками

3. Тестувальниками

4. Користувачами

9. Що характерно для низхідного інтеграційного тестування?

1. Тестування починається з нижніх рівнів системи

2. Тестування починається з інсталляції

3. Відсутні на даний момент модулі замінюються "заглушками"

4. Відсутні на даний момент модулі замінюються драйверами

10. Що з наступного є недоліком граничного аналізу

1. Його неможливо використовувати для регресійного тестування

2. Взаємозалежність між даними тесту не тестується

3. Усі можливі набори початкових даних не тестуються

4. Велика ймовірність пропустити баги

11. Поверхневу експертизу усіх основних компонентів програмної системи, з метою гарантувати їх функціонування, називають:

1. Fuzz тестування

2. Тестування методом чорного ящика (Black Box)

3. Smoke (Димове) тестування

4. Fade тестування

5. системне тестування.

12. Що треба зробити, якщо вимагається написати тест-кейсы на певний функціонал, але можлива кількість тестових сценаріїв занадто велика?

1. Зробити список усіх комбінацій (сценаріїв) і вибрати ті, які йдуть першими

2. Зробити список усіх комбінацій (сценаріїв) і вибрати якусь кількість випадковим чином

3. Оцінити риски і вибрати невелику кількість сценаріїв, які понизили б максимальні риски і знайшли б найбільшу кількість дефектів

4. Вибрати тести, які легко написати і виконати

5. Нічого не тестувати, т.к кількість комбінацій занадто велика і витрати на тестування перевищать розмір суми повернення інвестицій

13. Який вид тестування слід застосувати в першу чергу після виходу нової версії продукту?

1. Тестування (load testing) навантаження

2. Димове тестування (smoke testing)

3. Тестування безпеки (Security and Access Control Testing)

4. Monki nesting

3. Інше

14. Як називається рівень тестування, при якому продукт пропонується для невеликої аудиторії, з тим щоб переконатися, що він не має суттєвих помилок?

1. Гамма-тестування

2. Альфа-тестування

3. Преальфа-тестування

4. Бета-тестування

15. Коли приймається рішення про проведення приймального тестування?

1. Продукт досяг необхідного рівня якості

2. Замовник ознайомлений з Планом Приймальних Робіт (Product Acceptance Plan)

3. Продукт НЕ досяг необхідного рівня якості

4. Замовник НЕ ознайомлений з Планом Приймальних Робіт (Product Acceptance Plan)

16. Які з перерахованих типів тестування відносяться до функціонального тестування?

1. Тестування документації

2. Безпосередньо функціональне тестування

3. Тестування продуктивності

4. Тестування надійності\

17. Тест юзабіліті вказує на те, що дизайн і система мають бути змінені, якщо:

1. Користувачам складно зрозуміти інструкції до системи

2. Користувачі не застраховані від помилок

3. Користувачам складно інтерпретувати результати

4. Усе з перерахованого
18. Що таке severity дефекту?

1. Показник, що визначає пріоритет відлагодження дефекту

2. Міра впливу помилки на кінцевих користувачів

3. Міра впливу помилки в ПО на графік розробника

4. Міра впливу помилки на працездатність системи
19. Який вид тестів використовується для виявлення проблем з витоками пам'яті по методу black box.

1. навантажувальне тестування

2. димне тестування

3. тестування функціональності

4. модульне тестування

5. регресійне тестування
20. Як називається фаза тестування, яка здійснюється кінцевими користувачами безпосередньо перед офіційним випуском програмного забезпечення?

1. Alpha

2. Beta

3. Gamma

4. Нічого з вище наведеного
скачати

© Усі права захищені
написати до нас