I. Mục đích của testing
- Testing là gì? "Testing là quá trình chạy thử một chương trình nhằm tìm ra lỗi"
- Mục đích của testing? "Để tìm lỗi!"
- Testing có thể chứng minh được sự có mặt có lỗi, nhưng không thể chứng minh được sự vắng mặt của lỗi
- Vậy test để làm gì? "Để chứng minh phần mềm hoạt động được? Để chứng minh phần mềm không hoạt động được? Làm giảm khả năng phần mềm không hoạt động tới mức chấp nhận được"
- Testing là một nghề đòi hỏi trí tuệ nhằm đem lại một phần mềm ít rủi ro mà không tốn quá nhiều công sức cho việc test
- Đặc điểm của testing?
* Phải giả định là phần mềm có lỗi
* Lấy mục tiêu là break phần mềm chứ không phải chỉ ra phần mềm đang hoạt động đúng
* Không bao giờ được kết luận rằng phần mềm không còn lỗi
* Bản thân việc test không nâng cao chất lượng phần mềm
* Để nâng cao chât lượng phần mềm, cần phát triển tốt hơn, thay vì test nhiều hơn!
- Cái khó của testing là gì?
* Là biết khi nào thì dừng lại
* Là quyết định thực hiện những testcase nào cho hiệu quả
- Thuật ngữ
* Testcase: Là một tập hợp các giá trị đầu vào, các điều kiện thực hiện, các bước thực hiện và kết quả mong muốn để test phần mềm
* Testcase hiệu quả: là testcase mà khi thực hiện thì đem lại lỗi!
II. Mô hình chữ V
- Testing phải
* Bắt đầu bằng xác định mục tiêu
* Phải có kế hoạch (tester nên được tham gia vào phần mềm ngay từ đầu, testplan nên được lập càng sớm càng tốt, sẽ là quá muộn nếu lập testplan khi phần mềm đã hình thành)
III. Vai trò của các Tester
- Vai trò của các Tester độc lập:
* Tổ chức, bố trí testers cho các các dự án
* Độc lập báo cáo về chất lượng và mức độ hoàn thành các phần mềm
* Trao đổi kinh nghiệm, bồi dưỡng kỹ thuật testing cho các thành viên trong nhóm
- Tổ chức nhóm Tester theo dự án
* Các Role test trong một dự án
Test leader: làm test plan, test evaluation report phân công/ quản lý test member,
Test designer: Thiết kế testcase, sắp xếp thứ tự test
Test worker: Thực hiện test, là test result report
* Số Tester trong một dự án : >=1
* Tester = test designer + test worker
- Vai trò của Test Leader
* Giao việc và giám sát công việc các test members
* Đảm bảo các testcase giao cho các members được thiết kế đúng, thực hiện đủ
* Đảm bảo tất cả các lỗi được log lên phần mềm ghi lỗi
* Đảm bảo tất cả các lỗi Fixed phải được test lại
* Review, hỗ trợ chuyên môn cho members
* Đảm bảo việc test được thực hiện đúng kế hoạch, đúng tiến độ, với đầy đủ các tài liệu test cần thiết
* Chịu trách nhiệm báo cáo về sản phẩm được test
* Báo cáo công việc của nhóm lên quản lý
- Vai trò của Test member
* Thiết kế testcase và phân mức ưu tiên thực hiện
* Thực thi các testcase
* Log lỗi, theo dõi lỗi, trực tiếp trao đổi với Dev
* Làm báo cáo về các testcase được giao
* Hỗ trợ test leader làm test plan
IV. Khái niệm phân loại test
1.Phương pháp tiếp cận kiểm thử
- White box testing : test dựa trên cấu trúc của mã nguồn
- Black box testing : test dựa trên hành vi của hệ thống
2. Các giai đoạn kiểm thử
- Unit testing: được thực hiện bởi Dev, sử dụng phương pháp white box testing
- Integration testing : test các liên kết giữa các unit thành phần, gồm 3 cách integration ( top-down, bottom-up và big-bang)
Notes: Integration đòi hỏi các module phải được unit test trước, nếu có nhiều lỗi lẽ ra phải tìm thấy từ unit testing thì ngừng integration testing và trả module nhiều lỗi về cho Dev
- System testing : Khi integration testing đã hoàn tất, sử dụng phương pháp black box testing, test dựa trên requirements, do Tester thực hiện độc lập
- Acceptance testing : Chứng minh phần mềm đã đủ sẵn sàng để bàn giao cho khách hàng, các thủ tục test/ demo phải được khách hàng chấp nhận trước khi thực hiện nghiệm thu
- Regression testing: Khi bảo trì hay nâng cấp lên version mới, hoặc khi tích hợp các phần của một phần mềm.
3. Các loại kiểm thử
- Functionality : áp dụng ở mọi giai đoạn kiểm thử
- Usability : áp dụng ở giai đoạn system testing
- Reliability: áp dụng ở giai đoạn system testing
- Performance : áp dụng ở giai đoạn system testing
- Supportability : áp dụng ở giai đoạn system testing
V. Các kỹ thuật kiểm thử
1. Equivalence class partitioning
- Phân các testcase vào các class. Mỗi class là một nhóm các testcase tương tự nhau
- Trong mỗi class, chọn một vài testcase để test
- Nên test nhiều class thay cho test nhiều testcase của cùng một class
- Các loại class có thể xếp vào hai nhóm :
* Positive tests : test dựa trên những yêu cầu đã xác định, test những trường hợp, hoàn cảnh sử dụng thông thường
* Negative tests: test nhằm tìm ra lỗi, test những trường hợp, hoàn cảnh bất thường
- Ví dụ:
2. Control flow testing
- Sử dụng control flow graph
- Áp dụng cho mọi giai đoạn kiểm thử
3. Data flow testing
- Áp dụng cho các hệ thống data-intensive (ví dụ hệ thống báo cáo, thống kê, tính toán thay đổi số liệu)
- Lập data flow diagram, bắt đầu từ node output lần ngược lại khi gặp node input, ta được một testcase
4. Transaction testing
- Áp dụng cho các hệ thống xử lý giao dịch (ví dụ đặt vé máy bay, đặt phòng khách sạn)
- Sử dụng mô hình xử lý của hệ thống, lưu ý điểm đầu và điểm cuối của từng xử lý, hàng đợi
5. Domain testing
- Áp dụng cho các xử lý có xác định phạm vi giá trị dữ liệu
- Lưu ý test các giá trị biên, on/off
6. Loop testing
- Áp dụng trong white box testing (chú ý vòng lặp trong mã nguồn)
- Áp dụng trong black box testing (chú ý vòng lặp trong hành vi của hệ thống)
7. Syntax testing
- Dùng để test các câu lệnh, test các trường phải tuân theo một định dạng nhất định ( ví dụ ngày tháng, email, công thức toán ...)
- Thực hiện : nắm rõ các quy tắc syntax, sử dụng equivalence class partioning để thiết kế positive và negative testcase
8. State machine testing
- Áp dụng khi test các hệ thống có sơ đồ chuyển đổi trạng thái, các hệ thống thiết kế bằng phương pháp hướng đối tượng, khi test các menu driven application
- Phương pháp: vẽ một sơ đồ chuyển đổi trạng thái cho đối tượng cần test, thiết kế positive và negative testcase
9. Load and tress testing
- Load testing: Bắt hệ thống phải chịu tải lớn (ví dụ nhiều client cùng lúc truy cập, xử lý file lớn...)
- Stress testing : Bắt hệ thống vận hành trong điều kiện bất thường (ví dụ thiếu bộ nhớ, mất mạng khi đang vận hành, server down...)
VI. Test thế nào cho đủ
- Không thể có câu trả lời chính xác, phụ thuộc vào cảm nhận và kinh nghiệm trong từng dự án, từng phần mềm.
- Cần biết cách dành thời gian và nguồn lực cho những test nào trước theo các cách dưới đây
1. Ưu tiên phân bổ nguồn lực cho
- Danh sách ưu tiên (những vùng quan trọng nhất của phần mềm, những vùng phần mềm hay được dùng nhất, những lỗi dễ xảy ra nhất, những lỗi dễ nhìn thấy nhất, những vùng có đặc trưng riêng, những vùng dễ bị ảnh hưởng khi có các thay đổi, những loại lỗi mà tester biết rõ nhất, những loại lỗi khó fix nhất)
- Positive trước, negative sau
- Ưu tiên sắp xếp theo thứ tự
số 1. Thường là Functional testing
số 2. Usability testing (chú ý GUI đảm bảo đúng syntax, theo chuẩn, và thân thiện với người dùng) .
số 3. Security testing, installation testing....
2. Chọn lọc các testcase hiệu quả
- Dùng kỹ thuật Equivalence class partitioning, chỉ lấy 1 vài testcase đại diện cho từng class là đủ
- Dùng phương pháp Domain testing, chỉ lấy 1 số giá trị on/off là đủ
- Dùng kỹ thuật Loop testing, chỉ cần lấy 1 số testcase đi qua vòng lặp 0 lần, 1 lần, 2 lần và max +/-1 lần là đủ.
VII. Các tài liệu test
1.Test plan
2.Test Design Spec
3.Testcase Spec
4.Test Procedure Spec
5.Test Log
6. Test result report
7. Test release report
Notes:
-Test Plan/ Design:
*Xác định môi trường và các testcase sẽ thực hiện
*Chỉ ra khối lượng test sẽ thực hiện
*Giúp xác định được khi nào thì test xong
- Test report:
*Báo cáo kết quả test thực sự, đối chiếu với test plan
*Đưa ra đánh giá kết luận về độ tin cậy của chất lượng sản phẩm
*Cho biết kế hoạch test đã được thực hiện trọn vẹn hay chưa
No comments:
Post a Comment