軟件

        計劃：屬於組織管理層面的文檔，從組織管理的角度對測試活動進行規劃； 方案：屬於技術層面的文檔，從技術的角度對測試活動進行規劃。 　　測試計劃： 　　對測試全過程的組織、資源、原則等進行規定和約束，並制定測試全過程各個階段的任務分配以及時間進度安排，並提出對各項任務的評估，風險分析和管理需求。 　　測試方案：

       在回答要不要做全才之前，我們應該先弄清楚一個問題，作為一個全才應該需要哪些能力。 　　我認為作為一個測試人員，應該具備四方面知識：測試基礎，行業業務儲備，測試載入器和技術，測試管理能力和經驗。 　　以上四方面也是測試人員晉陞的參考，當然測試基礎咱們都有就看儲備了多少，其他三方面是咱們努力的方向。 　　測試基礎是所有測試人員應該具備的，其他三項精於一項可以一招鮮，精於兩項可以稱之為高手，精於三項的話。我的天啦

        特大好訊息。讓大家期待了很久的2013中國軟體測試現狀調查報告發布啦。。這次的報告新增了很多新的問題和分析，力求給大家更加全面和客觀的瞭解軟體測試行業的現狀，想要瞭解的朋友請點擊網址http://www.51testing.com/html/84/n-863184.html　　調查背景

       1、可編輯文字框的測試：主要是“字元長度、字元類型、文字格式設定”的測試 　　字元長度的驗證：最大值、最小值、適當值、超長值。 　　字元類型的驗證：中(簡、繁)、英(大小寫)、數字(整數、小數、負數)、標點符號(全形、半形)、特殊符號(斷行符號、空格、TAB、指令碼語言、NULL、null)、逸出字元，及這些字元類型的組合。 　　文字格式設定的驗證：比如日期(控制項、手動輸入)、郵箱、手機號。

         C/S結構與B/S結構的特點分析 　　為了區別於傳統的C/S模式，才特意將其稱為B/S模式。認識到這些結構的特徵，對於系統的選型而言是很關鍵的。 　　1、系統的效能 　　在系統的效能方面，B/S佔有優勢的是其異地瀏覽和資訊採集的靈活性。任何時間、任何地點、任何系統，只要可以使用瀏覽器上網，就可以使用B/S系統的終端。

       過猶不及，這是古代《論語》中的一個成語，做得過了就好比沒有做夠一樣。在軟體測試行業中同樣也會存在過度測試的情況，今天我就班門弄斧一下說說我對過度測試的理解。 　　很詳細的需求文檔會導致維護成本劇增 　　我所經曆過的項目中有過幾種很有代表性的PRD（product requirement document的簡稱，即產品需求文檔）：

 最近這個話題一直被熱論，感覺是個好事情，終於有人開始思考 軟體測試的價值，而不是盲目的用 軟體測試來彌補開發資源的稀缺，所以特意說一下自己的想法。 　　首先， 軟體測試存在的必要性。 　　關於軟體測試的目的各種書上不一致，比較通用的是驗證需求和實現的一致性。為什麼這些事情開發不能自己做。需要測試來做。原因有以下幾點。 　　從認知上：自己無法知曉自己的錯誤。

　　國內軟體測試工程師的職位從無到有，經曆的時間還不足10年。成熟的軟體測試理論體系構建也僅有10餘年的曆史。而縱觀現在如雨後春筍般蓬勃增長的電腦軟體企業，對優秀軟體測試工程師需求和渴望的現實，不禁讓我們不得不去思考一個問題：如何開展並做好軟體測試工程師的培訓工作。

　　粗看有些文不對題，不過這裡說的是有技術含量的軟體測試，而不只是有技術含量的軟體測試工程師，而這正是我們團隊需要做的。下面是對於測試組裡軟體測試工作的幾點思考： 　　1、關於需求分析 　　複雜的需求就像是一團纏在一起的毛線團，找不到開始和結尾。而我們分析需求的方式是每次好不容易都理清了看明白了，放在那裡不管了，過段時間又成了一團亂麻。如果有比較好的方法把這團毛線整理好了，按分類，順序擺放好，下次不管是自己還是別人再來用，就可以輕而易舉理清頭緒了。 　　2、關於溝通

　　想起這個題目，是因為最近遇到好幾次關於這方面的討論。發覺即便做過幾年軟體測試的老員工也或多或少有些這方面的困惑。當然一家之言，僅作拋磚引玉之談。 　　一、軟體測試就是保證軟體無故障運行 　　對這個，我只想說這個觀點只是出於軟體測試人員美好願望。再牛的軟體測試員也不可能保證他所測的軟體就能無故障運行。只能說在他所測的範圍內，軟體能按預先定義的需求運行。 　　這個誤區的一個潛在問題是，秉承這一觀點的測試人員可能更期望自己的測試對象能“順利”運行，而不是儘力發現產品中的問題。 　　

