Як великі компанії розробників програмного забезпечення перевіряють на наявність помилок у своїх програмах?

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

Вони просто тестують його на кількох комп'ютерах?

Ось деякі методи, якими користується Google.

1. Найміть хороших розробників, які, ймовірно, вироблять надійний код.
2. Тест блоку сильно.
3. Використовуйте огляд коду .
4. Налаштуйте безперервну збірку для вирішення проблем інтеграції.
5. Виділили відділи забезпечення якості. Мається на увазі як тестування людей, так і автоматизовані програми (наприклад, за допомогою Selenium), що імітують кінцевих користувачів.
6. Здійснюйте моніторинг у виробництві, щоб отримати свідчення про те, що речі погано себе ведуть.

Я класифікував це в тому, що я підозрюю, що це порядок зниження ефективності у виловленні помилок.

Більші компанії зазвичай мають цілі підрозділи Q / A, які відповідають за тестування коду та переконують, що він працює так, як належить. Зазвичай так само, як ви описали - купа людей, які випробовують багато машин. Іноді тести автоматизовані, іноді - ні. Див. Забезпечення якості - Вікіпедія

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

Більш дрібні компанії, як та, в якій я зараз працюю, використовують практику Agile Testing

Я б сказав про термін зрілості компанії, а не про розмір :) Є великі компанії, які мають погану практику розвитку та невеликі компанії, що знаходяться на межі кровотечі.

Загалом команда зрілого розвитку бере участь у наступних заходах до 1; мінімізувати введення нових помилок у систему та 2; знайти помилки в існуючій системі.

Тестування одиниць: це "міні-драйвери" для окремих методів, щоб переконатися, що метод виконує те, що, за його словами, робить. Це завжди автоматизовані тести.

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

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

Функціональне тестування: Ці тести схожі на тести прийняття, але вони також перевіряють «нещасний шлях». Ці тести означають перевірити не настільки очевидні сценарії. Може бути ручним або автоматизованим.

Регресійне тестування: Цей термін ми використовуємо для повного тестування системи перед її випуском для клієнтів. Ручний або автоматизований.

Тестування горили: (лише вручну). Це такий вид тестування, коли дуже розумні люди навмисно намагаються зламати додаток.

Тестування ефективності Намагається переконатися, що продуктивність є прийнятною та не погіршується з часом. Зазвичай автоматизовані.

Тестування на стабільність: Ці випробування розроблені так, щоб система залишалася стабільною з часом. Автоматизовані.

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

Звіти про покриття коду: Показує, яка частина вашого коду перевірена. Код, який не має тестового покриття, швидше за все порушиться.

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

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

Найважливіше відібрати: автоматизація та безперервна інтеграція .

Це залежить від компанії та від продуктів, які вона розробляє.

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

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

По-третє, коли це можливо, компанії роблять Dogfooding (мають власні користувачі, які використовують продукт всередині), а потім випускають обмежені бета-версії. На цьому етапі виявлено багато помилок. Наприклад, люди, які працюють у Microsoft, використовують новіші внутрішні версії Office та Windows та DevStudio, ніж ті, що у вас є поза. Тоді обмежені групи користувачів або підрядні компанії отримують вибірку. Так само в Google ми використовуємо внутрішні версії GMail та Docs до випуску. Ігрові компанії організовують відкриті бета-версії для тестування своїх продуктів та завантаження серверів тощо.

Звичайно, відповідь - "Це залежить", але я наведу зразок з мого найбільшого проекту досі, в який в пік було залучено близько 50 розробників.

Основна настройка: Запуск програмного забезпечення для обробки великої кількості даних за допомогою BizTalk.

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

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

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

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

На іншому треку постачальники систем тестували пакети встановлення, щоб перевірити, чи правильно вони встановлені у виробничому середовищі, і чи можна їх відкотити, якщо щось не вдалося.

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

Коли ми були задоволені всіма тестами, код був введений у виробництво. Ви отримуєте досить велику затримку для виправлення помилок у коді (наприклад, 4-6 тижнів протягом усього тестового циклу), і робити ці всі тести дорого, але загальна стабільність була досить хорошою. Насправді найкраще, що я бачив досі. Знову це досить важливо для системи, яка щодня обробляє кілька мільйонів доларів. Ваші вимоги можуть різнитися, але саме так ми це зробили і це спрацювало.

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

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

Ці потреби повинні бути відображені в окремих історіях / вимогах, які останнім часом (на етапі побудови) будуть реалізовані у вихідному коді.

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

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

Використання віртуальних машин сьогодні дозволяє одному тестувальнику запускати різні середовища в одному і тому ж реальному апаратному забезпеченні. Але іноді вам потрібні деякі комп’ютери, присвячені фазі QA.

Я сподіваюся, що це допоможе вам зрозуміти (приблизно) загальний процес.

Ну, я ненавиджу бути цинічним, але з кількістю відкритих помилок в певній операційній системі «пристроїв» здається, що чим більша та багатша компанія, тим більше помилок вони здатні створити та доставити кінцевому користувачеві. Якщо програмне забезпечення ніби працює і виглядає круто, вони все одно просто випускають його. Якщо менеджери думають, що вона готова, то вона готова. Ось тоді справді неприємні помилки починають виходити з дерев’яних виробів, і кінцевими користувачами стають морські свинки. Через десять років, більшість помилок буде відпрацьовано (і кілька додано для гарної міри), і компанія буде готова перейти до наступної великої ідеї.