Nghiên Cứu Các Giải Pháp Kiểm Thử Ứng Dụng Trên Nền Web Trong Luận Văn Thạc Sĩ

Luận văn thạc sĩ, đồ án tốt nghiệp nghiên cứu giải pháp kiểm thử ứng dụng web, đảm bảo chất lượng và hiệu quả trong phát triển phần mềm.

• Tác giả: Phạm Thị Ngà
• Người hướng dẫn: TS. Đinh Tuấn Long
• Trường học: Đại học Hà Nội
• Chuyên ngành: Công nghệ thông tin
• Đề tài: Nghiên cứu các giải pháp kiểm thử ứng dụng trên nền web
• Loại tài liệu: đồ án tốt nghiệp
• Năm xuất bản: 2015
• Địa điểm: Hà Nội

Mục lục chi tiết

• LỜI NÓI ĐẦU
• 1. CHƯƠNG 1: CƠ SỞ LÝ THUYẾT
• 1.1. Một số định nghĩa về quá trình kiểm thử
• 1.2. Một số định nghĩa về quá trình kiểm thử phần mềm
• 1.3. Mục tiêu của kiểm thử
• 1.4. Vai trò của kiểm thử
• 2. CHƯƠNG 2: NHỮNG VẤN ĐỀ LIÊN QUAN TỚI QUÁ TRÌNH KIỂM THỬ PHẦN MỀM
• 2.1. Vòng đời kiểm thử
• 2.2. Tiến trình test và các dạng test trong các giai đoạn
• 2.3. Những thành phần của một kế hoạch kiểm thử
• 3. CHƯƠNG 3: PHƯƠNG PHÁP VÀ CÁC LOẠI KIỂM THỬ
• 3.1. Phương pháp kiểm thử
• 3.2. Các phương pháp
• 3.3. Loại kiểm thử
• 3.4. Tìm hiểu về công cụ kiểm thử hiệu năng (webserver stress tool)
• 3.5. Một số công cụ kiểm thử hiệu năng
• 3.6. Đối tượng thực nghiệm
• 4. CHƯƠNG 4: TRIỂN KHAI THỰC NGHIỆM VỚI KIỂM THỬ
• 4.1. Đối tượng kiểm thử
• 4.2. Tìm hiểu về ERP
• 4.3. Các loại report trong dự án Team link
• 4.4. Cách viết test case theo hàng ngang
• 4.5. Cách viết test case theo hàng dọc
• TÀI LIỆU THAM KHẢO

Tóm tắt

I. Giới thiệu về kiểm thử ứng dụng web

Kiểm thử ứng dụng web là một phần quan trọng trong quy trình phát triển phần mềm. Giải pháp kiểm thử ứng dụng web không chỉ giúp phát hiện lỗi mà còn đảm bảo rằng phần mềm đáp ứng được yêu cầu của người dùng. Kiểm thử ứng dụng web bao gồm nhiều phương pháp và công cụ khác nhau, từ kiểm thử chức năng đến kiểm thử hiệu năng. Việc áp dụng các giải pháp kiểm thử hiệu quả sẽ giúp giảm thiểu rủi ro và nâng cao chất lượng sản phẩm. Theo Dijkstra, kiểm thử không chỉ là việc phát hiện lỗi mà còn là một quá trình để đảm bảo rằng phần mềm hoạt động như mong đợi.

1.1. Mục tiêu của kiểm thử ứng dụng web

Mục tiêu chính của kiểm thử ứng dụng web là phát hiện và sửa chữa lỗi trước khi sản phẩm được phát hành. Điều này bao gồm việc kiểm tra các chức năng của ứng dụng, đảm bảo rằng chúng hoạt động đúng theo yêu cầu. Kiểm thử hiệu suất cũng là một phần quan trọng, giúp đánh giá khả năng xử lý của ứng dụng dưới tải cao. Theo Myers, việc kiểm thử thành công là khi ít nhất một lỗi được phát hiện và sửa chữa, từ đó nâng cao chất lượng phần mềm.

1.2. Vai trò của kiểm thử trong phát triển phần mềm

Kiểm thử đóng vai trò quan trọng trong việc đảm bảo chất lượng phần mềm. Nó giúp phát hiện các lỗi tiềm ẩn và đảm bảo rằng phần mềm hoạt động đúng như mong đợi. Kiểm thử bảo mật cũng là một yếu tố không thể thiếu, đặc biệt trong bối cảnh ngày càng nhiều ứng dụng web bị tấn công. Việc thực hiện kiểm thử định kỳ sẽ giúp phát hiện sớm các vấn đề và giảm thiểu rủi ro cho người dùng.

II. Các phương pháp kiểm thử ứng dụng web

Có nhiều phương pháp kiểm thử ứng dụng web, mỗi phương pháp có những ưu điểm và nhược điểm riêng. Kiểm thử tự động là một trong những phương pháp phổ biến, giúp tiết kiệm thời gian và công sức. Các công cụ như Selenium hay JMeter thường được sử dụng để thực hiện kiểm thử tự động. Ngoài ra, kiểm thử thủ công cũng rất quan trọng, đặc biệt trong việc kiểm tra giao diện người dùng và trải nghiệm người dùng. Theo Beizer, việc kết hợp cả hai phương pháp này sẽ mang lại hiệu quả cao nhất trong việc phát hiện lỗi.

2.1. Kiểm thử tự động

Kiểm thử tự động giúp giảm thiểu thời gian và công sức cần thiết để thực hiện kiểm thử. Các công cụ như Selenium cho phép kiểm thử viên tự động hóa các kịch bản kiểm thử, từ đó tăng cường khả năng phát hiện lỗi. Kiểm thử hiệu suất cũng có thể được thực hiện tự động, giúp đánh giá khả năng xử lý của ứng dụng dưới tải cao. Việc sử dụng kiểm thử tự động không chỉ giúp tiết kiệm thời gian mà còn đảm bảo tính chính xác trong quá trình kiểm thử.

2.2. Kiểm thử thủ công

Kiểm thử thủ công vẫn giữ vai trò quan trọng trong quy trình kiểm thử ứng dụng web. Nó cho phép kiểm thử viên đánh giá trải nghiệm người dùng và phát hiện các vấn đề mà kiểm thử tự động có thể bỏ sót. Kiểm thử giao diện người dùng là một ví dụ điển hình, nơi mà cảm nhận và phản hồi của người dùng là rất quan trọng. Theo IEEE, kiểm thử thủ công giúp đảm bảo rằng phần mềm không chỉ hoạt động đúng mà còn mang lại trải nghiệm tốt cho người dùng.

III. Quy trình kiểm thử ứng dụng web

