目前分類:測試基本知識 (97)

瀏覽方式: 標題列表 簡短摘要
在上測試相關課程, 一開始都會問大家, 期待在課堂上學到什麼. 上了幾次後, 發現有幾件事情是大多數共同期待的:
 
A. 完整測試
希望測試可以很完整, 可以包含所有面向.
 
B. 可以找到所有 bug

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

今天整理一些東西, 看到一個名詞: Shift Left Testing. 平時自己為對測試懂得不少, 沒想到居然完全不曉得這是什麼, 並且從字面上也猜不出來. 只好乖乖 google, 來學學新東西.
 
在傳統開發方式, 測試活動的開始, 通常是在開發階段的後期. 那時候才開始進行測試, 不但錯誤不容易找, 找到之後修復所要花的代價也不低, 因為都忘了以前在寫什麼, 系統也變得複雜了. 更糟糕的是, 如果開發延遲了, 測試的時間便完全被壓縮了, 測試是需要時間去認識系統, 花時間去挖出更深入的問題, 時間太短是無法找出太多的問題. 所以傳統測試方式, 是有很多問題存在.
 
因此, 所謂的 Shift Left Testing 的觀念, 就是希望測試的提早發生, 並且能夠能夠經常舉行. 目前來說, 常見的 Shift Left Testing 有以下作法

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

James Bach, 測試界的怪才, 他曾經擔任過 apple 的測試經理, 老爸是天地一沙鷗的作者, 在每年大型的測試 conference 幾乎都可以看到他的身影. 是個超強的大怪咖.
 
7057554901_0cd4707347_b  
 
他最近在 blog 中寫了一篇文章,  根據他的經驗, 測試人員可以分成以下七類:
 

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

Planning is everything. Plans are nothing! 這是艾森豪將軍的名言. 二次大戰期間, 艾森豪帶領同盟國聯軍, 跨越英倫海峽反敗為勝, 靠的就是縝密的情報蒐集和靈活應變.
 
螢幕快照 2015-05-27 下午11.04.08  
 
我想大家應該都贊同這樣的理念, 專案一開始是要有計劃, 但是更重要的是要隨時隨地在規劃, 以因應各種突發狀況. 
 

kojenchieh 發表在 痞客邦 PIXNET 留言(1) 人氣()

很多開發人員在開發軟體時, 會說他們的工作很難估得很準, 因為 spec 常常更改, 或者 spec 不明確, 所以無法確保要做多久.
 
Developer-vs-Tester  
 
哪測試呢? 測試的工作就能估得很準嗎? 很多人會以為開發人員都已經寫好了, 測試人員只是把 test cases 跑完就好, 哪有什麼不確定的.
 

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

在最近的一門課程 - 測試個案設計與分析實戰班, 發現不少參加者是開發人員, 因為公司沒有專職的測試人員, 因此想要來學習如何測試. 
 
logo1  
 
聽到這樣的狀況, 真的很為這些工程師和公司感到高興, 我們對於軟體品質還是感到很重視, 願意花時間花錢出來學習. 不會因為公司小, 或者是沒有測試人員, 就放棄質量這一件事.
 

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

在 IEEE Standard 829 中有定義測試文件的範本應該長得什麼樣子, 你可以從很多地方找到個範本 
http://en.wikipedia.org/wiki/IEEE_829

Test-Planning-and-Development-Documentation  


可是很多人看完後會說這個太複雜了, 有沒有簡單的方式, 連做事的時間都不夠了, 哪有時間寫這麼長的文件. 我想是否要照著這個範本寫並不重要, 重要的是你需要考慮以下事情

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

軟體測試的方法有很多種, 其中黑箱測試方法被使用最多, 主要的原因是容易上手, 進入門檻不高. 所以很多測試人員會使用這種方法. 可是很多人對於何時該使用卻不是很清楚, 因此讓我們來做個簡單的比較吧

1. ECT (Equivalence Class Testing)
a. 說明: 將受測軟體的輸入資料, 切成好幾個分割(partitions), 對於每個分割, 將會有測試個案去涵蓋它
b. 適用時機
比較小的功能, 或是單一 API. 或是畫面某個 input control

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

很多測試人員會詢問, 是否有一種測試方法, 可以很系統化地, 來開立所有測試個案.

我也很期待有這種東西, 可惜一直沒有看到, 不管哪種黑箱測試方法, 都有它的優點和缺點.

更重要的是黑箱測試有個重大的致命點, 它是完全依賴測試人員的經驗. 如果測試人員的產品領域知識, 以及產品所處的系統知識豐富, 就能開出更好的測試個案.

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()


http://www.iiiedu.org.tw/ites/TCD.htm

 

對企業來說,軟體測試往往是軟體開發過程中,最繁瑣也是最重要的工作之一。其中測試個案開立技巧,更是決定的測試結果的成敗。因為好的測試個案能夠找出更 多錯誤,並且能以最小集合,來涵蓋最多範圍,以達到最佳投資報酬率。

 

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

何時測試可以停止

每次新版本要出貨時, 常常被詢問是否測試結束了? 品質是否有信心? 你依據的標準是甚麼? 

我想很多人都會覺得很難回答這個問題. 基本上, 可以根據以下五種狀況, 來決定是否測試可以結束.

1. 老闆說了算

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

單元測試 = 白箱測試?


單元測試 = 白箱測試? 這是很多人的想法. 一聽到白箱測試, 就認為他就是單元測試. 或者認為單元測試時, 就是要用白箱測試的方法來進行.

