Bài viết chuyên sâu

[Software Testing] Về 10 LƯU Ý QUAN TRỌNG khi làm kiểm định tự động

[Software Testing] Về 10 LƯU Ý QUAN TRỌNG khi làm kiểm định tự động

by Admin Dathoc -
Number of replies: 0

#koolj_softwaretesting

#kiểm_định_tự_động

#chiase


Về 10 LƯU Ý QUAN TRỌNG khi làm kiểm định tự động cho web, cho windows/pc app, cho mobile app cho các bạn mới tập làm kiểm định tự động.

.

.

(Mình viết bài với trải nghiệm làm kiểm thử tự động: năm 2011 đã tự viết cho mình và team một framework bằng java qua việc auto test cho mobile android - nếu admin thấy bài không phù hợp với group có thể xoá đi. Bạn có thể tham khảo tài nguyên tôi làm năm đó, phía cuối bài viết)

.

.

Như mình nêu: Đây là bài viết cho người MỚI TẬP làm kiểm thử tự động; tức là các bạn đang tập làm quen với tool này tool kia, framework này kia (< 5 tháng); các bạn cũng chưa có rành lập trình hoặc, các bạn đang tìm kiếm một công cụ HỖ TRỢ NHANH các bạn làm kiểm tra phần mềm một cách tự động. Như vậy, các bạn làm lâu năm (2-3 năm) hoặc đã từng trải nghiệm nhiều sẽ không phù hợp nội dung dưới đây. Nhờ các bạn có trải nghiệm và có kinh nghiệm trong miền kiểm tra phần mềm tự động, góp ý thêm cho bài viết tốt hơn. Thanks!

.

.

👉Thống nhất khái niệm Kiểm tra/ kiểm thử/ kiểm định phần mềm tự động với gia công phần mềm ở CNTT Việt Nam thời gian từ 1996 tới 2021, và có thể trong 20-50 năm nữa:

- Kiểm tra phần mềm tự động: là cách thức làm kiểm tra phần mềm công nghệ thông tin; có kèm theo những hỗ trợ từ các công cụ phần mềm, công nghệ tin học khác, để NHẰM LÀM TĂNG NĂNG SUẤT và HIỆU QUẢ HƠN công việc kiểm tra phần mềm.


....hy vọng các bạn hiểu khái niệm Kiểm tra phần mềm: là tìm kiếm và ngăn ngừa lỗi phần mềm và đảm bảo chất lượng phần mềm tốt nhất.

... hy vọng các bạn hiểu khái niệm chất lượng phần mềm tốt nhất: là phần mềm hoạt động ổn định và thoả mãn yêu cầu khách hàng cuối tốt nhất.

- theo CSQA của QAI India 2006 - 

.

.

👉1. Lưu ý 1: Nếu dự án của bạn định sẽ làm Kiểm tra tự động - CẦN NGAY việc team dev, bên coding cho phần mềm hỗ trợ các bạn tester làm kiểm định tự động bằng cách:

- Trong các module/ bản release giao cho tester làm tự động, cho cả webapp, pc app, mobile app... devteam cần ĐƯA ID VÀO UI/UX, vào các giao diện điều khiển của module/bản release đó. Như thế sẽ tốt hơn cho tester tự động dò tìm và đi nhanh việc tìm kiếm giao diện điều khiển cần tự động test.


Tôi dám cá với bạn đang đọc bài này là: Chưa thầy dạy automation test nào hoặc chưa teamlead hay team technical nào dạy bạn điều này. Hoặc bạn sẽ đọc trải nghiệm này đây là lần...đầu tiên. Có thể bạn sẽ thấy LẠ!!! Vì đơn giản công việc này sẽ làm GIẢM NHỮNG KHÓ KHĂN sau này của team test khi làm sâu về auto test.


Ví dụ: devteam không phân biệt hoặc tự động tạo id tự động cho các UI điều khiển, ví dụ textbox, combobox... dẫn tới mỗi lần chạy và dò tìm các UI điều khiển này là một.. ID mới. Dẫn tới tester làm tự động sẽ khó khăn hơn trong việc chạy lại script cũ để test tự động.


