第一篇：學(xué)習(xí)協(xié)議測(cè)試的心得體會(huì)

學(xué)習(xí)協(xié)議測(cè)試的心得體會(huì)

篇一：軟件測(cè)試學(xué)習(xí)感悟

學(xué)習(xí)軟件測(cè)試的感受及體會(huì)

這學(xué)期學(xué)習(xí)了趙培英老師教授的軟件測(cè)試這門計(jì)算機(jī)專業(yè)的專業(yè)課，我們學(xué)院又開(kāi)設(shè)了劉老師的關(guān)于這方面的講座，更徹底的使我們加深了對(duì)軟件測(cè)試的認(rèn)識(shí)。所以我想談?wù)勱P(guān)于軟件測(cè)試的體會(huì)及學(xué)到的一些知識(shí)。

作為計(jì)算機(jī)專業(yè)的一門很重要的課程，在計(jì)算機(jī)領(lǐng)域占據(jù)著不可替代的角色，隨著人類社會(huì)的進(jìn)步，各種領(lǐng)域計(jì)算機(jī)的普及，計(jì)算機(jī)軟件也越來(lái)越多的出現(xiàn)在各個(gè)場(chǎng)合，為人們的辦公，生活，學(xué)習(xí)，休閑等提供了前所未有的方便。軟件測(cè)試，其目的是：第一是確認(rèn)軟件的質(zhì)量，其一方面是確認(rèn)軟件做了你所期望的事情（Do the right thing），另一方面是確認(rèn)軟件以正確的方式來(lái)做了這個(gè)事件（Do it right）。作為計(jì)算機(jī)專業(yè)的學(xué)生，我想以我自己的觀點(diǎn)來(lái)闡述一下我對(duì)軟件測(cè)試的理解。

以前，就是在我沒(méi)有認(rèn)真了解測(cè)試行業(yè)之前，我也一直認(rèn)為測(cè)試應(yīng)該是不重要的，甚至認(rèn)為有必要有專門的測(cè)試職業(yè)嗎？認(rèn)為軟件主要是開(kāi)發(fā)人員的事，軟件的成果也是由開(kāi)發(fā)人員決定的，當(dāng)我學(xué)了軟件工程這門課，真正的了解到它的必要性，事實(shí)上真的不是那么一回事哦。軟件無(wú)處不在，然而，軟件是人編的——所以不完美。

我還查閱了一些資料就是不注意軟件測(cè)試的案例：

1、迪士尼的獅子王（1994～1995）軟件在少數(shù)系統(tǒng)中能正常工作，但在大眾使用的常見(jiàn)系統(tǒng)中不行。后來(lái)證實(shí)，迪士尼公司沒(méi)有對(duì)市場(chǎng)上投入實(shí)用的各種pc機(jī)型進(jìn)行正確的測(cè)試。

2、英特爾奔騰浮點(diǎn)除法軟件缺陷（1994）英特爾為自己處理軟件缺陷拿出4億美元支付更換壞芯片的費(fèi)用。導(dǎo)致付出如此昂貴的代價(jià)，其主要原因是發(fā)現(xiàn)了軟件缺陷沒(méi)有正確的處理。

3、美國(guó)航天局火星極地登陸（1999）該項(xiàng)目使用前有經(jīng)過(guò)測(cè)試，兩個(gè)測(cè)試小組雙方獨(dú)立工作都很好，但從未走在一起。

4、愛(ài)國(guó)者導(dǎo)彈防御系統(tǒng)（1991）一枚導(dǎo)彈在多哈擊斃28名美國(guó)士兵，癥結(jié)在于一個(gè)軟件缺陷：一個(gè)很小的系統(tǒng)時(shí)鐘錯(cuò)誤累積起來(lái)就可能拖延14小時(shí)，造成跟蹤系統(tǒng)失去準(zhǔn)確度。在多哈襲擊戰(zhàn)中系統(tǒng)被拖延100小時(shí)。

5、千年蟲(chóng)（大約1974）估計(jì)世界各地更換或升級(jí)該系統(tǒng)程序解決原有2000年錯(cuò)誤的費(fèi)用已經(jīng)超過(guò)數(shù)億美元。

這就是不注重測(cè)試的一些嚴(yán)重后果，因此我們發(fā)現(xiàn)了軟件測(cè)試的必要性！在設(shè)計(jì)有效測(cè)試用例之前，測(cè)試工程師必需理解軟件測(cè)試的基本原則，包括： 1、所有的測(cè)試都應(yīng)追溯到用戶需求。正如我們所知：軟件測(cè)試的目標(biāo)在于揭示錯(cuò)誤。而最嚴(yán)重的錯(cuò)誤（從用戶角度來(lái)看）是那些導(dǎo)致程序無(wú)法滿足需求的錯(cuò)誤。

2、應(yīng)該在測(cè)試工作真正開(kāi)始前的較長(zhǎng)時(shí)間內(nèi)就進(jìn)行測(cè)試計(jì)劃。測(cè)試計(jì)劃可以在需求模型一完成就開(kāi)始，詳細(xì)的測(cè)試用例定義可以在設(shè)計(jì)模型被確定后立即開(kāi)始。因此，所有測(cè)試應(yīng)該在任何代碼被產(chǎn)生前就進(jìn)行計(jì)劃和設(shè)計(jì)。3、Pareto 原則應(yīng)用于軟件測(cè)試。簡(jiǎn)單地講，Pareto 原則暗示著測(cè)試發(fā)現(xiàn)的錯(cuò)誤中的 80 ％很可能起源于程序模塊中的 20 ％。當(dāng)然，問(wèn)題在于如何孤立這些有疑點(diǎn)的模塊并進(jìn)行徹底的測(cè)試。

4、測(cè)試應(yīng)從 “ 小規(guī)模 ” 開(kāi)始，逐步轉(zhuǎn)向 “ 大規(guī)模 ”。最初的測(cè)試通常把焦點(diǎn)放在單個(gè)程序模塊上，進(jìn)一步測(cè)試的焦點(diǎn)則轉(zhuǎn)向在集成的模塊簇中尋找錯(cuò)誤，最后在整個(gè)系統(tǒng)中尋找錯(cuò)誤。

5、為了達(dá)到最佳效果，應(yīng)該由獨(dú)立的第三方來(lái)構(gòu)造測(cè)試?！?最佳效果 ” 指最有可能發(fā)現(xiàn)錯(cuò)誤的測(cè)試（測(cè)試的主要目標(biāo)），所以創(chuàng)建系統(tǒng)的軟件工程師并不是構(gòu)造軟件測(cè)試的最佳人選。

6、不充分的測(cè)試是不負(fù)責(zé)任的；過(guò)分的測(cè)試是一種資源的浪費(fèi)，同樣也是一種不負(fù)責(zé)任的表現(xiàn).。還有就是關(guān)于軟件測(cè)試的分類：從是否需要執(zhí)行被測(cè)軟件的角度，可分為： －靜態(tài)測(cè)試

－動(dòng)態(tài)測(cè)試

從測(cè)試是否針對(duì)系統(tǒng)的內(nèi)部結(jié)構(gòu)和具體實(shí)現(xiàn)算法的角度來(lái)看，可分為 ： －白盒測(cè)試

－黑盒測(cè)試

關(guān)于靜態(tài)測(cè)試和動(dòng)態(tài)測(cè)試：

（1）靜態(tài)測(cè)試是指不實(shí)際運(yùn)行被測(cè)軟件，而只是靜態(tài)的檢查程序代碼、界面或文檔中可能存在的錯(cuò)誤的過(guò)程。

其中包括代碼測(cè)試、界面測(cè)試和文檔測(cè)試3個(gè)方面。對(duì)于代碼測(cè)試，主要測(cè)試代碼是否符合相應(yīng)的標(biāo)準(zhǔn)和規(guī)范。對(duì)于界面測(cè)試，主要測(cè)試軟件的實(shí)際界面與需求中的說(shuō)明是否相符。對(duì)于文檔測(cè)試，主要測(cè)試用戶手冊(cè)和需求說(shuō)明是否符合用戶的實(shí)際要求。

