Sử dụng kiến thức SQL để công việc test dễ dàng hơn

Bài viết được sự cho phép của vntesters.com

Chia sẻ của bạn Nguyễn Dương Hải về việc sử dụng kiến thức SQL trong quá trình làm test.

Mình không dám nói mình làm DB test nhiều. DB test, nếu làm hoàn chỉnh có rất nhiều phần bạn phải take care ví dụ như Performance của câu SQL, DB indexing, … Nhưng ở bất cứ dự án nào mình cũng đều cố gắng tìm hiểu Database structure của hệ thống. Mục đích chính là xem data flow đi như thế nào khi sử dụng feature trên UI, rồi từ từ mình cũng test một số feature bằng cách viết SQL. Sau đó mình học được những mẹo nhỏ để sử dụng kiến thức Database cua project và SQL để phục vụ cho công việc test của mình tốt hơn, tìm ra được nhiều case hơn. Mình xin phép nói về những trường hợp mình can thiệp vào DB và can thiệp thế nào để có hiệu quả tốt nhất.

1/ Test một feature khi những feature liên quan chưa sẵn sàng

Mình tin rằng bạn nào cũng đã từng gặp những trường hợp như thế này. Ví dụ:

  • Feature tạo đơn hàng đã xong.
  • Nhưng feature để xem danh sách đơn hàng vẫn chưa làm xong

Thông thường, ta cần có feature xem danh sách đơn hàng để một lúc kiểm tra 2 chuyện: tạo đơn hàng thành công và list đơn hàng đúng. Tuy nhiên, về mặt bản chất, tạo đơn hàng xong rồi thì chỉ cần kiểm trong database xem nó có lưu đúng field, đúng value không là được.

Thoạt nghe đơn giản nhưng bạn sẽ thấy có những feature rất phức tạp mà team bạn mất nhiều ngày mới làm xong. Nếu bạn làm tới đâu kiểm tới đó sẽ chỉ có lợi.

2/ Test Back End bằng cách check SQL

Ngắn gọn là, có những feature mà Back End chủ yếu là làm ra 1 câu SQL đưa data lên cho Front End, lúc đó là có gì in ra đó. Tìm hiểu câu SQL đó có thể cho bạn những ý tưởng thú vị để test, hoặc chỉ đơn giản là Analyze nó ra để xem họ có làm đúng logic không?

  ## trong SQL (2 dấu thăng) nghĩa là gì?
  Hướng dẫn giải bài toán phân bổ số lượng (thuật toán chia kẹo) trong sqlserver

3/ Fake data, clean data, dump initial data

Fake data

Đây là một trong những ứng dụng mà mình thích nhất khi đã hiểu tường tận DB của product rồi. Một ví dụ đơn giản, bạn test chức năng Sign Up, bạn phải test 10 case. Chỉ mỗi chuyện tạo 10 email để test thôi là mệt thở rồi. Nhưng mà, nếu bạn biết cách vào trong database, mình tin rằng bạn chỉ cần edit 1 field “email” trong 1 table nào đó là cái email ban đầu của bạn sẽ free ngay.

Lời khuyên:

  • Learn DB structure,
  • Học cách execute SQL,
  • Học câu lệnh Update.

Ví dụ:

UPDATEUserSET email=’[email protected]’, username=’dummy1’WHERE email = ‘[email protected]’

Tóm lại, bạn sẽ có thể sử dụng email [email protected] bao nhiêu lần tùy thích để nhận được email confirmation và test nó.

Clean data

Dùng trong trường hợp bạn muốn test environment của bạn được sạch sẽ để demo cho client, để test case empty data, hoặc có quá nhiều data rác làm bạn rối trí. Lúc này, chưa chắc trên Front End của bạn đã có feature REMOVE, mà nếu remove bằng tay thì cũng chết.

1 câu lệnh DELETE sẽ giúp bạn tiết kiệm rất nhiều thời gian:

DELETEFROM table_name [WHERE Clause]

WARNING! Để đảm bảo được tính thống nhất của data, bạn phải chắc chắn rằng bạn hiểu rõ database structure của product bạn. Ví dụ, nếu bạn muốn delete 1 row User đi thì trước tiên bạn phải remove những đơn hàng của user đó trong table don_hang trước. Nếu không database sẽ báo lỗi khi bạn cố gắng remove, hoặc là data bạn test sẽ không còn đúng nữa. Keep that in mind!

Dump initial data

