Đề cương kiểm thử phần mềm nhúng (KMA)

Tổng hợp những câu hỏi cần thiết và quan trọng của môn Kiểm thử phần mềm nhúng (KMA). Tài liệu này giúp các bạn sinh viên có thể vượt qua các bài kiểm tra giữa kỳ, cuối kỳ và đạt kết quả cao nhất. Xin cảm ơn các bạn đã xem và tải tài liệu.

ĐỀ CƯƠNG ÔN TẬP CUỐI KỲ I Lý thuyết

Câu 1: Lợi ích chính của việc kiểm thử sớm trong chu kỳ phát triển phần mềm là gì? Vì

sao nói lỗi càng phát hiện muộn thì chi phí sửa lỗi càng cao?

• Lợi ích của kiểm thử sớm:

- Hoạt động kiểm thử nên bắt đầu càng sớm càng tốt trong chu trình phát triển mềm và cần được tập trung vào các mục tiêu xác định

- Kiểm thử sớm, phát hiện lỗi sớm, lỗi được sửa sớm sẽ đảm bảo được dự án hoàn thành đúng tiến độ và chất lượng sản phẩm cũng được đảm bảo Chi phí của dự án cũng sẽ không bị phát sinh

- Lỗi phát hiện muộn, sửa muộn, nhất là dồn vào giai đoạn thời gian cuối dự án, sẽ dẫn đến sửa vội, test vội, code vội, chất lượng không được đảm bảo, tiến độ không hoàn thành được dẫn đến phải overtime, tăng chi phí của dự án

- Phù hợp theo mô hình Thác nước

- Giúp phát hiện sớm các lỗi nghiêm trọng trong chu kỳ kiểm thử - Giúp Nhóm Phát triển ổn định mã nguồn sớm

- Giúp giảm thiểu chi phí do sửa lỗi

- Giúp Nhóm phát triển xác định các lỗi một cách chi tiết ngay từ đầu trong chu kỳ phát hành

- Nhóm quản lý có thể đưa ra các quyết định kinh doanh phù hợp dựa trên khối lượng các lỗi nghiêm trọng chưa được giải quyết trong Dự án/phiên bản phát hành

- Giúp phân phối tài nguyên dùng cho việc Phát triển và kiểm thử một cách hiệu quả

• Lỗi càng phát hiện muộn thì chi phí sửa lỗi càng cao vì:

- Lỗi được phát hiện càng muộn thì chi phí cho việc sửa lỗi càng lớn, bởi vì có những lỗi sẽ phải thực hiện lại từ khâu Thiết kế, rồi coding lại và mới thực hiện test được Nên lỗi được phát hiện càng sớm, càng ở những giai đoạn đầu dự án, thậm chí ngay từ giai đoạn làm Yêu cầu/ Nghiệp vụ giúp cho các giai đoạn sau thực hiện được chính xác, giảm được số lượng lỗi và sản phẩm hoàn thành đúng tiến độ theo kế hoạch

- Bug phát sinh ở giai đoạn release là nghiêm trọng và tốn kém nhất Không chỉ bị ảnh hưởng về mặt uy tín chất lượng sản phẩm, mà còn dẫn đến việc phải coding và testing lại, phát sinh chi phí về nhân lực dự án, chậm trễ tiến độ

- Bug được phát hiện càng muộn thì chi phí sửa càng lớn Đôi khi không chỉ tỷ lệ với thời gian mà có thể là tỷ lệ bình phương thời gian

Câu 2: Trình bày về ca kiểm thử và kịch bản kiểm thử? Lấy ví dụ minh họa

• Ca kiểm thử: Là một tình huống kiểm tra, được thiết kế để kiểm tra một đối tượng có thỏa mãn yêu cầu đặt ra hay không

- Một TC mô tả dữ liệu đầu vào, hành động và kết quả mong đợi, để xác định một chức năng của ứng dụng phần mềm hoạt động đúng hay không

- Mô tả TC chi tiết hay ngắn gọn phụ thuộc vào quy mô của dự án hay quy mô của công ty sản xuất phần mềm

o Cung cấp cái nhìn tổng thể cho các tester, nhà ptích, nhà phát triển, khách hàng o Tạo đề xuất về tổ chức hoặc nguồn nhân lực

