Kiểm thử Phần Mềm

Get Started. It's Free
or sign up with your email address
Kiểm thử Phần Mềm by Mind Map: Kiểm thử Phần Mềm

1. Testing là gì? - Là người tìm ra lỗi của phầm mềm/ hệ thống

2. Vai trò KTPM

2.1. - Ngăn ngừa và tìm ra lỗi sản phẩm

2.2. - Đánh giá và đảm bảo chất lượng của SP

2.3. - Tham gia và đưa ý tưởng cải thiện sản phẩm

3. Nhiệm vụ của 1 Tester

3.1. - Đọc- hiểu yêu cầu của dự án

3.2. - Phải viết ra được yêu cầu dưới dạng testcase( kịch bản kiểm thử

3.3. - Thực hiện các testcase đó và tìm ra Bug( lỗi)

3.3.1. Lỗi trong KTPM

3.3.1.1. Layout: lỗi về giao diện hệ thống/web (GUI: hiển thị giao diện các trường)

3.3.1.2. Font: phông chữ, chính tả

3.3.1.3. Color: Màu sắc

3.3.1.4. Content: Nội dung của 1 hệ thống/ website

3.3.1.5. Functional testing: Lỗi chức năng (chức năng đăng nhập

3.3.1.6. Validate: check dữ liệu các trường

3.3.1.6.1. Hợp Lệ

3.3.1.6.2. không hợp lệ

3.3.2. Cách Viết Bug(Cấu trúc của 1 Bug)

3.3.2.1. Ngày/Tháng viết ra bug đó

3.3.2.2. Đưa con Bug này cho ai:

3.3.2.3. Status:

3.3.2.3.1. Mới Viết: New

3.3.2.3.2. Sau khi đưa cho Dev là open

3.3.2.3.3. Dev đã sửa lỗi gọi là Fix

3.3.2.4. Title: Tiêu đề- Quan trọng Nhất của Bug để hiểu được bug đó đang bị gì , lỗi ở đâu

3.3.2.5. Mô tả tiêu đề

3.3.2.6. Môi trường xảy ra Bug

3.3.2.7. Các bước để Dev tìm ra lỗi đó

3.3.2.7.1. B1: mở vao màn hình đăng nhập

3.3.2.7.2. B2: nhấn vào nút này nút kia

3.3.2.7.3. B3....

3.3.2.8. Kết quả mong đợi: mình mong muốn con bug đó khi kiểm tra sẽ có kết quả như thế nào

3.3.2.9. Kết quả trả về: kết quả thực tế sau khi kiểm tra bug đó

3.3.2.10. Severity và Priority: Mức độ nghiêm trọng và mức độ ưu tiên

3.4. - sau khi Dev fix lỗi xong kiểm tra lại lần nữa

4. Quy Trình KTPM

4.1. Lập Kế Hoạch -> Phân Tích Yêu Cầu của KH -> Testcase( Thiết kế kịch bản)- Developer( Xây dựng, phát triển sản phẩm -> Testing -> Bảo trì, bảo dưỡng

5. Cấp độ kiểm thử

5.1. Unit Testing: kiểm thử đơn vị- Cấp độ này sẽ do đội Dev thực hiện- kiểm tra bên trong các hàm, cod(whitebox testing)

5.2. intergration Testing: Kiểm thử tích hợp- khi đội Dev bàn giao thành công, đội Tes sẽ tích hợp các module lại với nhau xem còn lỗi hay không

5.3. System testing: Kiểm tra hệ thống- kiểm tra lại hoàn bộ hệ thống, xem các module làm việc với các hệ thống khác có lỗi hay không

5.4. Acceptance testing: kiểm thử chấp nhận- Kiểm tra lại hệ thống xem đã đáp ứng đúng đủ yêu cầu của KH chưa, việc này cả Tes và KH sẽ làm việc cùng nhau

6. Các P2 kiểm thử

6.1. Blackbox Testing: không cần xử lý bên trong, cchir quan tâm đầu vào và đầu ra- VD như cái bút chỉ cần quan tâm hình thức, mực viết được

6.2. Whitebox Testing: Thực Hiện bên trong, xử lý code

6.3. Compatibility testing: kiểm thử tương thích(tích hợp)- xem hệ thống mình có tương tích với nhưng hệ thống khác ko

6.4. Localization testing: kiểm thử địa phương hóa- xem thửu khi chuyển sang ngôn ngữ khác thì tấ cả ở trên hệ thống có chuyển sang ngôn ngữ đó ko

6.5. performace testing: kiểm thử độ ổn định(kiểm thửu hiệu năng) - hệ thống phải đáp ứng, phục vụ đủ chức năng, số lượng nhất định- Công cụ hỗ trợ: Jmeter

6.6. Usability testing: kiểm thử mức độ tiện lợi

6.7. Secutity testing: kiểm thử độ bảo mật

7. Mô hình kiểm thử

7.1. Thác nước: ứng dụng vào các dự án nhỏ, ngắn hạn hoặc các dự án ít yêu cầu/ không có những yêu cầu rõ ràng

7.2. Xoắn ốc: Thường sử dụng cho các ứng dụng lớn và các hệ thống được xây dựng theo các gđ nhỏ hoặc theo các phân đoạn

7.3. Agile( Linh Hoạt- Nhanh Lẹ) : có thể sử dụng ở bất kì dự án nào, nhưng cần sự tương tác và tham gia của KH, sử dụng khi KH yêu cầu chức năng sẵn sàng trong thời gian ngắn

7.4. Tiếp cận lặp: Các dự án lớn và nhiệm vụ quan trọng, yêu cầu chính phải được xác định

7.5. Tăng trưởng: Áp dụng cho những dự án có yêu cầu đã được mô tả định nghĩa và hiểu 1 cách rõ ràng- khách hàng có nhu cầu về sp sớm

7.6. Chữ V: Yêu cầu đã được xác định rõ ràng, xcs định sản phẩm ổn định, công nghệ không thay đổi và được hiểu rõ bởi nhóm dự án,

7.7. - Scum

7.8. RAD: Module hóa rõ ràng( nếu dự án ko được chia thành các module, RAD có thể không thành công- nên được sử dụng khi có nhu cầu để tạo ra 1 hệ thống có ycau KH thay đổi trong khoảng tgian nhỏ 2-3 tháng- nên sử dụng khi đã có sẵn thiết kế cho model và chi phí cao

8. Automation là gì? Là kiểm tra tự động giảm thời gian làm việc thủ công...- lương cao hơn manual testing - giới thiệu 1 tí

9. 1 số từ khóa chuyên ngành

9.1. PM= Project manager: giống như người quản lý dự án

9.2. BA= Business Analyst: là người phân tích yêu cầu của dự ấn, gặ trực tiếp khách hàng, chi tiết hóa yêu cầu và bàn giao lại cho Dev- Tes

9.3. Dev= Developer: xây dựng, phát triển

9.3.1. Frontent (FE) làm giao diện

9.3.2. Backend( BE) xử lý đằng sau

9.4. QC= Quality control= Tester: Ngăn lỗi, tìm lỗi

9.5. Designer: Thiết kế, vẽ giao diện dựa vào yêu cầu của KH

9.6. QA: Quality Assurance: Giám sát chất lượng chung của toàn bộ công ty

9.7. Issue: lỗ hổng

9.8. Bug: Lỗi

9.9. Status: trạng thái của module

9.10. Assignee: khi thấy Bug, thì phải đưa cho 1 người nào đó có khả năng xử lý

9.11. SRS: sofware prepiment specipiticion: khi có BA/PM làm việc với KH sẽ ra tài liệu này, tất cả phải theo dõi nếu như có xung đột sẽ dựa vào tài liệu

9.12. Q&A: liệt kê những câu hỏi ko hiểu trong dụ án với những bộ phận hiểu câu hỏi

9.13. Due date: thời gian muộn nhất phải hoàn thành

9.14. Expected Result: các mong muốn phải đúng theo yêu cầu