I was so tired yesterday after playing basketball with my colleagues at Kovan. It has been probably 7 years since I played basketball last time in college.

I went back to the place where I stay. I was waiting for the traffic light to turn green with a group of people. Then suddenly a man started go across the road when the light was still red. There are cars running on the road. Luckily, he went to the other side without any accident. I can tell from his back that he may be a Indian or Malay. At this moment, some guy started to talk..."He is so lucky...Why didn't he wait for the light?"...I noticed there was a Chinese-looking family in the group of people. The wife replied her husband:"Last time I saw a China girl going across the road when the light is red, she was almost bumped." Then one kid said, "I guess in China they don't have traffic lights"..."Yeah.." the mom said...Why?

Why when you see something not good, you think about China? What bad thing did China do to you? Where did you gradparents come from? You hope you would become Malay or Indian some day?

I know why. Because you know nothing about the world out of Singapore, you never go out and see the world! I do have some friends from Singapore - Malay, Indian, Singaporean Chinese. Most of my friends are friendly - Annie, Nancy, Eric... But I also notice there are a certain percentage of Singaporean Chinese who look down on China a lot. I don't want to change your mind, but you should not teach your kids like this. A lot of your kids will go to work and live in China in the future I believe. You should open their mind, not limit them. Am I right?

亲爱的姥爷，我是小悦，和您很亲切的小悦。爸妈告诉我您昨天上午不在了，我的心好难过。这次出差来新加坡，包括从开始工作到现在，我比以前去看您看得少多了。其实真的也很惦记您，是我做得不够。
我早上给爸妈打过电话了，和他们说了说，也很担心妈妈的情绪与身体。从电话里听上去，妈妈很坚强，妈妈没哭，我先哭了。年前就听说您住院的消息，一直很担心，每次问妈妈，妈妈都告诉我您的病情没有进一步恶化，也没有什么明显的好转。我心里也不清楚您会不会好，可是真的心里很希望您能好起来，希望我回去还能看到您，也让您看到我。可我不能如愿以偿了，甚至连您的追悼会也不能赶去了。真的很难过。您还能在梦里和我说说话么？
从小和您一起生活了很久，脑子里还记得一些和您生活时候的片断。您总是给我讲故事哄我睡觉，那是听您讲的故事是那么有意思，有些故事我记得我要求您给我讲了好几遍，比如说“漏”的故事。很喜欢吃您做得拌黄瓜丝，也喜欢您的醋熘白菜，真的不想接受和我这么亲切的您这么快就离开了我们。我还记得我们以前经常一起去遛弯，早上去，晚上也去。这种好的锻炼习惯也让您保持了很好的身体状况，我曾经很开心的是您的身体一直很好。
我知道您曾经是八级木匠，那应该算是很高级的工人的级别吧，您但是一定出了自己的聪明也很努力。后来您还自己学着认识了很多字。我一直想，如果您和我生在一个时代，一定是个了不起的人物，说不定也能成为个科学家呢，一定是我的偶像（当然，您现在也是我心中的偶像）。我应该学习您那种积极对待人生，努力工作的态度。
您对儿女子孙都很好，妈妈刚才还告诉我，您省吃俭用省出了几万块，要留给孩子们。想起您的手指头，您告诉我那时干活受过伤；想起您的皮肤有些黑白斑块，您告诉我白表示卫生，黑表示健康；想起您那时候喜欢用的大扇子，您总用那大扇子给我扇风；记得您给我学南方人说话“外公，我要吃桔子”...还挺妈妈说过您年轻时候打舅舅们的事情，您对我从来都是和蔼可亲，即使我犯过错误也没骂过我，就别说打了。
我的好姥爷，悦想您，您去世前去世后，悦都想您。希望您好好的走，希望您没有遗憾的走，也希望我们来世还是亲人。等回国了，我让妈妈告诉我您的灵位在哪里，去看您。

I saw a list from the book i've been reading.

