目前分類:Performance Testing (34)

瀏覽方式: 標題列表 簡短摘要

在進行Benchmarking時常發生的錯誤

Source: High Performance MySQL, 
Baron Schwartz, Peter Zaitsev, Vadim Tkachenko, Jeremy D. Zawodny, Arjen Lentz, and Derek J. Balling, 
Oreilly

當我在讀"High Performance MySQL"一書時, 作者提到在執行Benchmarking時, 有些錯誤要小心不要去犯. 可是我看完後發現, 幾乎每一條我們都遇到了, 還覺得真得是很可恥. 因此特地整理出來給大家看一下, 希望大家不會在遇到同樣的問題.

1. Using a subset of the real data size

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

Capacity Tools

source: The Art of Capacity Planning
Appendix C: Capacity Tools

當你在進行capacity testing時, 很重要的一件事情就是要有工具來支援你. 否則若是要靠人定勝天, 以capacity testing的資料量和測試的頻率, 那將會你的測試工作變成一場夢饜.

這本書的作者收集了一些工具, 我想應該對大家有很大的幫助. Enjoy it.


kojenchieh 發表在 痞客邦 PIXNET 留言(3) 人氣()

MSDN教學影片: Web Performance Test

剛剛在上課時, 同事所提供了一個網站, 那是Microsoft的中文化教學網站, 並且有中文發音, 教你如何使用VSTS來做web performance test. 真是給他有夠感動, 大力推一下

MSDN教學影片: Web Performance Test
http://msdn.microsoft.com/zh-tw/vstudio/cc963632.aspx


kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

效能測試流程 (2)

這些是我根據"Improving .NET Application Performance and Scalability"的內容, 整理出在需求收集階段, 大概要做的事情. 之後還要跟同事討論一下是否還要加什麼.

Step 1: Identify key scenarios
A. Scenarios are anticipated user paths that generally incorporate multiple application activities
B. Scenarios are those for which

kojenchieh 發表在 痞客邦 PIXNET 留言(2) 人氣()

效能測試流程 (1)



最近大家想要來訂定一個效能測試的流程, 因此我收集了一下目前我手頭上有的:

1. BPT Part 2: A Performance Engineering Strategy, R. Scott Barber

kojenchieh 發表在 痞客邦 PIXNET 留言(1) 人氣()

效能測試的目標是什麼?

What are the Goals of Performance Testing?
http://hpperformancecenter.blogspot.com/2009/08/what-are-goals-of-performance-testing.html

Thursday, August 13, 2009
Posted by Stephen Feloney
Published in HP Performance Center

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

如何以省錢的方式來進行效能測試

Budget-friendly Web app performance testing, monitoring tips
http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1358632_mem1,00.html?track=NL-516&ad=717057&Offer=mn_eh072209SFTQUNSC_budgetH&asrc=EM_USC_8756843&uid=8968635

06.09.2009
Posted by Karen N. Johnson

通常預算是效能測試重要的因素, 因為不可能投入大量人力, 或是購買昂貴的測試工具, 或是購買和production一模一樣的機器或環境來模擬. 因此你必須精打細算, 利用一些現有或是不用錢的方式, 來達到相同的目標. 尤其在現在經濟不景氣的狀況下, 這件事情更是顯得重要.

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

一些有用的Web Performance Tool

Web Performance Tool Evaluation - lower end proprietary tools
http://www.testingreflections.com/node/view/8164

07/07/2009
Submitted by
corey@goldb.org (Corey Goldberg)

作者有些perofrmance 和load tools的經驗, 這裡是他的一些feedback. 他把測試工具分成以下幾類:

kojenchieh 發表在 痞客邦 PIXNET 留言(2) 人氣()

前100大負載和效能測試工具

Top 100 Load and Performance Test Tools List
http://csshook.com/cssresources/top-100-load-and-performance-test-tools-list/

在這裡作者列出了100個常用的負載和效能測試工具, 並且把他們適當的做了一些分類. 找不到工具好用的人, 可以來這裡逛逛.

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

要多快才是夠快

Part 3: How Fast is Fast Enough?
http://www.perftestplus.com/resources/BPT3.pdf

Posted by Scott Barber


kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

可接受的應用程式反應時間 v.s. 業界標準

Acceptable application response times vs. industry standard
Scott Barber
03.13.2007
http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1243574_mem1,00.html

過去六年間, 還沒有一天有人停止過問我: "一個網頁的業界標準反應時間是多久?"

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

為什麼我們要對效能做測試?

Why do we test for performance?
http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1317268_mem1,00.html

06.11.2008
posted by Scott Barber


kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

應用系統效能測試的難題: Cloud, Virtual labs, Scale-up

Application performance testing issues: Cloud, virtual labs, scale-up
http://itknowledgeexchange.techtarget.com/software-quality/application-performance-testing-issues-cloud-virtual-labs-scale-up/

Posted by: Jan Stafford
Published in IT Knowledge Exchange

應用程式的效能測試過去曾經是一個單獨的流程. 但是由於複雜mission-critical的應用系統, 虛擬化技術, 和雲端計算等狀況的出現, 人們將這些東西合在一起, 導致於效能測試十分困難. Mark Kremer, Precise Sofiware Solution of Redwood Shores的 CEO最近和我談到這些事. 在談話中, 他提出一些建言, 有關於要如何來面對這些挑戰, 以確保最高的系統效能.

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

