其他

作為一名IT工作者，或多或少的都會遇到過以下的問題。 1. 紙上談兵 ------- 舉個簡單的例子，馬謖兵書學得很好，結果還是被諸葛亮斬了腦袋。就是空得一頓理論，缺少實踐的檢驗。對於程式員也是這樣，紙上勾勾畫畫不是真本事，開啟電腦，開啟compiler檢驗你的代碼。 2. 天花亂墜 ------- 面試中，不僅僅會考察你的技術問題，對於你的行為言談舉止，同樣都很重要。空得一身本事，結果因為天馬行空，馬失前蹄的話，就有點太可惜了。

參加工作以來，手機測試是我的第一份工作，也是目前從事的工作。 這裡就說說我自己對手機測試的幾點看法： 1. 手機測試多半為黑箱測試，即手機應用測試。這種測試沒有什麼很大的技巧性，很多時候它根據個人的經驗而言。如果一個人對手機所有的模組的正常現象非常熟悉，那麼這個人就已經是一個合格的手機測試工程師了。   2.

//////////////////////////////////////////////////////////////////////////////// //第一次用窮舉法 // 05軟體 jacklam // 借書方案知多少 // EX8.cpp ////////////////////////////////////////////////////////////////////////////

我帶過多個Team Dev和測試團隊，說說我心目中好的測試人員。希望對大家以後的職業生涯有協助。 1工作積極主動  

大多數軟體測試員應具備的素質： 1.探索精神：軟體測試員不會害怕進入陌生環境。 有較強的學習能力，可以用最快的速度成為一個新的行業的專家。 2.故障排除能手：軟體測試員善於發現問題的癥結，喜歡猜謎。可以迅速的通過事物的表面現象發現事物的本質，能夠從瑣碎的現象中發現內部的聯絡和規律。 3.不懈努力：軟體測試員總是不停嘗試。他們可能會碰到轉瞬即逝或者難以重建的軟體缺陷；他們不會心存僥倖，而是盡一切可能去尋找。

什麼樣的代碼才是好代碼。衡量代碼的好壞的指標或者維度有很多，比如效能好、架構好、高內聚等，這些指標的側重點各不相同，不同的開發人員的關注的重點也各不相同。我個人更喜歡簡單的可讀性高的代碼，我主要從以下幾個維度衡量代碼是否良好： 代碼是可工作的

　　何為嵌入式系統。 　　嵌入式系統是指作業系統和功能軟體整合於電腦硬體系統之中。簡單的說就是系統的應用軟體與系統的硬體一體化，類似與BIOS的工作方式。具有軟體代碼小，高度自動化，響應速度快等特點。特別適合於要求即時的和多任務的體系。 　　嵌入式即時多任務作業系統

作為測試部負責人，我前前後後面試過很多人，面試過程中我通常會問來面試的人一個問題：為什麼要選擇做 軟體測試。其實這個問題也是我當初決定要做軟體測試時反覆問自己的一個問題。大家不妨在看到這個問題的時候也反問一下自己為什麼要選擇做軟體測試。

  　　對於測試案例的討論一直喋喋不休，什麼樣的測試案例是好的測試案例，每個人都有自己的觀點。這裡我不想說一個測試案例的屬性，用例的定義還有用例的特點，因為這些隨便一搜，就是一片，基本是你拷我 ，我拷你的結果，沒一點創新。 　　我一直在想，作為測試人員應該用腦袋去測試，也就是說應該在工作中不斷的總結經驗，把自己的發現應用到測試中去，這樣你才能有真正的提高，你所具備的理論和能力才有競爭力。 　　回到測試案例中來，我覺得做好以下三點就是一個好的測試案例。

  　　關於軟體測試這東西，玩了四年，仍然沒有摸透它的脾氣。 　　有人說，軟體測試是為了發現更多的缺陷，也有人說，軟體測試是為了保證產品的品質。都沒錯啊，一個是從職責的角度來看，一個是從控制的角度來看。 　　軟體測試，其實就是一個驗證的過程，軟體測試人員竭盡所能的折騰一套軟體，看它是否符合客戶要求的標準，是否能經得起折騰，藉以評價產品的品質好不好。不就是這樣嗎。：-） 　　常規的軟體測試理論是遵循了V模型中的V&V過程，也就是Validation and

