顛覆完美軟件：軟件測試必須知道的幾件事（讀書筆記3）

4、測試和修改軟件BUG有什麼分別？（第4章）

　　不能正肯定義測試，就可能會產生無休止的爭論。讓測試人員或開發人員不知道本身的本質工做是什麼，同時也會致使項目的失敗。

　　一、大機構和小機構對任務的分工

　　在小機構或者小公司，一我的能夠同時分飾多種角色，能夠發現問題，查明問題，定位，肯定重要性，修改和解決問題。

　　在大型機構或公司，必需要定義測試和開發的具體職責和分工，這樣才能避免項目衝突和失敗。當我的的職權範圍覆蓋測試團隊、開發團隊和支持團隊，就須要明確誰負責哪項工做。只有對工做進行明確分工，才能對整個項目加以改善，提升項目成功的可能性。

　　二、時間試探法的管理法則

　　項目中沒人能夠隨意浪費任何人的時間。

　　經過這一原則，有兩種應用：

　　1）測試人員在通知開發人員以前，對單個缺陷進行研究的時間限制在10分鐘之內

　　　　10分鐘後，若是對缺陷或缺陷所致使的問題仍是不瞭解，能夠請求他人幫助。

　　2）不要浪費時間來作細微的區分

　　　　發現和查明缺陷之間沒有一個很清晰的界限，不要浪費時間爭論特定的活動是否屬於查明問題，而讓測試人員和開發人員都投入進來共同完成工做。例如創建討論組，或者測試人員和開發人員一塊兒定位問題。

　　三、相關常識

　　1）定位缺陷須要花費時間，不要估算定位錯誤的時間。

　　2）每次任務切換都會損失一些時間，若是要切換的任務數目達到了五項，可能就會沒法完成任何工做。給人員分配工做時，不要隨意添加工做，最好不要超過3項。

　　3）若是須要進行可靠的測試，就須要集中精力，不能將其當作低優先級的工做而被打斷。

　　4）不能要求測試人員查明每一個故障，若是測試人員有相應時間，能夠安排幫助開發人員。但這項工做實質上仍是開發人員的職責。

　　5）不能要求開發人員定位每一個問題，這徹底是開發人員的工做。

　　6）程序完成修改，若是不趕時間，必定要從新測試（迴歸測試）。

　　7）在設計和構建代碼時就須要考慮可測試性，這樣能夠顯著下降測試方面所須要的時間和精力。

　　8）對間歇出現的缺陷要投入大量精力來追蹤，而不是把它做爲推遲測試和推遲修改的藉口。可使用已經得到的缺陷信息，而不要浪費測試人員時間，讓測試人員持續測試,去「重現」問題。

　　9）測試人員的工做不能僅經過肯定的測試用例來包含，應轉換爲按照測試活動進行思考。好比測試人員應可以根據項目創建測試用例，並執行測試用例。？？須要再考慮這一條。

　　10）當有如下這些特徵，可能須要公司改變一下：1.認爲測試人員須要查明和定位缺陷；2.認爲給開發人員送茶遞水是測試人員的工做。

5、關於軟件產品質量的元信息有哪些？（第5章）

　　軟件測試的目的是提供有關產品質量的信息，本章做者提供不少致使測試失敗的元信息，經過觀察和識別這些元信息，能夠顯著提升測試的效率並下降成本。

　　一、各類關於產品質量的信息

　　1）沒有規格說明書

　　咱們要對產品進行測試，就須要有測試所針對內容的規格說明書。若是找不到這些規格說明書，則就須要對所要測試的內容進行質疑了。

　　2）測試人員沒有對非本身組內的測試問題進行記錄

　　3）測試人員也許測試的就是錯誤的應用程序

　　4）由於最差的組件花費時間較多，因此不對最差的組件進行測試

　　5）忽略測試人員提供的信息

　　6）因懼怕開發人員發脾氣而不去報告缺陷

　　7）由於開發人員水平比較高而不進行測試

　　二、相關常識

　　1）測試報告中不會包括全部相關信息，裏面頂多也只包含一半你所須要的信息

　　2）應對測試的執行過程及其所隱含的狀況進行直接的觀察，從而驗證測試報告

　　3）測試只能顯示某些事情失敗了，或者在特定條件下沒有失敗。測試不是關於證明的，而是關於證據和推論的。

　　4）文檔不使用的狀況下沒有任何價值。若是使用了導向錯誤的文檔，比沒有價值更槽糕。

　　5）若是修改缺陷的速度慢於缺陷增加的速度，能夠中止製造新的缺陷，進而修復已有的那些缺陷。

　　6）有效的測試是，既要集中精力又要有目的。沒有目的地集中精神，看似不錯，但不會取得多少成果。

　　7）對發現故障應進行記錄，不該該進行忽略。爲了「節省時間」而不記錄故障狀況，會致使事與願違的效果。

　　8）不該該過分記錄發現的每個缺陷。由於記錄每個缺陷的代價是很高的，對於某些缺陷，不用準備正規的詳細說明，而是將相關信息放到電子郵件中，或在會議中進行說起，或向開發經理進行口頭報告。提升報告的成本會提高測試人員自我審查的可能性。有些類型的缺陷能夠做爲一個記錄按批提交。

　　9）某個模塊或者某個項目，已經發現的缺陷越多，將要發現的缺陷就會越多。完美的開發人員是不存在的。

　　10）模板保證了文檔的形式是標準的，可能會掩飾一些不可靠的信息。