o Các Tester sẽ dựa trên Test Scenario để xây dựng các Test Case/Test script Ví dụ: Danh sách kiểm thử tính khả dụng cho một ứng dụng web

- Nội dung chính xác, không có bất kỳ lỗi chính tả hoặc ngữ pháp nào - Tất cả font chữ phải giống nhau, theo đúng đặc tả

- Tất cả các văn bản phải được căn chỉnh đúng

- Phải có khoảng trống hợp lý giữa các nhãn trường, cột, hàng và thông báo lỗi - Kiểm tra các liên kết và các hình ảnh

Câu 3: Lỗi thường xuất hiện ở giai đoạn nào là chủ yếu trong chu kỳ phát triển phần mềm?

Lỗi phần mềm xuất hiện ở tất cả các công đoạn nhưng ở phần đặc tả là xuất hiện nhiều nhất (chiếm 70%) Thường là định nghĩa các yêu cầu bị lỗi, lỗi trong giao tiếp giữa khách hàng và nhà phát triển, đặc tả không được viết ra, không đủ cẩn thận, đã thay đổi hoặc do chưa phối hợp tốt trong nhóm

Câu 4: So sánh kiểm thử mức đơn vị và kiểm thử tích hợp? Lấy ví dụ minh họa

Đây là giai đoạn thử nghiệm ban đầu trong vòng đời phát triển phần mềm

Được thực hiện sau khi kiểm thử đơn vị và trước khi kiểm thử hệ thống

Đoạn code nhỏ nhất sẽ được thử nghiệm Các module khác nhau được kết hợp hoặc tích hợp để kiểm tra xem chúng có hoạt động cùng nhau hay không

Tập trung vào kiểm tra chức năng của từng đơn vị riêng lẻ

Tập trung vào việc xác định các lỗi phát sinh bằng cách tích hợp các module khác nhau

Là một loại kiểm thử hộp trắng Là một loại kiểm thử hộp đen Được thực hiện bởi các developer hoặc bởi

- Test số nguyên dương: kiểm tra hàm tính tổng của 2 và 3, kết quả phải là 5 - Test số âm và số dương: Kiểm tra hàm với -1 và 1 kết quả phải là 0

- Test số thập phân: kiểm tra hàm với 0.1 và 0.2, kết quả bằng 0.3

Ví dụ về Test case trong kiểm thử tích hợp Cho ứng dụng có ba module: Đăng nhập, Hộp thư và Xoá Email

1 Kiểm thử liên kết giao diện giữa module Đăng nhập và module Hộp thư

Nhập thông tin đăng nhập và click vào nút Đăng nhập

Được chuyển đến hộp thư

2 Kiểm thử liên kết giao diện giữa module Hộp thư và module Xoá thư

Từ Hộp thư chọn email và click vào nút xoá

Email đã xoá sẽ xuất hiện trong thư mục Đã xoá hoặc Thùng rác

Câu 5: Phân biệt kiểm thử hộp đen, kiểm thử hộp trắng Lấy ví dụ minh họa

- Tập trung vào các yêu cầu cn của pm - KTV xem phần mềm như là một hộp đen:

Không quan tâm đến cấu trúc và hành vi bên trong phần mềm Chỉ quan tâm đến các “hoạt động bề ngoài” của phần mềm - Mức áp dụng: kiểm tra hệ thống, kiểm tra

chấp nhận

- KTCN không cần biết về lập trình, cố gắng tìm ra các LỖI sau:

- Chức năng THIẾU hoặc KHÔNG ĐÚNG - Lỗi giao diện

- Lỗi cấu trúc dữ liệu

- Lỗi truy cập CSDL bên ngoài - Lỗi thi hành

- Lỗi khởi tạo/kết thúc

- Kiểm tra hộp đen được bắt đầu dựa trên tài liệu yêu cầu kỹ thuật

- Dựa trên việc phân tích mã chương trình hoặc của một mô hình của mã chương trình để xây dựng các phép thử theo các tiêu chuẩn bao phủ Kiểm thử cấu trúc bên trong của phần mềm, với mục đích kiểm tra tất cả các câu lệnh và điều kiện tồn tại trong phần mềm đó

các tài liệu thiết kế chi tiết VD: Chức năng đnhập dựa trên username

và password, ta chỉ quan tâm đến việc cn đnhập có hoạt động đúng đắn hay không, không cần biết cách nó được lập trình