Bob大叔在程式員的職業素養一書談到了最佳團隊陣容12人，基本上就是一隻足球隊的陣容，1個教練加11個足球隊員。 這12個人的團隊由一個專案經理，2名測試人員，2名分析師和7名程式員組成。分析師開發需求，並且編寫自動化驗收測試指令碼，測試人員也寫驗收測試指令碼。不同的是視角不同，分析師關注業務價值，測試人員關注正確性。分析師編寫成功路勁情境，測試人員關注可能出錯的情境，邊界，壓力測試等。專案經理追隨團隊進度，確保成員理解項目時間表和優先順序。 敏捷團隊的人數建議是6~10個人。以1

人們經常還是喜歡糾纏在一些具體的數字上，特別是西方人更是喜歡用資料說明問題，因為那樣客觀、具體，但同時也往往將人引入歧途，容易形而上學，因為每個公司、公司的每個產品、產品的各個項目或各個階段都不同，沒法用一刀切的辦法。在軟體企業，面對測試經理，常常被問的問題是“你們公司的開發人員和測試人員的比例多少。”，如果你回答是“2：1”，得到的反應也許不同，對方可能會說：你們公司挺重視品質的，測試搞得不錯啊。也可能會說：你們公司測試人員太多了，開發人員不怎麼樣吧。  

最近部門新來的兄弟比較多，大家之前接觸到的流程和規範都不一樣，當然對待測試過程中產生的Bug心態也不一樣，同樣對我們測試組的MM們，一貫面對了熟練的活動和項目開發，面對新的面孔新的處事方式，大家都有或多或少的問題。 　　1、先簡單介紹下大家共同面對的活動 　　活動開發目前大致分為：投票類、發號類、抽獎類、選秀類、調查類，我們測試組都在禪道上建立了對應的用例，有興趣的可以去

  在開始討論這個話題之前，我想先舉一個真實的例子:   有一對夫妻住在同一個房子裡， 但相互之間不溝通,或者說他們之間沒什麼好溝通的。 他們只有在重大事情發生的時候才用簡訊溝通。 否則他們都太忙於自己的生活， 也沒有時間去打擾（照顧）對方。 長年累月下去會發生什麼。 一次挫折、些許挫折、表面的憤怒、一次爆發就會發生。 只有更多的溝通、更少的爭執、一些認同和相互之間的鼓勵才能使一段關係更加穩固。   現在，將上面的情況和軟體項目周期比較一下。

　　摘要：手工測試和自動化測試都是軟體品質保障的重要途徑，也是很多測試人員爭相討論的兩種測試方法。如何正確的看待這兩種測試方式，更好的使兩者相互結合是我們現在所要討論的話題。本文總結了自動化測試和手工測試的優點和缺點，列舉了各自的適用範圍，並分析了自動化測試無法最終取代手工測試的原因。 　　1、自動化測試是靈丹妙藥嗎。 　　自動化測試有眾多的優點，例如：快速、全面、可靠、可程式化、可重複使用、可重用。自動化測試產品和解決方案的潛在客戶經常會以下面的思考方式設想自動化測試： 　　●

　　單元測試由一組獨立的測試構成，每個測試針對軟體中的一個單獨的程式單元。單元測試並非檢查程式單元之間是否能夠合作良好，而是檢查單個程式單元行為是否正確。在單元測試時，測試人員根據詳細設計說明書和來源程式清單，瞭解到該模組的I/O條件和模組的邏輯結構，主要採用白盒測試的測試案例，輔之以黑箱測試的測試案例，使之對任何合理和不合理的輸入都要能鑒別和響應。這就要求對程式所有的局部和全域的資料結構、外部介面和程式碼的關鍵區段進行案頭檢查和代碼審查。

　　有關自動化測試的誤區 　　目前，有些人對自動化測試的認識存在一定的誤區，因此有必要對自動化測試樹立正確的認識，以防止對其有過高的期望。 　　1．自動化測試載入器是“萬能”的

《探索式測試-實踐之路》--讀書筆記 探索式測試的概念：        探索式測試（Exploratory Testing）是一種自由的軟體測試風格，強調測試人員同時展開測試學習、測試設計、測試執行和測試結果評估等活動， 以持續最佳化測試工作，考慮到它所具備的即興發揮、快速實驗、動態調整等特徵，其思維方法可以追溯到軟體開發的最初歲月。

    1、喜歡做自己擅長的工作而不是應該做的工作；     2、還習慣於依靠自己的個人努力去完成任務而不是通過自己所帶領的團隊；     3、事必躬親，不善於授權和委派下屬的工作；     4、沒有工作目標；     5、沒有可行的工作計劃；    

標籤：錯誤   之間   family   區別   輸出   進階   理解   pytho   開發   目錄1、變數2、單引號、雙引號和三引號3、輸入和輸出4、條件判斷5、類型轉換5、迴圈7、小練習：猜數字遊戲9、格式化字串