TÌM HIỂU VỀ KIỂM THỬ PHẦN MỀM VÀ ỨNG DỤNG KIỂM THỬ ĐỂ ĐÁNH GIÁ CHẤT LƯỢNG WEBSITE “SHOP HOA ONLINE” - Full 10 điểm

UBND TỈNH QUẢNG NAM TRƯỜNG ĐẠI HỌC QUẢNG NAM KHOA CÔNG NGHỆ THÔNG TIN ---------- KHÓA LUẬN TỐT NGHIỆP ĐẠI HỌC Tên đề tài: TÌM HIỂU VỀ KIỂM THỬ PHẦN MỀM VÀ ỨNG DỤNG KIỂM THỬ ĐỂ ĐÁNH GIÁ CHẤT LƯỢNG WEBSITE “SHOP HOA ONLINE” Sinh viên thực hiện: LÊ THỊ THẢO Lớp: DT13CTT01 CHUYÊN NGÀNH: CÔNG NGHỆ THÔNG TIN KHÓA 2013 – 2017 Giảng viên hướng dẫn: ThS. NGUYỄN THỊ MINH CHÂU Quảng Nam tháng 4 năm 2017 LỜI CẢM ƠN Để hoàn thành khóa luận này, em xin tỏ lòng biết ơn sâu sắc đến ThS. Nguyễn Thị Minh Châu, đã tận tình hướng dẫn trong suốt quá trình viết báo cáo tốt nghiệp. Em chân thành cảm ơn quý Thầy, Cô trong khoa Công Nghệ Thông Tin, Trường Đại Học Quảng Nam đã tận tình truyền đạt kiến thức trong những năm em học tập. Với vốn kiến thức được tiếp thu trong quá trình học không chỉ là nền tảng cho quá trình nghiên cứu khóa luận mà còn là hành trang qúy báu để em bước vào đời một cách vững chắc và tự tin. Trong quá trình làm bài báo cáo khóa luận tốt nghiệp, do trình độ còn hạn hẹp, đề tài rộng, thời gian có hạn, nên không tránh khỏi những thiếu sót, mong quý Thầy Cô góp ý kiến để em học hỏi thêm được nhiều kinh nghiệm. Em xin chân thành cảm ơn! MỤC LỤC Phần 1. MỞ ĐẦU ......................................................................................1 1.1. Lý do chọn đề tài ..................................................................................1 1.2. Mục tiêu của đề tài ...............................................................................1 1.3. Đối tượng và phạm vi nghiên cứu ........................................................1 1.3.1. Đối tượng nghiên cứu........................................................................1 1.3.2. Phạm vi nghiên cứu ...........................................................................1 1.4. Nội dung và phương pháp nghiên cứu .................................................2 1.5. Lịch sử nghiên cứu ...............................................................................2 1.6. Đóng góp của đề tài………………………………………………….2 1.7. Bố cục của đề tài ..................................................................................2 Phần 2. NỘI DUNG NGHIÊN CỨU .......................................................3 Chương 1: CƠ SỞ LÝ THUYẾT VỀ KIỂM THỬ PHẦN MỀM ........3 1.1. Tổng quan về kiểm thử phần mềm.......................................................3 1.2. Các mục tiêu chính của kiểm thử phần mềm .......................................4 1.3. Lỗi (Bug) ..............................................................................................4 1.4. Nguyên tắc kiểm tra lỗi chung ............................................................5 1.5. Kiểm thử với mô hình trong phát triển phần mềm .............................7 1.6. Test case là gì? ...................................................................................14 1.7. Các kỹ thuật trong kiểm thử ...............................................................15 1.8. Các giai đoạn kiểm thử .....................................................................23 1.9. Mô hình kiểm thử ...............................................................................26 1.10. Sơ đồ tổ chức phổ biến của đội kiểm thử.........................................26 1.11. Quy trình kiểm thử phần mềm theo tiêu chuẩn CMMI5 .................27 1.11.1. Lập kế hoạch test ...........................................................................27 1.11.2. Phân tích và thiết kế test ...............................................................29 1.11.3. Review thiết kế test .......................................................................30 1.11.4. Chuẩn bị môi trường test ...............................................................30 1.11.5. Thực hiện test ...............................................................................30 1.11.6. Review kết quả Test ......................................................................31 1.11.7. Báo cáo kết quả Test .....................................................................31 1.12. Trách nhiệm của người kiểm thử. ....................................................31 1.13. Một số loại hình kiểm thử phổ biến. ................................................32 CHƯƠNG 2: XÂY DỰNG WEBSITE “SHOP HOA ONLINE” .......33 2.1. Đặt vấn đề...........................................................................................33 2.2. Giải pháp ............................................................................................33 2.3. Đặc tả bài toán ....................................................................................33 2.4. Phân tích yêu cầu ...............................................................................35 2.5 Cơ sở dữ liệu của website “Shop hoa online”.....................................37 2.6. Demo chương trình ............................................................................40 CHƯƠNG 3: THIẾT KẾ TEST CASE VÀ THỰC THI TEST .........42 3.1. Thực hiện Unit test. ............................................................................43 3.1.1. Quy trình test ...................................................................................43 3.2. Thực hiện test case black_box testing theo đặc tả yêu cầu ................47 3.2.1. Quy trình test ...................................................................................47 Phần 3. KẾT LUẬN ................................................................................49 TÀI LIỆU THAM KHẢO ......................................................................51 1 Phần 1. MỞ ĐẦU 1.1. Lý do chọn đề tài Ngày nay công nghệ thông tin ngày càng phát triển, kéo theo đó là hệ thống mạng và phần mềm cũng gia tăng cả về số lượng theo chiều rộng và chất lượng phần mềm theo chiều sâu. Nhưng cũng từ đó đã nảy sinh ra nhiều vấn đề về lỗi hỏng hóc phần mềm không đáng có, gây ra không ít ảnh hưởng đến kinh tế và xã hội… Những lỗi này có thể do tự bản thân phần mềm bị hỏng do không được kiểm tra kĩ lưỡng trước khi đến tay khách hàng, hay cũng có thể do có người cố tình phá hoại nhằm đánh cắp thông tin cá nhân như mã số tài khoản ngân hàng, số điện thoại, danh bạ, tin nhắn, …., từ đây ta dể dàng nhận ra là mặc dù phần mềm phát triển ngày càng nhiều nhưng vấn đề chất lượng vẫn là một dấu hỏi lớn cần xem xét cẩn thận. Do đó yêu cầu đặt ra là cần có công tác kiểm thử 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ên trong phần mềm mà ta chưa kịp nhận ra. Đó chính là lý do em chọn đề tài này để nghiên cứu tìm hiểu kỹ về “Kiểm Thử Phần Mềm” và ứng dụng để đánh giá “website Shop Hoa Online”. 1.2. Mục tiêu của đề tài - Tìm hiểu rõ hơn về kiểm thử phần mềm - Xây dựng một Website “Shop Hoa Online” hoàn chỉnh bao gồm các chức năng cần thiết trong thương mại điện tử. - Sử dụng kiểm thử để đánh giá website vừa xây dựng. 1.3. Đối tượng và phạm vi nghiên cứu 1.3.1. Đối tượng nghiên cứu - Đối tượng nghiên cứu: Kiểm thử phần mềm 1.3.2. Phạm vi nghiên cứu - Về nội dung: Áp dụng kiểm thử vào website “Shop hoa online” 2 - Về không gian: Kiểm thử phần mềm - Về thời gian: Đề tài được thực hiện trong 5 tháng kể từ tháng 11 năm 2016. 1.4. Nội dung và phương pháp nghiên cứu - Phương pháp nghiên cứu tự luận: Nghiên cứu tài liệu, tìm hiểu nhiều vấn đề kiểm thử thông qua các diễn đàn trên internet. - Phương pháp tổng kết kinh nghiệm: Qua việc làm việc thực tế trên một vài công ty. - Phương pháp lấy ý kiến chuyên gia: Lấy ý kiến giảng viên trực tiếp hướng dẫn, các giảng viên bộ môn để hoàn thiện về mặt nội dung và hình thức của khóa luận. - Để thực hiện đề tài này, em sử dụng phương pháp phân tích và thiết kế hệ thống theo hướng đối tượng, hoạt động khảo sát, phân tích, thiết kế… 1.5. Lịch sử nghiên cứu Đề tài nghiên cứu về kiểm thử phần mềm được bắt đầu từ tháng 12 năm 2016, trải qua quá trình nghiên cứu hơn 4 tháng và kết thúc vào tháng 4 năm 2017. 1.6. Đóng góp của đề tài Trải qua quá trình nghiên cứu giúp chúng ta hiểu rõ hơn về kiểm thử phần mềm. Nắm rõ hơn về các định nghĩa cũng như các quy trình, cách thức thực hiện trong kiểm thử phần mềm. 1.7. Cấu trúc của đề tài Ngoài hai phần mở đầu và kết luận, nội dung đề tài gồm 3 nội dung chính: Chương 1: Cơ sở lý thuyết về kiểm thử phần mềm Chương 2: Xây dựng website “Shop Hoa Online” Chương 3: Thiết kế Test Case, thực thi test 3 Phần 2. NỘI DUNG NGHIÊN CỨU Chương 1: CƠ SỞ LÝ THUYẾT VỀ KIỂM THỬ PHẦN MỀM 1.1. Tổng quan về kiểm thử phần mềm 1.1.1 Kiểm thử phần mềm là gì? - Kiểm thử phần mềm là một cuộc kiểm tra nhằm cung cấp cho các bên liên quan (khách hàng, nhóm phát triển) thông tin về chất lượng sản phẩm dịch đang kiểm thử. - Mục đích của kiểm thử phần mềm là chỉ ra rằng phần mềm thực hiện đúng các chức năng mong muốn. - 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à nó hỗ trợ. - Kiểm thử phần mềm là quy trình thi hành phần mềm với ý định tìm kiếm các lỗi của nó. - Kiểm thử phần mềm được xem là quy trình cố gắng tìm kiếm các lỗi của phần mềm. 1.1.2. Tại sao kiểm thử phần mềm là cần thiết? - Kiểm thử phần mềm là thực sự cần thiết vì nó chỉ ra những khiếm khuyết và sai sót đã được thực hiện trong giai đoạn phát triển. - Nó quan trọng vì nó đảm bảo độ tin cậy của khách hàng và sự hài lòng của họ trong ứng dụng. - Nó là rất quan trọng vì nó đảm bảo chất lượng của sản phẩm. - Kiểm thử là cần thiết cho một hoạt động hiệu quả của ứng dụng phần mềm hoặc sản phẩm. - Điều quan trọng là để đảm bảo rằng các ứng dụng không có bất kỳ kết quả nào không như mong đợi, bởi vì chi phí sẽ tăng cao nếu phát hiện lỗi trong các giai đoạn sau phát triển phần mềm. - Đó là yêu cầu thiết yếu giúp sản phẩm tồn tại trong kinh doanh. 4 1.2. Các mục tiêu chính của kiểm thử phần mềm - Phát hiện càng nhiều lỗi càng tốt trong thời gian kiểm thử xác định trước. - Chứng minh rằng sản phẩm phần mềm phù hợp với các đặc tả yêu cầu của nó. - Tạo các test case chất lượng cao, thực hiện kiểm thử hiệu quả và tạo ra các báo cáo vấn đề đúng và hữu dụng. 1.3. Lỗi (Bug) 1.3.1. Định nghĩa Lỗi: Là những gì hoạt động không đúng như mong đợi từ khách hàng hoặc nhà sản xuất. 1.3.2. Tại sao lại xảy ra lỗi? - Các lỗi có thể bị phát sinh do nhiều lý do, nhưng trong quá trình phân tích các dự án mẫu thì lý do chính có thể được tìm thấy trong quá trình truy vết theo bản đặc tả. - Những lý do liên quan đến bản đặc tả là nguyên nhân chính làm xuất hiện lỗi tài liệu đặc tả . - Một số bản đặc tả không viết cụ thể, không đủ kỹ lưỡng, hoặc nó liên tục thay đổi, nhưng lại không có sự phối hợp, trao đổi thông tin kịp thời với các đội phát triển dự án. - Lý do quan trọng tiếp theo mà dễ phát sinh lỗi là quá trình thiết kế . Các lỗi xuất hiện ở đây với những lý do tương tự như khi chúng xuất hiện trong bản đặc tả. Nó bị dồn lại, thay đổi, hoặc giao tiếp không tốt. - Cuối cùng là viết mã - Những lỗi về viết mã có thể được xem là quen thuộc nhất, lỗi về viết mã thường xảy ra do giao tiếp không tốt giữa người lập trình và người phân tích dự án, áp lực của lịch trình hay phần mềm phức tạp và nguyên nhân thường gặp nhất phát sinh ra lỗi ở người lập trình là sao chép mà quên chỉnh sửa. 5 1.3.3. Chi phí cho việc sửa lỗi ? Hình 1.1. Chi phí cho việc sửa lỗi - Chi phí cho việc sửa lỗi có thể tăng đột ngột trên toàn bộ dự án - Chi phí được tính theo hàm loga, mỗi lần chúng tăng lên gấp 10 lần. Lỗi được tìm thấy và sửa lại trong thời gian gần nhất khi bản đặc tả bắt đầu được viết thì chi phí có thể không là gì cả, hoặc chỉ là 1$ cho ví dụ của Hình 1.1 ở trên. Cũng với lỗi tương tự, nếu nó không được tìm thấy cho đến khi phần mềm được được lập trình và kiểm thử thì chi phí có thể lên tới 10$ đến 100$. Nếu để một khách hàng tìm ra nó, thì chi phí có thể lên tới hàng nghìn thậm chí hàng triệu dollar. Từ ví dụ trên, ta có thể kết luận, việc tìm ra lỗi là càng sớm càng tốt, để giảm chi phí cho việc sửa lỗi. 1.4. Nguyên tắc kiểm tra lỗi chung - Kiểm thử chứng minh sự hiện diện của lỗi: Kiểm thử chỉ chứng minh được rằng phần mềm đang có lỗi, kiểm thử không thể chứng minh được sản phẩm không còn lỗi. Nghĩa là sản phẩm luôn luôn có lỗi dù có kiểm thử bao nhiêu đi nữa. Do đó, điều quan trọng là chúng ta phải thiết kế các trường hợp kiểm thử (test case) sao cho có thể tìm được càng nhiều lỗi càng tốt. - Kiểm thử toàn bộ là không khả thi: Kiểm tra tất cả các trường hợp là không khả thi, do các yếu tố về thời gian và chi phí, vì vậy việc phân tích rủi ro và đưa ra các mức độ ưu tiên để kiểm tra các trường hợp cần thiết 6 nhất, rồi sau đó tùy thuộc vào tiến trình của dự án mà kiểm tra các trường hợp còn lại theo mức độ ưu tiên thấp hơn. - Kiểm thử càng sớm càng tốt : Hoạt động kiểm thử được triển khai càng sớm càng tốt, kiểm tra ngay từ giai đoạn đầu lấy yêu cầu khách hàng hay thiết kế tài liệu sản phẩm. Thông thường, thời gian cho kiểm thử thường bị co lại khi sản phẩm gần ra thị trường. Do đó, việc kiểm thử sớm trong giai đoạn đầu sẽ giúp chúng ta có thời gian để tiến hành kiểm thử trong từng giai đoạn một cách đầy đủ. Việc phát hiện lỗi càng trễ bao nhiêu thì chi phí để sửa lỗi càng cao bấy nhiêu, tương tự việc thay đổi yêu cầu không đúng ngay từ đầu thường tốn ít chi phí thay đồi tính năng trong hệ thống. - Lỗi phân bố tập trung: Trong quá trình kiểm thử, chúng ta có thể dễ dàng quan sát thấy, 80% số lỗi được tìm thấy trong 20% tính năng của hệ thống. Điều này cho thấy, lỗi thường tập trung ở một vài tính năng chính của chương trình. - Nghịch lý thuốc trừ sâu: Trong cuộc sống nếu ta cứ phun một loại thuốc trừ sâu với liều lượng như nhau thì một số loại sau nhờn thuốc sẽ không được diệt sạch. Cũng như trong kiểm thử phần mềm, nếu bạn cứ thực thi lặp đi lặp lại một bộ test case thì có khả năng rất thấp bạn sẽ tìm được lỗi từ những trường hợp kiểm thử này. Nguyên nhân là do khi hệ thống ngày càng hoàn thiện, những lỗi được tìm thấy lúc trước đã được sửa trong khi những trường hợp kiểm thử đã cũ. Do đó, khi một lỗi được sửa hay một tính năng mới được thêm vào, chúng ta nên tiến hành làm regression (kiểm thử hồi qui) nhằm mục đích đảm bảo những thay đổi này không ảnh hưởng đến những vùng khác của sản phẩm. Tuy nhiên, các trường hợp kiểm thử trong regression test cũng cần phải được cập nhật để phản ánh sự thay đổi tương ứng của hệ thống. 7 - Kiểm thử phụ thuộc vào ngữ cảnh: Tùy vào loại cũng như bản chất của ứng dụng mà chúng ta sẽ áp dụng những phương thức, kỹ thuật, cũng như loại kiểm thử khác nhau. Chẳng hạn như phần mềm trong các thiết bị y khoa cần sẽ được kiểm thử kỹ lưỡng hơn một trò chơi điện tử. Quan trọng hơn, việc kiểm thử trên loại thiết bị này đòi hỏi phải dựa trên đánh giá rủi ro, đáp ứng những quy định nghiêm ngặt trong y khoa cũng như một bộ kiểm thử đặc thù. Tương tự, một website “lớn” cần phải được kiểm thử một cách đầy đủ từ hiệu năng đến tính năng nhằm đảm bảo server không bị ảnh hưởng khi có nhiều người truy cập vào hệ thống. - Quan niệm sai lầm về việc hết lỗi: 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ẵn sàng để tung ra thị trường. Việc không tìm thấy lỗi cũng có thể là do bộ test case đượ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. 1.5. Kiểm thử với mô hình trong phát triển phần mềm 1.5.1.Mô hình thác nước Hình 1.2. Mô hình thác nước - Trong mô hình thác nước, năm pha trên phải được thực hiện một cách tuần tự; kết thúc pha trước, rồi mới được thực hiện pha tiếp theo. 8 + Phân tích yêu cầu và tài liệu đặc tả (Requirements and Specifications): là giai đoạn xác định những “đòi hỏi” (“What”) liên quan đến chức năng và phi chức năng mà hệ thống phần mềm cần có. Giai đoạn này cần sự tham gia tích cực của khách hàng và kết thúc bằng một tài liệu được gọi là “Bản đặc tả yêu cầu phần mềm” hay SRS (software requirement specification), trong đó bao gồm tập hợp các yêu cầu đã được duyệt (reviewed) và nghiệm thu (approved) bởi những người có trách nhiệm đối với dự án (từ phía khách hàng). SRS chính là nền tảng cho các hoạt động tiếp theo cho đến cuối dự án. + Phân tích và thiết kế hệ thống (System Analysis and Design): là giai đoạn định ra “làm thế nào” (“How”) để hệ thống phần mềm đáp ứng những “đòi hỏi” (“What”) mà khách hàng yêu cầu trong SRS. Đây là chính là cầu nối giữa “đòi hỏi” (“What”) và mã (Code) được hiện thực để đáp ứng yêu cầu đó. + Mã hóa (Coding): là giai đoạn hiện thực “làm thế nào” (“How”) được chỉ ra trong giai đoạn “Phân tích hệ thống và thiết kế” mã hóa thành câu lệnh. + Kiểm thử (Test): giai đoạn này sẽ tiến hành kiểm thử mã (code) đã được hiện thực, bao gồm kiểm thử tích hợp cho nhóm các thành phần và kiểm thử toàn hệ thống (system test). Một khâu kiểm thử cuối cùng thường được thực hiện là nghiệm thu (acceptance test), với sự tham gia của khách hàng trong vai trò chính để xác định hệ thống phần mềm có đáp ứng yêu cầu của họ hay không. + Bảo trì (Maintenance): đây là giai đoạn cài đặt, cấu hình và hướng dẫn khách hàng. Giai đoạn này sửa chữa những lỗi của phần mềm (nếu có) và phát triển những thay đổi mới được khách hàng yêu cầu (như sửa đổi, thêm hay bớt chức năng/đặc điểm của hệ thống). 9 - Nhược điểm chính của mô hình thác nước là rất khó khăn trong việc thay đổi các pha đã được thực hiện, phát hiện lỗi trễ dẫn đến chi phí sửa lỗi cao. - Mô hình này chỉ thích hợp khi các yêu cầu đã được tìm hiểu rõ ràng và những thay đổi sẽ được giới hạn một cách rõ ràng trong suốt quá trình thiết kế. 1.5.2. Mô hình V-Shape Hình 1.3. Mô hình chữ V Bước 1 : Phân tích yêu cầu Đóng vai trò xác định yêu cầu bài toán, tính chất của công việc, khi step này được hoàn thành, thì được đưa vào một bước test gọi là Kiểm thử chấp nhận. Bước 2 : Thiết kế cấp cao Bước này được xảy ra trên kỹ thuật hệ thống và thiết kế, nó là bước mức độ cao vì thời điểm này, nó phải cung cấp được tổng quan về giải pháp xử lý, nền tảng xây dựng, hệ thống sản phẩm, và các dịch vụ. Sau khi bước này được hoàn thành, nó được đưa vào công đoạn test kiểm tra đó là giai đoạn kiểm thử hệ thống. 10 Bước 3 : Thiết kế chi tiết Đây là bước mức độ thấp của thiết kế, là giai đoạn mà sản phẩm phần mềm đã được tiến hành thiết kế thực tế, bắt đầu đi vào xác định các yếu tố logic, các sơ đồ lớp với mọi phương thức, giai đoạn này có thể phát sinh các mâu thuẫn, sự phù hợp hay không phù hợp….Sau khi bước này được thực hiện thành công thì được chuyển đến công đoạn test gọi là : Kiểm thử tích hợp Bước 4 : Viết Mã Là bước bắt đầu tiến hành triển khai dự án, mỗi thành viên đảm nhiệm một chức năng nhiệm vụ của riêng mình, bắt đầu sử dụng ngôn ngữ lập trình và các thuật toán để coding ra một phần chức năng của phần mềm. Bước này được thực hiện xong sẽ tiến hành đưa vào một công đoạn test, người ta gọi đó là công đoạn kiểm thử đơn vị. *Ưu điểm của “Mô hình chữ V” - Đơn giản dễ sử dụng - Có hoạt động, kế hoạch cụ thể cho quá trình tes - Tiết kiệm được thời gian, và có cơ hội thành công cao hơn Waterfall (Mô hình thác nước) - Chủ động trong việc phát hiện lỗi (bug), sớm tìm ra lỗi ngay từ những bước đầu * Nhược điểm “Mô hình chữ V” - Độ linh hoạt ít và còn tồn tại sự cứng nhắc. Nó thể hiện ở chỗ cứ sau mỗi bước thì lại phải có một công đoạn test, nếu yêu cầu dự án không quá phức tạp và dễ hiệu, thì việc thực hiện nhiều công đoạn test như vậy là tốn thời gian. - Giống với mô hình thác nước, sản phẩm của dự án chỉ được xuất hiện khi tất cả các bước được hoàn thành xong, không có nguyên mẫu ngay 11 từ ban đầu. Không đáp ứng được yêu cầu dịch vụ vừa phát triển, song song với vừa bán sản phẩm. - Nếu có sự thay đổi về kỹ thuật ở nữa chừng, thì sẽ phải quay lại các bước đầu tiên, thực hiện lại, cập nhật (update) lại tài liệu. 1.5.3 Mô hình Agile Scrum Hình 1.4. Mô hình Agile Scrum Agile là phương pháp phát triển phần mềm linh hoạt để làm sao đưa sản phẩm đến tay người dùng nhanh nhất và tốt nhất. Nguyên tắc của Agile là : - “Cá nhân và sự tương tác hơn là quy trình và công cụ” - “Phần mềm chạy tốt hơn là tài liệu đầy đủ” - “Cộng tác với khách hàng hơn là đàm phán hợp đồng” - “Phản hồi với sự thay đổi hơn là bám theo kế hoạch” * Cá nhân và sự tương tác hơn là quy trình và công cụ Ý tưởng là đặt trọng tâm vào con người và sự tương hỗ giữa những thành viên trong nhóm. Cơ bản là nếu dự án có những thành viên có năng lực, chịu làm việc cùng nhau thì sẽ mang đến thành công cho dự án. Nếu dự án của bạn có quy trình làm việc tốt, được hỗ trợ những công cụ tốt nhất nhưng những thành viên không “cùng nhìn về một hướng” thì khả năng dự án thất bại là rất lớn. Nói điều này không có nghĩa là phủ nhận tầm quan 12 trọng của quy trình và công cụ nhưng trong Agile nó được đặt sau yếu tố con người. * Phần mềm chạy tốt hơn là tài liệu đầy đủ Trong một số quy trình phát triển phần mềm, việc tạo ra và cập nhật các tài liệu về sản phẩm là bắt buộc. Nhóm phát triển không thể hoặc không đồng ý tiến hành công việc nếu không có tài liệu đặc tả về yêu cầu, thiết kế hệ thống. Nhóm kiểm thử thì yêu cầu tài liệu về sản phẩm để có thể viết trường hợp kiểm thử và kiểm thử được. Nhóm kiểm định chất lượng đòi tất cả các tài liệu phải được viết trước khi sản phẩm được giao cho khách hàng nếu không thì không đủ điều kiện, chuẩn để giao sản phẩm cho khách hàng. Thực ra đứng với góc độ khách hàng thì khách hàng chỉ quan tâm đến sản phẩm có hoạt động được và tốt hay không. Trong khi việc tạo và cập nhật tài liệu mất nhiều thời gian và được cho là buồn tẻ. Vậy tại sao phải tập trung quá nhiều cho việc không cần thiết mà không dành thời gian đó để trao đổi để hiểu thêm về công việc phải làm. Mọi người đừng hiểu lầm là làm Agile là không viết tài liệu. Ý tưởng là chỉ viết những gì mà mọi người cần đọc. * Cộng tác với khách hàng hơn là đàm phán hợp đồng “Khách hàng là thượng đế” hay “khách hàng luôn luôn đúng”. Tuy nhiên có khách hàng am hiểu về công nghệ, có người không. Có người suy nghĩ nhất quán có người thay đổi xoành xoạch, có người lạnh lùng có người cười nói suốt ngày, v.v và cách duy nhất để có thể làm việc tốt là phải cộng tác với khách hàng để hiểu được khách hàng muốn gì và cần gì để có thể tư vấn và điều chỉnh thay vì chỉ dựa vào những điều đã quy định trong hợp đồng. * Phản hồi với sự thay đổi hơn là bám theo kế hoạch Có một điều thú vị là đa số trong chúng ta đều cơ bản đồng ý với 4 tuyên ngôn của Agile. Nhiều người hiểu tầm quan trọng của “cá nhân” hay 13 “cá nhân là tài sản quý giá nhất công ty” nhưng sẵn sàng thay đổi nhân lực để tương thích với quy trình/công cụ hiện có. Nhiều người hiểu “khách hàng là thượng đế” và “phải thích nghi với sự thay đổi” nhưng sẵn sàng tuyên bố “Dẹp, không làm nữa” vì khách hàng thay đổi yêu cầu liên tục. Hay như “sản phẩm xài được là quan trọng” nhưng vẫn cố gắng viết thêm tài liệu với ý nghĩ rằng “biết đâu/lỡ sau này có ai cần thì có cái mà cung cấp”. Scrum: Là một quy trình tuân thủ theo phương pháp của Agile. Vì thế nó tuân thủ các nguyên tắc của Agile. Ngoài ra Scrum hoạt động dựa trên ba giá trị cốt lõi, còn gọi là Ba chân của Scrum bao gồm Minh bạch, Thanh tra và Thích nghi. Minh bạch (transparency): Trong Scrum, tính minh bạch được đề cao như là giá trị cốt lõi cơ bản nhất. Muốn thành công với Scrum, thông tin liên quan tới quá trình phát triển phải minh bạch và thông suốt. Các thông tin đó có thể là: tầm nhìn (vision) về sản phẩm, yêu cầu khách hàng, tiến độ công việc, các khúc mắc và rào cản v.v. Từ đó mọi người ở các vai trò các nhau có đủ thông tin cần thiết để tiến hành các quyết định có giá trị để nâng cao hiệu quả công việc. Các công cụ và cuộc họp trong Scrum luôn đảm bảo thông tin được minh bạch cho các bên. Thanh tra (inspection): Công tác thanh tra liên tục các hoạt động trong Scrum đảm bảo cho việc phát lộ các vấn đề cũng như giải pháp để thông tin đa dạng và hữu ích đến được với các bên tham gia dự án. Truy xét kỹ càng và liên tục là cơ chế khởi đầu cho việc thích nghi và các cải tiến liên tục trong Scrum. Thích nghi (adaptation): Scrum rất linh hoạt như các phương pháp phát triển linh hoạt (agile software development) khác. Nhờ đó nó mang lại tính thích nghi rất cao. Dựa trên các thông tin minh bạch hóa từ các quá 14 trình thanh tra và làm việc, Scrum có thể phản hồi lại các thay đổi một cách tích cực, nhờ đó mang lại thành công cho dự án. Trong Scrum, đội ngũ tham gia phát triển phần mềm được phân chia ra ba vai trò với trách nhiệm rõ ràng để đảm bảo tối ưu hóa các công việc đặc thù. Ba vai trò này bao gồm: Product Owner (chủ sản phẩm), Scrum Master và Development Team (Đội sản xuất hay Nhóm Phát triển). Product Owner (chủ sản phẩm): Là người chịu trách nhiệm về sự thành công của dự án, người định nghĩa các yêu cầu và đánh giá cuối cùng đầu ra của các nhà phát triển phần mềm. Scrum Master: Là người có hiểu biết sâu sắc về Scrum và đảm bảo nhóm có thể làm việc hiệu quả với Scrum. Development Team (Đội sản xuất, hay Nhóm phát triển): Một nhóm liên chức năng (cross-functional) tự quản lý để tiến hành chuyển đổi các yêu cầu được tổ chức trong Product Backlog thành chức năng của hệ thống. Scrum định nghĩa quy tắc cho bốn sự kiện chủ chốt (các cuộc họp) nhằm tạo môi trường và quy cách hoạt động và cộng tác cho các thành viên trong dự án. Các lễ nghi này diễn ra trước khi Sprint bắt đầu (Sprint Planning), trong khi Sprint diễn ra (Daily Scrum) và sau khi Sprint kết thúc (Sprint Review và Sprint Retrospective). 1.6. Test case là gì? Test case mô tả dữ liệu đầu vào (input), hành động(action) hoặc sự kiện (event) 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ó 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 dữ liệu đầu vào, 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 ngữ cảnh của dự án và quy mô của công ty sản xuất phần mềm. 15 1.7. Các kỹ thuật trong kiểm thử Có nhiều kỹ thuật trong kiểm thử, nhưng có 2 loại được sử dụng nhiều nhất là : Kiểm thử hộp đen, và kiểm thử hộp trắng. 1.7.1. Kiểm thử hộp đen (Black Box testing) Dùng để kiểm tra chức năng mà không xem xét mã nguồn cũng như cấu trúc chương trình bên trong. Thường kiểm thử hộp đen quan tâm nhiều đến các bộ dữ liệu kiểm thử đầu vào. Các kỹ thuật trong kiểm thử hộp đen Phân vùng tương đương - Equivalence partitioning Ý tưởng : Phân hoạch miền dữ liệu vào thành các dữ liệu có liên hệ với nhau Mỗi vùng dùng để kiểm thử 1 chức năng , gọi là vùng tương đương. Các bước : - Đối với dữ liệu đầu vào , xác định các vùng tương đương từ miền dữ liệu. - Chọn dữ liệu đại diện cho mỗi vùng tương đương - Kết hợp các dữ liệu thử bởi tích đề các để tạo ra bộ dữ liệu kiểm thử. * Nguyên tắc phân hoạch các vùng tương đương Nếu dữ liệu vào phụ thuộc một khoảng, xây dựng o 1 vùng các giá trị lớn hơn o 1 vùng các giá trị nhỏ hơn o N các giá trị hợp lệ Nếu dữ liệu là tập hợp các giá trị, xây dựng o 1 vùng tập rỗng o 1 vùng quá nhiều các giá trị o N vùng hợp lệ Nếu dữ liệu đầu vào là điều kiện ràng buộc, xây dựng o 1 vùng các ràng buộc được thỏa mãn. 16 o 1 vùng với ràng buộc không được thỏa mãn. Ví dụ: Bài toán đặt vé theo giờ ============+==== -=========+========- Vé thường: ________|__________|_________|__________ =================9h30=======16h=====19h30 ========== -=======+=======-========+ Vé tiết kiệm: _______|________|_________|___________ =================9h30=====16h======19h30 Các vùng hợp lệ là vùng thuộc dấu (+) và vùng không hợp là vùng thuộc dấu (-). Phân theo các vùng hợp lệ và không hợp lệ ta có 4 tes

