CHƯƠNG 1. CƠ SỞ LÍ LUẬN VỀ KIỂM THỬ 1. Cơ sở lý luận về kiểm thử 1. Khái niệm cơ bản về kiểm thử 1.
khái niệm kiểm thử phần mềm Khái niệm phần mềm - Phần mềm (Software) là một tập hợp những câu lệnh hoặc chỉ thị (Instruction) được viết bằng một hoặc nhiều ngôn ngữ lập trình theo một trật tự xác định, và các dữ liệu hay tài liệu liên quan nhằm tự động thực hiện một số nhiệm vụ hay chức năng hoặc giải quyết một vấn đề cụ thể nào đó - Phần mềm thực hiện các chức năng của nó bằng cách gửi các chỉ thị trực tiếp đến phần cứng hoặc bằng cách cung cấp dữ liệu để phục vụ các chương trình hay phần mềm khác. - Phần mềm là một khái niệm trừu tượng, nó khác với phần cứng ở chỗ là "phần mềm không thể sờ hay đụng vào", và nó cần phải có phần cứng mới có thể thực thi được. Khái niệm website - Website còn gọi là trang web, trangmạng, là một tập hợp các trang web bao gồm văn bản, hình ảnhvideo, flash vv, thường chỉ nằm trong một tên miền( domain name) hoặc tên miền phụ (subdomain) Kiểm thử phần mềm: (kiểm tra, thử nghiệm) là một cuộc kiểm tra được tiến hành để cung cấp cho các bên liên quan thông tin về chất lượng của sản phẩm hoặc dịch vụ được kiểm thử. Kiểm thử có thể cung cấp cho doanh nghiệp một quan điểm, một cách nhìn độc lập về phần mềm để từ đó cho phép đánh giá và thấu hiểu được những rủi ro trong quá trình triển khai phần mềm.
Trong kỹ thuật kiểm thử không chỉ giới hạn ở việc thực hiện một chương trình hoặc ứng dụng với mục đích đi tìm các lỗi phần mềm (bao gồm các lỗi và các thiếu sót) mà còn là một quá trình phê chuẩn và xác minh một chương trình máy tính / ứng dụng / sản phẩm nhằm: - Đáp ứng được mọi yêu cầu hướng dẫn khi thiết kế và phát triển phần mềm. - Thực hiện công việc đúng như kỳ vọng. 4 Luan van - Có thể triển khai được với những đặc tính tương tự. - Và đáp ứng được mọi nhu cầu của các bên liên quan.
Tùy thuộc vào từng phương pháp, việc kiểm thử có thể được thực hiện bất cứ lúc nào trong quá trình phát triển phần mềm. Mục tiêu Kiểm thử phần mềm - Tìm các bug phát sinh do dev tạo ra khi code. - Đạt được sự tự tin và cung cấp thông tin về mức độ chất lượng. - Để ngăn ngừa lỗi.
- Đảm bảo rằng kết quả cuối cùng đáp ứng các yêu cầu kinh doanh và người sử dụng. - Để đạt được sự tín nhiệm của khách hàng bằng cách cung cấp cho họ một sản phẩm chất lượng. Kiểm thử phần mềm sẽ giúp hoàn thiện các ứng dụng phần mềm hoặc sản phẩm so với yêu cầu kinh doanh và người sử dụng. Nó là rất quan trọng để đảm bảo kiểm thử tốt để kiểm thử các ứng dụng phần mềm hoàn toàn và chắc chắn rằng nó hoạt động tốt và theo các thông số kỹ thuật.
Việc xác định phạm vi kiểm tra các trường hợp kiểm thử nên được thiết kế tốt với khả năng tối đa của việc tìm kiếm các lỗi hiệu quả và được tính toán là số bug báo cáo cho mỗi trường hợp kiểm thử. Kiểm tra phần mềm để chắc chắn kiểm thử đang thực hiện đúng cách và hệ thống đã sẵn sàng để sử dụng. Kiểm thử bao phủ các lĩnh vực khác nhau như: chức năng của các ứng dụng, khả năng tương thích của các ứng dụng với các hệ điều hành, phần cứng và các loại khác nhau của các trình duyệt, thực hiện kiểm thử để kiểm tra hiệu năng của các ứng dụng để đảm bảo rằng hệ thống đáng tin cậy và không có trục trặc hay không nên có bất kỳ vấn đề cản trở. Xác định rằng các ứng dụng có thể được triển khai một cách dễ dàng với máy tính và không có bất kỳ sự cố.
Do đó các ứng dụng rất dễ dàng để cài đặt, tìm hiểu và sử dụng. Kiểm thử phần mềm cho phép tạo ra những đánh giá khách quan về mức độ phù hợp của hệ thống các yêu cầu đã nêu và thông số kỹ thuật. Kiểm tra xác nhận rằng hệ thống đáp ứng các yêu cầu khác nhau bao gồm: chức năng, hiệu suất, độ tin cậy, an toàn, khả năng sử dụng và như vậy. Việc xác nhận này 5 Luan van được thực hiện để đảm bảo rằng chúng tôi đang xây dựng hệ thống phù hợp.
Xác nhận để đảm bảo đang xây dựng hệ thống phù hợp. Ngoài việc giúp đưa ra quyết định, các thông tin từ các kiểm thử phần mềm giúp quản lý rủi ro. Các nguyên tắc cơ bản của kiểm thử Kiểm thử chứng mình sự hiện diện của lỗi Kiểm thử chỉ có thể chứng minh được rằng sản phẩm có lỗi. Kiểm thử phần mềm không thể chứng mình rằng sản phẩm không còn lỗi.
Nghĩa là sản phẩm luôn có lỗi cho dù có kiểm thử nhiều bao nhiêu. Do đó, điều quan trọng là chúng ta phải thiết kế các trường hợp kiểm thử (test case) sao cho có thể tìm được càng nhiều lỗi càng tốt. Kiểm thử toàn bộ là không thể Trừ khi sản phẩm được kiểm thử quá đơn giản cũng như không có nhiều giá trị đầu vào (chẳng hạn như “Hello World”) thì việc chứng minh sản phẩm không còn bug cho dù có kiểm thử nhiều đến đâu là không khả thi. Hầu hết các sản phẩm ngày nay rất đa dạng và phức tạp do được phát triển trên nhiều nền tảng, công nghệ phong phú cũng như khả năng lưu trữ kết nối dữ liệu lớn, khiến việc kiểm thử trở nên khó khăn và việc kiểm thử toàn bộ là gần như không thể.
Kiểm thử với tất cả các kết hợp đầu vào và đầu ra, với tất cả các kịch bản là không thể trừ phi nó chỉ bao gồm ít trường hợp thì có thể kiểm thử toàn bộ. Thay vì kiểm thử toàn bộ, việc phân tích rủi ro và dựa trên sự mức độ ưu tiên chúng ta có thể tập trung việc kiểm thử vào một số điểm cần thiết, có nguy cơ lỗi cao hơn. Kiểm thử càng sớm càng tốt Nguyên tắc này yêu cầu bắt đầu thử nghiệm phần mềm trong giai đoạn đầu của vòng đời phát triển phần mềm. Các hoạt động kiểm thử phần mềm từ giai đoạn đầu sẽ giúp phát hiện bug sớm hơn.
Nó cho phép chuyển giao phần mềm theo yêu cầu đúng thời gian với chất lượng dự kiến. Ngoài ra ai làm phần mềm cũng biết được rằng việc phát hiện lỗi càng trể bao nhiêu thì chi phí để sửa lỗi càng cao bấy nhiêu. Tương tự, việc thay đổi yêu cầu không đúng ngay từ đầu thường tốn ít chi phí thay đổi tính năng trong hệ thống. Lỗi thường được phân bố tập trung Thông thường, phần lớn lỗi tập trung vào những module, thành phần chức năng chính của hệ thống.
Điều này cũng thuận theo nguyên lý Pareto: 80% số lượng lỗi được 6 Luan van tìm thấy trong 20% tính năng của hệ thống. Nếu bạn thành công xác định được điều này, bạn sẽ tập trung vào tìm kiếm lỗi quanh khu vực được xác định. Nó được coi là một trong những cách hiệu quả nhất để thực hiện kiểm tra hiệu quả Nghịch lý thuốc trừ sâu Trong kiểm thử phần mềm, nếu bạn cứ thực thi lặp đi lặp lại một bộ test case thì có khả năng rất thấp bạn sẽ tìm được lỗi từ những trường hợp kiểm thử này. Nguyên nhân là do khi hệ thống ngày càng hoàn thiện, những lỗi được tìm thấy lúc trước đã được sửa trong khi những trường hợp kiểm thử đã cũ.
Do đó, khi một lỗi được sửa hay một tính năng mới được thêm vào, chúng ta nên tiến hành làm regression (kiểm thử hồi qui) nhằm mục đích đảm bảo những thay đổi này không ảnh hưởng đến những vùng khác của sản phẩm. Kiểm thử phụ thuộc vào ngữ cảnh Theo nguyên tắc này thì nếu bạn đang kiểm thử ứng dụng web và ứng dụng di động bằng cách sử dụng chiến lược kiểm thử giống nhau, thì điều đó là sai lầm. Chiến lược để kiểm thử nên khác nhau và phụ thộc vào chính ứng dụng đó. Chiến lược cho test web application phải khác với ứng dụng android mobile.
Quan niệm sai lầm về việc “hết lỗi” Việc không tìm thấy lỗi trên sản phẩm không đồng nghĩa với việc sản phẩm đã sẵn sàng để tung ra thị trường. Việc không tìm thấy lỗi cũng có thể là do bộ trường hợp kiểm thử được tạo ra chỉ nhằm kiểm tra những tính năng được làm đúng theo yêu cầu thay vì nhằm tìm kiếm lỗi mới.4 Vai trò của kiểm thử Vai trò của kiểm thử phần mềm là Kiểm thử để tìm ra lỗi, ghi nhận thông tin về lỗi nhưng không sửa lỗi. Kiểm thử phần mềm không chỉ cần tìm lỗi phần mềm, mà còn là quá trình kiểm tra và xác minh một phần mềm đã đáp ứng được yêu cầu và mong đợi của khách hàng. Một số lỗi phần mềm đã gây ra thiệt hại nghiêm trọng trong lịch sử như: - Máy bay Airbus A300 do lỗi Phần mềm và bị tai nạn ngày 26/4/1994 giết chết 264 người - Năm 1985, Máy xạ trị Therac-25 của Canada do lỗi phần mềm mà phát ra tia gây chết người đã giết chết 3 người và làm 3 người khác bị thương nặng.
7 Luan van - Vào tháng Tư năm 1999, một lỗi phần mềm gây ra sự thất bại của một vụ phóng vệ tinh quân sự gây thiệt hại 1,2 tỷ USD, vụ tai nạn đắt đỏ nhất trong lịch sử. - 5/1996, Một lỗi phần mềm gây ra các tài khoản ngân hàng của 823 khách hàng của một ngân hàng lớn của Hoa Kỳ được ghi với 920 triệu đô la Mỹ. Chính vì vậy, việc kiểm thử phần mềm là vô cùng quan trọng vì lỗi phần mềm nếu để lọt thì ko chỉ thiệt hại về kinh tế mà còn thiệt hại đến tính mạng con người. Một số lý thuyết cơ bản về kiểm thử 1.Quy trình kiểm thử Phân tích yêu cầu :Trong giai đoạn này, test team nghiên cứu các yêu cầu từ quan điển của một nhân viên kiểm thử để xác định được những yêu cầu cần thực hiện kiểm thử.
QA team có thể tương tác với các bên liên quan khác (ví dụ như khách hàng, phân thích nghiệp vụ (BA), technical Leader.) để hiểu rõ các yêu cầu cụ thể. Các yêu cầu có thể là chức năng - Functional (xác định những gì phần mềm phải làm) hoặc không phải chức năng - Non functional ( như hiệu năng, tính bảo mật của hệ thống). Activities: - Xác định loại kiểm thử sẽ được thực hiện.