Kiển thử Test Complete

TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP HÀ NỘI
KHOA CÔNG NGHỆ THÔNG TIN
======***======

BÁO CÁO BTL HỌC PHẦN:
KIỂM THỬ PHẦN MỀM

ĐỀ TÀI: NGHIÊN CỨU CƠNG CỤ KIỂM THỬ TEST
COMPLETE VÀ ỨNG DỤNG
GVHD:
Nhóm:
Thành viên:

Hà Nội, Năm 2022

MỤC LỤC


2


LỜI NÓI ĐẦU
Hiện nay, sự phát triển mạnh mẽ cũng như bước chuyển mình nhanh chóng
của các xu thế cơng nghệ thông tin trên thế giới đã mang lại cho Việt Nam đồng
thời thuận lợi và khó khăn. Do đó, những dự án, chương trình quốc gia nhằm thúc
đẩy hiệu quả ứng dụng CNTT trong mọi mặt đời sống kinh tế - chính trị - xã hội
đang ngày càng được chú trọng và gấp rút triển khai. Kéo theo đó là nhu cầu về
lĩnh vực kiểm thử phần mềm, đặc biệt là kiểm thử phần mềm tự động. Tại Việt
Nam, khái niệm này tuy không mới mẻ song cũng chưa hoàn toàn quen thuộc.
Thực tế cho thấy, số lượng đơn vị đào tạo chuyên sâu, các tester chuyên nghiệp về
kiểm thử phần mềm không nhiều, chưa thể đáp ứng đủ cho các dự án doanh

nghiệp. Nếu xét theo tiêu chuẩn quốc tế, tỷ lệ giữa lập trình viên và tester là 3:1 (cứ
3 lập trình viên thì có 1 tester), đôi khi tỉ lệ này là 1:1 với những dự án đặc thù; thì
tại Việt Nam, tỉ lệ đáp ứng được công việc tester chỉ rơi vào khoảng 1.5. Dù biết
công tác kiểm thử, đảm bảo chất lượng giữ vai trị quan trọng trong việc mang lại
thành cơng của các dự án phần mềm song không phải công ty nào cũng có đủ
chun mơn và điều kiện cho phép để thực hiện quy trình này. Tuy nhiên, với
những lợi thế cạnh tranh như: nguồn nhân lực rẻ có sẵn trình độ kỹ thuật; đầu tư
phát triển cơ sở hạ tầng nhanh; mơi trường đầu tư an tồn; chất lượng dịch vụ nổi
trội và tỉ lệ thay đổi nhân sự thấp… Việt Nam có thể hi vọng và tin tưởng vào khả
năng trở thành đối tác kinh doanh đầy tiềm năng và hấp dẫn trong ngành kiểm thử
phần mềm.
Sau quá trình tìm hiểu nhóm 15 chúng em quyết định lựa chọn đề tài:
“Nghiên cứu công cụ kiểm thử Test Complete và ứng dụng” để làm báo cáo kết
thúc môn học. Rất mong nhận được ý kiến nhận xét, đóng góp của thầy và các bạn
để báo cáo của nhóm được hồn thiện hơn.
Chúng em xin chân thành cảm ơn thầy giáo đã hỗ trợ chúng em vơ cùng tận
tình để chúng em có thể hồn thành đề tài của mình. Chúc thầy thật nhiều sức khỏe
và ngày một thành công trên con đường giảng dạy của mình.

3


CHƯƠNG 1
TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM
1.1. Lý thuyết về kiểm thử phần mềm
1.1.1. Kiểm thử phần mềm là gì?
Kiểm thử phần mềm là quy trình được sử dụng để đánh giá, kiểm tra chất
lượng phần mềm ở nhiều khía cạnh khác nhau dựa trên các yêu cầu của người sử
dụng đối với sản phẩm phần mềm, nhằm đảm bảo phần mềm hoạt động tốt trong
các môi trường, trường hợp khác nhau.

Kiểm thử phần mềm là một cuộc kiểm tra được tiến hành để cung cấp cho
các bên liên quan thông tin về chất lượng của sản phẩm hoặc dịch vụ được kiểm
thử. Kiểm thử có thể cung cấp cho doanh nghiệp một quan điểm, một cách nhìn
độc lập về phần mềm để từ đó cho phép đánh giá và thấu hiểu được những rủi ro
trong quá trình triển khai phần mềm.
Trong kỹ thuật kiểm thử không chỉ giới hạn ở việc thực hiện một chương
trình hoặc ứng dụng với mục đích đi tìm các lỗi phần mềm (bao gồm các lỗi và các
thiếu sót) mà cịn là một quá trình phê chuẩn và xác minh một chương trình máy
tính / ứng dụng / sản phẩm nhằm:
- Đáp ứng được mọi yêu cầu hướng dẫn khi thiết kế và phát triển phần mềm.
- Thực hiện công việc đúng như kỳ vọng.
- Có thể triển khai được với những đặc tính tương tự.
- Và đáp ứng được mọi nhu cầu của các bên liên quan.
Tùy thuộc vào từng phương pháp, việc kiểm thử có thể được thực hiện bất
cứ lúc nào trong quá trình phát triển phần mềm. Theo truyền thống thì các nỗ lực
kiểm thử được tiến hành sau khi các yêu cầu được xác định và việc lập trình được
hồn tất nhưng trong Agile (là một tập hợp các phương pháp phát triển phần mềm
linh hoạt dựa trên việc lặp đi lặp lại và gia tăng giá trị) thì việc kiểm thử được tiến
hành liên tục trong suốt quá trình xây dựng phần mềm.
Như vậy, mỗi một phương pháp kiểm thử bị chi phối theo một quy trình phát
triển phần mềm nhất định.
1.1.2. Các mục tiêu chính của kiểm thử phần mềm
- Phát hiện càng nhiều lỗi càng tốt trong thời gian kiểm thử xác định trước
- Chứng minh rằng sản phẩm phần mềm phù hợp với các đặc tả yêu cầu
của nó.
4


- Xác thực chất lượng kiểm thử phần mềm đã dùng chi phí và nỗ lực tối
thiểu