Testing Types

Testing gets broken into two types: black box and glass box (also sometimes called white box):

• Black box. The idea behind this type of testing is that if the code is in a black box, you can't see the inside machinations of how it works. You see only how you are able to use it as an end user.

• Glass box (or white box). The idea here is that if the code is inside a glass box, you can see the internals of the code and poke at the weak points of the functions because you understand how the internals are put together.

The testing process gets further granularized into unit testing, integration testing, functional testing, system testing, end-to-end testing, regression testing, and more. The delimitations between these types of testing are often fuzzy, but can be used to indicate activities and assign ownership. The following list defines some of the more common types of testing you engage in:

• Unit testing. Developers create the code-small discrete functions. Once they add more functions, they need to go back and test to verify that the functions interact as a unit the way they anticipated and designed for. This process is the unit testing, testing individual atomic units to ensure that they work as expected.

• Integration testing. A thorough developer carries the idea of unit testing into testing how their new units work together with related units, integrating them and checking their connections. This usually expands to include testers, who perform the remainder of this sort of integration testing.

• Smoke testing, build verification tests (BVTs), check-in tests (CITs). The real challenge starts in integration as features that are stable are integrated with new functionality. When code is passed to the test team, it is often verified first through smoke tests, build verification tests (BVTs), check-in tests (CITs) or other quick-and-dirty validations of the program's main functions. Such tests are also performed to ensure that the same base level of functionality that was available yesterday is still available today after the latest check-ins.

• Functional testing. Putting more of the stable small functions together allows testers to perform functional testing, testing a complete function from the user's point of view (as opposed to a code-based single function). In the online bookstore example I use throughout this text, functional testing may mean trying to perform user functions such as logging on or logging off.

• System testing. Putting the functions together allows the tester to verify the entire system in system testing. This may mean testing pieces of every component available.

• End-to-end testing. These tests are usually similar to system testing, but involve a clear user scenario that is being followed to test a user's complete interaction with the system.

• Sanity testing. Initial tests to determine if the area or entire product is stable enough to put more time and effort into testing.

• Regression testing. Retesting areas after fixes or functional additions to ensure that previously fixed bugs have not reappeared and new bugs have not been introduced (often performed by running the same test case as before or through automation).

• Acceptance testing. Final test pass based on specifications, customer agreement, or other such particulars.

• Load testing. Testing the software under heavy usage to determine performance degradation or failures.

• Stress testing. Testing specific functions while the system is running under high loads; helps determine the mean time to failure and performance metrics.

• Performance testing. Determines how much time or cost is associated with certain actions of functions. (How long will a customer have to wait for a particular action to complete? How long does the code spend in a particular function?)

• Usability testing. Testing the ability of the software to be used by the identified customer base.

• Install/uninstall testing. Testing how product components download, don't download, and work on various platforms, client or server, as well as how easily they can be removed.

• Recovery testing. Evaluating how well and how fast the system can bounce back from a crash or other failure.

• Compatibility testing. Determining the primary and secondary supported environments (OS, platform, browser, and so on) and the levels of support/behavior/functionality provided on each.

• Exploratory testing. A creative approach to learning and evaluating the software; usually informally introduces a tester to the environment.

• User acceptance testing. Determining if the software is satisfactory to a customer (usually not performed in shrinkwrapped development efforts).

• Alpha testing. Initial incorporation of endusers into the completed program. Involves early adopters or other partners. Design changes may occur as a result of this feedback.

• Beta testing. Development and test are basically finished. Finds final problems before the final release. Can be an open invitation to anyone who wants to download the software or try the service.

• Comparison testing. Comparing software features and stability to those of competitors.

• Accessibility testing. Checking if product or service is accessible to users.

• Server log testing/report testing. Examining the server logs after particular actions or at regular intervals to determine if there are problems or errors generated or if the server is entering a faulty state.

• Security testing. Testing the potential for accidental or malicious damage due to attacks, denials of service, open ports, and other issues.

