優(yōu)秀的軟件測試人員思考問題的方式

1、軟件測試人員的思考問題方式測試員有很多不同的背景,測試團隊是多元化的集體,但是大多數(shù)人都同意:測試員的思考方式是不同的。怎么不同?有人說測試員是“消極”思維者。測試員會抱怨這種說法,認為自己喜歡征服,他們在報告壞消息時有一種特別的興奮感。這是種普遍觀點。我們提出另一種觀點。測試員并不抱怨,他們提供的是證據(jù)。測試員并不喜歡征服,他們喜歡打破產(chǎn)品沒有問題的幻覺。測試員并不喜歡發(fā)布壞消息,他們喜歡把客戶從虛假信念中解放出來。我們的觀點是,按測試員的方式思考意味著實踐認識論。測試運用的是認識論,不是靠傲慢或謙卑。本章旨在把測試員的大腦開發(fā)成,經(jīng)過仔細調(diào)諧的推理機器。請記住:要用精神力量做好事,而不做壞

2、事。經(jīng)驗1,測試運用的是認識論讀者看到這個題目會說:嘿,回來!我們在這里不是要討論對電影明星的新崇拜。請相信我們。認識論是能夠幫助測試員更好測試的一個哲學分支。認識論研究如何認識所了解的東西:研究證據(jù)和推理。這是科學實踐的基礎。研究認識論的人有科學家、教育家和哲學家,當然還有精英級的軟件測試員。學習認識論的學生研究科學、哲學和心理學,目標是了解怎樣才能改進我們的思維。我們使用的術語比經(jīng)典定義要寬,以便能夠更多地利用批評性思維的最新成果。將認識論運用于軟件測試,要問與以下類似的問題:z怎么知道軟件足夠好?z如果軟件并不是足夠好,怎樣才能知道?z怎么知道已經(jīng)完成了足夠的測試?蘇格拉底早在2400年

3、前就提倡并描述了對信念的批判性觀察,因此我們把他看作是最早的認識論者。直到今天,哲學家、科學家和心理學家都還在繼續(xù)研究認識論。作為測試員,這就是我們的遺產(chǎn)。經(jīng)驗2,研究認識論有助于更好測試直接與軟件測試有關的認識論問題包括:z如何收集和評估證據(jù)。z如何進行有效的推論。z如何使用不同邏輯形式。z擁有合理的信念意味著什么。z形式和非形式推理之間的差別。z非形式推理的常見謬誤。z自然語言的含義與模糊性。z如何做出好的決策。從來也沒有研究過這些問題的很多人也能測試得很好,但是如果要做得比很好還好,就要研究這些問題。研究認識論可幫助測試員設計有效的測試策略,更好地意識到自己工作中的錯誤,理解自己的測試能

