爲什麼你需要原型測試？

4

原型是一個操場，如果你願意的話。你可以測試一下，如果不能解決問題，就把它們扔掉。迭代地瞭解事物如何與真實用戶一起工作等。

原型測試不明確或尚未完全確定的具體方面，因此比嘗試弄清楚如何整合某些東西還不完全知道一個完整的系統。這也意味着扔掉它時不會傷害太多。

在沒有任何實際編程的情況下實現原型並不罕見。紙質原型和交互式PowerPoint幻燈片就是這方面的例子。

來源

2010-04-02 19:52:09 Joey

+1

這也是很常見的原型，成爲生產代碼來完成。讓我感到害怕，但它總是發生。 – 2010-04-02 19:59:10

+0

那麼，有*的過程*工作的方式。例如IBM的「該領域的迭代式開發」（儘管他們選擇將其稱爲「原型應用程序」以將區別標記爲原型）。但是，它應該*通常應該如何呢？就是說，原型與生產代碼是分開的......然而，正如你所指出的那樣，這可不是它總是如何結束的。 – Joey 2010-04-02 20:00:59

1

編寫高質量的生產軟件需要在項目的所有領域進行大量的工作。如果系統的某個特定部分可能很難實現，甚至不可能實現，那麼編寫一個可以解決問題的原型是一個不錯的主意。當知道問題可以解決時，花更多的時間寫出真正的高質量軟件是可以接受的。

原型也可能是向用戶展示概念的一種方式，否則難以解釋。在這種情況下，原型重點在於展示該概念的關鍵特徵，但它可能例如顯示靜態數據而不是實際計算。

來源

2010-04-02 19:52:53

3

所以，當它不起作用時你不會被解僱。

來源

2010-04-02 19:56:12 dmb

1

通常，在對原型進行編碼時，您可能不太注意測試和編碼標準。目標是快速找到一些工作來證明這個概念，或者開始討論項目的各個方面。如果你確定這是不可行的或者決定採取不同的方向，那麼你可以減少做出決定的努力。原型與完成的（或正在進行的）產品有不同的質量標準。

有時你會拿原型，然後簡單地將它重構成實際的產品。這實際上取決於原型的結構是多麼謹慎。通常最好的做法是使用原型作爲概念並重新開始，使用常規流程和標準構建真正的應用程序。這樣，您的產品就不會因爲您快速獲取原型而採取的捷徑而「感染」。當用單元測試改造原型時，確定已經進行了充分的測試也很困難，因爲只需編寫少量的「正常」案例測試並輕鬆實現，尤其是在寫入的代碼難以測試的情況下。在代碼之前編寫測試並使用覆蓋率分析有助於確保您已從測試性角度對設計進行充分測試和思考。

來源

2010-04-02 19:56:16 tvanfosson

0

由於編碼該死的東西可能需要很多年，而原型，可以在幾分鐘/小時/天

來源

2010-04-02 20:16:27 Jimmy

爲什麼你需要原型測試？

回答

相關問題