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

Định dạng
Số trang	56
Dung lượng	3,34 MB