Bài viết sử dụng mô hình tăng trưởng độ tin cậy NHPP (Non-Homogeneous Poisson Process) để đánh giá, xác định độ tin cậy của các ứng dụng di động thông qua việc áp dụng các kỹ thuật, phương pháp kiểm thử và kiểm thử tự động đã được chúng tôi công bố ở các nghiên cứu trước như (1) kỹ thuật tối ưu mã nguồn, (2) kiểm thử hướng ngữ cảnh One2explore, (3) ứng dụng Heuristics và Machine learning trong kiểm thử, (4) sinh kiểm thử tự động từ user stories và acceptance criteria.
Journal of Science and Technique - Le Quy Don Technical University - No 199 (6-2019) THỬ NGHIỆM ĐÁNH GIÁ ÁP DỤNG MỘT SỐ KỸ THUẬT KIỂM THỬ ĐỂ NÂNG CAO ĐỘ TIN CẬY CHO ỨNG DỤNG DI ĐỘNG TRONG MÔI TRƯỜNG PHÁT TRIỂN LINH HOẠT Nguyễn Thanh Hùng1 , Nguyễn Đức Mận2 , Huỳnh Quyết Thắng1 Tóm tắt Hệ sinh thái ứng dụng di động phát triển nhanh với hàng triệu ứng dụng hàng trăm nghìn nhà phát triển năm gần Trong xu hướng cạnh tranh, để sản phẩm ứng dụng di động tin dùng, nhà phát triển cần có kỹ thuật, phương pháp công cụ để (i) nâng cao hiệu việc kiểm thử trình phát triển xác định thất bại tiềm ẩn trước ứng dụng phát hành, (ii) đánh giá độ tin cậy phần mềm từ liệu thực nghiệm pha trình phát triển sản phẩm phần mềm, dựa vào kỹ thuật đánh giá nhằm tính toán giá trị độ đo độ tin cậy phần mềm (iii) hiệu suất đối mặt với điều kiện khác sử dụng thực tế Trong nghiên cứu này, chúng tơi sử dụng mơ hình tăng trưởng độ tin cậy NHPP (Non-Homogeneous Poisson Process) để đánh giá, xác định độ tin cậy ứng dụng di động thông qua việc áp dụng kỹ thuật, phương pháp kiểm thử kiểm thử tự động công bố nghiên cứu trước (1) kỹ thuật tối ưu mã nguồn, (2) kiểm thử hướng ngữ cảnh One2explore, (3) ứng dụng Heuristics Machine learning kiểm thử, (4) sinh kiểm thử tự động từ user stories acceptance criteria Kết nghiên cứu thực nghiệm đánh giá dự án thực tế, thử nghiệm số ứng dụng Android từ kho mã nguồn FOSS cho kết tích cực giúp cho nhà phát triển ứng dụng Android cải tiến chất lượng, nâng cao độ tin cậy hiệu phát triển ứng dụng di động môi trường phát triển linh hoạt cạnh tranh Từ khóa Kỹ thuật kiểm thử; kiểm thử ứng dụng di động; độ tin cậy ứng dụng di động; phát triển phần mềm linh hoạt Giới thiệu Phần mềm sử dụng lĩnh vực sống đại Tuy nhiên, phần mềm có lỗi thất bại dẫn đến hậu quả, tai nạn thảm khốc, gây thiệt hại lớn kinh tế người [1] Vì vậy, chất lượng phần mềm trở thành vấn đề quan trọng thuộc tính chất lượng phần Đại học Bách khoa Hà Nội, Đại học Duy Tân 35 Section on Information and Communication Technology (ICT) - No 13 (6-2019) mềm vấn đề tập trung nghiên cứu nhiều năm qua [1] Độ tin cậy thuộc tính quan trọng phần mềm liên quan đến hoạt động tính xác sản phẩm Độ tin cậy phần mềm xác suất mà hệ thống phần mềm hoạt động mà khơng có thất bại mơi trường định khoảng thời gian định [35] Kỹ nghệ độ tin cậy phần mềm SRE (Software Realiability Engineering) nghiên cứu phát triển để giải vấn đề độ tin cậy Các kỹ thuật dự đoán, đánh giá độ tin cậy phần mềm thường dựa chủ yếu vào mơ hình tốn học, kỹ thuật thống kê đóng vai trị quan trọng Hàng trăm mơ hình độ tin cậy nghiên cứu phát triển thập kỷ qua [35] Các mơ hình xác định biện pháp thích hợp cho độ tin cậy mục đích chúng ước tính dự đốn độ tin cậy phần mềm dựa liệu thất bại thu thập trình phát triển, thử nghiệm sau phát hành Các thước đo độ tin cậy bao gồm thời gian trung bình thất bại (MTTF), thời gian trung bình thất bại (MTBF), cường độ hỏng hóc, thời gian thử nghiệm bổ sung cần thiết để đạt mục tiêu độ tin cậy đó, cơng cụ trợ giúp cho người quản lý phần mềm đưa định kiểm thử tiếp hay phát hành sản phẩm [35] Sự khác biệt độ tin cậy ứng dụng máy tính để bàn điện thoại thơng minh xuất phát từ lý [2], [4] sau: khác biệt phần cứng; khác biệt hệ điều hành (OS); khác biệt tính chất kích cỡ ứng dụng thực máy tính để bàn điện thoại thông minh; khác biệt môi trường hoạt động (ở đâu thiết bị sử dụng) hồ sơ sử dụng (cách thiết bị sử dụng) hai trường hợp cuối khác biệt chức hiển thị Việc đo lường, đánh giá độ tin cậy ứng dụng phần mềm, hệ thống phần mềm nhiều phương pháp, kỹ thuật khác nhau, phổ biến mơ hình tăng trưởng độ tin cậy phần mềm (SRGMs), cụ thể như: NHPP, Musa, Nelson, Hiện có hai hướng tiếp cận việc đo lường xác định độ tin cậy phần mềm: • • (i) Dự đốn độ tin cậy phần mềm: từ thơng số hệ thống dự án phát triển sản phẩm phần mềm, dựa vào kỹ thuật dự đoán nhằm ước tính giá trị độ đo độ tin cậy phần mềm (ii) Đánh giá độ tin cậy phần mềm: từ liệu thực nghiệm pha trình phát triển sản phẩm phần mềm, dựa vào kỹ thuật đánh giá nhằm tính tốn giá trị độ đo độ tin cậy phần mềm Giá trị độ đo độ tin cậy phần mềm thông số quan trọng sử dụng nhiều pha khác trình phát triển sản phẩm phần mềm: lập trình, gỡ lỗi, phát hành bảo trì Việc sử dụng thông số giúp gia tăng chất lượng hỗ trợ thao tác định pha Phương pháp phát triển linh hoạt (Agile) phương pháp hướng đến cách tiếp cận phi truyền thống, làm bật hợp tác khách hàng, thành viên nhóm có động lực cao, cung cấp phần mềm chất lượng cao, khả thích ứng với thay đổi trì đơn giản phát triển [16], [43] Cách tiếp cận linh hoạt tuân theo triết lý phát hành sớm, phát hành thường xuyên, nhấn mạnh tầm quan trọng việc phát hành sớm thường xuyên hệ thống Các phát hành sớm phần mềm cung cấp sản phẩm 36 Journal of Science and Technique - Le Quy Don Technical University - No 199 (6-2019) cốt lõi với chức hạn chế phát hành tăng thêm chức mới, sửa chữa lỗi có điều chỉnh cơng nghệ Vì phát hành thêm mã vào hệ thống, có khả đưa lỗi Mặc dù phát hành có nghĩa để cải thiện hệ thống, ln có khả bị thối hóa bổ sung lỗi Về bản, phát hành thêm số nội dung lỗi vào hệ thống có Trong giai đoạn phát hành thường xuyên thực làm tăng tỷ lệ thất bại chung, làm giảm độ tin cậy hệ thống Các nghiên cứu [4], [13], [14], [16]–[18], [43], [46] sở đề đề xuất việc áp dụng số kỹ thuật kiểm thử vào quy trình phát triển Agile Scrum Trong phạm vi nghiên cứu này, thực việc đánh giá độ tin cậy ứng dụng di động mơ hình tăng trưởng độ tin cậy phần mềm thông qua việc áp dụng kỹ thuật tối ưu hóa tái cấu trúc mã nguồn, kỹ thuật PMD Android Lint, kỹ thuật sinh ca kiểm thử tự động dựa User story điều kiện chấp nhận, kỹ thuật kiểm thử hướng ngữ cảnh, kỹ thuật ứng dụng Heuristics học máy (ML) nghiên cứu công bố [21]–[26], [49] Chúng đề xuất quy trình, cách thực vận dụng hiệu kỹ thuật để nâng cao độ tin cậy cho ứng dụng di động thử nghiệm, đánh giá kết áp dụng quy trình số dự án thực tế Các nội dung báo trình bày tổng quan khái niệm liên quan phần 2, nghiên cứu liên quan trình bày phần Phần trình bày quy trình kỹ thuật kiểm thử nhằm nâng cao độ tin cậy cho ứng dụng di động Phần thảo luận kết thực nghiệm Kết luận hướng phát triển trình bày phần Các khái niệm nghiên cứu liên quan 2.1 Độ tin cậy phần mềm Theo tiêu chuẩn chất lượng quốc tế chất lượng phần mềm ISO/IEC 25010 (ISO/IEC 25000:2014) [5], [32], độ tin cậy đặc tính chất lượng Độ tin cậy có ứng dụng định pha khác vịng đời phần mềm: thiết kế, lập trình, kiểm thử triển khai Theo tác giả Chengjie [40]: Độ tin cậy xác suất phần mềm hoạt động không lỗi điều kiện cho trước khoảng thời gian xác định Trong Lyu [35] định nghĩa: Độ tin cậy xác suất phần mềm khơng có lỗi hoạt động khoảng thời gian xác định điều kiện xác định Tiêu chuẩn IEEE 610.12-1990 [5] định nghĩa độ tin cậy "Khả hệ thống phận để thực chức cần thiết theo điều kiện nêu khoảng thời gian định" Độ tin cậy phần mềm bao gồm ba hoạt động: (i) Phòng tránh lỗi; (ii) Phát lỗi gỡ bỏ; (iii) Các phép đo để tối đa hóa độ tin cậy, cụ thể biện pháp hỗ trợ hai hoạt động (i) (ii) Đã có nhiều nghiên cứu đo độ tin cậy cách sử dụng thời gian trung bình thất bại thời gian trung bình để thất bại Mơ hình hóa thành cơng thực để dự đoán tỷ lệ lỗi độ tin cậy [5] Các hoạt động giải khía cạnh thứ ba độ tin cậy, xác định loại bỏ lỗi để phần mềm hoạt động mong đợi với độ tin cậy xác định 37 Section on Information and Communication Technology (ICT) - No 13 (6-2019) 2.2 Biểu diễn toán học cho độ tin cậy Về phương diện toán học, hàm tin cậy hệ thống R(t) xác suất mà hệ thống hoạt động thành công khoảng thời gian từ đến thời điểm t: R(t) = P (T > t), t > với T biến ngẫu nhiên biểu diễn thời gian thất bại, thời gian từ lúc hoạt động đến lúc bị lỗi Xác suất thất bại là: F (t) = 1- R(t) = P(T P' (5) Kỹ thuật trực quan hóa kiểm thử -One2Explore & Heurictics-ML -Shinobi (6) [test data unit level] Yêu cầu phần mềm (User stories, Product backlog) Đặc tả yêu cầu chi tiết (User story spec, break US in to tasks, AC) cho sprint thứ i (1) Kiểm thử chấp nhận (User acceptance test) (3) (2) Sprint thứ i + Phát hành Phiên bản thứ i Sản phầm Hình Quy trình phát triển Scrum có đề xuất ứng dụng kỹ thuật kiểm thử tối ưu hóa mã nguồn Quy trình Scrum bao gồm giai đoạn lấy yêu cầu, đề xuất yêu cầu chủ sản phẩm (Product Owner -PO) việc đưa câu chuyện người dùng (User stories (US), Product backlog) [17] Từ Product Backlog, PO đội phát triển chọn lựa thực US ưu tiên thực trước để hình thành nên sprint phát triển (i=1), sprint có thời gian từ đến tuần Tại giai đoạn (thành phần (1) Hình trên), PO với đội phát triển đặc tả chi tiết câu chuyện người dùng (US), đưa điều kiện chấp nhận (Acceptance criteria – AC) cho US, phân rã US thành công việc cụ thể để giao việc cho thành viên đội Sau có đặc tả chi tiết sang giai đoạn lập trình kiểm thử đơn vị (thành phần (2) Hình 2) Ở giai đoạn này, đội phát triển dùng phương pháp TDD (Test-Driven Development), BDD (Behavior Driven Development) để thực “Viết thực thi kiểm thử trước – Lập trình – Thực thi kiểm thử tái cấu trúc mã nguồn” Kết thúc tính (feature/ mơ đun) chuyển sang giai đoạn kiểm thử chấp nhận (thành phần (3) Hình 2) Giai đoạn người kiểm thử (và PO) thực kiểm thử mức người dùng để đảm bảo yêu cầu phát hành phiên thứ (hoặc thứ i, i=1,n) Kết thúc phát hành phiên thứ i, đội phát triển PO tiếp tục chọn phát triển US cho phiên thứ i+1 Đề xuất áp dụng kỹ thuật sau giai đoạn: • Ở giai đoạn (1) chúng tơi đề xuất áp dụng kỹ thuật sinh ca kiểm thử (test case) liệu kiểm thử (test input) suy diễn từ US AC thông qua sử dụng phương pháp đặc tả hình thức Kỹ thuật (trong thành phần (4) Hình 2) mơ tả phần 4.2 c), kết đầu kỹ thuật sử dụng giai đoạn (2) (3) 43 Section on Information and Communication Technology (ICT) - No 13 (6-2019) • • Ở giai đoạn (2), kỹ thuật tối ưu mã nguồn PMD Android Lint, Kỹ thuật phân tích kiểm thử mã nguồn Java đề xuất áp dụng Mô tả kỹ thuật trình bày phần 4.2.1) 4.2.2), thành phần (5) Hình Ở giai đoạn (3), kỹ thuật trực quan hóa kiểm thử hướng ngữ cảnh kỹ thuật áp dụng Heurictics – học máy kiểm thử ứng dụng mobile web đề xuất áp dụng (thành phần 6), hai kỹ thuật thực nghiên cứu tương lai Như vậy, Hình 2, kỹ thuật đề xuất (4), (5), (6) nhằm mục đích cải tiến, nâng cao hiệu năng, tăng chất lượng độ tin cậy ứng dụng di động, cho giai đoạn (1), (2), (3) theo quy trình Scrum 4.2 Các kỹ thuật kiểm thử đề xuất áp dụng 4.2.1 Kỹ thuật phân tích tối ưu mã nguồn sử dụng PMD - Android lint: Mơ hình độ tin cậy liên quan mật thiết đến trình phát lỗi phần mềm Quá trình bao gồm thời điểm phát lỗi toàn vòng đời phần mềm Kỹ thuật tối ưu mã nguồn sử dụng PMD Android lint, sử dụng cú pháp trừu tượng đánh giá ảnh hưởng việc giảm thiểu lỗi hệ thống qua nâng cao độ tin cậy ứng dụng di động, kỹ thuật nghiên cứu công bố [21], [22] Tối ưu mã nguồn Java: Khi kích thước phần mềm tăng nhanh, Hình Màn hình cơng cụ phân tích, tối ưu hóa tái cấu trúc mã nguồn nhà nghiên cứu tập trung vào việc tối ưu mã nguồn để tiết kiệm tài nguyên A V Aho [36] quan tâm đến việc tối ưu mã nguồn vấn đề tốn trình biên dịch Ngày nay, số trình dịch tối ưu hóa mã nguồn ngữ cảnh gọi "mức trình dịch" (compile level) Tuy nhiên, việc tối ưu mã nguồn nên thực thủ công lập trình viên kỹ thuật phức tạp để thực tự động Lập trình an tồn liên quan đến vấn đề lỗi: phát hiện, chịu lỗi, lưu, biến cần định nghĩa quyền truy cập, đối tượng cần thiết lập "uncloneable" Từ tốn tối ưu hóa mã nguồn để nâng cao độ tin cậy cho ứng dụng di động trình bày [21], chúng tơi xây dựng tập luật để đưa 44 Journal of Science and Technique - Le Quy Don Technical University - No 199 (6-2019) vào PMD kết hợp với Android lint để nhằm mục đích tối ưu hiệu (mức tiêu thụ lượng) cho ứng dụng di động, tăng độ tin cậy cho ứng dụng cách tối ưu mã nguồn, phát thành phần tiềm năng, thay đổi mã nguồn, tái cấu trúc mã nguồn cho ứng dụng, cụ thể: (i) sử dụng luật phát thành phần tiềm mã nguồn Mỗi luật tác động đến thành phần khác mã nguồn, thành phần kết trình chuyển đổi để có cú pháp từ mã nguồn (ii) Sử dụng luật để thay đổi mã nguồn Sau phát thành phần tiềm năng, phần việc sửa đổi mã nguồn để không vi phạm luật Người phát triển phải định làm để chuyển đổi mã nguồn Kỹ thuật được đề xuất vận dụng vào giai đoạn (2) Hình Khi đó, kỹ sư phát triển vận dụng vào kiểm thử mức đơn vị, thực phân tích cấu trúc mã nguồn cơng cụ trình bày [21] để tìm thành phần vi phạm luật đề xuất AvoidSynchronizedBlocksInLoop, UseToArrayWithArrayAsParameter, tránh sử dụng DataInputStream.readByte() vòng lặp, từ thực tái cấu trúc mã nguồn thơng qua gợi ý công cụ hỗ trợ dựa vào kiến thức kỹ sư để điều chỉnh mã nguồn theo hướng tối ưu nâng cao chất lượng mã nguồn Công cụ phát triển dạng plug-in vào IDE java (thư viện java) để dễ dàng cho kỹ sư phần mềm áp dụng lúc lập trình 4.2.2 Kỹ thuật kiểm thử mã nguồn Java: Việc đánh giá mức độ bao phủ mã nguồn xác định lỗi cấu trúc, logic đánh giá khả chịu lỗi chương trình, phương thức (hay hàm) kiểm thử hộp trắng hoạt động quan trọng cần thiết để đảm bảo chương trình hoạt động tin cậy Trong nghiên cứu [23], chúng tơi trình bày kỹ thuật kiểm thử mã nguồn cho phương thức (chương trình con) lớp viết ngơn ngữ lập trình Java Thơng qua kỹ thuật kiểm thử này, biết độ bao phủ câu lệnh, độ bao phủ nhánh độ bao phủ đường mã nguồn phương thức viết Áp dụng kỹ thuật biết phương thức tồn loại lỗi nào; với liệu đầu vào phương thức bộc lộ lỗi; phương thức chưa xử lý chặt khiến khả chịu lỗi Từ tất thơng tin thu từ mơ hình kiểm thử này, người phát triển nhanh chóng tìm giải pháp để chỉnh sửa lại mã nguồn giúp phương thức viết gặp lỗi, bộc lộ lỗi tăng khả chịu lỗi cao Mục đích q trình kiểm thử mã nguồn có lỗi lỗi gì, nằm đâu Trong trường hợp q trình kiểm thử phát chương trình có lỗi khơng khoanh vùng xác vị trí lỗi đâu loại lỗi chương trình thực thi với liệu kiểm thử cụ thể Với tất thông tin độ bao phủ mã nguồn, độ bao phủ nhánh, độ bao phủ đường, thông tin lỗi, thông tin liệu vào giúp phát lỗi thông tin liệu vào mà chương trình chưa xử lý chặt nhằm giúp người lập trình có đủ thơng tin để tìm cách sửa lại phần mã nguồn chưa hay chưa hiệu quả, thơng qua tăng độ xác, độ tin cậy chương trình viết Kỹ thuật đề xuất vận dụng giai đoạn (2) Hình 2, kỹ sư phát triển áp dụng công cụ hỗ trợ kiểm thử mức đơn vị để tìm lỗi tìm ẩn thuật toán, kiểm tra khả chịu lỗi mức độ bao phủ dòng lệnh 45 Section on Information and Communication Technology (ICT) - No 13 (6-2019) Hình Màn hình cơng cụ hỗ trợ phân tích mã nguồn tìm lỗi tiềm ẩn hàm, mơ-đun lập trình ngơn ngữ Java Kỹ thuật đề xuất công cụ nghiên cứu [23] sử dụng thư viện plug-in cho môi trường phát triển IDE Java Eclipse, Android studio giúp người phát triển dễ dàng thực phân tích mã nguồn, kiểm thử để tìm lỗi thực tái cấu trúc mã nguồn từ nâng cao chất lượng mã nguồn, góp phần làm tăng chất lượng cho ứng dụng 4.2.3 Kỹ thuật sinh test case test input từ yêu cầu người dùng điều kiện chấp nhận: Đối với người kiểm thử ứng dụng di động, thay đổi nhanh chóng ứng dụng di động đẩy họ đến việc cần tiết, tỉ mỉ, để ý thứ khác lúc chuẩn bị cho tình hỏng hóc khơng mong đợi [27] Do đó, việc tạo test case thực thi kiểm thử trở nên tải thao tác tẻ nhạt Ngồi ra, vịng đời ứng dụng di động ngắn dẫn đến nhiều áp lực cho người kiểm thử Người kiểm thử đối mặt với vấn đề "Thời gian để đưa thị trường" "Chất lượng cao", “độ tin cậy ứng dụng”, yêu cầu họ phân bổ thời gian để kiểm tra sửa lỗi cách áp dụng phương pháp kiểm thử [28], [29] Kiểm thử sớm giúp cho đội dự án có chiến lược phát triển kiểm thử hợp lý [30] Tuy nhiên, thử nghiệm sớm phải hệ thống tương thích q trình phát triển phần mềm Hầu hết cơng ty phát triển phần mềm có xu hướng áp dụng số phương pháp phát triển linh hoạt (XP, Scrum) để đảm bảo sản phẩm phát hành thị trường sớm với chất lượng cao, độ tin cậy cao Với phương phát triển linh hoạt (Agile), yêu cầu phần mềm xác định khác với phương pháp truyền thống khác [29] Trong dự án nghiên cứu đề xuất kỹ thuật tiếp cận cho việc sinh trường hợp thử nghiệm liệu thử nghiệm thơng qua suy luận mơ hình dựa user story (US) acceptance criteria (AC) dự 46 Journal of Science and Technique - Le Quy Don Technical University - No 199 (6-2019) án [49] Kèm theo cơng cụ hỗ trợ nhằm giúp người thử nghiệm / nhà phát triển tạo trường hợp thử nghiệm tự động (test case/ test inputs) Hình Hình Công cụ hỗ trợ sinh test case test data, test script dựa US AC User stories Acceptance criteria cung cấp PO (product owner tester), công đoạn tester dựa vào mô tả yêu cầu điều kiện chấp nhận mà đặc tả lại yêu cầu đặc tả hình thức (formal specification) theo ngơn ngữ nhóm nghiên cứu đề xuất để từ sử dụng cơng cụ xây dựng sinh liệu test case test input dựa đặc tả Công cụ sinh test case/ test input sử dụng Z3 SMT solver để thực Kết test case test input sinh dùng cho developer sử dụng kiểm thử tự động công cụ Cucumber theo phương pháp BDD; và/ sử dụng cho kiểm thử mức system ứng dụng [49] Kỹ thuật thực nghiệm với miền đầu vào liệu số (int, real), Boolean loại liệu chuỗi, thay đổi thành độ dài chuỗi (len (st)), tìm chuỗi con, chuỗi chứa giá trị Miền giá trị đầu vào chọn hợp lệ, không hợp lệ, sử dụng phương pháp phân vùng tương đương, đường biên theo điều kiện chấp nhận user story User story mô tả theo cú pháp: “As a < type of user >, I want < some goal > so that < some reason >” điều kiện chấp nhận mô tả theo cú pháp: “When I < input > X and < process > Y, I will check for < outcome >Z as the result” Bảng ví dụ việc đặc tả user story điều kiện chấp nhận (AC) tương ứng cho tính đăng ký tài khoản (Register Account) ứng dụng ACMapp thực nghiệm phần Kỹ thuật vận dụng giai đoạn (2) Hình Kết thực kỹ thuật đề xuất test case test input cho user story ứng dụng sử dụng cho giai đoạn (3) Hình để thực kiểm thử theo phương pháp BDD giai đoạn (4) Hình để thực kiểm thử chức mức hệ thống (thực kiểm thử tự động thủ công) 4.3 Phương pháp thực nghiệm Đánh giá độ tin cậy ứng dụng di động áp dụng 03 kỹ thuật đề xuất phần 4.2 theo quy trình trình bày phần 4.1, mơ tả Hình 6, gồm 06 bước sau: 47 Section on Information and Communication Technology (ICT) - No 13 (6-2019) Bảng User stories Acceptance criteria mô tả cho tính Register ứng dụng ACMapp Story No US01 AC ID AC1 AC2 Các tính (features) Đăng kýRegistration Câu chuyện người dùng (User story) Mô tả Là người tham dự hội nghị, tơi đăng ký tài khoản tham dự hội nghị Đầu vào (Input) Các liệu vào hợp lệ: tên tài khoản, họ tên, email, mật khẩu, thông tin chi tiết Tên tài khoản không hợp lệ Xử lý/ điều kiện (Process) Tất trường không để trống, tên tài khoản >=4