NỘI DUNG NGHIÊN CỨU

1.1 Tổng quan về kiểm thử phần mềm

1.1.1 Ki ể m th ử ph ầ n m ề m là gì?

- Kiểm thử phần mềm là một cuộc kiểm tra nhằm cung cấp cho các bên liên quan (khách hàng, nhóm phát triển) thông tin về chất lượng sản phẩm dịch đang kiểm thử

- Mục đích của kiểm thử phần mềm là chỉ ra rằng phần mềm thực hiện đúng các chức năng mong muốn

- 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à nó hỗ trợ

- Kiểm thử phần mềm là quy trình thi hành phần mềm với ý định tìm kiếm các lỗi của nó

- Kiểm thử phần mềm được xem là quy trình cố gắng tìm kiếm các lỗi của phần mềm

1.1.2 T ạ i sao ki ể m th ử ph ầ n m ề m là c ầ n thi ế t?

- Kiểm thử phần mềm là thực sự cần thiết vì nó chỉ ra những khiếm khuyết và sai sót đã được thực hiện trong giai đoạn phát triển

- Nó quan trọng vì nó đảm bảo độ tin cậy của khách hàng và sự hài lòng của họ trong ứng dụng

- Nó là rất quan trọng vì nó đảm bảo chất lượng của sản phẩm