（2）動(dòng)態(tài)測(cè)試是指實(shí)際運(yùn)行被測(cè)程序，輸入相應(yīng)的測(cè)試數(shù)據(jù)，檢查實(shí)際輸出結(jié)果和預(yù)期結(jié)果是否相符的過(guò)程。所以，我們判斷一個(gè)測(cè)試屬于動(dòng)態(tài)還是靜態(tài)測(cè)試，唯一的標(biāo)準(zhǔn)就是看是否運(yùn)行程序。

關(guān)于黑盒測(cè)試和白盒測(cè)試 ：

（1）黑盒測(cè)試

指的是把被測(cè)軟件看作是一個(gè)黑盒子，我們不去關(guān)心盒子里面的結(jié)構(gòu)是什么樣子，只關(guān)心軟件的輸入數(shù)據(jù)和輸出結(jié)果。

黑盒測(cè)試方法是在程序接口上進(jìn)行測(cè)試，主要是為了發(fā)現(xiàn)以下錯(cuò)誤: ? 是否有不正確或遺漏了的功能? ? 在接口上，輸入能否正確地接受? 能否輸出正確的結(jié)果? ? 是否有數(shù)據(jù)結(jié)構(gòu)錯(cuò)誤或外部信息(例如數(shù)據(jù)文件)訪問(wèn)錯(cuò)誤? ?性能上是否能夠滿足要求? ? 是否有初始化或終止性錯(cuò)誤? 用黑盒測(cè)試發(fā)現(xiàn)程序中的錯(cuò)誤，必須在所有可能的輸入條件和輸出條件中確定測(cè)試數(shù)據(jù)，來(lái)檢查程序是否都能產(chǎn)生正確的輸出。但這是不可能的。

黑盒測(cè)試的測(cè)試用例設(shè)計(jì) ?等價(jià)劃分法 ?邊界值法 ?錯(cuò)誤推測(cè)法 ?因果圖法

（2）白盒測(cè)試

指的是把盒子蓋打開(kāi)，去研究里面的源代碼和程序結(jié)構(gòu)。白盒測(cè)試也稱結(jié)構(gòu)測(cè)試或邏輯驅(qū)動(dòng)測(cè)試，它是知道產(chǎn)品內(nèi)部工作過(guò)程，可通過(guò)測(cè)試來(lái)檢測(cè)產(chǎn)品內(nèi)部動(dòng)作是否按照規(guī)格說(shuō)明書(shū)的規(guī)定正常進(jìn)行，按照程序內(nèi)部的結(jié)構(gòu)測(cè)試程序，檢驗(yàn)程序中的每條通路是否都有能按預(yù)定要求正確工作，而不顧它的功能。使用被測(cè)單元內(nèi)部如何工作的信息，允許測(cè)試人員對(duì)程序內(nèi)部邏輯結(jié)構(gòu)及有關(guān)信息來(lái)設(shè)計(jì)和選擇測(cè)試用例，對(duì)程序的邏輯路徑進(jìn)行測(cè)試?；谝粋€(gè)應(yīng)用代碼的內(nèi)部邏輯知識(shí)，測(cè)試是基于覆蓋全部代碼、分支、路徑、條件。

白盒測(cè)試的主要方法： ?邏輯驅(qū)動(dòng)測(cè)試 ?基本路徑測(cè)試

主要用于軟件驗(yàn)證。

使用程序設(shè)計(jì)的控制結(jié)構(gòu)導(dǎo)出測(cè)試用例。

邏輯驅(qū)動(dòng)測(cè)試：

主要是測(cè)試覆蓋率，以程序內(nèi)在邏輯結(jié)構(gòu)為基礎(chǔ)的測(cè)試。包括以下6種類型： ?語(yǔ)句覆蓋 ?判斷覆蓋 ?條件覆蓋 ?判定-條件覆蓋 ?條件組合覆蓋 ?路徑覆蓋

白盒測(cè)試的主要目的

? 保證一個(gè)模塊中的所有獨(dú)立路徑至少被執(zhí)行一次； ?對(duì)所有的邏輯值均需要測(cè)試真、假兩個(gè)分支； ?在上下邊界及可操作范圍內(nèi)運(yùn)行所有循環(huán)； ?檢查內(nèi)部數(shù)據(jù)結(jié)構(gòu)以確保其有效性

測(cè)試是軟件開(kāi)發(fā)過(guò)程的重要組成部分，是用來(lái)確認(rèn)一個(gè)程序的品質(zhì)或性能是否符合開(kāi)發(fā)之前所提出的一些要求。軟件測(cè)試的目的，第一是確認(rèn)軟件的質(zhì)量，其一方面是確認(rèn)軟件做了你所期望的事情（Do the right thing），另一方面是確認(rèn)軟件以正確的方式來(lái)做了這個(gè)事件（Do it right）；第二是提供信息，比如提供給

開(kāi)發(fā)人員或程序經(jīng)理的反饋信息，為風(fēng)險(xiǎn)評(píng)估所準(zhǔn)備的信息；第三軟件測(cè)試不僅是在測(cè)試軟件產(chǎn)品的本身，而且還包括軟件開(kāi)發(fā)的過(guò)程。如果一個(gè)軟件產(chǎn)品開(kāi)發(fā)完成之后發(fā)現(xiàn)了很多問(wèn)題，這說(shuō)明此軟件開(kāi)發(fā)過(guò)程很可能是有缺陷的。

經(jīng)過(guò)這一門課程的學(xué)習(xí)和老師的給我們的講座，意識(shí)到測(cè)試并非是我想像的從客戶角度任意使用軟件產(chǎn)品，從而發(fā)現(xiàn)有無(wú)質(zhì)量問(wèn)題，它有它的理論和實(shí)踐體系。軟件測(cè)試是一項(xiàng)嚴(yán)謹(jǐn)?shù)墓ぷ?，軟件測(cè)試員一個(gè)基本的素質(zhì)是打破砂鍋問(wèn)到底。喜歡找出那些深藏不露的系統(tǒng)沖突，樂(lè)于處理最復(fù)雜的問(wèn)題，外表上熱衷於來(lái)回奔忙，追求盡善盡美，為征服系統(tǒng)而額手稱慶。

最后特別感謝老師對(duì)我們的課程學(xué)習(xí)的講授，讓我們了解到計(jì)算機(jī)更多的知識(shí)，也讓我們了解到求職關(guān)于計(jì)算機(jī)方面的崗位，應(yīng)具備哪些專業(yè)知識(shí)，謝謝老師！篇二：軟件測(cè)試培訓(xùn)心得體會(huì)

軟件測(cè)試培訓(xùn)心得體會(huì)

概述

2012年8月2日至2012年8月6日，中國(guó)軟件評(píng)測(cè)中心的測(cè)試技術(shù)應(yīng)用與實(shí)踐培訓(xùn)課程在武漢召開(kāi)，本人非常榮幸的參加此次培訓(xùn)，通過(guò)這次經(jīng)驗(yàn)讓我系統(tǒng)的梳理了軟件測(cè)試?yán)碚摷夹g(shù)，對(duì)軟件測(cè)試有了一個(gè)更深入更全面的認(rèn)識(shí)。

下面請(qǐng)準(zhǔn)許我簡(jiǎn)述軟件測(cè)試的概念及軟件測(cè)試在軟件工程中的重要性。