VD: Khi kiểm thử hàm Đăng nhập, ta phải kiểm tra tất cả các trường hợp tiêu biểu và biên của hàm để đảm bảo rằng tất cả các đoạn mã đã được thực thi đúng đắn

Câu 6: So sánh kiểm thử hệ thống và kiểm thử chấp nhận Lấy ví dụ minh họa

đnhập, thanh toán, q/lý sp Kiểm thử hệ thống sẽ k/tra các cn này hoạt động chính xác và mượt mà khi kết hợp lại với nhau

VD: Người dùng sẽ kiểm tra các tính năng và cn của hệ thống để xác nhận rằng nó đáp ứng nhu cầu và mong đợi của họ trước khi hệ thống được triển khai hoặc phát hành

Câu 7: Lấy ví dụ về việc xây dựng kế hoạch kiểm thử cho tổng thể? VD: Kiểm thử website:

Bước 2: Xây dựng chiến lược kiểm thử:

- Phạm vi kiểm thử: Trong phạm vi (kiểm thử chức năng, kiểm thử API), ngoài phạm vi (kiểm thử CSDL, phần cứng và bất kỳ giao diện bên ngoài nào khác)

- Loại kiểm thử: Kiểm thử API (kiểm thử các giao diện lập trình ứng dụng), kiểm thử tích hợp, kiểm thử hệ thống

- Tài liệu rủi ro và các vấn đề khác:

o Rủi ro: (1) Thành viên trong nhóm thiếu các kỹ năng cần thiết để kiểm thử website, (2) lịch trình dự án quá chặt, khó để hoàn thành công việc, (3) Test manager có kỹ năng quản lý kém, (4) ước lượng ngân sách sai và vượt chi phí o Giải pháp: (1) Lập khoá đào tạo, (2) Đặt mức độ ưu tiên cho từng hdong kiểm

thử, (3) lập kế hoạch đào tạo l/đạo cho các q/lý, (4) Thiết lập phạm vi trước khi bdau dự án, chú ý nhiều đến việc lập kết hoạch dự án và l/tục theo dõi tiến độ - Lựa chọn Tester: Ai sẽ kiểm thử và khi nào kiểm thử? Dựa trên kỹ năng của từng

Bước 6: Lịch trình và ước lượng: Ví dụ như Tester có nhiệm vụ thực hiện tạo kiểm thử và báo cáo kiểm thử, ước lượng hoàn thành trong khoảng thời gian 80 giờ và 10 giờ

Bước 7: Bàn giao sản phẩm kiểm thử: Bàn giao website cho khách hàng

Câu 8: Phân biệt giữa kiểm thử bởi nhóm kiểm thử độc lập và kiểm thử bởi lập trình viên

Lấy ví dụ minh họa

Người thực hiện

Nhóm kiểm thử chuyên nghiệp hoặc nhóm kiểm thử độc lập không liên quan trực tiếp đến việc phát triển sản phẩm

Lập trình viên đang phát triển sp

Mục tiêu

Tập trung vào việc kiểm tra và đánh giá tính năng, hiệu suất, bảo mật và các tiêu chí khác một cách toàn diện

Tập trung vào việc kiểm tra các phần tử cụ thể, hàm, phương thức hoặc module mà họ đã viết

Phạm vi

Kiểm thử từ góc độ người dùng cuối, tìm kiếm các lỗi và vấn đề tiềm ẩn mà nhóm phát triển có thể bỏ sót

Kiểm thử từ góc độ kỹ thuật, tập trung vào việc xác nhận rằng mà nguồn được viết hoạt động theo t/kế và y/cầu

Ví dụ Phát triển một app di động để mua sắm trực tuyến thì nhóm có thể tập trung vào việc kiểm tra các tính năng như đăng nhập, thêm sp vào giỏ hàng, thanh toán và bảo mật Kiểm tra xem hiệu suất app khi có nhiều ng dùng truy cập cùng lúc

Lập trình viên đang viết mã cho cn đăng nhập trong app Sau khi hoàn thành, họ sẽ thực hiện kiểm thử bằng cách nhập các thông tin đ/nhập (user, pass) và xác nhận xem cn này h/động có đúng như mong đợi hay không Họ cũng có thể tạo các TH kiểm thử để xác minh tính bảo mật và xử lý các TH ngoại lệ

