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

План

1. Генерування тестових даних.

2. Тестування і прийняття в експлуатацію.

3. Вимоги до документації.

 

Одною  з самих запущених тем в правилах безпеки, що стосуються розробки програмного забезпечення, є тема тестування і документування. Це дуже важливі компоненти розробки програмного забезпечення, які піднімають і питання безпеки. Програма повного тестування може допомогти виявити проблеми до того, як вони проявлять себе в експлуатованому програмному продукті. Крім того, відповідна документація необхідна тим, хто проводить тестування, аби було зрозуміло, що потрібно перевіряти. Тому, такі правила повинні починатися з вимог щодо тестування і документування. Формулювання може виглядати таким чином:

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

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

 

1.   Генерування тестових даних

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

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

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

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

 

2.   Тестування і прийняття в експлуатацію

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

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

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

v  Інсталяція не повинна проводитися без попереднього повідомлення користувачів про те, що їм необхідно надати звіт про помилки.

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

 

3.   Вимоги до документації

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

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

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

 

Питання для самоконтролю:

1.   Особливості документування.

2.   Яким чином проводиться генерування даних.

3.    Як забезпечити конфіденційність даних?

4.   Які вимоги висуваються до документації?