記得上中學的時候，一天上數學課時我們老師給我們說過一句話：「學的越多不知道的就越多。」具體是因為什麼提到這句話時間長了，記不清楚了。記得當時他在黑板上畫了個點，然後又畫了個圈把點包在內。給我們講了上面的一句話，在剛開始時學習就是乙個點，但感覺已經學的很多了，在那點的範圍內都知道，也就是當時是感覺無所不知的。可是當學到一定程度時，點就變成了圈，學的越多圈就變的越大，與外界接觸的就越多，不知道的也就越多，反而這個時候就感覺自己什麼都不會了。
我說這些是想說自己最初選擇測試行業，而今天的為之迷茫所在。
別人的引導也好，時代的熱潮也好，那都不是我最初走進測試這個行業的主要原因。我當時選擇測試行業就感覺，測試不就是找問題嗎？應該是一件很容易的事，女生心細應該是比較適合自己的。找問題就不用去開發，應該不會費腦。別人做出來的看看，挑挑錯應該是不難，把測試想成了檢大公尺一樣簡單，（大公尺裡掉別的東西了，把大公尺裡面不能吃的都檢出來就ok了）。可是現在感覺。。。。。。。測試並不簡單，一點也不簡單。由其是現在的一般公司的開發狀況，不會是像檢大公尺，是不是大公尺能不能吃一眼都能看出來，那是一種實體現象，而測試是一種虛體，你是看不見，摸不著的。到底是對不對，那要看使用者的標準是什麼，也就是需求說明書為參考。可實際中往往也就缺乏固定的需求說明，而有時使用者自己也不知道自己今天想要的和明天想要的是不是一樣。這是個最大的難點，天天在做測試時就是在去想別人要想的，尤其是剛開始工作時，自己沒有什麼經驗，天天去想別人想要的不是一件容易的事。別外想的同時還得要顧慮到開發人員這邊的情況，乙個問題提的不小心一場戰爭就會爆發。這就講到乙個和人交流的技巧方面，這也是大部分測試人員面對的實際問題。
同時要想讓開發人員對你所提出的問題給予肯定的態度，那就要拿出實際的依據，在哪出現問題，什麼樣的操作出現的問題，問題出現的可能原因是什麼？等等。要做到這步程度那就有關技術性的問題了。什麼相關軟體的功能，效能操作環境等問題都得要去了解。以前從不看也不關心硬體的也不得不去了解。（呵呵，我以前就是個電腦白痴，除了知道開機關機，主機和顯示器分明白外關於主機裡面是什麼從來都沒有想過也沒有去看過，在學校時要是電腦有問題就會找男生幫忙。上電腦維修課時，除了自己有電腦的可能會感興趣外，一般是老師在上面講，下面該做別的事情做別的事情，這也是大多數女生的通病。）
而現在那還能和在學校相比呢，不是同事不幫忙，是老麻煩別人也不好意思，別人也有他的事情要做，而有些也是很簡單的問題。如在安裝軟體時遇到的問題，當然有的軟體很固執是比較難安裝的。
安裝完之後出現了一種新的問題，介面說明全是英語。哎，才知道自己的英語是多麼的多麼的爛菜。還得天天來補習英語。越來越感覺要學的東西越多。
由原來的自己感覺很容易的測試，現在看來一點也不是很簡單：
（1）與他人的交流勾通技巧；（2）電腦硬體和軟體相關的知識；（3）相關業務的關係流程；（4）外語的水平
都是有待學習的。以後接觸的更多要學的東西還可能會更多，也有可能相關的技術或是業務管理技能等方面。這也可能就是點和圈的理論吧。
最後附帶一句「書山有路，勤為徑；學海無涯，苦作舟。」送給自己，也送給閱讀者。
點和圈的理論在軟體測試中的思考
挨踢脫口秀，將技術娛樂化，碎片系統化，盡在荔枝fm 記得上中學的時候，一天上數學課時我們老師給我們說過一句話 學的越多不知道的就越多。具體是因為什麼提到這句話時間長了，記不清楚了。記得當時他在黑板上畫了個點，然後又畫了個圈把點包在內。給我們講了上面的一句話，在剛開始時學習就是乙個點，但感覺已經學的很...
某君的一點軟體測試思考
測試的過程應該嚴格遵循一定的過程與計畫，這樣的過程體現於測試案例中，測試者可以只按照測試案例便可以找出該軟體的問題所在，而不需要對軟體的需求有深入的了解，恰恰這個測試案例的編寫人卻需要很深入了解軟體需求設計架構，可是能夠編寫好的測試案例的是乙個測試員的基本素質。總結幾年風雨兼程的測試歷程,有以下的一...
軟體測試的基礎理論
一 測試的目的 發現軟體中的缺陷和錯誤，並加以糾正。二 測試的一般流程 粗略版 明確測試物件，了解測試物件 根據需求文件編寫測試計畫 設計測試用例 搭建測試環境 執行測試用例 編寫測試報告 詳細版 1 編寫測試計畫 成果 專案進度計畫 需求說明書 2 編寫測試用例 成果 概要設計說明書 詳細設計說明...