Một số bạn có thể ý kiến: ôi như vậy bản release sẽ dễ bị hack vì các UI ngầm sẽ bị để tuần tự ID, và như vậy không đảm bảo cho chuẩn nào đó của release. Không sao ạ. Vì là bản release cho team test tự động, nên khi release chính thức cần bỏ cái tuần tự ID cố định này đi.


👉2. Lưu ý 2: Bạn hoàn toàn có thể chọn một tool/công nghệ tự động test mà... bạn KHÔNG CẦN BIẾT LẬP TRÌNH cũng sử dụng tốt được:

- Ví dụ công nghệ 2021 của tôi HERA: chỉ cần các bạn biết excel thôi là có thể làm auto test rồi. Fans có thể xem doc này để hiểu hơn HERA automation test như thế nào: https://onedrive.live.com/edit.aspx?cid=334e3b4fd5d42d83&page=view&resid=334E3B4FD5D42D83!59873&parId=334E3B4FD5D42D83!59657&authkey=!ABq9Z4TKA2E4MbE&app=Word

- Nên tìm kiếm và chọn từ khoá keyword driven test

- Như bạn thấy bây giờ, 2021, có rất rất nhiều những công cụ/tool làm kiểm thử tự động cho từng công nghệ riêng (tool autotest cho GUI, tool autotest cho windows app, tool cho java app, tool cho bank app...) các bạn có thể tham khảo tại đây

https://www.guru99.com/automated-testing-tools.html

https://en.wikipedia.org/wiki/List_of_web_testing_tools

https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis

- Đa phần các tool này theo công nghệ: Record and Playback; vậy đơn giản là không cần khả năng coding của bạn, bạn cũng làm đc auto test

- Thời tôi, 1997-2000, tụi tôi hay dùng đồ IBM Rational Robot, Mercury QuickTest... rồi Android Robotium. Nay 2021 có rất nhiều: Miễn phí có Webdriver, Appium, UI Path, RobotFramework, SOAP UI... Có phí: UIPath, Ranorex, IBM Functional Tester, HP Unified Functional Test...

- Sau đó các bạn mới đi tới tìm kiếm công nghệ về: data driven test hoặc behavior-driven test. Cái này cần kiến thức lập trình chút.

.

.

👉3. Lưu ý 3: Bạn cần kiến thức và trải nghiệm lập trình: và ...cần thay đổi quan điểm automation test: có nghĩa là 

- Trước đây chúng tôi hiểu: automation test nghĩa là: Sau khi hệ thống xong xuôi, logic chức năng tốt rồi, tức là dự án chuyển sang chuẩn bị deploy hay release cho khách hàng rồi, mới chạy auto test; hoặc auto test chỉ làm về regression test thôi là OK lắm rồi. Nhưng bây giờ, nămg 2021 là...

- Khi coding unittest xong: bạn cần làm một auto script test để validate lại...bất cứ list các unittest xong mỗi khi module đc release cho team test.

- Khi integration test, hoặc component integration test xong: bạn cũng cần một auto script test để validate lại...toàn bộ testcase ở trong giai đoạn tích hợp này, khi module hoặc sản phẩm release cho team test

- Vậy có thể bạn ý kiến là: Ôi, việc này hơi quá sức tester. Mình lại nghĩ nếu bạn không coding đc: vậy bạn thiết kế auto testcase để devteam làm hộ bạn. Còn bạn là giám sát blackbox test trên những cái trên.


👉4. Lưu ý 4: Bạn cần kiến thức và trải nghiệm lập trình: về việc tìm kiếm một ID giao diện UI, bằng việc loop vô hạn, cho tới khi gặp ID UI đó. Cho cả webapp, pc app, mobile app.

- Ví dụ, kiểu tôi tìm và đợi cho tới khi nào nút LOGIN của f.b hiện ra tôi mới làm các hành động khác: bạn vào youtube, search testerpro, tìm video 10 lưu ý khi phát triển script test tự động, phút 4:43