一：軟件測(cè)試歷史與發(fā)展 到了上世紀(jì)80年代初期，軟件和IT行業(yè)進(jìn)入了大發(fā)展，軟件趨向大型化、高復(fù)雜度，軟件的質(zhì)量越來(lái)越重要。這個(gè)時(shí)候，一些軟件測(cè)試的基礎(chǔ)理論和實(shí)用技術(shù)開(kāi)始形成，并且人們開(kāi)始為軟件開(kāi)發(fā)設(shè)計(jì)了各種流程和管理方法，軟件開(kāi)發(fā)的方式也逐漸由混亂無(wú)序的開(kāi)發(fā)過(guò)程過(guò)渡到結(jié)構(gòu)化的開(kāi)發(fā)過(guò)程，以結(jié)構(gòu)化分析與設(shè)計(jì)、結(jié)構(gòu)化評(píng)審、結(jié)構(gòu)化程序設(shè)計(jì)以及結(jié)構(gòu)化測(cè)試為特征。人們還將“質(zhì)量”的概念融入其中，軟件測(cè)試定義發(fā)生了改變，測(cè)試不單純是一個(gè)發(fā)現(xiàn)錯(cuò)誤的過(guò)程，而且將測(cè)試作為軟件質(zhì)量保證(SQA)的主要職能，包含軟件質(zhì)量評(píng)價(jià)的內(nèi)容，Bill Hetzel在《軟件測(cè)試完全指南》(Complete Guide of Software Testing)一書(shū)中指出:“測(cè)試是以評(píng)價(jià)一個(gè)程序或者系統(tǒng)屬性為目標(biāo)的任何一種活動(dòng)。測(cè)試是對(duì)軟件質(zhì)量的度量?！边@個(gè)定義至今

仍被引用。軟件開(kāi)發(fā)人員和測(cè)試人員開(kāi)始坐在一起探討軟件工程和測(cè)試問(wèn)題。

軟件測(cè)試已有了行業(yè)標(biāo)準(zhǔn)(IEEE/ANSI)，1983年IEEE提出的軟件工程術(shù)語(yǔ)中給軟件測(cè)試下的定義是:“使用人工或自動(dòng)的手段來(lái)運(yùn)行或測(cè)定某個(gè)軟件系統(tǒng)的過(guò)程，其目的在于檢驗(yàn)它是否滿足規(guī)定的需求或弄清預(yù)期結(jié)果與實(shí)際結(jié)果之間的差別”。這個(gè)定義明確指出:軟件測(cè)試的目的是為了檢驗(yàn)軟件系統(tǒng)是否滿足需求。它再也不是一個(gè)一次性的，而且只是開(kāi)發(fā)后期的活動(dòng)，而是與整個(gè)開(kāi)發(fā)流程融合成一體。軟件測(cè)試已成為一個(gè)專業(yè)，需要運(yùn)用專門的方法和手段，需要專門人才和專家來(lái)承擔(dān)。

進(jìn)入上世紀(jì)90年代，軟件行業(yè)開(kāi)始迅猛發(fā)展，軟件的規(guī)模變的非常大，在一些大型軟件開(kāi)發(fā)過(guò)程中，測(cè)試活動(dòng)需要花費(fèi)大量的時(shí)間和成本，而當(dāng)時(shí)測(cè)試的手段幾乎完全都是手工測(cè)試，測(cè)試的效率非常低;并且隨著軟件復(fù)雜度的提高，出現(xiàn)了很多通過(guò)手工方式無(wú)法完成測(cè)試的情況，盡管在一些大型軟件的開(kāi)發(fā)過(guò)程中，人們嘗試編寫了一些小程序來(lái)輔助測(cè)試，但是這還是不能滿足大多數(shù)軟件項(xiàng)目的統(tǒng)一需要。于是，很多測(cè)試實(shí)踐者開(kāi)始嘗試開(kāi)發(fā)商業(yè)的測(cè)試工具來(lái)支持測(cè)試，輔助測(cè)試人員完成某一類型或某一領(lǐng)域內(nèi)的測(cè)試工作，而測(cè)試工具逐漸盛行起來(lái)。人們普遍意識(shí)到，工具不僅僅是有用的，而且要對(duì)今天的軟件系統(tǒng)進(jìn)行充分的測(cè)試，工具是必不可少的。測(cè)試工具可以進(jìn)行部分的測(cè)試設(shè)計(jì)、實(shí)現(xiàn)、執(zhí)行和比較的工作。通過(guò)運(yùn)用測(cè)試工具，可以達(dá)到提高測(cè)試效率的目的。測(cè)試工具的發(fā)展，大大提高了軟件測(cè)試 的自動(dòng)化程度，讓測(cè)試人員從繁瑣和重復(fù)的測(cè)試活動(dòng)中解脫出來(lái)，專心從事有意義的測(cè)試設(shè)計(jì)等活動(dòng)。采用自動(dòng)比較技術(shù)，還可以自動(dòng)完成測(cè)試用例執(zhí)行結(jié)果的判斷，從而避免人工比對(duì)存在的疏漏問(wèn)題。設(shè)計(jì)良好的自動(dòng)化測(cè)試，在某些情況下可以實(shí)現(xiàn) “ 夜間測(cè)試 ” 和 “ 無(wú)人測(cè)試 ”。在大多數(shù)情況下，軟件測(cè)試自動(dòng)化可以減少開(kāi)支，增加有限時(shí)間內(nèi)可執(zhí)行的測(cè)試，在執(zhí)行相同數(shù)量測(cè)試時(shí)節(jié)約測(cè)試時(shí)間。而測(cè)試工具的選擇和推廣也越來(lái)越受到重視。

在軟件測(cè)試工具平臺(tái)方面，商業(yè)化的軟件測(cè)試工具已經(jīng)很多，如捕獲/回放工具、Web測(cè)試工具、性能測(cè)試工具、測(cè)試管理工具、代碼測(cè)試工具等等，這些都有嚴(yán)格的版權(quán)限制且價(jià)格較為昂貴，但由于價(jià)格和版權(quán)的限制無(wú)法自由使用，當(dāng)然，一些軟件測(cè)試工具開(kāi)發(fā)商對(duì)于某些測(cè)試工具提供了Beta測(cè)試版本以供用戶有限次數(shù)使用。幸運(yùn)的是，在開(kāi)放源碼社區(qū)中也出現(xiàn)了許多軟件測(cè)試工具，已得到廣泛應(yīng)用且相當(dāng)成熟和完善。

二：軟件測(cè)試的概念與目的

軟件測(cè)試就是利用測(cè)試工具按照測(cè)試方案和流程對(duì)產(chǎn)品進(jìn)行功能和性能測(cè)試，甚至根據(jù)需要編寫不同的測(cè)試工具，設(shè)計(jì)和維護(hù)測(cè)試系統(tǒng)，對(duì)測(cè)試方案可能出現(xiàn)的問(wèn)題進(jìn)行分析和評(píng)估。執(zhí)行測(cè)試用例后，需要跟蹤故障，以確保開(kāi)發(fā)的產(chǎn)品適合需求。

1.測(cè)試的目的是為了表明軟件能夠工作

2.測(cè)試的目的是為了表明軟件不能夠能夠正常工作 3.測(cè)試的目的不是要證明什么，而是為了把軟件不能正常工作的預(yù)知風(fēng)險(xiǎn)降低到能夠接受的程度

4.測(cè)試不是行為，而是一種自覺(jué)的約束，不用太多的測(cè)試投入產(chǎn)生低風(fēng)險(xiǎn)的軟件上的。三：自我體會(huì)

體會(huì)一：軟件測(cè)試在整個(gè)軟件生命周期中的重要性它存在于整個(gè)項(xiàng)目周期，在項(xiàng)目開(kāi)始之初需求調(diào)研的時(shí)候就開(kāi)始了，在形成需求規(guī)格說(shuō)明書(shū)的時(shí)候就需要針對(duì)文檔進(jìn)行測(cè)試。這個(gè)環(huán)節(jié)在后續(xù)整個(gè)項(xiàng)目中占了很大的比重，能主導(dǎo)整個(gè)軟件項(xiàng)目的走向，成敗與否全在于開(kāi)始階段的決策。

體會(huì)二：軟件測(cè)試的真正意義這與發(fā)現(xiàn)錯(cuò)誤，而不在于驗(yàn)證軟件是正確的