Với những tình uống sau đây, bạn nên cân nhắc tạo ra 1 bộ data chuẩn và lưu giữ nó lại:

  • Bạn đang cần 1 lượng data lớn để test performance
  • Bạn không muốn client của bạn phải vào test khi chưa có 1 data nào trong website sau mỗi lần deploy.
  • Bạn đang cần 1 bộ data gồm nhiều case, giả sử như First Name có đủ kiểu từ chữ thường cho đến tiếng Hoa, Tiếng Hàn, “?!@#”,… để test layout.
  • Bạn đang muốn test case: structure của Dabase cũ sẽ được migrate sang thành structure mới khi server bạn start
  • Automation test case của bạn cần phải có 1 bộ data chuẩn, vì test case được thiết kế để kiểm tra đúng sai trên đúng bộ data đó! Là cái khác, sai 1 chút thì sẽ có 1 test case fail.

Với những trường hợp như trên mình đề nghị:

  • Bạn tạo ra 1 bộ data test với những data bạn cần. Khi tạo data, mình dùng câu lệnh INSERT, hoặc những website như https://www.mockaroo.com/ sẽ giúp bạn làm chuyện này tốt hơn. Học cách sử dụng những “data generator tool” không khó.
  • Nếu bạn muốn chắc ăn. Hãy tạo data trên UI, nhưng mình không khuyến khích vì nó sẽ tốn thời gian và phụ thuộc vào độ support của UI.
  • Sau đó, dump nó ra thành 1 file SQL. Trong SQL tools hoặc thậm chí là command line luôn có cách để làm vụ này
  • Khi nào cần, thì dùng chức năng backup file SQL ( có cả command line) để dump data ngược trở vào, đè lên toàn bộ data cũ.

Với cách này, mỗi lần test, bạn có thể ung dung test những case bạn cần với data có sẵn. Thậm chí bạn đã biết trước kết quả sẽ như thế nào nên việc testing cũng sẽ dễ dàng

WARNING! Những side effect sau đây cần phải được cân nhắc:

  • Team bạn đang thực hiện testing và data của họ bị xóa. Đặc biệt là client. Nếu bạn đang dùng chung 1 environment, thì phải có sự đồng thuận của tất cả mọi người
  • Update data test để có structure mới nhất.

Ví dụ, mình tạo ra 1 bộ data test, lúc đó database chỉ có field email, username và password thôi. Một thời gian sau, mình có thêm 1 field mới nữa là Name. Khi mình dump data test cũ vào, hệ thống báo lỗi.

Nếu team bạn có làm migration tốt, đó sẽ là một test case hay. Nhưng nếu team bạn không có kế hoạch làm nó, thì bộ data test của bạn phải được update structure thường xuyên, nếu không sao khi dump data, feature của bạn có thể chạy sai.

4/ Query real data sẽ giúp bạn thấy những điều thú vị

Tìm ra lỗi

Câu chuyện về cách đây 4 năm, mình làm cho 1 dự án Social Network. Team mình collect từ fanpage của những ca sĩ, username của những fan hâm mộ họ rồi blah blah. Lúc đầu, team mình cứ đinh ninh rằng username sẽ không có dấu “?” nên lúc thiết kế UI để render ra cái list này cũng chẳng support nó. Đến một ngày đẹp trời, mình query trên production và thấy chuyện này là có thể khi hệ thống mình capture được 1 vài user như vậy, sau đó thì fix Front End.

Analytic

Cũng trong dự án đó, client thường hay request team theo kiểu:

Nói cho tui biết trong 1 tháng qua có bao nhiêu đứa có 2000 fan trong hệ thống.
Có đứa nào trong 1 tháng tăng được 500 fan không?
…
Mình biết công việc này thường rơi vào Dev lead, nhưng nếu mình có thể sao lại không làm? Nếu bạn muốn đề xuất add thêm feature mới hoặc remove feature cũ, bạn sẽ cần data query như là 1 back up cho lập luận của bạn đó

Lời kết

Hy vọng sau bài viết này bạn có thể sử dụng kỹ năng SQL của mình đúng lúc và cân nhắc tất cả những hậu quả có thể có để có thể test một cách nhanh và hiệu quả nhất. Chúc các bạn thành công.

Bài viết gốc được đăng tải tại vntesters.com

Có thể bạn quan tâm:

Xem thêm IT Jobs in Vietnam for Developer hấp dẫn trên TopDev