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

[Software Testing] Blockchain Testing

[Software Testing] Blockchain Testing

by Admin Dathoc -
Number of replies: 0

#koolj_softwaretesting

#những_mẫu_testcases_cơ_bản

#chiase

#blockchaintesting


Về trải nghiệm THIẾT KẾ testcase và thực hiện test cho ứng dụng chuỗi khối, ứng dụng trên nền tảng blockchain.


(Ad thấy bài viết quảng cáo nhiều quá cứ remove nhé- còn mình viết bài này với tâm tư share 100% những cái gì mình kinh nghiệm công việc trong 41 năm qua)

.

.

Nếu đơn giản nhất, tester cứ tưởng tượng blockchain là một database đặc biệt ứng dụng đầu cuối trên web/mobile móc vào query ra, còn rắc rối hơn là:

- Ban đầu bạn cần đọc một số tài liệu để hiểu thêm về blockchain - hơi khác so với gì bạn thấy nghe xem tin tức tiếng Việt: https://hyperledger-fabric.readthedocs.io/en/release-2.2/

- Sau đó bạn chạy thử và dựng ứng dụng mẫu trên một nền blockchain dựng sẵn để hiểu về các thành phần hệ thống: https://hyperledger-fabric.readthedocs.io/en/release-2.2/test_network.html

.

.

👉Vậy là tester, fans sẽ thấy là:

- Ứng dụng blockchain và nền tảng blockchain thường có 3 phần mà tester cần quan tâm (theo cá nhân - tiếp cận từ 2016):

👉 Phần 1: lõi blockchain - tiếng Việt dịch ra là phần lõi tính toán đồng thuận các giao dịch và mắt xích (chain) các bản ghi với nhau kèm thuật toán mã hoá, cái này điển hình là Bitcoin, Ethereum, hoặc Hyperledger Fabric/Cello/Indy/Sawtooth, gọi là nền tảng. Đây là nơi mà các tổ chức có thể tạo ra riêng (có thể dùng sẵn Bitcoin/Ether/Fabric, hoặc lái đi chút, hoặc tạo ra hẳn cái mới) để điều hành vận hành ứng dụng chạy trên nó. Vậy là Tester cần qua tâm 3 chức năng

+ Tính toán đồng thuận để sinh block

+ Tính toán sinh ra đơn vị gì? với đồng tiền ảo (nếu có) sau mỗi block gắn trên mắt xíc

+ Tính toán gắn kết mắt xích các bản ghi

+ Tính toán mã hoá các bản ghi đủ mạnh

+ Tính toán phân tán từ 1 NƠI LƯU TRỮ (node) các thông tin mắt xích mới được tạo ...sang các NƠI LƯU TRỮ mắt xích khác

+ Tính bảo mật và an toàn của giao thức xử lý các bên tham gia (protocol)

+ Một số mạng có phân quyền: Tính thêm phần phân quyền (như ứng dụng bình thường)

.

.

👉 Phần 2: logic hợp đồng thông minh (Ethereum gọi là smartcontract, Fabric gọi là chaincode), là phần triển khai logic nghiệp vụ mà tổ chức khác mong muốn có trên lõi blockchain. Thông thường logic này quy định: ra vào dữ liệu trên mắt xích, biến đổi theo logic của tổ chức mong muốn. Vậy Tester cần quan tâm trên hợp đồng thông minh

+ Hoạt động dữ liệu ra vào với lõi blockchain

+ Tính toán logic của các chức năng thuộc nghiệp vụ ...mà tổ chức áp dụng: ví dụ tổ chức có hoạt động mua bán; hoạt động cho thuê; cho vay tiền thật; chứng nhận xác nhận tài sản...

+ Tính bảo mật và an toàn của giao thức xử lý giữa smartcontract và lõi blockchain (protocol)


Một số bạn có thể hỏi là: Ơ thế các chức năng nghiệp vụ e để phần web hay client hay mobile có được ko? vì thế cho nó nhẹ smartcontract. 

- Thực ra thì ta nên hiểu thế này: Lõi blockchain chỉ là điện đường trường trạm; nó không có logic gì để tạo những chức năng nếu...một bệnh viện/rạp chiếu phim/nhà băng mọc lên trên đường; hoặc ở trên xóm làng đó. 

- Vậy: lõi blockchain nó phải có phần mềm móc nối với điện, phần mềm mở cổng, xây móng, phần mềm tạo vé/thẻ vào viện/ nhà băng/ rạp chiếu phim; phần mềm để lưu trữ các bản ghi của bệnh viện/rạp chiếu phim/nhà băng vào... chuỗi mắt xích của mạng blockchian đó. Vậy nó cần smartcontract là thế. Còn phần chính các nghiệp vụ thuộc bệnh viện/rạp chiếu phim/nhà băng thì...đa phần vẫn phải có logic xử lý client-server thông thường. Nếu xử lý hết trên smartcontract có thể sẽ bị không phù hợp.