在嚴(yán)格的測(cè)試也不能完全的發(fā)現(xiàn)軟件當(dāng)中所有的錯(cuò)誤，但是測(cè)試還是能發(fā)現(xiàn)大部分錯(cuò)誤的，能確保軟件基本可用和軟件的適用性，所以在后使用的過(guò)程中還需要加強(qiáng)快速響應(yīng)的環(huán)節(jié)。結(jié)合軟件測(cè)試?yán)碚?，故障暴露在最終客戶端之前及時(shí)主動(dòng)的去發(fā)現(xiàn)并解決。這點(diǎn)需要加強(qiáng)研發(fā)隊(duì)伍的建設(shè)。體會(huì)三：在系統(tǒng)性能方面需要重視

經(jīng)過(guò)這次培訓(xùn)中多個(gè)案例的講解，讓我了解到系統(tǒng)在上線之后會(huì)有很多不能預(yù)知的性能問(wèn)題，需要在上線之前實(shí)現(xiàn)進(jìn)行模擬，以避免風(fēng)險(xiǎn)，包括大數(shù)據(jù)量訪問(wèn)，高并發(fā)數(shù)等等。當(dāng)然也有很多應(yīng)對(duì)手段，沒(méi)有那種手段可以稱最完美的，只有最合適的，需要靈活的掌握，綜合運(yùn)用以達(dá)到最優(yōu)程度，這個(gè)很值的大家一起研究。

四：個(gè)人想法

根據(jù)軟件部門目前的情況，接下為了我們的軟件能在質(zhì)量上得到保障減輕項(xiàng)目后期維護(hù)驗(yàn)收的風(fēng)險(xiǎn)，在此做以下想法和建議； 想法一：有效制定軟件測(cè)試流程；

由于前期軟件工程項(xiàng)目中，未對(duì)軟件進(jìn)行系統(tǒng)化的測(cè)試，導(dǎo)致后期維護(hù)成本較高，變相增加了軟件開(kāi)發(fā)人員的工作量。方案： 1：測(cè)試需求分析 ? 明確需求范圍

? 明確每個(gè)功能業(yè)務(wù)處理流程 ? 不同的功能點(diǎn)作業(yè)務(wù)的組合 ? 挖掘顯示需求背后隱藏的需求

? 測(cè)試需求分析：?jiǎn)喂δ茳c(diǎn)輸入輸出------業(yè)務(wù)流分析-------篇三：軟件測(cè)試心得

軟件測(cè)試心得體會(huì)

軟件測(cè)試工作是一個(gè)系統(tǒng)而復(fù)雜的工程，軟件測(cè)試的目的就是確保軟件的質(zhì)量、確認(rèn)軟件以正確的方式做了你所期望的事情，所以工作的主要任務(wù)是發(fā)現(xiàn)軟件的錯(cuò)誤、有效定義和實(shí)現(xiàn)軟件成分由底層到高層的組裝過(guò)程、驗(yàn)證軟件是否滿足規(guī)格書(shū)要求和系統(tǒng)定義文檔所規(guī)定的技術(shù)要求、為軟件質(zhì)量模型的建立提供依據(jù)。

而且軟件的測(cè)試不僅是要確保軟件的質(zhì)量，還要給開(kāi)發(fā)人員提供信息，以方便其為風(fēng)險(xiǎn)評(píng)估做相應(yīng)的準(zhǔn)備，以及為其提供分析依據(jù)，重要的是要貫穿在整個(gè)軟件開(kāi)發(fā)的過(guò)程中，保證整個(gè)軟件開(kāi)發(fā)的過(guò)程是高質(zhì)量的。

軟件測(cè)試對(duì)測(cè)試工程師來(lái)講，要求具備較強(qiáng)的專業(yè)知識(shí)，嚴(yán)謹(jǐn)細(xì)心耐心的測(cè)試態(tài)度，良好的反向思維、發(fā)散思維能力、溝通能力等等。

以下是就自己的個(gè)人工作經(jīng)歷談一些淺見(jiàn)： 1.標(biāo)準(zhǔn)文檔的制定：

1.1.任何一個(gè)公司要讓自己的產(chǎn)品面市，都要有自己的一

套完整的品質(zhì)標(biāo)準(zhǔn)，這個(gè)標(biāo)準(zhǔn)一定是在符合國(guó)標(biāo)及客戶

標(biāo)準(zhǔn)的基礎(chǔ)上形成的企業(yè)標(biāo)準(zhǔn)，系統(tǒng)而全面地描述一款

產(chǎn)品的功能、性能、可靠性、健壯性、安規(guī)要求等一系 列的產(chǎn)品標(biāo)準(zhǔn)，并根據(jù)客戶特定要求相應(yīng)調(diào)整。1.2.測(cè)試儀器的作業(yè)指導(dǎo)書(shū)(SOP)及保養(yǎng)說(shuō)明等。定義儀器

的使用步驟、操作指南和保養(yǎng)細(xì)則等。2.測(cè)試資料的歸檔：

標(biāo)準(zhǔn)媒體文件、測(cè)試報(bào)告、BUG LIST庫(kù)（電子類問(wèn)題、結(jié)構(gòu)

類問(wèn)題、軟件類問(wèn)題：方案自存問(wèn)題、品證測(cè)試問(wèn)題、生產(chǎn)

測(cè)試問(wèn)題、客戶反饋問(wèn)題、終端消費(fèi)者反饋問(wèn)題等）、認(rèn)證測(cè)

試文檔歸納總結(jié)(認(rèn)證公司培訓(xùn)資料、認(rèn)證過(guò)程中出現(xiàn)并改善

的問(wèn)題)、測(cè)試工程師經(jīng)驗(yàn)分享、常見(jiàn)問(wèn)題解答FAQ等。3.功能測(cè)試：

3.1.這是軟件測(cè)試工作中最核心和最基本的一項(xiàng)測(cè)試，該測(cè)

試的主要內(nèi)容是檢查軟件是否符合需求定義，并通過(guò)構(gòu)

造正常的操作來(lái)檢查的動(dòng)作是否正確；在這個(gè)測(cè)試?yán)?，正確性是最最重要的軟件質(zhì)量要素。

3.2.功能測(cè)試按照可見(jiàn)性可以分為兩類：顯性功能和隱性功 能。

顯性功能：指在菜單里可以看得到的功能。

隱性功能：指在菜單里看不到的功能。

例如，電話本的顯性功能有增加、編輯、刪除、撥打等，這些功能可以在電話本的菜單里面看得到，姓名列表排

序則屬于一個(gè)隱性功能，因?yàn)樵陔娫挶镜牟藛卫餂](méi)有這

樣一個(gè)子菜單，但它卻是一個(gè)實(shí)實(shí)在在的功能。

如以下這些隱性功能都測(cè)試中都需重點(diǎn)關(guān)注： a.電話本上下頁(yè)切換，是否有遺漏聯(lián)系人信息？ b.是否支持手機(jī)內(nèi)存、SIM卡電話本的同時(shí)下載？還是

支持從一種介質(zhì)里下載？

c.斷電后再上電，系統(tǒng)設(shè)置的時(shí)間是否有記憶功能？ d.GPS信號(hào)正常時(shí)，導(dǎo)航地圖中時(shí)間是否有更新？ e.TFT屏在Power off→on, ACC off→on時(shí)，屏的角度

是否有記憶？

f.模擬導(dǎo)航時(shí)，是否有雙工功能？后臺(tái)源聲音輸出是否

正常？

g.路試語(yǔ)音產(chǎn)品外置麥克風(fēng)使用效果時(shí)，考慮車速、風(fēng)

聲、車內(nèi)講話噪聲、汽車底盤/發(fā)動(dòng)機(jī)噪聲等對(duì)麥克

風(fēng)錄音效果的影響，軟件多線程開(kāi)啟時(shí)導(dǎo)致的資源占

