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

Giai đoạn chuẩn bị môi trường trên thực tế sẽ tiến hành song song với giai đoạn thiết kế các test case và các thiết kế test. Người trưởng nhóm quản lý chất lượng sẽ giao công việc chuẩn bị môi trường cho một cán bộ chuyên trách thực hiện khảo sát môi trường phần cứng cũng như phần mềm trước khi mà thực thi test. Cán bộ chuyên trách dưới sự phân công của trưởng nhóm test sẽ tiến hành khảo sát môi trường dựa vào: bản đặc tả SRS, prototype( nếu có) …Và cuối cùng là điền kết quả khảo sát vào mẫu sau:

BIÊN BẢN GHI NHẬN KIỂM TRA MÔI TRƯỜNG

Máy số: ……………………………….Ngày: …../…./………………

Người sử dụng: ……………………………………………………………….

Phòng/Đơn vị: ……………………………………………………………….

Người khảo sát: ……………………………………………………………….

MÔI TRƯỜNG PHẦN CỨNG
Cấu hình máy CPU: …………………………………………………RAM: …………………………………………………HDD: …………………………………………………CD-ROM: ……………………………………………CD-RW: ………………………………..……………	2.Thiết bị khác[ ] LAN card: ……………………………………..[ ] ADSL: ………………………………….………[ ] HUB: …………………………………………..[ ] Khác: …………….…………………………….……………………………………………………….
MÔI TRƯỜNG PHẦN MỀM
1. Hệ điều hành[ ] Windows NT[ ] Windows 2000[ ] Windows 2003Loại khác: ………………………………………………………….. …………………………………..	Hệ quản trị [ ] Foxpro[ ] Oracle[ ] SQL Server[ ] AccessLoại khác:……………………………………………………..	Bộ gõ Tiếng việt [ ] TCVN[ ] VNI[ ] UnicodeLoại khác: ………………….………………………………………………………………
4. Phần mềm văn phòng/công cụ
[ ] MS Word[ ] MS Excel[ ] MS Access[ ] MS PowerPoint[ ] MS Visio	[ ] MS Outlook[ ] Outlook Express[ ] IE[ ] BKAV[ ] Norton ATV	[ ] Winzip, Winzar[ ] Công cụ quản lý lỗi[ ] Capture ảnhLoại khác:……………………………………………………..
5. Môi trường lập trình[ ] JDK[ ] Jbuider[ ] SQL Navigator[ ]……………………………….	6. Dữ liệu cần lưu trữ/thư mục gốc[ ] DOC, RTF [ ] E-mail[ ] XLS Khác: …̷ 0;………….……….[ ] MDB, dữ liệu ………..………….………….[ ] JPG, GIF, PPT ..……………………………..
7. Các ứng dụng cài trên máy chủ PQA[ ] Công cụ quản lý lỗi[ ] …………………………………….…[ ] …………………………………….…[ ]………………………………………..[ ]………………………………………..	Ghi chú, thông tin bổ sung: ……………………………………….……………………………………….……………………………………….……………………………………………………………………………….	Người thực hiện(Ký tên)……………………

Thực thi Test

Khái niệm Test chay

- Test chay là gì?

• Test không có tài liệu đầu vào
• Test nhằm phát hiện và sửa lỗi được chút nào hay chút ấy

- Khi nào chấp nhận test chay?

• Dự án quá gấp, không đủ thời gian cho nhóm phát triển lập tài liệu
• Requirements không thể được xác lập rõ ràng

- Làm gì để test chay có hiệu quả?

• Tích cực, mau chóng trao đổi với nhóm phát triển để nắm bắt được bài toán
• Tham khảo các sản phẩm tương tự, nếu có thể.
• Thống nhất với nhóm phát triển danh sách những vùng trọng tâm cần test
• Tranh thủ tiếp xúc với khách hàng, làm sáng tỏ những nghi vấn về yêu cầu, nghiệp vụ
• Lập checklist cho việc test, nếu kịp
• Tập trung test với cường độ cao
• Thường xuyên review Mức độ khẩn cấp của các lỗi.
• Làm các báo cáo ngắn và linh hoạt về tình trạng lỗi để thúc đẩy tiến độ fix lỗi.
• Tranh thủ xây dựng và tận dụng các testing checklist sẵn có

Test thế nào cho đủ

• Càng test càng tìm ra thêm lỗi, nhất là với các hệ thống lớn
• Vấn đề không phải là liệu tất cả các lỗi đã được tìm ra chưa, mà là liệu phần mềm đã đủ “tốt” để ngừng test hay chưa?
• Đó là một quyết định có tính “kinh tế”.
• Và là một trong những vấn đề khó nhất của testing.

Tìm câu trả lời:

• Khả năng tìm được thêm lỗi nếu tiếp tục test?
• Chi phí cận biên của việc đó?

• Khả năng NSD đụng phải các bug còn sót?
• Hậu quả những bug đó với NSD?

Kết luận:

• Không thể có câu trả lời chính xác mang tính công thức cho vấn đề trên
• Kinh nghiệm và cảm nhận cụ thể trong từng dự án, từng phần mềm vẫn là điều then chốt
• Tuy nhiên cần biết cần dành thời gian và nguồn lực cho những test nào trước, theo các cách sau