Câu 9: Kiểm thử phần mềm nhúng có gì khác so với kiểm thử phần mềm thông thường?

Lấy ví dụ minh họa

- Môi trường hoạt động: Sản phẩm phần mềm nhúng thường được tích hợp vào phần cứng và hoạt động trong môi trường nhúng, chẳng hạn như thiết bị điện tử, máy móc, hoặc thiết bị y tế

- Tính hệ thống: Kiểm thử không chỉ tập trung vào phần mềm mà còn phải xem xét sự tương tác giữa phần mềm và phần cứng

- Thách thức về nguồn lực: Các thiết bị nhúng thường có nguồn lực hạn chế về CPU, bộ nhớ và năng lượng, điều này yêu cầu phải tối ưu hóa và kiểm tra hiệu suất một cách cẩn thận

Ví dụ minh họa: Giả sử bạn đang phát triển phần mềm cho một thiết bị nhúng để điều khiển một hệ thống tưới cây thông minh Bạn cần kiểm tra tính năng điều khiển của thiết bị, đồng thời cũng phải kiểm tra tính năng kết nối không dây và tiết kiệm năng lượng

Câu 10: Trình bày phương pháp kiểm thử nhúng trên máy chủ bằng giàn giáo kiểm thử

Giàn giáo kiểm thử là 1 chương trình hay cụm chương trình phần mềm được xây dựng theo khung chức năng đảm bảo môi trường hoạt động như thực tế để tạo ra những tín hiệu, sự kiện, ngắt tác động vào chương trình nhúng kiểm thử

Test Scanffold tương tác đc với các thiết bị ngoại vi: màn hình, bàn phím, đĩa, mạng, giúp chúng ta kiểm thử và gỡ lỗi để có thể xây dựng phần mềm hoàn chỉnh hơn

- Mã giàn giáo kiểm thử lấy các lệnh từ bàn phím hoặc từ tệp và sản sinh ra kết quả được hiện trên màn hình hoặc ghi vào tệp lưu vết (log file) trên đĩa

Mã giàn giáo ở đây thay cho thiết bị phần cứng và mã phụ thuộc phần cứng của hệ thống đích

Vấn đề đặt ra trong kiểm thử nhúng đó là việc gọi các chương trình ngắt được chương trình nhúng thực hiện Môi trường đích cần thực thi chương trình ngắt tương ứng và phản hồi lại kết quả cho chương trình nhúng Do đó, trong giàn giáo kiểm thử chúng ta cần chia chương trình ngắt thành hai phần: liên quan đến xử lý và tương tác với phần cứng, liên quan đến tương tác với phần còn lại của hệ thống

Câu 12: Các loại kiểm thử trong kiểm thử hộp trắng hay được thực hiện trong kiểm thử

nhúng?

- Kiểm thử đơn vị: cần viết các stubs để tạo môi trường như thật cho kiểm thử từng đơn vị, có thể tích hợp vào giàn giáo kiểm thử

- Kiểm thử hồi quy: áp dụng như kiểm thử phần mềm thông thường

- Kiểm thử chức năng: nên được thiết kế sớm, ngay khi xây dựng đặc tả yêu cầu - Kiểm thử độ bao phủ: được thực hiện khi việc lập trình đã xong hoặc về cơ bản đã

hoàn tất Thường thì kiểm thử độ bao phủ được tiến hành sau kiểm thử chức năng nhưng ở mức kiểm thử tích hợp thì hai loại kiểm thử này nên kết hợp với nhau

Câu 11: Trình bày phương pháp kiểm thử nhúng bằng bộ mô phỏng tập lệnh

- Bộ mô phỏng tập lệnh là công cụ phần mềm chạy trên máy chủ và mô phỏng những hành vi của bộ vi xử lý, bộ nhớ và những thiết bị được gắn theo CPU của máy đích - Đầu vào của bộ mô phỏng là chương trình đích dạng hợp ngữ hoặc ngôn ngữ máy

đích

- Bộ mô phỏng thực hiện chương trình máy đích đúng như máy đích có thật để chúng ta có thể quan sát và đánh giá chương trình nhúng Qua mô phỏng chúng ta có thể quan sát thực hiện chương trình đích và thiết lập các điểm kiểm tra (checkpoints); khảo sát dữ liệu biến đổi thế nào trong bộ nhớ, trên thanh ghi; giám sát từng bước thực thi từng lệnh trong mã máy đích