用/系統(tǒng)繁忙對(duì)后臺(tái)錄音系統(tǒng)的影響。(也可從結(jié)構(gòu)方

面考慮：外置麥克風(fēng)型腔開(kāi)孔的接觸面積，是否360 度可旋轉(zhuǎn)等來(lái)增加錄音的路徑等。）

h.地圖上的POI信息通過(guò)后臺(tái)語(yǔ)音搜索獲取不到，解決

措施：要求方案商訊飛完善后臺(tái)語(yǔ)音庫(kù)。

3.3.在實(shí)際的測(cè)試過(guò)程中，顯性功能通過(guò)菜單遍歷可以很容

易地進(jìn)行無(wú)遺漏的測(cè)試，但是隱性功能卻很容易為我們

所忽略！一個(gè)有效的解決辦法是去檢查軟件的功能定義

列表(Feature List)，從這個(gè)列表里面找出那些隱性的功能。

3.4.制定測(cè)試用例時(shí)，要充分考慮各功能模塊軟件的顯性功

能和隱性功能。4.健壯性測(cè)試：

橘生淮南則為橘，生于淮北則為枳。是說(shuō)明橘的健壯性太差。

該成語(yǔ)充分說(shuō)明了我們對(duì)產(chǎn)品進(jìn)行健壯性測(cè)試的必要性。

4.1.健壯性是指在異常情況下，軟件還能正常運(yùn)行的能力。

健壯性有兩層含義：一是容錯(cuò)能力，二是恢復(fù)能力。

健壯性測(cè)試主要包括：電子硬件健壯性(如：遙控距離測(cè)

試、高低電壓適應(yīng)性測(cè)試、插拔電及開(kāi)關(guān)機(jī)測(cè)試、靜電 抗擾度測(cè)試、熱插拔測(cè)試)和機(jī)械健壯性(如：整機(jī)結(jié)構(gòu)

設(shè)計(jì)基準(zhǔn)測(cè)試、模擬運(yùn)輸測(cè)試、常溫包裝跌落測(cè)試)。4.2.這項(xiàng)測(cè)試主要是檢查軟件對(duì)異常操作的容錯(cuò)能力，異常

操作通常要考慮異常輸入操作及異常條件兩個(gè)方面。例如：測(cè)試藍(lán)光媒體播放器時(shí)，反復(fù)把HDMI連接線拔掉，造成通信異常中斷，再接上復(fù)合視頻(CVBS)信號(hào)輸出，即由數(shù)字信號(hào)輸出轉(zhuǎn)為模擬信號(hào)輸出。恢復(fù)測(cè)試重點(diǎn)考察一下幾項(xiàng)：（1）系統(tǒng)能否重新運(yùn)行；（2）有無(wú)重要的數(shù)據(jù)丟失；（3）是否毀壞了其它相關(guān)的軟件或硬件；（4）若軟件出現(xiàn)系統(tǒng)報(bào)錯(cuò)，是否有自恢復(fù)能力。

4.3.軟件的很多功能的實(shí)現(xiàn)是有很多隱含的條件的，在健壯

性測(cè)試中，要檢查當(dāng)這些條件不滿足的時(shí)候的反應(yīng)。例如：目前大多數(shù)3G智能手機(jī)，與各電信運(yùn)營(yíng)商形成利益捆綁，每款手機(jī)支持特定的電信運(yùn)營(yíng)商提供的通信服務(wù)，其它運(yùn)營(yíng)商提供的服務(wù)則被拒之門外。當(dāng)使用移動(dòng)SIM卡安裝在只支持聯(lián)通通信服務(wù)的3G手機(jī)上，關(guān)注該手機(jī)表現(xiàn)：是否在執(zhí)行自動(dòng)更新時(shí)重啟？還是執(zhí)行自動(dòng)更新后提示不支持移動(dòng)運(yùn)營(yíng)通信服務(wù)：SIM card not supported, emergency calls only？

例如：在做完常溫包裝跌落測(cè)試后，再測(cè)試機(jī)芯的讀碟能力，讀取偏芯碟、面振碟、偏重心碟、刮痕碟、指紋碟等等碟片，與未做跌落測(cè)試前讀碟能力進(jìn)行比較。如果讀碟能力比以前更差，則考慮改進(jìn)措施：軟件適當(dāng)增加錄軌時(shí)間或機(jī)芯托盤加固等。

第二篇：測(cè)試協(xié)議

______集成電路設(shè)計(jì)研究中心（甲方）和_______公司（乙方）經(jīng)友好協(xié)商，對(duì)__________項(xiàng)目的有關(guān)測(cè)試技術(shù)指標(biāo)問(wèn)題達(dá)成如下協(xié)議：

一、乙方應(yīng)在本協(xié)議簽定_____天內(nèi)將芯片資料，測(cè)試碼提供給甲方。

二、甲方在乙方提供封裝好的芯片后_____天內(nèi)，將測(cè)試分析結(jié)果提交給乙方。

三、具體測(cè)試要求：

甲方按乙方要求，在測(cè)試時(shí)將pa4、pa5、pa6、pa7端經(jīng)3.3k電阻上拉至5伏。

甲方在測(cè)試分析時(shí)，應(yīng)讓______芯片工作在5v。

乙方提供____功能測(cè)試碼文件（t______t格式）兩份。

甲方使用乙方提供的功能測(cè)試碼文件，在1mhz下對(duì)樣品進(jìn)行測(cè)試分析。

乙方認(rèn)為正常情況下，樣品的功能測(cè)試應(yīng)全部通過(guò)，參數(shù)測(cè)試結(jié)果應(yīng)在下表給定的范圍內(nèi)。

測(cè)試參數(shù)（常溫）測(cè)試條件 最大值 典型值 最大值 單位 ?

靜態(tài)工作電流 vdd＝5v ua ?

動(dòng)態(tài)工作電流 vdd＝5v ua ?

輸入高電平電壓 vdd＝5v v ?

輸入低電平電壓 vdd＝5v v ?

輸入高電平電流 vdd＝5v，vih＝5v ua ?

輸入低電平電流 vdd＝5v，vil＝0v ua ?

輸出高電平電壓 vdd＝5v v ?

輸出低電平電壓 vdd＝5v v ?

輸出高電平電流 vdd＝5v，voh＝4.2v ma ?

輸出低電平電流 vdd＝5v，vol＝0.4v ma

如乙方提供的樣品中有____%滿足以上要求，甲方應(yīng)向乙方出具一份測(cè)試分析報(bào)告，并以附件形式（磁盤文件，t______t格式）提供詳細(xì)的測(cè)試數(shù)據(jù)。

乙方若對(duì)甲方出具的測(cè)試分析報(bào)告及測(cè)試數(shù)據(jù)有任何疑問(wèn)，必須在甲方測(cè)試分析工作完成之日起的兩個(gè)月內(nèi)向甲方提出。

乙方若須增加測(cè)試分析內(nèi)容，必須與甲方協(xié)商解決。

乙方：________________

第三篇：HTTP協(xié)議學(xué)習(xí)心得體會(huì)

HTTP協(xié)議學(xué)習(xí)心得體會(huì)

HTTP(HyperText Transfer Protocol)

====================================

是TCP/IP協(xié)議集中的一個(gè)應(yīng)用層協(xié)議，用于定義瀏覽器和Web服務(wù)器之間交換數(shù)據(jù)的過(guò)程以及數(shù)據(jù)本身的格式?，F(xiàn)在被廣泛使用的是HTTP1.1，相對(duì)于1.0，1.1的最大特點(diǎn)是支持持續(xù)連接。

基于HTTP1.0協(xié)議的客戶機(jī)與服務(wù)器的信息交換過(guò)程包括四個(gè)步驟：建立連接；發(fā)送請(qǐng)求信息；回送響應(yīng)信息；關(guān)閉連接。

通信過(guò)程總是通過(guò)瀏覽器發(fā)送請(qǐng)求來(lái)啟動(dòng)的，Web服務(wù)器則是被動(dòng)地對(duì)這些請(qǐng)求作出響應(yīng)。HTTP協(xié)議是無(wú)狀態(tài)的。

HTTP1.1與HTTP1.0的比較

------

HTTP1.0規(guī)定瀏覽器與服務(wù)器只保持短暫的連接，瀏覽器的每次請(qǐng)求都需要與服務(wù)器建立一個(gè)TCP連接，服務(wù)器完成請(qǐng)求處理后立即斷開(kāi)TCP連接。服務(wù)器不跟蹤每個(gè)客戶機(jī)，也不記錄過(guò)去的請(qǐng)求。為了克服HTTP1.0的這個(gè)缺陷，HTTP1.1支持持久連接，在一個(gè)TCP連接上可以傳送多個(gè)HTTP請(qǐng)求和響應(yīng)，減少了建立和關(guān)閉連接的消耗和延遲。HTTP1.1還允許客戶端不用等待上一次請(qǐng)求結(jié)果返回，就可以發(fā)送下一次請(qǐng)求，但服務(wù)器端必須按照接受到客戶端請(qǐng)求的先后順序依次回送響應(yīng)結(jié)果，以保證客戶端能夠區(qū)分出每次請(qǐng)求的響應(yīng)內(nèi)容。

HTTP1.1還增加了host請(qǐng)求頭字段，用于明確表示訪問(wèn)服務(wù)器上的哪個(gè)web站點(diǎn)，可以在一個(gè)IP地址和端口號(hào)上使用不同的主機(jī)名來(lái)創(chuàng)建多個(gè)虛擬web站點(diǎn)。HTTP1.1還有keep-alive請(qǐng)求頭來(lái)支持持續(xù)連接。

HTTP消息的格式

-----------------------

一個(gè)完整的請(qǐng)求消息包括：一個(gè)請(qǐng)求行，若干消息頭，以及實(shí)體內(nèi)容，其中消息頭和實(shí)體內(nèi)容都是可選的。消息頭和實(shí)體內(nèi)容之間要用空行隔開(kāi)。瀏覽器使用GET方式的請(qǐng)求消息可以放松不含實(shí)體內(nèi)容的請(qǐng)求消息。只有使用POST, PUT, DELETE方式的請(qǐng)求消息中才可以包含實(shí)體內(nèi)容。

Hypertext Transfer Protocol

GET / HTTP/1.1rn

Request Method: GET

Request URI: /

Request Version: HTTP/1.1

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-ms-application, application/vnd.ms-xpsdocument, application/xaml+xml, application/x-ms-xbap,application/x-shockwave-flash, application/vnd.ms-excel, application/vn

Accept-Language: zh-cnrn

UA-CPU: x86rn

Accept-Encoding: gzip, deflatern

User-Agent: Mozilla/4.0(compatible;MSIE 7.0;Windows NT 6.0;SLCC1;.NET CLR

2.0.50727;.NET CLR 3.0.04506)rn

Connection: Keep-Alivern

rn

一個(gè)完整的響應(yīng)消息包括：一個(gè)狀態(tài)行，若干消息頭，以及實(shí)體內(nèi)容。同樣，消息頭和實(shí)體內(nèi)容都是可選的。消息頭和實(shí)體內(nèi)容之間要用空行隔開(kāi)。消息響應(yīng)的實(shí)體內(nèi)容就是網(wǎng)頁(yè)文檔的內(nèi)容。

Hypertext Transfer Protocol

HTTP/1.1 200 OKrn

Request Version: HTTP/1.1

Response Code: 200

Cache-Control: privatern

Content-Type: text/html;charset=UTF-8rn

Set-Cookie:

PREF=ID=7f53f6f0b1511417:NW=1:TM=1205568884:LM=1205568884:S=zHreYqNC-Z3rmOc6;expires=Mon, 15-Mar-2010 08:14:44 GMT;path=/;domain=.google.cnrn

Content-Encoding: gziprn

Server: gwsrn

Transfer-Encoding: chunkedrn

Date: Sat, 15 Mar 2008 08:14:44 GMTrn

rn

HTTP chunked response

Data chunk(1025 octets)

Chunk size: 1025 octets

Data(1025 bytes)

HTTP消息頭

----------------

HTTP請(qǐng)求和響應(yīng)都使用消息頭來(lái)描述HTTP消息本身的信息，可以實(shí)現(xiàn)HTTP客戶機(jī)與服務(wù)器之間的條件請(qǐng)求和應(yīng)答。

消息頭可以分為：通用消息頭，請(qǐng)求頭，響應(yīng)頭，實(shí)體頭四類。

請(qǐng)求行與狀態(tài)行

-----------------------

請(qǐng)求消息的請(qǐng)求行包括三個(gè)部分：請(qǐng)求方式，資源路徑，以及使用的HTTP版本。如：GET /

HTTP/1.1rn。

響應(yīng)消息的狀態(tài)行包括三個(gè)部分：HTTP協(xié)議的版本號(hào)，一個(gè)表示成功或者失敗的整數(shù)代碼（狀態(tài)碼）和對(duì)狀態(tài)碼進(jìn)行描述的文本信息。如：HTTP/1.1 200 OKrn。

使用GET和POST方式傳遞參數(shù)

-------------

在URL地址后面可以附加一些參數(shù)，每個(gè)參數(shù)由參數(shù)名和參數(shù)值組成，例如：當(dāng)使用GET方式提交表單內(nèi)容時(shí)，瀏覽器將各個(gè)表單字段元素及其數(shù)據(jù)按照URL參數(shù)的格式附加在請(qǐng)求行中的資源路徑后面。使用GET方式傳送的數(shù)據(jù)量有限制，一般在1KB以下。

當(dāng)使用POST方式提交表單內(nèi)容時(shí)，瀏覽器將個(gè)表單字段元素及其數(shù)據(jù)作為HTTP消息的實(shí)體內(nèi)容發(fā)送給服務(wù)器。因此數(shù)據(jù)量可以比GET方式大的多。使用POST方式時(shí)，還必須將Content-Type消息頭設(shè)置為“application/x-www-form-urlencoded”，將Content-length消息頭設(shè)置為實(shí)體內(nèi)容的長(zhǎng)度。

響應(yīng)狀態(tài)碼

---------------

1.100~199: 成功接受請(qǐng)求，要求客戶端繼續(xù)提交下一次請(qǐng)求才能完成整個(gè)處理過(guò)程。

2.200~299: 成功接受請(qǐng)求并已完成整個(gè)處理過(guò)程。

3.300~399: 為完成請(qǐng)求，客戶端需要進(jìn)一步細(xì)化請(qǐng)求。

4.400~499: 客戶端的請(qǐng)求有錯(cuò)誤。

5.500~599: 服務(wù)器段出現(xiàn)錯(cuò)誤。

通用信息頭

==============

即能用于請(qǐng)求消息，也能用于響應(yīng)消息，包括一些與被傳輸?shù)膶?shí)體內(nèi)容沒(méi)有關(guān)系的常用消息頭字段。

