How are you enjoying Beijing?

　　你在北京感觉怎么样？

　　A   Hello, Neil.  How are you enjoying Beijing?

　　A   尼尔，你好。你在北京感觉怎么样？

　　B   Hi, Yan.  It's very good.  Theres so much to see and do.

　　B   嗨，燕。非常好。在北京有那么多要看的东西和要做的事。

　　A   Have you been shopping yet?

　　A   你去购物了吗？

　　B   No.  I've been too busy seeing other things, like the Forbidden City.

　　B   还没有。我一直忙于看别的东西，比如故宫。

　　A   I can show you the shops on Wangfujing Street.

　　A   我可以带你去看王府井大街上的商店。

　　B   That would be nice.  I'd like that.

　　B   那太好了。我很愿意。

　　注释   Notes

　　If you want to ask someone how they are enjoying something, you can say: How are you enjoying...?

　　如果你想问某人做某事是否愉快，你可以说：How are you enjoying...？（做……你感觉如何？）。

　　If you want to ask someone if they have done something yet, you can say: Have you been shopping yet?

　　如果你想问某人是否已经做了某事，你可以说：Have you been shopping yet？（你去购物了吗？）

　　If you want to emphasise something, you can use the word too. For example, I've been too busy.

　　如果你想强调某事，你可以用too(太)这个词。例如：I've been too busy(我太忙了)。

　　You can offer to show someone something by saying: I can show you the shops on Wangfujing Street.

　　当你主动提出带某人看某物时可以这样说：I can show you the shops on Wangfujing Street(我可以带你逛王府井大街上的商店)。

　　A polite response to an offer like this is: That would be nice. Id like that.

　　对于别人的主动帮助，你可以这样回答：That would be nice(那太好了)。I'd like that(我很愿意)。

　　重要的短语和句子   Key phrases & sentences

　　How are you enjoying Beijing?   你在北京觉得怎么样？

　　There's so much to see and do. 有很多要看的东西和要做的事情。

　　Have you been shopping yet?     你已经去购物了吗？

　　I've been too busy.            我一直很忙。

　　I can show you the shops.       我可以带你去看商店。

　　That would be nice.             那太好了。

　　I'd like that.                 我很愿意。

I'd like a change of career.

　　我想变换一下工作。

　　A I work in a government office. It's a good job but not very exciting.

　　A 我在政府部门工作。这是一份不错的工作，但是不是特别有意思。

　　B I know what you mean. Some jobs are more interesting than others.

　　B 我明白你的意思。 一些工作有意思，另外一些工作不太有意思。

　　A Yes. It's not boring – it's just that I'd like a change.

　　A 是的。我的工作并不是无聊——只是我想变换一下。

　　B Maybe you should look for a new job and start a new career.

　　B 也许你应该找份新工作，开创新的事业。

　　There are different ways to describe your work or your job:

　　描述你的工作有不同的方法：

I love my work: it's really exciting.
My job is quite boring.

The pay is good.

Every day is different in my work.
我喜欢我的工作，它非常有意思。

我的工作很无聊。

工资不错。

我的工作内容每天都不一样。

（一）
A: Stone Corp. Hi, Mary speaking. 隐四通公司, 您好，我是Mary。
B: Hello, I’d like to speak to Mr. Hunter, please. 你好，我想找Hunter先生。
A: May I ask who is calling, please? 请问您是哪位？
B: My name is Herbert Wood of IBM Computer Company. 我是IBM电脑公司的Herbert Wood.
A: Thank you, Mr. Wood. One moment, please… (into PBX) Mr. Hunter, Mr. Wood of IBM Computer Company is on the line. 谢谢，Wood先生，请稍等。（打内线电话）Hunter先生，IBM电脑公司的Wood先生找您。
C: Can you find out what he wants? 你可以问他有什么事吗？
A: Yes, Mr. Hunter. (to caller) I’m sorry to have kept you waiting, Mr. Wood. Mr. Hunter is rather busy right now and would like to know what you wish to speak to him about.
　好的，Hunter先生。（对来电者说）对不起Wood先生，让您久等了。Hunter先生现在非常忙，他想知道你有什么事对他说。
B: Yes, I want to buy some computer software and talk about developing some other software. I don’t know whether he is interested in that or not? 是的，我想买一些计算机软件，另外再谈一谈开发一些其它的软件。我不知道他是否有兴趣。
A: I see. Thank you very much, Mr. Wood. Would you wait a moment, please? (to PBX) Mr Hunter, Mr. Wood wants to buy some computer software.
　我明白了，非常感谢，Wood先生。请你等一下好吗？（打内线电话）Hunter先生，Wood先生想买一些计算机软件。
C: I see. Put him on line two.　 好的，请转到2号线。
A: Yes, Mr. Hunter. (To caller) Mr. Wood, I’m very sorry to have kept you waiting. I’ll put you through to Mr. Hunter.　
　好的，Hunter先生。（对来电者）Wood先生，不好意思让你久等了，我把你的电话接给Hunter先生。
A: Good afternoon, Sales Department. May I help you? 下午好，销售部，我能帮你什么忙吗？
B: Could I speak to Mr. Bush, please? 可以和Bush先生说话吗？
A: I’ll see if he is available. Who shall I say is calling, please? 我要看一看他是否在。请问我得告诉他谁打来的？
B: John Smith.
A: Hold the line, please. Mr. Bush is in a meeting with the Managing Director at the moment, I’m afraid. Can I help you?
请别挂机，Bush先生正在和总经理开会，我可以帮你忙吗？
B: Well, I want to discuss with him the new contract we signed last week. 好的，我想跟他讨论一下我们上星期签订的合同。
A: I don’t think the meeting will go on much longer. Shall I ask him to call you when he is free? 我想会议不会开得太久，我让他有空给你打电话，好吗？
B: Yes, that would be easiest. 是的，那样最好了。
A: Could I have your name again, please? 请再一次告诉我你的姓名，好吗？
B: Yes. It’s John Smith.好的，我叫John Smith。

二