- Tạo các testcase chất lượng cao, thực hiện kiểm thử hiệu quả và tạo ra các
báo cáo vấn đề đúng và hữu dụng.
1.1.3. Phân loại kiểm thử phần mềm
Ta phân loại kiểm thử dựa vào yếu tố: Chiến lược kiểm thử, phương pháp
kiểm thử và kỹ thuật kiểm thử.
- Dựa vào chiến lược kiểm thử ta có thể phân chia kiểm thử thành 2 loại:
kiểm thử thủ công và kiểm thử tự động
- Theo phương pháp tiến hành kiểm thử ta chia kiểm thử thành 2 loại:
+ Kiểm thử tĩnh: Là loại kiểm tra trong đó code khơng được thực hiện. Nó
có thể được thực hiện bằng tay hoặc bằng một bộ công cụ. Loại kiểm tra
này thực hiện kiểm tra code, tài liệu yêu cầu và tài liệu thiết kế và đưa ra
nhận xét, lưu nhận xét vào tài liệu công việc. Khi phần mềm khơng thực
thi và khơng làm gì, chúng ta thực hiện kiểm tra trạng thái an toàn để
phân tích phần mềm trong mơi trường khơng chạy.
+ Kiểm thử động: Được thực hiện khi code đang ở chế độ thực thi. Thử
nghiệm động được thực hiện trong môi trường thực thi chạy chương trình
ứng dụng. Khi code được thực thi, thì đầu vào được truyền một giá trị,
kết quả hoặc đầu ra của việc thực hiện được so sánh với kết quả dự kiến
ban đầu đã đưa ra. Với việc này chúng ta có thể quan sát được các hành
vi chức năng của phần mềm, giám sát hệ thống bộ nhớ, thời gian phản
hồi của CPU, hiệu suất của hệ thống.được thực hiện khi code đang ở chế
độ thực thi. Thử nghiệm động được thực hiện trong môi trường thực thi
chạy chương trình ứng dụng. Khi code được thực thi, thì đầu vào được
truyền một giá trị, kết quả hoặc đầu ra của việc thực hiện được so sánh
với kết quả dự kiến ban đầu đã đưa ra. Với việc này chúng ta có thể quan
sát được các hành vi chức năng của phần mềm, giám sát hệ thống bộ nhớ,
thời gian phản hồi của CPU, hiệu suất của hệ thống.
- Dựa vào kỹ thuật kiểm thử ta có thể phân chia kiểm thử thành 3 loại:
+ Kiểm thử hộp đen
+ Kiểm thử hộp trắng

+ Kiểm thử hộp xám.

5


1.1.4 Các cấp độ kiểm thử phần mềm
Kiểm thử phần mềm không đơn giản như nhiều người thường nghĩ, công
việc này có nhiều mức độ khác nhau và có mối tương quan với các chặng phát
triển trong dự án phát triển phần mềm. Trong một dự án kiểm thử phần mềm bao
gồm 4 mức độ cơ bản: Kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống và
kiểm thử chấp nhận.

Hình 1. SEQ Hình_1. \* ARABIC 1 Bốn cấp độ cơ bản của kiểm

- Kiểm thử đơn vị (Unit Testing): kiểm thử sự hiện thực chi tiết của từng đơn
vị nhỏ (hàm, class, ...) có hoạt động đúng không?
- Kiểm thử module (Module Testing): kiểm thử các dịch vụ của module có
phù hợp với đặc tả của module đó khơng?
- Kiểm thử tích hợp (Integration Testing): kiểm thử xem từng phân hệ của
phần mềm có đảm bảo với đặc tả thiết kế của phân hệ đó khơng?
- Kiểm thử hệ thống (System Testing): kiểm thử các yêu cầu không chức năng
của phần mềm như hiệu suất, bảo mật, làm việc trong môi trường căng
thẳng, ...
- Kiểm thử độ chấp nhận của người dùng (AcceptanceTesting): kiểm tra xem
người dùng có chấp thuận sử dụng phần mềm khơng?
- Kiểm thử hồi quy: được làm mỗi khi có sự hiệu chỉnh, nâng cấp phần mềm
với mục đích xem phần mềm mới có đảm bảo thực hiện đúng các chức
năng trước khi hiệu chỉnh không?

6

1.1.5. Test case
Mỗi testcase chứa các thông tin cần thiết để kiểm thử thành phần phần mềm
theo 1 mục tiêu xác định. Testcase gồm bộ 3 thông tin {tập dữ liệu đầu vào, trạng
thái của thành phần phầm mềm, tập kết quả kỳ vọng}
- Tập dữ liệu đầu vào (Input): gồm các giá trị dữ liệu cần thiết để thành phần
phầm mềm dùng và xử lý.
- Tập kết quả kỳ vọng: kết quả mong muốn sau khi thành phần phần mềm xử
lý dữ liệu nhập.
- Trạng thái thành phần phần mềm: được tạo ra bởi các giá trị prefix và
postfix.
Tập các testcase: tập hợp các testcase mà ta có ý định dùng để kiểm thử
thành
phần phần mềm để minh chứng rằng TPPM có đúng các hành vi mong muốn.
Các phương pháp thiết kế test case
- Kiểm thử hộp đen (Black box testing): theo góc nhìn sử dụng
+ Khơng cần kiến thức về chi tiết thiết kế và hiện thực bên trong.
+ Kiểm thử dựa trên các yêu cầu và đặc tả sử dụng thành phần phần
mềm.
- Kiểm thử hộp trắng (White box testing): theo góc nhìn hiện thực
+ Cần kiến thức về chi tiết thiết kế và hiện thực bêntrong.
+ Kiểm thử dựa vào phủ các lệnh, phủ các nhánh, phủ các điều kiện con.

Kiểu kiểm thử
Kỹ thuật kiểm thử được dùng
Hình
1.
SEQ
Hình_1.

\*
ARABIC
2 Sơđen
đồ use case
Unit testing
Hộp
trắng, hộp
Integration testing
Hộp đen, hộp trắng
Functional testing
Hộp đen
System testing
Hộp đen
7


Acceptance testing
Hộp đen
1.1.6. Các nguyên tắc cơ bản về kiểm thử
Thông tin thiết yếu của mỗi testcase là kết quả hay dữ liệu xuất kỳ vọng.
Nếu kết quả kỳ vọng của testcase không được định nghĩa rõ ràng, người ta sẽ
giải thích kết quả sai (plausible) thành kết quả đúng bởi vì hiện tượng “the eyes
seeing what it wants to see.”
=> 1 test case phải chứa 2 thành phần thiết yếu:
- Đặc tả về điều kiện dữ liệu nhập.
- Đặc tả chính xác về kết quả đúng của chương trình tương ứng với dữ
liệu nhập.
Việc kiểm thử địi hỏi tính độc lập: lập trình viên nên tránh việc kiểm thử các
TPPM do mình viết.
Các issues tâm lý:

- Chương trình có thể chứa các lỗi do lập trình viên hiểu sai về đặc tả/phát
biểu vấn đề.
- Tổ chức lập trình khơng nên kiểm thử các chương trình của tổ chức mình
viết.
- Thanh tra 1 cách xuyên suốt các kết quả kiểm thử. Phải thiết kế đủ các
test case cho cả 2 trường hợp: dữ liệu đầu vào hợp lệ và dữ liệu đầu vào
không hợp lệ và chờ đợi. Xem xét chương trình xem nó khơng thực hiện
những điều mong muốn, xem nó có làm những điều khơng mong muốn?
Tránh các testcase "throwaway" trừ phi chương trình thật sự là "throwaway".
Khơng nên lập kế hoạch nỗ lực kiểm thử dựa trên giả định ngầm rằng phần
mềm khơng có lỗi.
Xác xuất xuất hiện nhiều lỗi hơn trong 1 section phần mềm tỉ lệ thuận với số
lỗi đã phát hiện được trong section đó.
Kiểm thử là 1 tác vụ rất thách thức địi hỏi sự sáng tạo và trí tuệ.
Kiểm thử phần mềm nên bắt đầu từ các thành phần nhỏ đơn giản rồi đến các
thành phần ngày càng lớn hơn.
Kiểm thử theo kiểu vét cạn là khơng thể.
Nên hoạch định qui trình kiểm thử trước khi bắt đầu thực hiện kiểm thử.
1.1.7. Quy trình kiểm thử phần mềm
Dẫu cho các biến thể tồn tại giữa các tổ chức lập trình thì vẫn có một quy
trình điển hình để kiểm thử. Mẫu dưới đây là phổ biến trong các tổ chức sử dụng
8


mơ hình phát triển Waterfall (thác nước). Các hoạt động tương tự thường được tìm
thấy trong các mơ hình phát triển khác, nhưng có thể có hoặc khơng rõ ràng.
Quy trình kiểm thử phần mềm:
- Phân tích u cầu: Kiểm thử thường sẽ bắt đầu lấy các yêu cầu trong các
giai đoạn của vòng đời phát triển phần mềm. Trong giai đoạn thiết kế, các
Tester làm việc với các nhà phát triển để xác định những khía cạnh của một

thiết kế được kiểm chứng và những thông số được kiểm tra.
- Lập kế hoạch kiểm thử: Chiến lược kiểm thử, kế hoạch kiểm thử, kiểm thử
sáng tạo… Và có một kế hoạch là cần thiết vì nhiều hoạt động sẽ được
thực hiện trong thời gian kiểm thử.
- Kiểm thử phát triển: Các quy trình kiểm thử, các kịch bản, Test Case, các
dữ liệu được sử dụng trong kiểm thử phần mềm.
- Kiểm thử thực hiện: Dựa trên các kế hoạch, các văn bản kiểm thử và các
báo cáo bất kỳ lỗi nào tìm thấy cho nhóm phát triển.
- Kiểm thử báo cáo: Sau khi hoàn tất kiểm thử, các Tester tạo ra các số liệu
và báo cáo cuối cùng về nỗ lực kiểm thử của họ và có sẵn sàng phát hành
phần mềm hay khơng.
- Phân tích kết quả kiểm thử hoặc phân tích thiếu sót được thực hiện bởi đội
ngũ phát triển kết hợp với khách hàng để đưa ra quyết định xem những
thiếu sót gì cần phải được chuyển giao, cố định và từ bỏ (tức là tìm ra được
phần mềm hoạt động chính xác) hoặc giải quyết sau.
- Test lại khiếm khuyết: Khi một khiếm khuyết đã được xử lý bởi đội ngũ
phát triển, nó phải được kiểm tra lại bởi nhóm kiểm thử.
- Kiểm thử hồi quy: Người ta thường xây dựng một chương trình kiểm thử
nhỏ là tập hợp của các bài kiểm tra cho mỗi tích hợp mới, sửa chữa hoặc cố
định phần mềm, để đảm bảo rằng những cung cấp mới nhất đã khơng phá
hủy bất cứ điều gì và tồn bộ phần mềm vẫn cịn hoạt động một cách chính
xác.
- Kiểm thử đóng gói: Mỗi phép thử thỏa mãn các chỉ tiêu truy xuất và thu
được những kết quả quan trong như: bài học kinh nghiệm, kết quả, các bản
ghi, tài liệu liên quan được lưu trữ và sử dụng như một tài liệu tham khảo
cho các dự án trong tương lai.

9

•
•
•
•
•
•
•
•

1.2. Kỹ thuật kiểm thử tự động
1.2.1. Khái quát về kiểm thử phần mềm tự động
Kiểm thử phần mềm tốn nhiều chi phí nhân cơng, thời gian. Trong một số dự
án, chi phí kiểm thử phần mềm chiếm 40% tổng giá trị của dự án. Nếu cần ứng
dụng an toàn hơn, chi phí kiểm thử cịn cao hơn nữa. Do đó một trong các mục tiêu
của kiểm thử là tự động hóa nhiều, nhờ đó mà giảm thiểu chi phí, giảm lỗi, đặc biệt
giúp việc kiểm thử hồi qui dễ dàng và nhanh chóng hơn. Tự động hóa việc kiểm
thử là dùng phần mềm điều khiển việc thi hành kiểm thử, so sánh kết quả có được
với kết quả mong muốn, thiết lập các điều kiện đầu vào, các kiểm soát kiểm thử và
các chức năng báo cáo kết quả.
1.2.2. Kiểm thử tự động là gì?
Kiểm thử tự động là 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ử. Kiểm thử tự động bằng một công cụ nhằm rút ngắn thời
gian kiểm thử.
1.2.3. Tại sao phải kiểm thử tự động
Kiểm thử phần mềm tự động với mục đích:
Giảm bớt cơng sức và thời gian thực hiện quá trình kiểm thử.
Tăng độ tin cậy.
Giảm sự nhàm chán cho con người.
Rèn luyện kỹ năng lập trình cho kiểm thử viên.
Giảm chi phí cho tổng q trình kiểm thử.