Các tính năng của bộ mô phỏng tập lệnh:

- Xác định thời gian hồi đáp và khả năng thông dòng của phần mềm nhúng: bộ mô phỏng cho biết thời gian thực hiện chương trình nhúng là bao nhiêu chu trình đồng hồ, từ đó ta biết được thời gian hồi đáp khi nhân số chu trình đồng hồ với tần số đồng hồ của CPU máy đích

- Kiểm thử mã hợp ngữ: đầu vào là chương trình sinh chương trình dịch chéo sinh ra ở dạng mã hợp ngữ máy đích Sử dụng bộ mô phỏng chúng ta có thể kiểm thử các đoạn chương trình ngắn viết trên hợp ngữ nhằm đảm bảo tốc độ hồi đáp và tối ưu khi viết trên C/C++

- Giải quyết những vấn đề khả chuyển: Việc thực hiện thành công chương trình nhúng trên bộ mô phỏng sẽ giúp cho việc chuyển sang máy đích thật thuận lợi và tiết kiệm được nhiều thời gian phát triển và gỡ lỗi trên máy đích thật

- Kiểm thử mã xử lý tương tác với các thiết bị ngoại vi kèm theo trong bộ vi xử lý: Phần lớn các bộ mô phỏng cũng thực hiện mô phỏng các thiết bị được kèm theo CPU của máy đích như ROM, RAM

Các vấn đề không được giải quyết bởi bộ mô phỏng:

- Lỗi chia sẻ dữ liệu: CPU chỉ thực hiện những gì mà các câu lệnh chỉ thị cho nó, còn nd dữ liệu và tính đúng đắn của dữ liệu thì do người lập trình phải tự đánh giá - Các thiết bị phần cứng khác: Bộ mô phỏng chỉ thực hiện mô phỏng CPU và những

thiết bị được gắn theo như RAM, ROM, bộ đếm thời gian, vv… Còn các thiết bị khác như thiết bị cảm biến, mạch chuyên dụng, vv… thì bộ mô phỏng chưa thể giúp chúng ta mô phỏng tương tác với CPU

- Chú ý: Bộ mô phỏng chú yếu dùng để đánh giá (tính năng, khả năng hồi đáp, …) và hỗ trợ gỡ lỗi Giàn giáo kiểm thử dùng để gỡ lỗi và kiểm thử

Câu 13: Các loại kiểm thử trong kiểm thử hộp đen hay được thực hiện trong kiểm thử

nhúng?

- Kiểm thử độ căng (stress test): kiểm thử sức chịu đựng của phần mềm nhúng với các giá trị vượt ngưỡng quá cao hoặc quá thấp, khả năng chịu đựng của các bộ đệm của bộ nhớ và các kênh vào/ra, sức tải của mô-đun truyền thông, vv…

- Kiểm thử giá trị biên: với các trường dữ liệu có miền xác định thì cần kiểm thử với chính giá trị gần biên, đúng biên và ngoài biên xem hệ thống nhúng có phản ứng và xử lý như thiết kế không

- Kiểm thử ngoại lệ: kiểm thử xem hệ thống nhúng có kích hoạt thông báo hay hỏng hóc hay phải xử lý ngoại leejhay không

- Kiểm thử đoán lỗi: Kiểm thử dựa trên kinh nghiệm của kiểm thử viên hoặc dựa trên các kiểm thử phần mềm tương tự

- Kiểm thử ngẫu nhiên: kiểm thử dạng này dù ít hiệu quả nhưng có ý nghĩa khi kiểm tra độ mạnh của hệ nhúng cũng như kiểm tra hiệu quả của giao diện người dùng - Kiểm thử tính năng, hiệu năng: Kiểm thử để đánh giá xem tính năng, hiệu năng có

nằm trong khoảng thời gian cho phép không, nhất là khả năng hồi đáp và đảm bảo tính thời gian thực

Câu 14: Trong quá trình kiểm thử, tester tìm thấy bug và báo cho developer nhưng

developer không đồng ý đó là bug Tester nên làm gì tiếp theo?

- Cung cấp thông tin chi tiết: Tester cung cấp thông tin chi tiết và minh họa rõ ràng về vấn đề mà họ đã phát hiện, bao gồm các bước để tái tạo lỗi và tác động của lỗi đó đối với hệ thống

