Qua thời gian tìmhiểu thực tế để thực hiện đề tài thực tập cũng như được nghiên cứu, tiếp cận trực tiếp với dự án em nhận thấy đây là một dự án lớn, vì vậy không thể tránh khỏi những lỗ
Trang 1
TRƯỜNG ĐẠI HỌC KIẾN TRÚC HÀ NỘIKHOA: CÔNG NGHỆ THÔNG TIN
BÁO CÁO THỰC TẬP TỐT NGHIỆP
GIÁO VIÊN HƯỚNG DẪN: TS BÙI HẢI PHONG SINH VIÊN THỰC HIỆN: TRẦN THỊ THANH
LỚP: 2020CN4
Đề tài:
KIỂM THỬ PHẦN MỀM BẰNG CÔNG CỤ SELELIUM IDE
CHO WEBSITE SHOPEE
Trang 2KIỂM THỬ PHẦN MỀM BẰNG CÔNG CỤ SELELIUM IDE
CHO WEBSITE SHOPEE BÁO CÁO THỰC TẬP TỐT NGHIỆP
Hà Nội, tháng 10/2024
GIÁO VIÊN HƯỚNG DẪN: TS BÙI HẢI PHONG SINH VIÊN THỰC HIỆN: TRẦN THỊ THANH
LỚP: 2020CN4
Trang 3LỜI NÓI ĐẦU 5
CHƯƠNG I: TỔNG QUAN VỀ CÔNG TY TNHH PHÂN TÍCH DỮ LIỆU INSIGHT DATA 6
1.1 GIỚI THIỆU CHUNG VỀ CÔNG TY TNHH PHÂN TÍCH DỮ LIỆU INSIGHT DATA 6
1.2 VĂN HÓA CON NGƯỜI 6
CHƯƠNG II: CƠ SỞ LÝ THUYẾT 7
2.1 KIẾN THỨC CƠ BẢN VỀ KIỂM THỬ 7
2.1.1 Kiểm thử phần mềm 7
2.1.2 Bảy nguyên tắc kiểm thử phần mềm 7
2.1.3 Quy trình kiểm thử phần mềm 8
2.1.4 Phân loại kiểm thử 10
2.2 CÁC MỨC ĐỘ KIỂM THỬ 11
2.2.1 Kiểm thử đơn vị - Unit test 11
2.2.2 Kiểm thử tích hợp – Intergration test 12
2.2.3 Kiểm thử hệ thống – System test 13
2.2.4 Kiểm thử chấp nhận sản phẩm – Acceptance Testing 16
CHƯƠNG III NỘI DUNG THỰC TẬP 18
3.1 CÁC MODULE KIỂM THỬ 18
3.2 XÂY DỰNG MODULE KIỂM THỬ 18
3.2.1 Module 1 - Kiểm tra phản hồi khi đăng nhập tài khoản 18
3.2.2 Module 2 - Kiểm tra phản hồi khi quên mật khẩu 19
3.2.3 Module 3 - Kiểm tra phản hồi khi tìm kiếm sản phẩm 20
3.2.4 Module 4 - Kiểm tra phản hồi khi mua hàng 21
Trang 43.2.5 Module 5 - Kiểm tra phản hồi khi đánh giá sau khi mua hàng và nhận được
hàng 22
CHƯƠNG IV KẾT LUẬN 24
TÀI LIỆU THAM KHẢO 25
DANH MỤC VIẾT TẮT CNTT Công nghệ thông tin DANH MỤC HÌNH ẢNH Hình 1 1 Logo công ty 6
Hình 3.2.1 Module 1 - Kiểm tra phản hồi khi đăng nhập tài khoản 18
Hình 3.2.2 Module 2 - Kiểm tra phản hồi khi quên mật khẩu 19
Hình 3.2.3 Module 3 - Kiểm tra phản hồi khi tìm kiếm sản phẩm 20 Hình 3.2.4 Module 3 - Kiểm tra phản hồi khi tìm kiếm sản phẩm
Hình 3.2.5 Module 3 - Kiểm tra phản hồi khi tìm kiếm sản phẩm
Trang 5LỜI NÓI ĐẦU
Trong những năm gần đây, với sự phát triển vượt trội của khoa học kĩ thuật đặc biệt
là công nghệ thông tin, với những ứng dụng của công nghệ thông tin vào các lĩnh vực đãgóp phần to lớn cho sự nghiệp phát triển của con người Việc Kiểm thử phần mềm chocác trang Web để phục vụ cho các nhu cầu riêng của tổ chức, công ti hay thâm chí cánhân ngày phổ biến và không còn là vấn đề xa lạ Đối với Kiểm thử phầm mềm bằngcông cụ SELENIUM IDE cho website Shopee thì ngày càng trở nên cấp thiết
Vì vậy, trong quá trình làm báo cáo em còn gặp nhiều khó khăn Qua thời gian tìmhiểu thực tế để thực hiện đề tài thực tập cũng như được nghiên cứu, tiếp cận trực tiếp với
dự án em nhận thấy đây là một dự án lớn, vì vậy không thể tránh khỏi những lỗ hổng, lỗisai sót trong quá trình phát triển phần mềm Do đó, yêu cầu đặt ra là cần có công tác kiểmthử phần mềm thật kỹ lưỡng nhằm ngăn chặn các lỗi hay hỏng hóc còn tiềm tàng bêntrong mà ta chưa kịp nhận ra, chính vì vậy em lưa chọn đề tài “Kiểm thử phầm mềm bằngcông cụ SELENIUM IDE cho website Shopee” để nghiên cứu, tìm hiểu và kiểm thử hệthống là để đáp ứng yêu cầu người dùng, phát hiện lỗi để từ đó nâng cao chất lượng phầnmềm ngày một tốt hơn
Báo cáo thực tập gồm 4 chương sau:
- Chương I: Tổng quan về Công ty TNHH phân tích dữ liệu Insight Data (INDA)
- Chương II: Cơ sở lý thuyết
- Chương III: Nội dung thực tập
- Chương IV: Kết luận
Vì kiến thức còn hạn hẹp nên không thể tránh khỏi có thiếu sót và sai lầm, rất mongnhận được sự góp ý từ các thầy, cô giảng viên của khoa Công nghệ thông tin trường Đạihọc Kiến trúc Hà Nội, cũng như góp ý từ phía cán bộ hướng dẫn thực tập tại Công tyTNHH phân tích dữ liệu Insight Data (INDA) để em có thể trau dồi kiến thức, đúc rútkinh nghiệm và phát triển kỹ năng sau này
Em xin chân thành cảm ơn!
Trang 6CHƯƠNG I: TỔNG QUAN VỀ CÔNG TY TNHH PHÂN TÍCH DỮ LIỆU
INSIGHT DATA1.1 GIỚI THIỆU CHUNG VỀ CÔNG TY TNHH PHÂN TÍCH DỮ LIỆU INSIGHT DATA
Thành lập từ năm 2020 Công ty TNHH phân tích dữ liệu Insight Data (INDA) hoạtđộng trong lĩnh vực Bigdata và Data Analytics chuyên cung cấp các dịch vụ & giải pháp
về dữ liệu gồm: Tư vấn, Triển khai xây dựng kho dữ liệu; Cho thuê nhân sự IT(Outsourcing); Đào tạo (Cá nhân, Doanh nghiệp); Bản quyền phần mềm (License) Độingũ tư vấn, triển khai của Insight data đều là những chuyên gia tư vấn có bề dày trên 10năm kinh nghiệm trong lĩnh vưc dữ liệu INDA đã tham gia triển khai rất nhiều các dự ánxây dựng kho dữ liệu (Data Warehouse/BI) cho các tổ chức tài chính, ngân hàng, tậpđoàn, doanh nghiệp lớn tại Việt Nam Chúng tôi hoàn toàn tin tưởng vào sự thành côngdựa trên năng lực của mình
Hình 1 1 Logo công ty 1.2 VĂN HÓA CON NGƯỜI
Với đội ngũ chuyên gia dày dặn kinh nghiệm, chúng tôi cam kết đặt yêu cầu củakhách hàng lên hàng đầu và đảm bảo công việc sẽ hoàn thành xuất sắc Đồng thời chúngtôi phối hợp chặt chẽ với khách hàng để đưa ra các giải pháp chất lương nhất và phù hợpnhất nhằm khai thác hiệu quả toàn bộ dữ liệu của họ
Trang 7CHƯƠNG II: CƠ SỞ LÝ THUYẾT2.1 KIẾN THỨC CƠ BẢN VỀ KIỂM THỬ.
2.1.1 Kiểm thử phần mềm
Kiểm thử phần mềm là quá trình thực thi 1 chương trình với mục đích tìm ra lỗi.Kiểm thử phần mềm đảm bảo sản phẩm phần mềm đáp ứng chính xác, đầy đủ và đúngtheo yêu cầu của khách hàng, yêu cầu của sản phẩm đề đã đặt ra Kiểm thử phần mềmcũng cung cấp mục tiêu, cái nhìn độc lập về phần mềm, điều này cho phép việc đánh giá
và hiểu rõ các rủi ro khi thực thi phần mềm Kiểm thử phần mềm tạo điều kiện cho bạntận dụng tối đa tư duy đánh giá và sáng tạo để bạn có thể phát hiện ra những điểm màngười khác chưa nhìn thấy
2.1.2 Bảy nguyên tắc kiểm thử phần mềm
Nguyên tắc 1: Kiểm thử luôn có 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ứngminh rằng một phần mềm không có lỗi Kiểm thử làm giảm xác suất lỗi tiềm ẩn trongphần mềm, ngay cả khi đã kiểm thử nghiêm ngặt phần mềm vẫn có thể còn lỗi Vì vậy,cần phải tìm được càng nhiều lỗi càng tốt
Nguyên tắc 2: Kiểm thử toàn bộ là không thể
Kiểm thử với tất cả các kết hợp đầu vào và đầu ra, với tất cả các kịch bản là khôngthể trừ khi kiểm thử chỉ bao gồm một số ít trường hợp thì có thể kiểm thử toàn bộ 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 người kiểm thử
có thể tập trung việc kiểm thử vào một số điểm cần thiết, có nguy cơ lỗi cao hơn Nghĩa làphải lên kế hoạch kiểm thử, thiết kế trường hợp kiểm thử sao cho có độ bao phủ nhiềunhất và giảm thiểu rủi ro sót lỗi khi đến tay người dùng
Nguyên tắc 3: Kiểm thử càng sớm càng tốt
Để tìm được lỗi sớm, các hoạt động kiểm thử nên được bắt đầu càng sớm càng tốttrong quy 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 trungvào các hoạt động/mục tiêu đã xác định trước Các hoạt động kiểm thử được bắt đầu càngsớm thì sẽ phát hiện ra lỗi sớm khi đó ít tốn công để tìm lỗi và sửa chữa
Nguyên tắc 4: Sự tập trung của lỗi
Trang 8Thông thường, lỗi tập trung vào những module, thành phần chức năng chính của
hệ thống Nếu xác định được điều này bạn sẽ tập trung vào tìm kiếm lỗi quanh khu vựcđược xác định Nó được coi là một trong những cách hiệu quả nhất để thực hiện kiểm trahiệu quả
Nguyên tắc 5: Nghịch lý thuốc trừ sâu
Nếu sử dụng cùng một tập hợp các trường hợp kiểm thử liên tục, sau đó một thờigian các trường hợp kiểm thử không tìm thấy lỗi nào mới Hiệu quả của các trường hợpkiểm thử bắt đầu giảm xuống sau một số lần thực hiện, vì vậy luôn luôn chúng ta phảiluôn xem xét và sửa đổi các trường hợp kiểm thử trên một khoảng thời gian thườngxuyên
Nguyên tắc 6: Kiểm thử phụ thuộc vào ngữ cảnh
Theo nguyên tắc này thì việc kiểm thử phụ thuộc vào ngữ cảnh và chúng ta phải tiếpcận kiểm thử theo nhiều ngữ cảnh khác nhau Nếu bạn đang kiểm thử ứng dụng web vàứng dụng di động bằng cách sử dụng chiến lược kiểm thử giống nhau, thì đó là sai Chiếnlược để kiểm thử ứng dụng web sẽ khác với kiểm thử ứng dụng cho thiết bị di động củaAndroid
Nguyên tắc 7: Không có lỗi – sai lầm
Việc không tìm thấy lỗi trên sản phẩm không đồng nghĩa với việc sản phẩm đã sẵnsàng để tung ra thị trường Việc không tìm thấy lỗi cũng có thể là do bộ trường hợp kiểmthử được tạo ra chỉ nhằm kiểm tra những tính năng được làm đúng theo yêu cầu thay vìnhằm tìm kiếm lỗi mới
2.1.3 Quy trình kiểm thử phần mềm.
2.1.3.1 Lập kết hoạch
Nhằm chỉ định và mô tả các loại kiểm thử sẽ được triển khai và thực hiện Kết quả làbản kế hoạch kiểm thử phần mềm bao gồm chi tiết từ các loại kiểm thử, chiến lược kiểmthử, cho đến thời gian và phân định lực lượng kiểm thử viên
Các bước lập kế hoạch kiểm thử:
- Xác định yêu cầu kiểm thử: Xác định những gì cần phải kiểm thử dựa theo yêu cầu
từ khách hàng, đặc tả yêu cầu người sử dụng
Trang 9- Xác định các chiến lược kiểm thử: Xác định phương thức, loại kiểm thử cần thựchiện và tiêu chí đầu ra.
- Xác định tài nguyên, môi trường: Xác định nguồn nhân lực và môi trường thựchiện kiểm thử (số lượng người, yêu cầu về phần cứng, phần mềm, công cụ hỗtrợ…)
- Lập thời gian cho các giai đoạn kiểm thử:
- Đánh giá kế hoạch: Trưởng dự án sẽ cùng những người liên quan tham gia đánhgiá xem bản kế hoạch kiểm thử có phù hợp với yêu cầu dự án chưa Nếu chưa thì
sẽ phải thực hiển sửa lại theo yêu cầu
- Thông báo tới các bên liên quan: Trưởng dự án sẽ gửi thông báo toàn bộ nhữngngười trong dự án có liên quan đến kế hoạch kiểm thử
b) Thiết kế test case (thiết kế trường hợp kiểm thử)
Nhằm chỉ định các test case và các bước kiểm tra chi tiết cho mỗi phần mềm Giaiđoạn thiết kế test case là hết sức quan trọng, nó đảm bảo các tình huống kiểm thử bao phủtất cả các yêu cầu
c) Phát triển test script
Bước này thường không bắt buộc trong các loại và mức kiểm thử, chỉ yêu cầu trongnhững trường hợp đặc thù cần thiết kế, tạo ra các test script có khả năng chạy trên máytính giúp tự động hóa việc thực thi các bước kiểm tra đã định nghĩa ở các bước thiết kếkiểm thử
d) Thực hiện kiểm thử
- Thiết lập môi trường và cài đặt: Để thực hiện kiểm thử, thao tác đầu tiên cần làm làxác lập và khởi động môi trường kiểm thử Việc này nhằm đảm bảo tất cả các bộphận liên quan (phần cứng, phần mềm, máy chủ, mạng, dữ liệu…) đã được cài đặt
và sẵn sàng trước khi chính thức bắt đầu thực hiện kiểm thử
- Tiến hành kiểm thử theo các trường hợp kiểm thử đã chuẩn bị
- Thẩm định kết quả kiểm thử: Sau khi tiến hành kiểm thử, kết quả kiểm thử cầnđược xem xét để đảm bảo kết quả nhận được là đáng tin cậy Nhận biết đượcnhững lỗi không phải do phần mềm mà do dữ liệu dùng để kiểm thử, môi trườngkiểm thử, hoặc các bước kiểm thử gây ra Nếu thực sự lỗi xảy ra do quá trình kiểmthử, cần phải sửa chữa và kiểm tra lại từ đầu
Trang 10e) Đánh giá quá trình kiểm thử
Bao gồm xem xét và đánh giá kết quả kiểm thử lỗi, chỉ định các yêu cầu thay đổi
và tính toán số liệu liên quan đến quá trình kiểm thử (chẳng hạn số giờ, thời gian kiểm tra,
số lượng lỗi…)
Các bước đánh giá quá trình kiểm thử:
- Thống kê số lượng lỗi
- Phân tích kết quả kiểm thử và yêu cầu sửa chữa: Chỉ định và đánh giá sự khác biệtgiữa kết quả mong đợi và kết quả thực tế, tổng hợp và gửi thông tin yêu cầu sửachữa đến những người có trách nhiệm trong dự án, lưu trữ để kiểm tra sau đó
- Đánh giá chất lượng sản phẩm kiểm thử: Từ những kết quả kiểm thử, nhóm kiểmthử sẽ xem xét, đánh giá chất lượng sản phẩm
- Thông báo tới các bên liên quan: Trưởng dự án sẽ thông báo cho các bên liên quan
về kết quả kiểm thử đạt được
2.1.4 Phân loại kiểm thử.
a) Static testing (Kiểm thử tĩnh)
Kiểm thử tĩnh là một hình thức của kiểm thử phần mềm mà phần mềm không được
sử dụng thực sự Thường thì nó không kiểm thử chi tiết mà chủ yếu kiểm tra tính đúngđắn của code (mã lệnh), thuật toán hay tài liệu Chủ yếu kiểm tra cú pháp của code/ hoặcreview code (kiểm tra xem code có được viết đúng tiêu chuẩn code Đây là loại kiểm thử
có thể được sử dụng bởi DEV (những người lập trình), làm việc một cách độc lập Các kỹthuật review code , kiểm tra và walkthoughs cũng được sử dụng trong test tĩnh này Kiểmthử tĩnh liên quan đến việc xem xét các yêu cầu và các tài liệu thiết kế chi tiết
Kiểm thử tĩnh cũng có thể được tự động hóa Nó sẽ thực hiện kiểm tra toàn bộ baogồm các chương trình được phân tích bởi một trình thông dịch hoặc biên dịch mà xácnhận tính hợp lệ về cú pháp của chương trình Các kỹ thuật kiểm thử tĩnh giúp nâng caochất lượng phần mềm bằng cách hỗ trợ các nhà phát triển nhận ra và sửa chữa các sai sótcủa họ trong quá trình phát triển phần mềm
b) Dynamic testing (Kiểm thử động)
Kiểm thử tự động là việc sử dụng phần mềm đặc biệt (tách biệt với phần mềm đangđược kiểm thử) để kiểm soát việc thực hiện các bài kiểm tra và so sánh kết quả thực tế vớikết quả dự đoán Kiểm thử tự động có thể tự động hóa một số nhiệm vụ lặp đi lặp lạinhưng cần thiết trong một quá trình kiểm thử đã được chính thức hóa, hay là các kiểm thử
Trang 11bổ sung nhưng sẽ khó thực hiện thủ công Kiểm thử động kiểm tra cách thức hoạt độngcủa mã lệnh, tức là kiểm tra sự phản ứng vật lý từ hệ thống tới các biến luôn thay đổi theothời gian Trong kiểm thử động, phần mềm phải thực sự được biên dịch và chạy Kiểmthử động thực sự bao gồm: làm việc với phần mềm, nhập các giá trị đầu vào và kiểm traxem liệu đầu ra có như mong muốn hay không.
Các phương pháp kiểm thử động gồm có: Unit test (Kiểm thử đơn vị), Intergration Tests(Kiểm thử tích hợp), System Tests (Kiểm thử hệ thống) và Acceptance Tests (Kiểm thửchấp nhận)
2.2 CÁC MỨC ĐỘ KIỂM THỬ
2.2.1 Kiểm thử đơn vị - Unit test
Unit test là mức độ kiểm thử nhỏ nhất trong quy trình kiểm thử phần mềm Unit testkiểm thử các đơn vị nhỏ nhất trong mã nguồn như method, class, module Do đó Unittest nhằm kiểm tra mã nguồn của các chương trình, các chức năng riêng rẽ hoạt độngđúng hay không
Viết Unit test tốt giúp tăng sự tin tưởng vào mã nguồn được thay đổi hoặc bảo trì.Bởi lẽ, nếu viết Unit test tốt, mỗi lần có sự thay đổi bên trong mã nguồn và chạyunit test, chúng ta có thể bắt được những lỗi sảy ra do thay đổi mã nguồn
Chúng ta có thể kiểm thử từng thành phần riêng rẽ của dự án mà không cần đợi cácthành phần khác hoàn thành
Do thực hiện test trên từng đơn vị nhỏ của các module riêng rẽ nên khi phát hiệnlỗi cũng dễ dàng khoanh vùng và sửa chữa
Có thể tái sử dụng mã nguồn
Chi phí cho việc sửa chữa lỗi trong giai đoạn unit test sẽ ít hơn so với các giai đoạnsau
Mã nguồn đáng tin cậy hơn nếu viết tốt unit test
Một số lưu ý khi viết Unit test
Chắc chắn rằng mỗi test case kiểm thử mức đơn vị sẽ độc lập với những test casekhác Không nên gọi một test case khác trong một test case Test case không nênphụ thuộc vào nhau cả về data và thứ tự thực hiện
Trang 12 Luôn luôn kiểm tra từng mô-đun một cách độc lập Nếu không, sẽ có nhiều sựchồng chéo giữa các ca thử nghiệm và việc thay đổi đối với một đơn vị có thể ảnhhưởng đến tất cả các mô-đun khác và khiến phần mềm bị lỗi.
Đặt tên các đơn vị kiểm thử một cách rõ ràng và nhất quán Đảm bảo rằng các testcase dễ đọc, bất kỳ ai cũng có thể chọn test case và chạy nó mà không gặp bất kỳvấn đề nào
Khi triển khai việc thay đổi giao diện hoặc chức năng, cần chạy lại các test casetrước đó nhằm đảm bảo việc thay đổi này không làm ảnh hưởng đến những testcase cũ đã pass
Luôn đảm bảo lỗi được xác định trong quá trình Unit test được sửa trước khichuyển sang giai đoạn tiếp theo
Không cố gắng viết test case để kiểm thử tất cả mọi thứ, thay vào đó nên tập chungvào kiểm thử sự ảnh hưởng của hành vi hệ thống
Bên cạnh viết test case để test hành vi hệ thống, cần viết thêm test case để kiểm thửhiệu năng của mã nguồn
Các testsuit nên đặt riêng ra, độc lập code với module
Không nên có nhiều assert trong một test case vì khi một điều kiện không thỏa mãnthì các assert khác sẽ bị bỏ qua
Sau một thời gian dài, số lượng test case nhiều, thời gian chạy lớn Nên chia ranhóm test case cũ và test case mới, test case cũ sẽ chạy với tần xuất ít hơn
2.2.2 Kiểm thử tích hợp – Intergration test
Kiểm thử tích hợp (Integration testing) hay còn gọi là tích hợp và kiểmthử (integration and testing, viết tắt: I&T) là một giai đoạn trong kiểm thử phầnmềm Mỗi môđun phần mềm riêng biệt được kết hợp lại và kiểm thử theo nhóm
Kiểm thử tích hợp xảy ra sau kiểm thử đơn vị (Unit Test) và trước kiểm thử xácnhận Kiểm thử tích hợp nhận các môđun đầu vào đã được kiểm thử đơn vị, nhómchúng vào các tập hợp lớn hơn, áp dụng các ca kiểm thử đã được định nghĩatrong kế hoạch kiểm thử tích hợp vào tập hợp đó, và cung cấp đầu ra cho hệ thốngtích hợp
Mặc dù mỗi module đều được kiểm thử đơn vị (Unit test) nhưng các lỗi vẫn còn tồn tại vớicác nguyên nhân sau: