Input:
o Yêu cầu của khách hàng và tiêu chí chấp nhận
o Yêu cầu về thay đổi
o Đặc tả yêu cầu phần mềm (Software Requirement Specification SRS) o Tài liệu thiết kế
o Chương trình (Modules)
Output:
o Tài liệu test: kế hoạch test, test cases và procedures, Test script, dữ liệu Test
o Danh sách lỗi o Mô tả thực hiện test o Báo cáo phân tích lỗi 4.2.3 Quản lý lỗi
Thông thường, lỗi phát hiện sẽ được quản lý trong các hệ thống quản lý lỗi (ví dụ RedMine, Jira,…). Một số lưu ý khi thực hiện ghi nhận lỗi:
o Lưu ý là 1 dự án có nhiều pha phát triển khác nhau, có nhiều chức năng trong hệ thống khác nhau => lúc log lỗi phải nói rõ là lỗi gì, thuộc chức năng nào? o Mục đích viết lỗi là để cho Developer/Leader đọc và hiểu được. Một ngày dev
có thể nhận được nhiều bugs, và phải thực hiện nhiều việc => cần viết ngắn gọn, rõ ràng, và có thể dễ dàng theo dõi chỉ từ subjects.
o Phải dùng từ ngữ thống nhất tránh gây hiểu lầm và dễ tìm kiếm nếu cần. Subject: cần chỉ rõ chức năng có lỗi, nội dung cụ thể của lỗi, Description: Mô tả rõ lỗi và đường đi tới lỗi
Ví dụ 2: lỗi điển hình và có liên quan tới dữ liệu
o Cần nhập rõ trình tự thực hiện và dữ liệu dẫn tới kết quả sai o Viết rõ kết quả thực hiện của chương trình
o Viết rõ kết quả mong muốn theo đặc tả
Ví dụ 3: cách log lỗi chưa tốt
Subject: không chỉ rõ điểm gây lỗi, mô tả lỗi chung chung Description: không mô tả rõ ràng vị trí gây lỗi
Hậu quả:
o developer không xác định được lỗi ở đâu (nhất là khi họ đang phải làm nhiều việc cùng lúc)
o các mô tả lỗi có subject giống giống nhau (trong khi có thể có hàng trăm, hàng nghìn lỗi trong hệ thống) nên dễ bị hiểu lầm là log trùng
Vòng đời lỗi
Sau khi tester tạo mới 1 lỗi, các thành viên trong đội dự án có thể thực hiện chỉnh sửa/từ chối và đổi trạng thái của lỗi. Một vòng trạng thái lỗi điển hình cho ở hình dưới, trong đó lập trình viên được gán lỗi có thể chấp nhận sửa lỗi hoặc từ chối nếu thấy đó không phải là lỗi; kiểm thử viên kiểm tra lại lỗi sau khi sửa và có thể chấp nhận để đóng lỗi hoặc yêu cầu sửa lại nếu việc sửa lỗi của lập trình viên không đáp ứng yêu cầu.
o
Hình 4-3: Vòng đời quản lý lỗi
4.3 Kế hoạch kiểm thử
Một số câu hỏi cần trả lời trong quá trình lập kế hoạch: • Test cái gì ?
• Ai thực hiện test?
• Thực hiện test ở chỗ nào ? • Khi nào kết thúc test?
-Test cái gì?
Quá trình kiểm thử sẽ giới thiệu đầy đủ kế hoạch kiểm thử, từ test đơn vị (unit test) đến test tích hợp (integration test) và test hệ thống (system test). Các yếu tố quyết định sẽ liên quan đến:
Các module nào sẽ được unit test Cách tích hợp cần được test.
Xác định rõ mức độ ưu tiên để phân bố tài nguyên test tới ứng dụng hệ thống phần mềm riêng rẽ.
+ Đánh giá các unit, integration và các application.
Các phương thức đánh giá cho các unit(module), integration và các ứng dụng để xác định rõ mức độ ưu tiên của chúng trong kế hoạch testing được dựa trên 2 yếu tố :
Yếu tố A: Mức thiệt hại ngiêm trọng. Độ nghiêm trọng trong trường hợp module hoặc ứng dụng thất bại.
Yếu tố B: Mức rủi ro của phần mềm. Mức độ rủi ro là xác suất xuất hiện thất bại. Để xác định mức rủi ro của một module, unit, integration hoặc ứng dụng, các vấn đề ảnh hưởng của rủi ro cần thẩm tra kĩ . Các vấn đề này có thể được phân loại như các vấn đề module/application và vấn đề người lập trình.
Các vấn đề ảnh hưởng tới mức rủi ro của phần mềm. Các vấn đề module/application
• Độ lớn
• Độ phức tạp và độ khó.
• Tỉ lệ của phần mềm gốc( với tỉ lệ phần mềm được dùng lại)
Vấn đề người lập trình
• Tính chuyên nghiệp
• Kinh nghiệm với các vấn đề của module cụ thể
• Tính khả dụng của hỗ trợ chuyên nghiệp ( việc sao lưu các kiến thức và kinh nghiệp)
• Sự hiểu biết của người lập trình và năng lực về khả năng đánh giá .
- Test được thực hiện bởi ai ?
Những người thực thi kiểm thử được xác định ở giai đoạn lập kế hoạch.
• Integration tests, đặc biệt là unit tests, thường được thực hiện bởi nhóm phát triển phần mềm.
• Sytem test thường xuyên được thực hiện bởi một nhóm test độc lập (trong nội bộ nhóm test hoặc cố vấn bên ngoài nhóm test).
• Trong trường hợp hệ thống phần mềm lớn, nhiều hơn một nhóm testing có thể được dùng để thực hiện các test hệ thống.
• Testing bởi nhóm phát triển khác. Mỗi nhóm phát triển sẽ coi như nhóm testing của dự án được phát triển cho các nhóm khác.
- Test được thực hiện ở đâu ?
Test đơn vị và test tích hợp được thực hiện ở phía người phát triển phần mềm. Khi test hệ thống: chúng nên thực hiện ở phía người phát triển hay phía khác hàng? Nếu test hệ thống là để được thực hiện bởi các tư vấn test bên ngoài, một lựa chọn thứ 3 phát sinh: phía người tư vấn. Lựa chọn phụ thuộc vào môi trường test hay môi trường hệ thống.
Tuy nhiên, môi trường máy tính ở phía khác hàng khác có thể khác với phía nhà phát triển. Trong trường hợp này, để giảm những lo ngại của khách hàng, hệ thống sẽ được cài đặt và kiểm thử ở phía khách hàng và không cần test chấp nhận nữa.
-Khi nào dừng test?
Quyết định khi nào quá trình kiểm thử kết thúc có ý nghĩa quan trọng nhất là với test hệ thống. Có nhiều hướng lựa chọn để có thể dừng test, mỗi lựa chọn dựa trên tiêu chí khác nhau, ví dụ như:
- Hướng hoàn tất thực thi . Theo hướng này, testing được hoàn thành khi toàn bộ kế hoạch test đã được thực hiện xong và sạch lỗi, kết quả đạt được cho tất cả các yêu cầu test. Đây là hướng lý tưởng, khi mà ta không bị giới hạn bởi ngân sách và thời gian. - Hướng áp dụng mô hình toán học. Ở hướng này, mô hình toán học được áp dụng để ước lượng tỉ lệ lỗi không bị phát hiện trên tỉ lệ lỗi được phát hiện. Testing sẽ hoàn thành khi tỉ lệ phát hiện lỗi giảm dưới mức chấp nhận được theo một chuẩn nào đó. Những bất lợi của hướng này là mô hình tính toán được lựa chọn có thể không đại diện hoàn toàn cho đặc trưng của dự án.
- Hướng các đội test độc lập. Hai đội test thực hiện test một cách độc lập. Bằng cách so sánh danh sách các lỗi được phát hiện của mỗi đội có thể đưa ra quyết định dừng quá trình test.
- Dừng khi hết tài nguyên. Với kiểu này việc dừng test sẽ xảy ra khi ngân sách hoặc thời gian được phân bố cho testing đã hết.
4.4 Thiết kế test (test design)
Các sản phẩm của giai đoạn thiết kế test là :
• Thiết kế chi tiết và các Thủ tục cho mỗi việc test. • Các tệp hoặc cơ sở dữ liệu của các test case.
Quá trình thiết kế test được tiến hành trên cơ sở của kế hoạch test phần mềm, lập tài liệu bởi STP (software test procedure). Các thủ tục test và cơ sở dữ liệu hay tệp test case có lập tài liệu trong một tài liệu “thủ tục test phần mềm” và “ test case file” hoặc trong một tài liệu đơn gọi là “mô tả test phần mềm” (STD). Một mẫu (template) của STD được trình bày như sau:
Mẫu mô tả test phần mềm (STD)
1.1 Các gói phần mềm được test ( name, version, và revision)
1.2 Các tài liệu cơ bản được cung cấp cho việc thiết kế test (tên và phiên bản của từng tài liệu)
• Môi trường test ( của mỗi test)
2.1 Định danh test ( các chi tiết test được viết tài liệu trong STP)
2.2 Mô tả chi tiết về hoạt động hệ thống và cấu hình phần cứng và yêu cầu chuyển đổi thiết lập test.
2.3 Hướng dẫn tải phần mềm. • Tiến trình test
3.1 Hướng dẫn cho đầu vào, mô tả chi tiết mỗi bước của tiến trình đầu vào. 3.2 Dữ liệu được ghi chép trong suốt quá trình test.
• Test cases (với mỗi case) 4.1 Chi tiết định danh test case
4.2 Dữ liệu Đầu vào và thiết lập hệ thống. 4.3 Kết quả trung gian mong đợi (nếu có)
4.4 Các kết quả mong đợi ( Số, thông điệp, sự kích hoạt thiết bị,...) Hành động trong trường hợp chương trình lỗi / kết thúc Thủ tục được áp dụng theo bản tóm tắt kết quả test. Ví dụ một bản test cases:
Pass Fail Untested
19 7 0
Mã Mô tả Quy trình ca kiểm thử Dữ liệu kiểm thử Kết quả mong muốn Kết quả thực tế Kết luận Người kiểm
thử Ngày kithửểm Chú thích 1 Kiểm thử giao diện màn hình quản lý danh mục cho vay 1. Chạy ứng dụng 2. Nhấp chuột vào mục "Quản Lý Khách Hàng"
'- Hiển thị màn hình "QUẢN LÝ THÔNG TIN KHÁCH HÀNG" với các thành phần sau:
+ Bảng danh mục thông tin gồm các trường thông tin: ô tích chọn, Số lưu ký,Họ và tên,Giới tính,Ngày sinh,Số CMND,Địa chỉ,Sốđiện thoại,Email,Trạng thái.. + 4 nút chức năng: Thêm, Sửa, Tra cứu,Phong tỏa/Giải tỏa. - Thứ tự tab: nút "Thêm" → "Sửa" →Tra cứu → Phong tỏa/Giải tỏa → .datagridview danh mục thông tin khách hàng
''- Hiển thị màn hình "QUẢN LÝ THÔNG TIN KHÁCH HÀNG" với các thành phần sau: + Bảng danh mục thông tin gồm các trường thông tin: ô tích chọn, Số lưu ký,Họ và tên,Giới tính,Ngày sinh,Số CMND,Địa chỉ,Sốđiện thoại,Email,Trạng thái.. + 4 nút chức năng: Thêm, Sửa, Tra cứu,Phong tỏa/Giải tỏa. - Thứ tự tab: datagridview danh mục thông tin khách hàng→ nút "Thêm" → "Sửa" →Tra cứu → Phong tỏa/Giải tỏa.Sai. Hãy sửa lại cho đúng
Fail xuandt 17/04/2016
2 Kiểm thử sự di chuyển của các nút chức năng
1. Tại màn hình "Quản lý thông tin khách hàng", nhấp chuột vào nút "Thêm" Hiển thị màn hình "Thêm mới tài khoản". Hiển thị màn hình "Thêm mới tài khoản". Pass xuandt 17/04/2016 3 Kiểm thử sự di chuyển của các nút chức năng 1. Tại màn hình "Thêm mới tài khoản", nhấp chuột vào nút "Hủy"
- Đóng màn hình "Thêm mới tài khoản". - Trở về màn hình "Quản lý thông tin khách hàng".
'- Đóng màn hình "Thêm mới tài khoản".
- Trở về màn hình "Quản lý thông tin khách hàng". Pass xuandt 17/04/2016 4 Kiểm thử sự di chuyển của các nút chức năng
1. Tại màn hình "Quản lý thông tin khách hàng", tích chọn một dòng trong danh mục quản lý thông tin khách hàng
2.Nhấp chuột vào nút "Sửa"
Các trường thông tin:Họ và tên,Giới tính,Ngày sinh,Số CMND,Địa chỉ,Số điện thoại,Email có thể sửa được
Các trường thông tin:Họ và tên,Giới tính,Ngày sinh,Số CMND,Địa chỉ,Số điện thoại,Email có thể sửa được
Pass xuandt 17/04/2016
Mã module QLTTKH
Yêu cầu kiểm thử Kiểm thử các chức năng trên màn hình quản lý thông tin khách hàng
Người kiểm thử
Số ca kiểm thử
26