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é

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ềm
Cá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. 
Unit test, chuyện chẳng của riêng devs nào!
Câu chuyện về unit test cho mỗi dev thì chẳng phải của riêng ai, nhất là khi bạn còn phải cover cả unit test cho những function của những người đồng đội của mình. Nếu ai đó chưa biết về unit test thì mình có thể định nghĩa nhanh và đơn giản như sau: Trong kiểm thử phần mềm có 4 mức độ kiểm thử: Unit test ( kiểm thử mức đơn vị), Intergration test ( kiểm thử tích hợp), System test (kiểm thử hệ thống), Acceptance test (kiểm thử chấp nhận). Unit Test là gì? Unit Test là một loại kiểm thử phần mềm trong đó các đơn vị hay thành phần riêng lẻ của phần mềm được kiểm thử. Kiểm thử đơn vị được thực hiện trong quá trình phát triển ứng dụng. Mục tiêu của Kiểm thử đơn vị là cô lập một phần code và xác minh tính chính xác của đơn vị đó. Unit là gì? Một Unit là một thành phần PM nhỏ nhất mà ta có thể kiểm tra được như các hàm (Function), thủ tục (Procedure), lớp (Class), hoặc các phương thức (Method). Lợi ích của Unit test 	Viết Unit test tốt giúp tăng sự tin tưởng vào mã nguồn được thay đổi hoặc bảo trì. Bởi lẽ, nếu viết Unit test tốt, mỗi lần có sự thay đổi bên trong mã nguồn và chạy unit test, chúng ta có thể bắt được những lỗi sảy ra do thay đổi mã nguồn. 	Chúng ta có thể kiểm thử từng thành phần riêng rẽ của dự án mà không cần đợi các thành phần khác hoàn thành. 	Do thực hiện test trên từng đơn vị nhỏ của các module riêng rẽ nên khi phát hiện lỗi cũng dễ dàng khoanh vùng và sửa chữa. 	Có thể tái sử dụng mã nguồn 	Chi phí cho việc sửa chữa lỗi trong giai đoạn unit test sẽ ít hơn so với các giai đoạn sau 	Mã nguồn đáng tin cậy hơn nếu viết tốt unit test Khi làm Unit test chúng ta thường thấy các khái niệm sau: Assertion: Là một phát biểu mô tả các công việc kiểm tra cần tiến hành, thí dụ: AreEqual(), IsTrue(), IsNotNull()… Mỗi một UT gồm nhiều assertion kiểm tra dữ liệu đầu ra, tính chính xác của các lỗi ngoại lệ ra và các vấn đề phức tạp khác như: – Sự tồn tại của một đối tượng – Điều kiện biên: Các giá trị có vượt ra ngoài giới hạn hay không – Thứ tự thực hiện của các luồng dữ liệu … Test Point: Là một đơn vị kiểm tra nhỏ nhất, chỉ chứa đơn giản một assertion nhằm khẳng định tính đúng đắn của một chi tiết mã nào đó. Mọi thành viên dự án đều có thể viết một test point. Test Case: Là một tập hợp các test point nhằm kiểm tra một đặc điểm chức năng cụ thể, thí dụ toàn bộ giai đoạn người dùng nhập dữ liệu cho đến khi thông tin được nhập vào cơ sở dữ liệu. Trong nhiều trường hợp kiểm tra đặc biệt và khẩn cấp có thể không cần đến test case. Test Suite: Là một tập hợp các test case định nghĩa cho từng module hoặc hệ thống con. Regression Testing (hoặc Automated Testing): Là phương pháp kiểm nghiệm tự động sử dụng một phần mềm đặc biệt. Cùng một loại dữ liệu kiểm tra giống nhau nhưng được tiến hành nhiều lần lặp lại tự động nhằm ngăn chặn các lỗi cũ phát sinh trở lại. Kết hợp Regression Testing với Unit Testing sẽ đảm bảo các đoạn mã mới vẫn đáp ứng yêu cầu thay đổi và các đoạn mã cũ sẽ không bị ảnh hưởng bởi các hoạt động bảo trì. Production Code: Phần mã chính của ứng dụng được chuyển giao cho khách hàng. Unit Testing Code: Phần mã phụ để kiểm tra mã ứng dụng chính, không được chuyển giao cho khách hàng. Một số lưu ý khi viết Unit test 	Chắc chắn rằng mỗi test case kiểm thử mức đơn vị sẽ độc lập với những test case khác. Không nên gọi một test case khác trong một test case. Test case không nên phụ thuộc vào nhau cả về data và thứ tự thực hiện. 	Luôn luôn kiểm tra từng mô-đun một cách độc lập. Nếu không, sẽ có nhiều sự chồng chéo giữa các ca thử nghiệm và việc thay đổi đối với một đơn vị có thể ảnh hưởng đến tất cả các mô-đun khác và khiến phần mềm bị lỗi. 	Đặt tên các đơn vị kiểm thử một cách rõ ràng và nhất quán. Đảm bảo rằng các test case dễ đọc, bất kỳ ai cũng có thể chọn test case và chạy nó mà không gặp bất kỳ vấn đề nào. 	Khi triển khai việc thay đổi giao diện hoặc chức năng, cần chạy lại các test case trước đó nhằm đảm bảo việc thay đổi này không làm ảnh hưởng đến những test case cũ đã pass. 	Luôn đảm bảo lỗi được xác định trong quá trình Unit test được sửa trước khi chuyển sang giai đoạn tiếp theo. 	Không cố gắng viết test case để kiểm thử tất cả mọi thứ, thay vào đó nên tập chung vào kiểm thử sự ảnh hưởng của hành vi hệ thống 	Bên cạnh viết test case để test hành vi hệ thống, cần viết thêm test case để kiểm thử hiệu năng của mã nguồn 	Các testsuit nên đặt riêng ra, độc lập code với module 	Không nên có nhiều assert trong một test case vì khi một điều kiện không thỏa mãn thì các assert khác sẽ bị bỏ qua 	Sau một thời gian dài, số lượng test case nhiều, thời gian chạy lớn. Nên chia ra nhóm test case cũ và test case mới, test case cũ sẽ chạy với tần xuất ít hơn Trên đây là tóm lược sơ bộ về các định nghĩa của unit test, bài viết sau mình sẽ trình bày cụ thể các công cụ để viết unit test và ví dụ minh họablog.ntechdevelopers.com
Để 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ề testing
https://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ứ!

--
Ủng hộ các bài viết tiếp theo của mình tại blog cá nhân nhé
http://blog.ntechdevelopers.com