Bài giảng Kiểm thử phần mềm - Chương 1: Giới thiệu về kiểm thử phần mềm - Nguyễn Thanh Hùng

Giới thiệu về kiểm thử phần mềm 1 Kiểm thử phần mềm TS. Nguyễn Thanh Hùng Bộ môn Công Nghệ Phần Mềm Viện Công Nghệ Thông Tin và Truyền Thông Email: [email protected] Trường Đại Học Bách Khoa Hà Nội CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Mục tiêu môn học  Các khái niệm, định nghĩa về kiểm thử và chất lượng phần mềm  Các mức độ kiểm thử phần mềm  Các kỹ thuật, tiến trình kiểm thử  Hiểu và tạo được các trường hợp kiểm thử cho các chương trình đơn giản Quản lý chất lượng phần mềm 2 CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Kiến thức cần thiết  Ngôn ngữ (nói , hiểu, viết): tiếng việt, tiếng anh  Cơ bản của IT  Kỹ năng lập trình (debug và kiểm tra lỗi)  Cơ bản của SE, quy trình phát triển phần mềm  Ngôn ngữ mô tả lôgic ( phản ứng) : tiến trình algebra, state machines, petri nets.  Toán học:  Logic, tập hợp  Thống kê. 3 CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Tài liệu tham khảo  Ian Sommerville: “Software Engineering”, 7th Ed., 2004.  Roger S. Pressman: “Software Engineering: A Practitioner's Approach”, 6th Ed., McGraw-Hill, 2004.  John Musa: “Software Reliability Engineering”, McGraw-Hill 4 CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Q&A Kiểm thử phần mềm là gì? 5 Kiểm thử phần mềm là quá trình thực thi 1 hệ thống phần mềm để xác định xem phần mềm có đúng với đặc tả không và thực hiện trong môi trường như mong đợi hay không? CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Q&A Thú vị nghề kiểm thử phần mềm? 6  Nghề chuyên đi tìmlỗi.  Cảm giác rất “Yomost”! CuuDuongThanCong.com https://fb.com/tailieudientucntt Thuật ngữ 7 ERROR FAILURE FAULT TEST ? ? ? DEBUG CuuDuongThanCong.com https://fb.com/tailieudientucntt Chi phí thay đổi 4 Xác định yêu cầu 1x Phát triển 1.5-6x Sau khi đã phát hành 60-100x CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Mục tiêu  Khám phá nền tảng của kiểm thử phần mềm để mọi người hiểu 6 ý chính sau: 1. Các định nghĩa và chi phí của các khiếm khuyết (defect). 2. Các định nghĩa và mục tiêu của kiểm thử phần mềm. 3. Mục tiêu và quy trình làm việc của người kiểm thử. 4. Điều gì làm nên một người kiểm thử giỏi. 5. Thực tiễn của kiểm thử phần mềm. 6. Các thuật ngữ của kiểm thử phần mềm. 9 CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Ví dụ  Giả sử có một hàm của một phần mềm nào đó được xác định như sau: nextDate (tháng, ngày, năm): hàm mà kết quả đầu ra là ngày tiếp theo của ngày đầu vào. 1 ≤ tháng ≤ 12, 1 ≤ ngày ≤ 31,1900 ≤ năm ≤ 2060. Hàm này đã được cài đặt bởi ngôn ngữ java.  Nếu chỉ có các đặc tả và các file .class, làm thế nào có thể chắc chắn rằng hàm đó đã được cài đặt chính xác?  Nếu đã cài đặt hàm, có nghĩa là, có các file .java, làm thế nào có thể chắc chắn rằng code là chính xác? 6 CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Ví dụ 1 (1)  Nếu bạn có các đặc tả và các file.class, có lẽ có thể tiếp tục như sau: 1. Suy nghĩ một vài phút dựa trên các đặc tả và chọn ngày 2006/06/16 như là một đầu vào cho chương trình. 2. Bắt đầu chương trình. 3. Nhập 6 vào trường tháng, 16 vào trường ngày và 2006 vào trường năm. 4. Nhấp vào nút cho biết. 5. Xem kết quả: 2006/06/17. Cuối cùng: kết quả là chính xác như mong muốn. =>hàm đúng. - Giả sử: đầu vào là ngày 2006/12/31. + Lặp lại các bước từ 2 đến 5. + Kết quả: 1/32/2007. 11 CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Ví dụ 1(2) 12 B1: Mở giao diện Next Date B2: Nhập: 6 vào ô Month 16 vào ô Date 2006 vào ô Year B3: Click vào nút Tell và xem kết quả hiện lên là ngày 16/6/2006 CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Ví dụ 1(3) 13 B1: Mở giao diện Next Date. B2: Nhập: 12 vào ô month 31 vào ô Date 2006 vào ô Year B3:Click vào nút Tell và kết quả hiện lên là 32/1/2007 CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Ví dụ 2 (1)  Khi đã thực hiện 1 chức năng , tức là đã có mã nguồn của nó. Nhưng làm sao để biết được code đó là chính xác. Hãy xem ví dụ dưới đây : 14 CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Ví dụ 2 (2)  Để kiểm tra code, thì mỗi dòng sẽ được chạy ít nhất một lần. Nhưng file Year.java chỉ là một phần của chương trình, nó không thể chạy một mình. Vì vậy cần code thêm 1 đoạn để kiểm tra xem 1 năm nào đó có phải là năm nhuận hay không. 15 CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Kết luận  Hai ví dụ cho ta biết được rằng chắc chắn sẽ có một số sai lầm trong chương trình. Trong thử nghiệm phần mềm, đây được gọi là một lỗi(defect).  Những ví dụ này là hai phương pháp tiếp cận khác nhau, đều có thể áp dụng để tìm lỗi. Một được gọi là kiếm tra chức năng như trong ví dụ 1, ví dụ 2 được gọi là kiểm tra cấu trúc  Bây giờ bạn có thể tự hỏi mình rằng là lý do tại sao chúng ta phải tìm các lỗi(defect)? 16 CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Tại sao lỗi lại phát sinh trong phần mềm?  Phần mềm được tạo ra bởi chính chúng ta  Chúng ta có thể biết nhiều thứ những chúng ta không thể biết được tất cả mọi thứ.  Các lập trình viên đều có kỹ năng, nhưng không phải ai cũng hoàn hảo.  1 số lập trình viên không có những quy tắc khắt khe với các đoạn mã của mình.  Các lập trình viên là những người dễ gây ra sai sót (lỗi).  Làm việc dưới áp lực ngày càng tăng để đảm bảo đúng thời hạn  Không có thời gian để kiểm tra, các chức năng có thể bị làm sai.  Hệ thống có thể không đáp ứng đầy đủ các yêu cầu ban đầu.  Phần mềm thực sự phức tạp, trừu tượng và vô hình  Khó có thể xem phần mềm nếu nó là chưa hoàn chỉnh hoặc hoạt động thiếu chính xác.  Khó có ai có thể hiểu hết hoàn toàn 1 hệ thống lớn.  Quá nhiều giao diện bên ngoài không cần thiết. 17 CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Tại sao phải tìm kiếm các lỗi  Phần mềm được viết bởi con người. Và họ tạo ra những sai sót . Chi phí của các lỗi có thể là rất cao.  Từ góc nhìn của 1 người phát triển phần mềm: • Phải mất rất nhiều thời gian và nỗ lực để sửa chữa các lỗi. Một cuộc khảo sát cho thấy khoảng 50% thời gian làm việc của người lao động phần mềm được chi tiêu vào việc tìm kiếm và sửa lỗi. • Càng sớm tìm ra lỗi thì chúng ta càng tiết kiệm được chi phí • Bài giảng 11 sẽ có thông tin chi tiết hơn  Từ góc nhìn của 1 người dùng cuối: • Không ai thích 1 phần mềm mà sử dụng thì hay bị treo. • Với việc sử dụng nhiều hơn và thường xuyên hơn của phần mềm trong cuộc sống hàng ngày ,chúng ta cần các phần mềm có chất lượng hơn, đáng tin cậy hơn và an toàn hơn.  Kết luận  Phải cần kỹ thuật để tìm các lỗi và đó là mục đích của kiểm thử phần mềm 18 CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Nguồn gốc của các lỗi  Khâu định hướng  Người phát triển không hiểu họ đang làm gì  Thiếu sự đào tạo thích hợp dẫn đến lỗi trong đặc tả, thiết kế , coding và kiếm thử  Khâu kết nối  Người phát triển không đủ hiểu biết và các kiến thức cần thiết.  Thông tin không đạt được ở tất cả các bên liên quan.  Thông tin bị mất.  Khâu giám sát  Bỏ qua những thứ cần thiết 19 CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Lỗi (defect) là gì ? (1)  Định nghĩa về lỗi:  Không có 1 định nghĩa tiêu chuẩn  Các tổ chức khác nhau có những định nghĩa khác nhau.  Những điều được chấp nhận bởi các chuyên gia: 1. Các phần mềm không làm được cái gì đó mà nó nên làm 2. Các phần mềm làm 1 cái gì đó mà đặc tả bảo nó không nền làm 3. Làm cái gì đó mà đặc tả không đề cập đến 4. Các phần mềm không làm 1 cái gì đó mà các đặc điểm kĩ thuật không đề cập đến nhưng lại là nên làm 5. Phần mềm khó hiểu , khó sử dụng , chậm hoặc không đúng 20 CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Lỗi (defect) là gì ? (2)  Có nhiều thuật ngữ khác nhau được sử dụng để mô tả một lỗi..  Mâu thuẫn (Variance)  Bất thường (Anomaly)  Vấn đề (Problem)  Sai sót (Mistake)  Rắc rối (Incident)  Bug  Điều quan trọng là phải biết chia sẽ những hiểu biết của mình trong tổ chức hoặc nhóm làm việc 21 CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Kiểm thử phần mềm là gì  Định nghĩa kiểm thử phần mềm  Không có định nghĩa tiêu chuẩn  Các tổ chức khác nhau có định nghĩa khác nhau  Dưới đây là định nghĩa được chấp nhận bởi nhiều chuyên gia 1. Myers : kiểm thử là tiến trình thực hiện 1 chương trình với mục đích là tìm ra lỗi 2. IEEE[1990] : kiểm thử là tiến trình của hoạt động hệ thống hoặc thành phần theo điều kiện cụ thể, quan sát hoặc ghi lại kết quả, và tạo một đánh giá về một số khía cạnh của hệ thống hoặc một thành phần  Chú ý :  Testing quá trình để chứng minh phần mềm có khiếm khuyết  Các đối tượng được thử nghiệm không chỉ bao gồm các đoạn code mà còn là các sản phẩm sau mỗi pha phần mềm 22 CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Mục tiêu của kiểm thử phần mềm Mục tiêu: Về định nghĩa kết luận: Mục tiêu của kiểm thử phần mềm là tìm ra các lỗi (defect)của phần mềm. Về khảo sát chất lượng phần mềm: mục tiêu của kiểm thử phần mềm là tìm ra các lỗi của phần mềm nhiều nhất có thể.  Về khảo sát chi phí kiểm thử: mục tiêu của kiểm thử phần mềm là tìm ra các lỗi của phần mềm nhiều nhất có thể đúng hạn với tài nguyên cho phép. 23 CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Quá trình kiểm thử làm việc như thế nào? 24 CuuDuongThanCong.com https://fb.com/tailieudientucntt 25 Giới thiệ u về CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Định nghĩa 1 Trường hợp kiểm thử (Test case)  Định nghĩa:  1 tập các bài kiểm thử đầu vào, các điều kiện thực hiện, các kết quả mong đợi được phát triển là 1 phần của 1 Trường hợp kiểm thử (Test case)  Được cài đặt trong ngôn ngữ tự nhiên hoặc ngôn ngữ lập trình.  1 trường hợp kiểm thử chất lượng gồm 4 thuộc tính:  Hiệu quả tìm lỗi: tìm được lỗi hoặc ít nhất là khả năng tìm lỗi  Tiêu chuẩn: giảm số lượng các test case cần thiết.  Kinh tế: trong thể hiện,phân tích và gỡ rối.  Tiến hóa: hiệu quả của các trường hợp kiểm thử (Test case) cũ sau mỗi lần thay đổi phần mềm. 26 CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Cài đặt 1 Trường hợp kiểm thử (Test case)(1)  Trong ngôn ngữ tữ nhiên 27 Mã kiểm thử(Test ID): TestSample_ST_001 Độ ưu tiên (Priority): P1 Phần kiểm thử (Test Item): Hàm Next Date Các điều kiện thực hiện: 1. Chương trình có thể chạy Quy trình kiểm thử: 1.Chạy chương trình 2.Nhập 6 vào ô Month,16 vào ô Day,2006 vào ô Year 3.Click vào nút Tell Kết quả mong đợi: 1/1/2007 Kết quả thực hiện: CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Cài đặt 1 Trường hợp kiểm thử (2)  Cài đặt trường hợp kiêm thử (Test case) trong ngôn ngữ lập trình Java sử dụng Junit frame work (www.junit.org)  Hàm kiểm tra năm nhuận ( Leap): 28 CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Các yêu cầu cho nhân viên kiểm thử giỏi(1) Hãy ghi nhớ những điều dưới đây có thể có ích:  Nhân viên kiểm thử cần có các tính cách nghiệp vụ: thật thà, khách quan, trung thành.  Nhân viên kiểm thử cần tuyệt đối tin rằng có lỗi trong phần mềm, và sẽ tìm ra lỗi hoặc không có lỗi  Nhân viên kiểm thử cần phải được định hướng rõ ràng bởi vì lỗi không tự thể hiện ra.  Nhân viên kiểm thử nên có tính kiên trì. Phần lớn thời gian các nhân viên phải lặp đi lặp lại 1 hành động, như nhập dữ liệu hàng nghìn lần chỉ để tìm ra 1 lỗi  Nhân viên kiểm thử phải báo cáo lỗi không phát sinh. Vì các lỗi đó có thể dẫn tới lỗi không tránh khỏi 29 CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Các yêu cầu cho nhân viên kiểm thử giỏi(2) Hãy ghi nhớ những điều này có thể có ích:  Nhân viên kiểm nên khôn khéo, có khả năng thuyết phục báo cho lập trình viên rằng có lỗi, nếu không sẽ bị từ chối.  Nhân viên kiểm thử nên có tính tin cậy. Khi quyết định báo cáo 1 lỗi, phải bảo đảm sự tồn tại của lỗi.  Nhân viên kiểm thử phải giữ các bản báo cáo lỗi an toàn, nếu không nhiều sự nỗ lực sẽ lãng phí. 30 CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Thực tế của việc kiểm thử phần mềm Một nhân viên kiểm thử nên chú ý đến những điều sau đây: Kiểm thử không bao giờ hết hoàn toàn lỗi. Đã là một kiểm thử thì phải đưa ra lỗi. Càng xem xét kĩ các lỗi thì càng tìm ra nhiều lỗi ở đó. Kiểm thử không phải là bước cuối cùng. 31 CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010  Nếu muốn kiểm thử chức năng của máy tính bên, hãy nghĩ ra các khả năng về đầu ra cho nó: Vậy có vô số trường hợp xảy ra: 1.Số nguyên: từ 1+1 đến 99999999999999999999999999999 +99999999999999999999999999999. 2.Số thực: 1.0+0.1;1.0+0.2.vv 3. Bất kì đầu vào nào là tổ hợp của các số trên bàn tính. 4. Đối với phép trừ, nhân và chia. 32 Không thể kiểm thử hoàn toàn 1 phần mềm (1) CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Không thể kiểm thử hoàn toàn một phần mềm (3) Nguyên nhân:  Số lượng khả năng đầu vào rất lớn  Số lượng đầu ra rất lớn  Số lượng đường dẫn rất lớn  Đặc tả phần mềm là chủ quan: Lỗi này là do chính mắt mình nhìn ra. 33 CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Kiểm thử không thể không tìm ra lỗi Lí do:  Một phần mềm chắc chắn có lỗi.  Mục tiêu của kiểm thử phần mềm là tìm ra lỗi. Nếu một nhân viên nghĩ lỗi không tồn tại, đó là do anh ấy không tìm ra lỗi hoặc chưa tìm ra lỗi.  Hiện tại, có một vài cách nào để chắc chắn rằng một phần mềm hết lỗi. 34 CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Càng tìm càng ra nhiều lỗi Nguyên nhân:  Lập trình viên làm việc không tốt: Có những lúc không tập trung gây nên lỗi.  Lập trình viên mắc lỗi do chủ quan.  Tiên đề của kiểm thử là : Lỗi sau lỗi( Sau mỗi lỗi tìm thấy và được gỡ sẽ phát sinh nhiều lỗi khác). 35 CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Kiểm thử phần mềm không phải là bước cuối Nguyên nhân:  Kiểm thử không thể tìm tất cả lỗi.  Kiểm thử không thể cải thiện chất lượng phần mềm: Chỉ là tìm lỗi chứ không sửa lỗi.  Sự thành công của 1 dự án bao gồm thành công của tất cả các pha trong xây dựng phần mềm 36 CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Thuật ngữ và định nghĩa  Thuật ngữ:  Kiểm thử và gỡ rối  Thẩm định và kiểm tra  Kiểm thử động và tĩnh  Kiểm thử chức năng và kiểm thử hộp đen  Kiểm thử cấu trúc và kiểm thử hộp trắng 37 CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Kiểm thử và gỡ rối  Kiểm thử( Testing):  Kiểm thử là tiến trình hoạt động của một hệ thống hoặc một thành phần với điều kiện xác định; nhằm quan sát hoặc ghi lại các kết quả, và tạo ra sự cân bằng một vài khía cạnh của hệ thống hoặc thành phần.  Đích đến của kiểm thử phần mềm là tìm ra lỗi.  Gỡ rối( Debugging):  Tiến trình của xác định vị trí và sửa hoặc vượt qua lỗi trong mã chương trình hoặc kiến trúc phần cứng.  Sự khác nhau và quan hệ giữa chúng:  Kiểm thử là quá trình tìm lỗi trong khi gỡ rối để xác định vị trí và sửa lỗi.  Qui trình làm việc: Kiểm thử: Tìm lỗi-> Gỡ rối: Định vị, sửa lỗi -> Kiểm thử xác minh xem lỗi đã được sửa chưa?. 38 CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Sự kiểm chứng (Validation) và sự kiểm định (Verification)  Sự kiểm chứng(Validation) - Chúng ta có xây dựng một sản phẩm đúng?  Hệ thống xử lý đáp ứng yêu cầu khách hàng , cần thiết và mong đợi  Chúng ta có xây dựng sản phẩm đúng không?  Sự kiểm định(Verification) - Chúng ta có xây dựng đúng sản phẩm không?  Chương trình phù hợp với mô tả của nó  Chúng ta có xây dựng đúng sản phẩm không? 07/06/2019CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Kiểm thử hộp đen và hộp trắng Hộp đen (Black box)(chức năng, hành vi ,điều khiển dử liệu)  Phần mềm dưới sự cân nhắc kiểm tra như hộp đen và không có kiến thức của cấu trúc bên trong hoặc như thế nào mà phần mềm thực sự làm việc sử dụng trong khi kiểm thử  Hộp trắng (White box)(cấu trúc , điều khiển logic)  Kiểm thử dựa trên hiểu biết về cấu trúc bên trong của hệ thống và logic phần mềm 07/06/2019CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Mô hình chữ V 41 CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Các cấp độ kiểm thử khác nhau  Cấp độ đơn  Các khối xây dựng lên của hệ thống làm việc chính xác như qui định không?  Cấp độ hội nhập  Các khối đơn giản có làm phù hợp với nhau không?  Cấp độ hệ thống  Tất cả các hình thức xây dựng khối có làm việc hệ thống  Cấp độ chấp nhận  Hệ thống này có giải quyết các vấn đề của khách hàng?  Bên trong môi trường tính toán 07 /0 6/ CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Phân loại các kỹ thuật kiểm thử CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Phân loại dựa trên việc các test được tạo ra như thế nào? CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Kiểm thử và đảm bảo chất lượng phần mềm  Kiểm thử  Kiểm thử là quá trình hoạt động của hệ thống hoặc bên dưới thành phần quy định truyền thống , quan sát hoặc ghi lại kết quả , và tạo ra một đánh giá của 1 vài khía cạnh của hệ thống hoặc thành phần Đảm bảo chất lượng phần mềm  Sự thiết lập của hoạt động thiết kế tới đánh giá quá trình bới những người thiết kế phần mềm  Mục tiêu của SQA là đánh giá và cải thiện tiến trình  Khác nhau và quan hệ  Đối tượng làm việc của kiểm thử là phần mềm  Đối tượng làm việc của quản lý chất lượng là quá trình phát triển phần mềm 45 CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Tổng kết  Khiếm khuyết có thể tốn kém , tuy nhiên mục tiêu của phần mềm là tìm kiếm khiếm khuyết  Kiểm thử phần mềm có thể chỉ đưa ra những khiếm khuyết trong phần mềm  Người kiểm thử phần mềm sử dụng các trường hợp kiểm thử để tìm lỗi  Kiểm thử phần mềm không phải là ống cuối cùng của phần mềm 46 CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Homework  Đọc và tổng kết chương 2  Lựa chọn nhóm và làm dự án  Đọc 47 CuuDuongThanCong.com https://fb.com/tailieudientucntt @ ISR-CMU 2010 Q&A 48 CuuDuongThanCong.com https://fb.com/tailieudientucntt