thảo luận [automation test] Xin góp ý về thiết kế hệ thống với số lượng test case trên 10.000.

flashsky · Nov 16, 2023

Hồi trước mới làm automation thì nghĩ viết càng nhiều auto test thì càng tốt, nhưng sau những va vấp và phát triển trong nghề thì thấy viết càng nhiều nhất là UI automation test thì sau này ăn hành càng nhiều, ban đầu viết thì thấy khá là đã tay nhưng về sau maintain cái đống test do chính tay mình viết chỉ cách đây 1 năm thôi là coi như mất trí nhớ cmnl, nhất là lúc ui change hoặc tính năng đổi, ngồi mò để modify là thấy oải.

Cái mà mình thấy mệt mỏi nhất là phần pre-condition, multiple environment setting, prepare data, ai mà không cứng xài fixed data nhiều thì test fail cho thấy mợ luôn, chưa kể mấy vấn đề trời hỡi liên quan đến network, máy móc, webdriver update... Trong trường hợp của bạn mình có vài ý kiến thế này dựa theo cái project mình đang làm

Break out autotest thành test level như mô hình test pyramid.

1. E2E (UI) testing: test scenarios tập trung các feature core quan trọng nhất của hệ thống. 10 k case manual thì mình có thể tưởng tượng được rằng nó sẽ có hằng hà sa số test case không quan trọng mấy liên quan đến sort/filter column, add/edit/delete data setting.. mà mình có thể move nó xuống tầng API testing

2. Integration (API) testing: Test scenario liên quan đến API request/response hoặc integration với các hệ thống khác. Test ở tầng này execute nhanh gọn lẹ, dễ debug, dễ maintain.

3. Unit testing: Dev handle phần này.

Đương nhiên là nếu có đội ngũ QC hùng hậu, cứng về automation thì viết 10k case UI chia mỗi ông nắm 1k cases cũng ổn, nhưng nếu là 1 ông cứng 9 ông scripter copy paste thì người khổ nhất vẫn là ông cứng tay thôi :big_smile:

samuro33 · Nov 16, 2023

flashsky said:
Hồi trước mới làm automation thì nghĩ viết càng nhiều auto test thì càng tốt, nhưng sau những va vấp và phát triển trong nghề thì thấy viết càng nhiều nhất là UI automation test thì sau này ăn hành càng nhiều, ban đầu viết thì thấy khá là đã tay nhưng về sau maintain cái đống test do chính tay mình viết chỉ cách đây 1 năm thôi là coi như mất trí nhớ cmnl, nhất là lúc ui change hoặc tính năng đổi, ngồi mò để modify là thấy oải.

Cái mà mình thấy mệt mỏi nhất là phần pre-condition, multiple environment setting, prepare data, ai mà không cứng xài fixed data nhiều thì test fail cho thấy mợ luôn, chưa kể mấy vấn đề trời hỡi liên quan đến network, máy móc, webdriver update... Trong trường hợp của bạn mình có vài ý kiến thế này dựa theo cái project mình đang làm

Break out autotest thành test level như mô hình test pyramid.

1. E2E (UI) testing: test scenarios tập trung các feature core quan trọng nhất của hệ thống. 10 k case manual thì mình có thể tưởng tượng được rằng nó sẽ có hằng hà sa số test case không quan trọng mấy liên quan đến sort/filter column, add/edit/delete data setting.. mà mình có thể move nó xuống tầng API testing

2. Integration (API) testing: Test scenario liên quan đến API request/response hoặc integration với các hệ thống khác. Test ở tầng này execute nhanh gọn lẹ, dễ debug, dễ maintain.

3. Unit testing: Dev handle phần này.

Đương nhiên là nếu có đội ngũ QC hùng hậu, cứng về automation thì viết 10k case UI chia mỗi ông nắm 1k cases cũng ổn, nhưng nếu là 1 ông cứng 9 ông scripter copy paste thì người khổ nhất vẫn là ông cứng tay thôi

