Coplien首先讓Uncle Bob定義了一下TDD，Uncle Bob說明了他的三個法則：（敏捷的同學一定不陌生）

　　一個測試驅動的程序員，其不會在寫出一個測試失敗的Unit Test前，去寫一句可用在生產線上的代碼。（沒有測試之前不要寫任何功能代碼）

　　在編寫用于生產線上代碼之前，不寫過多的測試失敗的Unit Test。（只編寫剛好能體現一個失敗情況的測試代碼）

　　在現有代碼通過Unit Test前，不寫更多的用于生產線上的代碼。（只編寫恰好能通過測試的功能代碼）

　　Coplien說他有意見的不是這三個法則，而是因為這個三個法則是孤立說出來的。Coplien說他和一些咨詢師或是Scrum Master參與過很多的項目，他們發現這些項目都有兩個問題：

　　他們使用TDD的時候，軟件沒有一個架構或是framework。當然，Kent Beck說——TDD可以驅使你去做架構。但是，TDD和Unit Test 是一回事嗎？Unit Test是一個偉大的事，尤其是當你去寫API和類庫的時候。今天XP所說的TDD和UT很不一樣。如果你使用TDD來驅動你的軟件系統架構，那么，基本上來說，三個迭代以后，你開發的軟件就會crash掉，而且無法再往前開發。因為什么？因為連軟件團隊自己都受不了這三個迭代出來的架構，而且你還會發現，你根本沒去重構。

　　第二個問題是，TDD這種方法破壞了GUI（圖形界面），就算是Kent也說：“你永遠不可以在一個漂亮的界面后面隱藏一個糟糕的架構”，Coplien強烈地相信軟件的架構是通過界面來發出其光芒。他覺得如果沒有一個好的軟件架構，這個會影響用戶的操作。

　　Coplien接著說，如果我們使用Uncle Bob的三條法則，我們也許沒有什么問題，但Coplien想告訴大家另一個非常重要的事，那就是軟件架構。并說：“我根本不接受TDD是軟件專業化實踐的論點”。

　　Bob大叔說，讓我們回到99年，那時的敏捷社區覺得軟件架構是無關的，不需要軟件架構，只需要做一堆tests，做一堆stories，以及足夠快的迭代，這樣就可以讓那些代碼魔幻式地拼裝起來，這就是horse shit。對于大多數的敏捷擁護者來說，這的確是愚蠢的。今天你再和Knet說這個事，他也會說那不過是一種說法。

　　Coplien回應到，實際上，Knet在解釋XP的時候，在他的書131頁的位置說過，“是的，你得做些前期的架構，但也別把自己搞亂了”。

　　Bob大叔把話題轉回來，繼續聊關于架構方面的事，他說軟件的架構很重要，他也寫很一些關于架構的書，他說他也是一個架構方面的怪才，但是他認為架構自己并不會形成軟件的所有的外表。他覺得好的軟件架構和設計能力應該出現在若干次迭代之后。他覺得你在架構軟件的時候，你會創造一些東西，也會破壞一些東西，并且會在幾次迭代中做一些試驗性的工作，來嘗試一下不同的架構。在2到3次迭代以后，你可以知道那一種架構是對的，這樣，你可以在后面的迭代中進行調整。因此，他認為架構是需要進化和發展的，而不會因為被可執行的代碼所形成，也不會因為你所寫的測試而形成。

　　Coplien贊同架構進化的觀點，而且他相信軟件的架構的演變和進化不是因為你寫的代碼，也不是因為Use Case，也不是告訴你你的軟件需求的范圍和其中的關系，但是如果你做的方法是以增量式的，以用戶驅動式的，而你卻在和用戶溝通時沒有一些前期的業務知識，那么這一定是相當有風險的，并且你一定會把事搞砸的。