A: And the number? 电话号码呢？
B: 021-64358796
A: OK. You’ll be hearing from Mr. Bush later in the morning then, Mr. Smith.
好的，Smith先生，早上晚些时候，你会收到Bush先生的电话。
B: Thank you for your help. Good-bye. 谢谢你的帮助，再见。
A: You are welcome. Good-bye. 别客气，再见。
A: Madison Industries. This is Cathy Winer speaking. Can I help you? Madison工业，我是Cathy Winer, 我能帮您吗？
B: Good afternoon. Could you connect this call with Mr. Black, please? 下午好，麻烦你接到Black先生，好吗？
A: May I know who’s calling? 请问您是哪位？
B: This is Mary Fox of A.B.C. Computer Co…I’m calling on behalf of Mr. Tom Backer, the general manager of our company. 这里是A.B.C电脑公司的Mary Fox. 我是替我们公司总经理Tom Backer先生打电话。
A: I am sorry, Ms. Fox. Mr. Black is now in a meeting. May I have your number and ask him to call back later?
　对不起，Fox小姐。Black先生正在开会，请告诉我你的电话号码，我会让他给你打电话的，好吗？
B: I’m afraid Mr. Baker would like to speak to Mr. Black right now. He has got an urgent matter to discuss with Mr. Black without delay.
　我想Baker先生想现在和Black先生说话，他有紧急事情与Black先生商量，不能拖延。
A: OK. Then, would you please hold the line? (one minute later) 好的，请你别挂机。（一分钟后）
Ms. Fox, the line is through. Mr. Black is ready to answer the call. Go ahead. Fox小姐，电话接通了，Black先生可以和你通话了，请吧。
B: Thank you for your kind assistance, Ms. Winer 非常感谢你的善意帮助，Winer小姐。
A: You are welcome. 别客气。
A: Good morning. NTT Co… 早上好，NTT公司。
B: Hello. May I speak to Mr. Ira Black, head of the Export Section, please? 你好，可以和出口部负责人Ira Black先生通话吗？
A: I’m sorry. Mr. Black has just gone out. May I ask who’s calling? 对不起，Black先生刚出去。可以问一下您是哪位吗？
B: This is John Carter from Ace Consultant. Would you please tell me when I could get a hold of him?
　我是Ace咨询公司的John Carter. 请你告诉我什么时候能找到他。
A: I really have no idea when Mr. Black could be available in the office. Could you call back later or would you mind leaving a message? 我真的一点都不知道Black先生什么时候会在办公室。您可以过一会儿再打来或者给他留言吗？
B: I think it’s better for me to leave a message. But it’s important and urgent. Please make sure he gets this message.
　我觉得还是留下一个口信比较好。不过这件事很要紧，请一定将留言传达给他。
A: I see. I’m sure to pass your messages to Mr. Black. 明白了，我一定把您的留言传达给Black先生。
B: Good. Would you mind telling him that due to some sudden changes, do not fill out any orders for NNC Corporation until further notice? It’s very important. I’ll explain later. 那就好，你可以告诉他，由于意外变化，在进一步通知之前，请勿给NNC公司发货。事关重大，稍后我会做出解释。
A: Okay, let me repeat your message to see if I’ve got it all. 行。我重复一遍留言，看看是否记全了。
作为职场中的一员，我们免不了要外出办公。为了使自己的工作更有效率，我们就需要提前和对方确定好相关事宜，这时，电话就发挥了相当重要的作用。通过电话还可以用它来解决当面不好说的许多问题呢！本期，我们就来学习一下如何用电话预约和解决问题。
（三）

OFFICE ASSISTANT: Good morning. Odyssey Promotions. How may I help you?
办公室文员: 早上好。这里是奥德赛企划公司。我能为您提供什么帮助吗？
NICK: Hello, this is Nick Delwin from Communicon. Could I speak to Helen Turner, please?
尼克: 你好，我是国际通讯公司的尼克·戴尔文。可以帮我转接海伦·特纳吗？
OFFICE ASSISTANT: Just a moment, please. 办公室文员: 请稍等。
OFFICE ASSISTANT: I have Nick Delwin on the line for you. 办公室文员: 有个叫尼克·戴尔文的人打来电话要找你。
HELEN: Thank you... Hi, Nick. Nice to hear from you. How’s the English weather?
海伦: 谢谢……你好，尼克。很高兴接到你的电话。英国那边的天气怎么样？
NICK: It’s pretty good for the time of year. What’s it like in New York? 尼克: 就今年这个时候来讲，还是相当不错的。纽约那边的天气呢？
HELEN: Not good, I’m afraid. 海伦: 恐怕不怎么样。
NICK: That’s a pity because I’m planning to come across next week.尼克:那真糟糕，因为我正打算下礼拜过去一趟。
HELEN: Really? Well, you’ll ②come by to see us while you’re here, I hope?
海伦: 真的吗？嗯，我希望你来的时候能顺便过来看看我们，可以吗？
NICK: That’s what I’m phoning about. I’ve got a meeting with a customer in Boston on Tuesday of next week. I was hoping we could arrange to ③meet up either before or after.
尼克: 这正是我打电话想要告诉你的事情。下礼拜二，我要在波士顿会见一个客户。我希望，在那之前或之后我们能找个时间见一下。
HELEN: Great. That would give us a chance to show you the convention centre, and we could also ④drop in at Caesar’s Restaurant where Gregg has arranged your reception.
海伦: 太好了。那样我们就有机会带领你参观一下会议中心了，而且我们还可以顺便去凯萨饭店，葛雷格已经在那里为你安排好了接待活动。
NICK: That’s what I was thinking. 尼克: 我也是这么想的。
HELEN: So you said you have to be in Boston on Tuesday? That’s the 8th? 海伦: 嗯，你说你要在礼拜二的时候到波士顿？那是8号吧？
NICK: That’s right. Now, I could ⑤stop over in New York either on the way in - that would be the Monday...Would that be possible? 尼克: 没错。那样的话，我也可以在去之前先去纽约一趟——可能是礼拜一的时候——那没问题吧？
HELEN: Ah, I’m afraid I won’t be in the office on Monday, and I think Gregg has meetings all day.
海伦: 啊，恐怕礼拜一的时候我不在办公室，而且我想葛雷格全天都在开会。
NICK: Uh-huh, well, the other possibility would be to arrange it after Boston on my way home.
尼克: 嗯嗯，好吧，那另一个可能就是在我从波士顿回来的时候再安排见一下了。
HELEN: When do you plan on leaving Boston? 海伦: 你打算什么时候离开波士顿？
NICK: Could be either Tuesday afternoon or Wednesday morning, but I would like to catch a flight back to London on Wednesday evening.可能是礼拜二下午，也可能是礼拜三上午，但我想赶在礼拜三晚上搭乘航班返回伦敦。
　HELEN: OK. Well, it would be best for us if you could fly in on the Wednesday morning. Either Gregg or I will pick you up at the airport, and then we could show you the convention centre and also Caesar’s. If there’s time, you could come back to the office and we’ll run through any of the details that still haven’t been finalized. 好。嗯，如果你能在礼拜三上午飞过来的话，那对我们来说最好不过了。葛雷格或者我可以去机场接你，之后，我们可以带你去参观会议中心和凯萨饭店。如果有时间的话，你可以再去一下我们的办公室，我们可以迅速处理一些还没有解决的细节问题。
　　NICK: That sounds good. Just as long as I can get back to the airport for my evening flight.
　　尼克: 听起来不错。只要我能赶回机场搭上我的夜班飞机就行。
　　HELEN: No problem. Look, why don’t you fax me your information once you’ve confirmed your flight times? Then we’ll get back to you with an itinerary for the day - that’s Wednesday the 9th, right?
　　海伦: 没问题。嗯，一旦你确定了你的航班日期，发个传真告诉我具体情况如何？那样我们就可以给你回复当天的日程安排——那天是9号礼拜三，对吧？
NICK: That’s right. Good, well, I’ll do that and I look forward to seeing you next week.
　　尼克: 没错。好，嗯，我会的，我期待着下礼拜和你们见面。
HELEN: Same here. See you next week. 海伦: 我也是。下礼拜见。

