Để hỗ trợ trang tổng quan tích hợp liên tục có khả năng mở rộng, hiệu quả và linh hoạt, bạn phải thiết kế cẩn thận phần phụ trợ của Trang tổng quan VTS với sự hiểu biết sâu sắc về chức năng cơ sở dữ liệu. Google Cloud Datastore là một cơ sở dữ liệu NoSQL cung cấp các đảm bảo về tính chất ACID của giao dịch và tính nhất quán cuối cùng cũng như tính nhất quán mạnh mẽ trong các nhóm thực thể. Tuy nhiên, cấu trúc này rất khác với cơ sở dữ liệu SQL (và thậm chí cả Cloud Bigtable); thay vì bảng, hàng và ô, có các loại, thực thể và thuộc tính.
Các phần sau đây trình bày cấu trúc dữ liệu và mẫu truy vấn để tạo một phần phụ trợ hiệu quả cho dịch vụ web Trang tổng quan VTS.
Số thực thể
Các thực thể sau đây lưu trữ bản tóm tắt và tài nguyên từ các lần chạy kiểm thử VTS:
- Thực thể kiểm thử. Lưu trữ siêu dữ liệu về các lần chạy kiểm thử của một kiểm thử cụ thể. Khoá của thuộc tính này là tên kiểm thử và các thuộc tính của thuộc tính này bao gồm số lượng lỗi, số lượng kiểm thử đạt và danh sách các trường hợp kiểm thử bị lỗi kể từ khi công việc cảnh báo cập nhật thuộc tính này.
- Thực thể chạy kiểm thử. Chứa siêu dữ liệu từ các lần chạy của một bài kiểm thử cụ thể. Tệp này phải lưu trữ dấu thời gian bắt đầu và kết thúc kiểm thử, mã bản dựng kiểm thử, số lượng trường hợp kiểm thử đạt và không đạt, loại lượt chạy (ví dụ: trước khi gửi, sau khi gửi hoặc cục bộ), danh sách đường liên kết nhật ký, tên máy chủ lưu trữ và số liệu tóm tắt về mức độ sử dụng.
- Thực thể thông tin thiết bị. Chứa thông tin chi tiết về các thiết bị được sử dụng trong quá trình chạy kiểm thử. Tệp này bao gồm mã bản dựng thiết bị, tên sản phẩm, mục tiêu bản dựng, nhánh và thông tin ABI. Dữ liệu này được lưu trữ riêng biệt với thực thể chạy kiểm thử để hỗ trợ chạy kiểm thử trên nhiều thiết bị theo kiểu một với nhiều.
- Thực thể chạy điểm phân tích tài nguyên. Tóm tắt dữ liệu được thu thập cho một điểm phân tích tài nguyên cụ thể trong một lần chạy kiểm thử. Tệp này mô tả các nhãn trục, tên điểm phân tích, giá trị, loại và chế độ hồi quy của dữ liệu phân tích.
- Thực thể phạm vi. Mô tả dữ liệu về mức độ sử dụng được thu thập cho một tệp. Tệp này chứa thông tin dự án Git, đường dẫn tệp và danh sách số lượng lượt bao phủ trên mỗi dòng trong tệp nguồn.
- Thực thể chạy trường hợp kiểm thử. Mô tả kết quả của một trường hợp kiểm thử cụ thể từ một lần chạy kiểm thử, bao gồm tên trường hợp kiểm thử và kết quả của trường hợp kiểm thử đó.
- Thực thể yêu thích của người dùng. Mỗi gói thuê bao của người dùng có thể được biểu thị trong một thực thể chứa tham chiếu đến thử nghiệm và mã nhận dạng người dùng được tạo từ dịch vụ người dùng App Engine. Điều này cho phép truy vấn hai chiều hiệu quả (tức là cho tất cả người dùng đã đăng ký một bài kiểm thử và cho tất cả bài kiểm thử mà người dùng đã đánh dấu là yêu thích).
Nhóm thực thể
Mỗi mô-đun kiểm thử đại diện cho thư mục gốc của một nhóm thực thể. Các thực thể chạy kiểm thử vừa là con của nhóm này vừa là thực thể mẹ của các thực thể thiết bị, thực thể điểm phân tích tài nguyên và thực thể mức độ sử dụng có liên quan đến thực thể gốc kiểm thử và chạy kiểm thử tương ứng.
Điểm chính: Khi thiết kế mối quan hệ về nguồn gốc, bạn phải cân bằng nhu cầu cung cấp cơ chế truy vấn hiệu quả và nhất quán với các giới hạn do cơ sở dữ liệu thực thi.
Lợi ích
Yêu cầu về tính nhất quán đảm bảo rằng các thao tác trong tương lai sẽ không thấy tác động của một giao dịch cho đến khi giao dịch đó được xác nhận và các giao dịch trong quá khứ sẽ hiển thị cho các thao tác hiện tại. Trong Cloud Datastore, tính năng nhóm thực thể tạo ra các đảo có tính nhất quán cao về việc đọc và ghi trong nhóm, trong trường hợp này là tất cả các lần chạy kiểm thử và dữ liệu liên quan đến một mô-đun kiểm thử. Điều này mang lại các lợi ích sau:
- Các thao tác đọc và cập nhật trạng thái mô-đun kiểm thử theo công việc cảnh báo có thể được coi là nguyên tử
- Đảm bảo chế độ xem nhất quán về kết quả trường hợp kiểm thử trong các mô-đun kiểm thử
- Truy vấn nhanh hơn trong cây phả hệ
Các điểm hạn chế
Bạn không nên ghi vào một nhóm thực thể với tốc độ nhanh hơn một thực thể mỗi giây vì một số hoạt động ghi có thể bị từ chối. Miễn là các công việc cảnh báo và quá trình tải lên không diễn ra với tốc độ nhanh hơn một lần ghi mỗi giây, thì cấu trúc sẽ vững chắc và đảm bảo tính nhất quán cao.
Cuối cùng, giới hạn một lần ghi cho mỗi mô-đun kiểm thử mỗi giây là hợp lý vì các lần chạy kiểm thử thường mất ít nhất một phút, bao gồm cả chi phí của khung VTS; trừ phi một kiểm thử được thực thi đồng thời một cách nhất quán trên hơn 60 máy chủ khác nhau, thì không thể có nút thắt cổ chai ghi. Điều này càng khó xảy ra hơn khi mỗi mô-đun là một phần của kế hoạch kiểm thử thường mất hơn một giờ. Bạn có thể dễ dàng xử lý các trường hợp bất thường nếu máy chủ chạy các chương trình kiểm thử cùng một lúc, gây ra các đợt ghi ngắn vào cùng một máy chủ (ví dụ: bằng cách phát hiện lỗi ghi và thử lại).
Những điều cần cân nhắc khi mở rộng quy mô
Một lần chạy kiểm thử không nhất thiết phải có kiểm thử làm thành phần mẹ (ví dụ: lần chạy này có thể lấy một số khoá khác và có tên kiểm thử, thời gian bắt đầu kiểm thử làm thuộc tính); tuy nhiên, việc này sẽ đánh đổi tính nhất quán mạnh mẽ để có được tính nhất quán cuối cùng. Ví dụ: công việc cảnh báo có thể không thấy ảnh chụp nhanh nhất quán lẫn nhau của các lần chạy kiểm thử gần đây nhất trong một mô-đun kiểm thử, tức là trạng thái toàn cục có thể không mô tả chính xác hoàn toàn trình tự chạy kiểm thử. Điều này cũng có thể ảnh hưởng đến việc hiển thị các lần chạy kiểm thử trong một mô-đun kiểm thử. Đây không nhất thiết phải là ảnh chụp nhanh nhất quán của trình tự chạy. Cuối cùng, ảnh chụp nhanh sẽ nhất quán, nhưng không có gì đảm bảo rằng dữ liệu mới nhất sẽ được cung cấp.
Các trường hợp kiểm thử
Một nút thắt cổ chai tiềm ẩn khác là các chương trình kiểm thử lớn với nhiều trường hợp kiểm thử. Hai điều kiện ràng buộc hoạt động là tốc độ truyền dữ liệu ghi tối đa trong một nhóm thực thể là 1 mỗi giây, cùng với kích thước giao dịch tối đa là 500 thực thể.
Một phương pháp là chỉ định một trường hợp kiểm thử có một lần chạy kiểm thử làm thành phần cấp trên (tương tự như cách lưu trữ dữ liệu mức độ sử dụng, dữ liệu phân tích tài nguyên và thông tin thiết bị):
Mặc dù phương pháp này mang lại tính nguyên tử và tính nhất quán, nhưng phương pháp này cũng đặt ra các giới hạn mạnh mẽ đối với kiểm thử: Nếu một giao dịch bị giới hạn ở 500 thực thể, thì một kiểm thử không được có nhiều hơn 498 trường hợp kiểm thử (giả sử không có dữ liệu về mức độ sử dụng hoặc hồ sơ). Nếu một kiểm thử vượt quá giới hạn này, thì một giao dịch không thể ghi tất cả kết quả trường hợp kiểm thử cùng một lúc và việc chia các trường hợp kiểm thử thành các giao dịch riêng biệt có thể vượt quá tốc độ ghi nhóm thực thể tối đa là một vòng lặp mỗi giây. Bạn không nên sử dụng giải pháp này vì giải pháp này sẽ không mở rộng quy mô hiệu quả mà không làm giảm hiệu suất.
Tuy nhiên, thay vì lưu trữ kết quả trường hợp kiểm thử dưới dạng phần tử con của lần chạy kiểm thử, bạn có thể lưu trữ các trường hợp kiểm thử một cách độc lập và cung cấp khoá của các trường hợp kiểm thử đó cho lần chạy kiểm thử (một lần chạy kiểm thử chứa danh sách giá trị nhận dạng cho các thực thể trường hợp kiểm thử):
Thoạt nhìn, điều này có vẻ như vi phạm cam kết về tính nhất quán mạnh. Tuy nhiên, nếu ứng dụng có một thực thể chạy kiểm thử và danh sách giá trị nhận dạng trường hợp kiểm thử, thì ứng dụng không cần tạo truy vấn; thay vào đó, ứng dụng có thể trực tiếp lấy các trường hợp kiểm thử theo giá trị nhận dạng của các trường hợp kiểm thử, luôn được đảm bảo là nhất quán. Phương pháp này giúp giảm đáng kể quy tắc ràng buộc về số lượng trường hợp kiểm thử mà một lần chạy kiểm thử có thể có, đồng thời đạt được tính nhất quán cao mà không gây ra tình trạng ghi quá nhiều trong một nhóm thực thể.
Mẫu truy cập dữ liệu
Trang tổng quan VTS sử dụng các mẫu truy cập dữ liệu sau:
- Mục yêu thích của người dùng. Có thể được truy vấn bằng cách sử dụng bộ lọc bằng trên các thực thể yêu thích của người dùng có đối tượng Người dùng App Engine cụ thể làm thuộc tính.
- Trang thông tin thử nghiệm. Truy vấn đơn giản về các thực thể kiểm thử. Để giảm băng thông hiển thị trang chủ, bạn có thể sử dụng phép chiếu trên số lượng bài kiểm thử đạt và không đạt để bỏ qua danh sách có thể dài gồm các mã nhận dạng trường hợp kiểm thử không đạt và siêu dữ liệu khác mà các công việc cảnh báo sử dụng.
- Chạy kiểm thử. Việc truy vấn các thực thể chạy kiểm thử yêu cầu sắp xếp theo khoá (dấu thời gian) và có thể lọc theo các thuộc tính chạy kiểm thử như mã bản dựng, số lần vượt qua, v.v. Bằng cách thực hiện truy vấn cấp trên với khoá thực thể kiểm thử, hoạt động đọc sẽ nhất quán. Tại thời điểm này, tất cả kết quả trường hợp kiểm thử có thể được truy xuất bằng cách sử dụng danh sách mã nhận dạng được lưu trữ trong thuộc tính chạy kiểm thử; điều này cũng được đảm bảo là kết quả nhất quán do bản chất của các thao tác lấy kho dữ liệu.
- Dữ liệu phân tích và mức độ phù hợp. Bạn có thể truy vấn dữ liệu phân tích tài nguyên hoặc mức độ sử dụng liên kết với một kiểm thử mà không cần truy xuất bất kỳ dữ liệu chạy kiểm thử nào khác (chẳng hạn như dữ liệu phân tích tài nguyên/mức sử dụng khác, dữ liệu trường hợp kiểm thử, v.v.). Truy vấn gốc sử dụng khoá thực thể kiểm thử và chạy kiểm thử sẽ truy xuất tất cả các điểm phân tích tài nguyên được ghi lại trong quá trình chạy kiểm thử; bằng cách lọc theo tên điểm phân tích tài nguyên hoặc tên tệp, bạn có thể truy xuất một thực thể phân tích tài nguyên hoặc mức độ sử dụng duy nhất. Theo bản chất của truy vấn đối tượng cấp trên, thao tác này rất nhất quán.
Để biết thông tin chi tiết về giao diện người dùng và ảnh chụp màn hình về các mẫu dữ liệu này đang hoạt động, hãy xem phần Giao diện người dùng của trang tổng quan về VTS.