上海翻譯公司完成安全問題類中文翻譯
時間:2018-02-12 08:44 來源:未知 作者:dl 點擊:次
上海翻譯公司完成安全問題類中文翻譯
關于提高質量問題，我想系統(tǒng)的解釋一下我見過很優(yōu)秀的解決方案，其實在之前的文檔中也說了，但是篇幅并不集中，所以我專門寫一封郵件針對這個問題。
1.首先，我要說，在現實中沒有錯誤的系統(tǒng)是不存在的，完全的測試也是不存在的（理論上存在，但由于測試成本原因，是不可實現的），我可以舉個簡單的例子，只是一個加法而已：
public int addition (int intValue1,int intValue2){if（intValue1 = 143059884）{
return -100;//將會產生錯誤
}
else{
return intValue1+intValue2;
}
}
上邊的例子中，如果只采用黑盒測試的方法，無法除非測試所有的值得組合，這需要進行，（2的32次方 * 2的32次方）這種測試用例的量是不可能實現的。
當然同時采用白盒測試的，代碼走查方法將會發(fā)現問題，但這只是個簡單的加法函數而已，實際的項目將比這復雜的多，所以在現實的約束下，完整測試并不存在，所以可以說確認沒有錯誤的系統(tǒng)也同樣是不存在的，比如說我們都在使用的windows系統(tǒng)，他的關于質量控制的投入是海量的，但他仍有問題。
那么我們如何保證軟件質量呢？請接著看下邊的章節(jié)。
2.測試覆蓋度，簡單說，就是測試覆蓋功能的百分比，這個值不容易精確計算，但是統(tǒng)計性計算是可行了，已經有先人針對不同類型的系統(tǒng)統(tǒng)計和研究過，我們可以借鑒下他們的經驗和成果（我記不清具體的數字了，但我會根據我的經驗給你一個合理的參考值）
類型 建議覆蓋度 建議開發(fā)：測試（投入比例） 解釋
生命相關（航空航天、醫(yī)療） 99%以上 1:6以上 由于錯誤將帶來嚴重后果，測試投入比例會非常高的情況下，才可以保證質量。
操作系統(tǒng)（windows,linux）或者與大眾相關的系統(tǒng)（銀行核心系統(tǒng)） 90%-95% 1:3-1:5 由于是為了其他軟件在上邊運行的基礎，所以錯誤的容忍率也是很低的，需要投入很高的質量成本。
產品級系統(tǒng)(office）行業(yè)核心系統(tǒng)（mopho比對服務)） 70%-90% 1:2-1:3 由于是為了服務不同的客戶，用戶群體廣泛，所以應該投入較高的質量成本。
項目級非核心產品（某企業(yè)辦公自動化系統(tǒng)，mopho查重外圍系統(tǒng)） 60%-80% 1:1 由于是特殊行業(yè)，專業(yè)行為，實際專業(yè)人員只使用較少的關鍵功能，所以在關鍵功能多投入，不常用的功能可以減少投入來控制成本。
工具級，內部使用的提高效率的工具 50%-60% 1:0.3 由于是為了提高效率而產生的，不能為了它浪費太多的成本（這將會抵消它的好處），所以 我們只關注我們需要的功能，甚至不是很需要異常測試。
上邊的圖表列出了不同類型軟件系統(tǒng)的測試覆蓋度、質量成本參數，其實這個值在每個行業(yè)、每家公司甚至每個工作小組都是有差異的（這取決于項目的特性，客戶的成本和質量的取舍，工作組的運行模式，編碼和測試人員的水平。。。），
每個組織都應該不斷的分析并調節(jié)參數來保證合理的產品質量同時控制投入成本，讓我們的投入產出比最合理。
3.測試分類和提高測試覆蓋度。
如何提高軟件的覆蓋度呢？首先我想先從兩個層面對測試進行分類（測試類型、測試手段）
測試類型：針對不同的目的對測試進行分類。
功能測試：關于組件的主要功能進行正常使用情況下的測試，這種測試在整個測試中投入的比例很�。ù蠹s10%），但是卻能保證系統(tǒng)中最重要的覆蓋30%需求的功能正常運行，基本是每個項目都必須進行的測試。
路徑測試：把功能場景中所有的可能性都進行至少一次的測試。
覆蓋度測試：代碼是否都可以運行到的測試，這個測試一般主流的IDE都可以自動進行，我們只需要使用它，并修改這種錯誤就可以。
邊界測試：在取值的邊界狀態(tài)進行測試，例如在加法，參數為0,1，-1，MaxIntValue,MinIntValue都設計測試用例，尤其在分支和循環(huán)的邊界值。
異常測試：可預料的異常情況下，系統(tǒng)的表現也盡量友好，這個測試的作用是檢查軟件可用性和易用性的，
壓力測試：系統(tǒng)在大量并發(fā)使用的狀態(tài)下的穩(wěn)定性測試，多用戶系統(tǒng)和系統(tǒng)關鍵服務的組件需要加強這種測試的投入，保證系統(tǒng)能滿足我們客戶的真是需求（不是無限制的，而且衡量過成本的貼近真實需要并考慮到一定擴展的需求量）。
性能測試：系統(tǒng)響應速度的測試，在貼近真實網絡和硬件條件下的測試，這種測試最好是用一些輔助工具在客戶的真實使用環(huán)境下進行。然后我們得到參數后，去和我們的真實需求去對比，如果有問題，在性能瓶頸上重構系統(tǒng)（按照這個順序進行，
架構層、設計層、編碼邏輯層、編碼算法層、嘗試使用更底層的語言-如匯編、最后升級硬件或者軟件組件硬件話-例如采用加密機進行加密），
除了架構層外（因為后期架構層的修改并不容易），其他的層次可以在測試出是瓶頸時再去優(yōu)化（因為性能指標往往和代碼可讀性、結構簡單相違背），
我們不會無緣無故的犧牲這兩種指標而成全可能不需要的性能指標（這將會帶來其他問題）。
安全性測試：代碼的安全性進行測試，如堆棧溢出就是常見漏洞的根源，我們在編碼層一般采用代碼審查和培訓初級程序員的手段去避免這種類似的問題，再比如系統(tǒng)的敏感數據進行加密存儲和傳輸（用戶密碼、個人醫(yī)療信息）。
破壞性測試：以破壞系統(tǒng)為目的來檢測系統(tǒng)的健壯性，如把系統(tǒng)中某個服務器的網線拔下，檢查這時候是否有備用系統(tǒng)來代替他工作，并同時通過郵件短信或者監(jiān)控臺等手段及時通知使用者。
其他測試：可用性測試、易用性測試等非關鍵測試，比如找一個外行來，檢查我們的行業(yè)軟件是否好用，他是否在很少的文檔幫助下就可以正常使用。
對比性測試，對比算法新舊多個版本，在同樣的環(huán)境下，進行的用于分析的測試。
...
以上，按照類型分類的測試方法，我們需要量體裁衣，分析系統(tǒng)，找到我們需要的，再根據時間、計劃投入和各項質量需求指標來調配我們的投入。
測試手段：針對測試進行的方式進行分類。（黑盒白盒分為兩個大類）
黑盒：只需知道輸入、輸出、行為帶來的影響及可預知的異常的測試手段。
自動化邏輯層黑盒測試：寫工具檢查輸入輸出，并記錄運行結果的黑盒測試。對于需要很多測試數據的邏輯層組件，采用這種形式比較值得。
自動化界面黑盒測試：針對界面，寫界面腳本進行的自動化黑盒測試，對于操作復雜的界面層組件，采用這種形式比較值得。
手工界面黑盒測試：人工進行的黑盒測試，這一般針對界面層經常會使用到的主要場景，進行的測試（這種類型的測試用例數量應該被控制在一個合理的區(qū)域），因為我們每次版本的提交都需要進行完整的回歸測試。
手工工具黑盒測試：由開發(fā)組寫一些輔助工具進行的黑盒測試，一般壓力測試或者性能測試，可以采用此種形式，程序員付出的這些勞動，會把這種重復性的（每次版本的提交都要進行）活動，轉移給不需要懂編程的測試人員。
白盒：需要知道具體邏輯，甚至是代碼的測試。
組件層白盒單元測試：針對功能性組件（好像把部件比喻成機器，零件就是功能組件、結合零件的部分就是邏輯性組件）進行的單元白盒測試。這種活動是需要開發(fā)人員進行的，可以借助junit等白盒單元測試工具，這種測試也是比較值得進行的活動，它將保證我們的所有的基礎部件是正常的。
上層邏輯部件能夠放心的使用它們。
邏輯層白盒測試：這種測試一般針對，邏輯比較復雜的邏輯組件，單靠黑盒的方式無法保證質量，或者邏輯分支組合太多，如果采用人工的形式太話費時間時，這種方法將會比較值得。
代碼審查：針對重要模塊代碼，身份有經驗的程序員，去查看經驗少一些的同事的代碼，來檢查問題，同時把問題回饋給代碼編寫人，可以保證重要模塊的質量并提高新人的水平。
代碼走查：定期抽取代碼片段給全組人員，大家前一天熟悉一下代碼，分別列出代碼中好的地方和不足的地方，在第二天進行討論，從而提高全組整體能力的活動，代碼量盡量控制在2小時會議可以討論完的量級，沒迭代執(zhí)行1次或者每周1次均可。
1.每種測試的方法，都可以解決一部分質量問題，他們會有部分重疊，就像下圖說的那樣（只是示意）。
2.每種測試方法都無法保證100%的測試覆蓋度。每種測試方法一般在合理時間投入的條件下，一般可以達到，30%-70%的覆蓋度。
結合以上兩點，我們發(fā)現，我們最劃算的并能保證質量的方式，最好是多種測試方法結合（視項目特性決定），并盡量減少重疊的工作。
在產品級系統(tǒng)的軟件類型，
功能性組件，開發(fā)組采用白盒自動化測試的方法（開發(fā)：測試 1 : 1），
邏輯性組件，采用手工界面黑盒測試（開發(fā)：測試 1 : 0.5），測試組手工黑盒測試.
不好測試的邏輯組件，開發(fā)組實現工具、測試組執(zhí)行測試（開發(fā)：測試 1:0.2）
其他適合于項目類型的測試：（開發(fā)：測試 1:0.5 - 1:1）
這幾種測試方法結合起來，大體能夠用，開發(fā)：測試1:2 - 1:3的質量投入達到70%-90%的測試覆蓋度。
其他類型的系統(tǒng)是同樣道理的，我們可以在項目初期估算一個合理的投入比，然后隨著迭代的進行，根據情況調整他，使之趨近于我們的質量需求。
4.適應需求變化模型的質量控制。
基于XP極限編程的模型中，質量控制部分：（可以參考之前的文檔），這里只把圖復制過來，便于參考。
1.首先，是在需求討論會中，尤其是直接面對客戶的活動中，測試經理需要參與（尤其不能錯過結論性的討論）。
2.內部需求梳理過程中，測試經理需要參與，可以從非技術層面提出意見以參考。
3.項目經理、項目商務負責人、需求控制人員、開發(fā)經理、技術核心人員、設計人員、測試經理（這些角色中有些是同一個人兼職的）對于需求列表及迭代劃分達成共識，
這樣可以優(yōu)化不同部門的協(xié)作。尤其是時間和資源上的安排用于進度控制（同時在最初迭代不要忘記風險分析），這個階段將形成分迭代的測試計劃。
4.在每個迭代的過程中，開發(fā)人員可以采用2人結對的方式，互相寫另一個人的代碼的白盒單元測試代碼。
5.視情況開發(fā)人員，編寫一些用于測試目的的測試工具。
6.開發(fā)人員分析測試報告并修改BUG,然后更新BUG狀態(tài)（是否已經修改）。
6.同時，測試組成員按照測試計劃，編寫測試用例。
7.測試組使用工具、或者手工執(zhí)行測試用例。
8.提交測試報告給項目經理和開發(fā)組。
9.針對開發(fā)人員修改的測試狀態(tài)，執(zhí)行回歸測試。
10.同時，技術帶頭人組織開展、代碼走查和代碼審查的工作。
11.如果可以，每個迭代的產品將經歷用戶測試，處理用例提交的BUG.
12.每個迭代后期，當質量問題比較嚴重的時候，審視項目整體運行狀態(tài)是否存在問題，找到問題，提出解決方案，
并在下一個迭代去嘗試解決它。（除了最后一個迭代）
5.寫易于測試的代碼。
開發(fā)組和測試組的結合點，如下的文檔是使兩個部門合作的關鍵點：
需求 - 功能解釋 - 輸入 - 輸出 - 預期異常。
那么在設計和開發(fā)的過程中，我們需要創(chuàng)造便于測試的接口。準則依然是（設計、開發(fā)的高質量準則本來就是這個），高內聚、低耦合，合理分層。
不好的例子：
public void DOThing(A Complex Type,... )//沒有意義的函數名或者變量名
{
Call1(unknown object);//全局變量
(##))@*@*# ;//一段十分難懂的代碼，并沒有注釋說明他的作用
... ;// 太長的代碼段，200行
... ;//沒有預期的異常定義
}
較好的例子：
// phoneNumber: the phone number what we want to call
// return : the status of call ( Call_Success is succes call, Shutdown means the phone is shutdown )
// WrongFormatException :
public CallResult PhoneCall(String phoneNumber)//有意義的函數名和變量名，明確的接口說明(輸入、輸出和異常)
{
if( CheckPhineNumber() )// 檢查參數錯誤，并拋出預期異常,（錯誤舉例：不是數字組成的）
{
throw new WrongFormatException (phoneNumber)
}
try //捕獲調用函數的已知異常。
{
CallResult = GetPhoneStatus();
}
catch
{
deal with exception.
}
// 代碼可讀性好，篇幅較短20-50行（特殊情況，如算法函數可能較長，但需要增加合理注釋）
}
簡單的參數，組成的函數，不需要什么復雜的測試樁程序，就可以執(zhí)行測試，這就是易于測試的代碼。
編寫測試工具，也是提高系統(tǒng)易測試性的好方法。
6.程序員需要改正的通病和防御式編程、結對編程測試。
通�。�
讓程序員執(zhí)行測試，尤其是自己的代碼時，往往會出現漏測得情況，
這由于多方面的原因：開發(fā)人員的質量意識、開發(fā)人員對自己代碼的盲目自信，開發(fā)人員的技術漏洞（寫的時候就犯錯了，測試的時候犯了同樣的錯誤。。。）。
這些毛病不好改，但我認為從心理根源上解決一個疑問將踢開阻礙開發(fā)人員高質量測試的路障.
測試的目的，不是為了驗證寫的代碼是正確的，而是為了找到系統(tǒng)中存在的錯誤。
這點至關重要，心理障礙消除了，才能使人成長。
防御式編程
是程序員假定使用自己的程序的人會犯種種錯誤,自己的程序會受到種種錯誤條件的制約的編程心理。
比如，讀文件，要假定文件不存在、文件名不符合規(guī)則、文件格式不正確等種種情況，甚至有時要考慮系統(tǒng)斷電情況下，自己程序可以會產生的問題，并寫錯恢復處理邏輯。
這是提高軟件系統(tǒng)健壯性的重要手段，如果一個組所有的成員都是很精于此道，那么針對某些常見BUG的白盒測試，可以酌情減少，這將會減少成本，如果這些功能能夠很好的通過黑盒測試組成員的測試，
那么我們認為這種偷懶是可取的。
結對編程測試
由于每個人的精力和知識都是有限的，所以由一個人知識漏洞產生的錯誤，將很難被他自己測試檢查出來。所以我們建議2人結對編程測試的手段。讓兩個人互相編寫對方代碼的白盒測試用例（首先，必須給了解對方的需求，和寫對方測試代碼留足時間）
（當然在提交給對方之前，我是一定會花一點時間測試自己寫的代碼的），這將不會比自己寫自己的測試用例的方法浪費更多的時間，同時系統(tǒng)的每段代碼都有兩個人了解，同時從對方學習自己所不擅長的經驗，又能保證質量，真是一舉多得的方案。
7.其他關于質量
任何類型的公司經營都需要考慮上邊圖例的三元（質量-成本-時間），我們都希望，最短的時間、花最少的成本來達到最高的質量。這個想法是這么簡單直接，如果都用最這個詞，那么這個想法就是一個夢。
比較實際的想法應該是，在保證質量的門檻上，用合理的時間（客戶真正可容忍的時間），盡量減少投入。同時我們需要合理利用資源（物質資源、人），這點也是至關重要的，我見過一些公司，為了降低公司的成本，一味的壓榨員工，
無休止的加班，保持高壓力的工作狀態(tài)（時間和工作量），但實際他們卻沒有得到想要的結果（員工工作效率下降、消極怠工，質量降低帶來高維護成本），Cogent有一個失敗項目的例子，我還記得，當時為了惠普在筆記本上做一個人臉和指紋識別的操作系統(tǒng)登陸程序。
我們經過分析計算，做出6個月的計劃，但老板說，能不能3個月呢？當時的項目經理沒有拒絕他，也沒有問他是否可以在3個月只做部分重要的需求，接下來，噩夢開始了，每天加班數小時，每周至少加一個周么的班，第一個月大家加足馬力努力工作，但是由于為了滿足不合理的時間計劃，
月底一些由于進度過快產生的問題就出現了，接下來大家開始更努力的修正錯誤和應付新的工作，這時工作效率高的員工變得很累同時他們會犯一些本不該犯的錯誤，工作效率低的員工開始消極怠工，接下來可想而知，大量的質量維護成本占用了本來就很短的時間，進度滯后和質量問題開始困擾團隊。
三個月已經到了，但是工作的進度十分的不理想，老板批評了大家，并囑咐經理，要繼續(xù)加強工作強度。接下來的日子，大家開始不堪重負，抱怨，消極怠工普遍出現在所有員工的身上。然后項目又出現一些需求變動，這真是雪上加霜。大家開始失去信心和習慣于領導的批評，項目失去了控制，項目經理每天都很頭疼，他只能每天監(jiān)督大家加班的時間，并控制自己的情緒，防止和團隊成員發(fā)生沖突。
最后，產品經過兩個版本（大概兩年時間），大概客戶也覺得這個時間太長了，放棄了與我們合作。我不知道這個項目我們有沒有收益。
這個例子，我要說的是，讓每個成員和團隊一起成長，做出合理的進度安排，必要時和客戶討價還價（合理范圍增加價格-用于增加投入，或延長時間，或者取消或延遲次要需求），不要忽視每個人的健康和關注他們的生活質量，一個狀態(tài)良好、士氣高漲和主動積極的團隊將是戰(zhàn)無不勝的，質量對他們來講根本不是問題。
|
