Пошук того, чого немає

Елізабет Хендріксона (Elisabeth Hendrickson)

Ця стаття ставить дуже важливе питання «Чого тут немає, що мало б бути?». Для виявлення «дір проектування та вимог» застосовується ідея, схожа на виявлення чорних дірок. Наприклад, часто існують залежності між кількістю помилок, які відносяться до певної області, і тим чи була ця область повністю протестована. Також дірки можуть бути в тому, що показують типи помилок. Хендріксона готує грунт для пошуку і радить як «шукати там, де нічого немає ».

«Тату, як знаходять чорні дірки? »

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

Ідея така: пошук чого або шляхом перегляду порожнечі.

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

Перший спосіб - це спостереження за результатами тестування. Якщо з певної областю не зіставлені помилки, це говорить про те, що дана галузь не була протестована. Звичайно, якщо з певною областю зіставлене багато помилок, це не означає, що вона добре протестована. Так що я також дивлюся на тип помилок. Досягають вони серця функціональності або вони всі поверхневі і несерйозні. Чи відносяться помилки до вхідних даними, переповнення буфера або довжині шляху? Я шукаю вказівка на те, що в нашому тестуванні існують дірки -- види помилок, які ще не знайдено.

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

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

За міру розвитку проекту пошук шаблонів пропущених помилок стає більше важким. Чим більше прив'язаних до областей помилок, тим важче позначати області, в яких спостерігається недолік помилок. І ще це час, коли воно стає критичним. Ви майже закінчили. Незабаром, дещо - хто з Виконавчого рівня почне запитувати вас, чому ви до цих пір не закінчили. Наступна річ, про яку ви знаєте, це те, що ПЗ викладена і/або не викладений на Web. Це не відповідний час для з'ясування, що ніхто не намагається поповнювати каталог з двох браузерів спільно.

Один шлях для пошуку дірок тестування.

Зведіть помилки в матрицю, як вони зберігаються в системі відслідковування помилок. Уздовж однієї боку розділіть тестованої додаток на області. Далі зверху для всіх областей розмістіть список всіх категорій тестів. Наприклад, якщо ви тестуєте програму для редагування, то вздовж сторони можуть розміщуватися Засіб Малювання, Засіб введення Тексту, Вставка Малюнків, рук і т.д.

Категорії зверху можуть включати Скасування введення, Drag and Drop, Міжнародні Символи, Недолік пам'яті і т.д. Ви можете мати кілька десятків елементів на сторону, бажано, не більше тридцяти. (Якщо осередків буде занадто мало, ви не зможете отримувати необхідну інформацію. Якщо занадто багато, матриця стане занадто громіздкою). Весь час хто - то додає помилки, робіть позначки відповідних комірках вашої матриці. Ви шукайте осередку без позначок.

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

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

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

Список літератури

Для підготовки даної роботи були використані матеріали з сайту http://software-testing.ru