New features hay features hay thay đổi mà cũng force làm auto (nhất là UI auto) thì chỉ do mấy công ty ép thôi, còn qui trình qa thì không ai làm. Lead hay ql dự án thấy hay có kiểu prefer automation testing ở VN như kiểu bắt trend hơn là phân tích giá trị của nó.

Love U So Much · Nov 16, 2023

Khách hàng cty tôi ngày xưa có automation test, nhưng chỉ test API và performance

1 cái app sẽ có unit test, 1 repo khác integration test, 1 repo automation test. 3 team khác nhau làm, còn có cả manual test

AccDuyNhat · Nov 16, 2023

flashsky said:
Cái mà mình thấy mệt mỏi nhất là phần pre-condition, multiple environment setting, prepare data, ai mà không cứng xài fixed data nhiều thì test fail cho thấy mợ luôn, chưa kể mấy vấn đề trời hỡi liên quan đến network, máy móc, webdriver update...

mình đẩy ra các pre-conditions, settings bên ngoài rồi import vào có đỡ bớt các issue này không bác? Mình đang tách các thư viện bên thứ 3 thành dạng như adapter. Wrap lại các tính năng của webdriver, ... để tránh việc gọi trực tiếp vào thư viện.

flashsky said:
Break out autotest thành test level như mô hình test pyramid.

Cảm ơn bác. Để mình tìm hiểu thêm xem sao. Tương lai là chuyển hệ thống hiện tại sang single page nên áp dụng test pyramid mình nghĩ là cũng khả thi.

AccDuyNhat · Nov 16, 2023

samuro33 said:
New features hay features hay thay đổi mà cũng force làm auto (nhất là UI auto) thì chỉ do mấy công ty ép thôi, còn qui trình qa thì không ai làm. Lead hay ql dự án thấy hay có kiểu prefer automation testing ở VN như kiểu bắt trend hơn là phân tích giá trị của nó.

Hôm đầu về dự án, mtg với PM thì ổng nói: "Giờ số lượng test case nhiều quá. Mà mỗi lần QC regression test quá cực, mất quá nhiều thời gian. Chưa kể thời gian tới convert sang single page. Nên muốn build bộ source automation test để giảm bớt thời gian regresstion test này lại".

Mà mình trước giờ có code automation bao giờ đâu, Nhưng thôi, sếp nói làm thì làm. Nên cũng ù ù, cạc cạc mà nhận. =((

samuro33 · Nov 16, 2023

AccDuyNhat said:
Hôm đầu về dự án, mtg với PM thì ổng nói: "Giờ số lượng test case nhiều quá. Mà mỗi lần QC regression test quá cực, mất quá nhiều thời gian. Chưa kể thời gian tới convert sang single page. Nên muốn build bộ source automation test để giảm bớt thời gian regresstion test này lại".

Mà mình trước giờ có code automation bao giờ đâu, Nhưng thôi, sếp nói làm thì làm. Nên cũng ù ù, cạc cạc mà nhận.

vậy bác hướng đề ra Test Strategy đi. Proj không ai consult Test Process mà cắm vô auto thì chưa nói code, việc triển khai đã như đống bùi nhùi rồi.
1. Grouping các features quan trọng, đã stable cao, ít change auto trước -> show ra ETA time effort giảm dẽ thuyết phục
2. Implement trong khi xem xét lại quá trình manual regression. Chứ tui thấy regression mà 10k cases thì hơi sai sai.
3. Nếu 2 làm được thì sẽ giảm khá nhiều scope bác cần auto lại, mà value mang lại vẫn cao hơn là cắm vô code rồi maintaince. Có khi thời gian debug, check log sau mỗi lần chạy còn lâu hơn để manual :v
anw, tùy tình hình cty bác, vụ này debate cũng căng lắm. Nhiều cty có manager nước ngoài hay có product mindset tốt thì ổn, chứ kiểu outsrc dễ đề cao mấy việc có code nhiều, cảm giác nó hype hay sao ấy =]]. Manual QA đúng hay tui gọi là qa analyst, họ khủng vl ra, tester is not checker.

