問題一：我聲明了什么！
String s = "Hello world!";
許多人都做過這樣的事情，但是，我們到底聲明了什么？回答通常是：一個String，內(nèi)容是“Hello world!”。這樣模糊的回答通常是概念不清的根源。如果要準(zhǔn)確的回答，一半的人大概會回答錯誤。
這個語句聲明的是一個指向?qū)ο蟮囊茫麨?#8220;s”，可以指向類型為String的任何對象，目前指向"Hello world!"這個String類型的對象。這就是真正發(fā)生的事情。我們并沒有聲明一個String對象，我們只是聲明了一個只能指向String對象的引用變量。所以，如果在剛才那句語句后面，如果再運(yùn)行一句：
String string = s;
我們是聲明了另外一個只能指向String對象的引用，名為string，并沒有第二個對象產(chǎn)生，string還是指向原來那個對象，也就是，和s指向同一個對象。
問題二："=="和equals方法究竟有什么區(qū)別？
==操作符專門用來比較變量的值是否相等。
比較好理解的一點是：
int a=10; int b=10;
則a==b將是true。
但不好理解的地方是：
String a=new String("foo"); String b=new String("foo");
則a==b將返回false。
根據(jù)前一帖說過，對象變量其實是一個引用，它們的值是指向?qū)ο笏诘膬?nèi)存地址，而不是對象本身。a和b都使用了new操作符，意味著將在內(nèi)存中產(chǎn)生兩個內(nèi)容為"foo"的字符串，既然是“兩個”，它們自然位于不同的內(nèi)存地址。a和b的值其實是兩個不同的內(nèi)存地址的值，所以使用"=="操作符，結(jié)果會是false。誠然，a和b所指的對象，它們的內(nèi)容都是"foo"，應(yīng)該是“相等”，但是==操作符并不涉及到對象內(nèi)容的比較。
對象內(nèi)容的比較，正是equals方法做的事。
看一下Object對象的equals方法是如何實現(xiàn)的：
boolean equals(Object o){ return this==o; }
Object對象默認(rèn)使用了==操作符。所以如果你自創(chuàng)的類沒有覆蓋equals方法，那你的類使用equals和使用==會得到同樣的結(jié)果。同樣也可以看出，Object的equals方法沒有達(dá)到equals方法應(yīng)該達(dá)到的目標(biāo)：比較兩個對象內(nèi)容是否相等。因為答案應(yīng)該由類的創(chuàng)建者決定，所以O(shè)bject把這個任務(wù)留給了類的創(chuàng)建者。
看一下一個極端的類：
Class Monster{ private String content; ... boolean equals(Object another){ return true; } }
我覆蓋了equals方法。這個實現(xiàn)會導(dǎo)致無論Monster實例內(nèi)容如何，它們之間的比較永遠(yuǎn)返回true。
所以當(dāng)你是用equals方法判斷對象的內(nèi)容是否相等，請不要想當(dāng)然。因為可能你認(rèn)為相等，而這個類的作者不這樣認(rèn)為，而類的equals方法的實現(xiàn)是由他掌握的。如果你需要使用equals方法，或者使用任何基于散列碼的集合（HashSet,HashMap,HashTable），請察看一下
java doc以確認(rèn)這個類的equals邏輯是如何實現(xiàn)的。
問題三：String到底變了沒有？
沒有。因為String被設(shè)計成不可變(immutable)類，所以它的所有對象都是不可變對象。請看下列代碼：
String s = "Hello"; s = s + " world!";
s所指向的對象是否改變了呢？從本系列第一篇的結(jié)論很容易導(dǎo)出這個結(jié)論。我們來看看發(fā)生了什么事情。在這段代碼中，s原先指向一個String對象，內(nèi)容是"Hello"，然后我們對s進(jìn)行了+操作，那么s所指向的那個對象是否發(fā)生了改變呢？答案是沒有。這時，s不指向原來那個對象了，而指向了另一個String對象，內(nèi)容為"Hello world!"，原來那個對象還存在于內(nèi)存之中，只是s這個引用變量不再指向它了。
通過上面的說明，我們很容易導(dǎo)出另一個結(jié)論，如果經(jīng)常對字符串進(jìn)行各種各樣的修改，或者說，不可預(yù)見的修改，那么使用String來代表字符串的話會引起很大的內(nèi)存開銷。因為String對象建立之后不能再改變，所以對于每一個不同的字符串，都需要一個String對象來表示。這時，應(yīng)該考慮使用StringBuffer類，它允許修改，而不是每個不同的字符串都要生成一個新的對象。并且，這兩種類的對象轉(zhuǎn)換十分容易。
同時，我們還可以知道，如果要使用內(nèi)容相同的字符串，不必每次都new一個String。例如我們要在構(gòu)造器中對一個名叫s的String引用變量進(jìn)行初始化，把它設(shè)置為初始值，應(yīng)當(dāng)這樣做：
public class Demo { private String s; ... public Demo { s = "Initial Value"; } ... }
而非
s = new String("Initial Value");
后者每次都會調(diào)用構(gòu)造器，生成新對象，性能低下且內(nèi)存開銷大，并且沒有意義，因為String對象不可改變，所以對于內(nèi)容相同的字符串，只要一個String對象來表示就可以了。也就說，多次調(diào)用上面的構(gòu)造器創(chuàng)建多個對象，他們的String類型屬性s都指向同一個對象。
上面的結(jié)論還基于這樣一個事實：對于字符串常量，如果內(nèi)容相同，Java認(rèn)為它們代表同一個String對象。而用關(guān)鍵字new調(diào)用構(gòu)造器，總是會創(chuàng)建一個新的對象，無論內(nèi)容是否相同。
至于為什么要把String類設(shè)計成不可變類，是它的用途決定的。其實不只String，很多Java標(biāo)準(zhǔn)類庫中的類都是不可變的。在開發(fā)一個系統(tǒng)的時候，我們有時候也需要設(shè)計不可變類，來傳遞一組相關(guān)的值，這也是面向?qū)ο笏枷氲捏w現(xiàn)。不可變類有一些優(yōu)點，比如因為它的對象是只讀的，所以多線程并發(fā)訪問也不會有任何問題。當(dāng)然也有一些缺點，比如每個不同的狀態(tài)都要一個對象來代表，可能會造成性能上的問題。所以Java標(biāo)準(zhǔn)類庫還提供了一個可變版本，即StringBuffer。
問題四：final關(guān)鍵字到底修飾了什么？
final使得被修飾的變量"不變"，但是由于對象型變量的本質(zhì)是“引用”，使得“不變”也有了兩種含義：引用本身的不變，和引用指向的對象不變。
引用本身的不變：
final StringBuffer a=new StringBuffer("immutable"); final StringBuffer b=new StringBuffer("not immutable"); a=b;//編譯期錯誤
引用指向的對象不變：
final StringBuffer a=new StringBuffer("immutable"); a.append(" broken!"); //編譯通過
可見，final只對引用的“值”(也即它所指向的那個對象的內(nèi)存地址)有效，它迫使引用只能指向初始指向的那個對象，改變它的指向會導(dǎo)致編譯期錯誤。至于它所指向的對象的變化，final是不負(fù)責(zé)的。這很類似==操作符：==操作符只負(fù)責(zé)引用的“值”相等，至于這個地址所指向的對象內(nèi)容是否相等，==操作符是不管的。 理解final問題有很重要的含義。許多程序漏洞都基于此----final只能保證引用永遠(yuǎn)指向固定對象，不能保證那個對象的狀態(tài)不變。在多線程的操作中,一個對象會被多個線程共享或修改，一個線程對對象無意識的修改可能會導(dǎo)致另一個使用此對象的線程崩潰。一個錯誤的解決方法就是在此對象新建的時候把它聲明為final，意圖使得它“永遠(yuǎn)不變”。其實那是徒勞的。
問題五：到底要怎么樣初始化！
本問題討論變量的初始化，所以先來看一下Java中有哪些種類的變量。
1. 類的屬性，或者叫值域
2. 方法里的局部變量
3. 方法的參數(shù)
對于第一種變量，Java虛擬機(jī)會自動進(jìn)行初始化。如果給出了初始值，則初始化為該初始值。如果沒有給出，則把它初始化為該類型變量的默認(rèn)初始值。
int類型變量默認(rèn)初始值為0
float類型變量默認(rèn)初始值為0.0f
double類型變量默認(rèn)初始值為0.0
boolean類型變量默認(rèn)初始值為false
char類型變量默認(rèn)初始值為0(ASCII碼)
long類型變量默認(rèn)初始值為0
所有對象引用類型變量默認(rèn)初始值為null，即不指向任何對象。注意數(shù)組本身也是對象，所以沒有初始化的數(shù)組引用在自動初始化后其值也是null。
對于兩種不同的類屬性，static屬性與instance屬性，初始化的時機(jī)是不同的。instance屬性在創(chuàng)建實例的時候初始化，static屬性在類加載，也就是第一次用到這個類的時候初始化，對于后來的實例的創(chuàng)建，不再次進(jìn)行初始化。這個問題會在以后的系列中進(jìn)行詳細(xì)討論。
對于第二種變量，必須明確地進(jìn)行初始化。如果再沒有初始化之前就試圖使用它，編譯器會抗議。如果初始化的語句在try塊中或if塊中，也必須要讓它在第一次使用前一定能夠得到賦值。也就是說，把初始化語句放在只有if塊的條件判斷語句中編譯器也會抗議，因為執(zhí)行的時候可能不符合if后面的判斷條件，如此一來初始化語句就不會被執(zhí)行了，這就違反了局部變量使用前必須初始化的規(guī)定。但如果在else塊中也有初始化語句，就可以通過編譯，因為無論如何，總有至少一條初始化語句會被執(zhí)行，不會發(fā)生使用前未被初始化的事情。對于try-catch也是一樣，如果只有在try塊里才有初始化語句，編譯部通過。如果在catch或finally里也有，則可以通過編譯。總之，要保證局部變量在使用之前一定被初始化了。所以，一個好的做法是在聲明他們的時候就初始化他們，如果不知道要出事化成什么值好，就用上面的默認(rèn)值吧！
其實第三種變量和第二種本質(zhì)上是一樣的，都是方法中的局部變量。只不過作為參數(shù)，肯定是被初始化過的，傳入的值就是初始值，所以不需要初始化。
問題六：instanceof是什么東東？
instanceof是Java的一個二元操作符，和==，> ， <是同一類東東。由于它是由字母組成的，所以也是Java的保留關(guān)鍵字。它的作用是測試它左邊的對象是否是它右邊的類的實例，返回boolean類型的數(shù)據(jù)。舉個例子：
String s = "I AM an Object!"; boolean isObject = s instanceof Object;
我們聲明了一個String對象引用，指向一個String對象，然后用instancof來測試它所指向的對象是否是Object類的一個實例，顯然，這是真的，所以返回true，也就是isObject的值為True。
instanceof有一些用處。比如我們寫了一個處理賬單的系統(tǒng)，其中有這樣三個類：
public class Bill {//省略細(xì)節(jié)} public class PhoneBill extends Bill {//省略細(xì)節(jié)} public class GasBill extends Bill {//省略細(xì)節(jié)}
在處理程序里有一個方法，接受一個Bill類型的對象，計算金額。假設(shè)兩種賬單計算方法不同，而傳入的Bill對象可能是兩種中的任何一種，所以要用instanceof來判斷：
public double calculate(Bill bill) { if (bill instanceof PhoneBill) { //計算電話賬單 } if (bill instanceof GasBill) { //計算燃?xì)赓~單 } ... }
這樣就可以用一個方法處理兩種子類。 然而，這種做法通常被認(rèn)為是沒有好好利用面向?qū)ο笾械亩鄳B(tài)性。其實上面的功能要求用方法重載完全可以實現(xiàn)，這是面向?qū)ο笞兂蓱?yīng)有的做法，避免回到結(jié)構(gòu)化編程模式。只要提供兩個名字和返回值都相同，接受參數(shù)類型不同的方法就可以了：
public double calculate(PhoneBill bill) { //計算電話賬單 } public double calculate(GasBill bill) { //計算燃?xì)赓~單 }
一,項目管理的模型
從傳統(tǒng)瀑布流到現(xiàn)在的基于快速迭代的各種靈活的模型和管理框架,發(fā)展非常迅速,而且也逐步被引入到各個非
軟件開發(fā)領(lǐng)域里去.新的企業(yè)也在嘗試著比較新的
敏捷開發(fā)的實踐.比如減少冗余繁雜的文檔,項目估時,站立會議等.
有些成功了,有些也失敗了.失敗的幾乎都是因為團(tuán)隊本身的成長限制了執(zhí)行的力度,或者與團(tuán)隊現(xiàn)有的管理模型有所沖突,導(dǎo)致各種不適應(yīng),最終放棄.我們自己也在這方面做著很多的整合嘗試,卻最終因為缺少比較接地氣的工具而受了不少挫.
也有不少實際的問題,比如:
1,每個人互相不太知道對方做了什么,所以到了涉及到其它人相關(guān)的模塊時,無法確定自己是否應(yīng)該繼續(xù)還是停下來.
2,我的代碼寫完了,測試總是遲遲不能得到通知.
3,如果總是在需要跟別人交互的時候打擾別人,又會讓整體的效率降低.
4,TM,PM也缺乏對項目的整體的直觀的管控.
…
這樣的類似的問題很多,各自也有各自的解決方案.我們采用了一種比較安靜的做法,整個過程不希望總是打斷別人.并且可以實時的監(jiān)控所有人的行為,比如正在做什么,哪些是做完了的,哪些是正在做的,哪些還沒有開始.是不是有任務(wù)被移交到了我這里(比如需要
測試的部分).
我自己也能一目了然的知道我所有的
工作,并且能以非常直觀的形式看到我每天的工作.管理者也要能非常清楚的看到整個團(tuán)隊的工作.
二,工具的用戶體驗和工具的實際效果.
如果沒有更合手的工具,大家往往不愿意使用.
比如畫軟件原型,有很多原型軟件如Axure,但是很多人還是更喜歡用筆在紙上畫.只有真正某個軟件足夠便利而且節(jié)約很多時間,大家才會轉(zhuǎn)到這個上面來
在一直以來的
項目管理里,也一直在調(diào)研不同的項目管理工具,最開始的Project,TFS,很多開源的軟件,網(wǎng)站等各種應(yīng)用.卻一直沒有找到一個很適合我理想中的工具,我的需求也很簡單:
1,一個自由公開的白板,
2,一個直觀查看所做任務(wù)的日歷
3,一個燃盡圖,知道項目是否延遲還是提前
4,跟其它組或者公司進(jìn)行協(xié)同.
另外一個需求是:我的個人倡導(dǎo),我希望建立一個共平自由的合作環(huán)境.
我大致說一下傳統(tǒng)的軟件的做法和我的沖突:
1,在我調(diào)研過的系統(tǒng)中部分是有白板的,但是操作上比較麻煩一些,我希望能直接拖動就能達(dá)到目的的.
2,普通認(rèn)為表格是最好的表達(dá)形式,比如所有的任務(wù)列表,bug列表,可以通過搜索,排序等方式進(jìn)行管理.每次要分析今天哪些人做了哪些事,需要一次一次的篩,一次一次的分類看.我是覺得挺累的.
3,軟件項目往往會產(chǎn)生的情況是前期松,后期緊,甚至超期,我希望知道是什么原因?qū)е铝诉@種情況的發(fā)生,當(dāng)前項目進(jìn)展是否是健康并且正常的.我只需要一個燃盡圖.而現(xiàn)在的往往做得比較復(fù)雜.
4,跟其它組或公司的配合,這個組和公司并不一定是軟件開發(fā)團(tuán)隊.比如客戶公司的營銷團(tuán)隊,設(shè)計部,開發(fā)部等.需要整體協(xié)作起來.
5,我希望所有團(tuán)隊成員都是平等的.沒有等級關(guān)系,沒有項目經(jīng)理,組長,組員的層級關(guān)系,沒有誰對誰負(fù)責(zé).因為一個項目是大家共同努力的結(jié)果,每個人都應(yīng)該對最終的結(jié)果負(fù)責(zé),每個人都應(yīng)該有自我協(xié)調(diào)能力.
我的需求不太多,但是我希望足夠好用,而且直接有效.
三,團(tuán)隊協(xié)作和軟件
從一個游戲來看團(tuán)隊協(xié)作
我以前曾經(jīng)玩過一個游戲,相信也有很多同行也玩過,游戲很簡單.在一個空房子里,擺滿很多凳子,然后由一個人被蒙上眼睛,由另一個人在旁邊指揮,什么地方應(yīng)該轉(zhuǎn)彎,什么地方應(yīng)該往前走,最后到達(dá)目的地,再一次,摘掉眼罩,由他自己決定.兩次的速度相關(guān)是非常大的,結(jié)果也是顯而易見的. 所以細(xì)節(jié)的實現(xiàn)更應(yīng)該去相信員工自己,讓員工自己來解決,而不是事無巨細(xì)的管理.
從版本管理軟件的發(fā)展來看團(tuán)隊協(xié)作
大家在工作中肯定有用過很多版本管理軟件,比如有名的有: vss,svn,git每一個都有各自鮮明的特點.
Vss: 它有這樣比較明顯的特點,整個過程基于鎖定和解鎖,如果你想修改某個文件,需要先鎖定簽出,然后修改完后再提交,提交結(jié)束后便解鎖.這時如果有其它人需要修改這些文件,需要等別人提交后才能解鎖,簽出,然后修改完成后再提交.他對版本的管理是依賴于同時只有一個人使用一個文件,當(dāng)然你可以選擇vss支持的另一種更開發(fā)的模式,但是這個已經(jīng)放棄了vss本身的優(yōu)點,利用版本管理軟件來建立起一個有序的開發(fā)的流程.以消除文件編輯的沖突. 同時帶來的負(fù)作用就是大家往往一半時間在等待其它人提交釋放鎖,而且在修改完成后,時刻要記得去提交.簽出時也小心翼翼.
Svn:從vss過渡到svn,是一個自我解放的過程.每個人可以自由奔放的修改然后提交,如果提交的文件里沒有別人修改的文件,就只管提交,如果有,更新下再提交.在實際工作中,因為大家實現(xiàn)的是不同的模塊,90%左右的沖突都由svn本身的合并功能解決了.只有極少部分需要手動合并,這要?dú)w功于svn的強(qiáng)大的合并功能還有忽略文件的配置等.它把可能的沖突轉(zhuǎn)給的團(tuán)隊線下自身來解決,事實上,人的可調(diào)控性遠(yuǎn)遠(yuǎn)好于軟件的強(qiáng)制性,很快采用這個版本管理軟件的團(tuán)隊,制定出了一套協(xié)作的方案,使每個人的工作獨(dú)立,相互沒有影響,當(dāng)然也同時促進(jìn)了團(tuán)隊的架構(gòu)水平和管理水平.
Git:從vss過渡到git,則是一種更大的自我釋放,它的歷史版本管理,不再完全依整服務(wù)器,文件提交也不再完全依賴網(wǎng)絡(luò),他可以僅僅只是先提交到本地,在本地積累到一定程度后,再一起提交到服務(wù)器.可以說一個本地副本在提交到服務(wù)器前就是一個svn,一個分支,你可以自由的回滾,可以最終提交你的決定.更多的工作交由線下自身來解決.
他們也呈現(xiàn)出了一種從封閉到開放,從軟件限制轉(zhuǎn)到人為管理轉(zhuǎn)化的過程.很可喜的是每一次轉(zhuǎn)化都極大的提高了生產(chǎn)率.也同時提高了團(tuán)隊的管理水平.
再回顧企業(yè)管理,總監(jiān)下有經(jīng)理,經(jīng)理有部門,部門有組長,組長有成員.一級一級管控.如果有個辦公室需要買一本書,可能需要給組長申請,組長再提交部門審批.一級一級.從想買到實際買到可能已經(jīng)過了一周了.一周后,可能這本書就沒必要買了.當(dāng)然在大的企業(yè)管理里,這樣沒什么問題. 但是我想如果把這種層級關(guān)系放開,由扁平化的組織結(jié)構(gòu)來管理,再制定一定的機(jī)制讓人員自我管理.這個效率會高很多.當(dāng)然可能也會非常混亂.
對于小的團(tuán)隊來說,如果所有成員扁平化,每個成員都是團(tuán)隊里重要的一員,每個人都有權(quán)力做所有的事情.我想這一定會是一個更高效的團(tuán)隊.我舉幾個例子:
1,如果團(tuán)隊成員因為有病不能來,但是項目又要求他這方面的工作完成,我可以直接拿過來他的任務(wù)然后完成它.
2,如果我有一個模塊開發(fā)完成,我可以直接拖到測試員,測試員直接接手測試.
3,測試員完成測試,反應(yīng)出一些問題,可以直接遞回我做修改.
我想權(quán)力越大,操作就會越謹(jǐn)慎,我們不應(yīng)該總是把大家綁得死死的.大家有了靈活性,反而不會去做一些實際上會逾越自己權(quán)力的事情.只在必要時去做.這個必要性,線下大家討論制定出一個協(xié)議,然后執(zhí)行即可.就好像我們制造了一把斧頭,但是我們不規(guī)定別人如何去使用他,線下我可以幫他們推薦一種比較好的揮斧方式,但是如果他喜歡,他也可以用別的方式來揮斧達(dá)到更好的效果.
還想說點什么
如果你是一個程序員,你是不是很想分享你的一個驚天的發(fā)現(xiàn),可能是一個js的游戲開發(fā)框架,可能是你寫的一個無比牛比的demo,有可能是你找出一個許久沒有解決的程序的bug.也許是你花了兩天時間最終配置起來的nodejs成套的開發(fā)環(huán)境.你是不想希望得到別人的關(guān)注,領(lǐng)導(dǎo)的關(guān)注,希望有一些成就感.那么你肯定也希望有一個能寫點什么的地方.所以也希望有一個知識庫,可以展現(xiàn)自己.
1. 引言
引言是對這份軟件產(chǎn)品
需求分析報告的概覽，是為了幫助閱讀者了解這份文檔是如何編寫的，并且應(yīng)該如何閱讀、理解和解釋這份文檔。
1.1 編寫目的
說明這份軟件產(chǎn)品需求分析報告是為哪個軟件產(chǎn)品編寫的，開發(fā)這個軟件產(chǎn)品意義、作用、以及最終要達(dá)到的意圖。通過這份軟件產(chǎn)品需求分析報告詳盡說明了該軟件產(chǎn)品的需求規(guī)格，包括修正和(或)發(fā)行版本號，從而對該軟件產(chǎn)品進(jìn)行準(zhǔn)確的定義。
如果這份軟件產(chǎn)品需求分析報告只與整個系統(tǒng)的某一部分有關(guān)系，那么只定義軟件產(chǎn)品需求分析報告中說明的那個部分或子系統(tǒng)。
1.2 項目風(fēng)險
具體說明本
軟件開發(fā)項目的全部風(fēng)險承擔(dān)者，以及各自在本階段所需要承擔(dān)的主要風(fēng)險，首要風(fēng)險承擔(dān)者包括：
● 任務(wù)提出者；
● 軟件開發(fā)者；
● 產(chǎn)品使用者。
1.3 文檔約定
描述編寫文檔時所采用的標(biāo)準(zhǔn)(如果有標(biāo)準(zhǔn)的話)，或者各種排版約定。排版約定應(yīng)該包括：
● 正文風(fēng)格；
● 提示方式；
● 重要符號；
也應(yīng)該說明高層次需求是否可以被其所有細(xì)化的需求所繼承，或者每個需求陳述是否都有其自己的優(yōu)先級。
1.4 預(yù)期讀者和閱讀建議
列舉本軟件產(chǎn)品需求分析報告所針對的各種不同的預(yù)期讀者，例如，可能包括：
● 用戶；
● 開發(fā)人員；
● 項目經(jīng)理；
● 營銷人員；
● 文檔編寫入員。
并且描述了文檔中，其余部分的內(nèi)容及其組織結(jié)構(gòu)，并且針對每一類讀者提出最適合的文檔閱讀建議。
1.5 產(chǎn)品范圍
說明該軟件產(chǎn)品及其開發(fā)目的的簡短描述，包括利益和目標(biāo)。把軟件產(chǎn)品開發(fā)與企業(yè)目標(biāo)，或者業(yè)務(wù)策略相聯(lián)系。
描述產(chǎn)品范圍時需注意，可以參考項目視圖和范圍文檔，但是不能將其內(nèi)容復(fù)制到這里。
1.6 參考文獻(xiàn)
列舉編寫軟件產(chǎn)品需求分析報告時所用到的參考文獻(xiàn)及資料，可能包括：
● 本項目的合同書；
● 上級機(jī)關(guān)有關(guān)本項目的批文；
● 本項目已經(jīng)批準(zhǔn)的計劃任務(wù)書；
● 用戶界面風(fēng)格指導(dǎo)；
● 開發(fā)本項目時所要用到的標(biāo)淮；
● 系統(tǒng)規(guī)格需求說明；
● 使用實例文檔；
● 屬于本項目的其它己發(fā)表文件；
● 本軟件產(chǎn)品需求分析報告中所引用的文件、資料；
● 相關(guān)軟件產(chǎn)品需求分析報告；
為了方便讀者查閱，所有參考資料應(yīng)該按一定順序排列。如果可能，每份資料都應(yīng)該給出：
● 標(biāo)題名稱；
● 作者或者合同簽約者；
● 文件編號或者版本號；
● 發(fā)表日期或者簽約日期；
● 出版單位或者資料來源。
2. 綜合描述
這一部分概述了正在定義的軟件產(chǎn)品的作用范圍以及該軟件產(chǎn)品所運(yùn)行的環(huán)境、使用該軟件產(chǎn)品的用戶、對該軟件產(chǎn)品己知的限制、有關(guān)該軟件產(chǎn)品的假設(shè)和依賴。
2.1 產(chǎn)品的狀況
描述了在軟件產(chǎn)品需求分析報告中所定義的軟件產(chǎn)品的背景和起源。說明了該軟件產(chǎn)品是否屬于下列情況：
● 是否是產(chǎn)品系列中的下一成員；
● 是否是成熟產(chǎn)品所改進(jìn)的下一代產(chǎn)品；
● 是否是現(xiàn)有應(yīng)用軟件的替代品(升級產(chǎn)品)；
● 是否是一個新型的、自主型的產(chǎn)品。
如果該軟件產(chǎn)品需求分析報告定義的軟件系統(tǒng)是：
● 大系統(tǒng)的一個組成部分；
● 與其它系統(tǒng)和其它機(jī)構(gòu)之間存在基本的相互關(guān)系。
那么必須說明軟件產(chǎn)品需求分析報告定義的這部分軟件是怎樣與整個大系統(tǒng)相關(guān)聯(lián)的，或者（同時）說明相互關(guān)系的存在形式，并且要定義出兩者之間的全部接口。
2.2 產(chǎn)品的功能
因為將在需求分析報告的第4部分中詳細(xì)描述軟件產(chǎn)品的功能，所以在此只需要概略地總結(jié)。僅從業(yè)務(wù)層面陳述本軟件產(chǎn)品所應(yīng)具有的主要功能，在描述功能時應(yīng)該 針對每一項需求準(zhǔn)確地描述其各項規(guī)格說明。如果存在引起誤解的可能，在陳述本軟件產(chǎn)品主要功能的作用領(lǐng)域時，也需要對應(yīng)陳述本軟件產(chǎn)品的非作用領(lǐng)域，以利 讀者理解本軟件產(chǎn)品。
為了很好地組織產(chǎn)品功能，使每個讀者都容易理解，可以采用列表的方法給出。也可以采用圖形方式，將主要的需求分組以及它們之間的聯(lián)系使用數(shù)據(jù)流程圖的頂層圖或類圖進(jìn)行表示，這種表示方法是很有用的。
參考用戶當(dāng)前管理組織構(gòu)架，了解各個機(jī)構(gòu)的主要職能，將有助于陳述軟件產(chǎn)品的主要功能。
2.3 用戶類和特性
確定有可能使用該軟件產(chǎn)品的不同用戶類，并且描述它們相關(guān)的特征。往往有一些軟件需求，只與特定的用戶類有關(guān)。描述時，應(yīng)該將該軟件產(chǎn)品的重要用戶類與非重要用戶類區(qū)分開。
用戶不一定是軟件產(chǎn)品的直接使用者，通過報表、應(yīng)用程序接口、系統(tǒng)硬件接口得到軟件產(chǎn)品的數(shù)據(jù)和服務(wù)的人、或者機(jī)構(gòu)也有他們的需求。所以，應(yīng)該將這些外部需求視為通過報表、應(yīng)用程序接口、系統(tǒng)硬件接口附加給軟件產(chǎn)品的附加用戶類。
2.4 運(yùn)行環(huán)境
描述了本軟件的運(yùn)行環(huán)境，一般包括：
● 硬件平臺；
● 操作系統(tǒng)和版本；
● 支撐環(huán)境(例如：數(shù)據(jù)庫等)和版本；
● 其它與該軟件有關(guān)的軟件組件；
● 與該軟件共存的應(yīng)用程序。
2.5 設(shè)計和實現(xiàn)上的限制
確定影響開發(fā)人員自由選擇的問題，并且說明這些問題為什么成為一種限制。可能的限制包括下列內(nèi)容：
● 必須使用的特定技術(shù)、工具、編程語言和數(shù)據(jù)庫；
● 避免使用的特定技術(shù)、工具、編程語言和數(shù)據(jù)庫；
● 要求遵循的開發(fā)規(guī)范和標(biāo)準(zhǔn)
例如，如果由客戶的公司或者第三方公司負(fù)責(zé)軟件維護(hù)，就必須定義轉(zhuǎn)包者所使用的設(shè)計符號表示和編碼標(biāo)準(zhǔn)；
● 企業(yè)策略的限制；
● 政府法規(guī)的限制；
● 工業(yè)標(biāo)準(zhǔn)的限制；
● 硬件的限制
例如，定時需求或存儲器限制；
● 數(shù)據(jù)轉(zhuǎn)換格式標(biāo)淮的限制。
2.6 假設(shè)和約束(依賴)
列舉出對軟件產(chǎn)品需求分析報告中，影響需求陳述的假設(shè)因素(與己知因素相對立)。如果這些假設(shè)因素不正確、不一致或者被修改，就會使軟件產(chǎn)品開發(fā)項目受到影響。這些假設(shè)的因素可能包括：
● 計劃使用的商業(yè)組件，或者其它軟件中的某個部件；
● 假定產(chǎn)品中某個用戶界面將符合一個特殊的設(shè)計約定；
● 有關(guān)本軟件用戶的若干假定(例如：假定用戶會熟練使用SQL語言。)；
● 有關(guān)本軟件開發(fā)工作的若干假定(例如：用戶承諾的優(yōu)惠、方便、上級部門給予的特殊政策和支持等。)；
● 有關(guān)本軟件運(yùn)行環(huán)境的一些問題；
此外，確定本軟件開發(fā)項目對外部約束因素所存在的依賴。有關(guān)的約束可能包括：
● 工期約束；
● 經(jīng)費(fèi)約束；
● 人員約束；
● 設(shè)備約束；
● 地理位置約束；
● 其它有關(guān)項目約束；
3. 外部接口需求
通過本節(jié)描述可以確定，保證軟件產(chǎn)品能和外部組件正確連接的需求。關(guān)聯(lián)圖僅能表示高層抽象的外部接口，必須對接口數(shù)據(jù)和外部組件進(jìn)行詳細(xì)描述，并且寫入數(shù) 據(jù)定義中。如果產(chǎn)品的不同部分有不同的外部接口，那么應(yīng)該把這些外部接口的全部詳細(xì)需求并入到這一部分實例中。
注意：必須將附加用戶類的特征與外部接口需求加以區(qū)分，附加用戶類的特征描述的是通過接口取得軟件產(chǎn)品的數(shù)據(jù)和服務(wù)的人的需求；而外部接口需求描述的是接口本身的需求。
3.1 用戶界面
陳述需要使用在用戶界面上的軟件組件，描述每一個用戶界面的邏輯特征。必須注意，這里需要描述的是用戶界面的邏輯特征，而不是用戶界面。以下是可能包括的一些特征：
● 將要采用的圖形用戶界面(GUl)標(biāo)準(zhǔn)或者產(chǎn)品系列的風(fēng)格；
● 有關(guān)屏幕布局或者解決方案的限制；
● 將要使用在每一個屏幕(圖形用戶界面)上的軟件組件，可能包括：
選單；
標(biāo)準(zhǔn)按鈕；
導(dǎo)航鏈接；
各種功能組件；
消息欄；
● 快捷鍵；
● 各種顯示格式的規(guī)定，可能包括：
不同情況下文字的對齊方式；
不同情況下數(shù)字的表現(xiàn)格式與對齊方式；
日期的表現(xiàn)方法與格式；
計時方法與時間格式；
等等。
● 錯誤信息顯示標(biāo)準(zhǔn)；
對于用戶界面的細(xì)節(jié)，例如：一個特定對話框的布局，應(yīng)該寫入具體的用戶界面設(shè)計說明中，而不能寫入軟件需求規(guī)格說明中。
如果采用現(xiàn)成的、合適的用戶界面設(shè)計規(guī)范(標(biāo)準(zhǔn))，或者另文描述，可以在這里直接說明，并且將其加入?yún)⒖嘉墨I(xiàn)。
3.2 硬件接口
描述待開發(fā)的軟件產(chǎn)品與系統(tǒng)硬件接口的特征，若有多個硬件接口，則必須全都描述。接口特征的描述內(nèi)容可能包括：
● 支持的硬件類型；
● 軟、硬件之間交流的數(shù)據(jù)；
● 控制信息的性質(zhì)；
● 使用的通訊協(xié)議；
3.3 軟件接口
描述該軟件產(chǎn)品與其它外部組件的連接，這些外部組件必須明確它們的名稱和版本號以資識別，可能的外部組件包括：
● 操作系統(tǒng)；
● 數(shù)據(jù)庫；
● 工具；
● 函數(shù)庫；
● 集成的商業(yè)組件
說明：這里所說的“集成的商業(yè)組件”，是指與系統(tǒng)集成的商業(yè)組件，而不是與軟件產(chǎn)品集成的商業(yè)組件。例如：中間件、消息服務(wù)，等等。
描述并且明確軟件產(chǎn)品與軟件組件之間交換數(shù)據(jù)或者消息的目的。描述所需要的服務(wù)，以及與內(nèi)部組件通訊的性質(zhì)。確定軟件產(chǎn)品將與組件之間共享的數(shù)據(jù)。如果必 須使用一種特殊的方法來實現(xiàn)數(shù)據(jù)共享機(jī)制，例如：在多用戶系統(tǒng)中的一個全局?jǐn)?shù)據(jù)區(qū)，那么就必須把它定義為一種實現(xiàn)上的限制。
3.4 通訊接口
描述與軟件產(chǎn)品所使用的通訊功能相關(guān)的需求，包括：
● 電子郵件；
● WEB瀏覽器；
● 網(wǎng)絡(luò)通訊標(biāo)準(zhǔn)或者協(xié)議；
● 數(shù)據(jù)交互用電子表格；
必須定義相關(guān)的：
● 消息格式；
● 通訊安全或加密問題；
● 數(shù)據(jù)傳輸速率；
● 同步和異步通訊機(jī)制；
4. 系統(tǒng)功能需求
需要進(jìn)行詳細(xì)的需求記錄，詳細(xì)列出與該系統(tǒng)功能相關(guān)的詳細(xì)功能需求，并且，唯一地標(biāo)識每一項需求。這是必須提交給用戶的軟件功能，使得用戶可以使用所提供 的功能執(zhí)行服務(wù)或者使用所指定的使用實例執(zhí)行任務(wù)。描述軟件產(chǎn)品如何響應(yīng)己知的出錯條件、非法輸入、非法動作。
如果每一項功能需求都能用一項，也只需要用一項測試用例就能進(jìn)行驗證，那么就可以認(rèn)為功能需求已經(jīng)適當(dāng)?shù)剡M(jìn)行描述了。如果某項功能需求找不到合適的測試用例，或者必須使用多項測試用例才能驗證，那么該項功能需求的描述必然存在某些問題。
功能需求是根據(jù)系統(tǒng)功能，即軟件產(chǎn)品所提供的主要服務(wù)來組織的。可以通過使用實例、運(yùn)行模式、用戶類、對象類或者功能等級來組織這部分內(nèi)容，也可以便用這些元素的組合。總而言之，必須選擇一種是讀者容易理解預(yù)期產(chǎn)品的組織方案。
用簡短的語句說明功能的名稱，例如：“4.1系統(tǒng)參數(shù)管理”。按照服務(wù)組織的順序，逐條闡述系統(tǒng)功能。無論說明的是何種功能，都應(yīng)該針對該系統(tǒng)功能重復(fù)敘述4.1~ 4.3這三個部分。
可以通過各種方式來組織這一部分內(nèi)容，例如采用：使用實例、運(yùn)行模式、用戶類、對象類、功能等級等，也可以采用它們的組合。其最終目的是，讓讀者容易理解 即將開發(fā)的軟件產(chǎn)品。一般來說，每個使用實例都對應(yīng)一個系統(tǒng)功能，因而按照使用實例來組織內(nèi)容比較容易讓用戶理解。
對應(yīng)一些被共享的獨(dú)立使用實例，可以定義一些公用系統(tǒng)功能。
必須特別注意的是，在2.2節(jié)“產(chǎn)品的功能”中描述的全部需求，以及它們的規(guī)格說明；必須在某個系統(tǒng)功能描述中有所反映，而且不應(yīng)重復(fù)。
4.1 說明和優(yōu)先級
對該系統(tǒng)功能進(jìn)行簡短的說明，并且指出該系統(tǒng)功能的優(yōu)先級是：高、中、還是低。需要的話，還可以包括對特定優(yōu)先級部分的評價，例如：利益、損失、費(fèi)用和風(fēng)險，其相對優(yōu)先等級可以從1(低)到9(高)。
4.2 激勵／響應(yīng)序列
列出輸入激勵(用戶動作、來自外部設(shè)備的信號或者其它觸發(fā))并且定義針對這——功能行為的系統(tǒng)響應(yīng)序列，這些序列將與使用實例中相關(guān)的對話元素相對應(yīng)。
描述激勵／響應(yīng)序列時，不僅需要描述基本過程，而且應(yīng)該描述可選(擴(kuò)充)過程，包括例外(引起任務(wù)不能順序完成的情況稱為例外)。疏忽了可選過程，有可能影響軟件產(chǎn)品的功能；如果遺漏例外過程，則有可能會引發(fā)系統(tǒng)崩潰。
如果采用流程圖來描述激勵／響應(yīng)序列，比較容易讓用戶理解。
4.3 輸入／輸出數(shù)據(jù)
列出輸入數(shù)據(jù)(用戶輸入、來自外部接口的輸入或者其它輸入)并且定義針對這些輸入數(shù)據(jù)的處理(計算)方法，以及相應(yīng)地輸出數(shù)據(jù)，描述對應(yīng)區(qū)別：輸入數(shù)據(jù)和輸出數(shù)據(jù)。
當(dāng)有大量數(shù)據(jù)需要描述時，也可以分類描述數(shù)據(jù)，并且注明各項數(shù)據(jù)的輸入、輸出屬性。
對于每一項數(shù)據(jù)，均需要描述：
● 數(shù)據(jù)名稱；
● 實際含義；
● 數(shù)據(jù)類型；
● 數(shù)據(jù)格式；
● 數(shù)據(jù)約束；
對于復(fù)雜的處理方法，僅僅給出算法原理是不夠的，必須描述詳細(xì)的計算過程，并且列出每一步具體使用的實際算式；如果計算過程中涉及查表、判斷、迭代等處理方法，應(yīng)該給出處理依據(jù)和相關(guān)數(shù)據(jù)。如果計算方法很簡單，也可以將其從略，不加描述。
5. 其它非功能需求
在這里列舉出所有非功能需求，主要包括可靠性、安全性、可維護(hù)性、可擴(kuò)展性、可測試性等。
5.1 性能需求
闡述不同應(yīng)用領(lǐng)域?qū)浖a(chǎn)品性能的需求，并且說明提出需求的原理或者依據(jù)，以幫助開發(fā)人員做出合理的設(shè)計選擇。盡可能詳細(xì)地描述性能需求，如果需要，可以針對每個功能需求或者特征分別陳述其性能需求。在這里確定：
● 相互合作的用戶數(shù)量；
● 系統(tǒng)支持的并發(fā)操作數(shù)量；
● 響應(yīng)時間；
● 與實時系統(tǒng)的時間關(guān)系：
● 容量需求
存儲器；
磁盤空間；
數(shù)據(jù)庫中表的最大行數(shù)。
5.2 安全措施需求
詳盡陳述與軟件產(chǎn)品使用過程中可能發(fā)生的損失、破壞、危害相關(guān)的需求。定義必須采取的安全保護(hù)或動作，以及必須預(yù)防的潛在危險動作。明確軟件產(chǎn)品必須遵從的安全標(biāo)準(zhǔn)、策略、或規(guī)則。
5.3 安全性需求
詳盡陳述與系統(tǒng)安全性、完整性問題相關(guān)的需求，或者與個人隱私問題相關(guān)的需求。這些問題將會影響到軟件產(chǎn)品的使用，和軟件產(chǎn)品所創(chuàng)建或者使用的數(shù)據(jù)的保 護(hù)。定義用戶身份認(rèn)證，或備授權(quán)需求。明確軟件產(chǎn)品必須滿足的安全性或者保密性策略。也可以通過稱為完整性的質(zhì)量屬性來闡述這些需求。一個典型的軟件系統(tǒng) 安全需求范例如下：“每個用戶在第一次登錄后，必須更改他的系統(tǒng)預(yù)置登錄密碼，系統(tǒng)預(yù)置的登錄密碼不能重用。”
5.4 軟件質(zhì)量屬性
詳盡陳述對客戶和開發(fā)人員至關(guān)重要的在軟件產(chǎn)品其它方面表現(xiàn)出來的質(zhì)量功能。這些功能必須是確定的、定量的、在需要時是可以驗證的。至少也應(yīng)該指明不同屬性的相對側(cè)重點，例如：易用性優(yōu)于易學(xué)性，或者可移植性優(yōu)于有效性。
5.5 業(yè)務(wù)規(guī)則
列舉出有關(guān)軟件產(chǎn)品的所有操作規(guī)則，例如：那些人在特定環(huán)境下可以進(jìn)行何種操作。這些本身不是功能需求，但是他們可以暗示某些功能需求執(zhí)行這些規(guī)則。一個 業(yè)務(wù)規(guī)則的范例如下：“進(jìn)行達(dá)到或者超過10，000，00元人民幣的儲蓄業(yè)務(wù)時，必須通過附加的管理員認(rèn)證。”
列舉業(yè)務(wù)規(guī)則時，可以根據(jù)規(guī)則的數(shù)量，選取合適的編目方式。
5.6 用戶文檔
列舉出將與軟件產(chǎn)品一同交付的用戶文檔，并且明確所有己知用戶文檔的交付格式或標(biāo)準(zhǔn)，例如：
● 安裝指南
紙質(zhì)文檔，16開本；
● 用戶手冊
紙質(zhì)文檔，16開本；
● 在線幫助
● 電子文檔，與軟件產(chǎn)品一同分發(fā)、配置；
● 使用教程電子文檔，與軟件產(chǎn)品一同分發(fā)、配置。
6. 詞匯表
列出本文件中用到的專業(yè)術(shù)語的定義，以及有關(guān)縮寫的定義(如有可能，列出相關(guān)的外文原詞)。為了便于非軟件專業(yè)或者非計算機(jī)專業(yè)人士閱讀軟件產(chǎn)品需求分析 報告，要求使用非軟件專業(yè)或者非計算機(jī)專業(yè)的術(shù)語描述軟件需求。所以這里所指的專業(yè)術(shù)語，是指業(yè)務(wù)層面上的專業(yè)術(shù)語，而不是軟件專業(yè)或者計算機(jī)專業(yè)的術(shù) 語。但是，對于無法回避的軟件專業(yè)或者計算機(jī)專業(yè)術(shù)語，也應(yīng)該列入詞匯表并且加以準(zhǔn)確定義。
7. 數(shù)據(jù)定義
數(shù)據(jù)定義是一個定義了應(yīng)用程序中使用的所有數(shù)據(jù)元素和結(jié)構(gòu)的共享文檔，其中對每個數(shù)據(jù)元素和結(jié)構(gòu)都準(zhǔn)確描述：含義、類型、數(shù)據(jù)大小、格式、計量單位、精度 以及取值范圍。數(shù)據(jù)定義的維護(hù)獨(dú)立于軟件需求規(guī)格說明，并且在軟件產(chǎn)品開發(fā)和維護(hù)的任何階段，均向風(fēng)險承擔(dān)者開放。
如果為軟件開發(fā)項目創(chuàng)建一個獨(dú)立的數(shù)據(jù)定義，而不是為每一項特性描述有關(guān)的數(shù)據(jù)項，有利于避免冗余和不一致性。但是卻不利于多人協(xié)同編寫需求分析報告，容 易遺漏數(shù)據(jù)，也不方便閱讀。因此還是建議為每個特性描述有關(guān)的數(shù)據(jù)項，匯總數(shù)據(jù)項創(chuàng)建數(shù)據(jù)定義，再根據(jù)數(shù)據(jù)定義復(fù)核全部數(shù)據(jù)，使得它們的名稱和含義完全一 致。必須注意的是，為了避免二義性，在匯總數(shù)據(jù)項時應(yīng)該根據(jù)數(shù)據(jù)項所代表的實際意義匯總，而不是根據(jù)數(shù)據(jù)項的名稱匯總。
在數(shù)據(jù)定義中，每個數(shù)據(jù)項除了有一個中文名稱外，還應(yīng)該為它取一個簡短的英文名稱，該英文名稱應(yīng)該符合命名規(guī)范，因為在軟件開發(fā)時將沿用該英文名稱。可以使用等號表示數(shù)據(jù)項，名稱寫在左邊，定義寫在右邊。常見數(shù)據(jù)項的描述方式如下：
● 原數(shù)據(jù)元素
一個原數(shù)據(jù)元素是不可分解的，可以將一個數(shù)量值賦給它。定義原數(shù)據(jù)元素必須確定其
含義、類型、數(shù)據(jù)大小、格式、計量單位、精度以及取值范圍。采用以星號為界的一行
注釋文本，描述原數(shù)據(jù)元素的定義。
● 選擇項
選擇項是一種只可以取有限離散值的特殊原數(shù)據(jù)元素，描述時一一枚舉這些值，并用方
括號括起來寫在原數(shù)據(jù)元素的定義前。在兩項離散值之間，使用管道符分隔。
● 組合項
組合項是一個數(shù)據(jù)結(jié)構(gòu)或者記錄，其中包含了多個數(shù)據(jù)項。這些數(shù)據(jù)項可以是原數(shù)據(jù)元
素，也可以是組合數(shù)據(jù)項，各數(shù)據(jù)項之間用加號連接。其中每個數(shù)據(jù)項都必須是數(shù)據(jù)定
義中定義過的，結(jié)構(gòu)中也可以包括其它結(jié)構(gòu)，但是絕對不允許遞歸。如果數(shù)據(jù)結(jié)構(gòu)中有
可選項，使用圓括號把該項括起來。
● 重復(fù)項
重復(fù)項是組合項的一種特例，其中有一項將有多個實例出現(xiàn)在數(shù)據(jù)結(jié)構(gòu)中，使用花括號
把該項括起來。如果知道該項可能允許的范圍，就按“最小值：最大值”的形式寫在花
括號前。
8. 分析模型
這是一個可選部分，包括或涉及到相關(guān)的分析模型，例如：
● 數(shù)據(jù)流程圖；
● 類圖；
● 狀態(tài)轉(zhuǎn)換圖；
● 實體-關(guān)系圖。
9. 待定問題列表
編輯一張在軟件產(chǎn)品需求分析報告中待確定問題時的列表，把每一個表項都編上號，以便跟蹤調(diào)查。
生活中有這么一種現(xiàn)象：如果你關(guān)注某些東西，它就會經(jīng)常出現(xiàn)在你眼前，例如一個不出名的歌手的名字，一種動物的卡通形象，某個非常專業(yè)的術(shù)語，等等等等。這種現(xiàn)象也叫做“孕婦效應(yīng)”。還有類似的一種效應(yīng)叫做“視網(wǎng)膜效應(yīng)”，它講的是：你有什么東西或者特質(zhì)你就特別容易在別處發(fā)現(xiàn)你有的這類東西和特質(zhì)。干了多年
測試的我就會經(jīng)常發(fā)現(xiàn)日常使用的系統(tǒng)中有很多的
bug，而我老婆就發(fā)現(xiàn)不了。今天要說的事兒是“重現(xiàn)難以重現(xiàn)的bug”，這件事兒在本周共遇見了4次：第一次是微博上有一篇《程序員，你調(diào)試過的最難的 Bug 是？》（后面會附上）；第二次是一個同事跟我抱怨，好幾個bug難以重現(xiàn)特心煩，并問我怎么處理比較好；第三次是本周上線的產(chǎn)品出現(xiàn)了一個當(dāng)時難以重現(xiàn)的bug，我們對它做了初步的分析；第四次是翻看史亮寫的書《
軟件測試實戰(zhàn)》，偶爾翻了翻，竟然看到一小節(jié)在寫“處理難以處理的缺陷”。這時候，腦子里很多東西匯集到了一起，我想還是記錄一下吧。下面是正文：
也許測試人員（尤其是對新手來說）在
工作過程中最不愿遇到的一件事情就是：在測試過程中發(fā)現(xiàn)了一個問題，覺得是bug，再試的時候又正常了。碰到這樣的事情，職業(yè)素養(yǎng)和測試人員長期養(yǎng)成的死磕的習(xí)性會讓她們覺得不能放過這個bug，但是重現(xiàn)這樣的bug有時候需要花費(fèi)大量的時間，有的時候還有一些盲目性（因為
黑盒測試的緣故，很多內(nèi)部狀態(tài)是不可見的，因此無法獲取有效的信息來做跟蹤），效率較為低下。在實際工作中，時間和進(jìn)度擺在那里，在經(jīng)歷了多次痛苦的失敗嘗試之后，測試人員的處理方法一般會有如下幾種：1.向開發(fā)人員尋求幫助來重現(xiàn)bug；2.當(dāng)做一個issue報給開發(fā)人員。可是這樣的做法存在如下問題：
1.開發(fā)人員責(zé)任心不夠強(qiáng)，不愿意花太多精力去求證這件事情，常見的回復(fù)就是：在我這兒沒事兒啊，我也重現(xiàn)不了，bug關(guān)了吧。結(jié)果隨后在生產(chǎn)系統(tǒng)上，bug又開始sui隨機(jī)出現(xiàn)了。
2.就跟測試人員不擅長編碼和調(diào)試一樣，開發(fā)人員并不擅長找出bug。經(jīng)過一番嘗試以后，他們也找不出什么問題來，常見的回復(fù)同第一條是一樣的。bug上線后又出現(xiàn)的宿命也是一樣的。
這時候，真正的問題來了：如何捕捉難以重現(xiàn)的bug？這件事兒對于測試人員來說就這么難么？
答案并不那么樂觀，重現(xiàn)“難以”重現(xiàn)的bug本來就是一件“難以”完成的事情。但“難以”并不是不可能，通過一系列的測試、分析方法，我們是能夠抽絲剝繭把絕大部分隱藏的很深的bug揪出來的，當(dāng)然有的時候你要考慮投入產(chǎn)出比，但投入產(chǎn)出比不是本篇要考慮的，本篇只講一些我積累的經(jīng)驗。
為什么不能重現(xiàn)bug？
最大的原因就是：測試人員對被測物的了解還不夠深入。
我曾經(jīng)做過一段很長時間的收集和統(tǒng)計，那些被稱作過“難以重現(xiàn)”的bug最后都可以分為如下幾類：
1.環(huán)境的變更造成了bug難以重現(xiàn)，這里的環(huán)境包括了：基礎(chǔ)軟硬件環(huán)境（
操作系統(tǒng)、網(wǎng)絡(luò)、存儲、中間件、容器等等），被測物自身發(fā)生了某些變更。環(huán)境的變更一般是由于多人共用環(huán)境造成的，也有少量情況下是系統(tǒng)內(nèi)部或者時間觸發(fā)的變更（這類bug非常難重現(xiàn)）。
2.沒有找到真正引發(fā)bug的操作。這些操作往往是一些不怎么顯而易見的操作，測試人員在不經(jīng)意間完成，而又忽略了這一操作，以致難于重現(xiàn)bug。
3.沒有找到真正會引發(fā)bug的操作序列。很多bug的重現(xiàn)需要滿足多個條件。在滿足多個條件的狀態(tài)下，你做了對應(yīng)的操作，bug才會被觸發(fā)。
4.bug必須使用特殊的數(shù)據(jù)才會出現(xiàn)，測試人員沒有意識到她使用的數(shù)據(jù)的特殊性。一種比較難搞的情況是：同一組輸入，在不同情況下（不是不同的業(yè)務(wù)情況）輸入會被轉(zhuǎn)化成不同的數(shù)據(jù)。我曾經(jīng)見到過這么個例子，程序員用系統(tǒng)當(dāng)前時間作為隨機(jī)數(shù)的種子來生成id，但是id設(shè)置的比較短，一個存儲的操作使用這個id，在一些情況下，發(fā)生了沖突，當(dāng)時做
功能測試這種小概率事件耗費(fèi)了測試人員大量時間也沒有穩(wěn)定重現(xiàn)，還是在
性能測試的階段測試了出來。
5.測試人員由于錯誤操作，出現(xiàn)了誤報（這很常見）。比如，記得自己執(zhí)行了step3,其實沒有，或者沒有正確執(zhí)行step卻覺得正確執(zhí)行了。
怎樣對付這樣的bug呢？
我喜歡James Bach 說的那句話：測試就像CSI。CSI是Criminal Scene Investigation 的縮寫，也是我非常喜歡的美國系列劇。
從我來看CSI的精髓在于：仔細(xì)觀察，詳細(xì)記錄，科學(xué)分析，嚴(yán)密推理，有序求證，大膽假設(shè)，持續(xù)不懈，團(tuán)隊協(xié)作和一點兒運(yùn)氣。找bug其實和CSI探員做犯罪現(xiàn)場調(diào)查沒什么太大區(qū)別。得知道，你工作的重要性一點兒不亞于CSI探員。
仔細(xì)觀察：第一件事情就是要觀察，觀察你所做的一切操作和一切相關(guān)的系統(tǒng)反饋。在一開始，觀察的重要性要遠(yuǎn)遠(yuǎn)大于思考，通過觀察你獲得蛛絲馬跡，這些蛛絲馬跡是你進(jìn)行思考和假設(shè)的關(guān)鍵輸入。例如，我在一次測試的過程中，發(fā)現(xiàn)做某種操作的時候會相當(dāng)慢，極少數(shù)情況下還報錯過一兩次，當(dāng)詢問了開發(fā)人員后得知這個操作的后臺實現(xiàn)步驟是：先查看數(shù)據(jù)是否在緩存中，如果不在，則從遠(yuǎn)端服務(wù)器請求數(shù)據(jù)。我抓住少數(shù)情況下會報錯的這一現(xiàn)象，仔細(xì)觀察它的出錯信息后猜測報錯并不是因為網(wǎng)絡(luò)連接不穩(wěn)定引起的，而是由于遠(yuǎn)端服務(wù)接口實現(xiàn)有問題引起的，后來重新設(shè)計了
測試用例，果然找到了問題所在。如果不仔細(xì)觀察出錯信息，就會聽信開發(fā)人員認(rèn)為這是網(wǎng)絡(luò)不穩(wěn)定引發(fā)的正常issue而錯過這個bug。
詳細(xì)記錄：詳細(xì)記錄你的操作步驟及返回結(jié)果非常有助于回朔問題，也有助于后續(xù)分析。準(zhǔn)備一個word文檔，和截圖工具有時候非常必要。另外，在觀察的時候，你不僅要注意被測物的最終返回，還需要觀察過程中的一些中間狀態(tài)，往往這些中間狀態(tài)提供的信息才是解開問題的關(guān)鍵。這些中間狀態(tài)一般會被記錄在log文件中，因此知道你的被測物是如何記log的，log被記錄在哪里非常重要。log給了你另外一個看系統(tǒng)的角度。log是有級別的，如果級別可以動態(tài)調(diào)整，在找比較難找的bug時，可以將log記錄的級別調(diào)至最低（DEBUG級）讓它們記錄更多內(nèi)容。利用系統(tǒng)的錯誤轉(zhuǎn)儲文件（比如linux的core dump文件，windows下也有相應(yīng)的記錄轉(zhuǎn)儲文件的方式）分析也是個不錯的辦法（需要較高技術(shù)能力），但一般建議測試人員把這些轉(zhuǎn)儲文件交給更專業(yè)的開發(fā)人員來分析。在我短暫的C++開發(fā)歲月中，有使用過GDB閱讀轉(zhuǎn)儲文件的經(jīng)歷，那絕對不是愉快的回憶。你瞧，測試人員的主要工作是找出可重現(xiàn)的bug，并不是定位它們，不是么？
除了log，如果能有監(jiān)控信息，也要查看他們。比如系統(tǒng)提供的監(jiān)控平臺，監(jiān)控日志；應(yīng)用自己的監(jiān)控平臺、監(jiān)控日志（如果有的話）；采用一些外部技術(shù)手段截取一些中間狀態(tài)信息，如使用sniffer抓取通訊包，使用Fiddler截獲HTTP報文內(nèi)容；給運(yùn)行程序插樁來查看內(nèi)存，堆棧，線程，函數(shù)被調(diào)用情況等情況，如Jprofile，gpertool等等。
科學(xué)分析：對于黑盒測試人員來說，科學(xué)分析意味著你需要有一定的分析策略。我們需要采取一些形式化的方法來完成我們的分析。基于我的統(tǒng)計，缺陷難以重現(xiàn)有很大一部分原因是因為“沒有找到真正引發(fā)bug的操作序列“。測試人員不可能像開發(fā)人員那樣去跟入到代碼內(nèi)部，設(shè)置斷點調(diào)試程序，他們主要的測試方式是直接來操縱被測物，并從外部觀察被測物狀態(tài)的改變。顯而易見，“狀態(tài)轉(zhuǎn)換圖分析法”是測試人員對付“難以重現(xiàn)bug”的最強(qiáng)有力武器之一。狀態(tài)轉(zhuǎn)化圖能夠幫助測試人員很好的選擇操作路徑，并且知道這么做有什么意義。“狀態(tài)圖轉(zhuǎn)化法”絕對是測試人員值得花時間學(xué)習(xí)和研究的一種方法，你可以走的很深，也可以研究得很遠(yuǎn)（可以從MBT的方向進(jìn)行拓展），限于篇幅，這里就不展開了。在這里推薦《探索吧！深入理解探索式軟件測試》這本書，它的第八章對“狀態(tài)轉(zhuǎn)換”做了非常實用的描述。
上文分析的讓bug難于重現(xiàn)的另一種原因是沒有找到“真正引發(fā)bug的特殊數(shù)據(jù)”。我的常用做法是這樣的：1.畫出系統(tǒng)交互圖（要真正弄清系統(tǒng)的邊界，這很重要），并識別出每種交互會有什么樣的輸入、輸出數(shù)據(jù)和中間數(shù)據(jù)，識別出這些數(shù)據(jù)的規(guī)約和格式，這樣你就不會對數(shù)據(jù)有遺漏。2.考慮數(shù)據(jù)的等價類、邊界值，對這些輸入進(jìn)行組合，分析數(shù)據(jù)之間是否有耦合關(guān)系，如果有耦合關(guān)系，弄明白關(guān)系是什么，設(shè)計違背這些關(guān)系的用例，最后采用組合測試工具初步生成測試集，再人工選取最可能出問題的數(shù)據(jù)集（直覺有時候非常管用）。
嚴(yán)密推理：天馬行空對測試人員很重要，但是當(dāng)你試圖重現(xiàn)一個bug的時候，這并不是一個非常好的方法。抓住了蛛絲馬跡，你就要推理是為什么產(chǎn)生了這種蛛絲馬跡。限于工作性質(zhì)，測試人員更多的會從：業(yè)務(wù)完整性、數(shù)據(jù)完整性、業(yè)務(wù)正確性、數(shù)據(jù)正確性等方面考慮問題。但是，如果測試人員對被測物的IT架構(gòu)有比較深入了解的話，推理的范圍會擴(kuò)大到技術(shù)實現(xiàn)層面，如：多線程可能引發(fā)的問題，網(wǎng)絡(luò)引發(fā)的問題，excepiton處理不當(dāng)引發(fā)的問題，全局事務(wù)設(shè)計不當(dāng)引發(fā)的問題，內(nèi)存泄漏引發(fā)的問題，數(shù)據(jù)庫表設(shè)計不合規(guī)引發(fā)的問題等等等等，這些會讓你的分析推理能力如虎添翼。當(dāng)然，如果限于條件，測試人員不具備這類能力，則應(yīng)該在適當(dāng)?shù)臅r候請求開發(fā)人員協(xié)助。
有序求證：這里只有一點需要注意。那就是，在求證的過程中不要打散彈槍，按照你的推理一步一步的來，一個個推理的來驗證，一次只引入一處修改。這樣才能讓你的捕蟲網(wǎng)編制的足夠細(xì)密。
大膽假設(shè)：有的時候，看似八竿子打不著的東西竟然存在著千絲萬縷的聯(lián)系，而你獲取信息的過程總是一個由少及多的過程，一開始這些聯(lián)系是無法被識別出來的。通過推理，逐步驗證，你慢慢的識別出了大部分內(nèi)在聯(lián)系。但有時候這種逐步推進(jìn)的工作也會有局限性，工作如果出現(xiàn)了瓶頸（你試遍了你所有的假設(shè)，都沒有重現(xiàn)bug），這時候就需要發(fā)揮一點兒想象力了，天馬行空這時候從一定程度上又變得有用起來，當(dāng)然天馬行空也不是無厘頭，還得靠我們所謂的“靈光一閃”，這號稱是潛意識在幫助你。CSI的劇情中不也總是出現(xiàn)這種柳暗花明的橋段么？
堅持不懈：話不多說，有的時候你差的就是那么一點兒點兒耐心。
團(tuán)隊協(xié)作：很多情況下，重現(xiàn)bug不是一個人能搞定的。我們需要測試環(huán)境ready，測試數(shù)據(jù)ready，各種監(jiān)控、分析工具ready，各種不同的視角開拓思路、加深對被測試物的認(rèn)識。這是team work！！！獨(dú)行俠有時候很管用，但是終究有極限。這就是為什么CSI是一票人在做而不是一兩個人在做。
一點兒運(yùn)氣：說實在的，有的時候重現(xiàn)bug就是靠運(yùn)氣，你不得不承認(rèn)這一點。事實上很多美好的事情發(fā)生都得依靠運(yùn)氣，比如中彩票。要記住的一點是，運(yùn)氣是建立在你不懈努力的基礎(chǔ)上的。如果你一張彩票不買，你肯定什么也中不了。但如果你堅持買上幾年，中個五塊十塊甚至二百也不是夢。
Let it go：全試過了，連運(yùn)氣都沒有。你只能放手，回到最上面我說的那兩條了：找開發(fā)來幫忙，或者給開發(fā)報issue。btw，即使不能重現(xiàn)bug，也應(yīng)該給開發(fā)人員提供更多信息：如log、dump文件、監(jiān)控記錄、屏幕截圖等。做一個負(fù)責(zé)人的測試人員，把煩惱真實的留給下家，這很重要：）
概念與思辨深度
一個行業(yè)的發(fā)展似乎總伴隨著更多的概念被塑造出來。拿
測試來說，我們有
單元測試、集成測試、
系統(tǒng)測試、回歸測試、冒煙測試，等等。我們緣何塑造如此多的概念來“為難”自己呢？答案可以用我從@李智勇SZ老師那學(xué)到的“概念越純粹表示思辨深度越深”這句話加以解釋，而這一切又為了提高同行間的溝通效率。需要特別指出的是，多個相似但不同的概念想表達(dá)的是各自的不同之處，而非共同之處。為此，如果人家在討論單元測試時，你冒出一句“寫好程序，編譯完，跑一跑，看看寫得對不對，這就是最簡單的UT啊！”就不大合適，因為這說明你根本沒有理解單元測試的概念（可以讀一下我寫的《明晰單元測試》一文）。如果你再加上一句“靠，都是測試，分那么清干什么？”，那還表明你邏輯不清。
我近期所寫的《對
軟件測試團(tuán)隊“核心價值”的思考》一文引發(fā)了一些討論。比如，@朱少民老師（后面簡稱朱老師）指出：“‘（文中所述測試）幫助開發(fā)人員提高其開發(fā)質(zhì)量和效率’是軟件測試團(tuán)隊的價值取向之一，但還不是軟件測試團(tuán)隊的主要核心價值“。于是我向朱老師請教他所理解的測試核心價值，得到的回復(fù)是“軟件測試最核心的價值還是能夠快速發(fā)現(xiàn)問題以提供產(chǎn)品的質(zhì)量反饋，有能力提供準(zhǔn)確的、客觀的、完整的質(zhì)量評估，并通過缺陷分析、用戶行為分析等，確定缺陷模式和開發(fā)人員不良行為、習(xí)慣等，幫助開發(fā)人員預(yù)防缺陷（從設(shè)計到編程、單元測試，不僅僅是設(shè)計）”。
之后我的回復(fù)是，“我們應(yīng)將QA（Quality Assurance，質(zhì)量保證）與測試區(qū)分開來”，因為我認(rèn)為朱老師將測試的范圍定義得太大了。但朱老師卻幫我指出“我這是地地道道的測試，看來你對QA理解不夠。QA的主要對象是（包括開發(fā)、測試）流程，QA人員評審、審計和改進(jìn)流程，以保證質(zhì)量。測試的對象是產(chǎn)品，包括階段性半成品。從嚴(yán)格意義看，測試就是對軟件產(chǎn)品的質(zhì)量評估”。
類似與QA和測試相關(guān)的討論發(fā)生在@左耳朵耗子老師寫了《我們需要專職的QA嗎？》一文之后。這些討論又為我們帶來了@程序員鄒欣老師寫的《測試QA的角色和分工》，以及@段念-段文韜老師寫的《對《我們需要專職QA嗎？》的回應(yīng)》。在本文我想順便談一談以前讀這些
文章的看法。
誰對誰錯？
如果讀過我所寫的《
軟件開發(fā)：個人與團(tuán)隊是永遠(yuǎn)的核心》一文的話，知道我給出了高質(zhì)高效軟件開發(fā)的一個效能模型。從模型所涵蓋的內(nèi)容來看，其范圍非常廣，包括行為、能力和方法三大支柱。某種程度上，我們在軟件行業(yè)的
職場旅程有點象是“盲人摸象”（但我們能溝通），這個摸索的過程與我們從事的軟件細(xì)分行業(yè)（如
互聯(lián)網(wǎng)、通訊、銀行）、服務(wù)公司（如國企、外企、私企）、工種（如開發(fā)、測試）等都有著很直接的關(guān)系，所獲得的一種成功經(jīng)驗很可能在另一種情形下根本行不通。摸索的過程很容易通過現(xiàn)實去理解書本上的東西，這不是壞事，但千萬不要以為所“眼見的”就是“宇宙真理”，也千萬別放棄自己的獨(dú)立思考。
存在爭議并不是壞事，我們之所以爭議，是因為我們有著不同的成長途徑和思考深度（年齡起著一定的作用）。爭議的焦點不是為了“你死我活”地相互“拉黑”，而應(yīng)最大可能地達(dá)成共識和完善自我認(rèn)識。所達(dá)成的共識越多就越是知道“象的模樣”，這對所有的從業(yè)人員都有意義。正因如此，作為技術(shù)人，我時常會告誡自己“多放下一點自大與自尊去接受別人的想法，這對于自己來說是一種很好的成長途徑。”而且，我對于自己所不熟悉的技術(shù)領(lǐng)域更多持敬畏而非否定態(tài)度。總的說來，誰對誰錯并非爭論的關(guān)鍵，而是我們有哪些想法其實是相通或相同的、如何擺事實講邏輯地讓對方了解自己的想法。我希望每一位讀者都能理性對待所碰到的爭議，這算是一個小小的呼吁吧。
QA不包含測試
我認(rèn)為引起QA與測試相關(guān)的很多爭議出現(xiàn)在我們沒有明晰概念，或者有的概念太泛了容易導(dǎo)致問題。QA這個詞就是一個例子！
質(zhì)量保證很容易讓人想到與軟件質(zhì)量相關(guān)的方方面面，比如測試、流程、缺陷數(shù)據(jù)分析等。既然這樣，開發(fā)工程師的水平是不是也影響著軟件質(zhì)量呢？那人員的招聘為什么不由QA部門管，而是由HR和開發(fā)部門管？這個問題問得是不是很無厘頭？但這個問題也告訴我們，各種部門的職責(zé)定義其實并非由其名字表意所定，而是由公司根據(jù)組織架構(gòu)的需要指派的。既然如此，我們在使用這些名詞時，一定要根據(jù)職責(zé)加以展開，而不能依據(jù)名字意思本身，否則很容易因為不當(dāng)言語而引發(fā)沒有價值的爭議。有些爭議甚至影響到了他人的“飯碗”了，你叫人如何理性？這間接地指出，我們的言語應(yīng)盡可能嚴(yán)謹(jǐn)。
如果QA不是測試，那它是干什么的？老實說，我不敢憑空給一個角色定義職責(zé)，加上我并不是QA（與測試）方面的專家，在此只能以我曾經(jīng)服務(wù)過的Motorola公司為例說一說我的大致理解。簡單說來，Motorola的QA是一個與測試部門完全獨(dú)立的部門，她關(guān)注二大事務(wù)，一是缺陷數(shù)據(jù)分析與缺陷預(yù)防，二是流程規(guī)范與改善。QA會根據(jù)測試與開發(fā)兩大部門所產(chǎn)生的缺陷數(shù)據(jù)進(jìn)行數(shù)據(jù)分析（或叫數(shù)據(jù)挖掘吧），發(fā)現(xiàn)各產(chǎn)品的缺陷模型（常犯錯誤、缺陷數(shù)趨勢等），通過模型去預(yù)測可能潛在的遺留缺陷，以幫助開發(fā)部門進(jìn)行改進(jìn)（最終作用于流程）。另外，QA會全程參與軟件開發(fā)活動以跟蹤公司所制定流程的執(zhí)行情況。比如，以前我就職的Motorola杭州研發(fā)中心通過了TL9000認(rèn)證，QA必須確保開發(fā)活動完全符合TL9000的要求，以免出現(xiàn)資質(zhì)復(fù)審時無法通過的狀況。
讀者請注意，我以Motorola公司為例去定義QA的職責(zé)就一定對嗎？未必！對于就職于一些測試隸屬于QA部門的同仁可能很難接受以上的定義。在這種情況下，我們需要思考的是，這個定義是否有助于我們更方便地溝通？如果定義有助于我們的溝通，則這種定義就是可取的，否則值得商榷。理性思考不能忘！
我們需要QA嗎？
如果問“我們需要測試嗎？”答案很清楚，不是嗎？那公司是依據(jù)什么決定是否需要一個工種的？很簡單，不同的技能！
不少軟件公司需要通過象CMMI、ISO9000系列、TL9000等這樣的質(zhì)量體系認(rèn)證，并定期復(fù)審。這些質(zhì)量體系主張“質(zhì)量源于過程”，因此，一定需要有人為公司制定相應(yīng)的開發(fā)流程并監(jiān)督流程在公司的到位實施。流程驅(qū)動研發(fā)的質(zhì)量意識是需要培養(yǎng)的，這就離不開象“Quality begins with me”這樣的培訓(xùn)。缺陷數(shù)據(jù)通過挖掘能幫助發(fā)現(xiàn)其他有價值的東西，這就需要相應(yīng)的數(shù)據(jù)建模與分析技能。
不難認(rèn)同，以上知識與相關(guān)技能不能由開發(fā)或測試團(tuán)隊的人去兼顧，因此我們需要獨(dú)立的QA部門。
QA部門的作用與重視程度在不同的行業(yè)完全不同。平均說來，互聯(lián)網(wǎng)行業(yè)的產(chǎn)品因為對質(zhì)量問題具有更高的容忍度（大多互聯(lián)網(wǎng)產(chǎn)品直接上線，有問題可以直接回退），而非象通訊行業(yè)那樣得交由象中國移動這樣的運(yùn)營商去運(yùn)營，也不存在因質(zhì)量事故引發(fā)的第三方懲罰性費(fèi)用。另外，互聯(lián)網(wǎng)產(chǎn)品的用戶根本不關(guān)心產(chǎn)品開發(fā)過程是否遵循CMMI等質(zhì)量體系，這與通訊行業(yè)運(yùn)營商對之可能有要求完全不同。我在《離開通訊業(yè)入職互聯(lián)網(wǎng)圈的一些感悟》一文中進(jìn)一步談到了兩個行業(yè)的不同。
至此，我希望讀者接受我將QA與測試兩個概念區(qū)分開的建議。
一點重申
無論使用何種天花亂綴的技法和理論，探尋測試團(tuán)隊核心價值時一定要打破測試與開發(fā)團(tuán)隊之間的心理博弈防線，否則沒有成功的可能。以我長期在開發(fā)一線的經(jīng)歷，測試的價值困惑首先源于缺乏開發(fā)工程師對之的認(rèn)可，這是種心理感受問題，不是技術(shù)問題。《對軟件測試團(tuán)隊“核心價值”的思考》雖沒有直接給出核心價值的定義，但給出了探索方向，希望值得我們共同思考。
測試工程師思考從開發(fā)工程師的“痛點”尋找突破口，或許能找到出路。當(dāng)然，要真從開發(fā)的“痛點”下手，測試團(tuán)隊必須有些“刷子”，否則只能游離在質(zhì)量與效率的邊緣。
對朱老師所言的回復(fù)
朱老師：軟件測試最核心的價值還是能夠快速發(fā)現(xiàn)問題以提供產(chǎn)品的質(zhì)量反饋，有能力提供準(zhǔn)確的、客觀的、完整的質(zhì)量評估，并通過缺陷分析、用戶行為分析等，確定缺陷模式和開發(fā)人員不良行為、習(xí)慣等，幫助開發(fā)人員預(yù)防缺陷（從設(shè)計到編程、單元測試，不僅僅是設(shè)計）。
回復(fù)：這個定義存在將測試與QA混為一談的問題。如果我是一名測試工程師，看到這樣的定義真的會嚇一跳，要求太高了。我認(rèn)為質(zhì)量度量很容易出現(xiàn)主觀現(xiàn)象，難以做到“1+1=2”這樣的真實。軟件質(zhì)量度量的目的不是為了“真實”了解軟件的質(zhì)量狀況，因為團(tuán)隊級的質(zhì)量無法直接度量，度量的目的是為了幫助開發(fā)團(tuán)隊找到改善點。軟件質(zhì)量管理應(yīng)重實踐、輕量化，以幫助工程師改善工作習(xí)慣和提升開發(fā)環(huán)境的效率為目標(biāo)。我欣賞朱老師身兼QA與測試雙重身份，但就測試核心價值的探討上，我希望能采納所提出的將QA與測試分開的建議。概念只有清晰了、輕量了，才不容易引起歧義，也更利于我們達(dá)成更多的共識和提高溝通效率。
朱老師：我這是地地道道的測試，看來你對QA理解不夠。QA的主要對象是（包括開發(fā)、測試）流程，QA人員評審、審計和改進(jìn)流程，以保證質(zhì)量。測試的對象是產(chǎn)品，包括階段性半成品。從嚴(yán)格意義看，測試就是對軟件產(chǎn)品的質(zhì)量評估。
回復(fù)：第一話既講測試又講QA，很容易引起誤解。第二句與第三句的觀點我認(rèn)同。對于第四句，我的問題是“測試真能評估軟件質(zhì)量嗎？”
對《我們需要專職的QA嗎？》相關(guān)文章的看法
《我們需要專職的QA嗎？》這篇文章的論點是QA，但內(nèi)容其實談的是測試，文不對題引發(fā)沒有必要的爭議屬于情理之中。該文中還是有很多值得我們思考的觀點，其中不足之處后面兩篇文章對之加以反駁了。
《測試QA的角色和分工》一文同樣存在將QA與測試混在一起討論的問題，但其中還是能看出QA與測試的痕跡。比如，其中談到了認(rèn)證。其對于分工的論述我很欣賞，也闡述了為什么需要專職測試人員。
《對《我們需要專職QA嗎？》的回應(yīng)》一文明確區(qū)別了QA和測試，且只關(guān)注于測試的討論。我與段老師有很多共識，雖沒有聽過他的演講，但看過他一些分享主題的PPT，能從開發(fā)人員的角度找到共鳴點。注意文中的最后一句話，“測試和開發(fā)之間有更多配合，更多相親相愛，把測試當(dāng)成提高和推動質(zhì)量的手段，不正應(yīng)該是測試的方向嗎？”
QTP不識別樹結(jié)構(gòu)中的點擊事件，未生成該點擊事件的腳本，解決辦法：
1、未生成點擊"auto分類c1"的腳本
2、點擊1、對象庫-2、添加對象庫-3、選中對象-點擊OK，即將該對象加到對象庫中。
3、腳本中添加該對象的點擊事件
Browser("通用呼叫中心后臺").Page("通用呼叫中心后臺_2").Frame("iframe_main").WebElement("auto分類c1").Click
4、回訪成功
For non-interactive testing, you may choose to run
JMeter without the GUI. To do so, use the following command options
-n This specifies JMeter is to run in non-gui mode
-t [name of JMX file that contains the
Test Plan].
-l [name of JTL file to log sample results to].
-r Run all remote servers specified in JMeter.properties (or remote servers specified on command line by overriding properties)
The script also lets you specify the optional firewall/proxy
server information:
-H [proxy server hostname or ip address]
-P [proxy server port]
Example : JMeter -n -t my_test.jmx -l log.jtl -H my.proxy.server -P 8000
-n 該參數(shù)表示Jmeter運(yùn)行在非圖形化模式下（即命令行模式）。
-l 保存樣本結(jié)果的JTL文件
-r 運(yùn)行所有在JMeter.properties 中定義的遠(yuǎn)程服務(wù)（或者通過命令行覆蓋配置文件中定義的遠(yuǎn)程服務(wù)）。腳本還允許您指定可選的防火墻/代理服務(wù)器信息：
-H 代理服務(wù)器主機(jī)名或者IP地址
-P 代理服務(wù)器的端口號
上面這段說明來自 JMeter 的官方用戶手冊。其中提到了使用命令行方式運(yùn)行 JMeter 腳本的方法。只有幾個簡單的參數(shù)，很直觀，用起來也很方便。好處是可以節(jié)省一些系統(tǒng)資源。
今天嘗試 300 個虛擬用戶連續(xù)運(yùn)行 5 分鐘時——使用 GUI 方式，發(fā)現(xiàn)開始運(yùn)行后不久 UI 就失去了響應(yīng)，并提示一個有關(guān) AWT 的錯誤，最終只能把 Java 進(jìn)程結(jié)束掉。但是使用命令行方式時卻很穩(wěn)定。
不過當(dāng)在命令行方式下嘗試 500 個虛擬用戶連續(xù)運(yùn)行 5 分鐘時，JMeter 拋出了一個 Out of Memory 的異常并退出了進(jìn)程。
Note：
1.執(zhí)行命令前要檢查當(dāng)前目錄是否是 %JMeter_Home%\bin 目錄；
2.如果 JMeter 腳本不在當(dāng)前目錄，需要指定完整的路徑；如果要把執(zhí)行的結(jié)果保存在其他地方也要指定完整的路徑。
如何
測試寫好的Webservice？你當(dāng)然可以寫代碼來測試，但還是太麻煩，你得花時間去
學(xué)習(xí)各語言的關(guān)于Webservice調(diào)用的相關(guān)API。這里推薦一個Webservice開發(fā)的必備工具-
SoapUI，無須了解底層細(xì)節(jié)，就能快速測試你的Webservice開發(fā)的是否正確。
SoapUI是一個開源測試工具，通過Soap/HTTP來檢查、調(diào)用、實現(xiàn)
Web Service的功能,而且還能對Webservice做性能方面的測試。
SoapUI下載地址：http://sourceforge.net/projects/soapui/files/
(SoapUI也有收費(fèi)的Pro版本，對于一般的開發(fā)人員來說，如果只是調(diào)試下，開源的免費(fèi)版就足夠用了)
Demo
首先新建一個SoapUI Project，在Initial WSDL/WADL中輸入wsdl的地址
Project建立好后，SoapUI會根據(jù)WSDL的格式生成左邊的列表樹，包括CUX_0_WS_SERVER_PRG_Binding為WSDL Binding，INVOKEFMSWS為Binding中的Operation。雙擊Request1就能看到Soap請求報文的內(nèi)容。
在請求報文中填寫必要的請求信息，并在左下角的Request Properies中輸入用戶名，密碼及WSS-Pasword Type，再點擊綠色的運(yùn)行按鈕，就能在右側(cè)生成Soap響應(yīng)報文。
只是對SoapUI 做了簡單的介紹，主要用其來查看web service提供的接口，以及返回的結(jié)果，SoapUI的功能遠(yuǎn)不止這些，其可以對web service進(jìn)行功能上和性能上的測試。
世易時移，現(xiàn)今的科技發(fā)展一日千里，
軟件測試這門科學(xué)也到了該進(jìn)行革命的時候了，“這是變革者的路！。”Bhumika Mehta的這篇
文章很好的詮釋了為什么軟件測試需要變革以及如何進(jìn)行變革。他認(rèn)為，軟件測試需要的就是想法與創(chuàng)意。沒有想法的測試人員可能在測試這條路上不會走得太遠(yuǎn)。
用戶變得更有想法：
集萬千寵愛于一身的用戶與客戶有了更多的選擇空間。破除商業(yè)薄弱環(huán)節(jié)的競賽在激烈地進(jìn)行著，企業(yè)者們煞費(fèi)苦心地去想爭奪市場和討好用戶，時間、成本、產(chǎn)品本身都是孕育商業(yè)里程碑的重要營養(yǎng)元素。
對于用戶和客戶來說，你的產(chǎn)品是否足夠完美，是否兼具美學(xué)觀感，是否值得信賴都是他們目前所關(guān)心和關(guān)注的。此外，客戶對自己提出的要求更為明確更為苛刻，不再是含糊不清亦或語焉不詳而將就附和。
在這種情況下，傳統(tǒng)的軟件測試方法亟需改革創(chuàng)新以滿足用戶思維和觀念上的轉(zhuǎn)變需求。
我們不妨先問問自己幾個問題：
我們做需求分析時是否到了無從入手的境地？
我們是否很難再給自己或團(tuán)隊寫出簡明扼要的說明文檔？
我們是否很難再在溝通技能上有所加強(qiáng)？
我們是否很難再在報表研究和分析上有所進(jìn)步？
如果答案是肯定的，我們還在等待什么？現(xiàn)在就該即刻動身去計劃，去執(zhí)行，去改變，去觀察，去記錄。
技術(shù)每天都在轉(zhuǎn)變：
當(dāng)初桌面系統(tǒng)橫行的時候，
移動端的軟件應(yīng)用還只是襁褓里的娃娃。時過境遷，如今人手一機(jī)，特別是智能
手機(jī)，成了地鐵、公交上獨(dú)特的詠嘆調(diào)。移動端的軟件測試完全有別于傳統(tǒng)的測試范疇，我們必須適應(yīng)這種轉(zhuǎn)變。
應(yīng)該嘗試的事情：
我們需要考慮更多的應(yīng)用場景；
我們需要更多觀察人們是如何使用移動設(shè)備的；
我們需要更了解清楚產(chǎn)品或應(yīng)用的真正意圖。
工具常有，但魯班不常有：
自動化的需求日漸增長，成為衡量軟件測試員優(yōu)劣與否的標(biāo)尺。但實際上并非想象的那么美好。任何工具都不能替代人的意志。好的工具固然能事半功倍，但是若沒有其背后人的想法和努力，再好的工具也只是花瓶。沒有工具可以完全脫離人而獨(dú)立
工作，至少目前仍然如此。
市場上過百款的新工具和套件可供選擇，但時間對于測試環(huán)節(jié)依舊彌足珍貴，所以自動化是個必然選擇，但必須與人和諧共處，通力合作。
應(yīng)該嘗試的事情：
就當(dāng)前應(yīng)用或產(chǎn)品想出另外5種的測試方法；
對工具運(yùn)用進(jìn)行更深入細(xì)致的研究直至找出最合適最優(yōu)化的選擇或組合；
對產(chǎn)品或應(yīng)用開展更緊密的監(jiān)察以及就錯誤之處作出更深入的調(diào)查分析。
有多少人會認(rèn)同——若減免考試壓力，會使我們學(xué)得更多走得更遠(yuǎn)？或許多年后再回首，純粹的應(yīng)試學(xué)習(xí)換來的只是冰冷冷的通過與不通過，對實際工作或職業(yè)的幫助實在。我不是對認(rèn)證考試有個人偏見，但其不能成為衡量技術(shù)高低的全部。受時間所限，考試中并不能完全反映個人的真正實力。放之于軟件測試，時間意味著成長。
你或許不能每天都提出上百個新點子；
你或許不能在數(shù)小時內(nèi)就掌握一個自動化工具；
你或許不能在測試的第一周就發(fā)現(xiàn)多于100處的差錯；
你或許不能剛?cè)?a target="_self" style="word-break: break-all; color: #202859; line-height: normal !important;">職場馬上就能與他人進(jìn)行良好有效的溝通。
但不論高低，成長是個必然之物。隨著閱歷的沉淀與經(jīng)驗的累積，我們的技術(shù)和為人處事會相應(yīng)增加了厚度。過去所犯的種種差錯都應(yīng)該好好反省與保持警惕，避免重滔覆轍，重復(fù)犯錯，這會使我們少走不少彎路。
生于憂患：
開發(fā)主管或經(jīng)理或許可以從基層代碼工作中抽離，但對于測試經(jīng)理來說卻應(yīng)該始終工作在第一線。當(dāng)我們想忘卻基本技能時，我們同時也會被職業(yè)生涯所忘卻。即使擁有再豐富的測試經(jīng)驗，我們都應(yīng)該一如既往地做好測試的本職工作。
應(yīng)該嘗試的事情：
測試真正的產(chǎn)品；
提出讓產(chǎn)品更好用的建議；
學(xué)習(xí)研究市場上那些銷售得最好或沒有銷路的產(chǎn)品；
想明白如何讓想法與實際更好地融合。
寫在最后：
無論本文怎么論述，軟件測試需要的就是想法與創(chuàng)意。沒有想法的測試人員可能在測試這條路上不會走得太遠(yuǎn)。所以要學(xué)會思考。研究那些與自己有關(guān)的真正的產(chǎn)品，換位思考如果這是你的產(chǎn)品，你會怎么做，你會如何測試。同時，要把溝通與報表分析技能武裝好。一個不懂溝通與閱讀報表數(shù)據(jù)的測試人員，同樣會走得比別人艱辛。
今天在公司機(jī)器上安裝了
BugFree 3.0.2，就安裝過程中出現(xiàn)的問題記錄如下，以備將來查閱。
問題1：xampp中的Apache不能啟動，而且80端口也沒有被占用。
原因和解決：XAMPP Control Panel提示visual svn
server占用了443端口。點擊Apache后的Config按鈕，將Apache（httpd-ssl.conf中的Listen 443改為其它值就好了，比如433）。
問題2：在第一步環(huán)境檢查頁面時，顯示xampp/htdocs/BugFile目錄讀寫失敗。
解決辦法： 在xampp/htdocs/下新建一個BugFile文件夾就好了！
問題3：在第二步配置頁面時，不知道
數(shù)據(jù)庫用戶名和密碼應(yīng)該輸入什么。寫錯了會報錯：Access denied for user '****'@'*****' (using password: YES)
解決：用戶名默認(rèn)輸入：root，密碼為空。
問題4：添加用戶時，用戶名中不可包含大寫字母。否則在登錄的時候總是提示“用戶名不存在”
問題5：添加的用戶在登錄時提示“無產(chǎn)品訪問權(quán)限”
解決：用戶要至少有一個可以訪問的產(chǎn)品。如果是剛裝的bugfree，還沒有用戶組和產(chǎn)品的話。先在用戶組管理頁面添加一個用戶組，比如GroupA，將這個用戶加入這個用戶組，在產(chǎn)品管理頁面添加一個產(chǎn)品，指定這個產(chǎn)品的用戶組為GroupA。這樣這個用戶就可以登錄了。
最后記得在xampp control panel中將Apache和MySql前面對應(yīng)的svc勾上，這樣每次開機(jī)他們就會作為服務(wù)自動啟動了。