一、Don’t worry.别担心。（劝告对方别担忧）
　　a.—Is my illness serious？我的病严重吗？
　　—Don’t worry. You’ll be well soon.别担心，你很快就会好的。
　　b.—Can I pass the exam？我能通过这次考试吗？
　　—Don’t worry. I think you can.别担心，我认为你能通过。

　　二、Don’t be afraid.别担心。（劝告对方别担心）
　　a.—Will he agree to see me？他会同意见我吗？
　　—Don’t be afraid.别担心。
　　b.—Will the exam be very difficult？考试会很难吗？
　　—Don’t be afraid.别担心。

　　三、It’ll be OK/all right.行，没问题。（使对方放心）
　　a.—Will my plan work？我的计划会起作用吗？
　　—It’ll be OK/all right.没问题。
　　b.—Will the meeting succeed？会议会成功吗？
　　—It’ll be OK/all right.没问题。

　　四、It’s all right.没问题。（请对方宽心）
　　a.—Will you help me with my English？你会帮助我学英语吗？
　　—It’s all right.没问题。
　　b.—Will the car pass the test？汽车能通过检验吗？
　　—It’s all right.没问题。

 
　　五、Well done！干得不错！（肯定、鼓励对方工作）
　　a.—What do you think of my article？你认为我的文章怎么样？
　　—Well done.写得不错。
　　b.—Is my work OK？我的工作还行吗？
　　—Well done.干得不错。

　　六、You can do it！你肯定行！（肯定对方能力）
　　a.—I’m afraid I can’t pass the exam.恐怕这次考试我过不了关。
　　—You can do it！你肯定行！
　　b.—I wonder whether I can finish the task in time.我不知道是否能及时完成这项任务。
　　—You can do it！你肯定行！

　　七、Come on！别灰心。（劝告对方别灰心）
　　a.—I’m afraid I can’t succeed.恐怕我难以成功。
　　—Come on！别灰心。
　　b.—I’ll not learn English any longer. I can’t remember all these words.我不想学英语了，我记不住这么多单词。
　　—Come on！别灰心。

　　八、That’s better. Keep trying.有长进，继续努力。（肯定对方的进步）
　　a.—What do you think of my homework？你认为我的家庭作业做得怎么样？
　　—That’s better. Keep trying.有长进，继续努力。
　　b.—Is my composition still bad？我的作文还是不好吗？
　　—That’s better. Keep trying.有长进，继续努力。

   九、cheer up (振作起来)

   Cheer up! Things are not so bad as they seem. 振作起来！情况并不象看上去那样糟

   Cheer up! I'm sure you'll feel better tomorrow. 振作起来！我肯定你明天会好些的

   十、take it easy (别着急，慢慢来--当别人在处理某种事情有困难的时候，提醒别人要放松)

   I'm afraid I can't finish my homework in time. ---Take it easy.You can do it.

  

   Below is a list of suggestions (in no particular order) from people now in the field of QA that might help the new comers to this field get started working towards their career goals of Quality Assurance and testing. These can apply regardless of whether you use manual or automated tools. And thank you to all who contributed.
1. Things I have learned - Take a class in the programming language that you are testing. This will improve not only your skills, but your ability to communicate with the developers.

2. Always keep in mind that some of your best teachers are also your co-workers.

3. Keep your ears open about projects both new and in progress. Get to know the requirements of the project and what the expectations of the users are.

4. Establish a partnership relationship with your developers. Sit down and discuss mutual expectations.

5. Ask questions.

6. Be persistent.

7. Be precise. Whether you are reporting a defect or reporting a process improvement need, if you cannot precisely describe the problem and the impact, you won't get far.

8. Pick your battles. You cannot change everything at once. If you are trying to establish or improve your testing process or development process, do a thorough assessment of where you are and how you need to improve, and prioritize this list.

9. Pick some "low hanging fruit", document, implement, assess --- and hopefully as people begin to SEE the benefits, you'll win more converts. So your next process improvement attempt will go more smoothly.

10. Read recommended literature

11. Make sure everything you do gets reviewed by at least one experienced person (No matter how long I have been in this industry, I still follow this principle)
12. Don't be afraid to ask questions!!! I learned so much from the developers at my first company, it was unbelievable! And at a subsequent company, I got a developer to give QA a bit of a session on EJBs when they were still bleeding edge technology we were working with. If you ask, they will generally help - because it shows that you don't profess to know everything better than they do, which can be a misconception!

13. Keep up on new technology. Even if you're not using it now, you might be someday, so take the time to at least read up on the basics!

14. Look at joining a User's Group or QA group in your area, if one exists. The networking, venting, and communication are priceless!

15. Think about what you think might need to be checked.

16. Ask questions and be curious.

17. NEVER criticize the developers for defects.

18. Get a mentor. We all know how demanding QA and Test can be and having someone to bounce ideas and thoughts off is extremely useful. My own mentor was a very experienced QA/Test Manager who was extremely good and helped me enormously