Khi nào cần kiểm thử tự động:
Không đủ tài nguyên: khi số lượng tài nguyên quá nhiều mà kiểm thử viên khơng
thể hồn tất trong thời gian cụ thể.
Kiểm tra hồi quy: nâng cấp phần mềm, kiểm tra lại các tính năng đã chạy tốt và
những tính năng đã sửa -> khó đảm bảo về mặt thời gian.
Kiểm tra khả năng vận hành phần mềm trong môi trường đặc biệt:
- Đo tốc độ trung bình xử lí một u cầu của web server.
- Xác định số yêu cầu tối đa xử lý bởi web server.
- Xác định số cấu hình máy thấp nhất mà phần mềm vẫn có thể hoạt
động tốt.
1.2.4. Nguyên tắc kiểm thử tự động
Thực sự là sai lầm khi nghĩ tự động là đơn giản chụp lại, ghi lại 1 tiến trình
kiếm thử thủ cơng. Thực tế, kiểm thử tự động có những điểm khác với kiểm thử
10


thủ cơng. Nó có những lỗi và khả năng dự đốn. Vì thế, những cơ hội thành cơng
với kiểm kiêm thử tự động sẽ được cải thiện đáng kể trong trượng hợp bạn thực sự
hiểu nó.
Kiểm thử tự động tuân theo đầy đủ những nguyên tắc kiểm thử nói chung,
đó là các nguyên tắc sau:
- Nguyên tắc 1: Kiểm thử đưa ra lỗi
Kiểm thử có thể cho thấy rằng phần mềm đang có lỗi, nhưng khơng thể
chứng minh rằng phần mềm khơng có lỗi. Kiểm thử làm giảm xác suất lỗi chưa tìm
thấy vẫn cịn trong phần mềm, thậm chí là khơng cịn lỗi nào, nó khơng phải là
bằng chứng của sự chính xác.
- Nguyên tắc 2: Kiểm thử mọi thứ là không thể
Kiểm thử mọi thứ (tất cả các tổ hợp của điều kiện input đầu vào) là
không thể thực hiện được, trừ phi nó chỉ bao gồm một số trường hợp bình thường
(ít trường hợp tổ hợp thì có thể test tồn bộ được).

Thay vì kiểm thử tồn bộ, việc phân tích rủi ro và dựa trên sự mức độ ưu
tiên chúng ta có thể tập trung việc kiểm thử vào một số điểm cần thiết.
- Nguyên tắc 3: Kiểm thử sớm
Để tìm được bug sớm, các hoạt động kiểm thử nên được bắt đầu càng
sớm càng tốt trong qui trình phát triển (vịng đời phát triển) phần mềm hoặc hệ
thống, và nên tập trung vào các hoạt động đã định trước.
- Nguyên tắc 4: Sự tập trung của lỗi
Nỗ lực kiểm thử nên tập trung một cách cân đối vào mật độ lỗi dự kiến
và lỗi phát hiện ra sau đó trong các mơ-đun.
Một số ít các mô-đun thường chứa nhiều lỗi không phát hiện ra trong lúc
kiểm thử trước khi phát hành (release), hoặc chịu trách nhiệm cho hầu hết các lỗi
hoạt động của phần mềm.
- Nguyên tắc 5: Nghịch lý thuốc trừ sâu
- Nếu việc kiểm thử tương tự nhau được lặp đi lặp lại nhiều lần, thì cuối
cùng sẽ có một số trường hợp kiểm thử (ca kiểm thử - test case) sẽ không cịn tìm
thấy bất kỳ lỗi nào mới. Để khắc phục "nghịch lý thuốc trừ sâu" này, các trường
hợp kiểm thử cần phải được xem xét và sửa đổi thường xuyên, và cần phải viết các
test case mới và khác nhau để thực hiện nhiều phần khác nhau của phần mềm hoặc
hệ thống để tìm ra lỗi tiềm ẩn nhiều hơn nữa.
- Nguyên tắc này giống như việc trừ sâu trong nông nghiệp, nếu chúng ta
cứ phun một loại thuốc với nồng độ giống nhau trong một khoảng thời gian dài thì
11


có một số con sâu sẽ quen dần và cuối cùng việc phun thuốc giống như là tắm
chúng vậy (bị lờn thuốc) => lúc đó chúng ta khơng thể diệt sạch chúng được. Do
vậy, để diệt sạch sâu một cách hiệu quả, người ta thường thay đổi loại thuốc trừ
sâu, mỗi loại chỉ dùng trong khoảng thời gian ngắn.
- Nguyên tắc 6: Kiểm thử theo các ngữ cảnh độc lập
Nguyên tắc này là việc testing phụ thuộc vào ngữ cảnh, test trong nhiều

ngữ cảnh khác nhau.
- Nguyên tắc 7: Sự sai lầm về việc khơng có lỗi
Việc tìm và sửa chữa lỗi sẽ khơng giúp được gì nếu hệ thống được xây
dựng xong nhưng không thể dùng được và không đáp ứng được nhu cầu và sự
mong đợi của người dùng. (Nghĩa là nếu sau khi code, test rồi fix bug, làm đủ tất
cả các trường hợp và cuối cùng cho ra một sản phẩm không như mong đợi hoặc
không đáp ứng được nhu cầu của khách hàng thì dự án phần mềm đó coi như thất
bại mặc dù đã được test xong).
1.2.5. Quy trình kiểm thử tự động
STT
Bước 1

Bước thữ hiện
Tạo kịch bản kiểm thử

Bước 2

Chỉnh sử kịch bản

Bước 3

Chạy kịch bản kiểm thử

Bước 4

Đánh giá kết quả

Môt tả
Giai đoạn này dùng công cu kiểm
thử để ghi lại các thao tác lên phần

mềm cần kiểm tra và tự động sinh ra
kịch bản kiểm thử
Chỉnh sửa để kịch bản kiểm thử thực
hiện kiểm tra theo đúng yêu cầu đặt
ra (làm theo trường hợp kiểm thử
cần thực hiện)
Chạy kịch bản kiểm thử để kiểm tra
phần mềm có đưa ra đúng như mong
muốn không.
Đánh giá kết quả sau khi chạy kịch
bản kiểm thử

12


