欢迎来到三一办公! | 帮助中心 三一办公31ppt.com(应用文档模板下载平台)
三一办公
全部分类
  • 办公文档>
  • PPT模板>
  • 建筑/施工/环境>
  • 毕业设计>
  • 工程图纸>
  • 教育教学>
  • 素材源码>
  • 生活休闲>
  • 临时分类>
  • ImageVerifierCode 换一换
    首页 三一办公 > 资源分类 > PPT文档下载  

    一个台湾的经典PPT课件(繁体字) .ppt

    • 资源ID:2668214       资源大小:290KB        全文页数:42页
    • 资源格式: PPT        下载积分:8金币
    快捷下载 游客一键下载
    会员登录下载
    三方登录下载: 微信开放平台登录 QQ登录  
    下载资源需要8金币
    邮箱/手机:
    温馨提示:
    用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)
    支付方式: 支付宝    微信支付   
    验证码:   换一换

    加入VIP免费专享
     
    账号:
    密码:
    验证码:   换一换
      忘记密码?
        
    友情提示
    2、PDF文件下载后,可能会被浏览器默认打开,此种情况可以点击浏览器菜单,保存网页到桌面,就可以正常下载了。
    3、本站不支持迅雷下载,请使用电脑自带的IE浏览器,或者360浏览器、谷歌浏览器下载即可。
    4、本站资源下载后的文档和图纸-无水印,预览文档经过压缩,下载后原文更清晰。
    5、试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。

    一个台湾的经典PPT课件(繁体字) .ppt

    驗證與確認,保證軟體系統符合使用者的需求,本章目的,介紹軟體的驗證與確認(V&V),並討論它們之間的差異描述程式檢查(program inspections)程序,及其在V&V中擔任的角色解釋靜態分析(static analysis)作為驗證技術的原因描述淨室(Cleanroom)軟體開發程序,本章內容,驗證與確認規劃軟體檢查自動化靜態分析淨室軟體開發,驗證(Verification):我們是否正確的開發了產品?軟體應該與規格相符確認(Validation):我們是否開發了對的產品?軟體應該執行使用者真實的需求,驗證與確認的比較,是一完整的生命週期程序-V&V 必須應用在軟體發展過程中的各個段.有兩個主要目的發現系統中的缺失(defect)評估在作業環境中 系統是否適用,V&V程序,軟體檢查(Software inspections)與分析靜態系統的表示方式來發現問題有關(靜態驗證)可使用文件和原始碼的分析工具來輔助 軟體測試(Software testing)與實作完成的軟體並檢視其輸出行為有關(動態驗證)提供測試資料實作系統,並檢視其操作過程是否按照預期的行為執行,靜態與動態驗證,靜態與動態V&V,能夠揭示錯誤存在而非不存在能夠發現一個或一個以上的錯誤便是成功的測試這是對非功能性需求唯一的確認技術應該與靜態驗證合併使用以擴大 V&V的涵蓋範圍,程式測試,缺失測試(Defect testing)設計測試案例找出系統缺失.成功的缺失測試是能揭露出系統中的缺失.將在第20章中將介紹這一類測試統計測試(Statistical testing)設計測試案例反映使用者的輸入頻率.用於可靠度預估(reliability estimation).將在第21章中將介紹這一類測試,測試的類別,V&V的目標,驗證與確認應該建立軟體系統符合其目的的信心 這不表示系統必須完全沒有錯誤而是表示系統必須好到足以符合它的用途,而這些用途的類別將決定對於需求面的信心程度,V&V信賴程度,依系統目的、系統使用者期望以及系統目前的行銷環境而定軟體功能所需的信賴程度根據軟體對組織的重要性而定。使用者期望許多使用者對他們使用的某類軟體普遍抱持較低的期望 行銷環境 讓產品及早上市可能比找出程式中的缺失還重要,缺失測試和除錯是不同的處理程序驗證與確認著重於讓程式的缺失得以浮現 除錯著重於找出缺失並加以改正 除錯需要先界定出與程式執行行為有關的假設,再分別測試這些假設以找出系統錯誤,測試與除錯,除錯程序,謹慎地規劃才能得到更多的測試及檢查規劃應在開發過程的初期開始 規劃工作應該在靜態驗證與測試之間取得平衡 測試規劃與建立測試程序的標準有關,而非著重於描述產品如何測試,V&V規劃,開發的驗證模式,軟體測試計畫結構,測試程序需求追蹤測試項目測試時程測試記錄程序硬體與軟體需求限制,軟體檢查,包括人員檢視系統的原始表述,以助於發現異常與缺失不需要執行系統,故可在程式實作前進行可應用於系統的任何表述(如:需求規格、細部設計、測試資料、.等)是發現錯誤的很有效技術,檢查所以成功的原因,許多不同的缺失可在一次的檢查過程中被查出。在測試時,一個缺失會導致其他缺失,故需要執行多回 再使用應用領域及程式語言的知識,故審查人員可能會看到時常發生的錯誤類型,檢查與測試,檢查與測試是相輔相成而非對立的驗證技術可一起在驗證與確認作業中使用 檢查可以檢核是否與規格相符,但不能確認是否與客戶的真正需求相符檢查不可以檢核非功能性的特性,例如:執行效能、可使用性、.等,程式檢查,以正式的程序審查文件目的明確在缺失偵測(DETECTION)而非更正這些缺失可能是邏輯錯誤、程式碼中可能引發錯誤的異常行為,或是與組織或專案的標準不符,程式檢查之前的先備條件,一個可供檢查的明確程式碼規格 熟悉組織所訂標準的檢查小組的成員 一份語法正確的程式碼版本可用 先準備好一份錯誤檢核清單管理者必須能接受程式檢查會增加軟體開發的期初成本 管理者必須不將程式檢查中的表現來考評員工,檢查程序,檢查程序,向檢查小組說明系統概要事先將程式碼和相關規格分發給檢查小組 記錄下檢查時間與發現的錯誤 進行更新以修復發現的錯誤可視需要決定是否重新檢查程式碼,檢查小組,至少由四個成員組成 被檢查之程式的設計者負責尋找錯誤、疏忽及不一致的檢查者 向檢查小組解述程式碼內容的讀者 主持檢查會議及記錄所發現錯誤的仲裁者還可加入書記及仲裁長等成員,檢查的檢核清單,建立常犯錯誤的檢核清單做為檢查的主要項目 錯誤檢核清單的內容會隨著程式語言的不同而有所改變 程式語言中有關資料型態的檢查能力越弱,檢核清單就越長例如:變數初始化、常數命名、迴圈終止、陣列範圍、.等,檢查的檢核內容,檢查速率,在概觀階段,每小時可檢視約500行的原始程式碼 在個人預備階段,每小時可檢視約125行的原始程式碼 在開會討論階段,每小時可檢視90到125行的原始程式碼 因此,檢查是件成本昂貴的工作 檢查500行原始程式碼的成本約40人/時,等於 2800英鎊,自動化靜態分析,靜態分析程式屬於軟體工具,用於處理程式原始檔它們剖析程式原始檔,並試圖找出潛在的錯誤,將其通報給V&V小組注意 與程式檢查搭配使用效果最好,可輔助但非在取代程式檢查,靜態分析的檢查內容,靜態分析的階段,控制流程分析(Control flow analysis)找出有許多跳離或進入點的迴圈、無法被執行到的程式碼、.等資料使用分析(Data use analysis)找出未初始化即被使用的變數、被指派兩次但其間未被使用的變數、宣告後未使用的變數、.等介面分析(Interface analysis)檢核常式(routine)與程序(procedure)在宣告和使用時的一致性,靜態分析的階段,資訊流程分析(Information flow analysis)找出輸出變數的相依性。將所用到的變數值其變動過程詳盡列出,供程式碼檢查或審查時使用 路徑分析(Path analysis)找出程式中所有可能路徑,並列出路徑中會被執行到的敘述。基本上這在檢核的過程中是很有用的資訊流程分析和路徑分析會產生非常多的資訊,要謹慎應用,LINT的靜態分析,138%more lint_ex.c#include printarray(Anarray)int Anarray;printf(“%d”,Anarray);main()int Anarray5;int i;char c;printarray(Anarray,i,c);printarray(Anarray);139%cc lint_ex.c140%lint lint_ex.clint_ex.c(10):warning:c may be used before setlint_ex.c(10):warning:i may be used before setprintarray:variable#of args.lint_ex.c(4):lint_ex.c(10)printarray,arg.1 used inconsistently lint_ex.c(4):lint_ex.c(10)printarray,arg.1 used inconsistently lint_ex.c(4):lint_ex.c(11)printf returns value which is always ignored,靜態分析的使用,使用鬆散的資料型別語言(如C)時,靜態分析程式可以偵測出許多編譯程式無法找出的錯誤 對像Java 這類型的語言來說,編譯時會檢核所有變數類別,故可偵測出許多錯誤,使用靜態分析可能不符成本效益,淨室(cleanroom)這名稱是源自於半導體製造設備,其主要理念是缺失避免,而非缺失移除軟體開發程序的基礎:增量開發(incremental development)正式規格(formal specification)始用正確參數的靜態驗證(Static verification using correctness arguments)決定程式可靠度的統計測試(Statistical testing to determine program reliability),淨室軟體開發,淨室程序,淨室程序的特性,使用狀態轉變模型(state-transition model)的正式規格 增量開發 結構化程式設計-只允許使用有限的控制敘述和抽象化結構使用嚴格檢查的靜態驗證 系統的統計測試(將於第21章介紹這個主題).,增量開發,正式規格和檢查,以狀態為基礎的模型是一系統規格及檢查程序,用於檢核程式與本模型程式設計的方式很清楚,以致模型與系統之間的關係是清晰的使用數學論點(不是證明)可增加檢查程序中的性賴度,規格小組(specificationteam)負責開發及維護系統的規格 開發小組(development team)負責開發及驗證軟體。但在本過程中不需要執行甚至編譯軟體檢定小組(certification team)負責開發一套統計測試案例,在軟體開發完成後執行該軟體。可靠度成長模型可用來於決定可靠度何時可被接受,淨室程序小組,在IBM以淨室方式開發出的交付系統較少發生故障,這結果令人難忘客觀評論指出,以淨室方式開發的成本與傳統方式開發比較起來,不會太貴 與傳統開發程序比較起來錯誤較少將淨室方法轉移到工程師技術不甚熟練,且動機不強烈的組織,仍然是個挑戰,淨室程序評估,重點整理,驗證與確認是不同的兩件事。驗證是在確定程式與其規格相符:確認是在確定程式是否能夠滿足客戶的需要 測試計畫應該作為測試程序的指引 靜態驗證技術包含檢查及分析程式原始碼,並且找出錯誤,重點整理,程式檢查對尋找程式錯誤非常有效程式碼由一小組檢核,以找出軟體錯誤 靜態分析工具可以發現一些異常情形,有助於找出程式碼的的錯誤淨室開發程序包括增量開發、靜態驗證,以及統計測試,

    注意事项

    本文(一个台湾的经典PPT课件(繁体字) .ppt)为本站会员(laozhun)主动上传,三一办公仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知三一办公(点击联系客服),我们立即给予删除!

    温馨提示:如果因为网速或其他原因下载失败请重新下载,重复下载不扣分。




    备案号:宁ICP备20000045号-2

    经营许可证:宁B2-20210002

    宁公网安备 64010402000987号

    三一办公
    收起
    展开