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

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

• 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?

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=’dummy_email_1@gmail.com’, username=’dummy1’WHERE email = ‘hainguyentesting@gmail.com’
  

Tóm lại, bạn sẽ có thể sử dụng email hainguyentesting@gmail.com 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 donhang 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 đó