事情是這樣嗎? 讓我們繼續看下去:

kojenchieh 發表在 痞客邦 PIXNET 留言(1) 人氣()

Cross Browser Testing Tools 的介紹


Cross Browser Testing Tools–Reduce Browser Compatibility Testing Effort
http://www.softwaretestingstuff.com/2011/09/cross-browser-testing-toolsreduce.html


1. IE Tab:

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

自動化回歸測試的目的

回歸測試(regression testing)的目的, 是當程式有修改後, 檢查之前能運作的功能, 是否仍能無誤地被執行.

那自動化回歸測試的目的又是甚麼呢?

很多人覺得也是要確保之前的修改, 不會影響到原先的功能. 若是我們能將所有測試個案都自動化, 那就不用太多測試人員了, 因為之後都是測試程式在run, 測試人員就都可以休息了

根據殺蟲劑謬論(pesticide paradox), 你若是一再使用相同的殺蟲劑, 來消滅家中的害蟲. 時間一久, 蟲子就會有抗藥性, 之後對它們再也沒有用處了.

kojenchieh 發表在 痞客邦 PIXNET 留言(2) 人氣()

如何安排測試的優先順序


Tips to Prioritizing the tests | A way to achieve Time-boxing in testing
http://www.softwaretestingtimes.com/2010/05/tips-to-prioritizing-tests-way-to.html

一般測試人員最常遇到的問題, 就是要測試的東西太多, 但是時間太少. 作者在這這介紹一些經驗法則, 來處理這樣的狀況.

首先, 他提到要使用timebox的技巧, 他說這是可以使用在測試上面.

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

各種測試方法的問題

在 Exploratory Software Testig 一書中, James Whittaker在第二章中, 提到各種測試方法的不足:

Defect Preventation
從開發人員的角度來說, 他們希望藉由 design review, code review, static analysis tool, 和 unit test, 來增加軟體的品質.

但是作者覺得這些方法都有些根本的問題:
(1) 開發人員通常不是個好的測試人員

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

為什麼要記錄 bug 到 bug tracking system

最近有個新人, 我和他檢視完受測系統之後, 發現了一些問題. 這些問題有些很嚴重(功能尚未完成), 有些很單純(像是畫面上 layout 的問題, 或是錯誤訊息不是很正式). 因此我請這位新人去 submit bug.

隔了一天之後, 我雖然已經催促了好幾次, 可是新人都還沒有動作. 於是和他聊了一下, 他說他已經和開發人員談過了, 他已經知道了有這些問題, 所以不用再 submit 這些 bug 給他.

問他為什麼呢? 他說他已經跟他談過了, 如果再 submit bug 給他, 似乎是給他找麻煩, 給他增加不好的紀錄, 破壞了彼此之間的默契和情誼.

到此我開始明白了, 新人用的是開發人員的角度在思考, 這也是一般人不容易了解測試人員在甚麼的正常現象. 認為找 bug 是在給專案找麻煩, 是在挑開發人員的毛病, 有些事情大家講好就好, 幹嘛要記錄下來呢?

事實上, 紀錄 bug 到 bug tracking system是有些目的和幫助的:

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

如何當一個好的測試人員

8 Ways to be a Good Software Tester
http://www.testandtry.com/2009/04/14/8-ways-to-be-a-good-software-tester/

作者根據他七年測試人員的經驗, 給了我們以下的建議

1. 閱讀些有關軟體測試的東西
基本上, 這部分我覺得所有QA都缺乏的, 因為大部台灣的工程師都不懂測試, 身為測試人員需要更加強這方面的認識 

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

在測試人員心中, 何謂好的開發人員

7 Ways To Be Good Developer From Tester Point of View
http://www.testandtry.com/2009/04/29/7-ways-to-be-good-developer-from-tester-point-of-view/

作者在這篇文章中, 列出了七個項目, 指出怎樣的開發人員, 才是測試人員心中的好的RD.

1. 不要考驗你的測試人員
即使你和測試人員的關係不好, 也不要故意製造bug, 來考驗你測試人員的程度.

kojenchieh 發表在 痞客邦 PIXNET 留言(3) 人氣()

QA 該具備什麼要的能力? (3)

QA需要具備的第三個能力, 是需求分析.

需知道RD的工作通常是研究某種技術, 並且負責實作某些module or 功能.

他鑽的很深, 但是全面性可能不夠. 所謂全面性, 是指對於產品整體功能的了解度. 通常他只熟悉他所負責的部分, 其他部份的操作可能不太熟悉. 就算即使是他的部分, 若是加上對於環境的影響, 或是使用者可能遭遇的問題, 他可能也不見得很熟.

可是QA不同, 他需要測試大部分的功能, 或者說他需要組合不同功能來做測試. 並且他需要針對不同環境, 或是模擬使用者的環境或是行為. 因此他被要求的是廣度, 是全面性的了解.

因此QA會對於受測系統功能的了解度, 應用程度, 操控程度, 會比RD還要熟悉的多.

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

1 2345
找更多相關文章與討論

您尚未登入,將以訪客身份留言。亦可以上方服務帳號登入留言

請輸入暱稱 ( 最多顯示 6 個中文字元 )

請輸入標題 ( 最多顯示 9 個中文字元 )

請輸入內容 ( 最多 140 個中文字元 )

請輸入左方認證碼:

看不懂,換張圖

請輸入驗證碼