4、夠證明什么、不能證明什么,并編寫出無懈可擊的測試報告。以下是三本具有很高可讀性的入門書:z批判性思維的工具:心理學的元思想(Tools of Critical Thinking:Metathoughts for Psychology(Levy l997。這本書是針對精神病醫(yī)生寫的,但是對測試員也很有用。書中每一章都是有關更好思維的不同思想。不一定把它全讀完,可以挑選任何一章閱讀。z思考與決策(Thinking and Deciding(Baron l994。這是討論思維世界的一本可讀性很高的普通教科書,是很好的入門書。z研究的技巧(The Craft of Research(Booth、Col

5、omb和Williams 1995。 這是一本有關批判性閱讀和寫作的很好的書籍,包括如何組織有說服力的論據(jù)。主要針對大學生讀者。經(jīng)驗3,認知心理學是測試的基礎如果說認識論告訴我們的是應該怎樣思考,那么認知心理學告訴我們的是我們是怎樣思考的。與測試有關的一些問題包括:z人的感覺和記憶可靠性。z信念從哪里來。z信念如何影響人的行為。z做出決策所使用的偏見和捷徑。z如何了解并分享所知道的信息。z如何考慮復雜事情。z在壓力下如何思考。z如何識別模式。z如何把想法和事物分類。z如何注意事物之間的差別。z記憶事件中的失真。z如何重新構建部分記憶的事件(例如不可再現(xiàn)的程序錯誤。從來也沒有研究過這些問題的很多

6、人也能測試得很好,但是如果要做得比很好還好,就要研究這些問題。研究認知心理學有助于理解影響測試員工作成績的因素,以及影響人們解釋自己工作方式的因素。開始研究認知心理學,不能不看曠野中的認知(Cognition in the wild(Hutchins 1995。Hutchins研究海軍航海團隊,以及他們怎樣協(xié)同工作。這本書的很多內(nèi)容也都與軟件項目和測試團隊有關。有關思考心理學的一本有用的書是理論與證據(jù):科學推理的能力的開發(fā)(Theory and Evidence:The Development of Scientific Reasoning(Koslowski 1996。在這本書中,Koslo

7、wski研究了人們?nèi)绾问褂靡蚬P系理論進行系統(tǒng)推理。這可以解釋為什么測試不只是查看外部行為,并對照簡單的預期描述進行檢查。經(jīng)驗4,測試在測試員的頭腦中優(yōu)秀測試和平庸測試之間的差別在于測試員如何思考:測試員的測試設計選擇,解釋所觀察到的現(xiàn)象的能力,以及非常令人信服地分析描述這些現(xiàn)象的能力。測試的其他工作大部分是一般的辦公室工作。如果看到兩個測試員并排工作,不一定能看出誰的測試更好。他們工作中能夠看得到的部分外表相同,這說明:z很多人認為測試很容易,因為可以很容易地模仿優(yōu)秀測試員的外表看得到的行為,并且他們沒有好的測試的其他標準。z如果要成為優(yōu)秀測試員,就要學會像優(yōu)秀測試員那樣思考,而不是模仿他們

8、的行為。 z經(jīng)驗5,測試需要推斷,并不只是做輸出與預期結果的比較流行的觀點認為,測試員只是執(zhí)行測試用例,并對照預期結果比較執(zhí)行結果。這種觀點把測試看作是簡單的比較活動,沒有看到一些聰明人必須設計測試,并確定預期輸出。想想看,測試設計人員幾乎從來沒有得到過應該測試什么的權威指導,更不要說應該期望什么了。可以得到的指導是要解釋的主體。在現(xiàn)實生活中,大多數(shù)測試設計都是基于推斷,或基于與測試員的推斷有關的經(jīng)驗。不僅如此,這些推斷還要隨時間發(fā)生變化。像測試員那樣思考,就是要掌握探索式推斷的藝術。探索式推斷聽起來可能像是奇怪的想法,這意味著要以一種不能事先預測的方式,通過一種思想引出另一種思想,然后再引出

9、下一種思想。有關探索式推斷的一本很好的書是證明與反駁:數(shù)學發(fā)現(xiàn)的邏輯(Proofs and Refutations:The Logic of Mathematical Discovery(Lakatos,1976。關于這本書需要注意的是,Lakatos如何說明數(shù)學和科學推理過程是探索式的,而不是腳本化的。甚至數(shù)學家也是積極探索地推理,而不是通過運用枯燥的公式。他們像測試員那樣思考!經(jīng)驗6,優(yōu)秀測試員會進行技術性、創(chuàng)造性、批判性和實用性地思考各種類型的思考都要考慮測試的實施。但是我們認為需要提出四種主要思考:z技術性思考。對技術建模并理解因果關系的能力。這包括諸如相關技術事實的知識和使用工具并預

10、測系統(tǒng)行為的能力。z創(chuàng)造性思考。產(chǎn)生思想并看到可能性的能力。測試員只能以能夠想象得到的方式進行測試,只能尋找猜想會存在的問題。z批判性思考。評估思想并進行推斷的能力。這包括在自己的思考中發(fā)現(xiàn)并消除錯誤的能力,將產(chǎn)品觀察與質(zhì)量準則關聯(lián)起來的能力,以及針對特定信念或所建議的行動過程構建有說服力的測試用例的能力。z實用性思考。把想法付諸實施的能力。這種能力包括諸如運用測試工具,并使測試手段和力量與項目范圍適應的技能?？傊?像測試員那樣思考,會最終導致相信事物可能不像外表看起來那樣。不管事物是怎樣的,都可能有差別。我們發(fā)現(xiàn),當測試過程以最具破壞性的方式失敗時,根本原因最有可能是視野狹窄。換句話說,這不

11、是運行了一萬個測試,而本來應該運行一萬零一個的問題;問題是沒有想象出測試的總體大綱,沒有做即使有兩倍時間和資源也不會做的測試。經(jīng)驗7,黑盒測試并不是基于無知的測試黑盒測試意味著產(chǎn)品內(nèi)部知識在測試中不起重要作用。大多數(shù)測試員都是黑盒測試員。為了做好黑盒測試.就要了解用戶,了解他們的期望和需要,了解技術,了解軟件運行環(huán)境的配置,了解這個軟件要與之交互的其他軟件,了解軟件必須管理的數(shù)據(jù),了解開發(fā)過程等等。黑盒測試的優(yōu)勢在于測試員可能與程序員的思考不同,因此有可能預測出程序員所遺漏的風險。黑盒測試強調(diào)有關軟件的用戶和環(huán)境知識,這一點并不是所有人都喜歡的。我們甚至把黑盒測試描述為基于無知的測試,因為測試

12、員自始至終都不了解軟件內(nèi)部代碼。我們認為這反映出對測試團隊角色的根本誤解。我們不反對測試員了解產(chǎn)品的工作原理。測試員對產(chǎn)品了解得越多,了解產(chǎn)品的方式越多,越能夠更好地測試它。但是,如果測試員主要關注的是源代碼,以及能夠從源代碼導出的測試,則測試員所做的工作也許就是程序員已經(jīng)做過的,并且測試員關于這些代碼的知識要少于程序員。經(jīng)驗8,測試員不只是游客測試員對產(chǎn)品做的大量不是測試的事,有助于測試員對產(chǎn)品的了解。測試員可以瀏覽產(chǎn)品,看看產(chǎn)品由什么組成,怎么工作。這樣做有很高價值,但這不能算是測試。測試員和游客之間的差別在于,測試員把精力放在評估產(chǎn)品上,而不只是見證產(chǎn)品。雖然不必事先預測產(chǎn)品應該表現(xiàn)出的

13、行為,但是試驗產(chǎn)品能力的活動還沒有成為測試,除非而且直到測試員運用某種如果問題存在就能標識的原理或過程時,這種活動才能成為測試。經(jīng)驗9,所有測試都試圖回答某些問題所執(zhí)行的所有測試,都是要回答有關現(xiàn)實的產(chǎn)品和應該得到的產(chǎn)品之間關系的某個問題。有時測試員完全沒有意識到自己在回答問題。如果測試員只是在尋找明顯的問題可能還好,但是在很多情況下,問題并不會閃爍著“請報告我”的提示自己跳出來。產(chǎn)品的有些錯誤行為用戶可能一眼就會看出,盡管測試員可能沒有注意到。在任何測試活動中,都要問自己什么樣的問題應該推動自己評估測試策略,否則就會更像是游客,而不是測試員。經(jīng)驗10,所有測試都基于模型測試員在設計測試時,頭

14、腦中可能會有一個想象的圖景,也可能有功能清單或某種圖表。測試員會有誰是用戶、用戶關心什么的一些概念。所有這些都是模型。不管模型是什么,測試都主要基于產(chǎn)品模型進行,而不是實際產(chǎn)品。有缺點的模型會產(chǎn)生有缺點的測試。學會一種對產(chǎn)品建模的新方法,就像是學會了觀察產(chǎn)品的一種新方法。要研究建模問題。測試員對建模藝術越精通,越能夠更好地測試。有關需求分析和軟件體系結構的教科書和課程會有所幫助。獲得各種建模技能的一種很好方法就是研究系統(tǒng)的思考。請參閱通用系統(tǒng)思考引論:25周年版(An Introduction to General Systems Thinking : Silver Anniversary E

15、dition(Weinberg 2001。經(jīng)驗11,直覺是不錯的開始,但又是糟糕的結束測試員很想根據(jù)自己的直覺使用具體的測試數(shù)據(jù),或判斷具體的輸出,即測試員自己知道的“本能感覺”,即使說不出來使用這些知識的合理性的理由。我們認為這是有用的感覺,但是只是在開始時更有用,而不是在其他時候。除了直覺有很強的偏見這個事實之外,真正的問題還在于測試員試圖讓其他人(例如程序員和經(jīng)理認真地對待自己的錯誤報告和質(zhì)量評估。除非這種發(fā)現(xiàn)是基于大家都有的直覺,否則測試員的工作建議很可能不被采用。因此.我們建議把直覺用作指南,但不能用作合理性證明。當有“這是問題,因為它顯然是問題”的想法時,可考慮換一種方式;“這是問

16、題,因為我觀察到產(chǎn)品行為與需求x、Y 和z矛盾,而我的客戶很看重這些需求?！苯?jīng)驗12,為了測試,必須探索為了很好地測試產(chǎn)品,測試員就必須研究它,必須深入它。這是一種探索過程,即使已經(jīng)有了產(chǎn)品的完美描述。直到通過想象或接觸產(chǎn)品本身而探索規(guī)格說明之前,所得到的測試都會是膚淺的。即使充分研究了產(chǎn)品,對產(chǎn)品有了很深的了解,仍然要探索問題。因為所有測試都是采樣,而且樣本永遠也不可能完備,探索式思考要在整個測試項目過程中,在尋求最大化測試價值時起作用。這里所謂的探索,是指有目的的漫游:帶著一般使命在某個空間中漫游,但沒有預先確定的路線。探索包括不斷學習和實踐。常常需要返回、重復或在沒有經(jīng)過培訓的人看來是浪

17、費的其他過程。也許正因為如此,探索對于測試和對軟件工程的重要性,常常沒有得到重視,總之受到這個領域的文獻作者和顧問的嘲笑。證明我們關于探索核心重要性的論斷超出了本書的主題范圍。生動地體驗探索的一種方法,就是觀察自己在不看印在盒子上的完成圖的情況下,如何拼接拼圖板,或玩“20點問題(Twenty Questions”或“策劃(Mastermind”游戲。請注意,通過預先嚴格確定的步驟進行,在這些活動中會怎樣遇到更多的困難,得到更少的回報。經(jīng)驗13,探索要求大量思索探索就是偵查,是沒有邊界的搜索?？砂烟剿骺醋魇窃谔罩绣塾?需要前向,后向和側向思索。z前向思索。根據(jù)已知探索未知,從所看到的探索還沒

18、有看到的,注意支流和副作用。例如,看到一個打印菜單項,點擊看看會發(fā)生什么。z后向思索。從懷疑或想象的東西返回到已知,嘗試證實或否定自己的推測。例如:懷疑是否有打印這個文檔的方法,于是打開菜單并檢查是否有打印菜單項Solow 1990。z側向思索。讓自己的工作由于新冒出的想法而轉移,然后再將探索主題返回到主線索上(de Bono 1970 。例如:這個圖非常有意思。嘿!我想該打印一些更復雜的圖,看看會怎么樣。即使沒有要測試的產(chǎn)品,也可以探索?？梢允褂猛瑯拥乃妓鬟^程探索一組文檔,或與程序員面談。通過構建更豐富、更具想象力的產(chǎn)品模型,探索也會不斷取得進展。這些模型以后會使測試員設計出有效的測試。經(jīng)驗

19、14, 使用誘導推斷邏輯發(fā)現(xiàn)推測誘導推斷(abductive inference又叫做假設歸納(hypothetical induction,是一種測試員每天都要使用的關鍵推理形式的有些怪的術語:最佳解釋的推理。其主要內(nèi)容是:1.收集一些數(shù)據(jù)并要找出其中的意義。2.構造可能說明這些數(shù)據(jù)的各種解釋。3.收集更多的數(shù)據(jù),以確定或否定每種解釋。4.從候選解釋中,選擇能夠最一致地說明所有重要數(shù)據(jù)的解釋,如果沒有足夠證據(jù)證實任何結論,則繼續(xù)搜索。誘導推斷是科學和測試的基本方法。醫(yī)生在為病人診斷時就要使用這種方法,測試員在判斷產(chǎn)品是什么和不是什么、產(chǎn)品應該怎樣運行或不應該怎樣運行時,也要使用這種方法。如果

20、要更好地進行誘導推斷,則:z收集更多的數(shù)據(jù)。z收集更重要的數(shù)據(jù)。z收集更可靠的數(shù)據(jù)。z理解應用于數(shù)據(jù)的原因和效果。z找出可以說明數(shù)據(jù)的更多、更好的解釋。z收集更多否定每個解釋的數(shù)據(jù)。z收集更多區(qū)分解釋的數(shù)據(jù)。z除非某個解釋能說明所有重要數(shù)據(jù),并且明顯得到比其他解釋更好的解釋,否則不要確定解釋。誘導是尋找好的解釋的一種系統(tǒng)化方法。盡管誘導推斷過程并不提供絕對確定性,但是在很多情況下,這都是最佳手段。經(jīng)驗15,使用猜想與反駁邏輯評估產(chǎn)品20世紀初,哲學家Karl Popper引入了猜想與反駁(conjecture and refutation方法(Popper 1989,用于如何區(qū)分宗教和科學問題

21、。這種方法基于科學家永遠也不能絕對肯定任何具體事實,或關于自然的理論這個前提。任何東西都是猜想。有些猜想很強.例如重力的存在。它是猜想而不是絕對肯定的事實,是因為能夠想象出新的信息,如果這種信息存在,就會使人們拒絕該猜想。Popper注意到,雖然我們不能證明猜想是真,但是卻可以證明猜想是假的。因此,他提出給定猜想的置信度,只能來自反駁它.但又反駁不了的努力。這種給出猜想并嘗試反駁的方法,以三種重要方式應用于測試:z測試的目的是顯示產(chǎn)品失效,要比顯示產(chǎn)品正常更有力。如果想知道產(chǎn)品是否能夠正常運行,尋找方法反駁其正常運行,這樣的測試可能更好。z有關軟件(軟件有怎樣的行為、如何好等已經(jīng)牢固形成的信念

22、應該受到質(zhì)疑。這意味著應該能夠想象出新的與已有信念矛盾的信息。否則,我們的信念只不過就是信仰。信仰在私人生活中是有益的,但是對測試是有害的。z警惕聲稱以超過測試員所運行的具體測試的方式,檢驗或確認了產(chǎn)品的測試。任何量的測試都不能提供產(chǎn)品質(zhì)量的確認性。z經(jīng)驗16,需求是重要人物所關心的質(zhì)量或條件可以從很多種“需求”定義中選擇適合測試員的定義。作為測試員,必須認識到誰的關于質(zhì)量的觀點最重要(并不是每個人的觀點都同等重要。然后了解對于產(chǎn)品他們要什么,不要什么。這種需求與軟件工程的“需求”(在“需求文檔”中發(fā)布的,并由有批準權限的人批準的一組陳述和所有種類的規(guī)格說明沒有差別。至于測試,產(chǎn)品應該具備或滿

23、足的任何質(zhì)量或條件都是需求。不同客戶通過產(chǎn)品要得到不同的東西,他們不一定知道要什么,而且所要的東西會隨時發(fā)生變化。這位測試員的工作更有意義。歡迎測試。經(jīng)驗17,通過會議、推導和參照發(fā)現(xiàn)需求如果期望得到一迭印刷精美、文件袋封條蓋有全球有效印章的需求,那還是另找工作吧。我們所經(jīng)歷的最好情況,需求文檔(包括所有種類的產(chǎn)品規(guī)格說明、用例、多媒體文檔等是不完整、不準確的,盡管需求文檔提供了信息并且是有幫助的。我們所看到的最差情況,文檔是不完整、不準確、沒有提供信息并且是沒有幫助的。測試員把項目文檔(產(chǎn)品的顯式規(guī)格說明看作是惟一需求來源會影響其測試過程。在我們所管理的所有測試團隊中,堅持這樣要求會招致反駁

24、。需求信息到達測試員主要有三種途徑:z會議。找出其有關質(zhì)量的意見具有影響力的人,與他們交流,了解他們最關心什么。 z推導。通過外推己知的項目和產(chǎn)品其他信息,確定什么需求最重要。z參照。既發(fā)現(xiàn)顯式,也發(fā)現(xiàn)隱式規(guī)格說明,并以此作為測試的基礎。在很多項目中,優(yōu)秀測試員所使用的大多數(shù)需求要么來自推導,要么來自隱式規(guī)格說明的參照。搜尋測試所需的信息,是測試員的工作。有一本關于這個問題的好書:探索需求:設計之前的質(zhì)量(Exploring Requirements: Quality Before Design(Gause和Weinberg l989。經(jīng)驗18,既要使用顯式規(guī)格說明,也要使用隱式規(guī)格說明并不是

25、包含測試所依賴重要信息的所有參照都是顯式地提供給測試員的:z顯式規(guī)格說明是一個有用的需求信息源,經(jīng)過客戶的權威確認。(“是的,這就是規(guī)格說明,是產(chǎn)品描述?！眤隱式規(guī)格說明是沒有經(jīng)過客戶權威確認的一個有用的需求信息源。(“這不是規(guī)格說明,但是有意義?！彪[式規(guī)格說明的威信來自其內(nèi)容的說服力和可信性,而不是客戶的批準。在大多數(shù)情況下,只有部分隱式規(guī)格說明與當前產(chǎn)品有關。隱式規(guī)格說明有很多種形式:z競爭對手的產(chǎn)品。z相關產(chǎn)品。z同一產(chǎn)品的老版本。z項目團隊之間的電子郵件討論。z顧客意見。z雜志文章(例如,有關產(chǎn)品老版本的綜述 。z相關主題的教科書(會計書籍適用于會計應用程序 。z圖形用戶界面(GUI風

26、格指南。z操作系統(tǒng)(o/s兼容性需求。z測試員自己的豐富經(jīng)驗。當產(chǎn)品與顯式規(guī)格說明沖突時,測試員的報告任務相對簡單一些:“產(chǎn)品違反了規(guī)格說明,因此產(chǎn)品也許錯了?！碑斶`反的是隱式規(guī)格說明時,測試員的報告必須詳細一些:“在Microsoft Office中,功能鍵F4固定用于重復命令。除非我們也這樣定義,否則在日常工作中也使用Office的用戶會感到困惑。”雖然沒有人說Microsoft Office是這個產(chǎn)品的規(guī)格說明,但是客戶可能會同意采用與Office一致的用戶界面會提高可使用性。如果是這樣,則Office 就是這個產(chǎn)品的一個隱式規(guī)格說明。有些測試員可能會問,為什么設計人員不把所有有用的信息

27、都放入顯式規(guī)格說明,使得他們不必再從隱式資源中分辨規(guī)格說明?；卮鸷芎唵?雖然這樣做方便了測試員,但是很昂貴,而且沒有必要。客戶相信測試員能夠使用所需的各種參考資料快速找出重要的問題。經(jīng)驗19,“它沒有問題”真正的含義是,它看起來在一定程度上滿足部分需求 任何時候聽到有人說“我試過了,它沒有問題”、“我保證它沒有問題”或“它現(xiàn)在更好了”,我們建議把“它沒有問題”解釋為“它看起來在一定程度上滿足部分需求”。測試員應該立即想到的一些問題包括:z“它”是什么?我們正在談論的是產(chǎn)品的哪個部分?z外觀是什么情況?到底觀察到了什么?z檢查了哪些需求?正確性如何?性能如何?z為了通過測試要在多大的程度上滿足該

28、需求?只是剛剛通過,還是超過指標很多?z它什么時候沒有問題?測試覆蓋了多大范圍的條件?通過這些條件可以安全地推廣到多遠?如果不愿意,可以默默地問自己。關鍵是如果對“它沒有問題”沒有進一步地限定,它就會是模糊的。測試員所認為的“它沒有問題”的意義,可能與別的人定義不同.經(jīng)驗20,測試員所能得到的只是對產(chǎn)品的印象不管測試員對產(chǎn)品的質(zhì)量有什么看法,都是猜想。不管猜想有多么好的支持,也不能肯定自己是對的。因此,任何時候報告產(chǎn)品質(zhì)量狀態(tài)時,都應該用有關測試方法和測試過程的己知局限性的信息,對報告進行限定。經(jīng)驗21,不要將試驗與測試混淆起來試驗的含義是什么,可能表示測試員執(zhí)行一段探索式測試,產(chǎn)生些沒有文檔

29、或試驗產(chǎn)品的臨時性試驗;也可能表示測試員編寫一套可執(zhí)行測試程序,或一套顯式的測試過程;也可能表示某種高水平的測試矩陣、測試大綱或一套測試數(shù)據(jù)。試驗的概念是自包含的、實在的,與其他方便(我們通篇使用方便(convenient概念,因為它是測試界的標準行話試驗不同,但也是受限的。關鍵還是測試,而不是如何將測試打成被稱為試驗的包。測試是任何至少包含以下四種活動的活動:z配置。準備要測試的產(chǎn)品,將其置于正確的起始狀態(tài),否則測試結果會受到不良變量的影響。z運行。向產(chǎn)品輸人數(shù)據(jù),向產(chǎn)品發(fā)命令,以某種方式與產(chǎn)品交互。否則,產(chǎn)品只是放在那里,測試員能夠做的只是評審,而不是測試。z觀察。收集有關產(chǎn)品行為信息、輸

30、出數(shù)據(jù)、系統(tǒng)整體狀態(tài)、與其他產(chǎn)品的交互等方面的信息。測試員不能觀察所有事物,但是沒有觀察的任何事物都可能使測試員看不到問題所在。z評估。運用規(guī)則、推理或可檢測所觀察到數(shù)據(jù)中存在問題的機制。否則要么不能報告問題,要么只是把數(shù)據(jù)提交給客戶,由客戶自己進行評估。試驗產(chǎn)生的可能有很多形式,不要過于關注形式,要保證有這四種活動發(fā)生。要關注執(zhí)行這些活動的思考者,關注試驗是否很好地完成了預想的策略和測試使命。經(jīng)驗22,當測試復雜產(chǎn)品時:陷入與退出有時復雜性可能是無法抗拒的。測試員的意志可能會被擊垮。因此,當要測試復雜和使人畏懼的功能集合時,可間歇進行。人的頭腦具有處理復雜問題的驚人能力,但是不要指望馬上就能

31、理解復雜產(chǎn)品?？稍囍妊芯繌碗s產(chǎn)品30分鐘或一個小時,然后停下來干點別的。這就是陷入與退出(P1unge in and quit法。不要擔心在這段不長的時間內(nèi)效率不高,如果覺得問題太多,要盡快退出。這種方法的優(yōu)點是,除了選擇產(chǎn)品的一部分并研究外,絕對不需要計劃。經(jīng)過幾個輪次的陷入與退出,就會開始明白產(chǎn)品的模式和輪廓,很快就會在頭腦中更系統(tǒng)、更具體地測試和研究策略。這種方法很神奇。最終,會掌握足夠的知識以設計全面的測試計劃,如果認為這些計劃能夠完成自己的任務。經(jīng)驗23運用試探法快速產(chǎn)生測試思路試探法(hcuristic是一種經(jīng)驗規(guī)則,是一種基于經(jīng)驗做出猜測的方法。這個詞源自希臘語,表示“開始發(fā)現(xiàn)

32、”。試探法并不能保證得到正確的答案或最佳答案,但是很有用。最早運用試探法的著作是如何解決它(How to Solve it(Polya l957。出于可能的測試用例數(shù)量是無限的,因此肯定要選出在所面臨的時間和預算約束條件下有效的少量測試用例。有經(jīng)驗的測試員會收集并共享能夠改進其猜測質(zhì)量的測試試探方法。一組好的試探方法有助于很快地生成測試。以下是采用試探法測試的一些例子:z測試邊界。邊界更有可能暴露規(guī)格說明的模糊問題。z測試所有錯誤消息。錯誤處理代碼與主流功能代碼相比,一般比較弱。z測試與程序員的配置不同的配置。程序員已經(jīng)偏信自己的配置沒有問題。z運行比較難設置的測試。在其他條件相同的情況下,易

33、于設置的測試更有可能已經(jīng)被執(zhí)行過。z避免冗余測試。如果某個測試實際上是重復其他測試,就不會產(chǎn)生新價值。為了明智地運用試探法,請注意:試探法中并沒有智慧,智慧來自測試員。試探法所能夠做的,只不過就是為測試員的思考提出建議。盲目使用自己并不了解的試探法并不是好的測試實踐。在收集測試方法時,要了解每個方法背后的原理,以及更適用和不太適用的條件。經(jīng)驗24,測試員不能避免偏向,但是可以管理偏向測試員是有偏向的,這使得測試員選擇一部分測試的可能性要比其他測試大。如果有一個很長的編輯字段,測試員也許更可能輸入諸如1111111111,而不是3287504619,因為輸入字符重復的字符串,要比從0到9隨機選擇

34、數(shù)字更容易。也許這是一種很小的偏向,但仍是一種偏向。更糟的偏向是,大多數(shù)測試員傾向于測試最可視的功能,不管是不是最重要的功能。此外,大多數(shù)測試員還傾向于考慮認為與自己類似的用戶,傾向于使用非常簡單、非?；闹嚨妮斎?而不是具有中等復雜度的現(xiàn)實輸入。以下是一些常見偏向:z同化偏向。更有可能把未來的測試結果解釋為總體上證實自己對產(chǎn)品的看法。z證實偏向。更有可能關注確實會證實自己對產(chǎn)品看法的測試結果。z可用性偏向。如果頭腦中已經(jīng)想到一種用戶以某種方式操作的場景,則更 有可能認為這種操作更常出現(xiàn)。z最初印象偏見。更信任所做的第一次觀察。z最新印象偏見。更信任所做的最近一次觀察。z框架效應。對錯誤報告的反

35、應與措辭有很大關系,不管其真正含義如何。z知名偏向。把碰巧認識的用戶意見放在更重要的地位。z表達偏向。期望較小的問題也許有較小的原因,而嚴重問題會有大原因。測試員不能避免這些偏向,因為這些偏向在很大程度上已經(jīng)固化在頭腦中。測試員能夠做的是管理偏向。例如,只需通過研究偏向并在實踐中注意,這樣在思考時就可以更好地進行補償。多樣化也可以抵御過強的偏向。如果測試員集體談論測試問題,可以將一個測試員的偏向降低到最低限度。根據(jù)定義,試探法也是一種偏向。使用試探法,是因為其偏向可以以比較好的方式引導測試員。經(jīng)驗25,如果自己知道自己不聰明,就更難被愚弄騙子說,最容易上當?shù)娜?是絕對自信不會被愚弄的人。作為測

36、試員也可以把這條定律用于自己的工作中。證明自己容易被愚弄。做到這一點并不難,只需仔細看看自己在測試中犯的錯誤。任何時候都要注意其他測試員所發(fā)現(xiàn)的自己本來也可以發(fā)現(xiàn),但是沒有發(fā)現(xiàn)的問題。如果真心認為自己容易被愚弄,也會比較謹慎一點,在考慮自己的測試策略細節(jié)時就會更認真一點。這是一種新測試員能夠提高的最快的方法之一,因為知道自己可以被愚弄是一種態(tài)度,并不是特殊技能或知識。新測試員的問題是,對于他們來說,這個定律只是一條信仰(“人家告訴我,我應該認為我可以被愚弄”,而有經(jīng)驗的測試員的感覺和反應,會通過實際教訓喚起和加強(“我還覺得1994年的那次大教訓。我們怎么也沒有想到病毒會感染我們自認為性能非常

37、可靠的磁盤。我的聲譽在這一天全給毀了” 。經(jīng)驗26,如果遺漏一個問題,檢查這種遺漏是意外還是策略的必然結果如果擲幣猜邊時,猜的是國徽面,出現(xiàn)的卻是字面.這是否意味著做出了差的決策?以任何理性的觀點看都不是這樣。除非在硬幣上做了手腳,否則出現(xiàn)任何一回的機會都是50%。出現(xiàn)字面沒有什么可奇怪的,只是不夠幸運罷了。決策策略沒有問題。在測試過程中沒有發(fā)現(xiàn)程序錯誤時也存在同樣問題,同樣也會困擾客戶。在研究測試策略出現(xiàn)了什么問題之前,先不要自責。出現(xiàn)遺漏,是否因為忠實地執(zhí)行了好的測試策略,并只是碰巧沒有發(fā)現(xiàn)那個特定的問題?如果是這樣,可保持原有方針不變。確實有這種情況。但是,如果遺漏程序錯誤是因為測試策略

38、關注了錯的問題類型,可利用這個機會改進測試策略。經(jīng)驗27,困惑是一種測試工具當測試員感到困惑時,這可能是某種重要的預示。z規(guī)格說明不清楚嗎?規(guī)格說明中的模糊點,常常是為了掩蓋有影響力的項目相關人員之間的重要分歧。z產(chǎn)品不清楚嗎?產(chǎn)品可能有嚴重問題。z用戶文檔不清楚嗎?產(chǎn)品的這個部分可能太復雜,有太多的特例和不一致性要描述。z內(nèi)部問題只是難以理解嗚?我們試圖自動化的有些系統(tǒng)具有內(nèi)在的復雜性,或包含復雜的技術問題。程序員也認為它們復雜、困難,并導致自己犯遺漏、誤解和過于簡化的錯誤。測試員對產(chǎn)品、技術和一般測試問題了解得越多,自己的困惑就會成為更有力的指南針,指出重要問題所在。在測試過程中,如果對產(chǎn)

39、品一無所知,那么至少知道自己在困惑。在這種情況下,困惑可以成為最佳交付內(nèi)容,即提出也許其他人沒有勇氣提出的問題。經(jīng)驗28,清新的眼光會發(fā)現(xiàn)失效理解事物,是把新信息吸收到已知信息中,同時修改已知的信息以適應新信息的高智力過程。測試員在理解了產(chǎn)品或功能部件之后,會在頭腦中形成映射,并且頭腦不再那么努力工作。對于測試員來說這可能是個問題。當非常了解產(chǎn)品后,會對產(chǎn)品做出更多的假沒,并更少檢查這些假沒。這種情況對于測試至少有三點提示:z第一次接觸產(chǎn)品或功能時,要特別注意使自己困惑和煩惱的地方。這可能 說明用戶也會有類似反應。z當與團隊的新成員一起工作時,與他們一起測試。觀察他們在了解產(chǎn)品時的反應。z警惕

40、陷人測試慣例。即使沒有遵循嚴格的測試腳本,也可能對特定功能太熟悉,以至于以越來越窄的方式進行測試。在任何可能的地方引人多樣性,或改由其他測試員負責。經(jīng)驗29,測試員要避免遵循過程,除非過程先跟隨自己警惕其他人的過程。測試用例和過程的描述,常常不提測試的內(nèi)部設計目標。這非常容易使測試員在執(zhí)行測試時并不太理解如何建立測試,或尋找什么。換句話說,測試員并沒有真正跟上過程。一般來說,測試過程的編寫和設計都比較差,因為沒有多少優(yōu)秀測試員像擅長計算機那樣擅長程序設計人員的工作。如果要遵循測試過程,最好采用自己設計、自己擁有或已經(jīng)完全了解的過程。為了得到最好結果,測試員必須掌握自己的測試,而不是自己的文檔。

41、要使過程跟隨自己。如果確信那些過程很好,也至少要研究一下過程的工作原理。請參閱使我們聰明的事物:機器時代的人性保護(Things that Make Us Smart : Defending Human Attributes in the Age of The Machine(Norman l993和信息的社會壽命(The Social Life of information(Brown和Duguid 2000。經(jīng)驗30,在創(chuàng)建測試過程時,避免“1287”我們中的Bach曾經(jīng)見過一位測試員編寫的測試過程包含“在字段中輸入1287個字符。”這1287是從哪里來的?測試員解釋說.他的測試想法只不過是在一個小輸入字段中,輸入非常多的字