【文章內(nèi)容簡介】 ，記得比較清楚的有關于專屬管轄的一個選擇題，我想不學法律的人恐怕很少有人知道什么是專屬管轄吧。在我飛速做完以后，一看時間，還有5分鐘不到。我一向自居做題速度快，我想應該有很多人比我還感到時間緊吧，如果他真的是每道題都自己去做的話。我稍微檢查了一下前面做的邏輯題，居然還讓我發(fā)現(xiàn)了一個明顯做錯的——人家讓選錯誤的，我選成對的了。交卷出來，聽到有人在說還剩30分鐘的時候她才做了100個題?？磥碓谶@種考試中，放棄也是很重要的。后來一想，今天考試的人中有學計算機的，有學法律的，有學經(jīng)濟的，其他專業(yè)的題大家肯定都一樣的不會做，重點的得分點應該還是前面的邏輯題吧，后面的只要把本專業(yè)的不做錯就達到目的了。不出意外的話，我想我這次又會被農(nóng)行鄙視了。不過也好，讓我又見識了一場高難度的考試。100道選擇，一道一分求職45道單選，其余的是多選，都是4個選項多選（一個以上答案正確）：人文常識，英語（暈，這個居然放在多選里面。幾個選擇，一篇閱讀理解），金融有關知識單選45個，會計審計知識，考的不深，有細節(jié)多選(2個以上答案正確)：專業(yè) 會計審計知識記得的題目：wto保護期截止日期貨幣收付應填寫的憑證（收款、付款、轉賬？）外幣核算差額應付工資的期末余額（借方，貸方？）查找借貸計入同一方向的錯誤（差額法？）現(xiàn)金流量屬于投資的項目？主營業(yè)務收入借方核算（銷售折讓，退回？）應交稅金—未交增值稅核算內(nèi)容（本期未交，多交？）不真實原始憑證的處理（退回，拒絕接受？）第二篇：測試經(jīng)驗總結黑盒測試人員和用戶，都是站在實際應用層進行操作，因此他們對應用層的可用性、實用性非常關注。用戶不懂的是軟件的使用，而相對用戶來說，測試人員對軟件比較了解，但不熟悉業(yè)務本身。八個字歸納：用戶是用，測試是測。用戶不懂使用就需要技術支持人員去培訓，而測試人員在測試初期經(jīng)過開發(fā)人員和項目負責人的簡單培訓后，就應該通過所學的理論知識和相關的業(yè)務知識獨立去了解、深入到軟件的功能點中。應該做到：由測試人員培訓技術支持人員，由技術支持人員實施時給用戶培訓。阿豬工作守則第一條：帶著問題去測試測試中會遇到很多問題，沒關系，沒有腦子里面的一個個問號，是不能很好的發(fā)現(xiàn)問題的。往往發(fā)現(xiàn)一些藏的很深的bug都是在測試人員一步步解決這些問號的過程中，切忌遇到問題就問，不僅因為增加不必要的與開發(fā)人員、負責人等的交流時間可能延誤項目進度，而且自己對問題的印象也不會很深刻，畢竟在相對較短的測試時間內(nèi)，聽不如記，記不如自己去發(fā)現(xiàn)規(guī)律。什么時候應該提問題？我們都知道，作為測試人員，并不是測試期間什么時候遇到問題就要馬上問，那什么時候是提問的時間？培訓培訓時，一般在講解內(nèi)容的間歇允許打斷，由培訓人員解答測試人員的疑惑。培訓的過程其實就是一個傳輸新知識并答疑的時間，這個期間的提問是歡迎的，也可以增加參與性和調(diào)動積極性。所以希望大部分的問題能在這個階段提出來。受時間、環(huán)境等條件制約，有時培訓的人講的也不一定細致和全面，這時就需要自己多想，想想這個功能是干什么的，為什么這么做，對應的業(yè)務是什么。阿豬工作守則第二條：培訓時腦子靈活轉動，多想多問以前大家可能有過參加辯論會的經(jīng)歷，就算沒有其實和人聊天也是一個交互的過程。參加辯論會要求快速思考，然后放慢語速說出自己的觀點，因為不能說錯。我們在參加培訓時前者相同，后者相反。腦子嘴巴都要快，說錯了也沒有關系，自己的想法被糾正的過程中也是加深印象和理解的過程。計劃評審提出對于軟件不理解、安排的任務不明白的地方。測試期間這個時期最主要的問題應該集中在影響測試流程和進度的問題，而不是說明書或其它文檔上已有的內(nèi)容，或者與自己負責模塊無關的內(nèi)容。開發(fā)人員和其他測試人員都有自己的進度安排，因此，影響測試流程和進度的問題,馬上問！不影響流程的問題，記下來統(tǒng)一問！不必要的問題（說明書或其它文檔上已有的內(nèi)容、講過三遍以上的問題、今晚去哪里吃飯的問題），不問！好處：避免不必要的時間支出，不打亂自己的測試思路，一氣呵成，并且使項目成本得到控制壞處（？）：腦子里、筆記本上留下一堆待解決的問號吧，浪費腦細胞和公司的筆和紙張等資源阿豬工作守則第三條：先做事，后學習在有限的時間內(nèi)先完成該做的事，有空閑的時間再去補充自己的知識。要很好的把握上述內(nèi)容，也要求提高培訓期間培訓人員培訓內(nèi)容的完善性，要求前期培訓人員強調(diào)出軟件的重點、難點和注意事項。這個期間適合于上面提到的“帶著問題去測試”的方法。但有一點需要注意：不要為了一個地方的卡殼在那耗上一天半天的，這就不值得了。測試中期評審測試問題答疑解惑的時間。測試報告評審對一些結論有疑惑和不解的地方，提！一個老生常談的話題。阿豬工作守則第四條：好記性不如爛筆頭測試培訓的時候對于一些重點應該記下來，即使當時聽懂了；沒聽明白的更應該記下來，到測試軟件的時候去驗證自己的疑問。如果培訓時特別強調(diào)的地方，測試時再去問，這就不好了。養(yǎng)成一個良好的習慣，會使以后的工作更加順利。學校是專門學習的地方，公司就是工作的地方，因此，它們的性質決定了其學習內(nèi)容和方法的不同。學校 公司 備注內(nèi)容上 主要是系統(tǒng)的理論知識 主要是和項目相關的業(yè)務知識 如果在測試中感到自己部分理論知識欠缺時，就應該回家多補充了時間上 大塊時間的連續(xù)學習相對鄰散 在公司一般不會拿出大塊時間來學習和講解 形式上 老師授課＋自學 培訓＋交流＋測試過程中自學個人覺得，一個高效的測試流程應該如下：、設計文檔；這個階段要讓腦子里面形成對軟件的整體印象感，能夠讓自己把握全局，因此，測試負責人安排時間看文檔時，決不能忽視它的重要性，否則就會出現(xiàn)后續(xù)階段磕磕碰碰的情況。注重速讀，把握軟件說明，忽略具體的數(shù)據(jù)庫設計、功能點設計、計算、規(guī)則和輔助工具（相關軟件）說明文檔，囫圇吞棗的方法在這里就顯得很有效。如果項目時間緊或沒有文檔，這個步驟所做的事可以在下面完成。幾個小時至多半天時間，熟悉軟件框架和基本功能，不要求所有功能都會操作，自己負責的模塊可以多側重一些。主要癥對計劃中安排給自己做的模塊，這時就要相對放慢節(jié)奏，每一步操作、每個對話框（操作界面）都要深究，別放過任何情況。這時會遇到一些錯誤或不理解的地方，明顯的如報錯就提到開發(fā)過程論壇，不明顯的就先記下來，等這個功能點測完再回頭去看，你會發(fā)現(xiàn)：50％的問題可以自己分析出來和解決，有的問題不是問題，只是開始還沒有完全理解。阿豬工作守則第五條：軟件不是一次能測透的Rome is not built in one 、人力、環(huán)境資料等，都制約著測試的深度和廣度，因為不要期望一次能完全把握某個軟件。綜合測試的優(yōu)勢在于，我們負責公司產(chǎn)品的把關，而項目由產(chǎn)品延伸而來；測試產(chǎn)品會不斷出新的版本，一次沒有理解，可以在下一次中彌補，溫故而知新。一口吃不成一個胖子，看我這么瘦又這么能吃就知道了^^要結合自己的實際情況決定本次測試的深度，不要看著別人進度快了就打亂自己的節(jié)奏，只要安排合理，應該按照計劃來。特別忌諱認為自己這塊沒問題了就馬上去看看別人負責的功能，期望全能。這樣一般來說除了ljl這種全能性人物外都會造成最后自己的問題留了一堆，別人的也沒搞懂。新人特別注意，踏踏實實的搞懂每個自己負責的模塊，打陣地站，這種方法很有效。評價自己是否可以轉入下個模塊的幾個因素：自我提問與別人提問、測試進度如果大多數(shù)相關人員（主要是測試負責人、其他部分相關測試人員特別是開發(fā)組集成測試人員和技術支持人員）對于自己負責模塊的問題都能解答，搞定！NEXT轉入下個模塊。否則，還是再回頭想想思路和遺漏的地方。當然，要綜合考慮測試進度。請組長對自己提幾個軟件的問題，他會很樂意的。一個階段就進行一次小結，這個小結可以是書面的，比如測試問題記錄、測試用例補充、測試模塊設計等，但大多是自己分析，性能測試不僅是測試性能，同時也加深自己對軟件應用的理解，因為性能測試往往和實際應用或用戶需求結合的很緊密，避免造成軟件功能都會用，但不知用來干麻的尷尬情況。安裝盤程序測試，簡單過一下軟件功能有無錯誤。安裝盤程序文件、庫文件、組件等的完整性、正確性，這個非常重要，要不返工就浪費時間了。這個階段要積極與開發(fā)負責人和GJ溝通，確保最后的勝利。測試接近尾聲，總結自己對軟件的掌握情況，得出測試結論、歸納測試方法、提出修改建議，為軟件以后版本的修改提供依據(jù)，也為以后再測類似軟件提供捷徑。216。 用戶用軟件，測試測軟件培訓時多想多問216。好記性不如爛筆頭216。帶著問題去測試，在測試中解決問題216。216。 先做事，后學習，爭取雙贏軟件不是一次能測透的216。第三篇：測試經(jīng)驗總結6年測試工作的思考前言在公司已經(jīng)干了6年的測試了，干測試經(jīng)理也5年了。正好趁此機會把自己6年來一直想寫但沒寫的東西寫出來。這篇文件純粹是對自己工作的回顧。由于時間倉促基本上是想到什么些什么，有點兒亂，也請大家多多擔待了。只要還有些人能從中找到些兒同感，或從中得到一些幫助，一些經(jīng)驗，我就知足了。首先我要談談什么是測試。相信好多測試人員跟我一樣，來公司之前也沒有從事過任何測試工作。對于測試都是從零開始的。也有好多人跟我一樣，從各種書上或是培訓中得到過有關測試的各種定義。但不知道大家有沒有凈下心思考一下。什么是測試。在公司公司測試工作的定義是什么，測試的工作范圍是什么。測試的定義根據(jù)測試技術的發(fā)展，歷經(jīng)了3個主要的階段。第一個階段，認為測試就是找產(chǎn)品中的bug。第二個階段，除了找bug以外，又增加測試是對軟件質量的度量這一概念。第三個階段，明確了測試是指為了度量和提高被測試軟件的質量，對測試件進行工程設計，使用和維護的并發(fā)生命周期。注意其中提高的測試件，其主要是與軟件這個詞進行對應。明確測試也是一種開發(fā)過程。他的工作成果就是測試件，好像平時我們所謂的測試案例、測試腳本等等都可以稱為測試件。然后使用測試件去度量和提高被測試軟件的質量。目前，在中國大部分軟件企業(yè)，尤其是中小型的軟件企業(yè)還停留在第一階段。我個人覺得公司稍微好一點兒，處于一、二階段之間。因為我們平時做的最多的一件事，還是找bug。至于測試案例和測試腳本等等，只占用工作量的很小一部分。而且我看不到大家在平時的測試工作中是完全依據(jù)測試案例進行測試的。目前測試案例等工作更多的成為了一種形式上的產(chǎn)物。從有些部分所有產(chǎn)品的測試案例在一個下午就能評審完就能看得出來。說到這里順便在談一句測試計劃。目前的測試計劃是作為產(chǎn)品計劃的一部分。先明確大概發(fā)版時間，然后是各個階段的里程碑，其中提交集成的里程碑是死的。開發(fā)需要的時間就是那么多，剩下倒推的時間就是測試的時間。這樣定出的計劃是否能夠起到計劃的作用就不好說了?，F(xiàn)在的計劃更多的是羅列聯(lián)調(diào)測試的各種內(nèi)容，至于時間，不說也罷。所以從中也可以開出公司的測試也就停留在一、二階段之間。明確了公司測試的定義（個人理解），也就不難理解公司給測試人員的定位了。在測試人員中經(jīng)常流傳的一種說法就是國外測試人員的地位多么多么的高，開發(fā)就是coding。咱們公司開發(fā)比測試多拿多少多少，測試人員地位是開發(fā)序列中最低的。大家也要看看人家公司測試人員的素質，測試在開發(fā)過程中的重要性。再看看自己所從事的工作，就是找軟件的bug。當然我也個人認為有經(jīng)驗極其豐富的測試人員對產(chǎn)品的貢獻比開發(fā)和需求大。明確了這些，心里也就能少點兒不平衡感。說完個人對測試含義的理解，再說說個人對測試方案的一些思考。個人認為在公司6年，測試方法沒有什么提高。主要還是以黑盒測試為主。中間也曾經(jīng)引入過各種各種工具，但測試人員真正用起來的也就是robot。而且robot主要是進行回歸測試，再加上一些人并沒有真正認識到其價值，應用范圍也極其有限。對整體測試效率的提升影響不大。所以目前的測試方案還主要是以需求為依據(jù)的黑盒測試。至于什么極限值了，成對測試法等等，都是建立在黑盒測試的基礎上，而且從我一來公司就有相應的測試項目，只不過沒有明確概念而已。另一個說個人覺得6年來公司測試方法沒有什么提高的原因是，6年前測試是以人為主，靠得是測試人員的經(jīng)驗，對產(chǎn)品的熟悉程度，對業(yè)務的理解程度。6年后測試還是以人為主，人就是測試的主體，產(chǎn)品質量的保證。還沒有過渡到測試案例就是測試的主體，測試案例的完整性是產(chǎn)品質量的保證。只要測試還是以人為本，我覺得測試的效率就不會有太大提高，產(chǎn)品質量的信心來源也是對相關測試人員的信任。我個人覺得以黑盒測試為主要的測試方法沒錯，而且也比較符合目前公司的測試現(xiàn)狀。但一定要注意各種經(jīng)驗的總結、積累，更重要的是共享。雖然目前測試案例在測試工作過程中的地位不重要，但其畢竟是編寫者的經(jīng)驗積累。匯總起來也是一筆可觀的財富?？涩F(xiàn)在如果有人問我850的測試方案在那里，其中還有多大比例能夠用在現(xiàn)在的產(chǎn)品中，在現(xiàn)在的測試工作中有多少以前的案例能夠復用。其他產(chǎn)品中的測試案例中有多少是關于接口功能，有多少我可以借鑒。我不知道，這也是自己工作不到位的地方。所以我要說的作為黑盒測試為主要的測試方法，一定要注意測試經(jīng)驗的總結和共享。而