1.3. Kỹ thuật kiểm thủ thủ công.
1.3.1. Khái niệm kiểm thử thủ công
Kiểm thử thủ công là kiểm thử một phần mềm một cách thủ công (không sử
dụng bất kỳ công cụ tự động hoặc bất kỳ đoạn mã nào). Với loại kiểm thử này,
tester như người sử dụng cuối sẽ kiểm tra phần mềm để xác định bất kỳ hành vi
khơng mong muốn hoặc lỗi. Có rất nhiều giai đoạn để kiểm thử bằng tay như Kiểm
thử đơn vị (Unit testing), Kiểm thử tích hợp (Integration testing), Kiểm thử hệ
thống (System testing) và Kiểm thử chấp nhận (User Acceptance testing).
Bất kỳ ứng dụng mới nào cũng phải được kiểm thử thủ công trước khi thực
hiện kiểm thử tự động hóa. Kiểm thử thủ cơng địi hỏi nhiều nỗ lực hơn nhưng lại
rất cần thiết để kiểm tra tính khả thi để thực hiện tự động hóa.
Tester sử dụng kế hoạch kiểm thử (test plans), trường hợp kiểm thử (test
case), hoặc kịch bản kiểm thử (test scenarios) để đảm bảo tính đầy đủ của kiểm
thử. Kiểm thử thủ cơng cũng bao gồm kiểm thử phám phá, tester kiểm thử khám
phá phần mềm để tìm ra lỗi trong phần mềm đó.

1.3.2. Mục tiêu của kiểm thử thủ công
Khái niệm của kiểm thử thủ công là đảm bảo rằng ứng dụng hoạt động phù
hợp với các yêu cầu chức năng được chỉ định.
Kiểm thử thủ công cũng đảm bảo rằng các lỗi đã tìm thấy được sửa chữa bởi các
developer và được kiểm thử lại bởi những tester sau khi các lỗi được khắc phục.
Kiểm thử thủ công kiểm tra chất lượng của hệ thống và cung cấp sản phẩm
khơng có lỗi cho khách hàng.
1.3.3. Các loại kiểm thử thủ công
- Black Box Testing.
- White Box Testing.
- Unit Testing.
- System Testing.
- Integration Testing.
- Acceptance Testing.
1.3.4. Cách thực hiện kiểm thử thủ công
Đọc và hiểu tài liệu của dự án phần mềm. Ngoài ra, nghiên cứu Ứng dụng
khi thực hiện kiểm thử (AUT) nếu có.
Dự thảo kiểm thử bao gồm tất cả các yêu cầu được đề cập trong tài liệu.
13


Xem xét và vạch ra các trường hợp thử nghiệm với Trưởng nhóm, Khách
hàng (nếu có).
Thực hiện các trường hợp kiểm thử trên AUT.
Báo cáo lỗi.
Khi các lỗi đã được sửa sẽ được tester thực hiện một lần nữa các trường hợp
kiểm thử thất bại để xác minh rằng lỗi đã được khắc phục.
1.3.5. Điểm mạnh và điểm yếu của kiểm thử thủ công
Điểm mạnh:
- Cho phép tester thực hiện việc kiểm thử khám phá.

- Thích hợp kiểm tra sản phẩm lần đầu tiên.
- Thích hợp kiểm thử trong trường hợp các test case chỉ phải thực hiện một
số ít lần.
- Giảm được chi phí ngắn hạn.
Điểm yếu:
- Tốn thời gian.
- Đối với mỗi lần release, người kiểm thử vẫn phải thực hiện lại một tập
hợp các test case đã chạy dẫn đến sự mệt mỏi và lãng phí effort.
1.4. Một số công cụ kiểm thử tự động
1.4.1. Selenium IDE
Là công cụ giúp bạn phát triển ca kiểm thử dược xây dựng dưới dạng Add –
ons của Firefox. Đây là cách tiện lợi nhất để xây dựng các ca kiểm thử, gồm các
phần tử giao diện giúp bạn có thể lựa chọn thể hiện các thao tác, không chỉ tiết
kiệm thời gian mà con là cách thông minh để hiểu kịch bản Selenium. Bộ công cụ
này cung cấp chức năng “thu và chạy lại” – Record and Playback. Nhờ đó, Tester
có thể nhanh chóng tạo một bộ kịch bản kiểm tra (test script) bằng cách trực tiếp
“thu” các thao tác của mình trên đối tượng cần kiểm tra thành 1 tập các câu lệnh
“Selenese” (ngôn ngữ kịch bản được phát triển cho Selenium IDE và Selenium
Core có dạng bản HTML). Sau đó chạy lại các câu lệnh này để kiểm tra. Chức
năng này rất hữu dụng, cho phép tiết kiệm thời gian viết kịch bản kiểm tra.
Selenium IDE cho phép lưu kịch bản đã thu dưới nhiều loại ngôn ngữ lập trình

14


1.4.2. Selenium Remote Control
Selenium RC là framework kiểm thử hàng đầu của dự án Selenium trong một
thời gian dài. Đây là công cụ kiểm tra web tự động đầu tiên cho phép người dung
sử dụng ngơn ngữ lập trình mà họ thích. Kể từ phiên bản 2.25.0, RC có thể hỗ trợ
các ngơn ngữ lập trình sau: Java, C#, PHP, Python, Perl, Ruby

Ưu điểm
Nhược điểm
Trình duyệt chéo và nền tảng chéo Cài đặt phức tạp hơn IDE
Có thể thực hiện vịng lặp và các Phải có kiến thức lập trình
hoạt động có điều kiện

Cần máy chủ selenium RC để chạy

Có thể hỗ trợ kiểm tra theo hướng API chứa các câu lệnh dư thừa và
dữ liệu

khó hiểu

Đã phát triển và hồn thành API

Tương tác của Brower ít thực tế

Có thể hỗ trợ trình duyệt mới

hơn

Thực thi nhanh hơn IDE

Kết quả không phù hợp và sử dụng
Javascript
Thời gian thực hiện chậm hơn
webDriver.

1.4.3. Selenium Grid
Selenium Grid là một công cụ được sử dụng cùng với Selenium RC để chạy

thử nghiệm song song trên các máy khác nhau và các trình duyệt khác nhau cùng
một lúc. Thực thi song song có nghĩa là chạy nhiều thử nghiệm cùng một lúc.
Đặc điểm:
• Cho phép chạy đồng thời các thử nghiệm trong nhiều trình duyệt và mơi
trường.
• Tiết kiệm thời gian rất nhiều.
• Sử dụng khái niệm hub-and-nodes. Hub hoạt động như một nguồn trung
tâm của các lệnh Selenium cho mỗi nút được kết nối với nó.
15


