CHƯƠNG 1 CÁC YẾU TỐ CƠ BẢN CỦA KIỂM THỬ - KIỂM THỬ LÀ GÌ?

Kiểm thử phần mềm là một cuộc kiểm tra nhằm cung cấp cho các bên liên quan (khách hàng hay nhóm phát triển phần mềm,...) thông tin về chất lượng của sản phẩm hoặc dịch vụ đang kiểm thử (under test). Software testing cũng cung cấp mục tiêu, cái nhìn độc lập về phần mềm, điều này giúp đánh giá và hiểu rõ các rủi ro lie6n quan khi thực thi phần mềm. Các kỹ thuật kiểm thử bao gồm, nhưng không giới hạn, trong qui trình thực thi chương trình hoặc ứng dụng với mục đích tìm kiếm bug (lỗi, khiếm khuyết/nhược điểm).

1. Các mô hình kiểm thử phần mềm:

1.1. Mô hình chữ V

Mô hình chữ V cũng là một con đường thực hiện tuần tự các quy trình. Từng giai đoạn phải được hoàn thành đầy đủ trước khi bắt đầu một giai đoạn mới. Mỗi giai đoạn trong mô hình chữ V toàn bộ quy trình được chia ra là hai giai đoạn phát triển và kiểm thử phần mềm. mỗi giai đoạn phát triển tương ứng với mỗi giai đoạn kiểm thử. Các loại kiểm thử trong mô hình chữ V:

• Unit test: Unit test sẽ được các lập trình viên tiến hành kiểm thử, kiểm tra các đoạn code trong dự án để đảm bảo các module hoạt động chính xác.
• Integration test: Để tìm hiểu các vấn đề liên quan đến giao diện và các xung đột giữa các phần tích hợp.
• System test: Kiểm tra hệ thống có chạy được hoàn chỉnh và đáp ứng yêu cầu của người dùng hay không và độ chính xác mà hệ thống thực hiện.
• Acceptance test: Xác định hệ thống có được thỏa mảng với thị hiếu và mong đợi của người tiêu dùng hay không? Ưu nhược điểm của mô hình chữ V: Ưu điểm:
• Đơn giản dễ sử dụng.
• Có hoạt động, kế hoạch cụ thể cho quá trình kiểm thử.
• Tiết kiệm được thời gian, và có cơ hội thành công cao hơn mô hình thác nước.
• Chủ động trong việc phát hiện bug, sớm tìm ra bug ngay từ những bước đầu. Nhược điểm
• Độ linh hoạt ít và còn tồn tại sự cứng nhắc.
• Giống với waterfall, sản phẩm của dự án chỉ được xuất hiện khi tất cả các bước được hoàn thành xong.
• Nếu có sự thay đổi về kỹ thuật ở nửa chừng, thì sẽ phải quay lại các bước đầu tiên, thực hiện lại, update lại tài liệu.

1.2. Chu kỳ vòng đời lặp lại:

Không phải tất cả các vòng đời đều tuần tự. Cũng có vòng đời lặp hoặc gia tăng chu kỳ, thay vì một dòng thời gian phát triển lớn từ đầu đến cuối, chúng ta đi qua một số giai đoạn chu kỳ khép kín nhỏ hơn cho cùng một dự án. Giống như mô hình V, có nhiều biến thể của vòng đời lặp đi lặp lại trong chu kỳ.

• Phát triển ứng dụng nhanh (RAD) Quá trình phát triển của RAD khuyến khích phản hồi của khách hàng. Khách hàng nhận được thông tin sớm của sản phẩm, có thể cung cấp phản hồi về thiết kế và có thể quyết định, dựa trên các chức năng hiện có, cho dù tiến hành phát triển, chức năng nào sẽ bao gồm trong phần tiếp theo pha chu kỳ hoặc thậm chí ngừng dự án nếu nó không mang lại giá trị dự kiến.
• Phát triển linh hoạt (XP)
  • Nó thúc đẩy việc đưa ra kinh doanh để xác định chức năng. Nó đòi hỏi một khách hàng tại chỗ để liên tục phản hồi và xác định, thực hiện kiểm thử chấp nhận chức năng.
  • Nó khuyến khích lập trình cặp và chia sẻ quyền sở hữu mã trong các lập trình viên.
  • Nó nói rằng các kịch bản kiểm thử thành phần phải được viết trước khi mã được viết và những bài kiểm thử đó phải được tự động.
  • Nó tuyên bố rằng việc tích hợp và kiểm thử mã sẽ xảy ra nhiều lần một ngày.
  • Nó nói rằng chúng tôi luôn thực hiện giải pháp đơn giản nhất để đáp ứng nhu cầu các vấn đề ngày nay.