　　Coplien接著說，他在Knet早期提到TDD的時候和Knet時，提到YAGNI（陳皓注：You Aren’t Gonna Need It，XP的一個法則，也就是只做最簡單的事）時，Kent說到：“讓我們來做一個銀行帳戶，一個儲蓄帳戶”，儲蓄帳戶其實就是對余額進行一些加加減減的事，就像一個計算器一樣。Copilen繼續解釋到，但是如果你要做一個真正的銀行系統，你的軟件架構根本不可能從一個儲蓄帳戶的對象（計算器）重構出來。因為儲蓄帳戶根本就不是一個對象，其是一個流程，后面有一個數據庫的查帳索引事務，還有存款保證金和利息，還有一些轉帳功能。就算是這樣，這也只是用戶的功能，你還需要支持稅務人員和精算會計師等這些人，這會讓銀行系統成為一個錯綜復雜的軟件架構，這絕對不是你可以用迭代干出來的事。當然，Bob大叔是可以的，因為他有40年的銀行系統的經驗。但是Bob大叔你的這40年可真不敏捷啊。

　　Coplien接著說，因為Bob大叔可以在軟件前期做很多很重要的決定，這讓得后面的事變得相對比較簡單。Coplien根本不相信只要你把代碼往那一放，在上面披上一層皮，再設置好一些角色，設置好接口，在文檔里寫上整個業務結構，而你只有在有人花錢的時候你才會在其中填充進真正的代碼，反之就違反了你的YAGNI原則。所以，你只是在你需要的時候做你要做的事，但你卻還是要提前得到你的軟件架構，否則你一定會把你自己逼進死角的。

　　Bob大叔辯解到，我說的可能和你說的這個有點不同。我們應該不會像你所說的往接口中寫一些抽象成員函數，而是創建一些有抽象接口的對象。當然，我不會一下子為這個對象裝載上一堆方法。那些是我需要使用測試驅動或是需求驅動來做的事，我還會隨時隨地在看是否哪里軟件架構可以讓我拆分接口。

　　Coplien說，問題是你得知道你要干什么？他說他非常同意Knet的書”XP Explained”里說的——“你不能去猜”，然后他舉了一個例子，一個他曾經在一個電信項目中重新架構軟件的例子，這是一個長途交換機的項目，項目組特別喜歡用面向對象，有一個人需要去做一個“Recovery Object”（應該是系統恢復對象），Coplien說這是很扯的一件事，因為系統恢復根本就不是一個對象，因為他對業務不熟，所以想這么做。而當你在細節上分析的時候，你會發現這根本就不是一個有成員方法的對象。我個人認為，Coplien想用這個例子來說Bob大叔的先定義對象的抽象接口并不是一個好的需求分析的方法。Coplien還說，這個事情今天被資本化成了SOA，真是在玩火啊

　Q4階段，服務線項目特別忙，每個小二身上都承擔了兩到三個項目的壓力，情況的比較壞的是，有些項目是測試執行時間并行的，讓人有些腹背受敵的感覺，倍感壓力！總結了一些本人在項目測試執行時間并行的情況下的一些小經驗，供童鞋們參考：

　　1、每天計劃并不斷的總結，簡單可行

　　兩項目并行初期，埋頭苦干，發現工作效率很低，疏漏的地方總是防不慎防，在項目中陷入被動的境地。靜下心來冷靜思考，切身體會到工作效率的低下，照此下去，項目風險不可控！為了改變被動的處境，先簡單做了個日工作計劃，很簡單可行，兩個項目都兼顧到，執行中嚴格按照計劃的時間點集中投入時間精力，每個時間點的成果都保存并打印，執行結果反應在紙上一目了然，發的日報和qc上的記錄都清晰的顯示了白天的工作量和比重！項目的質量、風險完全可以把控！

　　2、持續的跟進需求，和業務方保持良好的溝通

　　在測試執行前和業務方重新過了一遍需求點，對項目的核心功能、重點及TC優先級劃分，執行中嚴格按照需求的優先級執行用例提bug并督促研發人員修改，并對分歧點做記錄備份，每天一匯總并體現在測試日報中，如果分歧點比較多的話，可以和業務方、PD、PM、開發人員一起討論溝通，確定最終實現方法并得到業務方認可.

