收集了各大公司的面試經驗,現整理出來,但願能給正在找工做的志同道合的小夥伴一些指引,本文會持續更新的哦。面試
一個是通用計算,一個是專用計算。
CPU主要負責操做系統和應用程序,GPU主要負責跟顯示相關的數據處理,GPU的活CPU通常均可以幹,可是效率低下。CPU和GPU之因此大不相同,是因爲其設計目標的不一樣,它們分別針對了兩種不一樣的應用場景。CPU須要很強的通用性來處理各類不一樣的數據類型,同時又要邏輯判斷又會引入大量的分支跳轉和中斷的處理。這些都使得CPU的內部結構異常複雜。而GPU面對的則是類型高度統一的、相互無依賴的大規模數據和不須要被打斷的純淨的計算環境。算法
推薦應該說分爲兩類:個性化推薦和非個性化推薦,「讓全局優秀的內容被你們看到」應該算是非個性化推薦,熱門榜單/最多觀看這類方法能夠簡單解決這個問題;不一樣的人對於「好」的理解不同,換句話說也就是偏好不一樣,因此推薦新加入的好內容我認爲是個性化推薦問題。
個性化推薦的兩個主要思想八個字歸納之:物以類聚、人以羣分。主要的方法及變種應該有不少,像協同過濾、基於內容的推薦、基於標籤的推薦等等。chrome
http://blog.csdn.net/czp11210/article/details/51161541數據庫
查看磁盤空間命令:df –lh編程
grep -rn "aaa"&& "bbb" *瀏覽器
* : 表示當前目錄全部文件,也能夠是某個文件名緩存
-r 是遞歸查找安全
-n 是顯示行號服務器
-R 查找全部文件包含子目錄微信
-i 忽略大小寫
白盒測試:語句覆蓋、條件覆蓋、斷定覆蓋、斷定條件覆蓋、條件組合覆蓋
黑盒測試:等價劃分法、邊界值法、因果圖法、猜錯法、隨機數法
五、 三角形測試用例類別 |
||
輸入條件 |
有效等價類 |
無效等價類 |
是不是三角形 |
(A>0) (1) (B>0) (2) (C>0) (3) (A+B>C) (4) (B+C>A) (5) (C+A>B) (6) |
(A<=0) (7) (B<=0) (8) (C<=0) (9) (A+B<=C) (10) (B+C<=A) (11) (C+A<=B) (12) |
是不是等腰三角形 |
(A=B) (13) (B=C) (14) (C=A) (15) |
(A!=B)and(B!=C)and(C!=A) (16) |
是不是等腰直角三角形 |
(A=B)and(A2+B2=C2) (17) (B=C)and(B2+C2=A2) (18) (C=A)and(C2+A2=B2) (19) |
(A!=B)and(B!=C)and(C!=A) (20) |
是不是等邊三角形 |
(A=B)and(B=C)and(C=A) (21) |
(A!=B) (22) (B!=C) (23) (C!=A) (24) |
三角形測試用例:用最少的測試用例覆蓋全部的有效等價類,而無效等價類每一個類型都要覆蓋到
序號 |
輸入[A,B,C] |
覆蓋等價類 |
輸出 |
1 |
[3,4,5] |
(1)(2)(3)(4)(5)(6) |
是三角形 |
2 |
[0,1,2] |
(7) |
非三角形 |
3 |
[1,0,2] |
(8) |
非三角形 |
4 |
[1,2,0] |
(9) |
非三角形 |
5 |
[1,2,3] |
(10) |
非三角形 |
6 |
[1,3,2] |
(11) |
非三角形 |
7 |
[3,1,2] |
(12) |
非三角形 |
8 |
[3,3,4] |
(1)(2)(3)(4)(5)(6)(13) |
等腰三角形 |
9 |
[3,4,4] |
(1)(2)(3)(4)(5)(6)(14) |
等腰三角形 |
10 |
[3,4,3] |
(1)(2)(3)(4)(5)(6)(15) |
等腰三角形 |
11 |
[2√2,2√2,4] |
(1)(2)(3)(4)(5)(6)(17) |
等腰直角三角形 |
12 |
[4,2√2,2√2] |
(1)(2)(3)(4)(5)(6)(18) |
等腰直角三角形 |
13 |
[2√2,4,2√2] |
(1)(2)(3)(4)(5)(6)(19) |
等腰直角三角形 |
14 |
[3,4,5] |
(1)(2)(3)(4)(5)(6)(16)(20)(22)(23)(24) |
是三角形 |
15 |
[3,3,3] |
(1)(2)(3)(4)(5)(6)(16)(21) |
等邊三角形 |
16 |
[,,,] |
無效等價類 |
錯誤提示 |
17 |
[-3,4,5] |
無效等價類 |
錯誤提示 |
18 |
[a,3,@] |
無效等價類 |
錯誤提示 |
19 |
[3,4] |
無效等價類 |
錯誤提示 |
按照功能測試的劃分等價類來測試
有效的等價類有:
金額剛夠,順利出貨
金額超出,找零出貨
金額超出, 沒錢找零,出貨.
金額不足,進行提示,把貨幣退出
金額足夠,取消交易
假幣,不出
無效等價類:
投入金額,不出貨,不找零
投入金額,不出貨,退錢
金額超出,出貨,不找零
金額超出,不出貨,找零
金額不足,出貨,找零l
金額不足,出貨,不找零
金額不足,不出貨,不退款
金額剛夠,不出貨,退款
金額剛夠,出貨,找零
金額剛夠,不出貨,找零
不投金額,直接出貨
如今的軟件行業突飛猛進,發展的如日中天,同行之間的競爭更是此起彼伏,稍有不慎就會面臨破產,其中產品的質量更是重中之重,出現一點點小問題就會致使用戶量驟減,因爲我國的互聯網行業起步較晚,在質量把控這方面沒有國外作到到位,但我相信,軟件測試行業將會有很大的發展前景,我也能在這個領域一展個人抱負。
優點:
一、 我有足夠的責任心
二、 有很好的學習能力
三、 適應新事物新環境很迅速
四、 有計算機相關理論基礎
劣勢:
一、 缺乏社會經驗
二、 編程能力較弱
無論你怎麼放,機率都是二分之一。
譬如,紅的全放一個箱子,那麼只要你從倆個箱子中選擇這個箱子,就必定是紅球,爲二分之一。
二,若是一個箱子放一半紅球一半籃球,那麼你隨便抽一個箱子,都是二分之一的機率抽到紅球。
三,任意狀況,如,箱子一有30個紅球,那麼紅球的機率,爲1/2*30/50+1/2*20/50,仍是二分之一
採用反推過來的算法:
5號表決時,造成的狀態是:
1獲得0個寶石,死
2獲得0個寶石,死
3獲得0個寶石,死
4獲得0個寶石,死
5獲得100個寶石,活,贊成
緣由:
不用講了,能輪到5號表決固然他獨吞了
可是也會與題目違背了,由於前面幾個海盜都是傻瓜差很少
4號表決時,造成的狀態是:
1獲得0個寶石,死
2獲得0個寶石,死
3獲得0個寶石,死
4獲得100個寶石,活,贊成
5獲得0個寶石,活,不一樣意
緣由:
這時只剩下二比一的狀況,只要本身贊成便可達到半數而經過表決,不存在生命危險
可是3號也不是白癡
3號表決時,造成的狀態是:
1獲得0個寶石,死
2獲得0個寶石,死
3獲得99個寶石,活,贊成
4獲得0個寶石,活,不一樣意
5獲得1個寶石,活,贊成
輪到3號時,他只要給5號1個寶石就夠了
緣由:
由於5號會意識到,一旦輪到4號時他就一個也得不到,如今能獲得1個寶石已是給了面子了
但2號也很聰明的,可否輪到他只是一種期待,來看看2號的狀況
2號表決時,造成的狀態是:
1獲得0個寶石,死
2獲得99個寶石,活,贊成
3獲得0個寶石,活,不一樣意
4獲得1個寶石,活,贊成
5獲得0個寶石,活,不一樣意
要是輪到此海盜他必會拿走99顆寶石,而後給4號1顆便可!
爲何? 緣由是:
4號已經意識到,要是輪到3號表決時,他將一個也得不到,因此這時有點收穫,當然贊成了
這時也考慮到:
3號不可巴結,會損失太多,由於若是隻是單單給3號的話,他隨時均可以不一樣意而得到表決權
5號也可巴結,但須要2顆寶石,不合算,由於5號也知道即便下一輪也是拿定一顆寶石的
1號:此海盜固然也聰明瞭
從上述看出,既然輪到2號的局勢已定,那他早已知道後面的海盜內心想什麼了
也就是簡單的說,他們清楚認識到,輪到2號時,3號和5號得不到寶石!
那麼這樣的話,事情就好辦多了,給他們一人一顆天然就搞定了!
因此,1海海盜毅然做出決定,分別給3號和5號各1顆寶石
最終結局的狀態是:
1獲得98個寶石,活,贊成
2獲得 0個寶石,活,不一樣意
3獲得 1個寶石,活,贊成
4獲得 0個寶石,活,不一樣意
5獲得 1個寶石,活,贊成
即:98,0,1,0,1 (達到1號利益最大化)
1、使用的是有線網線
一、路由器數據堵塞,通常重啓路由能夠解決;若是重啓仍不能解決,多是運營商的問題了,及時電話諮詢;
二、自身電腦問題,鏈接有線網的狀況,這種狀況不多見;
2、鏈接的是無線網
一、路由器問題,重啓路由試試;也不排除線路問題;
二、無線接收器問題,看燈閃爍是否正常,能夠嘗試拔隊,從新插上;
三、也能夠嘗試把無線禁用,而後從新開無線網絡;
四、從新安裝無線網驅動試試;
1.紙張的質地,是否爲紙張
2.紙張的品質,是草木、皮革。。。
3.紙張的類別,是否爲白紙
4.紙張的功能,可否書寫,圖畫等
5.紙張的兼容性,水筆、油筆、鉛筆是都都能正常書寫
6.紙張的擴展性,摺疊、拉伸
7.紙張的安全性,紙張的生產工藝是否安全,紙張有無有毒性物質
8.紙張的結構
9.紙張的性能:對各類筆的吸油性是否夠快
一、求語文分數最高的學生
Select 姓名,max(分數)from 表名where 課程名=「語文」
2.求每一個班語文成績最高的學生
第一次握手:創建鏈接時,客戶端發送syn包(syn=j)到服務器,並進入SYN_SENT狀態,等待服務器確認;SYN:同步序列編號(Synchronize Sequence Numbers)。
第二次握手:服務器收到syn包,必須確認客戶的SYN(ack=j+1),同時本身也發送一個SYN包(syn=k),即SYN+ACK包,此時服務器進入SYN_RECV狀態;
第三次握手:客戶端收到服務器的SYN+ACK包,向服務器發送確認包ACK(ack=k+1),此包發送完畢,客戶端和服務器進入ESTABLISHED(TCP鏈接成功)狀態,完成三次握手。
補充:
完成三次握手,客戶端與服務器開始傳送數據,在上述過程當中,還有一些重要的概念:
未鏈接隊列
在三次握手協議中,服務器維護一個未鏈接隊列,該隊列爲每一個客戶端的SYN包(syn=j)開設一個條目,該條目代表服務器已收到SYN包,並向客戶發出確認,正在等待客戶的確認包。這些條目所標識的鏈接在服務器處於SYN_RECV狀態,當服務器收到客戶的確認包時,刪除該條目,服務器進入ESTABLISHED狀態。
對於一個已經創建的鏈接,TCP使用改進的三次握手來釋放鏈接(使用一個帶有FIN附加標記的報文段)。TCP關閉鏈接的步驟以下:
第一步,當主機A的應用程序通知TCP數據已經發送完畢時,TCP向主機B發送一個帶有FIN附加標記的報文段(FIN表示英文finish)。
第二步,主機B收到這個FIN報文段以後,並不當即用FIN報文段回覆主機A,而是先向主機A發送一個確認序號ACK,同時通知本身相應的應用程序:對方要求關閉鏈接(先發送ACK的目的是爲了防止在這段時間內,對方重傳FIN報文段)。
第三步,主機B的應用程序告訴TCP:我要完全的關閉鏈接,TCP向主機A送一個FIN報文段。
第四步,主機A收到這個FIN報文段後,向主機B發送一個ACK表示鏈接完全釋放。
保活計時器:
設想有這樣的狀況:客戶端已主動與服務器創建了TCP鏈接,但後來客戶端的主機忽然出現故障。
一般設爲2小時。若2小時沒有收到客戶端的數據,服務器就發送一個探測報文段,之後則每隔75分鐘發送一次。若一連發送10個探測報文段後仍無客戶端的響應,服務器就認爲客戶端出現了故障,接着就關閉這個鏈接。
答:由於當Server端收到Client端的SYN鏈接請求報文後,能夠直接發送SYN+ACK報文。其中ACK報文是用來應答的,SYN報文是用來同步的。可是關閉鏈接時,當Server端收到FIN報文時,極可能並不會當即關閉SOCKET,因此只能先回復一個ACK報文,告訴Client端,"你發的FIN報文我收到了"。只有等到我Server端全部的報文都發送完了,我才能發送FIN報文,所以不能一塊兒發送。故須要四步握手。
答:雖然按道理,四個報文都發送完畢,咱們能夠直接進入CLOSE狀態了,可是咱們必須假象網絡是不可靠的,有能夠最後一個ACK丟失。因此TIME_WAIT狀態就是用來重發可能丟失的ACK報文。
一、功能測試
圖片、文字(大段文字)、小視頻、語音)是否發送順利,數據有沒有丟失、有沒有延遲,一我的發了100遍一樣的數據可否發送成功,羣發功能
二、性能測試
併發度,響應時間,系統資源佔用、壓力測試、兼容性測試(硬件兼容和軟件兼容)、還有就是考慮多端登陸消息的同步
Fiddler是一款很是流行而且實用的http抓包工具,它的原理是在本機開啓了一個http的代理服務器,而後它會轉發全部的http請求和響應,所以,它比通常的firebug或者是chrome自帶的抓包工具要好用的多。不只如此,它還能夠支持請求重放等一些高級功能。顯然它是能夠支持對手機應用進行http抓包的。
黑盒測試:等價劃分法、邊界值斷定、因果圖、錯誤猜想
白盒測試:語句覆蓋、條件覆蓋、斷定覆蓋、條件/斷定覆蓋、條件組合覆蓋
dd 刪除一整行
D d$ 刪除光標位置到本行結尾
d0 刪除光標位置到本行開頭
2六、Linux怎麼查看大文件,怎麼實時查看文件
[root@getlnx01 u03]# find . -type f -size +800M -print0 | xargs -0 ls –l
負載測試、壓力測試、疲勞性測試、容量測試
一、GET請求,請求的數據會附加在URL以後,以?分割URL和傳輸數據,多個參數用&鏈接。URL的編碼格式採用的是ASCII編碼,而不是uniclde,便是說全部的非ASCII字符都要編碼以後再傳輸。
POST請求:POST請求會把請求的數據放置在HTTP請求包的包體中。上面item=bandsaw就是實際的傳輸數據。所以,GET請求的數據會暴露在地址欄中,而POST請求則不會。
二、傳輸數據的大小
在HTTP規範中,沒有對URL的長度和傳輸的數據大小進行限制。可是在實際開發過程當中,對於GET,特定的瀏覽器和服務器對URL的長度有限制。所以,在使用GET請求時,傳輸數據會受到URL長度的限制。
對於POST,因爲不是URL傳值,理論上是不會受限制的,可是實際上各個服務器會規定對POST提交數據大小進行限制,Apache、IIS都有各自的配置。
三、安全性
POST的安全性比GET的高。這裏的安全是指真正的安全,而不一樣於上面GET提到的安全方法中的安全,上面提到的安全僅僅是不修改服務器的數據。好比,在進行登陸操做,經過GET請求,用戶名和密碼都會暴露再URL上,由於登陸頁面有可能被瀏覽器緩存以及其餘人查看瀏覽器的歷史記錄的緣由,此時的用戶名和密碼就很容易被他人拿到了。除此以外,GET請求提交的數據還可能會形成Cross-site request frogery攻擊
不必定
作性能測試用的。測試軟件的性能、壓力、負載狀況、服務器的響應時間,吞吐量、監控服務器、數據庫的性能指標。等等。總之很強大。