Software-testing - Історія редагувань

WikiSysop в 18:12, 9 вересня 2022

2022-09-09T18:12:06Z

WikiSysop в 18:07, 9 вересня 2022

2022-09-09T18:07:32Z

WikiSysop в 18:06, 9 вересня 2022

2022-09-09T18:06:51Z

WikiSysop в 08:06, 9 вересня 2022

2022-09-09T08:06:49Z

WikiSysop в 08:00, 9 вересня 2022

2022-09-09T08:00:17Z

WikiSysop в 07:58, 9 вересня 2022

2022-09-09T07:58:36Z

WikiSysop в 07:58, 9 вересня 2022

2022-09-09T07:58:04Z

WikiSysop в 07:57, 9 вересня 2022

2022-09-09T07:57:17Z

WikiSysop: Створена сторінка: == Тестування програмного забезпечення == Тестування програмного забезпечення (англ. Softw...

2022-09-09T07:52:25Z

Створена сторінка: == Тестування програмного забезпечення == Тестування програмного забезпечення (англ. Softw...

Нова сторінка

== Тестування програмного забезпечення ==
Тестування програмного забезпечення (англ. Software Testing) – техніка контролю якості, що перевіряє відповідність між реальною і очікуваною поведінкою програми завдяки кінцевому набору тестів, які обираються певним чином.

Може оцінюватись:
* відповідність вимогам, якими керувалися проектувальники та розробники;
* правильна відповідь для усіх можливих вхідних даних;
* виконання функцій за прийнятний час;
* практичність;
* сумісність з програмним забезпеченням та операційними системами;
* відповідність задачам замовника.

Зазвичай, якість обмежується такими поняттями як коректність, надійність, практичність, безпечність, але може містити більше технічних вимог, котрі описані у стандарті '''ISO 9126''. Склад та зміст супутньої документації процесу тестування визначається стандартом '''IEEE 829–1998''' Standard for Software Test Documentation. Існує багато підходів до тестування програмного забезпечення, але ефективне тестування складних продуктів – це по суті дослідницький та творчий процес.

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

== Рівні тестування ==
# '''Компонентне або модульне тестування''' Перевіряє функціональність і шукає дефекти в частинах програми, які доступні і можуть бути протестовані окремо в силу своєї автономності (модулі програми, об’єкти, функції і т.д.).
# '''Інтеграційне тестування''' Призначено для перевірки зв’язків між компонентами програми, а також дослідження взаємодії додатку зсередовищем, в рамках якого воно буде виконуватися.
# '''Системне тестування''' направлено на дослідження функціональних і нефункціональних особливостей системи в цілому. При цьому виявляються
дефекти, такі як невірне використання ресурсів системи, непередбачені комбінації даних рівня користувача, несумісність з оточенням, непередбачені сценарії використання, відсутня або невірна функціональність, незручність використання і т.д.
# '''Приймальне тестування''' проводиться на фінальному етапі розробки та спрямовано на з’ясування того, чи відповідає система приймально/здавальним критеріям до вимог замовника.

== Види тестуванн ==
# Функціональні види тестування пов’язані з дослідженням зовнішньої поведінки системи, тобто виконуваних нею функцій. До них належать:
* функціональне тестування
* тестування безпеки
* тестування взаємодії
# Нефункціональні
* тестування встановлення
* тестування зручності використання
* тестування на відмову і відновлення
* конфігураційне тестування,
* тестування продуктивності (навантаження)

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

== Термінологія ==
=== Помилка, баг, дефект ===
* '''Помилка (Еrror)''' – хибне значення величини на виході системи або підсистеми, що викликане несправностями або збоями, яке, в свою чергу,
може викликати відмову.
* '''Несправність, дефект (Fault)''' – визнана або передбачувана причина помилки; наслідок відмови деякої системи, що обслуговувала або обслуговує в даний момент часу розглянуту систему. Дефекти також часто називають «'''багами'''» (від англ. '''bugs''' – жучки).
* '''«Гейзінбаг» (англ. heisenbug)''' – це програмна помилка, яка зникає або змінює свої характеристики при спробі її виявити.
* '''«Борбаг» (англ. bohrbug)''' – це така програмна помилка, поведінку якої визначено деякою кількістю певних (але, можливо, невідомих) умов.
* '''«Шредінбаг» (англ. schrodinbug )''' – це програмна помилка, яка ніяк не проявляється (або є невідомою), до тих пір, поки хто-небудь не виявить її, прочитавши вихідний код або використавши програми в незвичайних (не передбачених) умовах.
* '''«Статистичний баг» (англ. statistical bug )''' – це така програмна помилка, яка може бути виявлена тільки при агрегації досить великої кількості результатів тестів. Іншими словами, окремі випробування (і навіть їх невелика кількість) не виявляють помилки – вона стає видна, тільки якщо розглядати велику кількість результатів одночасно.

=== Збій, відмова, аварія ===
* '''Збій (Malfunction)''' – перший прояв дефекту в роботі системи (проява несправності, зазвичай в роботі устаткування).
* '''Відмова (Failure)''' – це більш серйозний прояв дефекту в системі (або підсистеми), при якому вся система або її частина виходять з ладу, виходячи при цьому з працездатного стану, тобто стану в якому всі аспекти функціонування системи відповідають вимогам.
* '''Аварія''' – відмова системи, при якому система виходить з ладу таким чином, що відновлення її працездатного стану або неможливо, або займає значний час. У разі програмних систем можна уникнути виникнення аварійних ситуацій за допомогою повного дублювання системи як виконуваного програмного коду, так і даних.

← Попередня версія		Версія за 08:06, 9 вересня 2022
Рядок 62:		Рядок 62:
	* '''Відмова (Failure)''' – це більш серйозний прояв дефекту в системі (або підсистеми), при якому вся система або її частина виходять з ладу, виходячи при цьому з працездатного стану, тобто стану в якому всі аспекти функціонування системи відповідають вимогам.		* '''Відмова (Failure)''' – це більш серйозний прояв дефекту в системі (або підсистеми), при якому вся система або її частина виходять з ладу, виходячи при цьому з працездатного стану, тобто стану в якому всі аспекти функціонування системи відповідають вимогам.
	* '''Аварія''' – відмова системи, при якому система виходить з ладу таким чином, що відновлення її працездатного стану або неможливо, або займає значний час. У разі програмних систем можна уникнути виникнення аварійних ситуацій за допомогою повного дублювання системи як виконуваного програмного коду, так і даних.		* '''Аварія''' – відмова системи, при якому система виходить з ладу таким чином, що відновлення її працездатного стану або неможливо, або займає значний час. У разі програмних систем можна уникнути виникнення аварійних ситуацій за допомогою повного дублювання системи як виконуваного програмного коду, так і даних.
−
−	~~==Тестування програмного забезпечення==~~
−
−	Вид діяльності в процесі розробки, пов’язаний з виконанням процедур, спрямованих на виявлення (доказ наявності) помилок (невідповідностей, неповноти, двозначностей тощо) в поточному визначенні розроблюваної програмної системи.
−
−	* '''Верифікація''' (лат. verus – «істинний» і facere – «роблю») – постійно виконуваний аналітичний процес перевірки того, що розробка перебуває на правильному шляху: кожен етап розробки є коректним, необхідним (не зайвим) і задовольняє потреби наступного етапу
−	~~# Потреби користувачів.~~
−	~~# Функції продукту.~~
−	~~# Вимоги.~~
−	~~# Архітектура.~~
−	~~# Модель проектування.~~
−	~~# Реалізація.~~
−	~~# Планування тестів.~~
−
−	~~Верифікувати слід:~~
−
−	~~# Описані функції системи дійсно відповідають потребам клієнта/користувачів.~~
−	~~# Варіанти використання та вимоги, створені на основі функцій, підтримують ці функції.~~
−	~~# Проектування, яке підтримує функціональну і нефункціональну поведінку системи~~
−
−	* '''Валідація''' (англ. Validation – перевірка правильності) – процес перевірки того, що реалізована система задовольняє пред’явленим вимогам і працює так, як передбачалося – «Ми створюємо правильну систему»
−
−	~~План тестування. Керівний документ, що відображає :~~
−	~~# як проводитиметься тестування, включаючи конфігурації тестованої системи;~~
−	~~# хто буде тестувати;~~
−	~~# що буде тестуватися;~~
−	~~# скільки часу займе тестування;~~
−	~~# який рівень якості тестування необхідний.~~
−	~~# Критерії успішності тестування.~~
−	~~# Дані для тестування.~~
−	~~# Сценарії тестування, включаючи передумови і кроки тестів.~~
−	~~# Звіт про переходи між етапами тестування.~~
−	~~# Протокол тестування.~~
−	# Звіт про інциденти, включаючи очікуваний результат, фактичний результат, час, передбачувані причини інциденту і все, що може допомогти з розв’язанням ситуації. '''Інцидент''' – не обов’язково має на увазі помилку в системі: очікуваний результат міг бути невірним, перевірка могла проводитися невірно, вимога могла тлумачитися поіншому.
−	~~# Звіт про тестування.~~
−
−	~~[http://eprints.cdu.edu.ua/1482/1/testyvan.pdf ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ]~~

← Попередня версія		Версія за 08:00, 9 вересня 2022
Рядок 97:		Рядок 97:
	# Звіт про інциденти, включаючи очікуваний результат, фактичний результат, час, передбачувані причини інциденту і все, що може допомогти з розв’язанням ситуації. '''Інцидент''' – не обов’язково має на увазі помилку в системі: очікуваний результат міг бути невірним, перевірка могла проводитися невірно, вимога могла тлумачитися поіншому.		# Звіт про інциденти, включаючи очікуваний результат, фактичний результат, час, передбачувані причини інциденту і все, що може допомогти з розв’язанням ситуації. '''Інцидент''' – не обов’язково має на увазі помилку в системі: очікуваний результат міг бути невірним, перевірка могла проводитися невірно, вимога могла тлумачитися поіншому.
	# Звіт про тестування.		# Звіт про тестування.
		+
		+	[http://eprints.cdu.edu.ua/1482/1/testyvan.pdf ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ]

@@ Рядок 95: / Рядок 95: @@
 # Звіт про переходи між етапами тестування.
 # Протокол тестування.
-# Звіт про інциденти, включаючи очікуваний результат, фактичний результат, час, передбачувані причини інциденту і все, що може
+# Звіт про інциденти, включаючи очікуваний результат, фактичний результат, час, передбачувані причини інциденту і все, що може допомогти з розв’язанням ситуації. '''Інцидент''' – не обов’язково має на увазі помилку в системі: очікуваний результат міг бути невірним, перевірка могла проводитися невірно, вимога могла тлумачитися поіншому.
 # Звіт про тестування.

← Попередня версія		Версія за 07:57, 9 вересня 2022
Рядок 62:		Рядок 62:
	* '''Відмова (Failure)''' – це більш серйозний прояв дефекту в системі (або підсистеми), при якому вся система або її частина виходять з ладу, виходячи при цьому з працездатного стану, тобто стану в якому всі аспекти функціонування системи відповідають вимогам.		* '''Відмова (Failure)''' – це більш серйозний прояв дефекту в системі (або підсистеми), при якому вся система або її частина виходять з ладу, виходячи при цьому з працездатного стану, тобто стану в якому всі аспекти функціонування системи відповідають вимогам.
	* '''Аварія''' – відмова системи, при якому система виходить з ладу таким чином, що відновлення її працездатного стану або неможливо, або займає значний час. У разі програмних систем можна уникнути виникнення аварійних ситуацій за допомогою повного дублювання системи як виконуваного програмного коду, так і даних.		* '''Аварія''' – відмова системи, при якому система виходить з ладу таким чином, що відновлення її працездатного стану або неможливо, або займає значний час. У разі програмних систем можна уникнути виникнення аварійних ситуацій за допомогою повного дублювання системи як виконуваного програмного коду, так і даних.
		+
		+	==Тестування програмного забезпечення==
		+
		+	Вид діяльності в процесі розробки, пов’язаний з виконанням процедур, спрямованих на виявлення (доказ наявності) помилок (невідповідностей, неповноти, двозначностей тощо) в поточному визначенні розроблюваної програмної системи.
		+
		+	* '''Верифікація''' (лат. verus – «істинний» і facere – «роблю») – постійно виконуваний аналітичний процес перевірки того, що розробка перебуває на правильному шляху: кожен етап розробки є коректним, необхідним (не зайвим) і задовольняє потреби наступного етапу
		+	# Потреби користувачів.
		+	# Функції продукту.
		+	# Вимоги.
		+	# Архітектура.
		+	# Модель проектування.
		+	# Реалізація.
		+	# Планування тестів.
		+
		+	Верифікувати слід:
		+
		+	# Описані функції системи дійсно відповідають потребам клієнта/користувачів.
		+	# Варіанти використання та вимоги, створені на основі функцій, підтримують ці функції.
		+	# Проектування, яке підтримує функціональну і нефункціональну поведінку системи
		+
		+	* '''Валідація''' (англ. Validation – перевірка правильності) – процес перевірки того, що реалізована система задовольняє пред’явленим вимогам і працює так, як передбачалося – «Ми створюємо правильну систему»
		+
		+	План тестування. Керівний документ, що відображає :
		+	# як проводитиметься тестування, включаючи конфігурації тестованої системи;
		+	# хто буде тестувати;
		+	# що буде тестуватися;
		+	# скільки часу займе тестування;
		+	# який рівень якості тестування необхідний.
		+	# Критерії успішності тестування.
		+	# Дані для тестування.
		+	# Сценарії тестування, включаючи передумови і кроки тестів.
		+	# Звіт про переходи між етапами тестування.
		+	# Протокол тестування.
		+	# Звіт про інциденти, включаючи очікуваний результат, фактичний результат, час, передбачувані причини інциденту і все, що може
		+	допомогти з розв’язанням ситуації. '''Інцидент''' – не обов’язково має на увазі помилку в системі: очікуваний результат міг бути невірним,
		+	перевірка могла проводитися невірно, вимога могла тлумачитися поіншому.
		+	# Звіт про тестування.

@@ Рядок 18: / Рядок 18: @@
 # '''Компонентне або модульне тестування''' Перевіряє функціональність і шукає дефекти в частинах програми, які доступні і можуть бути протестовані окремо в силу своєї автономності (модулі програми, об’єкти, функції і т.д.).
 # '''Інтеграційне тестування''' Призначено для перевірки зв’язків між компонентами програми, а також дослідження взаємодії додатку з середовищем, в рамках якого воно буде виконуватися.
-# '''Системне тестування''' направлено на дослідження функціональних і нефункціональних особливостей системи в цілому. При цьому виявляються
+# '''Системне тестування''' направлено на дослідження функціональних і нефункціональних особливостей системи в цілому. При цьому виявляються дефекти, такі як невірне використання ресурсів системи, непередбачені комбінації даних рівня користувача, несумісність з оточенням, непередбачені сценарії використання, відсутня або невірна функціональність, незручність використання і т.д.
 # '''Приймальне тестування''' проводиться на фінальному етапі розробки та спрямовано на з’ясування того, чи відповідає система приймально/здавальним критеріям до вимог замовника.

@@ Рядок 10: / Рядок 10: @@
 * відповідність задачам замовника.
-Зазвичай, якість обмежується такими поняттями як коректність, надійність, практичність, безпечність, але може містити більше технічних вимог, котрі описані у стандарті '''ISO 9126''. Склад та зміст супутньої документації процесу тестування визначається стандартом '''IEEE 829–1998''' Standard for Software Test Documentation. Існує багато підходів до тестування програмного забезпечення, але ефективне тестування складних продуктів – це по суті дослідницький та творчий процес.
+Зазвичай, якість обмежується такими поняттями як коректність, надійність, практичність, безпечність, але може містити більше технічних вимог, котрі описані у стандарті '''ISO 9126'''. Склад та зміст супутньої документації процесу тестування визначається стандартом '''IEEE 829–1998''' Standard for Software Test Documentation. Існує багато підходів до тестування програмного забезпечення, але ефективне тестування складних продуктів – це по суті дослідницький та творчий процес.
-'''Тест'' – контрольна задача для перевірки коректності функціонування ПЗ. Основна ідея тестування – запустити ПЗ і спостерігати за його роботою та її наслідками.
+'''Тест''' – контрольна задача для перевірки коректності функціонування ПЗ. Основна ідея тестування – запустити ПЗ і спостерігати за його роботою та її наслідками.
 Якщо збій в роботі ПЗ відбувся, то аналізується звіт з метою виявлення місцезнаходження помилки, яка його викликала. «Вдалим» тестом є той, при якому виконання програми закінчилось з помилкою.

@@ Рядок 23: / Рядок 23: @@
 == Види тестуванн ==
-# Функціональні види тестування пов’язані з дослідженням зовнішньої поведінки системи, тобто виконуваних нею функцій. До них належать:
+* Функціональні види тестування пов’язані з дослідженням зовнішньої поведінки системи, тобто виконуваних нею функцій. До них належать:
-* функціональне тестування
+# функціональне тестування
-* тестування безпеки
+# тестування безпеки
-* тестування взаємодії
+# тестування взаємодії
-# Нефункціональні
+* Нефункціональні
-* тестування встановлення
+# тестування встановлення
-* тестування зручності використання
+# тестування зручності використання
-* тестування на відмову і відновлення
+# тестування на відмову і відновлення
-* конфігураційне тестування,
+# конфігураційне тестування,
-* тестування продуктивності (навантаження)
+# тестування продуктивності (навантаження)
 == Мета і задачі тестування ==