- Hiểu thế này: thông thường 100% tester ít kinh nghiệm sẽ làm kiểu: khi bạn có hành động auto làm việc gì đó trên một UI nào đó, bạn sẽ cần đợi cái UI đó nó xuất hiện, và tự wait hoặc wait có thời gian. Xong khi UI chưa hiện lên trong khoảng thời gian đó thì..hành động trong script của bạn sẽ failed. Tức là UI chưa hiện lên thì bạn sẽ xử lý hành động auto test rồi.

- Vậy để tránh việc đó; tránh việc không biết khi nào UI hiện lên: bạn cần: tạo loop vô hạn và đợi cho tới khi nào id UI hiện ra mới thoát khỏi loop

- Có thể một số bạn băn khoăn là: ơ thế khi đợi mãi mãi ...mà nó vẫn không hiện ra thì mình failed ạ. Không sao ạ, vậy bạn cần làm tiếp một script bao ngoài loop đó là một loop khác: xử lý thêm là: khi >10 phút, hoặc >2 giờ, hoặc >1 tuần...thì báo hệ thống có vấn đề. Case đó failed. Đơn giản mà.


👉5. Lưu ý 5: Bạn cần kiến thức và trải nghiệm lập trình: về việc bóc tách xpath nhanh (với web app) bằng việc sử dụng regex contains, startwith.... Tương tự với tool, công nghệ khác.

- Hiện tượng đa phần các auto tester gặp là: một cái ID khi các bạn nắm được xong nó bị biến đổi liên tục ở đằng đuôi, ví dụ: ID của textbox, lúc nó hiện ra là: abctext089343, lúc nó hiện ra là: abctext333389... vây khi xử lý bạn sẽ cần một cố định khi tìm kiếm với kiểu ID này

- Với webapp, đa phần a chị e sẽ dùng xpath, và regex của nó, tức là bạn dùng contains (khi ID đó có chứa một ký tự nào đó), hoặc startwith (khởi điểm id đó một mẫu ký tự nào đó), ví dụ

+ với contains: //h4/a[contains(text(),'SAP M')] - tức là với bất kỳ element nào bao gồm có cum từ "SAP M"

+ với startwith: //label[starts-with(@id,'message')] - tức là với bất kỳ element nào bắt đầu bằng "MESSAGE"

Bạn có thể xem kỹ hơn tại đây: https://www.guru99.com/using-contains-sbiling-ancestor-to-find-element-in-selenium.html

.

.

👉6. Lưu ý 6: Bạn cần kiến thức và trải nghiệm lập trình: về việc sử dụng ĐỢI/ WAIT thế nào cho chiến lược. Đợi khi nào cho đủ. Đợi khi nào cho element/id hiện ra mới ...dừng việc ĐỢI

- Ở đây mong muốn nắm rõ tư tưởng làm auto test khi bạn tạo ra những cơ chế mà...bạn có thể dùng mãi mãi về sau. Và gần như nó là cơ bản và lâu dài cho nghiệp automation test của bạn

- Cái này giống với lưu ý 4, xong mở rộng hơn, tức là khi bạn tìm và đợi một ID, một element, hay một instant nào đó từ UI, bạn sẽ có quan điểm vậy đợi nó bao giờ

- Vậy tốt nhất bạn nên viết một xử lý riêng để loop vô hạn cho tới khi bạn gặp ID/element/instant đó hiện ra, hoặc xuất hiện.

- Vì sao phải vậy: có thể có bạn nêu là: ôi em thấy hệ thống nhanh lắm, xử lý và hiện UI nhanh lắm. Vâng lúc này nó nhanh, song bạn không thể đảm bảo nó chạy suốt 2 tuần 1 tháng và nhiều kiểu logic tình huống khác nhau mà...nó vẫn nhanh, vẫn hiện UI nhanh được.


