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
Performance testing – Nó là cái quái gì mà lại dùng nó để vọc phá spiderum
Trước khi bắt đầu vào chiến dịch vọc phá spiderum thì bài viết này nhằm tổng hợp và định nghĩa một số khái niệm về testing cho những anh chị em ngoại đạo hiểu được hay mường tượng được về Performance testing mà mình nói ở bài viết giới thiệu trước nhé Các phương pháp test được phân chia dựa vào blackbox testing và whitebox testing. Hai phương pháp tiếp cận này được chú ý trong lúc thiết kế testcase. Test Case hay còn gọi là trường hợp thử nghiệm, là một tài liệu có một tập hợp các điều kiện hay hành động được thực hiện trên ứng dụng phần mềm để xác minh chức năng dự kiến của tính năng. Black box testing Là phương pháp test mà không biết bên trong code có những gì, thực hiện như thế nào. Phương pháp test này bao gồm:- Equivalence partitioning- Boundary value analysis- All-pairs testing- Fuzz testing- Model-based testing- Traceability matrix- Exploratory testing- Specification-based testing White box testing Phương pháp này ngược với black box testing, tester có thể thấy được cấu trúc và thuật toán bên trong phần mềmCác loại test được dùng trong whitebox testing:- Api testing – Kiểm tra ứng dụng sử dụng các Public API và Private API(API là các phương thức, giao thức kết nối với các thư viện và ứng dụng khác. Nó là viết tắt của Application Programming Interface – giao diện lập trình ứng dụng. API cung cấp khả năng cung cấp khả năng truy xuất đến một tập các hàm hay dùng. Và từ đó có thể trao đổi dữ liệu giữa các ứng dụng).- Code coverage – Kiểm tra các điều kiện bao phủ các câu lệnh- Fault injection. - Mutation testing. - Static testing – Bao gồm tất cả các phương pháp test tĩnh.- Code completeness evaluation Grey Box Testing Vài năm gần đây thuật ngữ grey box mới được dùng phổ biến. phương pháp này cho phép sử dụng cấu trúc và thuật toán bên trong chương trình để thiết kế testcase. Nhưng khi test thì tester thực hiện như blackbox. Kiểm thử phần mềm thôi mà coi bộ như đang bày binh bố trận thiên la địa võng vợt mấy chú dev ý nhỉ Bài viết trước mình có đề cập đến Unit test, đây cũng là 1 kỹ thuật nhưng dành cho dev kiểm thử function và thuộc phương pháp White Box Testing nhé. http://blog.ntechdevelopers.com/unit-test-chuyen-chang-cua-rieng-devs-nao/ Để hiểu rõ hơn bạn có thể nhìn hình dưới Testing chia thành 3 (4) loại testing, khác với bên trên nhé! bên trên là phương pháp testing.- Functional (Kiểm thử về chức năng)- Non-Functional (Kiểm thử ngoài chức năng)- Maintenance (Loại kiểm thử vào giai đoạn bảo trì) - Có những nơi thì tách cái này thành Confirmantion và Regression testing Bạn thấy đó cả 4 loại trên đều nằm trong phương pháp test Black box testing mình nói ban đầu.Đối với quá trình phát triển thì khâu kiểm thử này chia thành nhiều tầng theo từng giai đoạn nữa Đến đây bạn thấy đó, Performance testing  mà mình đề cập chỉ là 1 góc nhỏ xíu trong thế giới kiểm thử phần mềm. Và nó nằm trong loại kiểm thử Non-Functional. Thường thì nó không trực tiếp tạo ra giá trị cho sản phẩm nhưng mà khi nghiệm thu sản phẩm thì khách hàng lại rất rất quan tâm có khi còn bắt buộc đối với hệ thống lớn nữa Rồi chưa dừng ở đó, trong Performance testing lại còn chi thành nhiều phần nhỏ bên trong nữa cơ.  Ngoài lề một chút là mức lương của các chị gái kiểm thử sẽ tăng dần theo các cấp độ khó nhé- Manual testing - Kiểm thử bằng tay: Lương bạc trăm- Automation testing - Kiểm thử tự động: Lương bạc vạn- Performance tesing - Kiểm thử hiệu năng: Lương bạc triệu- Security testing - Kiểm thử hệ thống bảo mật: Lương bạc tỷ Tất nhiên là cấp độ testing dưới thì dường như phải bao hàm và biết cấp độ testing trên nên lương mới tăng như vậy rồi!Ai muốn tìm hiểu thêm về kiểm thử phần mềm thì mình để link ở dưới nhé! Nhắc lại lần nữa là mình không phải chuyên về testinghttps://www.guru99.com/non-functional-testing.html Quay về spiderum nhé, tại sao mình lại test thử spriderum với kỹ thuật performance testing. Haha, chẳng tại sao cả vì mình thích vọc vạch kiến thức mới ngoài code và mình muốn tổng hợp kiến thức sau quá trình tham gia dự án của mình với vai trò làm performance testing. Trước mình đã thử vai trò Automation testing rồi, có cơ hội mình sẽ chia sẻ ở loạt bài viết khác nhé. Bài viết hơi dài! Mình xin hẹn các bạn bài viết sau về chiến lược testing spiderum của mình nhé! Làm gì cũng phải có hoạch định chiến lược chứ!blog.ntechdevelopers.com
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

--
Bạn có thể theo dõi bài viết tiếp theo tại
http://blog.ntechdevelopers.com/len-ke-hoach-chien-luoc-kiem-thu-hieu-nang-spiderum/