Số lần lặp Input Tổng số phần tử của dãy Số lượng phần tử xét Output (Sum) 6 [4,5,6,7,14,8,22,15,46] 6 10 6 32
Với code_4, chương trình kiểm thử phần mềm cũng thực hiện kiểm thử để đưa tính độ phức tạp, ma trận kiểm thử, tập đường cơ bản.
Với bộ input nhập vào trong mục Đầu vào hợp lệ theo cấu trúc: [<giá trị phần tử 1>, [<giá trị phần tử 2>,[<giá trị phần tử 3>…]<1 dấu cách> <số lượng phần tử xét trong dãy> từ đó đưa ra kết quả Sum (Tổng các số chẵn trong các phần tử được xét của dãy) trong mục Đầu ra và Đường kiểm thử.
Hình 3.17: Form kiểm thử ứng với code_4
3.3.6. Kiểm thử vòng lặp While
Đối với đơn vị chương trình thứ nhất (có tên code_1) qua áp dụng các bước trong quá trình kiểm thử vòng lặp đơn, nên chương trình kiểm thử ở trên đã đưa ra được 7 đường kiểm thử của đơn vị chương trình với số lần lặp tương ứng số giá trị nhập vào của chương trình thử nghiệm kiểm thử là: 0 giá trị, 1 giá trị, 2 giá trị, m =5 giá trị (0<m<100), 99 giá trị, 100 giá trị, 101 giá trị.
Đối với đơn vị chương trình thứ hai (có tên code_2), đơn vị chương trình thứ ba (có tên code_3), đơn vị chương trình thứ bốn (có tên code_4) đều thực hiện kiểm thử vòng lặp while thông qua các bộ test từ đó tìm ra các lỗi còn tiềm ẩn trong chương trình để thu được ca kiểm thử thành công.
Mặc dù 4 chương trình code thử nghiệm cho chương trình chạy kiểm thử ở dạng đơn giản, nhưng cũng đã làm nổi bật được kỹ thuật ma trận đồ thị trong quá trình xây dựng phần mềm kiểm thử.
3.4. Đánh giá và so sánh kỹ thuật ma trận đồ thị với một số kỹ thuật thiết kế ca kiểm thử khác kế ca kiểm thử khác
Kỹ thuật ma trận kiểm thử là một trong những kỹ thuật kiểm thử hộp trắng. Ma trận kiểm thử được sử dụng như một dữ liệu có cấu trúc để kiểm tra các con đường cơ bản: số đường đi qua nút (có thể tính cả trọng số của chúng). Ma trận kiểm thử là một công cụ mạnh trong việc đánh giá cấu trúc điều khiển chương trình.
Thứ nhất, về mặt kỹ thuật, kỹ thuật ma trận kiểm thử có những ưu thế
nổi trội sau:
- So với kỹ thuật đồ thị dòng, tận dụng được những tính năng đặc trưng của kỹ thuật đồ thị dòng là “kiểm thử đường cơ sở”. Chúng ta biết rằng phương pháp đường cơ sở giúp cho người thiết kế trường hợp kiểm thử có thể suy dẫn ra một cách đo độ phức tạp logic của thiết kế thủ tục và dùng cách đo này như một hướng dẫn để xác định một tập cơ sở các đường thực hiện. Các trường hợp kiểm thử được suy dẫn ra để thực hiện một tập cơ sở, được đảm bảo để thực hiện mọi câu lệnh trong chương trình ít nhất một lần trong khi kiểm thử. Mỗi kết cấu có cấu trúc theo triết lý lập trình có cấu trúc như sequence, if, while, until, case đều có một cú pháp đơn giản thể hiện. Như vậy, kỹ thuật ma trận đồ thị thực chất cũng là một kỹ thuật dựa trên cấu trúc điều khiển của chương trình. Từ đó tính được độ phức tạp V(G) và xác định được các đường kiểm thử cụ thể.
Bên cạnh đó, kỹ thuật ma trận kiểm thử đã khắc phục được hạn chế rất lớn của kỹ thuật đồ thị dòng là việc xác định miền phẳng kín trên đồ thị dòng
rất khó tự động hóa (mặc dù thực hiện bằng tay lại rất trực quan và dễ). Điều này gây trở ngại lớn cho việc lập trình.
- So với kỹ thuật điều kiện logic, bao phủ được điều kiện logic, nó đỡ phức tạp hơn vì không phải phân tích các kiểu sai và điều kiện phức hợp cấu thành từ hơn một điều kiện đơn nhờ các toán tử Bool.
- So với kỹ thuật kiểm thử phân nhánh, nó vẫn kiểm thử được từng điều kiện trong chương trình. Giống như kiểm thử nhánh, việc thực hiện vẫn theo nguyên tắc: với mỗi điều kiện phức hợp C, thì với mỗi nhánh “true” và “false” của C, mỗi điều kiện đơn trong C phải được kiểm thử ít nhất một lần.
- So với kỹ thuật kiểm thử miền, nó cũng quan tâm đến kiểm thử nhánh và toán tử quan hệ, dùng “ràng buộc điều kiện làm điều kiện cần thử” để phát hiện sai ở nhánh và toán tử khi xảy ra 1 lần và không có biến chung.
- So với kỹ thuật kiểm thử điều khiển theo dòng dữ liệu, nó duyệt toàn bộ chứ không chỉ tuyển chọn các đoạn đường của chương trình tương ứng nhằm định vị việc xác định biến và sử dụng biến trong chương trình. Với chiến lược theo dòng dữ liệu, chương trình được kiểm soát phần lớn trạng thái.
Thứ hai, về mặt thiết kế ca kiểm thử, kỹ thuật ma trận đồ thị dựa vào ý tưởng phương pháp bao phủ câu lệnh bao gồm cả bao phủ quyết định/điều kiện, thực hiện đủ các ca kiểm thử mà mỗi điều kiện trong một quyết định thực hiện trên tất cả các kết quả có thể ít nhất 1 lần và mỗi điểm vào được gọi ít nhất 1 lần, và bao phủ đa điều kiện, viết đủ các ca kiểm thử mà tất cả những sự kết hợp của các kết quả điều kiện có thể trong mỗi quyết định, và tất cả các điểm vào phải được gọi ít nhất 1 lần. So với một số kỹ thuật thiết kế ca kiểm thử khác, nó có những ưu thế nhất định.
- So với kỹ thuật phân lớp tương đương, nó không bỏ sót một ca kiểm thử có lợi nào.
- So với kỹ thuật phân tích giá trị biên, nó không đòi hỏi yêu cầu óc sáng tạo cao và lượng chuyên môn hóa nhất định cũng như đòi hỏi tính kinh nghiệm cao.
- So với kỹ thuật đồ thị nguyên nhân – kết quả, nó không cần khảo sát đầu vào. Việc kiểm tra sự kết hợp đầu vào không phải là một nhiệm vụ đơn giản, thường là rất lớn, dễ có thể dẫn tới việc kiểm thử không có hiệu quả, mất thời gian do số lượng các ca kiểm thử rất lớn. Bên cạnh đó, kỹ thuật đồ thị nguyên nhân – kết quả cũng gặp khó khăn trong việc chuyển đổi đồ thị thành bảng quyết định, tức là không có tính thuật toán, khó có thể tự động hóa nó bằng việc viết một chương trình.
- So với kỹ thuật đoán lỗi, nó không yêu cầu một quy trình có tính trực giác cao, không cần liệt kê những trường hợp đặc biệt đó mà có thể đã bị bỏ sót khi chương trình được thiết kế.
Tất nhiên mỗi kỹ thuật có thể đóng góp một tập riêng các ca kiểm thử hữu dụng, nhưng không cái nào trong số chúng tự nó đóng góp một tập trọn vẹn các ca kiểm thử.
3.5. Đánh giá kết quả thử nghiệm và hướng mở rộng
Kết quả thử nghiệm trình bày ở trên, về cơ bản, đã đáp ứng được mục tiêu đề ra trong luận văn. Phần mềm thử nghiệm đã có thể kiểm thử được nhiều đơn vị chương trình khác nhau
Hướng mở rộng:
- Phát triển chương trình kết hợp đồ họa vẽ biểu đồ để người dùng dễ hiểu, dễ hình dung.
- Thực hiện kiểm thử cho nhiều đơn vị chương trình hơn, với những đơn vị chương trình lớn hơn nữa, và chương trình kiểm thử có thể kiểm thử cho nhiều đơn vị chương trình viết bằng các ngôn ngữ khác nhau.
KẾT LUẬN VÀ KIẾN NGHỊ 1.Kết luận (adsbygoogle = window.adsbygoogle || []).push({});
Từ việc nghiên cứu tổng quan về kiểm thử phần mềm và kiểm thử hộp trắng để nắm những kiến thức cơ sở về kiểm thử phần mềm nói chung và kiểm thử hộp trắng nói riêng phục vụ các nghiên cứu tiếp theo. Sau đó, em tiến hành nghiên cứu các hướng chính trong phương pháp kiểm thử hộp trắng. Cuối cùng em nghiên cứu một số kỹ thuật chính để thiết kế ca kiểm thử đặc biệt là kỹ thuật ma trận đồ thị cho thiết kế ca kiểm thử và áp dụng kỹ thuật ma trận đồ thị này vào kiểm thử một số chương trình cụ thể.
Như vậy với quá trình nghiên cứu ở trên về mặt cơ bản em đã hoàn thành được mục tiêu của đề tài đưa ra. Một số kết quả đạt được như sau:
- Nắm được kiến thức cơ bản liên quan đến kiểm thử phần mềm và kiểm thử thộp trắng;
- Trình bày một số kỹ thuật chính để thiết kế các ca kiểm thử trong kiểm thử phần mềm;
- Lập trình thử nghiệm kỹ thuật ma trận đồ thị cho thiết kế ca kiểm thử từ đó có thể kiểm thử được một số môdun phần mềm.
- Báo cáo có thể làm tài liệu tham khảo về lĩnh vực kiểm thử phần mềm, kiểm thử hộp trắng và đặc biệt là kiểm thử bằng kỹ thuật ma trận đồ thị;
- Kết quả nghiên cứu có thể làm tiền đề cho các nghiên cứu liên quan khác.
2. Kiến nghị
Đây là lĩnh vực mới tiếp cận nên trong báo cáo còn một số phần chưa được hoàn thiện, do vậy thời gian tới em sẽ tiếp tục nghiên cứu chuyên sâu hơn và cố gắng xây dựng được chương trình kiểm thử cho nhiều môđun hơn nữa dựa vào kỹ thuật ma trận đồ thị.
Trong quá trình làm luận văn, em đã cố gắng rất nhiều, tuy nhiên không tránh khỏi những thiếu sót, em mong rằng sẽ nhận được các ý kiến đóng góp của các Thầy giáo, Cô giáo, các bạn bè, đồng nghiệp để luận văn ngày càng hoàn thiện hơn.
TÀI LIỆU THAM KHẢO
A.TIẾNG VIỆT
[1]. Thạc Bình Cường, Nguyễn Đức Mận (2011), Kiểm thử và đảm bảo chất lượng phần mềm, Nhà xuất bản Bách Khoa Hà Nội.
[2]. Chu Thị Minh Huệ, Đặng Đức Hạnh, Nguyễn Ngọc Bình (2015), Phương pháp sinh tự động ca kiểm thử từ mô hình ca sử dụng, Kỷ yếu Hội nghị Quốc gia lần thứ VIII về Nghiên cứu cơ bản và ứng dụng CNTT (FAIR); DOI: 10.15625/vap.2015.000198.
[3]. Phạm Ngọc Hùng, Trương Anh Hoàng, Đặng Văn Hưng (2014), Giáo trình kiểm thử phần mềm, Đại học Công nghệ, Đại học Quốc gia Hà Nội
[4]. Phạm Thị Hùy (2017), Kỹ thuật xác định các ca kiểm thử, Luận văn Thạc sỹ CNTT, Đại học Quản lý và Công nghệ Hải Phòng.
[5].Tô Hữu Nguyên, Nguyễn Hồng Tân, Hà Thị Thanh, Đỗ Thanh Mai (2016), Thực thi tượng trưng trong sinh tự động dữ liệu kiểm thử phần mềm, Tạp chí Khoa học Đại học Đà Lạt, Tập 6, Số 2, 254–131 254.
[6]. Đỗ Văn Nhỏ, Nguyễn Quang Vũ, Nguyễn Thanh Bình (2017), Kiểm thử đột biến bậc cao: hiệu quả và những vấn đề tồn tại, Kỷ yếu Hội nghị Quốc gia lần thứ X về Nghiên cứu cơ bản và ứng dụng CNTT (FAIR), Đà Nẵng, ngày17-18/08/2017.DOI:10.15625/vap.2017.00040.
[7]. Lê Văn Phùng (2014), Kỹ nghệ phần mềm, tái bản lần 1, Nhà xuất bản Thông tin và Truyền thông.
[8]. Lê Văn Phùng (2015), Kỹ nghệ phần mềm nâng cao, tái bản lần 1, Nhà xuất bản Thông tin và Truyền thông.
[9]. Lê Văn Phùng, Nguyễn Văn Tảo (2018), Giáo trình Công nghệ phần mềm nâng cao, Nhà xuất bản Đại học Thái Nguyên.
[10]. Nguyễn Thị Tính (2016), Các phương pháp đánh giá chất lượng phần mềm, Luận văn Thạc sỹ CNTT, Đại học CNTT&TT, Đại học Thái Nguyên.
[11]. Nguyên Thị Yên (2016), Các kỹ thuật trong kiểm thử dòng dữ liệu tĩnh, Luận văn thạc sỹ Kỹ thuật phần mềm, Đại học Công nghệ, Đại học quốc gia Hà Nội.
B.TIẾNG ANH
[12] L. Madeyski, W. Orzeszyna, R. Torkar, and M. Józala (2014). Overcoming the equivalent mutant problem: A systematic literature review and a comparative experiment of second order mutation. IEEE Transactionson Software Engineering, 40 (1):23-42.
[13]. Quang Vu Nguyen and L. Madeyski (2015), Searching for strongly subsuming higher order mutants by applying multiobjective optimization algorithm. Advanced Computational Methods for Knowledge Engineering , Advances in Intelligent Systemsand Computing, 358:391-402.
[14]. Quang Vu Nguyen and L. Madeyski (2017), Addressing mutation testing problems by applying multi-objective optimization algorithms and higher order mutation. Journal of Intelligent & Fuzzy Systems, vol. 32, No 2, pp. 1173-1182, 2017.
[15]. Roger S.Pressman (1992). Software Engineering, a Practitioner’s Approach. 3th Edition, McGraw-Hill, Inc.