👉7. Lưu ý 7: Bạn cần kiến thức và trải nghiệm lập trình: về việc tìm vị trí element/id. Như nêu ở trên nếu devteam cho bạn ID thì tốt. Xong nếu bạn ở trong tình trạng mỗi lần hiện UI lên là một ID mới, Element mới thì bạn deal thế nào?

- Tức là: như các tester làm tự động thấu hiểu, ngay cả những tool hiện đại hại điện nhất cũng yêu cầu, hoặc đề nghị bạn nên có một ID/element/instant ...cố định. Tức là cứ khi nào nó hiện lên UI, thì nó phải là 1 nội dung để script test auto của mình với tới nó được. Còn nếu không script của bạn được coi là không ổn định. Vì có lúc nó bắt được ID có lúc không. Ví dụ khi tôi xử lý auto task lấy data từ element của f.b, nó rất khó để tìm thấy một ID cố định. 

- Kinh nghiệm 1 của mình là: tìm các UI element bên cạnh nó. Đúng rồi ạ, nếu bạn không tìm được ID bạn mong đợi, vậy bạn cần script thêm là tìm những tương đối của các UI bên cạnh nó, để nhận diện UI ID đó là cái bạn cần tìm tới

- Kinh nghiệm 2: yêu cầu dev team đính kèm ID cho UI element khó đó

- Kinh nghiệm 3: lấy toàn bộ nội dung hiện trên bề mặt và bóc tách sau này. Cái này hơi vất vả. Xong nó cần những dấu hiệu khác biệt để nhận ra vùng ID UI mà mình cần dò tới

- Kinh nghiệm 4: dùng loop để tìm ra thứ tự cái UI ID của mình cần. Và kỳ vọng cái thứ tự đó là mong đợi. Vậy như thế bạn luôn cần chuẩn bị môi trường tình huống là của...riêng bạn. Vì mình thấy rất ít khi 1 ứng dụng/hệ thống chỉ có 1 bạn test. Mà sẽ nhiều ng test trên đó. Vậy khi làm kiểu dò thứ tự này, sẽ có thể bị sai. Vậy chuẩn nhất là bạn làm script reset data và reset hệ thống trở về tình trạng nào đó và khi đó...bạn mới dò kiểu thứ tự được


👉8. Lưu ý 8: Bạn cần kiến thức và trải nghiệm lập trình: về việc chạy tự tạo ra vòng LOOP cho testcase của mình. Giả sử bạn cần 1000 case khác nhau. Chắc bạn phải tạo 1000 case auto script riêng. Vậy nên tạo riêng một LOOP và cơ chế LOOP đưa ra datadriven, hoặc keyword driven như tôi làm.

- Đúng rồi, tức là với test LOGIN đi, ví dụ bạn cần 15 testcase cho việc validate khi login sai, login thiếu, thừa... vậy sơ sơ là bạn cần 15 script riêng. Còn tôi chỉ cần 1 vòng loop và những đầu vào đầu ra khác nhau, soạn trên Excel. Bạn có thể xem vào youtube, search testerpro, tìm video 10 lưu ý khi phát triển script test tự động.

- Vậy sâu hơn: bạn cần script kiểu keyword loop, ví dụ: kiểu For ...Endfor như mình làm. Bạn xem doc HERA của mình (link trên)

- Vậy sâu hơn: bạn tiếp tới, tạo những biến nhớ để thay thế cho mỗi lần FOR

- Sâu hơn: bạn cứ mỗi lần chạy qua for bạn lại khởi tạo lại biến...

... cứ thế cứ thế cho tới khi hết loop FOR

.

.

👉9. Lưu ý 9: Bạn cần kiến thức và trải nghiệm lập trình: về việc chạy nhiều LUỒNG/ session. Đơn giản thì 1 lúc bạn có thể chạy nhiều case khác nhau SONG SONG 