Quy trình kiểm thử ứng dụng web bao gồm nhiều bước từ lập kế hoạch đến thực hiện và đánh giá kết quả. Quy trình kiểm thử cần được thực hiện một cách có hệ thống để đảm bảo rằng tất cả các khía cạnh của ứng dụng đều được kiểm tra. Bắt đầu từ việc xác định yêu cầu, lập kế hoạch kiểm thử, thiết kế các kịch bản kiểm thử, thực hiện kiểm thử và cuối cùng là đánh giá kết quả. Việc thực hiện quy trình này một cách chặt chẽ sẽ giúp phát hiện lỗi sớm và giảm thiểu rủi ro cho sản phẩm.

3.1. Lập kế hoạch kiểm thử

Lập kế hoạch kiểm thử là bước đầu tiên và rất quan trọng trong quy trình kiểm thử. Nó bao gồm việc xác định các yêu cầu cần kiểm thử, lập danh sách các kịch bản kiểm thử và phân bổ nguồn lực. Kế hoạch kiểm thử cần phải rõ ràng và chi tiết để đảm bảo rằng tất cả các khía cạnh của ứng dụng đều được kiểm tra. Việc lập kế hoạch tốt sẽ giúp tiết kiệm thời gian và công sức trong các bước tiếp theo.

3.2. Thực hiện kiểm thử

Sau khi lập kế hoạch, bước tiếp theo là thực hiện kiểm thử. Kiểm thử viên sẽ tiến hành kiểm tra các chức năng của ứng dụng theo các kịch bản đã được thiết kế. Kiểm thử hiệu suất và kiểm thử bảo mật cũng cần được thực hiện trong giai đoạn này. Kết quả kiểm thử sẽ được ghi nhận và đánh giá để xác định xem ứng dụng có đáp ứng được yêu cầu hay không. Việc thực hiện kiểm thử một cách cẩn thận sẽ giúp phát hiện sớm các vấn đề và giảm thiểu rủi ro cho sản phẩm.

IV. Đánh giá kết quả kiểm thử

Đánh giá kết quả kiểm thử là bước cuối cùng trong quy trình kiểm thử ứng dụng web. Kết quả kiểm thử cần được phân tích để xác định các lỗi đã phát hiện và mức độ nghiêm trọng của chúng. Đánh giá hiệu quả kiểm thử không chỉ giúp cải thiện quy trình kiểm thử mà còn cung cấp thông tin quý giá cho các giai đoạn phát triển tiếp theo. Việc đánh giá cần được thực hiện một cách khách quan và dựa trên các tiêu chí đã được xác định trước đó.

4.1. Phân tích kết quả kiểm thử

Phân tích kết quả kiểm thử giúp xác định các lỗi đã phát hiện và mức độ nghiêm trọng của chúng. Các lỗi cần được phân loại theo mức độ ảnh hưởng đến người dùng và ứng dụng. Đánh giá hiệu quả kiểm thử cũng cần xem xét các kịch bản kiểm thử đã thực hiện và xác định xem có cần điều chỉnh hay bổ sung gì không. Việc phân tích kết quả một cách chi tiết sẽ giúp cải thiện quy trình kiểm thử trong tương lai.

4.2. Cải tiến quy trình kiểm thử

Dựa trên kết quả phân tích, quy trình kiểm thử cần được cải tiến để nâng cao hiệu quả. Việc điều chỉnh các kịch bản kiểm thử, cập nhật công cụ kiểm thử và đào tạo kiểm thử viên là những bước cần thiết để nâng cao chất lượng kiểm thử. Cải tiến quy trình kiểm thử không chỉ giúp phát hiện lỗi sớm mà còn nâng cao chất lượng sản phẩm cuối cùng. Theo Hetzel, việc cải tiến quy trình kiểm thử là một phần quan trọng trong việc đảm bảo chất lượng phần mềm.

Nội dung chính

Bối cảnh và vấn đề nghiên cứu

Sự phát triển của công nghệ website trên nền tảng Internet đã tạo ra phương thức liên kết dữ liệu quy mô lớn, cho phép các ứng dụng độc lập về hệ điều hành hoặc chia sẻ cùng ngôn ngữ có thể trao đổi thông tin thông suốt qua môi trường mạng. Tuy nhiên, kiến trúc phân tán, tính chất liên kết phức tạp, sự phụ thuộc vào các dịch vụ bên ngoài và việc thiếu hụt quy trình thử nghiệm toàn diện đặt ra những thách thức lớn đối với quá trình phát triển ứng dụng web. Lỗi phần mềm là nguyên nhân trực tiếp làm giảm năng suất, dẫn đến các sai sót thực thi, lỗ hổng bảo mật, sai lệch chức năng hoặc sụp đổ toàn bộ hệ thống. Chi phí và thời gian khắc phục khiếm khuyết tăng theo cấp số nhân nếu lỗi chỉ được phát hiện ở các giai đoạn muộn trong vòng đời phần mềm. Xuất phát từ thực tiễn đào tạo chuyên ngành và yêu cầu bảo đảm độ tin cậy của phần mềm, đồ án tốt nghiệp "Nghiên cứu các giải pháp kiểm thử ứng dụng trên nền web" được tác giả Phạm Thị Ngà thực hiện dưới sự hướng dẫn của TS. Đinh Tuấn Long tại Khoa Công nghệ thông tin – Viện Đại học Mở Hà Nội vào tháng 01 năm 2015.

Mục tiêu nghiên cứu của đề tài được xác định theo 4 nội dung cụ thể:

1. Tìm hiểu các kiến thức tổng quan về kiểm thử phần mềm và kỹ thuật thiết kế trường hợp kiểm thử (test case) chuyên biệt cho ứng dụng website.
2. Khảo sát các công cụ kiểm thử tự động nhằm nâng cao tốc độ và hiệu quả của tiến trình kiểm thử.
3. Vận dụng lý thuyết kỹ thuật phần mềm để thiết kế các kịch bản kiểm thử đáp ứng yêu cầu kỹ thuật và nghiệp vụ thực tế.
4. Triển khai thực nghiệm các giải pháp kiểm thử trên các đối tượng phần mềm cụ thể nhằm phát hiện khiếm khuyết hệ thống.

Đối tượng và phạm vi nghiên cứu của đồ án bao gồm:

• Đối tượng nghiên cứu: Lý thuyết kiểm thử phần mềm, quy trình kiểm thử ứng dụng web, các kỹ thuật thiết kế ca kiểm thử chức năng và công cụ kiểm thử hiệu năng/chịu tải WebServer Stress Tool.
• Phạm vi không gian: Thực nghiệm kiểm thử hiệu năng trên cổng thông tin của Khoa Công nghệ thông tin – Viện Đại học Mở Hà Nội (trang giới thiệu tại đường dẫn http://www.aspx?aid=1&cid=6) và thực nghiệm kiểm thử chức năng trên hệ thống quản trị nguồn lực doanh nghiệp (ERP - dự án Team link) cùng website thương mại điện tử giày dép, quần áo thể thao tại Công ty Cổ phần Phần mềm Hanel (Hanel Software).
• Phạm vi thời gian: Công trình được hoàn thành và bảo vệ vào ngày 28 tháng 01 năm 2015.

Cơ sở lý thuyết và phương pháp

Đồ án xây dựng nền tảng học thuật dựa trên các định nghĩa và quan điểm kinh điển về kỹ nghệ kiểm thử phần mềm:

• Quan điểm của Dijkstra: Kiểm thử chỉ có khả năng hiển thị các lỗi hiện có trong phần mềm, không thể chứng minh phần mềm hoàn toàn không còn lỗi tiềm ẩn chưa được phát hiện.
• Định luật Beizer: Định luật 1 nêu rõ mọi phương pháp ngăn ngừa hoặc tìm kiếm lỗi đều chỉ loại trừ được một phần lỗi phức tạp; Định luật 2 khẳng định độ phức tạp của phần mềm luôn vượt quá khả năng quản lý tuyệt đối, và người kiểm thử không thể thiết kế lỗi tốt hơn mức độ mà lập trình viên tạo ra trong mã nguồn.
• Định nghĩa chuẩn IEEE: Kiểm thử là tiến trình vận hành hệ thống hoặc cấu phần dưới các điều kiện xác định, thực hiện quan sát hoặc ghi nhận kết quả và đưa ra đánh giá khách quan về hệ thống.
• Quan niệm của Myers (1979) và Hetzel (1988): Myers định nghĩa kiểm thử là tiến trình thực thi chương trình với mục đích phát hiện lỗi; Hetzel nhấn mạnh mục tiêu thiết lập và bảo đảm chất lượng phần mềm.

Đồ án phân định rõ chuỗi phát sinh khiếm khuyết trong kỹ thuật phần mềm: Sai sót (Error - sự nhầm lẫn của con người trong quá trình phát triển) dẫn đến Lỗi/Khuyết tật (Fault/Defect - xuất hiện trong cấu trúc mã nguồn hoặc tài liệu), từ đó gây ra Hỏng hóc (Failure - hành vi sai lệch hoặc sự cố ngừng hoạt động của hệ thống khi vận hành). Đồng thời, tác giả chỉ rõ sự khác biệt giữa kiểm thử (testing - phát hiện và ghi nhận lỗi nhưng không sửa lỗi) và gỡ rối (debugging - xác định bản chất vị trí lỗi và sửa mã nguồn).

Về bản chất đánh giá chất lượng, đồ án phân tích hai khái niệm then chốt:

• Xác minh (Verification): Kiểm tra phần mềm có được xây dựng đúng theo thiết kế kỹ thuật hay không; chiếm 80% khối lượng công việc kiểm thử và đóng vai trò là điều kiện cần.
• Thẩm định (Validation): Kiểm tra phần mềm có đáp ứng đúng nhu cầu và mong đợi thực tế của người dùng hay không; chiếm 20% khối lượng công việc nhưng chi phối đến 80% hiệu quả tổng thể của sản phẩm, đóng vai trò là điều kiện đủ.

Về phương pháp tiếp cận kỹ thuật, tác giả tổng hợp các phương pháp kiểm thử chủ đạo:

• Kiểm thử hộp đen (Black Box Testing): Kiểm thử dựa trên đặc tả yêu cầu bên ngoài ở giao diện người dùng (front-end), không can thiệp vào cấu trúc mã nguồn bên trong.
• Kiểm thử hộp trắng (White Box Testing): Đánh giá cấu trúc nội bộ của chương trình ở cấp độ đơn vị (unit) hoặc tích hợp (integration) thông qua các kỹ thuật: kiểm thử giao diện lập trình ứng dụng (API), đo lường độ bao phủ mã (bao phủ câu lệnh đạt 100%, bao phủ chức năng), kỹ thuật chèn lỗi (fault injection), kiểm thử đột biến (mutation testing) và kiểm thử tĩnh.
• Kiểm thử hộp xám (Grey Box Testing): Kết hợp hiểu biết về thuật toán, cấu trúc dữ liệu bên trong, cơ sở dữ liệu back-end và truy vấn SQL với góc nhìn thao tác bên ngoài của người dùng nhằm thiết kế các kịch bản kiểm thử tích hợp giữa các module.
• Phân loại theo tiêu chuẩn ISTQB: Bao gồm Kiểm thử tĩnh (Static Testing - thực hiện qua hoạt động rà soát, đánh giá tài liệu phân tích thiết kế) và Kiểm thử động (Dynamic Testing - thực thi chương trình với dữ liệu đầu vào cụ thể để quan sát kết quả đầu ra).

Phương pháp nghiên cứu thực nghiệm được tiến hành thông qua việc sử dụng phần mềm WebServer Stress Tool phiên bản v7.173 để gửi các luồng yêu cầu HTTP/HTTPS đồng thời đến máy chủ web mục tiêu nhằm đo lường khả năng đáp ứng, thời gian phản hồi và thu thập mã lỗi giao thức. Nguồn dữ liệu thực nghiệm bao gồm log hệ thống của WebServer Stress Tool và tài liệu phân tích yêu cầu từ dự án thực tế tại doanh nghiệp phần mềm.

Nội dung chính theo từng chương

Chương 1: Cơ sở lý thuyết

Chương 1 tập trung chuẩn hóa hệ thống khái niệm nền tảng trong lĩnh vực kiểm thử phần mềm. Tác giả phân tích mục tiêu kiểm thử nhằm tìm ra khiếm khuyết và thiết lập chuẩn chất lượng phần mềm, đồng thời làm rõ vai trò của người kiểm thử (tester) là cung cấp dữ liệu kiểm định để đảm bảo phần mềm vận hành ở mức "đủ tốt" với "độ rủi ro thấp nhất có thể". Nội dung chương xác lập các thuật ngữ nghiệp vụ cốt lõi: dữ liệu thử (test data), kịch bản kiểm thử (test scenario), phán xét kiểm thử (test oracle - thực hiện tự động bằng phần mềm hoặc thủ công bởi con người), người kiểm thử (tester) và ca kiểm thử (test case - tập hợp dữ liệu đầu vào, điều kiện thực thi và kết quả mong đợi).

Chương 2: Những vấn đề liên quan tới quá trình kiểm thử phần mềm

Chương 2 trình bày vòng đời kiểm thử phần mềm (STLC) và các giai đoạn triển khai dự án kiểm thử:

• Vòng đời kiểm thử: Khởi đầu từ bước kiểm điểm yêu cầu (yêu cầu phải kiểm thử được; tester tham gia sớm cùng kỹ sư yêu cầu để hạn chế sự mơ hồ), lập kế hoạch kiểm thử (chuẩn bị chiến lược, lịch biểu, ước lượng thời gian), thiết kế kiểm thử (xây dựng test case, kịch bản, dữ liệu thử, thiết lập ma trận truy vết yêu cầu), thiết lập môi trường kiểm thử (bảo đảm tương thích tuyệt đối với môi trường người dùng cuối), và thực hiện kiểm thử (chạy kịch bản, ghi nhận kết quả Đạt/Hỏng và phát sinh báo cáo lỗi).
• Lập kế hoạch kiểm thử bằng Microsoft Project: Hướng dẫn 5 bước lập Test Plan dựa trên kế hoạch tổng thể (master plan), kế hoạch viết mã (code plan), năng lực nhân sự và mục tiêu chất lượng. Đồ án đưa ra ví dụ cụ thể về kế hoạch kiểm thử một website trong thời hạn 1 tháng, vận hành trên đa môi trường trình duyệt (Internet Explorer 7, 8, 9; Firefox 3.8; Chrome) và thực hiện đo lường tải/hiệu suất.

Bên cạnh đó, chương 2 phân loại các kỹ thuật kiểm thử chức năng chuyên sâu trên môi trường web theo bảng tổng hợp sau:

Kỹ thuật kiểm thử	Mục tiêu kỹ thuật	Tiêu chí và phạm vi kiểm tra cụ thể
FAST (Functional Acceptance Simple Testing)	Kiểm thử đơn giản chấp nhận chức năng; thuộc mức thứ hai của kiểm thử chấp nhận phát hành (RAT).	Bao phủ toàn bộ chức năng theo chiều rộng (không đi sâu); kiểm tra sự tồn tại và phản hồi của các điều khiển giao diện (textbox, pull-down list, radio button, phím tắt Ctrl-X, Ctrl-V, thứ tự tab); kiểm tra liên kết nội dung, thumbnail, nút điều hướng, đăng nhập, thanh toán, xử lý thư điện tử.
TOFT (Task Oriented Functional Testing)	Kiểm tra hướng tác vụ nhằm đánh giá tính đúng đắn và hữu ích của chương trình theo đặc tả.	Kiểm tra tích cực bằng cách đối chiếu hành vi phần mềm với tài liệu đặc tả sản phẩm hoặc kỳ vọng người dùng; ví dụ yêu cầu trang web phải tải xong trong thời gian 2 giây.
FET (Forced-Error Tests)	Kiểm thử lỗi ép buộc bằng cách cố ý tạo ra các điều kiện lỗi phần mềm.	Đánh giá khả năng bẫy lỗi, phục hồi dữ liệu hệ thống mà không làm sụp đổ ứng dụng; ví dụ nhập ký tự số vào trường họ tên để kiểm tra thông báo lỗi.
Kiểm thử biên và phân tích lớp tương đương	Kiểm tra các giá trị biên giới hạn của biến dữ liệu đầu vào.	Mở rộng từ TOFT và FET; ví dụ trường dữ liệu cho phép độ dài từ 2 đến 7 ký tự cần kiểm tra tại các giá trị biên: 00, 9999999, nhập 1 ký tự, nhập 8 ký tự, để trống, nhập chuỗi ký tự kết hợp.
Kiểm thử khám phá (Exploratory Testing)	Kiểm thử phi cấu trúc (unstructured testing) hoặc phi hình thức (ad hoc testing).	Đòi hỏi tư duy sáng tạo của tester; nghiên cứu, lập kế hoạch và thực thi đồng thời nhằm thực hiện các hành vi người dùng không mong đợi hoặc cố tình thao tác sai.

Chương 3: Phương pháp và các loại kiểm thử

Chương 3 đi sâu vào các cấp độ kiểm thử trong quy trình kỹ thuật phần mềm, bao gồm: Unit test (kiểm tra mã nguồn chức năng đơn vị), Shakeout test (kiểm tra kết nối mạng, tương tác giữa các module do nhóm quản lý cấu hình thực hiện trước khi đưa vào môi trường test), Smoke test (kiểm tra nhanh các chức năng chính ngay sau khi biên dịch mã nguồn), Functional test (kiểm tra chức năng chi tiết theo tài liệu đặc tả), Integration test (kiểm tra tích hợp giữa các module sau khi ráp mã nguồn), Regression test (kiểm thử hồi quy khi có tính năng mới hoặc bản vá lỗi), System test (kiểm thử toàn bộ hệ thống trên môi trường thật với dữ liệu thật), UAT (kiểm thử chấp nhận người dùng), Alpha test và Beta test.

Chương này cũng tổng hợp một danh mục khảo sát quy mô lớn gồm hơn 30 công cụ kiểm thử tải, hiệu năng và sức ép (stress test) trên thị trường: SiteBlaster, Xceptance LoadTest, Load-Intelligence, LoadStorm, BrowserMob, Load Impact, Pylot, AppLoader, fwptt, JCrawler, vPerformer, Curl-Loader, RealityLoad XF, StressTester, The Grinder, Proxy Sniffer, Test Master, JKool Online, Funkload, Spirent Avalanche (Tuyết băng), Loadea, LoadManager, QEngine Tester, NeoLoad, TestComplete Enterprise, QTest, Load Perspective, SiteTester1, httperf, NetworkTester, WAPT, Visual Studio Team System Test Edition, OpenLoad, Apache JMeter, TestMaker, SiteStress, Siege (Cuộc vây hãm), JBlitz, WebServer Stress Tool, OpenSTA, PureLoad, ApacheBench, Torture (Tra tấn), WebSpray, eValid LoadTest, WebPerformance Load Tester, Quality Optima Studio, Forecast (Dự báo), http-Load, QALoad, IBM Rational Performance Tester, SilkPerformer, Radview WebLoad và HP LoadRunner.

Nội dung trọng tâm của chương 3 là nghiên cứu và thực nghiệm công cụ WebServer Stress Tool v7.173 của hãng Paessler AG:

• Cấu hình môi trường: Ứng dụng chạy trên hệ điều hành Windows (2003 R2, Vista, 7, 2008), hỗ trợ chuẩn hóa kiểm thử cho máy chủ HTTP phục vụ trang tĩnh, JSP/ASP hoặc CGI.
• Quy trình cài đặt: Trình bày chi tiết qua 7 bước thiết lập từ tệp cài đặt đến giao diện làm việc chính (Màn hình #1).
• Thiết lập thông số thử nghiệm:
  • Mục Test Type: Chọn chế độ CLICK (chạy thử nghiệm với tải không đổi cho đến khi sinh sự kiện nháy chuột), thiết lập điều kiện dừng Run until, số lượng người dùng đồng thời Number of user, và thời gian trễ giữa các lần nhấp Click Delay.
  • Mục URLs: Thiết lập thứ tự kiểm tra URL#, tên trang Name, độ trễ Click delay [s] và dán đường dẫn kiểm thử mục tiêu.
• Quy trình phân tích kết quả: Sau khi khởi chạy Start Test và hoàn tất chu trình đo tải, phần mềm hiển thị cửa sổ View logfile Results bao gồm 3 phân vùng dữ liệu: cột Logfiles (danh sách tài khoản người dùng giả lập - #2), cột Results per User (kết quả chi tiết của từng người dùng - #3), và cột Results per URL (kết quả phản hồi của từng liên kết - #4).

Chương 4: Triển khai thực nghiệm với kiểm thử

Chương 4 liên kết lý thuyết kiểm thử vào môi trường sản xuất phần mềm thực tế:

• Nghiên cứu hệ thống ERP và dự án Team link: Khảo sát kiến trúc hệ thống hoạch định tài nguyên doanh nghiệp và phân tích các dạng báo cáo (report) trong dự án Team link đang phát triển tại Công ty Cổ phần Phần mềm Hanel (Hanel Software).
• Khảo sát hệ thống website thương mại điện tử: Khảo sát các chức năng nghiệp vụ trên giao diện website bán lẻ giày và quần áo thể thao.
• Kỹ thuật thiết kế ca kiểm thử (Test Case): Đồ án hướng dẫn và so sánh hai phương thức biên soạn tài liệu kiểm thử: thiết kế test case theo khuôn dạng hàng ngang và thiết kế test case theo khuôn dạng hàng dọc.

Kết quả và đóng góp

Quá trình chạy thực nghiệm công cụ WebServer Stress Tool v7.173 trên đường dẫn http://www.aspx?aid=1&cid=6 thuộc cổng thông tin Khoa Công nghệ thông tin – Viện Đại học Mở Hà Nội đã phát hiện lỗi truy cập máy chủ thực tế được ghi nhận chi tiết trong tệp nhật ký:

!FAILED! All requests of click done, but at least one request failed with HTTP result 404 (=Not Found), (21,002 ms)

Dữ liệu thực nghiệm chỉ ra rằng yêu cầu gửi đến máy chủ hoàn tất trong khoảng thời gian trễ 21,002 ms nhưng phát sinh mã phản hồi lỗi HTTP 404. Tác giả kết luận nguyên nhân do đường dẫn liên kết nội bộ đã bị gỡ bỏ hoặc tài nguyên không còn tồn tại trên máy chủ web tại thời điểm kiểm tra.

Nhằm chuẩn hóa việc phân tích lỗi máy chủ trong quá trình kiểm thử tải, đồ án đã tổng hợp hệ thống bảng tra cứu mã trạng thái giao thức HTTP:

Nhóm mã HTTP	Mã trạng thái	Diễn giải kỹ thuật trong đồ án
Thông tin (Information Codes)	100 Continue	Yêu cầu thực hiện thành công, quy trình có thể tiếp tục.
	101 Switching Protocols	Yêu cầu chuyển đổi giao thức gửi đến máy chủ được chấp nhận (ví dụ từ FTP sang HTTP).
Thành công (Success Codes)	200 OK	Yêu cầu gửi đến máy chủ đã có sẵn và phản hồi chính xác.
	201 Created	Một địa chỉ tài nguyên mới được tạo ra khi sử dụng phương thức đăng dữ liệu (form posting).
	202 Accepted	Yêu cầu đã được chấp nhận xử lý nhưng chưa hoàn thành.
	203 Non-Authoritative Information	Thông tin nhận được không phải từ máy chủ gốc mà từ một nguồn trung gian khác.
	204 No Content	Máy chủ xử lý thành công nhưng không có nội dung gửi về theo yêu cầu của đường link.
	205 Reset Content	Kịch bản máy chủ đang xác lập lại việc hiển thị nội dung cho người dùng.
	206 Partial Content	Máy chủ chỉ hiển thị được một phần nội dung (do giới hạn băng thông, lỗi mã HTML, cơ chế lưu đệm kém).
Chuyển hướng (Redirection Codes)	300 Multiple Choices	Xuất hiện trang lựa chọn hoặc thông báo lỗi khi một địa chỉ trỏ tới nhiều hơn hai tài nguyên.
	301 Moved Permanently	Trang yêu cầu đã được di chuyển cố định, máy chủ tự động chuyển đến địa chỉ mới.
	302 Found	Tài nguyên được chuyển đến địa chỉ tạm thời, máy chủ tự động chuyển hướng.
	303 See Other	Dữ liệu lưu trữ tại địa chỉ luân phiên; sử dụng phương thức GET để truy vấn dữ liệu.
	304 Not Modified	Dữ liệu trên máy chủ không thay đổi kể từ lần truy cập gần nhất của trình duyệt.
	305 Use Proxy	Tài nguyên yêu cầu chỉ có thể truy cập thông qua máy chủ ủy thác (proxy) được ủy quyền.
	307 Temporary Redirect	Trang yêu cầu tạm thời thay đổi địa chỉ, máy chủ chuyển hướng đến đích tương ứng.
Lỗi phía Client (Client Error Codes)	400 Bad Request	Yêu cầu bị từ chối do cú pháp gửi lên máy chủ bị lỗi.
	401 Unauthorized	Từ chối truy cập do địa chỉ IP, tên đăng nhập hoặc mật khẩu không chính xác.
	402 Payment Required	Dữ liệu không thể truy cập tại thời điểm yêu cầu do đòi hỏi điều kiện thanh toán.
	404 Not Found	Máy chủ không tìm thấy tài nguyên tương ứng với liên kết yêu cầu.

Về mặt đóng góp học thuật và ứng dụng thực tiễn, đồ án đạt được các điểm chính:

• Hệ thống hóa toàn diện các cơ sở lý luận về kiểm thử phần mềm, phân định ranh giới giữa kiểm tra (verification) và thẩm định (validation), đồng thời cụ thể hóa các phương pháp kiểm thử hộp trắng, hộp đen, hộp xám.
• Xây dựng bảng khảo sát phong phú về hơn 30 công cụ kiểm thử hiệu năng/chịu tải ứng dụng web trên thị trường công nghệ.
• Đưa ra quy trình mẫu về việc lập kế hoạch kiểm thử đa trình duyệt bằng công cụ quản lý dự án Microsoft Project và hướng dẫn hai kỹ thuật viết test case (hàng ngang, hàng dọc) ứng dụng trực tiếp vào dự án phần mềm doanh nghiệp tại Hanel Software.

Hạn chế và hướng nghiên cứu tiếp

Căn cứ vào phạm vi nghiên cứu được công bố trong văn bản, đồ án tồn tại một số giới hạn kỹ thuật:

• Công cụ kiểm thử hiệu năng WebServer Stress Tool phiên bản v7.173 phụ thuộc vào nền tảng hệ điều hành Windows cũ (hỗ trợ Windows 2003 R2, Vista, Windows 7, Windows 2008), chưa đánh giá trên các môi trường máy chủ Linux hoặc các nền tảng hệ điều hành hiện đại.
• Dữ liệu thực nghiệm đo kiểm tải mới chỉ thực hiện trên một URL đơn lẻ (http://www.aspx?aid=1&cid=6), chưa triển khai kịch bản tải trọng phức hợp đa luồng trên toàn bộ cấu trúc liên kết trang web hoặc các giao dịch cơ sở dữ liệu lớn.
• Báo cáo kết quả kiểm thử trên hệ thống ERP Team link tại Công ty Hanel Software chưa được tổng hợp số liệu đo kiểm tự động chi tiết trong văn bản.

Hướng phát triển tiếp theo được xác định là mở rộng phạm vi kiểm thử hiệu năng trên các hệ thống web quy mô lớn, xây dựng kịch bản kiểm thử tải kết hợp với xác thực dữ liệu phiên làm việc (session, cookie) và áp dụng các công cụ kiểm thử tự động mã nguồn mở đa nền tảng.

Giá trị tham khảo

Đồ án là tài liệu học thuật hữu ích cho:

• Sinh viên chuyên ngành Công nghệ thông tin và Tin học ứng dụng: Nắm bắt quy trình kiểm thử phần mềm chuẩn tắc, hiểu rõ chu trình chuyển tiếp từ phân tích yêu cầu sang thiết kế trường hợp kiểm thử.
• Kỹ sư kiểm thử phần mềm (Tester/QA) mới vào nghề: Tham khảo các bước lập Test Plan thực tế bằng phần mềm Microsoft Project, phương pháp phân loại lỗi chuyên sâu cho web qua bộ kỹ thuật FAST, TOFT, FET và kỹ thuật cấu trúc tài liệu test case dạng hàng ngang hoặc hàng dọc.
• Nghiên cứu viên về hiệu năng hệ thống web: Tiếp cận phương pháp thiết lập kịch bản kiểm thử tải, phân tích log kết quả từ công cụ WebServer Stress Tool và bảng phân loại chi tiết các mã trạng thái HTTP.

Câu hỏi thường gặp

1. Tác giả phân biệt tỷ lệ khối lượng và vai trò giữa Xác minh (Verification) và Thẩm định (Validation) như thế nào?
Trong đồ án, tác giả chỉ rõ hoạt động Verification chiếm 80% khối lượng công việc kiểm thử nhưng chỉ đóng vai trò là điều kiện cần. Ngược lại, Validation chiếm 20% khối lượng công việc kiểm thử nhưng tác động trực tiếp tới 80% hiệu quả chung của dự án/sản phẩm, đóng vai trò là điều kiện đủ để bảo đảm phần mềm thỏa mãn người dùng.

2. Điểm khác biệt căn bản giữa hai kỹ thuật kiểm thử chức năng FAST và TOFT là gì?
FAST (Functional Acceptance Simple Testing) là kiểm thử đơn giản chấp nhận chức năng, tập trung bao phủ theo chiều rộng để kiểm tra sự tồn tại và tính hợp lệ của các thành phần giao diện (textbox, radio button, liên kết, phím tắt) mà không xét sự kết hợp phức tạp giữa các chức năng. Trong khi đó, TOFT (Task Oriented Functional Testing) là kiểm thử hướng tác vụ mang tính tích cực, đối chiếu các chức năng chuyên sâu với tài liệu đặc tả sản phẩm hoặc yêu cầu nghiệp vụ cụ thể (chẳng hạn như kiểm tra thời gian tải trang phải dưới 2 giây).

3. Kế hoạch kiểm thử website mẫu bằng Microsoft Project trong đồ án bao gồm các ràng buộc nào?
Kế hoạch mẫu đặt ra yêu cầu hoàn thành kiểm thử trong thời hạn 1 tháng, thực hiện trên các môi trường trình duyệt: Internet Explorer 7, 8, 9; Firefox 3.8 và Chrome, đồng thời phải thực hiện kiểm thử hiệu năng và hiệu suất của website. Quy trình lập kế hoạch trên Microsoft Project gồm 5 bước: nhập Task Name, phân công nhân sự, nối quan hệ phụ thuộc Predecessors, xác định ngày bắt đầu/kết thúc (tự động loại trừ thứ Bảy, Chủ nhật), và cập nhật tỷ lệ hoàn thành (% complete).

4. Kết quả kiểm thử thực nghiệm trên website Khoa CNTT – Viện Đại học Mở Hà Nội ghi nhận lỗi cụ thể nào?
Công cụ WebServer Stress Tool ghi nhận thông báo lỗi: !FAILED! All requests of click done, but at least one request failed with HTTP result 404 (=Not Found), (21,002 ms). Lỗi này xác nhận có ít nhất một yêu cầu kiểm thử thất bại do đường dẫn liên kết trên trang web đã bị xóa hoặc không còn tồn tại trên máy chủ, với thời gian thực thi là 21,002 mili-giây.

5. Trong công cụ WebServer Stress Tool, giao diện View logfile Results được chia thành những vùng dữ liệu nào để định vị lỗi?
Giao diện hiển thị kết quả kiểm thử (View logfile Results) bao gồm một bảng Datagridview chia làm 3 cột chính: cột Logfiles hiển thị danh sách tài khoản người dùng giả lập (#2), cột Results per User hiển thị kết quả chi tiết của từng người dùng (#3), và cột Results per URL hiển thị số lượng lỗi phát sinh theo từng địa chỉ liên kết (#4). Người kiểm thử sẽ kiểm tra số lượng lỗi tại màn hình #4, sau đó đối chiếu tên User tại màn hình #3 và xem chi tiết nguyên nhân lỗi tại màn hình #2.

Kết luận

Đồ án tốt nghiệp của tác giả Phạm Thị Ngà đã hệ thống hóa toàn diện các lý thuyết nền tảng về kiểm thử phần mềm, quy trình vòng đời kiểm thử và kỹ thuật lập kế hoạch trên phần mềm Microsoft Project. Công trình đã khảo sát sâu rộng bức tranh công nghệ với hơn 30 công cụ đo lường tải và hiệu năng, đồng thời triển khai cài đặt, thực nghiệm chi tiết phần mềm WebServer Stress Tool v7.173 trên hệ thống website trường đại học. Dữ liệu thực nghiệm thực tế phát hiện chính xác lỗi liên kết mã HTTP 404 cùng việc nghiên cứu thiết kế test case cho hệ thống ERP tại Hanel Software đã tạo nên giá trị ứng dụng rõ ràng cho công tác bảo đảm chất lượng phần mềm ứng dụng web.

Trích đoạn nội dung tài liệu

CHƯƠNG 1 CƠ SỞ LÝ THUYẾT 1. Một số định nghĩa về quá trình kiểm thử Kiểm thử là việc kiểm tra kết quả thực hiện của chương trình máy tính xem có đúng với các mục tiêu đã đặt ra với nó không thông qua việc thực hiện ở một số mẫu thử.Kiểm thử phần mềm bao gồm quá trình kiểm tra và kiểm định để đảm bảo phần mềm đáp ứng nhu cầu người dùng, phần mềm chạy đúng chức năng.Kiểm thử phần mềm có thể được thực hiện ở bất kỳ giai đoạn nào trong phát triển phần mềm, phổ biến nhất là kiểm thử sau khi yêu cầu người dùng hoàn thiện hoặc phần mềm vừa xong giai đoạn phát triển. Tuy nhiên, trong quy trình phát triển phần mềm theo kiểu Agile thì kiểm thử phần mềm là quy trình đi cùng với việc phát triển phần mềm.Kiểm thử là việc tìm ra những lỗi trong bản thân phần mềm, việc kiểm thử này trong phần mềm sẽ biểu thị ra những thiếu sót mà ta có thể nhận thấy trong hành vi của phần mềm, và tìm ra những phần không tuân theo quy định và đi lệch ra khỏi những yêu cầu của phần mềm. Theo một số nhà nghiên cứu thì kiểm thử phần mềm được định nghĩa như sau:  Dijkstra: Kiểm thử sẽ hiện thị những lỗi hiện có, nhưng không hiển thị lỗi chưa thấy.

 Beizer Định luật 1: Mọi phương pháp bạn sử dụng để ngăn ngừa hoặc tìm thấy lỗi bỏ đi một phần lỗi rắc rối, cái mà những phương thức cần. Định luật 2: Phần mềm phức tạp lớn hơn những giới hạn khả năng quản lý. Những người kiểm thử không tốt hơn trong thiết kế lỗiso với những lập trình viên kiểm thử trong thiết kế mã.  IEEE: Kiểm thử là tiến trình vận hành hệ thống hoặc thành phần dưới những điều kiện xác định, quan sát hoặc ghi nhận kết quả và đưa ra đánh giá về hệ thống hoặc thành phần đó.

 Myers: Kiểm thử là tiến trình thực thi chương trình với mục đích tìm thấy lỗi. (The art of software testing) 2 Giữa kiểm thử và gỡ rối có sự khác biệt: Kiểm thử nhằm phát hiện ra lỗi trong khi đó gỡ rối là việc xác định bản chất lỗi và định lỗi trong chương trình, sau đó tiến hành sữa lỗi. Một số định nghĩa về quá trình kiểm thử phần mềm Một sai sót(Error): Là một sự nhầm lẫn hay một sự hiểu sai trong quá trình phát triển phần mềm của người phát triển.Một lỗi(fault, defect): Xuất hiện trong phần mềm như là kết qủa của một sai sót.Một hỏng hóc(failure):là kết quả của một lỗi xuất hiện làm cho chương trình không hoạt động được hoặc hoạt động được nhưng không cho kết quả như mong muốn. Sai sót Lỗi Hỏng hóc Dữ liệu thử(test data): Dữ liệu vào cần cung cấp cho phần mềm khi thực thi.Kịch bản kiểm thử(test scenario): Các bước thực hiện khi kiểm thử.Phán xét kiểm thử(test oracle): Là việc đánh giá của kiểm thử, có hai cách đánh giá đó là bằng chương trình(tự động), bằng con người(thủ công).Kiểm thử viên(tester): Người thực hiện kiểm thử.Ca kiểm thử(test case):Tập dữ liệu kiểm thử, điều kiện kiểm thử, để đưa ra kết quả mong đợi.

Mục tiêu của kiểm thử Bằng việc kiểm thử sẽ tìm ra được những lỗi trong phần mềm (Myers,1979)và thiết lập chất lượng của phần mềm(Hetzel,1988).Việc kiểm thử thành công khi bạn tìm được ít nhất một lỗi, và đưa ra sự đánh giá với độ tin cậy lớn.Đáp ứng được các yêu cầu công việc và kỹ thuật đã được qui định trong thiết kế và trong lúc phát triển, làm việc như mong đợi và có thể thực thi với các đặc tính giống nhau. Vai trò của kiểm thử - Testing để tìm ra lỗi, ghi nhận các thông tin về lỗi, nhưng không sữa lỗi. - Testing giúp kiểm định phần mềm, đảm bảo rằng phần mềm “đủ tốt” với độ rủi ro “thấp nhất” có thể. 3 CHƯƠNG 2: NHỮNG VẤN ĐỀ LIÊN QUAN TỚI QUÁ TRÌNH KIỂM THỬ PHẦN MỀM 2.

Vòng đời kiểm thử Vòng đời của kiểm thử bắt đầu từ việc kiểm điểm yêu câu, lập kế hoạch kiểm thử. Sau đó là ghi ra các ý tưởng các trường hợp kiểm thử. Từ các trường hợp kiểm thử này đưa ra tất cả các trường hợp kiểm thử và các kịch bản kiểm thử.Sử dụng các thủ tục hay kịch bản kiểm thử này, người kiểm thử có thể phát họa toàn bộ kiểm thử hệ thống hay kiểm thử tích hợp. Kết quả kiểm thử sẽ được đánh giá bởi các tiêu chí kiểm thử đặt ra ban đầu.

Mô hình kiểm thử là một dãy các kế hoạch, các trường hợp kiểm thử và các thủ tục kiểm thử. Trong tiến trình bảo trì và nâng cấp dự án, thì kiểm thử đóng vai trò quan trọng. Cụ thể là: Hình 1.1: Vòng đời kiểm thử Kiểm điểm yêu cầu: Người kiểm thử kiểm điểm yêu cầu phần mềm để dùng chúng và chắc rằng chúng là kiểm thử được. (Nếu chúng không kiểm thử được thì yêu cầu là mơ hồ và cần được xem lại); đây là một hoạt động quan trọng trong 4 nguyên lí kĩ nghệ phần mềm chủ trương người kiểm thử phải tham gia sớm trong dự án phần mềm và làm việc chặt chẽ với các kĩ sư yêu cầu để chắc rằng các yêu cầu phần mềm là tốt và đầy đủ trước khi dự án bắt đầu.

Lập kế hoạch kiểm thử: Người kiểm thử biết cái gì cần được kiểm thử, và lập kế hoạch các hoạt động kiểm thử của họ như: Chuẩn bị chiến lược kiểm thử, kế hoạch kiểm thử, lịch biểu kiểm thử và ước lượng thời gian kiểm thử. Bởi vì người kiểm thử tham gia sớm vào trong dự án, họ có thể làm việc chặt chẽ với kiến trúc sư phần mềm và người thiết kế phần mềm trong việc xác định mọi cấu phần của sản phẩm phần mềm, cả yêu cầu chức năng và phichức năng.Người kiểm thử cũng giúp nhận diện giao diện giữa phần cứng và phần mềm cũng như lập kế hoạch cách kiểm thử các yêu cầu này. - Để thiết kế 1 kế hoạch kiểm thử thường dùng Msproject Cách tạo test plan bằng Msproject : Muốn lên được test plan tốt, người lên kế hoạch cần phải dựa vào một số yếu tố sau:’’ master plan kế hoạch tổng thể của dự án Code Plan, kế hoạch coding sản phẩm, nhân sự trong nhóm, trình độ và năng lực của các thành viên trong nhóm,chính sách mục tiêu chất lương của công ty , các yêu cầu test của khách hàng hoặc hệ thống,khách hàng cần test như thế nào, đảm bảo dự án hoạt động tốt trên các môi trường gì, có cần dùng công cụ test hiệu năng, hiệu suất hay không? Ví dụ: Tạo 1 test plan bao gồm các nội dung công việc của tester để thực hiện test 1 website đơn giản. o Yêu cầu: Hoàn thành test trong vòng 1 tháng o Test trên các môi trường : IE7, 8, 9, FF3.8, chrome o Thực hiện test hiệu năng, hiệu suất của website  Các bước thực hiện Bước 1: Viết đầy đủ các đầu mục công việc cần thực hiện vào phần Task Name Bước 2: Điền thông tin người làm các task Bước 3: Điền thông tin Predecessors.

Nối các task lại với nhau 5 Bước 4: Xác định ngày bắt đầu và ngày hoàn thành task. Hệ thống tự động bỏ qua 2 ngày nghỉ là thứ 7 và CN. Tuy nhiên người làm plan vẫn có thể chọn thứ 7 và chủ nhật theo chủ ý. Bước 5: Điền % complete nếu các task đã hoàn thành hoặc comment lại nếu có các vấn đề phát sinh.

Thiết kế kiểm thử: Người kiểm thử bắt đầu xây dựng các trường hợp kiểm thử, kịch đoạn kiểm thử và dữ liệu kiểm thử dựa trên yêu cầu/thiết kế của phần mềm. Họ cũng tạo ra việc dõi vết các yêu cầu để chắc việc kiểm thử là đầy đủ bao quát mọi chi tiết của yêu cầu phần mềm.Bằng việc hiểu thiết kế trong chi tiết, người kiểm thử có thể phát triển các trường hợp kiểm thử tốt hơn và dữ liệu kiểm thử cho dự án. Các modul mà người kiểm thử cần phải thiết kế khi kiêm thử:Viết tescase modul quản trị hệ thống,viết testcase modul quản trị dự án, viết testcase modul quản trị thiết bị, unit test modul quản trị hệ thống,unit test modul quản trị dự án, unit test modul quản trị thiết bị,modul test : liệt kê các modul của hệ thống, system test toàn bộ hệ thống, thực hiện test hiệu năng hệ cho hệ thống, tổng hợp và lên báo cáo kết quả test, viết tài liệu hướng dẫn sử dụng hệ thống, viết tài liệu đào tạo hệ thống,lưu tài liệu lên tài nguyên chung và kết thúc dự án Thiết lập môi trường kiểm thử: Người kiểm thử thiết lập môi trường kiểm thử và chắc rằng nó là hệt như với môi trường người dùng. Thực hiện kiểm thử: Người kiểm thử thực hiện các trường hợp kiểm thử của họ và kịch đoạn kiểm thử trong môi trường kiểm thử để xác định chất lượng của phần mềm (Qua/Hỏng) và phát sinh kết quả kiểm thử và báo cáo khiến khuyết.

Người kiểm thử tiến hành kiểm thử chức năng, kiểm thử tích hợp, và kiểm thử hệ thống và giúp khách hàng tiến hành kiểm thử chấp nhận của người dùng. Tiến trình test và các dạng test trong các giai đoạn Các dự án có thể được chia thành 3 giai đoạn test. Giai đoạn đầu tiên gọi là kiểm thử Alpha, giai đoạn thứ 2 là kiểm thử Beta, giai đoạn 3 là giai đoạn cuối 6 cùng. Trong từng giai đoạn, có những gợi ý và đề xuất các phương pháp test phù hợp, gồm: - Kiểm thử chức năng là một nhóm kiểm thử rất rộng bao gồm FAST, TOFT, kiểm thử biên, kiểm thử dạng khám phá và các dạng khác.

Để định nghĩa tốt hơn phạm vi của kiểm thử chức năng, hãy xem các mức hoạt động khác nhau của một ứng dụng.FAST: Mỗi đầu vào và điều khiển duyệt có hoạt động đúng như mong đợi? TOFT: Ứng dụng có thể thực hiện các chức năng hữu ích như mong đợi? Kiểm thử biên điều gì xảy ra khi sử dụng các giá trị biên? Kiểm thử lỗi ép buộc điều gì xảy ra khi một điều kiện lỗi xuất hiện? Kiểm thử dạng khám phá kinh nghiệm nói lên điều gì về các vùng tiềm ẩn vấn đề trong ứng dụng? Kiểm thử dạng khám phá bao gồm việc nghiên cứu, lập kế hoạch, và thực thi kiểm thử một cách đồng thời. Tấn công phần mềm: Tại sao phần mềm bị lỗi? Làm thế nào bạn có thể biến những bài học kinh nghiệm thành các hoạt động tương tác nhằm công kích và phát hiện các lỗi phần mềm? - FAST FAST: (Funcitonal acceptance simple testing) Kiểm thử đơn giản chấp nhận chức năng .Kiểm thử đơn giản chấp nhận chức năng-FAST là mức thứ hai của kiểm thử chấp nhận phát hành(Release acceptance testing- RAT).