19. Don't be afraid to ask for help and questions, find a mentor. We like to share our thoughts and knowledge. I worked for a larger company that had many different testing departments. One of the things we did was form a 'corporate' qa steering committee. This was a way to share ideas, network with others, and do some streamlining.......

  Although you have mentioned three areas in the software line of work, there are many more e.g. business analyst, system administrator etc. If the three choices offered by you are indicative, you should basically decide whether you should start in the development area or software testing area. Each area has tremendous potential. It really depends on you. If you introspect on the following, you should be able to estimate which area is more conducive to your success. In the event you are still unable to decide, you should aim to get exposure (experience) in both areas so that you can see things first hand.

1) Do you have in-depth knowledge of some technology (testers can manage their work without gaining in-depth knowledge of any development technology; though such knowledge is required while performing white box/ gray box testing or automation testing)?

2) Are you more of a problem solver or a problem finder (In development work, you will have to solve problem after problem; in testing you should have the knack of finding problems that others can then solve)?

3) Do you like to focus on one task or are you a multi-tasker (While performing development, you might have to stick with one task until it is completed; a tester might have many tasks e.g. creating test cases, performing testing, reporting test results to perform in a day)?

The skills/ abilities/ knowledge that are common to both areas are:
1) Being able to work successfully as part of a team as well as alone

2) Ability to work hard depending on the project demands

3) Knowledge of the process being followed (highly structured/ dynamic/ somewhere in between)

4) Domain knowledge of the industry you are working for helps

If you are able to make this critical decision, you will find the future of your chosen line quite bright

As a tester, much of my work is writing test cases and executing test case. But when I think the following questions, I am still confused:
(1)Why do we write test cases? Is this is a good way?
(2)What is a good test case?
(3)How to execute test cases efficiently?

Why do we write test cases?
(1) To make testing be a manageable activity.
It can provide good evidence when boss and client check the testing status.
(2) To validate the testing coverage of application. It's very good for regression testing
(3) It can record what tester understand the system functionality. Then if any new man come for testing, he can execute the test cases by reading step by step. This can ensure that everyone can do this testing.

 

Some people think that software testing is a low skill job, and that just any one can be a tester.  This is definitely not true.  Allow me to explain why.

If we represent the software being tested as a ball, then the aim of the software testing is to cover as much of the space of the ball as possible.

Test cases act together as a net, attempting to cover the ball.  Test cases act individually as a node in that net.  So the most important aspect of a test case is not its amount, but its structure.  The test case should cover the entire surface of the ball, but without too many nodes in any one place.

A well designed test case requires a deep understanding to the software, high ability of abstraction, and skills to balance between the coverage and testability.  The requirements are not that different from other forms of design work.

To continue the previous analogy, the actual test behavīor is like a piece of cloth wrapped around the node; there to fill spare space left by nodes.  How much space your real test behavīor can cover is one key standard to measure the capability of a tester.

Good testers test far more than the test case descrīption.  In fact, it’s an essential requirement.  They will extend the test case descrīption by changing parameters, adjusting preconditions, and using many different means in order to try to wrap more space around a single test case.

One investigation showed that over 3/4 of all bugs found, are not directly related to test case descrīptions.  That is to say, the number of bugs a good tester can find can be 4 times as many as that of a tester who simply follows the test case descrīption.

So the job of software testing may seem simple and straightforward enough, but the truth is, the actual effort expended is much greater than just a simple test case.

(Thanks to Kyle for fixing errors of the original version)

转：http://www.51testing.com/?764

I will soon be employing some new testers which made me think. What makes a good tester?What questions should be asked to determine how good the tester is?

There's the usual list of attention to detail, good communication skills blah blah blah but probably one of the main things I look for is an interest ( passion would be even better ) in testing

So I used to ask if they read any testing books, surfed any testing sites, what did they do to increase their testing skills and knowledge

____________________________________________

It totally depends upon what kind of profile you are looking for i.e. whether you are looking for experienced software tester or just fresh graduate. In the 30/60 minutes interview it is not completely possible to judge someone, whether he/she is suitable for this job. Here I am going to explain some hiring tips which might be help you.

For Experienced Software Tester
------------------------------------------------
1. Attitude.
2. Passion about software testing as Phil said.
3. Past experience:
- What kind of project he/she execute?
- What was his/her role in the project?
- How long he/she was involved in that project?
- What is his/her major contribution in the project?
- What he/she learned from the project?
- What is his/her contribution for the Team?
4. Why he/she is quiting his/her job? What drives him/her to take decision?
5. What is her/her objective in his/her testing career? Where he/she wants to be after 5/10 years?
6. Look into his/her analytical skills.

For fresh graduate
--------------------------
1. Attitude.
2. Passion about testing.
3. Analytical Skills

____________________________________________

In interviews I don't want people to draw me the v-model or tell me what SPACEDIRT stands for, it's not a memory test (I might ask a Junior though ;p ). I want then to tell me stories, I want to see them 'lost' in reflection, engaged in what they tell me and congruent in thier answers.

* "Tell me about a time when..." Ask them to recount testing challenges and any great success.

* Give me an example of when you were working on a test task that perhaps was hard but you also found was enjoyable, engaging.

* As testers it seems we always harp on about documentation, documents we should produce or we should have provided. Share with me your thoughts on that, based on your experience and perspectives.

* What is it about the testing profession that pulls you into work everyday?

What I'm looking for is a reflective, insightful answer, One where they tell you the point and then tell you how they felt, what they were thinking, how that connected with something else, how someone responded, what impact that had on people/organisation/project, how they were challenged, what they did to work with others, how that helped them grow and learn.

I've seen candidates look away into the middle distance or on the floor and keep talking in a fluid way that tells me they're really drawing out actual experience that they are engaged with.

A candidate who answers with "tricky projects... yeh, quite a few, but you have to be professional." type answers have already lost the role. Either because I don't believe them or they're not engaged and interested.

* Do you blog, write papers, visit forums, talk to other testers, go to SIGIST, etc?

Recently I met the situation when the bug was found by the end-user.Of course sometimes this can happen. In this case the programmers say that the application wasn't tested carefully enough. And testers say that they can't check the functionality without access to the source code and so on...
But in fact - who is to blame for that? Programmers or testers?
What do you think about it?

