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