Требования к тестированию

Question

Я только что закончил реализацию моей программной системы, и теперь я должен подтвердить, удовлетворяет ли она ее требованиям. Какую информацию я должен включить и как ее изложить?

Мои первоначальные функциональные и нефункциональные требования было в таблице на две колонки и смотрел что-то вроде этого:

• FN-01 Система должна позволить пользователям отправлять личные сообщения друг с другом .
• NFN-03 Конфигурация/конфигурация форма должна содержать разумные значения по умолчанию для большинства полей.

Answer 1

Список, один за другим, номера требований с линией требований, а затем текст и/или скриншоты, подтверждающие, что это так.

Имейте номер требования слева выделен жирным шрифтом, затем введите текст требования и введите курсивом. Совместите пробный текст/скриншоты с текстом требований, оставляя левый столбец четкими только для номеров требований. EG:

REQ-1  italicized requirement text 

      text discussing how the software has 
      fulfilled the requirements, possibly 
      with a picture: 

      ----------------------- 
      |      | 
      |      | 
      |      | 
      |      | 
      |      | 
      ----------------------- 

REQ-2  italicized requirement text 

      etc... 

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

Answer 2

Я хотел бы сохранить это простой и добавьте следующие столбцы:

• Доставка Удовлетворенный требование - с помощью выпадающего списка, содержащего Да, Нет, Open
• комментарий - любой комментарий по поводу доставки, таких как «нужно отменить Мелкий размер сообщения»,„Не полностью удовлетворить в макете сообщения, но одобряется клиентом“и т.д.
• Дата завершена - когда изменение было доставлено удовлетворено
• Дата - когда изменение было принято

при использовании требование идентификаторов, я предполагаю, что они указывают обратно на документы, содержащие более подробную информацию, включая макеты, снимки экрана и т.д.

Answer 3

Я хотел бы использовать схему нумерации требование уже на месте, а не создавать новенький. Я бы документ следующие пункты для каждого требования:

1. Требование Статус: Это можно выразить по-разному, но вы Tyring общаться, если требование было завершено, как указано, завершено в модифицированном варианте, что был указан или просто не мог быть завершен вообще.
2. Комментарий к требованию: Описывает ранее указанный статус требований. Это «почему», который объяснит те предметы, которые не смогли полностью удовлетворить требования.
3. Дата завершения: Это в основном для будущего планирования продукта, но также и для серверов как историческая справка.

Пару других точек помнить:

1. Требования могут быть рассмотрены клиентом, особенно если клиент является источником требований. Следовательно, этот документ должен быть максимально точным и информативным. (Это еще одна причина, по которой вы не меняете схему нумерации требований, если вам не нужно.)
2. В вашем отделе тестирования (при условии, что у вас есть) эти документы должны использоваться для планирования тестирования, и им необходимо знать, какие требования были выполнены , которых не было и главное, какие из них изменились и как.

Наконец, если вы не ставите на собаку и выставку пони для кого-то, вам не нужны скриншоты как часть документации по требованию. Вам также не нужно предоставлять «доказательство» завершения. Отдел тестирования сделает это за вас.

Answer 4

Обычно у нас есть план тестирования, в котором каждый элемент может быть отмечен галочкой, если он удовлетворительный. План будет основываться на первоначальных требованиях (функциональных или нефункциональных), например:

Требование: Учетная запись пользователя должна быть заблокирована после трех попыток входа с неправильным паролем.

Тест: Попытка входа в систему более трех раз с неправильным паролем. Учетная запись пользователя заблокирована?

Мы сделаем это для каждого требования и заново запустим планы для каждого кандидата на выпуск. Некоторые из тестов автоматизированы, но у нас есть лифчик тестовой команды для проведения ручного тестирования!

Основываясь на результатах выполнения этих планов испытаний и тестирования приемочных испытаний, мы должны были бы отменить RC как правильный и подходящий для выпуска.

Обратите внимание, что иногда мы выходим на учет, даже если некоторые пункты в плане тестирования не проходят, все зависит от характера предметов!

Answer 5

Формальный способ проверки требований - тестирование - обычно приемочное тестирование.

Идея: для каждого требования должен быть один или несколько тестов, которые подтверждают это требование. В официальной ситуации развития клиент будет подписываться на приемочные испытания в то же время, когда они подписываются на требования.

Затем, когда продукт будет готов, вы представите результаты приемочных испытаний, и клиент проверяет их до принятия окончательного продукта.

Если у вас есть требования, которые не могут быть протестированы, они, вероятно, плохо написаны.

например. не говорите, что «загрузка файлов должна быть быстрой», скажем, «файл размером X должен быть загружен не более Y миллисекунд на аппаратном обеспечении Z» или что-то в этом роде.

Answer 6

Есть некоторые методы для преобразования ваших требований в тестовые примеры. Но это зависит от того, как ваши требования документированы. Если вы уже сделали анализ требований к сценариям, тогда это будет очень просто: просто создайте диаграмму последовательности для каждого пути вашего сценария, напишите/сделайте тест -> сделано. Кроме того, созданная таким образом документа должна также впечатлить вашего лектора.

Если у вас нет сценариев, вы должны создать некоторые из своих вариантов использования.

Недостатком здесь является то, что она очень интенсивно работать и должны использоваться только в тех случаях, оправдывающих его использование (тезис, например;))