1.Cache-Control

2.Connection

3.Date

4.Pragma

5.Trailer

6.Transfer-Encoding

7.Upgrade

8.Via

9.Warning

Cache-Control

--------------------

如果位于請(qǐng)求消息頭，用于通知位于客戶機(jī)和服務(wù)之間的代理服務(wù)器如何使用已緩存的頁(yè)面，可以取值為：no-cache, no-store, max-age, max-stale, min-fresh, no-transform, only-if-cached等。

如果位于響應(yīng)消息頭，用于通知客戶機(jī)和代理服務(wù)器如何緩存該頁(yè)面，可以取值為：public, private, no-cache, no-store, no-transform, must-revalidate, proxy-revalidate, max-age, s-maxage等。

Connection

---------------

用于指定處理完本次請(qǐng)求/響應(yīng)后，客戶端與服務(wù)器是否還要繼續(xù)保持連接。如果為Keep-Alive，則保持連接，如果為close，則關(guān)閉。HTTP1.1默認(rèn)采用持久連接。

Date

---------

表示HTTP消息產(chǎn)生的當(dāng)前時(shí)間。服務(wù)器回送的正常響應(yīng)消息中，應(yīng)該總是設(shè)置Date頭字段。如果客戶機(jī)發(fā)送的請(qǐng)求消息中包含有實(shí)體內(nèi)容，也要設(shè)置Date。

Pragma

------------

只能固定為no-cache.Trailer

-----------

一些頭字段可以放置在整個(gè)HTTP消息的尾部。

Transfer-Encoding

