Viettel - một tập đoàn mà nhiều sinh viên sau khi ra trường đều mơ ước được vào làm việc một phần vì Viettel trả lương cho nhân viên khá cao so với mặt bằng chung một phần vì oai chả hạn. Hi.
Bản thân mình cũng vậy sau khi ra trường, đã luôn mơ ước được vào làm việc cho Viettel, mơ thì làm thôi, thế là mình nộp đơn tuyển dụng vào Viettel tại trang website http://tuyendung.viettel.com.vn/RMSPortal/#!/home
Sau tầm 3 tháng, thì mình nhận được cuộc gọi mời đi phỏng vấn và thi.
Lần 1 : Mình được hẹn đi thi viết bao gồm thi tiếng anh ( Trắc nghiệm đơn giản thôi ) và thi chuyên môn ( cũng trắc nghiệm ) , thi chuyên môn thì hay thì về các mô hình phát triển phần mềm như
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 đó.
II. 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
Lần 3 : Sau khi đã Ok về kết quả phỏng vấn lần 2 thì bạn sẽ được gọi đi phỏng vấn lần 3 để check lại kiến thức của lần 2 ( Vì sẽ có anh chị khác phỏng vấn bạn ) và thương lượng mức lương.
Đấy là toàn bộ kinh nghiệm phỏng vấn làm việc tại Viettel mà mình muốn chia sẻ với các bạn. Chúc các bạn sẽ bước chân vào được ngôi nhà chung Viettel yêu dấu - Nơi mà mình đã gắn bó ở đó hơn 1 năm trời.
Have Fun!!!
Bản thân mình cũng vậy sau khi ra trường, đã luôn mơ ước được vào làm việc cho Viettel, mơ thì làm thôi, thế là mình nộp đơn tuyển dụng vào Viettel tại trang website http://tuyendung.viettel.com.vn/RMSPortal/#!/home
Sau tầm 3 tháng, thì mình nhận được cuộc gọi mời đi phỏng vấn và thi.
Lần 1 : Mình được hẹn đi thi viết bao gồm thi tiếng anh ( Trắc nghiệm đơn giản thôi ) và thi chuyên môn ( cũng trắc nghiệm ) , thi chuyên môn thì hay thì về 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 :
I. 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 đó.
II. 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
Lần 3 : Sau khi đã Ok về kết quả phỏng vấn lần 2 thì bạn sẽ được gọi đi phỏng vấn lần 3 để check lại kiến thức của lần 2 ( Vì sẽ có anh chị khác phỏng vấn bạn ) và thương lượng mức lương.
Đấy là toàn bộ kinh nghiệm phỏng vấn làm việc tại Viettel mà mình muốn chia sẻ với các bạn. Chúc các bạn sẽ bước chân vào được ngôi nhà chung Viettel yêu dấu - Nơi mà mình đã gắn bó ở đó hơn 1 năm trời.
Have Fun!!!
0 nhận xét:
Đăng nhận xét