#3 Chiến lược kiểm thử hiệu năng Spiderum – Kịch bản chức năng

Bài viết trước mình đã giới thiệu về performance testing, một kỹ thuật nho nhỏ trong 1 thế giới kiểm thử rộng lớn.
Bạn có thể đọc lại tại
http://blog.ntechdevelopers.com/performance-testing-no-la-cai-quai-gi-ma-lai-dung-no-de-voc-pha-spiderum/

Bài viết này mình sẽ nói sơ bộ về chiến lược chạy performance testing trên trang spiderum.

Bắt đầu thôi!

Đầu tiên nếu bạn nhìn vào mind map

Manual testing

Bạn hình dung để tiếp cận một website, đặc biệt là một website mà mình không nằm trong đội ngũ phát triển phần mềm đó, tức là mình một bên thứ ba độc lập kiểm thử thì mình phải tiếp cận website đó đầu tiên.

Một cái nhìn tổng quát sẽ giúp bạn hiển được website đó làm về lĩnh vực gì (domain), nó được xếp vào thể loại nào (diễn đàn, blog, giao dịch, thương mại điện tử…)

Tiếp đó, bạn phải nắm được các tính năng (features) hoặc ít nhất là chức năng chính mà bạn muốn test. Đi dạo qua một vòng spiderum mình đã liệt kê được các chức năng chính của nó như sau

• Đăng ký
• Đăng nhập, đăng xuất
• Quên mật khẩu
• Thông báo
• Bình luận
• Tạo mới, cập nhật, xoá bài viết
• Upvote/downvote các bài viết
• Ngoài ra còn các chức năng tìm kiếm (theo tag, tên bài viết, tác giả)

Bạn có thấy điểm gì khi mình liệt kê tính năng của trang không?

Dường như mình không chú trọng vào những tính năng lấy dữ liệu (get data) hiển thị lên màn hình (GUI) như hiển thị bài viết, đếm lượt vote, đếm số bình luận, đếm số thông báo, mà mình lại chú trọng đến những chức năng có đầu vào (input). Đơn giản chỉ có input mới  hay phát sinh ra những lỗi nghiêm trọng, chứ giờ mình nói tính năng vote kia đếm sai thì 1 account khác không phải account admin không có đội ngũ phần mềm thì khó lòng đánh giá được nó đúng hay nó sai hoặc những chức năng cơ bản đó thì đội ngũ kiểm thử nội bộ chắc đã duyệt qua. Vậy nên chủ yếu mình lướt qua tính năng chỉ để đánh giá sơ bộ và điểm đặc biệt quan trọng là ghi chú tạo kịch bản (scenario) để có thể viết script peformance (mã chạy kiểm thử hiệu suất) ở phần sau

Một ghi chú nữa mình thấy được khi dạo quanh spiderum đó là cách tính số spiders. Đối với đội ngũ thứ 3 không hề biết quy luật gì về cách tính này nên mình đoán là nó có một thuật toán tính toán nào đó

Bên cạch đó còn có gợi ý hiển thị bài cho mỗi account riêng, khi mới tạo tài khoản mới, spiderum bắt bạn phải chọn ít nhất một topic chủ đề là nhằm mục đích suggestion gợi ý hiển thị các bài viết giúp bạn đọc tiếp cận các bài viết dễ hơn. Mình cũng đánh giá nó là một thuật toán sâu xa nào đó

Nói sâu hơn chút về vấn đề lên kịch bản (scenario) nhé!

Test scenario: một quá trình thử nghiệm toàn diện (tức là trên tất cả mọi khía cạnh, mọi hoàn cảnh) là bất khả thi bởi khối lượng dữ liệu khổng lồ chồng chéo và những đường hướng phức tạp trong phần mềm.

Test Scenario bao gồm tất cả các chức năng có thể được kiểm thử. Test Scenario cũng được gọi là Test Condition hoặc Test Possibility

Là một tester, bạn có thể đặt mình vào vị trí của người dùng cuối và tìm ra các tình huống trong thực tế và các trường hợp có thể xảy ra của ứng dụng đang được kiểm thử.

Ở bài trước mình có nhắc tới Testcase, mình nhắc lại một chút. Test case là một tập hợp các điều kiện hoặc các biến mà tester sẽ xác định xem liệu một ứng dụng, một hệ thống phần mềm hay một trong những chức năng của nó có chạy đúng như nó được thiết lập theo mục đích vốn có hay không.

Test Case được ví như những đơn vị nhỏ nhất của từng test project, như các tế bào của một cơ thể sống.

Trong khi đó Test Scenario đi sâu hơn vào chi tiết của từng feature. Test Scenario mô tả cái cần test, lưu ý là cái cần test.

Api testing

Chắc mình sẽ viết tiếp chiến lược này ở bài sau nhé!. Khá dài và cần chỉnh sửa một chút nên hẹn gặp lại các bạn