- Kiểm thử là cần thiết cho một hoạt động hiệu quả của ứng dụng phần mềm hoặc sản phẩm

- Điều quan trọng là để đảm bảo rằng các ứng dụng không có bất kỳ kết quả nào không như mong đợi, bởi vì chi phí sẽ tăng cao nếu phát hiện lỗi trong các giai đoạn sau phát triển phần mềm

- Đó là yêu cầu thiết yếu giúp sản phẩm tồn tại trong kinh doanh.

CƠ SỞ LÝ THUYẾT VỀ KIỂM THỬ PHẦN MỀM

Tổng quan về kiểm thử phần mềm

1.1.1 Ki ể m th ử ph ầ n m ề m là gì?

- Kiểm thử phần mềm là một cuộc kiểm tra nhằm cung cấp cho các bên liên quan (khách hàng, nhóm phát triển) thông tin về chất lượng sản phẩm dịch đang kiểm thử

- Mục đích của kiểm thử phần mềm là chỉ ra rằng phần mềm thực hiện đúng các chức năng mong muốn

- 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à nó hỗ trợ

- Kiểm thử phần mềm là quy trình thi hành phần mềm với ý định tìm kiếm các lỗi của nó

- Kiểm thử phần mềm được xem là quy trình cố gắng tìm kiếm các lỗi của phần mềm

