ALM-測試

Lisää tämän kaltaisia

森林生態

luonut 瑞莎 余

部署-SQL

luonut 余小章 's

消費與生活 備份

luonut ray303.std ray303.std

專案管理

luonut BigELK176 ≡≡≡

ALM-測試

為什麼會測試不好寫

物件設計能力太差

物件相依性太高

不要為了測試而測試

不是用使用案例數量當指標

測試涵蓋率不是唯一指標

測試涵蓋率

沒有用需求，而是用無意義的糟糕測試達到100%的涵蓋率，所以，一昧的提高涵蓋率並不能解決問題

涵蓋率越高，發現缺陷的可能性更大

甚麼情況下不要寫測試

無法預測結果的

非對稱式加密

圖片

亂數

以下情境不要寫測試 Survey API、POC

不要測，好爽，是哪個案子，我要加入。

補測試的時機

不知錯誤在那，該如何進行下一步：這表示一次貪心實作太多功能，把目標縮小，一步步補 unit test 吧。

執行 debugger：同上，你還是得花時間設中斷，一步步看訊息，不如寫個 unit test，之後能持續受惠。

在程式裡輸出訊息找錯誤：與其花時間寫 print、看輸出訊息、再回頭砍掉 print，不如寫個 unit test，之後能持續受惠。

我發現以下幾個情況，都是寫新測試碼的好時機：

行為驅動開發 Behavior-driven development，BDD）

BDD in .NET - TDD 在實務上最後一塊拼圖

案例

實例化

需求

需求描述

Scenario用來驗證故事，Scenario都完成了，才代表功能完成

用一系列的Scenario，來驗證故事可以被實現 Scenario 1: 標題（描述場景的單行文字） Given [上下文] And[更多的上下文]... When [事件] Then [结果] And [其他结果]

使用者故事，系統對某方面的功能稱為"故事" User Story

範例

Story: 標題(描述故事的單行文字) As a [WHO 角色：誰要使用這個功能] I want [WHAT願望：需要完成甚麼樣的功能 ] So that [WHY利益：為什麼需要這個功能]

用極度抽象的方式來描述文件 你很難一眼看穿那麼多文件的內容，但卻可以透過使用者故事看出它針對的角色、想要實現的願望/功能及利益

不管用甚麼工具，使用者故事是寫下來討論用的

描述使用者、系統或軟體購買者，有價值的功能

通用語言

Cucumber for .NET

表達不一致是軟體開發最常見的問題，開發人員做出來的東西不是使用者期望的

開發人員做出來的跟PM想的不一樣

PM想的跟使用者不一樣

開發者和使用者使用同一種語言來描述系統，避免表達不一致所帶來的問題

BDD的開發基礎是使用一種通用語言，這種語言被開發者和使用者用來定義系統行為

用人話來說明需求、描述使用案例

BDD(Behavior-driven development)是TDD的進化開發方法，使用通用語言定義系統的需求(行為)

TDD的價值是需求，為什麼我們不把需求從程式碼裡面抽取出來呢?就這樣BDD的實作方式就被提出來

測試驅動開發 （Test-driven development，TDD）

LifeCycle

Subtopic

有甚麼特別?

TDD的規格本身就是可執行的文件

只是回到軟體工程第一件要做的事，先定義規格，再開發軟體

要測的就是需求，不論透過甚麼樣子的需求採集手段，進入到開發階段時，需求應該已經明確，這時候的需求就是使用案例(驗收測試)，TDD背後的需求才是真正的價值

測試就是需求，需求就是測試

依據『需求』先寫Test Code，然後再寫Production Code

由極限編程中倡導

不是測試方法，是一種開發方法

軟體工程

敏捷開發

不論何種敏捷方法，測試都是實施敏捷開發的基礎，依賴大量的測試才能快速的做出反應，並確保軟體的品質

敏捷開發並不是單指某種開發方法，而是同一類的開發方法，這些方法有一個共通性，有效的交流以便提早發生問題，降低修正問題的成本和提高成功的機率

傳統的流程裡面測試何時做?

跟敏捷的不同是?

敏捷只是縮短了每個階段的生命週期，讓問題越快浮現，不要上線前一刻才發現問題一堆

Waterfall

驗證模型

V-Model

開發人員最討厭的事

當你學會用使用案例當開發技巧，你還會再多討厭一件事

文件和程式對應不起來

沒有文件

使用案例能取代以往的文件嗎

可用來補足以往文件的不足

不能

為什麼用使用案例會減少整體開發時間

釐清需求減少浪費

寫使用案例是為了減少你的測試時間用的，減少測試時間進而減少整體開發時間，那你為什麼不做呢？

用使用案例來開發的好處

提升開發人員設計物件的能力

