Как я иду о создании плана тестирования относительно нашего отдела QA?

Question

Как я иду о создании плана тестирования относительно нашего отдела QA?

void Marix::setRowXColumn(int row,int column). Это должно Матрица. Используете ли вы IDE, она должна предупредить вас об этих опечатках.
setRowXColumn(int row,int column) должно быть setRowXColumn(row,column);
для c ++ всегда требуется символ ";" в конце.
double A[row][column];, если вы пытались создать «динамический массив», сделайте это так double **A;. и
```
    A = new double*[row];

    for(int i = 0; i < row; i++){
        A[i] = new double[column];
    }
```
в вашем конструкторе, затем удалите его в своем деконструкторе.

Я думаю, что в этом случае вы можете использовать вектор вместо массива.

14

testing qa software-quality

задан jsight 29 April 2009 в 16:39

6 ответов

Другие вопросы по тегам:

testing qa software-quality

Похожие вопросы:

score 4 · Answer 1

И давайте не будем забывать, что никогда не будет достаточно времени, чтобы выполнить все тесты, которые вы хотите сделать. Таким образом, тесты в вашем плане должны быть приоритетными. Я часто нахожу, что расставлять приоритеты по риску - лучший путь.

Однако, обычно группа тестирования разрабатывает план тестирования в координации с dev и PM. Если QA не создает план самостоятельно, похоже, ваша команда QA может использовать обновление. По крайней мере, даже если dev разрабатывает первоначальный план, QA должен предоставить некоторую информацию, поскольку у них будет другой POV. Чем больше внимания будет уделено плану тестирования, тем более полным он будет.

score 10 · Answer 2

The best book I've found on the subject is Managing the Testing Process. The author goes into how to create a test plan.

In my experience, the basics of a test plan are as follows:

Feature Description
Assumptions
Related Documentation
Test Matrix
Valid tests
Invalid/Error Condition tests
State Tests (behavior is based on various states of the object/system)
Stress Tests
Performance Tests
Performance Metrics
Required tools
Environmental concerns (specific hardware, browser, OS, etc.)

If you can fill that out, the team should be able to carry out testing pretty well.

One decision you need to make is how capable is the test team? I prefer a test plan to be an algorithm to derive all of the test cases. Describe the sorts of cases, but not necessarily each case in detail. If the team is less competent, you may need to spell out each case specifically.

One final caution. Avoid the siren's call of being too detailed. A plan that cannot be kept in someone's head is not likely to be followed. If your test plan is 25 pages long, you probably wrote too much.

score 0 · Answer 3

Try: Artifact: Test Plan

0

ответ дан 1 December 2019 в 14:22

score 0 · Answer 4

QA обязательно должен написать план тестирования, как указывает Том Э. Они должны взаимодействовать с заказчиком, чтобы понять требования, и с командой разработчиков, чтобы понять реализацию, но, в конце концов, команда с мышлением о тестировании должна владеть планом тестирования.

Единственная ситуация, которую я могу придумать, где может потребоваться составить план тестирования для команда QA - это когда у вас есть внештатная команда, выполняющая QA, но еще не знакомая с вашим продуктом. В этом случае я бы рекомендовал, чтобы один или два старших члена команды находились рядом с вами во время проектирования и разработки; это помогает им набирать скорость намного быстрее, и они могут передать эти знания остальной команде.

score -1 · Answer 5

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

Как только вы знать, что функция должна делать и как узнать, работает она или нет, автоматизируйте этот тест (где, очевидно, это имеет смысл), используя что-то вроде TestComplete , SmarteScript . Эти тесты легко запускать и автоматизировать, поэтому они всегда будут работать стабильно, не беспокоясь о том, что что-нибудь проскользнет сквозь трещины.

score 1 · Answer 6

эй, павлики, я не знаю, насколько базовым он вам нужен, но если вы хотите что-то простое и легкое для освоения и работы, взгляните на эту статью: Writing a System Test Plans

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

что касается очень базового, общего протокола регистрации ошибок, вы можете взглянуть на: Logging Bugs Like a Pro <- это все о регистрации ошибок с минимальными усилиями и захвате голой информации, необходимой для расследования ошибки

-- LM