- Bàn bạc trực tiếp: Thực hiện cuộc họp hoặc trao đổi trực tiếp giữa tester và developer để trao đổi, hiểu rõ hơn về quan điểm và tìm ra giải pháp

- Kiểm tra và xác nhận lại: Tester và developer cùng kiểm tra và xác nhận lại vấn đề một cách kỹ lưỡng Có thể yêu cầu một người thứ ba, như Business Analyst, tham gia để có quan điểm trung lập

- Tạo ticket hoặc report: Nếu vấn đề vẫn chưa được giải quyết, tester có thể tạo một ticket hoặc report chi tiết để ghi lại vấn đề và đưa ra lập luận hỗ trợ cho quan điểm của mình

- Chấp nhận và chuyển tiếp: Nếu vấn đề vẫn không được giải quyết, tester cần chấp nhận quan điểm của developer và tiếp tục kiểm thử theo hướng dẫn hoặc yêu cầu mới từ developer

Trong mọi trường hợp, sự hợp tác và trao đổi thông tin một cách rõ ràng và xây dựng là chìa khóa để giải quyết mọi tranh chấp giữa tester và developer và đảm bảo chất lượng của sản phẩm phần mềm

Câu 15: Một báo cáo công việc kiểm thử (test report) gồm những gì? Và ích lợi của bảng

báo cáo này?

Báo cáo công việc kiểm thử (test report) thường bao gồm những thông tin sau: - Thông tin cơ bản: Tên dự án, ngày thực hiện kiểm thử, tên người kiểm thử

- Phạm vi kiểm thử: Mô tả các phần tử đã kiểm thử (chức năng, module, tính năng) - Kết quả kiểm thử: Số lượng test case đã thực hiện, số lượng bug được phát hiện, các

bug đã được fix và chưa fix

- Bảng tổng kết: Tình trạng tổng quát của kiểm thử, tỷ lệ bug đã fix và bug chưa fix - Ghi chú: Các vấn đề, khó khăn và nhận xét từ quá trình kiểm thử

Ích lợi của báo cáo kiểm thử:

- Xác định chất lượng: Đánh giá chất lượng của sản phẩm phần mềm dựa trên số lượng và tính năng của các bug

- Điều chỉnh chiến lược: Giúp quản lý và team định hướng lại chiến lược và nguồn lực kiểm thử

- Báo cáo cho các bên liên quan: Cung cấp thông tin cho các stakeholder để họ có cái nhìn tổng quan về tiến trình và chất lượng sản phẩm

- Dự đoán và ưu tiên: Hỗ trợ việc ưu tiên và xác định những phần cần kiểm thử mạnh mẽ hơn trong các lần kiểm thử tiếp theo

Báo cáo kiểm thử là công cụ hữu ích để đảm bảo rằng việc kiểm thử được thực hiện đúng, đầy đủ và chất lượng, đồng thời cung cấp thông tin quan trọng cho việc ra quyết định và điều chỉnh trong dự án

Câu 16: Kiểm thử tự động là gì? Ưu nhược điểm của kiểm thử tự động?

Kiểm thử tự động hay còn gọi là Automation testing là một quá trình thực hiện một cách tự động các bước trong một kịch bản kiểm thử

Ưu điểm: Độ tin cậy cao: có tính ổn định cao

- Khả năng lặp: có thể kiểm tra các ca kiểm thử lặp lại nhiều lần

- Khả năng tái sử dụng: một bộ kiểm thử tự động, có thể sử dụng nhiều phiên bản ứng dụng khác nhau

- Thời gian kiểm thử nhanh

- Chi phí thấp: tiết kiệm thời gian và nguồn nhân lực Nhược điểm:

- Khó mở rộng, khó bảo trì: để cập nhật, chỉnh sửa một ca kiểm thử, yêu cầu rất nhiều công việc như gỡ rối, thay đổi dữ liệu đầu vào, cập nhật mã nguồn…

- Khả năng về bao phủ thấp vì khó ứng dụng, đòi hỏi nhiều kĩ năng lập trình

- Công cụ và nhân lực: cần trả phí công cụ, đôi khi cần công cụ kiểm thử đặc thù nên khó đầu tư phát triển, nguồn nhân lực đạt yêu cầu cũng bị hạn chế