效能測試中有哪些需要注意的階段

Performance Testing Core Principles: CCD IS EARI
http://www.testingreflections.com/node/view/5448

21/05/2007
Posted by sbarber
Published in TestingReflection

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

在Agile專案中如何進行效能工程

Performance Engineering in an Agile Project
http://www.infoq.com/news/2009/03/agile-performance-engineering

Mar 25, 2009
Posted by Vikas Hazrati
Published i InfoQ

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

4. 效能測試、壓力測試(Stress Testing)負載測試(Volume Testing)的比較 

談完效能測試後,接下來我都會大家一個問題:效能測試、壓力測試
(Stress Testing)和負載測試的差別在哪裡?一般人聽到這三個名詞,覺得很相像,又覺得不太一樣,很少人會分的清楚到底差在哪裡。這三個名詞要做的事情當然不一樣,否則老外不會那麼無聊去創造出他們出來,讓我們來看看各位名家所給的定義:
 

A. J Myers 

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

3. 什麼是效能測試

效能測試是指在一個給定的工作量(workload)下,量測以下的項目,是否滿足原先所設定的目標。 

#
受測系統的反應時間(response time) 
# 生產量(throughput) 
# 系統資源使用狀況 (resource utilization) 

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

第一章 簡介 



1.
為什麼要做效能測試 (Performance Testing)  

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

在面試Automation 和Load testing相關經驗時可以問的問題

Automation Q & A
http://thiyagarajan.wordpress.com/automation-q-a/

Posted by Thiyagarajan Veluchamy
Published in Thiyagarajan Veluchamy's BLog

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

The 10 Commandments of Load Testing
http://www.myloadtest.com/ten-commandments-of-load-testing/

以下是你在做load testing, 要小心的十件事情

1. 你需要知道test toll是如何運作的
- The worst performance testers I have met were always more concerned about whether they could get their scripts to run, rather than whether the tests they were running were realistic.
- Read the documentation, practice, spend some time figuring out what all the settings do, then relate how your scripts are running back to how real users exercise your application.

2. 你需要收集真實的在運作或使用的資料
- Garbage in, garbage out. If your transaction volumes are wrong, then your load test is wrong.

3. 你需要有可測試的requirements.
- Non-functional requirements (especially load and performance-related requirements) are usually an afterthought for many projects.
- This shouldn’t stop you from trying to gather the requirements you need for your tests.
- The business approach of “let us know how fast it is, and we will let you know if that’s okay” isn’t good enough.
- Get some numbers. The numbers can change in the future (maybe call them “targets” or “guidelines” rather than “requirements”), but you need something to test against before you start.

4. 你應該要撰寫測試計劃
- Even if you already know what you’re going to be doing, other people would probably like to know too - they might even be able to help.
- A a signed-off test plan has saved many a tester from the wrath of project management.

5. 你應該要測試最差的狀況
- Don’t test with transactions from an average day, test for the busiest day your business has ever had.
- Add a margin for growth.
- Testing failover? A server doesn’t fall over at midnight when no one is using your application (would we care in this situation anyway?), it falls over in the middle of the day when lots of real people are using it.

6. 你需要監控你的測試環境
- Monitoring your servers allows you to more easily figure out where the problem is.
- You can also make neat observations like “response times for the new version of the application are the identical to the previous version, but CPU utilisation on the servers has increase by 10%”
- When I say “monitor your servers”, this includes your load generators.

7. 必須要對你的測試環境做change control
- The final thing you tested should be what is deployed into Production - same application version, same system configuration.
- It’s easy to lose track of what you are actually testing against if people are making uncontrolled changes to your environment, or if people are making tuning changes without tracking what they are changing.
- Keep a list of changes that are made…even if you are in a hurry; and always make sure you know what you are testing against.

8. 你應該要使用 defect tracking tool.
- An untracked defect is a little like a tree that fall in the forest when no-one is around - no-one cares.
- Raising defects lets everyone know there is a problem
- It also provides a neat repository to keep track of all the things that have been tried to fix the problem.

9. 在submit defect之前, 你應該先確認那不是你的問題或是工具的問題
- “Oops, my bad!” is a great way to lose credibility with the people who are going to be fixing your defects.
- If you don’t have credibility, you are going to have to work much harder to convince people that the problem you are seeing is due to a fault with the system rather than a fault with your test scripts.
- Don’t be so afraid of making a mistake that you test “around” errors (like people who see HTTP 500 errors under load and “solve” the problem by changing their scripts to put less load on the system).

10. 你應該要傳遞你的知識給相關的人
- Write a Test Summary Report and let management know what you found (and fixed) during testing, make some PowerPoint slides, hold a meeting.
- Let the Production monitoring group know which metrics are useful to monitor, let them re-use your LoadRunner scripts for Production monitoring with BAC.
- Leave some documentation for future testers; don’t make them gather requirements and transaction volumes again, or re-write all your scripts because they don’t understand them.
- Retain your test results until you are sure that no-one is going to ever ask about the results of that test you ran all those months ago.

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

1 2
找更多相關文章與討論

您尚未登入,將以訪客身份留言。亦可以上方服務帳號登入留言

請輸入暱稱 ( 最多顯示 6 個中文字元 )

請輸入標題 ( 最多顯示 9 個中文字元 )

請輸入內容 ( 最多 140 個中文字元 )

請輸入左方認證碼:

看不懂,換張圖

請輸入驗證碼