Trung tâm đào tạo thiết kế vi mạch Semicon

Login

Username: Password:

Forgot your password? Forgot your username?
ĐĂNG KÝ TÀI KHOẢN ĐỂ TRUY CẬP NHIỀU TÀI LIỆU HƠN!

Create an account

Skip to content

Công việc hàng ngày của một Tester như thế nào?

Sunday, 16 June 2019 19:58 Semicon Editor 01

Chào các bạn, hôm nay tôi chia sẻ cho các bạn về công việc hàng ngày của một tester là như thế nào. Mục đích là để các bạn có một cái nhìn cụ thể về nghề công nghệ thông tin nói chung cũng như là tester nói riêng.

Những bạn nào đang tìm hiểu về nghề nghiệp này có thể đọc để tham khảo. Tất nhiên, đây chỉ là một công việc việc cụ thể ở một công ty đặc thù, nó sẽ không phản ánh được một cách khái quát nhất về nghề này, nhưng bài viết cũng sẽ giúp bạn hiểu được phần nào công việc tester.

Nói rõ thêm một chút, vị trí cụ thể của tôi tại công ty là: Design Verification Engineer và mới đây được đổi lại thành (Logic Verification) và mình đã làm công việc này được 2 năm. Nó khác với Sofware Tester vì bạn test cho ngôn ngữ mô tả phần cứng Verilog, sản phẩm bạn test không phải là phần mềm mà một loại hardward, một loại chịp. Tại sao lại có chữ “design” ở đây? Mặc dù công việc chính của tôi là tester, nhưng đồng thời, mình cũng phải thiết kế ra môi trường (enviroment), để mà có thể phục vụ việc test, chứ không phải có sẵn tool.

Tôi sử dụng ngôn ngữ SystemVerilog (một ngôn ngữ lai giữa Verilog và C++) và framework UVM (Universal Verification Methodology). Tôi dùng những phương tiện này thiết kế ra Testbench (có thể hiểu như test tool) để test cho sản phầm được viết bằng Verilog. Một cách cơ bản và để dễ hiểu có thể giải thích như vầy: bây giờ bạn có một khối code viết bằng Verilog gọi là A, khối A này cần có input (đầu vào) để có thể hoạt động được, tuỳ theo chức năng, khối A này sẽ phát ra output (đầu ra).

Các thành phần của UVM

Một môi trường cơ bản để test gồm có những thành phần như sau

- Bộ phát (generator): phát ra những tín hiệu mong muốn để đưa vào input cho khối A có thể hoạt động được, giống như bạn có một cái quạt điện, thì để muốn nó hoạt động được bạn phải cung cấp điện cho nó, điện chính là input của nó.

- Bộ ghi nhận dữ liệu (monitor): khối này dùng để ghi nhận lại những output của khối A phát ra. Giống như cái quạt điện, khi bạn cấp điện cho nó, nó sẽ chạy. Bạn sẽ đo và ghi lại tốc độ gió, số vòng quay của cánh quạt…

- Bộ tiên đoán (predictor): khối này có nhiệm vụ là giả lập lại chức năng giống như khối A. Tưởng tượng như nó là một cái quạt điện mẫu, cái quạt này dùng để làm chuẩn, để so sánh với cái quạt cần test

Công việc được tiến hành như sau: bạn dùng bộ phát để cấp điện cho 2 cái quạt, một cái quạt mẫu và một cái quạt muốn test. Sau đó bạn dùng bộ ghi nhận dữ liệu để đo lại thông số đầu ra của 2 cái quạt này. Tiếp đến bạn sẽ so sánh 2 thông số này với nhau. Nếu giống nhau thì ok, bạn sẽ chuyển sang testcase mới, tức là đưa vào những input khác, để có những output khác. Nếu khác nhau, lúc này bạn bắt đầu kiểm tra coi mình cấp điện vào đúng chưa, rồi mình chỉnh 2 cái quạt giống nhau chưa, xem lại cái quạt mẫu của mình có bị sao không, nếu như tất cả thiết bị dùng để test đều tốt, thì lúc này bạn đưa lỗi đó qua cho người thiết kế để họ sửa.

Công việc hằng ngày sẽ như thế nào?

Viết testcase, testplan. Testcase thì kiểu như bạn input gì, cấu hình như nào, mong muốn tín hiệu ra sẽ ra sao. Còn testplan sẽ là tập hợp những testcase đó, bạn sẽ dựa vô testplan để biết mình đã test đến đâu, còn thiếu case nào để có thể sắp xếp công việc và report cho xếp.

Testplan trông giống như thế này

Sử dụng ngôn ngữ SystemVerilog và framework UVM để viết nên Testbench. Compile code, run testcase, debug nếu có lỗi. Sử dụng các tool hỗ trợ để xem wave, phân tích log file. Đây có thể coi là phần thú vị nhất và mất thời gian nhất.

Khi đã phát hiện ra bug, debug chính xác bug đó không phải do mình tạo ra mà là bug của developer thì report bug, tạo ticket lên trên hệ thống để mô tả về bug, thông báo cho developer và những người liên quan như leader, manager.

Viết report hằng tuần hoặc hằng ngày tuỳ vô dự án để báo cáo cho leader/manager. Phần này có thể coi là phần vừa khó vừa dễ. Dễ khi tuần vừa rồi bạn làm được rất nhiều thứ, bạn kể lể ỉ ôi “xếp ơi em làm được nhiều lắm nè, abc…”, bạn tha hồ viết, vừa viết vừa phấn khích. Còn khó khi cả tuần không làm được gì, debug mãi không ra, developer bận việc khác không giải quyết bug cho bạn được, vân vân. Lúc này bạn phải vận dụng toàn bộ trí thông minh 200IQ để có thể nặn ra được việc bạn làm được trong tuần rồi (chứ không là mệt à )

