1.優惠券生成原理：
2.eg：實際後臺生成頁面
3.測試點：
薅羊毛測試點：
1.
2.
實際測試中可能只用到其中幾條而已，比如銀行卡密碼的修改，就不用考慮英文和非法字符，更不用考慮那些ＴＡＰ之類的快捷鍵。而有的需要根據需求具體分析了，比如連續出錯多少次出現的提示，和一些軟件修改密碼要求一定時間內有一定的修改次數限制等
測試工作需要的基礎資料： 1、需求文檔/原型 2、接口文檔 3、app 用戶的手機系統相關信息(系統，版本號，ROM,RAM，CPU) 4、bugly賬號——App綁定bugly 5、產品用戶羣體確認 新項目流程： 1、需求分析
（1）輸入正確的用戶名和正確的密碼 （2）輸入正確的用戶名和錯誤的密碼 （3）輸入錯誤的用戶名和正確的密碼 （4）輸入錯誤的用戶名和錯誤的密碼 （5）不輸入用戶名和密碼（均爲空格） （6）只輸入用戶名，密碼爲空 （7）用戶名爲空，
一、用戶註冊 只從用戶名和密碼角度寫了幾個要考慮的測試點，如果需求中明確規定了安全問題，Email，出生日期，地址，性別等等一系列的格式和字符要求，那就都要寫用例測了~ 以等價類劃分和邊界值法來分析 1.填寫符合要求的數據註冊：
目錄一、出現問題1、2、3、其他問題就不再現了二、問題解決1、環境配置2、pom配置，解決驅動問題3、jdbc連接配置，解決驅動問題到此所有問題就解決了，能幫到各位，請點個贊謝謝 一、出現問題 由於數據庫版本的升級，會出現很多問題
之前寫過一篇文章，講了mac上怎麼通過操作彈框的方式上傳文件，然後有個同事問我，他想用send_keys()方法上傳，但是他往輸入框裏輸入了地址後，依舊提示沒有上傳文件。我一看，他果然陷入一個誤區input框一定就是上傳文件的地方
mac+python3+selenium 通過控制系統輔助功能上傳文件 問題描述 selenium提供的sendkeys方法上傳文件我就不贅述，網上很多教程，但是缺點也很明顯。並不是完全適用各種場景。如果上傳文件不是input類型
WireShark抓包數據分析： 1、TCP報文格式 源端口、目的端口：16位長。標識出遠端和本地的端口號。 順序號：32位長。表明了發送的數據報的順序。 確認號：32位長。希望收到的下一個數據報的序列號。 TCP協議數據報頭DE
那麼在移動互聯網發展到今天，native界面測試已經成爲傳統，webview+natvie模式已經漸漸來到我們身邊，目前市面上也有許許多多hybird類應用，並且我認爲這也是未來的趨勢，當然最大的好處就是更新成本低，直接更新h5
介紹下工作中，Web端測試所涉及到的方法： 前言：Web測試常用的方法，兼容性測試、安全性測試、可用性測試 & 邏輯功能測試 1 > 兼容性測試 先說下兼容性測試，工作中在測試時，一般涉及操作系統測試、瀏覽器測試、分辨率測試。
做了快十年的測試了。4年做app的測試，web測試也做了6年。其實我覺得這兩者並沒有什麼大的區別。 僅僅從功能測試的層面上來講的話，在流程和功能測試上是沒有區別的。那麼區別在哪裏呢？ 我個人覺得就是由於載體不一樣，所以系統測試和一些細節可
一、跨域 1.概念： 只要協議、域名、端口有任何一個不同，都被當作是不同的域。 不同的域之間相互請求資源，就叫“跨域”。 http:// www . google : 8080 / script/jquery.js
sonar 檢測代碼質量實戰演示第一章：sonarqube 的安裝與啓用① sonarqube 獲取② sonarqube 配置③ sonarqube 驅動放置④ sonarqube 的啓動第二章：sonarqube 報錯解決①
這個問題要分兩種情況討論1、測試用例質量較高，覆蓋了需求設計中的測試點，並且測試人員認真負責，沒有發現bug ，說明程序質量很好， 這種測試的價值就很大，能夠去評判軟件的質量2、測試用例質量不高，測試人員的責任心不強，沒有發現bug，這種
就常規的導入導出，關測試點，適用大部分場景，部分還需要自己就需求或設計文檔編寫 一、導出 1、導出格式檢查 （1）格式是否正確 （2）各字段是否正確 （3）文件名是否有要求，是否符合要求 （4）不同瀏覽器導出是否一致（瀏覽器兼容測