Ưu tiên phân bổ nguồn lực cho:

- Danh sách “where to focus testing”:

• Những vùng quan trọng nhất của phần mềm
• Những lỗi dễ xảy ra nhất
• Những lỗi (người dùng) dễ nhìn thấy nhất
• Những vùng phần mềm hay được dùng nhất
• Những vùng có đặc trưng riêng, khác biệt hẳn với các vùng khác của phần mềm.
• Những vùng phần mềm dễ bị ảnh hưởng nhất của các change vừa có (khi regression test).
• Những loại lỗi khó fix nhất
• Những loại lỗi mà tester biết rõ nhất
• Những loại lối mà tester biết l̖ 1; mờ nhất

• Positive test trước, negative test sau.
• Ưu tiên sắp xếp test theo quality dimension:
  • Số 1: thường là Function testing, và phải bao quát được busines cycle của hệ thống.
  • Số 2: Usability testing, chú ý test GUI, đảm bảo đúng syntax, theo standards và user friendly.
  • Số 3: security testing, installation testing, …
• Chọn lọc các test case hiệu quả:
  • Dùng kỹ thuật Equivalence class partitioning, chỉ lấy một vài test case đại diện cho từng class là đủ.
  • Dùng kỹ thuật Domain testing, chỉ lấy một số giá trị on và off là đủ.
  • Dùng kỹ thuật Loop testing, thì chỉ một số test case cho các trường hợp đi qua vòng lặp 0 lần, 1 lần, 2 lần, x lần và số lần tối đa ± 1 là đủ.
  • …- Chọn lọc các test case hiệu quả (tiếp):
  • Tính mức ưu tiên cho mỗi test case bằng cách xây dựng “Test Coverage matrix”
  • “Test Coverage matrix” map từng test case vào từng software feature
  • Cần ưu tiên những test case có liên quan đến nhiều feature nhất.
  • Thống kê hiệu quả của mỗi test case qua thời gian
  • Thu thập số liệu về số lỗi mà mỗi test case đem lại theo từng loại phần mềm, từng khoảng thời gian
  • Đào thải dần những test case đã “hao mòn hiệu quả”, tìm các test case mới thay thế.
  • Đánh giá xác suất lỗi còn tiềm ẩn:- Dựng đồ thị biếu diễn số lượng lỗi đã tìm thấy trong mỗi đơn vị thời gian

• có thể tạo cho mỗi loại bug một đồ thị dạng này, ví dụ tạo một đồ thị dạng này cho loại lỗi về Security – High Priority)
• Đồ thị đi xuống một cách tương đối ổn định, đạt một tần suất lỗi/đơn vị thời gian tương đối thấp là dấu hiệu tốt.

- Dựng đồ thị thống kế số lỗi tìm thấy trong mỗi phiên bản đã release của phần mềm

• Đồ thị đi xuống một cách tương đối ổn định là dấu hiệu tốt

- So sánh với mức xác suất còn lỗi sau khi release có thể chấp nhận

• Mức này được xác định một cách định tính, từ nhiều yếu tố mang tính business

Lưu kết quả Test trong Test Result và đưa ngay lên Bugtracker

- Test log:

Là tài liệu ghi lại theo trật tự thời gian những sự kiện test đã được thực hiện và kết quả.

- Test Result Report:

Tester

- Test Release Report:

Trong khi thực hiện test.

• Test result report là gì?
  • Là tài liệu báo cáo kết quả thực hiện test.
• Ai làm Test result report?
  • Tester
• Khi nào làm Test result report?
  • Sau khi thực hiện test xong một test item.
  • Sau khi test được một khoảng thời gian nào đó.
  • Sau khi test xong một lượt của toàn hệ thống hay một tiểu hệ thống.
  • Khi cần cung cấp thông tin cho người quản lý dự án
  • Khi Test leader yêu cầu
• Nội dung căn bản của Test result report
  • Giới thiệu tài liệu
  • Giới thiệu các test item mục tiêu
  • Các test case dự kiến thực hiện
  • Các test case đã thực hiện
  • Kết quả chi tiết của việc thực hiện từng test case
  • Thống kê tỉ lệ test case được thực hiện và tỉ lệ pass của các test case.
  • Đưa ra các change request
  • Ghi chú về các hiện tượng cần theo dõi thêm
• Test release report là gì?
  • Là tài liệu báo cáo kết quả test của sản phẩm, đánh giá chất lượng sản phẩm đã đủ tốt đ̓ 5; release hay chưa?
• Ai làm Test release report?
  • Test leader
• Khi nào làm Test release report?
  • Khi ngừng test một bản sản phẩm
  • Khi cần kết luận sản phẩm có thể được release hay chưa?
• Nội dung căn bản của Test Release Report
  • Giới thiệu tài liệu
  • Giới thiệu hệ thống được test
  • Khái quát về kết quả test:
    • Đánh giá chung về hệ thống được test, kết luận release hoặc không.
    • Đánh giá ảnh hường của môi trường kiểm tra
    • Các nhận xét khuyến nghị
  • Kết quả test chi tiết
  • Các phụ lục: thống kê số lỗi, số test case được thực hiện,…

Xử lý các vấn đề phát sinh trong quá trình Test