1.1.2 T ạ i sao ki ể m th ử ph ầ n m ề m là c ầ n thi ế t?

- Kiểm thử phần mềm là thực sự cần thiết vì nó chỉ ra những khiếm khuyết và sai sót đã được thực hiện trong giai đoạn phát triển

- Nó quan trọng vì nó đảm bảo độ tin cậy của khách hàng và sự hài lòng của họ trong ứng dụng

- Nó là rất quan trọng vì nó đảm bảo chất lượng của sản phẩm

- Kiểm thử là cần thiết cho một hoạt động hiệu quả của ứng dụng phần mềm hoặc sản phẩm

- Điều quan trọng là để đảm bảo rằng các ứng dụng không có bất kỳ kết quả nào không như mong đợi, bởi vì chi phí sẽ tăng cao nếu phát hiện lỗi trong các giai đoạn sau phát triển phần mềm

- Đó là yêu cầu thiết yếu giúp sản phẩm tồn tại trong kinh doanh.

Các mục tiêu chính của kiểm thử phần mềm

- Phát hiện càng nhiều lỗi càng tốt trong thời gian kiểm thử xác định trước

- Chứng minh rằng sản phẩm phần mềm phù hợp với các đặc tả yêu cầu của nó

- Tạo các test case 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.

Lỗi (Bug)

Lỗi: Là những gì hoạt động không đúng như mong đợi từ khách hàng hoặc nhà sản xuất

- Các lỗi có thể bị phát sinh do nhiều lý do, nhưng trong quá trình phân tích các dự án mẫu thì lý do chính có thể được tìm thấy trong quá trình truy vết theo bản đặc tả

- Những lý do liên quan đến bản đặc tả là nguyên nhân chính làm xuất hiện lỗi tài liệu đặc tả

- Một số bản đặc tả không viết cụ thể, không đủ kỹ lưỡng, hoặc nó liên tục thay đổi, nhưng lại không có sự phối hợp, trao đổi thông tin kịp thời với các đội phát triển dự án

- Lý do quan trọng tiếp theo mà dễ phát sinh lỗi là quá trình thiết kế Các lỗi xuất hiện ở đây với những lý do tương tự như khi chúng xuất hiện trong bản đặc tả Nó bị dồn lại, thay đổi, hoặc giao tiếp không tốt

- Cuối cùng là viết mã

- Những lỗi về viết mã có thể được xem là quen thuộc nhất, lỗi về viết mã thường xảy ra do giao tiếp không tốt giữa người lập trình và người phân tích dự án, áp lực của lịch trình hay phần mềm phức tạp và nguyên nhân thường gặp nhất phát sinh ra lỗi ở người lập trình là sao chép mà quên chỉnh sửa

Hình 1.1 Chi phí cho việc sửa lỗi

- Chi phí cho việc sửa lỗi có thể tăng đột ngột trên toàn bộ dự án

- Chi phí được tính theo hàm loga, mỗi lần chúng tăng lên gấp 10 lần Lỗi được tìm thấy và sửa lại trong thời gian gần nhất khi bản đặc tả bắt đầu được viết thì chi phí có thể không là gì cả, hoặc chỉ là 1$ cho ví dụ của

Hình 1.1 ở trên Cũng với lỗi tương tự, nếu nó không được tìm thấy cho đến khi phần mềm được được lập trình và kiểm thử thì chi phí có thể lên tới 10$ đến 100$ Nếu để một khách hàng tìm ra nó, thì chi phí có thể lên tới hàng nghìn thậm chí hàng triệu dollar

Từ ví dụ trên, ta có thể kết luận, việc tìm ra lỗi là càng sớm càng tốt, để giảm chi phí cho việc sửa lỗi.

Nguyên tắc kiểm tra lỗi chung

- Kiểm thử chứng minh sự hiện diện của lỗi: Kiểm thử chỉ chứng minh được rằng phần mềm đang có lỗi, kiểm thử không thể chứng minh được sản phẩm không còn lỗi Nghĩa là sản phẩm luôn luôn có lỗi dù có kiểm thử bao nhiêu đi nữa Do đó, điều quan trọng là chúng ta phải thiết kế các trường hợp kiểm thử (test case) sao cho có thể tìm được càng nhiều lỗi càng tốt

- Kiểm thử toàn bộ là không khả thi: Kiểm tra tất cả các trường hợp là không khả thi, do các yếu tố về thời gian và chi phí, vì vậy việc phân tích rủi ro và đưa ra các mức độ ưu tiên để kiểm tra các trường hợp cần thiết nhất, rồi sau đó tùy thuộc vào tiến trình của dự án mà kiểm tra các trường hợp còn lại theo mức độ ưu tiên thấp hơn

- Kiểm thử càng sớm càng tốt: Hoạt động kiểm thử được triển khai càng sớm càng tốt, kiểm tra ngay từ giai đoạn đầu lấy yêu cầu khách hàng hay thiết kế tài liệu sản phẩm Thông thường, thời gian cho kiểm thử thường bị co lại khi sản phẩm gần ra thị trường Do đó, việc kiểm thử sớm trong giai đoạn đầu sẽ giúp chúng ta có thời gian để tiến hành kiểm thử trong từng giai đoạn một cách đầy đủ Việc phát hiện lỗi càng trễ bao nhiêu thì chi phí để sửa lỗi càng cao bấy nhiêu, tương tự việc thay đổi yêu cầu không đúng ngay từ đầu thường tốn ít chi phí thay đồi tính năng trong hệ thống

