Kiến thức cơ bản về quy trình kiểm thử phần mềm, kiểm thử phần mềm, lý thuyết cơ bản về kiểm thử phần mềm, kiểm thử tự động, cách cài đặt và sử dụng selenium IDE. Bài toán thực tế. Là một tài liệu về kiểm thử phần mềm mang tính khách quan, cơ bản dễ hiểu nhất về kiểm thử phần mềm
Trang 1LỜI NÓI ĐẦU
Trong thời kì phát triển của công nghệ thông tin, công nghệ phần mềm đang chiếm vị trí quan trọng trong xu hướng phát triển kinh tế công nghiệp hóa hiện đại hóa của nước ta Bên cạnh với sự phát triển nhanh chóng của công nghệ phần mềm thì lỗi phần mềm và chất lượng phần mềm cũng là một thách thức đối với các nhà phát hành phần mềm Kiểm thử phần mềm là giai đoạn chiếm hơn 40% thời gian, kinh phí và nguồn nhân lực phát triển dự án phần mềm Ở Việt Nam hiện nay, việc kiểm thử phần mềm đã và đang được nhìn nhận đúng với tầm quan trọng của nó nhưng mức độ đáp ứng của các kiểm thử viên kiểm thử phần mềm ở Việt Nam vẫn chưa được nâng cao Các kiểm thử viên chưa được đào tạo chuyên sâu về kiểm thử phần mềm Kiểm thử phần mềm vẫn đang tiêu tốn một lượng thời gian, kinh phí và nhân lực trong phát triển phần mềm Hiện nay các ứng dụng web đã được phát triển và trở thành nền tảng kết nối thông tin trong nhiều doanh nghiệp, thông tin giữa doanh nghiệp với khách hàng
Để việc trao đổi thông tin thuận lợi các ứng dụng web cần có hiệu năng cao và đáng tin cậy Vì vậy, cần có các hệ thống kiểm thử phần mềm tự động cho phép thực hiện các công việc một cách nhanh chóng và chính xác Để đáp ứng nhu cầu của việc kiểm thử thì một loạt các công cụ kiểm thử tự động ra đời như Quick Test Professional, Nunit, Junit, Load Runne…Selenium là một công cụ kiểm thử ứng dụng web có nhiều ưu điểm như có thể kiểm thử được trên nhiều trình duyệt, hỗ trợ nhiều ngôn ngữ lập trình, đặc biệt Selenium là một bộ mã nguồn mở nên các tổ chức sẽ không tốn kinh phí để mua bản quyền
Với sự tìm tòi và định hướng trong tương lai và mong muốn có cái nhìn rõ ràng hơn về kiểm thử phần mềm trong phát triển phần mềm và tiếp cận với công cụ kiểm thử tự động Selenium để làm nền tảng cho định hướng tương lai sau khi tốt nghiệp sẽ
trở thành một kiểm thử viên em lựa chọn đề tài “Nghiên cứu về kiểm thử phần mềm
và kiểm thử ứng dụng web với Selenium” để làm đề tài tốt nghiệp đại học của mình.
Trang 2Để có kết quả và thành tích học tập như ngày hôm nay, bên cạnh sự học hỏi cố gắng của bản thân, em xin chân thành cảm ơn các thầy cô trong Viện Điện tử - Viễn thông đã hướng dẫn, dạy dỗ, giúp đỡ em trong thời gian học tập ở trường.
Em xin gửi lời cảm ơn chân thành và sâu sắc đến thầy T.S Nguyễn Vũ Thắng giảng viên Viện Điện tử - Viễn thông trường Đại học Bách Khoa Hà Nội đã định hướng, hướng dẫn chỉ bảo tận tình trong quá trình em hoàn thành đồ án này
Mặc dù đã cố gắng hết sức nhưng do thời gian và kiến thức trình độ của bản thân còn hạn chế nên báo cáo không thể tránh khỏi những sai sót Vì vậy em rất mong
sự góp ý từ các thầy cô và bạn bè Em xin chân thành cảm ơn!
Sinh viên
Lê Thị Thúy
Trang 3
TÓM TẮT ĐỒ ÁN
1. Mục tiêu nghiên cứu
- Hiểu sâu hơn và có cái nhìn cụ thể cơ bản về phần mềm và kiểm thử phần mềm
- Hiểu rõ về các thành phần, nắm được cách sử dụng công cụ kiểm thử tự động Selenium IDE
- Ứng dụng kiến thức về kiểm thử và sử dụng công cụ tự động Selenium vào bài toán thực tế
2. Nội dung tóm tắt
Đồ án gồm 6 phần
- Mở đầu: Lời nói đầu: Chương này trình bày lí do chọn đề tài, lời cảm ơn, mục
tiêu nghiên cứu, tóm tắt bố cục đồ án
- Chương I: Khái quát về phần mềm và lỗi của phần mềm: Chương này nêu định
nghĩa cơ bản về các vấn đề của phần mềm, các lỗi phần mềm thường gặp và quy trình phát triển phần mềm, quy trình xử lí lỗi
- Chương II: Khái quát về kiểm thử phần mềm: Chương này nêu kiến thức cơ
bản về kiểm thử phần mềm, định nghĩa, các loại kiểm thử, cấp độ kiểm thử, mục đích và vai trò của kiểm thử…
- Chương III: Kiểm thử ứng dụng web và công cụ kiểm thử tự động Selenium:
Trình bày tổng quan về kiểm thử ứng dụng web, kiểm thử tự động, cách cài đặt
và sử dụng công cụ Selenium IDE
- Chương IV: Bài toán thực tế: Chương này trình bày kịch bản kiểm thử cho một
số chức năng của website testerhnstore.com, dùng Selenium IDE để kiểm thử.
- Kết luận: Chương này nêu kết quả đồ án đạt được, những điều chưa làm được
trình bày hướng phát triển trong tương lai
Trang 5Selenium IDE Selenium Integrated Development Environment
HTML HyperText Markup Language
MỞ ĐẦU
Bài toán đặt ra trong đồ án: Nghiên cứu tổng quan lý thuyết về kiểm thử phần
mềm, công cụ kiểm thử tự động Selenium, ứng dụng công cụ Selenium IDE vào kiểm thử website http://testerhnstore.com/
Trang 6Phương pháp giải quyết: Hiện nay trên mạng internet có rất nhiều thông tin,
bài viết nói về kiểm thử phần mềm, phần lớn chủ yếu tìm hiểu qua mạng, và một số sách tiếng anh
Có rất nhiều công cụ kiểm thử website hiện nay nhưng Selenium là công cụ được sử dụng rộng rãi nhất Các thành phần của Selenium như Selenium IDE, Selenium RC…
Phạm vi giải quyết và hạn chế của đồ án: Chỉ dừng ở lý thuyết tổng quan,
không đào sâu vào lý thuyết cụ thể của kiểm thử phần mềm, phương pháp giải quyết bài toán chỉ trong dừng ở công cụ Selenium IDE trong khi Selenium còn có các thành phần công cụ khác như Selenium RC, Selenium Webdriver…
Chương I: Khái quát về phần mềm và lỗi của phần mềm
Trang 7• Khái niệm về phần mềm, lỗi của phần mềm
1.2 Phân loại phần mềm
Theo phương thức hoạt động:
o Phần mềm hệ thống: Dùng để vận hành máy tính và các phần cứng máy tính (ví dụ: Windows, Linux, Unix…)
o Phần mềm ứng dụng: Người sử dụng có thể hoàn thành một hay nhiều công việc nào đó (ví dụ phần mềm văn phòng như: word, excel…)
o Các phần mềm chuyển dịch mã bao gồm trình biên dịch và trình thông dịch: các chương trình này sẽ đọc các câu lệnh từ mã nguồn được viết bởi các lập trình viên theo một ngôn ngữ lập trình và dịch nó sang một dạng khác như là tập tin đối tượng, tập tin thư viện mà các phần mềm khác có thể hiểu để vận hành máy tính thực thi các lệnh
o Các nền tảng công nghệ như Net
Theo khả năng ứng dụng
o Những phần mềm không phụ thuộc, có thể bán cho bất kỳ khách hàng nào trên thị trường tự do ví dụ như: Phần mềm về cơ sở dữ liệu như Oracle…
o Những phần mềm được viết theo đơn đặt hàng hay hợp đồng của một khách hàng cụ thể nào đó (công ty, bệnh viện, trường học…) ví dụ như: Phần mềm điều khiển, phần mềm hỗ trợ bán hàng,…
1.3 Quy trình phát triển phần mềm
1.3.1 Khái quát
Trang 8Quy trình là một trong những yếu tố cần thiết và quan trọng mang lại sự thành công cho các nhà sản xuất phần mềm Hiện nay có rất nhiều quy trình phát triển phần mềm theo nhiều mô hình khác nhau Có thể nói quy trình phát triển phần mềm có tính chất quyết định để tạo ra một sản phẩm chất lượng tốt với chi phí thấp và năng suất cao nhất Quy trình có thể hiểu là phương pháp cách thức thực hiện, sản xuất ra sản phẩm Thông thường một quy trình phát triển phần mềm gồm các giai đoạn như hình vẽ sau:
Hình 1 Quy trình phát triển phần mềm1.3.2 Một số vấn đề thường gặp trong phát triển phần mềm
Trong quá trình phát triển phần mềm, nhà phát triển có thể gặp nhiều vấn đề, các tình huống phát sinh, vì vậy biết rõ được các vấn đề thường gặp sẽ giúp cho nhà phát triển có những kế hoạch cụ thể, xây dựng kiểm thử sản phẩm một cách chặt chẽ và đầy
đủ hơn Một số vấn đề thường gặp như sau:
- Tính toán không đúng, hiệu chỉnh sai dữ liệu
- Tìm kiếm dữ liệu sai yêu cầu
- Xử lí sai các mối quan hệ giữa các dữ liệu
- Lập trình, hiện thực sai các quy luật nghiệp vụ
- Hiệu suất của phần mềm còn thấp, kết quả không tin cậy
Trang 9- An ninh bảo mật phần mềm chưa đủ.
1.3.3 Mối quan hệ giữa quy trình phát triển phần mềm và kiểm thử phần
mềm
Trong quá trình phát triển phần mềm thường gặp các vấn đề xảy ra ảnh hưởng tới sản phẩm Vì vậy, việc kiểm thử phần mềm là điều tất yếu Trong quá trình phát triển phần mềm thì việc kiểm thử phải được tiến hành ở tất cả các giai đoạn để nếu phát hiện ra lỗi thì sữa chữa kịp thời vì để về sau mới phát hiện ra lỗi thì chi phí sửa lại là vô cùng lớn, mất thời gian và công sức Việc kiểm thử phải luôn luôn được thực hiện trong suốt quá trình phát triển phần mềm để đảm bảo chất lượng sản phẩm một cách tốt nhất
1.4 Chất lượng phần mềm và đảm bảo chất lượng phần mềm
Theo IEEE (1991): Chất lượng phần mềm là một mức độ mà một hệ thống hay thành phần, quy trình đáp ứng được yêu cầu đã được đặc tả, đáp ứng được yêu cầu, sự mong đợi của khách hàng hay người sử dụng
Hay có thể nói: Đảm bảo chất lượng phần mềm là một tập hợp các hành động cần thiết lên kế hoạch một cách hệ thống để cung cấp đầy đủ niềm tin rằng quá trình phát triển phần mềm phù hợp để thành lập các yêu cầu chức năng cũng như các yêu cầu quản lý theo lịch trình và hoạt động trong giới hạn cho phép
Có thể nói đảm bảo chất lượng phần mềm chính là tạo và bắt phần mềm phải tuân theo các chuẩn để cải tiến quy trình phát triển và ngăn chặn các lỗi xuất hiện bất cứ lúc nào
1.5 Lỗi phần mềm
1.5.1 Định nghĩa và phân loại
Định nghĩa: Lỗi phần mềm chính là sự không khớp giữa chương trình và đặc
tả của nó
Dựa vào định nghĩa trên có thể phân loại phần mềm thành 3 dạng sau:
o Lỗi sai: Sản phẩm phần mềm được xây dựng khác với đặc tả
o Lỗi thiếu: Các yêu cầu của sản phẩm phần mềm có trong đặc tả nhưng không có trong sản phẩm thực tế
o Lỗi thừa: Sản phẩm thực tế có những tính năng không có trong đặc tả
Trang 101.5.2 Các nguyên nhân gây ra lỗi phần mềm
Phần mềm bị lỗi có thể đến từ nhiều nguyên nhân khác nhau, nguyên nhân khách quan và các nguyên nhân chủ quan:
- Lỗi trong giao tiếp giữa khách hàng và nhà phát triển: Những lỗi này thường xuất hiện ở giai đoạn đầu của dự án Một số lỗi thường gặp như: hiểu sai yêu cầu, hiểu sai về sự thay đổi trong yêu cầu của khách hàng…
- Sai lệch cố ý với các yêu cầu phần mềm: Trong một số trường hợp các nhà phát triển cố tình làm sai lệch các yêu cầu trong tài liệu đặc tả, nguyên nhân là do áp lực về thời gian, ngân sách…hoặc yêu cầu đặc tả của khách hàng chưa phân tích đầy đủ
- Lỗi thiết kế logic: Lỗi phần mềm xảy ra trong quá trình các chuyên gia thiết kế
hệ thống, kỹ sư phần mềm, các nhà phân tích xây dựng phần mềm theo yêu cầu Các lỗi như: Định nghĩa các yêu cầu phần mềm bằng các thuật toán sai, thiếu sót các trạng thái hệ thống phần mềm được yêu cầu…
- Lỗi do lập trình: Do hiểu sai tài liệu thiết kế, sai sót trong ngôn ngữ lập trình, sai sót trong lựa chọn dữ liệu, công cụ phát triển…
- Không tuân thủ theo các tài liệu hướng dẫn và tiêu chuẩn lập trình: Các lỗi phần mềm có thể đến từ việc không tuân thủ theo các tài liệu và tiêu chuẩn của các tổ chức phát triển phần mềm
- Thiếu sót trong quá trình kiểm thử: không có kế hoạch kiểm thử, sót yêu cầu cần kiểm thử, tính thiếu cẩn thận của người kiểm thử
- Lỗi thủ tục và lỗi trong tài liệu
1.5.3 Quy trình xử lí lỗi phần mềm
Trước khi giới thiệu về quy trình xử lí lỗi phần mềm thì sau đây là một vài
trạng thái có thể của lỗi
Trang 11Hình 1 Một số trạng thái của lỗi
Trong đó:
- Lỗi mới (New)
- Lỗi đã được gán cho nhân viên phát triển (Assigned)
- Lỗi đã được xử lý (Resolved)
- Lỗi cần được chứng thực, thảo luận lại (Confirmed)
- Lỗi được xác định là không phải lỗi, lỗi được bỏ qua (Cancelled)
- Lỗi không thuộc phạm vi của dự án, hoặc sẽ được xử lý trong một giai đoạn của dự án (Next)
- Các lỗi có thể chấp nhận được: ví dụ như các lỗi do framework (Accepted)
- Trạng thái đóng, lỗi đã được sửa thành công (Closed)
Mỗi một tổ chức phát triển phần mềm sẽ sử dụng một công cụ quản lí lỗi riêng, công cụ điển hình và được sử dụng phổ biến hiện nay có thể kể đến như Mantis Để việc xử lý lỗi triệt để nhà phát triển phần mềm thường theo quy trình xử lí lỗi như sau:
Trang 12Hình 1 Quy trình xử lí lỗiTheo hình vẽ trên, quy trình xử lý lỗi có thể bao gồm 6 bước chính:
Bước 1: Bắt đầu: Phát hiện phần mềm có lỗi
Bước 2: Đưa lỗi lên hệ thống quản lí lỗi
- Người thực hiện: Tất cả các thành viên trong đội dự án như quản trị dự án, nhóm kiểm thử, nhóm giải pháp, nhóm lập trình Trạng thái của lỗi là New
- Một số thông tin cần có về lỗi như:
o Category: Thư mục lỗi dùng để phân loại lỗi, lỗi thuộc phần chức năng nào phải chọn đúng phần thư mục lỗi tương ứng để thuận tiện cho việc tra cứu, thống kê lỗi của chức năng
Trang 13o Severity (trọng số của lỗi): Thông số này biểu hiện độ nghiêm trọng của lỗi, thông thường lỗi sẽ thuộc một trong ba trọng số dưới đây:
• Minor: Các lỗi định dạng (font chữ, cỡ chữ, màu sắc của các đối tượng, chiều dài của các đối tương), lỗi chính tả, lỗi giá trị dữ liệu
• Major: Các lỗi ràng buộc dữ liệu, lỗi chức năng nghiệp vụ của hệ thống (chưa gây ra treo hệ thống hay không làm cho hệ thống không xử lí được tiếp)
• Crash: các lỗi chức năng nghiệp vụ của hệ thống gây treo hệ thống, không xử lí được tiếp
o Reproducibility: Khả năng tái tạo lỗi Khi phát hiện ra lỗi, nhân viên kiểm thử cần thực hiện lại phần chức năng phát hiện ra lỗi để tái tạo lỗi và lựa chọn đúng khả năng tái tạo lỗi
o Priority: Mức độ ưu tiên trong việc sửa lỗi
o Summary: Tóm tắt nội dung lỗi, có thể là tiêu đề của lỗi
o Description: Đây là phần mô tả lỗi, phải mô tả 3 phần nội dung: Các bước thực hiện, kết quả trả về từ hệ thống, kết quả mong muốn
o Notes: Dùng để đưa các lưu ý, trao đổi về lỗi của các thành viên trong dự án
Bước 3: Gán lỗi cho nhân viên phát triển
- Nhân viên kiểm thử thực hiện gán lỗi cho nhân viên phát triển, người sẽ chịu trách nhiệm về phần chức năng bị lỗi
- Trạng thái của lỗi là Assigned
- Chú ý:
o Trưởng nhóm kiểm thử, quản trị dự án có thể xem xét lại các lỗi có trạng thái New và Assigned trên hệ thống phần mềm quản lí lỗi: Nếu thấy không phải lỗi thì đưa lỗi về trạng thái Cancelled và nêu rõ nguyên nhân đưa lỗi về Cancelled Nếu thấy nhân viên kiểm thử mô tả không rõ ràng, thiếu thông tin thì chuyển lỗi sang trạng thái confirmed và yêu cầu nhân viên kiểm thử
bổ sung thêm thông tin Nếu thấy lỗi không thuộc phạm vi phát triển của dự
án trong giai đoạn hiện tại thì chuyển lỗi về trạng thái Next
o Quản lý dự án xem xét lại các lỗi có trạng thái New hoặc Assigned, nếu thấy
là lỗi nhưng có thể chấp nhận được thì chuyển lỗi sang trạng thái Accepted
và nêu rõ nguyên nhân đưa lỗi về trạng thái Accepted
Bước 4: Xử lí lỗi
Trang 14Nhân viên phát triển xem xét các lỗi được gán cho mình:
- Nếu thấy đúng là lỗi và đã mô tả rõ ràng, đầy đủ thông tin, nhân viên phát triển thực hiện sửa lỗi và chuyển lỗi về trạng thái Resolved, đồng thời bắt buộc nêu rõ hướng giải quyết và các chức năng bị ảnh hưởng trong phần Notes
- Các trường hợp khác: Nếu thấy không phải là lỗi của hệ thống, nhân viên phát triển sẽ yêu cầu nhân viên kiểm thử bổ sung thêm thông tin, hoặc thấy là lỗi nhưng có thể chấp nhận được lỗi thì nhân viên phát triển chuyển lỗi sang trạng thái Confirmed và nêu rõ lí do chuyển lỗi
Bước 5: Kiểm thử lại
Theo phân công của trưởng nhóm kiểm thử, nhân viên kiểm thử thực hiện kiểm thử lại các chức năng có lỗi ở trạng thái Resolved:
- Nếu có lỗi đã được sử thì chuyển đổi về trạng thái Closed
- Nếu lỗi chưa được sửa hoặc mới chỉ sửa một phần thì chuyển lỗi về trạng thái Assigned và nêu rõ những phần chức năng nào chưa hoàn chỉnh để nhân viên phát triển tiến hành sửa tiếp
- Nếu thấy có thể chấp nhận lỗi thì chuyển lỗi về trạng thái Accepted Đồng thời khi cập nhật kịch bản kiểm thử thì sẽ để kết quả của trường hợp đó là lỗi
- Nếu phần chức năng bị ảnh hưởng gây ra lỗi mới thì đưa một lỗi mới lên phần mềm quản lí lỗi
Bước 6: Đóng lỗi
1.5.4 Chi phí cho việc sửa lỗi phần mềm
Kiểm thử và sửa lỗi phần mềm có thể thực hiện trong bất cứ giai đoạn nào của quy trình phát triển phần mềm Tuy nhiên công việc này nên được thực hiện càng sớm càng tốt vì càng để về các giai đoạn sau, chi phí cho sửa lỗi sẽ trở nên rất lớn và ảnh hưởng đến uy tín của tổ chức phát triển phần mềm Càng để về sau chi phí để sửa lỗi càng tăng
Kết luận:
Chương I của đồ án đã trình bày được định nghĩa và những vấn đề cơ bản xung quanh phần mềm, lỗi phần mềm
Trang 15- Các định nghĩa phần mềm, quy trình phát triển phần mềm, chất lượng phần mềm.
- Các vấn đề liên quan đến lỗi phần mềm và quy trình xử lí lỗi phần mềm
Chương II: Khái quát về kiểm thử phần mềm
• Khái niệm kiểm thử phần mềm
• Các nguyên tắc cơ bản kiểm thử phần mềm
Có rất nhiều định nghĩa về kiểm thử phần mềm, sau đây là một vài ví dụ:
Kiểm thử phần mềm là quy trình chứng minh phần mềm không có lỗi
Kiểm thử phần mềm là quy trình thiết lập sự tin tưởng về việc phần mềm hay hệ thống thực hiện được điều mà hỗ trợ
Kiểm thử phần mềm có thể nói là quá trình phê chuẩn và xác minh rằng một chương trình, máy tính, ứng dụng, sản phẩm đáp ứng được mong đợi, đáp ứng được các nhu cầu của các bên liên quan
2.2 Mục tiêu 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ó
Trang 16- Tiến hành sửa lỗi ở các phần mềm được kiểm thử và kiểm thử lại cho đến khi đạt được mức độ chất lượng phần mềm như mong đợi.
- Tạo các kịch bản kiểm tra 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
- Thực thi kiểm thử với chi phí và nổ lực tối thiểu
Kiểm thử phần mềm tốn nhiều chi phí nhân công, thời gian Kiểm thử có thể tiêu hao lên đến 50% tổng giá trị phát triển phần mềm Do đó một trong các mục tiêu của kiểm thử là tự động hóa nhiều nhất có thể, nhờ vậy có thể giảm thiểu chi phí rất nhiều
và tối thiểu hóa các lỗi do con người gây ra, giúp kiểm thử hồi qui dễ dàng và nhanh chóng hơn
2.3 Các nguyên tắc cơ bản của kiểm thử phần mềm
Có 7 nguyên tắc chính cần chú ý khi kiểm thử phần mềm:
- Nguyên tắc 1: Kiểm thử phần mềm để chứng minh sự có mặt của lỗi và không chứng minh điều ngược lại.
Kiểm thử có thể cho thấy sự có mặt của lỗi nhưng không thể chứng minh chương trình không có lỗi Việc kiểm thử sẽ giảm nguy cơ không tìm thấy lỗi trong phần mềm nhưng kể cả khi không tìm thấy lỗi thì cũng không thể chứng minh được phần mềm phát triển chính xác
- Nguyên tắc 2: Kiểm thử hết tất cả là không thể
Kiểm thử mọi thứ là không thể thực hiện được Thay vì kiểm thử toàn bộ, chúng ta nên dựa trên mức độ ưu tiên, tập trung vào vấn đề dễ rủi ro nhất để kiểm thử
- Nguyên tắc 3: Kiểm thử sớm
Để tìm được lỗi sớm, các hoạt động kiểm thử nên bắt đầu càng sớm càng tốt trong quy trình phát triển phần mềm, nên tập trung vào hoạt động đã có kế hoạch 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à mật độ lỗi và lỗi phát hiện ra sau
đó trong các module Một số ít các module thường chứa nhiều lỗi không phát hiện ra
Trang 17trong lúc kiểm thử trước khi phát hành 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: Kiểm thử ngược
Nếu một phương pháp kiểm thử được lặp đi lặp lại nhiều lần, các trường hợp kiểm thử giống nhau sẽ không phát hiện triệt để lỗi mới Để khắc phục điều này có thể sử dụng nguyên tắc kiểm thử ngược Các trường hợp kiểm thử cần được xem xét và sửa đổi thường xuyên, cần phải viết các kịch bản kiểm thử khác nhau thực hiện nhiều lần
để tìm ra lỗi tiềm ẩn
- Nguyên tắc thứ 6: Kiểm thử theo ngữ cảnh
Nguyên tắc kiểm thử này là việc kiểm thử phụ thuộc vào ngữ cảnh, kiểm thử trong nhiều ngữ cảnh khác nhau thì khác nhau
- Nguyên tắc thứ 7: Sai lầm về việc không có lỗi
Việc tìm và sửa lỗi 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à đáp ứng được nhu cầu, sự mong đợi của người dùng
2.4 Quy trình kiểm thử phần mềm
2.4.1 Định nghĩa
Để thực hiện kiểm thử hiệu quả phải cần có chiến lược kiểm thử, cần nhận dạng cái
gì là quan trọng đối với tổ chức (chi phí, chất lượng, thời gian, phạm vi…) và cách nào, bởi ai và khi nào việc kiểm thử sẽ được thực hiện Tất cả các thông tin trên sẽ được lập thành tài liệu cho hoạt động kiểm thử và ta có thể gọi là quy trình tạo lập tài liệu này là quy trình kiểm thử phần mềm
Tại sao cần phải thực hiện quy trình kiểm thử phần mềm?
Cần làm rõ vai trò và trách nhiệm của việc kiểm thử phần mềm
Cần làm rõ các công đoạn, các bước kiểm thử
Trang 18Cần phải hiểu và phân biệt các tính chất kiểm thử (tại sao phải kiểm thử), các bước kiểm thử và các kỹ thuật kiểm thử (kiểm thử bằng cách nào).
2.4.2 Quy trình kiểm thử phần mềm
Tùy thuộc vào từng tổ chức, hệ thống, ngữ cảnh, mức độ rủi ro của phần mềm mà quy trình có thể có nhiều bước khác nhau Tuy nhiên nhìn chung mọi quy trình kiểm thử đều có những bước cơ bản như quy trình dưới đây:
Hình 2 Quy trình kiểm thử phần mềm
Theo như hình trên thì một quy trình kiểm thử phần mềm gồm có 4 giai đoạn:
- Lập kế hoạch kiểm thử: Trong quá trình lập kế hoạch kiểm thử cần xác định được các yếu tố sau:
• Phương pháp kiểm thử
• Công cụ kiểm thử
• Giai đoạn kiểm thử áp dụng cho dự án
• Nguồn nhân lực kiểm thử
• Môi trường kiểm thử
• Thời gian bàn giao các tài liệu kiểm thử
- Chuẩn bị kiểm thử: Nhiệm vụ của giai đoạn này bao gồm:
• Tìm hiểu thông tin, nghiệp vụ của hệ thống cần kiểm thử
• Xây dựng kịch bản kiểm thử, người kiểm thử, phát triển các thủ tục
• Chuẩn bị dữ liệu kiểm thử
• Xem xét, phê duyệt các tài liệu kiểm thử
- Thực thi kiểm thử
• Thực thi kiểm thử dựa trên kế hoạch, kịch bản kiểm thử, thủ tục, dữ liệu
đã có sẵn, chuẩn bị trước khi kiểm thử
Trang 19• Quan sát quá trình quản lý lỗi, báo cáo lỗi, sửa lỗi.
- Báo cáo phân tích dữ liệu kiểm thử
• Báo cáo kiểm thử
• Phân tích đánh giá, đề xuất các phương pháp khắc phục để bớt sai sót lỗi Quy trình này sẽ được lặp đi lặp lại trong việc kiểm thử phần mềm
- Mục đích của chiến lược kiểm thử này là tìm kiếm các trường hợp mà chương trình không thực hiện theo các đặc tả của nó
Quy trình kiểm thử hộp đen tổng quát
o Phân tích đặc tả về các yêu cầu chức năng mà thành phần phần mềm cần thực hiện
o Dùng một kỹ thuật định nghĩa các test case xác định Định nghĩa mỗi test case là xác định 3 thông tin sau:
• Giá trị dữ liệu nhập để thành phần phần mềm xử lý (hợp lệ hoặc không hợp lệ)
• Trạng thái của thành phần phần mềm cần có để thực hiện test case
• Giá trị dữ liệu xuất mà thành phần phần mềm phải tạo được
o Kiểm thử các test case đã định nghĩa
o So sánh kết quả thu được với kết quả kỳ vọng trong từng test case, từ
đó lập báo cáo về kết quả kiểm thử
Các kỹ thuật ứng dụng
Trang 20Vì chiến lược kiểm thử hộp đen thích hợp cho mọi mức độ kiểm thử nên nhiều người đã nghiên cứu tìm hiểu và đưa ra nhiều kỹ thuật kiểm thử khác nhau, sau đây là một vài kỹ thuật kiểm thử được ứng dụng nhiều nhất:
o Kỹ thuật phân lớp tương đương
o Kỹ thuật phân tích các giá trị biên
o Kỹ thuật dùng các bảng quyết định
o Kỹ thuật dùng bảng chuyển trạng thái
o Kỹ thuật phân tích vùng miền
o Kỹ thuật dùng lược đồ quan hệ nhân quả
Ưu, nhược điểm của kiểm thử hộp đen
- Ưu điểm: Người kiểm thử không cần kiến thức thực hiện, bao gồm cả ngôn ngữ lập trình cụ thể, người kiểm thử thực hiện kiểm thử trên quan điểm của người dùng, có thể phát hiện sự không thống nhất trong các đặc tả chức năng
- Nhược điểm: Kiểm thử mò do người kiểm thử không biết thực sự chương trình xây dựng như thế nào, không thể kiểm thử được hết tất cả
2.5.2 Kiểm thử hộp trắng (White Box Testing)
Định nghĩa:
Kiểm thử hộp trắng hay còn gọi là kiểm thử cấu trúc, là kỹ thuật cho phép khảo sát kiến trúc bên trong của chương trình Kiểm thử hộp trắng kiểm nghiệm một chương trình (một phần chương trình, hay một hệ thống, một thành thành hệ thống) đáp ứng tất
cả các giá trị đầu vào bao gồm các giá trị không đúng hay không theo dự định của chương trình Chiến lược này xuất phát từ dữ liệu kiểm thử tính logic của chương trình Kiểm thử viên sẽ truy cập vào cấu trúc dữ liệu và giải thuật bên trong chương trình
Đặc điểm
o Dựa vào thuật toán cụ thể, cấu trúc dữ liệu bên trong của đơn vị phần mềm cần kiểm thử để xác định xem đơn vị phần mềm đó có thực hiện đúng không
o Kiểm thử viên phải có kỹ năng, kiến thức nhất định để có thể hiểu chi tiết và đoạn code cần kiểm thử
o Tốn nhiều thời gian và công sức nếu mức độ kiểm thử được nâng lên
ở cấp kiểm thử tích hợp hay kiểm thử hệ thống
o Kỹ thuật này chủ yếu dùng để kiểm thử đơn vị
Trang 21 Ưu, nhược điểm của kiểm thử hộp trắng
- Ưu điểm
• Kiểm tra được toàn bộ chương trình nguồn
• Phát hiện lỗi tại chỗ
• Tự động hóa kiểm thử
- Nhược điểm
• Yêu cầu kiểm thử viên phải hiểu biết cấu trúc mã lệnh chương trình, do đó đòi hỏi nhân lực cao
• Có khả năng tồn tại các tổ hợp lệnh khác nhau gây lỗi
• Không kiểm thử hết đường đi với các vòng lặp lớn, phức tạp
• Kho thực hiện và chi phí thực hiện cao
2.5.3 Kiểm thử hộp xám (Gray Box Testing)
- Kiểm thử hộp xám là phương pháp kiểm thử phần mềm được kết hợp giữa kiểm thử hộp đen và kiểm thử hộp trắng Trong đó cũng quan tâm đến dữ liệu đầu vào
và đầu ra giống như trong kiểm thử hộp đen, song cũng đòi hỏi truy cập đến cấu trúc dữ liệu và giải thuật để thiết kế các trường hợp kiểm thử
- Phương pháp kiểm thử hộp xám có thể ứng dụng vào nhiều mức kiểm tra khác nhau nhưng sử dụng chủ yếu trong kiểm thử tích hợp
2.6 Các giai đoạn kiểm thử
Có 5 giai đoạn kiểm thử chính:
và phân tích kết quả, nếu phát hiện ra lỗi và sửa lỗi cũng đơn giản, tốn ít thời gian, chi phí Kiểm thử đơn vị thường do các lập trình viên thực hiện, công đoạn này cần được thực hiện càng sớm càng tốt, và thường xuyên kiểm tra trong giai đoạn viết code và phát triển phần mềm
- Mục đích: Đảm bảo thông tin được xử lí đúng và có đầu ra chính xác trong môi tương quan giữa dữ liệu nhập và chức năng của đơn vị
Trang 22- Người thực hiện kiểm thử: Việc kiểm thử đơn vị đòi hỏi kiểm tra từng nhánh lệnh nên người kiểm thử cần có kiến thức lập trình cũng như thiết kế hệ thống nên thường người kiểm tra là lập trình viên.
2.6.2 Kiểm thử tích hợp
- Kiểm thử tích hợp là kiểm thử sự kết hợp giữa các module của một chương tình cùng thực hiện một công việc có đạt được kết quả như tài liệu yêu cầu hay không
- Mục đích:
• Phát hiện lỗi giao tiếp xảy ra giữa các đơn vị cũng như lỗi từng đơn vị
• Tích hợp các đơn vị lẻ thành các hệ thống nhỏ, tích hợp các hệ thống nhỏ thành một hệ thống hoàn chỉnh để chuẩn bị cho kiểm thử hệ thống
Trong giai đoạn kiểm thử tích hợp chỉ nên thực hiện trên từng đơn vị đã được kiểm tra cẩn thận trước đó bằng kiểm thử đơn vị và tất cả các lỗi mức đơn vị đã được sửa chữa và nên tích hợp dần từng đơn vị
• Kiểm thử hiệu năng
• Kiểm thử an toàn thông tin
- Mục đích: Kiểm tra toàn bộ hệ thống được làm ra có thỏa mãn yêu cầu hay không như: hoạt động, độ tin cậy, hiệu năng của hệ thống
Việc lập kế hoạch kiểm tra hệ thống nên bắt đầu từ những giai đoạn mới bắt đầu
Trang 23Kiểm thử giao diện là việc kiểm tra sự tương tác của người dùng với phần mềm Mục tiêu của việc kiểm thử giao diện là để đảm bảo rằng giao diện người dùng cung cấp cho người sử dụng cách truy cập và sử dụng các chức năng của hệ thống một cách phù hợp, đảm bảo các đối tượng trên giao diện giống như thiết kế Việc sử dụng thông qua mục tiêu kiểm thử phản ánh đúng các chức năng và yêu cầu nghiệp vụ, bao gồm màn hình đến màn hình và sử dụng các phương pháp truy cập.
Kiểm thử luồng nghiệp vụ
Kiểm thử luồng nghiệp vụ là kiểm tra các yêu cầu chức năng và nghiệp vụ hệ thống bao gồm các hoạt động để kiểm tra tính đúng đắn của dữ liệu, quy trình, báo cáo
và thực hiện đúng những quy tắc nghiệp vụ Kiểm thử luồng nghiệp vụ dựa trên kỹ thuật kiểm thử hộp đen, kiểm tra ứng dụng và các xử lí Đảm bảo mục tiêu kiểm thử đúng đắn của chức năng bao gồm: dữ liệu đầu vào, xử lí dữ liệu và dữ liệu nhận được
2.6.3.2 Kiểm thử hiệu năng
Kiểm thử hiệu năng thường được thực hiện để xác định một hệ thống hay hệ thống thực hiện về một hoạt động ổn định theo một khối lượng công việc cụ thể Nó cũng có thể phục vụ để điều tra, đánh giá, xác nhận hoặc xác minh các thuộc tính chất lượng khác của hệ thống, chẳng hạn như khả năng mở rộng, độ tin cậy và sử dụng tài nguyên
2.6.3.3 Kiểm thử an toàn thông tin
Kiểm thử an toàn thông tin tập trung vào hai lĩnh vực bảo mật chính:
- Bảo mật ở mức ứng dụng: Bao gồm truy cập dữ liệu và các chức năng nghiệp vụ
- Bảo mật ở mức hệ thống: Bao gồm truy cập vào hệ thống hoặc truy cập từ xa.Bảo mật mức ứng dụng đảm bảo rằng, dựa trên bảo mật đã yêu cầu, người dùng bị hạn chế sử dụng một số chức năng hoặc tình huống sử dụng, hoặc bị hạn chế trong giới hạn dữ liệu phù hợp với họ Bảo mật mức hệ thống đảm bảo rằng chỉ những người dùng được cho quyền truy cập vào hệ thống mới có khả năng truy cập vào ứng dụng
Trang 242.6.4 Kiểm thử hồi quy
- Kiểm thử hồi quy là hoạt động trợ giúp để đảm bảo rằng các thay đổi không đưa
ra những hành vi hoặc những lỗi bổ sung không mong đợi
- Kiểm thử hồi quy tập trung vào việc tìm kiếm lỗi sau khi một thay đổi mã lớn đã xảy ra Cụ thể, nó tìm cách khám phá hồi quy phần mềm, hoặc lỗi cũ đã quay trở lại Khi một chức năng mới được thêm vào phần mềm, cần chắc chắn rằng phần chức năng mới được thêm vào không phá hỏng các phần khác của ứng dụng Hoặc khi lỗi đã được chỉnh sửa, chúng ta cần chắc chắn rằng lỗi chỉnh sửa không phá hỏng các phần khác trong ứng dụng
- Kiểm thử hồi quy là một trong những loại kiểm thử tốn nhiều thời gian và công sức nhất Tuy nhiên, việc bỏ qua kiểm thử hồi quy là điều không thể vì có thể dẫn đến tình trạng phát sinh hoặc tái xuất hiện những lỗi nghiêm trọng
2.6.5 Kiểm thử chấp nhận
- Mục đích: Kiểm thử chấp nhận còn gọi là kiểm thử nghiệm thu nhằm mục đích phần mềm thỏa mãn tất cả yêu cầu của khách hàng và khách hàng đã chấp nhận sản phẩm Người thực hiện kiểm thử chấp nhận chính là khách hàng
- Có 2 phương pháp kiểm thử chấp nhận: Kiểm thử alpha và kiểm thử beta
• Kiểm thử Alpha
Khách hàng kiểm thử phần mềm ngay tại nơi phát triển phần mềm dưới sự hỗ trợ của nhân viên kiểm thử, nhân viên kiểm thử ghi nhận lỗi hoặc phản hồi của khách hàng và báo cáo lại với đơn vị phát triển phần mềm để lên kế hoạch sữa chữa
• Kiểm thử Beta
Phần mềm sẽ được gửi tới khách hàng để kiểm thử trong môi trường thực Nếu
có lỗi và phản hồi sẽ gửi lại cho đơn vị phát triển phần mềm để lên kế hoạch sữa chữa
2.7 Kiểm thử tự động
2.7.1 Định nghĩa
Kiểm thử tự động phương pháp sử dụng phần mềm hay các công cụ để xử lý tự động các bước thực hiện test case mà không cần sự can thiệp của con người Trong kiểm thử tự động, phần mềm phải được biên dịch và chạy thực sự
Trang 25Mục tiêu của kiểm thử tự động:
- Tăng độ tin cậy
- Giảm bớt được thời gian, công sức, chi phí thực hiện kiểm thử
- Rèn luyện kỹ năng lập trình cho tester
2.7.2 Quy trình kiểm thử tự động
Quy trình kiểm thử phần mềm bao gồm 4 bước thực hiện:
- Bước 1: Lên kế hoạch, viết kịch bản kiểm thử, dùng công cụ 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 test script
- Bước 2: Chỉnh sửa để kịch bản kiểm thử được thực hiện kiểm tra theo đúng yêu cầu đặt ra, làm theo các trường hợp kiểm thử cần thực hiện
- Bước 3: Chạy kịch bản kiểm thử, giám sát hoạt động kiểm tra phần mềm theo kịch bản
- Bươc 4: Kiểm tra kết quả thông báo sau khi thực hiện kiểm thử tự động Bổ sung và chỉnh sửa những sai sót
2.7.3 Ưu điểm, nhược điểm của kiểm thử tự động
- Ưu điểm:
• Không cần đến sự can thiệp của kiểm thử viên
• Giảm chi phí, thời gian, công sức khi kiểm thử
• Giả lập tình huống khó có thể thực hiện bằng tay
• Hiệu năng của kiểm thử các lớp vượt xa tầm với của kiểm thử thủ công
- Nhược điểm:
• Mất chi phí tạo các script, bảo trì script để thực hiện kiểm thử tự động
• Đòi hỏi kiểm thử viên phải có kỹ năng tạo các script kiểm thử tự động
• Không áp dụng được trong việc tìm lỗi mới của phần mềm
• Chi phí cao cho việc chuyển giao công nghệ và đào tạo nhân viên
• Khu vực kiểm thử tự động có thể không bao quát đầy đủ, không áp dụng được trong việc tìm lỗi mới của phần mềm
2.7.4 Các trường hợp áp dụng kiểm thử tự động
Việc kiểm thử phần mềm không phải lúc nào cũng nên áp dụng kiểm thử tự động bởi vì nhiều khi chi phí, thời gian cho việc kiểm thử tự động còn lớn hơn nhiều so với kiểm thử thủ công Sau đây là một số trường hợp nên áp dụng phương pháp kiểm thử
tự động để đạt được hiệu quả cao hơn về thời gian, chi phí, chất lượng cho sản phẩm
- Trường hợp kiểm thử hồi qui: Trong quá trình phát triển phần mềm, người lập trình đưa ra rất nhiều bản phần mềm liên tiếp để kiểm thử Mỗi phiên bản bao
Trang 26gồm tính năng mới, hoặc tính năng cũ được sửa đổi, cập nhật, nâng cấp Việc bổ sung hoặc sửa lỗi cho những tính ở phiên bản mới có thể làm cho những tính năng khác đã kiểm tra tốt chạy sai mặc dù mã của chương trình không hề chỉnh sửa Để khắc phục điều này, đối với từng phiên bản, kiểm thử viên không chỉ kiểm tra chức năng mới hoặc được sửa, mà phải kiểm tra lại tất cả những tính năng mà đã kiểm tra trước đó Điều này khó khả thi về mặt thời gian nếu kiểm thử thủ công.
- Trường hợp không đủ tài nguyên: Khi số lượng trường hợp kiểm thử lặp lại quá trình trên nhiều môi trường để kiểm thử khác nhau, không có đủ nguồn nhân lực
để kiểm thử thủ công trong một giới hạn nào đó
- Trường hợp kiểm thử khả năng vận hành phần mềm trong môi trường đặc biệt: Đây là kiểm thử đánh giá xem vận hành của phần mềm có thỏa mãn yêu cầu đặt
ra hay không Thông qua đó mà kiểm thử viên có thể xác định được các yếu tố
về phần cứng, phần mềm ảnh hưởng đến khả năng vận hành của hệ thống Ví dụ một số tình huống như sau:
• Đ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 được xử lí bở web server hoặc xác định cấu hình máy thấp nhất mà tốc độ xử lý của phần mềm có thể hoạt động ở mức cho phép
Kết luận:
Chương II của đồ án đã trình bày các vấn đề cơ bản của kiểm thử phần mềm, các vấn đề chính được trình bày bao gồm:
- Một số định nghĩa của kiểm thử phần mềm
- Mục tiêu của kiểm thử phần mềm
- Các nguyên tắc cơ bản của kiểm thử phần mềm
- Quy trình, kỹ thuật kiểm thử phần mềm
- Các phương pháp kiểm thử phần mềm
- Các giai đoạn kiểm thử phần mềm, giới thiệu về kiểm thử tự động
Trang 27Chương III: Kiểm thử ứng dụng web và công cụ kiểm thử
tự động Selenium
• Khái niệm về kiểm thử ứng dụng web
• Mục đích của kiểm thử web
• Tổng quan về công cụ Slenenium
• Hướng dẫn sử dụng và cài đặt Selenium IDE
3.1 Kiểm thử ứng dụng web
3.1.1 Khái niệm
Kiểm thử website là một thành phần trong kiểm thử phần mềm tập trung vào ứng dụng web, là một trong những thành phần đang phát triển nhanh nhất của kiểm thử phần mềm