　　3、在滿足業務方需求的基礎上完善產品

　　在項目中，完成業務方提出的需求功能點就完事了嗎？答案不言自明，業務方提出的只是一些基本的功能點，實現后功能是否可用、是否符合用戶的操作習慣也是必須考慮進去的，不同的客戶的專業要求不同、習慣也各有特點.做好這個部分就靠測試人員來把握了，需要和需求方多溝通，了解業務方的一些特定功能點和功能實現方式.

　　把握住以上三個方面，讓我在測試執行時間并行的不利情況下，把控住了項目的風險，希望對以后有類似情況的童鞋們有幫助！

我們知道開發人員與測試人員在某種程度上可以說是冤家對頭，因為開發總是認為我做的產品是完美無缺的，沒有Bug的，但是測試總是想方設法給你挑刺，因而產生了“矛盾”。很多公司對開發的績效評估里就有一條是每千行代碼產生的Bug量，當然是越少越好了，但是對于測試的績效評估也有一條平均每天提交的Bug量，所以表明上看起來這種矛盾真的是無法避免的，因為大家都要“混飯”吃的。

　　但是大家其實心里都很清楚，一個產品不可能沒有Bug的，或多或少，或大或小，總是會有Bug存在，不然微軟也不會這樣經常發布補丁了，連微軟這種級別的公司都會Bug，所以對于Bug的存在，我們大可以泰然處之。

　　雖然可以泰然處之，但是對于Bug我們還是需要很重視，因為既然產生Bug，總是某一方面沒有想到或者是想錯了，所以我是建議可以通過對Bug分布進行分析，找出哪些地方特別容易出Bug，然后在開發過程中特別注意。對于我們公司而言，之前說過了我們是用TechExcel DevSuite 系統來管理，所以我們在開發中會加入幾個強制檢查項，比如說是否兼容不同數據庫，是否支持不同語言，是否考慮過不同瀏覽器，開發在完成代碼如果不檢查這幾項的話，是無法把開發任務直接交給測試來測的，這樣就可以從某種程度上避免一些Bug的產生。

　　不過即使避免了總還是會有一些Bug會被找到的，呵呵，沒有Bug還要測試干嘛呀？在很多公司里測試人員的數量都大于開發人員的，像微軟這種公司，可能是2：1的關系，為什么需要這么多測試呢？

　　第一方面，當然是他們的產品太大了，太復雜了

　　第二方面，一個產品的質量光靠開發是不行的，因為開發雖然能把產品做出來，也可能可以用，但是他們可能沒法考慮其他一些方面，比如用戶體驗上，比如壓力測試上，比如不同語言下的應用，甚至是不同操作系統下的應用等等，這些方面光靠開發可能沒法想全，甚至即使想全了也做了，你能保證在哪些環境就一定不出問題嗎，畢竟開發編程總是在一個環境下的編的，他編完即使自己測了一下也不可能把所有環境下都測過的。

　　第三方面，因為一個產品/一個功能需要在很多外在環境下測試（操作系統，數據庫，瀏覽器，網絡），另外一個功能需要測試點又很多（正常輸入，非正常輸入，臨界，壓力值等），所以即使是一個功能，需要測試的地方就很多，何況產品大功能多的了。而且，我們知道一個人再強，他能想到的測試點總是有限的，所以我還需要另外的人對一個已經測過的功能點進行再次驗證測試 （關于這個方面，由于我們公司是用DevSuite 方案中的 DevTest 工具來管理測試覆蓋面的，所以稍微可以減少一些測試人員配置）。另外對于一個開發來講，由于功能點是他做的，所以別人發現了問題讓他修，其實他是可以修起來很快，代碼都輕車熟路的，所以如果一個測試配一個開發的話，可能發現的Bug量無法讓開發完全忙起來，從領導角度說這個比較浪費成本的。

