Hôm trước có bạn hỏi về các trường hợp trong Basic Design và Testing. Thực sự thì để chat trả lời … cũng được, nhưng mà cưỡi ngựa xem hoa, có khi bị tẩu hỏa vì nó khá phức tạp. Nay hơi rảnh tí nên type mấy dòng trả lời bạn như bên dưới.
V Model là gì
Trước tiên muốn hiểu về mối liên hệ thì cần nắm thật chắc V model trong phát triển phần mềm. Nếu tìm trên mạng các bạn sẽ thấy có … khá nhiều mô hình na ná nhau. Tất cả đều không sai, tuy nhiên đối với từng công ty sẽ có các quy định – qui trình khác nhau vậy nên cũng có chút biến tấu là điều dễ hiểu.
Về cơ bản V Model thể hiện mối tương quan giữa các công đoạn trong phát triển phần mềm từ khi định nghĩa yêu cầu cho tới hoàn thiện và đưa vào sử dụng. Trong đó nó chỉ rõ cho chúng ta biết phần test ứng với phần tài liệu nào, các bạn xem hình minh họa.
Mình chỉ bàn tới đây, còn bạn nào muốn tìm hiểu sâu về cách áp dụng có thể tìm thêm, trên mạng có đầy … đó là người ta nói chứ mình không nói vậy.
Basic Design và Integration Test
Basic Design viết tắt là BD, thiết kế ở mức cơ bản. Tức là từ RD chúng ta có được … chút ít thông tin về tính năng, ở phần này mọi người sẽ chia làm 3 mục để làm. 1 là BD cho screen, tức là vẽ layout màn hình, mô tả các item, 2 là BD cho API backend để xử lý logic, 3 là BD cho database, tùy khách hàng – công ty mà phần này có thể bao gồm Table Define, Procedure, Function, Triggers … hoặc chỉ bao gồm Table Define còn các phần kia cho vào Detail Design.
Integration Test : Là kiểm thử tích hợp, tích hợp cái gì ? nó là các module riêng lẻ mà ở phần UT đã được test OK, còn không OK thì test lại cho tới khi done hết mới được qua phần này. Sẽ có rất nhiều trường hợp từng cục thì ngon nhưng khi ghép lại 1 tảng là bug tè le xơ mướp. Lấy ví dụ cái xe đạp, chúng ta sẽ sản xuất bánh xa, tay cầm, phanh, xích, bàn đạp … Ở UT thì ta sẽ kiểm tra từng cái tăm xe từng chi tiết nhỏ nhỏ như các con ốc hay dây phanh, ruột phanh. Còn ở IT thì mình sẽ ghép tăm xe với vành xe, cho săm lốp vào bơm lên rồi cho cả cái bánh vào bắt vít lại. Vấn đề phát sinh ở chỗ này, từng cái thì ok, nhưng khi ghép lại bánh xe nó … méo, không nhét vào khung xe được. Rồi UT từng cái mắt xích, bàn đạp, xong rồi gắn lại IT thử coi quay cái bàn đạp thì bánh sau xe có quay không, quay thì pass. Còn ST với AT thì lắp hết cả cái xe, test tải trọng với người có cân nặng 70kg ngồi lên đạp được 10km với vận tốc 20km/h mà vẫn ngon lành, bánh xe không bị … bay ra giữa đường thì pass. Mấy cái như 70kg, 10km, 20km/h là yêu cầu của hệ thống được mô tả trong RD. Còn bánh xe có 2 cái, bánh trước và sau, có hình tròn, gồm vành xe bằng nhôm, săm lốp bằng cao su, tăm bằng thép mỗi item có kích thước là xxx thì mô tả trong BD.
Với hệ thống IT thì mình sẽ lấy ví dụ về màn hình nhập thông tin sản phẩm. 1 TestCase cho phần IT sẽ bao gồm các step như sau : từ menu click chức năng thêm sản phẩm, nhập thông tin, click button OK sẽ chuyển sang màn hình confirm, kiểm tra lại thông tin và nhấn submit thì hiển thị message thông báo thêm sản phẩm thành công.
Khi tạo BD cần có tài liệu về Screen Flow, Function Flow với từng điều kiện khác nhau (ví dụ như flow đăng sản phẩm, có loại mặt hàng đặc thù như … tên lửa thì cần có thêm 1 vài màn hình với các item chuyên dụng để nhập thông số chi tiết) để làm tiền đề cho việc phân chia IT test case sau này, tránh bỏ sót chức năng và pattern.
Requerement Define và System Test/ Acception Test
Với một số bạn chưa quen các khái niệm này thì mình cụ thể nó như sau.
Requirement Define : tức là định nghĩa yêu cầu, tham khảo thêm ở bài viết về định nghĩa yêu cầu trên blog. Nôm na thì nó mô tả toàn bộ project có bao nhiêu hệ thống con, mỗi con có chức năng gì, mối liên hệ như thế nào, Có bao nhiêu loại người dùng, dùng để làm gì và như thế nào. Hệ thống có cơ chế hạ tầng vận hành và bảo mật ra sao…
System Test : Kiểm thử hệ thống, tên tiếng việt là vậy nhưng mới đọc mà hiểu chít liền á ? tức là để 1 hệ thống chạy ổn bạn phải kiểm tra việc cài đặt – đăng nhập (quên mật khẩu, reset mật khẩu) – thực thi chức năng toàn diện – bảo mật – phục hồi (trường hợp treo hệ thống hoặc data bị lỗi …) tóm lại là trong hệ thống đó có cái gì thì test cái đó và test cả việc liên kết giữa các hệ thống với nhau vì 1 dự án sẽ có 1 hoặc nhiều system liên kết lại, VD như : Hệ thống dành cho người dùng thông thường, hệ thống cho đại lý, hệ thống cho Admin tổng …
Acception Test : Nghiệm thu. Thường là khách hàng sẽ làm, đôi khi họ nhờ … thì mình làm, nhưng nhớ là phải đưa vào estimate hoặc CR để còn tính bill. Ngay cái tên nói lên tất cả, để nghiệm thu OK thì tất tần tật mọi tính năng trong hệ thống đều phải đúng với yêu cầu ban đầu đã được mô tả trong RD.
Để dễ hình dung thì có vài ví dụ bên dưới. Về hệ thống thương mại điện tử có bên bán là các đại lý, bên mua là người dùng thông thường , admin quản trị hệ thống.
Pattern 1 :
RD mô tả : Chức năng đăng ký người dùng mới sẽ cần nhập thông tin về tên tuổi, nơi ở và thông tin liên lạc như số dt hoặc email. Trường hợp quên mật khẩu thì sẽ được reset và gửi về mail đã đăng ký – có hiệu lực trong 1 ngày, đối với những người dùng không có email thì phải xác nhận thông qua code gửi qua điện thoại đã được đăng ký – có hiệu lực trong 15p.
ST/AT : Scenario (tức là kịch bản)
Scenario 1 : Đăng ký người dùng mới, xác nhận tự động email và số điện thoại chính chủ và thực hiện Login thành công, thao tác được các chức năng ứng với role user đã đăng ký.
Scenario 2 : Thiết lập lại mật khẩu bằng Email
Scenario 3 : Thiết lập lại mật khẩu bằng Số điện thoại
Scenario 4 : Admin reset mật khẩu trường hợp hệ thống auto reset không hoạt động
Pattern 2 :
RD mô tả : Chức năng up hàng hóa với người dùng đại lý (người phân phối). Bắt đầu với việc login vào trang quản lý hàng, thêm sản phẩm, chọn category và nhập thông tin mô tả về sản phẩm đó, đặt giá cùng với phương thức vận chuyển, phương thức thanh toán và một vài option khác. Kiểm tra lại danh sách hàng hóa được hiển thị defautl thứ tự được sắp xếp theo ngày đăng, người dùng có thể chủ động sắp xếp tùy chọn theo danh mục hàng hoặc đơn giá, trạng thái hàng hóa (chưa bán, đã bán, đang chờ thanh toán, đang vận chuyển …). Đại lý có thể tùy chọn rút hàng xuống trường hợp trạng thái là đang bán, có thể hủy trạng thái đang chờ thanh toán nếu chờ quá lâu mà khách hàng chưa thanh toán. Với trường hợp trả sau thì nếu vận chuyển tới nhưng khách không nhận hàng thì có thể re-up lại hàng lên kệ.
ST/AT : Scenario
Scenario 1 : Đăng nhập vào hệ thống với user thuộc role đại lý, thực hiện chức năng thêm sản phẩm mới lên kệ hàng, sau đó vào kệ hàng để kiểm tra lại danh sách hàng hóa vừa đăng cũng như số hàng trước đó. Thực hiện sắp xếp theo từng option. Thực hiện tìm kiếm với các điều kiện tùy chọn.
Scenario 2 : Đăng nhập vào hệ thống user thuộc role đại lý, vào trang quản lý kệ hàng, thực hiện tìm kiếm đơn hàng đang chờ thanh toán, chọn đại 1 cái rồi hủy giao dịch. Quay lại kệ hàng và xác minh trạng thái sản phẩm đó đã được reset lại chưa.
Scenario 3 : Đăng nhập vào hệ thống user thuộc role đại lý, vào trang quản lý kệ hàng, thực hiện tìm kiếm đơn hàng đang vận chuyển, trường hợp vận chuyển quá 3 ngày (chuyển đi, người nhận hủy đơn, chuyển về lại kho) thì cho phép re-up, còn nếu không thì chức năng này bị disable, chọn đại 1 cái rồi re-up, sau đó lại vào trang quản lý để check trạng thái sản phẩm.
Scenario 4 : Thôi type mệt quá, dừng tay.
Kết
Trên đây là khái niệm cũng như 1 vài ví dụ để các bạn dễ phân biệt. Mình đưa ra cái V model cho các bạn dễ hình dung tính tương quan thôi chứ thực tế mô hình thác nước hay agile thì cũng có chung quan điểm in/out như vậy, chỉ khác nhau về trình tự và cách vận hành. Nếu còn thắc mắc thì tự tra thêm google nhé … đấy là người ta nói thế, còn mình luôn sẵn sàn đón nhận các câu hỏi, còn việc trả lời hay không thì hên xui, biết mới trả lời, còn im lặng là các bạn tự hiểu… đang bí.