Bài giảng Kiểm thử phần mềm - Bài 2: Phương pháp kiểm thử

BÀI GIẢNG KIỂM THỬ PHẦN MỀM BÀI 2: I. Phương pháp kiểm thử ( Testing Methods) II. Các giai đoạn kiểm thử (Testing Levels) III. Quy trình kiểm thử (Testing Process) PHƯƠNG PHÁP KIỂM THỬ (Testing methods)  Kiểm thử hộp trắng (White Box Testing)  Kiểm thử hộp đen ( Black Box Testing):  Phân vùng tương đương (Equivalence partitioning)  Phân tích giá trị biên (Boundary value analysis)  Vẽ Đồ Thị Nguyên Nhân Kết Quả (Cause-effect Graphing)  Đoán lỗi – Error Guessing PHƯƠNG PHÁP KIỂM THỬ (Testing methods)  Kiểm thử hộp trắng (White Box Testing): Trong kiểm thử hộp màu trắng, cấu trúc mã hoặc thuật toán của chương trình được đưa vào xem xét. Các trường hợp kiểm thử được thiết kế dựa vào cấu trúc mã hoặc cách thức làm việc của chương trình. Người kiểm thử truy cập vào mã nguồn chương trình và có thể kiểm tra nó, lấy đó làm cơ sở để hỗ trợ việc kiểm thử.  Kiểm thử hộp đen ( Black Box Testing): Trong khi đó kiểm thử hộp đen không yêu cầu kỹ sư kiểm thử cần phải có bất kỳ kiến thức về mã hoặc thuật toán của chương trình. Nó kiểm tra các chức năng của hệ thống tức là những gì hệ thống được cho là cần phải làm dựa trên các Đặc tả yêu cầu. Các trường hợp kiểm thử thường được xây dựng xung quanh đó. Có 2 phương pháp: KIỂM THỬ HỘP ĐEN (Black Box Testing)  Là phương pháp test dựa trên đầu vào và đầu ra của chương trình để test mà không quan tâm tới code bên trong được viết ra sao. Tester xem phần mềm như là một hộp đen  Trong khi đó kiểm thử hộp đen không yêu cầu kỹ sư kiểm thử cần phải có bất kỳ kiến thức về mã hoặc thuật toán của chương trình. Nó kiểm tra các chức năng của hệ thống tức là những gì hệ thống được cho là cần phải làm dựa trên các Đặc tả yêu cầu. Các trường hợp kiểm thử thường được xây dựng xung quanh đó. Phân vùng tương đương(Equivalence partitioning)  Chia (partition) đầu vào thành những nhóm tương đương nhau (equivalence). Nếu một giá trị trong nhóm hoạt động đúng thì tất cả các giá trị trong nhóm đó cũng hoạt động đúng và ngược lại  —Mục đích : Giảm đáng kể số lượng test case cần phải thiết kế vì với mỗi lớp tương đương ta chỉ cần test trên các phần tử đại diện Thiết kế Test-case bằng phân lớp tương đương tiến hành theo 2 bước: (1). Xác định các lớp tương đương (2). Xác định các ca kiểm thử. Phân vùng tương đương(Equivalence partitioning)  Nguyên tắc:  1 lớp các giá trị lớn hơn  1 lớp các giá trị nhỏ hơn  n lớp các giá trị hợp lệ  Bảng liệt kê các lớp tương đương Điều kiện vào/ ra Các lớp tương đương hợp lệ Các lớp tương không hợp lệ Phân vùng tương đương(Equivalence partitioning) Ví dụ minh họa:  Xác định phân vùng tương đương và test case thích hợp theo yêu cầu dưới đây: + Zip Code : 5 chữ số Phân vùng tương đương(Equivalence partitioning) Bài làm:  Phân vùng tương đương ZIP Code 1. Ký tự số: + Không nhập ký tự nào + Nhập < 5 ký tự + Nhập 5 ký tự + Nhập> 5 ký tự 2. Ký tự chữ 3. Ký tự đặc biệt Điều kiện đầu vào yêu cầu một giá trị xác định, phân hoạch thành một lớp tương đương hợp lệ và hai lớp tương đương không hợp lệ. Chẳng hạn, nếu đầu vào x=5 (x là Zip code), thì lớp hợp lệ là x= 5, các lớp không hợp lệ là x 5. Phân vùng tương đương(Equivalence partitioning) Bảng các lớp tương đương: Điều kiện vào Các lớp tương đương hợp lệ Các lớp tương không hợp lệ Số Zip Code Các ký tự số Các ký tự chữ Các ký tự đặc biệt Nhập 5 ký tự Nhập < 5 ký tự Nhập > 5 ký tự Phân tích giá trị biên (Boundary value analysis)  Đây là phương pháp test mà chúng ta sẽ test tất cả các giá trị ở vùng biên của dữ liệu vào và dữ liệu ra. Chúng ta sẽ tập trung vào các giá trị biên chứ không test toàn bộ dữ liệu. Thay vì chọn nhiều giá trị trong lớp đương tương để làm đại diện, phân tích giá trị biên yêu cầu chọn một hoặc vài giá trị là các cạnh của lớp tương đương để làm điều kiện test  — “Test các giá trị biên” chúng ta chỉ test các phần sau:Bất kỳ một cách chọn thực hiện trong phương pháp “Giá trị biên” ta có thể sử dụng được tốt. Thay vì ta phải test toàn bộ vùng cần test ta có thể test 6 hoặc 4 case và vẫn đảm bảo là hệ thống hoạt động tốt. Boundary conditions là các vị trí ở giữa, trên và dưới các biên của lớp tương đương.  Một số điểm cần lưu ý khi dùng phương pháp này:  Luôn test trường hợp “0” nếu nó nằm trong vùng kiểm tra và một vài trường hợp nếu nó nằm ngoài vùng bởi vì 0 là giá trị khá đặc biệt. Phân tích giá trị biên (Boundary value analysis)  Luôn test các chuỗi rỗng nếu nó nằm trong vùng test và ngay cả khi nó không nằm trong vùng test.  Phân tích giá trị biên là kỹ thuật thiết kế test case và hoàn thành phân vùng tương đương.  Mục tiêu là lựa chọn các test case để thực thi giá trị biên.  Phân tích giá trị biên sẽ chọn các giá trị:  Giá trị nhỏ nhất  Giá trị ngay trên giá trị nhỏ nhất  Giá trị bình thường  Giá trị ngay dưới giá trị lớn nhất  Giá trị lớn nhất  Ví dụ: a<=y<=b thì sẽ chọn: a, a+1, a+b/2, b-1, b. Phân tích giá trị biên (Boundary value analysis) Ví dụ minh họa: Cho một mảng [ -3 , 10], ta có giá trị biên là: + Giá trị nhỏ nhất: -3 + Giá trị lớn nhất: 10 + Giá trị nhỏ hơn giá trị nhỏ nhất: -4 + Giá trị lớn hơn giá trị lớn nhất: 11 + Giá trị nằm trong -3 và 10: 0 Đây là phương pháp test mà chúng ta sẽ test tất cả các giá trị ở vùng biên của dữ liệu vào và dữ liệu ra. Chúng ta sẽ tập trung vào các giá trị biên chứ không test toàn bộ dữ liệu Đồ thị Nguyên nhân - Kết quả(Cause & Effect Graphing)  Một điểm yếu của hai phương pháp trên là chúng không khảo sát sự kết hợp của các trường hợp đầu vào. Việc kiểm tra sự kết hợp đầu vào không phải là một nhiệm vụ đơn giản bởi vì nếu bạn phân lớp tương đương các trạng thái đầu vào, thì số lượng sự kết hợp thường là rất lớn.  Đồ thị nhân - quả sử dụng mô hình các quan hệ logic giữa nguyên nhân và kết quả cho thành phần phần mềm. Mỗi nguyên nhân được biểu diễn như một điều kiện (đúng hoặc sai) của một đầu vào, hoặc kết hợp các đầu vào. Mỗi kết quả được biểu diễn như là một biểu thức Bool biểu diễn một kết quả tương ứng cho những thành phần vừa thực hiện Đồ thị Nguyên nhân - Kết quả(Cause & Effect Graphing)  Kỹ thuật gồm có 4 bước:  Xác định điều kiện vào và hành động cho mỗi module cần kiểm định.  —Xác định đồ thị nguyên nhân – kết quả.  Đồ thị được chuyển thành bảng quyết định.  —Những phần trong bảng quyết định được chuyển thành test case. Đồ thị Nguyên nhân - Kết quả(Cause & Effect Graphing) Ví dụ minh họa:  Trên màn hình đăng nhập, có 2 thông tin cần đưa vào là Tên đăng nhập và mật khẩu, chỉ thực hiện đăng nhập thành công nếu nhập đúng cả Tên đăng nhập và mật khẩu, các trường hợp còn lại sẽ hiển thị thông báo “Nhập không chính xác, yêu cầu nhập lại” Đồ thị Nguyên nhân - Kết quả(Cause & Effect Graphing) Đoán Lỗi ( Error Guessing)  —Một kỹ thuật thiết kế test-case khác là error guessing – đoán lỗi. Tester được đưa cho 1 chương trình đặc biệt, họ phỏng đoán, cả bằng trực giác và kinh nghiệm, các loại lỗi có thể và sau đó viết các ca kiểm thử để đưa ra các lỗi đó.  Thật khó để đưa ra một quy trình cho kỹ thuật đoán lỗi vì nó là một quy trình có tính trực giác cao và không thể dự đoán trước. Ý tưởng cơ bản là liệt kê một danh sách các lỗi có thể hay các trường hợp dễ xảy ra lỗi và sau đó viết các ca kiểm thử dựa trên danh sách đó.Nói cách khác, bạn liệt kê những trường hợp đặc biệt đó mà có thể đã bị bỏ sót khi chương trình được thiết kế. Sự giống nhau giữa Kiểm thử Hộp trắng và Hộp đen  GIỐNG NHAU  Hai loại hình kiểm thử đều nhằm mục đích là kiểm định lại phần mềm nhằm loại bỏ những lỗi và những gì thiếu trong quá trình làm phần mềm nhằm mục đích là đem lại một sản phẩm tốt đến khách hàng.  KHÁC NHAU  Kiểm thử hộp trắng: Kiểm thử hộp trắng là phương pháp kiểm thử dựa vào cấu trúc/mã lệnh chương trình. Phương pháp kiểm thử hộp trắng kiểm thử một chương trình (một phần chương trình, hay một hệ thống, một phần của hệ thống) đáp ứng tốt tất cả các giá trị input bao gồm các giá trị không đúng hay không theo dự định của chương trình.  Phương pháp dựa trên: o Data flow testing o Branch testing o Statement testing (các câu lệnh) o Path testing (đường dẫn) o .... Sự giống nhau giữa Kiểm thử Hộp trắng và Hộp đen  Kiểm thử hộp đen: Kiểm thử hộp đen hay còn gọi là kiểm thử chức năng, việc kiểm nghiệm này được thực hiện mà không cần quan tâm đến các thiết kế và viết mã của chương trình. Kiểm thử theo cách này chỉ quan tâm đến chức năng đã đề ra của chương trình. Vì vậy kiểm thử loại này chỉ dựa vào bản mô tả chức năng của chương trình, xem chương trình có thực sự cung cấp đúng chức năng đã mô tả trong bản chức năng hay không mà thôi. Phương pháp dựa trên: - Chức năng thiếu hoặc không đúng đắn - Sai về giao diện - Sai trong cấu trúc hoặc trong truy cập dữ liệu ngoài - Sai thực thi chức năng Tùy vào từng giai đoạn trong quá trình phát triển phần mềm sẽ dùng các loại kiểm thử thích hợp. CÁC GIAI ĐOẠN KIỂM THỬ (Testing levels) CÁC GIAI ĐOẠN KIỂM THỬ (Testing levels) CÁC GIAI ĐOẠN KIỂM THỬ (Testing levels) Có 4 mức độ kiểm thử: 1. UnitTesting : test ở mức cơ bản, test từng module nhỏ trong hệ thống do lập trình viên thực hiện. Là kiểu white box testing Mục đích: để xác nhận rằng mỗi thành phần của phần mềm thực hiện đúng với thiết kế. 2. Integration Testing: test ở mức tích hợp (tích hợp các hàm lại với nhau, tích hợp các màn hình lại với nhau theo từng module hay dựa theo chức năng) do tester thực hiện Mục đích: mục đích để tìm ra lỗi trong quá trình tích hợp các thành phần , module lại với nhau CÁC GIAI ĐOẠN KIỂM THỬ (Testing levels) 3. System Testing: test ở mức hệ thống (tích hợp toàn bộ các hàm, các chức năng thành một phần mềm, module hoàn chỉnh) Mục đích: để đánh giá hệ thống tuân thủ đúng với đặc tả yêu cầu 4. Acceptance Testing: mức test này giống như system test nhưng thường được khách hàng thực hiện test, mục đích là xem phần mềm có đáp ứng đúng yêu cầu của khách hàng chưa. Mục đích: để đánh giá hệ thống tuân thủ đúng với yêu cầu của khách hàng và có thể chấp nhận hay không chấp nhận để bàn giao sản phẩm Và trong kiểm thử chấp nhận chia ra làm hai loại: CÁC GIAI ĐOẠN KIỂM THỬ (Testing levels)  Apha: là việc kiểm thử hoạt động chức năng thực tế hoặc giả lập do người dùng/khách hàng tiềm năng hoặc một nhóm test độc lập thực hiện tại nơi sản xuất phần mềm. Alpha testing thường dùng cho phần mềm đóng gói sẵn để bán (ví dụ như MS office, window, chương trình diệt virus) là một hình thức kiểm thử chấp nhận nội bộ, trước khi phần mềm được tiến hành kiểm thử beta.  Beta: được thực hiện sau alpha testing. Các phiên bản của phần mềm - được biết như là các phiên bản beta – chúng được phát hành tới một số lượng giới hạn khán giả bên ngoài nhóm sản xuất phần mềm. Sản phẩm được phát hành đến một số nhóm người để test nhiều hơn nữa có thể chắc chắn rằng sản phẩm có một số bug. Thỉnh thoảng, các phiên bản beta được phát hành rộng rãi để tăng phạm vi phản hồi từ một lượng người sử dụng tương lai lớn nhất. QUY TRÌNH KIỂM THỬ (Testing process)  Software Testing Process SOFTWARE TESTING là gì?  Software testing là một cuộc kiểm tra nhằm cung cấp cho các bên liên quan (khách hàng hay nhóm phát triển phần mềm,...) thông tin về chất lượng của sản phẩm hoặc dịch vụ đang kiểm thử (under test).  Software testing cũ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. Các kỹ thuật kiểm thử bao gồm, nhưng không giới hạn, trong quy trình thực thi chương trình hoặc ứng dụng với mục đích tìm kiếm bug (lỗi, khiếm khuyết/nhược điểm).  Software testing cũng có thể xem như là quá trình thẩm định và thẩm tra (validating and verifying) phần mềm/chương trình/ứng dụng/sản phẩm để:  Đáp ứng được các yêu cầu công việc và kỹ thuật đã được quy định trong thiết kế và trong lúc phát triển  Làm việc như mong đợi SOFTWARE PROCESS là gì? TEST PLAN là gì?  Một kế hoạch kiểm thử dự án phần mềm (test plan) là một tài liệu mô tả các mục tiêu, phạm vi, phương pháp tiếp cận, và tập trung vào nỗ lực kiểm thử phần mềm. Quá trình chuẩn bị test plan là một cách hữu ích để suy nghĩ tới những nỗ lực cần thiết để xác nhận khả năng chấp nhận một sản phẩm phần mềm.  Cấu trúc chung của một test plan: Tên project Danh sách các Module cần test Ngày bắt đầu, ngày kết thúc Danh sách các Test case Nhân sự tham gia Tài nguyên sử dụng (Servers, Workstations, Printers,) Kế hoạch thực hiện (sử dụng Ms Project lập kế hoạch)  Xem biểu mẫu Test Plan TEST CASE là gì?  Test case mô tả một dữ liệu đầu vào (input), hành động (action) và một kết quả mong đợi (expected response), để xác định một chức năng của ứng dụng phần mềm hoạt động đúng hay không.  Một test case có thể có các phần đặc thù khác nhau như mã test case, tên test case, mục tiêu test, các điều kiện test, các yêu cầu data input, các bước thực hiện và các kết quả mong đợi. Mức chi tiết có thể được định nghĩa khác nhau dựa vào quy mô của dự án hay quy mô của công ty sản xuất phần mềm.  Quá trình phát triển test case có thể giúp tìm ra lỗi trong các yêu cầu hoặc thiết kế của ứng dụng, vì nó đòi hỏi phải tư duy hoàn toàn thông qua các hoạt động của ứng dụng. Vì lý do này, việc chuẩn bị test case sớm nhất có thể trong qui trình phát triển phần mềm là rất hữu ích. TEST CASE là gì?  Nó bao gồm 3 bước cơ bản : - Mô tả : đặc tả các điều kiện cần cố để tiến hành kiểm tra. - Nhập : đặc tả đối tượng hoặc dữ liệu cần thiết, được sử dụng làm đầu vào để thực hiện kiểm tra. - Kết quả mong chờ : kết quả trả về từ đối tượng kiểm tra.  Biểu mẫu Testcase: TESTING EXECUTION là gì?  Thực hiện test trực tiếp trên ứng dụng phần mềm sau khi lập trình viên bàn giao  Dựa trên các test cases đã được viết trước đó để thực hiện test trên phần mềm  Thực hiện ghi nhận kết quả kiểm thử vào cột kết quả của tài liệu kịch bản kiểm thử. Nếu kết quả kiểm thử là thất bại thì nhóm kiểm thử ghi nhận lỗi lên hệ thống quản lý lỗi.  Nhóm kiểm thử, QTDA, nhóm lập trình, nhóm giải pháp tham gia vào quá trình quản lý/xử lý lỗi ( bug/ defect) TESTING EXECUTION là gì?  Thực hiện test trực tiếp trên ứng dụng phần mềm sau khi lập trình viên bàn giao  Dựa trên các test cases đã được viết trước đó để thực hiện test trên phần mềm  Thực hiện ghi nhận kết quả kiểm thử vào cột kết quả của tài liệu kịch bản kiểm thử. Nếu kết quả kiểm thử là thất bại thì nhóm kiểm thử ghi nhận lỗi lên hệ thống quản lý lỗi.  Nhóm kiểm thử, QTDA, nhóm lập trình, nhóm giải pháp tham gia vào quá trình quản lý/xử lý lỗi ( bug/ defect) Question & Answer? Bài 3: Nội dung buổi học tuần sau: Học phần Nội dung Các tài liệu quan trọng trong testing Tìm hiểu tài liệu Giải pháp (Software Requirement Specification) Tìm hiểu phân tích yêu cầu, các nghiệp vụ Biểu mẫu test plan Giới thiệu biểu mẫu, các nội dung test plan Biểu mẫu testcases Khái niệm và cấu trúc của testcases Hướng dẫn cách viết testcases Bài tập Biểu mẫu Test Report Lỗi phần mềm là gì ? (Defect/Bug) Khái niệm (Concept) Bug Priority, Bug Severity Bug Report Quy trình log và closed Bug ( Defect life cycle) Re-test khác Regression test thế nào?