---------------------

指定傳輸編碼方式，目前標(biāo)準(zhǔn)的設(shè)置值只有chunked，用于把整個(gè)消息分成一連串的分段后進(jìn)行傳輸。

Upgrade

------------

允許客戶機(jī)指定它所支持并希望將當(dāng)前協(xié)議切換到的通信協(xié)議。

Via

-----

用于指定HTTP消息所途徑的中介代理服務(wù)器名稱和所使用的協(xié)議。

請(qǐng)求頭

=========

客戶端可以接受的數(shù)據(jù)類型，壓縮方法，語(yǔ)言，以及發(fā)出請(qǐng)求的超鏈接所屬頁(yè)面的URL地址等信息。Accept：指出客戶端程序能夠處理的MIME類型。

Accept-Charset：用于指出客戶端程序可以使用的字符集。

Accept-Encoding：客戶機(jī)能夠進(jìn)行解碼的數(shù)據(jù)編碼方式。

Accept-Language：指定客戶機(jī)期望服務(wù)器返回哪個(gè)國(guó)家語(yǔ)言的文檔。

Authorization：兩種認(rèn)證方式BASIC，和DIGEST.Except:

From:

Host: 指定資源所在的主機(jī)號(hào)和端口號(hào)。HTTP1.1中每個(gè)請(qǐng)求消息中都必須包含Host請(qǐng)求字段。If-Match:

If-Modified-Since:

If-None-Match:

If-Range

If-Unmodified-Since

Max-Forwards:

Proxy-Authorization:

Range:

Referer: 當(dāng)單擊另一個(gè)網(wǎng)頁(yè)上的超鏈接時(shí)發(fā)出的請(qǐng)求在Referer字段中指定URL。

TE：

User-Agent:

響應(yīng)頭

==========

Accept-Range, Age, Etag,Location: 用于通知客戶機(jī)應(yīng)當(dāng)?shù)侥膫€(gè)新的地址去獲取文檔。狀態(tài)碼為300~399的響應(yīng)消息都應(yīng)該使用Location字段將新的文檔地址告訴客戶機(jī)，以便客戶機(jī)自動(dòng)重新連接到新地址并檢索新文檔。使用Location頭的HTTP消息不應(yīng)該有實(shí)體內(nèi)容。所以，HTTP消息頭中不能同時(shí)出現(xiàn)Location和Content-Type這兩個(gè)頭字段。

Proxy-Authenticate，Retry-After, Server, Vary, WWW-Authenticate。

實(shí)體頭

========

是實(shí)體內(nèi)容的元信息，描述了實(shí)體內(nèi)容的屬性，包括實(shí)體信息類型、長(zhǎng)度、壓縮方法、最后一次修改時(shí)間、數(shù)據(jù)有效期等。

Allow: 指定客戶端請(qǐng)求的資源所支持的請(qǐng)求方法（如GET，POST等）。

Content-Encoding: 指定實(shí)體內(nèi)容的壓縮編碼方式。

Content-Language:

Content-Length: 用于表示實(shí)體內(nèi)容的長(zhǎng)度（字節(jié)數(shù)），瀏覽器與Web服務(wù)器之間使用持久連接時(shí)，這個(gè)字段在非Chunked傳輸編碼的響應(yīng)消息中是必不可少的。

Content-Location: 指定響應(yīng)消息中所封裝的實(shí)體內(nèi)容的實(shí)際位置路徑。

Content-MD5, Content-Range, Content-Type

Expires: 指定當(dāng)前文檔應(yīng)該在什么時(shí)候被認(rèn)為過(guò)期，瀏覽器到哪個(gè)時(shí)候以后不能再繼續(xù)使用本地緩存，而是在有需要時(shí)應(yīng)該像服務(wù)器發(fā)出新的請(qǐng)求訪問(wèn)。

Last-Modified：文檔的最后更改時(shí)間。

擴(kuò)展頭

========

現(xiàn)在流行的瀏覽器實(shí)際上都支持Cookie，Set-Cookie，Refresh和Content-Disposition等幾個(gè)常用的擴(kuò)展頭字段。

Refresh: 告訴瀏覽器多少秒后自動(dòng)刷新頁(yè)面。

第四篇：產(chǎn)品測(cè)試保密協(xié)議

產(chǎn)品測(cè)試保密協(xié)議

甲方：北京交通大學(xué)信息中心

法人代表：

通訊地址：

郵編：

電話：

傳真：

乙方：

法人代表：

通訊地址：

郵編：

電話：

傳真：

甲、乙雙方經(jīng)友好協(xié)商，在平等、自愿、誠(chéng)實(shí)、信任、互利互惠的基礎(chǔ)上，根據(jù)《中華人民共和國(guó)合同法》及相關(guān)法律，就乙方的產(chǎn)品術(shù)事宜達(dá)成如下保密協(xié)議：

一、定義

專有信息：本協(xié)議所稱的“專有信息”是指以下信息的總稱：

乙方的產(chǎn)品在甲方的機(jī)房中測(cè)試的整個(gè)過(guò)程中（包括事前、事中、事后），甲乙雙方為了使測(cè)試能夠順利進(jìn)行并最終得出測(cè)試結(jié)論而互相向?qū)Ψ教峁┑男?/p>

息，包括：（1）乙方提供給甲方的有關(guān)測(cè)試產(chǎn)品的技術(shù)秘密、設(shè)備設(shè)置參數(shù)秘密

以及相關(guān)的其他信息；（2）甲方向乙方提供的為測(cè)試所必須的各種信息。

乙方被測(cè)產(chǎn)品在測(cè)試過(guò)程中所收集到的甲方的各種信息、數(shù)據(jù)。

附件（如果有附件的話）中專門規(guī)定的其他信息、數(shù)據(jù)。

二、權(quán)利保證

乙方保證其向甲方透露的專有信息不侵犯任何第三方的智慧財(cái)產(chǎn)權(quán)及其他利益。

三、保密義務(wù)

3.1甲方同意嚴(yán)格控制乙方所透露的專有信息，保護(hù)的程度不能低于甲方保護(hù)自己的專有信息。

3.2乙方保證采取所有必要的方法對(duì)甲方所提供的專有信息以及在測(cè)試過(guò)程中所獲得的甲方的專有信息進(jìn)行保密，包括避免非授權(quán)透露、使用或復(fù)制專有信息。

3.3甲乙雙方保證不向任何第三方透露本協(xié)議的存在或本協(xié)議的任何內(nèi)容。

四、使用方式和不使用的義務(wù)

4.1甲乙雙方同意如下內(nèi)容：

4.1.1乙方向甲方所透露的專有信息只能被甲方用于評(píng)價(jià)所測(cè)試產(chǎn)品的目的，而不得用于其它任何目的；

4.1.2乙方所獲得的甲方的專有信息也只能被乙方用于評(píng)價(jià)所測(cè)試產(chǎn)品的目的，而不得用于其它任何目的；

4.2甲乙雙方應(yīng)當(dāng)告知并以適當(dāng)方式要求其參與本項(xiàng)工作之雇員遵守本協(xié)議之規(guī)定，若某一方參與本項(xiàng)工作之雇員違反本協(xié)議規(guī)定，則相應(yīng)方應(yīng)承擔(dān)全部的連帶責(zé)任。

五、甲方專有信息的交回

5.1沒(méi)有甲方的許可，乙方不得擅自丟棄或處理任何測(cè)試中所產(chǎn)生或獲得的專有信息；

5.2乙方有按照甲方要求在測(cè)試設(shè)備中銷毀測(cè)試中所產(chǎn)生或獲得的專有信息的義務(wù)，并同意實(shí)施過(guò)程接受甲方的監(jiān)督。

六、救濟(jì)方法

6.1雙方承認(rèn)并同意如下內(nèi)容：

6.1.1甲乙雙方為了使測(cè)試能夠順利進(jìn)行而向?qū)Ψ酵嘎兜膶Ｓ行畔⑹怯袃r(jià)

值的秘密；

