其他

隨著Web技術和移動互連網的發展，越來越多的應用被遷移到了雲端，這也使得使用者可以隨時隨地使用它們。目前大量的優質應用，逐漸提升了使用者的品味，也降低了使用者的容忍度，如果你的Web應用無法使使用者滿意，那麼很快就會有其他的應用來代替。 　　對於開發人員來說，建立良好的客戶口碑才是最有意義的事情。在完成了Web應用的設計和開發工作後，並不意味著你就可以直接發布了，你還需要從各方面來對其進行測試，以便讓使用者在使用過程中，不會出現各種各樣的問題，比如效能、使用體驗、安全問題等等。

        好的單元測試用例中發現的問題揭露了設計和代碼上的缺點。 　　最近這段時間，對單元測試的介紹急劇地增多。而在上世紀90年代和2000年早期，這一習慣似乎十分無力。通常就是這樣，人們採用一項新的技術，回溯當年，各機構們也在從結構化設計方法轉向以對象為中心的設計方法，他們將所有的焦點放在至關重要的權利上，同時丟棄看起來不能與新願景整齊地融合的例行做法。因此單元測試就被忽略了。

  一作業系統裝入程式到記憶體中幾種方法： 　　1：絕對裝入方式(Absolute Loading Mode)： 　　即程式在編譯時間就產生物理地址的目標代碼，編譯完成後，不在需要對程式和資料進行修改，程式員也可以在程式中賦值物理地址。 　　缺點：不靈活，要求程式員對記憶體相當熟悉，只適用於單道程式環境。 　　2：靜態重定位裝入方式(Relocation Loading Mode)：

　　 1.1 效能測試計劃階段 　　測試計劃階段主要工作如下： 　　1、明確測試對象 　　2、定義測試目標 　　3、定義測試通過的標準 　　4、規劃測試進度 　　5、規劃測試參與人員（需求、開發、測試、營運和配置） 　　6、申請測試資源 　　7、風險控制 　　1.2 效能測試設計階段 　　測試設計階段主要工作如下： 　　1、測試案例設計 　　2、測試方法設計（單情境和混合情境） 　　3、定義監控指標，如測試效能指標以及效能計數器等 　　1.3 效能測試實施階段 　　測試實施階段工作如下： 　　1

介面測試資料準備方案 　　[資料準備部分主要是單元測試的測試資料準備策略方案。] 　　1  背景測試資料 　　測試背景資料是被測試系統運行依賴的業務資料，可能來自於其他外圍系統，背景資料通常在被測試系統中作為輸入資料，業務操作只是讀取操作，並不做任何修改，業務處理完成後者部分可能保持位置不動也可能被備份到其他地方。 　　背景測試資料在測試前根據測試需求進行一次性準備，並在測試前對背景資料表進行備份作為資料基準。

UI自動化測試，首要考慮的是我們所選用的測試載入器或架構對測試程式的支援如何。而這個支援，則主要是通過對控制項的識別和操作來體現的；但是，不管一個測試載入器或者架構對測試程式的支援程式如何，它執行測試程式時最終都是以螢幕的絕對座標來定位執行的，儘管我們平時都能聽到很多人在說，盡量避免用座標。 　　盡量避免用座標和最終通過座標來識別，這個看起來有點衝突，但是卻又不會衝突，是不是有點類似太極的感覺了。 　　座標，通常分為兩類：絕對座標和相對座標。 　　1.

       1、項目進度 　　1.1測試執行階段 　　寫清楚當前是在冒煙階段、功能測試執行階段，還是迴歸測試階段 　　寫清楚當前階段預計在什麼時候結束（在可控的情況下，如果不可控或者不可預測，說明風險在哪裡） 　　寫清楚當前測試了哪個模組，還有哪些模組沒有測試（一般都是先測試優先順序高的模組） 　　寫清楚下個星期的測試計劃是什麼 　　2、測試情況 　　2.1 再介紹一下本周的測試模組 　

　　安全性測試都有什麼。簡單的就包括跳過許可權驗證啊，修改提交資訊啊，複雜的呢，就有sql盲注、跨網站指令碼等等。這些咱們暫時不一一細表，只說說我們為什麼要進行安全性測試。、 　　其實網上關於安全性測試的資料並不是非常多，即使有人關注已只是很淺顯的談到部門安全性因素。當然，據我瞭解部分大公司都有自己的安全性測試團隊，這部分工作並不由測試人員進行。 　　胡扯了兩句，今天我們來聊聊為什麼進行安全性測試，或者說，安全性到底會引起哪些問題、後果。

  　　接觸功能測試已經有三年之久，對功能測試也有自己的一些感觸和心得，下面就說說功能測試那點事。 　　一、從測試前期工作開始談起

  　　作為黑箱測試的一個重要階段，功能測試毋庸置疑是不可缺失的。功能測試的相關話題很多，無論是測試的形式，例如手動測試和自動化測試，還是測試方法，例如資料驅動和關鍵字驅動，都有大量的研究文章。我這篇博文裡卻打算從國別不同的角度來討論一下功能測試的差異，原創文章可能有一些謬誤的地方，請讀者指摘。 　　日式循規蹈矩

