Вариант тестирования - История изменений

Admin в 17:33, 24 мая 2021

2021-05-24T17:33:29Z

Admin в 09:50, 15 декабря 2017

2017-12-15T09:50:49Z

Admin: /* Уровни проработки */

2017-12-15T09:50:17Z

‎Уровни проработки

Admin: /* Уровни проработки */

2017-02-01T14:54:43Z

‎Уровни проработки

Admin: Новая страница: «'''Вариант тестирования''' (Test case) ― рабочий продукт альф Архитектура и Требования. Ва…»

2017-02-01T14:13:51Z

Новая страница: «'''Вариант тестирования''' (Test case) ― рабочий продукт альф Архитектура и Требования. Ва…»

Новая страница

'''Вариант тестирования''' (Test case) ― рабочий продукт альф [[Архитектура]] и [[Требования]]. Вариант тестирования это набор условий, при которых тестировщик будет определять, удовлетворяется ли заранее определённое требование. Чтобы определить, что требование полностью выполняется, может потребоваться много вариантов тестирования. Часто варианты тестирования группируют в тестовые наборы.

== Уровни проработки ==
[[OMG Essence]] определяет следующие уровни проработки (levels of detail) для рабочего продукта "Вариант тестирования" и контрольные вопросы на каждом уровне:

{| class="wikitable" style="font-size: 9pt;"
! style="text-align: center; font-weight: bold;" | №
! style="text-align: center; font-weight: bold;" | Уровень проработки
! style="text-align: center; font-weight: bold;" | Level of Detail
! style="text-align: center; font-weight: bold;" | Описание
! style="text-align: center; font-weight: bold;" | Контрольные вопросы
|-
| 1
| style="font-weight: bold;" | Идеи тестирования сформулированы
| Test Ideas Formulated
| The lightest level of detail just captures the initial idea that will inform the test case. When defining a test case it needs to be clear what the idea behind the test case is, and which slice of the requirements it applies to. A test case can be considered as a question that you ask of the system. The point of running the test case is to gain information, for example whether the system works as specified or not. There has to be a reason for the creation of the test case. Some test cases exist to address specific project risks, whereas others are based upon experience, hunches, test results or test techniques used to methodically produce test cases. This reasoning can be summarized as the test idea behind the test case, and is the earliest form that a test case can take.
| ❑The reason for the existence of the test case is clear.

❑The information to be revealed by the test case is clear.
|-
| 2
| style="font-weight: bold;" | Сценарий выбран
| Scenario Chosen
| To make the test case executable the scenario to be performed needs to be selected. Once the scenario has been identified the test case is defined enough to support exploratory and investigative testing. This can be very useful early in the project lifecycle when the insight provided by testing the system is invaluable but the specification (and solution) may not be stable enough to support formal, scripted testing.
| ❑The scenario to be executed is clearly defined.

❑The start and end state for the scenario execution are defined.
|-
| 3
| style="font-weight: bold;" | Переменные определены
| Variables Identified
| A test case takes some inputs, manipulates system states, and produces some results. These appear as inputs, internal states and outputs in the requirements that the scenario covers. At this level of detail the acceptable ranges for the key variables involved in the scenario are explicitly identified. Use the inputs, outputs and internal states of the relevant requirements to identify suitable variables. This level of detail is suitable for those test cases where soliciting the opinion of the tester is an essential part of the test, for example when undertaking usability testing. It can also be used when more structure is needed for exploratory and investigative testing. Once identified the variables can be characterized and more detailed ranges of inputs and expected results specified.
| ❑Relevant variables have been identified.

❑Acceptable ranges for the key variables are known.
|-
| 4
| style="font-weight: bold;" | Переменные установлены
| Variables Set
| Once the variables have been identified the test case can be further elaborated to explicitly define specific values for all of the variables involved in the test case. This level of detail for the variable values is often accompanied by an increased level of detail to describe general system interactions, navigational steps and expected results.
| ❑The preconditions have been defined.

❑All input, output and state variables have their values explicitly defined.

❑All scenario inputs, outputs, and state variables have been considered for inclusion as a test case variable.
|-
| 5
| style="font-weight: bold;" | Вариант тестирования описан или автоматизирован
| Scripted or Automated
| If a test case is to be used many times or to support many different tests, then it is worth making the effort to fully script or automate it. For a test case to be fully scripted and automatable it must contain no ambiguity. At this level of detail the test case is often documented as an automated testing script, one that can be interpreted and executed by an automated testing tool.
| ❑Test data is available.

❑All steps in the test case are defined and scripted.

❑There are no ambiguous instructions, navigational steps, input values or expected results.

❑The test case can be executed without any intervention or additional decision making.

❑If fully automated, an automated test script is available.
|}