6.1.2遵守本協(xié)議的條款和條件對(duì)于保護(hù)專有信息的秘密是有必要的；

6.1.3所有違約對(duì)該專有信息進(jìn)行未被授權(quán)的透露或使用將對(duì)甲乙雙方造

成不可挽回的和持續(xù)的損害。

6.2如果發(fā)生乙方違約，雙方同意如下內(nèi)容：

6.2.1乙方應(yīng)當(dāng)按照甲方的指示采取有效的方法對(duì)該專有信息進(jìn)行保密，所需費(fèi)用由乙方承擔(dān)；

6.2.2乙方應(yīng)當(dāng)賠償甲方因違約而造成的所有損失，包括（但不限于）：法

院訴訟的費(fèi)用、合理的律師酬金和費(fèi)用、全部直接或間接的損失或傷害等等。

七、保密期限

7.1自本協(xié)議生效之日起，雙方的交流合作都要符合本協(xié)議的條款。

7.2甲乙雙方必須按照本協(xié)議所承擔(dān)的保密義務(wù)對(duì)在結(jié)束協(xié)議前收到或獲得的對(duì)方的專有信息進(jìn)行保密，保密期限不受本協(xié)議有效期的限制。

7.3保密期限自本協(xié)議生效之日起，三年的時(shí)間。

八、適用法律：

本協(xié)議受中華人民共和國(guó)法律管轄，并在所有方面依其進(jìn)行解釋。

九、爭(zhēng)議的解決

因本協(xié)議而產(chǎn)生或與本協(xié)議有關(guān)的任何爭(zhēng)議，應(yīng)通過(guò)友好協(xié)商解決。如果任何爭(zhēng)議的一方向另一方發(fā)出協(xié)商解決爭(zhēng)議的書(shū)面通知后三十（30）天內(nèi)通過(guò)友好協(xié)商仍無(wú)法解決，則任一方可將該爭(zhēng)議提交北京市裁委員會(huì)，按其當(dāng)時(shí)有效的仲裁規(guī)則通過(guò)仲裁解決。

十、生效及其它事項(xiàng)

10.1本協(xié)議一式貳份，甲乙雙方各執(zhí)一份。

10.2本協(xié)定為中文文本。

10.3本協(xié)定簽訂于2009年4月28日，于簽訂之日生效。任何于協(xié)議簽訂前經(jīng)雙方協(xié)商但未記載于本協(xié)議中之事項(xiàng)，對(duì)雙方皆無(wú)約束力。

10.4本協(xié)議及其附件（如果有附件的話）對(duì)雙方具有同等法律約束力，若附件與本協(xié)議相抵觸時(shí)，以本協(xié)議為準(zhǔn)。

10.5未盡事宜由雙方友好協(xié)商解決。

甲方：北京交通大學(xué)信息中心

代表人：

地址：

乙方：

代表人：

地址：

第五篇：測(cè)試心得體會(huì)

經(jīng)過(guò)幾周的測(cè)試工作，對(duì)測(cè)試工作已經(jīng)有所了解。現(xiàn)結(jié)合之前的測(cè)試工作情況和剛剛發(fā)布的網(wǎng)站測(cè)試方法，對(duì)測(cè)試工作進(jìn)行回顧總結(jié)以及對(duì)之后的測(cè)試工作進(jìn)行規(guī)劃。

一.測(cè)試流程

剛接觸測(cè)試工作時(shí)由于對(duì)工作和車連我平臺(tái)的不熟悉，工作情況僅限于對(duì)平臺(tái)的了解以及匯報(bào)了解過(guò)程中所發(fā)現(xiàn)的比較明顯的錯(cuò)誤。之后的時(shí)間里雖然也慢慢發(fā)現(xiàn)平臺(tái)內(nèi)部功能的錯(cuò)誤，但測(cè)試流程太過(guò)于雜亂無(wú)章?，F(xiàn)對(duì)測(cè)試流程根據(jù)平臺(tái)模塊功能進(jìn)行劃分，并對(duì)照網(wǎng)站測(cè)試方法的測(cè)試執(zhí)行標(biāo)準(zhǔn)執(zhí)行，形成周期性的測(cè)試。1.會(huì)員注冊(cè)

定期進(jìn)行新會(huì)員注冊(cè)測(cè)試，查看是否可以進(jìn)行正常注冊(cè)是否有錯(cuò)誤注冊(cè)行為即用戶名是否會(huì)重復(fù)、注冊(cè)資料是否有正確記錄、注冊(cè)時(shí)開(kāi)通的功能是否能正確使用如郵箱綁定，手機(jī)綁定、注冊(cè)提示是否有誤等。2.會(huì)員資料管理

查看會(huì)員資料是否有正確顯示、是否能正常修改。查看開(kāi)通的功能能否正常使用。3.頁(yè)面瀏覽

查看頁(yè)面瀏覽過(guò)程中是否出現(xiàn)錯(cuò)誤或者警告提示，查看頁(yè)面上是否存在有非法或者無(wú)效的鏈接，查看頁(yè)面上是否存在無(wú)效的圖片或者非法的字符。4.導(dǎo)航系統(tǒng)

查看頁(yè)面的導(dǎo)航功能是否正常，搜導(dǎo)向的頁(yè)面是否正確無(wú)誤，是否有無(wú)效的導(dǎo)航鍵，是否有缺失或者多余的導(dǎo)航鍵，搜索功能能否正常工作，產(chǎn)品篩選過(guò)濾功能能否正常運(yùn)行。5.商品查看

查看是否有重復(fù)多余的商品，商品的歸類是否正確，商品的價(jià)格、圖片、說(shuō)明是否正確，查看是否有無(wú)效的商品上架、有關(guān)于商品的功能例如商品的收藏、購(gòu)買記錄查看等功能能否正常使用。6.支付系統(tǒng)

交易記錄是否能正常查看和顯示，是否能正常的購(gòu)買商品和支付，查看購(gòu)

物車功能能否正常使用。

二．測(cè)試標(biāo)準(zhǔn)

之前的測(cè)試過(guò)程并沒(méi)有對(duì)預(yù)測(cè)結(jié)果有任何標(biāo)準(zhǔn)性的限制，導(dǎo)致測(cè)試的結(jié)果無(wú)法達(dá)到一個(gè)標(biāo)準(zhǔn)化。現(xiàn)由我和小潘一起規(guī)定了網(wǎng)站測(cè)試方法，以后的測(cè)試標(biāo)準(zhǔn)將根據(jù)網(wǎng)站測(cè)試方法進(jìn)行實(shí)施。

測(cè)試標(biāo)準(zhǔn)詳見(jiàn)網(wǎng)站測(cè)試方法 三．測(cè)試結(jié)果匯報(bào)

根據(jù)技術(shù)部對(duì)于項(xiàng)目模塊改進(jìn)說(shuō)明書(shū)的反饋意見(jiàn)，發(fā)現(xiàn)之前提交的項(xiàng)目模塊改進(jìn)說(shuō)明書(shū)存在一定問(wèn)題就是對(duì)于問(wèn)題的說(shuō)明和修改的意見(jiàn)描述的不夠準(zhǔn)確導(dǎo)致技術(shù)部無(wú)法對(duì)問(wèn)題做出相應(yīng)的處理或處理結(jié)果較實(shí)際比較不理想。

總結(jié)之前的匯報(bào)情況對(duì)項(xiàng)目模塊改進(jìn)說(shuō)明書(shū)中的問(wèn)題描述要求盡量附上截圖，以便說(shuō)明問(wèn)題的具體情況和出現(xiàn)錯(cuò)誤的位置。對(duì)于改進(jìn)意見(jiàn)需做詳細(xì)的說(shuō)明，做到寫明修改內(nèi)容、修改要求以及修改所要達(dá)到的效果。

由于其他的平臺(tái)的功能建設(shè)還不夠齊全如微網(wǎng)、百科，這里先暫時(shí)不做系統(tǒng)性的規(guī)劃，對(duì)于這份總結(jié)規(guī)劃還存在許多不足之處在以后的工作中會(huì)逐漸完善。