　　所以考慮到這些原因，一般大公司就會有很多的測試人員了，當然現在的情況又有不少改變了，隨著自動化測試的引入，需要人工的地方會相對減少，所以有不少公司開始減少純手工測試的活，但是做過開發的人也知道，如果一個產品很復雜，光靠自動化測試是遠遠不夠的，所以呢，我相信手工測試還會在很長時間內存在，至少在我能看到的范圍呢，好像還沒法用自動化測試來代替。

　　不過在國內的話，我接觸到的大多數軟件公司里，對測試人員的配置都不太多，當然我不認為他們是忽視軟件質量，他們可能認為功能做出來了，開發直接測一下就好了，測試人員的話只要最后綜合跑一下就Ok了。我相信這個是怎么保證軟件質量的一種認知的觀念問題，我認為這樣就可以保證產品質量，你認為那樣才可以保證質量，大家各有說法，但是從我們公司的角度來說，我們還是比較看重質量的，可能也跟我們公司背景有關吧，外企，跟國外比較接軌。所以我們公司現在的開發與測試配置是大于1：1的，不過比微軟還是差一點。

　　介紹了一下測試的必要性，再回過頭來繼續說開發與測試的“矛盾”，其實這個矛盾從本質上來說是由于績效管理時過分強調了開發人員造成的Bug，而這個“過分強調”又必須是測試人員一定要強調的。所以呢，矛盾就開始產生了，開發說，這個不是Bug，或者說我不能重現，還說，你干嘛老是提Bug，是不是對我有啥不滿的。久而久之，“矛盾”產生了，激化了，產品質量下降了......從領導層角度來說，他們當然也希望開發做出來產品是沒有Bug的，這樣子我連測試人員都不用配了，成本下降很多了。當然，大多數領導也知道這個是不可能的，與其由于產品質量下降造成產品不好賣，還不如配幾個測試人員了。配了測試人員，又出現“矛盾”了，我想許多公司的領導已經處理得很好了，不過我還是想簡單介紹一下我們公司的處理方案：

序言：上篇文章說的“自動化例行測試有效性策略”，在又一次進行例行測試的時候，安排了一個不懂腳本的測試人員進行了例行測試操作，結果這是最迅速的一次，而且還發現了一些產品問題，效果不錯，驗證發現，其有效性還是得到了一些提高。所以說，有時候，做自動化測試很害怕的是“完美主義”與“盲目主義”，局限于一些誤區，所以一定要以“測試價值”為導向，不時的跳出來看一看其自動化測試的應用價值是不是進入了誤區。這次，對一些不同的自動化測試方式的應用進行了策略分析，不同的自動化測試方式應用不同的場景，不管如何應用，提高效率則是最佳應用。

　　一、自動化幾種測試方式

　　這次，自動化測試幾種方式，我暫時按測試類型分成：

　　1、界面自動化測試

　　C/S架構（或者桌面類型）界面自動化測試：包括桌面界面測試類型，當然有windows方面的軟件界面、跑在windows操作系統上的虛擬機方式的界面，例如java swing。前者采取的方式可以調用操作系統本身的API來構建自動化測試、后者可以采用虛擬機內的事件處理機制來完成了。

　　B/S架構（或者web類型）界面自動化測試：其實現原理之一可以依靠JS來進行客戶端的操作，然后尋找對象是采用了DOM解析技術，將web方面的節點進行解析定位。

　　手機方面（嵌入式產品）界面自動化測試：其實現原理之一也是可以依靠其相關系統提供的API來完成。例如：安卓的monkey就是安卓提供的一個提供動作操作的一個工具。

　　2、命令行自動化測試

　　CLI自動化測試：即嵌入式的產品很都基于嵌入式操作系統完成，例如：電信產品中的ciso路由器就是最早的代表，而系統測試人員的測試大都應用命令行進行測試，所以，其自動化測試實現可以基于CLI的腳本控制實現。當然，對數據庫SQL命令行的操作也可以歸為此類。

　　3、API自動化測試