- Ví dụ tôi làm mutithread với Webdriver kết hợp TestNG để làm nhiều công việc cùng lúc: máy 128 GB ram, 48 lõi cpu, với 300 thread song song để lấy ảnh user trên Google: https://youtu.be/lLDrUuw1RHc?list=PL0ANjPcxElLh0wVySS_pJO2mvz8-19U3f&t=123

- Vậy cái đề cập ở đây là: nếu bạn cần làm SONG SONG: 1 case order hàng, 1 case xoá hàng, 10 case list danh sách hàng... thì bạn cần tạo cơ chế multithread trên công nghệ bạn đang dùng. Đa phần là ngôn ngữ lập trình sẽ hỗ trợ bạn.

- Hoặc bạn cần dùng những cơ chế đang có sẵn để: chỉ cần cấu hình trên file cấu hình, là có thể multithread được. Ví dụ với selenium webdriver, bản thân đó chưa hỗ trợ multithread, vậy bạn lập trình thêm. Hoặc bạn dùng TestNG.org kết hợp để cấu hình từ XML vào chạy nhiều task với webdriver


👉10. Lưu ý 10: Bạn cần kiến thức và trải nghiệm lập trình: về việc lấy dữ liệu từ bên ngoài cho mỗi hoạt động test và tách biệt với script của bạn, hoặc datadriven

- Ở đây có hai khái niệm:

+ Keyword driven testing: tức là bạn tạo ra những keyword và tester khác sẽ dùng đơn giản, vd: như excel, file text, csv,... để áp dụng keyword để auto test tự động. Ví dụ như tôi làm HERA, bạn xem link doc trên. Và việc chạy testcase nào do cấu hình mỗi test case hoặc tùy keyword bạn xử lý.

+ Data driven testing: tức là bạn bên cạnh keyword, bạn đưa input data, và nhận output data; tức là dữ liệu đầu vào và việc ra quyết định test case nào đi tiếp theo sẽ là do kết quả data trả ra từ testcase trước đó. Hoặc với kết quả output data bao nhiêu, chất lượng data trả ra thế nào, mà bạn chạy tiếp ..testcase nào. Hoặc nhiều áp dụng nhất hiện nay với data driven là: gần với kiểu keyword, xong mỗi data là một kiểu chạy khác nhau.

- Ví dụ: tôi dùng keyword trên Excel và tạo vòng loop FOR  cho nhiều case để validate login; và input data từ một bảng data excel khác: https://youtu.be/r7AOkVpGV5E?t=193


👉11. Lưu ý phụ: Hãy học lập trình JavaScript. Việc trải nghiệm mới cho người mới học làm auto test không hề đơn giản và ngon ăn. Nó cần thời gian và sự kiên trì của bạn. Và cần sự trải nghiệp lập trình nào đó. Bạn nên chọn JavaScript, vì nó dễ học, đơn giản, và có thể áp dụng mọi nơi khi cần auto test. 

.

.

Tới đây mình hy vọng chắc các bạn mong muốn, hoặc đang quen dần với kiểm tra/kiểm thử phần mềm tự động đã thấy những khó khăn cần lưu ý, hoặc đã thấy chiến lược sắp tới mình định làm cái gì..sẽ rõ ràng hơn; và tiếp tục theo học tìm tòi sâu hơn trong kiểm tra phần mềm tự động.


Gluk!

------------------------------------

Dự án autotest của mình năm 2011: https://code.google.com/archive/p/datadriven-for-robotium-selenium/wikis/DFRSintro.wiki

Dự án autotest của mình từ 2016-2021: https://www.youtube.com/watch?v=-uqX2-npxjo&list=PL751V5I3RIDH4RzUWGCQ1NhXuO2sCb-G3

SÁCH - TẠP CHÍ - TÀI LIỆU ĐÚC KẾT KINH NGHIỆM làm về SOFTWARE TESTING cần tham khảo: dathoc.net/booktest

Bạn muốn thông thạo hơn việc viết thiết kế testcase, sử dụng công cụ automation test HERA để auto test, các framework Appium, TestNG, xin tham gia FREE tại: youtube.com/c/TesterPRO/

By: dathoc.net/cv