　　軟體測試中如何主動思考。如何?軟體測試人員的自由。你是如何理解的。 　　專案經理給你分配了工作後，他是否經常要關注你的進度和品質，如果真的是這樣，你就應該好好反思了。下面我談談我對軟體測試人員主動思考的理解（不包含測試模式等） 　　其實首先要瞭解軟體測試的本質或者說是目標，一般可以理解為“快速地發布高品質的產品”，2個維度，1）品質；2）效率。不管你在測試團隊的角色是什麼，最終目的肯定如此。 　　我剛畢業進入測試行業1年，是一個軟體測試小兵，從剛開始實習及適用進入公司做測試執行，

　　給出了軟體測試的適當定義之後，下一步就是確定軟體測試是否能夠發現“所有”的錯誤。我們將證明答案是否定的，即使是規模很小的程式。一般說來，要發現程式中的所有錯誤也是不切實際的，常常也是不可能的。這個基本的問題反過來暗示出軟體測試的經濟學問題、測試人員對被測軟體的期望，以及測試案例的設計方式。 　　為了應對測試經濟學的挑戰，應該在開始測試之前建立某些策略。黑箱測試和白盒測試是兩種昀普遍的策略，我們將在下面兩節中討論。 　　黑箱測試

　　幹了小三年的時間，對於軟體測試我也有自己的一點想法了，離開了也是該總結一下。 　　先說說什麼人適合做軟體測試： 　　首先要說的是對於一個優秀的軟體測試人員的要求一點也不比一個優秀的開發人員低（雖然我還沒做開發，這句話說的還不算有底氣）。而且在某些方面要更高一籌。換句話說一個好的QA應當也是一名優秀的開發，而優秀的開發未必能做好的QA。這裡的QA是指真正意義上的QA，而不是純Tester。 　　我認為，一個優秀的軟體測試人員應當具有的特質： 　　●

　　軟體測試作為軟體品質保證的重要手段已引起軟體使用者和開發人員越來越多的關注。然而在對軟體測試認識逐漸深化的過程中，首先應該弄清幾個問題。 　　非進行軟體測試不可嗎。

　　軟體測試的科學 　　軟體測試曾在商業軟體領域被認為是一種事後 的亡羊補牢。初級的產品經理甚至開發人員認為軟體測試是任何人都可以從事的工作。一些關於軟體測試的書籍甚至冠以“藝術”、“手藝”之類的名字。這導致軟 件行業的某些讀者誤認為品質測試不是軟體工程的一個學科。相反，通過缺陷鑒別，錯誤預防和合理風險分析的實測報告，有效測試不僅是一門工程的學科，而且 是提升軟體品質和可靠性的關鍵區段。 　　測試的創造力

　　不要測試它 　　做為一名軟體測試人員，我們也許會問我們自己很多問題： 　　● 我們可以立即執行的最好的軟體測試是什麼。 　　● 我將要使用的軟體測試方法是什麼。 　　● 這是一個Bug嗎。 　　● 我已經測試完成了嗎。 　　但是我們之中會有多少人提出以下的這些問題呢。 　　● 這個組件需要一直被測試到嗎。 　　● 需要由我來測試它嗎。 　　● 如果它不工作，誰會去在意它呢。

程式員與 軟體測試在工作流程中是上下遊的關係，而且工作上聯絡緊密，溝通上難免出現各種各樣的問題。筆者作為管理軟體行業的一個程式員，也算是和軟體測試人員打過多年交道。希望能從程式員的角度出發，為軟體測試人員提一點建議。 　　首先，我們一起來看一下程式員們最不願意從軟體測試人員口中聽到哪些話。 　　1、XX，又發現了一個嚴重BUG。 　　（尼瑪，文案錯誤也要算C級BUG嗎。尼瑪，1號BUG和2號BUG是同一個問題，你提兩遍C級。要不要哥把你提的BUG在JIRA裡都置成NotaBUG）

　　自動化軟體測試的實際情況 　　自動化軟體測試（Automated Software

　　軟體測試對軟體品質的保證起著致關重要的作用。雖然國內軟體企業越來越注重軟體測試工作，但仍然存在這樣一個不爭的現實：除了部分大中型軟體企業外，相當多的軟體企業的軟體測試工作還完全處於手工測試狀態，甚至還沒有穩定的測試團隊。在這樣的企業環境下，軟體測試工作變成了一項枯燥繁重的“苦差事”。大型軟體項目的新增業務需求和變更需求比較多，且各類業務比較複雜，如ERP、CRM、SCM等等。軟體開發往往採取模組化設計和增量整合的方式，加上某些系統對流程和許可權的控制比較嚴格，從而導致單據從受理到進入歸檔狀態

探索式軟體 測試的四個類型、探索式軟體 測試一共分為自由式探索式測試、基於情境的探索式測試、基於策略的探索式測試和基於反饋的探索式測試。下面將詳細介紹4種類型的應用情境。 　　一：自由式探索式測試