Chuyển đến nội dung chính

Lý thuyết Automation test: Mô hình kim tự tháp có đúng?

Bài viết nói về mô hình kim tự tháp:

Test Unit > Testing Integration > Testing Accept

1 - Unit test
Đáy tháp, đây là mức test thấp nhấn, tưởng tượng nó là viên gạch!
Khi thực thi thì nếu ở code thì đây là mức test từng feature code hoặc procedure, function.
Goal ở đây là: chặn được các lỗi ở mức cơ bản nhất và đảm bảo unit làm đúng vai trò của mình.
Tưởng tượng như sau: viên gạch xây kim tự tháp thì unit test phải đảm bảo viên gạch này chịu được tải trọng 5kg, phơi khô không bị bể, đập không gãy đôi...

Còn về code: ví dụ hàm tính tổng, đảm bảo hai số nhập vô ra được số tổng ở mức hửu tỉ ! => Đừng đòi hỏi quá đáng ở hàm tính tổng như tính tới vô tỉ, tính toán tới vô cực (infinitive war)

2 - Integration mức Unit
Mức này với ví dụ Kim tự tháp thì giống dạng sử dụng keo dính xem 2 viên gạch nó nối lại được không...

Về mặt function thì đảm bảo các functions hoặc tính năng nhỏ gọi nhau không bị hư. Ví dụ làm hàm tính tổng dev chia thành 2 unit: xử lý input và tính tổng, việc integration này đảm bảo 2 unit này gọi nhau ổn định, không phát sinh ra lỗi.

3 - Integration mức System
Mức này thì cao hơn mức 2, tưởng tượng như: kim tự tháp Alecial gồm các khối kiến trúc: 2 con nhân sư, 1 cái quan tài, một số cái bẫy, một đoàn lính bảo vệ, 1 cái cửa ra vào... thì việc đảm bảo chất lượng là gắn mấy cái này vào cho khớp với nhau.

Về phần mềm thì đảm bảo cho mấy tính năng lớn trong hệ thống ăn khớp, phần mềm nhân sự thì đảm bảo chấm công cho người lao động đúng theo biểu đồ thời gian, kể cả khi có sự kiện đặc biệt như: lễ tết...

Phần này thường thì QC tham gia vào nhiều nhất để đảm bảo chất lượng phần mềm

4 - Testing Acceptance
 Phần này thì đưa pharaong vào kim tự tháp xem nằm vô hòm ổn không =)). Không ổn thì bắt dân phu trảm đi, xây cái mới...

Phần mềm thì đưa cho khách hàng xài và lấy tiền, nếu khách hàng thấy ổn thì sử dụng tiếp, sau đó đến giai đoạn cù cưa lâu lâu trả tiền 1 lần của KH...

Tựu chung lại là mô hình kim tự tháp có đúng? - Về cơ bản nếu làm đúng quy trình này thì mức độ lỗi của kim tự tháp ít, nó sẽ thành một phần mềm kỳ quan thế giới!

Nhưng thực tế cho thấy thì do quá tốn chi phí làm và vận hành chưa kể yếu tố khách quan của kiến trúc sư phần mềm (vẽ ra kim tự tháp hay chùa một cột) mà mô hình này sinh ra nhiều yếu tố bất lợi !

Nhận xét

Bài đăng phổ biến từ blog này

Hướng dẫn cơ bản về chẩn đoán mã lỗi OBD 2 trên ô tô

OBD2 - DTCs    1) Diagnostic Trouble Code (DTC) là gì? DTC hay còn gọi là mã lỗi là những mã được lưu trữ trong máy tính của xe hơi. Mỗi xe hơi hiện đại từ 1994 trở đi đều được trang bị một hộp đen có chứa máy tính, máy tính này có nhiệm vụ chẩn đoán tình trạng hiện tại của xe nhằm đảm bảo xe được vận hành an toàn không gây nguy hiểm cho người sử dụng (Ví dụ: nếu máy tính này phát hiện thắng xe đang có lỗi nó sẽ cảnh báo và không cho người dùng sử dụng xe). Mỗi mã được lưu trữ mang một ý nghĩa nhất định và chỉ ra nơi đang gặp vấn đề trong xe. Kỹ sư ô tô dựa vào đó để tìm và sửa lỗi. Mã lỗi này có thể đọc được bằng cách dùng thiết bị đọc mã lỗi do các bên thứ ba phát hành. Hiện tại trên thị trường có rất nhiều loại thiết bị đọc mã lỗi với các tính năng khác nhau. 2) DTC có đáng tin cậy không? Câu trả lời là: Có và không! Có vì nó chỉ ra những mã lỗi một cách dã chiến nhất theo ý hiểu của máy tính (Cá nhân tôi gọi là ngu ngốc). Ví dụ: nếu một bộ phận cảm biến nà...

Dùng Jira Quản lý testcase

Jira là bộ công cụ quản lý bug và công việc hiệu quả theo mô hình Agile framework, SCRUM (scrum là lý thuyết). Khi ta dùng Jira kết hợp với việc quản lý testcase: 1. Lợi ích và nhược điểm trong việc quản lý testcase dùng Jira. Jira phát triển một hệ thống software inside tools, có khả năng kết nối với các công cụ của MS như Excel, Word,... nên hầu như mọi công ty khi team test phát triển hệ thống đều kết nối MS Excel làm testcase list và Jira làm task links. Ưu điểm: nhanh gọn, excel viết testcase nhanh thông dụng, đánh kết quả tốt chỉ cần 1 template chuẩn cho việc này. Khuyết điểm: Jira testcase attach, việc tìm kiếm nội dung không tốt nếu triển khai Jira team không thành công. 2. Tester dùng Jira. Tester dùng Jira như một member và chạy task trên Project. Thường một task dev thì tester chia 3 loại: - Create test case - Prepare data test - Execution test Trong một vài công ty lớn chuyên nghiệp thì họ chia thêm một số việc như: Thực thi test môi trường thử nghiệm, môi trường pilot...

Bảy nguyên tắc cơ bản của Kiểm thử phần mềm

Nội dung: nói và diễn giải về bảy nguyên tắc cơ bản trong testing software. Bài này là bài lý thuyết bổ sung và tester phải nắm được nằm lòng các nguyên tắc này! Bảy nguyên tắc (như khẩu huyết trong võ công): Kiểm thử tất cả mọi trường hợp là không thể được. ( EXHAUSTIVE testing is not possible ). Giải thích như sau: Một form có textbox cho phép nhập từ 1 -> 1.000.000.000.000. Nếu để kiểm thử nhập liệu cho textbox này ta phải kiểm thử 1k tỷ lần. Mỗi thao tác nhập cho là 1 giây, và phép toán kiểm tra nhập liệu là 0.1 giây nữa thì ta phải mất xấp xỉ 1k tỷ giây là khoảng 31k năm để thực thi nó. Đời người chỉ khoảng một trăm năm, vậy phải mất cả mấy nghìn đời để thực thi kiểm tra một textbox mà chưa kể đến nhiều đối tượng khác cho nên mới nói điều này là không thể làm được! (Chi phí nuôi nghìn người và giá trị bỏ ra là không xứng). Để xử lý thì ta: dùng kỹ thuật phân vùng tương đương, Phân nhánh nghiệp vụ, chia lớp xử lý... (Sẽ nói chi tiết sau). Kiểm thử là chỉ ra sai sót đang có ...