搜索标题
我的好友
音乐欣赏
统计信息
- 访问量: 603
- 日志数: 103
- 建立时间: 2007-09-12
- 更新时间: 2008-05-16
RSS订阅
我的最新日志
-
Dynamic testing
2008-5-16
Dynamic testing (or dynamic analysis) is a term used in software engineering to describe the testing of the dynamic behavīor of code. That is, dynamic analysis refers to the examination of the physical response from the system to variables that are not constant and change with time. In dynamic testing the software must actually be compiled and run; this is in contrast to static testing. Dynamic testing is the validation portion of Verification and Validation.
Some of dynamic testing methodologies include unit testing, integration testing, system testing and acceptance testing.
Dynamic Testing involves working with the software, giving input values and checking if the output is as expected. These are the Validation activities. Unit Tests, Integration Tests, System Tests and Acceptance Tests are few of the Dynamic Testing methodologies.
-
Boundary value analysis
2008-5-16
Boundary value analysis is a software testing design technique to determine test cases covering off-by-one errors. The boundaries of software component input ranges are areas of frequent problems.
Testing experience has shown that especially the boundaries of input ranges to a software component are liable to defects. A programmer implement e.g. the range 1 to 12 at an input, which e.g. stands for the month January to December in a date, has in his code a line checking for this range. This may look like:
if (month > 0 && month < 13)
But a common programming error may check a wrong range e.g. starting the range at 0 by writing:
if (month >= 0 && month < 13)
For more complex range checks in a program this may be a problem which is not so easily spotted as in the above simple example.
To set up boundary value analysis test cases you first have to determine which boundaries you have at the interface of a software component. This has to be done by applying the equivalence partitioning technique. Boundary value analysis and equivalence partitioning are inevitably linked together. For the example of the month in a date you would have the following partitions:
... -2 -1 0 1 .............. 12 13 14 15 ..... --------------|-------------------|--------------------- invalid partition 1 valid partition invalid partition 2
Applying boundary value analysis you have to select now a test case at each side of the boundary between two partitions. In the above example this would be 0 and 1 for the lower boundary as well as 12 and 13 for the upper boundary. Each of these pairs consists of a "clean" and a "dirty" test case. A "clean" test case should give you a valid operation result of your program. A "dirty" test case should lead to a correct and specified input error treatment such as the limiting of values, the usage of a substitute value, or in case of a program with a user interface, it has to lead to warning and request to enter correct data. The boundary value analysis can have 6 testcases.n, n-1,n+1 for the upper limit and n, n-1,n+1 for the lower limit.A further set of boundaries has to be considered when you set up your test cases. A solid testing strategy also has to consider the natural boundaries of the data types used in the program. If you are working with signed values this is especially the range around zero (-1, 0, +1). Similar to the typical range check faults, programmers tend to have weaknesses in their programs in this range. e.g. this could be a division by zero problem where a zero value may occur although the programmer always thought the range started at 1. It could be a sign problem when a value turns out to be negative in some rare cases, although the programmer always expected it to be positive. Even if this critical natural boundary is clearly within an equivalence partition it should lead to additional test cases checking the range around zero. A further natural boundary is the natural lower and upper limit of the data type itself. E.g. an unsigned 8-bit value has the range of 0 to 255. A good test strategy would also check how the program reacts at an input of -1 and 0 as well as 255 and 256.
The tendency is to relate boundary value analysis more to the so called black box testing ,which is strictly checking a software component at its interfaces, without consideration of internal structures of the software. But looking closer at the subject, there are cases where it applies also to white box testing.
After determining the necessary test cases with equivalence partitioning and subsequent boundary value analysis, it is necessary to define the combinations of the test cases when there are multiple inputs to a software component.
-
Equivalence partitioning
2008-5-16
Equivalence partitioning is a software testing related technique with the goal:
- To reduce the number of test cases to a necessary minimum.
- To select the right test cases to cover all possible scenarios.
Although in rare cases equivalence partitioning is also applied to outputs of a software component, typically it is applied to the inputs of a tested component. The equivalence partitions are usually derived from the specification of the component's behaviour. An input has certain ranges which are valid and other ranges which are invalid. This may be best explained at the following example of a function which has the pass parameter "month" of a date. The valid range for the month is 1 to 12, standing for January to December. This valid range is called a partition. In this example there are two further partitions of invalid ranges. The first invalid partition would be <= 0 and the second invalid partition would be >= 13.
... -2 -1 0 1 .............. 12 13 14 15 ..... --------------|-------------------|--------------------- invalid partition 1 valid partition invalid partition 2The testing theory related to equivalence partitioning says that only one test case of each partition is needed to evaluate the behaviour of the program for the related partition. In other words it is sufficient to select one test case out of each partition to check the behaviour of the program. To use more or even all test cases of a partition will not find new faults in the program. The values within one partition are considered to be "equivalent". Thus the number of test cases can be reduced considerably.
An additional effect by applying this technique is that you also find the so called "dirty" test cases. An inexperienced tester may be tempted to use as test cases the input data 1 to 12 for the month and forget to select some out of the invalid partitions. This would lead to a huge number of unnecessary test cases on the one hand, and a lack of test cases for the dirty ranges on the other hand.
The tendency is to relate equivalence partitioning to so called black box testing which is strictly checking a software component at its interface, without consideration of internal structures of the software. But having a closer look at the subject there are cases where it applies to white box testing as well. Imagine an interface to a component which has a valid range between 1 and 12 like in the example above. However internally the function may have a differentiation of values between 1 and 6 and the values between 7 and 12. Depending on the input value the software internally will run through different paths to perform slightly different actions. Regarding the input and output interfaces to the component this difference will not be noticed, however in your white-box testing you would like to make sure that both paths are examined. To achieve this it is necessary to introduce additional equivalence partitions which would not be needed for black-box testing. For this example this would be:
... -2 -1 0 1 ..... 6 7 ..... 12 13 14 15 ..... --------------|---------|----------|--------------------- invalid partition 1 P1 P2 invalid partition 2 valid partitionsTo check for the expected results you would need to evaluate some internal intermediate values rather than the output interface.
Equivalence partitioning is no stand alone method to determine test cases. It has to be supplemented by boundary value analysis. Having determined the partitions of possible inputs the method of boundary value analysis has to be applied to select the most effective test cases out of these partitions.
-
Data-driven testing
2008-5-15
Data-driven testing is a methodology used in Test automation where test scrīpts are executed and verified based on the data values stored in one or more central data sources or databases. These databases can range from datapools, ODBC sources, csv files, Excel files, DAO objects, ADO objects, etc. Data-driven testing is the establishment of several interacting test scrīpts together with their related data results in a framework used for the methodology. In this framework, variables are used for both input values and output verification values: navigation through the program, reading of the data sources, and logging of test status and information are all coded in the test scrīpt. Thus, the logic executed in the scrīpt is also dependant on the data values.
This is similar to Keyword-driven testing in that the test case is contained in the data values and not in the test scrīpt; the scrīpt is just a "driver" or delivery mechanism for the data. Unlike in keyword-driven testing, though, the navigation data isn't contained in the test scrīpt. In data-driven testing, only test data is contained in the data source.
-
Daily build
2008-5-15
A daily build is the practice of each day doing a software build of the latest version of a program. This is so it can first be compiled to ensure that all required dependencies are present, and possibly tested to show no bugs have been introduced. In this context a build is the result of compiling and linking all the files that make up a computer program. The use of such disciplined procedures as daily builds is particularly necessary in large organizations where many programmers are working on a single piece of software. Performing daily builds helps ensure that developers can work knowing with reasonable certainty that any new bugs that show up are a result of their own work done within the last day. Daily builds typically include a set of tests, sometimes called a smoke test ( as in where there is smoke there is fire). These tests are included to assist in determining what may have been broken by the changes included in the latest build. The critical piece of this process is to include new and revised tests as the project progresses.
-
Acceptance testing
2008-5-15
In engineering and its various subdisciplines, acceptance testing is black-box testing performed on a system (e.g. software, lots of manufactured mechanical parts, or batches of chemical products) prior to its delivery. In some engineering subdisciplines, it is known as functional testing, black-box testing, release acceptance, QA testing, application testing, confidence testing, final testing, validation testing, usability testing,, or factory acceptance testing.
In most environments, acceptance testing by the system provider is distinguished from acceptance testing by the customer (the user or client) prior to accepting transfer of ownership. In such environments, acceptance testing performed by the customer is known as beta testing, user acceptance testing (UAT), end user testing, site (acceptance) testing, or field (acceptance) testing.
Overview
Acceptance testing generally involves running a suite of tests on the completed system. Each individual test, known as a case, exercises a particular operating condition of the user's environment or feature of the system, and will result in a pass or fail boolean outcome. There is generally no degree of success or failure. The test environment is usually designed to be identical, or as close as possible, to the anticipated user's environment, including extremes of such. These test cases must each be accompanied by test case input data or a formal descrīption of the operational activities (or both) to be performed—intended to thoroughly exercise the specific case—and a formal descrīption of the expected results.
Process
The acceptance test suite is run against the supplied input data or using an acceptance test scrīpt to direct the testers. Then the results obtained are compared with the expected results. If there is a correct match for every case, the test suite is said to pass. If not, the system may either be rejected or accepted on conditions previously agreed between the sponsor and the manufacturer.
The objective is to provide confidence that the delivered system meets the business requirements of both sponsors and users. The acceptance phase may also act as the final quality gateway, where any quality defects not previously detected may be uncovered.
A principal purpose of acceptance testing is that, once completed successfully, and provided certain additional (contractually agreed) acceptance criteria are met, the sponsors will then sign off on the system as satisfying the contract (previously agreed between sponsor and manufacturer), and deliver final payment.
User acceptance testing
User Acceptance Testing (UAT) is a process to obtain confirmation by a Subject Matter Expert (SME), preferably the owner or client of the object under test, through trial or review, that the modification or addition meets mutually agreed-upon requirements. In software development, UAT is one of the final stages of a project and often occurs before a client or customer accepts the new system.
Users of the system perform these tests, which developers derive from the client's contract or the user requirements specification.
Test designers draw up formal tests and devise a range of severity levels. It is preferable that the designer of the user acceptance tests not be the creator of the formal integration and system test cases for the same system, however there are some situations where this may not be avoided. The UAT acts as a final verification of the required business function and proper functioning of the system, emulating real-world usage conditions on behalf of the paying client or a specific large customer. If the software works as intended and without issues during normal use, one can reasonably infer the same level of stability in production. These tests, which are usually performed by clients or end-users, are not usually focused on identifying simple problems such as spelling errors and cosmetic problems, nor show stopper bugs, such as software crashes; testers and developers previously identify and fix these issues during earlier unit testing, integration testing, and system testing phases.
The results of these tests give confidence to the clients as to how the system will perform in production. They may also be a legal or contractual requirement for acceptance of the system.
Acceptance Testing in Extreme Programming
Acceptance testing is a term used in agile software development methodologies, particularly Extreme Programming, referring to the functional testing of a user story by the software development team during the implementation phase.
The customer specifies scenarios to test when a user story has been correctly implemented. A story can have one or many acceptance tests, whatever it takes to ensure the functionality works. Acceptance tests are black box system tests. Each acceptance test represents some expected result from the system. Customers are responsible for verifying the correctness of the acceptance tests and reviewing test scores to decide which failed tests are of highest priority. Acceptance tests are also used as regression tests prior to a production release. A user story is not considered complete until it has passed its acceptance tests. This means that new acceptance tests must be created for each iteration or the development team will report zero progress.
-
深入浅出的英语口语400句（二）
2008-5-14
81. Enjoy yourself! 祝你玩得开心!
82. Excuse me，Sir． 先生，对不起。
83. Give me a hand! 帮帮我!
84. How's it going? 怎么样?
85. I have no idea． 我没有头绪。
86. I just made it! 我做到了!
87. I'll see to it 我会留意的。
88. I'm in a hurry! 我在赶时间!
89. It's her field． 这是她的本行。
90. It's up to you． 由你决定。
91. Just wonderful! 简直太棒了!
92. What about you? 你呢?
93. You owe me one．你欠我一个人情。
94. You're welcome． 不客气。
95. Any day will do． 哪一天都行。
96. Are you kidding? 你在开玩笑吧!
97. Congratulations! 祝贺你!
98. I can't help it. 我情不自禁。
99. I don't mean it. 我不是故意的。
100. I'll fix you Up． 我会帮你打点的。
101. It sounds great!． 听起来很不错。
102. It's a fine day。 今天是个好天。
103. So far，So good． 目前还不错。
104. What time is it? 几点了?
105. You can make it! 你能做到!
106. Control yourself! 克制一下!
107. He came by train． 他乘火车来。
108. He is ill in bed． 他卧病在床。
109. He lacks courage． 他缺乏勇气。
110. How's everything? 一切还好吧?
111. I have no choice． 我别无选择。
112. I like ice-cream． 我喜欢吃冰淇淋。
113. I love this game． 我钟爱这项运动。
114. I'll try my best． 我尽力而为。
115. I'm on your side． 我全力支持你。
116. Long time no see! 好久不见!
117. No pain，no gain． 不劳无获。
118. Well，it depends. 噢，这得看情况。
119. We're all for it． 我们全都同意。
120. What a good deal! 真便宜!
121. What should I do? 我该怎么办？
122. You asked for it! 你自讨苦吃!
123. You have my word． 我保证。
124. Believe it or not! 信不信由你!
125. Don't count on me．别指望我。
126. Don't fall for it! 别上当!
127. Don't let me down． 别让我失望。
128. Easy come easy go． 来得容易，去得快。
129. I beg your pardon． 请你原谅。
130. I beg your pardon? 请您再说一遍(我没有听清)。
131. I'll be back soon． 我马上回来。
132. I'll check it out． 我去查查看。
133. It’s a long story． 说来话长。
134. It’s Sunday today． 今天是星期天。
135. Just wait and see! 等着瞧!
136. Make up your mind． 做个决定吧。
137. That's all I need． 我就要这些。
138. The view is great． 景色多么漂亮!
139. The wall has ears． 隔墙有耳。
140. There comes a bus． 汽车来了。
141. What day is today? 今天星期几?
142. What do you think? 你怎么认为？
143. Who told you that? 谁告诉你的?
144. Who's kicking off? 现在是谁在开球?
145. Yes，I suppose so． 是的，我也这么认为。
146. You can't miss it. 你一定能找到的。
147. Any messages for me? 有我的留言吗?
148. Don't be so modest． 别谦虚了。
149. Don't give me that! 少来这套!
150. He is a smart boy． 他是个小机灵鬼。
151. He is just a child． 他只是个孩子。
152. I can't follow you． 我不懂你说的。
153. I felt sort of ill. 我感觉有点不适。
154. I have a good idea! 我有一个好主意。
155. It is growing cool． 天气渐渐凉爽起来。
156. It seems all right． 看来这没问题。
157. It's going too far． 太离谱了。
158. May I use your pen? 我可以用你的笔吗?
159. She had a bad cold． 她患了重感冒。
160. That's a good idea． 这个主意真不错。
-
深入浅出的英语口语400句（一）
2008-5-14
1. I see． 我明白了。
2. I quit! 我不干了!
3. Let go! 放手!
4. Me too． 我也是。
5. My god! 天哪!
6. No way! 不行!
7. Come on． 来吧(赶快)
8. Hold on． 等一等。
9. I agree。 我同意。
10. Not bad． 还不错。
11. Not yet． 还没。
12. See you． 再见。
13. Shut up! 闭嘴!
14. So long． 再见。
15. Why not? 好呀! (为什么不呢?)
16. Allow me． 让我来。
17. Be quiet! 安静点!
18. Cheer up! 振作起来!
19. Good job! 做得好!
20. Have fun! 玩得开心!
21. How much? 多少钱?
22. I'm full． 我饱了。
23. I'm home． 我回来了。
24. I'm lost． 我迷路了。
25. My treat． 我请客。
26. So do I． 我也一样。
27. This way。 这边请。
28. After you． 您先。
29. Bless you! 祝福你!
30. Follow me． 跟我来。
31. Forget it! 休想! (算了!)
32. Good luck! 祝好运!
33. I decline! 我拒绝!
34. I promise． 我保证。
35. Of course! 当然了!
36. Slow down! 慢点!
37. Take care! 保重!
38. They hurt． (伤口)疼。
39. Try again． 再试试。
40. Watch out! 当心。
41. What's up? 有什么事吗?
42. Be careful! 注意!
43. Bottoms up! 干杯(见底)!
44. Don't move! 不许动!
45. Guess what? 猜猜看?
46. I doubt it 我怀疑。
47. I think so． 我也这么想。
48. I'm single． 我是单身贵族。
49. Keep it up! 坚持下去!
50. Let me see．让我想想。
51. Never mind．不要紧。
52. No problem! 没问题!
53. That's all! 就这样!
54. Time is up． 时间快到了。
55. What's new? 有什么新鲜事吗?
56. Count me on 算上我。
57. Don't worry． 别担心。
58. Feel better? 好点了吗?
59. I love you! 我爱你!
60. I'm his fan。 我是他的影迷。
61. Is it yours? 这是你的吗?
62. That's neat． 这很好。
63. Are you sure? 你肯定吗?
64. Do l have to 非做不可吗?
65. He is my age． 他和我同岁。
66. Here you are． 给你。
67. No one knows . 没有人知道。
68. Take it easy． 别紧张。
69. What a pity! 太遗憾了!
70. Any thing else? 还要别的吗?
71. To be careful! 一定要小心!
72. Do me a favor? 帮个忙，好吗?
73. Help yourself． 别客气。
74. I'm on a diet． 我在节食。
75. Keep in Touch． 保持联络。
76. Time is money． 时间就是金钱。
77. Who's calling? 是哪一位?
78. You did right． 你做得对。
79. You set me up! 你出卖我!
80. Can I help you? 我能帮你吗?
-
"打岔"、"插嘴"的十句话
2008-5-14
1. I'm sorry to interrupt your conversation, but I've got something urgent to tell you.
抱歉打断你们的谈话，但我有急事要告诉你。
2. Sorry to butt in.
抱歉，打岔一下。
3. I'm sorry to barge in like this, but I need your help with a problem.
很抱歉这样打断你们，但我需要你帮我解决一个问题。
4. Wait, can I put in a word here?
等一下，我可以插句话吗？
5. Can I say something?
我可以说句话吗？
6. She kept cutting in when I was making my point.
我表示意见的时候她一直打断我的话。
7. He chipped in when I was about to answer his question.
我正准备回答他问题的时候，他就打断我的话。
8. He always breaks in on our discussions.
他老是打断我们的讨论。
9. My boss got really mad when his secretary chimed in during the meeting.
我老板的秘书在开会的时候插嘴，把他弄得很火大。
10. It's very impolite to interpose in such a formal seminar.
在这么正式的研讨会里插嘴是很不礼貌的。 -
关于“特价”的几种说法
2008-5-14
special offer:特供，特价
reduced price:减价，削价
reduced to clear:削价处理
close-down sale:（店关闭前的）大甩卖
all stocks must go:大清仓
by-one-get-one-free:买一送一
30% extra free:加送30%（重量）
discount:折扣
10% off:九折
factory outlet:工厂削价产品