__________________________________________________________

To answer this I need to know so much more about the bug.
- Was it in an area included in your test coverage but missed by a test?
- Did you explicitly plan not to test that area?
- Was the product trialled, if so, how come it wasn't caught there?
- What severity was it? Showstoper, Major, Minor, Cosmetic?
- What circumstances does it happen under? Does it happen because of a conflict with a 3rd party app? Is it because of a certain type of hardware?
- Were you happy with the qualiy of the product when it was released? Was it released with known bugs?
- Would you have needed to spend a huge amount of time testing masses of combinations of factors to capture this bug?

There are many more questions I'm sure, but I think it's hugely important that we fully understand a defect, before looking at who might be to blame (if you work in that kind of culture) for it being missed.

 

 

 

 

 

It can be quite a promising job if you have the following traits:
1) You enjoy finding problems.
2) You have good communication skills.
3) You are able to handle and keep track of several things in a single day.
4) You work well independently as well as within a team and with other people.
5) You work well with both the details as well as the big picture.

 

1) Talk to developers and ask them what are vulnerable areas they would think?
2) Go through your bug tracking tool and identify the similar  functional areas bugs , you would get more ideas from the list.
3) Talk to your team and discuss about product and their ideas
4) Do exploratory testing with product

After executing the test cases we can report the defects to the
developement team,some of the defects were rejected by the developement team, so as a tester what we can do for that situations?

Thanks in advance.

---------------------------------------------------

 

Whether to reject defects should not be just a development decision. It should be a business decision. Are developers alone deciding what to fix and not fix? Neither developers or testers should make that decision alone.

so as a tester what we can do for that situations？We can become an advocate for the bugs we report and explain why the bug should be fixed in terms that matter to the business.
We can also try to understand the business reasons for not fixing a bug.

 

具有3-4年经验的测试工程师或程序员。帮助开发或维护测试或编程标准与过程，负责同级的评审，并为其它初级的测试工程师或程序员充当顾问。继续拓展编程语言、操作系统、网络与数据库方面的技能

测试组负责人

具有4-6年经验的测试工程师或程序员。负责管理1至3名测试工程师或程序员。担负一些进度安排和工作规模/成本估算职责。更集中于技能方面

测试/编程负责人

具有6-10年经验的测试工程师或程序员。负责管理8至10名技术人员。负责进度安排、工作规模/成本估算、按进度表和预算目标交付产品。负责开发项目的技术方法。为一些用户提供支持与演示。开发一些特定领域的技术专长

测试/质量保证/开发（项目）、经理

具有10多年的工作经验。管理8名或更多的人员参加的1个或多个项目。负责这一领域（测试/质量保证/开发）内的整个开发生存周期业务。为一些用户提供交互和大量演示。负责项目成本、进度安排、计划和人员分工

计划经理

LoadRunner 中的 Unique Number 参数类型（续）

 

取系统时间作为参数：

	场景一	场景二	场景三	场景四	场景五
迭代一	0.023591	0.017908	0.010141	0.02521	0.017241
迭代二	0.00989	0.010288	0.012148	0.009862	0.010312
迭代三	0.010657	0.009689	0.010065	0.009892	0.010261
迭代四	0.009867	0.010119	0.01023	0.010229	0.009717
迭代五	0.010608	0.010473	0.015352	0.010075	0.016587
消耗时 间总和	0.064613	0.058477	0.057936	0.065268	0.064118

  

从上面3个表格看，性能最好的要数Unique Number类型的参数方案，其次是取用系统时间作为参数，最后才是使用for循环。

 

尾声：

综上所述，当遇到对唯一性数据进行参数化时，使用Unique Number参数类型是一个不错的选择。本文档是在学习Unique Number类型的参数时整理的，或许上述的验证方式不够合理与完善，肯请各位看官给出宝贵的意见和建议，谢谢！

 

 

LoadRunner 中的 Unique Number 参数类型 （续）

 

验证：

现在就针对这几种参数处理方式的验证结果做一下阐述，Unique Number类型、for循环、用系统时间作为参数。

从便捷性方面看：

Unique Number类型的参数创建方式非常简单，只要选中需要参数化的值，右键Replace with a parameter，根据实际需要做相应的设置即可，便于记忆，易于维护。

For循环：需要编写代码，而且每次执行以后都要查找代码，重新修改循环变量的起始值，方便性可想而知。

用系统时间作为参数：也需要编写代码，而且必须使用lr_save_datetime()函数特有的格式，如果记忆不深刻的话，每次使用都需要查阅帮助，不是很方便。

从性能方面看：

为了查看这三种方式的性能，特地进行了如下试验：

1、                用Unique Number类型作为参数，在该实例中设置5次迭代，每一个场景执行完后取该场景中每次迭代的消耗时间，取时间之和。

2、                For循环处理参数，循环5次，取该循环总的消耗时间

3、                用系统时间作为参数，该实例的操作步骤同试验1。

上面3个场景，每个执行5次，取到的测试数据如下：

Unique Number类型参数

	场景一	场景二	场景三	场景四	场景五
迭代一	0.016507	0.022646	0.016263	0.02098	0.0128
迭代二	0.009697	0.008834	0.009304	0.013324	0.011806
迭代三	0.009392	0.009119	0.009371	0.009595	0.012904
迭代四	0.008781	0.009133	0.008802	0.009916	0.008767
迭代五	0.009046	0.0095	0.015279	0.00926	0.009376
消耗时 间总和	0.053423	0.059232	0.059019	0.063075	0.055653

 

For循环：

消耗时 间总和

0.076782

0.071071

0.085025

0.080379

0.077205

引言：

我们在测试过程中经常会遇到批量添加数据的情况，并且这些数据很多时候是具有唯一性的。

比如说当前项目中需要创建一个添加用户的脚本，这些用户都是唯一的，当时采取的是创建file类型的参数，将参数用excel拖曳下来（tester001-tester1000）保存成dat类型的文档，如果参数数量很小这种方案也还算切实可行，但是如果遇到成百上千万的数据，再用这种方式就非常的吃力，势必会浪费大量的人力物力，也就达不到节约资源、降低成本的目的。