6、如何應對因爲不一樣人因恐懼形成的防衛反應？（第6章和第7章）

　　測試的目的是提供信息，但人們經常會將這些信息當作某種威脅。測試很容易觸及人們的恐懼點，咱們要作的就是識別每一個人表現出的防衛行爲，而後主動的去應對，這樣才能避免混亂的情緒而影響測試工做。

　　防衛反應的類別和特徵

　　在咱們的自尊程度比較低而某些交互觸發了生存規則的時候，咱們會採起防衛措施。由於若是生存規則被打破，會致使咱們對自身安全產生強烈的恐懼感。而測試很是容易觸及這樣的生存規則。好比測試發現了一堆缺陷，項目沒法順利完成可能會觸發本身的生存規則，說：「我必須按進度工做」或者「我必須實現承諾」。

　　心理學家將這些防衛錯誤分紅六個類別：壓抑、合理化、投射、轉移、過分補償和強迫。

　　一、壓抑沒法接受的事物

　　壓抑就是不認可或者忽略咱們認爲沒法接受的想法、感受和記憶。壓抑的一個例子：鴕鳥將本身腦殼埋到沙子裏：「若是我看不見，那就不存在」，掩耳盜鈴。

　　二、讓不可接受的事物合理化

　　合理化就是試圖讓沒有意義的、愚蠢的或者是無理的舉動看上去合理。例如，一名開發人員聲稱：「我在程序中留下錯誤就是爲了檢驗測試人員是否工做得很好」就是在進行合理化。對於測試人員，應如何引發開發人員的注意而不讓他們感到威脅增長？他能夠經過解除掉開發人員的防衛（用合乎邏輯的過程進行解釋），而後說明須要作出一個修復。

　　三、將本身的負面品質投射給其餘人

　　負面的投射，就是批評其餘人具備咱們本身身上也有的某種並不但願的品質。好比，若是我私底下懷疑本身有些自私或者專橫，我可能會在其餘人身上找出這些負面品質，抱怨說：「他很貪婪」，或者「他頗有控制慾」。

　　四、轉移指責從而免除本身的責任

　　轉移就是指責並不是問題真正來源的人或事，從而免除咱們本身的責任。例如，「個人鉛筆斷了，因此我無法完成家庭做業。」。當開發人員面對測試人員提出的「沒法接受」的問題時，可能將抱怨向測試人員，向其餘開發人員，向他們的經理，向整個世界進行轉移。

　　五、對本身的不足進行過分補償

　　過分補償就是爲了彌補某些真實的或者是想象的我的不足而作得過了頭。例如，某我的由於以爲本身不夠可愛而變成一個工做狂。

　　六、咱們以爲失去控制時開始強迫本身

　　強迫就是沒法擺脫某種負面的行爲模式。例如，某人不容許對已定義的過程有任何微小的誤差。

　　七、相關常識

　　1）在人們懼怕時，須要注意觀察，很容易看出別人採起的防衛機制。

　　2）不能製造恐慌的環境，由於報信的人帶來了不想聽到的消息而指責他，你將再也沒法聽到你應該聽到的信息了。

　　3）一我的的強迫行爲，每每會致使其餘人產生恐懼和防衛行爲。最優的作法應該是努力讓本身的行爲合乎道理。

　　4）學會帶着讚揚的態度聽取異議和辯解。試着在反對觀點中尋找和尊重那些有價值的內容，實際上總會有些內容是有價值的。爭論者辯解說「太難修復了」，也許是爲了表示，「我不知道如何才能快速或者廉價地修復它，我也不肯定我花時間在這裏是不是個好主意。」

　　5）防衛行爲是人的廣泛反應，在任何地方均可能發生。

　　如何應對防衛反應

　　對於應對防衛反應，不須要了解他們爲何這樣進行防衛，須要經過創建合理的規則和指導原則來糾正這種狀況。規則：首先不將對方的行爲定義爲防衛性的，但按照它是防衛性反應來看待，看看它是否會在溫和的測試下表現出來。

　　一、肯定恐懼

　　首先，須要瞭解防衛性反應是受恐懼驅動的。嘗試一下可否肯定對方懼怕的是什麼，再看看在找到方法減輕那種恐懼以後會怎麼樣。 

　　二、使用危機思惟

　　危機思惟：在順境中要有警戒心。對某些防衛反應用危機思惟來思考，就是，某些防衛反應可能就是無效的論點，可能就是一些我的攻擊。這種狀況下，經過使用邏輯方法找到比人論點是不是基於邏輯。

　　三、實踐，實踐，再實踐

　　經過足夠的時間，能夠更好的辨識別人的防衛反應，並加以解決。例如，一些常見的防衛反應說法：「這是爲了用戶自身利益」，「這是按照我設計的方式工做」，「修復它「太冒險」」。

　　四、相關常識

　　1）要考慮差別，每一個人都有本身的規則。每一個人在本身的規則受到威脅的時候都會感到恐懼。規則不一樣，作出的反應也是不一樣的。要平等地對待每一個人，但不必定要採起徹底相同的方法。

　　2）不要對別人說他們不關心質量。每一個人都是至關關心質量，他們也許不瞭解如何得到高質量。每一個人對質量的見解都是不一致的，要教育他們，使得你們對於質量的理解統一。

　　3）須要經過實踐來學習如何辨識和有效地應對防衛反應。若是出了一些錯誤，讓本身稍微放鬆一下。

　　4）若是你是經理，須要處理其餘人可能影響他們工做完成狀況的反應就是你的職責。