2.7.4.Документування тестових наборів

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

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

• Ідентифікувати тестовий набір і вказати, що саме перевіряється з його допомогою.

• Указати, які функції системи цим тестом не зачіпаються.

• Перелічити усі вимоги до тесту — використовувані файли даних, індекси, відносини, драйвери і т. п.

• Указати всі додаткові вимоги до комплексу апаратних і програмних засобів. Наприклад, тест OLE вимагає наявності на комп'ютері чи в мережі таких програм, як Excel, Word і Mail.

• Указати всі припущення, що враховані в тесті, — мінімальний обсяг пам'яті, вимоги до жорсткого диска, наявність гнучкого диска і т. д.

• Перелічити всі операції, необхідні для запуску тесту.

• Вказати умови, при яких очікується проходження чи непроходження тесту.

• Указати, де можна призупинити проходження тесту і переглянути поточний стан програми.

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

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

• Зробити оцінку передбачуваного часу, необхідного на підготовку і прогін тесту. По завершенні тесту необхідно зафіксувати реально витрачений час.

І ще декілька корисних рекомендацій щодо тестування.

Починайте проводити тестування з перших днів підготовки програмного коду. Виконуйте тестування при першому зручному випадку: чим частіше програма буде тестуватися, тим краще. Якщо для формування виражень використовується Expression Builder, завершуйте процес командою Verify. Якщо в додатку планується використовувати який-небудь спеціальний клас, то обов'язково протестуйте його за допомогою допоміжного драйвера чи форми, перш ніж включати в додаток. Тестуйте окремі функції і процедури. Створюйте макроси для перевірки елементів керування, використовуваних в інтерактивних компонентах додатка — меню чи екранних формах.

• Використовуйте при розробці програм графічні схеми послідовності виконання операцій.

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

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

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

Переглянете також всі елементи введення даних і зверніть увагу на наступні їхні функції:

установка значень за замовчуванням;

використання допоміжного члена PІCTURE;

• необхідність спеціального форматування;

• можливість використання для введення списку визначених значень;

• спеціальні міри для перевірки коректності введених даних і обліку обмежень на діапазон значень.

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

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

• Екранні форми. Чи може користувач закрити форму, не цілком завершивши заповнення полів, і як на це буде реагувати програма?

• Дозавантаження компонентів. Як буде реагувати додаток на те, що викликувана програма на диску відсутня? Що відбудеться, якщо відсутній необхідний індекс? Чи звіт? Чи екранна форма?

• Розміщення даних у файловій системі. Де програма розраховує знайти таблиці даних?

• Настроювання оточення. Чи повинен користувач перед викликом програми використовувати команди SET? А якщо так, те як саме? Чи відомо вам, що в Visual FoxPro дія більшості команд SET поширюється тільки на поточний сеанс роботи з даними? Це означає, що можна організувати в кожній екранній формі власний варіант настроювання оточення командами SET, просто установивши в її властивості DataSessіon значення 2 (приватний сеанс роботи з даними).