Doctor Steel · Nov 16, 2023

Công ty đã amateur còn gặp đúng chủ thread xăm mình dám nhận. Chuyển đổi tất cả 10k test case manual sang auto để làm gì? Đã viết auto thì phải đánh giá dc khả năng chạy thường xuyên của test suite đó. Dám hỏi chủ thớt cái bộ 10k case đó chạy day by day hay viết để đó nhìn chơi.
Nên có định hướng handle case theo mô hình pyramid, từ phía unit test, API rồi mới tới E2E.
Mà dính cái cty này thì đúng là tha hồ vẽ, kiểu như chính nó cũng ko biết mình muốn cái gì từ automation thì phải :sneaky:

flashsky · Nov 16, 2023

AccDuyNhat said:
mình đẩy ra các pre-conditions, settings bên ngoài rồi import vào có đỡ bớt các issue này không bác? Mình đang tách các thư viện bên thứ 3 thành dạng như adapter. Wrap lại các tính năng của webdriver, ... để tránh việc gọi trực tiếp vào thư viện.

Cảm ơn bác. Để mình tìm hiểu thêm xem sao. Tương lai là chuyển hệ thống hiện tại sang single page nên áp dụng test pyramid mình nghĩ là cũng khả thi.

Việc build một automation framework chuẩn chỉ để mọi người trong team follow là điều kiện tiên quyết rồi, vì nó sẽ giúp handle những vấn đề liên quan đến biến môi trường, common function cho webdriver, web locator...

Nhưng cái quan trọng nhất là mindset trong việc implement automation test script và cái mình cho là quan trọng nhất chính mình sẽ handle phần test data như thế nào. Test data phải làm sao để không bị ảnh hưởng bởi những test khác hay bởi những môi trường khác. Nhiều bạn mới biết làm auto rất hay kiểu set fixed test data, rồi đến hồi mới chạy thì pass, bẵng đi một thời gian thì fail bấy nhầy ngồi maintain mắc mệt. :amazed:

Ngohuaanh23 · Nov 16, 2023

flashsky said:
Hồi trước mới làm automation thì nghĩ viết càng nhiều auto test thì càng tốt, nhưng sau những va vấp và phát triển trong nghề thì thấy viết càng nhiều nhất là UI automation test thì sau này ăn hành càng nhiều, ban đầu viết thì thấy khá là đã tay nhưng về sau maintain cái đống test do chính tay mình viết chỉ cách đây 1 năm thôi là coi như mất trí nhớ cmnl, nhất là lúc ui change hoặc tính năng đổi, ngồi mò để modify là thấy oải.

Cái mà mình thấy mệt mỏi nhất là phần pre-condition, multiple environment setting, prepare data, ai mà không cứng xài fixed data nhiều thì test fail cho thấy mợ luôn, chưa kể mấy vấn đề trời hỡi liên quan đến network, máy móc, webdriver update... Trong trường hợp của bạn mình có vài ý kiến thế này dựa theo cái project mình đang làm

Break out autotest thành test level như mô hình test pyramid.

1. E2E (UI) testing: test scenarios tập trung các feature core quan trọng nhất của hệ thống. 10 k case manual thì mình có thể tưởng tượng được rằng nó sẽ có hằng hà sa số test case không quan trọng mấy liên quan đến sort/filter column, add/edit/delete data setting.. mà mình có thể move nó xuống tầng API testing

2. Integration (API) testing: Test scenario liên quan đến API request/response hoặc integration với các hệ thống khác. Test ở tầng này execute nhanh gọn lẹ, dễ debug, dễ maintain.

3. Unit testing: Dev handle phần này.