Meeting hàng tuần hoặc hàng ngày để cập nhật tiến độ, báo cáo việc làm được, hoặc để giải quyết một vấn đề nào đó hóc búa cần giải quyết chung cả team.

Kỹ năng cần có của một tester? (Cụ thể là Design Verification Engineer)

- Về ngôn ngữ lập trình: SystemVerilog, UVM để có thể viết nên Testbench. Hiểu Verilog để có thể debug sâu. Python (hoặc các ngôn ngữ script) để xử lý một số tác vụ khác hỗ trợ trong việc debug như phân tích log, autotest.

- Kiến thức về phần cứng như RAM, Register, cổng logic AND, OR; mạch cộng/trừ, timing, xung clock, Finite state machine, vân vân…

- Kỹ năng lập trình, đặc biệt là phải hiểu OOP (Object Oriented Programming) cơ bản vì UVM giựa trên OOP.

- Quen với Linux và các command cơ bản vì bạn phải compile code và run testcase trên các máy server Linux.

- Các kiến thức cụ thể về sản phẩm và lĩnh vực đang làm (cái này phụ thuộc vô cty) như cty mình làm chip viễn thông thì phải có kiến thức về mạng viễn thông như SDH, PDH, Ethernet, TCP/IP, mô hình OSI…

- Tiếng Anh: RẤT cần thiết vì bạn phải đọc tài liệu tiếng Anh cực nhiều cũng như phải viết email trao đổi nếu làm cho các cty nước ngoài.

- Các kỹ năng mềm khác như kỹ năng report, kỹ năng viết email, sử dụng các phần mềm office cở bản…

Trên đây là những kỹ năng cần thiết nếu bạn muốn làm một Design Verification Engineer. Liệt kê ra thì có vẻ nhiều nhưng bạn sẽ đạt được những điều trên với 4 năm Đại Học. Nếu muốn nêu lên kỹ năng nào là cần thiêt nhất thì mình có thể nói đó là kỹ năng lập trình và kiến thức về phần cứng (tiếng Anh mặc định phải biết, ít nhất là đọc hiểu tài liệu), tất cả những kỹ năng khác bạn có thể học tập và rèn luyện thông qua quá trình làm việc.

Điểm vui và “không vui” khi làm tester là gì?

Đây là những điều vui và “không vui” cho lắm khi so tester với developer

Điểm “không vui” có nghĩa là những bất lợi, những thứ không “tốt lắm”

Khi sản phầm đã được release mà có bug, thì tức là bạn sai chứ không phải dev sai, vì bạn đã test không ra bug.

Xét về mặt bằng chung, và dĩ nhiên, lương bạn sẽ không cao bằng developer. Tuy nhiên, nếu bạn đang vui với việc mình đang làm thì việc gì phải so đo chuyện này phải không?

Công việc có lúc nào đó phải phụ thuộc vô dev, nhiều lúc bạn không chủ động kiểm soát được, phải chạy theo dev.

Khi testplan đã có, test tool chạy ổn định rồi thì bạn phải test đi test lại một tính năng rất nhiều lần, có thể gây nhàm chán rất cao.

Vui có nghĩa là những điểm lợi, những thứ “hay ho” khi bạn làm tester:

- Viết code không cần “chuẩn” lắm, không có quá nhiều rule bắt bạn phải vô khuôn khổ. Vì đặc thù tester là cần test sản phẩm nhanh nhất có thể chứ không phải là viết ra một test tool “perfect”. Do đó hầu như bạn có thể tự do thoải mái thích viết theo kiểu nào thì viết làm sao ra được test tool nhanh và “có thể chạy được”. Tuy nhiên, đây cũng có thể coi là một phần “hại”. Cũng chính vì chú trọng quá nhiều vô “chạy được” mà không chú trọng vô rule, vô perfomance nên test tool viết ra nhiều khi chạy khá chậm, tốn nhiều resouce khi chạy và khó nâng cấp, bảo trì sau này. (Bạn có biết là có những testcase phải chạy cả mấy ngày mới xong?! Vâng điều đó là có thật!)

- Khi đã có testplan và một testtool chạy khá ổn, lúc này bạn chỉ ung dung chạy testcase và report bug, cả thế giới cứ để developer lo

- Xét về mặt bằng chung và tổng thể, thời gian và lượng công sức bạn bỏ ra sẽ ít hơn với developer (mình nói mặt bằng chung nhé). Có nghĩa là bạn có thể (chỉ là có thể không phải luôn luôn) về sớm, giành thời gian nhiều hơn cho gia đình và bản thân.

- Tìm ra bug như một loại thuốc phiện, và tester sẽ là một con nghiện chân chính. Nếu niềm vui của developer là giấu bug (chứ không phải dev new feature), thì niềm vui của tester là moi ra được cái bug đó. Cảm giác tìm ra bug sẽ giống như bạn vừa mới giải một bài toán khó, chính phục một ngọn núi, hay một cô nàng nào đó vậy. Bạn sẽ cầm cái bug đó và report kiểu như: “Bug nè, fix đi mày, muhahaha. Còn tao sẽ ngồi phè phỡn xem mày sấp mặt…luôn”

Vâng, trên đó là một số tâm sự cũng như kinh nghiệm làm việc hơn 2 năm của tôi ở vị trí Design Verification Engineer (và giờ tôi đã làm Developer :D). Mong rằng các bạn đang đi tìm con đường sự nghiệp có thể hình dung được phần nào những niềm vui và “nỗi buồn” của nghề này để có thể lựa chọn công việc phù hợp cho mình!