再比如前段时间性能测试中就有一个对数据库的容量和处理能力的验证，主要是通过页面新建用户向数据库中添加数据。在这些需要添加的数据中，email字段要求必须是唯一的。因为需要插入大批量的数据，再使用上面的file类型的文件来参数化就非常困难了。当时的解决方案有两种：一种是使用for循环，再一种是用当前的系统时间，具体到时分秒作为参数处理。使用for循环，可能仅仅只有一个字段需要取唯一值，但是却要循环整个业务，这样势必造成资源的浪费，而且执行效率也不高，进而影响性能测试的准确性。

简介：

从引言中可以看到，参数的处理方式可以多种多样，今天主要介绍Unique Number类型的参数。参数的创建方式跟file类型的一样，在此就不多做赘述。下面主要结合场景看一下Unique Number参数类型的特性，该类型主要包括数据的范围(Number range)、示例(Sample value)、数据格式(Number format)、更新参数的方式(Update value on)、异常情况下的处理(When out of values)。

     （------图片稍候上传------）

如上图设置，就表示从001开始取值，每个用户有5个值，按照迭代的方式更新参数，如果参数不够就从第一个值（001）开始取：

如果有5个用户并发，每个用户迭代10次，第一个用户取值为001、002、003、004、005、001、002、003、004、005，第二个用户为006、007、008、009、010、006、007、008、009、010，以此类推，具体可根据实例在场景中执行查看。

实例：

Unique Number参数类型实例：

/*************************************************

 * 用Unique Number类型对唯一性的数据进行参数化，

 * 并且计算该方法所耗费的时间                                      

**************************************************/

Action()

{

    double time_elapsed;

    merc_timer_handle_t timer;

    char fullname[1024] =  "tester";

 

    timer = lr_start_timer();

 

    strcat(fullname,lr_eval_string("{memberID}"));

    lr_log_message("The running username is --- %s:",fullname);

 

    time_elapsed = lr_end_timer(timer);

    lr_log_message("===%lf===",time_elapsed);

 

    lr_log_message("memberID:%s",lr_eval_string("{memberID}"));

    return 0;

}

For循环实例：

/***********************************************

 * 用for循环对唯一性的数据进行参数化，

 * 并且计算该方法所耗费的时间                                      

************************************************/

Action()

{

    double time_elapsed;

    merc_timer_handle_t timer;

    char fullname[1024] =  "tester";

    char str[10];

    int i;

 

    timer = lr_start_timer();

 

    for(i=0;i<5;i++){

       itoa(i,str,10);

        strcat(fullname,str);

        lr_log_message("The running username is --- %s:",fullname);

        strcpy(fullname,"tester");

    }

 

    time_elapsed = lr_end_timer(timer);

    lr_log_message("===%lf===",time_elapsed);

 

    return 0;

}

取系统时间作为参数的实例：

/********************************************

 * 取系统时间对唯一性的数据进行参数化，

 * 并且计算该方法所耗费的时间                                      

*********************************************/

Action()

{

    double time_elapsed;

    merc_timer_handle_t timer;

    char fullname[1024] ="tester";

 

    timer = lr_start_timer();

 

    lr_save_datetime("%Y%m%d%H%M%S", DATE_NOW+TIME_NOW,"mydates");

    strcat(fullname,lr_eval_string("{mydates}"));

    lr_log_message("The running username is --- %s:",fullname);

 

    time_elapsed = lr_end_timer(timer);

    lr_log_message("===%lf===",time_elapsed);

 

    return 0;

}

最近在测试的时候遇到这样一个问题：

 

浏览器版本：FireFox2.0.0.2英文版

 

操作步骤：

 

1、在textarea文本框中输入连续的‘ssssssssssssss’，空格，继续输入‘ssssssssssssss’

 

2、用Ctrl+A全部选中，离开焦点

 

执行结果：

 

1、此时textarea文本框的内容‘ssssssssssssss ssssssssssssss’下方会出现红色曲线

 

2、整个textarea处于灰化状态

 

原因分析：

 

因为FireFox有一个拼写检查功能，如果输入错误的单词系统就会自动启用拼写检查，所以就会出现上面的情况。

 

解决方案：

 

在Tools->Advanced->Browsing中有一个 【Check my spelling as I type】选项，将前面的对号√勾掉，问题就会解决了。FireFox2.0好像默认选中的。

 

测试心得：

 

此问题的出现虽然增长了一定的知识，但是觉得很丢脸，同时也暴露了自己在测试过程中存在的不足，测试出问题来以后没有仔细追究问题产生的原因，就当作BUG提交了，给开发的兄弟姐妹们带来了不必要的困扰，在此深表歉意I am sorry 以后再测试出问题一定先仔细查找问题产生的原因，到底是程序的问题，还是由于某些特殊设置导致的问题，抑或是由于自身经验不足导致的。GO，GO，加油吧！猪猪，支持你！！！o yeah！

 

 

“苍蝇式的战斗精神”和“XXX性能测试”

 

前言：

XXX性能测试终于告一段落了，心情也轻松了许多，感觉一块大石头落地了。从先前的协助调优，到之后的天天熬性能，前前后后断断续续几个月的时间，总算媳妇熬成婆了。这么长的时间，咱不能白忙活了呀，总得把学到的想到的听到的以后可能会用到的记录下来，与天下人共享，这才叫“境界”，O(∩_∩)O哈哈~。借用曹雪芹老先生的话“满纸荒唐言，一把辛酸泪”，当然我这份资料可是绝对滴“不荒唐”，反倒是“粉实在粉实在”。这可是第一手资料哦，值得珍藏ing，(*^__^*) 嘻嘻……

 

不过“辛酸”的的确确是真实的，现在俺只能告诉各位看官“辛酸”的滋味真滴不好受。曾经有那么一段时间，俺是真的失望了，对整个性能的失望，甚至是对自己的绝望，特打击自信滴。俺就像一只没头苍蝇，天天面对着LoadRunner不停的乱试。那时候真的都不知道自己还能做什么了，还会做什么了，曾经一度没有了方向，整个人都要垮掉了，提不起精神，觉得自己特没用，这也许就是所谓的“挫败感”吧。不知各位看官是否有过类似的感受，如有过那咱们先握个手吧，兄弟，知己呀。如果没有，我向您致敬，您运气真好O(∩_∩)O~

 

