Dữ liệu công ty hư cấu là công cụ hợp lệ và cần thiết cho kiểm thử phần mềm, nhưng nó chỉ hợp lệ trong một phạm vi rất hẹp. Ra khỏi phạm vi đó, cùng một bộ dữ liệu có thể biến một bài thử vô hại thành hành vi mạo danh. Bài này vẽ rõ ranh giới ấy, và nói về những đường rò rỉ mà đội kỹ thuật thường không để ý.
Vì sao cần nói rõ ranh giới của dữ liệu công ty hư cấu?
Vì trong công việc hằng ngày, ranh giới này rất dễ bị mờ đi. Một hồ sơ mô phỏng được dùng để chạy bài thử, rồi được dùng tiếp để chụp ảnh cho tài liệu, rồi được dán vào một cuộc trao đổi với đối tác như ví dụ minh hoạ, rồi được dùng để kiểm tra xem biểu mẫu của bên thứ ba có chấp nhận hay không. Không bước nào trong chuỗi đó có ý xấu, nhưng càng về sau thì hồ sơ càng rời xa môi trường thử.
Vấn đề trở nên nghiêm trọng khi hồ sơ đó vô tình trùng hoặc gần giống một doanh nghiệp có thật. Khi đó, việc dùng tên, mã số hay địa chỉ của một chủ thể khác để chạy thủ tục không còn là chuyện dữ liệu chưa chuẩn; nó trở thành mạo danh, và hậu quả pháp lý thuộc về bên đã dùng.
Những việc tuyệt đối không được làm
Danh sách dưới đây là ranh giới cứng, không có ngoại lệ vì lý do tiện lợi.
- Không dùng hồ sơ hư cấu để mở tài khoản thật, xin giấy phép, chứng nhận hành nghề hay bất kỳ sự công nhận nào có hiệu lực.
- Không dùng nó để phát hành hoá đơn, chứng từ hay hợp đồng có giá trị thực.
- Không đăng ký dưới danh nghĩa một chủ thể khác, kể cả khi bạn tin rằng mình đang làm việc đó với mục đích kiểm tra.
- Không dùng nó để đi qua một quy trình xác minh doanh nghiệp thật, dù chỉ để xem hệ thống của bên kia phản ứng thế nào.
- Không dùng nó cho việc đăng ký hàng loạt hay tạo nhiều chủ thể để thử giới hạn của một hệ thống bên ngoài.
- Không gửi nó cho khách hàng thật, không đưa vào tài liệu đối ngoại, không đưa vào thư gửi đồng thời cho nhiều người nhận thật.
- Không trộn nó với dữ liệu thật trong cùng một tệp, một cơ sở dữ liệu hay một màn hình.
| Ngữ cảnh | Dùng dữ liệu hư cấu | Vì sao |
|---|---|---|
| Kiểm thử biểu mẫu nội bộ | Được | Không tạo ra hệ quả pháp lý nào |
| Trình diễn sản phẩm | Được, với dữ liệu đã đánh dấu rõ | Người xem cần biết đây là minh hoạ |
| Sandbox do đối tác cung cấp | Được, nếu đúng phạm vi sandbox | Môi trường đã được tách khỏi vận hành thật |
| Mở tài khoản hoặc xin cấp phép | Không | Đây là thủ tục có hiệu lực thật |
| Phát hành hoá đơn | Không | Chứng từ thật phải gắn với chủ thể thật |
| Đăng ký thay cho người khác | Không | Là mạo danh, không phải kiểm thử |
Vì sao dữ liệu trông thật lại nguy hiểm hơn dữ liệu trông giả?
Vì dữ liệu trông thật không tự báo cho ai biết nó là giả. Một hồ sơ có tên giống doanh nghiệp thật, địa chỉ thật và mã số đúng hình dạng sẽ đi qua các bước kiểm tra tự động mà không gây nghi ngờ, và khi nó tới tay một người thật, người đó không có cách nào phân biệt nó với hồ sơ thật. Đây chính là cơ chế khiến dữ liệu thử rò rỉ trở thành sự cố.
Ngược lại, dữ liệu được đánh dấu rõ ràng sẽ tự vô hiệu hoá khi ra khỏi môi trường thử. Nếu tên chủ thể mang dấu hiệu đặt kiểu mẫu, người nhận sẽ dừng lại và hỏi. Nếu địa chỉ nằm trong dải dành cho tài liệu, hệ thống gửi thư sẽ không làm phiền ai. Nếu hộp thư dùng tên miền dành riêng cho ví dụ, thư sẽ không bao giờ tới một người thật. Đánh dấu rõ không làm bài thử yếu đi; nó làm bài thử an toàn hơn.
Cách làm cho dữ liệu thử dễ nhận ra
Nguyên tắc là dấu hiệu nhận biết phải nằm trong chính dữ liệu, không nằm ở ghi chú bên ngoài. Bất kỳ ai nhìn thấy một dòng dữ liệu cũng phải nhận ra ngay nó là mô phỏng, kể cả khi dòng đó bị tách khỏi ngữ cảnh và dán vào một tệp khác.
Những cách thường được dùng:
- Đặt tên chủ thể theo kiểu mẫu rõ ràng, có từ chỉ rõ đây là ví dụ.
- Dùng địa chỉ nằm trong dải địa chỉ mà tài liệu và minh hoạ dành riêng, thay vì địa chỉ có thật.
- Dùng hộp thư hoặc tên miền thuộc khu vực dành riêng cho ví dụ và tài liệu.
- Thêm một trường ghi chú nội bộ ngay trong hồ sơ, ví dụ một cờ đánh dấu bản ghi thử, và đảm bảo cờ này đi theo hồ sơ khi xuất dữ liệu.
- Không dùng tên gần giống một doanh nghiệp nổi tiếng, vì sự gần giống sẽ làm mất tác dụng nhận biết.
Trong tài liệu nội bộ, hãy thống nhất một quy ước duy nhất cho việc đánh dấu và ghi quy ước đó ở nơi mọi người đọc được. Nhiều tổ chức có quy ước nhưng không ai biết, và kết quả là mỗi nhóm đánh dấu một kiểu. Nếu bạn cần một bộ dữ liệu đã theo quy ước, trình tạo dữ liệu công ty để thử nghiệm của trang này sinh sẵn hồ sơ công ty tổng hợp với tên đặt kiểu mẫu và mã số theo hình dạng của quốc gia bạn chọn.
Dữ liệu thử rò rỉ ra ngoài bằng những đường nào?
Đường rò rỉ thường không phải một vụ hack mà là những thao tác bình thường tích tụ lại. Ảnh chụp màn hình trong tài liệu và trong báo cáo lỗi là đường phổ biến nhất. Tệp xuất dùng để phân tích là đường thứ hai, nhất là khi tệp đó được gửi qua thư điện tử cho đồng nghiệp hoặc đối tác. Nhật ký hệ thống là đường thứ ba, vì nhật ký thường lưu cả dữ liệu gửi đi trong các bài kiểm tra tích hợp. Bản sao cơ sở dữ liệu để dựng môi trường thử là đường thứ tư, và đây là đường nguy hiểm nhất vì nó trộn dữ liệu thật với dữ liệu thử ở quy mô lớn.
Kiểm soát tốt nhất không phải là nhắc nhở mọi người cẩn thận, mà là làm cho việc rò rỉ trở nên khó xảy ra về mặt kỹ thuật. Nếu dữ liệu thử không bao giờ nằm cùng chỗ với dữ liệu thật, thì một tệp xuất sai cũng không thể chứa thông tin thật. Nếu nhật ký tự động che các trường nhạy cảm, thì việc chia sẻ nhật ký trở nên an toàn hơn.
Phần dành cho nhà phát triển
Hãy coi việc tách môi trường là yêu cầu kiến trúc chứ không phải quy ước vận hành, và viết các quy tắc đó thành thứ có thể kiểm tra tự động.
- Mỗi bản ghi phải mang một dấu hiệu cho biết nó thuộc môi trường nào, và dấu hiệu đó phải sống cùng bản ghi qua mọi lần xuất dữ liệu.
- Không cho phép bất kỳ đường nào đẩy dữ liệu thử vào môi trường thật; nếu cần sao chép để dựng môi trường thử, hãy sao chép theo hướng ngược lại và che dữ liệu ngay khi sao chép.
- Che các trường định danh trong nhật ký và trong thông báo lỗi, đồng thời ghi lại việc che này để người đọc nhật ký biết giá trị hiển thị không phải giá trị gốc.
- Đặt lịch thu hồi và xoá dữ liệu thử theo từng đợt, kèm một cách kiểm tra rằng việc xoá đã thực sự diễn ra.
- Ghi lại ai đã tạo, ai đã sửa và ai đã xuất một bộ dữ liệu thử, vì khi có sự cố bạn cần biết nó đi qua tay những ai.
- Đừng để công cụ kiểm thử tự động gửi thư tới địa chỉ bên ngoài; hãy chặn ở tầng gửi thư, không chỉ ở tầng cấu hình.
Nếu bạn đang chuẩn bị bộ dữ liệu cho các bài thử liên quan tới địa chỉ và số điện thoại, bài viết danh sách kiểm thử định dạng địa chỉ và số điện thoại có thêm các nhóm trường hợp nên rà. Và nếu luồng của bạn có bước xác minh doanh nghiệp, hãy đọc bài kiểm thử KYB trước khi dựng dữ liệu, để ranh giới được đặt đúng từ đầu.
Bước tiếp theo
Hãy rà lại bốn đường rò rỉ nói trên trong quy trình hiện tại của bạn và chọn một đường để xử lý trước, thường là tệp xuất vì đây là đường dễ kiểm soát nhất. Sau đó kiểm tra xem mọi hồ sơ thử đã mang dấu hiệu nhận biết trong chính dữ liệu hay chưa. Bài dữ liệu công ty thử nghiệm là điểm bắt đầu phù hợp nếu bạn cần nắm lại toàn bộ khái niệm trước khi chuẩn hoá quy trình. Nội dung bài thuộc nhóm tài liệu kiểm thử; mọi tình huống nêu ra đều giả định và không được dùng để thay thế dữ liệu doanh nghiệp hợp pháp.