Đương nhiên là nếu có đội ngũ QC hùng hậu, cứng về automation thì viết 10k case UI chia mỗi ông nắm 1k cases cũng ổn, nhưng nếu là 1 ông cứng 9 ông scripter copy paste thì người khổ nhất vẫn là ông cứng tay thôi

E cũng thấy vậy đó bác. Cái nào đẩy xuống đc API thì đẩy, UI làm ETE thui. Cty nào tốt đội dev làm TDD còn handle luôn khoản API setup đủ mock database luôn cho á

Ngohuaanh23 · Nov 16, 2023

Ngohuaanh23 said:
E cũng thấy vậy đó bác. Cái nào đẩy xuống đc API thì đẩy, UI làm ETE thui. Cty nào tốt đội dev làm TDD còn handle luôn khoản API setup đủ mock database luôn cho á

Tuy nhiên điều này phụ thuộc vào architecture của hệ thống nữa ak. trc e làm dev mà nhiều xử lý đẩy lên tầng View và sau đó có công cuộc refactoring để đẩy hết xử lý xuống tầng dưới qua API đấy. Đến lúc đó API test cover đc gần hết luôn và giảm tải UI test

AccDuyNhat · Nov 16, 2023

samuro33 said:
vậy bác hướng đề ra Test Strategy đi. Proj không ai consult Test Process mà cắm vô auto thì chưa nói code, việc triển khai đã như đống bùi nhùi rồi.
1. Grouping các features quan trọng, đã stable cao, ít change auto trước -> show ra ETA time effort giảm dẽ thuyết phục
2. Implement trong khi xem xét lại quá trình manual regression. Chứ tui thấy regression mà 10k cases thì hơi sai sai.
3. Nếu 2 làm được thì sẽ giảm khá nhiều scope bác cần auto lại, mà value mang lại vẫn cao hơn là cắm vô code rồi maintaince. Có khi thời gian debug, check log sau mỗi lần chạy còn lâu hơn để manual :v
anw, tùy tình hình cty bác, vụ này debate cũng căng lắm. Nhiều cty có manager nước ngoài hay có product mindset tốt thì ổn, chứ kiểu outsrc dễ đề cao mấy việc có code nhiều, cảm giác nó hype hay sao ấy =]]. Manual QA đúng hay tui gọi là qa analyst, họ khủng vl ra, tester is not checker.

1: Cảm ơn bác. Để mình note lại.
2. Code hiện tại là của product luôn á bác ơi. Chạy cũng được 7 năm rồi. Mình mới từ dự án khác qua.

P/s: Mới hỏi lại bé QC là regression khoảng 2k case. Còn total hiện tại là 6k5.
Xin lỗi về sự nhầm lẫn của mình.

AccDuyNhat · Nov 16, 2023

Doctor Steel said:
Công ty đã amateur còn gặp đúng chủ thread xăm mình dám nhận. Chuyển đổi tất cả 10k test case manual sang auto để làm gì? Đã viết auto thì phải đánh giá dc khả năng chạy thường xuyên của test suite đó. Dám hỏi chủ thớt cái bộ 10k case đó chạy day by day hay viết để đó nhìn chơi.
Nên có định hướng handle case theo mô hình pyramid, từ phía unit test, API rồi mới tới E2E.
Mà dính cái cty này thì đúng là tha hồ vẽ, kiểu như chính nó cũng ko biết mình muốn cái gì từ automation thì phải

Công ty đã amateur còn gặp đúng chủ thread xăm mình dám nhận

