測試項目描述怎麼寫

我本身是做軟件行業的，已經做了七八年了，給你一知些建議，僅供參考~

① 項目介紹的部分，要介紹清楚項目內容，並突出軟件測試在項目各階段中的位置，例如，項目的開發模式如果是V模型，那麼軟件測試伴隨每個開發階段道，包括設計、編碼等等。

② 項目經驗這部分需要詳細考慮了，分為兩個方面，一、測試技術；二、角色職能；

· 測試技術

項目當中使用到的技術一定要簡明易懂版的提出來，例如是否用到自動化測試，性能測試，以及測試的OS是Linux還是Windows之類的，用到的數據庫是MySQL還是Oracle。

· 角色職能

在項目當中，你扮演的角色是什麼。如果是測試工程師，那麼有沒權有妥善的完成測試設計和測試執行；如果是高級工程師，有沒有做好測試分析工作，有沒有很好的理解需求等。

希望對你有所幫助，有疑問的地方歡迎探討。

1.首先進行介紹項目最近測試的項目是一個B/S架構的Web項目，運營模式類似於天貓，京東這些B2C類型網站。

項目系統由前台和後台兩部分構成。前台面向購物用户，包括xxx等系統模塊。

後台面向經營商家，包括xxxx等系統模塊。2.説明自己負責測試的模塊我在項目中主要負責前xxx等相關模塊測試。

3.針對部分模塊展開説明（挑選有代表性）對測試的模塊的作用及相關 業務進行説明。這是我在黑馬程序員學習測試的筆記，現在已經畢業了。

月薪12k左右，真心感謝黑馬。

能表達得有條理就可以了。

不必介意格式。總結無非就是總結經驗，吸取教訓咯，本人什麼時候參加了什麼項目的測試 這個項目是幹什麼的 我在項目組中做了什麼 遇到了什麼困難 如何解決的 通過這個項目我學習到了什麼 我要感謝誰誰誰 我以後要在什麼方面加強 此致 敬禮 附件一 X項目的測試工作到今天算是全部結束了，除了後期維護必要的一些迴歸測試和用户使用手冊的撰寫外，整個測試階段告一段落。

從10月底進入項目，在測試經理的幫助下開始學着寫項目測試文檔，到根據文檔的每日功能測試及迴歸測試，再到整個項目進行迭代後對測試文檔的重新架構及整體迴歸測試，直至最後的統一交付測試，我個人提交總BUG數為244個。在這244個BUG的提交和迴歸過程中，在測試文檔的寫作及修訂中，我對整個項目的邏輯及架構逐步清晰，對項目之間所需的複雜交互的認識也越發深入，對項目功能邏輯上的測試如何進行也更加明晰。

下面我簡單談談對項目的認識、經驗和教訓，以及對未來改進的一些建議！一、對項目的認識 進入這個項目是在今年十月底，當時測試經理和C已經把Setting（當時是Admin）部分的測試結束了，所以我直接開始接着D的測試文檔繼續往下寫（當時是從Revenue的Report部分開始，即現在的Report模塊）。因為跳過了邏輯部分，所以對整個項目邏輯理解很不夠，開始寫的測試文檔也非常淺顯，就是描述了一下頁面佈局。

這裏我的感覺是，測試人員進入項目初期，項目經理有必要指派專門人員與測試人員溝通，幫助其理清整個項目的順序邏輯。當時C簡單地跟我介紹了一下整個項目，我的感覺是溝通不夠，對邏輯理解比較欠缺。

Report部分寫完，就直接開始測試——用自己剛寫完的文檔進行測試，效果顯然不夠理想。因為測試人員剛進行該模塊測試文檔的編撰，再讓他對該模塊進行測試，這樣做的一個後果就是，測試人員會先入為主地覺得自己不需要按部就班地照着文檔進行測試（因為文檔就是自己寫的）。

還有一個很大的問題就是，倘若測試人員在文檔撰寫上存在嚴重漏洞的話，他在測試時仍然不可能發現自己的漏洞所在。所以我建議測試文檔撰寫人員與測試人員最好不要是同一個人，這樣有助於發現測試文檔構建的漏洞。

測試完Report後，緊接着開始進行Expense模塊測試文檔的撰寫。這時我開始接觸到一些邏輯，即Expense與Setting部分聯繫的邏輯。

這時遇到的問題最多最雜，隨時隨地都需要與C，甚至項目經理進行溝通。由於之前對主功能（Setting部分）的不熟悉，這種一邊溝通一邊撰寫的測試文檔可以説是漏洞百出。