- Lỗi phân bố tập trung: Trong quá trình kiểm thử, chúng ta có thể dễ dàng quan sát thấy, 80% số lỗi được tìm thấy trong 20% tính năng của hệ thống Điều này cho thấy, lỗi thường tập trung ở một vài tính năng chính của chương trình

- Nghịch lý thuốc trừ sâu: Trong cuộc sống nếu ta cứ phun một loại thuốc trừ sâu với liều lượng như nhau thì một số loại sau nhờn thuốc sẽ không được diệt sạch Cũng như trong kiểm thử phần mềm, nếu bạn cứ thực thi lặp đi lặp lại một bộ test case thì có khả năng rất thấp bạn sẽ tìm được lỗi từ những trường hợp kiểm thử này Nguyên nhân là do khi hệ thống ngày càng hoàn thiện, những lỗi được tìm thấy lúc trước đã được sửa trong khi những trường hợp kiểm thử đã cũ Do đó, khi một lỗi được sửa hay một tính năng mới được thêm vào, chúng ta nên tiến hành làm regression (kiểm thử hồi qui) nhằm mục đích đảm bảo những thay đổi này không ảnh hưởng đến những vùng khác của sản phẩm Tuy nhiên, các trường hợp kiểm thử trong regression test cũng cần phải được cập nhật để phản ánh sự thay đổi tương ứng của hệ thống

- Kiểm thử phụ thuộc vào ngữ cảnh: Tùy vào loại cũng như bản chất của ứng dụng mà chúng ta sẽ áp dụng những phương thức, kỹ thuật, cũng như loại kiểm thử khác nhau Chẳng hạn như phần mềm trong các thiết bị y khoa cần sẽ được kiểm thử kỹ lưỡng hơn một trò chơi điện tử Quan trọng hơn, việc kiểm thử trên loại thiết bị này đòi hỏi phải dựa trên đánh giá rủi ro, đáp ứng những quy định nghiêm ngặt trong y khoa cũng như một bộ kiểm thử đặc thù Tương tự, một website “lớn” cần phải được kiểm thử một cách đầy đủ từ hiệu năng đến tính năng nhằm đảm bảo server không bị ảnh hưởng khi có nhiều người truy cập vào hệ thống

- Quan niệm sai lầm về việc hết lỗi: 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ẵn sàng để tung ra thị trường Việc không tìm thấy lỗi cũng có thể là do bộ test case đượ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.

Kiểm thử với mô hình trong phát triển phần mềm

Hình 1.2 Mô hình thác nước

- Trong mô hình thác nước, năm pha trên phải được thực hiện một cách tuần tự; kết thúc pha trước, rồi mới được thực hiện pha tiếp theo

+ Phân tích yêu cầu và tài liệu đặc tả (Requirements and Specifications): là giai đoạn xác định những “đòi hỏi” (“What”) liên quan đến chức năng và phi chức năng mà hệ thống phần mềm cần có Giai đoạn này cần sự tham gia tích cực của khách hàng và kết thúc bằng một tài liệu được gọi là “Bản đặc tả yêu cầu phần mềm” hay SRS (software requirement specification), trong đó bao gồm tập hợp các yêu cầu đã được duyệt (reviewed) và nghiệm thu (approved) bởi những người có trách nhiệm đối với dự án (từ phía khách hàng) SRS chính là nền tảng cho các hoạt động tiếp theo cho đến cuối dự án

+ Phân tích và thiết kế hệ thống (System Analysis and Design): là giai đoạn định ra “làm thế nào” (“How”) để hệ thống phần mềm đáp ứng những “đòi hỏi” (“What”) mà khách hàng yêu cầu trong SRS Đây là chính là cầu nối giữa “đòi hỏi” (“What”) và mã (Code) được hiện thực để đáp ứng yêu cầu đó

+ Mã hóa (Coding): là giai đoạn hiện thực “làm thế nào” (“How”) được chỉ ra trong giai đoạn “Phân tích hệ thống và thiết kế” mã hóa thành câu lệnh

+ Kiểm thử (Test): giai đoạn này sẽ tiến hành kiểm thử mã (code) đã được hiện thực, bao gồm kiểm thử tích hợp cho nhóm các thành phần và kiểm thử toàn hệ thống (system test) Một khâu kiểm thử cuối cùng thường được thực hiện là nghiệm thu (acceptance test), với sự tham gia của khách hàng trong vai trò chính để xác định hệ thống phần mềm có đáp ứng yêu cầu của họ hay không

+ Bảo trì (Maintenance): đây là giai đoạn cài đặt, cấu hình và hướng dẫn khách hàng Giai đoạn này sửa chữa những lỗi của phần mềm (nếu có) và phát triển những thay đổi mới được khách hàng yêu cầu (như sửa đổi, thêm hay bớt chức năng/đặc điểm của hệ thống)

- Nhược điểm chính của mô hình thác nước là rất khó khăn trong việc thay đổi các pha đã được thực hiện, phát hiện lỗi trễ dẫn đến chi phí sửa lỗi cao

- Mô hình này chỉ thích hợp khi các yêu cầu đã được tìm hiểu rõ ràng và những thay đổi sẽ được giới hạn một cách rõ ràng trong suốt quá trình thiết kế

Bước 1: Phân tích yêu cầu Đóng vai trò xác định yêu cầu bài toán, tính chất của công việc, khi step này được hoàn thành, thì được đưa vào một bước test gọi là Kiểm thử chấp nhận

Bước 2: Thiết kế cấp cao

Bước này được xảy ra trên kỹ thuật hệ thống và thiết kế, nó là bước mức độ cao vì thời điểm này, nó phải cung cấp được tổng quan về giải pháp xử lý, nền tảng xây dựng, hệ thống sản phẩm, và các dịch vụ Sau khi bước này được hoàn thành, nó được đưa vào công đoạn test kiểm tra đó là giai đoạn kiểm thử hệ thống

Bước 3: Thiết kế chi tiết Đây là bước mức độ thấp của thiết kế, là giai đoạn mà sản phẩm phần mềm đã được tiến hành thiết kế thực tế, bắt đầu đi vào xác định các yếu tố logic, các sơ đồ lớp với mọi phương thức, giai đoạn này có thể phát sinh các mâu thuẫn, sự phù hợp hay không phù hợp….Sau khi bước này được thực hiện thành công thì được chuyển đến công đoạn test gọi là : Kiểm thử tích hợp

Là bước bắt đầu tiến hành triển khai dự án, mỗi thành viên đảm nhiệm một chức năng nhiệm vụ của riêng mình, bắt đầu sử dụng ngôn ngữ lập trình và các thuật toán để coding ra một phần chức năng của phần mềm Bước này được thực hiện xong sẽ tiến hành đưa vào một công đoạn test, người ta gọi đó là công đoạn kiểm thử đơn vị

- Đơn giản dễ sử dụng

- Có hoạt động, kế hoạch cụ thể cho quá trình tes

- Tiết kiệm được thời gian, và có cơ hội thành công cao hơn Waterfall (Mô hình thác nước)

- Chủ động trong việc phát hiện lỗi (bug), sớm tìm ra lỗi ngay từ những bước đầu

* Nh ượ c đ i ể m “Mô hình ch ữ V”

- Độ linh hoạt ít và còn tồn tại sự cứng nhắc Nó thể hiện ở chỗ cứ sau mỗi bước thì lại phải có một công đoạn test, nếu yêu cầu dự án không quá phức tạp và dễ hiệu, thì việc thực hiện nhiều công đoạn test như vậy là tốn thời gian

- Giống với mô hình thác nước, sản phẩm của dự án chỉ được xuất hiện khi tất cả các bước được hoàn thành xong, không có nguyên mẫu ngay từ ban đầu Không đáp ứng được yêu cầu dịch vụ vừa phát triển, song song với vừa bán sản phẩm

- Nếu có sự thay đổi về kỹ thuật ở nữa chừng, thì sẽ phải quay lại các bước đầu tiên, thực hiện lại, cập nhật (update) lại tài liệu

Hình 1.4 Mô hình Agile Scrum

Agile là phương pháp phát triển phần mềm linh hoạt để làm sao đưa sản phẩm đến tay người dùng nhanh nhất và tốt nhất Nguyên tắc của Agile là :

- “Cá nhân và sự tương tác hơn là quy trình và công cụ”

- “Phần mềm chạy tốt hơn là tài liệu đầy đủ”

- “Cộng tác với khách hàng hơn là đàm phán hợp đồng”

- “Phản hồi với sự thay đổi hơn là bám theo kế hoạch”

* Cá nhân và sự tương tác hơn là quy trình và công cụ Ý tưởng là đặt trọng tâm vào con người và sự tương hỗ giữa những thành viên trong nhóm Cơ bản là nếu dự án có những thành viên có năng lực, chịu làm việc cùng nhau thì sẽ mang đến thành công cho dự án Nếu dự án của bạn có quy trình làm việc tốt, được hỗ trợ những công cụ tốt nhất nhưng những thành viên không “cùng nhìn về một hướng” thì khả năng dự án thất bại là rất lớn Nói điều này không có nghĩa là phủ nhận tầm quan trọng của quy trình và công cụ nhưng trong Agile nó được đặt sau yếu tố con người

* Phần mềm chạy tốt hơn là tài liệu đầy đủ

Test case là gì?

Test case mô tả dữ liệu đầu vào (input), hành động(action) hoặc sự kiện (event) 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ó 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 dữ liệu đầu vào, 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 ngữ cảnh của dự án và quy mô của công ty sản xuất phần mềm.

Các kỹ thuật trong kiểm thử

Có nhiều kỹ thuật trong kiểm thử, nhưng có 2 loại được sử dụng nhiều nhất là : Kiểm thử hộp đen, và kiểm thử hộp trắng

1.7.1 Ki ể m th ử h ộ p đ en (Black Box testing)

Dùng để kiểm tra chức năng mà không xem xét mã nguồn cũng như cấu trúc chương trình bên trong Thường kiểm thử hộp đen quan tâm nhiều đến các bộ dữ liệu kiểm thử đầu vào

Các kỹ thuật trong kiểm thử hộp đen

Phân vùng t ươ ng đươ ng - Equivalence partitioning Ý tưởng: Phân hoạch miền dữ liệu vào thành các dữ liệu có liên hệ với nhau