16


1.4.4. Selenium webdriver
WebDriver chứng minh rằng nó tốt hơn cả Selenium IDE và Selenium RC ở
nhiều khía cạnh. Nó thực hiện một cách tiếp cận hiện đại và ổn định hơn trong việc
tự động hóa các hành động của trình duyệt. WebDriver, không giống như Selenium
RC, không dựa vào JavaScript cho tự động hóa. Nó kiểm sốt trình duyệt bằng
cách giao tiếp trực tiếp với nó. Các ngơn ngữ được hỗ trợ giống như ngôn ngữ
trong Selenium RC.
Ưu điểm
Nhược điểm
Cài đặt đơn giản hơn so với selenium Cài đặt phức tạp hơn so với selenium
RC

IDE

Giao tiếp trực tiếp với trình duyệt

Yêu cầu kiến thức lập trình

Tương tác Brower thực tế hơn

Khơng thể hỗ trợ các trình duyệt mới

Khơng cần một thành phần riêng biệt Khơng có cơ chế tích hợp để ghi nhật
như máy chủ của RC

ký thời gian chạy và tạo kết quả kiểm

Thời gian thực thi nhanh hơn IDE và tra
RC
1.4.5. Jmeter
Apache JMeter là một mã nguồn mở, phát triển dựa trên nền tảng Java thuần
(pure Java), được thiết kế để kiểm tra tải của các hành vi, chức năng và đo lường
hiệu suất của một hệ thống.
Ban đầu, JMeter được giới thiệu cho các ứng dụng web kiểm tra tải và hiệu
năng, nhưng sau đó, phạm vi của nó đã mở rộng và có thể thực hiện kiểm tra tải và
hiệu năng trên các trang web, ứng dụng web và các tài nguyên tĩnh hay động như
Database, Rest Web Services, LDAP, Java Object…
Stefano Mazzocchi của Apache Software Foundation là người phát triển ra
JMeter. Ông ban đầu đã viết nó chủ yếu để kiểm tra hiệu năng của Apache Jserv
(hiện nay được gọi là Apache Tomcat – được sử dụng phổ biến đối với server). Sau
17


đó, cộng đồng Apache đã thiết kế lại để nó cải thiệu về mặt GUI (Giao diện), thêm
nhiều tính năng cũng như có khả năng kiểm thử chức năng.
1.4.6. Katalon

Là một bộ cơng cụ tồn diện cho kiểm thử tự động hóa ứng dụng trên web và
điện thoại di động. Cơng cụ này bao gồm một gói đầy đủ các tính năng mạnh mẽ
giúp vượt qua những thách thức phổ biến trong tự động hóa thử nghiệm giao diện
web, ví dụ như pop-up, iFrame và wait-time. Giải pháp thân thiện và linh hoạt này
giúp tester thực hiện công tác kiểm tra tốt hơn, làm việc nhanh hơn và khởi chạy
phần mềm chất lượng cao nhờ vào sự thông minh mà nó cung cấp cho tồn bộ q
trình tự động hóa kiểm thử.
1.4.7. Junit
Junit là một framwork kiểm thử đơn vị cho ngơn ngữ lập trình Java. JUnit đã
rất quan trọng trong việc phát triển phần mềm theo hướng thử nghiệm. Junit là một
thể hiện của kiến trúc xUnit cho các khung kiểm thử đơn vị. JUnit thiết lập ý tưởng
"thử nghiệm đầu tiên sau codeing", nhấn mạnh vào việc thiết lập dữ liệu thử
nghiệm cho một đoạn code có thể được kiểm tra trước và sau đó được triển khai.
Cách tiếp cận này giống như "kiểm tra một chút, viết mã một chút, kiểm tra một
chút, viết mã một chút.". Junit làm tăng năng suất của lập trình viên và sự ổn định
của mã chương trình, do đó làm giảm sự căng thẳng trên lập trình viên và thời gian
dành cho việc gỡ lỗi.
1.4.8. Appium
Appium đã nổi lên là một trong những test tool phổ biến nhất để thử nghiệm
các ứng dụng di động và đã được xác nhận hiệu quả bởi những Tester và Developer
về tính dễ sử dụng. Nó là một tool mã nguồn mở cho phép tự động hóa web gốc,
web di động và ứng dụng lai trên nền tảng iOS và Android. Ứng dụng gốc là những
ứng dụng được viết bằng iOS, Android hoặc Windows SDK. Ứng dụng web di
động là các ứng dụng web được truy cập bằng trình duyệt dành cho thiết bị di
18


động. Ứng dụng lai có trình bao bọc xung quanh “chế độ xem web” một điều khiển
gốc cho phép tương tác với nội dung web. Các dự án như Apache Cordova hoặc
Phoneapp giúp dễ dàng xây dựng các ứng dụng bằng cách sử dụng cơng nghệ web

sau đó được gói thành một trình bao bọc gốc, tạo ra một ứng dụng lai.
Một trong những điểm nổi bật của Appium là nó hỗ trợ Safari trên iOS và
Chrome trên Android hoặc bất kỳ trình duyệt nào tích hợp trên Android. Điều này
giúp cho Appium trở thành một công cụ tự động hóa đa nền tảng và cho phép
người dùng viết các thử ngiệm trên nhiều nền tảng, cụ thể là iOS, Android và
Windows với cùng một API.
Công cụ này được built trên nền tảng testing native apps, không cần phải xử
lý SDK hoặc sắp xếp lại ứng dụng. Quan trọng nhất, nó cho phép người dùng sử
dụng đồng thời với các framework và tool khác cùng lúc. Hơn nữa, phụ trợ của
Appium là Selenium, cung cấp mọi chức năng của Selenium cho các yêu cầu kiểm
thử của bạn.
1.4.9. LoadStorm
LoadStorm là một công cụ kiểm thử phần mềm giúp kiểm tra tải tốt nhất thế
giới cho các trang web và ứng dụng. LoadStorm là một cơng cụ kiểm tra tải SaaS.
Nó thử nghiệm hiệu suất theo yêu cầu, kiểm tra tải và thử nghiệm ứng suất cho các
ứng dụng web và trang web. Nó tạo giúp cho việc tìm kiếm các dữ liệu có vấn đề
của trang web của bạn bằng cách cung cấp báo cáo phân tích sâu rộng trên máy
chủ, từng trang hoặc theo loại yêu cầu cho mọi chỉ số hiệu suất.
LoadStorm này được sử dụng để hỗ trợ nhiều người dùng đồng thời một ứng
dụng web hoặc trang web. Các nhà phát triển web có thể tạo các tài khoản miễn phí
để thiết kế, thử nghiệm và lập kế hoạch kiểm tra tải, sau đó chạy thử nghiệm với 50
người dùng ảo. Nếu số lượng người dùng ảo lớn hơn và kiểm tra băng thơng lớn
hơn thì tài khoản phải trả phí.

