упну фазу, де розробляється кінцевий продукт, що складається для користувача - функціональна специфікація. p align="justify"> Функціональна специфікація - це міст між початковим оглядом вимог і технічної специфікацією, розроблюваної пізніше. Початковий огляд вимог виділяє те, що система повинна робити, а технічна специфікація - це деталізоване проектування кожного елемента системи. Таким чином, функціональна специфікація описує, ЩО система буде робити, але не як це буде виконано. Це відмінність важливо. Функціональна специфікація також включає опис всіх головних функціональних модулів і враховуються обмеження. p align="justify"> Цей документ у бізнес-термінах пояснює, що повинна робити система, як повинна працювати і виглядати. А так само специфікація відображає самі останні і кращі ідеї і рішення менеджерів, розробників і дизайнерів. Все в ньому має становити інтерес для користувача, і він не повинен бути перевантажений технічними подробицями, структурами файлів та іншими технологічними деталями. p align="justify"> Відповідальний за специфікацію тільки одна людина. Може бути відповідальною і група людей, якщо проект дуже великий, але навіть у цьому випадку кожен з групи повинен відповідати за окрему частину документа. p align="justify"> Розробка тестових сценаріїв
Одним з методів технічного контролю якості є складання тестових сценаріїв, які містять у собі опис тестування граничних станів, загальний підхід до оцінки якості ПЗ і в той же час визначає специфіку тестування кожного окремо взятого модуля.
Тестові сценарії розробляються відповідно до функціональної специфікацією.
Використання тестового сценарію дозволяє знизити вплив людського фактора на процес тестування: пропускається менше помилок, можливість тестування додаткових функцій і вимог, регресійне тестування, передача інформації, нагадування про тести деякої давності, дозволяють контролювати результати і обмін досвідом, тестування можна відслідковувати в цілому (% зроблено), дозволяє не упустити жодну вимогу.
Наступним етапом контролю якості є тестування додатків.
Тестування Web додатків
Основи тестування Web додатків:
В· реалізація та дизайн
В· Клієнт - сервер установка
В· WEB-орієнтована допомогу
В· конфігурація
В· база даних
В· безпека
В· продуктивність, завантаженість і стійкість до стресів
При тестуванні слід розуміти цілі та реалізацію (технологію)
Два основні класи тестування:
В· дизайн компонентів;
В· реалізація компонентів;
Список перевірок - максимальний набір тестових випадків, який може бути використаний при складанні тестових сценаріїв.
Тестування навігації:
Навігація повинна бути проста, логічна, інтуїтивна. Найбільш використовувані функції швидко доступні, доступні за допомогою клавіатури і миші, навігація в прямому і зворотному порядку. p align="justify"> Тестування презентабельності:
Повинен бути доступ з дозволами 1024 * 768 і 600 * 800, не повинно бути зайвих Скрол, текст на кнопках д/бути видно повністю, кольору лінків відповідні, без розривів картинок, колірної контраст НЕ д/бути низьким, без пробілів в таблицях, відповідним чином оформлені кордону, вирівнювання, форматування, правильне розташування всіх кнопок, перевірка анімації (ненав'язлива, коректно програється).
Обробка помилок:
повідомлення повинно максимально описувати проблему, користувачеві, пропонувати можливі шляхи виходу з неї, не повинні містити граматичних помилок. Краще, якщо валідація відбувається на обміні даних, бажано вказівку конкретних проблем. p align="justify"> Безпека:
В· шифрування
В· аутентифікація
В· цифрові сертифікати
В· брандмауери
В· авторизація
Тестування бази даних:
В· пошук
В· додавання дублюється інформації
В· додавання/редагування/з...