Mỗi vùng dùng để kiểm thử 1 chức năng , gọi là vùng tương đương

- Đối với dữ liệu đầu vào , xác định các vùng tương đương từ miền dữ liệu

- Chọn dữ liệu đại diện cho mỗi vùng tương đương

- Kết hợp các dữ liệu thử bởi tích đề các để tạo ra bộ dữ liệu kiểm thử

* Nguyên tắc phân hoạch các vùng tương đương

Nếu dữ liệu vào phụ thuộc một khoảng, xây dựng o 1 vùng các giá trị lớn hơn o 1 vùng các giá trị nhỏ hơn o N các giá trị hợp lệ Nếu dữ liệu là tập hợp các giá trị, xây dựng o 1 vùng tập rỗng o 1 vùng quá nhiều các giá trị o N vùng hợp lệ Nếu dữ liệu đầu vào là điều kiện ràng buộc, xây dựng o 1 vùng các ràng buộc được thỏa mãn o 1 vùng với ràng buộc không được thỏa mãn

Ví dụ: Bài toán đặt vé theo giờ

=================9h30====h=====h30 Các vùng hợp lệ là vùng thuộc dấu (+) và vùng không hợp là vùng thuộc dấu (-)

Phân theo các vùng hợp lệ và không hợp lệ ta có 4 test case cho phân vùng tương đương: (0 – 9h30) , (9hh31 – 16h), (16h01 – 19h30), (19h31 – 23h59)

Phân tích giá tr ị biên - Boundary value analysis

Cơ sở: lỗi thường xuất hiện gần các giá trị biên của miền dữ liệu

Tập trung phân tích các giá trị biên của miền dữ liệu để xây dựng dữ liệu kiểm thử

Nguyên tắc kiểm thử các dữ liệu bao gồm:

- Giá trị gần kề lớn hơn giá trị nhỏ nhất

- Giá trị gần kề nhỏ hơn giá trị lớn nhất

Nguyên tắc chọn dữ liệu thử

- Nếu dữ liệu vào thuộc một khoảng, chọn :

4 giá trị = Giá trị biên ± sai số nhỏ nhất

- Nếu giá trị vào phụ thuộc danh sách các giá trị, chọn phần tử lớn thứ nhất , phần tử thứ hai, phần tử kế cuối , phần tử cuối

- Nếu dữ đầu vào là điều kiện ràng buộc số giá trị, chọn số giá trị tối thiểu và số giá trị tối đa và một số giá trị không hợp lệ

Ví dụ: Bài toán đặt vé theo giờ

Các vùng hợp lệ là vùng thuộc dấu (+) và vùng không hợp là vùng thuộc dấu (-)

Ta có 6 test case kiểm tra các giá trị biên: 9h29, 9h31, 5h59, 16h01,19h29 và 19h31

B ả ng quy ế t đị nh - Decision Table Bases testing

Làm giảm số lượng test casse không cần thiết so với 2 kỹ thuật trên vì nó loại trừ các phép kết hợp không cần thiết giữa các giá trị biến đầu vào

Liệt kê nguyên nhân (cause) – kết quả (result) trong một ma trận Mỗi cột ma trận đại diện cho 1 phép kết hợp giữa các cause trong trong việc tạo ra 1 result

Các bước để tạo bảng quyết định:

 Liệt kê các nguyên nhân trong bảng quyết định

 Tính tổng số lượng kết hợp giữa các cause

 Điền vào các cột với tất cả các kết hợp có thể có

 Rút bớt số lượng các phép kết hợp dư thừa

 Kiểm tra các phép kết hợp có bao phủ hết mọi trường hợp hay không

 Bổ xung kết quả vào bảng quyết định

Ví dụ: Bài toán đặt vé xem phim

1 Có thẻ Over 60s và có thẻ Family Rail Card và đi cùng trẻ em => được giảm 50%

2 Có thẻ Over 60s và không có thể Family Rail Card và đi cùng trẻ em => được giảm 34%

3 Có thẻ Over 60s và không đi cùng trẻ em => được giảm 34%

4 Không có thẻ Over 60s và có thẻ Family Rail Card và đi cùng trẻ em => được giảm 50%

5 Không có thẻ Over 60s và không có thẻ Family Rail Card và đi cùng trẻ em => được giảm 15%

6 Không có thẻ Over 60s và không đi cùng trẻ em => không được giảm Điều Kiện 1 2 3 4 5 6

Có thẻ Over 60s Y Y Y N N N đi cùng trẻ em Y Y N Y Y N

Bảng 1.1 Bài toán đặt vé xem phim Đồ th ị nguyên nhân k ế t qu ả

Là kỹ thuật thiết kế test case dựa trên đồ thị

Tập trung vào việc xác định các mối kết hợp giữa các điều kiện và kết quả mà các mối kết hợp mang lại

Các bước xây dựng đồ thị:

B1: Phân chia hệ thống thành vùng hoạt động

B2: Xác định nguyên nhân kết quả

B3: Chuyển nội dung ngữ nghĩa trong đặc tả thành đồ thị liên kết các cause và result

B4: Chuyển đổi đồ thị thành bảng quyết định

B5: Thiết lập danh sách test case từ bảng quyết định Mỗi test case tương ứng với 1 cột trong bảng quyết định

Ki ể m th ử d ự a trên đặ c t ả – Specification-based testing

Phương pháp kiểm thử dựa vào chức năng - Specification-based testing: Việc kiểm thử được tiến hành dựa vào việc kiểm thử chức năng của phần mềm xem nó có phù hợp với yêu cầu của người dùng hay không Vì vậy, các kiểm thử viên nhập dữ liệu vào phần mềm và chỉ cần xem kết quả của phần mềm và các mục tiêu test Mức test này thường yêu cầu các tester phải viết test case đầy đủ trước khi test, khi test, đơn giản chỉ cần thực hiện theo các bước mô tả trong test case thao tác và nhập dữ liệu vào, sau đó xem kết quả trả về hoặc hành vi của phần mềm, rồi so sánh với kết quả mong đợi đã được viết trong test case, điền kết quả test vào test case là OK (OK = is – chương trình làm đúng theo mong đợi) hay NG (not good = is not – chương trình không làm đúng theo mong đợi) Specification-based testing là cần thiết, nhưng nó không đủ để bảo đảm chắc chắn các rủi ro xảy ra (nó chỉ là điều điện cần chứ không phải là điều kiện đủ)

* Ưu, nhược điểm của kiểm thử hộp đen a)Ưu diểm:

- Tester 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ể

- Tester thực hiện trên quan điểm của người sử dụng

- Giúp phát hiện bất kỳ sự mơ hồ hoặc không nhất quán trong các đặc tả chức năng b)Nhược điểm:

- Chỉ có một số nhỏ các yếu tố đầu vào có thể thực sự có thể được thử nghiệm, để kiểm tra tất cả các dòng đầu vào có thể sẽ mất gần như mãi mãi

- Có thể để lại nhiều phần chương trình chưa được kiểm tra

1.7.2 Ki ể m th ử h ộ p tr ắ ng (White Box testing)

- Khác với kiểm thử hộp đen, kiểm thử hộp trắng xem xét mọi module trong chương trình, các luồng thực hiện công việc để từ đó đưa ra các chiến lược kế hoạch cụ thể cho việc kiểm thử

* Các kỹ thuật của kiểm thử hộp trắng:

Thiết kế quá trình kiểm tra sao cho mỗi câu lệnh của chương trình được thực hiện ít nhất một lần Phương pháp kiểm tra này xuất phát từ ý tưởng: Trừ khi một câu lệnh được thực hiện, nếu không ta không thể biết được có lỗi xảy ra trong câu lệnh đó hay không Nhưng việc kiểm tra với một giá trị đầu vào không đảm bảo là sẽ đúng cho mọi trường hợp Đườ ng d ẫ n (Branch)

Là phương pháp kiểm tra bao trùm mọi đường dẫn của chương trình và cần kết hợp với lược đồ tiến trình Ý tưởng: Viết đủ các ca kiểm thử mà mỗi quyết định có kết luận đúng hay sai ít nhất 1 lần Nói cách khác, mỗi hướng phân nhánh phải được xem xét kỹ lưỡng ít nhất 1 lần

Nhận xét: Phương pháp kiểm tra theo đường dẫn phụ thuộc nhiều vào các biểu thức điều kiện Tuy nhiên, có những trường hợp số lượng đường dẫn quá lớn (trường hợp vòng lặp) Vì vậy thường không phải là lựa chọn thực tế để tiến hành việc kiểm tra tính đúng đắn của chương trình

Các đ i ể m quy ế t đị nh (Decision)

Là phương pháp kiểm tra các biểu thức điều kiện trên 2 giá trị true và false

 Viết đủ các Ca kiểm thử để đảm bảo rằng mỗi điều kiện trong một quyết định đảm nhận tất cả các kết quả có thể ít nhất một lần

Nhận xét: Khi kiểm tra bằng phương pháp kiểm tra theo điều kiện cần xem xét kết hợp các điều kiện với nhau

Ta có 1 đoạn chương trình như sau:

Float calcRentalFee(Tape[] tapes, Customer customer){ float total = 0; for(int i = 0; i 5){ total *= 9;

Từ đoạn chương trình này ta chuyển qua sơ đồ khối như bên dưới

Vẽ thành theo sơ đồ khối:

Theo sơ đồ ta có thể thấy :

Có 2 test case theo Statement:

Và ở trường hợp này ta thấy số test case cho Decision và Branch giống nhau:

* Ư u, nh ượ c đ i ể m c ủ a White Box Testing a)Ư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ử b)Nhược điểm

- Yêu cầu người kiểm thử phải am hiểu cấu trúc mã lệnh chương trình Do đó đòi hỏi tài nguyên nhân lực và máy tốn kém

- 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

- Khó thực hiện và chi phí thực hiện cao

Các giai đoạn kiểm thử

Ki ể m th ử đơ n v ị (Unit test): kiểm thử từng module nhỏ trong chương trình để tìm ra các lỗi và khắc phục Kiểm thử đơn vị thường do 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 trong giai đoạn viết code và xuyên suốt chu kỳ phát triển phần mềm Thông thường, kiểm thử đơn vị đòi hỏi kiểm tra viên có kiến thức về thiết kế và code của chương trình Mục đích của kiểm thử đơn vị là bảo đảm thông tin được xử lý và xuất ra khỏi đơn vị là chính xác trong mối tương quan giữa dữ liệu nhập và chức năng của unit