[[Категория: Рабочие продукты]]

@@ Строка 12: / Строка 12: @@
 | 1
 | style="font-weight: bold;" | Идеи тестирования сформулированы (Test Ideas Formulated)
-| The lightest level of detail just captures the initial idea that will inform the test case. When defining a test case it needs to be clear what the idea behind the test case is, and which slice of the requirements it applies to. A test case can be considered as a question that you ask of the system. The point of running the test case is to gain information, for example whether the system works as specified or not. There has to be a reason for the creation of the test case. Some test cases exist to address specific project risks, whereas others are based upon experience, hunches, test results or test techniques used to methodically produce test cases. This reasoning can be summarized as the test idea behind the test case, and is the earliest form that a test case can take.
+| Самый легкий уровень детализации просто фиксирует начальную идею, которая будет положена в основу ВТ (здесь и далее - вариант тестирования). При определении ВТ необходимо четко понимать, какая идея лежит в его основе и к какому фрагменту требований он относится. ВТ можно рассматривать как вопрос, который вы задаете системе. Смысл запуска ВТ заключается в получении информации, например, о том, работает ли система в соответствии с требованиями или нет. Для создания ВТ должна быть причина. Некоторые ВТ существуют для устранения конкретных рисков проекта, в то время как другие основаны на опыте, догадках, результатах тестирования или методах тестирования, используемых для методичного создания ВТ. Это обоснование можно кратко назвать идеей теста, лежащей в основе ВТ, и это самая ранняя форма, которую может принять ВТ.
-| ❑The reason for the existence of the test case is clear.
+| ❑Причина для существования ВТ определена.
-❑The information to be revealed by the test case is clear.
+❑Информация, которая должна быть раскрыта ВТ, определена.
 |-
 | 2
 | style="font-weight: bold;" | Сценарий выбран (Scenario Chosen)
-| To make the test case executable the scenario to be performed needs to be selected. Once the scenario has been identified the test case is defined enough to support exploratory and investigative testing. This can be very useful early in the project lifecycle when the insight provided by testing the system is invaluable but the specification (and solution) may not be stable enough to support formal, scripted testing.
+| Чтобы сделать ВТ выполнимым, необходимо выбрать сценарий, который будет выполняться. После определения сценария ВТ достаточно определен для поддержки исследовательского и ознакомительного тестирования. Это может быть очень полезно на ранних этапах жизненного цикла проекта, когда понимание, которое дает тестирование системы, бесценно, но спецификация (и решение) может быть недостаточно стабильной для поддержки формального, сценарного тестирования.
-| ❑The scenario to be executed is clearly defined.
+| ❑Сценарий, который необходимо выполнить, четко определен.
-❑The start and end state for the scenario execution are defined.
+❑Начальное и конечное состояние для выполнения сценария определены.
 |-
 | 3
 | style="font-weight: bold;" | Переменные определены (Variables Identified)
