MB - Ngân hàng Quân Đội MB
Note 1 : Nộp đơn tại website
https://tuyendung.mbbank.com.vn/TrangChu
Sau tầm 10 ngày thì sẽ nhận được cuộc gọi mời đi phỏng vấn
Note
2 : Phỏng vấn thì có 3 anh chị sẽ phỏng vấn về chuyên môn, các anh sẽ hỏi về
kinh nghiệm làm việc, hỏi về có thể OT được không, hỏi vì sao chuyển
việc, hỏi mức lương mong muốn là bao nhiêu, hỏi về cơ sở dữ liệu, hỏi sự
khác nhau giữa having và where, hỏi có biết đá bóng không, có tham gia
hoạt động văn nghệ nào không, hỏi
kinh nghiệm xử lý khi gặp bug, hỏi khi xảy ra xung đột với code thì
hướng giải quyết như nào, hỏi về số lượng bảng thông thường tối đa trong
1 cơ sở dữ liệu, hỏi cách tối ưu hóa câu lệnh sql, hỏi về cách đánh
index, hỏi về các trường tối thiểu trong 1 bảng, hỏi các case kiểm thử
cơ bản, hỏi char(10) và varchar(10) khác nhau như thế nào. Hỏi về trong tờ khai nộp thuế có những trường như nào.
Note 3 : Nếu Ok ở vòng phỏng vấn thì sẽ nhận được cuộc gọi mail báo
trúng tuyển, sẽ yêu cầu nộp khá nhiều giấy tờ bao gồm quyết định chấm
dứt hợp đồng lao động ở công ty cũ, bảo hiểm ở công ty cũ, sao kê bảng
lương trong 3 tháng gần nhất nên mình khuyên các bạn đừng nên nói dối về
mức lương hiện tại với nhà tuyển dụng kẻo khi được nhận rồi lại mất hay
đi.
Note 4 : Kiến thức các bạn cần chuẩn bị
I. Các mô hình phát triển phần mềm như
- Mô hình thác nước
- Mô hình xây dựng tiến triển
- Công nghệ phần mềm dựa thành phần
- Mô hình phát triển lặp lại, tăng thêm
- Mô hình xoắn ốc
Lần
2 : Sau khi thi lần 1 nếu đạt ( 2 môn thi kia trên 50% ) thì sẽ được
gọi đi thi lần 2 sau khoảng 15 ngày, thi lần 2 thì mình được gọi đi
phỏng vấn thời đó là ở 93 Trung Kính, thành phần phỏng vấn gồm khoảng 6
anh chị phỏng vấn, các anh chị yêu cầu mình trình bày về bản thân, về
năng lực, hỏi 1 số câu hỏi lý thuyết về giai đoạn kiểm thử và các phương
pháp kiểm thử. Các bạn chỉ cần nắm vững các kiến thức dưới đây :
II. Các giai đoạn kiểm thử
1. Kiểm thử mức đơn vị (Unit Test)
- Kiểm thử đơn vị hay tiếng anh gọi là Unit Test là kiểm thử trên từng
đơn vị nhỏ nhất của phần mềm mà chúng ta có thể thực hiện kiểm thử.
Đó có thể là một hàm (function), một thủ tục (stored procedure),..
- Ở giai đoạn kiểm thử này nếu phát hiện lỗi, việc xác định nguyên
nhân và khắc phục cũng tương đối dễ dàng vì chỉ khoanh vùng trong một
đơn thể Unit đang kiểm tra.
- Một nguyên lý đúc kết từ thực tiễn: thời gian tốn cho Unit Test tiết
kiệm hơn rất nhiều thời gian ở các mức kiểm tra sau đó. Bên canh đó chi
phí cho việc kiểm tra và sửa lỗi cũng là thấp nhất.
Người thực hiện test đơn vị thường là lập trình viên. Các testcase trong
giai đoạn này có thể giữ lại để tái sử dụng cho các dự án khác.
- 2. Kiểm thử tích hợp(Integration Test)
- Unit riêng lẻ thì Integration Test kết hợp chúng lại với nhau và kiểm tra sự giao tiếp giữa chúng.
- Integration test kết hợp các thành phần của một ứng dụng và kiểm tra như một ứng dụng đã hoàn thành.
- Integration Test có 2 mục tiêu chính:
Phát hiện lỗi giao tiếp xảy ra giữa các Unit
Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ (subsystem) và cuối cùng
là hoàn chỉnh hệ thống (system) để chuẩn bị cho kiểm tra ở mức hệ thống
(System Test)
- Tại sao nên tích hợp dần từng Unit ?
Một Unit khi được tích hợp vào một nhóm các Unit khác đã tích hợp trước
đó thì lúc này, ta chỉ cần kiểm tra giao tiếp của Unit mới thêm vào với
nhóm các Unit đã được tích hợp trước đó. Điều này làm cho số lượng kiểm
tra sẽ giảm đi rất nhiều, sai sót sẽ giảm đáng kể.
Người thực hiện test tích hợp thường là lập trình viên
- 3. Kiểm thử hệ thống(System test)
Mục đích System Test là kiểm tra thiết kế và toàn bộ hệ thống (sau khi tích hợp) có thỏa mãn yêu cầu đặt ra hay không?
Phải thực hiện Unit Test và Integration Test để bảo đảm mọi Unit và sự
tương tác giữa chúng hoạt động chính xác trước khi thực hiện System
Test.
Đặc điểm kiểm tra hệ thống
Tốn rất nhiều công sức
Mất nhiều thời gian
Bởi vì trọng tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầu khác liên quan đến chất lượng của toàn hệ thống.
Điểm khác nhau then chốt giữa Integration Test và System Test
System Test: chú trọng các hành vi và lỗi trên toàn hệ thống
Integration Test: chú trọng sự giao tiếp giữa các đơn thể (Unit) khi chúng làm việc cùng nhau.
Người thực hiện test hệ thống thường là kiểm thử viên. Một hoặc nhóm
kiểm thử viên test hoàn toàn độc lập so với nhóm phát triển dự án.
4. Kiểm tra chấp nhận sản phẩm (Acceptance Test) hay còn gọi là kiểm thử nghiệm thu
Acceptance Test có ý nghĩa hết sức quan trọng. Giai đoạn này thường
được khách hàng thực hiện (hoặc ủy quyền cho một nhóm thứ ba thực hiện)
để kiểm tra xem sản phẩm thực hiện có đáp ứng được yêu cầu đặt ra của
mình trước đó hay không.
Trong hầu hết mọi trường hợp, các phép kiểm tra của System Test và
Acceptance Test gần như tương tự, nhưng bản chất và cách thức thực hiện
lại rất khác biệt.
Thực tế cho thấy, nếu khách hàng không quan tâm và không tham gia vào
quá trình phát triển phần mềm thì kết quả Acceptance Test sẽ sai lệch
rất lớn, mặc dù phần mềm đã trải qua tất cả các kiểm tra trước đó.
III. Các phương pháp kiểm thử
Gồm có:
1. White box testing
2. Black box testing
3. Grey box testing
Các
phương pháp test được chia theo cách truyền thống gồm có whitebox
testing (kiểm thử hộp trắng) - và blackbox testing (hộp đen). Hai phương
pháp tiếp cận này được sử dụng để mô tả điểm nhìn mà kỹ thuật viên test
(tester engineer) sử dụng khi thiết kế các test case.
1. White box testing
Khi
thiết kế test case và test, các tester truy cập thẳng vào bên trong
source code, cấu trúc và thuật toán của chương trình và thực thi nó được
gọi là White box testing.
Có các loại white box testing đang tồn tại như sau:
* API testing (application programming interface) – Kiểm thử ứng dụng bằng cách sử dụng các hàm API public và private
*
Code coverage – Là việc tạo các trường hợp test để thỏa mãn một số điều
kiện bao phủ code - code coverage (ví dụ như, người thiết kế test có
thể tạo ra các trường hợp test sao cho tất cả các câu lệnh của chương
trình đều được thực thi ít nhất 1 lần)
* Fault injection methods – cải tiến bao phủ một trường hợp bằng cách đưa một số lỗi vào để test các đường dẫn code.
* Mutation testing methods
* Static testing - White box testing bao gồm tất cả các phương pháp kiểm thử tĩnh (ví dụ review code).
Kiểm thử độ bao phủ
Phương
pháp kiểm thử white box cũng có thể được sử dụng để ước lượng tính trọn
vẹn đầy đủ của các tập hợp kiểm thử (test suit) đã được tạo ra bằng
phương pháp kiểm thử black box. Điều này cho phép nhóm sản xuất phần mềm
xem xét lại các phần của hệ thống ít được test nhất và để chắc chắn
rằng các chức năng quan trọng nhất đã được tập trung test kỹ.
Hai hình thức chung của kiểm thử độ bao phủ code:
* Bao phủ chức năng - Function coverage, dựa trên việc thực thi các chức năng.
* Bao phủ câu lệnh - Statement coverage, dựa trên số lượng các dòng lệnh đã được thực thi để hoàn thành kiểm thử.
Cả hai hình thức trên đề trả về một cách đo độ bao phủ code, sự đo lường được tính bằng phần trăm %.
2. Black box testing
Phương
pháp kiểm thử Black box là nghiên cứu xem phần mềm như là một “hộp đen”
– không biết gì về hoạt động bên trong của nó. Các phương pháp kiểm thử
Black box bao gồm: equivalence partitioning (phân vùng tương đương),
boundary value analysis (phân tích giá trị biên), all-pairs testing
(kiểm thử tất cả các cặp), fuzz testing (cách test: nhập vào các điều
kiện sai hoặc data một cách ngẫu nhiên), model-based testing (Kiểm thử
dựa trên model), traceability matrix (các chức năng của chương trình
được tạo thành một ma trận, các trường hợp test là sự kết hợp các dòng
hoặc các cột có liên quan), exploratory testing (kiểm thử chủ yếu dựa
vào kinh nghiệm và khả năng focus vào việc test các chức năng của
tester) và specification-based testing (kiểm thử dựa vào chức năng).
Phương
pháp kiểm thử dựa vào chức năng - Specification-based testing: Việc
kiểm thử được tiến hành dựa vào việc kiểm thử chức năng của phần mềm xem
nó có phù hợp với yêu cầu của người dùng hay không. Vì vậy, các tester
nhập data vào phần mềm và chỉ cần xem kết quả của phần mềm và các mục
tiêu test. Mức test này thường yêu cầu các tester phải viết test case
đầy đủ trước khi test, khi test, đơn giản chỉ cần thực hiện theo các
bước mô tả trong test case thao tác và nhập data vào, sau đó xem kết quả
trả về hoặc hành vi của phần mềm, rồi so sánh với kết quả mong đợi đã
được viết trong test case, điền kết quả test vào test case là OK (OK =
is – chương trình làm đúng theo mong đợi) hay NG (not good = is not –
chương trình không làm đúng theo mong đợi).
Specification-based
testing là cần thiết, nhưng nó không đủ để bảo đảm chắc chắn các rủi ro
xảy ra (nó chỉ là điều điện cần chứ không phải là điều kiện đủ).
Ưu
điểm và nhược điểm: Các tester kiểm thử theo phương pháp black box
không có “mối ràng buộc” nào với code, và nhận thức của một tester rất
đơn giản: một source code có nhiều lỗi. Sử dụng nguyên tắc, "Hỏi và bạn
sẽ nhận" các tester black box tìm được nhiều bug ở nơi mà các DEV không
tìm thấy. Mặt khác, việc kiểm thử black box được xem như "là bước đi
trong mê cung tối đen mà không mang đèn pin” bởi vì tester không biết
phần mềm đang test đã được xây dựng như thế nào. Như là một kết quả, ở
đây có nhiều trường hợp khi một tester viết rất nhiều trường hợp test để
kiểm tra một số thứ có thể chỉ được test bằng một trường hợp test (1),
và/hoặc một vài phần cuối cùng không được test hết.
Vì vậy, black
box testing có ưu điểm là "an unaffiliated opinion" (một quan điểm độc
lập), mặt khác, nó có nhược điểm là "blind exploring" (khám phá mù).
3. Grey box testing
Grey
box testing (Viết theo Tiếng Mỹ: gray box testing) bao gồm các kiến
thức về các thuật toán, cấu trúc bên trong của chương trình để thực hiện
mục đích việc thiết kế các trường hợp test, nhưng việc test phải thực
hiện như là người dùng (suy nghĩ theo cách nghĩ của người dùng cuối),
hoặc thiết kế ở mức black-box. Việc vận dụng dữ liệu đầu vào và xác định
qui cách đầu ra không được gọi là grey box, bởi vì điều kiện input và
output là ở bên ngoài rõ ràng là của "black-box" trên hệ thống chúng ta
đang test. Sự phân biệt này đặc biệt quan trọng khi tiến hành thử nghiệm
tích hợp giữa hai module đã được viết bởi hai DEV khác nhau, ở đó chỉ
có các interface (giao tiếp giữa 2 module) được đưa ra để kiểm thử. Tuy
nhiên, việc chỉnh sửa ngân hàng data test không được xem là grey box,
như người dùng bình thường thì sẽ không thể thay đổi data bên ngoài hệ
thống đang test. Grey box testing cũng có thể bao gồm kỹ thuật đảo ngược
để xác định, ví dụ, các giá trị biên hoặc thông báo lỗi.
Ghi chú:
- Trường hợp kiểm thử = test case
- Các trường hợp kiểm thử = test cases
IV. Cơ sở dữ liệu ư
4.1. Sự khác nhau giữa where và having
WHERE - filter kết quả theo dòng
HAVING - filter kết quả theo GROUP
Ví dụ: bạn có 1 bảng như sau (3 trường student, subject, mark nhé)
A, math, 8
A, physics, 5
B, math, 4
C, physics, 9
Câu lệnh: SELECT student, sum(mark) from math GROUP BY student, nó sẽ ra
A, 13 (nó kiếm student giống nhau, ở đây 2 dòng đều có A nên lấy SUM)
B, 4
C, 9
Câu lệnh: SELECT student, sum(mark) from math WHERE mark > 5 GROUP BY student, nó sẽ ra
A, 8
C, 9
nó sẽ check WHERE từng dòng trước, sau đó mới GROUP BY
Câu lệnh: SELECT student, sum(mark) as s from math WHERE mark > 5 GROUP BY student HAVING s>8, nó sẽ ra
C,9
HAVING
thì mới dùng với các điều kiện của cả nhóm (GROUP) như max, sum, count,
... được (gọi là các hàm tổng hợp (AGGREGATE function) được define trên
1 tập hợp)
Chú ý: WHERE phải trước GROUP BY nhé.
4.2. Sự khác nhau giữa GROUP BY và HAVING
Các hàm tập hợp (ví dụ như SUM) thông thường cần thêm chức năng của mệnh đề GROUP BY.
GROUP BY...
Mệnh đề GROUP BY...được thêm vào SQL bởi vì các hàm tập hợp (như SUM)
trả về một tập hợp của các giá trị trong cột mỗi khi chúng được gọi, và
nếu không có GROUP BY ta không thể nào tính được tổng của các giá trị
theo từng nhóm riêng lẻ trong cột.
Cú pháp của GROUP BY như sau:
SELECT tên_cột, SUM(tên_cột) FROM tên_bảng GROUP BY tên_cột
Ví dụ sử dụng GROUP BY:
Giả sử ta có bảng Sales như sau:
| Company | Amount |
|---|
| W3Schools | 5500 |
| IBM | 4500 |
| W3Schools | 7100 |
Câu lệnh SQL sau:
SELECT Company, SUM(Amount) FROM Sales
sẽ trả về kết quả:
| Company | SUM(Amount) |
|---|
| W3Schools | 17100 |
| IBM | 17100 |
| W3Schools | 17100 |
Kết quả trả về ở trên đôi khi không phải là cái mà ta mong đợi. Ta thêm mệnh đề GROUP BY vào trong câu lệnh SQL:
SELECT Company, SUM(Amount) FROM Sales GROUP BY Company
và kết quả trả về lần này sẽ là:
| Company | SUM(Amount) |
|---|
| W3Schools | 12600 |
| IBM | 4500 |
Kết quả này đúng là cái mà ta mong muốn.
HAVING...
Mệnh đề HAVING...được thêm vào SQL vì mệnh đề WHERE không áp dụng được đối với các hàm tập hợp (như SUM). Nếu không có HAVING, ta không thể nào kiểm tra được điều kiện với các hàm tập hợp.
Cú pháp của HAVING như sau:
SELECT tên_cột, SUM(tên_cột) FROM tên_bảng GROUP BY tên_cột HAVING SUM(tên_cột) điều_kiện giá_trị
Ta sử dụng lại bảng Sales ở trên. Câu lệnh SQL sau:
SELECT Company, SUM(Amount) FROM Sales GROUP BY Company HAVING SUM(Amount) > 10000
sẽ trả về kết quả:
| Company | SUM(Amount) |
|---|
| W3Schools | 12600 |
Đấy
là toàn bộ kinh nghiệm phỏng vấn làm việc tại MB mà mình muốn chia
sẻ với các bạn. Chúc các bạn may mắn nhé!
Have Fun!!!
