Trong lĩnh vực phát triển phần mềm, kiểm thử là một bước quan trọng không thể thiếu nhằm đảm bảo chất lượng và hiệu suất của sản phẩm.
Bài viết này tại VNLibs.com sẽ giới thiệu chi tiết về quá trình kiểm thử phần mềm, từ việc chứng minh các yêu cầu của hệ thống đến việc phát hiện và khắc phục các lỗi và khiếm khuyết. Qua đó, chúng ta sẽ hiểu rõ hơn về các kỹ thuật kiểm thử khác nhau và tầm quan trọng của chúng trong việc tạo ra những phần mềm đáng tin cậy và hiệu quả.
1. Quá trình kiểm thử là gì?
Quá trình kiểm thử phần mềm có hai mục tiêu riêng biệt: Chứng minh cho người phát triển và khách hàng; Phát hiện các lỗi và khiếm khuyết trong phần mềm.
– Chứng minh cho người phát triển và khách hàng thấy các yêu cầu của phần mềm. Với phần mềm truyền thống, điều này có nghĩa là chúng ta có ít nhất một thử nghiệm, cho mỗi yêu cầu của người dùng và tài liệu hệ thống yêu cầu. Với các sản phẩm phần mềm chung, điều đó có nghĩa là chúng ta nên thử nghiệm tất cả các đặc tính của hệ thống sẽ được kết hợp trong sản phẩm phát hành.
– Phát hiện các lỗi và khiếm khuyết trong phần mềm. Phần mềm thực hiện không đúng, không như mong đợi hoặc không làm theo như đặc tả. Kiểm tra khiếm khuyết tập trung vào việc tìm ra tất cả các kiểu thực hiện không như mong đợi của hệ thống, như sự đổ vỡ hệ thống, sự tương tác không mong muốn với hệ thống khác, tính toán sai và sai lạc dữ liệu.
Mục tiêu thứ nhất dẫn đến kiểm thử hợp lệ, sử dụng tập các thử nghiệm phản ánh mong muốn của người dùng, để kiểm tra xem hệ thống có thực hiện đúng không. Mục tiêu thứ hai dẫn đến kiểm thử khiếm khuyết: các trường hợp kiểm thử được thiết kế để tìm ra các khiếm khuyết.
Các trường hợp kiểm thử có thể được làm không rõ, và không cần phản ánh cách hệ thống bình thường được sử dụng. Với kiểm thử hợp lệ, một thử nghiệm thành công là thử nghiệm mà hệ thống thực hiện đúng đắn. Với kiểm thử khiếm khuyết, một thử nghiệm thành công là một thử nghiệm tìm ra một khiếm khuyết, nguyên nhân làm cho hệ thống thực hiện không chính xác.
Kiểm thử có thể không chứng minh được phần mềm không có khiếm khuyết, hoặc nó sẽ thực hiện như đặc tả trong mọi trường hợp. Rất có thể một thử nghiệm bạn bỏ qua có thể phát hiện ra các vấn đề khác trong hệ thống.
Như Dijkstra, một người đi đầu trong việc phát triển kỹ nghệ phần mềm, đã tuyên bố (1972): “Kiểm thử chỉ có thể phát hiện ra các lỗi hiện tại, chứ không thể đưa ra tất cả các lỗi”.
Nói chung, mục tiêu của kiểm thử phần mềm là thuyết phục người phát triển phần mềm và khách hàng rằng, phần mềm là đủ tốt cho các thao tác sử dụng. Kiểm thử là một quá trình được dùng để tạo nên sự tin tưởng trong phần mềm.
Mô hình tổng quát của quá trình kiểm thử được mô tả. Các trường hợp kiểm thử sẽ chỉ rõ đầu vào để thử nghiệm và đầu ra mong đợi từ hệ thống, cộng với một bản báo cáo sản phẩm đã được kiểm thử. Dữ liệu kiểm thử là đầu vào, được nghĩ ra để kiểm thử hệ thống. Dữ liệu kiểm thử thỉnh thoảng có thể được tự động sinh ra. Các trường hợp kiểm thử tự động là điều không làm được. Đầu ra của thử nghiệm chỉ có thể được dự đoán bởi người hiểu biết về hoạt động của hệ thống.
Kiểm thử toàn diện: mọi chương trình có thể thực hiện kiểm tra tuần tự, là điều không thể làm được. Vì vậy, kiểm thử phải được thực hiện trên một tập con các trường hợp kiểm thử có thể xảy ra. Trong trường hợp lý tưởng, các công ty phần mềm có những điều khoản, để lựa chọn tập con này hơn là giao nó cho đội phát triển.
Những điều khoản này có thể dựa trên những điều khoản kiểm thử chung, như một điều khoản là tất cả các câu lệnh trong chương trình, nên được thực thi ít nhất một lần. Một sự lựa chọn là những điều khoản kiểm thử có thể thực hiện dựa trên kinh nghiệm sử dụng hệ thống, và có thể tập trung vào kiểm thử các đặc trưng hoạt động của hệ thống.
Ví dụ: Tất cả các đặc trưng của hệ thống được truy cập thông qua thực đơn nên được kiểm thử; Kết hợp các chức năng (ví dụ định dạng văn bản) được truy cập thông qua cùng thực đơn phải được kiểm thử; Khi đầu vào được đưa vào, tất cả các chức năng phải được kiểm thử, với cùng một thử nghiệm đúng đắn và thử nghiệm không đúng đắn.
Điều đó rõ ràng có được từ kinh nghiệm với sản phẩm phần mềm lớn như phần mềm xử lý văn bản, hoặc bảng tính có thể so sánh các nguyên tắc thông thường được sử dụng trong lúc kiểm thử sản phẩm. Khi các đặc trưng của phần mềm được sử dụng cô lập, chúng sẽ làm việc bình thường.
Các vấn đề phát sinh, như Whittaker giải thích (Whittaker, 2002). Khi liên kết các đặc trưng không được kỹ thuật kiểm thử cùng nhau. Ông đã đưa ra một ví dụ, khi sử dụng phần mềm xử lý văn bản, sử dụng lời chú thích ở cuối trang, với cách sắp xếp nhiều cột, làm cho văn bản trình bày không đúng.
Khi thực hiện một phần của quá trình lập kế hoạch V&V, người quản lý phải đưa ra các quyết định ai là người chịu trách nhiệm trong từng bước kiểm thử khác nhau. Với hầu hết các hệ thống, các lập trình viên chịu trách nhiệm kiểm thử các thành phần mà họ đã triển khai.
Khi các lập trình viên đã hoàn thành các công việc đó, công việc được giao cho đội tổng hợp, họ sẽ tích hợp các môđun từ những người phát triển khác nhau để tạo nên phần mềm và kiểm thử toàn bộ hệ thống. Với hệ thống quan trọng, một quá trình theo nghi thức có thể được sử dụng, những người thử độc lập chịu trách nhiệm về tất cả các bước của quá trình kiểm thử. Trong kiểm thử hệ thống, quan trọng là các thử nghiệm được kiểm thử riêng biệt và hồ sơ chi tiết của kết quả kiểm thử được duy trì.
Kiểm thử các thành phần được thực hiện bởi những người phát triển thường dựa trên hiểu biết trực giác về cách hoạt động của các thành phần. Tuy nhiên, kiểm thử hệ thống phải dựa trên văn bản đặc tả hệ thống. Đó có thể là một đặc tả chi tiết yêu cầu hệ thống, hoặc có thể là đặc tả hướng người sử dụng ở mức cao của các đặc tính được thực hiện trong hệ thống. Thường có một đội độc lập chịu trách nhiệm kiểm thử hệ thống, đội kiểm thử hệ thống làm việc từ người sử dụng và tài liệu yêu cầu hệ thống để lập kế hoạch kiểm thử hệ thống.
Hầu hết các thảo luận về kiểm thử, bắt đầu với kiểm thử thành phần và sau đó chuyển đến kiểm thử hệ thống. Tôi đã đảo ngược thứ tự các thảo luận trong bài viết này, bởi vì, rất nhiều quá trình phát triển phần mềm bao gồm việc tích hợp các thành phần sử dụng, lại và được lắp vào phần mềm để tạo nên các yêu cầu cụ thể. Tất cả các kiểm thử trong trường hợp này, là kiểm thử hệ thống và không có sự tách rời trong quá trình kiểm thử thành phần.
2. Kiểm thử hệ thống là gì?
Hệ thống gồm hai hoặc nhiều thành phần tích hợp nhằm thực hiện các chức năng hoặc đặc tính của hệ thống. Sau khi tích hợp, các thành phần tạo nên hệ thống, quá trình kiểm thử hệ thống được tiến hành. Trong quá trình phát triển lặp đi lặp lại, kiểm thử hệ thống liên quan với kiểm thử một lượng công việc ngày càng tăng để phân phối cho khách hàng; Trong quy trình thác nước, kiểm thử hệ thống liên quan với kiểm thử toàn bộ hệ thống. Với hầu hết các hệ thống phức tạp, kiểm thử hệ thống gồm hai giai đoạn riêng biệt:
– Kiểm thử tích hợp: Đội kiểm thử nhận mã nguồn của hệ thống. Khi một vấn đề được phát hiện, đội tích hợp thử tìm nguồn gốc của vấn đề và nhận biết thành phần cần phải gỡ lỗi. Kiểm thử tích hợp hầu như liên quan với việc tìm các khiếm khuyết của hệ thống.
– Kiểm thử phát hành: Một phiên bản của hệ thống có thể được phát hành tới người dùng được kiểm thử. Đội kiểm thử tập trung vào việc hợp lệ các yêu cầu của hệ thống và đảm bảo tính tin cậy của hệ thống. Kiểm thử phát hành thường là kiểm thử “hộp đen”, đội kiểm thử tập trung vào mô tả các đặc tính hệ thống có thể làm được hoặc không làm được. Các vấn đề được báo cáo cho đội phát triển để gỡ lỗi chương trình. Khách hàng được bao hàm trong kiểm thử phát hành, thường được gọi là kiểm thử chấp nhận. Nếu hệ thống phát hành đủ tốt, khách hàng có thể chấp nhận nó để sử dụng.
Về cơ bản, bạn có thể nghĩ kiểm thử tích hợp như là kiểm thử hệ thống chưa đầy đủ, bao gồm một nhóm các thành phần. Kiểm thử phát hành liên quan đến kiểm thử hệ thống phát hành có ý định phân phối tới khách hàng. Tất nhiên, có sự gói chồng lên nhau, đặc biệt khi phát triển hệ thống và hệ thống được phát hành khi chưa hoàn thành.
Thông thường, sự ưu tiên hàng đầu trong kiểm thử tích hợp là phát hiện ra khiếm khuyết trong hệ thống, và trong kiểm thử hệ thống là làm hợp lệ các yêu cầu của hệ thống. Tuy nhiên trong thực tế, có vài kiểm thử hợp lệ và vài kiểm thử khiếm khuyết trong các quá trình.
3. Kiểm thử tích hợp là gì?
Quá trình kiểm thử tích hợp bao gồm việc xây dựng hệ thống từ các thành phần, và kiểm thử hệ thống tổng hợp với các vấn đề phát sinh từ sự tương tác giữa các thành phần. Các thành phần được tích hợp có thể trùng với chính nó, các thành phần có thể dùng lại được có thể thêm vào các hệ thống riêng biệt hoặc thành phần mới được phát triển.
Với rất nhiều hệ thống lớn, có tất cả ba loại thành phần được sử dụng. Kiểm thử tích hợp kiểm tra trên thực tế các thành phần làm việc với nhau, được gọi là chính xác và truyền dữ liệu đúng vào lúc thời gian đúng thông qua giao diện của chúng.
Hệ thống tích hợp bao gồm một nhóm các thành phần thực hiện vài chức năng của hệ thống, và được tích hợp với nhau bằng cách gộp các mã để chúng làm việc cùng nhau. Thỉnh thoảng, đầu tiên toàn bộ khung của hệ thống được phát triển, sau đó các thành phần được gộp lại để tạo nên hệ thống. Phương pháp này được gọi là tích hợp từ trên xuống (top-down).
Một cách lựa chọn khác là đầu tiên bạn tích hợp các thành phần cơ sở cung cấp các dịch vụ chung, như mạng, truy cập cơ sở dữ liệu, sau đó các thành phần chức năng được thêm vào. Phương pháp này được gọi là tích hợp từ dưới lên (bottom-up). Trong thực tế, với rất nhiều hệ thống, chiến lược tích hợp là sự pha trộn các phương pháp trên. Trong cả hai phương pháp top-down và bottom-up, bạn thường phải thêm các mã để mô phỏng các thành phần khác và cho phép hệ thống thực hiện.
Một vấn đề chủ yếu nảy sinh trong lúc kiểm thử tích hợp là các lỗi cục bộ. Có nhiều sự tương tác phức tạp giữa các thành phần của hệ thống và khi một đầu ra bất thường được phát hiện, bạn có thể khó nhận ra nơi mà lỗi xuất hiện. Để việc tìm lỗi cục bộ được dễ dàng, bạn nên thường xuyên tích hợp các thành phần của hệ thống và kiểm thử chúng. Ban đầu, bạn nên tích hợp một hệ thống cấu hình tối thiểu và kiểm thử hệ thống này. Sau đó bạn thêm dần các thành phần vào hệ thống đo và kiểm thử sau mỗi bước thêm vào.
| Dãy kiểm thử 1 | Dãy kiểm thử 2 | Dãy kiểm thử 3 |
|---|---|---|
| [A] — [B] └────┬────┘ │ ├─ T1 ├─ T2 └─ T3 |
[A] — [B] — [C] └────┬────┬────┘ │ │ ├─ T1 ├─ T4 ├─ T2 │ └─ T3 ┘ |
[A] — [B] — [C] — [D] └────┬────┬────┬────┘ │ │ │ ├─ T1 ├─ T4 ├─ T5 ├─ T2 │ │ └─ T3 ┘ ┘ |
Giải thích các ký hiệu:
[ ]: Biểu diễn cho một thành phần (module).
—: Biểu diễn mối quan hệ kết nối giữa các thành phần.
└, ┬, ├, ┘: Các ký tự đặc biệt dùng để vẽ đường kết nối từ các thành phần đến thử nghiệm.
Trong ví dụ trên Bảng 1, chúng ta thấy A, B, C, D là các thành phần và T1, T2, T3, T4, T5 là tập các thử nghiệm kết hợp các đặc trưng của hệ thống. Đầu tiên, các thành phần A và B được kết hợp để tạo nên hệ thống (hệ thống cấu hình tối thiểu) và các thử nghiệm T1, T2, T3 được thực hiện. Nếu phát hiện có khiếm khuyết, nó sẽ được hiệu chỉnh.
Sau đó, thành phần C được tích hợp và các thử nghiệm T1, T2 và T3 được làm lập lại để đảm bảo nó không tạo nên các kết quả không mong muốn khi tương tác với A và B. Nếu có vấn đề nảy sinh trong các kiểm thử này, nó hầu như chắc chắn do sự tương tác với các thành phần mới.
Nguồn gốc của vấn đề đã được khoanh vùng, vì vậy làm đơn giản việc tìm và sửa lỗi. Tập thử nghiệm T4 cũng được thực hiện trên hệ thống. Cuối cùng, thành phần D được tích hợp vào hệ thống và kiểm thử được thực hiện trên các thử nghiệm đã có và các thử nghiệm mới.
Khi lập kế hoạch tích hợp, chúng ta phải quyết định thứ tự tích hợp các thành phần. Trong một quy trình như Extreme Programing, khách hàng cũng tham gia trong quá trình phát triển và quyết định các chức năng nên được thêm vào trong mỏi bước tích hợp hệ thống.
Do đó, tích hợp hệ thống được điều khiển bởi sự ưu tiên của khách hàng. Trong cách tiếp cận khác để phát triển hệ thống, khi các thành phần và các thành phần riêng biệt được tích hợp, khách hàng có thể không tham gia vào quá trình tích hợp hệ thống, và đội tích hợp quyết định thứ tự tích hợp các thành phần.
Trong trường hợp này, một quy tắc tốt, là đầu tiên tích hợp các thành phần thực hiện hầu hết các chức năng thường sử dụng của hệ thống. Điều này, có nghĩa là các thành phần thường được sử dụng hầu hết đã được kiểm thử.
Ví dụ, trong hệ thống thư viện, đầu tiên bạn nên tích hợp chức năng tìm kiếm trong hệ thống tối thiểu, để người dùng có thể tìm kiếm các tài liệu mà họ cần. Sau đó, bạn nên tích hợp các chức năng cho phép người dùng tải tài liệu từ trên Internet, và dần thêm các thành phần thực hiện các chức năng khác của hệ thống.
Tất nhiên, thực tế ít khi đơn giản như mô hình trên. Sự thực hiện các chức năng của hệ thống có thể liên quan đến nhiều thành phần. Để kiểm thử một đặc tính mới, chúng ta có thể phải tích hợp một vài thành phần khác nhau. Kiểm thử có thể phát hiện lỗi trong khi tương tác giữa các thành phần riêng biệt và các phần khác của hệ thống.
Việc sửa lỗi có thể khó khăn, bởi vì một nhóm các thành phần thực hiện chức năng đó có thể phải thay đổi. Hơn nữa, tích hợp và kiểm thử một thành phần mới có thể thay đổi tương tác giữa các thành phần đã được kiểm thử. Các lỗi có thể được phát hiện có thể đã không được phát hiện trong khi kiểm thử hệ thống cấu hình đơn giản.
Những vấn đề này có nghĩa là khi một hệ thống tích hợp mới được tạo ra, cần phải chạy lại các thử nghiệm trong hệ thống tích hợp cũ, để đảm bảo yêu cầu là các thử nghiệm đó vẫn thực hiện tốt, các kiểm thử mới thực hiện tốt các chức năng mới của hệ thống.
Việc thực hiện kiểm thử lại tập các thử nghiệm cũ gọi là kiểm thử hồi quy. Nếu kiểm thử hồi quy phát hiện có vấn đề, thì bạn phải kiểm tra có lỗi trong hệ thống cũ hay không, mà hệ thống mới đã phát hiện ra, hoặc có lỗi do thêm các chức năng mới.
Rõ ràng, kiểm thử hồi quy là quá trình tốn kém, không khả thi nếu không có sự hỗ trợ tự động. Trong lập trình cực độ, tất cả các thử nghiệm được viết như mã có thể thực thi, các đầu vào thử nghiệm và kết quả mong đợi được xác định rõ và được tự động kiểm tra.
Khi được sử dụng cùng với một khung kiểm thử tự động như Junit (Massol và Husted, 2003), điều này có nghĩa là các thử nghiệm có thể được tự động thực hiện lại. Đây là nguyên lý cơ bản của lập trình cực độ, khi tập các thử nghiệm toàn diện được thực hiện bất cứ lúc nào mã mới được tích hợp, và các mã mới này không được chấp nhận cho đến khi tất cả các thử nghiệm được thực hiện thành công.
4. Kiểm thử phát hành là gì?
Kiểm thử phát hành là quá trình kiểm thử một hệ thống sẽ được phân phối tới các khách hàng. Mục tiêu đầu tiên của quá trình này là làm tăng sự tin cậy của nhà cung cấp rằng, sản phẩm họ cung cấp có đầy đủ các yêu cầu.
Nếu thỏa mãn, hệ thống có thể được phát hành như một sản phẩm hoặc được phân phối đến các khách hàng. Để chứng tỏ hệ thống có đầy đủ các yêu cầu, bạn phải chỉ ra nó có các chức năng đặc tả, hiệu năng và tính tin cậy cao, đồng thời không gặp sai sót trong khi được sử dụng bình thường.
Kiểm thử phát hành thường là quá trình kiểm thử hộp đen, các thử nghiệm được lấy từ đặc tả hệ thống. Hệ thống được đối xử như chiếc hộp đen, các hoạt động của nó chỉ có thể được nhận biết qua việc nghiên cứu đầu vào và đầu ra của nó. Một tên khác của quá trình này là kiểm thử chức năng, bởi vì người kiểm tra chỉ tập trung xem xét các chức năng và không quan tâm tới sự thực thi của phần mềm.
Các tác giả như Whittaker (Whittaker, 2002) đã tóm lược những kinh nghiệm kiểm thử của họ, trong một tập các nguyên tắc nhằm tăng khả năng tìm ra các thử nghiệm khiếm khuyết. Dưới đây là một vài nguyên tắc:
– Lựa chọn những đầu vào làm cho hệ thống sinh ra tất cả các thông báo lỗi.
– Thiết kế đầu vào làm cho bộ đệm đầu vào bị tràn.
– Làm lặp lại với các đầu vào như nhau hoặc một dãy các đầu vào nhiều lần.
– Làm sao để đầu ra không đúng được sinh ra.
– Tính toán kết quả ra rất lớn hoặc rất nhỏ.
Để xác nhận hệ thống thực hiện chính xác các yêu cầu, cách tiếp cận tốt nhất vấn đề này là kiểm thử dựa trên kịch bản, bạn đưa ra một số kịch bản và tạo nên các trường hợp thử nghiệm từ các kịch bản đó.
Ví dụ, kịch bản dưới đây mô tả cách hệ thống thư viện LIBSYS, có thể được sử dụng: Một sinh viên ở Scotland nghiên cứu lịch sử nước Mỹ đã được yêu cầu viết một bài luận về “Tâm lý của người miền Tây nước Mỹ từ năm 1840 đến năm 1880”.
Để làm việc đó, cô ấy cần tìm các tài liệu từ nhiều thư viện. Cô ấy đăng nhập vào hệ thống LIBSYS, hoặc hệ thống VNLibs.com và sử dụng chức năng tìm kiếm để tìm xem cô ấy có được truy cập vào các tài liệu gốc trong khoảng thời gian ấy không. Cô ấy tìm được các nguồn tài liệu từ rất nhiều thư viện của các trường đại học của Mỹ và tải một vài bản sao các tài liệu đó.
Tuy nhiên, với một vài tài liệu, cô ấy cần phải có sự xác nhận từ trường đại học của mình rằng, cô ấy thật sự là một sinh viên và các tài liệu được sử cho những mục đích phi thương mại. Sau đó, sinh viên đó sử dụng các phương tiện của LIBSYS hoặc VNLibs.com để yêu cầu sự cho phép và đăng ký các yêu cầu của họ.
Nếu được xác nhận, các tài liệu đó sẽ được tải xuống từ máy chủ của thư viện và sau đó được in. Cô ấy nhận được một thông báo từ LIBSYS hoặc VNLibs nói rằng cô ấy sẽ nhận được một email khi các tài liệu đã in có giá trị để tập hợp.
Từ kịch bản trên, chúng ta có thể áp dụng một số thử nghiệm để tìm ra mục đích của LIBSYS:
– Kiểm thử cơ chế đăng nhập bằng cách thực hiện các đăng nhập đúng và đăng nhập sai, để kiểm tra người dùng hợp lệ được chấp nhận và người dùng không hợp lệ không được chấp nhận.
– Kiểm thử cơ chế tìm kiếm bằng cách sử dụng các câu hỏi đã biết cho các tài liệu cần tìm, để kiểm tra xem cơ chế tìm kiếm có thực sự tìm thấy các tài liệu đó hay không?
– Kiểm thử sự trình bày hệ thống để kiểm tra các thông tin về tài liệu có được hiển thị đúng không?
– Kiểm thử cơ chế cho phép yêu cầu tải tài liệu xuống.
– Kiểm thử email trả lời cho biết, tài liệu đã tải xuống là sẵn sàng sử dụng.
Với mỗi thử nghiệm, chúng ta nên thiết kế một tập các thử nghiệm, bao gồm các đầu vào hợp lệ, và đầu vào không hợp lệ, để sinh ra các đầu ra hợp lệ và đầu ra không hợp lệ. Chúng ta, cũng nên tổ chức kiểm thử dựa trên kịch bản. Vì thế, đầu tiên các kịch bản thích hợp được thử nghiệm. Sau đó, các kịch bản khác thường và ngoại lệ, được xem xét. Vì vậy, sự cố gắng của bạn dành cho các phần, mà hệ thống thường được sử dụng.
Nếu bạn đã sử dụng trường hợp người dùng, để mô tả các yêu cầu của hệ thống, các trường hợp người dùng đó, và biểu đồ liên kết nối tiếp, có thể là cơ sở để kiểm thử hệ thống.
5. Kiểm thử hiệu năng là gì?
Ngay khi một hệ thống đã được tích hợp đầy đủ, hệ thống có thể được kiểm tra các thuộc tính nổi bật như hiệu năng và độ tin cậy. Kiểm thử hiệu năng phải được thiết kế để đảm bảo hệ thống có thể xử lý như mong muốn. Nó thường bao gồm việc lập một dây các thử nghiệm, gánh nặng sẽ được tăng cho đến khi hệ thống không thể chấp nhận được nữa.
Cùng với các loại kiểm thử khác, kiểm thử hiệu năng liên quan đến cả việc kiểm chứng các yêu cầu của hệ thống và phát hiện các vấn đề cũng như khiếm khuyết trong hệ thống. Để kiểm thử các yêu cầu hiệu năng đạt được, bạn phải xây dựng mô tả sơ lược thao tác. Mô tả sơ lược thao tác là tập các thử nghiệm phản ánh sự hòa trộn các công việc sẽ được thực hiện bởi hệ thống.
Vì vậy, nếu 90% giao dịch trong hệ thống có kiểu A, 5% kiểu B và phần còn lại có kiểu C, D, E, thì chúng ta phải thiết kế mô tả sơ lược thao tác phần lớn tập trung vào kiểm thử kiểu A. Nếu không bạn sẽ không có được thử nghiệm chính xác về hiệu năng hoạt động của hệ thống.
Tất nhiên, cách tiếp cận này không nhất thiết là tốt để kiểm thử khiếm khuyết. Như tôi đã thảo luận, theo kinh nghiệm đã chỉ ra, cách hiệu quả để phát hiện khiếm khuyết là thiết kế các thử nghiệm xung quanh giới hạn của hệ thống. Trong kiểm thử hiệu năng, điều này có nghĩa là nhấn mạnh hệ thống (vì thế nó có tên là kiểm thử nhấn mạnh) bằng cách tạo ra những đòi hỏi bên ngoài giới hạn thiết kế của phần mềm.
Ví dụ: Một hệ thống xử lý các giao dịch có thể được thiết kế để xử lý đến 300 giao dịch mỗi giây; Một hệ thống điều khiển có thể được thiết kế để điều khiến tới 1000 thiết bị đầu cuối khác nhau. Kiểm thử nhấn mạnh tiếp tục các thử nghiệm bên cạnh việc thiết kế lớn nhất được nạp vào hệ thống cho đến khi hệ thống gặp lỗi. Loại kiểm thử này có hai chức năng:
– Kiểm thử việc thực hiện lỗi của hệ thống. Trường hợp này có thể xuất hiện qua việc phối hợp các sự kiện không mong muốn, bằng cách nạp vượt quá khả năng của hệ thống. Trong trường hợp này, sai sót của hệ thống làm cho dữ liệu bị hư hỏng hoặc không đáp ứng được yêu cầu của người dùng. Kiểm thử nhấn mạnh kiểm tra sự quá tải của hệ thống dẫn tới thất bại mềm hơn là làm sụp đổ dưới lượng tải của nó.
– Nhấn mạnh hệ thống và có thể gây nên khiếm khuyết trở nên rõ ràng mà bình thường không phát hiện ra. Mặc dù, nó chứng tỏ những khiếm khuyết không thể dẫn đến sự sai sót của hệ thống trong khi sử dụng bình thường, có thể hiếm gặp trong trường hợp bình thường mà kiểm thử gay cấn tái tạo. Kiểm thử gay cấn có liên quan đặc biệt đến việc phân phối hệ thống dựa trên một mạng lưới máy xử lý. Các hệ thống thường đưa ra đòi hỏi cao, khi chúng phải thực hiện nhiều công việc. Mạng bị làm mất tác dụng với dữ liệu kết hợp, mà các quá trình khác nhau phải trao đổi, vì vậy các quá trình trở nên chậm hơn, như khi nó đợi dữ liệu yêu cầu từ quá trình khác.
6. Kiểm thử thành phần là gì?
Kiểm thử thành phần (thỉnh thoảng được gọi là kiểm thử đơn vị) là quá trình kiểm thử các thành phần riêng biệt của hệ thống. Đây là quá trình kiểm thử khiếm khuyết, vì vậy mục tiêu của nó là tìm ra lỗi trong các thành phần. Khi thảo luận trong phần giới thiệu, với hầu hết các hệ thống, người phát triển các thành phần chịu trách nhiệm kiểm thử các thành phần.
Có nhiều loại thành phần khác nhau, ta có thể kiểm thử chúng theo các bước sau: Các chức năng và cách thức riêng biệt bên trong đối tượng; Các lớp đối tượng có một vài thuộc tính và phương thức; Kết hợp các thành phần để tạo nên các đối tượng và chức năng khác nhau.
Các thành phần hỗn hợp có một giao diện rõ ràng được sử dụng để truy cập các chức năng của chúng. Các chức năng và phương thức riêng lẻ là loại thành phần đơn giản nhất, và các thử nghiệm của bạn là một tập các lời gọi tới các thủ tục với tham số đầu vào khác nhau.
Bạn có thể sử dụng cách tiếp cận này, để thiết kế trường hợp kiểm thử (được thảo luận trong phần sau), thiết kế các thử nghiệm chức năng và phương thức. Khi bạn kiểm thử các lớp đối tượng, bạn nên thiết kế các thử nghiệm để cung cấp tất cả các chức năng của đối tượng.
Do đó, kiểm thử lớp đối tượng nên bao gồm: Kiểm thử tất cả các thao tác cô lập liên kết tạo thành đối tượng; Bố trí và kiểm tra tất cả các thuộc tính liên kết tạo thành đối tượng; Kiểm tra tất cả các trạng thái của đối tượng. Điều này có nghĩa là tất cả các sự kiện gây ra các trạng thái khác nhau của đối tượng nên được mô phỏng.
Ví dụ công nghệ giao diện của đối tượng WeatherStation như sau: WeatherStation -> identifier -> reportWeather () ; calibrate (instruments) ; test () ; startup (instruments) ; shutdown (instruments).
Trạm dự báo thời tiết có giao diện trình bày trên. Nó chỉ có một thuộc tính, là định danh của nó. Nó có một hằng số là tập thông số khi trạm dự báo thời tiết được thiết đặt. Do đó, bạn chỉ cần một thử nghiệm để kiểm tra nó đã được thiết đặt hay chưa. Bạn cần xác định các trường hợp kiểm thử để kiểm tra report Weather, calibrate, test, startup và shutdown. Trong trường hợp lý tưởng, bạn nên kiểm thử các phương thức riêng biệt, nhưng trong một vài trường hợp, cần có vài thử nghiệm liên tiếp. Ví dụ để kiểm thử phương thức shutdown bạn cần thực hiện phương thức startup.
Sử dụng mô hình này, bạn có thể nhận biết thứ tự của các trạng thái chuyển tiếp phải được kiểm thử và xác định thứ tự chuyển tiếp các sự kiện. Trong nguyên tắc này bạn nên kiểm thử mọi trạng thái chuyển tiếp có thể xảy ra, mặc dù trong thực tế, điều này có thể rất tốn kém. Ví dụ, dãy trạng thái nên kiểm thử trong trạm dự báo thời tiết bao gồm:
Tắt máy → Chờ → Tắt máy.
Đang chờ → Hiệu chỉnh → Kiểm tra → Truyền → Đang chờ.
Chờ đợi → Thu thập → Chờ đợi → Tóm tắt → Truyền tải → Chờ đợi.
Nếu sử dụng sự kế thừa sẽ làm cho việc thiết kế lớp đối tượng kiểm thử khó khăn hơn. Một lớp cha cung cấp các thao tác sẽ được kế thừa bởi một số lớp con, tất cả các lớp con nên được kiểm thử tất cả các thao tác kế thừa. Lý do là các thao tác kế thừa có thể đã thay đổi các thao tác và thuộc tính sau khi được kế thừa. Khi một thao tác của lớp cha được định nghĩa lại, thì nó phải được kiểm thử.
Khái niệm lớp tương đương, được thảo luận trong phần sau, có thể cũng được áp dụng cho các lớp đối tượng. Kiểm thử các lớp tương đương giống nhau có thể sử dụng các thuộc tính của đối tượng. Do đó, các lớp tương đương nên được nhận biết như sự khởi tạo, truy cập và cập nhật tất cả thuộc tính của lớp đối tượng.
7. Kiểm thử giao diện là gì?
Nhiều thành phần trong một hệ thống là sự kết hợp các thành phần tạo nên bởi sự tương tác của một vài đối tượng. Kiểm thử các thành phần hỗn hợp chủ yếu liên quan đến kiểm thử hoạt động giao diện của chúng thông qua các đặc tả.
Kiểm thử giao diện đặc biệt quan trọng trong việc phát triển phần mềm hướng đối tượng và các thành phần cơ sở. Các đối tượng và các thành phần được xác định qua giao diện của chúng, và có thể được sử dụng lại khi liên kết với các thành phần khác trong các hệ thống khác nhau. Các lỗi giao diện trong thành phần hỗn hợp không thể được phát hiện qua việc kiểm thử các đối tượng và các thành phần riêng lẻ. Sự tương tác giữa các thành phần trong thành phần hỗn hợp có thể phát sinh lỗi.
Có nhiều kiểu giao diện giữa các thành phần chương trình, do đó có thể xuất hiện các kiểu lỗi giao diện khác nhau:
– Giao diện tham số: Khi dữ liệu hoặc tham chiếu chức năng được đưa từ thành phần này tới thành phần khác.
– Giao diện chia sẻ bộ nhớ: Khi một khối bộ nhớ được chia sẻ giữa các thành phần. Dữ liệu được để trong bộ nhớ bởi một hệ thống con và được truy xuất bởi một hệ thống khác.
– Giao diện thủ tục: Một thành phần bao gồm một tập các thủ tục có thể được gọi bởi các thành phần khác. Các đối tượng và các thành phần dùng lại có dạng giao diện này.
– Giao diện truyền thông điệp: Một thành phần yêu cầu một dịch vụ từ một thành phần khác, bằng cách gửi một thông điệp tới thành phần đó. Thông điệp trả lại bao gồm các kết quả thực hiện dịch vụ. Một vài hệ thống hướng đối tượng có dạng giao diện này như trong hệ thống chủ-khách (client-server).
Các lỗi giao diện là một dạng lỗi thường gặp trong các hệ thống phức tạp (Lutz, 1993). Các lỗi này được chia làm ba loại:
– Dùng sai giao diện: Một thành phần gọi tới thành phần khác và tạo nên một lỗi trong giao diện của chúng. Đây là loại lỗi rất thường gặp trong giao diện tham số: các tham số có thể được truyền sai kiểu, sai thứ tự hoặc sai số lượng tham số.
– Hiểu sai giao diện: Một thành phần gọi tới thành phần khác nhưng hiểu sai các đặc tả giao diện của thành phần được gọi và làm sai hành vi của thành phần được gọi. Thành phần được gọi không hoạt động như mong đợi và làm cho thành phần gọi cũng hoạt động không như mong đợi. Ví dụ, một thủ tục tìm kiếm nhị phân có thể được gọi thực hiện trên một mảng chưa được xếp theo thứ tự, kết quả tìm kiếm sẽ không đúng.
– Các lỗi trong bộ đếm thời gian: Các lỗi này xuất hiện trong các hệ thống thời gian thực sử dụng giao diện chia sẻ bộ nhớ hoặc giao diện truyền thông điệp. Dữ liệu của nhà sản xuất và dữ liệu của khách hàng có thể được điều khiển với các tốc độ khác nhau. Nếu không chú ý đến trong thiết kế giao diện, thì khách hàng có thể truy cập thông tin lỗi thời bởi vì thông tin của nhà sản xuất chưa được cập nhật trong giao diện chia sẻ.
Kiểm thử những khiếm khuyết trong giao diện rất khó khăn bởi vì một số lỗi giao diện chỉ biểu lộ trong những điều kiện đặc biệt. Ví dụ, một đối tượng có chứa một danh sách hàng đợi với cấu trúc dữ liệu có chiều dài cố định. Giả sử danh sách hàng đợi này được thực hiện với một cấu trúc dữ liệu vô hạn và không kiểm tra việc tràn hàng đợi khi một mục được thêm vào. Trường hợp này chỉ có thể phát hiện khi kiểm thử với những thử nghiệm làm cho tràn hàng đợi và làm sai hành vi của đối tượng theo những cách có thể nhận biết được.
Những lỗi khác có thể xuất hiện do sự tương tác giữa các lỗi trong các môđun và đối tượng khác nhau. Những lỗi trong một đối tượng có thể chỉ được phát hiện khi một vài đối tượng khác hoạt động không như mong muốn.
Ví dụ, một đối tượng có thể gọi một đối tượng khác để nhận được một vài dịch vụ và giả sử được đáp ứng chính xác. Nếu nó đã hiểu sai về giá trị được tính, thì giá trị trả về là hợp lệ nhưng không đúng. Điều này chỉ được phát hiện khi các tính toán sau đó có kết quả sai.
Sau đây là một vài nguyên tắc để kiểm thử giao diện:
– Khảo sát những mã đã được kiểm thử và danh sách lời gọi tới các thành phần bên ngoài.
– Những tham số trong một giao diện, kiểm thử giao diện với tham số đưa vào rỗng.
– Khi một thành phần được gọi thông qua một giao diện thủ tục, thiết kế thử nghiệm sao cho thành phần này bị sai. Các lỗi khác hầu như là do hiểu sai đặc tả chung.
– Sử dụng kiểm thử gay cấn, như đã thảo luận ở phần trước, trong hệ thống truyền thông điệp. Thiết kế thử nghiệm sinh nhiều thông điệp hơn trong thực tế. Vấn để bộ đếm thời gian có thể được phát hiện theo cách này.
– Khi một vài thành phần tương tác thông qua chia sẻ bộ nhớ, thiết kế thử nghiệm với thứ tự các thành phần được kích hoạt thay đổi. Những thử nghiệm này có thể phát hiện những giả sử ngắm của các lập trình viên về thứ tự dữ liệu chia sẻ được sử dụng và được giải phóng.
Kỹ thuật hợp lệ tĩnh thường hiệu quả hơn kiểm thử để phát hiện lỗi giao diện. Một ngôn ngữ định kiểu chặt chẽ như JAVA cho phép ngăn chặn nhiều lỗi giao diện bởi trình biên dịch.
Khi một ngôn ngữ không chặt chẽ như C được sử dụng, một phân tích tỉnh như LINT có thể phát hiện các lỗi giao diện. Sự kiểm tra chương trình có thể tập trung vào các giao diện giữa các thành phần và câu hỏi về hành vi giao diện xảy ra trong quá trình kiểm tra.
Tác giả: Thạc Bình Cường
Bạn đang xem bài viết:
Mô tả quá trình kiểm thử phần mềm với các kỹ thuật kiểm thử
Link https://vnlibs.com/cong-nghe/mo-ta-qua-trinh-kiem-thu-phan-mem-voi-cac-ky-thuat-kiem-thu.html