- Còn các phần mềm kết nối đầu cuối, ví dụ như các bạn xem hàng ngày trên điện thoại trên web như: ví giao dịch, phần mềm quản lý thẻ ra vào, quản lý đơn hàng...mà có kết nối blockchain, thực ra nó chỉ là phần logic ra vào giao diện, làm cho phù hợp người dùng. Có thể kết hợp xử lý một phần nghiệp vụ đầu cuối rồi mới đưa vào smartcontract, đưa vào lõi blockchain. Hoặc có thể validate đơn giản và đưa vào smartcontract luôn.


.

.

👉 Phần 3: ứng dụng đầu cuối: thông thường qua web hoặc mobile app, nhằm xử lý một phần logic nghiệp vụ; có thể là một ứng dụng client-server hoàn chỉnh; sau đó bản ghi nào logic nào cần sẽ ...ra vào dữ liệu với lõi blockchain qua hợp đồng thông minh. Vậy là Tester cần quan tâm:

+ Như một ứng dụng thông thường: Các logic nghiệp vụ

+ Các tương tác ra vào với ứng dụng đầu cuối với người dùng

+ Các tương tác ra vào với smartcontract

+ Tính bảo mật của ứng dụng đầu cuối


Để cho rõ hơn bạn có thể theo guideline này để tạo thử một lõi blockchain, rồi một ứng dụng cơ bản trên nó, sau đó bạn sẽ hình dung được cần testing những cái gì: https://hyperledger-fabric.readthedocs.io/en/release-2.2/test_network.html

.

.

.

Vậy tester nên tiếp cận để thiết kế cases cho ứng dụng chuỗi khối, gồm cả 3 phần trên là:

- Như muôn thưở thôi: Unit, Integrate, System, Acceptance


👉Xong một số bạn hỏi tiếp: vậy tester cần kỹ năng gì? 

Đấy nếu xem tới đây có thể một số bạn cho là: Ôi bó tay nhiều phần cần phải test thế. Chứ.. mình tester không biết...coding thì có làm được không?

.

.

Theo quan điểm của mình thế này:

- Rất nhiều lần mình thấy: tester bên mình viết case, và coder thực thi case đó. Vì đơn giản tester bên mình ko code đc. Xong quan trọng là họ tạo ra testcase và bắt buộc họ phải giám sát case đó phải PASS mới cho hệ thống qua vòng test. Vậy đơn giản bạn cũng làm vậy đi. Quan trọng nhất là: Ai là người thiết kế và viết ra testcase mới quyết định phần mềm chất lượng thế nào. Việc thực thi testcase: bạn không làm đưọc whitebox, sẽ phải dùng blackbox để test: tức là theo dõi đầu ra đầu vào. Và nếu cần coding...đơn giản lôi một anh dev sang làm hộ bạn. Bạn validate đầu vào ra.


Sách tham khảo bạn có thể xem: (tham khảo link bên dưới)

Blockchain testing approach: https://1drv.ms/b/s!AoMt1NVPO04zg9ViWq7wWkpZT8-uAw?e=vRYjFK

Smartcontract testing: https://1drv.ms/b/s!AoMt1NVPO04zg9Vj64-upipDigTCXw?e=AX1fuB

.

.

👉Vậy tester cần kỹ năng gì? 

- Tester cần biết cách vận hành ứng dụng trên OS linux, vì một số case chạy theo kiểu cmd và quen với các lệnh linux. Cái này là MUSTHAVE nhé.

- Các nghiệp vụ ứng dụng thông thường bạn quá rõ kỹ năng rồi. Còn những cái liên quan tới blockchain, smartcontrac thì sao

- Đơn giản hoá đi: cứ đơn giản nghĩ smartcontract thực ra...là một ứng dụng phần mềm. Hãy test nó với kỹ năng tester thông thường.

- Và cố gắng validate thêm những nghiệp vụ chuyên về chuỗi khối, ví dụ như hình vẽ, là: mã chuyển hex sang binary, hàm băm, mã hoá rsa, tlsv1.2, thuật toán đồng thuận, thuật toán mã hoá riêng của mắt xích, kết nối mắt xích, thời gian chờ sinh block, đơn vị và tiền ảo sinh sau mỗi block, giao thức tổ chức dùng trao đổi các bên với lõi blockchain, trao đổi phân tán thông tin sang các node (nơi lưu trữ mắt xích), trao đổi với ứng dụng đầu cuối, trao đổi với smartcontract.



Cụ thể hơn, xin đưa ra mấy quan tâm - test case mẫu, từ việc thiết kế case cho kiểm định ứng dụng chuỗi khối:


👉A. Với lõi blockchain (bất kỳ của ai viết) cần quan tâm các testcase: 

1. Contract Application Binary Interface (ABI): Ví dụ Ethereum: validate từ code của (sm- martcontract/chaincode) sinh các mã hexa cho toàn (sm), lõi blockchain nào cũng làm cái này, vì cuối cùng chúng ta chỉ nhìn (sm) dưới dạng hex, và hex dó đã có tool convert ra ascii hoặc unicode để soi lại smartcontract. Và việc vận hành cái chuỗi hex đó. Ra vào sau khi chạy 1 chức năng nó cũng ra hex. Vậy nên cần tool hoặc tự viết tool convert hex ra ascii là cần thiết.