还好，俺这“苍蝇式的战斗精神”总算感动了上天，本以为看不到头了，没得救了，突然那么一天，上帝眷顾俺咧，怜悯俺咧，这么好的一个娃儿，不能就让她这么废的老，让性能好起来吧，性能就真的好啦O(∩_∩)O ~。哈哈，开个玩笑，It is just a story！其实主要是想告诉大家，遇到任何事情都不要回避气馁，坚持一点，再坚持一点，也许就会“柳暗花明又一村”咯。当然，我们性能的优化经历了千辛万苦，与“苍蝇式的探索”和开发兄弟们的辛苦努力是分不开滴。为了纪念“苍蝇”兄弟给俺的启发，特地以此命名。

 

正文：

言归正转，下面就把俺这段时间所学所想所感记录下来，让“苍蝇精神”永垂千古(*^__^*) ……

 

（一）总体统筹

1、作为性能测试，挖掘用户需求是非常重要的。

对客户来讲，他可能只需要知道这个页面我要几秒钟就能看到，不能低于几秒钟，超过几秒我就接受不了了。或者说我需要这个系统能支持多少用户，以后公司发展了，还需要支持更多的用户使用等等。

这个时候我们就要进行需求的分析和细化，把这个几秒钟、多少个用户具体的整理归纳成性能测试所需要的东西。有效的性能测试需求分析才是整个性能测试过程中的重中之重。

2、性能需求固然重要，更重要的还要做好性能测试计划，测试计划可以说是整个项目的总指挥。

这个计划不应该是泛泛而谈，为应付而应付的东西。它不仅仅应该是测试计划，更应该是计划测试。计划测试就是要让测试活起来，有生气，有内容。

经过XXX的测试，个人觉得性能测试计划最好使用Excel表格，这样便于及时的记录结果、修订内容，而且看起来会非常的清晰。XXX性能测试计划我是跟测试用例整理到一起的，详见附件《XXX性能测试计划.xls》，仅供参考。 

3、一定要有测试用例，如果说测试计划是总指挥的话，测试用例就是总指挥手中的魔法棒，它指导着用户的操作过程。

因为性能测试比较繁琐，可能需要不停的反复，因此测试用例要做到及时更新，并且必须要及时的记录一些重点的测试结果。“好脑筋不如烂笔头”，记录下来就不容易忘记了，而且也能更好的做到有据可循。

众所周知，凡是有人的地方就会有矛盾，就会有责任的纷争和归属，如果有据可循，就避免了大量麻烦。其实这种事情我想每个做测试的兄弟姐妹们都应该遇到过，尤其是功能测试的时候。系统上线啦，咱们的辛劳没人太在意，一旦系统出了问题，得啦，好日子来啦，测试是怎么做的，这种问题怎么没有测到。嗳，这个时候如果有证据说明你确实做过了，而且是没有问题的，那自然就……当然，这也不能成为我们推卸责任的理由，出现问题了，还是需要积极的去面对，及时的去修正，不管是不是你的责任。

（二）细节把握

1、录制脚本前要先熟悉系统，这样才能做到“知己知彼，百战不殆”。其实不需要这么冠冕堂皇的理由，如果连系统都不熟悉，“丈二和尚摸不着头”的，谈何而来的脚本录制。

2、脚本要优化。脚本不是录制完就算完事了，就可以使用了，而是要根据需要进行优化，脚本分割、创建事务、参数化等等。我在实际过程中总结了下面几点：

（1）脚本删减。因为LoadRunner是模拟用户之间的通信过程的，不是所有的脚本都是必需的，事实上有些垃圾代码可能会影响性能测试结果的准确性。因此可以对脚本进行删减，只保留关键部分。删减的过程中需要注意的是如果你不确定，可以先把不需要的脚本注释掉，然后在VUGen中执行一遍，如果成功执行，这些被注释掉的脚本就可以删除了。

   经过实践发现，脚本中的这些地方是可以删除的：web_add_cookie函数、一些非必须的web_url函数等等，还有每个函数EXTRARES之后LAST之前的部分。或者通过Tree View视图查看，没有Server Response返回值的，或者返回值中的内容对整个脚本无关紧要的，不需要用到它的返回值来做关联或者其他操作的，就都可以删掉。这是个很实用的技巧，屡试不爽。

   有人可能会产生这样的困惑，哎呀，这么删来删去的，万一删错怎么办呢，还要重新录制脚本，岂不是很麻烦。不要着急，试试Regenerate Script…吧，VUGen -> Tools -> Regenerate Script…可以还原到初始脚本哦。

（2）脚本分割。LR的脚本分割具有更强的灵活性，如果有一段内容需要经常被使用到，那么就可以把他单独拎出来，放在一个函数，也就是在Script. View左边Action导航中Create New Action即可。这样就可以随用随调了。

   脚本处理好以后在VUGen中回放时，默认是按照RunTime-Setting -> Run Logic -> Run下面的action顺序执行的，这个时候就会出现问题。比如Run下面有4个action：login()、start()、sendMsg()（调用start()）、logout()，其中只需要在sendMsg的时候调用一次start就可以了，按照目前的顺序回放的话，start()就被多执行了一次。要解决这个问题，只需要将start()从RunTime-Setting -> Run Logic -> Run中删除即可。回到Script. View左边Action导航可以看到start()的图标变成了半透明状，类似“只读”状态，事实上是可以编辑的。这又是一个行之有效的小窍门。

（3）脚本参数化。以前只拘泥于选择file文件类型对脚本进行参数化，后来发现file类型太麻烦了，特别是大数据量的时候，如果不是必须用的话，建议选择其他的类型。比如说XXX项目中，对Server的参数化就是选择在server0、server1还是server2上执行，先前都是采用file类型，因为最多要有1500个用户并发，所以要在file中准备1500条数据，这样就是一个比较大的工作量，尽管用excel拖曳一下也蛮方便的。事实上，我只需要对0、1、2做参数化就行了，所以使用Random Number类型就更方便啦，而且通过压力测试发现，这种参数处理方式可以使各台服务器的负载更加均衡。强调这一点并不是说file类型不好，而是说在进行参数化的时候要结合实际，做最有效的处理。其实对于参数化已经讲了不止一次了，每次都有新的内容，关键是要用，在用的过程中才能做到“融会贯通，游刃有余”。

（4）脚本关联方式。脚本的关联是在脚本处理过程中经常用到的，他可以自动关联，也可以手动关联。可以参考鄙人以前写的《在LoadRunner中用web_reg_save_param()做关联》，除了该文档中编写的方法外，鄙人还发现一个查找关联点的方法，那就是在脚本回放的时候选择打开浏览器Tools->General Options->Display->Show browser during replay，这样就会将新一轮的回放结果显示在浏览器中，很明了的就可以查看了。如果对系统比较熟悉，关联就会变得非常简单了。

