標簽：組合 權限設置 內容 環境 界面 數據庫 平台 com 資源
目錄
1、App測試和Web測試的區別？
2、什麽是HTTP請求，HTTP請求方式有哪些？
3、Get請求與Post請求的區別？
4、常用的測試用例設計方法？
5、測試過程中遇到一個bug，開發不認爲是bug如何解決？
6、微信朋友圈點贊功能如何設計測試用例？
7、如果在購物平台上選購了物品，並且成功支付，但在“我的訂單”中沒有查到該筆訂單，此時怎麽處理？
1、App測試和Web測試的區別？
App測試與Web測試從功能測試和整體流程角度來講，幾乎沒有什麽區別，都是點點點的測試。
Web测试，包含了UI测试、链接测试、搜索测试、表单测试、输入域测试、数据交互、兼容性测试、安全性测试、性能测试等等很多方面。而App测试，是基于客户端进行测试，测试人员的手机型号不同、版本不同、测试環境不同，涉及到的兼容性问题会有很多。
系統架構：Web測試一般是B/S架構，只要更新了服務器端，客戶端就會同步更新。而且客戶端能保證每位用戶的客戶端完全一致。但是App端一般是C/S架構，除非用戶更新客戶端，否則無法保證軟件在每個人手機中的一致性。如果在App下修改了服務端，就意味著又需要進行回歸測試。
性能測試：Web測試比較關注網頁的響應時間，而App除了關注在流暢網絡下的響應時間，還需要關心流量、電量、CPU、GPU、Memory等等因素。
兼容性測試：Web端的測試更傾向于浏覽器、電腦硬件配置以及電腦系統方向的兼容，不過一般還是以主流的浏覽器爲主。而App的測試則必須依賴移動端的設備：手機、平板等，不僅要看設備型號，還要看設備系統：Android、iOS、鴻蒙。
App專項測試：異常場景的考慮以及弱網測試。比如：中斷，來電，短信，關機，重啓等。而弱網測試是App測試中必須執行的一項測試。包括弱網和網絡切換，需要測試弱網時的用戶體驗問題，提示語和等待頁面的設置，回退和刷新是否會造成二次提交，以及延時的處理機制等。
针对App产品性质的测试內容，绝大多数用户使用的都是触屏手机，所以测试的时候还要注意手势，横竖屏切换，多点触控，功能触发区域等测试。
Web測試是針對浏覽器，無需考慮安裝卸載問題。而App是客戶端，需要測試安裝卸載和更新的情況。除了常規的操作還要考慮到異常場景。比如說：安裝時的中斷、弱網、安裝後刪除文件，強制更新與非強制更新、斷點續傳、弱網，卸載後刪除App相關的文件等等。
2、什麽是HTTP請求，HTTP請求方式有哪些？
HTTP，即超文本传输协议，是HyperText Transfer Protocol的缩写。
浏覽網頁時在浏覽器地址欄中輸入的URL前面都是以"http://"開始的。
HTTP定義了信息如何被格式化、如何被傳輸，以及在各種命令下服務器和浏覽器所采取的響應。
HTTP請求方式：GET、POST、PUT、HEAD、DELETE、OPTIONS、TRACE、CONNECT
3、Get請求與Post請求的區別？
Get，获取資源，Get方法一般用来从服务器上获取資源的方法。服务器端接到Get请求后，就会明白客户端是要从服务器端获取相应的資源，然后就会根据请求报文中相应的参数，将需要的資源返回给客户端。使用Get方式的请求，传输的参数是拼接在URL上的。
Post，數據提交，Post方法一般用于表單提交，將客戶端的數據塞到請求體中發送給服務器端。
Get和Post區別：
1、Get請求無消息體，只能攜帶少量數據；Post請求有消息體，可以攜帶大量數據。
2、Get請求將數據放在URL地址中；Post請求將數據放在消息體中。
3、Get請求提交的數據放置在HTTP請求地址中，而Post提交的數據則放在實體數據中；Get方式提交的數據最多只能有1024字節，而Post則沒有此限制。
4、常用的測試用例設計方法？
等價類劃分法：等價類劃分主要適用于單個輸入條件，輸入爲數值型的情況，如果輸入規定了輸入區間，可劃分出一個有效等價類，兩個無效等價類；如果輸入只規定了輸入範圍，可劃分出一個有效等價類，一個無效等價類。有效等價類：有意義的合理的正確輸入；無效等價類：非法的錯誤的異常的輸入。
邊界值分析法：邊界值方法也是適用于單個輸入條件的情況，輸入類型可以數值、字符等，要測試的邊界包括上點、下點、離點。
相關術語：上點：邊界上的點叫做上點；離點：離邊界最近的點叫做離點（如果是閉區間，離點落在邊界外；如果是開區間，離點落在邊界內）；內點：邊界內任意一個點叫做內點。
因果图法：如果输入之间有关系，我们在测试时必须考虑输入条件的各种組合，那么可以考虑使用一种适合于描述对于多种条件的組合，相应产生多个动作的形式来设计测试用例，这就需要利用因果图。优点：因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种組合情况。
錯誤推測法：錯誤推測法主要是測試設計人員的測試經驗相關，測試經驗不同，設計出來的測試用例也區別很大。
判定表驱动法：判定表适合于解决多个逻辑条件的組合。将各种逻辑的組合罗列出来，避免遗漏。不能表达重复的操作。判定表包括条件桩、条件项、动作桩、动作项。
正交法：當輸入條件很多時，因果圖等設計方法設計出來的用例數往往多的驚人，用正交法可有效減少用例數。正交法的核心思想是從大量測試數據中選取有代表性的點來測試，從而減少測試用例數。
功能圖法：功能圖法適合于用來設計程序的控制結構的測試用例。有順序、選擇、重複三種控制結構。
場景法：場景法特別適用于控制流清晰的系統。測試過程中可以針對不同的場景設計測試用例。
5、測試過程中遇到一個bug，開發不認爲是bug如何解決？
該問題是面試時常見問題，沒有固定答案，但是該問題能夠反映出測試人員在發現問題後，如何解決問題的能力，能夠體現出候選人的主動解決問題的能力和思路，作爲一名測試人員，發現並主動解決問題最爲關鍵，這裏列出幾點，便于參考：
首先分析下到底會有哪些原因會導致開發不修改bug：
1、開發與測試對bug的定義理解不一致産生的問題，例如暴力操作、非常規操作出現的問題、問題路徑深、服務器返回的數據不規範、競品同樣有的問題、個別機型問題等情況，開發可能會不願意修改。
2、工作流程方面的原因，例如開發有更高優先級的任務沒有時間修改、上線時間緊急，來不及修改、開發不關注名下的bug、開發認爲目前的實現比産品需求好等情況。
3、當然還有個人能力原因，例如找不到好的解決方案、影響範圍大、找不到bug原因，沒有解決方案、技術實現難，不知道怎麽修改等等原因。
4、另外還有一些不可抗力的客觀因素，例如系統問題，第三方應用問題等等。
我們逐條分析並列出簡單的解決方案：
1、針對路徑較深的bug，測試在推動開發修複bug時，需要注意以下幾點：
1）從用戶的角度分析問題的嚴重性，分析用戶的遇到此問題的概率，引導開發站在用戶角度去思考，從而使開發意識到問題的嚴重性。
2）可以和開發人員列舉一個之前的類似問題，爲開發提供參考。
3）産品是負責這個軟件的人員，當測試與開發意見無法達成一致時，不要因爲無法推動開發修改而放棄，一定要找産品確認，最終的決定權交給産品人員。
2、上線時間緊張，開發來不及修改了，這個時候測試應該分析問題的嚴重性，和産品人員商議是否需要修改。
3、修改bug改動較大，影響範圍廣，沒有最優的解決方案等情況在項目即將上線的節點比較忌諱這種事情的發生。面對這種情況，建議開發人員做調研工作，請教其他的同事，或者組織一個臨時會議，集衆人之力研究好的修改方案。
4、第三方應用問題，開發無法修改。確認原因之後需要找相關的工作人員，例如産品，聯系第三方工作人員，反饋問題，盡量推動應用解決問題。
bug修不修，測試應該有一個自己的原則，同時也要權衡利弊。不能因爲推不動開發，就放棄，由著bug上線，也不能揪著一個小bug不放，影響上線時間。
6、微信朋友圈點贊功能如何設計測試用例？
1、首先检查朋友圈可见權限設置，针对不同的权限、好友关系设置哪些好友可见
2、設置單個好友可見時，發送一條朋友圈，對方好友是否可見
3、可見之後是否有可展開的操作欄（其中包括點贊和評論）
4、多次點擊後操作欄是否能夠重複展開或退回
5、點贊功能：UI檢查，是否有點贊圖標，點贊提示，評論圖標，評論提示
6、點擊點贊圖標後，圖標是否有點贊成功提示
7、點贊成功後點贊提示是否變爲取消點贊
8、點贊成功後是否在該條朋友圈下有點贊人姓名及圖標
9、點贊成功後，是否在被點贊人朋友圈處出現被點贊數統計提示
10、被點贊人點擊被點贊的提示後，頁面是否跳轉至被點贊朋友圈處，並顯示已點贊的好友圖標
11、設置多個好友可見時，重複點贊步驟後，被點贊人查看個人朋友圈，是否能夠展示所有點贊人的圖標，統計數量
12、若多個好友同時點贊，被點贊人收到贊時頁面展示是否按照點贊時順序排序
13、多個人同時點贊時，順序如何排序
14、若其余幾位點贊人之間不互爲好友關系，是否能夠看到對方點贊情況
15、若有個別人員是好友關系，能否通過點贊的頭像進入對方信息
16、點贊之後該條贊能否一直保持
17、若該條朋友圈被刪除，點贊的訊息是否也被刪除
18、取消點贊，只能對已點贊的朋友圈進行取消點贊
19、在已點贊的朋友圈下點擊操作欄，是否彈出取消點贊的圖表及提示
20、點擊取消後是否提示已取消點贊
21、取消的點贊後是否可以再次點贊
22、取消點贊後是否會通知被點贊人
23、設置朋友圈可見限制，當被點贊人收獲很多贊之後，關閉朋友圈可見，那麽被點贊人是否能夠看到自己收獲點贊統計，其點贊好友是否能夠看到已點贊的信息
7、如果在購物平台上選購了物品，並且成功支付，但在“我的訂單”中沒有查到該筆訂單，此時怎麽處理？
測試人員發現問題後，先確認該問題是否滿足需求，若在需求要求下，則：
1、重现问题：如果是测试環境，可以再做一笔订单，詳細记录该笔订单讯息，检查该问题是否为偶发性问题，此处分两种情况：
1）若該筆訂單能夠查到，則需判斷，沒有找到訂單的那筆有可能是偶發現象，需明確記錄。
2）若該筆訂單還是無法找到，則需確定是前端還是後端問題。
2、排查问题：若为Web类测试，通过开发者工具查看界面返回结果，若“我的订单”中有返回值，但在页面中没有展示，需找前端同事确认是否是做数据处理时没有展示结果；若“我的订单”中没有返回值，有可能是数据没有传给前端，需确认是否是接口没有返回或数据传输丢失。此时可以通过检查數據庫对应表格、或者用抓包工具检查接口是否报错。若为App类测试，通过抓包工具检查接口返回，同时检查數據庫中对应表，是否有存储该笔数据。
3、確認是前端或後端問題後，可以截圖發送給對應同事確認問題，並將該問題提交至缺陷管理工具中，並及時跟蹤問題。若問題較嚴重並短期內無法解決，需及時與負責人、項目經理聯系，及時彙報該問題。
4、若该问题为偶发问题，需记录该笔订单詳細情况，并在后期测试中重点关注，若经过几个迭代后该问题没有再次出现，则可降低该问题等级，但仍需留意。
標簽：組合 權限設置 內容 環境 界面 數據庫 平台 com 資源
原文地址：https://www.cnblogs.com/alltests/p/14985302.html
