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