1.3. Kiểm thử trong một mô hình chu kỳ vòng đời

• Cho mỗi hoạt động phát triển có một hoạt động kiểm thử tương ứng;
• Mỗi cấp độ kiểm thử có các mục tiêu kiểm thử cụ thể cho mức độ đó;
• Việc phân tích và thiết kế các bài kiểm thử cho một mức độ kiểm thử nhất định phải bắt đầu trong suốt hoạt động phát triển tương ứng;
• Người kiểm thử nên tham gia vào việc rà soát tài liệu ngay khi có bản thảo trong chu trình phát triển;

2. Các mức độ kiểm thử:

2.1. Kiểm thử thành phần

Kiểm tra thành phần (cũng được xem như là kiểm tra (ở mức) unit, module hoặc là một chương trình) là việc tìm kiếm các lỗi và kiểm chứng rằng chức năng của các module, chương trình, mục tiêu, các lớp, v.v... của phần mềm đã được test một cách riêng biệt. Nó có thể được thực hiện độc lập, riêng biệt so với các thành phần khác của chương trình, phụ thuộc vào ngữ cảnh của hệ thống và quá trình sản xuất phần mềm. các Stub, driver và simulator có thể được sử dụng để thực hiện hiện kiểm tra. Kiểm tra thành phần có thể bao gồm kiểm tra chức năng và phi chức năng, chẳng hạn như hành vi của tài nguyên (ví dụ tìm kiếm sự rò rỉ của bộ nhớ) hoặc kiểm tra mức chịu tải cũng như kiểm tra cấu trúc (ví dụ quyết định độ bao phủ). Các Test case sẽ được viết dựa vào SPEC (tài liệu mô tả chi tiết của component), thiết kế phần mềm hoặc cấu trúc data.

2.2. Kiểm thử tích hợp

Kiểm thử tích hợp không xảy ra ở giai đoạn cuối của vòng đời phát triển phần mềm, đúng hơn nó được tiến hành đồng thời với sự phát triển. Do vậy trong hầu hết các trường hợp tất cả các module không thực sự có sẵn để kiểm thử và đây là những thách thức đi kèm để kiểm thử một số thứ không tồn tại.

2.3. Kiểm thử hệ thống

Kiểm thử hệ thống liên quan đến hành vi của toàn bộ hệ thống / sản phẩm được xác định bởi phạm vi của một dự án hoặc sản phẩm phát triển. Nó có thể bao gồm các bài kiểm thử dựa trên rủi ro và / hoặc yêu cầu đặc điểm kỹ thuật, quy trình nghiệp vụ, trường hợp sử dụng hoặc các mô tả cấp cao về hành vi của hệ thống, tương tác với hệ điều hành và tài nguyên hệ thống. Kiểm thử hệ thống thường là bài kiểm thử cuối cùng về sự phát triển để xác minh rằng hệ thống sẽ được cung cấp đáp ứng các đặc điểm kỹ thuật và mục đích của nó có thể là để tìm càng nhiều khiếm khuyết càng tốt. Thông thường nó được thực hiện bởi các chuyên gia kiểm thử tạo thành một nhóm kiểm thử dành riêng và đôi khi độc lập, trong quá trình phát triển, báo cáo với người quản lý phát triển.

2.4. Kiểm thử chấp nhận