3、场景设计。场景设计是非常重要的，这个更多的依赖于性能需求，想要什么样的结果就做什么样的设计。在此次的测试过程中发现，场景开始执行时如果同时有100个用户并发操作，就会出现大量的连接超时，服务器无法响应，或者连接被过早的关闭等错误，这个时候就需要寻求最佳的并发用户数量，因为有多台客户端，所以在设计场景时就需要仔细计算每个客户端的并发用户数量，并且需要保证每次接收和发送消息的并发用户数量是相同的。具体可参见附件《XXX性能测试报告.pdf》中的场景设计图。

4、Run-tXXXe Setting设置。因为要保证每个用户都必须成功登录，所以在登录脚本中做了条件判断，如果用户的ID和应用ID等不为空，就表示登录成功了，如果为空就重新登录，这个时候Miscellaneous的Continue on error选项就需要被勾选，这样就可以保证每个用户都能成功登录了。

   Preferences -> Options里面，step timeout caused by resources is a warning 设置为yes，这样资源下载失败了就会显示为一个警告，就不会在场景中出现大量的error。

   Preferences -> Options里面，step download timeout (sec)可以设置的时间长一点，比如说300s，这样就保证了资源下载的时间，资源下载失败的现象也会减少。 

   同时需要在场景的Tools -> Options -> Timeout做一些超时时间限制的调整。

   如果基本上知道结果输出可能的情况，就可以General -> Log设置Send messages only when an errors occurs，也就是仅在错误时候输出日志。如果需要查看所有的日志输出，可以选择Always send messages。

5、场景定时运行。有时候可能并不需要场景设置好了马上就执行，而是希望在某个时间点开始。这个时候可以选择场景中的Edit Schedule -> Scenario Start Time，设置为At (HH:MM:SS) on (yyyy-mm-dd)执行。此时需要注意的是，一定要点 Start Scenario

6、结果文件的命名和保存。场景执行后势必会产生结果文件，结果文件的命名需要规范易于分辨。如上第4点，如果选择Always send messages，那么光日志文件就可能占据很大的空间，把结果文件制作成HTML Report的形式就会节省很大的空间。在Analysis中整理好所需要的结果图表，选择Analysis -> Reports -> HTML Report即可。

7、使用多台客户端作为Load Generators。为保证每台机器都能正常连接，各客户端的LoadRunner Agent Process都是开启的，然后在场景开始之前需要先Connect每台客户端。

多台客户端机器作为Load Generators时，除了主控机，也就是执行场景的机器，LoadRunner会在各个客户端机器的临时文件夹中生成很大的文件，有的多大10几个G，文件的大小跟场景执行时间成正比。因此场景开始之前，一定要保证各客户机的磁盘空间充足。

（三）结果分析

个人认为结果分析是一个长期的过程，更应该是一个集体合作的结晶。由于个人知识结构的限制，分析的难免不到位，附上测试报告，仅供分享。

　 此次测试，主要关注了事务的响应时间、吞吐量和服务器的资源占用率等几个方面的指标。

　1、事务正常运行的时候，如果响应时间曲线持续上升，点击率和吞吐量曲线都在下降，可能表明系统的处理能力在下降。引起该现象的原因可能有：（1）用户数连接未做限制，导致请求数不断上升，响应时间不断变长。（2）出现内存泄露。

　2、CPU的使用率不断上升，内存的使用率也是不断上升，其他一切都很正常，表明系统中可能产生资源争用。

　3、 所有的事务响应时间、cpu等指标都很正常，大量的业务失败，可能是由于数据库死锁造成的，也就是说，你在操作一张表或一条记录，别人就不能使用，即数据存在互斥性，当数据量大时，就会出现数据错乱的情况。

（四）相关知识

   性能测试真是一个考验所有相关人员，尤其是测试人员各方面能力的活计。做好性能测试需要具备各方面的知识，不一定全部精通，但至少都要懂一点。专业的测试技能、软件编程能力、网络知识、操作系统、数据库、中间件、行业知识、个人素养等等。

在网络方面，测试人员应该掌握基本的网络协议以及网络工作原理。尤其要掌握一些网络环境的配置知识，这些都是测试工作中经常用到的知识。

操作系统和中间件方面，应该掌握基本的使用、安装及配置等技能。例如，很多应用系统都是基于Unix、Linux来运行的，这就要求测试人员掌握其基本的操作命令以及相关工具软件的使用。而WebLogic、Websphere等中间件的安装与配置方法也需要掌握一些。

数据库知识则是更应该掌握的基础知识。现在的应用系统几乎离不开数据库。因此，不但要掌握基本的安装、配置，还要掌握SQL。测试人员至少应该掌握Mysql、MS SqlServer、Oracle等常见数据库的使用。

作为一名优秀的测试工程师，首先要对测试工作有兴趣，因为测试工作在很多时候多少显得有些枯燥。因此，先要热爱测试工作，才能做好测试工作。在个人素养方面，除了具备必须的专业技能和行业知识外，测试人员还应该具有一些基本的品质：专心+细心+耐心+责任心+自信心 ，统称为“五心”。

如此看来，要真正的做好性能测试，还有很大一段距离，有差距才有动力，有动力才有进步的空间，加油！

尾声：

  终于接近尾声了，希望这篇《“苍蝇式的战斗精神”和“XXX性能测试”》能给大家带来一点点的帮助。

 

LINUX系统性能监测工具sysstat的安装

1、下载sysstat的tar.gz包
链接地址：http://pagesperso-orange.fr/sebastien.godard/download.html
如果可以直接链接到网络的话，可以使用apt-get install sysstat命令进行安装

2、安装
 
  tar zxvf  xxx.tar.gz 
  ./configure       
   make
   make install

安装完成后，用户sar 2 5测试，不行，删除文件重新安装，发现在./configure的时候出现三个warning，并且在make的时候，很多文件被忽略了，特别是.o文件，从网上搜索，需要安装gettext

因为在虚拟机上，不能直接连接到网络，所以选择了下载gettext-xxx.deb后安装，如果可以上网的话，可以直接使用
apt-get install gettext
进行安装