Читайте также:
|
|
6. Домашнє завдання: вивчити матеріал лекції.
Зміст лекції
Якість програмного продукту можна оцінити деяким набором характеристик, що визначають наскільки продукт „гарний” з точки зору всіх потенціально зацікавлених в ньому сторін. Такими сторонами є: замовник продукту, спонсор, кінцевий користувач, розробники продукту, тестувальники продукту, інженери підтримки, відділ навчання, відділ продажів і т.д.
Кожен з учасників може мати різне представлення про продукт та по різному судити про те, наскільки він хороший чи поганий, тобто наскільки висока його якість. З точки зору розробника, продукт може бути настільки гарний, настільки гарні закладені в ньому алгоритми та технології. Користувачеві продукту, скоріш за все, байдужі всі деталі внутрішньої реалізації, його в першу чергу хвилюють питання функціональності та надійності. Спонсора хвилює ціна та сумісність з майбутніми технологіями. Таким чином, задача забезпечення якості продукту виливається в задачу визначення зацікавлених осіб, погодження їх критеріїв якості та знаходження оптимального рішення, що задовольняє цим критеріям.
В рамках подібної задачі група тестування розглядається не просто як ще одна зацікавлена сторона, але і як сторона, що може оцінити задоволення вибраних критеріїв та зробити висновки про якість продукту з точки зору інших учасників. На жаль, далеко не всі критерії можуть бути оцінені групою тестування, тому її увага зосереджена на критеріях, що визначають якість ПП з точки зору кінцевого користувача.
Тестування не позиціонується як єдиний спосіб забезпечення якості. Воно є частиною загальної системи забезпечення якості продукту, елементи якого вибираються за критерієм найбільшої ефективності застосування в конкретному проекті.
В кожному конкретному проекті елементи системи мають бути обрані так, щоб забезпечити прийнятну якість, виходячи з пріоритетів та ресурсів, що є. Вибираючи елемент для системи забезпечення якості конкретного продукту, можна застосовувати комбіноване тестування, огляди кодів, аудит. При подібному виборі деякі якості, наприклад легкість модифікації та виправлення дефектів, не будуть оцінені та, можливо, виконані. Завданням тестування в даному випадку буде знаходження дефектів та оцінка зручності використання продукту, включаючи повноту функціональності. Виходячи з задач, поставлених перед групою тестувальників в конкретному проекті, обирається відповідна стратегія тестування. Так, в даному випадку, при необхідності оцінити зручність використання та повноту функціональності, переважно використовувати підхід до розробки тестів на основі сценаріїв.
Отже, основна послідовність дій при виборі та оцінці критеріїв якості програмного продукту включає:
- визначення всіх осіб, які так чи інакше зацікавлені в виконанні та результатах даного проекту;
- визначення критеріїв, що формують уявлення про якість для кожного з учасників;
- надання пріоритетів критеріям, з врахуванням важливості конкретного учасника для компанії, що виконує проект, та важливості кожного з критеріїв для даного учасника;
- визначення набору критеріїв, що будуть відстеженні та виконані в рамках проекту, виходячи з пріоритетів та можливостей проектної команди. Постановка мети по кожному з критеріїв;
- визначення способів та механізмів досягнення кожного критерію;
- визначення стратегії тестування виходячи з набору критеріїв, що підпадають під відповідальність групи тестування, вибраних пріоритетів та цілей.
Процес тестування. Як відмічалося раніше, в тестуванні виділяють три основних рівні, або фази: модульне тестування, інтеграційне тестування та системне тестування. Задача планування активності в тому, щоб оптимально розподілити ресурси між всіма типами тестування. Найбільш важливою та критичною активністю для розробки якісного ПП є фаза системного тестування.
В процесі тестування виділяють наступні фази:
1) визначення цілей (вимог до тестування), що включають наступну конкретизацію: які частини системи будуть тестуватися, які аспекти їх роботи будуть вибрані для перевірки, яка бажана якість і т.д.;
2)планування: створення графіку (розкладу) розробки тестів для кожної підсистеми, що тестується; оцінка необхідних людських, програмних та апаратних ресурсів; розробка розкладу тестових циклів. Важливо відмітити, що розклад тестування повинен бути погоджений з розкладом розробки системи, що створюється;
3)розробка тестів, тобто тестового коду для системи, що тестується, якщо необхідно – коду системи автоматизації тестування та тестових процедур (що виконуються вручну);
4)виконання тестів: реалізація тестових циклів;
5)аналіз результатів.
Після аналізу результатів можливе повторення процесу тестування, починаючи з третього, другого та навіть першого пунктів.
Тестовий цикл. Це цикл виконання тестів, що включають фази 4 та 5 тестового процесу. Зміст тестового циклу в прогоні розроблених тестів на деякому однозначно визначеному зрізі системи (стані коду системи, що розробляється). Зазвичай такий зріз і називають build. Тестовий цикл включає наступну послідовність дій:
- перевірка готовності системи та тестів до проведення тестового циклу, яка включає: перевірку того, що всі тести, заплановані для виконання на даному циклі, розроблені та вкладені в систему контролю версій; перевірку того, що всі підсистеми, які заплановані для тестування на даному циклі, розроблені та вкладені в систему контролю версій; перевірку того, що розроблена та задокументована процедура визначення та створення зрізу системи або build; перевірки деяких додаткових критеріїв.
- підготовка тестової машини відповідно до вимог, визначених на етапі планування (наприклад, повне очищення та перевстановлення системного програмного забезпечення). Конфігурація тестової машини так само як і зріз системи мають бути однозначно відтворюваними.
Відтворення зрізу системи. Прогон тестів відповідно до задокументованих процедур; збереження тестових протоколів (test log). Тest log може містити вивід системи в STDOUT, список результатів порівняння отриманих при виконанні даних з еталонними або будь-які другі вихідні дані тестів, з допомогою яких можна перевірити правильність роботи системи; аналіз протоколів тестування та прийняття рішення про пройшов чи не пройшов кожен з тестів (STDOUT).
Аналіз та документування результатів циклу. Останній перед випуском продукту тестовий цикл не повинен включати змін коду build або коду продукту системи, що тестується. Цей цикл називається „фінальним”. Таким чином забезпечується ситуація, коли фінальний цикл повністю повторюється, а продукт, що випускається, повністю співпадає з продуктом, що пройшов тестування. Фінальний цикл необхідний для гарантії достовірності результатів тестування.
Лекція 2 (2 години)
Тема: Планування тестування
Мета: ознайомити студентів з правилами складання плану тестування та основними пунктами планування тестування.
Література:
1. Котляров В.П. „Основи тестування програмного забезпечення ” Інтернет – університет інформаційних технологій – ІНТУІТ.ру, 2006
2. Орлов С. А., „Технології розробки програмного забезпечення: Підручник для вузів ”. – Спб.: Пітер, 2004р.
Хід заняття
Дата добавления: 2015-07-15; просмотров: 57 | Нарушение авторских прав
<== предыдущая страница | | | следующая страница ==> |
Підведення підсумків заняття. | | | Підведення підсумків заняття. |