Kiểm thử Chấp nhận (acceptance test) được tạo ra từ user story (yêu cầu người dùng). Trong một phân đoạn, những user story được chọn trong buổi họp lập kế hoạch phân đoạn sẽ được chuyển thành các kiểm thử chấp nhận. Khách hàng xác định kịch bản để kiểm thử xem một user story đã được triển khai đúng chưa. Mỗi user story có thể có một hay nhiều kiểm thử chấp nhận, hoặc bất cứ điều gì để có thể đảm bảo các tính năng hoạt động tốt. Kiểm thử chấp nhận là kiểm thử hệ thống hộp đen (black box). Mỗi một kiểm thử chấp nhận đại diện cho một số kết quả được mong đợi từ hệ thống. Khách hàng có trách nhiệm kiểm tra tính chính xác của các kiểm thử chấp nhận và xem xét kết quả để quyết định kiểm thử thất bại nào có độ ưu tiên cao nhất. Kiểm thử chấp nhận cũng được sử dụng như kiểm thử hồi quy trước khi một sản phẩm được phát hành.

3. Các kiểu kiểm thử

3.1. Kiểm thử chức năng

Kiểm thử chức năng là một loại kiểm thử hộp đen (black box) và test case của nó được dựa trên đặc tả của ứng dụng phần mềm/thành phần đang test. Các chức năng được test bằng cách nhập vào các giá trị nhập và kiểm tra kết quả đầu ra, và ít quan tâm đến cấu trúc bên trong của ứng dụng (không giống như kiểm thử hộp trắng - white-box testing). Kiểm thử chức năng thường bao gồm 5 bước (trích dẫn các bước cần thiết):

• Việc xác định các chức năng mà phần mềm mong muốn sẽ thực hiện
• Việc tạo ra các dữ liệu đầu vào dựa trên các tài liệu đặc tả kỹ thuật của các chức năng
• Việc xác định kết quả đầu ra dựa trên các tài liệu đặc tả kỹ thuật của các chức năng
• Việc thực hiện các trường hợp kiểm thử
• Việc so sánh kết quả thực tế và kết quả mong muốn

3.2. Kiểm thử đặc tính phần mềm

• Bao gồm 5 đặc điểm phụ: sự phù hợp, độ chính xác, an ninh, khả năng tương tác và tuân thủ.
• Độ tin cậy, được định nghĩa sâu hơn vào đặc điểm phụ đặc điểm, chấp nhận lỗi, khả năng thu hồi và tuân thủ;
• Khả năng sử dụng, được chia thành các phần nhỏ dễ hiểu: Khả năng học hỏi, tính hoạt động, tính hấp dẫn và tuân thủ;
• Hiệu suất, được chia thành hành vi thời gian (hiệu suất), sử dụng tài nguyên và tuân thủ.
• Khả năng bảo trì, bao gồm 5 đặc điểm phụ: phân tích, khả năng thay đổi, tính ổn định, khả năng kiểm thử và tuân thủ;
• Tính di động, mà còn bao gồm năm tiểu đặc điểm: khả năng thích ứng, khả năng lắp đặt, sự cùng tồn tại, khả năng thay thế và tuân thủ.

3.3. Kiểm thử cấu trúc

Mục tiêu thứ ba của kiểm thử là cấu trúc của hệ thống hoặc thành phần. Nếu chúng ta nói về cấu trúc của một hệ thống, chúng ta có thể gọi nó là kiến trúc hệ thống. Kiểm thử kết cấu thường được gọi là 'hộp trắng' hoặc 'hộp kính' vì chúng ta quan tâm đến những gì đang xảy ra 'bên trong hộp'. Kiểm thử kết cấu thường được sử dụng như là một cách để đo sự triệt để kiểm thử thông qua phạm vi bảo vệ của một bộ các yếu tố cấu trúc hoặc phạm vi bảo vệ. Nó có thể xảy ra ở bất kỳ mức độ kiểm thử, mặc dù nó là đúng để nói rằng nó có xu hướng chủ yếu được áp dụng ở tích hợp và nói chung ít có khả năng mức độ kiểm thử cao hơn, ngoại trừ kiểm thử quy trình nghiệp vụ. Tại tích hợp thành phần cấp độ nó có thể được dựa trên kiến trúc của hệ thống, chẳng hạn như một hệ thống phân cấp gọi điện thoại. Một hệ thống, tích hợp hệ thống hoặc cơ sở kiểm thử nghiệm thu chấp nhận có thể là một mô hình kinh doanh hoặc cấu trúc menu.