由於項目時間也比較緊，我需要在一週內完成整個Expense模塊的測試文檔，所以最終完成的文檔很不理想。這裏我覺得還是之前溝通不到位的問題，應該有一個對整個項目非常熟悉的人來幫助測試人員理清整個項目邏輯再進行測試文檔撰寫，而不是一開始就撰寫測試文檔。

接着就是根據自己撰寫的Expense文檔對Expense模塊進行測試，效果也不夠理想。這裏我還有一個建議就是，如果測試人員在初始進入項目時沒有得到及時溝通，至少需要給他一週時間先對主功能（即Setting部分）進行完整測試，對照需求手冊及主功能發現的BUG，對主功能進行深入理解。

Expense測試完成後，開始對整個項目進行迴歸測試。在這個過程中，我逐漸理清了整個項目的邏輯，也開始試圖修改以前的文檔。

但由於文檔量太大，文檔結構不夠清晰，時間也比較緊，修改難於進行。大部分原因是我經驗不足造成的，之前撰寫測試文檔時，思路過於混亂，想到哪裏寫到哪裏，導致最後文檔難於維護和修改。

迴歸測試結束後，整個系統邏輯已經比較清晰。這時項目進行新一輪的迭代，用户需求改了很多，其中包括增加、修改大量功能、名稱，以及對整個系統結構進行重構。

這對測試文檔而言改動點非常多（包括結構順序改變、測試編號訂正、功能模塊名稱修改等），而且需求文檔並未因此變化，造成最後測試文檔與需求文檔的不匹配。這是一個協調的過程，系統迭代後，需求文檔應及時隨着系統進行修改。

迭代開發過程中，測試基本上是項目改到哪就測到哪，這裏面最大的問題不是發現修改模塊的BUG，而是發現修改該模塊後牽涉到的其它模塊出現的BUG。這種連帶BUG的產生可以説是防不勝防，讓測試人員苦惱不已。

到現在我也沒想出解決辦法，只能説對模塊之間的聯繫及交互邏輯理解仍需加深。迭代開發後期，開始對整個系統從頭回歸一遍，這時候又發現了許多以前從未出現的BUG。

這個時期大家都很煩躁困惑，曾經運轉良好的頁面，突然出現存儲問題；曾經更新正常的功能，突然無法更新；曾經顯示正常的Excel，突然顯示錯誤… …這些都讓人苦惱，當然，這些應該都是正常現象。測試人員在測試後期尤其需要提高警惕，不能漏過任何一個功能點，更不能忽略任何一次貌似無用的查詢、翻頁、按鍵。

最後，是大家一起進行的交付測試，人員包括了所有的編程人員及測試人員。這期間，除了對基本功能的迴歸測試外，還包括了併發測試及性能測試（這主要是編程人員在做），除此之外，我將過去提交修正過的所有BUG重新驗。

1 簡介 1.1編寫目的 本測試報告為安天科技項目的測試報告，目的在於總結測試階段的測試以及分析測試結果，描述系統是否符合ATKJ-用户需求説明書。

預期參考人員包括用户、測試人員、開發人員、項目管理者、質量管理人員和需要閲讀本報告的高層經理。TestAge 中國軟件測試時代！T/d5sPAl 1.2項目背景 本產品是為天安科技有限公司開發的外貿企業管理系統。

本產品依據EasyTrade基礎模型研發，形成一個完善的以業務管理系統為核心，以基礎信息、系統維護支持的外貿企業管理系統。主要功能是對該公司生產銷售過程，財務過程實現信息化管理。

1.3系統簡介 1.4術語和縮寫詞 無 1.5參考資料 1、安天科技項目需求與設計、2、安天科技項目測試計劃、3、安天科技項目測試用例、4、安天科技項目缺陷報告單、系統測試報告 5、公司CMMI體系文件《TS002_測試報告》 2 測試概要 2.1測試用例設計 本次測試用例設計主要採用黑盒測試方法，功能模塊及集成測試採用的具體方法有等價類劃分、邊界值劃分、正交分解、因果圖分析和錯誤猜測。在系統測試時依據業務流程採用迴歸測試。

