『壹』 aAPP測試用例怎麼寫
測試用例的設計方法和編寫
1.如何設計編寫測試用例？
對各個功能模塊進行測試點分析提取測試點再堆測試點進行用例編寫
【測試點：通過需求分析後對得出的需要進行測試的具體內容】
比如對PC端QQ賬號的登錄模塊，提取測試點就有：
①正常登陸 ②賬號為空時點擊登錄 ③密碼為空時點擊登錄 ④賬號密碼都為空時點擊 登錄 ⑤密碼錯誤時點擊登錄 ⑥找回密碼功能是否有效 ⑦記住密碼功能是否有效 ⑧ 自動登錄功能是否有效
2.編寫測試用例該注意什麼？
①根據項目的實際情況設計測試用例表格
②用例格式不要生搬硬套
③根據具體情況編寫
3.編寫測試用例的常用方法：
①等價類劃分法：等價類是輸入的集合，比如在注冊時，密碼規定為6-16位英文字母或數字及下劃線，那麼小於6位的一串字元就是一個等價類，大於16位的一串字元是另一個等價類，在6-16位之間且符合規范的一串字元也是一個等價類，在6-16位之間的但包含除英文字母和數字和下劃線之外的字元是另外一個等價類。
在每個等價類中選取一定數目的值作為代表。等價類分為有效等價類和無效等價類，輸入符合條件的值對功能進行檢驗，輸入無效等價類中的值可以找出程序錯誤的地方。
②邊界值分析法：對輸入的邊界值或稍大（小）於邊界值的值進行分析。比如某公司在招聘時篩選簡歷時對年齡的要求是20歲到35歲，那麼19、20、21、34、35、36都是邊界值，對其進行輸入測試觀察結果是否符合要求。
③場景法：通過運用場景來對系統的功能點或業務流程的描述，從而提升測試效果。場景法一般分為基本流和備用流，覆蓋所有的場景。
④錯誤猜測法：通過直覺和經驗對結果進行分析。
『貳』 軟體工程設計導論:過程、原理與模式(UML2.0版)目錄
軟體工程設計導論:過程、原理與模式(UML2.0版)的目錄詳細介紹了多個核心章節，旨在幫助讀者理解軟體設計的各個方面。
第1部分，簡介，涵蓋軟體設計學的基礎概念。第1章從軟體設計的概念出發，解釋了設計的本質——它是問題的解決方案，強調了抽象化和模型在設計中的關鍵作用。設計的多樣性被進一步探討，包括產品設計、工程設計以及軟體工程設計團隊的協作。此外，軟體設計在生命周期中的重要性，如軟體生命周期、跨生命周期的設計和「做什麼」與「如何做」的區別，也做了深入討論。
第2章深入解析軟體設計過程和管理，使用UML活動圖展示了設計過程的可視化表示。這部分內容有助於讀者理解設計方法和歷史，以及其在實踐中的應用。
第II部分詳細介紹了軟體產品設計，從設計的上下文開始，然後逐步深入到產品設計分析、解析以及用例驅動的設計。
第III部分重點轉向軟體工程設計，包括工程設計分析、解析、體系結構設計和各種設計解析，如靜態中級面向對象設計和動態設計的交互作用模型、狀態模型等。
第IV部分深入探討軟體設計模式，如體系結構風格、面向對象和中級設計模式，以及代理者、生成器和反應器等具體模式的介紹。
最後，附錄部分提供了術語表、AquaLush案例分析和參考文獻，為深入研究和實踐提供了補充資源。
本書是國際知名軟體工程專家Christopher Fox教授關於軟體工程設計的一本大學教程，著重描述如何理解軟體問題以及如何設計用來解決這些問題的方案。為了便於大家理解和應用，書中採用了常用的UML2表示法進行設計，並提供大量的示例，本書適用於具有面向對象編程基礎並熟悉基本的數據結構和演算法知識的大學高年級學生和軟體開發人員。
『叄』 如何有效地管理測試用例
剛在51testing上看到一個人發帖，說自己寫測試用例沒有很好的思路，對於一些復雜的功能點，有沒有比較好的測試覆蓋方法，比如高級查詢等等，非要列出來那麼詳細的測試用例嗎？～～～～看完之後，我就忍不住發言了，作為一個測試人員，設計測試用例那是本職工作，如果我們連寫用例的基本耐心都丟棄了，還談什麼測試。那開發總不能說因為寫代碼很麻煩，而不寫吧。很多事情沒有捷徑，必須要做的事情，那是沒有辦法去逃避，不然我們就失去了工作的意義了。
其實說來，也是由於最近對於測試用例的設計，讓我產生了一些反思。如何設計測試用例，如何評審測試用例，最後如何管理測試用例，這都是我們測試工作中必須要去改進的問題。在之前的公司，由於團隊工作任務繁忙，我們沒有太多的時間去管理和優化測試用例，也因此對用例方面少了太多的思考，而且雖然有對於用例的評審，但一直以來，我認為是做得不夠好的，畢竟每次評審下來，感覺效果沒有預期的那麼好，主要還是沒有足夠的時間去管理，所以無法引起重視。不過，現在我想我需要花大量的時間來管理用例了，而且要保證有序的進行，最後輸出讓團隊中各個成員都認為滿意而且高效的測試用例。對於用例管理的根本問題，我個人認為是分類上，如何有效的維護和優化用例，就是需要前期明確的分類規劃，根據分類的優先順序一步一步地來完成就可以了，到最後，我們也可以有效把控的測試覆蓋度。
當前，我們大致可以把測試用例分稱三個方面，分別是功能、UI和業務流程，從這三個角度來進行設計。
1、從功能的角度，功能是每個項目測試的重點，通常在測試人員得到需求文檔的時候，我們就開始設計測試用例，那麼這個時候需求文檔上列出都是功能以及部分一些業務邏輯等，所以在測試用例的第一階段就是完成功能的用例設計。不過這里，肯定會讓很多人疑惑，其實功能、業務還有UI，都是有關聯的，而且很多時候無法分解的。這里後面我會舉個例子說明哈，但絕非都是可以分類，只是談談如何分解的方法，最重要的就是不要遺漏就行。
2、從UI的角度，UI通常是指界面測試，這個應該不難理解，但要想與功能點進行分解，也不是那麼容易區分的，所以我們來直觀的說明哈。界面測試，注重樣式，外觀、整潔、擺放以及易用性，還包括用戶體驗等。
下面通過一個證券交易平台上的買入和撤單業務，進行具體說明：
業務說明：買入業務包括股票代碼、當前價格、買入價格，買入股票數量、確定買入按鈕和取消按鈕；
撤單業務包括選擇撤單的未成交業務、撤單成功、撤單失敗以及取消撤單按鈕；
以上只是大致列舉了一部分。
功能點：買入按鈕、取消按鈕、選擇撤單、撤單按鈕和取消撤單按鈕等
UI界面測試：股票代碼、當前價格、買入價格、買入股票數量，所有的文本框；買入成功/失敗的提示框；撤單成功/失敗的提示框；撤單成功/失敗的業務狀態等
業務測試：買入業務，從輸入買入表單的數據，到提交表單，到最後買入的表單顯示的位置，以及買入提交但未成交，可以撤單，完成撤單的業務，到撤單成功或者失敗等，這一連串的工作組合就是一個業務流程。
其實這里就存在一個爭議性的問題，對於買入和撤單，既可以作為功能點，也可以作為一個業務邏輯來設計，但從本質上來講，功能點注重單獨的操作，而業務流重的在是一個流程，還需要具體業務去甄別。功能點的設計更主要對這個買入和撤單的按鈕本身進行用例設計；而業務則是需要從買入和撤單之前的輸入到最後輸出這樣一個過程來設計。
以上也只是大概的一個簡單的說明，具體的操作還得根據自己的實際流程來執行，畢竟測試用例的管理是一個長期的積累和沉澱的過程，好的方法都是總結出來的。對於測試來說，用例是基礎，對於回歸測試、自動化、性能等等都是根本，管理好測試用例，也就是提高測試的工作質量。