15/07/2021 - vừa được xem lúc 20 giờ trước
Người đăng: Nguyen Van Nam D
- Kỹ thuật thiết kế kiểm thử giúp chúng ta thiết kế một cách đầy đủ nhất các trường hợp kiểm thử. Vì việc test toàn diện là không thể;
- Kỹ thuật thiết kế kiểm thử giúp làm giảm số lượng các trường hợp kiểm thử mà vẫn đảm bảo chất lượng test, giúp xác định các phạm vi và điều kiện test mà khó nhận biết.
Có 2 dạng chính của kỹ thuật thiết kế kiểm thử:
- Static Testing [Kiểm thử tĩnh]
- Dynamic Testing [Kiểm thử động]
1. Static Testing [Kiểm thử tĩnh]
Static Testing hay còn gọi là Kiểm thử tĩnh là việc kiểm tra từng phần của phần mềm, chủ yếu dựa trên các tài liệu của phần mềm, hoặc tự phân tích các cú pháp của code để kiểm tra tính logic mà không cần phải chạy phần mềm một cách trực tiếp. Các loại Static Testing:
- Informal review: là quá trình đánh giá mà không cần hồ sơ cuộc họp, cũng không cần ghi chép lại nội dung cuộc họp. Informal review chủ yếu được thực hiện giữa 2 người ở bất kỳ đâu có thể là quán cà phê, căng-tin,... Phương pháp này không cần phải tuân theo chu trình gì, nên đem lại lợi ích khá nhanh chóng và không tốn kém chi phí.
- Walkthroughs: Đây là hình thức hướng dẫn, giải thích bởi người nắm rõ về logic phần mềm nhất, nhằm mục đích chuyển giao kiến thức tới những người tham gia vào chu trình test, qua đó mọi người sẽ có đạt được sự hiểu biết nhất định. Thường thì phương pháp này sẽ truyền tải qua một buổi họp, và có người ghi chép riêng.
- Technical review: Phương pháp này tập trung vào việc đánh giá kỹ thuật của phần mềm. Thường được dẫn dắt bởi moderator hoặc người có kiến thức kỹ thuật cùng với sự tham gia của các chuyên gia kỹ thuật. Đây là một cuộc thảo luận tập trung vào việc đạt được sự đồng thuận về nội dung kỹ thuật nhằm đưa ra quyết định, đánh giá sự thay thế, tìm kiếm lỗi, giải quyết vấn đề kỹ thuật...
- Inspection: Phương pháp này cũng được điều hành bởi moderator. Mục đích của nó là để xác định rõ vai trò của từng người trong quy trình cũng như các tiêu chuẩn đầu vào, đầu ra của phần mềm. Từ đó tìm kiếm lỗi cũng như tập hợp và phân tích để tối ưu hóa quy trình.
2. Dynamic Testing [Kiểm thử động]
Kỹ thuật specification-based
Nhóm kỹ thuật specification-based chỉ tập trung kiểm thử những yếu tố bên ngoài của hạng mục kiểm thử. Chúng có thể là các đặc điểm kỹ thuật, thiết kế, cách vận hành bên ngoài,… Nhờ đó, tester có thể test chất lượng bên ngoài mà không làm hỏng cấu trúc bên trong phần mềm. Nhóm kỹ thuật này gồm có:
a. Phân vùng tương đương [Equivalence Partitioning]
Là phương pháp chia miền đầu vào của một chương trình thành các lớp dữ liệu, từ đó suy dẫn ra các ca kiểm thử, thường được tiến hành theo 2 bước sau:
- B1: phân các vùng dữ liệu thành các vùng điều kiện tương đương
- B2: Xác định các ca kiểm thử
Nguyên tắc xác định các lớp tương đương:
- Nếu điều kiện đầu vào định rõ giới hạn của một mảng thì chia vùng tương đương thành 3 tình huống: Xác định một lớp tương đương hợp lệ. Xác định hai lớp tương đương không hợp lệ. Ví dụ: giá trị của mật khẩu phải từ 6-24 ký tự, vậy ta có 1 lớp giá trị tương đương hợp lệ là [6-24], 2 lớp tương đương không hợp lệ là:
- Nếu điều kiện đầu vào là một giá trị xác định thì chia vùng tương đương thành 3 tình huống: Một lớp tương đương hợp lệ. Hai lớp tương đương không hợp lệ. Ví dụ: test font chữ = 12, vậy ta có 1 lớp giá trị tương đương hợp lệ là 12, 2 lớp tương đương không hợp lệ là: .
b. Phân tích giá trị biên [Boundary Value Analysis]
Test các giá trị biên của các vùng dữ liệu vào và ra.
- Kiểm tra 2 giá trị: Có 4 test cases [Nhỏ nhất, Sát dưới mức nhỏ nhất, Sát trên mức lớn nhất, Lớn nhất]. Ví dụ:
- Kiểm tra 3 giá trị: Có 6 test cases [Nhỏ nhất, Sát dưới mức nhỏ nhất, Sát trên mức nhỏ nhất, Lớn nhất, Sát dưới mức lớn nhất, Sát trên mức lớn nhất]. Ví dụ:
c. Bảng quyết định [Decision Table Testing]
Bảng quyết định là một kỹ thuật tốt khi input có nhiều điều kiện và có nhiều action output. Giúp giảm thời gian chạy thử nhưng vẫn giữ đủ độ bao phủ của test.
- Liệt kê tất cả các điều kiện và action
- Tính số lượng các trường hợp tổ hợp có thể
- Điền các tổ hợp vào Bảng
- Lược bỏ các tổ hợp test và đưa ra action cho các trường hợp test.
- Ví dụ về bảng quyết định:
d. Chuyển đổi trạng thái [State Transition Testing]
Đây là một phương pháp kiểm thử mà trong đó dựa vào thay đổi điều kiện đầu vào gây ra thay đổi trạng thái trong phần mềm được kiểm thử. Trong kỹ thuật này, tester sẽ cung cấp cả giá trị kiểm thử đầu vào hợp lệ và không hợp lệ, sau đó xác định cách xử lý của hệ thống.
- Các bước tạo bảng chuyển đổi trạng thái:
- Liệt kê tất cả các trạng thái từ biểu đồ chuyển đổi trạng thái vào cột đầu tiên của bảng.
- Liệt kê tất cả các kết hợp event/condition
- Tạo bảng với trong đó, mỗi hàng sẽ cho 1 trạng thái với kết hợp event/condition
- Mỗi hàng bao gồm 4 trường:
- Current state
- Event/condition
- Action
- New state
Ví dụ về bảng chuyển đổi trạng thái:
e. Use cases Testing
Là một kỹ thuật kiểm thử phần mềm, giúp xác định các test cases bao phủ toàn bộ hệ thống trên cơ sở chuyển giao từ điểm bắt đầu đến điểm kết thúc. Ta có thể sử dụng Kiểm thử Use Case để tìm các liên kết còn thiếu sót hay các yêu cầu không hoàn chỉnh, từ đó tìm cách khắc phục, hệ thống sẽ hoạt động chính xác hơn.
Kỹ thuật Structure-based
Nhóm kỹ thuật structure-based giúp tester kiểm thử cấu trúc và cách vận hành bên trong của phần mềm. Cấu trúc phần mềm thường bao gồm code [mã], control flow [luồng điều khiển], data flow [luồng dữ liệu],… Lúc này, tester sẽ nạp các input để thực thi code và kiểm tra đối chiếu những output thu được. Vì có liên quan đến cấu trúc phần mềm nên tester phải có kiến thức lập trình. Dưới đây là các kỹ thuật thiết kế test case thuộc nhóm structure-based:
a. Statement testing [kiểm thử câu lệnh] Trong kỹ thuật statement testing, mọi câu lệnh trong cấu trúc code sẽ thực thi ít nhất một lần. Qua đó, tester có thể test được cách vận hành của toàn bộ source code [mã nguồn] phần mềm. Tuy nhiên, tester không thể kiểm thử điều kiện sai mà chỉ có thể thực thi các điều kiện đúng.
b. Decision testing [kiểm thử quyết định] Decision testing sẽ thực thi, test những quyết định dựa trên decision result [kết quả quyết định]. Để làm điều này, test case sẽ đi theo các control flow từ decision point [điểm quyết định]. Decision testing giúp kiểm thử xem có câu lệnh không thể truy cập hay gây bất thường không.
c. Condition testing [kiểm thử điều kiện] Condition testing được dùng để test các biểu thức Boolean có dạng True [đúng] hoặc False [sai]. Mỗi biểu thức Boolean sẽ được thực thi ít nhất một lần bằng cả tham số True và False. Với kỹ thuật này, test case được thiết kế để những điều kiện Boolean có thể thực thi dễ dàng.
d. Multiple condition testing [kiểm thử đa điều kiện] Mục đích của kỹ thuật này là kiểm thử mọi tổ hợp điều kiện có thể của quyết định. Công thức tính số tổ hợp này là 2 lũy thừa bậc N, với N là số biến điều kiện. Số lượng tổ hợp này cũng chính là số lượng test case mà bạn phải dùng.
Kỹ thuật experience-based
Như tên gọi của mình, nhóm kỹ thuật này phụ thuộc vào hiểu biết và năng lực của tester. Những kiến thức, kinh nghiệm của tester sẽ là cơ sở để thiết kế test case. Do đó, chất lượng của các test case dựa trên kinh nghiệm sẽ hoàn toàn phụ thuộc vào tester. Nhóm kỹ thuật này được chia thành 2 loại:
a. Exploratory testing [kiểm thử thăm dò] Đây là kỹ thuật test không cần chuẩn bị hay theo một lịch trình cụ thể. Khi thực hiện exploratory testing, tester sẽ vừa phân tích phần mềm, vừa thiết kế và thực thi kiểm thử. Ngoài ra, việc lên kế hoạch và lưu kết quả cũng diễn ra linh động trong quá trình kiểm thử.
b. Error guessing [phỏng đoán lỗi] Error guessing được dùng để dự đoán các lỗi tiềm ẩn dựa trên kiến thức của tester. Những kiến thức này thường về cách vận hành trước đây của phần mềm, các lỗi đã và có khả năng xuất hiện, những lỗi mà tester từng phát hiện,…
Nguồn tham khảo: //vn.got-it.ai/blog/khai-quat-ve-ky-thuat-thiet-ke-test-case-trong-kiem-thu-phan-mem
03/09/2021 Blogs 0 Comments
The test basis documentation is analyzed in order to determine what to test, i.e., to identify the test conditions. – Trong quá trình phân tích test thì các tài liệu cơ sở của test được phân tích để xác định các trường hợp test, và các điều kiện testA test condition is defined as an item or event that could be verified by one or more test cases [e.g., a function, transaction, quality characteristic or structural element]. – Một bộ điều kiện test được định nghĩa là 1 item hoặc sự kiện mà có thể kiểm tra được bởi 1 hoặc nhiều test case[ vd chức năng, giao dịch, đặc tính chất lượng hoặc các yếu tố cấu trúc]Establishing traceability from test conditions back to the specifications and requirements enables both effective impact analysis when requirements change, and determining requirements coverage for a set of tests – Thiết lập ma trận theo dõi các điều kiện test với các đặc tả và yêu cầu sẽ giúp việc phân tích các ảnh hưởng hiểu quả hơn khi yêu cầu thay đổi và xác định được mức độ bao phủ của 1 tập hợp testDuring test analysis and test design:The detailed test approach is implemented to select the test design techniques to use based on, among other considerations, the identified risks – Trong suốt quá trình phân tích các trường hợp test, kỹ thuật thiết kế test caces được lựa chọn sử dụng dựa trên sự xem xét phù hợp và các rủi roThe test cases and test data are created and specified. A test case consists of a set of input values, execution preconditions, expected results and execution post conditions, defined to cover a certain test objective[s] or test condition[s]. – Một test case bao gồm 1 tập các giá trị đầu vào, điều kiện chạy, kết quả mong đợi, điều kiện sau khi chạy.The ‘Standard for Software Test Documentation’ [IEEE STD 829-1998] describes the content of test design specifications [containing test conditions] and test case specifications. – Thiết kế test cũng bao gồm cả việc tạo ra test cases và test data. – Tiêu chuẩn IEEE STD 829-1998 mô tả cụ thể 1 tài liệu thiết kế test case và đặc tả test case gồm những nội dung nào
Bạn đang xem: Test design là gì, unit những cái bẫy cần tránh Đối với tester mới
During test implementation
The test cases are developed, implemented, prioritized and organized in the test procedure specification [IEEE STD 829-1998]. – Trong quá trình thực hiện test thì test case sẽ được xây dựng, thực hiện, sắp xếp thứ tự ưu tiên, tổ chức trong tài liệu đặc tả thủ tục test [IEEE STD 829- 1998].Xem thêm: Si Là Gì Trong Xuất Nhập Khẩu, Cho Mình Hỏi Si Trong Xuất Nhập Khẩu Là Gì
The test procedure specifies the sequence of actions for the execution of a test. If tests are run using a test execution tool, the sequence of actions is specified in a test script [which is an automated test procedure]. – Thủ tục test chỉ rõ thứ tự của các hành động dể thực hiện test. Nếu Nếu các Test này được chạy bằng tool, thì thứ tự các hành động sẽ được chỉ rõ trong test script.
3.2 Categories of Test Design Techniques
The purpose of a test design technique is to identify test conditions, test cases, and test data. – Mục tiêu của các kỹ thuật thiết kế test là để xấc định các điều kiện test, test cases, và test data
It is a classic distinction to denote test techniques as black-box or white-box – Chia thành 2 kỹ thuật thiết kế test cơ bản là black-box và white-box
Common characteristics of specification-based test design techniques include – Đặc điểm chung của kỹ thuật thiết kế test hướng đặc tả:
Models, either formal or informal, are used for the specification of the problem to be solved, the software or its componentsCác mô hình, hoặc là chính thức hay không chính thức, được sử dụng cho các đặc điểm kỹ thuật của vấn đề cần giải quyết, các phần mềm hoặc các thành phần của nó
Test cases can be derived systematically from these modelsTC được dẫn ra được bắt nguồn từ những mô hình có hệ thống
Common characteristics of structure-based test design techniques include – Đặc điểm chung của kỹ thuật thiết kế test hướng cấu trúc:
Information about how the software is constructed is used to derive the test cases [e.g., code and detailed design information]TC được dẫn ra dựa vào việc hiểu rõ cấu trúc của PM [ dự vào code hoặc thiết kế chi tiết]
The extent of coverage of the software can be measured for existing test cases, and further test cases can be derived systematically to increase coverageMức độ bao phủ của test có thể đo đạc được và có thể bổ sung test case để tang được mức độ bao phủ này
Common characteristics of experience-based test design techniques include – Đặc điểm chung của kỹ thuật thiết kế test hướng kinh nghiệm:
The knowledge and experience of people are used to derive the test cases – Kiến thức và kinh nghiệm của con người được dung để viết test cacseThe knowledge of testers, developers, users and other stakeholders about the software, its usage and its environment is one source of information – Nguồn thông tin được lấy từ kiến thức của tester, LTV, user, nhà đầu tư về phần mềm, khả năng sử dụng và môi trườngKnowledge about likely defects and their distribution is another source of information – Nguồn thông tin còn đc lấy từ các lỗi tương tự, sự phân bố của nóMeasurement – Đo đạc
Test successful coverage = Tổng TC Pass/ [Tổng TC- N/A]
Objective assessment of thoroughness of testing [with respect to use of each technique]- Mục tiêu đánh giá mức độ triệt để của kiểm thử [mong đợi đối với mỗi kỹ thuật được sử dụng]Useful for comparison of one test effort to another – Sử dụng để so sánh nỗ lực của một thử nghiệm với những cái khácEg:| Project A | Project B |
| 60% Equivalence partitions – phân vùng tương đương | 40% Equivalence partitions |
| 50% Boundaries – biên | 45% Boundaries |
| 75% Branches – nhánh | 60% Branches |