寫測試的重點是在於隔離技巧(mock)，這技巧學會了，設計物件及架構的能力無形之間就會提升

提升軟體的品質

測試程式可以變成可交付的文件

釐清需求問題，減少浪費，縮短開發時間

功能(目標)，團隊能有一致的共識，不會各自表述

就是一種使用範例

縮短找Bug的時間，快速地找出問題

需求異動或改善系統的時候，不怕系統被改壞

確保程式真的能動

使用案例

要有三個東西

驗證執行結果

執行步驟

輸入資料

不要用臆測的方法來除錯

用使用案例來取代

你以為你在開發，其實是在創造臭蟲...

測試作業太慢開始、程式碼之中散佈著因為需求或設計規格、或實作結構問題所產生的一些疏漏或錯誤，這些現象使得程式瑕疵擴散或蔓延的速度比修正的速度還來得快。當程式的瑕疵愈變愈多、除錯就會顯得更困難，對程式的除錯與測試都是個沉重的負擔，更不用說可以及早發現程式中的瑕疵了。

有些開發者會習慣於暫緩程式的驗證，他們總以為進行程式的開發遠比進行測試驗證還來得要有生產力，甚至在面對時程的壓力時，會選擇省略功能測試，期望以整合測試或系統測試來將測試問題延後處理

寫好的功能，沒有使用案例，很快就忘記這個功能是幹嘛用的

自己創造Bug，自己解開Bug

你誤會了，F5是偵錯，不是測試

一個好的測試程式碼有幾個特性

結果是穩定的，不會因為環境而影響結果

任何人、任何地點都能運行

能自動化，可重複執行

以前的測試方法做不到

思考一下，既然測試都是要做的事，這樣的方法不但沒有效率，還會影響品質

你需要用多少時間知道哪些程式被影響了?

用這樣的方法你知道程式碼異動後影響的範圍嗎?

上述的動作都是憑開發人員的心情、直覺，只有開發人員當下的狀態才知道，日後沒有人知道開發人員怎麼做，包含開發人員自己也沒辦法在短時間之內知道

其實你一直都在寫測試

需求異動時，你可能會這樣做

結果： A功能改好了，但BCD功能壞掉了，可怕的是BCD壞了你還不知道....

好花時間、好麻煩阿，最後，只針對那個需求按A按鈕

把UI打開，將所有的按鈕都按過一遍，下次需求異動的時候，在手動按過一遍

開發階段，你可能會這樣做...

對表單的CUD操作，會開啟SSMS，針對需求下Insert、Update(還原)、Select(人眼比對)

在UI彈跳出一個警告視窗，觀看視窗的結果，看完了再把它註解起來(人眼比對)

為什麼覺得不容易執行

測試VS不測試

主管不挺

既然要測，為何不挺?

寫好的東西要不要測?

不知道如何開始

心理障礙，不習慣改變、害怕、質疑

測試寫了，還是沒有辦法滿足使用者的需求

不寫測試的推託說詞

這個功能很簡單還需要寫測試嗎

只要有Production Code，就應該被驗證，而不是用簡單與否來當旗標

最有效確認需求的方法之一就是利用測試個案. 就像是在測試一個系統一樣, 來測試需求是否正確. 也就是說, 你可以用範例來闡釋需求, 把範例變成測試, 然後使用測試驗證需求」

為了避免浪費，必須要做需求確認

一個簡單的需求，大家的想法就不一樣..

但其實是，最簡單的事往往最花時間

寫測試會讓專案Delay

測試的重點不是寫測試，而是需求

需求不明確，幹嘛要花時間寫測試

為什麼需求不明確就要開始寫程式?而不是先釐清問題?

因為，寫了測試還是沒辦法達到User需求阿，幹嘛寫它

你可能搞錯對象了

功能都寫不完了，沒有時間寫測試

你有沒有碰過這些問題?

所以… 需求改來改去，PM下班，我加班 久而久之，形成對立

找不到錯誤，你認為沒有問題但是結果一直不對

用錯方法，除錯所花費的時間會是你開發的兩倍時間以上

總是要到上線前一刻才發現程式有問題，無法立即反應 http://www.lifeparty.idv.tw/blog/archives/308

維護前人留下的專案，不安感很重

進退兩難 了解前人的程式碼不難，難的是你不知道是否會引發出意料之外的副作用

平安就是福

除了主機要放乖乖之外，程式碼也要擺個平安符

改了A功能後，B功能不能動了?改A壞B

為什麼要一直改需求?不能把需求都定下來嗎?

Ruddy老師說過的話，一位信仰敏捷的人，是會認清這個事實： 「你無法凍結需求，正如你無法凍結市場、競爭、知識、進化或者成長一樣。」