　　API（Application Programming Interface，應用程序編程接口）是一些預先定義的函數，目的是提供應用程序與開發人員基于某軟件或硬件的以訪問一組例程的能力，而又無需訪問源碼，或理解內部工作機制的細節，其實就是軟件中的封裝性的思想。個人認為，API測試是用來驗證組成軟件的那些單個方法的正確性，其可以包括為單元測試、單個組件測試以及接口測試。一者是對單個模塊功能測試、另外一者是對測試系統組件間接口的一種測試。但本質上都是調用其API來驗證相應相應功能實現或者交互。

　　二、自動化測試不同方式策略分析

　　以前總在思考如何能夠最大化的應用界面自動化測試與CLI自動化測試或者API自動化測試的不同特點去實現各自的自動化測試最大利用率：

　　1、界面自動化測試的特點在于：

　　1）操作方式復雜，需模擬出不同的手工操作。

　　2）其界面元素結構層次變動性較大。

本文從功能、性能、可用性、客戶端兼容性、安全性等方面討論了基于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系統的測試、確認和驗收是一項重要而富有挑戰性的工作。基于Web的系統測試與傳統的軟件測試不同，它不但需要檢查和驗證是否按照設計的要求運行，而且還要測試系統在不同用戶的瀏覽器端的顯示是否合適。重要的是，還要從最終用戶的角度進行安全性和可用性測試。然而，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等也要進行驗證。
　　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站點中的所謂"相關文章列表"。
　　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的系統測試與傳統的軟件測試既有相同之處，也有不同的地方，對軟件測試提出了新的挑戰。基于Web的系統測試不但需要檢查和驗證是否按照設計的要求運行，而且還要評價系統在不同用戶的瀏覽器端的顯示是否合適。重要的是，還要從最終用戶的角度進行安全性和可用性測試。 

快速提升MySQL可擴展性的五大絕招

我對抽象類和接口的理解

今天公司組織培訓。講解到抽象類和接口這里的時候。好像有同事不太明白。（請允許我自作多情一下！）

　　鑒于我自己對這部分也不是掌握的很透徹。所以發個博文上來，一是記錄一下。二是希望還不明白的朋友在閱讀完本文之后能有個了解。

　　新手，如有不當之處，請多多包涵！

　　MSDN：抽象類是從子類發現了公共的東西，泛化（也可以說把公共的東西單獨提取出來）出父類，然后子類繼承父類，而接口是根本不知道子類的存在，方法如何實現還不確定，預先定義的

　　有一個人，他叫王麻子，那年，他生了個兒子，起名叫 王三。這個時候用程序來描述就是他和他老婆創建了一個對象 ，代碼如下：

public class WangSan     {         string FirstName;         string Sex;         void CanDo()         {             Console.WriteLine("我是王三,我會畫畫");         }     }

　　王三有 姓、性別、和一個能力，他會畫畫。

　　又過了一年，王麻子和他老婆又生了個孩子，起名叫 王四，用程序來說，他們倆又創建了一個對象

public class WangSi     {         string FirstName;         string Sex;         void CanDo()         {             Console.WriteLine("我是王四,我會唱歌");         }     }

　　王四也有 姓、性別和一個能力，他會唱歌

　　假如一下。假如他們是印度人，對計劃生育沒什么限制，他們每隔幾年都會再生個孩子出來。這樣的話。如果要用程序來描述起來豈不是很麻煩，所以這個時候我們應該考慮對代碼進行重構，提取共同的部分，也就是姓名、性別和一個能力

　　如下：

public abstract class Son     {         protected string FirstName;         protected string Sex;     }

　　因為他們都是王麻子的孩子，咱們假設一下，假設由于他們都是王麻子的孩子，所以他們必須 姓王、有性別，所以這個 基類 Son 就必須聲明為  abstract 的（創建就為被繼承）。就是說凡是 王麻子的孩子，都必須繼承自 Son 這個基類，因為他們都有王麻子的一些特性和自己的特性，

　　比如：

public class WangSan:Son     {     }

　　我們不必在 WangSan 這個類中寫任何代碼，因為他是王麻子的孩子，所以他有 姓 和 性別。。在New WangSan 這個對象的時候。他就自動的有了 FirstName 和 Sex。這些屬性。

