精彩回答：
天順：
這個問題仿佛就是問我的一般。先說說我自己。
我畢業后從事了相當一段時間軟件測試的工作，最高做到高級測試工程師，帶部門2/3的測試工程師，負責公司大多數項目的測試管理。在做測試的過程中，我漸漸對產品經理這個工作產生了興趣。
每當研發和測試為了功能點吵得不可開交的時候，最經常聽到的一句話是：別煩了！問產品經理不就知道了！
每當項目上線后，技術的同事們都相當盼望著知道項目的結果（別說技術同胞們是死腦筋只會寫代碼，項目給公司帶來利潤多少，是否成功，是很多技術同事非常關心的，成就感這東西不是簡單用錢能衡量的），大家第一個想到的就是去問產品經理（公司2，沒有獨立的運營崗）。
每當業務討論時想不出為何要這么做的時候，也都會去問產品經理。
毫不夸張的說，在當初我們這些“土鱉”技術眼里，產品經理是能寫代碼、能找BUG、對內能說清業務，對外能忽悠客戶的一群人。當時我希望成為產品經理， 一來是希望自己在業務上能有所進步，成為行業內業務的專家；二來是希望在薪水待遇上有所提升，獲得一個更為廣闊的職業發展平臺（我也不避諱，在當時的公 司，隨便找一個產品經理的薪水，都是和部門主管水平相近的，而測試在公司是不受重視沒有前途的）。其實從現在來看，當時的我挺可笑的，但已經走了這么一條 路，只有繼續好好走下去了。
OK，扯了那么多有的沒的，LZ問的問題還是沒回答，我當時怎么做的呢？我后來也想了一下，有幾個方面導致了后面能順利內部轉崗成為產品經理：
1、產品部同事的認可（人和）
當時作為測試負責人，在項目過程中與產品經理有相當多的接觸。在產品部門這邊，有很多欣賞我的同事。有些同事在產品經理職位有缺口的時候，向產品總監推 薦我內部轉崗。而我又是與產品部總監以及高級產品經理同坐一部公交車回家，路上碰到的機會相當多，自然就熟悉了，為后期轉崗打下了人脈的基礎。
2、相對其他技術同事，我接觸公司業務機會更多（地利）
因為公司測試部門剛起步，人員不夠，所以沒有將人員很機械地劃分到對應的業務線，作為測試這邊的項目負責人，我可以接觸到公司各式各樣的項目，這些項目豐富了我對支付業務的認識，為日后成為產品經理打下了業務基礎。
3、最重要的是運氣（天時）
這個看似很扯淡，不是嗎？LZ問的是如何能成為，而我強調的居然是運氣。
事實上，當初如果不是因為測試主管欣賞我，提拔我做高工，管理項目，我沒有那么多機會接觸公司方方面面的各類業務，就無法從各個角度了解公司業務，就不具備當時公司對產品經理的基本要求。
如果當初公司產品經理職位沒有空缺，而我與產品總監完全不認識，我就根本沒有機會轉崗。
如果當時部門主管心眼小，知我想轉作產品時，橫加阻攔，給我穿小鞋或者拒不放行，我亦沒有機會。
所以我后來反反復復分析自己當時轉崗的過程，也覺得自己實在是運氣很好。
4、自我積累
在正式提出轉崗做產品前，我請教了很多產品經理，向他們咨詢看法。平時工作中也漸漸關注產品經理們經常使用的工具，經常關注的問題。不懈地學習業務知識，積累自己對行業的了解，積累同事們的口碑。
總結一下就是，積累必要的業務基礎，人脈，等待最好的時機。
以上，其實每個人的路途都不盡相同，別人的過去只能給你當做參考。倒是LZ不妨多想想自己究竟為什么希望成為產品經理。
成為產品經理后，以下是我經常反思的：
1、如果拋開薪資待遇，產品經理工作是否就比當時做測試更讓我喜歡，更容易讓我充滿激情地工作。
2、如果當時沒有轉崗成為產品經理，是否意味著我的職業平臺將狹小很多，測試工作是否真的像我當初所認為的“沒有發展前途”？
3、成為產品經理后，如何更好地利用過去測試時積累的經驗，將這份新工作做好？是否有能力改變公司里對測試有偏見的氛圍？
最后，潑些涼水。
產品經理在很多公司，并不像很多人想象的這般風光無限。很多時候，他的標簽包括帶不限于：“備胎測試”、“備胎架構師”、“備胎項目經理”、“備胎運營”、“寫文檔的”、“寫會議紀要的”、“背黑鍋的”。
產品規劃？那是老板的事。
方案的確定？那是總監的事。
頁面圖標用什么配色？那是UED的事。
項目進度運籌帷幄？那是項目經理的事。
別人不想干的事？沒錯，多半是你的。
所有和產品有關的事，都是產品經理的事。
這句話聽上去很拽不是么，翻譯一下很有可能變成：這個事情太煩了，不搞了，反正到最后沒人弄，產品經理也會想辦法的。
這不是開玩笑，而是時時刻刻發生在全國各地，各類行業，各種產品經理身上的真實場景。產品經理，互聯網產品經理，尤其是目前中國的互聯網產品經理，絕大多數不是外人所想象的風光角色！
任何人都可以拋棄產品，拍拍屁股走人或者搗糨糊，但產品經理不可以。關于產品的任何細枝末節都是產品經理的工作范圍，任何對產品有影響的工作，產品經理都要過問并清楚。產品進度慢了、產品方案改了、產品上線出BUG了，沒錯，有人要承擔責任，產品經理一定是其中之一。
做產品經理意味著你選擇了一條操心勞累，可能會沒日沒夜，可能會鞠躬盡瘁的道路，如果沒有這個覺悟，還是再想想，再想想。
龔博致：
產品經理其實是沒有標準的，只有一些大致的指導方向。在各個公司各個部門各個階段，它的職責側重都可能有不同。按我的理解，大概有：
1、產品型產品經理。這個是最正統的，他的重點職責就是向協同部門（如運營）收集需求，設計產品，和開發溝通跟進進度，上線后跟蹤，總結。
2、商業型產品經理。也可能叫運營型。貼近運營側，直接接觸用戶，從反饋中總結/提取需求，偏重于用現有方案/產品解決問題。
3、技術型產品經理。分析已有產品，推動整合、打通、改造。產品發展久了，業務變化下就會出現功能重復、業務分裂等問題，需要改版重構，這個時 候涉及多個系統打通，甚至需要把底層平臺當成一個產品來打造，然后再支持原有產品的做法。所以這時候重點在于了解各個產品底層需求，了解技術背景，提供嚴 謹的功能文檔（因為涉及的功能太多）
所以對于轉產品經理需要做什么準備，其實主要還是需要看你們老板想要什么樣的產品經理，部門有什么資源來幫你分擔職責，以及你想成為什么樣的產品經理。例如：
● 如果部門有項目經理，項目管理可以先不看。
● 如果可以的話，熟悉一下產品的文檔/流程，然后結合測試經歷提出自己的想法，自己實踐一下來證明給老板看，再推廣
● 如果是想做線上產品，那一般是要趕緊補運營課，了解產品的指標，定計劃/里程碑/KPI
如果沒有概念，那最簡單了——全都做，多看多聽多想。
產品經理是個“多面手”，意思就是你什么事情都要做得要多——多找人溝通，設計的時候多想一想，文檔多描述清楚一下，上線后多跟進一下……（其實這些標準所有崗位都一樣：D）
所以任何一個方面的提升都是提升，多交流，多看書，多看帖，多參加分享，然后你會接觸到很多相互沖突的理念——別糾結，不用全學。多思考，然后吸取你覺得適合你的那部分就行了，此之甘露，彼之砒霜。
設計是用戶需求到編碼實現的必經階段，軟件項目在設計階段的稟賦決定了軟件項目的資質。好的軟件設計不是軟件項目成功的唯一條件，但是沒有好的設計軟件項目肯定無法做好。
一、軟件設計的重要性體現在以下幾個方面：
1、軟件設計在整個軟件項目的建設中起著承上啟下的重要作用。
從整個軟件項目開發階段來看，軟件項目可以分為需求、設計、編碼、驗證四個階段。設計承接需求分析，基于準確的需求分析，對項目目標進行結構化搭建。設計階段產生的設計說明書以及設計規范是編碼階段的作業指導，也是測試人員開發測試用例的指導書。
2、軟件設計是對軟件項目質量進行保障的關鍵步驟。
軟件項目的質量與需求分析、設計、編碼、驗證段這四個階段的質量之間的關系，可以用C語言表達為：最終的軟件質量 = 需求分析質量 && 設計質量 && 編碼質量 && 驗證質量，這種“與”的關系表明任何一個階段出現質量紕漏，軟件項目的最終質量都無法保障。
3、設計階段提供的軟件表示，使軟件項目質量的評價成為可能。
反映軟件設計質量的要素有：準確性、穩健性、安全性、通信有效性、處理有效性、可操作性、完備性、一致性、可追蹤性、可見性、可擴充性、復用性、模塊 性、清晰性、自描述性、簡單性、結構性、硬件系統無關性、軟件系統無關性、文檔完備性等。通過這些考核要素對設計階段質量進行控制，從而達到從項目前端控 制軟件質量的效果。同時該階段的設計規范也是進行軟件質量評價的參照標準與基本要求。
因此，想做好整個軟件項目的質量保障，必須充分重視設計階段的質量保障工作。山東省軟件評測中心作為國內最早一批獲得國家實驗室認可并取得政府授權的中立的第三方機構，在十余年的軟件項目質量服務過程中發現：
二、設計階段經常出現的質量問題從大的方面看有以下幾種原因：
1、需求分析階段工作不充分
好的軟件設計必然基于準確的需求分析，離開正確的需求分析，軟件設計就是做得再好，在源頭上也是錯誤的，更無任何意義，有時甚至是南轅北轍。有些軟件項 目因為工期緊張或乙方軟件企業管理不規范，甲方用戶人員技術受限或配合不到位或承建方需求分析人員業務、技術經驗不足等這樣那樣的原因，需求調研沒有做 透，更有甚者基本的業務邏輯還沒有完全理清，就匆匆開始需求分析然后又囫圇吞棗的進行自我想象中的架構設計，結果可想而知。
2、設計不充分
有許多軟件企業不重視設計階段的工作，或者略掉設計直接進行編碼。這樣必然把許多的問題遺留給編碼階段，等寫了一部分代碼后再后頭看，錯了，返工……另 外，設計人員由于技術欠缺或經驗不足，或者對業務理解不夠深入，未能充分考慮后期需求變動對設計的影響也是造成設計不充分的一類重要原因。
設計不充分往往導致頻繁變更與諸多性能、安全方面的漏洞。在軟件項目里，越是在項目前期發現問題，解決成本越低。據相關機構統計，在設計階段發現偏差比在需求分析階段發現并修正要高出5 倍，在編碼階段覺察偏差則會提高到10倍，而如果延續到單元測試或系統測試階段發現設計缺陷修正成本則會提高到20倍。另外，設計人員由于技術欠缺或經驗不足，或者對業務理解不夠深入，未能充分考慮后期需求變動對設計的影響也是造成設計不充分的一類重要原因。
3、過度設計
與設計不充分相對應的一種情況是設計過度，過度設計一般是由于設計人員在做項目分析設計時，過分的考慮潛在的、未來的以及準備擴展等因素，過度的抽象， 過多思考封裝、分離解耦，導致太多顆粒單位，太多插件等等，給設計資源造成不必要的浪費，并且可能導致原本可以簡單實現的邏輯變復雜，造成系統整體性能的 下降與維護成本的上升等等，以至于影響到用戶體驗或者簡直沒法用。
上述情況都會造成軟件設計質量的下降，那么我們應該如何做好設計階段的質量保障工作？
三、如何才能做好軟件項目設計階段的質量保障
1、思想上重視
充分認識設計階段的重要性，從思想上強調設計階段質量保障工作的必要性與重要性。關于軟件設計的重要性前文已從幾個方面作了總結，不再贅述。項目團隊成員與甲方都要充分理解并一致認同設計規范與設計評審等質量管理措施對整個項目的意義與重要性。
2、選用合適的設計思想、設計方法
設計開始，在充分了解需求與項目背景的前提下，結合項目情況采用恰當的設計思想與設計方法，從設計的指導思想與方法上避免設計階段的質量瑕疵。 我們在做軟件設計時還要根據項目的具體情況與應用場景選用合適的設計思想作指導，選用合適的建模方法幫我們盡快理清系統的業務邏輯并理出思路。
從方法學的角度來講，軟件的設計與開發從最初的機器語言-匯編語言發展到面向過程的結構化設計方法，到現在應用較多的面向對象、面向組件發展到面向服務，每一步都體現了不斷抽象、更加貼近業務實務的發展趨勢。
不管采用什么樣的設計方法進行架構設計，設計都需要以充分滿足項目需求為目的，任何分析與設計方法只有針對具體問題才有實際意義。另一方面要考慮的是，采用的方法要側重滿足項目或產品的質量需求，也就是非功能性需求。確保設計階段的質量無憂。
3、項目管理上避免
項目管理是貫穿整個項目生命周期的，80%的軟件項目質量問題是由項目管理造成的。軟件設計階段作為軟件項目的一個重要環節，要做好質量保障自 然離不開好的項目管理。從設計團隊組建到角色分工與權責確定，到設計規范的制定與流程梳理，所有這些工作都需要一個好的團隊負責人去把控。設計團隊負責人 還要重視設計評審，通過設計評審不斷發現問題，逐步完善細化設計架構與詳細設計說明書，作為后期代碼實現與測試用例編寫的指導。要重視項目經理的作用，項 目經理的職責是進行溝通，促進溝通并建立溝通的渠道。只有通過溝通才能在項目成員間建立起認同與理解，從而將設計思路有效實現。
4、引入專業的第三方質量保障服務機構指導
一般的項目建設，乙方自己充當質量保障的角色，部分軟件企業為了降低成本，盡可能的減少質量保障環節的資源支出，致使設計質量無法保障，即使有 部分軟件企業視質量為生命，建立了良好的質量管理體系，但是囿于精力所限或趕工期或質量保障經驗上的限制，設計質量也是不能令人滿意。而從甲方看，一般囿 于人員、技術、精力的限制，甲方很難有精力或技術能力去對項目的質量進行深入的關注。更何況軟件本身并不可見，充滿復雜的邏輯關系，模塊之間的耦合關聯度 不易把握。第三方質量保障服務機構靠技術與服務來贏得客戶信任，因而更加重視項目的質量與最終用戶體驗。從而會更加專業的對待項目過程中的質量管理。
綜上，算是拋磚引玉，歡迎探討！
Q（ amandating ）：
看著大家豐富的閱歷和工作履歷，以及職業前景的廣闊，不禁想起自己可憐的履歷。
沒有開發背景的碩士（還不是computer專業而是communication專業），工作直接做了測試，接著做QA，現在兼職做EGP成員。
想問問專家，指點一下，最佳發展道路是？難道一直做QA？
同時說明一下發展道路上所需的資質，多謝了
A（ lilyli ）：
我的學歷不及lz，但是工作經歷上多了開發和項目管理兩個階段，這兩個階段的工作經歷對于我做QA的幫助還是很大的，因為我可以結合我的項目經歷，站在PM的角度和開發工程師的角度看問題，開展符合項目情況的質量管理活動。
個人認為QA是比較富于挑戰性的工作，具備了項目開發知識還不夠，還需要在軟件工程、溝通能力、工作方式方法上做提高，才能幫助QA工作更好的開展。
發展的道路沒有最好的，只有最適合的。如果你喜歡QA工作，那就做下去，興趣會使工作變的更愉快
A（steplv）：
關于樓主問的問題，我略談一下自己的淺見。
你問的是QA的職業發展道路與所具備的資質，在這里，我不想扯遠，就這兩點，我大體談談自己的看法。
1、一直走QA這條路
如果單純要走QA這一條路，要具備什么素質，我曾經寫過一篇文章《淺談QA所應該具備的知識》（在本網站中的地址是：http://www.51testing.com/html/32/n-78432.html）， 這里面有詳細敘述，這里不再多說。但如果說QA這一條路的發展，個人認為，隨著中國軟件企業越來越多的走出去（做外包或者其他），勢必需要具備國際認可的 標準與規范，就跟“Made in China”這個品牌一樣，需要接受國際環境的挑戰，那么， 作 為行業的發展，QA將來一定會有所作為的，就跟現在PM的價值一樣，只是體現方式不同而已。所以，一定要相信，QA這個行業在將來一定會有所發展并初具規 范與規模，當初本人選擇這個行業也是在無形中看到了這點。畢竟社會是進步發展的，QA這個行業也是一樣，需要發展，可能只因我們現在處于初級階段，所以會 存在太多的困擾，但正因為有這些困擾，所以才需要我們去解決。
2、走向QA管理
我這里所指的管理，是指QM（質量管理），逐漸上升成為QML。這個過程需要大量QA經驗、項目開發與管理經驗、甚至軟件配置、軟件測試等經驗的積累，也許過程比較長，也許比較短，一看機遇，二看自身能力。需要具備的資質還是包括“第1條、一直做QA這條路”中的內容，只是要求更精，而且此階段尤其突出溝通能力、協調能力，并要注意培養自己的情商、逆商。
3、走向高級管理
這里所說的管理，是指總監這一級別，也就是所謂的質量總監（或分管質量管理副總），如果真正走到這一步，那是相當的牛氣了。這個階段，專業知識體系不在 話下，更多的是側重于對于整個企業質量管理體系的建立與優化、維護，企業的研發流程管理優化與維護，以及質量戰略的制訂、統籌企業管理。具備的素質我也不 知道，呵呵
Q（ amandating ）：
在我們這里，好像QA唯一有前途的發展道路就是做咨詢了。你們怎么看呢？
A（ lilyli ）：
我覺得QA轉管理的可行性是比較高的。我的分析主要基于這么幾個方面：
1、QA需要具備很強的溝通能力，這點也是作為管理者的基本要求。
2、QA要有發現問題、分析問題并解決問題的能力，從組織的日常工作中發現可以改進的地方，并執行改進。這個能力也是作為管理人員的基本要求，管理就是發現問題、分析問題并解決問題嘛。
3、QA工作可以涉及到組織工作的方方面面，大處著眼小處著手，很鍛煉人的。真要練成了一定的功力，轉管理是自然而然的事。
當然，還得看組織只否具有這種競爭管理職位的機會哦
A（ grace ）：
還有一種和QA差不多的職位，是項目監理
A（tyrone）：
呵呵，其實我覺得這樣的討論會讓人很泄氣呢。因為 QA 原本是一項過程，后來因為資源管理的需要，把技術特性類似的工作集合在一起，發展成為一個部門。 QA 其實是公司里每一個人的責任，但是現在誤打誤撞成了一項看似專業又不像是專業的領域。不過，最好是成立這種部門的公司，人力資源管理單位，能夠為這些人發 展一個職涯流路，或者在社會上，有系統地成立 QA 的專業協會，利用群體的力量，建立專業知識技能認證體系，并透過立法的方式，真正形成 QA 專業，讓軟件或產品的開發制程中，一定要有 QA 專業人員的參與，就如同蓋房子要有建筑師及鑒測專業人員的參與，而且這些人一定要專業執照才行。
QA 人員如果沒有項目管理與產品開發經驗，一定要設法申請去參與，那怕是一年兩年的時間，這些經驗對于未來職涯會有非常大的幫助。
一個公司的 QA 部門如果非常強的話，就可以做很多事情，例如去承攬其它公司的 QA 、測試的工作，這樣公司的 QA 部門可以從成本中心變成利潤中心，或者到達某一個規模的時候，又可以把這個部門獨立成為一個子公司，除了承攬母公司的 QA 與測試的工作外，更可以對外做更多 QA 、測試、審計、項目監理、第三方驗證與確認、質量保證咨詢等等服務的業務，不斷培養自己的專業領域，例如專門在飛航控制或交通方面的軟件測評、核電廠控制 系統的軟件測評、汽車電子自動控制類軟件的測評、銀行金融系統軟件的測評 ……. ，看來錢景不錯呢，因為中國的內需市場夠大。
QA 人員的發展方向，并不會是 EPG 而已，而是其它的相關事業，例如，軟件測評中心、產品開發維護項目監理公司 （ 職司開發與維護的驗證與確認 ） 、質量管理咨詢公司等等，在這類的公司里，所有的管理技能都會被需要，可以有各種職務分工，包括測試、模擬、評估、驗證與確認、審計等等服務的專業了，在 這些公司里，也可以導入 CMMI（ 未來還有 CMMI-SVC 呢 ） ，想當 EPG 的機會多得很。而在這類公司里，又有總經理、技術總監、測試工程師、項目經理、質量保證人員 ……. 等等職務，從這些角度去看，其實不管是那一類人都有很好的發展呢。
◆ 簡介 在您開始閱讀這篇文章之前，我得明確地告訴您，我并不是一個數據庫設計領域的大師。以下列出的 11 點是我對自己在平時項目實踐和閱讀中學習到的經驗總結出來的個人見解。我個人認為它們對我的數據庫設計提供了很大的幫助。實屬一家之言，歡迎拍磚 ： ）
我之所以寫下這篇這么完整的文章是因為，很多開發者一參與到數據庫設計，就會很自然地把 “三范式” 當作銀彈一樣來使用。他們往往認為遵循這個規范就是數據庫設計的唯一標準。由于這種心態，他們往往盡管一路碰壁也會堅持把項目做下去。
大家都說標準規范是重要的指導方針并且也這么做著，但是把它當作石頭上的一塊標記來記著（死記硬背）還是會帶來麻煩的。以下 11 點是我在數據庫設計時最優先考慮的規則。
◆ 規則1：弄清楚將要開發的應用程序是什么性質的（OLTP 還是 OPAP）？
當你要開始設計一個數據庫的時候，你應該首先要分析出你為之設計的應用程序是什么類型的，它是 “事務處理型”（Transactional） 的還是 “分析型” （Analytical）的？你會發現許多開發人員采用標準化做法去設計數據庫，而不考慮目標程序是什么類型的，這樣做出來的程序很快就會陷入性能、客戶 定制化的問題當中。正如前面所說的，這里有兩種應用程序類型， “基于事務處理” 和 “基于分析”，下面讓我們來了解一下這兩種類型究竟說的是什么意思。
事務處理型：這種類型的應用程序，你的最終用戶更關注數據的增查改刪（CRUD，Creating/Reading/Updating/Deleting）。這種類型更加官方的叫法是 “OLTP” 。
分析型：這種類型的應用程序，你的最終用戶更關注數據分析、報表、趨勢預測等等功能。這一類的數據庫的 “插入” 和 “更新” 操作相對來說是比較少的。它們主要的目的是更加快速地查詢、分析數據。這種類型更加官方的叫法是 “OLAP” 。
那么換句話說，如果你認為插入、更新、刪除數據這些操作在你的程序中更為突出的話，那就設計一個規范化的表否則的話就去創建一個扁平的、不規范化的數據庫結構。
以下這個簡單的圖表顯示了像左邊 Names 和 Address 這樣的簡單規范化的表，怎么通過應用不規范化結構來創建一個扁平的表結構。
◆ 規則2：將你的數據按照邏輯意義分成不同的塊，讓事情做起來更簡單
這個規則其實就是 “三范式” 中的第一范式。違反這條規則的一個標志就是，你的查詢使用了很多字符串解析函數
例如 substring、charindex 等等。若真如此，那就需要應用這條規則了。
比如你看到的下面圖片上有一個有學生名字的表，如果你想要查詢學生名字中包含“Koirala”，但不包含“Harisingh”的記錄，你可以想象一下你將會得到什么樣的結果。
所以更好的做法是將這個字段拆分為更深層次的邏輯分塊，以便我們的表數據寫起來更干凈，以及優化查詢。
◆ 規則3：不要過度使用 “規則 2” 開發者都是一群很可愛的生物。如果你告訴他們這是一條解決問題的正路，他們就會一直這么做下去，做到過了頭導致了一些不必要的后果。這也可以應 用于我們剛剛在前面提到的規則2。當你考慮字段分解時，先暫停一下，并且問問你自己是否真的需要這么做。正如所說的，分解應該是要符合邏輯的。
例如，你可以看到電話號碼這個字段，你很少會把電話號碼的 ISD 代碼單獨分開來操作（除非你的應用程序要求這么做）。所以一個很明智的決定就是讓它保持原樣，否則這會帶來更多的問題。
◆ 規則4：把重復、不統一的數據當成你最大的敵人來對待
集中那些重復的數據然后重構它們。我個人更加擔心的是這些重復數據帶來的混亂而不是它們占用了多少磁盤空間。
例如下面這個圖表，你可以看到 “5th Standard” 和 “Fifth standard” 是一樣的意思，它們是重復數據。現在你可能會說是由于那些錄入者錄入了這些重復的數據或者是差勁的驗證程序沒有攔住，讓這些重復的數據進入到了你的系統。 現在，如果你想導出一份將原本在用戶眼里十分困惑的數據顯示為不同實體數據的報告，該怎么做呢？
解決方法之一是將這些數據完整地移到另外一個主表，然后通過外鍵引用過來。在下面這個圖表中你可以看到我們是如何創建一個名為 “Standards”（課程級別） 的主表，然后同樣地使用簡單的外鍵連接過去。
◆ 規則5：當心被分隔符分割的數據，它們違反了“字段不可再分”
前面的規則 2 即“第一范式”說的是避免 “重復組” 。下面這個圖表作為其中的一個例子解釋了 “重復組”是什么樣子的。如果你仔細的觀察 syllabus（課程） 這個字段，會發現在這一個字段里實在是填充了太多的數據了。像這些字段就被稱為 “重復組” 了。如果我們又得必須使用這些數據，那么這些查詢將會十分復雜并且我也懷疑這些查詢會有性能問題。
這些被塞滿了分隔符的數據列需要特別注意，并且一個較好的辦法是將這些字段移到另外一個表中，使用外鍵連接過去，同樣地以便于更好的管理。
那么，讓我們現在就應用規則2（第一范式） “避免重復組” 吧。你可以看到上面這個圖表，我創建了一個單獨的 syllabus（課程） 表，然后使用 “多對多” 關系將它與 subject（科目） 表關聯起來。
通過這個方法，主表（student 表）的 syllabus（課程） 字段就不再有重復數據和分隔符了。
◆ 規則6：當心那些僅僅部分依賴主鍵的列
留心注意那些僅僅部分依賴主鍵的列。例如上面這個圖表，我們可以看到這個表的主鍵是 Roll No.+Standard。現在請仔細觀察 syllabus 字段，可以看到 syllabus（課程） 字段僅僅關聯（依賴） Standard（課程級別） 字段而不是直接地關聯（依賴）某個學生（Roll No. 字段）。
Syllabus（課程） 字段關聯的是學生正在學習的哪個課程級別（Standard 字段）而不是直接關聯到學生本身。那如果明天我們要更新教學大綱（課程）的話還要痛苦地為每個同學也修改一下，這明顯是不符合邏輯的（不正常的做法）。更 有意義的做法是將這些字段從這個表移到另外一個表，然后將它們與 Standard（課程級別）表關聯起來。
你可以看到我們是如何移動 syllabus（課程）字段并且同樣地附上 Standard 表。
這條規則只不過是 “三范式” 里的 “第二范式”：“所有字段都必須完整地依賴主鍵而不是部分依賴”。
◆ 規則7：仔細地選擇派生列
如果你正在開發一個 OLTP 型的應用程序，那強制不去使用派生字段會是一個很好的思路，除非有迫切的性能要求，比如經常需要求和、計算的 OLAP 程序，為了性能，這些派生字段就有必要存在了。
通過上面的這個圖表，你可以看到 Average 字段是如何依賴 Marks 和 Subjects 字段的。這也是冗余的一種形式。因此對于這樣的由其他字段得到的字段，需要思考一下它們是否真的有必要存在。
這個規則也被稱為 “三范式” 里的第三條：“不應該有依賴于非主鍵的列”。我的個人看法是不要盲目地運用這條規則，應該要看實際情況，冗余數據并不總是壞的。如果冗余數據是計算出來的，看看實際情況再來決定是否應用這第三范式。
◆ 規則8：如果性能是關鍵，不要固執地去避免冗余
不要把 “避免冗余” 當作是一條絕對的規則去遵循。如果對性能有迫切的需求，考慮一下打破常規。常規情況下你需要做多個表的連接操作，而在非常規的情況下這樣的多表連接是會大大地降低性能的。
◆ 規則9：多維數據是各種不同數據的聚合
OLAP 項目主要是解決多維數據問題。比如你可以看看下面這個圖表，你會想拿到每個國家、每個顧客、每段時期的銷售額情況。簡單的說你正在看的銷售額數據包含了三個維度的交叉。
為這種情況做一個實際的設計是一個更好的辦法。簡單的說，你可以創建一個簡單的主要銷售表，它包含了銷售額字段，通過外鍵將其他所有不同維度的表連接起來。
◆ 規則10：將那些具有“名值表”特點的表統一起來設計
很多次我都遇到過這種 “名值表” 。 “名值表” 意味著它有一些鍵，這些鍵被其他數據關聯著。比如下面這個圖表，你可以看到我們有 Currency（貨幣型）和 Country（國家）這兩張表。如果你仔細觀察你會發現實際上這些表都只有鍵和值。
對于這種表，創建一個主要的表，通過一個 Type（類型）字段來區分不同的數據將會更有意義。
◆ 規則11：無限分級結構的數據，引用自己的主鍵作為外鍵
我們會經常碰到一些無限父子分級結構的數據（樹形結構？）。例如考慮一個多級銷售方案的情況，一個銷售人員之下可以 有多個銷售人員。注意到都是 “銷售人員” 。也就是說數據本身都是一種。但是層級不同。這時候我們可以引用自己的主鍵作為外鍵來表達這種層級關系，從而達成目的。
這篇文章的用意不是叫大家不要遵循范式，而是叫大家不要盲目地遵循范式。根據你的項目性質和需要處理的數據類型來做出正確的選擇。
需求分析的20條法則
對商業用戶來說，他們后面是成百上千個供應商，前面是成千上萬個消費顧客。怎樣利用軟件管理錯綜復雜的供應商和消費顧客，如何做好精細到一個小小調料包的進、銷、調、存的商品流通工作，這些都是商業企業需要信息管理系統的理由。軟件開發的意義也就在于此。而弄清商業用戶如此復雜需求的真面目，正是軟件開發成功的關鍵所在。
經理：“我們要建立一套完整的商業管理軟件系統，包括商品的進、銷、調、存管理，是總部-門店的連鎖經營模式。通過通信手段門店自動訂貨，供應商自動結算，賣場通過掃條碼實現銷售，管理人員能夠隨時查詢門店商品銷售和庫存情況。另外，我們也得為政府部門提供關于商品營運的報告。”
分析員：“我已經明白這個項目的大體結構框架，這非常重要，但在制定計劃之前，我們必須收集一些需求。”
經理覺得奇怪：“我不是剛告訴你我的需求了嗎？”
分析員：“實際上，您只說明了整個項目的概念和目標。這些高層次的業務需求不足以提供開發的內容和時間。我需要與實際將要使用系統的業務人員進行討論，然后才能真正明白達到業務目標所需功能和用戶要求，了解清楚后，才可以發現哪些是現有組件即可實現的，哪些是需要開發的，這樣可節省很多時間。”
經理：“業務人員都在招商。他們非常忙，沒有時間與你們詳細討論各種細節。你能不能說明一下你們現有的系統？”
分析員盡量解釋從用戶處收集需求的合理性：“如果我們只是憑空猜想用戶的要求，結果不會令人滿意。我們只是軟件開發人員，而不是采購專家、營運專家或是財務專家，我們并不真正明白您這個企業內部運營需要做些什么。我曾經嘗試過，未真正明白這些問題就開始編碼，結果沒有人對產品滿意。”
經理堅持道：“行了，行了，我們沒有那么多的時間。讓我來告訴您我們的需求。實際上我也很忙。請馬上開始開發，并隨時將你們的進展情況告訴我。”
風險躲在需求的迷霧之后
以上我們看到的是某客戶項目經理與系統開發小組的分析人員討論業務需求。在項目開發中，所有的項目風險承擔者都對需求分析階段備感興趣。這里所指的風 險承擔者包括客戶方面的項目負責人和用戶，開發方面的需求分析人員和項目管理者。這部分工作做得到位，能開發出很優秀的軟件產品，同時也會令客戶滿意。若 處理不好，則會導致誤解、挫折、障礙以及潛在的質量和業務價值上的威脅。因此可見——需求分析奠定了軟件工程和項目管理的基礎。
撥開需求分析的迷霧
像這樣的對話經常出現在軟件開發的過程中。客戶項目經理的需求對分析人員來講，像“霧里看花”般模糊并令開發者感到困惑。那么，我們就撥開霧影，分析一下需求的具體內容：
·業務需求——反映了組織機構或客戶對系統、產品高層次的目標要求，通常在項目定義與范圍文檔中予以說明。
·用戶需求——描述了用戶使用產品必須要完成的任務，這在使用實例或方案腳本中予以說明。
·功能需求——定義了開發人員必須實現的軟件功能，使用戶利用系統能夠完成他們的任務，從而滿足了業務需求。
·非功能性的需求——描述了系統展現給用戶的行為和執行的操作等，它包括產品必須遵從的標準、規范和約束，操作界面的具體細節和構造上的限制。
·需求分析報告——報告所說明的功能需求充分描述了軟件系統所應具有的外部行為。“需求分析報告”在開發、測試、質量保證、項目管理以及相關項目功能中起著重要作用。
前面提到的客戶項目經理通常闡明產品的高層次概念和主要業務內容，為后繼工作建立了一個指導性的框架。其他任何說明都應遵循“業務需求”的規定，然而“業務需求”并不能為開發人員提供開發所需的許多細節說明。
下一層次需求——用戶需求，必須從使用產品的用戶處收集。因此，這些用戶構成了另一種軟件客戶，他們清楚要使用該產品完成什么任務和一些非功能性的特性需求。例如：程序的易用性、健壯性和可靠性，而這些特性將會使用戶很好地接受具有該特點的軟件產品。
經理層有時試圖代替實際用戶說話，但通常他們無法準確說明“用戶需求”。用戶需求來自產品的真正使用者，必須讓實際用戶參與到收集需求的過程中。如果不這樣做，產品很可能會因缺乏足夠的信息而遺留不少隱患。
在實際需求分析過程中，以上兩種客戶可能都覺得沒有時間與需求分析人員討論，有時客戶還希望分析人員無須討論和編寫需求說明就能說出用戶的需求。除非 遇到的需求極為簡單；否則不能這樣做。如果您的組織希望軟件成功，那么必須要花上數天時間來消除需求中模糊不清的地方和一些使開發者感到困惑的方面。
優秀的軟件產品建立在優秀的需求基礎之上，而優秀的需求源于客戶與開發人員之間有效的交流和合作。只有雙方參與者都明白自己需要什么、成功的合作需要什么時，才能建立起一種良好的合作關系。
由于項目的壓力與日俱增，所有項目風險承擔者有著一個共同目標，那就是大家都想開發出一個既能實現商業價值又能滿足用戶要求，還能使開發者感到滿足的優秀軟件產品。
客戶的需求觀
客戶與開發人員交流需要好的方法。下面建議20條法則，客戶和開發人員可以通過評審以下內容并達成共識。如果遇到分歧，將通過協商達成對各自義務的相互理解，以便減少以后的磨擦（如一方要求而另一方不愿意或不能夠滿足要求）。
1、 分析人員要使用符合客戶語言習慣的表達
需求討論集中于業務需求和任務，因此要使用術語。客戶應將有關術語（例如：采價、印花商品等采購術語）教給分析人員，而客戶不一定要懂得計算機行業的術語。
2、分析人員要了解客戶的業務及目標
只有分析人員更好地了解客戶的業務，才能使產品更好地滿足需要。這將有助于開發人員設計出真正滿足客戶需要并達到期望的優秀軟件。為幫助開發和分析人員，客戶可以考慮邀請他們觀察自己的工作流程。如果是切換新系統，那么開發和分析人員應使用一下目前的舊系統，有利于他們明白目前系統是怎樣工作的，其流程情況以及可供改進之處。s
3、 分析人員必須編寫軟件需求報告
分析人員應將從客戶那里獲得的所有信息進行整理，以區分業務需求及規范、功能需求、質量目標、解決方法和其他信息。通過這些分析，客戶就能得到一份“需求分析報告”，此份報告使開發人員和客戶之間針對要開發的產品內容達成協議。報告應以一種客戶認為易于翻閱和理解的方式組織編寫。客戶要評審此報告，以確保報告內容準確完整地表達其需求。一份高質量的“需求分析報告”有助于開發人員開發出真正需要的產品。
4、 要求得到需求工作結果的解釋說明
分析人員可能采用了多種圖表作為文字性“需求分析報告”的補充說明，因為工作圖表能很清晰地描述出系統行為的某些方面，所以報告中各種圖表有著極高的 價值；雖然它們不太難于理解，但是客戶可能對此并不熟悉，因此客戶可以要求分析人員解釋說明每個圖表的作用、符號的意義和需求開發工作的結果，以及怎樣檢查圖表有無錯誤及不一致等。
5、 開發人員要尊重客戶的意見
如果用戶與開發人員之間不能相互理解，那關于需求的討論將會有障礙。共同合作能使大家“兼聽則明”。參與需求開發過程的客戶有權要求開發人員尊重他們并珍惜他們為項目成功所付出的時間，同樣，客戶也應對開發人員為項目成功這一共同目標所做出的努力表示尊重。
6、 開發人員要對需求及產品實施提出建議和解決方案
通常客戶所說的“需求”已經是一種實際可行的實施方案，分析人員應盡力從這些解決方法中了解真正的業務需求，同時還應找出已有系統與當前業務不符之處，以確保產品不會無效或低效；在徹底弄清業務領域內的事情后，分析人員就能提出相當好的改進方法，有經驗且有創造力的分析人員還能提出增加一些用戶沒有發現的很有價值的系統特性。
7、 描述產品使用特性
客戶可以要求分析人員在實現功能需求的同時還注意軟件的易用性，因為這些易用特性或質量屬性能使客戶更準確、高效地完成任務。例如：客戶有時要求產品 要“界面友好”或“健壯”或“高效率”，但對于開發人員來講，太主觀了并無實用價值。正確的做法是，分析人員通過詢問和調查了解客戶所要的“友好、健壯、 高效所包含的具體特性，具體分析哪些特性對哪些特性有負面影響，在性能代價和所提出解決方案的預期利益之間做出權衡，以確保做出合理的取舍。
8、 允許重用已有的軟件組件
需求通常有一定靈活性，分析人員可能發現已有的某個軟件組件與客戶描述的需求很相符，在這種情況下，分析人員應提供一些修改需求的選擇以便開發人員能 夠降低新系統的開發成本和節省時間，而不必嚴格按原有的需求說明開發。所以說，如果想在產品中使用一些已有的商業常用組件，而它們并不完全適合您所需的特 性，這時一定程度上的需求靈活性就顯得極為重要了。
9、 要求對變更的代價提供真實可靠的評估
有時，人們面臨更好、也更昂貴的方案時，會做出不同的選擇。而這時，對需求變更的影響進行評估從而對業務決策提供幫助，是十分必要的。所以，客戶有權 利要求開發人員通過分析給出一個真實可信的評估，包括影響、成本和得失等。開發人員不能由于不想實施變更而隨意夸大評估成本。
10、 獲得滿足客戶功能和質量要求的系統
每個人都希望項目成功，但這不僅要求客戶要清晰地告知開發人員關于系統“做什么”所需的所有信息，而且還要求開發人員能通過交流了解清楚取舍與限制，一定要明確說明您的假設和潛在的期望，否則，開發人員開發出的產品很可能無法讓您滿意。
11、 給分析人員講解您的業務
分析人員要依靠客戶講解業務概念及術語，但客戶不能指望分析人員會成為該領域的專家，而只能讓他們明白您的問題和目標；不要期望分析人員能把握客戶業務的細微潛在之處，他們可能不知道那些對于客戶來說理所當然的“常識”。
12、 抽出時間清楚地說明并完善需求
客戶很忙，但無論如何客戶有必要抽出時間參與“頭腦高峰會議”的討論，接受采訪或其他獲取需求的活動。有些分析人員可能先明白了您的觀點，而過后發現 還需要您的講解，這時請耐心對待一些需求和需求的精化工作過程中的反復，因為它是人們交流中很自然的現象，何況這對軟件產品的成功極為重要。
13、 準確而詳細地說明需求
編寫一份清晰、準確的需求文檔是很困難的。由于處理細節問題不但煩人而且耗時，因此很容易留下模糊不清的需求。但是在開發過程中，必須解決這種模糊性和不準確性，而客戶恰恰是為解決這些問題作出決定的最佳人選，否則，就只好靠開發人員去正確猜測了。
在需求分析中暫時加上“待定”標志是個方法。用該標志可指明哪些是需要進一步討論、分析或增加信息的地方，有時也可能因為某個特殊需求難以解決或沒有 人愿意處理它而標注上“待定”。客戶要盡量將每項需求的內容都闡述清楚，以便分析人員能準確地將它們寫進“軟件需求報告”中去。如果客戶一時不能準確表 達，通常就要求用原型技術，通過原型開發，客戶可以同開發人員一起反復修改，不斷完善需求定義。
14、 及時作出決定
分析人員會要求客戶作出一些選擇和決定，這些決定包括來自多個用戶提出的處理方法或在質量特性沖突和信息準確度中選擇折衷方案等。有權作出決定的客戶 必須積極地對待這一切，盡快做處理，做決定，因為開發人員通常只有等客戶做出決定才能行動，而這種等待會延誤項目的進展。
15、 尊重開發人員的需求可行性及成本評估
所有的軟件功能都有其成本。客戶所希望的某些產品特性可能在技術上行不通，或者實現它要付出極高的代價，而某些需求試圖達到在操作環境中不可能達到的性能，或試圖得到一些根本得不到的數據。開發人員會對此作出負面的評價，客戶應該尊重他們的意見。
16、 劃分需求的優先級
絕大多數項目沒有足夠的時間或資源實現功能性的每個細節。決定哪些特性是必要的，哪些是重要的，是需求開發的主要部分，這只能由客戶負責設定需求優先級，因為開發者不可能按照客戶的觀點決定需求優先級；開發人員將為您確定優先級提供有關每個需求的花費和風險的信息。
在時間和資源限制下，關于所需特性能否完成或完成多少應尊重開發人員的意見。盡管沒有人愿意看到自己所希望的需求在項目中未被實現，但畢竟是要面對現實，業務決策有時不得不依據優先級來縮小項目范圍或延長工期，或增加資源，或在質量上尋找折衷。
17、 評審需求文檔和原型
客戶評審需求文檔，是給分析人員帶來反饋信息的一個機會。如果客戶認為編寫的“需求分析報告”不夠準確，就有必要盡早告知分析人員并為改進提供建議。
更好的辦法是先為產品開發一個原型。這樣客戶就能提供更有價值的反饋信息給開發人員，使他們更好地理解您的需求；原型并非是一個實際應用產品，但開發人員能將其轉化、擴充成功能齊全的系統。
18、 需求變更要立即聯系
不斷的需求變更，會給在預定計劃內完成的質量產品帶來嚴重的不利影響。變更是不可避免的，但在開發周期中，變更越在晚期出現，其影響越大；變更不僅會 導致代價極高的返工，而且工期將被延誤，特別是在大體結構已完成后又需要增加新特性時。所以，一旦客戶發現需要變更需求時，請立即通知分析人員。
19、 遵照開發小組處理需求變更的過程
為將變更帶來的負面影響減少到最低限度，所有參與者必須遵照項目變更控制過程。這要求不放棄所有提出的變更，對每項要求的變更進行分析、綜合考慮，最后做出合適的決策，以確定應將哪些變更引入項目中。
20、 尊重開發人員采用的需求分析過程
軟件開發中最具挑戰性的莫過于收集需求并確定其正確性，分析人員采用的方法有其合理性。也許客戶認為收集需求的過程不太劃算，但請相信花在需求開發上 的時間是非常有價值的；如果您理解并支持分析人員為收集、編寫需求文檔和確保其質量所采用的技術，那么整個過程將會更為順利。
“需求確認”意味著什么
在“需求分析報告”上簽字確認，通常被認為是客戶同意需求分析的標志行為，然而實際操作中，客戶往往把“簽字”看作是毫無意義的事情。“他們要我在需求文檔的最后一行下面簽名，于是我就簽了，否則這些開發人員不開始編碼。”
這種態度將帶來麻煩，譬如客戶想更改需求或對產品不滿時就會說：“不錯，我是在需求分析報告上簽了字，但我并沒有時間去讀完所有的內容，我是相信你們的，是你們非讓我簽字的。”
同樣問題也會發生在僅把“簽字確認”看作是完成任務的分析人員身上，一旦有需求變更出現，他便指著“需求分析報告”說：“您已經在需求上簽字了，所以這些就是我們所開發的，如果您想要別的什么，您應早些告訴我們。”
這兩種態度都是不對的。因為不可能在項目的早期就了解所有的需求，而且毫無疑問地需求將會出現變更，在“需求分析報告”上簽字確認是終止需求分析過程的正確方法，所以我們必須明白簽字意味著什么。
對“需求分析報告”的簽名是建立在一個需求協議的基線上，因此我們對簽名應該這樣理解：“我同意這份需求文檔表述了我們對項目軟件需求的了解，進一步 的變更可在此基線上通過項目定義的變更過程來進行。我知道變更可能會使我們重新協商成本、資源和項目階段任務等事宜。”對需求分析達成一定的共識會使雙方 易于忍受將來的摩擦，這些摩擦來源于項目的改進和需求的誤差或市場和業務的新要求等。
需求確認將迷霧撥散，顯現需求的真面目，給初步的需求開發工作畫上了雙方都明確的句號，并有助于形成一個持續良好的客戶與開發人員的關系，為項目的成功奠定了堅實的基礎。
國內為數不少軟件企業雖然經過多年的發展，但仍處于疲于奔命、停滯不前的局面；另一方面，規模像“作坊”一樣的小公司，幾乎每天都在誕生、消亡。導致公司興衰成敗的原因是多方面的，筆者以為其中一個最重要的原因是軟件產品質量的好壞。（當然，市場策略也是其中一個極為重要的因素。）幾乎所有的企業都想對自己已有的技術成果或項目成果進行產品化，然后再把產品市場化、國際化。可是，絕大多數企業的軟件產品一旦走向市場就會遭遇重重困難，例如，軟件質量不過關，軟件可維護性差，軟件使用學習周期過長等等問題。本文不打算深入剖析決定軟件企業及其產品成敗的各個因素，而是側重于測試角度，以案例的形式，對軟件企業中影響產品質量提升的常見錯誤認識作一些分析并給出解決方案。
軟件公司在產品開發中，通常存在三大不合理現象，它們嚴重影響了產品質量的提升：
1）為了保證產品的工期和進度，文檔、質量管理、測試、評審等一系列工作統統可以忽略；
2）為了早日推出產品，不進行正規的缺陷管理，導致缺陷反復出現，缺陷較多的問題不能從“源頭”進行控制；
3）發生質量問題不好好反思自己產品開發管理方面的不足，進而從最根本處入手解決問題；而是掩蓋真實原因，追查個人責任。
本文將針對這三大現象，以真實的案例為藍本，逐個進行剖析。
1、進度 VS 質量
本案例是非常典型的產品開發案例，幾乎是很多中小公司的典型做法——以按時發布產品和進度為理由，不實施任何測試工作，就更不用說質量保證工作了。
下面是案例的一些基本信息：
產品信息
內容
產品名稱
系統為J2EE結構的某行業的ERP系統。本產品是一個來源于項目的產品，原有客戶和新的客戶已經投入使用部分功能。
開發人員
產品開發人員10人。
功能模塊
含有工作流流程的模塊有30個，不含工作流流程的普通功能模塊20個左右。
進度要求
當時計劃一年內開發完成，實際目前已經耽誤進度0.5年。
產品現狀
主要功能基本完成，而且在一些新的客戶中投入使用，反饋問題較多。
下面是產品開發的過程：
階段
過程
大事記
項目立項階段
三家大客戶準備采用該產品，公司把三個項目在內部作為一個項目來開發，同時制定要把該項目成果產品化的目標。
為了趕進度，采取封閉開發的方法，同時決定第一版不進行測試。
第1個月
項目在沒有文檔的情況下進入開發狀態，主要參考依據是公司內部基于另外一個平臺的同類產品，該平臺有些過時是開發這個產品的主要原因。
產品整個開發過程基本沒有進行關鍵方案、文檔的評審工作；沒有進行任何測試；沒有任何質量保證人員。
第2～5個月
產品正常開發，大多數功能由程序員做主進行開發。同時，開發完成的部分準備安裝試用。
第6～12個月
開發團隊進一步開發產品；
實施人員在現場安裝已經完成的部分，同時做缺陷修改工作；
第六個月時，客戶開始對公司施壓，要求盡快安裝全部產品，同時拒絕使用已經安裝好的部分產品；
幾個實施工程師以超人的“救火”能力，解決了現有缺陷，在幾乎沒有提供新產品的條件下撐過了半年。
第13個月
把主要功能提供給客戶進行安裝；
前面的幾位實施工程師在季度會議上，被公司評為了“英雄”，給予了一定的獎勵，鼓勵他們繼續堅守陣地。
第14～18個月
公司決定把產品交給現場的實施人員進行維護，專注產品化工作；
確定在接下來的6個月推出新版本的目標；
由于缺陷較多，現場用戶抱怨不斷；
實施人員忙于現場“救火”。
第19個月
所有的開發人員不再兼顧項目，加班加點準備按時發布產品。
……
……
……
現實中很多公司目前都是這樣進行軟件開發的，幾乎很少進行測試工作，最多也就是在產品發布后進行最后的“用戶測試”和一些功能性測試。當軟件系統在用戶那里出故障了，現場補救成功的人成了公司的英雄，好心的用戶甚至還會因此寄來感謝信。然而這并不是真正合理的做法。如同案例中描述的那樣，這會導致現場用戶抱怨不斷，分配用于“救火”的工程師越來越多，最后導致企業不堪重負，不得不放棄部分現有客戶的系統維護工作。要想改變這種現狀，應該從以下幾個方面入手：
不但要主觀認識到測試對軟件質量的重要性，同時還要落實到行動中。
測試的重要性已經逐漸被軟件開發團隊認可。但是落實到實際工作中，通過測試真正提高軟件質量，還有一段很長時間的路要走。因為幾乎所有的軟件公司都灌輸著“進度高于一切”的思想，只要是為了趕進度和發布產品，所有影響進度的工作都可以忽略。
從表面上看，測試、質量檢查、評審是在耽誤進度，實際上則不然。如果軟件缺陷被遺落并流落到客戶那里，其結果就是代價高昂的電話費或者現場支持費 用，還可能需要修復、重新測試和發布新的產品，更糟糕的情況是產品要被召回甚至被客戶起訴。這種成本付出非常高，幾乎是在內部修改缺陷時的幾何級數倍，一 般高達100～1000倍（可以參考PhilipCrosb的相關著作）。
案例中的情況，實際上就是為了趕進度而不進行測試，如果第一版進行規范的測試，后面那些“救火”英雄肯定會少些，同時也會得到客戶對公司更大的認可。很多公司盡管對這個道理已經耳熟能詳，但接下來如何進一步落實到行動中卻是不容樂觀的問題。
樹立提高質量就是尊重客戶的思想。
作者注意到目前不少公司存在著“愚弄客戶”的嫌疑。不管是有心的還是無意的，很多公司認為只要能拿到“錢”就已經達到目的了，因此也不在乎是否 掩蓋缺陷和敷衍客戶。案例中的做法肯定是不尊重客戶的，因為沒有產品可以安裝時，不說明實情，反而提供一個“滿目瘡痍”的產品來臨時應付客戶，甚至最后安 排實施人員“硬撐”半年。
生活中大家都討厭假冒偽劣產品，但是軟件行業從業者的卻很少意識到質量不好的軟件也是假冒偽劣產品。對客戶負責，就是對公司負責。“樹立客戶是 上帝”的思想，一定要把重視質量落實到行動中，這樣我們就不至于拼命的去生產那些“假冒偽劣”軟件，最后被市場淘汰。在軟件產業發達的今天，已經是客戶的 買方市場，客戶永遠會選擇質量好的、服務好的產品來滿足自己的需求，只有質量好的產品，才可以不斷的向前發展。
建立規范的測試體系和質量保證體系，逐步使軟件開發進入良性循環狀態。
在沒有開發規范的前提下，軟件團隊是很少能開發出高質量的軟件。因此軟件團隊一定要建立規范的測試體系和質量保證體系，同時把規范體系逐步落實 到工作中。案例中的公司就是沒有“開發法律”的小軟件作坊，所以才倒行逆施。不但做了很多浪費人力、物力的無謂工作，還給客戶留下了不好的印象，造成了不 良后果。類似案例中這樣的開發團隊在現實中很多，都是處于混亂的開發狀態。解決的根本辦法就是逐步規范測試體系，進而建立全面管理的質量管理系統，最終形 成一個良好的開發體系。在好的開發體系下，片面重視進度的情況是不容易發生的。
2、缺陷反復出現，誰的責任？
下面的案例取材自某公司產品開發部開發某網絡教育平臺軟件的工程過程。本產品在歷時一年半的研發后開始投入測試。測試工作允許的時間為7個工作日。
測試工作過程記錄如下
| 進度 | 測試人員 | 開發人員 | 其他問題 |
| 第一天 | （1）熟悉軟件 （2）閱讀項目文檔 （3）制定測試策略（2人） （4）制作測試跟蹤表格（1人） | 其它工作 | 無 |
| 第二天 | （1）確定測試策略 （2）劃分測試任務 （3）閱讀各自測試模塊的文檔 | 下午做整個系統的業務功能串講（部分開發人員）。 |
| 第三天 | 開始執行測試 | 其它工作 | 缺陷總數70多 |
| 第四天 | 執行測試 | 其它工作 | 缺陷總數200多 |
| 第五天 | 執行測試 | 其它工作 | 缺陷總數500多 |
| 第六天 | （1）執行測試 （2）總結測試 （3）撰寫測試缺陷報告 | 其它工作 | 缺陷總數600多 |
| 第七天 | 撰寫測試分析報告 | 其它工作 | 無 |
經過7個工作日的測試，得出結果，此系統不可用，需做重大修改。系統經過重新設計，保留了部分原有業務功能和業務邏輯之后重新開發，并進行了測試。測試工作允許的時間為三個月。
測試工作過程記錄如下
| 階段 | 測試人員 | 開發人員 | 其他問題 |
| 單元測試 | 無 | build通過，操作均實現 | 無 |
| 集成測試 | 無 | 數據流轉執行正常 |
| 系統測試 | 隨著開發過程測試 | 無 | 缺陷總數500多 |
| | 全部開發完成集中測試 | 無 | 缺陷總數4000多 |
在最后的系統測試結束后，對測試結果進行了分析，發現如下現象：
第二版中的4000個多缺陷基本包含了第一版發現的600多個缺陷；
相似缺陷較多，例如：如果一個程序員寫的模塊中發現某個頁面郵件輸入格式沒有校驗，那么他寫的所有頁面中包含郵件數據項的內容都不會校驗；
數據校驗遺漏較多：如果在一個系統輸入了不合法的數據項，那么，整個系統中就會出現幾十個數據項合法校驗遺漏；
細節錯誤較多，例如：頁面Title不對應的錯誤在系統中有600多個；
程序設計風格不統一。相同的功能點，如分頁、翻頁處理，做得五花八門，并且以測試人員的理解來判斷是否為缺陷，導致某些功能點在不同頁面就能發現個3到5個缺陷。
通過上面的案例信息，可以看出這個產品的開發過程本身就是不規范的，而且測試工作介入的太晚，同時在軟件產品設計、過程管理、文檔評審等諸多方 面均存在問題。產品開發工作和項目開發工作相比，一般進度壓力較小。但是產品要進行商業化最終轉化為通用的商品軟件，質量方面的要求要比項目成果高很多。 缺陷反復出現幾乎是軟件產品開發的一個常見現象，要想解決這個問題，作者建議整個團隊要從下面幾個方面入手：
規范化產品開發流程：產品開發是應該遵循軟件工程規范的，開發過程不應該跳過必要的環節。例如這個案例中的產品，無疑就是開始系統設計和評審工作沒有做好，才導致二次開發，并且還有一個嚴重的遺漏就是首次開發忽略了測試工作。測試、質量保證等相關工作應該從立項開始就同步啟動。
需求分析要明確：如果開發人員都不知道完成的內容是否正確，而是由測試人員來判斷是否符合要求，那簡直是需求分析的的巨大“失誤”。用戶或者設計者想要達到什么目標一定要清晰的描述出來，模棱兩可的需求是沒有辦法設計測試用例的，更不用說進行測試了。
開發人員的調試一定要到位：開發人員一定要認真調試代碼，至少要把自己負責的部分和其它模塊的接口部分進行 詳細的測試。這項由開發人員進行的基礎測試是不可缺少的。目標就是把盡可能多的缺陷消滅在開發階段，這也無疑是最節約成本的。現代軟件系統十分復雜，程序 員寫了程序不仔細檢查代碼，大多會有很多缺陷存在。如果憑著僥幸心里把所有的測試工作都交給測試工程師來完成，那只能適得其反。這些本來在開發階段解決的 缺陷由測試人員來發現會有如下的后果：
耽誤進度——首先，缺陷要經過一定的測試流程。例如上面的案例中，網頁的Title寫錯這樣的缺陷折騰了兩個部門，簡直是“勞民傷財”。
轉移測試人員注意力——大量的低級缺陷使測試工程師無法進行更加深入的測試。測試工程師的注意力分散在對于開發工程師來說“無關痛癢”的缺陷上，使得更深層次的缺陷隱藏起來。
降低開發人員斗志——盡管這些缺陷是開發人員自己“制造”的，但是一看到上百、上千個缺陷，無疑會影響心情，降低效率。
當然，增大開發人員測試力度會帶來一定的投入，因此需要在項目初期進行合理的規劃，否則開發工程師就會拼命趕進度，自然把測試工作“寄厚望”于測試工程師。
加強缺陷管理：缺陷管理在這個案例的前期做的不好。在缺陷管理中，我們不但應該把缺陷修改工作能否一次通過 作為考核開發師的標準之一，更應該把一些常見的缺陷是否存在作為考核開發工程師的標準。在經過一定的積累后，開發團隊應該形成一些常見的程序缺陷列表，以 引起開發組成員注意。在此基礎上，還需要做到下面幾個要求來提高質量：
修改缺陷要徹底——徹底不單單是要修改好測試人員提交的缺陷，還要爭取不帶來新的缺陷、這就要求開發工程師修改缺陷時要對相關聯的部分進行檢查。
低級缺陷不存在——常見缺陷列表中的錯誤盡量不應該由測試工程師發現并提出。
3、產品發布后，缺陷誰來負責？
本案例發生在一個正在建設測試團隊的組織中，這個研發團隊有獨立的測試小組，但不是獨立的測試部門，產品部經理兼任測試經理。在產品提交給代理商后，代理商發現了一個嚴重的缺陷，并對其進行了投訴，最終的結果是公司領導層對開發隊伍的相關人員進行了一系列懲罰。
測試過程簡要記錄：
| 測試階段 | 測試人員 | 備注 |
| 單元測試 | 主要由開發人員負責。 | 開發人員一邊開發一邊測試。 |
| 集成測試 | 開發人員負責，測試人員沒有參與。 | 沒有作為一個獨立的測試階段進行，在開發過程中進行。 |
| 系統測試 | 由測試小組進行，共5名工程師，測試了進15個工作日。 | 測試過程采用了缺陷管理工具。 |
| 回歸測試 | 測試工程師和開發工程師進行交互的測試、修改。 | 開發工程師修改完最后的缺陷后，把所有的模塊打包，發送給客戶。 |
| 驗收測試 | 由軟件代理商的測試隊伍自己進行驗收測試。 | 根據用戶手冊進行測試。 |
在代理商驗收測試進行的第三天，測試人員發現了一個嚴重缺陷——“流轉后的文檔無法正常歸檔”。代理商立刻向公司的客戶服務部進行了投訴。在此之后的10多天里，代理商的測試人員又陸續發現了近30個缺陷。
公司對產品的質量十分“震怒”，詳細調查后，發現了這個問題產生的過程如下：
這個缺陷實際發現過一次，開發人員進行修改時，發現難度較大，決定暫停修改，得到了測試人員的認可；
接著大家忙于新的測試和修改工作；
產品發布前，開發工程師進行了修改，然后直接發布，在開發環境下問題確實得到了解決；
最后公司對相關人員進行了連帶懲罰：
產品部經理、項目經理、開發工程師本季度績效考核降為最低，即下個季度每個月份都要扣除一定比例的工資；
測試工程師績效考核降為最低，同樣扣除了工資。
上面案例的執行過程中，有幾處顯而易見的不合理的地方：
缺少文檔，尤其是需求文檔。文檔是測試的主要依據。如果交給測試組僅僅是一個軟件系統，然后告訴他“你們來測試吧，發現缺陷就提交”，我相信提交缺陷后開發與測試雙方幾乎會陷入喋喋不休的爭吵狀態。
測試介入太晚。只在系統測試階段才安排測試人員進行測試，實際上質量已經失控了。尤其是沒有文檔，測試人員 無疑會把一些“缺陷”認為是合理的，而開發人員通常會自信地人為自己的開發工作是正確的。這樣，一些問題是否是缺陷就會最終交給客戶來完成。質量控制和測 試的相關工作沒有按照合理的流程進行必然會產生這種結果。要改變這種現狀測試工作就應該盡早地介入整個產品的開發流程。
回歸測試做的不合理。案例中在回歸測試時，“開發工程師修改完最后的缺陷后，把所有的模塊打包，發送給客戶”，這里明顯還缺少一次測試。所有的缺陷應該經過修改驗證后才可以發布產品，最后階段發現的缺陷也不應例外。必須經過這道工序才可以發布產品，因為修改可能會帶來新的缺陷。
產品發布的出口不對。案例中的產品最后是由開發人員發布的，這是十分不合理的。這些產品來自于開發環境，眾 所周知，很多缺陷在開發環境下運行時是不出現的。產品在經過最后的回歸測試并且確定可以發布后，應該把經過測試的產品而不是來自于開發環境的產品納入配置 管理基線庫，最后發布的產品應該從配置管理庫中提取的。
缺陷流程不合理。這個帶來嚴重后果的缺陷其實就是從不規范的流程“空隙”中逃脫的，原因主要如下：
缺陷的用戶權限控制不嚴。開發工程師無權決定是否延期或者暫時停止修改某一缺陷。案例中開發工程師自己決定延期修改，測試工程師也進行了認可，這是不合理的做法。
沒有對每個缺陷進行全程跟蹤。測試工程師應該跟蹤每一條缺陷，并確定修改后才可以進行關閉操作，而不是發現缺陷就完成了任務。
缺少了缺陷審核步驟。產品發布前，項目經理應該對產品發現的缺陷進行審核，根據修改狀況來決定是否可以發 布。產品帶著缺陷發布也是正常的行為，例如微軟的大多數產品都是帶著缺陷發布的。重要的是對最后未關閉的缺陷進行合理的處理。這些缺陷要由項目經理甚至是 技術總監進行審核簽字后確定不進行修改后，才可以轉入產品發布。本案例中如果事先對缺陷做過審核并確認，就可以規避風險。
上面的諸多原因，必然導致了產品會遺漏很多缺陷。實際也是如此。開始發現的這個“嚴重缺陷”只是個開端，后面陸續發現的30多個缺陷才是上面這 些原因的“所以”。如果這30多個缺陷都要進行懲罰，公司可以收入一大筆。雖然公司根本目的是想把產品質量做好，并不希望處罰大家，可是找不出提高質量的 根本方法，只能出此下策以儆效尤。
產品發布后的責任究竟應該由誰來承擔？作者認為，應該根據具體的問題來決定。首先要意識到產品帶著一些缺陷是正常現象。如果純屬個人原因造成， 個人是應當承擔責任的，懲罰永遠不是最有效的辦法。實際上，本案例中的開發工程師在不到20天就提出了辭職并離開公司，給公司的產品開發帶來更大的損失。 提高質量必須從提高項目管理水平處入手，同時加強質量控制來避免類似問題發生。
4、小結
通過對上面三個案例進行分析，我們應該已經意識到質量、進度、成本是相輔相成、同等重要的，決不可以忽略任何一個方面。尤其是軟件質量，決不要 因為它是非硬性指標就敷衍了事。此外，軟件測試作為質量控制的最重要手段，必須引起足夠的重視。本文所討論的案例，都是直接從實踐中來的，且具有相當的代 表性。那么，為什么為數不少的軟件企業會陷入上述“怪圈”呢？歸根結底就是短期利益心理在作怪。希望企業能夠通過本文的案例剖析，意識到問題產生的原因的 所在，進而提高軟件質量管理水平，建立合理的質量管理體系。
自動化測試的優點在于快速、可靠、可重復、可重用、無疲勞，是對繁重的手工測試的一次解放，適用于回歸測試。自動化還有一個特點是無人值守，測試人員要做的是通過看
REPORT
ER來判斷系統是否存在缺陷。當然，腳本執行的過程中或多或少會出現ERROR，由于無人值守的特點，接下來的腳本就會不能運行，這也是為什么在自動化腳本中彈出框要用POP函數的原因。QTP提供的場景恢復可以解決這個問題，我將自己學習實踐的過程與大家分享，有不合適的地方請大家指正。
場景恢復可以看做一種嵌入式機制，是QTP腳本的一個可安裝可拆卸零部件，這個零部件的作用就是在機器出現的問題的時候根據我們的指示執行指定的命令， 記錄案發現場，等腳本跑完的時候遞出報告，供我們分析。我們來看看怎么制造這個零件，我分享一個出錯時調用函數截圖的場景恢復。我使用的版本是 QTP10.00
一、設置
1、新建Recovery Scenario
首先我們打開Resouces--Recovery Scenario Manager窗口。
點擊新建場景恢復圖標
，開始新建一個Recovery Scenario。
2、選擇觸發方式
場景恢復機制提供了四種類型的觸發事件，分別用來識別：彈出對話框、對象的特殊屬性值、運行錯誤、應用程序失敗。我這里選擇Test run error觸發方式。
Error選擇Any error，這樣出現任何錯誤都能觸發恢復場景。
3、設置恢復時操作，這里我們選擇調用函數。
點擊下一步，選擇編輯好的函數，我的恢復操作函數如下，函數的作用是將出錯頁面截屏打印到REPORTER。
Function RecoveryFunction1(Object, Method, Arguments, retVal)
Dim datestamp,filename,ResPath
ResPath = Environment("ResultDir")
datestamp = Now()
filename = Environment("TestName")&"_"&datestamp&".png"
filename = Replace(filename,"/","")
filename = Replace(filename,":","")
filename = ResPath + "\" + ""&filename
Desktop.CaptureBitmap filename,True
Reporter.ReportEvent micFail,"場景恢復","報錯截屏",filename
End Function
點擊下一步，將add another recovery operations選項取消。
4、設置腳本恢復運行時的操作，這里處理下一個Action或者組件中的下一個迭代。
到這里，這個調用函數的場景恢復設置就基本完成了，下一步是給場景恢復取名并保存。
可以選擇將新建的場景恢復添加到當前的TEST或者將其視為默認設置。
5、關聯場景恢復文件
在file>setting>recovery選項中，可以選擇添加或者刪除場景設置，就跟resources中國添加關聯函數是一個道理。
在test setting里可以看到我們新建的場景設置已經與當前TEST關聯。
二、運行
批量運行腳本實驗場景恢復的作用。
在前面的腳本執行出錯時不影響下一個腳本的執行，也即是場景恢復起到了作用，如果沒有這個設置，我們批量運行腳本時就會中斷在出錯的位置，沒有起到自動化應有的作用。我們來看一下運行的報告。
SKIP ITERATION，我們設置的恢復操作，執行下一個迭代。
這個是出錯的截屏，這里我將密碼設置錯誤觸發了場景恢復。
謝謝大家，有不正確的請指正。
我們知道，查詢優化器的基本的目標就是為我們的查詢語句找出一個比較高效的執行計劃。即使是一個非常簡單的查詢，也會存在很多的不同方式去訪問數 據，而這些不同的方式都是可以得到相同的結果的，所以，查詢優化器必須要很“明智的”從這些大量的執行計劃中找出了一個“最佳”的出來。
前一篇：淺析SQL Server查詢優化器的工作原理
為了得到最好的計劃，查詢優化器必須在某些條件的限制下，盡可能多的創建和評估大量的候選執行計劃。看到這里，就有一點需要注意了“查詢優化器是盡可能 多的創建候選執行計劃”，而不是為一個查詢產生所有的執行計劃。在SQL Server中，我們把一個查詢產生的候選執行計劃的集合稱之為“搜索空間（search space）”。很顯然，搜索空間中的所有的執行計劃都返回相同的結果。
給一張示意圖，讓大家更好理解一點，如下所示：
注：圖中的Search Space中的曲線代表執行計劃
從理論上說，為了找到最佳的執行計劃的查詢，基于成本的查詢優化器應該生成搜索空間中存在的所有可能的執行計劃，并正確估計每個計劃的成本。然而，一些 復雜的查詢可能有成千上萬，或者甚至數百萬可能的執行計劃，查詢優化器不可能去產生并評估一個查詢的每一個候選的執行計劃，如果那樣，評估所有計劃的時間 會非常的長，并且嚴重影響查詢的整體的執行時間。
查詢優化器必須優化的時間和執行計劃的質量之間取得平衡。 例如，如果查詢優化器花1秒鐘的時間找到了一個比較好的執行計劃，并且這個計劃的執行時間是1分鐘，那么這個時候，就沒有必要再去花費5分鐘的時間去為這 個查詢找更優的執行計劃。因此SQL Server不會做一個詳盡的全部查找，而是盡快找到一個合適的有效的計劃。由于查詢優化器是有時間限制的，那么就可能選擇的計劃可能是最優方案，也有可 能只是一些接近最優的方案。
候選的執行計劃是在查詢優化器的內部通過使用轉換規則，啟發式算法產生的。候選 的執行計劃在優化過程中一直保存在稱之為“Memo（中文翻譯可能為“備忘錄”，以后我們就直接使用英文名稱，很多的技術術語翻譯過來之后就變味了）”的 內存組件中。從這里我們就可以知道：如果為了復雜的查詢產生所有的候選執行計劃勢必會占用大量的內存。
我們這里只是簡單的介紹一下候選執行計劃的產生，后面我們會對每一個步驟進行詳細的分析。
執行計劃成本估算
查詢優化器需要為產生的候選的執行計劃進行成本的估算，從而選擇一個成本最低的。為了估算一個計劃的成本，查詢優化器會使用一些成本估算的公式來計算一 個計劃的成本，這些成本估算公式會考慮很多資源的使用，例如CPU，I/O，內存等。成本估算主要是取決于算法中采用的物理操和估算的將要處理的數據記錄 的量（估算數據記錄的量也被稱之為“基數估算”）。
為了便于進行基數估算，SQL Server會使用并且維護統計數據（statistics），統計數據描述了表中數據的值的分布情況，或者簡單的理解為“元數據-描述數據的數據”。一 旦采用基數估算得出了嗎，每個操作的成本和對資源的要求，那么查詢優化器就會將這個成本數值進行累計，從而得出整個就會的成本。我們這里不會討論過多與統 計數據相關的知識，在后面中會詳細的講述。
在下一篇文章中，我們會講述計劃的執行與緩存，以及與Hint相關的話題。
軟件測試是對開發人員已經發布出來的軟件進行驗證和測試，以保證軟件的質量。和其他工作一樣，也需要相應的工作人員實現已規劃好的測試計劃。
本文將從測試人才招聘、測試人才的應用、績效考核和職業規劃幾個方面對軟件測試中的人才培養進行描述。
1、測試人才招聘
招聘是為已經確定的工作崗位物色適合的人選的過程。在這個過程中，首先需要明確職位描述、技術知識能力要求、完成這份工作所需要具備的基本素質和其他具 體的特殊的要求。職位描述包括崗位職責和將來的工作任務。技術、知識和能力要求是必須掌握了相應的技術，知識和能力才能勝任該份工作的需求。基本素質是除 了技術、知識和能力必須具備的基本素質。下面將以初級測試人員為例，明確招聘需求：
項目 | 內容描述 | 備注 |
職位描述 | 根據已經設計完成的測試用例測試軟件 對根據用例測試發現的問題進行確認 對已確認問題，按照標準格式書寫并提交該bug 對已提交的bug進行跟蹤，并作驗證直到bug被修復 … | 公共基本技能 |
技術要求 | 編程語言 | 掌握C/C++語言… | 根據還同的公司背景需求 |
操作系統 | 精通Window’s / Linux / Mac … |
工具 | 熟悉CVS or VSS / Clear Quest / TD … |
知識要求 | 了解軟件工程 熟悉軟件測試分類 熟悉軟件測試的基本方法 … | |
能力要求 | 良好的邏輯思維能力 具有團隊合作能力 具有一定的創造性 … | |
基本素質 | 1．有良好的溝通習慣 2．良好的書寫習慣 3．對待工作認真細致，條理性較好 … | |
語 言 | 英語 6級 | 至少能看懂 |
其他要求 | | |
明確需求之后是具體的面試。面試是一個雙方初步觀察，判斷和選擇的過程。面試前可以根據職位的描述和要求，設計相應的問題和題目，從各個方面對應試人員進行觀察，判斷其是否符合相應的要求。
2、人才的使用
當選中相應的測試人員之后，則需要進行試用。試用是面試的延續，是對其能力進行進一步的驗證和觀察。
測試人員入職后，除了參加公司組織的入職培訓，也需要進行項目入職培訓。對于新員工的培訓，可以根據積累的經驗，建立新員工項目培訓體系，以幫助新員工 盡快了解當前的項目基本狀況。新員工培訓結束后，則測試人員應該已經掌握了當前項目的基本知識，可以嘗試安排其進行簡單的工作。隨著測試人員對項目的了解 程度增加，則應該逐步增加工作量和工作難度，直到其應該做的工作。
在試用期內需要對測試人員進行細致的觀察，以對其能力、做事風格和真實性格有進一步的了解。同時對進行一定的引導，觀察其是否能夠感知并向引導的方向努力。在整個過程中，及時和其進行溝通，以獲取其對培訓和工作中的反應。
轉正是雙方經過觀察，建立了信任，并愿意進行長期合作的標志。一方面是公司對測試人員試用期內的能力和表示認可，認為其可以勝任當前的工作，并愿意提供其展現才華的平臺。另一方面，是測試人員對公司的認可，也一起共同發展。
在日常工作中，一方面給各個員工能力相當的工作量，另一方面也需要對測試人員實際的工作結果進行考核。同時及時調動測試人員的積極性和團隊整體士氣，給團隊營造一種和諧，相互交流的平臺。
3、績效考評
績效考評對許多軟件公司來講是很頭痛的事，對于測試人員進行績效考核也存在同樣的問題，這里給大家一些建議：測試人員的績效考核和其他工作考評一樣，測試經理應該做到客觀、公正和公平。那么，如何針對測試人員建立考評？
簡單來講，基本上分為兩類，一類是可以量化的各種度量指標，如Bug的數量，Bug的類型，Bug的修復率，Case的覆蓋率等等， 但bug數量一般不建議管理人員來作為考核的主要依據，因為數量多并不代表質量高等一些因素。另一類是不可量化的軟指標，如工作積極性，工作的認真細致的 態度，合作態度等軟指標，如果通過細分分級，也可以做到量化。還有一類是客戶和開發人員的反饋，也作為績效考核的一部分。另外，多數公司還將公司的總體經 營狀況納入績效考核部分，加強員工的團隊意識與責任感。
每個公司的狀況和每個任務的難度和強度均不一樣，那么具體的考評，則需要根據實際的情況進行設計。
無論什么樣的績效考核，應遵守基本原則：激勵員工的工作積極性，提高團隊意識，獎罰分明。
4、職業規劃
當測試人員加入測試隊伍之后，一方面是員工當前的工作，另一方面需要幫助其進行職業規劃，以求得公司和個人能夠雙贏。
一個人是否能在工作崗位上做好，會有如下幾個因素其比較大的影響：
● 個人興趣愛好
● 技術能力
● 綜合素質（包括邏輯思維和良好的工作習慣）
● 而這幾個因素也會影響未來的職業發展。
一個人的職業規劃，不單對測試人員非常重要的作用，對整個測試Team的規劃發展也是非常重要的。
在日常工作中，需要和測試人員保持通暢的溝通，以聆聽他們的愿望和希望，并且在日常工作中對每個測試人員的技能、性格、做事習慣、為人處世方式等等方面的觀察，并結合其發展愿望，可以幫助測試人員分析、確定一個發展方向。
一般來講，軟件測試人員會有兩個發展方向 – 資深的技術專家 和 測試管理人員。當然也有做SQA和項目經理的。這里我們就這兩個發展方向給予討論。這兩類人員需要掌握不同的知識體系和相當有區別的性格特點，很難有人能 夠同時兼顧。一般來講，性格比較沉靜，邏輯思維嚴密，喜歡鉆研的人，發展為資深的技術專家比較合適，而相對比較外向，喜歡和各式各樣的人相處的人，而且對 管理有興趣的人，做管理科能比較合適，具體規劃需要根據實際情況進行引導。
5、定期培訓
根據測試的需求，結合各個測試人員的發展規劃之后，可與公司的培訓部門聯系，為每個測試人員建立培訓計劃。可作Team的整體性的知識/技術普 及培訓，也可結合實際的需求和個人發展規劃，進行小規模的培訓。最終的目的，就是提高個人的技術能力，同時也能提高團度的整體水平。
最后，軟件測試人員的培訓是一個系統的工程。應因人因地而宜，本文僅給出拋磚引玉的作用，大家不同建議或觀點可與我聯系。
單行函數和多行函數示意圖：
單行函數分為五種類型：字符函數、數值函數、日期函數、轉換函數、通用函數
單行函數：
--大小寫控制函數
select lower('Hello World') 轉小寫, upper('Hello World') 轉大寫 from dual;
--initcap: 首字母大寫
select initcap('hello world') 首字符大寫 from dual;
--字符控制函數
-- concat: 字符連接函數, 等同于 ||
select concat('Hello',' World') from dual;
--substr:求母串中的某個子串
select substr('Hello World',3) from dual;
select substr('Hello World',3,4) from dual;
--length和lengthb: 字符數和字節數
select length('China') 字符數, lengthb('China') 字節數 from dual;
--instr:在母串中，查找子串的位置
select instr('Hello World','ll') from dual;
--lpad,rpad: 左右填充,將abcd用*填充到10位
select lpad('abcd',10,'*') 左填充, rpad('abcd',10,'*') 右填充 from dual;
--trim: 去掉字符串前后指定的字符
select trim('H' from 'Hello WorldH') from dual;
--replace:字符串替換函數
select replace('Hello Wordl','l','*') from dual;
--數字函數
select round(45.926,2) 四舍五入, trunc(45.926,2) 截斷 ,mod(1600,300) 求于 from dual;
--ROUND函數
select round(45.923,0) 整數位, round(45.923,-1) 十位,round(45.923,-2) 百位 from dual;
--日期函數
--顯示當前日期
select sysdate from dual;
--顯示時間部分
select to_char(sysdate,'yyyy-mm-dd hh24:mi:ss') from dual;
--顯示昨天，今天和明天，加減數字仍未日期
select sysdate-1 昨天, sysdate 今天, sysdate+1 明天 from dual;
--兩個日期相減，結果為相差的天數，查詢員工信息，顯示員工工齡。兩個日期不能相加
select empno,ename, sysdate-hiredate 天 from emp;
--查詢員工信息，顯示員工工齡,分別按照天，星期，月顯示
select empno,ename,sysdate-hiredate 天,(sysdate-hiredate)/7 星期, (sysdate-hiredate)/30 月 from emp;
--months_between:兩個日期相差的月數
select (sysdate-hiredate)/30 方式一, months_between(sysdate,hiredate) 方式二 from emp;
--add_months:在指定日期上加上若干個月
select add_months(sysdate,1) 下個月, add_months(sysdate,123) "123個月后" from dual
--last_day: 某個日期當月的最后一天
select last_day(sysdate) from dual;
--next_day:下周六
select next_day(sysdate,'星期五') from dual;
--對日期進行四舍五入
select round(sysdate,'MONTH') 月,round(sysdate,'YEAR') from dual;
--對日期進行截斷
select trunc(sysdate,'MONTH') 月,trunc(sysdate,'YEAR') from dual;
--日期格式
select * from emp where hiredate=to_date('1982-01-23','yyyy-mm-dd');
-- 查詢當前日期：顯示: 2011-09-17 15:12:15今天是星期六
select to_char(sysdate,'yyyy-mm-dd hh24:mi:ss"今天是"day') from dual;
--查詢員工信息，顯示員工的編號，姓名，月薪,要求有貨幣代碼(L)，千位符(,)，小數點(.),
select empno,ename,to_char(sal,'L9,999.99') from emp;
--通用函數
--nvl(exp1,exp2):當exp1為空時，返回exp2
--nvl2(exp1,exp2,exp3):當exp1為空時，返回exp3；否則返回exp2
select ename,sal*12+nvl2(comm,comm,0) 年收入 from emp;
--NULLIF (expr1, expr2),如果expr1=expr2,返回null;否則,返回expr1
select nullif('abc','abc') from dual;
select nullif('abc','abcaa') from dual;
--COALESCE :找到參數列表中，第一個不為空的值
select ename,comm,sal,COALESCE(comm,sal) from emp;
--給員工漲工資,根據職位漲，總裁漲1000，經理漲600 其他人員漲400
select ename,job,sal 漲前工資, case job when 'PRESIDENT' then sal+1000
when 'MANAGER' then sal+600
else sal+400
end 漲后工資
from emp;
select ename,job,sal 漲前工資, decode(job,'PRESIDENT',sal+1000,
'MANAGER',sal+600,
sal+400) 漲后工資
from emp;
多行函數
和單行函數相比，oracle提供了豐富的基于組的，多行的函數。這些函數能在select或select的having子句中使用，當用于select子串時常常都和GROUP BY一起使用。多行函數分為接收多個輸入，返回一個輸出。
組函數：
--求員工的工資總和
select sum(sal) from emp;
--求個數
select count(*) from emp;
--求平均工資
select sum(sal)/count(*) 方式一, avg(sal) 方式二 from emp;
--關于空值：組函數會自動濾空
select count(*), count(comm) from emp;
--max和min：求最高工資和最低工資
select max(sal) 最高工資,min(sal) 最低工資 from emp;
--分組數據：求各個部門的平均工資
select deptno,avg(sal) from emp group by deptno;
--group by作用于多列： 按部門，不同的工種，統計平均工資
--group by作用于多列：先按照第一列分組；如果相同，再按照第二列分組
select deptno,job,avg(sal) from emp group by deptno,job;
--：求部門的平均工資大于2000的部門
select deptno,avg(sal) from emp group by deptno having avg(sal)>2000;
--group by的增強
select deptno,job,sum(sal) from emp group by rollup(deptno,job);
--不同的deptno空兩行/取消設置
break on deptno skip 2/break on null