四处找的文章之Q-Patterns

（说明，读了这篇文章，对于Q-Patterns只有一个大致的了解，即：将所有可能遇到的问题进行归类×××的一种方法，这种方法的好处是～～～）
Q-Patterns
What are Q-Patterns?
1. Q-Patterns are a set ofinterrelated questions（具体来说，interrelated questions 包含有哪些内容？）, grouped together.
2.These Questions（即指：interrelated questions）relate tosome aspect of user/software requirements（晕！）
3. They try to provide you with various alternatives which could be
used to provide a solution. For your needs either you could pick up a
solution from the questions OR based on the solution, pick up
required review comments, test cases etc. THUS you get a good set of
PRE-COOKED, pre-though out review comments, design strategies and
test cases etc.
4. You can add to the existing Q-Patterns to enhance them or create
new ones, based on your own experiences, needs etc.（开源的？在网络上共享？）
5. They follow a format different from GOF patterns（什么是GPF patterns?） but that may change. We have to think on this aspect and come up with a template generic enough to be useful to all types of Q-Patterns.


Understanding Q-Patterns by the help of an example

Password management

Passwords are used for security almost everywhere. But probably the
policies are not implemented in a similar manner by all. Even the
same company has two different policies of handling password in two
different products.

Some questions (without any attempt to categorize them...) that can
be asked are...

1. How many characters can the password accept? What are the maximum and the minimum number of characters?
2. What is the policy on password strength
 2.1 It should contain some minimum numbers of numeric characters
 2.2 It should contain some minimum number of characters long
3. Does the Password expire in X number of days? If yes then can the
user set the value of X?
4. Does the administrator have control over whose password does not
expire?
5. When the password is changed after expiry can it be reset to the
same password again? Or last N number of password can not be used?
6. Display: When password is typed (Either for login OR for first
time entry/changing) is password displayed in clear text or as some
other common character as * etc.? Or is it invisible?
7. When the password is shown as * to the user say, for changing, how
many characters are displayed? As many as the length of password OR a
fixed number of characters? Example: In Windows NT open control
panel/services. The password with which a service is running is
displayed as a fixed number of *s as compared to say Microsoft word's
password storage mechanism for protecting a document.
...
Some of these questions may have already been answered in the
specifications, but the chances are that there will be many unanswered
questions. If we could provide some structure to these questions which would help us categorize these questions, could provide us with framework where many more questions come to your mind naturally, it would enable us to write more complete test cases.


It is also amply evident from the questions that we are not trying to force a particular line of thought hence our Q-Patterns, based on these questions, will not be rigid depending on a particular implementation.Most important is the fact that we are not assuming any implementation. We are simply asking relevant questions. And these questions can help at the time of reviews or writing specs/design/test cases.(hence: [ hens ]
ad. 今后,从此,因此,所以
例句与用法:
1. We have no chance to meet each other a week hence.
我们今后一星期没有见面的机会了。
2. I fell off my bike yesterday hence the bruises.
我昨天骑自行车摔倒了--所以青一块、 紫一块的.
3. Handmade and hence expensive.
手工制造，因此很贵
4. A year hence it will be forgotten.
今后将被遗忘的一年 英英解释:副词hence:1. (used to introduce a logical conclusion) from that fact or reason or as a result同义词：therefore, thence, thus2. from this place3. from this time)
Q-Patterns FAQ
Q1. Why is a structure required for describing a Q-Pattern?
A structure is required to effectively capture the information in
represented in a UNIFORM manner for ease of RECORDING and SHARING.
Structure also promotes structured thoughts. At the same time a
structure also poses some restrictions and a possibility of stunting
the growth of new thoughts. A conscious effort may be required to
think "outside the box." This effort may not only help in bringing to
light new ideas but also in improving the structure.

Q2. What structure could possibly exist for Q-Patterns, since they
can be of
1. Different granularity
2. Different domains
3. Different concepts etc.

It is indeed very difficult to come up with a general structure that
fits all. The structure that I am proposing may be valid for the type
of Q-Patterns I have in mind. It may also be valid for some other
domains/concepts however, there is no guarantee. At best this is a
tentative format that I am proposing and this is likely to undergo
changes.

Q3. Why can we not use the existing GOF structure
A GOF Patterns typically has the following structure

Name: A single word or short phrase
Problem: A statement of the problem
Context: The environment where/for-which the problem has been
identified and a solution required.
Forces: Various conditions and constraints that influence the
solution.
Solution
Examples
Related Patterns
Known Uses
etc...