• Memory leak testing. Testing the server components to see if memory is not properly referenced and released, which can lead to instability and the product's crashing.

• International sufficiency/localization/globalization. These are discussed in Chapter 7; however, each one is a distinct testing effort.

  • International sufficiency. This involves testing that the product can be localized into the target languages; languages that write from the right side of the page to the left side of the page place special requirements on the user interface as do double-byte languages such as Chinese and Japanese. Testing that the user interface can handle these is a separate task from actually translating the words.

  • Localization. This is testing that all the words that the user sees are translated into the specified language properly.

  • Globalization. This is testing that all the various characters and combinations from the various languages can be accepted by the system or are properly rejected and that no data conversions or corruptions occur.

• HTML validation testing. Specific to Web testing. This certifies that the HTML meets specifications and internal coding standards.

• SSL testing. Testing Web site/service over an SSL connection, if that's an option.

• Bandwidth testing. Testing a site with a variety of link speeds, both fast (internally connected LAN) and slow (externally, through a proxy or firewall, and over a modem); sometimes called slow link testing if the organization typically tests with a faster link internally (in that case, they are doing a specific pass for the slower line speed only).

Overall, you want to move away from brute force methods of testing. Sure you could find bugs by blindfolding yourself and randomly hitting keys, but it would take a very long time and be rather inefficient. You will include some amount of ad hoc testing in your test activities. Where brute force just bangs on the keys and the mouse, ad hoc testing lets loose your creativity to think more about certain areas and investigate them. This is best undertaken by a tester who knows the software and testing methodologies well enough to see the bug patterns and know where to poke to find more problems.

按计划一样，我们女友7月8日、9日两天跑到了上海。

一路上还算顺利，我们通过票贩子搞到了两张硬卧票，在火车上半梦半醒的整了14个小时，终于到了。好像睡得有点着凉，我鼻子两个窟窿都不通气了。不过上还挺热的，很快鼻子就没什么不适的感觉了。

大姨来火车站接我们了，出了站的第一件事情就是买回程的火车票。考虑了很久，联络了很久，终于下定决心，买软卧吧，硬卧实在没把握了，我不想耽误上班。呵呵

然后我们就直奔了[新上海城市广场]——原以为是一个什么商场/购物中心之类的呢，结果是一个写字楼。不管怎样，我们还是很顺利地找到了珠宝展示中心。

开始眼花缭乱的挑选了。。。经过了好几的小时，我们终于拍板。要了一颗F色的3EX的35分的石。哇，那光真漂亮。有人很喜欢它还是有道理的，不过也确实挺贵的。但给老婆花点钱我还是愿意的。随后我们又选了一对彩金对戒，我觉得挺好看的，价钱也不算贵。大功告成！

 

后面的时间是我们自由行动了。去了老城隍庙，淮海路，浦东（东方明珠下），南京路，最后又回到了老城隍庙。老城隍庙里面最热闹，一大堆老外。呵呵。

吃了两顿算是有名的上海菜，小绍兴的白斩鸡，和那个叫绿波廊的上海人都舍不得去的饭馆。饭菜味道的确不错，可是绿波廊的价钱却是不菲，还有点欺骗我的意思。具体的评论看这里吧http://www.dianping.com/shop/500395

 

研究了很久，了解到时下最流行的是先买裸钻再做托。因为裸钻我们能够更清楚的检测他的各项参数，被骗的机率也小得多。

网上流行团购，我也准备参加一把，主要是因为价钱便宜得多。同样水平的钻石，通过团购买裸钻再做托的价钱比买成品钻戒（比如周大福、恒信等）要便宜1/3还要多。花同样的钱，卖个更大一点的钻石给未来的老婆，她一定喜欢。

我要参加的团购的发起人在上海，这周末准备去一趟。

 顺便分享店挑选钻石的知识吧：

 

（我和此网站商家无关，仅仅引用）