目錄
總結MySQL：
最終還是得按照SQL的語法來實施。
1、MySQL的數據類型：指業務數據按照什么格式存儲在數據庫中的。
任何數據類型最常見的三種：字符串、整型和小數型。
如：寶貝計劃這種存在視頻的項目，你們的視頻是存放在服務器的還是存放在數據庫的？
答案：數據庫存放視頻在服務器中的文件路徑。
2、MySQL的約束：
主鍵約束（唯一和非空）標志位基本上是和ID有關。
外鍵約束（關系型數據庫）
至于非空，唯一，自增長和默認不經常用到。
3、建庫，建表，修改表結構。（測試基本不用）
4、重點：增刪改查。核心還是查詢，修改，增，最后是刪。
5、在查詢SQL語句中：需要遵循對應的格式即可。
SELECT 字段列表FROM 表名列表 WHERE 條件篩選GROUP BY 分組字段 HAVING 分組后查詢ORDER BY 排序 LIMIT 分頁6、子查詢：
SELECT 嵌套——相當于一條SELECT語句就當做一份常數來看待。
7、多表查詢：雙表查詢。
一、關于龍戈：
1、管理員（admin）不能直接參與業務的。因為admin的權限很高，而且不方便跟蹤，造成管理混亂。
2、通過龍戈來考慮項目在實際公司的落地價值。需要結合你自身的經驗。
3、關于測試點的提取：終極目標：XXX怎么測？
原型：XX怎么測？XX有哪些測試點？XX怎么設計測試用例？這三個問題的測試思想和測試場景是一樣的，但是回答還是存在少許區別。
實際落地：關于測試用例的設計——基本上是用于工作中，尤其是外包。
XX怎么測試？（體現測試動作和測試場景）XX有哪些測試點？（重點體現測試點就行）——很適合面試。
案例來區別這兩個問題：登錄為參考。
有哪些測試點？
- 正確賬戶和密碼
- 錯誤密碼
- 未注冊賬戶
- 賬戶是否為空
- 賬戶長度的限制
- 賬戶支持的數據類型
- 特殊業務：（掛失賬戶，凍結賬戶，二類賬戶，信用卡用戶……）
（有些公司可以代替測試用例）
登錄怎么測？ - 正確賬戶和密碼登錄來查看是否登錄成功進入主頁。
- 使用錯誤密碼登錄后是否提示失敗，失敗信息是否存在問題。
- 使用未注冊的賬戶登錄時，提示什么相關信息，是否符合需求。
說到底：考慮單個功能到底有哪些測試點？
實際場景：怎么去面對需求文檔不是最新，不齊全，甚至沒有。
最重要的一點：只要不是特別核心需要明確定義的，那么其它的都是根據軟件的正常操作來衡量。
意味著：在需求評審會議之前提取測試點——就是提取需求中沒有那么明確的點，而不會提取軟件的正常操作標準。
案例1：**稅務報表怎么測？**綜合全面
- 下拉框輸入字符串是否會報錯，不報錯是否會正確顯示并修改進數據庫中。
- 日期輸入框輸入不符合規定的日期。如：平年2月29日。會不會報錯還是正常修改進數據庫，報錯信息是否正確。
- 日期輸入框輸入其他數據類型，如：中文，英文，特殊符號等會不會報錯。
- 什么都不選擇，點擊查詢會不會有查詢結果還是會有什么提示信息。
- 點擊重置按鈕，各個輸入框是否會重置為空。
- 統計年月起或是稅款所屬期起有數據，而截止日期沒有數據，點擊查詢會不會出來從這個日期起的所有數據？還是有提示輸入起始日期？
- 統計年月止或是稅款所屬期止有數據，而起始日期沒有數據，點擊查詢會不會出來以這個日期止的所有數據？還是有提示輸入截止日期？
- 當查詢結果為空時如何顯示提示信息？ 當查詢結果很多需要翻頁時，翻頁功能是否正常。
- 測試各個下拉框下拉數據顯示是否正常
- 針對每個條目進行查詢，查詢結果有無錯漏。
- 針對日期框，輸入合適的日期，查詢結果有無錯漏。
1、需要測試整個報表的界面顯示，排版布局以及輸入款和按鈕操作是否符合設計原型。
2、測試報表中每個輸入項都輸入正確的數據后（如：主管稅務機關。統計年月起止等）是否能查詢到需要的信息，這個操作也是報表冒煙測試。
3、接下來在測試正確的信息前提后，分別測試每個子選項。如測試輸入不同的主管稅務機關后，是否能查詢到不同的地區稅務數據。
4、測試報表中的統計年月起止的時間段是否能查詢到匹配的數據，需要考慮時間段的限制。如是否可以查詢當月，如時間跨度是否有約束。
所以如果是面試涉及到這個問題：前提腦海中有這個報表的圖場景，根據這個場景中的每個功能點進行闡述。
場景案例2：直播怎么測？個根據目前這個界面來闡述測試點。
1、界面顯示，排版布局以及輸入框和按鈕操作是否符合設計原型。
2、輸入框輸入數據發送后，是否正確顯示并被其他人看到。
3、點擊關注按鈕，沒有登錄賬戶是否提示要登錄，登錄賬戶是否能正常關注。
4、點擊屏幕，是否出現點贊特效，用戶名下方的點贊數量有無相應變化。
5、點擊愛心或是禮品圖標，點擊禮品，能否正確送出禮物給主播，禮物特效是否符合要求。
6、當送禮物余額不足時是否有提示并彈出充值界面、
7、點擊分享按鈕，能否正確彈出分享渠道（如：微信，微博或QQ），能否正確彈出相應的APP并分享鏈接。
8、輸入信息和禮物特效，主播查看到延時是否符合SRS要求。
9、直播間人數統計是否正確，當直播間人數過萬、過十萬……時在線人數顯示是否符合要求。
10、點擊直播廣場、小時榜等能否正確跳轉。
11、直播畫面畫質和聲音的大小、時延是否符合要求。
12、輸入框的輸入字符有無長度限定，輸入其他語言（如：日語，泰語等）能否正確顯示。
13、點擊主播頭像，能否正確瀏覽主播主頁。
14、左上角的禮品或抽獎能否正確顯示（倒計時和種類），用戶能否抽取倒計時結束的禮物。
15、點擊“點歌”功能能否正常使用。
16、點擊觀眾列表的用戶，是否顯示出打賞排名前十的用戶，點擊頭像能否瀏覽該用戶的主頁。
17、點擊“每日鮮花”，是否正常顯示數量，能否送出鮮花。
18、管理員飄屏彈幕能否正常使用，能否被其他人看到。
19、主播點擊用戶留言，能否浮屏顯示。
20、主播設置用戶禁言后，該用戶是否能繼續留言。
21、用戶進入直播間有無相應的提示，例如：XX來了。歡迎來到直播間！抖音嚴禁……
22、評論區用戶的等級能否正確顯示。
寫直播中的測試點：
每日一練：
1、WHERE, GROUP BY 和HAVING有什么區別。
WHERE 后面接 篩選字段，是針對于表進行篩選；
GROUP BY 后面接 分組字段
HAVING 是分組后進行過濾，針對結果進行過濾，跟在GROUP后面。
執行順序 WHERE -> GROUP BY -> HAVING
- HAVING后面的條件可以加聚合函數， WHERE不可以，因為WHERE 比聚合函數先執行
- 一但按照某個字段分組后，那么SELECT子句后面出現分組字段和聚合函數，如果寫了其他的毫無意義。
2、數據表的幾種合表方式，有什么區別
1、內連接：查詢A表和B表的交集數據。
隱式語法：SELECT 字段列表 FROM 表1, 表2 WHERE 條件;
顯式語法：SELECT 字段列表 FROM 表1 JOIN 表2 ON 條件;
2、外連接：
左外連接：查詢左邊的數據 + 交集數據（左邊有而右表沒有的數據缺失補NULL）
語法：SELECT 字段列表 FROM 表1 LEFT JOIN 表2 ON 條件;
右外連接：查詢右表的數據 + 交集數據（右邊有而左表沒有的數據缺失補NULL）
語法：SELECT 字段列表 FROM 表1 RIGHT JOIN 表2 ON 條件;
問題：有沒有可能，內連接，左連接和右連接合表后的數據是一樣的？
匹配數據完全一致
當左表和右表的所有匹配數據完全一致時（即左表所有行在右表均有匹配且
右表無未匹配行），內連接（返回匹配行）的結果與左連接（保留左表全部行
）的結果相同。此時右連接的結果也會與前兩者一致，因為右表所有行均被匹配。
3、子查詢和多表查詢有什么區別。
子查詢雖然參與多個表，但是最終還是在單表中進行復雜查詢
多表查詢一般是2個表或3個表，多表查詢就是合表查詢，合的表要有關聯，不然就沒意義了
)
)