19


Mục tiêu của LoadStorm là tiện lợi và tiết kiệm. Biểu đồ và báo cáo mở rộng
của LoadStorm hiển thị cho bạn thời gian phản hồi, thông lượng, tỷ lệ lỗi, yêu cầu
mỗi giây, thời gian hoàn thành trang, v.v.

1.4.10. Quick Test Professional (QTP)
Là một công cụ kiểm thử tự động được thiết kế bởi Mercury Interactive và
sau đó được mua lại bởi HP. QTP giúp tester tiến hành các kiểm tra một cách tự
động để xác định errors, defects khác với kết quả mong muốn của ứng dụng, phần
mềm hay chức năng... mà ta đang kiểm tra.
1.4.11. Robotium
Kiểm thử tự động giúp chúng ta duy trì chất lượng phần mềm cao và cung cấp
một cơ sở để nắm bắt rõ ràng với bất kỳ thay đổi mã nào gây ảnh hưởng khi sử
dụng thực tế. Đầu tiên giới thiệu tổng quan về Robotium, các tính năng khác nhau
và lợi ích của nó trong kiểm thử tự động. Đến cuối phần này, sẽ thiết lập hồn
chỉnh Mơi trường Android trong Android studio để kiểm thử Robotium.
1.4.12. SOASTA CloudTest
CloudTest giúp bạn kiểm tra các website và ứng dụng trên di động một cách
linh hoạt, nhanh chóng. SOASTA CloudTest có thể kiểm tra khả năng chịu tải của
các ứng dụng theo vị trí địa lý khác nhau, đặc biệt 2 khâu integration và phân tích
thời gian thực giữa các monitoring, test design, reporting đều được tiến hành một
cách liền mạch.
1.4.13. Test Complete
TestComplete, được phát triển bởi SmartBear Software, cung cấp hỗ trợ cho
các công nghệ như là: Net, Delphi, C++Builder, Java, Visual Basic, HTML5,
Flash, Flex, Silverlight Desktop, hệ thống Web and Mobile. TestComplete giúp
người kiểm thử phát triển các trường hợp thử nghiệm của họ bằng nhiều ngôn ngữ
kịch bản khác nhau như JavaScript, Python, VBScript, Delphi Script, JavaScript.

20


Nó có sẵn với hai giấy phép và một phiên bản dùng thử miễn phí có giá trị trong 30
ngày.

CHƯƠNG 2
CÔNG CỤ KIỂM THỬ TEST COMPLETE
2.1. Giới thiệu chung về Test Complete
TestComplete là một môi trường kiểm thử tự động cho một loạt các loại ứng
dụng và công nghệ, bao gồm Windows, .NET, WPF, Visual C + +, Visual Basic,
Delphi, C + + Builder, Java và các ứng dụng Web và dịch vụ.
TestComplete được định hướng như nhau đối với chức năng kiểm thử, đơn
vị. Nó cung cấp hỗ trợ cho các thử nghiệm hồi quy hàng ngày và hỗ trợ nhiều loại
thử nghiệm: thử nghiệm dữ liệu điều khiển, kiểm thử đối tượng điều khiển, và
những người khác.
Bạn tạo ra các bài kiểm thử bằng cách ghi lại chúng hoặc lệnh kiểm thử
chỉnh sửa trong bảng và biên tập viên của TestComplete. Kiểm thử có thể được
chạy từ bên trong TestComplete hoặc họ có thể được xuất khẩu sang một ứng dụng
bên ngồi và chạy đó.
TestComplete nhận đối tượng và điều khiển trong các ứng dụng thử nghiệm
và cung cấp các lệnh đặc biệt để mô phỏng hành động sử dụng với họ. Nó cũng
cung cấp các trạm kiểm soát cụ thể, cho phép bạn dễ dàng kiểm thử trạng thái ứng
dụng trong thời gian chạy thử nghiệm.
2.2. Lịch sử hình thành
TestComplete được phát triển đầu tiên vào năm 1999 bởi cơng ty
AutomatedQA với tên Aqtest. Từ đó cho đến năm 2022, TestComplete trải qua
nhiều phiên bản khác nhau. Phiên bản hiện tại là TestComplete 15.40.
Các phiên bản trải qua:
• Aqtest 1.x (1.01; 1.5).
• TestComplete 2.x (2.0; 2.02; 2.03; 2.04).

21


• TestComplete 3.x (3.0; 3.01; 3.02; 3.03; 3.04; 3.05; 3.06; 3.07; 3.08;

3.09;3.10).
• TestComplete 4.x (4.0; 4.10; 4.20; 4.21; 4.22;4.23; 4.24; 4.25; 4.26;
4.27;4.28; 4.29; 4.30).
• TestComplete 5.x (5.0; 5.1; 5.11; 5.12; 5.13; 5.14).
• TestComplete 6.x (6.0; 6.10; 6.11; 6.12; 6.20; 6.30; 6.40; 6.50; 6.51;
6.52).
• TestComplete 7.x (7.0; 7.10; 7.20; 7.50; 7.51; 7.52).
• TestComplete 8.x (8.0; 8.10; 8.20; 8.50; 8.60; 8.70).
• TestComplete 9.x (9.0; 9.10; 9.20; 9.30; 9.31).
• TestComplete 10.x (10.0; 10.10; 10.20; 10.30; 10.40; 10.50; 10.60).
• TestComplete 11.x (11.0; 11.10; 11.11; 11.20; 10.30; 10.31).
• TestComplete 12.x (12.0; 12.10; 12.20; 12.30; 12.31; 12.40; 12.41;
12.42; 12.50; 12.60).
• TestComplete 14.x (14.0; 14.10; 14.20; 14.30; 14.40; 14.50; 14.60;
14.61; 14.70; 14.71; 14.72; 14.73; 14.74; 14.80; 14.81; 14.90; 14.91;
14.92; 14.93).
• TestComplete 15.x (15.0; 15.10; 15.20; 15.30; 15.31; 10.40).
2.3. Đặc điểm của công cụ Test Complete
2.3.1. Các chức năng chính
- Keyword testing: Sử dụng trình kiểm tra soạn thảo được tích hợp sẵn
Keyword do đó testers có thể phát triển được frameworks mà kiểm soát
Keyword rất dễ dàng.
- Scripted Testing: Người kiểm thử có thể viết kịch bản kiểm thử từ scratch
hoặc sửa đổi các tập lệnh được ghi trong trình chỉnh sửa được tích hợp sẵn.