Cũng như các mức kiểm tra khác, kiểm thử đơn vị cũng đòi hỏi phải chuẩn bị trước các tình huống (test case) hoặc kịch bản (script), trong đó chỉ định rõ dữ liệu vào, các bước thực hiện và dữ liệu mong chờ sẽ xuất ra Các test case và script này nên được giữ lại để tái sử dụng

Ki ể m th ử tích h ợ p (Integration Test): sau khi đã thực hiện thành công kiểm thử đơn vị, ta sẽ tiến hành tích hợp các module này với nhau và kiểm thử trên toàn bộ khối mã lệnh đã tích hợp này

Các mục tiêu chính của kiểm thử tích hợp bao gồm:

- Phát hiện lỗi giao tiếp xảy ra giữa các đơn vị

- Tích hợp các đơn vị đơn lẻ thành các hệ thống nhỏ (subsystem) và cuối cùng là nguyên hệ thống hoàn chỉnh (system) chuẩn bị cho kiểm tra ở mức hệ thống (System Test)

- Trong kiểm thử đơn vị, lập trình viên cố gắng phát hiện lỗi liên quan đến chức năng và cấu trúc nội tại của đơn vị Có một số phép kiểm tra đơn giản trên giao tiếp giữa đơn vị với các thành phần liên quan khác, tuy nhiên mọi giao tiếp liên quan đến đơn vị, thật sự được kiểm tra đầy đủ khi các đơn vị tích hợp với nhau trong khi thực hiện

- Kiểm thử tích hợp, trừ một số ít ngoại lệ, kiểm thử tích hợp chỉ nên thực hiện trên nhữ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 Một số người hiểu sai rằng một khi đã qua giai đoạn đơn vị Test với các giao tiếp giả lập thì không cần phải thực hiện kiểm thử tích hợp nữa Thực tế việc tích hợp giữa các Unit dẫn đến những tình huống hoàn toàn khác

Một chiến lược cần quan tâm trong kiểm thử tích hợp là nên tích hợp dần từng đơn vị Một đơn vị tại một thời điểm được tích hợp vào một nhóm các đơn vị khác mà nhóm các đơn vị đó đã được tích hợp trước đó và đã hoàn tất các đợt kiểm thử tích hợp trước đó Lúc này, ta chỉ cần kiểm tra giao tiếp của đơn vị mới thêm vào với hệ thống các đơn vị đã tích hợp trước đó, điều này làm cho số lượng kiểm tra sẽ giảm đi rất nhiều và sai sót sẽ giảm đáng kể

Ki ể m th ử h ệ th ố ng (System test)

Kiểm thử hệ thống bao gồm một loạt những kiểm nghiệm nhằm xác minh toàn bộ các thành phần của hệ thống được tích hợp một cách đúng đắn Mục đích của kiểm thử hệ thống là đảm bảo toàn bộ hệ thống hoạt động như khách hàng mong muốn

Kiểm thử hệ thống bắt đầu khi tất cả các bộ phận của phần mềm đã được tích hợp thành công Thông thường loại kiểm tra này tốn rất nhiều công sức và thời gian Trong nhiều trường hợp, việc kiểm tra đòi hỏi yên cầu phải có môi trường kiểm thử thích hợp Ví dụ như một số thiết bị phụ trợ, phần mềm hoặc phần cứng đặc thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân bố, hoặc hệ thống nhúng Ở mức độ của ST (system test) thì tester cũng tìm kiếm các lỗi, nhưng trọng tâm của loại kiểm thử này là đánh giá về chức năng, hoạt động, thao tác, sự tin cậy và các yêu cầu khác liên quan đến chất lượng của toàn hệ thống Điểm khác nhau then chốt giữa kiểm thử tích hợp và kiểm thử hệ thống là kiểm thử hệ thống chú trọng các hành vi và lỗi trên toàn hệ thống, còn kiểm thử tích hợp chú trọng sự giao tiếp giữa các thực thể hoặc đối tượng khi chúng làm việc cùng nhau Trong quy trình kiểm thử thì thông thường ta phải thực hiện kiểm thử đơn vị và kiểm thử tích hợp để đảm bảo mọi đơn vị và giao tiếp, tương tác giữa chúng hoạt động chính xác trước khi thực hiện kiểm thử hệ thống

Ki ể m th ử ch ấ p nh ậ n (Acceptance Test)

- Sau giai đoạn kiểm thử hệ thống là kiểm thử chấp nhận, đây là giai đoạn kiểm tra được khách hàng thực hiện Mục đích của kiểm thử chấp nhận là để chứng minh 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 và trả tiền thanh toán hợp đồng

- Kiểm thử chấp nhận có ý nghĩa hết sức quan trọng, mặc dù trong hầu hết mọi trường hợp, các phép kiểm tra của kiểm thử hệ thống và kiểm thử chấp nhận gần như tương tự, nhưng bản chất và cách thức thực hiện lại rất khác biệt

- Trên thực tế, nếu khách hàng không quan tâm và không tham gia vào quá trình phát triển phần mềm thì thường kết quả kiểm thử chấp nhận sẽ sai lệch rất lớn, mặc dù PM đã trải qua tất cả các kiểm tra trước đó Sự sai lệch này liên quan đến việc hiểu sai yêu cầu cũng như sự mong chờ của khách hàng Ví dụ đôi khi một PM xuất sắc vượt qua các phép kiểm tra về chức năng thực hiện bởi nhóm thực hiện dự án, nhưng khách hàng khi kiểm tra sau cùng vẫn thất vọng vì bố cục màn hình nghèo nàn, thao tác không tự nhiên, không theo tập quán sử dụng của khách hàng…

Mô hình kiểm thử

Hình 1.6 Mô hình kiểm thử

Sơ đồ tổ chức phổ biến của đội kiểm thử

Hình 1.7 Sơ đồ tổ chức phổ biến của đội kiểm thử

Dựa vào sơ đồ có thể thấy, những người liên quan đến việc kiểm thử phần mềm gồm có: Test Manager (Người Quản lý test), Test Leader (Nhóm trưởng test), Test Analyst (Người phân tích test), Test Designer (Người thiết kế test) và Tester (người trực tiếp test).

Quy trình kiểm thử phần mềm theo tiêu chuẩn CMMI5

Hình 1.8 Quy trình kiểm thử phần mềm theo tiêu chuẩn CMMI5

SRS: Software requirement specification (đặc tả yêu cầu phần mềm)

CR: Change request (thay đổi yêu cầu)

SAD: Software Architect Document ( tài kiệu kiến trúc phần mềm)

RA: Requirement attribute (thuộc tính yêu cầu)

Sau khi yêu cầu dự án được xác định và dự án đã có kế hoạch tổng thể, Test Manager hoặc Test Lead sẽ tiến hành lập kế hoạch test cho dự án

Kế hoạch kiểm thử cần chứa các thông tin sau

Phạm vi/mục tiêu kiểm thử

Các chiến lược được dùng

Các tài nguyên phần cứng và phần mềm phục vụ kiểm thử

Các nhu cầu về nhân viên và huấn luyện nhân viên

Các tính chất cần/không cần được kiểm thử

Các rủi ro hoặc sự cố bất ngờ

Lịch kiểm thử cụ thể

Các kênh thông tin liên lạc

Tiêu chí đầu vào và các tiêu chí dừng kiểm tra

Các kết quả phân phối

Nhận dạng các hoạt động kiểm thử nào là thủ công, kiểm thử nào là tự động hay cả hai Ước lượng chi phí kiểm thử và xây dựng lịch kiểm thử

Kế hoạch kiểm thử cần được

- Xem lại bởi Tester team, Developers, Bussiness Analyst, Test Architect (nếu cần), PM và Customer

- Chấp thuận bởi: PM và Customer

- Hiệu chỉnh trong suốt chu kỳ kiểm thử để phản ánh các thay đổi nếu cần thiết

Các bước lập kế hoạch kiểm thử

- Xác định yêu cầu kiểm thử : Chỉ định bộ phận, thành phần của phần mềm sẽ được kiểm tra, phạm vi hoặc giới hạn của việc kiểm tra Yêu cầu kiểm tra cũng được dùng để xác định nhu cầu nhân lực

- Khảo sát rủi ro: Các rủi ro có khả năng xảy ra làm chậm hoặc cản trở quá trình cũng như chất lượng kiểm tra Ví dụ: kỹ năng và kinh nghiệm của kiểm tra viên quá yếu, không hiểu rõ yêu cầu

- Xác định chiến lược kiểm tra : Chỉ định phương pháp tiếp cận để thực hiện việc kiểm tra, chỉ định các kỹ thuật và công cụ hỗ trợ kiểm tra, chỉ định các phương pháp dùng để đánh giá chất lượng kiểm tra cũng như điều kiện để xác định thời gian kiểm tra

- Xác định nhân lực,vật lực: Kỹ năng, kinh nghiệm của kiểm tra viên; phần cứng, phần mềm, công cụ, thiết bị giả lập… cần thiết cho việc kiểm tra

- Lập kế hoạch chi tiết : Uớc lượng thời gian, khối lượng công việc, xác định chi tiết các phần công việc, người thực hiện, thời gian tất cả các điểm mốc của quá trình kiểm tra

- Tổng hợp và tạo các bản kế hoạch kiểm tra : Kế hoạch chung và kế hoạch chi tiết

- Xem xét các kế hoạch kiểm tra: Phải có sự tham gia của tất cả những người có liên quan, kể cả trưởng dự án và có thể cả khách hàng Việc xem xét nhằm bảo đảm các kế hoạch là khả thi, cũng như để phát hiện (và sửa chữa sau đó) các sai sót trong các bản kế hoạch

1.11.2 Phân tích và thi ế t k ế test

- Tester tiến hành study spec (học đặc tả yêu cầu), sau đó sẽ viết quan điểm test, ước lượng được số case trong từng quan điểm

- Tiến hành lập test case hoặc thiết kế test script (nếu là kiểm thử tự động) dựa trên quan điểm test

- Sẽ thiết kế (định nghĩa) các test case từ các yêu cầu chức năng và các yêu cầu phi chức năng của phần mềm

- Các test case cần bao phủ tất cả khía cạnh kiểm thử cho từng yêu cầu phần mềm

- Các test case cần bao phủ tất cả yêu cầu trong các chiến lược kiểm thử

