Вариант тестирования

Версия от 02:50, 15 декабря 2017; Admin (обсуждение | вклад)

(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)

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

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

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

Уровень проработки Описание Контрольные вопросы
1 Идеи тестирования сформулированы (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 Сценарий выбран (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 Переменные определены (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 Переменные установлены (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 Вариант тестирования описан или автоматизирован (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.