又假如，由于王麻子是個全能人才。所以他的孩子必須會一項技術，比如游泳或者 唱歌。這個時候 基類就可以修改一下：

public abstract class Son     {        protected string Name;        protected string Sex;         /// <summary>         /// 抽象類中的抽象方法，在子類中必須自行實現         /// </summary>         public abstract void CanDO();     }

　　添加了 CanDo 的抽象方法。 這樣 當 王三 這個對象一被創建，他就必須繼承 Son 這個類（他必須是王麻子的兒子，莫非兩口子生的孩子是別人的？？）...而又由于Son 中有個抽象的方法 CanDo. 所以。王三 他必須 得有一項技術。如果不實現 CanDo .編譯不通過（你不實現，就不能說明你是我孩子，以后我對你不好！）

public class WangSan:Son     {         public override void CanDO()         {             Console.WriteLine("我是王三，王麻子的孩子，我必須有一個擅長，那我選擇唱歌");         }     }

　　這樣。王三也必須會一項長處了！！

　　王四也是一樣。只要他是 王麻子的兒子。他就必須實現 CanDo 方法，并且有FirstName 和 Sex屬性

　　又假如有一天，王麻子偷師學藝，學會水上漂。但是他不知道誰愿意學，又不想強迫孩子們。所以他讓孩子們自己決定。他定義了一個接口（發布了一個規范） IShuiShangPiao。

interface IShuiShangPiao {         void CanFly();     }

　　誰想學。就來我這里報道。結果王武想學。所以王武來報道了（程序解釋就是王武實現這個接口）

public class WangWU : Son, IShuiShangPiao     {         public override void CanDO()         {             throw new NotImplementedException();         }         /// <summary>         /// 實現接口（報道），老爸就教我水上漂         /// </summary>         public void CanFly()         {             throw new NotImplementedException();         }     }

　　回到我們軟件開發當中，假設以上類是我們程序中實現的一項功能，假如某一天，我們發現（或者客戶要求）：凡是王麻子的孩子都必須會英語，這個時候，我們就僅僅只需要在 Son 這個類中 增加一個會說英語的方法。他的孩子們就都會說英語了。如果不采用繼承的話。假設王麻子有1萬個孩子，那就得修改一萬個類，很累。。。。

　　以上就是我個人針對 抽象類和 接口的理解，如有不當之處，敬請提出！

　　程序需要慢慢重構，這個我當時理解起來也非常不容易。多練習，多思考就會豁然開朗！

　　但是切記，千萬不要為了設計而設計。造成過度設計會很糟糕的。。。就好像我們設計數據庫，雖然有3大范式，但是有時候業務迫使我們不得不違背。。。。

　　以上！

　　希望對這部分不明白的朋友通過本文能對這部分知識有個進一步的了解。同時希望各位的技術一天牛比一天！！

　如果您很容易使 shell 提示行變得色彩絢爛且帶有更多信息，為什么還要堅持用煩人的標準提示行呢？在這篇技巧中，Daniel Robbins 將說明如何獲得符合您的意愿的 shell 提示行，并會說明如何動態更新 xterm 的標題欄。

　　作為 Linux/UNIX 人，我們有很長的時間是在 shell 中工作，并且在許多情況下，下面這一行就是始終盯著我們的那個提示行：

　　bash-2.04$

　　如果您恰巧是超級用戶 (root)，您就有權使用下面這個美麗的標示“身份”的提示行版本：

　　bash-2.04#

　　這些提示行并不是十分漂亮。這也就難怪幾種 Linux 版本對默認提示行進行了升級，在其中增加了顏色和更多的信息。但是，即便您恰好有一個本身帶有很好的彩色提示行的新式版本，它也不可能是完美無缺的。您或許希望在提示行中增加或更改幾種顏色，或者增加(或刪除)一些信息。從頭開始設計屬于您自己的彩色的、經過裝飾的提示行并不難。

　　提示行基礎

　　在 bash 下，可以通過更改 PS1 環境變量的值來設置提示行，如下所示：

　　$ export PS1="> " >

　　更改會立即生效，通過將 "export" 定義放在您的 ~/.bashrc 文件中可將這種更改固定下來。只要您愿意，PS1 可以包含任意數量的純文本：

　　$ export PS1="This is my super prompt > " This is my super prompt >

　　盡管這很有趣，但在提示行中包含大量靜態文本并不是特別有用。大多數定制的提示行包含諸如用戶名、工作目錄或主機名之類的信息。這些花絮信息可以幫助您在 shell 世界中遨游。例如，下面的提示行將顯示您的用戶名和主機名：

　　$ export PS1="\u@\H > "drobbins@freebox>

　　這個提示行對于那些以多個不同名稱的帳戶登錄多臺機器的人尤為有用，因為它可以提醒您：您目前在哪臺機器上操作，擁有什么權限。

　　在上面的示例中，我們使用了專用的用反斜杠轉義的字符序列，藉此通知 bash 將用戶名和主機名插入提示行中，當這些轉義字符序列出現在 PS1 變量中時，bash 就會用特定的值替換它們。我們使用了序列 "\u"（表示用戶名）和 "\H"（表示主機名的第一部分）。下面是 bash 可識別的全部專用序列的完整列表（您可以在 bash man page 的 "PROMPTING" 部分找到這個列表）：

　　序列說明

　　\aASCII 響鈴字符(也可以鍵入 \007)

　　\d"Wed Sep 06" 格式的日期

　　\eASCII 轉義字符(也可以鍵入 \033)

　　\h主機名的第一部分(如 "mybox")

　　\H主機的全稱(如 "mybox.mydomain.com")

　　\j在此 shell 中通過按 ^Z 掛起的進程數

　　\l此 shell 的終端設備名(如 "ttyp4")

　　\n換行符

　　\r回車符

　　\sshell 的名稱(如 "bash")

　　\t24 小時制時間(如 "23:01:01")

　　\T12 小時制時間(如 "11:01:01")

當測試和開發在一起的時候事情好像是向著兩個極端發展！

　　一是開發人員很厭惡測試人員給他們提BUG（當然存在這種想法的開發人員也很少），另一個則是開發人員很想讓測試人員幫自己糾錯！

　　這次我們幾個測試人員要和開發人員急了！BUG太多，每個工作流都走得舉步維艱！

　　平時在公司很自由，開發在二樓，測試在三樓，上個月看需求，寫測試需求和測試用例，過得挺安逸！搞不明白的地方就直接打電話給項目經理及其他兩位帶頭人！很少正面和開發人員接觸！我們測試團隊的老大說任何需求上有疑問處和那三位負責需求的人商量，不要問開發人員！

　　現在項目進行到封閉階段，集成測試，和開發人員坐一起面對面辦公，改變了以往的平靜！

　　我們測試團隊到后，項目經理就讓我們盡快展開工作，發揮我們的找BUG的作用！呵呵！

　　幸福的是這次給我配置了一臺新的電腦（臺式），配置較高，速度挺快！不幸的是我的機器同時作為服務器，多的時候會有十幾個人連我的機器！

　　項目緊，清明節前要先交給客戶一個版本看看！但是現在我們用測試版，流程都走不通！每進行一步都會發現BUG！模塊之間的嵌套有些復雜！想把整個流程走通還是很難！

　　和他們開發人員講趕緊把某某BUG改了，他們也是不斷地到我的機器上查看數據庫！找到源頭，發現問題，然后去改！但有時大家會都比較忙，有點混亂，和他們說了當是沒說！昨天項目經理對開發人的機器實行了物理隔離！我們和開發人員之間雖然面對面坐著，但是想傳個什么文件都還要用U盤來拷貝！估計下一步要給我們測試機也斷網了！這樣大家交流又會困難些！

　　一個同事氣急之下和旁邊的開發人員說“我不測了，你先改吧，等改好了我再測！”我們幾個異口同聲“支持”！呵呵！他們開發人員也報以很無奈的表情！只好和她說好話，大家好好商量！

　　中午大家在一塊匆匆吃過飯，項目經理招呼大家去休息會，幾個開發人員說哪能睡得著！又回去工作！中午搭載我那臺服務器，也和他們一塊勞作！

　　有時候會很急的是和他們說的問題改不了，想測試下一個流程無法進行，或者是他們修改的效率很低，耽誤我們測試的進展！但是他們說我們測試團隊的人很細心，也表示很感謝！既然開發人員都這么說了，我們測試團隊成員也得稍微大度一些，得控制一下情緒了！時間趕得緊，有些環節沒安排太好，也要大家共同相互理解一下了！一位項目指導人和我聊天時說現在他們的編程能力已經有很大的提高了，問問題的質量也高了很多！

　　測試團隊和開發畢竟還是一個團隊，還是和諧相處吧，有時偶爾雖然會有些哭笑不得！呵呵！

程序員應知——關注細節

　曾經有一句話，叫做“細節決定成敗”，充分說明了細節對于成功的作用。如果我們注意一下，就會發現很多因為注重細節而獲得成功的案例。

　　產品的細節

　　蘋果的系列產品我們都已經非常熟悉了，各種各樣i打頭的產品，對于細節已經給予了非常大的關注。尤其體現明顯的就是在對用戶使用的友好度和便利性方面的細節。iPad、iPhone和iTouch等產品都是大大的屏幕，而在正面就只有一個按鈕，用戶不必考慮到底需要按什么按鈕。而系列產品的做工更是讓人贊不絕口，這也是另外一個細節。

　　另外對于國內的電子書產品，bambook我感覺細節做得也很不錯，首先所使用的硬件質量都很好，我已經用了快一年的時間了，每個按鈕還和剛擁有的時候一樣靈活；電池也一直非常耐用，充一次電基本上可以至少用大半個月，這還是因為我幾乎每天上下班的路上都會使用它來看書。曾經在使用的時候遇到一位用漢王產品的人，和我抱怨那款電子書的問題，首先就是按鈕，沒用兩個月就壞掉了；還有電池，剛開始的時候能撐一個多月，但不長時間之后，就只能撐幾天了。按鈕、電池，看起來都是很細節的東西，但確實直接影響到了用戶的體驗，從而影響了用戶對于產品乃至于企業的印象。

　　服務的細節

　　以上說的是產品，對于服務也是一樣，同樣需要關注細節。最近一段時間最火的飯店應該就是“海底撈”了，有無數的故事讓人來傳說，其實他們的服務充分體現了關注細節這一特點，不僅僅是產品的質量，更包括了服務的質量，他們能夠關注于客戶的各種反應，從而做出讓人最滿意的服務，那樣才獲得了巨大的成功。盡管說“海底撈你學不會”，但我們至少可以學習他們關注細節這一點，呵呵。

　　程序員要關注細節

　　作為程序員，我們的工作有很多，一方面需要創造出各種系統，編寫各種程序，制造各種產出物；另一方面要和客戶溝通，為最終的業務用戶服務。無論哪個方面，我們都需要關注細節，那樣才能夠把工作做得更好。

　　在創建產品方面，我想我們可以做的有：

　　● 所有程序外觀、使用方式統一，從而讓用戶更容易地學習和使用

　　● 程序代碼遵守規范，便于維護和修改

　　● 各種功能使用簡單，程序幫助用戶做盡可能多的事兒

　　● 協助用戶改進不合理的工作方式，幫助用戶提高工作效率

　　● ……

　　其實這還比較籠統，更細節的問題可能會是：

　　● 界面上的文字是否有錯別字？

　　● 文字的大小、顏色是否符合規范？

　　● 各種提示信息是否規范，是否真正有助于用戶發現并解決問題？

　　● 代碼中的注釋是否必要，是否能夠正確地為代碼提供補充說明？

　　● ……

　　如果能夠做到關注細節，那么不管是對于用戶，還是團隊中的其他開發人員來說，我們所體現出來的就是一種專業的精神和專業的態度。