3.4. Kiểm thử thay đổi

Kiểm thử xác nhận (kiểm thử lại) Kiểm thử lại nghĩa là thực hiện test lại một lần nữa. Lý do không quan trọng. Khi bạn thực hiện lại 1 lần kiểm thử, nghĩa là bạn đang Kiểm thử lại. bạn có thể kiểm thử lại các chức năng của phiên bản hiện tại, hoặc 1 sửa lỗi, hoặc chức năng của phiên bản cũ, hoặc một test case mà bạn vừa xây dựng, v.v... Kiểm thử hồi quy

• Kiểm thử hồi quy là 1 dạng của Kiểm thử lại. Chi tiết để trả lời câu hỏi "Vì sao" và "Khi nào" sẽ giúp phân biện nó với Kiểm thử lại.
• Khi nào chúng ta kiểm thử lại: khi phần mềm đang có thay đổi.
• Tại sao chúng ta kiểm thử lại: để đảm bảo các thay đổi mới thêm vào không làm cho các chức năng đã/đang hoạt động trở nên không ổn định.

4. Kiểm thử bảo trì

4.1. Phân tích tác động và kiểm thử hồi quy

Thông thường kiểm thử bảo trì sẽ bao gồm hai phần:

• Kiểm thử thay đổi.
• Kiểm thử hồi quy để thấy rằng hệ thống không bị ảnh hưởng bởi kiểm thử bảo trì.

4.2. Dấu hiệu cho việc kiểm thử bảo trì

• Sửa đổi theo kế hoạch: Các loại kế hoạch sửa đổi có thể được xác định:
  • Sửa đổi hoàn hảo (thích nghi phần mềm với mong muốn của người dùng, ví dụ bằng cách cung cấp các chức năng mới hoặc nâng cao hiệu suất);
  • Sửa đổi thích nghi (thích ứng phần mềm với những thay đổi môi trường như: Phần cứng mới, phần mềm hệ thống mới hoặc luật mới);
  • Điều chỉnh sửa đổi kế hoạch (sửa chữa khiếm khuyết). Cách tiếp cận kiểm thử chuẩn có cấu trúc gần như hoàn toàn phù hợp với kế hoạch sửa đổi. Trung bình, thay đổi theo kế hoạch chiếm trên 90% tổng số công tác bảo trì hệ thống.
• Sửa đổi không theo kế hoạch: Sửa đổi không theo kế hoạch liên quan đến các khiếm khuyết đòi hỏi một giải pháp ngay lập tức. Có nhiều quy tắc và thủ tục khác nhau để giải quyết vấn đề loại này. Không thể thực hiện các bước cần thiết cho một cách tiếp cận có cấu trúc để kiểm thử. Ở một mức độ nào đó, loại kiểm thử bảo trì thường giống như viện trợ cấp cứu - vá - và ở giai đoạn sau quá trình kiểm thử tiêu chuẩn sau đó được thực hiện để thiết lập một bản sửa lỗi, kiểm thử nó và thiết lập mức độ thích hợp của tài liệu. Một phân tích rủi ro của các hệ thống hoạt động cần được thực hiện để thiết lập những chức năng hoặc chương trình nào gây nguy cơ lớn nhất đối với các dịch vụ vận hành. Nếu nó được quyết định rằng một chức năng cụ thể có nguy cơ nên luôn luôn được kiểm thử bất cứ khi nào có liên quan, cần chuẩn bị một số bài kiểm thử tiêu chuẩn có thể thực hiện gần như ngay lập tức. Ngay cả trong trường hợp có sửa đổi bổ sung, do đó có thể mang lại về việc nâng cao chất lượng bằng cách áp dụng một phương pháp kiểm thử cụ thể.