2.2測試環境與配置 測試服務器配置： 服務器地址：10.0.0.39 操作系統：Windows XP Professional SP2 CPU: Intel(R) Pentium(R)4 CPU 3.00HZ 硬盤可用空間：74GB 數據庫：Microsoft SQL Server 8.00.2039 應用服務器：EasyTrade服務器 測試對象：EasyTradeS3.exe 缺陷工具：Mercury Interactive TD8.0 SP2 2.3測試方法（和工具） 主要是黑盒測試，測試的重點集中在業務流程、數據提取和各功能模塊間的接口。其中單元測試由開發人員直接完成；功能模塊採用黑盒測試的常用方法；集成測試模塊採用非漸增式測試，偏重系統的接口和數據提取方面；系統測試主要體現在業務流程的測試，主要採用迴歸測試 3 測試結果及缺陷分析 3.1測試執行情況與記錄 3.1.1測試組織 3j5Ylc i2r/{8TestAge 中國軟件測試時代 `4Nri0N,_$T9X測試經理：劉義照TestAge 中國軟件測試時代m!iL)S"_I­S 主要測試人員：李志學 TestAge 中國軟件測試時代（tWA ]3lh$t#K陳龍 參與測試人員：張士紅（模塊測試用例編寫） 3.1.2測試時間 測試類型 實際開始時間 實際結束時間 總工作日 功能測試 貿易管理 2008-04-14 2008-04-15 2 生產管理 2008-04-14 2008-04-15 2 採購管理 2008-04-14 2008-04-16 3 財務管理 2008-04-15 2008-04-16 2 發運單 2008-04-15 2008-04-16 2 集成測試 2008-04-16 2008-04-18 2 系統測試 2008-04-18 2008-04-24 6 安裝測試 2008-04-25 2008-04-25 1 3.1.3測試版本 版本號 修訂日期 修訂人 修訂內容説明 EASYTRADE 2008.04.16 劉義照 EASYTRADE3 2008.04.26 劉義照 3.2覆蓋分析 3.2.1需求覆蓋 功能模塊 功能名稱 編號 是否通過 備註 基礎資料 （JC） 國家代碼 JC01 Y 世界港口 JC02 Y 貨幣設定 JC03 Y 計量單位 JC04 Y 退税率設定 JC05 Y 附件類別 JC06 Y 材料類別 JC07 Y 單據編號 JC08 Y 工藝説明 JC09 Y 線説明 JC10 Y 銀行利息設定 JC11 Y 貿易管理 （MY） 客户資料 MY01 Y 款式工藝 MY02 Y ▲ 客户訂單 MY03 Y ▲ 訂單款式工藝 MY04 Y ▲ 大貨跟蹤表 MY06 Y ▲ 通訊錄 MY05 Y 排產管理 （PC） 服裝工廠資料 PC01 Y 訂貨合同 PC02 Y ▲ 生產工藝資料 PC03 Y ▲ 大貨生產狀態確認 PC04 Y 採購管理 （CG） 供應商資料 CG01 Y 訂購單 CG02 Y ▲ 發貨單 CG03 Y ▲ 退貨單 CG04 Y ▲ 產品清單彙總 CG05 Y 單證管理 （DZ） 發運單 DZ01 Y ▲ 成本核算單 DZ02 Y ▲ 財務管理 （CW） 服裝工廠往來帳目 CW01 Y 服裝廠配料擔保賬目 CW02 Y 服裝工廠結算單 CW03 Y ▲ 供應商擔保賬目 CW04 Y 注：TestAge 中國軟件測試時代­r*fm:Z1W3~?[Y][P][N][N/A]四項值依據TestAge 中國軟件測試時代測試結果，按編號給出每一測試需求的通過與否結論。

P表示部分通過，N/A表示不可測試或者用例不適用。▲表示為測試重點部分。

D­dduS­a6} ihV WW8需求覆蓋率=Y項數/需求項數 *100%=33/33*100%=100% 3.2.2測試覆蓋 模塊 用例個數 執行數 未執行數 未執行/漏測原因 貿易管理 28 28 生產管理 38 38 採購管理 39 39 單證管理 17 17 財務管理 11 11 合計 133 133 .o Knz)u5 ~5_zD }mI-N9c8測試覆蓋率=執行總數/用例總數 *100%=133/133*100%=100% 3.3缺陷的統計與分析 3.3.1缺陷彙總 缺陷總數：105 按缺陷嚴重程度：1-Low: 16個 所佔百分比：15.238% 2-Medium: 77個 所佔百分比：73.342% 3-High: 12個 所佔百分比：11.420%。

我公司的測試的責任描述

崗位職責：

1.參與項目的測試用例的編寫和執行

2.按照佈置執行功能和性能測試，缺陷的追蹤管理

任職要求：

1. 計算機或相關專業本科以上學歷

2. 良好的溝通技巧和強烈的責任心

3. 參加過至少一個完整項目的測試工作

4. 4.熟悉至少一種數據庫的使用（SQL Server、Oracle、Mysql）

5. 5.有C/C++, Java, WAP、HTML,XML、XHTML其中之一相關編程經驗者優先

1、進度，計劃進度曲線圖及實際進度曲線圖進行對比，總結出入原因。

2、風險，按各里程碑階段出現的風險分類進行分析，如質量、時間、人力、溝通、需求變更。

3、需求，按個里程碑階段計劃需求數量、實際需求數量柱形圖進行分析；描述需求變更給項目帶來的影響。

4、質量，從功能測試階段、迴歸測試階段、驗收測試階段等測試階段入手，分析各階段有效BUG數，以及分析BUG分佈情況；根據BUG情況分析千行代碼缺陷率趨勢。

5、成本，按里程碑階段，計算各階段投入的人日，以及計算開發和測試的人員比例，按市場人月價格可估算成本。

擴展資料

項目申請報告的基本內容：

第一章 申報單位及項目概況

第二章 發展規劃、產業政策和行業准入分析

第三章 資源開發及綜合利用分析

第四章 節能方案分析

第五章 建設用地、徵地拆遷及移民安置分析

第六章 環境和生態影響分析

第七章經濟影響分析

第八章 社會影響分析

在編寫具體項目的項目申請報告時，可根據擬建項目的實際情況進行適當的調整與刪減。

參考資料

百度百科-項目

目前沒有經典的定義。比較通常的説法是：指對一項特定的軟件產品進行測試任務的描述，體現測試方案、方法、技術和策略。內容包括測試目標、測試環境、輸入數據、測試步驟、預期結果、測試腳本等，並形成文檔。

不同類別的軟件，測試用例是不同的。不同於諸如系統、工具、控制、遊戲軟件，管理軟件的用户需求更加不統一，變化更大、更快。筆者主要從事企業管理軟件的測試。因此我們的做法是把測試數據和測試腳本從測試用例中劃分出來。測試用例更趨於是針對軟件產品的功能、業務規則和業務處理所設計的測試方案。對軟件的每個特定功能或運行操作路徑的測試構成了一個個測試用例。

隨着中國軟件業的日益壯大和逐步走向成熟，軟件測試也在不斷髮展。從最初的由軟件編程人員兼職測試到軟件公司組建獨立專職測試部門。測試工作也從簡單測試演變為包括：編制測試計劃、編寫測試用例、準備測試數據、編寫測試腳本、實施測試、測試評估等多項內容的正規測試。測試方式則由單純手工測試發展為手工、自動兼之，並有向第三方專業測試公司發展的趨勢。

要使最終用户對軟件感到滿意，最有力的舉措就是對最終用户的期望加以明確闡述，以便對這些期望進行核實並確認其有效性。測試用例反映了要核實的需求。然而，核實這些需求可能通過不同的方式並由不同的測試員來實施。例如，執行軟件以便驗證它的功能和性能，這項操作可能由某個測試員採用自動測試技術來實現；計算機系統的關機步驟可通過手工測試和觀察來完成；不過，市場佔有率和銷售數據（以及產品需求），只能通過評測產品和競爭銷售數據來完成。

既然可能無法（或不必負責）核實所有的需求，那麼是否能為測試挑選最適合或最關鍵的需求則關係到項目的成敗。選中要核實的需求將是對成本、風險和對該需求進行核實的必要性這三者權衡考慮的結果

如果你參與了項目，最好寫清楚參與的項目的時間，項目描述，自己在這個項目中的主要責任，以及在項目中用到的技術和自己在項目中學到的東西

完成了xxx部分編碼/測試/設計，（在xxx時間內）實現了yyyy功能，使得項目獲得了zzzz收益，獲得dddd獎勵。

可以在項目描述中談談自己在實現某項功能時用到了什麼技術，如用MySQL的 limit語句實現分頁功能

先介紹一下項目要實現的功能，在介紹下程序的結構劃分（MVC），再談下MVC各是用什麼技術實現的（如View用了JSP、JSTL,Controller使用Struts2的過濾器。。。），然後介紹下實現主要功能時具體用了哪些技術（建議你多談點對AJAX的理解）