22


- Test Record and Playback: Cung cấp cơ chế cơ bản của bản ghi và phát lại
những kiểm thử đã khởi tạo. Các test cases được ghi lại có thể được sửa đổi

khi cần thiết.
- Distributed Testing: TestComplete có thể chạy các tests tự động trên các
máy trạm hoặc máy ảo riêng biệt.
- Access to Methods and Properties of Internal Objects: TestComplete đọc
tên của các phần tử hiển thị và nhiều phần tử bên trong của các ứng dụng
Delphi, C ++ Builder, .NET, WPF, Java và Visual Basic và cho phép các tập
lệnh kiểm tra truy cập các giá trị này để xác minh hoặc sử dụng trong các
test.
- Integration to Bug Tracking Software: Tích hợp với nhiều phần mềm theo
dõi lỗi khác nhau như Jira, Bugzilla, v.v. Nó có thể được sử dụng để sửa đổi
hoặc tạo ra các mục trong phần mềm theo dõi lỗi bằng những mẫu theo dõi
vấn đề.
- Data Driven Testing: Trích xuất dữ liệu dễ dàng từ tệp CSV, bảng cơ sở dữ
liệu, trang tính Excel, v.v.
- COM-based, Open Architecture: Cơng cụ của TestComplete dựa trên giao
diện COM, API mở. Nó độc lập với ngơn ngữ nguồn và có thể đọc thơng tin
trình gỡ lỗi và sử dụng nó trong thời gian chạy thơng qua TestComplete
Debug Info Agent.
- Test Visualizer: Chụp ảnh màn hình trong quá trình thực hiện kiểm thử cho
phép chúng ta có thể phân biệt giữa các màn hình mong muốn và thực tế.
- Extensions and SDK - Mọi thứ hiển thị trong TestComplete - bảng, mục dự
án, đối tượng tập lệnh cụ thể và các mục khác - được triển khai dưới
dạng plug-ins. Các plugin này được tích hợp trong sản phẩm và được cài đặt
trên máy tính của bạn cùng với các mơ-đun TestComplete khác. Bạn có thể

23


tạo các plug-ins riêng của mình để mở rộng TestComplete và cung cấp chức
năng cụ thể cho nhu cầu cần thiết.

2.3.2. Các dạng test được hỗ trợ
- Functional (or GUI) Testing: Kiểm tra hàm.
- Regression testing: Kiểm tra hồi quy.
- Unit testing: Kiểm tra đơn vị.
- Distributed Testing: Kiểm tra phân tán.
- Load Testing: Kiểm tra truyền tải..
- Web Testing: Kiểm tra trên nền Web.
-Functional and load testing of web services: Kiểm tra các hàm và truyền tải
của dịch vụ Web.
- Coverage Testing.
- Data-Driven Testing.
- Manual Testing: Kiểm tra bằng tay.
- Keyword testing: Kiểm tra từ khóa.
2.3.3. Các ngơn ngữ viết mã hỗ trợ
- VBScript.
- Jscript.
- DelphiScript.
- C++Script.
- C#Script.
2.4. Cấu hình tối thiểu
- Hệ điều hành: Microsoft Windows 7 with Service Pack 1.
-

Trình duyệt: Microsoft Internet Explorer 10.0 hoặc cao hơn.

-

Chip: Intel Core 2 Duo 2 GHz hoặc cao hơn.

-

RAM: 2 GB.

24


- Đĩa hệ thống: 4 GB dung lượng trống trên đĩa hệ thống 1.5 GB dung luợng
trống để cài đặt, cộng thêm không gian cho các tệp tạm thời trong q trình
chạy thử.
-

Độ phân giải 1024×768 hoặc cao hơn.

-

Chuột hoặc thiết bị trỏ khác.

2.5. Ưu nhược điểm của công cụ TestComplete
Ưu điểm:
-

Dễ sử dụng: Trình chỉnh sửa tích hợp cho phép người dùng có kíến thức về bất kỳ
ngơn ngữ lập trình nào đều có thể thêm và xóa các bài kiểm tra, sửa đổi các tham
số và thay đổi thứ tự kiểm tra.

-

Tùy biến: Bên cạnh việc sử dụng giao diện trực quan, bạn được phép viết hoặc
chỉnh sửa tập lệnh theo cách thủ công nếu bạn thấy công cụ chỉnh sửa khơng đủ.

-

Cập nhật kịp thời: Vì đây là một sản phẩm thương mại, bạn có thể mong đợi một
mức độ bảo trì cao, hỗ trợ khách hàng và tất nhiên là các bản cập nhật.
Documentation của tool cũng đã và ln đuợc hồn thiện cho nên bạn khơng phải
mất thời gian truy cập, tìm kiếm trong các diễn đàn một mẹo hoặc giải pháp nào
cho phần mềm này.

-

Hỗ trợ các ứng dụng Desktop: Trong khi Selenium chỉ có thể thực thi các tests
trong trình duyệt (và ứng dụng di động sử dụng Appium), TestComplete hỗ trợ các
ứng dụng Windows.

-

Ngoài ra kiểm tra chức năng được đưa lên cấp độ tiếp theo khi bạn tích hợp các tập
lệnh Selenium test của mình với các giải pháp SmartBear bao gồm TestComplete.
Nhược điểm:

-

Chỉ hỗ trợ trên hệ điều hành Windows, nếu muốn sử dụng trên các hệ điều hành
khác điển hình là MacOS bạn cần phải cài máy ảo và tất nhiên cài máy ảo thì hiệu
suất làm việc khơng thể bằng máy thật được.

25