讀微軟的軟體測試之道，其中有一個有趣的小故事。講得是主人公自己有個菜園，菜園裡的植物面臨著各種動物和昆蟲的威脅，所以必須要找到某種防護措施來阻止包括野兔，害蟲的侵擾，否則肯定會顆粒無收。主人經過分析，發現野兔對菜園的破壞其實並不大，最令人深惡痛絕的害蟲是蛞蝓。

        軟體開發難，恐怕大家都覺得最難的是搞清楚需求；但是其實更難的是 管理需求。今天在北京.NET俱樂部上又有人提出了這樣的問題，主要的痛點是他的Team Dev是為了自己的領導們服務的，幾個領導都有自己的想法，而且不停的在開發過程中提各種個樣的問題；開發進度無法保證，開發的結果總是滿足不了要求……

      項目在分析、設計、實現、組裝後，就進入測試環節，測試作為檢測我們設計的軟體是否滿足設計的功能需求，及其效能需求及其隱性需求起著重大的作用，作為最後成形的產品，可能在一些功能或是設計上存在缺陷，或是對於使用者的需求歪曲的設計，都可以在測試環節找出來，予以修正。 　　因此從這個角度上看，我們應該是重視軟體測試，軟體測試是提高軟體品質的一個重要手段。據國外一些開發公司的統計，一般是設計：實現：測試人員投入的比例是1:3:3，可見對於測試的重視程度。

  　　最近，我也在網上看了一些貼子有關測試團隊的管理問題，覺得在測試管理方面確實是個難題，這也可能測試團隊確實不太好管理的原因吧，但我想只要自己去思考、去探索，總會找到適合自己的測試團隊的管理理念和模式吧。 　　我自己總結了一下，也結合自己的一些管理經驗跟大家分享一下吧，歡迎大家把自己的提意見並把自己的經驗也分享出來吧， 也算是大家相互學習的一個機會吧。

黑盒、白盒測試 黑箱測試：已知產品的功能設計規格，可以進行測試證明每個實現了的功能是否符合要求。 白盒測試：已知產品的內部工作過程，可以通過測試證明每種內部操作是否符合設計規格要求，所有內部成分是否以經過檢查。 一、黑箱測試（又叫功能測試或資料驅動測試） 軟體的黑箱測試意味著測試要在軟體的介面處進行。這種方法是把測試對象看做一個黑盒子，測試人員完全不考慮程式內部的邏輯結構和內部特性，只依據程式的需求規格說明書，檢查程式的功能是否符合它的功能說明。

在移動互聯時代，每個人的智能手機上都安裝了各種各樣的APP，那我們在使用這些APP的時候都會用到找回密碼這個功能，這個功能極大的方便了使用者，但是如果這個功能沒有做好，或者對於測試工程師來說，如果沒有對這個功能測試好，也會造成一些嚴重的後果，比如，任意使用者密碼重設，使用者資料泄露等一系列安全問題。這個看起來很簡單的功能，卻被開發工程師挖了很多坑，我們一不小心就會掉下去。下面我們就一起探討一下，APP找回密碼這一功能中的那些坑。

       一次面試一個品學兼優的女孩子，剛從51testing學習完畢，來我們單位面試，由於我本人對於統計學比較有興趣，所以就問了她一個統計學的方法，什麼叫做正交測試。 　　她的回答非常流利，而且說這是51Testing老師所教。但是我卻說了她說得並不完全正確，我一時也沒有說清楚為什麼不正確，也許這就是直覺。

51Testing要求“原創首發”或者“國外原文翻譯”的稿件，稿件形式包括但不限於軟體測試經驗、經曆、見解、感想、隨筆、筆記等所有與軟體測試內容相關的一切稿件。 　　稿件要求及稿費相關說明： 　　　　1、原創文章徵稿——菜鳥也能煮酒論英雄，詳情請見 http://bbs.51testing.com/thread-77515-1-1.html 　　　　2、翻譯文章徵稿——閉門造車不如師夷長技，詳情請見

  　　下載地址：http://www.51testing.com/html/54/n-247254.html 本期雜誌內容： 　　● 自動化測試資料之可不可複用........................5 　　● 我的GUI自動化測試架構發展曆程.....................11 　　● 軟體測試中的衝突測試..............................35 　　● 基於Win32視窗的開源自動化測試載入器White............

在我們剛踏入軟體測試行業時，不管你是專業的、非專業的，培訓出來的還是未培訓的。剛進公司時你看著身邊的同時報的Bug很多並且大都是嚴重程度高，自己也很想提高一下，想要提高自己的bug敏感度，建議從下面幾點做起，純屬個人建議。 　　1 熟悉需求：這是最基礎也是最重要的，原始需求隨著項目的進度在不斷地變化，這就需要你多溝通多交流清楚最新的需求是什麼。畢竟書面上的需求是不完整的，隱性需求就靠你和PM溝通了，讓PM聽你的建議，從使用者的角度考慮。 　　2