測試與刑法之間的關係

2021-10-04 23:29:00 字數 1823 閱讀 3492

測試與刑法之間,有點開腦洞:

上週聽了張明楷老師關於刑法學習的分享,有諸多收穫和思考。

刑法怎麼學?老師給了四點建議:

1、培養良好的預判能力;

2、學會善意地解釋法律;

3、鍛鍊精準地歸納事實;

4、養成規範的涵攝判斷;

且慢慢聽來,有點意思:

我認為這四點建議與我們軟體測試有非常大的相似性。

下面我一一解讀:

1、培養良好的預判能力;

預判能力是測試的基本能力,在測試之前,我們是不知道可能會出現的異常結果。

但是,測試的基本思路就是設計一整套測試方法和測試模型,將實際的執行結果與預判的結果進行對比,進而根據預判的結果來綜合分析產品的質量。

以測試用例為例,非常典型,乙個完整的用例包括測試標題、前置條件、測試步驟、預期結果、實際結果五部分,編寫測試用例的過程就是對產品進行預判的過程,每乙個用例的預期必須設計到位,每乙個執行步驟的預期必須要對應清楚。

2、學會善意地解釋法律;

法律是冷冰冰的,正如需求是冷冰冰的一樣。

但是所有法律的目的一定是向好的,一定是為了解決和約束大家的行為。

所有的專案需求、產品設計、開發規範、測試流程也是一樣,看起來都是冷冰冰的,但它們的目的一定是為了更好的解決問題。我們需要從使用者的真實場景、問題痛點著手,從更多維度尤其是使用者的維度去理解需求;我們需要從公司的制度、流程、要求著手,理解產品設計、開發規範、測試流程等;這樣才能更好的去做測試。

3、鍛鍊精準地歸納事實;

精準的歸納事實,是測試人員成為頂級專家的基本能力。

比如說某個環節丟包了,那麼問題來了。

丟包的數量有多少?丟的是什麼型別的報文?丟包發生在資料處理的哪個環節?丟包的嚴重程度有多少?這個場景的測試用例覆蓋完整嗎?有臨時規避的解決手段嗎?後續如何從根本上解決?

總之,我們能夠歸納和提供的越精準,越有利於分析問題和解決問題。

4、養成規範的涵攝判斷;

最後乙個太重要了,所謂的涵攝判斷就是在事理、事實的基礎上如何給出結論,找到問題的原因。

比如說我們認為某個問題是缺陷,或認為設計不合理。

給出結論其實只是假定,我們需要尋找事實,尋找依據。

如果是那些簡單的缺陷,其實是很好定義的,但是對於那些很難界定的缺陷,則需要我們擁有非常深厚的功底和非常高的證據蒐集能力。

又比如說某些字元介面輸入比較慢,這算缺陷嗎,其實很難說清楚,因為怎麼才算慢呢?有標準固然好判斷,沒有標準又該如何抉擇?

又比如說某個介面互動起來不方便,這時候我們想提交乙個缺陷,那你能代表使用者的程度是多少?這些問題可能有很多人的主觀因素。

又或者更難一點的問題,某個效能測試結果,這個指標我們不確定好還是不好,我們如何確定乙個標準,或者說找到行業共識,那麼問題又來了,我們又如何來證明自己尋找到的標準或行規是具有說服力的?

最後的話:

我認為測試和刑法之間,底層邏輯就是思辨能力的相通性。

刑法是特別講求證據、法理、事實、結論的學科,而測試又何嘗不是如此?

我們盡力去挖掘使用者的真實需求;

在公司制定的工作法則和規範要求下,我們設計合適、恰當、完善的測試基線和質量控制模型;

在測試執行的過程中,我們尋找真實結果與預期結果之間的偏差;

之後我們竭力的尋找事實和依據,以證明可能存在的質量缺陷;

最終我們通過公正、高效、合理的方式找到解決問題的終極答案。

FastCgi與PHP fpm之間的關係

我在網上查fastcgi與php fpm的關係,查了快一周了,基本看了個遍,真是眾說紛紜,沒乙個權威性的定義。網上有的說,fastcgi是乙個協議,php fpm實現了這個協議 有的說,php fpm是fastcgi程序的管理器,用來管理fastcgi程序的 有的說,php fpm是php核心的乙個...

類與類之間的關係

uml uml是統一建模語言 為軟體開發提供一些標準的圖例,統一開發思想,從而促進團隊協作 在軟體過程中,會用到uml 分析 設計 編碼 測試 維護 主流的有 rup rational unified process 合理的統一過程 強調軟體開發一開始就要有好的設計 才能有好的設計 xp程式設計 e...

類與類之間的關係

1.在乙個類中將被聚合元素作為其屬性 如果所有類都會用到乙個類的物件,則把它作為屬性 在任何方法的任何類,都可以建立物件 package 聚合 public class car public static void main string args package 聚合 public class w...