- Nếu cần kiểm thử tự động, Tester sẽ xây dựng các kịch bản dựa trên các testcase/ Test procedures

Các bước thiết kế test bao gồm

- Xác định và mô tả Test Case: xác định các điều kiện cần thiết lập trước và trong lúc kiểm tra Mô tả đối tượng hoặc dữ liệu đầu vào, mô tả các kết quả mong chờ sau khi kiểm tra

- Mô tả các bước chi tiết để kiểm tra: mô tả chi tiết để hoàn thành một Test Case khi thực hiện kiểm tra

- Xem xét và khảo sát độ bao phủ của việc kiểm thử

- Xem xét test case và các bước kiểm thử

Các test case cần được

 Xem xét lại bởi Project lead, developer có liên quan, các Testers khác, Test Lead, Business Analysis, và Customer

 Chấp thuận bởi Test lead hoặc Customer

 Hiệu chỉnh/cập nhật nếu Tester đã tìm được những lỗi mà không nằm trong các test case hiện có

1.11.4 Chu ẩ n b ị môi tr ườ ng test

Test Manager tiến hành thiết lập và cấu hình môi trường test dựa trên Test Plan được phê duyệt (thành viên dự án hỗ trợ thực hiện)

- Tester sẽ được bố trí công việc bởi Test Leader để tiến hành kiểm thử

- Tiến hành kiểm thử theo từng testcase

- Thực hiện kiểm thử đặc biệt (ad-hoc)

- Thực hiện kịch bản kiểm thử mà không được định nghĩa trong test case

- Kiểm tra lại các lỗi đã được fix

- Tester sẽ tạo các báo cáo về lỗi trong suốt quá trình kiểm lỗi và theo dõi chúng cho đến khi chúng đã được xử lý

- Ở công đoạn kiểm thử độ chấp nhận, Customer sẽ thi hành kiểm thử để kiểm định xem hệ thống phần mềm có thỏa mãn các nhu cầu người dùng không?

Test Manager sẽ tiến hành review và thực hiện hiệu chỉnh lỗi (bug) nếu cần thiết Thông báo cho các Tester những lỗi (bug) không đúng và Tester sẽ chuyển lỗi (bug) sang trạng thái “Cancel”

- Test Manager/Test Leader sẽ phân tích các lỗi trong hệ thống, theo dõi các lỗi

- Tạo các báo cáo lỗi

- Đánh giá các kết quả kiểm thử, thống kê các yêu cầu thay đổi

- Tính và phân phối các thông tin đo lường hoạt động kiểm thử

- Tạo bảng tổng kết đánh giá hoạt động kiểm lỗi thông qua file Test Summary Report

- Xác định xem đã đạt tiêu chí thành công và hoàn thành kiểm thử chưa.

Trách nhiệm của người kiểm thử

- Phân tích các yêu cầu

- Tham gia trong việc chuẩn bị test plans

- Chuẩn bị kịch bản test

- Chuẩn bị test case cho các modul, tích hợp và thử nghiệm hệ thống

- Chuẩn bị dữ liệu test

- Theo dõi kết quả test

Một số loại hình kiểm thử phổ biến

Hiện nay, do sự phát triển mạnh mẽ của công nghệ phần mềm nên có một số loại hình kiểm thử tiêu biểu như:

Kiểm thử các phần mềm trên Desktop: Đây là các ứng dụng được cài đặt trực tiếp trên máy tính cá nhân nhằm thực hiện các chức năng theo yêu cầu người dùng Đây vẫn đang là những ứng dụng phổ biến nhất

Kiểm thử Web hay kiểm thử trên đám mây: Với sự lớn mạnh của

Internet thì các ứng dụng web cũng ngày càng phát triển và đang dần thay thế các ứng dụng trên Desktop truyền thống như Google Document, Microsoft web apps,

Kiểm thử trên Mobile: Ngày nay xã hội với sự phát triển nhanh chóng, các thiết bị di động (điện thoại thông minh, máy tính bảng, ) có số lượng người dùng cũng đang tăng lên chóng mặt, cùng với đó là số lượng phần mềm phục vụ cho nhu cầu cũng tăng cao vì vậy đây là một lĩnh vực đầy tiềm năng và thách thức trong công nghệ phần mềm.

XÂY DỰNG WEBSITE “SHOP HOA ONLINE”

Đặt vấn đề

Xã hội ngày càng phát triển, kéo theo con người cũng từ đó mà trở nên bận rộn Nhưng dù bận rộn thế nào, những bó hoa tươi thắm tặng Mẹ, người yêu, hoặc bạn bè trong dịp lễ, sinh nhật… là không thể thiếu Vậy làm thế nào để chúng ta có thể dung hòa được 2 vấn đề đặt ra ở đây, là vừa không mất nhiều thời gian vừa thể hiện được tình cảm với đối phương?

Giải pháp

Với thời đại công nghệ thông tin thì để giải quyết vấn đề này quả thật là không khó Chúng ta có thể xây dựng một website bán hoa online, mà trong đó khách hàng có thể đặt hoa thông qua mạng internet, chỉ cần ngồi ở

1 nơi nào đó lúc rảnh rổi có thể bật điện thoại hoặc máy tính lên, vào website và lựa chọn những đóa hoa mình thích, sau đó nhấn vào nút mua hàng, sẽ có người ship đến tận nơi mà không cần tốn thời gian công sức đến tận shop để lựa chọn.

Đặc tả bài toán

Tính năng của hệ thống

* Tìm sản phẩm bằng thanh công cụ

Mô tả và mức độ ưu tiên

Chức năng cho phép người dùng tìm kiếm sản phẩm bằng thanh công cụ Yêu cầu chức năng

REQ-1: Hiển thị thanh tìm kiếm và button “Tìm Kiếm” trên trang chủ

REQ-2: User có thể nhập vào textbox và nhấn button “Tìm Kiếm” REQ-3: Tất cả sản phẩm được hiển thị theo điều kiện Search

REQ-4: Người dùng có thể xem chi tiết sản phẩm trên trang kết quả tìm kiếm

* Xem chi tiết sản phẩm

REQ-1: Trong danh sách kết quả, hình ảnh của sản phẩm được gắn liên kết, người dùng có thể nhấp vào nó để xem chi tiết sản phẩm

REQ-2: Chi tiết sản phẩm được mở ra cửa sổ mới

REQ-1: Hệ thống cập nhật giỏ hàng dựa trên các sản phẩm được lựa chọn trong danh sách kết quả tìm kiếm khi người dùng nhấp vào nút “Thêm vào giỏ hàng”

REQ-2: Hệ thống xóa Sản phẩm ra khỏi giỏ khi người dùng click vào nút “Xóa” các mục trên trang shopping

* Quản lý phiên làm việc - Đăng ký khách hàng

Yêu cầu về chức năng

REQ-1: Click vào nút đăng ký và input tất cả thông tin cần thiết vào các trường và nhấn button “Đăng ký”

REQ-2: Hệ thống sẽ kiểm tra các trường yêu cầu và định dạng của nó, như Email, mật khẩu, Tên đăng nhập, Số điện thoại

REQ-3: Hệ thống sẽ báo tin nhắn lỗi nếu đăng ký thất bại, và chuyển đến trang login khi đăng ký thành công

* Quản lý phiên làm việc-Đăng nhập

Khách hàng phải đăng nhập trước khi đặt hàng

Yêu cầu về chức năng

REQ-1: Hệ thống hiển thị textbox “Tên đăng nhập”, textbox “Mật khẩu” và button “Đăng nhập”

REQ-2: Hệ thống sẽ chuyển đến trang chủ nếu đăng nhập thành công REQ-3: Hệ thống sẽ show tin nhắn lỗi nếu đăng nhập thất bại

* Quản lý phiên làm việc-Đăng xuất

REQ-1: Người dùng click vào button “đăng xuất”

REQ-2: Hệ thống sẽ chuyển đến trang “đăng nhập” nếu “đăng xuất” thành công

* Quản lý sản phẩm-Thêm/Xóa/Sửa sản phẩm

REQ-1: Người dùng phải đăng nhập với quyền admin

REQ-1: Kiểm tra tránh trùng lặp sản phẩm trong cơ sở dữ liệu

REQ-2: Người dùng có thể thêm,xóa, cập nhật sản phẩm nhưng không được mua hàng

* Quản lý sản phẩm-Tìm sản phẩm Điều kiện

REQ-1: Người dùng phải đăng nhập với quyền admin

REQ-1: Người dùng có thể tìm kiếm theo loại hoa

REQ-2: Danh sách trả về cho phép người dùng lựa chọn để chỉnh sửa / xóa một sản phẩm trong trang quản trị.

Phân tích yêu cầu

Từ yêu cầu của hệ thống chúng ta có hai tác nhân chính đó là: Quản Trị viên và Khách hàng

Khách: Là người sử dụng bình thường, có quyền đặt hoa, xem thông tin hoa, Đăng ký, Đăng nhập

Quản trị viện: Là người quản lý hệ thống, có quyền quản lý đặt hoa, thông tin khách hàng,quản lý hoa, quản lý hóa đơn, quản lý khuyến mãi, quản lý loại hoa,

Uc1: Xóa thông tin Khách hàng

Gói Quản lý Khuyến Mãi

Gói quản lý hóa đơn

Gói quản lý loại hoa

Uc1: Xem thông tin hoa

2.4.3 Bi ể u đồ ca s ử d ụ ng ở m ứ c t ổ ng quát

Hình 2.1 Biểu đồ ca sử dụng ở mức tổng quát

Cơ sở dữ liệu của website “Shop hoa online”

a Bảng User b Bảng Nhóm hoa c Bảng Loại hoa d Bảng Khuyến mãi e Bảng Khách hàng f Bảng Hóa đơn g Bảng Hoa h Bảng Chi tiết hóa đơn k Bảng hình ảnh

Demo chương trình

Hình 2.2 Trang chủ b Giao diện danh mục sản phẩm

Hình 2.3 Trang Danh mục sản phẩm c Giao diện Admin

Hình 2.4 Trang Admin d Giao diện trang khuyến mãi

THIẾT KẾ TEST CASE VÀ THỰC THI TEST

Thực hiện Unit test

- Đưa lỗi lên hệ thống (nếu có)

Thực hiện test cho đoạn code được lấy từ chức năng “Đăng ký” trong hệ thống “Shop hoa online”