ĐỀ tài NGHIÊN cứu CÔNG cụ KIỂM THỬ TEST COMPLETE và ỨNG DỤNG

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ó đủ chuyên môn và điều kiện

TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP HÀ NỘI

KHOA CÔNG NGHỆ THÔNG TIN

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ó đủ

chuyên 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 toà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 hoà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ể hoà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.

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 hoà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ềmlinh 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ó.

- 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.

- 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?

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ầnphầ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.

Hộộp đeen

Acccceeppttaanncce teessttiinng Hộộp đeen

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.

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

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.

- 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à toà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.

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 quá trình kiểm thử.

• 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ể hoà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 yê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ử

thủ công Nó có những lỗi và khả năng dự đoá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 toàn bộ được).

Thay vì kiểm thử toà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úckiể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ì

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

STTT Bưướớc thhữ hiiệện Môôt tả

Bưướớc 1 Tạạo kịịcch bảản kiiểểm thhử Giiaai đooạạn nàày dùùnng côông cu kiiểể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ử

Bước 2 Chỉnh sử kịch bản 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)

Bưướớc 3 Chạy kịịcch bảản kiiểểm thhử Chhạạ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.

Bưướớc 4 Đáánnh giiá kếết quuả Đáánnh giiá kếết quả sau khi chhạạy kịcch

bản kiểm thử

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.

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.

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

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 điiểểm Nhhưượợc điiểể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à

Đã phát triển và hoà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ệiệ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ó.

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 soá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 điiểểm

Cài đặt đơn giản hơn so với selenium

RC

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

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

Không cần một thành phần riêng biệt

như máy chủ của RC

Thời gian thực thi nhanh hơn

IDE và RC

1.4.5 Jmeter

Nhhưượợc điiểểmCài đặt phức tạp hơn so với seleniumIDE

Yêu cầu kiến thức lập trình Không thể hỗ trợ các trình duyệt mới Không có cơ chế tích hợp để ghi nhật ký thời gian chạy và tạo kết quả kiểm tra

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

đó, 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ụ toà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 toàn bộ quá 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

độ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ểmthử của bạn.

đó 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í.

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 hoà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.

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.

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 ngoà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

TestComplpletete được phát triểiể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).

• 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).

- 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.

- 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õivấ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ể

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.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.

- Đĩ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 quá 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à luôn đuợc hoà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.

- Đây là một phần mềm trả phí một lần, tuy nhiên bạn còn phải trả thêm phí duy trì mỗi năm (nhưng theo nhận xét của cộng đồng nguời sử dụng trên mạng phản ánh nó là một công cụ hỗ trợ đáng để cho bạn trả ra khoản tiền này).

2.6 Cài đặt TestComplete

- TestComplete có thể được tải xuống từ trang chủ của SmartBear:

https://smartbear.com/product/testcomplete/free-trial/

Hình 2.1 Giao diện để điền thông tin lấy link tải test complete

- Các bước hướng dẫn tải:

Bước 1: Nhấp đúp vào gói cài đặt TestComplete đã tải xuống Cài đặt phần mềm sẽ bắt đầu và thỏa thuận cấp phép sẽ được hiển thị.

Bước 2: Chỉ định đường dẫn của thư mục mà bạn muốn cài đặt phần mềm.Bước 3: Hộp thoại chào mừng được hiển thị để yêu cầu kích

hoạt giấy phép, chúng ta có thể bắt đầu bằng cách nhấp vào

giấy phép dùng thử 30 ngày Bước 4: Sau đó khởi động lại máy tính, chúng ta đã hoàn tất quá trình cài đặt TestComplete.