(For details you may refer to the Design Patterns book and also this
link http://www.hillside.net/patterns/patterns.html)

We use part of this structure.

Q4. What is the proposed format?
I propose the following format for documenting Q-Patterns

1. Name of the pattern
2. Intent/Explanation/definition
3. Questions related to:
a. Administration
b. Usage/User
c. UI
d. Security
e. Performance
i. Response Time (Fetch, insert/delete/update, Display)
ii. Concurrency
iii. Max and Min parameters (Data size etc.)
iv. Memory requirement
v. Disk Space
4. Examples
5. Associated patterns: Some times some Q-Patterns collaborate
together and these collaborating patterns should be preferably looked
at when looking at a given pattern.

6. Specialization: If the given patterns can be specialized, with
extra, context specific questions added and some specific questions
removed then that patterns can be called as "specialized pattern."
These patterns are specific to the given context.

We do not have
(a) Forces
(b) solution
as part of our template/structure because our questions indicate the forces and to
provide a solution is not the aim of Q-Patterns. To ask questions and
to enable one to choose to answer some of them is the intent.


Q5. What issues do you see with this structure?
I am not entirely satisfied with this structure. The reasons are
(a) Possibility of unwieldy collection of questions.
(b) Possibility of duplicating the questions in various
related/unrelated patterns
(c) Ambiguity in some heads/sections which makes it difficult to
place some questions in correct section.
(d) All the sections described in the proposed structure may not be
universally applicable.


Q6. What improvements can be made to the existing structure?
Some things that I have in mind are
1. Versioning the patterns: It is required for sharing the patterns
unambiguously.
2. Use of OO techniques like encapsulation and inheritance to take
care of some issues. This will give us a more robust and intuitive
structure for referencing other Q-Patterns.
3. Some classification of various Q-Patterns as Organizational Q-
Patterns, Design Q-Patterns, System Testing Q-Patterns etc.

Example of a Q-Pattern（看到这里似乎就清楚了些，但仅仅是“似乎”～）
Example: An incomplete example of a Q-Pattern is given here. I have not completed writing all questions yet :-)

NAME
Password Management

INTENT
The most general and common approach to authenticate a system or user is asking for a Password. Password authentication can be at different levels like user level, group level etc or at different stages like Operating System authentication, Application authentication etc.

QUESTIONS
If you are using Password authentication anywhere in your
spec/design/code/test you may ask following questions:

Administration
1. Can administrator reset the password?
2. Can administrator's password be reset?
3. What happens If the administrator forgets his password (any
default password is given or reinstallation would take place)?
4. Can administrator set the default password?
5. Can another administrator reset an administrator's password?
6. Can an administrator read the password of a user?

Usage
1. What's the maximum and minimum length of password?
2. Can we enter numbers in password?
3. Can blank password be used?
4. Where are passwords stored?
5. What is the default password (If any)?
6. Can one customize the default password?
7. Can Special characters (like #,$,ç,è,Þ,ß) be used
in password?
8. How is password change affected? Is original password required
before change password is allowed?
9. Is Confirm password used?
10. Is `Save Password' facility is there on the screen (so
that
user may not need to enter password every time she logs in)?

UI
11. Is password shown as stars (at the time of entering the
password, at the time of changing or resetting the password etc.)?
12. How many stars are shown for a password
• When it is being entered?
• When it is to be changed? (Note: Do not show same number of
stars as the number of characters.)

Security
1. How are passwords stored? Are they encrypted before storing? If
yes what is the encryption algorithm used?
2. Whether the password is case sensitive or not?
3. Whether the password can be cut and pasted?
4. Can a previously used password be used again? If `Yes'
then after how many changes?
5. Is there any expiry time for the password? What happens after
the date if user does not change the password during that period?
6. Is there any policy to count the number of password validations
in succession (e.g.. If user enters wrong password 4 times then she
is not able to enter password again in succession).
7. If application creates logs of all activities, then the logs of
password are created or not?
8. If logs of password are being made then the password is stored
in encrypted form or not?

Performance
1. Whether password is made up of single-byte characters (even if
multi-byte character set is being used in the application).
2. How much time will it take to authenticate the user after the
submission of password?
3. What is the maximum space required to store a password? Will
all the passwords require same space irrespective of size?
4. If wrong password is given, how much time will it take to give
the error message?
5. How many users can be authenticated at the same time?

Example: Various login screens and mechanisms (web based mail
systems, console based login etc.)
Associated patterns: Access Rights, Error messages
Specialization: Say, login for any particular web based mail system.
You can prune the question list to suite your needs, add more
questions to the specialized list OR enhance the parent Q-Pattern.


The Q-Pattern presented here is a simple one. Once we move to more
complex Q-Patterns and develop a web of collaborating Q-Patterns, the
whole concept will (hopefully) acquire a new and increased relevance
and usefulness.

文章来源http://www.whatistesting.com/qpatterns/qpatternintro.htm