聯想集團CEO楊元慶近日談及這一變革時表示，互聯網的時代，要更加積極，更加進取，不能被動，不能保守。
楊元慶說，這些方面，陳旭東也都是強項，他喜歡嘗鮮，喜歡嘗試，喜歡冒險，他有開放的心態，能夠擁抱互聯網，這些都是聯想移動需要有的精神。
楊元慶對聯想移動原有團隊的不滿很明顯。楊元慶說，現在需要的競爭力已經完全不同。“我去年跟你們說了幾次，要醒一醒，我甚至還說了你們拿榔頭敲都敲不醒，你們太慢了，在錯失機會。”
楊元慶對陳旭東團隊提出了要求：不能固步自封，要有更強烈的互聯網思維和基因。
權力是春藥，即使旁觀人事變動、權力更迭也能讓人血脈僨張。
2015年6月1日晚，聯想集團發布了人事變更聲明：聯想執行副總裁、移動業務集團總裁及摩托羅拉管理委員會主席劉軍，將離開現在的崗位，在一段時間內擔任移動業務及戰略方面的集團CEO特別顧問。同時宣布陳旭東出任移動業務集團領導人及摩托羅拉管理委員會主席，任命從即日起生效。
這是一場蹊蹺的離職，要知道離職者可是被認為是聯想集團的二號人物，在剛剛結束的聯想tech world大會上，他還詳解了聯想手機的下一步規劃和安排。關于離職原因，甚至在官方聲明中也未做解釋。
我們可以認為是最高層對他幾年業績的不滿嗎?
劉軍被派去接管手機時，當時聯想手機的市場份額只有0.9%，而且還是在聯想重金推出一代樂phone剛剛鎩羽而歸，完全失去方向和節奏之時。
劉軍上任后設定的最主要目標是規模。他認為，“如果沒有規模，就無法在行業里立足。因為規模決定了采購成本，決定了上游廠商的支持力度”。
當時智能手機市場主流價格在2000元左右， 劉軍決定以1000塊可能將引爆市場，于是聯想和聯發科合作，只用了大概5個月時間，就完成了產品定義到產品上市，率先推出雙卡雙待的千元智能手機A60，而且在長達一個季度的時間內，聯想獨占了這個市場。A60是聯想的明星機型。
在規模至上的理念中，聯想很長時間里在手機渠道戰略中有70%份額依賴于運營商渠道。這導致的后果是不斷壓低成本、機海戰術以及對其他渠道的弱化。而這些，都在運營商渠道生變之后，對聯想的發展形成重重壓力。
相較其他品牌，聯想的互聯網手機品牌一直沒有特別亮眼表現，而差不多同樣基礎的華為榮耀，則短短一年多時間，完成初步積累。
在手機廠商都在致力完成“軟件+硬件+服務”三位一體的流行趨勢中，聯想也沒有落下。而且還推出過茄子快傳等明星應用，但由于觀念沒有“軟化”，這些應用并沒有投入更好地服務支持。聯想軟件的適配和優化都與一流國產廠商存在巨大差距。以至于在友盟的統計中，互聯網服務應用最活躍的機型仍然來自三星、小米等熱門機型。
而受累于運營商渠道的過分依賴，數據顯示，聯想移動業務的總銷售收入占集團整體收入約20%，但移動業務集團仍虧損3.7億美元。
這些都說明，雖然聯想一直在追求轉型，但還是非常徹底的一家硬件廠商。
但這一切，很難說是劉軍的錯，他根植于聯想，他的思路根本就是聯想集團在PC時代思路延續。規模、成本、供應鏈管理。。。不就是聯想PC成功的關鍵嗎?如果聯想移動要成功，那勢必是要從聯想的最根部做革命性改變，這恐怕是個一把手工程。
劉軍高大，帥氣，與著名模特姜培琳結婚。作為清華同學，他還在高曉松的書《如喪》中出現過，書中劉軍作為清華籃球隊隊員，是個被女生仰慕著的形象，這些都讓人覺得他與聯想的固有形象會有不同，但他是個地道聯想人。
劉軍1993年清華畢業后進入聯想，曾經是聯想最年輕的部門總經理、“聯想十八棵青松”之一，是聯想內部“專門來打硬仗的人物”。加入聯想的第二年，劉軍就開始與楊元慶一起工作，到1996年，開始直接向楊元慶匯報工作，一直是他的得力干將，兩人一起度過很多艱難時刻。楊元慶的辦公桌上曾經長期有一張照片，是他和劉軍等人十多年前在美國拍下的。當時抱著取經心態到硅谷參觀過英特爾等公司之后，激情澎湃的幾個人，在那里立下遠大志向：要讓聯想十年成為國際品牌。#p#分頁標題#e#
聯想收購IBM PC之后，一度引入以戴爾系阿梅里奧作為CEO，這位CEO認為當時主管供應鏈的劉軍表現不佳，當時以楊元慶為首的中國人在董事會話語權不高，劉軍被迫下課。
對于這件事，柳傳志曾回憶道，“專項戰略委員會匯報的時候給劉軍打的分數很低，我當時差一點流眼淚，……一員大將的培養真的不知道經過多少磨難。”后來2009年，柳傳志復出，劉軍再次進入聯想最高經營8人管理團隊“聯想執行委員會”。
2013年，聯想宣布重組業務部門，分拆成Lenovo業務集團和Think業務集團，劉軍成為Lenovo業務集團負責人。大概就是在這個時候，聯想內部傳出劉軍將成為接班人的傳聞，畢竟他掌管代表未來的移動業務。而在此之前另外一位大將陳紹鵬已被調到聯想控股負責農業板塊，陳本來是另外一位接班候選，將陳紹鵬調走外界多認為這是柳傳志的安撫之舉。
附：楊元慶與移動業務管理團隊內部溝通會講話速記
很多人都很驚訝，也都很想知道為什么做這個變化。這當然跟我們現在的業務狀況有關系，但我相信每個人都知道，業務狀況是種什么瓜，得什么果，是長期積累的結果。我們的個人電腦業務，在過去這些年突飛猛進，并不是一日之功，也是經過很長時間的準備，積蓄能量，把核心競爭力建立起來之后，才有后來的騰飛(take off)。
這次的調整，無關乎責任，而關乎機遇。當然我們應該從過去吸取經驗和教訓，但我們更要關心未來怎么做，未來有什么樣的機會。如果大家要記住一個理由，一個原因，一個詞，那就是CHANGE(改變)。今天的狀況，很大的原因就是我們用過去做事情的經驗來做新的業務，我們在PC上的成功經驗，想用在手機上;我們傳統的經驗，想用在互聯網時代……
正是這些根深蒂固的mindset(意識)的東西，這些深入到基因的東西，造成了今天的結果和狀況。所以，不變化，肯定不會看到成功的結果。這就是最重要的，最根本的原因。
我們過去做PC，產品比較簡單，所謂用戶體驗，更多不是由我們掌控，而是由微軟掌控，所以我們只要把硬件跟操作系統弄順了就行。但現在，用戶體驗每一家都不同，它不是由Android掌控，谷歌掌控，而是由我們掌控，尤其是在中國，這對我們做產品提出了更高的、更苛刻的要求。
互聯網提供了直接接觸用戶的方式。今天我們可以跟用戶直接互動，了解他們的需求，響應他們的反饋，對產品做快速的開發和迭代，讓用戶體驗最優。
過去我們的銷售方式也是很傳統的，從分銷商、代理商、零售商，再到用戶，手機渠道，40%多的利潤+費用，而小米們沒有這些，我們怎么跟他們競爭?
營銷也一樣，這已經不是大把撒錢的時代了，而是靠腦子、靠智慧營銷的時代。我們現在開始用微博、用微信，才意識到過去有多吃虧。如果今天有上千萬的粉絲，只要發一個微博，那就是廣告，一分錢都不用花。
在此之前，別人已經做了多少免費的廣告?過去我們是有變化，但只是把傳統媒體轉到了數字化媒體(網絡媒體)，沒想到社交媒體已經如火如荼，讓競爭對手們占了那么大的便宜!直到開始做了，才有所體會，做的好，做的差，確實是天壤之別。
所有的環節，昨天和今天都已經不同。所以我們需要CHANGE。但是我們這支團隊，大家可以反省一下，想一想，你們覺得變了嗎?你們覺得變得夠了嗎?
這已經不是PC時代，只要靠運營，加上渠道和品牌的優勢就能取勝?，F在需要的競爭力已經完全不同。
我去年跟你們說了幾次，要醒一醒，我甚至還說了你們拿榔頭敲都敲不醒，你們太慢了，在錯失機會。當然，從今年年初開始看到了一些變化的跡象，比如做精品，建on line模式，上微博等等。但是肯定不夠，不夠到位，也不夠快。
這就是我們這次調整的意義所在，我們希望能夠給這個團隊，給這個業務帶來更多的變化。這個變化要從頭開始，所以首先要從領導人開始，從調整一把手開始。我們希望通過這樣的調整，給這個團隊注入更多活力，讓變革來得更徹底，更到位，更猛烈些。
我相信旭東能給這個團隊，給這個業務帶來很多新的經驗、新的能力。他在中國開展業務轉型，已有相當一段時間。當然，PC和手機不一樣，旭東也不能固步自封。
如何從傳統模式轉向on line和off line結合，在這些方面他還是很有想法的。他在神奇已有半年，在如何把產品做精，與用戶互動上，也有更多、更深的體驗。他有更強烈的互聯網思維和基因。#p#分頁標題#e#
現在這個互聯網時代，尤其是在中國，一方面是要把產品做精做好，但是市場端，如果不能拉住粉絲，不能讓粉絲幫著推廣，是不可能把產品推廣好、銷售好的。相信旭東在市場端的優勢，會給團隊非常多的啟發和經驗的輸入。
而且在這個互聯網的時代，要更加積極，更加進取，不能被動，不能保守。這些方面，旭東也都是強項，他喜歡嘗鮮，喜歡嘗試，喜歡冒險，他有開放的心態，能夠擁抱互聯網，這些都是我們需要有的精神。
另外，旭東比較open，國際化的經驗也相對豐富，和國際團隊的溝通沒有什么障礙和芥蒂，容易溝通，容易合作。
這點之所以重要，是因為此時，除了要給中國團隊注入新的基因，尋求變化和突破以外，還有很重要的一條，是下一步要讓MOTO和聯想的業務有更深入的整合，更好地實現協同效應。我們相信在旭東的帶領下，你們能夠把這件事情做好。
這也給大家提出了更高的要求，以更開放的心態接受調整、配合調整，以使得兩個業務合起來不僅有更多的協同效應，還能為未來建立更扎實的基礎。
最后一點，我們這個團隊，在過去兩年里，業績都是跟預算有差距的，沒有達成目標，去年尤為低，造成士氣不高，這種情形不能再繼續下去了。要想建立一個成功的業務，就必須建立一支有求勝心、并且不斷去贏的團隊。
所以我們要認真做組織整合的方案，要認真地去重定戰略、策略，認真做業務計劃和目標設定。
在做了新的調整之后，就要重新啟動，在重新啟動之后，就要本著聯想說到做到的文化，一步一個腳印地，每一步都踩到點子上，達成目標，真正成為勝利之師!
你們都經歷過聯想的成功。大家都知道2009年，我重新擔任CEO之后，給董事會提交了4年計劃，之后的每一年，都打超了目標，從而不僅讓業務成功，更讓士氣大振。
大家不但想到更高的目標，而且能實現，能打超，然后在這樣的情況下，大家再討論戰略也好，再討論目標設定也好，才會更加火花四溢，激情飛揚，這才是一個勝利之師應該有的情況。我們希望這支團隊，從現在開始，能夠重新看到這樣的精神頭和士氣。
所以說，求變，跟MOTO實現深入整合，以及要建立贏的文化，這就是我們這次做調整的意圖所在。
在座都是聯想的精英，有的久經考驗，有的新加入聯想，是沖著我們的品牌、文化和機會而來，我們在一起，所要從事的工作，其實是一個非常神圣，非常了不起的事，不僅是聯想的戰略重點，而且從技術發展趨勢看，也是產業發展、技術突破的重要方向，我們要把握這個機會，一起努力配合旭東，把這個事情做漂亮，做成功!
文章分類:IT新聞]]>
人和機器人PK，誰能贏?如果放在新聞媒體這個領域上，最近進行的一場比賽或許能給你一個答案。
近日，NPR(美國國家公共電臺)向一臺可以寫新聞的機器人“WordSmith”發起了挑戰，NPR派出的選手是駐白宮記者Scott Horsley，他是國外媒體公認的寫作能手。
在Dennys餐飲公司的財報公布后，Scott Horsley用了7分鐘寫完了這條新聞，而WordSmith只花了2分鐘，但是在稿件質量上，依舊是Scott Horsley獲得了更多人的支持。
好了，比賽結束，回到現實。
此前人們對機器人用途的印象還停留在代替人類從事簡單機械的重復勞動上，隨著人工智能化程度越來越高，機器人可從事的工作領域也越來越廣。
去年7月，美聯社與Automated Insights公司合作，引入其WordSmith平臺自動生產財報報道，此后美聯社每季度報道的財報新聞數量從之前的300多篇增長到4400篇，幾乎可覆蓋美國所有上市公司。
此舉不光引起了新聞界嘩然一片，也使得人們開始密切關注這個會寫新聞的機器人。
使用機器人寫作的媒體有哪些?
其實美聯社并非是第一家使用機器人寫作的媒體，《洛杉磯時報》曾用由其記者兼程序員Ken Schwenck開發的Quakebot系統寫作了關于一場4.4級的地震的報道，整個過程耗時僅3分鐘，《洛杉磯時報》由此成為最快報道這一突發事件的媒體。此外，《洛杉磯時報》還有另一套報道犯罪新聞的程序。
Automated Insights公司表示，除美聯社之外，WordSmith合作媒體還有美國最大的有線電視運營商康卡斯特，雅虎也曾用WordSmith生產“夢幻橄欖球(Fantasy Football)”報道。
Automated Insights的競爭對手Narrative Science也有一套自動撰寫新聞系統，包括《福布斯》在內的20多家媒體都是這套系統的客戶，《福布斯》曾使用Narrative Science的服務制作收益預覽，還有許多體育網站也使用該公司提供的技術生成實時賽事回顧。
機器人如何寫新聞?
由于機器人有極強的信息抓取和數據處理能力，為提高工作效率，越來越多媒體雇傭起“機器人員工”，讓其著手體育賽事、突發事件、財經、數據分析等報道工作。
由于財報、體育報道、突發事件等新聞的寫作模式相對固定，機器人接收到新聞數據信息后可瞬間反應，將其填入模板，大大加快了寫作速度。并且據美聯社稱，Wordsmith撰寫的文章錯誤率比人工撰寫的文章更低，現在已無需人工干預。據悉，Wordsmith平臺每周可以撰寫數百萬篇新聞報道，系統每秒甚至能生產2000篇文章。
機器人記者的出現不光縮短了從事件發生到稿件出爐之間的時間差，還能大大降低媒體報道成本。據《紐約時報》證實，美國十大體育電視網在2009年到2010年賽季期間，使用電腦軟件寫作簡要報道占據足球賽事報道的40%，每篇500字左右的新聞報道僅耗資10美元。
當人們擔心機器人會不會搶了記者、編輯們的飯碗時，業界卻有不少人士對于二者間“各司其職”的關系樂觀看待。
對于記者們來說，整理、編輯枯燥乏味的體育賽事綜述、財經報道等簡單事實類新聞，無異于對智力和時間的浪費。
美聯社的執行總編費拉拉表示，自動寫稿的機器人可以將記者解放出來，撰寫更有深度的稿件。當然，美聯社對蘋果、谷歌(微博)等受市場高度關注企業的財報新聞還是謹慎地選擇人工操作。
《紐約》雜志商業與科技版撰稿人凱文•羅斯也非常歡迎“機器人新同事”，并表示從長期來看，啟用自動化的報道對新聞記者來說是最大的好消息。
人工寫作還有未來嗎?
盡管機器人寫作耗時短、成本低、產量高，但并不意味著機器人能超越人類，因為“機器人記者”們本身就存在著難以克服的成長障礙。
首先，機器人可操作的新聞題材有限，只能進行需要數據信息轉述和簡單分析體育賽事、財經類等報道，對于需要運用記者親身采訪和經歷的內容的深度報道無能為力;
其次，從目前來看，機器人整理好數據之后進行簡單歸納，盡量用正確的語法使語句通順，但難免措辭生硬，連美聯社的費拉拉也不得不承認機器人撰寫會因內容生硬和重復影響稿件質量。#p#分頁標題#e#
最后，機器人無法按照人類閱讀的喜好和習慣來生產可讀性高的文字，只能按照“預設的邏輯規則”來辨認數據中的事實和關鍵趨勢，然后從詞庫中選取恰當的詞匯進行描述，相比人工寫作運用靈活的邏輯組織稿件和用生動的語言風格來打動讀者，“機器人記者”們只能自嘆不如。
因此，從整體來看，機器人參與創作的新聞偏于事實類報道，而對于分析、解讀、抒情題材類的新聞，仍需要大量的人工編輯。
機器正在取代人類的工作。IBM的深藍曾經打敗過世界棋王。在這個智能時代，即使是最有創造性的工作之一：寫作，也是可以由機器完成的。
雅虎和美聯社的相當一部分財報和體育新聞都是機器人寫的。它們使用的都是一家叫做Automated Insights的公司開發的軟件WordSmith。只要導入最新的數據，1分鐘最快可以生成2000篇報道。
為了測試機器人和記者誰能寫出更好的報道，NPR的駐白宮記者，前任商業記者Scott Horsley和 WordSmith 進行了一場比賽。
比賽規則是： Horsley和WordSmith一起等Denny’s餐飲公司出財報，兩“人”同時開寫一篇短報道，比的主要是速度和質量。
Horsley開始很得意： 他是Denny家的?？?，甚至有熟識的侍應生知道他喜歡吃什么，他以為能在熟悉的題材中占上風。然而在速度上遭到了挫?。簷C器人兩分鐘就寫完了，他花了整整7分鐘。
不過質量上的結果相反。NPR在Polar上發起了投票。截至發稿時，機器人寫的文章獲得了912票，人類寫的獲得了9916票。Horsley的文章雖然更長一些，但語言更簡明易懂。
NPR的報道稱，機器可以通過學習寫得更好。通過學習一家媒體上的幾千篇文章，它能夠大致掌握語言風格，甚至玩些常見的梗。如果我司有一個WordSmith，它大概很快就能get到黃姓編輯和劉姓編輯是怎么回事。
而對媒體人來說，更理想的報道方式可能是， 讓機器人和記者打配合，前者負責快速、全面、準確地發消息，后者負責后續跟進和深入分析。
那么，在這個機器入侵的時代，最難被機器人取代的工作是什么?NPR給出的答案是精神健康和社工類的工作。這類工作只有0.3%的可能會被機器取代，因為它需要運用人的智力、協調溝通能力、還有最重要的人性的力量。而最容易被機器取代的工作則是電話推銷員，而且這已經成為了現實——現在連10086都自動打電話來催你交話費辦業務了。
常常覺得我司還是挺需要幾臺機器人的，只是不知道它們學不學得會中文。
文章分類:IT新聞]]>
一、問題：
許多測試類的書籍都有大幅篇章介紹用例的設計方法，如等價類劃分，邊界值，錯誤推斷，因果圖，判定表等。但實際應用中這些理論卻不能給我們很明確的行為指導，尤其是業務復雜，關聯模塊緊密，輸入標準和輸出結果間路徑眾多時，完全的遵循這些方法只能讓我們在心理上得到一種滿足，而無法真正有效的提高測試效率，并且我們也沒有足夠的時間和資源編寫完備的用例。通常我們只能依靠以前項目的用例編寫經驗(或習慣)，希望能在這一個項目中更加規范，但多數情況下我們規范的只是“書寫的規范”，在用例設計上以前存在的問題現在依舊。
當好不容易用例基本完成，我們卻發現面對隨之而來的眾多地區特性和新增需求，測試用例突然處于一種十分尷尬的境地：
* 從此幾乎很少被執行
* 已經與程序的實現發生了沖突(界面變動，功能變動)
* 執行用例發現的bug很少
* 根本沒有時間為新的功能需求增補用例
* 有時間補充，但用例結構越來越亂
* 特性的用例與通性用例之間聯系不明確(以新增需求為主線列出所有涉及到的更改，但特性與通行之間的數據或業務聯系在用例中逐漸淡化)
知道怎樣執行這個用例，但它要說明什么呢?(多數用例給我們的感覺是只見樹木，不見森林，只說明某一功能的實現，無法串起)
通過上面的一系列問題可以看到，似乎測試用例給我們帶來的問題遠多于益處，也正是因為在實際過程中遇到的問題積累，導致我們有很充分的理由忽視或拒絕用例的應用。
但沒有用例或簡略用例的編寫我們又會舒服很多么?不言自明，誰也不想倒退發展。
二、原因：
事實上我們在測試用例編寫和設計上遇到的一系列問題只是一種表面的呈現，究其原因我認為有如下幾點：
1、沒有適合的規范
“適合的規范”或稱“本地化的規范”。這是我們在測試過程中遇到的第一個問題，通常也是很容易習慣且淡忘的。我們擁有相當多的流程文檔、指導步驟和書本上的定義，但它適合我們當前的項目么?
每一個測試工程師在進入這個職業的初期都會了解一些測試上的概念和術語，進入公司或項目組后也會進一步學習相應的文檔，例如怎樣規范編寫，怎樣定義bug級別，軟件實現的主要業務等。但當測試經理開始給我們分配某一模塊的用例編寫時，又有多少人知道該怎樣去寫，怎樣寫算是好?
在測試論壇中常能看到介紹用例編寫方法的帖子，而迷茫于怎樣應用到實踐的回復也不為少數。為何我們無法在公司和項目組內找到明確且適合的規范?于是我們只得選擇從書本或之前的用例中復制，不管是結構還是方式都依賴于以往的經驗，我并不是說這樣就是錯誤的，但不能總結成文的經驗無法給予測試更多幫助。我們有太多經驗，但卻沒有形成適合的規范。
2、功能與業務的分離
我們知道怎樣列舉一個輸入框的用例，但卻很少考慮說明這個輸入框是用來做什么的，如果仔細分析不難發現，用例中這種功能與業務的分離越來越普遍也越來越明顯。
邊界值、等價類劃分、因果圖，這些用例方法是一種高度提純的方法，本身就很偏向于功能及代碼，所以怎樣編寫業務的用例我們就從理論上失去了參考。
復雜的業務會貫穿于整個軟件，涉及眾多功能點，里面組合的分支更不可勝數。測試用例務求簡潔、明確，這一點也與業務“格格不入”。功能用例依賴程序界面，業務描述依賴需求文檔。于是我們更偏向于根據已實現的界面編寫功能用例，列舉出眾多的邊界值、等價類。流程的操作只有憑借經驗和理解，這時測試出的bug是最多的，但我們卻無法使這個bug對應到一個用例中(點擊一個按鈕報出的錯誤有時原因并不在這個按鈕或按鈕所在的窗體)，只能自己添加note向開發人員指出可能出錯的源頭。正因為我們沒有很好的積累業務上的用例，才使得我們感到執行用例時發現的 bug不多。#p#分頁標題#e#
用例結構的劃分一定程度上也造成了功能和業務的分離，依照界面模塊建立文件夾，并在其中新建不同用例，這使得用例從結構上就很難聯通起來。
3、測試未能跟上變化
變化!想象一下，當我們越來越多的聽到開發人員在那里高呼“擁抱變化”“敏捷開發”的時候，測試又有什么舉措呢?當地區特性，軟件版本越來越多的時候，測試是否在積極響應呢?變化是我們面臨的最大挑戰，我認為測試未能跟上變化是造成測試過程中遇到種種問題和矛盾的主要原因。
對需求和程序的變化測試人員的感受是非常深的，測試總是跟在需求和開發后面跑，使得所有風險都壓在自己身上。不斷壓縮的時間和資源使我們只能放棄那些“不必要”的工作：盡快投入測試，盡快發現bug，而非從整體把握軟件的質量情況，統籌策略。
疲于應對的直接影響就是程序質量無法準確度量，進度無法控制，風險無法預估。用例與程序脫節，新增用例混亂和缺少。長此以往我們只得放棄修改、增補用例，甚至放棄之前積累的所有成果。用例變為程序變更的記錄摘要，沒有測試數據的保留，測試步驟和重點無法體現，新加功能與原來的程序逐漸“脫離”，可能還會出現相互違背的情況，但這我們卻無法及時發現。
永遠是變化決定我們的下一步工作，這也是混亂的開始。
三、可能的解決辦法：
上面的問題也許在成熟的公司和項目組內很少遇到，而遇到問題的也需根據不同的情況單獨考慮。分析錯誤并不能給我們帶來成功，而成功的特質也不會盡為相同。所以在這里我希望以探討的方式提出一些可能的解決辦法，不拘泥形式，以結果來確定，最適合的就是最好的。
1、測試驅動開發，用例指導結果，數據記錄變化
“測試驅動開發”(TDD)是一個比較新的概念，在網上可以看到很多介紹文章，它主要討論如何讓開發的代碼更奏效(Work)更潔凈(Clean)，“測試驅動開發的基本思想就是在開發功能代碼之前，先編寫測試代碼”?？梢钥吹?，TDD是建立在“代碼”級別的驅動，但目前我們需要探討的問題是怎樣在黑盒測試中做到“測試驅動開發”。
首先我們需要糾正一個態度，很多人認為黑盒測試的技術含量不高，可思考可拓展的內容不多，主要的工作就是用鼠標在那里瞎點，于是很多“高級”的技術方法都試圖與黑盒測試劃清界限。但測試人員發現的bug有80%以上都是黑盒測試發現的，手工操作軟件仍是目前檢驗軟件質量最有效的一種方法。
如何在黑盒測試中做到測試驅動開發?我認為可以從用例級別做起，以業務用例指導實現的結果。
開發人員通常比較關注技術，對于業務上的理解容易忽視并出現偏差，而需求文檔又不會很全面的指出應該實現怎樣的結果，這就使得從業務到功能出現一個“閱讀上的障礙”，如果最后發現程序錯了還需返工，這樣耗費的人力物力就非常大了。測試人員和最終用戶不用過分關心軟件實現的細節，所以以業務用例驅動開發，就是一個比較好的方法。給出一個明確的預期結果，指導開發人員如何界定是否達成目標，同樣這也需要運用測試中的各種方法，列舉出業務流程里數據的等價類和邊界值。
業務用例的構造要先于程序實現，與需求和開發人員溝通一致，并以此作為一個基準，保證程序實現不會出錯，還能對整個軟件的進度和質量有一個很好的估計和度量。業務用例可以不關注程序的界面，但一定要有數據的支持。這就是測試主導變化的另一點“數據記錄變化”。
我們不僅要應對變化，還要記錄變化，使測試用例成為對程序持續性的監控，數據可以作為最基本、最簡單的支持。當一個業務很復雜時可以拆分成段(業務段與程序中以窗體或頁面的劃分是不一樣的)，使用典型的用例方法列出實際輸入和預期結果。我們希望數據能做到通用和共享，最理想的情況就是建立一個“數據庫”，每個業務用例都從“數據庫”中取得輸入數據和預期結果，這個數據只是針對業務入口和出口的，當程序內部設計變更時，保留的數據不會因此而作廢。舉一個例子，例如我的程序要從某種文件中讀取數據并計算結果，一段時間后程序內部字段增加了，如果是以保存的文件附件方式提供數據，則現在程序很可能就打不開這個文件了。使用“數據庫”指導測試人員可以在變化的程序里直接針對業務輸入，而不關心程序內部結構。#p#分頁標題#e#
再進一步的話“數據庫”就開始涉及到程序內部的接口，屬于單元和集成測試，這需要開發人員的配合。
2、為用例標明時間(版本)和優先級
為測試用例標明時間或版本可以起到一種基準的作用，標明項目進度過程中的每一個階段，使用例直接和需求基線、軟件版本對應。同樣這需要規范流程，也是對變更的一種確認和控制?；蛘呖梢詾橛美黾右粋€狀態，指明這個用例目前是否與程序沖突，當程序變更時改變用例的狀態，并更新用例版本。
為測試用例標明優先級可以指出軟件的測試重點、用例編寫的重點，減少用例回歸的時間，增加重點用例執行的次數，幫助項目組新人盡快了解需求，在自動化測試的初期也可以參考這個優先級錄制腳本。
3、功能用例與業務用例分開組織
為業務用例單獨開辟出一種分類，將功能用例與業務用例分開組織，按照不同關注點列舉執行路徑。業務用例應在開發前或同期編寫，幫助測試人員和開發人員明確業務，了解正確流程和錯誤流程。功能用例更依賴于程序界面的描述，但功能用例并不等于使用說明。對某些模塊的等價類、邊界值測試會發現很多嚴重的bug，也許與業務無關，但用戶往往很容易這樣操作(例如登錄名，你是否考慮到很長的名字，或者用戶的鍵盤有問題，總是敲入n多空格在里面，這與業務無關，但程序將會怎樣處理?)。
4、審核用例，結對編寫
測試組長或經理對用例進行審核可以做到用例的補充和校對，但一般情況下是很難做到的，我們可以采用另一種方法，就是結對編寫測試用例(前提是你有兩個以上的測試人員)，內部審核。
測試用例不是自己編寫自己執行，它需要其他測試人員都能讀懂且明白目標所指。結對編寫可以盡量減少個人的“偏好習慣”，同時也能拓展思維，加強測試重點的確認，小組內部達到統一。一定程度上結對編寫也可以減少組長或經理對用例的管理負擔，提高組員的參與積極性。
四、發展
上面的這些解決方法只是一種建議，具體如何實施到項目中還需根據情況而定。同時即使我們正在積極的尋求改變，我們還是會碰到無數的新問題和新苦惱，也許會比以前更為眾多，這是我們必須付出的。
可以看到測試的發展方向很多很廣，即使傳統的黑盒測試并不是毫無新意，高級的測人員必須同時在測試技巧和專業領域方面都有很高的“修為”。測試工作怎樣更適合我們而發展，將給予我們更多的思考。
文章分類:測試用例]]>
測試經理不知道性能測試人員在做什么
不知道性能測試進展如何
不知道性能測試是否有效
不知道如何協助性能測試人員
本文目的
了解性能測試的進展，更好的控制整個測試流程
了解性能測試的質量
十問
性能測試何時介入
性能測試的過程是怎樣的
是否有必要提起性能測試
性能測試有哪些類型
如何分析性能需求
如何衡量性能
性能測試(不)能做什么
如何檢驗性能測試的質量
…
Q1、性能測試何時介入
開發生命周期中的性能測試
單元測試
代碼層面的測試。寫完一塊代碼，對代碼的執行效率、內存使用、資源占用等情況進行測試，由開發人員完成。
組件/服務/接口測試
此層面的測試，通常是針對一個已完成的公用功能，此功能向外提供服務或者接口。既可以是代碼級別的測試，也可以是不涉及代碼的調用測試(如webservice接口)，應由測試人員完成。
系統測試
整個系統已經實現，通過模擬用戶的使用對系統進行測試。我們做的性能測試主要就是這個，由測試人員完成。
生產環境測試
在系統測試通過的基礎上，構建出更完整的生產環境。比如一個生產環境，部屬多個系統，這些系統共同使用時可能會相互影響，需要考慮到此種情況進行測試。
系統測試中，何時介入呢
穩定版
→ 進入太晚，進度無法保證
→ 可能會影響到功能測試
這是測試負責人最害怕的，即測試晚期發現性能問題，修改涉及面較大，造成功能測試返工。
盡早
→ 流程可跑通
→ 數據無嚴重問題
等到穩定版再進入是不靠譜的，要盡早。
盡早到什么時候，性能測試需要哪些流程和數據呢?關注性能方案中的用戶模型。
Q2、性能測試的過程是怎樣的
敏捷方式的最大特點就是不斷確認、不斷修正、多次迭代。
在傳統方式的測試過程中，經常出現的問題恰恰是缺少了敏捷思想中的確認過程，導致了測試方向偏離、測試有效性不夠
當前進展到哪個階段?
文檔
步驟1～3
執行
步驟4～7
在傳統方式中，可以很簡單的將過程分為文檔和執行兩部分。文檔過程很容易被檢查，問題主要是在執行過程，這個過程有可能對測試經理是不可見的。
考慮這個問題：如果一次性能測試，沒有提起任何問題，是否在性能報告之前的執行過程是不可知的?
如果現有的工作方式確實存在這個問題，該如何解決呢?
這就需要依靠性能測試執行過程規范和檢查制度，請繼續往后看。
Q3、是否有必要提起性能測試?
新項目
目前基本都需要進行性能測試。
新版本(哪些變化可能涉及性能)→ 用戶量
用戶數的增加，如推廣使用、知名度提高。
→ 數據量
數據量的增加，如分布式部屬變成集中式部屬。
→ 實現改變
架構實現的變化，如音視頻點播系統更換了流媒體服務器。
測試負責人的疑問主要是新版本需不需要再做一次性能測試?比如只新增加了一個功能。
拋開上面提到的3個方面，新增功能或模塊可能會引起性能測試用戶模型的變化。如果經過確認，用戶模型無需變化，那自然也沒必要重新測試。如果用戶模型確實發生了改變，其實我覺得是有必要再次執行測試的，畢竟性能測試也算是一種自動化的測試，就應該能夠持續性的運行。
只不過我們現在的問題是，性能測試的復用性太低，基于HTTP請求的腳本很容易失效，測試環境也總需要重新搭建，這些因素導致了性能測試的成本和投入變大，即使只是增加了一個小功能，可能也需要重頭來做一次性能測試。如果有辦法改變這個狀況，那么每次新版本只要補充一下相關的測試代碼就可以了。#p#分頁標題#e#
我的想法是，性能測試要向組件/服務/接口級別靠近(見Q1)，越接近底層，可復用性也就越高。另外，企業級虛擬化的建設一定要跟上，這樣才不會在測試環境上浪費時間。
Q4、性能測試有哪些類型
基準測試
比如單用戶的測試或者在無數據條件下的測試，目的是提供一個標準供后續測試比對。
負載測試
向系統施加一定的壓力，一般最大壓力的20%或者日常使用壓力即可，確保系統可正常運轉。
壓力測試
向系統施加預期最大壓力，測試系統在繁忙狀態下的性能表現。
容量測試
不斷的增大對系統的壓力，直至出現瓶頸。用于探測系統的瓶頸，為系統的發展提供重要信息。
穩定性測試
長時間運行的穩定情況。
還有很多其他類型的測試，這里只是列出了幾種最常用到的，術語的定義可能也和其他資料有些差別，比如負載和壓力，不過無關緊要。
這里需要注意的一點，在負載、壓力和容量測試中，測試的依據都是用戶模型，只有用戶模型準確，測試的結果才會有意義。
提起性能測試，需要做那種測試呢?
一般來說，除了容量測試，其他幾種都是要做的，這是得到有效測試結果的必備過程。容量測試，屬于獲取“額外信息”的測試，不過這種測試其實是非常有價值的，很多資料都把它列為了必做之一。
穩定性測試需要運行多長時間?
之所以會有這個疑問，其實是因為測試人員提供的結果數據沒有說服力，不是證明了系統可以長期穩定運行，而只是下了個系統穩定的結論。
我也總和性能測試人員強調，測試的結果是要用數據來證明的，不是說測完了下一個通過的結論就可以了，這樣自然要被測試經理、開發經理懷疑(尤其是你是一個新人)。
如果能夠提供各種詳盡的數據，比如測試運行12小時內，操作系統的資源利用情況、應用中間件內部的資源利用情況、甚至是程序內部的一些性能指標等等，如果這些指標足夠代表系統的性能，且它們的表現是非常平穩的，那么完全可以從這個趨勢推斷出，即使系統運行更長的時間也將是穩定的。
反之，如果不提供數據，而只是描述測試運行了3天，那么自然會有“3天夠不夠長”的疑問，只有通過“足夠長”的運行時間才能減少人們的顧慮。
Q5、如何分析性能需求
性能相關需求一般由需求人員提供，測試負責人是這些需求的第一個把關人。針對這些需求，測試負責人可以分析哪些內容呢?
是否全面
用戶角度
→ 能不能
→ 快不快
業務角度
→ 吞吐量、TPS、每小時完成工作量
→ 處理壓力的方式
如12306購票，當壓力太大的時候，是讓所有人都能得到非常慢的服務，還是保證一部分人可以正常使用、另外的人停止服務?
技術角度
→ 是否使用了某些有潛在風險的技術
→ 系統內部的一些資源
其他角度
→ 比如系統擁有者，要求服務器資源利用率60%左右，想想為什么?
是否有效
可行性
要求發送短信后能即時到達。這就是不可行的需求，因為涉及到運營商的網絡。
可量化
郵件發出后，較短的時間內到達。
是否靈活
需求vs.期望
→ 需求是必須要達到的。比如發送即時消息，必須保證沒有丟失，這時可能就要有一個到達率的指標，如果達不到100%，那就是不合格。
→ 期望是靈活的，比如頁面響應時間3s以內，這就是一個期望，不會因為最后是3.2s而影響結論或者導致延期發布。
Q6、如何衡量性能
性能的評價標準
用戶感受
用戶實際的感受是最權威的評價標準。
明確的性能指標
但大多數情況無法用實際感受來進行衡量，所以我們需要能夠有效代替“感受”的數據，也就是各種性能指標。
性能指標一般有哪些
響應時間
業務類web系統一般主要耗時在服務端，所以通常獲取請求的響應時間即可，這是不涉及到客戶端展現的。#p#分頁標題#e#
頁面展現時間
互聯網網站通常最關注展現時間，一般有更具體的指標如首屏展現時間。大家用一用淘寶或者京東就能理解了。
吞吐量
TPS
業務上的需求，比如百度一定會有每秒鐘處理多少萬次搜索請求這類的指標。
特定需求的評估標準
如上面舉的例子，消息到達率。
這些對性能的評價標準，應該在測試設計時就明確下來，測試負責人可對此進行檢查。
有一點需要注意的是，性能指標是否可檢測。通用的指標如頁面響應時間很容易獲取，所有的測試工具都可以做到。但一些特殊的指標，尤其是涉及到客戶端的，可能會存在技術上的問題。比如即時通訊軟件的測試中，要求最大壓力時，發送信息能夠在1s內到達。那么這個到達時間如何獲取呢?如果沒有提前做好準備，在測試執行時很可能會遇到問題，而測試人員遇到這個問題，很有可能會選擇忽視它，只顧把壓力加上去就算測完了。
Q7、性能測試(不)能做什么
web系統性能測試
最常見的目的是模擬用戶的實際行為，獲取用戶的感受。
如何模擬用戶的實際行為
建立用戶模型。即用戶做什么操作、操作路徑是什么、操作頻率……
如何建立用戶模型
常用業務
性能敏感業務
關鍵業務
特殊關注
這里只是用戶模型覆蓋度的問題，實際使用的用戶模型還需要很多其他信息才能建立起來。
測試負責人需要重點關注和確認用戶模型的建立。
性能測試的覆蓋率
由上可知，性能測試只能覆蓋系統的一部分功能。不要指望所有和性能相關的問題都由性能測試來發現。
性能測試最最想發現的是瓶頸，而不是缺陷。
我比較害怕聽到這樣的話，“生產環境的一個操作很慢，去做下性能測試吧”。
Q8、如何檢驗性能測試的質量
執行過程
建立執行規范
明確定義執行過程各檢查點需要的輸出物
指派檢查人員
根據執行規范進行檢查
輸出執行記錄
測試人員都知道，設計的用例和實際的執行總是不一樣的。性能測試更是如此，調整參數重新運行腳本也是一次執行，這些信息必須有清晰的記錄。
持續交互確認
性能報告
讓數據證明結論，而不是下結論
文章分類:性能測試]]>
隨著我國加入WTO，各行各業都面臨更多的機遇和挑戰。如何提高產品的質量，增強市場競爭力，日益成為企業發展必須解決的迫切問題，對軟件企業來說尤為重要。軟件企業要直接參與國際軟件市場的競爭，首要問題就是要保證軟件的質量，同時要加快軟件產品的發布與交付使用。因此，如何提高軟件質量，越來越成為當前軟件產業發展中一個迫在眉睫的問題。本文只針對軟件質量的性能方面，做一些探討。
2、軟件質量
質量保證能力的強弱直接影響著軟件業的發展和生存。那么，到底什么是軟件的質量呢?《GB/T 16260 信息技術 軟件產品評價 質量特性及其使用指南》明確定義：軟件質量是軟件產品具有滿足明確的或隱含需求能力的特征和特性總和。具體包括以下六個方面的質量特性：
1)功能性
與一組功能及其指定的性質有關的一組屬性。這里的功能是指滿足明確或隱含的需求的那些功能。
2)易用性
與一組規定或潛在的用戶為使用軟件所需作的努力和對這樣的使用所作的評價有關的一組屬性。
3)可靠性
與在規定的一段時間和條件下，軟件維持其性能水平的能力有關的一組屬性。
4)效率
與在規定的條件下，軟件的性能水平與所使用資源量之間關系有關的一組屬性。
5)可維護性
與進行指定的修改所需的努力有關的一組屬性。
6)可移植性
與軟件可從某一環境轉移到另一環境的能力有關的一組屬性。
因此，為了評價軟件產品的質量，需要對軟件質量的每個特性實施和執行測試. 隨著現代軟件構架技術的發展，特別是WEB技術的發展，與軟件可靠性、效率質量特性相關的軟件性能問題越來越受到包括軟件從業人員、專家學者以及軟件使用者的重視，軟件的性能指標的好壞已直接影響到軟件的質量。
3、軟件性能測試技術
軟件性能的測試一般包括三個方面，即性能評測、負載測試和強度測試。每一方面的測試都有其不同的測試目標、測試技術、完成標準，具體如下：
3.1 性能評測
針對響應時間、事務處理速率和其他與時間相關的需求進行評測和評估。目標是驗證性能需求是否都已滿足。
測試目標：
驗證所指定的事務或業務功能在以下情況下的性能行為：
(1)正常的預期工作量
(2)預期的最繁重工作量
測試技術：
使用為功能或業務周期測試制定的測試過程。
(1)通過修改數據文件來增加事務數量，或通過修改腳本來增加每項事務的迭代數量。
(2)腳本應該在一臺計算機上運行(最好是以單個用戶、單個事務為基準)，并在多個客戶機(虛擬的或實際的客戶機)上重復。
完成標準：
(1)單個事務或單個用戶：在每個事務所預期或要求的時間范圍內成功地完成測試腳本，沒有發生任何故障。
(2)多個事務或多個用戶：在可接受的時間范圍內成功地完成測試腳本，沒有發生任何故障。
注意事項：
綜合的性能測試還包括在服務器上添加后臺工作量。 可采用多種方法來執行此操作，其中包括：
(1)直接將“事務強行分配到”服務器上，這通常以“結構化查詢語言”(SQL) 調用的形式來實現。
(2)通過創建“虛擬的”用戶負載來模擬許多個(通常為數百個)客戶機。此負載可通過“遠程終端仿真”(Remote Terminal Emulation) 工具來實現。此技術還可用于在網絡中加載“流量”。
(3)使用多臺實際客戶機在系統上添加負載。
(4)性能測試應該在專用的計算機上或在專用的機時內執行，以便實現完全的控制和精確的評測。
(5)性能測試所用的數據庫應該是實際大小或相同縮放比例的數據庫。
3.2 負載測試
負載測試通過使測試對象承擔不同的工作量，以評測和評估測試對象在不同工作量條件下的性能行為，以及持續正常運行的能力。目標是確定并確保系統在超出最大預期工作量的情況下仍能正常運行，以及軟件的性能特征，例如，響應時間、事務處理速率和其他與時間相關的方面。
測試目標：
驗證所指定的事務在不同的工作量條件下的性能行為時間。#p#分頁標題#e#
測試技術：
使用為功能或業務周期測試制定的測試。通過修改數據文件來增加事務數量，或通過修改測試來增加每項事務發生的次數。
完成標準：
多個事務或多個用戶：在可接受的時間范圍內成功地完成測試，沒有發生任何故障。
注意事項：
(1)負載測試應該在專用的計算機上或在專用的機時內執行，以便實現完全的控制和精確的評測
(2)負載測試所用的數據庫應該是實際大小或相同縮放比例的數據庫。
3.3 強度測試
強度測試目的是找出因資源不足或資源爭用而導致的錯誤。如果內存或磁盤空間不足，測試對象就可能會表現出一些在正常條件下并不明顯的缺陷。而其他缺陷則可能由于爭用共享資源(如數據庫鎖或網絡帶寬)而造成的。強度測試還可用于確定測試對象能夠處理的最大工作量。
測試目標：
驗證測試對象能夠在以下強度條件下正常運行，不會出現任何錯誤：
(1)服務器上幾乎沒有或根本沒有可用的內存(內存和磁盤空間)
(2)連接或模擬了最大實際(實際允許)數量的客戶機
(3)多個用戶對相同的數據或賬戶執行相同的事務
(4)最繁重的事務量或最差的事務組合
注：強度測試的目標可表述為確定和記錄那些使系統無法繼續正常運行的的情況或條件。
測試技術：
(1)使用為性能評測或負載測試制定的測試。要對有限的資源進行測試，就應該在一臺計算機上運行測試，而且應該減少或限制服務器上的內存和磁盤空間。
(2)對于其他強度測試，應該使用多臺客戶機來運行相同的測試或互補的測試，以產生最繁重的事務量或最差的事務組合。
完成標準：
所計劃的測試已全部執行，并且在達到或超出指定的系統限制時沒有出現任何軟件故障，或者導致系統出現故障的條件并不在指定的條件范圍之內。
注意事項：
(1)如果要增加網絡工作強度，可能會需要使用網絡工具來給網絡加載消息或信息包。
(2)應該暫時減少用于系統的磁盤空間，以限制數據庫可用空間的增長。
(3)使多個客戶機對相同的記錄或數據賬戶同時進行的訪問達到同步。
4、結束語
軟件質量的保證，不僅需要科學的測試策略，更要處理好整個軟件生命周期中其他如需求、分析、設計、實現各階段中出現的問題。只有對軟件質量進行全面、全過程的質量控制，才能最終保證軟件產品的質量，提高企業的競爭力。
文章分類:性能測試]]>
與性能計數器相關的另一個術語是“資源利用率”。該術語指的是系統各種資源的使用狀況。為了方便比較，一般用“資源的實際使用/總的資源可用量”形成資源利用率的數據，用以進行各種資源使用的比較。
性能測試之內存篇(windows)
要監視內存不足的狀況，請從以下的對象計數器開始：
· Memory\ Available Bytes
· Memory\ Pages/sec
Available Bytes剩余的可用物理內存，單位是兆字節(參考值：>=10%)。表明進程當前可使用的內存字節數。Pages/sec 表明由于硬件頁面錯誤而從磁盤取出的頁面數，或由于頁面錯誤而寫入磁盤以釋放工作集空間的頁面數。
如果 Available Bytes 的值很小(4 MB 或更小)，則說明計算機上總的內存可能不足，或某程序沒有釋放內存。如果 Pages/sec 的值為 20 或更大，那么您應該進一步研究頁交換活動。Pages/sec 的值很大不一定表明內存有問題，而可能是運行使用內存映射文件的程序所致。
操作系統經常會利用磁盤交換的方式提高系統可用的內存量或是提高內存的使用效率。下列四個指標直接反映了操作系統進行磁盤交換的頻度。
Page Faults/sec
當處理器在內存中讀取某一頁出現錯誤時，就會產生缺頁中斷，也就是 page Fault。如果這個頁位于內存的其他位置，這種錯誤稱為軟錯誤，用Transition Fault/sec 來衡量;如果這個頁位于硬盤上，必須從硬盤重新讀取，這個錯誤成為硬錯誤。硬錯誤會使系統的運行效率很快將下來。Page Faults/sec這個計數器就表示每秒鐘處理的錯誤頁數，包括硬錯誤和軟錯誤。
Page Input/sec
表示為了解決硬錯誤而寫入硬盤的頁數(參考值：>=Page Reads/sec)
Page Reads/sec
表示為了解決硬錯誤而從硬盤上讀取的頁數。(參考值： <=5)
Pages/sec
表示為了解決硬錯誤而從硬盤上讀取或寫入硬盤的頁數(參考值：00~20)
必須同時監視 Available Bytes、Pages/sec 和 Paging File % Usage，以便確定是否發生這種情況。如果正在讀取非緩存內存映射文件，還應該查看緩存活動是否正常。
Cathe Bytes
文件系統的緩存(默認為50%的可用物理內存)
內存泄露
· Memory\Available Bytes
· Memory\ Committed Bytes
如果您懷疑有內存泄露，請監視 Memory\Available Bytes 和 Memory\ Committed Bytes，以觀察內存行為，并監視你認為可能在泄露內存的進程的 Process\ Private Bytes、Process\ Working Set 和Process\ Handle Count。如果您懷疑是內核模式進程導致了泄露，則還應該監視 Memory\ Pool Nonpaged Bytes、Memory\ Pool Nonpaged Allocs 和 Process(process_name)\ Pool Nonpaged Bytes。
private Bytes
進程無法與其他進程共享的字節數量。該計數器的值較大時，有可能是內存泄露的信號
檢查過于頻繁的頁交換
由于過多的頁交換要使用大量的硬盤空間，因此有可能將導致將頁交換內存不足，這容易與導致頁交換的磁盤瓶頸混淆。因此，在研究內存不足不太明顯的頁交換的原因時，您必須跟蹤如下的磁盤使用情況計數器和內存計數器：
· Physical Disk\ % Disk Time
· Physical Disk\ Avg.Disk Queue Length
例如，包括 Page Reads/sec 和 % Disk Time 及 Avg.Disk Queue Length。如果頁面讀取操作速率很低，同時 % Disk Time 和 Avg.Disk Queue Length的值很高，則可能有磁盤瓶徑。但是，如果隊列長度增加的同時頁面讀取速率并未降低，則內存不足。
要確定過多的頁交換對磁盤活動的影響，請將 Physical Disk\ Avg.Disk sec/Transfer 和 Memory\ Pages/sec 計數器的值增大數倍。如果這些計數器的計數結果超過了 0.1，那么頁交換將花費百分之十以上的磁盤訪問時間。如果長時間發生這種情況，那么您可能需要更多的內存。
研究程序的活動
接下來，檢查正在運行的程序導致的過多的頁交換。如果可能，請停 止具有最高工作集值的程序，然后查看頁交換速率是否有顯著變化。如果您懷疑存在過多的頁交換，請檢查 Memory\ Pages/sec 計數器。該計數器顯示由于頁面不在物理內存中而需要從磁盤讀取的頁面數。(注意該計數器與 Page Faults/sec 的區別，后者只表明數據不能在內存的指定工作集中立即使用。)#p#分頁標題#e#
性能測試之處理器篇(windows)
監視“處理器”和“系統”對象計數器可以提供關于處理器使用的有價值的信息，幫助您決定是否存在瓶頸。需要包含下列內容：
Processor\ % Total Processor Time 獲得處理器整體使用情況。
該計數值用于體現服務器整體的處理器利用率，對多處理器的系統而言，該計數值體現的是所有CPU的平均利用率。如果該值的數值持續超過90%，則說明整個系統面臨著處理器方面的瓶頸，需要通過增加處理器來提高性能。
要注意的是，由于操作系統本身的特性，在某些多CPU系統中，該數據本身并不大，但此時CPU之間的負載狀況極不均衡，此時也應該視作系統產生了處理器方面的瓶頸。
監視 Processor\ % Processor Time、Processor\ % User Time 和 % Privileged Time 以獲得詳細信息。
Processor\ % User Time是指系統的非核心操作消耗的CPU時間，如果該值較大，可以考慮是否通過優化算法等方法降低這個值。如果該服務器是數據庫服務 器，Processor\ % User Time大的原因很可能是數據庫的排序或是函數操作消耗了過多的CPU時間，此時可以考慮對數據庫系統進行優化。
System\ Processor Queue Length 用于瓶頸檢測。
%Total Processor Time
系統中所有處理器都處于繁忙狀態的時間百分比，對于多處理器系統來說，該值可以反映所有處理器的平均繁忙狀態，該值為100%，如果有一半的處理器為繁忙狀態，該值為50%
File Data Operations/sec
計算機對文件系統進行讀取和寫入操作的頻率，但是不包括文件控制操作
Process Queue Length
線程在等待分配CPU資源所排隊列的長度，此長度不包括正在占有CPU資源的線程。如果該隊列的長度大于處理器個數+1，就表示處理器有可能處于阻塞狀態(參考值：<=處理器個數+1)
%Processor Time
CPU利用率，該計數器最為常用，可以查看處理器是否處于飽和狀態，如果該值持續超過 95%，就表示當前系統的瓶頸為CPU，可以考慮增加一個處理器或更換一個性能更好的處理器。(參考值：<80%)
%Priviliaged Time
CPU在特權模式下處理線程所花的時間百分比。一般的系統服務，進城管理，內存管理等一些由操作系統自行啟動的進程屬于這類
%User Time
與%Privileged Time計數器正好相反，指的是在用戶狀態模式下(即非特權模式)的操作所花的時間百分比。如果該值較大，可以考慮是否通過算法優化等方法降低這個值。如果該服務器是數據庫服務器，導致此值較大的原因很可能是數據庫的排序或是函數操作消耗了過多的CPU時間，此時可以考慮對數據庫系統進行優化。
%DPC Time
處理器在網絡處理上消耗的時間，該值越低越好。在多處理器系統中，如果這個值大于50%并且%Processor Time非常高，加入一個網卡可能會提高性能。
觀察處理器使用情況的值
要測量處理器的活動，請查看 Processor\ % Processor Time 計數器。該計數器顯示處理器忙于執行非空閑線程所耗時間的百分比。
檢查處理器使用時，請考慮計算機的角色和所完成工作的類型。根據計算機進行的工作，較高的處理器值意味著系統正有效地處理較重的工作負載或正在努力維持。例如，如果正在監視用戶的計算機，并且該計算機用于計算，計算程序可能容易使用 100% 的處理器時間。即使這會造成該計算機中其他應用程序的性能受到影響，但可以通過改變負載來解決。
另一方面，在處理許多客戶請求的服務器計算機中，100% 左右的值表示這些過程在隊列中，正在等待處理器時間，并且造成瓶頸。如此持續高層次的處理器使用對服務器而言是無法接受的。
考察處理器瓶頸
進程的線程所需要的處理器周期超出可用周期時，處理器瓶頸將逐步顯示出來?？梢越⑤^長的處理器隊列，并且系統響應會受到影響。處理器瓶頸兩種常見的原因是 CPU 限制程序和產生過多中斷的驅動程序或子系統組件。
要決定是否由于對處理器時間的要求較高而存在處理器瓶頸，請查看 System\ Processor Queue Length 計數器。隊列中包含兩個或更多的項目則表明存在瓶頸。如果多個程序進程競爭大多數處理器時間，安裝更快速的處理器會提高吞吐量。如果正在運行多線程的進程，附加處理器會有所幫助，但是請注意，附加處理器可能只有有限的益處。#p#分頁標題#e#
此外，跟蹤計算機的服務器工作隊列當前長度的 Server Work Queues\ Queue Length 計數器會顯示出處理器瓶頸。隊列長度持續大于 4 則表示可能出現處理器擁塞。此計數器是特定時間的值，而不是一段時間的平均值。
要決定中斷活動是否造成瓶頸，請觀察 Processor\ Interrupts/sec 計數器的值，該計數器測量來自輸入/輸出 (I/O) 設備的服務請求的速度。如果此計數器的值明顯增加，而系統活動沒有相應增加，則表明存在硬件問題。
也可以對生成中斷的磁盤驅動器、網卡和其他設備活動的間接指示器監視 Processor\ % Interrupt Time 時間。
注意
要檢測可能影響處理器性能的硬件問題，例如 IRQ 沖突，請觀察 System\ File Control Bytes/second 的值。
監視多處理器系統
要觀察多處理器計算機的效率，請使用下列附加計數器。
計數器
說明
Process\ % Processor Time
過程的所有線程在每個處理器上的處理器時間總和。
Processor(_Total)\ % Processor Time
計算機中所有處理器的處理器活動的度量。
“N[{y8_0此計數器采樣間隔期間的所有處理器平均非空閑時間的總和，并用處理器數目除以該和。51Testing軟件測試網
t#e_5I：N2y8@"a：X：Y
例如，如果所有處理器平均忙半個采樣間隔，則顯示 50%。如果半數處理器忙整個間隔，而其他的處理器空閑，則也顯示 50%。
Thread\ % Processor Time
線程的處理器時間數
性能測試之磁盤篇(windows)
監測對象：PhysicalDisk
如果分析的計數器指標來自于數據庫服務器、文件服務器或是流媒體服務器，磁盤I/O對這些系統來說更容易成為瓶頸。
每磁盤的I/O數可用來與磁盤的I/O能力進行對比，如果經過計算得到的每磁盤I/O數超過了磁盤標稱的I/O能力，則說明確實存在磁盤的性能瓶頸。
下表給出了每磁盤I/O的計算公式：
| RAID類型 | 計算方法 |
| RAID0 | (Reads+Writes)/Number of Disks |
| RAID1 | (Reads+2*Writes)/2 |
| RAID5 | [Reads+(4*Writes)]/Number of Disks |
| RAID10 | [Reads+(2*Writes)]/Number of Disks |
表示磁盤驅動器為讀取或寫入請求提供服務所用的時間百分比，如果只有%Disk Time比較大，硬盤有可能是瓶頸
Average Disk Queue Length
表示磁盤讀取和寫入請求提供服務所用的時間百分比，可以通過增加磁盤構造磁盤陣列來提高性能(<=磁盤數的2倍)
Average Disk Read Queue Length
表示磁盤讀取請求的平均數
Average Disk write Queue Length
表示磁盤寫入請求的平均數
Average Disk sec/Read
磁盤中讀取數據的平均時間，單位是s
Disk Bytes/sec 提供磁盤系統的吞吐率。
決定工作負載的平衡
要平衡網絡服務器上的負載，需要了解服務器磁盤驅動器的繁忙程度。使用 Physical Disk\ % Disk Time 計數器，該計數器顯示驅動器活動時間的百分比。如果 % Disk Time 較高(超過 90%)，請檢查 Physical Disk\ Current Disk Queue Length 計數器以查看正在等待磁盤訪問的系統請求數量。等待 I/O 請求的數量應當保持在不大于組成物理磁盤的主軸數的 1.5 到 2 倍。
Average Disk sec/Transfer
磁盤中寫入數據的平均時間，單位是s
計數器反映磁盤完成請求所用的時間。較高的值表明磁盤控制器由于失敗而不斷重試該磁盤。這些故障會增加平均磁盤傳送時間。一般來說，定義該值小于15ms最為優異，介于15-30ms之間為良好，30-60ms之間為可以接受，超過60ms則需要考慮更換硬盤或硬盤的 RAID方式#p#分頁標題#e#
Average Disk Bytes/Transfer
值大于 20 KB 表示該磁盤驅動器通常運行良好;如果應用程序正在訪問磁盤，則會產生較低的值。例如，隨機訪問磁盤的應用程序會增加平均 Disk sec/Transfer 時間，因為隨機傳送需要增加搜索時間。
性能測試之網絡篇(windows)
監測對象：Network Interface
網絡分析是一件技術含量很高的工作，在一般的組織中都有專門的網絡管理人員進行網絡分析，對測試工程師來說，如果懷疑網絡是系統的瓶頸，可以要求網絡仍有來寫真進行網絡方面的檢測。
Network Interface\Bytes Total/sec為發送和接收字節的速率(包括幀字符在內)?？梢酝ㄟ^該計數器的值判斷網絡連接速度是否是瓶頸，具體操作方法是用該計數器的值與目前的網絡帶寬進行比較。
Byte Total/sec
表示網絡中接受和發送字節的速度，可以用該計數器來判斷網絡是否存在瓶頸(參考值：該計數器和網絡帶寬相除，<50%)
性能測試之進程篇(windows)
查看進程的%Processor Time值
每個進程的%Processor Time反映進程所消耗的處理器時間。用不同進程所消耗的處理器時間進行對比，可以很容易的看出具體是哪個進程在性能測試過程中消耗了最多的處理器時間，從而可以據此針對應用進行優化。
查看每個進程產生的頁面失效
可以用每個進程產生的頁面失效(通過Process\Page Failures/sec計數器獲得)和系統的頁面失效(可通過Memory\Page Failures/sec計數器獲得)的比值，來判斷哪個進程產生了最多的失效頁面，這個進程要么是需要大量內存的進程，要么是非?；钴S的進程，可以對其進行中的分析。
了解進程的Process\Private Bytes
Process\Private Bytes是指進程所分配的無法與其他進程共享的當前字節數量。該計數器主要用拉判斷進程在性能測試過程中有無內存泄漏。
例如：對于一個IIS之上的web應用，我們可以重點監控inetinfo進程的Private Bytes，如果在性能測試過程中，該進程的Private Bytes計數器值不斷增加，或是性能測試停止后一段時間，該進程的Private Bytes仍然持續在高水平，則說明應用存在內存泄漏。
(備注：進程分析方法用到的計數器主要有：Process\%Processor Time、Page Failures/sec、Page Failures/sec、Private Bytes)
相關鏈接：
內存映射文件機制
內存映射文件是利用虛擬內存把文件映射到進程的地址空間中去，在此之后進程操作文件，就像操作進程空間里的地址一樣了，省去了讀和寫I/O的時間。
比如使用memcpy等內存操作的函數。這種方法能夠很好的應用在需要頻繁處理一個文件或者是一個大文件的場合，這種方式處理IO效率比普通IO效率要高。
利用內存映射文件您可以認為操作系統已經為您把文件全部裝入了內存，然后您只要移動文件指針進行讀寫即可了。這樣您甚至不需要調用那些分配、釋放內存塊和文件輸入/輸出的API函數，另外您可以把這用作不同的進程之間共享數據的一種辦法。運用內存映射文件實際上沒有涉及實際的文件操作，它更象為每個進程保留一個看得見的內存空間。至于把內存映射文件當成進程間共享數據的辦法來用，則要加倍小心，因為您不得不處理數據的同步問題，否則您的應用程序也許 很可能得到過時或錯誤的數據甚至崩潰。
內存映射文件本身還是有一些局限性的，譬如一旦您生成了一個內存映射文件，那么您在那個會話期間是不能夠改變它的大小的。所以內存映射文件對于只讀文件和不會影響其大小的文件操作是非常有用的。當然這并不意味著對于會引起改變其大小的文件操作就一定不能用內存影射文件的 方法，您可以事先估計操作后的文件的可能大小，然后生成這么大小一塊的內存映射文件，然后文件的長度就可以增長到這么一個大小。我們的解釋夠多的了，接下來我們就看看實現的細節：
1、調用CreateFile打開您想要映射的文件。
2、調用CreateFileMapping，其中要求傳入先前CreateFile返回的句柄，該函數生成一個建立在CreateFile函數創建的文件對象基礎上的內存映射對象。
3、調用MapViewOfFile函數映射整個文件的一個區域或者整個文件到內存。該函數返回指向映射到內存的第一個字節的指針。用該指針來讀寫文件。
4、調用UnmapViewOfFile來解除文件映射。#p#分頁標題#e#
5、調用CloseHandle來關閉內存映射文件。注意必須傳入內存映射文件的句柄。
6、調用CloseHandle來關閉文件。注意必須傳入由CreateFile創建的文件的句柄。
文章分類:性能測試]]>
在開發人員完成他們的測試之后，我將會出于兩個具有代表性的原因來審查他們的工作。第一，我想要在和客戶交流時能夠說出應用軟件是什么樣子和它如何工作。第二，我想要看一看有沒有什么顯而易見的錯誤可以在客戶看到結果之前得到更正。
我知道有我在中間會讓我的開發人員感覺受到挫折。這種挫折并不是因為我是一個瓶頸，而我通常試圖在開發人員告訴我應用軟件已經完成的當天之內就開始我的測試工作。真正使他們感到受挫的是他們可以對應用軟件進行測試并認為他們已經找到了所有的東西。然而，通常在我開始測試之后的30分鐘之內，我就會在一張紙上記錄下來我有疑問或是看起來不正常的事情。
通常這種測試方式也會使我感到受挫。有時，我奇怪開發人員如何能夠說應用軟件已經完成，而他們所忽視的內容我在幾分鐘之內就能夠找到。然而，一般來說，出現的錯誤通常是由對測試理念的缺乏所導致。開發人員關注于提供正常工作的應用軟件，而我傾向于從一個用戶的角度看一看是否能打破它。我還會尋找其中的一些矛盾和直覺性的缺乏，這些反映出了使用者的經驗。
提供正確的應用軟件
測試工作具有一些不同的方面。一方面就是去驗證最終的產品達到所認可的要求。測試工作要求測試人員確保所有所要求的功能和特性都已經給出并可用。然后，確保這些功能和特性以所期望的方式工作。這種測試方式并沒有錯，但是你還需要更進一步。
試著作為一個用戶去打破應用軟件
很多開發人員所欠缺的地方是，他們以他們所期望的用戶的反應方式為基礎進行測試工作。他們沒有進行足夠的思考，離開慣常的途徑進行測試。例如，比方說你有一個Web應用軟件，其中有大量的在線處理過程，如果第一個頁面要求輸入用戶名和密碼，那么我一開始就什么值都不輸入，然后看一看會發生什么。我能不能進入?有沒有錯誤出現?有些時候是不是屏幕會靜止不動?這時，應用軟件就應該將其視為一個非法的響應并返回恰當的錯誤信息。
用戶會向所有可能位置輸入任何值
當我進入應用軟件界面時，我會輸入各種各樣奇怪的值。如果這里需要輸入的是字母，那么我就輸入一個數字，然后我會輸入類似于“(*&%$’的特殊字符。很多次，應用軟件都會發生問題，真是讓我感到驚異。我對所有的區域都做了相同的測試，如果一個區域包含一個drop-down列表，我就會試著鍵入一個值。如果某些區域是事先制定的，我就會改變他們。如果一些值是數據庫的關鍵字而不能動，我就會改變他們。我還試著通過在區域中加入頁面所允許的足夠多的數字或字符，讓他們溢出。然后我就會點擊可選的按鈕和鏈接看一看會發生什么。
同樣的，我還試著搞亂所有的預制定區域。我總是告訴我的開發人員說，如果你不希望一個區域被改變，那么你就不要允許用戶將指針放在上面和鍵入。我向你保證，如果你將一個區域設置為開放的可以輸入，那么就一定會有某些人在某些時候，出于某種原因試圖向其中鍵入數值。
用戶為什么會向一個需要輸入數字的區域鍵入特殊字符呢?問題在于他們或許不會有意去這樣做，然而，鍵入錯誤去卻隨時都會發生。如果你向用戶給出一個數字區域，那么隨著時間的過去，錯誤的鍵入就會導致在任何的區域之中輸入任何的字符。我認為這樣的問題應該現在就找出來，而不是讓一個Web應用軟件在用戶手中出問題。
用戶會嘗試邏輯流的所有組合
除了一些簡單的編輯性錯誤之外，我還會嘗試每一個邏輯流的組合。當我看到一個Web頁面時，我會嘗試每一個超鏈接看一看結果是什么。開發人員會看著我納悶為什么用戶會這樣做。再說一次，問題是他們可能不是有意去這么做，然而，你應該設想每一個邏輯組合都可能會在某個時間被嘗試。
看一看外觀
我著眼的最后一件事就是整體的視覺和感覺。我試圖確保屏幕有一個漂亮的外觀，漂亮的字體，而且他們是協調一致的。例如，如果你在列表中一些項目的最后放置一個句號，那么他們都應該帶有句號，否則就都沒有，這取決于你的編輯上的習慣。同樣，字體也應該保持一致，如果在一個區域的標題的字體是14，那么他們都應該是這個大小。這樣做都是為了使應用軟件看起來具有專業性。#p#分頁標題#e#
做最壞的準備
在我所管理的團體之中，開發人員做出了很好的工作，確保他們的應用軟件以所指定的方式工作。但在很多情況下，他們沒有從一個用戶的角度做出足夠的測試工作。他們應該關注于確保應用軟件的堅固可靠。用戶在百分之九十的時間之內，會像你所期望的那樣對應用軟件進行操作，然而，剩下的百分之十的時間里，他們就會做一些奇怪的事情。當發生這樣的事情時，你的應用軟件就需要對其妥當并成功地進行處理。你不希望一個很棒的應用軟件在用戶第一次輸入12位數字的社會保障號碼而不是9位數字時就垮掉。你要確保進行了測試工作保證你的應用軟件如宣傳的那樣進行工作。還有，盡可能地對意外因素的組合進行多種測試。你需要確保沒有任何的錯誤數據或處理流程致使用戶得到任何意料之外的系統信息。
文章分類:Web測試]]>
本文從功能、性能、可用性、客戶端兼容性、安全性等方面討論了基于Web的系統測試方法。
隨著Internet和Intranet/Extranet的快速增長，Web已經對商業、工業、銀行、財政、教育、政府和娛樂及我們的工作和生活產生了深遠的影響。許多傳統的信息和數據庫系統正在被移植到互聯網上，電子商務迅速增長，早已超過了國界。范圍廣泛的、復雜的分布式應用正在Web環境中出現。Web的流行和無所不在，是因為它能提供支持所有類型內容連接的信息發布，容易為最終用戶存取。
Yogesh Deshpande和Steve Hansen在1998年就提出了Web工程的概念。Web工程作為一門新興的學科，提倡使用一個過程和系統的方法來開發高質量的基于Web的系統。它" 使用合理的、科學的工程和管理原則，用嚴密的和系統的方法來開發、發布和維護基于Web的系統"。目前，對于web工程的研究主要是在國外開展的，國內還剛剛起步。
在基于Web的系統開發中，如果缺乏嚴格的過程，我們在開發、發布、實施和維護Web的過程中，可能就會碰到一些嚴重的問題，失敗的可能性很大。而且，隨著基于Web的系統變得越來越復雜，一個項目的失敗將可能導致很多問題。當這種情況發生時，我們對Web和Internet的信心可能會無法挽救地動搖，從而引起Web危機。并且，Web危機可能會比軟件開發人員所面對的軟件危機更加嚴重、更加廣泛。
在Web工程過程中，基于Web系統的測試、確認和驗收是一項重要而富有挑戰性的工作?；赪eb的系統測試與傳統的軟件測試不同，它不但需要檢查和驗證是否按照設計的要求運行，而且還要測試系統在不同用戶的瀏覽器端的顯示是否合適。重要的是，還要從最終用戶的角度進行安全性和可用性測試。然而，Internet和Web媒體的不可預見性使測試基于Web的系統變得困難。因此，我們必須為測試和評估復雜的基于Web的系統研究新的方法和技術。
一般軟件的發布周期以月或以年計算，而Web應用的發布周期以天計算甚至以小時計算。Web測試人員必須處理更短的發布周期，測試人員和測試管理人員面臨著從測試傳統的C/S結構和框架環境到測試快速改變的Web應用系統的轉變。
一、功能測試
1、鏈接測試
鏈接是Web應用系統的一個主要特征，它是在頁面之間切換和指導用戶去一些不知道地址的頁面的主要手段。鏈接測試可分為三個方面。首先，測試所有鏈接是否按指示的那樣確實鏈接到了該鏈接的頁面;其次，測試所鏈接的頁面是否存在;最后，保證Web應用系統上沒有孤立的頁面，所謂孤立頁面是指沒有鏈接指向該頁面，只有知道正確的URL地址才能訪問。
鏈接測試可以自動進行，現在已經有許多工具可以采用。鏈接測試必須在集成測試階段完成，也就是說，在整個Web應用系統的所有頁面開發完成之后進行鏈接測試。
2、表單測試
當用戶給Web應用系統管理員提交信息時，就需要使用表單操作，例如用戶注冊、登陸、信息提交等。在這種情況下，我們必須測試提交操作的完整性，以校驗提交給服務器的信息的正確性。例如：用戶填寫的出生日期與職業是否恰當，填寫的所屬省份與所在城市是否匹配等。如果使用了默認值，還要檢驗默認值的正確性。如果表單只能接受指定的某些值，則也要進行測試。例如：只能接受某些字符，測試時可以跳過這些字符，看系統是否會報錯。
3、Cookies測試
Cookies通常用來存儲用戶信息和用戶在某應用系統的操作，當一個用戶使用Cookies訪問了某一個應用系統時，Web服務器將發送關于用戶的信息，把該信息以Cookies的形式存儲在客戶端計算機上，這可用來創建動態和自定義頁面或者存儲登陸等信息。
如果Web應用系統使用了Cookies，就必須檢查Cookies是否能正常工作。測試的內容可包括Cookies是否起作用，是否按預定的時間進行保存，刷新對Cookies有什么影響等。
4、設計語言測試
Web設計語言版本的差異可以引起客戶端或服務器端嚴重的問題，例如使用哪種版本的HTML等。當在分布式環境中開發時，開發人員都不在一起，這個問題就顯得尤為重要。除了HTML的版本問題外，不同的腳本語言，例如Java、JavaScript、 ActiveX、VBScript或Perl等也要進行驗證。#p#分頁標題#e#
5、數據庫測試
在Web應用技術中，數據庫起著重要的作用，數據庫為Web應用系統的管理、運行、查詢和實現用戶對數據存儲的請求等提供空間。在Web應用中，最常用的數據庫類型是關系型數據庫，可以使用SQL對信息進行處理。
在使用了數據庫的Web應用系統中，一般情況下，可能發生兩種錯誤，分別是數據一致性錯誤和輸出錯誤。數據一致性錯誤主要是由于用戶提交的表單信息不正確而造成的，而輸出錯誤主要是由于網絡速度或程序設計問題等引起的，針對這兩種情況，可分別進行測試。
二、性能測試
1、連接速度測試
用戶連接到Web應用系統的速度根據上網方式的變化而變化，他們或許是電話撥號，或是寬帶上網。當下載一個程序時，用戶可以等較長的時間，但如果僅僅訪問一個頁面就不會這樣。如果Web系統響應時間太長(例如超過5秒鐘)，用戶就會因沒有耐心等待而離開。
另外，有些頁面有超時的限制，如果響應速度太慢，用戶可能還沒來得及瀏覽內容，就需要重新登陸了。而且，連接速度太慢，還可能引起數據丟失，使用戶得不到真實的頁面。
2、負載測試
負載測試是為了測量Web系統在某一負載級別上的性能，以保證Web系統在需求范圍內能正常工作。負載級別可以是某個時刻同時訪問Web系統的用戶數量，也可以是在線數據處理的數量。例如：Web應用系統能允許多少個用戶同時在線?如果超過了這個數量，會出現什么現象?Web應用系統能否處理大量用戶對同一個頁面的請求?
3、壓力測試
負載測試應該安排在Web系統發布以后，在實際的網絡環境中進行測試。因為一個企業內部員工，特別是項目組人員總是有限的，而一個Web系統能同時處理的請求數量將遠遠超出這個限度，所以，只有放在Internet上，接受負載測試，其結果才是正確可信的。
進行壓力測試是指實際破壞一個Web應用系統，測試系統的反映。壓力測試是測試系統的限制和故障恢復能力，也就是測試Web應用系統會不會崩潰，在什么情況下會崩潰。黑客常常提供錯誤的數據負載，直到Web應用系統崩潰，接著當系統重新啟動時獲得存取權。
壓力測試的區域包括表單、登陸和其他信息傳輸頁面等。
三、可用性測試
1、導航測試
導航描述了用戶在一個頁面內操作的方式，在不同的用戶接口控制之間，例如按鈕、對話框、列表和窗口等;或在不同的連接頁面之間。通過考慮下列問題，可以決定一個Web應用系統是否易于導航：導航是否直觀?Web系統的主要部分是否可通過主頁存取?Web系統是否需要站點地圖、搜索引擎或其他的導航幫助?
在一個頁面上放太多的信息往往起到與預期相反的效果。Web應用系統的用戶趨向于目的驅動，很快地掃描一個Web應用系統，看是否有滿足自己需要的信息，如果沒有，就會很快地離開。很少有用戶愿意花時間去熟悉Web應用系統的結構，因此，Web應用系統導航幫助要盡可能地準確。
導航的另一個重要方面是Web應用系統的頁面結構、導航、菜單、連接的風格是否一致。確保用戶憑直覺就知道Web應用系統里面是否還有內容，內容在什么地方。
Web應用系統的層次一旦決定，就要著手測試用戶導航功能，讓最終用戶參與這種測試，效果將更加明顯。
2、圖形測試
在Web應用系統中，適當的圖片和動畫既能起到廣告宣傳的作用，又能起到美化頁面的功能。一個Web應用系統的圖形可以包括圖片、動畫、邊框、顏色、字體、背景、按鈕等。圖形測試的內容有：
(1)要確保圖形有明確的用途，圖片或動畫不要胡亂地堆在一起，以免浪費傳輸時間。Web應用系統的圖片尺寸要盡量地小，并且要能清楚地說明某件事情，一般都鏈接到某個具體的頁面。
(2)驗證所有頁面字體的風格是否一致。
(3)背景顏色應該與字體顏色和前景顏色相搭配。
(4)圖片的大小和質量也是一個很重要的因素，一般采用JPG或GIF壓縮。
3、內容測試
內容測試用來檢驗Web應用系統提供信息的正確性、準確性和相關性。
信息的正確性是指信息是可靠的還是誤傳的。例如，在商品價格列表中，錯誤的價格可能引起財政問題甚至導致法律糾紛;信息的準確性是指是否有語法或拼寫錯誤。這種測試通常使用一些文字處理軟件來進行，例如使用Microsoft Word的"拼音與語法檢查"功能;信息的相關性是指是否在當前頁面可以找到與當前瀏覽信息相關的信息列表或入口，也就是一般Web站點中的所謂"相關文章列表"。#p#分頁標題#e#
4、整體界面測試
整體界面是指整個Web應用系統的頁面結構設計，是給用戶的一個整體感。例如：當用戶瀏覽Web應用系統時是否感到舒適，是否憑直覺就知道要找的信息在什么地方?整個Web應用系統的設計風格是否一致?
對整體界面的測試過程，其實是一個對最終用戶進行調查的過程。一般Web應用系統采取在主頁上做一個調查問卷的形式，來得到最終用戶的反饋信息。
對所有的可用性測試來說，都需要有外部人員(與Web應用系統開發沒有聯系或聯系很少的人員)的參與，最好是最終用戶的參與。
四、客戶端兼容性測試
1、平臺測試
市場上有很多不同的操作系統類型，最常見的有Windows、Unix、Macintosh、Linux等。Web應用系統的最終用戶究竟使用哪一種操作系統，取決于用戶系統的配置。這樣，就可能會發生兼容性問題，同一個應用可能在某些操作系統下能正常運行，但在另外的操作系統下可能會運行失敗。
因此，在Web系統發布之前，需要在各種操作系統下對Web系統進行兼容性測試。
2、瀏覽器測試
瀏覽器是Web客戶端最核心的構件，來自不同廠商的瀏覽器對Java，、JavaScript、 ActiveX、 plug-ins或不同的HTML規格有不同的支持。例如，ActiveX是Microsoft的產品，是為Internet Explorer而設計的，JavaScript是Netscape的產品，Java是Sun的產品等等。另外，框架和層次結構風格在不同的瀏覽器中也有不同的顯示，甚至根本不顯示。不同的瀏覽器對安全性和Java的設置也不一樣。
測試瀏覽器兼容性的一個方法是創建一個兼容性矩陣。在這個矩陣中，測試不同廠商、不同版本的瀏覽器對某些構件和設置的適應性。
五、安全性測試
Web應用系統的安全性測試區域主要有：
(1)現在的Web應用系統基本采用先注冊，后登陸的方式。因此，必須測試有效和無效的用戶名和密碼，要注意到是否大小寫敏感，可以試多少次的限制，是否可以不登陸而直接瀏覽某個頁面等。
(2)Web應用系統是否有超時的限制，也就是說，用戶登陸后在一定時間內(例如15分鐘)沒有點擊任何頁面，是否需要重新登陸才能正常使用。
(3)為了保證Web應用系統的安全性，日志文件是至關重要的。需要測試相關信息是否寫進了日志文件、是否可追蹤。
(4)當使用了安全套接字時，還要測試加密是否正確，檢查信息的完整性。
(5)服務器端的腳本常常構成安全漏洞，這些漏洞又常常被黑客利用。所以，還要測試沒有經過授權，就不能在服務器端放置和編輯腳本的問題。
六、總結
本文從功能、性能、可用性、客戶端兼容性、安全性等方面討論了基于Web的系統測試方法。
基于Web的系統測試與傳統的軟件測試既有相同之處，也有不同的地方，對軟件測試提出了新的挑戰?；赪eb的系統測試不但需要檢查和驗證是否按照設計的要求運行，而且還要評價系統在不同用戶的瀏覽器端的顯示是否合適。重要的是，還要從最終用戶的角度進行安全性和可用性測試。
七、參考文獻
[1] N. Zelnick. Nifty Technology and Nonconformance: The Web in Crisis. Computer， 1998(10): 115-119
[2] W. Gibbs. Software's chronic crisis. Scientific American. 1994.9
[3] Yogesh Deshpande and Steve Hansen. Web Engineering: Creating a Discipline among Disciplines. IEEE Software，2001(2): 82-87
[4] A. Ginige. Web Engineering: Methodologies for Developing Large and Maintainable Web Based Information Systems. Proc IEEE International Conference on Networking， the India and the World CNIW'98，Ahmedabad， India， 1998，12
[5] Internet Testing: Keeping Bugs Off the Web. http://www.stlabs.com/bugs_off.htm
[6] J. Bach. Testing Internet Software.
http://www.stlabs.com/testnet/docs/inet.htm
[7] Tongren.Compatibility and Security Testing of Web-Based Applications. TTN Online，1999，3
文章分類:Web測試]]>
本文將 web 測試分為 6 個部分：
1. 功能測試
2. 性能測試(包括負載/壓力測試)
3. 用戶界面測試
4. 兼容性測試
5. 安全測試
6. 接口測試
本文的目的是覆蓋 web 測試的各個方面，未就某一主題進行深入說明。
1 功能測試
1.1 鏈接測試
鏈接是Web應用系統的一個主要特征，它是在頁面之間切換和指導用戶去一些不知道地址的頁面的主要手段。鏈接測試可分為三個方面。首先，測試所有鏈接是否按指示的那樣確實鏈接到了該鏈接的頁面;其次，測試所鏈接的頁面是否存在;最后，保證Web應用系統上沒有孤立的頁面，所謂孤立頁面是指沒有鏈接指向該頁面，只有知道正確的URL地址才能訪問。
鏈接測試可以自動進行，現在已經有許多工具可以采用。鏈接測試必須在集成測試階段完成，也就是說，在整個Web應用系統的所有頁面開發完成之后進行鏈接測試。
采取措施：采用自動檢測網站鏈接的軟件來進行。
推薦軟件：
Xenu Link Sleuth 免費 綠色免安裝軟件
HTML Link Validator 共享(30天試用)
1.2 表單測試
當用戶通過表單提交信息的時候，都希望表單能正常工作。
如果使用表單來進行在線注冊，要確保提交按鈕能正常工作，當注冊完成后應返回注冊成功的消息。如果使用表單收集配送信息，應確保程序能夠正確處理這些數據，最后能讓顧客能讓客戶收到包裹。要測試這些程序，需要驗證服務器能正確保存這些數據，而且后臺運行的程序能正確解釋和使用這些信息。
當用戶使用表單進行用戶注冊、登陸、信息提交等操作時，我們必須測試提交操作的完整性，以校驗提交給服務器的信息的正確性。例如：用戶填寫的出生日期與職業是否恰當，填寫的所屬省份與所在城市是否匹配等。如果使用了默認值，還要檢驗默認值的正確性。如果表單只能接受指定的某些值，則也要進行測試。例如：只能接受某些字符，測試時可以跳過這些字符，看系統是否會報錯。
1.3 數據校驗
如果系根據業務規則需要對用戶輸入進行校驗，需要保證這些校驗功能正常工作。例如，省份的字段可以用一個有效列表進行校驗。在這種情況下，需要驗證列表完整而且程序正確調用了該列表(例如在列表中添加一個測試值，確定系統能夠接受這個測試值)。
在測試表單時，該項測試和表單測試可能會有一些重復。
1.2和1.3的采取措施：第一個完整的版本采用手動檢查，同時形成WinRunner(QTP)腳本;回歸測試以及升級版本主要靠WinRunner(QTP)自動回放測試。
1.4 cookies測試
Cookies通常用來存儲用戶信息和用戶在某應用系統的操作，當一個用戶使用Cookies訪問了某一個應用系統時，Web服務器將發送關于用戶的信息，把該信息以Cookies的形式存儲在客戶端計算機上，這可用來創建動態和自定義頁面或者存儲登陸等信息。
如果Web應用系統使用了Cookies，就必須檢查Cookies是否能正常工作。測試的內容可包括Cookies是否起作用，是否按預定的時間進行保存，刷新對Cookies有什么影響等。如果在 cookies 中保存了注冊信息，請確認該 cookie能夠正常工作而且已對這些信息已經加密。如果使用 cookie 來統計次數，需要驗證次數累計正確。
采取措施：
1 采用黑盒測試：采用上面提到的方法進行測試
2 采用查看cookies的軟件進行(初步的想法)
可以選擇采用的軟件
IECookiesView v1.50
Cookies Manager v1.1
1.5 數據庫測試
在Web應用技術中，數據庫起著重要的作用，數據庫為Web應用系統的管理、運行、查詢和實現用戶對數據存儲的請求等提供空間。在Web應用中，最常用的數據庫類型是關系型數據庫，可以使用SQL對信息進行處理。#p#分頁標題#e#
在使用了數據庫的Web應用系統中，一般情況下，可能發生兩種錯誤，分別是數據一致性錯誤和輸出錯誤。數據一致性錯誤主要是由于用戶提交的表單信息不正確而造成的，而輸出錯誤主要是由于網絡速度或程序設計問題等引起的，針對這兩種情況，可分別進行測試。
采取措施：暫時沒有更好的測試方法
考慮結合到1.2和1.3的測試中
1.6 應用程序特定的功能需求
最重要的是，測試人員需要對應用程序特定的功能需求進行驗證。嘗試用戶可能進行的所有操作：下訂單、更改訂單、取消訂單、核對訂單狀態、在貨物發送之前更改送貨信息、在線支付等等。這是用戶之所以使用網站的原因，一定要確認網站能像廣告宣傳的那樣神奇。
采取措施：深刻理解需求說明文檔
1.7 設計語言測試
Web設計語言版本的差異可以引起客戶端或服務器端嚴重的問題，例如使用哪種版本的HTML等。當在分布式環境中開發時，開發人員都不在一起，這個問題就顯得尤為重要。除了HTML的版本問題外，不同的腳本語言，例如Java、javascript、 ActiveX、VBScript或Perl等也要進行驗證。
暫時沒有方法測試，可以多參考一點討論組內的更新信息
2 性能測試
2.1 連接速度測試
用戶連接到Web應用系統的速度根據上網方式的變化而變化，他們或許是電話撥號，或是寬帶上網。當下載一個程序時，用戶可以等較長的時間，但如果僅僅訪問一個頁面就不會這樣。如果Web系統響應時間太長(例如超過5秒鐘)，用戶就會因沒有耐心等待而離開。
另外，有些頁面有超時的限制，如果響應速度太慢，用戶可能還沒來得及瀏覽內容，就需要重新登陸了。而且，連接速度太慢，還可能引起數據丟失，使用戶得不到真實的頁面。
2.2 負載測試
負載測試是為了測量Web系統在某一負載級別上的性能，以保證Web系統在需求范圍內能正常工作。負載級別可以是某個時刻同時訪問Web系統的用戶數量，也可以是在線數據處理的數量。例如：Web應用系統能允許多少個用戶同時在線?如果超過了這個數量，會出現什么現象?Web應用系統能否處理大量用戶對同一個頁面的請求?
2.3 壓力測試
負載測試應該安排在Web系統發布以后，在實際的網絡環境中進行測試。因為一個企業內部員工，特別是項目組人員總是有限的，而一個Web系統能同時處理的請求數量將遠遠超出這個限度，所以，只有放在Internet上，接受負載測試，其結果才是正確可信的。
進行壓力測試是指實際破壞一個Web應用系統，測試系統的反映。壓力測試是測試系統的限制和故障恢復能力，也就是測試Web應用系統會不會崩潰，在什么情況下會崩潰。黑客常常提供錯誤的數據負載，直到Web應用系統崩潰，接著當系統重新啟動時獲得存取權。
壓力測試的區域包括表單、登陸和其他信息傳輸頁面等。
負載/壓力測試應該關注什么
測試需要驗證系統能否在同一時間響應大量的用戶，在用戶傳送大量數據的時候能否響應，系統能否長時間運行?？稍L問性對用戶來說是極其重要的。如果用戶得到“系統忙”的信息，他們可能放棄，并轉向競爭對手。系統檢測不僅要使用戶能夠正常訪問站點，在很多情況下，可能會有黑客試圖通過發送大量數據包來攻擊服務器。出于安全的原因，測試人員應該知道當系統過載時，需要采取哪些措施，而不是簡單地提升系統性能。
瞬間訪問高峰
如果您的站點用于公布彩票的抽獎結果，最好使系統在中獎號碼公布后的一段時間內能夠響應上百萬的請求。負載測試工具能夠模擬 X 個用戶同時訪問測試站點。
每個用戶傳送大量數據
網上書店的多數用戶可能只訂購 1-5 書，但是大學書店可能會訂購 5000 本有關心理學介紹的課本? 或者一個祖母為她的 50 個兒孫購買圣誕禮物(當然每個孩子都有自己的郵件地址) 系統能處理單個用戶的大量數據嗎?
長時間的使用
如果站點用于處理鮮花訂單，那么至少希望它在母親節前的一周內能持續運行。如果站點提供基于 web 的 email 服務，那么點最好能持續運行幾個月，甚至幾年?？赡苄枰褂米詣訙y試工具來完成這種類型的測試，因為很難通過手工完成這些測試。你可以想象組織100 個人同時點擊某個站點。但是同時組織 100000 個人呢。通常，測試工具在第二次使用的時候，它創造的效益，就足以支付成本。而且，測試工具安裝完成之后，再次使用的時候，只要點擊幾下。#p#分頁標題#e#
采取措施：采用測試工具WAS、ACT協助進行測試
3 用戶界面測試
3.1 導航測試
導航描述了用戶在一個頁面內操作的方式，在不同的用戶接口控制之間，例如按鈕、對話框、列表和窗口等;或在不同的連接頁面之間。通過考慮下列問題，可以決定一個Web應用系統是否易于導航：導航是否直觀?Web系統的主要部分是否可通過主頁存取?Web系統是否需要站點地圖、搜索引擎或其他的導航幫助?
在一個頁面上放太多的信息往往起到與預期相反的效果。Web應用系統的用戶趨向于目的驅動，很快地掃描一個Web應用系統，看是否有滿足自己需要的信息，如果沒有，就會很快地離開。很少有用戶愿意花時間去熟悉Web應用系統的結構，因此，Web應用系統導航幫助要盡可能地準確。
導航的另一個重要方面是Web應用系統的頁面結構、導航、菜單、連接的風格是否一致。確保用戶憑直覺就知道Web應用系統里面是否還有內容，內容在什么地方。
Web應用系統的層次一旦決定，就要著手測試用戶導航功能，讓最終用戶參與這種測試，效果將更加明顯。
3.2 圖形測試
在Web應用系統中，適當的圖片和動畫既能起到廣告宣傳的作用，又能起到美化頁面的功能。一個Web應用系統的圖形可以包括圖片、動畫、邊框、顏色、字體、背景、按鈕等。圖形測試的內容有：
(1)要確保圖形有明確的用途，圖片或動畫不要胡亂地堆在一起，以免浪費傳輸時間。Web應用系統的圖片尺寸要盡量地小，并且要能清楚地說明某件事情，一般都鏈接到某個具體的頁面。
(2)驗證所有頁面字體的風格是否一致。
(3)背景顏色應該與字體顏色和前景顏色相搭配。
(4)圖片的大小和質量也是一個很重要的因素，一般采用JPG或GIF壓縮，最好能使圖片的大小減小到 30k 以下
(5)最后，需要驗證的是文字回繞是否正確。如果說明文字指向右邊的圖片，應該確保該圖片出現在右邊。不要因為使用圖片而使窗口和段落排列古怪或者出現孤行。
通常來說，使用少許或盡量不使用背景是個不錯的選擇。如果您想用背景，那么最好使用單色的，和導航條一起放在頁面的左邊。另外，圖案和圖片可能會轉移用戶的注意力。
3.3內容測試
內容測試用來檢驗Web應用系統提供信息的正確性、準確性和相關性。
信息的正確性是指信息是可靠的還是誤傳的。例如，在商品價格列表中，錯誤的價格可能引起財政問題甚至導致法律糾紛;信息的準確性是指是否有語法或拼寫錯誤。這種測試通常使用一些文字處理軟件來進行，例如使用Microsoft Word的"拼音與語法檢查"功能;信息的相關性是指是否在當前頁面可以找到與當前瀏覽信息相關的信息列表或入口，也就是一般Web站點中的所謂"相關文章列表"。
對于開發人員來說，可能先有功能然后才對這個功能進行描述。大家坐在一起討論一些新的功能，然后開始開發，在開發的時候，開發人員可能不注重文字表達，他們添加文字可能只是為了對齊頁面。不幸的是，這樣出來的產品可能產生嚴重的誤解。因此測試人員和公關部門一起檢查內容的文字表達是否恰當。否則，公司可能陷入麻煩之中，也可能引起法律方面的問題。測試人員應確保站點看起來更專業些。過分地使用粗體字、大字體和下劃線可能會讓用戶感到不舒服。在進行用戶可用性方面的測試時，最好先請圖形設計專家對站點進行評估。你可能不希望看到一篇到處是黑體字的文章，所以相信您也希望自己的站點能更專業一些。最后，需要確定是否列出了相關站點的鏈接。很多站點希望用戶將郵件發到一個特定的地址，或者從某個站點下載瀏覽器。但是如果用戶無法點擊這些地址，他們可能會覺得很迷惑。
3.4 表格測試
需要驗證表格是否設置正確。用戶是否需要向右滾動頁面才能看見產品的價格?把價格放在左邊，而把產品細節放在右邊是否更有效? 每一欄的寬度是否足夠寬，表格里的文字是否都有折行?是否有因為某一格的內容太多，而將整行的內容拉長?
3.5 整體界面測試
整體界面是指整個Web應用系統的頁面結構設計，是給用戶的一個整體感。例如：當用戶瀏覽Web應用系統時是否感到舒適，是否憑直覺就知道要找的信息在什么地方?整個Web應用系統的設計風格是否一致?#p#分頁標題#e#
對整體界面的測試過程，其實是一個對最終用戶進行調查的過程。一般Web應用系統采取在主頁上做一個調查問卷的形式，來得到最終用戶的反饋信息。
對所有的用戶界面測試來說，都需要有外部人員(與Web應用系統開發沒有聯系或聯系很少的人員)的參與，最好是最終用戶的參與。
采取措施：手動測試，參與人員最好有外部人員
4 兼容性測試
4.1 平臺測試
市場上有很多不同的操作系統類型，最常見的有Windows、Unix、Macintosh、Linux等。Web應用系統的最終用戶究竟使用哪一種操作系統，取決于用戶系統的配置。這樣，就可能會發生兼容性問題，同一個應用可能在某些操作系統下能正常運行，但在另外的操作系統下可能會運行失敗。
因此，在Web系統發布之前，需要在各種操作系統下對Web系統進行兼容性測試。
4.2 瀏覽器測試
瀏覽器是Web客戶端最核心的構件，來自不同廠商的瀏覽器對Java，、javascript、 ActiveX、 plug-ins或不同的HTML規格有不同的支持。例如，ActiveX是Microsoft的產品，是為Internet Explorer而設計的，javascript是Netscape的產品，Java是Sun的產品等等。另外，框架和層次結構風格在不同的瀏覽器中也有不同的顯示，甚至根本不顯示。不同的瀏覽器對安全性和Java的設置也不一樣。
測試瀏覽器兼容性的一個方法是創建一個兼容性矩陣。在這個矩陣中，測試不同廠商、不同版本的瀏覽器對某些構件和設置的適應性。
4.3 分辨率測試
頁面版式在 640x400、600x800 或 1024x768 的分辨率模式下是否顯示正常? 字體是否太小以至于無法瀏覽? 或者是太大? 文本和圖片是否對齊?
4.4 Modem/連接速率
是否有這種情況，用戶使用 28.8 modem下載一個頁面需要 10 分鐘，但測試人員在測試的時候使用的是 T1 專線? 用戶在下載文章或演示的時候，可能會等待比較長的時間，但卻不會耐心等待首頁的出現。最后，需要確認圖片不會太大。
4.5 打印機
用戶可能會將網頁打印下來。因此網也在設計的時候要考慮到打印問題，注意節約紙張和油墨。有不少用戶喜歡閱讀而不是盯著屏幕，因此需要驗證網頁打印是否正常。有時在屏幕上顯示的圖片和文本的對齊方式可能與打印出來的東西不一樣。測試人員至少需要驗證訂單確認頁面打印是正常的。
4.6 組合測試
最后需要進行組合測試。600x800 的分辨率在 MAC 機上可能不錯，但是在 IBM 兼容機上卻很難看。在 IBM 機器上使用 Netscape 能正常顯示，但卻無法使用 Lynx 來瀏覽。如果是內部使用的 web 站點，測試可能會輕松一些。如果公司指定使用某個類型的瀏覽器，那么只需在該瀏覽器上進行測試。如果所有的人都使用 T1 專線，可能不需要測試下載施加。(但需要注意的是，可能會有員工從家里撥號進入系統) 有些內部應用程序，開發部門可能在系統需求中聲明不支持某些系統而只支持一些那些已設置的系統。但是，理想的情況是，系統能在所有機器上運行，這樣就不會限制將來的發展和變動。
采取措施：根據實際情況，采取等價劃分的方法，列出兼容性矩陣
5 安全測試
即使站點不接受信用卡支付，安全問題也是非常重要的。Web 站點收集的用戶資料只能在公司內部使用。如果用戶信息被黑客泄露，客戶在進行交易時，就不會有安全感。
5.1 目錄設置
Web 安全的第一步就是正確設置目錄。每個目錄下應該有 index.html 或 main.html 頁面，這樣就不會顯示該目錄下的所有內容。我服務的一個公司沒有執行這條規則。我選中一幅圖片，單擊鼠標右鍵，找到該圖片所在的路徑"…com/objects/images"。然后在瀏覽器地址欄中手工輸入該路徑，發現該站點所有圖片的列表。這可能沒什么關系。我進入下一級目錄 "…com/objects" ，點擊 jackpot。在該目錄下有很多資料，其中引起我注意的是已過期頁面。該公司每個月都要更改產品價格，并且保存過期頁面。我翻看了一下這些記錄，就可以估計他們的邊際利潤以及他們為了爭取一個合同還有多大的降價空間。如果某個客戶在談判之前查看了這些信息，他們在談判桌上肯定處于上風。
5.2 SSL
很多站點使用 SSL 進行安全傳送。你知道你進入一個 SSL 站點是因為瀏覽器出現了警告消息，而且在地址欄中的 HTTP 變成 HTTPS。如果開發部門使用了SSL，測試人員需要確定是否有相應的替代頁面(適用于3.0 以下版本的瀏覽器，這些瀏覽器不支持SSL。當用戶進入或離開安全站點的時候，請確認有相應的提示信息。是否有連接時間限制?超過限制時間后出現什么情況?#p#分頁標題#e#
5.3 登錄
有些站點需要用戶進行登錄，以驗證他們的身份。這樣對用戶是方便的，他們不需要每次都輸入個人資料。你需要驗證系統阻止非法的用戶名/口令登錄，而能夠通過有效登錄。用戶登錄是否有次數限制? 是否限制從某些 IP 地址登錄? 如果允許登錄失敗的次數為3，你在第三次登錄的時候輸入正確的用戶名和口令，能通過驗證嗎? 口令選擇有規則限制嗎? 是否可以不登陸而直接瀏覽某個頁面?
Web應用系統是否有超時的限制，也就是說，用戶登陸后在一定時間內(例如15分鐘)沒有點擊任何頁面，是否需要重新登陸才能正常使用。
5.4 日志文件
在后臺，要注意驗證服務器日志工作正常。日志是否記所有的事務處理? 是否記錄失敗的注冊企圖? 是否記錄被盜信用卡的使用? 是否在每次事務完成的時候都進行保存? 記錄IP 地址嗎? 記錄用戶名嗎?
5.5 腳本語言
腳本語言是常見的安全隱患。每種語言的細節有所不同。有些腳本允許訪問根目錄。其他只允許訪問郵件服務器，但是經驗豐富的黑客可以將服務器用戶名和口令發送給他們自己。找出站點使用了哪些腳本語言，并研究該語言的缺陷。還要需要測試沒有經過授權，就不能在服務器端放置和編輯腳本的問題。最好的辦法是訂閱一個討論站點使用的腳本語言安全性的新聞組。
6 接口測試
在很多情況下，web 站點不是孤立。Web 站點可能會與外部服務器通訊，請求數據、驗證數據或提交訂單。
6.1服務器接口
第一個需要測試的接口是瀏覽器與服務器的接口。測試人員提交事務，然后查看服務器記錄，并驗證在瀏覽器上看到的正好是服務器上發生的。測試人員還可以查詢數據庫，確認事務數據已正確保存。
這種測試可以歸到功能測試中的表單測試和數據校驗測試中
6.2 外部接口
有些 web 系統有外部接口。例如，網上商店可能要實時驗證信用卡數據以減少欺詐行為的發生。測試的時候，要使用 web 接口發送一些事務數據，分別對有效信用卡、無效信用卡和被盜信用卡進行驗證。如果商店只使用 Visa 卡和 Mastercard 卡， 可以嘗試使用 Discover 卡的數據。(簡單的客戶端腳本能夠在提交事務之前對代碼進行識別，例如 3 表示 American Express，4 表示 Visa，5 表示 Mastercard，6 代表Discover。)通常，測試人員需要確認軟件能夠處理外部服務器返回的所有可能的消息。
這種情況在遠程抄表中可能會體現到
6.3 錯誤處理
最容易被測試人員忽略的地方是接口錯誤處理。通常我們試圖確認系統能夠處理所有錯誤，但卻無法預期系統所有可能的錯誤。嘗試在處理過程中中斷事務，看看會發生什么情況?訂單是否完成?嘗試中斷用戶到服務器的網絡連接。嘗試中斷 web 服務器到信用卡驗證服務器的連接。在這些情況下，系統能否正確處理這些錯誤?是否已對信用卡進行收費?如果用戶自己中斷事務處理，在訂單已保存而用戶沒有返回網站確認的時候，需要由客戶代表致電用戶進行訂單確認。
采取措施：在理解需求的基礎上，充分發揮想象力，盡量比較全面的列出各種異常情況。
7 結論
無論你在測試 internet、intranet 或者是 extranet 應用程序，web 測試相對于非 web 測試來說都是更具挑戰性的工作。用戶對 web 頁面質量有很高的期望。在很多情況下，就像業務功能一樣，頁面用于維護和發展公共關系，所以第一印象非常重要。
文章分類:Web測試]]>
(1) 頁面清單是否完整(是否已經將所需要的頁面全部都列出來了)
(2) 頁面是否顯示(在不同分辨率下頁面是否存在，在不同瀏覽器版本中頁面是是否顯示)
(3) 頁面在窗口中的顯示是否正確、美觀(在調整瀏覽器窗口大小時，屏幕刷新是否正確)
(4) 頁面特殊效果(如特殊字體效果、動畫效果)是否顯示
(5) 頁面特殊效果顯示是否正確
2 頁面元素部分
(1)頁面元素清單(為實現功能，是否將所需要的元素全部都列出來了，如按鈕、單選框、復選框、列表框、超連接、輸入框等等)
(2)素是否顯示(元素是否存在)
(3)頁面元素是否顯示正確(主要針對文字、圖形、簽章)
(4)頁面元素的外形、擺放位置(如按鈕、列表框、核選框、輸入框、超連接等)
(5) 頁面元素基本功能是否實現(如文字特效、動畫特效、按鈕、超連接)
(6) 頁面元素的容錯性列表(如輸入框、時間列表或日歷)
(7) 頁面元素的容錯性是否存在
(8) 頁面元素的容錯性是否正確
3 功能部分
(1) 數據初始化是否執行
(2) 數據初始化是否正確
(3) 數據處理功能是否執行
(4) 數據處理功能是否正確
(5) 數據保存是否執行
(6) 數據保存是否正確
(7) 是否對其他功能有影響
(8) 如果影響其他功能，系統能否作出正確的反應
(9) 其他錯誤
(10) 對模塊的具體功能進行測試時可以列出功能模塊的所有功能，進行排列組合，測試所有情況
如：某一功能模塊具有最基本的增刪改查功能，則需要進行以下測試
單項功能測試(增加、修改、查詢、刪除)
增加——>增加——>增加 (連續增加測試)
增加——>刪除
增加——>刪除——>增加 (新增加的內容與刪除內容一致)
增加——>修改——>刪除
修改——>修改——>修改 (連續修改測試)
修改——>增加 (新增加的內容與修改前內容一致)
修改——>刪除
修改——>刪除——>增加 (新增加的內容與刪除內容一致)
刪除——>刪除——>刪除 (連續刪除測試)
(11)查詢功能分為兩種情況，驗證操作結果。
一、打開頁面時自動顯示結果，則不特別強調;
二、需要手工操作進行查詢，則每次在其他功能完成后進行。
4 提示信息
(1) 成功、失敗提示
(2) 操作結果提示
(3) 確認提示
(4) 危險操作、重要操作提示
(5) 返回頁面 提示后顯示的頁面
5 容錯性
注意以下幾種情況
(1) 為空、非空
(2) 唯一性
(3 )字長、格式
(4) 數字、郵政編碼、金額、電話、電子郵件、ID號、密碼
(5) 日期、時間
(6) 特殊字符 (對數據庫)英文單、雙引號，&符號
6 權限部分
功能權限： 指定用戶可以使用那些功能，不能使用那些功能
數據權限： 指定用戶可以處理那些數據，不可以處理那些數據?？梢院喜⒌焦δ軠y試
操作權限： 在邏輯關系上，操作前后順序、數據處理情況?？梢院喜⒌焦δ軠y試
權限變化： 可以合并到功能測試
(1) 功能權限是否存在
(2)功能權限是否正確
(3) 數據權限是否存在
(4) 數據權限是否正確
(5)操作權限是否存在
(6) 操作權限是否正確
(7) 引起權限變化的功能列表
(8) 功能權限變化還是數據權限變化，或兩者兼有
(9) 權限變化是否正確
7 鍵盤操作
(1) Tab鍵的使用
(2) 上下方向鍵的使用
(3) Enter鍵的使用
(4) 系統設定快捷鍵的使用(如果設置有快捷鍵)
8 測試中還應注意的其他事項
(6) 完整性：是否是一個整體，沒有功能缺損
(7) 易用性：使用是否方便#p#分頁標題#e#
(8) 一致性：類似的問題用類似的方法處理
(9) 提示信息：提示信息是否完整、正確、詳細
(10) 幫助信息：是否提供幫助信息，幫助信息的表現形式(頁面文字、提示信息、幫助文件)，幫助信息是否正確、詳細
(11) 兼容性：包括操作系統兼容和應用軟件兼容，可能還包括硬件兼容
(12) 可擴展性：是否由升級的余地，是否保留了接口
(13) 穩定性：運行所需的軟硬件配置，占用資源情況，出現問題時的容錯性，對數據的保護
(14) 運行速度：運行的快慢，帶寬占用情況
有幾點：
1.功能點測試：是否滿足需求所要求的功能
2.字符串長度檢查: 輸入超出需求所說明的字符串長度的內容, 看系統是否檢查字符串長度,會不會出錯.
3.字符類型檢查: 在應該輸入指定類型的內容的地方輸入其他類型的內容(如在應該輸入整型的地方輸入其他字符類型),看系統是否檢查字符類型,會否報錯.
4.標點符號檢查: 輸入內容包括各種標點符號,特別是空格,各種引號,回車鍵.看系統處理是否正確.
5.中文字符處理: 在可以輸入中文的系統輸入中文,看會否出現亂碼或出錯.
6.信息重復: 在一些需要命名,且名字應該唯一的信息輸入重復的名字或ID,看系統有沒有處理,會否報錯,重名包括是否區分大小寫,以及在輸入內容的前后輸入空格,系統是否作出正確處理.
7.界面測試：界面的正確性、一致性、友好性、易用性。
用戶界面測試是從最終的使用者用戶的角度來看軟件，軟件難以理解，不易使用就是軟件缺陷?？梢詮囊韵聨讉€方面重點來檢查用戶界面：
1.易用性檢查：確保軟件易于理解，方便使用。
2.一致性檢查：
a.注意系統頁面的風格是否一致，如字的大小、顏色、字體要相同。
b.提示信息的表達方式是否一致。
c.按鈕排列順序是否一致。
d.back, cancel等按鈕跳轉頁面處理是否一致。
e.各字段的名稱，位置、長度、類型是否和設計文檔要求一致，如Employee No和LoginName不一致。
3.正確性檢查：檢查頁面上的form, button, table, header, footer,提示信息，還有其他文字拼寫，句子的語法等是否正確。
4.友好性檢查：
a.提示信息是否友好.
b.系統應該在用戶執行錯誤的操作之前提出警告，提示信息.
c.頁面分辨率檢查，在各種分辨率瀏覽系統檢查系統界面友好性。
5.合理性檢查：做delete, update, add, cancel, back等操作后，查看信息回到的頁面是否合理。
6.檢查本地化是否通過：英文版不應該有中文信息，英文翻譯準確，專業。
7.頁面最大化檢查：測試最大化/最小化/還原時頁面是否做了對應的處理。
文章分類:Web測試]]>
1.1 CUnit簡要描述
CUnit是一個編寫、管理及運行c語言單元測試的系統。它使用一個簡單的框架來構建測試結構，并為普通數據結構的測試提供豐富的斷言。此外，CUnit為測試的運行和結果查看提供了許多不同的接口，包括自動測試模式和可交互的控制臺模式。
其常用的數據類型和函數在以下頭文件中聲明：
頭文件 內容描述
<CUnit/CUnit.h> 包括測試用例中常用的宏定義和框架中其它頭文件
<CUnit/CUError.h> 錯誤處理函數及錯誤編號
<CUnit/TestDB.h> 測試注冊簿、測試包和測試用例的操作及數據類型
<CUnit/TestRun.h> 測試運行及結果檢索的操作及數據類型
<CUnit/Automated.h> 輸出Xml結果相關的自動模式接口
<CUnit/Basic.h> 非交互模式的基本模式接口
<CUnit/Console.h> 交互模式的接口
1.2 測試框架結構
CUnit核心框架為測試注冊簿、測試包和測試用例的管理提供了基本支持，它提供的接口可以使用戶和測試框架交互，方便測試的運行和測試結果的查看。CUnit被組織成一個常見的單元測試框架，其結構如下：
測試用例被打包成測試包，并被注冊到當前活動的測試注冊簿中。測試包的裝載和卸載函數在測試執行前后被自動調用。所有的測試包和測試用例可以一鍵運行，也可以選擇相應的測試包或測試用例來執行測試。
1.3 基本使用方法
使用CUnit框架的常用流程如下：
編寫測試用例，如果有必要須對測試包進行初始化或者清理
初始化測試注冊簿 CU_initialize_registry()
向注冊簿中注冊測試包 CU_add_suite()
向測試包中添加測試用例 CU_add_test()
使用合適的測試模式執行測試CU_automated(basic/console/curses)_run_tests()
清理測試注冊簿 CU_cleanup_registry()
1.4 Linux下CUnit的安裝
The usual sequence of steps should succeed in building and installing CUnit: aclocal (if necessary) autoconf (if necessary) automake (if necessary) chmod u+x configure (if necessary) ./configure --prefix <Your choice of directory for installation> make make install What's installed: libcunit.a (Library file) CUnit Header files DTD and XSL files supporting xml output files in share directory Man Pages in relevant man directories under the installation path. HTML users guide in the doc subdirectory of the installation path. Example & test programs in the share subdirectory of the install path. |
2. 編寫CUnit測試用例
2.1 測試用例函數的命名
CUnit中對于測試函數的定義沒有嚴格的規范，一個常用的示例如下：
int maxi(int i1, int i2)
{
return (i1 > i2) i1 : i2;
}
void test_maxi(void)
{
CU_ASSERT(maxi(0,2) == 2);
CU_ASSERT(maxi(0,-2) == 0);
CU_ASSERT(maxi(2,2) == 2);
}
|
2.2 CUnit中的斷言
CUnit為邏輯條件測試提供了一系列的斷言。測試框架會跟蹤這些斷言的通過或失敗，當測試執行完成時便可看到結果。
每一個斷言測試一個邏輯條件，條件的值為CU_FALSE表示斷言失敗。對于測試失敗，測試將會繼續執行，除非用戶選擇“xxx_FATAL”類型的斷言，這種情況下該測試函數將會失敗并立即返回。FATAL類型的斷言應該和警告一塊使用！一旦FATAL類型的斷言導致測試失敗，測試函數將沒有機會做清理工作，普通的清理函數不會起任何作用。
另外一些特殊的斷言被注冊為“pass”或“fail”，它們不是用來做邏輯測試，而是用來測試流程控制或者其他條件測試的。例如：#p#分頁標題#e#
void test_longjmp(void)
{
jmp_buf buf;
int i;
i = setjmp(buf);
if (i == 0) {
run_other_func();
CU_PASS("run_other_func() succeeded.");
}
else
CU_FAIL("run_other_func() issued longjmp.");
}
|
所有的斷言被定義在<CUnit/CUnit.h>
3. 測試注冊簿
3.1 常用相關函數
#include <CUnit/TestDB.h> typedef struct CU_TestRegistry typedef CU_TestRegistry* CU_pTestRegistry CU_ErrorCode CU_initialize_registry(void) void CU_cleanup_registry(void) CU_BOOL CU_registry_initialized(void) CU_pTestRegistry CU_get_registry(void) CU_pTestRegistry CU_set_registry(CU_pTestRegistry pTestRegistry) CU_pTestRegistry CU_create_new_registry(void) void CU_destroy_existing_registry(CU_pTestRegistry* ppRegistry) |
3.2 注冊簿內部結構體
測試注冊簿是測試包和相關測試用例的倉庫。當用戶添加測試包或測試用例時，CUnit維護當前活動的測試注冊簿的狀態更新，當用戶選擇運行所有測試用例時，當前活動的注冊簿中所有的測試包均被執行。
測試注冊簿結構在<CUnit_TestDB.h>中定義，它包括所有測試包的數量、所有測試用例的數量以及一個指向該注冊簿中測試包鏈表的指針：
typedef struct CU_TestRegistry
{
unsigned int uiNumberOfSuites;
unsigned int uiNumberOfTests;
CU_pSuite pSuite;
} CU_TestRegistry;
typedef CU_TestRegistry* CU_pTestRegistry;
|
3.3 與注冊簿相關的其它函數
CU_pTestRegistry CU_get_registry(void) CU_pTestRegistry CU_set_registry(CU_pTestRegistry pTestRegistry) CU_pTestRegistry CU_create_new_registry(void) void CU_destroy_existing_registry(CU_pTestRegistry* ppRegistry) |
4. 測試包及測試用例的管理
4.1 相關函數及結構
#include <CUnit/TestDB.h> typedef struct CU_Suite typedef CU_Suite* CU_pSuite typedef struct CU_Test typedef CU_Test* CU_pTest typedef void (*CU_TestFunc)(void) typedef int (*CU_InitializeFunc)(void) typedef int (*CU_CleanupFunc)(void) CU_pSuite CU_add_suite(const char* strName,CU_InitializeFunc pInit,CU_CleanupFunc pClean); CU_pTest CU_add_test(CU_pSuite pSuite,const char* strName,CU_TestFunc pTestFunc); typedef struct CU_TestInfo typedef struct CU_SuiteInfo CU_ErrorCode CU_register_suites(CU_SuiteInfo suite_info[]); CU_ErrorCode CU_register_nsuites(int suite_count, ...); CU_ErrorCode CU_set_suite_active(CU_pSuite pSuite, CU_BOOL fNewActive) CU_ErrorCode CU_set_test_active(CU_pTest, CU_BOOL fNewActive) CU_ErrorCode CU_set_suite_name(CU_pSuite pSuite, const char *strNewName) CU_ErrorCode CU_set_suite_initfunc(CU_pSuite pSuite, CU_InitializeFunc pNewInit) CU_ErrorCode CU_set_suite_cleanupfunc(CU_pSuite pSuite, CU_CleanupFunc pNewClean) CU_ErrorCode CU_set_test_name(CU_pTest pTest, const char *strNewName) CU_ErrorCode CU_set_test_func(CU_pTest pTest, CU_TestFunc pNewFunc) CU_pSuite CU_get_suite(const char* strName) CU_pSuite CU_get_suite_at_pos(unsigned int pos) unsigned int CU_get_suite_pos(CU_pSuite pSuite) unsigned int CU_get_suite_pos_by_name(const char* strName) CU_pTest CU_get_test(CU_pSuite pSuite, const char *strName) CU_pTest CU_get_test_at_pos(CU_pSuite pSuite, unsigned int pos) unsigned int CU_get_test_pos(CU_pSuite pSuite, CU_pTest pTest) unsigned int CU_get_test_pos_by_name(CU_pSuite pSuite, const char *strName) |
4.2 注冊測試包
CU_pSuite CU_add_suite(const char* strName, CU_InitializeFunc pInit, CU_CleanupFunc pClean) |
創建一個測試包，該測試包擁有自己特定的名字、初始化函數及清理函數。該測試包被注冊到一個測試注冊簿，該注冊簿在添加任意測試包之前須初始化。當前版本不支持獨立于注冊簿之外的測試包的創建，該函數不應該在測試執行期間被調用。
在注冊簿中，推薦每個測試包有唯一的名字，這樣可以通過名字查找測試包。在上述函數中，測試包的初始化函數和清理函數是可選的，如果不需要這些函數可以傳參數NULL。
該函數返回值分為五種：
CUE_SUCCESS suite creation was successful. CUE_NOREGISTRY Error the registry has not been initialized. CUE_NO_SUITENAME ErrorstrName was NULL.CUE_DUP_SUITE Warning the suite's name was not unique. CUE_NOMEMORY Error memory allocation failed. |
4.3 添加測試用例到測試包
CU_pTest CU_add_test(CU_pSuite pSuite, const char* strName, CU_TestFunc pTestFunc) |
創建一個測試用例，該測試包擁有自己特定的名字、初始化函數及清理函數。該測試用例被打包到一個測試包，當前版本不支持獨立于測試包之外的創建，該函數不應該在測試執行期間被調用。
在單個測試包中，推薦每個測試用例有唯一的名字，這樣可以通過名字查找測試用例。參數接受一個測試函數的函數指針，不可以為空，當執行測試時，該函數將被調用。測試函數沒有參數也沒有返回值。
該函數返回值分為7種：
CUE_SUCCESS suite creation was successful. CUE_NOREGISTRY Error: the registry has not been initialized. CUE_NOSUITE Error: the specified suite was NULL or invalid. CUE_NO_TESTNAME Error: strName was NULL. CUE_NO_TEST Error: pTestFunc was NULL or invalid. CUE_DUP_TEST Warning: the test's name was not unique. CUE_NOMEMORY Error: memory allocation failed. |
4.4 測試包及測試用例管理的快捷方法
CUnit定義了許多類似如下的宏：
#define CU_ADD_TEST(suite, test) (CU_add_test(suite, #test, (CU_TestFunc)test)) |
這些宏可以針對測試函數名字，自動生成擁有惟一名字的測試用例，并將該測試用例添加到指定的測試包，用戶應該驗證返回值以保證正常添加。
CU_ErrorCode CU_register_suites(CU_SuiteInfo suite_info[]) CU_ErrorCode CU_register_nsuites(int suite_count, ...) |
對于擁有很多測試包和測試用例的大型測試結構，管理測試包和測試用例的關聯和注冊是相當乏味和易出錯的。CUnit提供了一個特殊的注冊系統來幫助用戶管理測試包和測試用例。這個系統將測試包的注冊和測試用例的關聯集中起來，以縮減用戶的代碼量。
CU_TestInfo實例可以將許多測試用例集中放到一個數組，以便于關聯到一個測試包。每個數組元素包括一個惟一的名字和測試函數。該數組必須以CU_TEST_INFO_NULL結尾。
CU_TestInfo test_array1[] = {
{ "testname1", test_func1 },
{ "testname2", test_func2 },
{ "testname3", test_func3 },
CU_TEST_INFO_NULL,
};
|
同樣的，CU_SuiteInfo也提供類似的封裝功能，它將測試包名字、測試包初始化函數、清理函數和其關聯的測試用例封裝起來。#p#分頁標題#e#
CU_SuiteInfo suites[] = {
{ "suitename1", suite1_init-func, suite1_cleanup_func, test_array1 },
{ "suitename2", suite2_init-func, suite2_cleanup_func, test_array2 },
CU_SUITE_INFO_NULL,
};
|
這樣，我們將整個注冊流程簡化為：
CU_ErrorCode error = CU_register_suites(suites); |
或者
CU_ErrorCode error = CU_register_nsuites(2, suites1, suites2); |
這些函數的返回值和包注冊函數、測試用例關聯函數相同
4.5 設置當前活動測試包和測試用例
CU_ErrorCode CU_set_suite_active(CU_pSuite pSuite, CU_BOOL fNewActive) CU_ErrorCode CU_set_test_active(CU_pTest pTest, CU_BOOL fNewActive) |
這些函數被用來測試包測試用例為當前活動包和當前活動測試用例，一個測試包或者測試用例在執行測試時不會被執行，除非用戶將它設置為是當前活動的。所有的測試包和測試用例在創建時被默認設置為活動的。當前活動狀態可以通過pSuite->fActive或pTest->fActive獲取。這樣，客戶端就有能力動態地選擇測試用例去執行測試。如果參數對應的包或者用例不存在則返回CUE_NOSUIT或CUI_NOTEST。
4.6 修改測試包和測試用例的屬性
CU_ErrorCode CU_set_suite_name(CU_pSuite pSuite, const char *strNewName) CU_ErrorCode CU_set_test_name(CU_pTest pTest, const char *strNewName) CU_ErrorCode CU_set_suite_initfunc(CU_pSuite pSuite, CU_InitializeFunc pNewInit) CU_ErrorCode CU_set_suite_cleanupfunc(CU_pSuite pSuite, CU_CleanupFunc pNewClean) CU_ErrorCode CU_set_test_func(CU_pTest pTest, CU_TestFunc pNewFunc) |
4.7 測試包和測試用例的查詢
大多數情況下，客戶端可以通過注冊測試包和關聯測試用例獲取它們的引用。有時候客戶端可能需要有能力去檢索某個測試包或測試用例的引用。CUnit提供給客戶端獲取某個測試包或測試用例信息的能力。
CU_pSuite CU_get_suite(const char* strName) CU_pSuite CU_get_suite_at_pos(unsigned int pos) unsigned int CU_get_suite_pos(CU_pSuite pSuite) unsigned int CU_get_suite_pos_by_name(const char* strName) |
這些函數使用戶查詢注冊到當前活動注冊簿中的測試包?？梢酝ㄟ^傳入名字、位置參數來獲取測試包，如果該測試包不存在，則返回NULL。位置參數從1開始到注冊簿中的測試包數。按名字查詢的方式只返回測試包鏈表中的第一個測試包。如果注冊簿沒有初始化則錯誤碼為CUE_NOREGISTRY，相應的，如果按名字查找的包不存在，錯誤碼為CUE_NO_SUITENAME且返回NULL。
CU_pTest CU_get_test(CU_pSuite pSuite, const char *strName) CU_pTest CU_get_test_at_pos(CU_pSuite pSuite, unsigned int pos) unsigned int CU_get_test_pos(CU_pSuite pSuite, CU_pTest pTest) unsigned int CU_get_test_pos_by_name(CU_pSuite pSuite, const char *strName) |
如上函數和測試包查詢類似。
5. 運行測試
5.1 常用相關函數
#include void CU_automated_run_tests(void) CU_ErrorCode CU_list_tests_to_file(void) void CU_set_output_filename(const char* szFilenameRoot) #include typedef enum CU_BasicRunMode CU_ErrorCode CU_basic_run_tests(void) CU_ErrorCode CU_basic_run_suite(CU_pSuite pSuite) CU_ErrorCode CU_basic_run_test(CU_pSuite pSuite, CU_pTest pTest) void CU_basic_set_mode(CU_BasicRunMode mode) CU_BasicRunMode CU_basic_get_mode(void) void CU_basic_show_failures(CU_pFailureRecord pFailure) #include void CU_console_run_tests(void) #include void CU_curses_run_tests(void) #include unsigned int CU_get_number_of_suites_run(void) unsigned int CU_get_number_of_suites_failed(void) unsigned int CU_get_number_of_tests_run(void) unsigned int CU_get_number_of_tests_failed(void) unsigned int CU_get_number_of_asserts(void) unsigned int CU_get_number_of_successes(void) unsigned int CU_get_number_of_failures(void) typedef struct CU_RunSummary typedef CU_Runsummary* CU_pRunSummary const CU_pRunSummary CU_get_run_summary(void) typedef struct CU_FailureRecord typedef CU_FailureRecord* CU_pFailureRecord const CU_pFailureRecord CU_get_failure_list(void) unsigned int CU_get_number_of_failure_records(void) void CU_set_fail_on_inactive(CU_BOOL new_inactive) CU_BOOL CU_get_fail_on_inactive(void) |
5.2 自動模式
CUnit支持運行注冊簿中所有的測試用例，它同時支持單獨運行某個測試包或測試用例。 CUnit框架會在每個測試運行期間跟蹤測試包、用例、斷言以及斷言通過和失敗的數量。需要注意的是，每次測試初始化（即便是初始化失?。┣按蔚臏y試結果都會被清空。，如果客戶端想排除某些用例以做某個特殊測試，單個測試包或測試用例可以被設置為非活動。
自動模式接口提供非交互模式測試，用戶初始化測試并運行，結果被導出到一個XML文件，所有的測試注冊簿和測試包均可以被導出到XML文件。自動模式接口包括如下函數：
void CU_automated_run_tests(void) 該函數運行注冊簿中所有活動的的測試包，測試結果被輸出到一個名字為ROOT-Results的XML文件。ROOT可以通過 CU_set_output_filename()設置，否則使用默認文件名 CUnitAutomated-Results.xml。需要指出的是，如果不設置一個獨特的名字，測試結果會被覆蓋。
CU_ErrorCode CU_list_tests_to_file(void) 該函數在文件中列出所有注冊的測試包及相關聯的測試用例。列表文件名為ROOT-Listing.XML。名字ROOT可以通過 CU_set_output_filename()設置，否則默認文件名CUnitAutomated便被啟用，同樣的，如果不區分名字，該列表文件將會被覆蓋。需要指出的是，如果用戶需要一個列表文件，他必須顯示地去調用該接口函數。
void CU_set_output_filename(const char* szFilenameRoot) 這個函數用于設置輸出結果或列表文件的文件名，該參數后面會相應的追加-Results.xml或-Listing.xml。
文章分類:CUnit]]>
常見的 XSS 輸入
XSS 輸入通常包含 JavaScript 腳本，如彈出惡意警告框：<script>alert("XSS");</script>
XSS 輸入也可能是 HTML 代碼段，譬如：
網頁不停地刷新 <meta http-equiv="refresh" content="0;">
嵌入其它網站的鏈接 <iframe src=http://xxxx width=250 height=250></iframe>
XSS (Cross Site Scripting) Cheat Sheet 維護了一份常見的 XSS 攻擊腳本列表，可用來作為檢測 WEB 應用是否存在 XSS 漏洞的測試用例輸入。初次接觸 XSS 攻擊的開發人員可能會對列表提供的一些 XSS 輸入不是很理解，本文第二部分將會針對不同代碼上下文的 XSS 輸入作進一步的解釋。
測試工具
很多工具可以在瀏覽器發送 Get/Post 請求前將其截取，攻擊者可以修改請求中的數據，從而繞過 JavaScript 的檢驗將惡意數據注入服務器。以下是一些常用的截取 HTTP 請求的工具列表。
Paros proxy (http://www.parosproxy.org) Fiddler (http://www.fiddlertool.com/fiddler) Burp proxy (http://www.portswigger.net/proxy/) TamperIE (http://www.bayden.com/dl/TamperIESetup.exe) |
筆者曾經使用 TamperIE 對 WEB 應用進行安全性測試。TamperIE 小巧易用，能夠截取 IE 瀏覽器發送的 Get/Post 請求，甚至能繞過 SSL 加密。不過 TamperIE + IE7 工作不穩定。IE7 提供了對 IPV6 的支持，如果你并不計劃測試你的 Web 應用對 IPV6 的支持，建議還是使用 TamperIE + IE6 的組合。
如圖2所示: TamperIE 繞過客戶端瀏覽器 JavaScript 的校驗，在 POST 請求提交時將其截取，用戶可以任意修改表單輸入項 name 和 message 的值，譬如將 message 的值修改為 "<script>alert(“XSS hole!!”);</script>"，然后點擊 ”Send altered data” 按鈕，將修改后的惡意數據發送給 Web 服務器。
圖 2. 使用 TamperIE 截取 Post 請求
在輸出端對動態內容進行編碼
對一個 Web 應用而言，其動態內容可能來源于用戶輸入、后臺數據庫、硬件狀態改變或是網絡信息等。動態內容特別是來自用戶輸入的動態內容很有可能包含惡意數據，從而影響網頁的正常顯示或是執行惡意腳本。將動態內容安全地顯示在瀏覽器端與動態內容所處的上下文背景有關，譬如動態內容處在 HTML 正文、表單元素的屬性、或是 JavaScript 代碼段中。對于一個基于 PHP 語言的 Web 應用，當執行"echo"、"print"、"printf"、"<?=" 等語句時表示正在處理動態內容。本節將首先介紹 PHP 提供的庫函數 htmlspecialchars()的用法，此函數能將 5 個 HTML 特殊字符轉化為可在網頁顯示的 HTML 實體編碼;然后將介紹一些常見背景下的 XSS 攻擊輸入，以及如何在輸出端對動態內容進行轉義、編碼從而避免 XSS 攻擊。
使用 PHP 的 htmlspecialchars() 顯示 HTML 特殊字符
從上文列舉的 XSS 惡意輸入可以看到，這些輸入中包含了一些特殊的 HTML 字符如 "<"、">"。當傳送到客戶端瀏覽器顯示時，瀏覽器會解釋執行這些 HTML 或JavaScript 代碼而不是直接顯示這些字符串。< > & “ 等字符在HTML語言中有特殊含義，對于用戶輸入的特殊字符，如何直接顯示在網頁中而不是被瀏覽器當作特殊字符進行解析?
HTML字符實體由 & 符號、實體名字或者 # 加上實體編號、分號三部分組成。以下為 HTML 中一些特殊字符的編碼。有的字符實體只有實體編號，沒有對應的實體名字，譬如單引號。
PHP 提供了htmlspecialchars()函數可以將 HTML 特殊字符轉化成在網頁上顯示的字符實體編碼。這樣即使用戶輸入了各種 HTML 標記，在讀回到瀏覽器時，會直接顯示這些 HTML 標記，而不是解釋執行。htmlspecialchars()函數可以將以下五種 HTML 特殊字符轉成字符實體編碼：#p#分頁標題#e#
& 轉成 &amp; “ 轉成 &quot; < 轉成 &lt; > 轉成 &gt; ‘ 轉成 &#39; |
當直接調用 htmlspecialchars($str)時, & " < > 被轉義。
當設置 ENT_QUOTES 標記時, 即調用htmlspecialchars($str, ENT_QUOTES)時，單引號也被轉義。
當設置 ENT_NOQUOTES 標記時，單引號和雙引號都不會被轉義。即調用 htmlspecialchars($str, ENT_NOQUOTES)時，只有& < > 被轉義。
不同背景下的動態內容的 XSS 攻擊及解決方案
XSS 攻擊輸入與動態內容所處的代碼背景相關，譬如動態內容為表單元素屬性的值、位于 HTML 正文、或是 Javascript 代碼段中等等。
HTML標記的屬性為動態內容
Web 應用中，"input"、"style"、"color" 等 HTML 標記的屬性都可能為動態內容，其中"input" 標記的 "value" 屬性通常為動態內容。
例子1
<form…><INPUT type=text name="msg" id="msg" size=10 maxlength=8 value="<?= $msg?>"></form> |
攻擊XSS輸入
Hello"><script>evil_script()</script> |
將動態內容替換
將 $msg 替換為惡意 XSS 輸入:
<form…><INPUT type=text name="msg" id="msg" size=10 maxlength=8 value="Hello"><script>evil_script()</script>"></form> |
例子2
<form…><INPUT type=text name="msg" id="msg" size=10 maxlength=8 value=<?= $msg?>></form> |
攻擊 XSS 輸入
Hello onmouseover=evil_script() |
將動態內容替換
將 $msg 替換為惡意 XSS 輸入:
<form…><INPUT type=text name="msg" id="msg" size=10 maxlength=8 value=Hello onmouseover=evil_script()></form> |
分析
從例子 1 可以看到其 XSS攻擊輸入中包含了 HTML 特殊字符 < > "
從例子 2 可以看到其 XSS 攻擊輸入中沒有包含上節中提到的五種 HTML 字符， 但是 "value"屬性值沒有使用雙引號包圍。
解決方案
調用htmlspecialchars($str, ENT_QUOTES)將以下 5 種 HTML 特殊字符 < > &‘ “ 轉義;同時使屬性值被雙引號包圍。譬如：
<form…><INPUT type=text name="msg" id="msg" size=10 maxlength=8 value="<?= htmlspecialchars($msg, ENT_QUOTES))?>"></form> |
注意事項
將 input 的 value 進行轉義，必須考慮顯示和存儲數據的一致性問題，即顯示在瀏覽器端和存儲在服務器端后臺的數據可能因為轉義而變得不一致。譬如存儲在服務器端的后臺原始數據包含了以上 5 種特殊字符，但是沒有轉義，為了防止 XSS 攻擊，在瀏覽器端輸出時對 HTML 特殊字符進行了轉義：#p#分頁標題#e#
1. 當再度將表單提交時，存儲的內容將會變成轉義后的值。
2. 當使用 JavaScript 操作表單元素，需要使用到表單元素的值時，必須考慮到值可能已經被轉義。
HTML文本為動態內容
例子
<b> 歡迎：<?= $welcome_msg?></b> 攻擊XSS輸入 <script>evil_script()</script> 將動態內容替換 將$welcome_msg 替換為惡意 XSS 輸入: <b>歡迎：<script>evil_script()</script></b> |
分析
在 HTML 正文背景下，< > 字符會引入 HTML 標記，& 可能會認為字符實體編碼的開始，所以需要將 < > & 轉義
解決方案
為簡潔起見，直接使用 htmlspecialchars()將 5 種 HTML 特殊字符轉義，如：
<b>歡迎：<?= htmlspecialchars($welcome_msg,, ENT_NOQUOTES)?></b> |
URL的值為動態內容
Script/Style/Img/ActiveX/Applet/Frameset… 等標記的 src 或 href 屬性如果為動態內容，必須確保這些 URL 沒有指向惡意鏈接。
例子1
<script src=<?= "$script_url>"> 攻擊XSS輸入 http://evil.org/evil.js 將動態內容替換 將$script_url替換為惡意 XSS 輸入: <script src="http://evil.org/evil.js"> |
例子2
<img src=”<?= $img_url>”> 攻擊XSS輸入 javascript:evil_script() 將動態內容替換 將$img_url替換為惡意XSS輸入: <img src=” javascript:evil_script()”> |
分析
一般情況下盡量不要讓 URL 的值被用戶控制。如果用戶需要自己定義自己的風格及顯示效果，也不能讓用戶直接控制整個 URL 的內容，而是提供預定義好的風格供用戶設置、裝配，然后由后臺程序根據用戶的選擇組合成安全的 URL 輸出。
字符集編碼
瀏覽器需要知道字符集編碼才能正確地顯示網頁。如果字符集編碼沒有顯式在 content-type 或meta 中定義，瀏覽器會有算法猜測網頁的字符集編碼。譬如<script>alert(document.cookie)</script> 的 UTF-7 編碼為：
+ADw-script+AD4-alert(document.cookie)+ADw-/script+AD4- |
如果+ADw-script+AD4-alert(document.cookie)+ADw-/script+AD4-作為動態內容位于網頁的頂端并傳送到瀏覽器端，IE 會認為此網頁是 UTF-7 編碼，從而使網頁不能正常顯示。
解決方案
顯式定義網頁的字符集編碼，譬如
<meta http-equiv=content-type content="text/html; charset=UTF-8"> |
動態內容為JavaScript事件處理函數的參數
JavaScript 事件處理函數如 onClick/onLoad/onError/onMouseOver/ 的參數可能包含動態內容。
例子
<input type="button" value="go to" onClick='goto_url("<?= $target_url>");'>
攻擊XSS輸入
foo&quot;);evil_script(&quot;
將動態內容替換
HTML 解析器會先于 JavaScript 解析器解析網頁，將$target_url 替換為惡意 XSS 輸入:
<input type="button" value="go to" onClick='goto_url("foo");evil_script("");'>
動態內容位于 JavaScript 代碼段中
|
例子
<SCRIPT language="javascript1.2"> var msg='<?= $welcome_msg?> '; // … </SCRIPT> 攻擊XSS輸入1 Hello'; evil_script(); // 將動態內容替換 將 $welcome_msg 替換為惡意 XSS 輸入: <SCRIPT language="javascript1.2"> var msg='Hello'; evil_script(); //'; // … </SCRIPT> 攻擊XSS輸入2 Hello</script><script>evil_script();</script><script> 將動態內容替換 將$welcome_msg 替換為惡意 XSS 輸入: <script> var msg = 'Hello</script> <script>evil_script();</script> <script>' // ... // do something with msg_text </script> |
分析
如上文所示，在 JavaScript 背景中使用動態內容需要非常謹慎。一般情況下，盡量避免或減少在 Javascript 的背景下使用動態內容，如果必須使用動態內容，在開發或代碼審計時必須考慮這些動態內容可能的取值，是否會導致 XSS 攻擊。
建立PHP庫函數校驗輸入
Web 開發人員必須了解，僅僅在客戶端使用 JavaScript 函數對非法輸入進行檢測過濾對于構建安全的 WEB 應用是不夠的。如上文所述，攻擊者可以輕易地借助工具繞過 JavaScript 校驗甚至 SSL 加密輸入惡意數據。在輸出端對動態內容進行編碼也只能起到一種雙重保護的作用，更重要的應該在服務器端對輸入進行校驗。PHP 提供了strpos()、strstr()、preg_match()等函數可用于檢測非法字符和字符串;preg_replace() 函數可用于替換非法字符串。OWASP PHP Filters 開源項目提供了一些 PHP 庫函數用于過濾非法輸入可作為參考。一些常見的檢測和過濾包括：
輸入是否僅僅包含合法的字符;
輸入如果為數字，數字是否在指定的范圍;
輸入字符串是否超過最大長度限制;
輸入是否符合特殊的格式要求，譬如email 地址、IP 地址;
不同的輸入框在邏輯上存在的耦合和限制的關系;
除去輸入首尾的空格;
總結
Web 應用的安全性是一個很重要、覆蓋范圍很廣泛的主題。為了防止常見的 XSS 的攻擊，Web 開發人員必須明白不能僅僅只在客戶端使用 JavaScript 對輸入進行檢測、過濾;同時還應建立服務器端的輸入校驗、輸出編碼庫函數;在服務器端檢測、過濾輸入;根據動態內容所處的背景將特殊字符進行編碼后再傳送給瀏覽器端顯示。
文章分類:安全測試]]>
5月6日消息，《華爾街日報》從知情人士處獲悉，百度聯合寶馬、奧迪、奔馳向芬蘭諾基亞發出了收購后者HERE地圖業務的邀約，目前談判已進入最后階段，有望在兩周內達成協議。
寶馬、奧迪和奔馳在豪車市場通常是激烈競爭的對手，但如今他們因擔心硅谷掌控汽車產業而決定抱團收購諾基亞的地圖業務，以避免谷歌、蘋果或Facebook取得一項在自動駕駛汽車和車內數字服務領域的關鍵技術。
知情人士透露，由德國三大豪華汽車制造商牽頭的財團準備協同中國科技公司百度，正式就收購諾基亞公司HERE地圖業務的多數股權發出收購提議，并給予HERE遠高于20億歐元的價值。
知情人士說，談判已進入后期階段，可能在未來兩周內達成協議，但包括交易價格與股份配置等細節仍有可能改變。
這三大德國汽車制造商希望取得控制股權。百度與一名未透露的財務投資者則將取得少數股份。諾基亞也會保留少數股份。
諾基亞拒絕就此事置評。
據經濟之聲《天下財經》報道，諾基亞公司董事長昨天表示，在完成對HERE地圖業務的評估后，公司最終可能決定不出售這項業務。目前，這項業務已經吸引了來自汽車制造商和零部件供應商的目光，而社交網站Facebook和打車軟件公司Uber也很感興趣。
根據諾基亞最新財報顯示，今年一季度，HERE地圖業務營收比去年同期增長了25%，達到了2.61億歐元，而諾基亞還將這項業務的全年運營利潤率預期從此前的7%到12%上調到9%到12%。
另據外媒消息稱，芬蘭諾基亞董事長Risto Siilasmaa本周二在諾基亞年度股東大會上表示，公司還未在是否出售HERE地圖業務上做出最后決定。
據《華爾街日報》報道，百度現在也向諾基亞發出了收購Here地圖的邀約，同時聯合的還有寶馬、奔馳和奧迪，都是有錢的主。
據悉，這次的聯合收購出價有可能超過諾基亞報出的32億美元，那這么一來Here幾乎就真有可能成了百度家的了。至于寶馬、奔馳和奧迪為何也想摻一腳，有解釋稱是這德系三雄擔心硅谷掌控汽車產業。
而百度的目的就更明顯了，百度地圖目前在國內正與高德競爭，但苦于沒有自己強大圖資團隊而有些被動。百度目前負責地圖服務的團隊顯然不如Here強大。
諾基亞出售Here地圖的目的是希望能夠緩解財政壓力，將地圖業務出售后全力進攻移動網絡業務?，F在已經有多家公司進行接洽，包括FaceBook、Sirius XM、百度、亞馬遜、阿里巴巴、Uber等等。
諾基亞Here地圖，是由諾基亞推出的地圖服務。已于2012年11月20日正式登陸蘋果商城。這款地圖在上市后短短15分鐘時間內已從原來的101名上升至32名。該款軟件的功能是提供免費turn-by-turn語音導航，公共交通信息，以及豐富的道路交通信息等。但是也存在缺陷，比如在公共汽車以及地鐵等重要公共交通信息提供上經常性的設置一些無意義的導航。
Here for Android提供了一線地圖應用所需的各種功能，包括語音導航、交通信息、離線地圖(包括離線導航)，以及將自己的位置與家人好友分享等。
2014年12月11月，諾基亞的地圖應用Here for Android在谷歌Play商店中上線。2014年10月，這款應用首先出現在三星Galaxy系列產品中。[1]
2014年12月，諾基亞與百度達成一項合作協議，諾基亞地圖及導航業務Here將向百度提供中國內地以外的地圖數據服務。[2]
文章分類:IT新聞]]>
其中的缺陷和測試用例管理，發現很多思路和做法跟目前我們在進行的也頗為相似，總結如下：
缺陷管理和用例管理是一個軟件測試項目的必備，無論是數千人的國際化大企業，還是三五人的小軟件作坊。這都是測試隊伍的兩大工作成果。其中，測試用例描述測試過程的意圖，缺陷則描述這些測試用例的結果，今天談談缺陷工作流程。
缺陷工作流程為：
文字描述如下：
產品代碼-》運行測試用例-》創建缺陷報告-》三方會審討論缺陷
如果缺陷沒有批準-》把缺陷當作不修正來解決-》關閉缺陷
如果缺陷批準了要調查-》研究是代碼錯誤還是設計錯誤
如果是代碼錯誤，提議修正代碼錯誤-，在提交三方會審-》如果修正批準了-》修改代碼-》解決缺陷-》重現缺陷-》通過了則關閉缺陷;不通過，則重新激活-》重新調查是代碼錯誤還是設計錯誤
如果是設計錯誤，修正錯誤直到批準-》再進行三方會審。其他后續流程和以前類似。
在這里需要注意的是，有些缺陷需要綜合考慮優先級別，產品發布周期等因素，標注為不予修復。也就是說雖然承認該缺陷，但不會修正，或者決定推遲修正，即該缺陷會在未來的版本修正。這些不予修正的缺陷應該在releasenotes中予以注明。
這里所說的三方會審，一般意義上指的是開發測試和項目管理。
缺陷報告中應該經常避免的幾個錯誤：
1、電子郵件討論
電子郵件和缺陷系統是大多數的工程師常用的工具，所以很多時候兩者被混用就不足為怪了。然后除了開發工程師和測試工程師之外，缺陷報告還有其他的廣泛用途，所以和缺陷不直接相關的信息不應該被寫入報告。
2、缺陷漸變
缺陷漸變是說在同一個缺陷的報告中，缺陷從一個問題演變成另外一個不相關的問題。這種現象有時候發生很快，有時候過幾天或者幾個月。不管怎么樣，都要極力避免缺陷漸變。對于已經變形的缺陷，通常很難分析其中根本原因，產品支持工程師在搜索相關問題時候還會發生混淆。如果一個缺陷報告開始演變，要及時停止，并就新問題重新報告一個新的缺陷。
3、對個缺陷
如果測試人員很忙碌，他們可能會相關的缺陷記錄放在一個缺陷報告中。盡管我們盡力避免這類問題，在一個缺陷報告中報告幾個問題從來就不是好主意。這會帶來一系列的問題，比如：
(1)缺陷的優先級別不能單獨設置
(2)缺陷的決定不能單獨設置，比如立即修復還是推遲到下一版本
(3)雖然缺陷在類似領域，但是可能需要分配給不同的開發工程師
(4)在分析產品缺陷的根本原因時候，同一缺陷報告中的每個缺陷可能有不同的錯誤根源。
關于缺陷報告的時候
這似乎是管理層最喜歡干的事情，這些報告發掘和代表了各種各樣的數據。比如下面的一些度量：
(1)修復的缺陷/所有解決了的缺陷：可以衡量缺陷修正和其他決斷的比例
(2)缺陷發現率
(3)缺陷修正率：當缺陷會審標準提高時候，修正的百分比下降
(4)每個組件的缺陷數：根據功能排序可以影響哪些領域需要更多的測試
(5)如何發現缺陷：了解缺陷如何發現可以幫助根源分析和實現缺陷防止技術
(6)每個測試活動發現的缺陷：分析測試類別包括結構化測試，發布前測試，測試用例開發，自動化測試等
(7)平均解決缺陷的時間：跟蹤開發團隊對輸入的缺陷的響應速度
(8)平均關閉缺陷的時間：跟蹤缺陷的平均反應時間
缺陷數據唯一不能使用的時候：績效衡量
缺陷數據具有太多的可變量，比如：
(1)所測試功能的復雜性
(2)開發人員的編程能力
(3)規格完整性
(4)缺陷預防和缺陷發現
(5)報告的及時性
文章分類:缺陷管理]]>
使用的是： Apache 2.0.53 + PHP 4.3.10 + MySQL 4.0.23 + Mantis 0.19.2
由于服務器數據需要升級到MySQL 5.0.67，而4.*l和5.*有一些不兼容，導致，無法將舊的
Mantis的Mysql4.*庫導入到MySQL 5.*中，索性，全面升級Mantis，重新配置。
新的配置是： Apache 2.2.10 + PHP 5.2.6 + MySQL 5.0.67 + Mantis 1.1.4
配置總體手順如下：【以下內容轉載】
最近要搭建一個Bug跟蹤管理系統，開源免費的Mantis自然首當其沖。要運行Mantis，有兩種主流的環境配置：IIS+PHP+MySQL+Mantis和Apache+PHP+MySQL+Mantis，本文主要介紹后一種。
首先介紹如何在Apache上運行PHP：
1.安裝Apache
首先下載Apache服務器的windows版本，網址為：http://httpd.apache.org/download.cgi，最新版本為Apache2.2，下載完后安裝。
注意：檢查80端口有沒有被占用，本人安裝時就由于打開IIS，導致apache無法啟動。如果要查看80端口被哪個程序占用，可以在命令行窗口中輸入netstat -o -an，找到占用該端口的程序的PID，然后在任務管理器中點"查看"->"選擇列..."，勾選"PID"，找到該PID的程序，結束任務。 測試apache是否是否工作，安裝后可以打開瀏覽器，輸入http://localhost/驗證Apache是否成功，如果成功則顯示：It works 字樣。
2.安裝PHP
首先下載PHP，網址為：http://www.php.net/downloads.php，最新版本為PHP5.2.6，注意下載有兩種版本：.zip版本和 安裝版。先執行安裝版，安裝中選擇支持apache 2.2.x，那么會自動配置apache的http.conf文件、mime.types文件和產生PHP的php.ini文件。注意：在安裝中我遇到過問題，如果選擇默認安裝，則很順利沒有錯誤，如果選擇自定義安裝且將所有的組件都選擇安裝，那么會發生錯誤，原因我現在也沒搞清楚。
由于，安裝版本內容不全，沒有ext和pear等目錄，所以，安裝完后，將解壓版解壓到剛才的安裝目錄下。
3.apache與PHP整合
安裝版的PHP安裝后，apache2.2的httpd.conf，會自動添加以下兩行(如果沒有要添加上)：
PHPIniDir "G:/JCDevTool/PHP5/"
LoadModule php5_module "G:/JCDevTool/PHP5/php5apache2_2.dll"
mime.type文件自動增加如下兩行：
application/x-httpd-php php
application/x-httpd-php-source phps
注意：G:/JCDevTool是PHP的安裝目錄，如果是apache2.2，必須寫"php5apache2_2.dll"。
PHP已apache模塊的方式與Apache結合。是你的WEB網站具有支持PHP服務器腳本程序的能力。
4.測試是否配置成功
測試PHP是否加載成功：
編寫一個PHP文件(hello.php)：
將該文件復制到C:\apache2.2\htdocs中，然后瀏覽器中輸入http://localhost/hello.php，如果顯示"hello,php"，則表示加載成功。
接下來介紹如何安裝MySQL：
這個比較簡單，首先下載MySQL，網址為：http://dev.mysql.com/downloads/，最新的穩定版本為5.0.67，下載完后按照安裝向導一步一步就可以完成安裝了。
最后介紹如何安裝配置Mantis：
1.安裝Mantis
首先下載Mantis，網址為：http://www.mantisbt.org/download.php，最新的穩定版本為Mantis1.1.4，下載完后解壓到C:\mantis-1.1.4。
2.配置Apache
也就是向Apache暴露Mantis的位置。修改%APACHE_HOME%\conf\httpd.conf，在文件末尾添加以下文字，以配置mantis目錄的訪問權限：
Alias /mantis "c:/mantis-1.1.4/"
Options Indexes
AllowOverride None
Order allow,deny
Allow from all
注意：這里特別注意，必須寫成UNIX路徑的/，不能寫成Window路徑的\,否則會無法正確顯示mantis。
可選配置：如果希望在瀏覽器中直接輸入目錄名(即http://localhost/mantis)就可以訪問Mantis主頁(如果不添加，則每次都顯示Mantis目錄下的文件和子目錄列表，又安全隱患)，可以在dir_module標簽中添加上index.php：
DirectoryIndex index.html index.php
這樣就可以在瀏覽器中直接輸入目錄名了(當然，這時候訪問還會出錯，因為mantis數據庫還沒建立呢，不要急，我們一會馬上去創建。)#p#分頁標題#e#
3.配置PHP
因為我們需要使用基于PHP的應用程序Mantis,而Mantis本身的特性需要(如使用MySQL數據庫等)，就要求我們去修改php.ini文件：
(1)包含Pear庫(Mantis中用到了Pear庫)
查找include_path，改為include_path=".;C:\php5.2\PEAR"，并去掉前面的分號
(2)包含外部PHP庫(因為需要知道php_mysql.dll動態庫的路徑)
查找extension_dir，改為extension_dir="C:\php5.2\ext"，并去掉前面的分號
(3)包含PHP-MySQL庫(因為需要支持MYSQL)
查找php_mysql.dll，去掉前面的分號,這樣PHP就能調用mysql模塊了
4.為Mantis創建表、數據
訪問http://localhost/mantis/admin/install.php，輸入MySQL的用戶名和密碼，然后點擊Install/Upgrade Database，就會自動建立Mantis所需要的數據庫和所有數據表。(這里注意，這是和以前的mantis比較大的不同，以前的mantis，如 mantis-0.19.4.tar.gz版本，會提供一個db_generate.sql數據庫腳本來創建mantis需要的數據庫，而新版 mantis則通過install界面來自動創建。，還需要注意的是，這里的內容多是從mantis/config_inc.php中獲取，特別需要注意的是Hostname一欄，默認值為localhost，而MySQL安裝時變動了端口，則應該寫成 localhost:端口號，別忘同時修改config_inc.php文件)
這里還要注意一個問題，有時創建時會失敗，提示：【Checking PHP support for database type 】的錯誤：BAD database is not supported by PHP. Check that it has been compiled into your server.查看apache的log發現有如下錯誤：PHP Warning: PHP Startup: Unable to load dynamic library 'd:\\Program Files\\PHP\\ext\\php_mysql.dll' - \xd5\xd2\xb2\xbb\xb5\xbd\xd6\xb8\xb6\xa8\xb5\xc4\xc4\xa3\xbf\xe9\xa1\xa3\r\n in Unknown on line 0 這是因為不能正確加載php_mysql.dll庫，導致php與mysql不能連攜，請檢查環境變量中path是否有：【安裝路徑】\PHP和【安裝路徑】\PHP\ext 類似的配置。如果沒有請將該路徑添加到path中。特別再注意，添加后請務必重啟OS，才能生效。
5.啟動Mantis
訪問http://localhost/mantis/，出現登錄界面，(注意，mantis的默認用戶名為administrator，默認密碼為root。)
6.郵件服務器配置
在Mantis中注冊新用戶時，會給你指定的郵箱發一封郵件，點開郵件中的鏈接才可以設定密碼，因此需要給Mantis添加郵件功能。
使用phpmailer作為郵件服務器，首先下載phpmailer，網址為：http://phpmailer.codeworxtech.com，下載完后解壓到c:\phpmailer。
修改C:\mantis-1.1.4\config_inc.php，添加以下內容：
$g_smtp_host = 'smtp.sina.com.cn';
$g_smtp_username = 'xinqian3607';
$g_smtp_password = '123456';
$g_use_phpMailer = ON;
$g_phpMailer_path = 'c:/phpmailer/';
$g_phpMailer_method = 2;
$g_return_path_email = 'xinqian3607@sina.com'
把其中的內容修改為你自己的郵箱信息就可以了，趕緊點擊修改密碼，試一試能不能收郵件吧~
【-------轉載完畢-----------】
心得：
由于是第一次配置，以前都是其他人負責，所以，重新配置時很多概念都沒有，就看手順來配置，感覺很混亂，所以，去補充了一些周邊知識，了解了這些知識后，再來看上面看似很繁瑣的手順，其實就很容易理解了。
知識1：WAMP=windows+Apache+MySQL+PHP，是一個開發網絡應用程序的網絡開發平臺(全是開源軟件)，因為mantis就是 PHP應用，即Mantis就是PHP腳本語言寫出來的程序。所以，要使用mantis，先搭建好mantis運行的環境是必須的步驟。
知識2：mantis是需要數據庫來管理用戶登陸的BUG的，所以，我們還需要使用MySQL，當然，不是必須使用MySQL(插一句：mantis是希望實現與具體數據庫系統無關的更通用的bug管理系統。從現在的數據庫創建方式就很明確了。)
知識3：所以，配置的思路就是，apache(http.conf)支持PHP，PHP(php.ini)支持MySQL，apache(http.conf)支持Mantis;Mantis創建MySQL數據庫;
文章分類:Mantis]]>