Việc giao thì làm bác ơi. ;(

Chuyển đổi tất cả 10k test case manual sang auto để làm gì? Đã viết auto thì phải đánh giá dc khả năng chạy thường xuyên của test suite đó. Dám hỏi chủ thớt cái bộ 10k case đó chạy day by day hay viết để đó nhìn chơi.

Kế hoạch sắp tới sẽ convert sang single page, làm cuốn chiếu từng phần nên mình nghĩ sẽ chạy thường xuyên chứ không có viết để đó rồi nhìn á bác.

tailt01319 · Nov 16, 2023

AccDuyNhat said:
Chào các bác!

Mình có nhận một yêu cầu thiết kế hệ thống automation test với selenium + mocha. Số lượng test case cỡ trên 10 ngàn test.
Do trước giờ mình cũng không có kinh nghiệm nhiều về thiết kế hệ thống và trình mình cũng không giỏi nên mang lên đây xin ý kiến của các bác để hoàn thiện hơn.

Code mình có đẩy lên repo: GitHub - M1nhNV/selenium (https://github.com/M1nhNV/selenium) và cũng đã viết ý tưởng và cấu trúc source vào README mời các bác xem qua.

Cảm ơn các bác!

Chẳng thể nào run stable cho 10k cases đc đâu,
Chia tcs theo tag, change code ở phần nào thì run tag đó
Filter out ra các e2e cần thiết run regression test

via theNEXTvoz for iPhone

Doctor Steel · Nov 16, 2023

AccDuyNhat said:
Kế hoạch sắp tới sẽ convert sang single page, làm cuốn chiếu từng phần nên mình nghĩ sẽ chạy thường xuyên chứ không có viết để đó rồi nhìn á bác.

Tôi không hiểu khái niệm convert single page của bác là cái gì, với auto thì phải là Page object model. Còn nếu là khái niệm của infrastructure thì sẽ là chuyển đổi từ monolithic sang microservices.

Lời khuyên cho bác là chỉ nên tập trung cho regression test giai đoạn này thôi. Nếu product đang build theo microservices thì đẩy phần lớn test xuống tầng API. Chứ ko phải cắm mặt vào làm 10k hay 6k5 case kiểu đó.

Mà cách phân định 2k regression/ 6k5 total cũng là tào lao nhé. Ko thể nào tỷ lệ case regression so với total cao như vậy. Trừ khi nó lấy cả những test case râu ria vào bộ regression.

AccDuyNhat · Nov 16, 2023

Doctor Steel said:
Tôi không hiểu khái niệm convert single page của bác là cái gì, với auto thì phải là Page object model. Còn nếu là khái niệm của infrastructure thì sẽ là chuyển đổi từ monolithic sang microservices.

Do mình dùng từ gây hiểu lầm cho bác. "Covert sang single page" => trước hệ thống viết bằng php blade. Giai đoạn tới sẽ viết lại các phần php blade đó bằng vuejs.

Doctor Steel said:
Lời khuyên cho bác là chỉ nên tập trung cho regression test giai đoạn này thôi. Nếu product đang build theo microservices thì đẩy phần lớn test xuống tầng API. Chứ ko phải cắm mặt vào làm 10k hay 6k5 case kiểu đó.

Cảm ơn bác. Mình sẽ nghiên cứu thêm.

Doctor Steel said:
Mà cách phân định 2k regression/ 6k5 total cũng là tào lao nhé. Ko thể nào tỷ lệ case regression so với total cao như vậy. Trừ khi nó lấy cả những test case râu ria vào bộ regression.

Các con số 2k regression, hay 6k5 total cũng không phải là mình đưa ra á bác. Số liệu này lấy từ test case manual và test case regression hiện có.

Ngohuaanh23 · Nov 16, 2023

AccDuyNhat said:
Do mình dùng từ gây hiểu lầm cho bác. "Covert sang single page" => trước hệ thống viết bằng php blade. Giai đoạn tới sẽ viết lại các phần php blade đó bằng vuejs.

Cảm ơn bác. Mình sẽ nghiên cứu thêm.

Các con số 2k regression, hay 6k5 total cũng không phải là mình đưa ra á bác. Số liệu này lấy từ test case manual và test case regression hiện có.

E làm page object, dùng mindset OOP để design framework. E ko làm theo đa phần rất nhiều ng học từ mấy trang dạy selenium ak. Áp dụng tư duy dev vào thiết kế như 1 hệ thống automation test e thấy hiệu quả hơn trong cách viết code và quản lý data

haisonitpro3 · Nov 17, 2023

AccDuyNhat said:
Chào các bác!

Mình có nhận một yêu cầu thiết kế hệ thống automation test với selenium + mocha. Số lượng test case cỡ trên 10 ngàn test.
Do trước giờ mình cũng không có kinh nghiệm nhiều về thiết kế hệ thống và trình mình cũng không giỏi nên mang lên đây xin ý kiến của các bác để hoàn thiện hơn.

Code mình có đẩy lên repo: GitHub - M1nhNV/selenium (https://github.com/M1nhNV/selenium) và cũng đã viết ý tưởng và cấu trúc source vào README mời các bác xem qua.

Cảm ơn các bác!

Acc ghithub giống thằng cu e mình quen

tranvanlan · Nov 17, 2023

Làm selenium thì cái core trọng nhất phần waiting. Vì từng loại elements phải dùng kiểu wait khác nhau nên nếu phần core implement các loại wait tốt sẽ tránh được rủi ro hare code và đỡ mất công maintain.
Với số lượng case khoảng vài ngàn case thì bắt buộc sẽ có nhiều member và dĩ nhiên trình kỹ thuật không cao, nên framework phải dễ dùng và maintain. Số lượng cases nhiều nghĩa là nhiều case step giống nhau nhưng data sẽ khác, manual viết kiểu vét cạn nên design framework thì phải design functions đủ các parameters sao cho sử dụng lại hiệu quả.
Với những vấn đề trên nên dùng Cucumber để design test script+ test data truyền vào feature file thay vì để file test data (trực quan và dễ dùng lại).
Vì sao dùng Cucumber bởi vì nó là text, thuần test và các parameters+ Data Table, các bạn manual chuyển qua dùng cũng dễ hơn, chỉ là build cực hơn và scripts nhiều hơn.
Và khi build framework bằng Cucumber thì phải giữ mindset là build cho người khác dùng, những bạn low tech dùng, chứ ko phải bản thân dùng.
Cách tiếp cận implement đầu tiên là build bộ smoke test trước, bởi vì smoke sẽ cover các Screen chính của app, từ đó triển khai regression dễ hơn.

toi5 · Nov 17, 2023

AccDuyNhat said:
Chào các bác!

Mình có nhận một yêu cầu thiết kế hệ thống automation test với selenium + mocha. Số lượng test case cỡ trên 10 ngàn test.
Do trước giờ mình cũng không có kinh nghiệm nhiều về thiết kế hệ thống và trình mình cũng không giỏi nên mang lên đây xin ý kiến của các bác để hoàn thiện hơn.

Code mình có đẩy lên repo: GitHub - M1nhNV/selenium (https://github.com/M1nhNV/selenium) và cũng đã viết ý tưởng và cấu trúc source vào README mời các bác xem qua.

Cảm ơn các bác!

gì 10k test cases, project toàn test UI ko hay gì?

cho_coi · Nov 19, 2023

khét lẹt
nhìn số lượng TC muốn xỉu ròi kaka
theo tôi thì cứ xài mấy cái opensource thôi
nếu ông nào đủ skill để build thì sau khi xong cũng tốn thêm mớ time training nữa
tôi thấy cứ thông dụng như java mà phang, sereniry bdd chả hạn, ko thì serenity thuần
còn dễ dùng hơn thì có vẻ là robotframework

thảo luận [automation test] Xin góp ý về thiết kế hệ thống với số lượng test case trên 10.000.

Senior Member

Đã tốn tiền

Senior Member

Senior Member

Senior Member

Đã tốn tiền

Senior Member

Senior Member

Junior Member

Junior Member

Senior Member

Senior Member

Đã tốn tiền

Senior Member

Senior Member

Junior Member

Senior Member

Senior Member

Senior Member

Junior Member

Similar threads

Share this page