Mcredit
Note 1 : Nộp đơn tại website http://mcreditjobs.com/tim-viec-lam/tat-ca-viec-lam/viSau tầm 7 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 sẽ phỏng vấn trong đó có 1 anh nhân sự và 2 anh 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. Khi phỏng vấn thì nên trao đổi thoải mái với các anh vì các anh cũng khá dễ tính nên mình cứ tự tin mà trao đổi thông tin về bản thân.
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)
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 Mcredit 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!!!
0 nhận xét:
Đăng nhận xét