-| A test case takes some inputs, manipulates system states, and produces some results. These appear as inputs, internal states and outputs in the requirements that the scenario covers. At this level of detail the acceptable ranges for the key variables involved in the scenario are explicitly identified. Use the inputs, outputs and internal states of the relevant requirements to identify suitable variables. This level of detail is suitable for those test cases where soliciting the opinion of the tester is an essential part of the test, for example when undertaking usability testing. It can also be used when more structure is needed for exploratory and investigative testing. Once identified the variables can be characterized and more detailed ranges of inputs and expected results specified.
+| ВТ принимает некоторые входные данные, манипулирует состояниями системы и выдает некоторые результаты. Они появляются как входы, внутренние состояния и выходы в требованиях, которые охватывает сценарий. На этом уровне детализации четко определены допустимые диапазоны для ключевых переменных, задействованных в сценарии. Используйте входы, выходы и внутренние состояния соответствующих требований для определения подходящих переменных. Этот уровень детализации подходит для тех ВТ, в которых выяснение мнения тестировщика является важной частью теста, например, при проведении тестирования удобства использования. Он также может быть использован, когда требуется более четкая структура для исследовательского и поискового тестирования. После определения переменных можно охарактеризовать их и определить более точно разброс входных данных и ожидаемых результатов.
-| ❑Relevant variables have been identified.
+| ❑Подходящие переменные определены.
-❑Acceptable ranges for the key variables are known.
+❑Приемлемые диапазоны для ключевых переменных известны.
 |-
 | 4
 | style="font-weight: bold;" | Переменные установлены (Variables Set)
-| Once the variables have been identified the test case can be further elaborated to explicitly define specific values for all of the variables involved in the test case. This level of detail for the variable values is often accompanied by an increased level of detail to describe general system interactions, navigational steps and expected results.
+| После определения переменных ВТ может быть доработан для явного определения конкретных значений для всех переменных, задействованных в ВТ. Такой уровень детализации значений переменных часто сопровождается повышенным уровнем детализации для описания общих взаимодействий системы, шагов навигации и ожидаемых результатов.
-| ❑The preconditions have been defined.
+| ❑Предварительные условия определены
-❑All input, output and state variables have their values explicitly defined.
+❑Все входные, выходные переменные и переменные состояния имеют свои значения, определенные в явном виде.
-❑All scenario inputs, outputs, and state variables have been considered for inclusion as a test case variable.
+❑Все входы, выходы и переменные состояния сценария были рассмотрены для включения в качестве переменной ВТ.
 |-
 | 5
 | style="font-weight: bold;" | Вариант тестирования описан или автоматизирован (Scripted or Automated)
-| If a test case is to be used many times or to support many different tests, then it is worth making the effort to fully script or automate it. For a test case to be fully scripted and automatable it must contain no ambiguity. At this level of detail the test case is often documented as an automated testing script, one that can be interpreted and executed by an automated testing tool.
+| Если ВТ будет использоваться много раз или поддерживать множество различных тестов, то стоит приложить усилия для его полной автоматизации. Чтобы ВТ был полностью автоматизирован, он не должен содержать неоднозначности. На этом уровне детализации ВТ часто документируется как сценарий автоматизированного тестирования, который может быть интерпретирован и выполнен инструментом автоматизированного тестирования.
-| ❑Test data is available.
+| ❑Имеются данные для теста.
-❑All steps in the test case are defined and scripted.
+❑Все шаги в ВТ определены и прописаны в сценарии.
-❑There are no ambiguous instructions, navigational steps, input values or expected results.
+❑Инструкции, переходы между шагами, входные значения или ожидаемые результаты однозначно определены.
-❑The test case can be executed without any intervention or additional decision making.
+❑ВТ может быть выполнен без какого-либо вмешательства или принятия дополнительных решений.
-❑If fully automated, an automated test script is available.
+❑При полной автоматизации доступен сценарий автоматизированного тестирования.
 |}
 [[Категория: Рабочие продукты]]

← Предыдущая		Версия 09:50, 15 декабря 2017
Строка 55:		Строка 55:

	[[Категория: Рабочие продукты]]		[[Категория: Рабочие продукты]]
		+	[[Категория: Недопереведенные статьи]]

@@ Строка 9: / Строка 9: @@
 ! style="text-align: center; font-weight: bold;" | Level of Detail
 ! style="text-align: center; font-weight: bold;" | Описание
-! style="text-align: center; font-weight: bold;" | Контрольные вопросы
+! style="text-align: center; font-weight: bold; width: 35%;" | Контрольные вопросы
 |-
 | 1