2. Tích hợp các node: Ví dụ Hyperledger Fabric: mỗi node đc coi là một bản sao của toàn dữ liệu mắt xích. Vậy validation đơn giản nhất là compare 2 node, và tại 1 node tạo 1 block xem nó chuyển sang node kia chưa

3. Các state từ bắt đầu có transaction tới khi block tạo xong: VD bất kỳ mạng blockchain nào: cái này mỗi tổ chức làm một kiểu, nên là bạn cần ghi lại thứ tự từ khi có yêu cầu, đi qua (sm) rồi tới loạt thuật toán tính giá trị xử lý yêu cầu, rồi tính giá trị đó bằng với giá trị xử lý của 1 block. Cái này nên chèn thêm case

4. Check block đầu tiên: thông thường đây là nơi cấu hình cho khái niệm block là gì, và cần bao nhiêu năng lượng để tạo block. Đây cũng chính là logic để sinh tiền ảo để thưởng cho các bạn góp phần bỏ công sức mã hoá block (thợ đào - miner)

5. Các key của mỗi account sinh ra: bạn cần đảm bảo user sinh ra sẽ có một rsa key riêng và được lưu nơi an toàn

.

.

6. Test thuật toán sinh block: có cỡ 11 thuật toán: mỗi tổ chức tạo lõi chain có một kiểu tạo thuật toán này: có thể là dựa vào năng lượng xử lý mỗi block, có thể là dựa vào độ tin cậy người tham gia xử lý block, có thể dựa vào vị trí địa lý, có thể là dựa vào tiền bỏ vào xử lý cao hay thấp, hay có thể dựa vào máy xử lý block đang có.

7. Test thuật toán sinh mã hash: Cho dù là kiểu sinh hash gì thì bạn cần lưu ý là: block 1 sẽ nối với block 2 bằng một mắt xích. Nhiệm vụ của bạn là tìm ra logic này. Thêm nữa hash phải đủ an toàn, ko thể hoặc khó dịch ngược lại với máy tính lớn. Time tạo phải đủ nhanh để xử lý cỡ triệu hash cho 1mili giây (gợi ý kpi). Và chính cái mắt xích hash này là key tìm kiếm theo cây nhị phân (do tổ chức đó định nghĩa) có đủ nhanh không, vd tìm 1 block trong 1 triệu block mất 1 mili giây

8. Test giao thức (protocol) giữa các bên: cái này quan trọng nếu tổ chức cần một protocol riêng vậy bạn cần validate cert bắt tay, và data gửi qua lại. Đảm bảo đúng thuật toán trong protocol là đc.

9. Test độ chịu đựng máy ảo của lõi blockchain: cần stress hoặc volume với lượng lớn block và trans, cỡ 1TB, 2TB xem VM xử lý với lõi chain tốt không.

.

.

👉B. Với smartcontract/chaincode (sm) cần lưu ý 1 số testcase đặc thù:

1. Overflow-underflow: lỗi dễ gây tính toán sai do sai kiểu, ngoài vùng kiểu của các loại input. Chú trọng bound

2. Access control: vì (sm) rất quan trọng việc bạn giao tiếp cái gì, cho ai vào xử lý, nên việc xác thực, xác định ai được quyền xử lý và xử lý tới đâu là quan trọng

3. Cơ chế gọi trans: có thể có 3 hoặc nhiều hơn, xong bạn cần quan tâm là các kiểu gọi như vậy có gây cho thread khác xen vào không, và ko tốn vượt quá năng lượng cần dùng

4. Cơ chế xử lý nếu có lỗi: mọi (sm) đều cần làm cái này, func đơn giản của app đơn giản cũng có cái này nghĩa là (sm)

5. Cơ chế huỷ (sm) hoặc tạo (sm) mới khi upgrade: (sm) đc lập trình để làm cái gì đó lâu dài, vậy rất cần định nghĩa lại nó đc upgrade lên thì những cái cũ đã hoàn toàn bỏ hết đi chưa

6. Test các hàm-biến-đổi từ hàm khác: cái này là thuật ngữ riêng, tuỳ (sm) loại nào mới có. Bạn cần quan tâm là nếu các biến-đổi được thỏa mãn thì hàm này sẽ chạy. Vậy có khả năng từ nguồn khác tạo ra biến-đổi và hàm sẽ được thực thi khi chủ nhân chưa cho phép.


👉C. Với ứng dụng móc với sm - với lõi blockchain 

- Chẳng khác gì ứng dụng software bình thường

- Các mẫu function, gui, usability, về security, performance, load bạn có thể tham khảo các bài viết khác của tôi về các phần này

.

.

.

Thực hiện testing:

- Ví dụ cách mình test operation với một blockchain: https://www.youtube.com/watch?v=zxiTYuQBRMw

- Ví dụ cách mình thiết kế case cho security test cho blockchain: https://www.youtube.com/watch?v=j6MNGbcdqmI

.

.

.

Vậy bạn có thể kết hợp các gợi ý trên để tạo ra những blockchain testcases hoàn hảo hơn.

Gluk!

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

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