NỘI DUNG CHÍNH

NỘI DUNG CHÍNH
1. Test case là gi?
2. Các điểm chính trong Test case
3. Test plan là gì?
4. Các bước lập Test plan
5. Nội dung cơ bản của Test plan

1. TEST CASE LÀ GÌ
Giả sử bạn được yêu cầu liệt kê tấc cả các lỗi trong chức năng login của chương trình Toeic Mastery

"hinh" UPLOAD SAU

Vậy bạn cần làm gi?
+ Liệt kê tấc cả các đối tượng cần kiểm tra.
+ Tiến hành kiểm tra.
+ Kết quả mong chờ có đạt yêu cầu hay không?

Test case có thể xem là 1 tình huống kiểm tra, được thiết kế để kiểm tra 1 đối tượng có thoả yêu cầu đặt ra hay không.

2. CÁC PHẦN CƠ BẢN TRONG TEST CASE
+ Mô tả: đặc tả các điều kiện cần có để kiểm tra.
+ Nhập: đặc tả các đối tượng hay dữ liệu cần thiết, được sử dụng làm đầu vào để thực hiện việc kiểm tra.
+ Kết quả mong chờ: kết quả trả về từ đối tượng kiểm tra đạt yêu cầu hay không.

3. TEST PLAN LÀ GÌ
Test plan là kế hoạch kiểm tra. Nhằm để định hướng chính xác công việc cần làm trong qui trình kiểm tra phần mềm.

** MỤC ĐÍCH CỦA VIỆC LẬP TEST PLAN
Nhằm để đưa ra và mô tả tấc cả các loại kế hoạch kiểm tra sẽ được thực hiện trong qui trình kiểm tra.

4. CÁC BƯỚC CƠ BẢN ĐỂ LÂP TESR PLAN
- Xác định yêu cầu kiểm tra.
- Khảo sát rủi ro.
- Xác định chiến lược kiểm tra.
- Xác định nhân lực, vật lực cần thiết.
- Lập kế hoạch chi tiết.
- Tổng hợp và đưa ra kế hoạch kiểm tra.
- Xem xét các kế hoạch kiểm tra.

"hinh" UPLOAD SAU

5. NỘI DUNG CƠ BẢN CỦA TEST PLAN
** CHIẾN LƯỢC KIỂM TRA
- Chiến lược kiểm tra đưa ra phương pháp tiếp cận để kiểm tra mục tiêu.
- Chiến lược kiểm tra bao gồm các kỹ thuật được áp dụng và điều kiện để biết khi nào việc kiểm tra hoàn thành.
+ Mô tả các kiểu kiểm tra dùng trong dự án.
+ Có thể liệt kê với mỗi kiểu kiểm tra tương ứng kiểm tra cho chức năng nào.
+ Việc kiểm có thể dừng khi nào.

** CÁC KIỂU KIỂM TRA
Mỗi kiểu kiểm tra phải bao gồm các đìều kiện:
+ Kỹ thuật.
+ Điều kiện hoàn thành.
+ Các vấn đề đặc biệt liên quan.
* Kỹ thuật: Mô tả việc kiểm tra như thế nào, những gì sẽ được kiểm tra, các hoạt động chính được thực hiện trong quá trình kiểm tra và các phương pháp đánh giá kết quả.
* Điều kiện hoàn thành:
- Xác định chất lượng chương trình được chấp nhận.
- Thời điểm ktra hoàn tất.
* Các vấn đề đặc biệt: Các vấn đề gây ảnh hưởng đến việc kiểm tra.

1. Functional testing – kiểm tra chức năng
a. Function testing – kiểhom tra chức năng
b. User interface testing – kiểm tra giao diện người sử dụng
c. Data & database integrity testing – kiểm tra DL & tích hợp DL
d. Business cycle testing – kiểm tra chu trình nghiệp vụ

2. Performance testing – kiểm tra hiệu xuất
a. Performance profiling c. Stress testing
b. Load testing d. Volume testing

4. Security & Access control testing – kiểm tra bảo mật & kiểm soát truy cập
5. Regression testing – kiểm tra hồi qui

** MÔ TRƯỜNG KIỂM TRA
Tuỳ vào mỗi giai đoạn Unit test, Intergration test, System test, acceptance test sẽ ứnag với môi trờng kiểm tra nhất định. Từ đó xác định các yếu tố để xây dựng môi trường kiểm tra, sử dụng như môi trường thật hay tạo môi trường giả lập gần giống với môi trường chạy thật của chương trình.

- Khi test chạy chương trình bằng bản dịch hay chạy trên code. Thông thường, các giai đoạn System test, Acceptance test phải chạy trên bản dịch

- Với CSDL thì thông thường, từ Intergration test, ta phải thiết lập CSDL riêng và thiết lập các thông số cho CSDL gần giống hoặc giống hệt như khi chương trình sẽ chạy thật.

- Điều kiện về mạng: sẽ sử dụng mạng LAN hay Dial up… Thông thường, khi Unit test, có thể sử dụng mạng LAN nhưng khi System test trở đi thì nên sử dụng hệ thống đường truyền giống như hoặc gần giống như môi trường chạy thật.

- Mô hình sẽ cài đặt chương trình test: số lượng máy chủ, máy trạm; việc chia tách các server, các máy trạm, việc cài đặt các domain … Thông thường, trong Unit test có thể sử dụng viếc thiết lập như khi lập trình, nhưng khi System test trở đi, phải chú ý thiết lập sao cho gần giống mô hình sẽ chạy trong thực tế nhất
--

1. Test case là gì? các điểm chính trong testcase
- Test case là tài liệu mô tả tất cả các bước tester làm để tạo các tình huống có thể xảy ra và kiểm tra “phản ứng” của chương trình có đúng với kết quả mong muốn không. Một bộ test case thường gồm: Test Scenarios và Data test
- (theo kinh nghiệm của mình)Một Test Scenarios thường gồm các yếu tố cơ bản sau: Điều kiện ban đầu, mô tả các thao tác,các bước thực hiện, kết quả hiện tại, kết quả mong muốn. Test data là bộ dữ liệu test

2. Test plan là tài liệu dùng để:
•Xác định những thông tin dự án và các phần dự án cần được kiểm thử
•Liệt kê những yêu cầu kiểm thử (Test Requirements)
•Nêu ra những phương pháp, chiến lược kiểm thử nên sử dụng
•Xác định nguồn lực cần và tính công
•Liệt kê những kết quả, tài liệu có được sau khi thực hiện kiểm thử

3. Whilebox (hộp trắng)
Còn gọi là kiểm nghiệm cấu trúc. Kiểm nghiệm theo cách này là loại kiểm nghiệm sử dụng các thông tin về cấu trúc bên trong của ứng dụng. Việc kiểm nghiệm này dựa trên quá trình thực hiện xây dựng phần mềm.

Tiêu chuẩn của kiểm nghiệm hộp trắng phải đáp ứng các yêu cầu như sau:
-Bao phủ dòng lệnh: mỗi dòng lệnh ít nhất phải được thực thi 1 lần
-Bao phủ nhánh: mỗi nhánh trong sơ đồ điều khiển (control graph) phải được đi qua một lần.
-Bao phủ đường: tất cả các đường (path) từ điểm khởi tạo đến điểm cuối cùng trong sơ đồ dòng điều khiển phải được đi qua.
Phương pháp kiểm nghiệm white-box dựa trên:
-Các câu lệnh (statement)
-Đường dẫn (path)
-Các điều kiện (condition)
-Vòng lặp (loop)
-Ngã rẽ (branch)
-…


3. blackbox (hộp đen): Còn gọi là kiểm nghiệm chức năng. Việc kiểm nghiệm này được thực hiện mà không cần quan tâm đến các thiết kế và viết mã của chương trình. Kiểm nghiệm theo cách này chỉ quan tâm đến chức năng đã đề ra của chương trình. Vì vậy kiểm nghiệm loại này chỉ dựa vào bản mô tả chức năng của chương trình, xem chương trình có thực sự cung cấp đúng chức năng đã mô tả trong bản chức năng hay không mà thôi.
Các phương pháp blackbox:
• Phân chia tương đương
• Phân tích giá trị biên
• Đồ thị Cause – Effect
• Kiểm tra hành vi (Behavioural testing)
• Kiểm thử ngẫu nhiên
• Ước lượng lỗi ….

4.Khi nào thì dừng việc kiểm phần mềm?
- Khi không còn lỗi , trên thực tế không có 1 chương trình nào 100% không có bug (có bug nhưng có thể hoặc không có khả năng phts hiện thôi hihi) vì vậy chương trình luôn được test, trước tiên là tester sẽ thực hiện test, họ phải đảm bảo đúng yêu cầu khách hàng, tìm lỗi hệ thống, đụng độ dữ liệu, kể cả về thẩm mỹ...sau khi Tester hoàn tất việc test sẽ chuyển đến khách hàng test, nếu khách hàng không tìm thấy bug và nghiêm thu, khi đó Tester sẽ dừng test, nhưng phần mềm vẫn còn được test đó là người dùng phần mềm. Tóm lại, việc test phần mềm sẽ không bao giờ dừng, mà chỉ chuyển từ người test ngày sang nguời test khác mà thôi (cho đến khi phần mềm không còn được sử dụng, lúc đó mới dừng test). Câu hỏi đặt ra là test như thế nào cho đủ thì mới chính xác hơn là khi nào dừng test (có thể tham khảo phần 1.3 của link http://minhvi.aceboard.com/283095-535-4508-0-7892-QUAN-7872-TESTING.htm)

5. Mục đích của việc kiểm tra phần mềm?
- Mục đích của việc kiểm tra phần mềm là phát hiện lỗi, hỏng hóc, và những kiếm khuyết của phần mềm (kiểm thử phần mêm ko làm cho phần mềm hết lỗi mà chỉ tìm thấy lỗi của phần mềm, không làm cho phần mêm hoàn thiện mà chỉ tìm ra những điểm chưa hoàn thiện của phần mềm)

6. Testing nên bắt đầu từ giai đoạn nào?
- Tùy theo mô hình phát triên phần mềm của từng công ty. Tuy nhiên, Một dự án phát triển phần mềm thường trải qua các hoạt động sau đây:

- Phân tích yêu cầu.

- Thiết kế và lập trình.

- Testing.

- Bảo trì.


7. Quy trinh test?
-Tùy theo qui mô phát triển trùng công ty mà có nhưng qui trình kiểm thử khác nhau, Tuy nhiên thông thường 1 qui trình kiểm thử sẽ gồm các bước cơ bản sau:
+Lập kế hoạch test (Test Plan)
+Thiết kế test case (Test case Design)
+Thiết kế test (Test Design)
+Thực hiện test (Test Implimentation)
+Thẩm tra và đánh giá kết quả test (Valuate and Verify Test
Result)
+Tiếp nhận xử lý lỗi khách hàng trong quá trình dùng thử
(Acceptance Test)
+Lập kế hoạch và thực hiện test lại (Regression Test)