Đồ án: Kiểm thử ứng dụng trên nền Web bằng công cụ Selenium

Mục lục

Đánh giá post

Đồ án: Kiểm thử ứng dụng trên nền Web bằng công cụ Selenium. Bạn đang chuẩn bị làm bài báo cáo thực tập nghề nghiệp, hay bạn đang làm đồ án tốt nghiệp, nhưng các bạn lại chưa biết lựa chọn đề tài nào cho phù hợp với trường hợp của bạn, giờ đây các bạn không còn phải lo lắng về vấn đề đó nữa, vì dưới đây Dịch Vụ Hỗ Trợ Viết Luận Văn sẽ chia sẻ đến các bạn sinh viên một bài Đồ án: Kiểm thử ứng dụng trên nền Web bằng công cụ Selenium các bạn có thể tham khảo thử nhé.

MỞ ĐẦU

Ngày nay, công nghệ thông tin nói chung và công nghệ phần mềm nói riêng đang chiếm một vị trí quan trọng trong tiến trình công nghiệp hoá, hiện đại hoá đất nước. Song song với việc phát triển công nghệ phần mềm luôn tiềm ẩn những thách thức cho dành các doanh nghiệp, nhà phát triển phần mềm trong việc kiểm soát lỗi, chất lượng đầu ra của sản phẩm. Tuy nhiên ở Việt Nam, số lượng các kiểm thử viên vẫn chưa đáp ứng được với nhu cầu của thị trường. Tại Hội nghị Quốc tế về kiểm thử phần mềm tự động (12/2011, TP. HCM), các chuyên gia đã nhận định: “Với đà tăng trưởng mạnh mẽ của ngành gia công phần mềm, trong vài năm tới, Việt Nam thiếu khoảng 10.000 kiểm thử viên.” “Đồ án: Kiểm thử ứng dụng trên nền Web bằng công cụ Selenium”

Bên cạnh đó, xu hướng áp dụng tự động hoá đang được triển khai rộng rãi ở nhiều lĩnh vực, trong đó có kiểm thử phần mềm. Đặc biệt, khi kiểm thử phần mềm là công đoạn chiếm phần lớn thời gian trong quá trình phát triển dự án phần mềm thì sự ra đời của các công cụ kiểm thử tự động càng có ý nghĩa hơn bao giờ hết, giúp tiết kiệm thời gian, công sức và tiền bạc. Selenium là một công cụ hỗ trợ kiểm thử tự động dành cho các ứng dụng Web, hoạt động trên hầu hết các trình duyệt phổ biến hiện nay như Firefox, Chrome, Internet Explorer, Safari, v.v. cũng như hỗ trợ số lượng lớn các ngôn ngữ lập trình Web phổ biến. Công cụ Selenium hiện được đánh giá là một trong những công cụ tốt nhất cho kiểm thử tự động các ứng dụng Web.

Với mong muốn được tìm hiểu sâu về lĩnh vực kiểm thử phần mềm cũng như trở thành một kỹ sư kiểm thử phần mềm sau khi tốt nghiệp đại học, em đã chọn đề tài “Kiểm thử ứng dụng trên nền Web bằng công cụ Selenium.” Trong quá trình làm đồ án, do còn hạn chế về thời gian và kinh nghiệm thực tế, em mong nhận được những góp ý chân thành từ thầy cô và các bạn.

Đề tài giới thiệu về lý thuyết kiểm thử phần mềm, các công cụ hỗ trợ kiểm thử tự động. Ngoài ra, đề tài đi sâu vào việc tìm hiểu, sử dụng các tính năng, công cụ của bộ phần mềm Selenium như:

  • Đưa ra hướng dẫn cài đặt, sử dụng hiệu quả bộ công cụ.
  • Ứng dụng các kiến thức đã học được để viết một kịch bản kiểm thử cho ứng dụng cụ thể.

Đồ án được tổ chức làm 5 phần như sau:

  • Mở đầu: Trình bày rõ lý do chọn đề tài, mục tiêu nghiên cứu đồ án và bố cục của đồ án.
  • Chương 1: Phần mềm và kiểm thử phần mềm. Chương này trình bày các khái niệm cơ bản về phần mềm, kiểm thử phần mềm và các kỹ thuật kiểm thử phần mềm.
  • Chương 2: Kiểm thử ứng dụng trên nền Web. Chương này trình bày chi tiết các khái niệm về kiểm thử ứng dụng Web, các công việc khi kiểm thử ứng dụng Web, giới thiệu một số công cụ hỗ trợ kiểm thử ứng dụng web.
  • Chương 3: Kiểm thử ứng dụng trên nền Web bằng công cụ Selenium.
  • Giới thiệu chung về Selenium, các cài đặt và sử dụng bộ công cụ, ứng dụng thực tế với Selenium.

Kết luận: Phần này đưa ra những kết quả đồ án đạt được, những thiếu sót chưa thực hiện được và hướng phát triển đề tài trong tương lai.

Chương đầu tiên của đồ án đi sâu vào việc tìm hiểu các khái niệm về phần mềm và kiểm thử phần mềm, giúp khái quát việc phân loại kiểm thử phần mềm, đưa ra các quy trình, mức độ, các kỹ thuật trong kiểm thử phần mềm.

CÓ THỂ BẠN QUAN TÂM ĐẾN DỊCH VỤ:

===>>> Viết Thuê Đồ Án Tốt Nghiệp

1.1. Phần mềm và khái niệm liên quan “Đồ án: Kiểm thử ứng dụng trên nền Web bằng công cụ Selenium”

1.1.1. Phần mềm

Phần mềm thường được mô tả với ba bộ phận cấu thành:

Tập các lệnh (chương trình máy tính) trên máy tính khi được thực hiện sẽ tạo ra các dịch vụ và đem lại những kết quả mong muốn cho người dùng.

Các cấu trúc dữ liệu (lưu giữ trên các bộ nhớ) làm cho chương trình thao tác hiệu quả với các thông tin thích hợp và nội dung thông tin được số hoá.

Các tài liệu để mô tả các thao tác, cách sử dụng và bảo trì phần mềm (hướng dẫn sử dụng, tài liệu kỹ thuật, tài liệu phân tích, thiết kế, kiểm thử, v.v.) [1].

1.1.2. Lỗi phần mềm “Đồ án: Kiểm thử ứng dụng trên nền Web bằng công cụ Selenium”

Lỗi phần mềm nhìn chung là sự không khớp giữa chương trình và đặc tả của nó, kéo theo những vấn đề xuất hiện trong các giai đoạn phát triển phần mềm.

Lỗi phần mềm thường xuất hiện ở các hình thức sau đây:

Sai (Fault): Khi phần mềm gặp lỗi sẽ đưa đến những sai sót. Tuy nhiên, không dễ để phát hiện ra sai sót trong quá trình phát triển phần mềm. Sai lầm có thể xuất hiện ở ngay đầu quy trình phát triển phần mềm khi người phân tích, thiết kế bỏ sót thông tin dẫn tới thiếu chức năng mà lẽ ra cần phải có.

Thất bại (Failure): Thất bại dễ nhận thấy nhất khi một lỗi được thực thi.

Chúng thường xuất hiện dưới 2 dạng: thất bại có thể chạy được (ví dụ như mã nguồn) và thất bại chỉ liên kết với các lỗi về nhiệm vụ. Ngoài ra, có thể kể đến các thất bại liên quan tới các lỗi do bỏ quên. Chúng ta có thể hạn chế thất bại ngay tại bước đầu tiên của quy trình phát triển phần mềm nếu việc khảo sát được thực hiện tốt.

Sự cố (Incident): Sự cố thường được liên kết với một thất bại. Tuy nhiên nó khác với thất bại ở chỗ sự cố luôn hiển thị cho người dùng hoặc kiểm thử viên biết về sự tồn tại của nó.

Thừa: 1 số chức năng không có trong bản đặc tả yêu cầu phần mềm nhưng lại xuất hiện trong phần mềm được xây dựng.

Ngoài ra, còn xuất hiện 1 số lỗi phi chức năng như phần mềm khó sử dụng, tốc độ không đáp ứng yêu cầu (vấn đề hiệu năng) hay giao diện khó nhìn cũng dễ khiến cho người sử dụng nghĩ rằng phần mềm đang hoạt động không đúng.

1.1.3. Yêu cầu của khách hàng

Phần mềm được phát triển dựa trên nhu cầu của khách hàng. Chính vì lẽ đó, các chức năng của phần mềm được xây dựng dựa trên việc thu thập, phân tích, khảo sát nhu cầu của khách hàng thông qua những yêu cầu cụ thể. Đối với phần mềm, yêu cầu thường được tổng hợp từ nhiều người, nhiều tổ chức có mức độ chuyên môn và mức độ tham gia cũng như tương tác với phần mềm khác nhau trong môi trường hoạt động của nó. “Đồ án: Kiểm thử ứng dụng trên nền Web bằng công cụ Selenium”

Có thể phân loại yêu cầu của khách hàng cho sản phẩm phần mềm thành một số loại như sau:

Phân loại theo sản phẩm và tiến trình

Yêu cầu sản phẩm: là những đòi hỏi hay ràng buộc mà phần mềm phải thực hiện [2].

Yêu cầu tiến trình: là những ràng buộc liên quan đến việc phát triển phần mềm (kĩ thuật sử dụng, mô hình phát triển, v.v.) [2].

Ví dụ: Khách hàng muốn phát triển một website làm bài thi trực tuyến. Lúc này, yêu cầu sản phẩm là xây dựng website thi trực tuyến với các tính năng như quản lý câu hỏi; quản lý đề thi; cho phép người dùng có thể tham gia làm bài thi; quản trị viên có thể duyệt các câu hỏi và bộ đề thi trước khi đăng lên website. Việc website được phát triển theo mô hình Agile hay mô hình thác nước chính là yêu cầu tiến trình của sản phẩm phần mềm.

Phân loại theo chức năng

Yêu cầu chức năng: đặc tả các chức năng mà phần mềm cần phải thực hiện.

Yêu cầu phi chức năng: là các ràng buộc về giải pháp và chất lượng (hiệu năng, việc bảo trì, mức độ an toàn, bảo mật, v.v.).

Yêu cầu đặc tả các thuộc tính nổi bật: là đặc tả cho các thuộc tính phụ thuộc vào sự vận hành, đặc biệt là kiến trúc hệ thống. Các thuộc tính này không thể xác định được cho từng thành phần đơn lẻ.

Phân loại theo tính kiểm định

Những yêu cầu mang tính mơ hồ, không thể kiểm định

Những yêu cầu đã rõ ràng và có thể kiểm định được.

Phân loại theo phạm vi đặc tả

Yêu cầu hệ thống: đặc tả các cấu hình, cơ sở hạ tầng, phần cứng, phần mềm, con người, kỹ thuật, v.v. của toàn bộ hệ thống.

Yêu cầu phần mềm: đặc tả các chức năng, giao diện, v.v. của các cấu phần phần mềm.

1.1.4. Đặc tả yêu cầu phần mềm “Đồ án: Kiểm thử ứng dụng trên nền Web bằng công cụ Selenium”

Từ yêu cầu của khách hàng và những yêu cầu bắt buộc khác, đặc tả yêu cầu phần mềm được viết ra để mô tả một cách chính xác các yêu cầu cần đáp ứng của sản phẩm phần mềm. Đây cũng chính là tài liệu cơ sở để lập trình viên, kiểm thử viên và các bộ phận khác dựa vào để phát triển phần mềm hoàn chỉnh, đúng với yêu cầu đặt ra ban đầu. Các khái niệm về lỗi đã nói ở mục 1.1.2 cũng chính là đề cập đến việc phần mềm sau khi xây dựng hoạt động không đúng với bản đặc tả yêu cầu phần mềm. Tài liệu đặc tả yêu cầu phần mềm cũng cần cung cấp đầy đủ các thông tin về chi phí, rủi ro và lịch trình cho quá trình phát triển sản phẩm.

Đặc tả yêu cầu phần mềm được viết ra phục vụ rất nhiều đối tượng từ người dùng hệ thống, khách hàng đến các nhà phát triển và bảo trì phần mềm. Do đó, tài liệu đặc tả nên được viết bằng ngôn ngữ tự nhiên, sử dụng biểu đồ, bảng biểu để đảm bảo tính dễ hiểu, dễ sử dụng cho tất cả các đối tượng trên.

1.1.5. Chất lượng và độ tin cậy của phần mềm

Chất lượng của phần mềm trước hết là sự đáp ứng các yêu cầu đề ra trong bản đặc tả yêu cầu phần mềm. Có thể kể đến các yếu tố đại diện cho chất lượng phần mềm như: tính đúng đắn, tính hiệu quả, độ tin cậy, tính khả kiểm thử, dễ học, dễ sử dụng, dễ bảo trì… Ta có thể thấy độ tin cậy chỉ là một trong những yếu tố đánh giá chất lượng phần mềm. Tuy nhiên người kiểm thử lại hay nhầm lẫn giữa khái niệm chất lượng và độ tin cậy của phần mềm. Sau quá trình kiểm thử đảm bảo phần mềm có thể chạy ổn định, kiểm thử viên thường sẽ cho rằng phần mềm lúc này đã đạt chất lượng tốt.

Độ tin cậy của phần mềm là xác suất để phần mềm chạy không có thất bại trong một khoảng thời gian nhất định [3]. Ngoài ra, có thể dựa vào thời gian khắc phục sự cố để đánh giá độ tin cậy của phần mềm.

Trong phần tiếp theo, chúng ta sẽ tìm hiểu về khái niệm cũng như các vấn đề xung quanh việc Kiểm thử phần mềm.

1.2. Kiểm thử phần mềm “Đồ án: Kiểm thử ứng dụng trên nền Web bằng công cụ Selenium”

1.2.1. Khái niệm

Kiểm thử phần mề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ử [4]. Hiểu theo cách đơn giản hơn, kiểm thử phần mềm là quá trình tìm thất bại hoặc chứng tỏ việc tiến hành của phần mềm là đúng đắn.

1.2.2. Vai trò của kiểm thử phần mềm

Kiểm thử phần mềm chiếm một vị trí quan trọng trong việc nâng cao chất lượng cũng như độ tin cậy của phần mềm trong quá trình phát triển. Hoàn thành vòng quay “đưa lỗi vào – tìm lỗi – khử lỗi đi” của quy trình kiểm thử phần mềm sẽ thu lại được những cải tiến đáng kể cho chất lượng sản phẩm phần mềm. Việc biết được sản phẩm phần mềm tốt tới mức nào trước khi đưa vào sử dụng sẽ hạn chế tối đa những rủi ro gặp phải trong quá trình phát triển phần mềm.

1.2.3. Các cấp độ trong kiểm thử phần mềm “Đồ án: Kiểm thử ứng dụng trên nền Web bằng công cụ Selenium”

Có rất nhiều cách để chia cấp độ kiểm thử phần mềm, nhưng tựu chung lại sẽ gồm 4 cấp độ sau:

Kiểm thử đơn vị: Cấp độ này chủ yếu do lập trình viên trực tiếp thực hiện. Phần mềm khi phát triển sẽ bao gồm nhiều đơn vị chức năng (hàm, phương thức) hợp thành. Mỗi lập trình viên sẽ đảm nhiệm việc phát triển một hay nhiều đơn vị chức năng. Kiểm thử đơn vị chính là việc lập trình viên sau khi hoàn thành code đơn vị chức năng của mình sẽ tiến hành kiểm thử chức năng đó một cách cô lập nhằm phát hiện ra lỗi và khắc phục trước khi tích hợp với các đơn vị chức năng khác. Kiểm thử đơn vị thường được tiến hành theo 2 giai đoạn: kiểm thử đơn vị tĩnh và kiểm thử đơn vị động.

Kiểm thử tích hợp: Sau khi kiểm thử đơn vị được tiến hành bởi chính lập trình viên viết ra nó, các đơn vị chức năng sẽ được ghép lại với nhau để tạo thành hệ thống đầy đủ và có thể làm việc được. Các đơn vị chức năng hoạt động tốt khi ở trạng thái độc lập riêng rẽ, nhưng khi ghép lại sẽ có thể xuất hiện những lỗi về giao diện hoặc cho ra kết quả không đúng khi phải sử dụng dữ liệu từ những đơn vị chức năng khác. Đó chính là lý do tại sao phải tiếp tục kiểm thử để phát hiện ra những lỗi kể trên. Người ta thường chia bước kế tiếp này thành 2 giai đoạn: kiểm thử tích hợp và kiểm thử hệ thống. Ở mức kiểm thử tích hợp, các đơn vị chức năng được kết hợp lại với nhau và tiến hành kiểm thử chúng theo phương pháp tăng dần để đảm bảo cụm các đơn vị chức năng sẽ làm việc ổn định trong môi trường thử nghiệm.

Kiểm thử hệ thống: Sau khi tất cả các đơn vị chức năng đã được tích hợp lại với nhau tạo thành một hệ thống hoàn chỉnh, kiểm thử hệ thống sẽ được thực thi để đảm bảo sản phẩm phần mềm đáp ứng đầy đủ các yêu cầu trong bản đặc tả yêu cầu phần mềm. Đây là công việc tốn nhiều công sức nhất trong quá trình kiểm thử phần mềm. Đồng thời cũng sử dụng nhiều kỹ thuật kiểm thử khác nhau như: kiểm thử giao diện người dùng, kiểm thử chức năng, kiểm thử hiệu năng, kiểm thử tính dễ dùng, v.v. để hoàn tất công việc kiểm thử trong cấp độ này. “Đồ án: Kiểm thử ứng dụng trên nền Web bằng công cụ Selenium”

Kiểm thử chấp nhận: Khi kiểm thử hệ thống hoàn tất, sản phẩm phần mềm được coi như đã sẵn sàng cho việc đưa vào sử dụng thực tế. Lúc này, phần mềm cần được tiến hành cấp độ kiểm thử cuối cùng – kiểm thử chấp nhận bởi chính khách hàng hay người sử dụng phần mềm. Tuy có phần tương tự như kiểm thử hệ thống nhưng mục đích chính của kiểm thử chấp nhận là quyết định việc đưa vào sử dụng chính thức sản phẩm phần mềm. Người ta dựa trên các số liệu thống kê thực tế về chất lượng, độ tin cậy của phần mềm để quyết định triển khai cho người dùng cuối. Kiểm thử chấp nhận thường được thực hiện dưới hình thức cho một nhóm người dùng thử sản phẩm phần mềm để phát hiện các lỗi và nhận phản hồi từ người dùng. Trong đó, phiên bản alpha dành cho đội phát triển phần mềm và phiên bản beta được cung cấp cho người sử dụng thật để đưa ra đánh giá trong môi trường thực tế. Ở thời điểm hiện tại, kiểm thử chấp nhận được coi là cấp độ quy chuẩn bắt buộc không thể thiếu trong quy trình phát triển của nhiều sản phẩm phần mềm.

1.2.4. Quy trình kiểm thử phần mềm

Kiểm thử phần mềm bao gồm nhiều giai đoạn với sự phối hợp của nhiều bên liên quan chứ không chỉ là một hoạt động đơn lẻ. Chính vì thế, cần có quy trình kiểm thử phần mềm để làm rõ các công đoạn, các bước kiểm thử, người chịu trách nhiệm và khi nào việc kiểm thử được tiến hành trong toàn bộ quy trình phát triển phần mềm. Nói cách khác, quy trình kiểm thử phần mềm chính là chuỗi các hoạt động được tiến hành để thực hiện việc kiểm thử. Các giai đoạn trong quy trình kiểm thử phần mềm được biểu diễn tổng quát bằng sơ đồ sau:

Phân tích yêu cầu: Nhóm kiểm thử sẽ tương tác với các bên liên quan để hiểu rõ những yêu cầu cụ thể cần cho việc kiểm thử. Các yêu cầu có thể là chức năng (xác định phần mềm cần phải làm những gì) hoặc phi chức năng (hiệu năng, tính bảo mật hệ thống, màu sắc, v.v.) “Đồ án: Kiểm thử ứng dụng trên nền Web bằng công cụ Selenium”

Hoạt động cụ thể:

  • Xác định loại kiểm thử sẽ thực hiện.
  • Tổng hợp chi tiết về và mức độ tập trung thứ tự ưu tiên.
  • Chuẩn bị RTM (Requirement Traceability Matrix – một tài liệu dưới dạng bảng sử dụng để theo dõi các yêu cầu của khách hàng và kiểm tra xem các yêu cầu này đã được đáp ứng đầy đủ hay chưa)
  • Xác định môi trường kiểm thử.
  • Phân tích khả năng sử dụng kiểm thử tự động.

Tài liệu sử dụng:

Báo cáo về khả năng sử dụng kiểm thử tự động (nếu cần).

Lên kế hoạch kiểm thử: Còn được gọi bằng tên khác là lên chiến lược thử nghiệm. Ở giai đoạn này, trưởng nhóm kiểm thử sẽ dự toán chi phí cho dự án cũng như chuẩn bị kế hoạch kiểm thử.

Hoạt động cụ thể:

  • Lựa chọn công cụ kiểm thử (test tool).
  • Lên kế hoạch về nhân sự và ấn định vai trò trách nhiệm cho từng người trong nhóm.
  • Phổ biến cho mọi người trong nhóm kiểm thử về yêu cầu dự án.

Tài liệu sử dụng:

Bản kế hoạch kiểm thử.

Tạo ca kiểm thử: Giai đoạn này cần phải tạo, xác minh, kiểm tra lại các ca kiểm thử. Dữ liệu kiểm thử cũng được tạo và xác định trong giai đoạn này. “Đồ án: Kiểm thử ứng dụng trên nền Web bằng công cụ Selenium”

Hoạt động cụ thể:

  • Tạo ca kiểm thử.
  • Xác minh, kiểm tra lại các ca kiểm thử.
  • Tạo dữ liệu kiểm thử.

Tài liệu sử dụng:

  • Ca kiểm thử.
  • Dữ liệu kiểm thử.

Cài đặt môi trường kiểm thử: Môi trường kiểm thử quyết định bởi các điều kiện phần cứng và phần mềm trong từng dự án. Thiết lập môi trường kiểm thử có thể thực hiện song song với giai đoạn sinh ca kiểm thử và là một tiêu chí quan trọng trong quá trình kiểm thử. Tuy nhiên, nhóm kiểm thử có thể không cần tham gia vào giai đoạn này nếu đã có các bên liên quan khác hỗ trợ, nhiệm vụ của nhóm kiểm thử chỉ là yêu cầu môi trường kiểm thử cần thiết.

Hoạt động cụ thể:

Hiểu được kiến trúc yêu cầu, thiết lập môi trường và chuẩn bị danh sách yêu cầu về phần cứng và phần mềm cho môi trường thử nghiệm.

Thiết lập môi trường kiểm thử.

Thực hiện kiểm thử: Nhóm kiểm thử thực hiện kiểm thử theo kế hoạch và danh sách ca kiểm thử đã chuẩn bị từ giai đoạn trước. Các lỗi phát hiện ở giai đoạn này sẽ được thông báo lại cho nhóm phát triển phần mềm để chỉnh sửa và thực hiện kiểm thử lại. “Đồ án: Kiểm thử ứng dụng trên nền Web bằng công cụ Selenium”

Hoạt động cụ thể:

  • Thực hiện kiểm thử theo kế hoạch.
  • Làm tài liệu về kết quả kiểm thử, cập nhật lại các lỗi trong ca kiểm thử.
  • Kiểm thử lại các lỗi đã được chỉnh sửa.
  • Kiểm tra để đóng lỗi.

Tài liệu sử dụng:

  • Ca kiểm thử (cập nhật kết quả).
  • Báo cáo lỗi.

Đóng chu trình kiểm thử: Nhóm kiểm thử sẽ họp, thảo luận và phân tích những bài học rút ra sau quá trình kiểm thử, đưa ra chiến lược cho những lần kiểm thử kế tiếp hoặc chia sẻ kinh nghiệm cho những dự án tương tự.

Hoạt động cụ thể:

  • Đánh giá việc hoàn thành quy trình kiểm thử dựa vào thời gian, mức độ bao phủ, chi phí và chất lượng.
  • Chuẩn bị dữ liệu dựa trên các tiêu chí trên.
  • Chuẩn bị báo cáo kết thúc kiểm thử.
  • Báo cáo chất lượng sản phẩm cho khách hàng.
  • Phân tích kết quả kiểm thử để tìm ra sự phân bố lỗi theo loại và mức độ nghiêm trọng.

Tài liệu sử dụng:

Báo cáo kết thúc kiểm thử.

1.2.5. Phân loại kiểm thử phần mềm “Đồ án: Kiểm thử ứng dụng trên nền Web bằng công cụ Selenium”

Có 2 cách cơ bản để xác định các ca kiểm thử là kiểm thử tĩnh và kiểm thử động.

Kiểm thử tĩnh: là một hình thức của kiểm thử phần mềm mà không cần thực thi chương trình. Điều này ngược với thử nghiệm động. Công việc chủ yếu là kiểm tra tính đúng đắn của mã lệnh, thuật toán hay tài liệu. Đây là loại kiểm thử được thực hiện bởi lập trình viên. Lỗi được phát hiện bằng kiểm thử tĩnh ít tốn kém để sửa chữa hơn so với lỗi phát hiện bằng kiểm thử động sẽ được đề cập dưới đây. Các lập trình viên có thể trao đổi mã nguồn chéo nhau hoặc làm việc một cách độc lập để thực hiện kiểm thử tĩnh.

Kiểm thử động: Liên quan đến việc thực thi chương trình để phát hiện các lỗi, thất bại có thể có của chương trình hay tìm ra các vấn đề về hiệu năng hệ thống. Việc thực thi chương trình trên tất cả các dữ liệu đầu vào là không thể nên ta chỉ có thể chọn một tập con các dữ liệu đầu vào để thực thi hay nói cách khác là sinh ra các ca kiểm thử. Trong kiểm thử động, người ta chia làm 2 kỹ thuật: kiểm thử hộp trắng (kiểm thử cấu trúc) và kiểm thử hộp đen (kiểm thử chức năng).

Kiểm thử hộp trắng: là kỹ thuật kiểm thử dựa vào thuật toán, cấu trúc mã nguồn bên trong của chương trình với mục đích đảm bảo rằng tất cả các câu lệnh và điều kiện sẽ được thực hiện ít nhất một lần.

Người kiểm thử truy cập vào mã nguồn chương trình và kiểm tra nó, lấy đó làm cơ sở để thực hiện việc kiểm thử. Kiểm thử hộp trắng bao gồm các công việc cơ bản: Kiểm thử đường dẫn, kiểm thử luồng điều khiển, kiểm thử nội bộ (xác nhận các tham số, vòng lặp), kiểm thử tính năng (kiểm tra thời gian xử lý, dữ liệu cụ thể). Tuy nhiên, việc kiểm thử hộp trắng tồn tại khá nhiều hạn chế như: không thể đảm bảo rằng chương trình đã tuân theo đặc tả, khó phát hiện được các lỗi do dữ liệu, thiếu đường dẫn, v.v. Như vậy, không thể chỉ sử dụng kiểm thử hộp trắng để kiểm thử chương trình. “Đồ án: Kiểm thử ứng dụng trên nền Web bằng công cụ Selenium”

Kiểm thử hộp đen: Là kỹ thuật kiểm thử dựa trên đầu vào và đầu ra của chương trình mà không quan tâm tới mã nguồn bên trong được viết ra sao. Với kỹ thuật này, kiểm thử viên xem phần mềm như là một hộp đen. Để thực hiện, kiểm thử viên sẽ xây dựng các nhóm giá trị đầu vào sao cho chúng có thể thực hiện đầy đủ các chức năng cần có của chương trình. Kiểm thử hộp đen sử dụng các phương pháp: phân tích giá trị biên, kiểm thử tính bền vững, kiểm thử trường hợp xấu nhất, kiểm thử phân lớp tương đương miền dữ liệu đầu vào, đầu ra, kiểm thử giá trị đặc biệt, kiểm thử dựa trên bảng quyết định. Tất cả các phương pháp trên đều dựa trên thông tin xác định về các thành phần đang được kiểm thử.

Cho tới nay, việc xác định kỹ thuật kiểm thử nào là tốt hơn trong 2 kỹ thuật: kiểm thử hộp đen và kiểm thử hộp trắng vẫn còn là một dấu hỏi lớn. Biểu đồ Venn sau đây sẽ giúp hình dung khái quát về mối liên hệ giữa kiểm thử hộp đen và kiểm thử hộp trắng trong thực tế kiểm thử hiện nay.

Trước hết cần khẳng định mục đích của hai kỹ thuật trên đều là để xác định ca kiểm thử. Trong khi kiểm thử hộp trắng chỉ dùng đặc tả để xác định ca kiểm thử, thì kiểm thử hộp đen lại dùng mã nguồn chương trình để làm cơ sở xác định ca kiểm thử. Trong phần trình bày chi tiết về hai kỹ thuật đã nói ở trên đều cho thấy không có kỹ thuật nào là đủ tốt hoàn toàn. Cụ thể: Nếu tất cả các hành vi được nêu trong bản đặc tả yêu cầu phần mềm vẫn chưa được cài đặt thì kiểm thử hộp trắng sẽ không thể nhận biết được điều đó. Hay nếu các hành vi đã được cài đặt trong chương trình nhưng lại chưa có trong bản đặc tả yêu cầu phần mềm, kiểm thử hộp đen dường như bất lực trong trường hợp này. Qua biểu đồ Venn, ta có thể khẳng định: việc kết hợp khéo léo cả hai kỹ thuật kiểm thử trên sẽ đem lại một kết quả tốt nhất trong kiểm thử phần mềm. Thực hiện song song kiểm thử hộp đen và kiểm thử hộp trắng sẽ hạn chế tối đa các khiếm khuyết có thể bị bỏ sót. Tuy nhiên, nếu biết được loại lỗi nào hay mắc phải hoặc những sai lầm thường thấy trong dự án đang được triển khai, ta hoàn toàn có thể chọn kỹ thuật kiểm thử thích hợp cho từng ca kiểm thử. Kinh nghiệm của kiểm thử viên sẽ được phát huy trong những trường hợp này.

1.2.6. Các mức độ nghiêm trọng của lỗi

Chương trình một khi đã xuất hiện lỗi đều kéo theo những hệ luỵ nghiêm trọng. Một trong những cách phân loại mức độ nghiêm trọng của lỗi thường được sử dụng là dựa trên tần suất xuất hiện: chỉ một lần, thỉnh thoảng, xuất hiện lại hay lặp đi lặp lại nhiều lần. Việc phân loại mức độ nghiêm trọng của lỗi sẽ giúp kiểm thử viên cũng như lập trình viên ý thức được đâu là lỗi cần được giải quyết trước, nhằm giảm thiểu tối đa những tổn thất về chi phí và nâng cao chất lượng cho sản phẩm phần mềm. Hình 1.6 dưới đây minh hoạ các mức độ nghiêm trọng của lỗi dựa trên độ nghiêm trọng và hậu quả.

1.2.7. Ca kiểm thử “Đồ án: Kiểm thử ứng dụng trên nền Web bằng công cụ Selenium”

Ca kiểm thử là một khái niệm không thể thiếu trong kiểm thử phần mềm. Theo ISTQB “ca kiểm thử là một tập hợp các giá trị đầu vào, tiền điều kiện, các kết quả mong đợi và điều kiện kết thúc, được xây dựng cho mục đích hoặc điều kiện kiểm thử riêng biệt để kiểm tra tính đúng đắn của chương trình với yêu cầu của bản đặc tả yêu cầu phần mềm” [5]. Hay nói cách khác, ca kiểm thử mô tả dữ liệu bao gồm: đầu vào, hành động hoặc sự kiện và kết quả đầu ra mong đợi (expected results) để xác định liệu 1 ứng dụng, hệ thống phần mềm hoặc một trong các tính năng của nó có hoạt động đúng như mong muốn hay không.

Cấu trúc của một ca kiểm thử thông thường bao gồm:

  • Test case ID: Xác định số lượng trường hợp cần kiểm thử.
  • Function (Chức năng): Các function có thể được chia nhỏ dựa theo chức năng của hệ thống nhằm giúp ca kiểm thử trở nên rõ ràng hơn.
  • Pre-condition: Điều kiện đầu vào của ca kiểm thử, ví dụ như khi thực hiện kiểm thử form đăng nhập, pre-condition sẽ là form đăng nhập phải được hiển thị ra.
  • Test Data: Dữ liệu đầu vào cần chuẩn bị trước khi kiểm thử.
  • Test Steps: Mô tả chi tiết các bước thực hiện kiểm thử.
  • Expected Results: Kết quả mong đợi sau khi thực hiện các bước kiểm thử.
  • Actual result: Mô tả kết quả thực tế khi thực hiện kiểm thử trên môi trường của hệ thống. Actual result thường bao gồm ba giá trị: pass, fail và pending.
  • Comments: Có thể chứa screen shot hoặc thông tin liên quan khi thực hiện ca kiểm thử.

Ngoài ra có thể có thêm một số cột như: Designed by (người thực hiện kiểm thử), Execute Date (ngày thực hiện kiểm thử), v.v. Mức độ chi tiết của ca kiểm thử sẽ phụ thuộc vào từng dự án và quy mô của công ty sản xuất phần mềm.

  • Một ca kiểm thử được cho là hiệu quả khi:
  • Dựa vào ca kiểm thử có thể tìm thấy lỗi.
  • Tìm được nhiều lỗi khó phát hiện.
  • Chỉ ra được những điểm ban đầu mà khi thực hiện kiểm thử không tìm ra vấn đề.
  • Ca kiểm thử cần có những bước thực hiện kiểm thử (Test steps) đơn giản, minh bạch, dễ hiểu.
  • Các trường hợp thử nghiệm nên có giá trị, tóm tắt và ngắn.

Các ca kiểm thử nên có sự liên kết: Mỗi ca kiểm thử cần được đánh số thứ tự (Test case ID) để đảm bảo ca kiểm thử đã bao phủ 100% bản đặc tả yêu cầu phần mềm. “Đồ án: Kiểm thử ứng dụng trên nền Web bằng công cụ Selenium”

Ca kiểm thử có thể bảo trì: Nên viết ca kiểm thử sao cho khi có thay đổi, chỉnh sửa thì các bên liên quan có thể dễ dàng nhận thấy được sự thay đổi đó.

Ca kiểm thử có tính ứng dụng cao.

Tóm lại, ca kiểm thử được viết ra để kiểm tra hoạt động của các chức năng có đúng như mong muốn trong bản đặc tả yêu cầu phần mềm hay không. Khi viết ca kiểm thử nên cố gắng viết đơn giản, dễ hiểu nhưng phải đầy đủ các dữ liệu chuẩn cần có của một ca kiểm thử.

1.2.8. Kiểm thử tự động

Kiểm thử tự động là quá trình kiểm tra một hệ thống nào đó bằng các công cụ tự động hoá với dữ liệu đầu vào và đầu ra đã được xác định.

Công việc kiểm thử thường chiếm từ 11% – 40% chi phí cho quá trình phát triển phần mềm [6]. Hơn nữa, các dự án phần mềm đều mong muốn giảm chi phí về thời gian, nhân lực mà vẫn đem lại hiệu quả cao, chất lượng tốt. Đó chính là lý do kiểm thử tự động được áp dụng rộng rãi trong các quy trình phát triển phần mềm ngày nay.

Kiểm thử tự động đặc biệt phát huy tác dụng trong các trường hợp kiểm thử lặp đi lặp lại, kiểm thử hồi quy hay các ca kiểm thử có giá trị dữ liệu đầu vào rất lớn khiến cho việc kiểm thử thủ công gặp nhiều khó khăn. Đối với các trường hợp kiểm thử lặp đi lặp lại, nếu thực hiện thủ công sẽ gây ra sự nhàm chán cho người kiểm thử, dẫn tới năng suất lao động kém. Đó là chưa kể tới việc lặp đi lặp lại quy trình một cách thủ công hoàn toàn có thể dẫn tới sai sót. Ngược lại, nếu thay bằng kiểm thử tự động, dù có lặp đi lặp lai bao nhiêu lần thì cũng cho ra thao tác và kết quả chính xác. Điều này giúp chúng ta tránh được những rủi ro không đáng có và giảm đáng kể thời gian cho việc kiểm thử. “Đồ án: Kiểm thử ứng dụng trên nền Web bằng công cụ Selenium”

Một số công cụ kiểm thử tự động phổ biến hiện nay:

Selenium: Công cụ kiểm thử phần mềm mã nguồn mở hỗ trợ kiểm thử tự động cho các ứng dụng Web. Selenium cung cấp chức năng ghi tự động và phát lại, hỗ trợ hữu ích cho kiểm thử hồi quy. Điểm mạnh của Selenium là hỗ trợ nhiều nền tảng khác nhau, tích hợp vào các trình duyệt phổ biến hiện nay, có thể thực hiện nhiều ca kiểm thử cùng lúc, có khả năng lưu các ca kiểm thử để sử dụng lại khi cần và cho phép người dùng chèn chú thích ở giữa kịch bản kiểm thử để hiểu rõ hơn nội dung kiểm thử. Selenium cũng hỗ trợ một lượng lớn các ngôn ngữ lập trình Web phổ biến hiện nay như C#, Java, Perl, PHP, Python, Ruby, v.v. Selenium có thể kết hợp với một số công cụ khác như Bromien và Junit nhưng với người dùng thông thường chỉ cần chạy tự động mà không cần cài thêm các công cụ hỗ trợ. Selenium hiện nay đang được cộng đồng đánh giá là một trong những công cụ tốt nhất cho kiểm thử tự động các ứng dụng Web.

QTP (HP UFT): Được sử dụng rộng rãi để kiểm thử chức năng và hồi quy. QTP sử dụng khái niệm kiểm thử từ khoá để đơn giản hoá việc tạo và bảo trì ca kiểm thử. Công cụ này hỗ trợ môi trường. NET và có cơ chế xác định đối tượng kiểm thử tốt. Đối với những kiểm thử viên không theo ngành kỹ thuật vẫn có thể sử dụng dễ dàng công cụ này.

Rational Function Tester: Là 1 công cụ kiểm tra tự động hướng đối tượng có khả năng tự động kiểm tra dữ liệu, kiểm tra giao diện, và kiểm thử hồi quy. Rational Function Tester hỗ trợ rất nhiều giao thức và ứng dụng như Java, HTML, .NET, Windows, Visual Basic, v.v. Công cụ này cũng hỗ trợ ghi và phát lại các hành động theo yêu cầu. Nó cho phép các nhà phát triển tạo ra các kịch bản liên quan đến từ khóa để có thể được tái sử dụng. Bộ biên tập Công cụ Java Developer Toolkit của Eclipse tạo điều kiện cho kiểm thử viên tạo mã thử nghiệm các đoạn mã trong Java với Eclipse.

WATIR: Là một phần mềm kiểm tra mã nguồn mở để kiểm thử hồi quy. Watir hỗ trợ nhiều trình duyệt trên nhiều nền tảng khác nhau. “Đồ án: Kiểm thử ứng dụng trên nền Web bằng công cụ Selenium”

Đồng thời cũng sử dụng một ngôn ngữ kịch bản hiện đại có đầy đủ các tính năng. Điểm mạnh của Watir là hỗ trợ ứng dụng Web được viết bởi bất kỳ ngôn ngữ nào.

SilkTest: Silk Test được thiết kế để thực hiện kiểm thử chức năng và hồi quy. Nó là một ngôn ngữ hướng đối tượng giống như C++. SilkTest sử dụng các khái niệm về đối tượng, các class và sự kế thừa. Nó chuyển đổi các lệnh script thành các lệnh GUI. Trên cùng một máy, các lệnh có thể được chạy trên một máy từ xa hoặc máy chủ. Silktest có thể xác định chuyển động của con chuột cùng với các phím bấm. Nó có thể sử dụng cả phương pháp ghi và phát lại hoặc các phương pháp lập trình mô tả.

Dù có rất nhiều ưu điểm về mặt thời gian thực thi nhưng kiểm thử tự động cũng không thể thay thế hoàn toàn quá trình kiểm thử của con người. Để thực hiện kiểm thử tự động, trước hết vẫn cần bàn tay con người thiết lập thao tác cho công cụ hay các đoạn kịch bản máy tính để thực thi. Đối với những ca kiểm thử chỉ thực hiện số ít lần thì việc mất thời gian tạo kịch bản kiểm thử tự động là không cần thiết. Chưa kể tới những ca kiểm thử với đặc thù riêng biệt mà kiểm thử tự động không làm được. Thêm vào đó, không phải công cụ kiểm thử tự động nào cũng miễn phí và dễ sử dụng hay đưa vào triển khai rộng rãi.

1.2.9. Nguyên tắc quan trọng trong kiểm thử phần mềm

Có thể hiểu nguyên tắc là những quy định mà chúng ta phải tuân theo. Trong kiểm thử phần mềm, việc theo đuổi những nguyên tắc là điều cần thiết giúp chúng ta phát triển hệ thống một cách tốt nhất. Người ta đưa ra 7 nguyên tắc kiểm thử quan trọng có thể dựa vào chúng để tiết kiệm thời gian, công sức và chi phí phát triển [5]. Cụ thể:

Kiểm thử chỉ ra lỗi: Kiểm thử có thể phát hiện ra lỗi của phần mềm, nhưng lại không thể chứng minh phần mềm hoàn toàn không có lỗi. Thực tế cho thấy, ngay cả khi kiểm thử một cách nghiêm ngặt phần mềm vẫn có thể xuất hiện lỗi. Vì vậy, cần phải tìm được ra càng nhiều lỗi càng tốt. “Đồ án: Kiểm thử ứng dụng trên nền Web bằng công cụ Selenium”

Kiểm thử cạn kiệt là không thể: Đó chính là việc chúng ta không thể kiểm tra với mọi dữ liệu đầu vào, đầu ra với toàn bộ các kịch bản của một phần mềm. Hay nói cách khác, kiểm tra mọi thứ trong chương trình một cách trọn vẹn là điều không thể làm được. Tuy nhiên, có thể phân tích rủi ro và dựa trên mức độ ưu tiên thông qua các mức độ nghiêm trọng của lỗi phần mềm để kiểm thử một số chức năng chính, thiết yếu của phần mềm.

Kiểm thử càng sớm càng tốt: Chi phí cho việc khắc phục, sửa lỗi sẽ tỷ lệ thuận với thời gian phát hiện ra lỗi đó. Không ít phần mềm khi chuẩn bị giao cho khách hàng mới phát hiện ra lỗi xuất hiện ngay từ bản đặc tả yêu cầu phần mềm hay bản phân tích thiết kế hệ thống. Điều này gây ra những thiệt hại không nhỏ cho quá trình phát triển phần mềm. Vì vậy, kiểm thử phần mềm ngay từ những giai đoạn đầu của quy trình phát triển là điều hết sức cần thiết.

Xác định vị trí tập trung lỗi: Lỗi thường tập trung nhiều ở những chức năng chính của phần mềm. Do đó, tập trung tìm ra lỗi ở những chức năng này sẽ giúp giảm thiểu thời gian kiểm thử. Đây là một trong những cách cơ bản và hiệu quả nhất trong kiểm thử phần mềm.

Nghịch lý thuốc trừ sâu: Dữ liệu của một hệ thống thay đổi liên tục và thường xuyên xuất hiện những hành vi mới từ phía người dùng. Nó giống như việc sử dụng một loại thuốc trừ sâu trong nhiều mùa vụ mà không để ý tới sự phát triển đa dạng của sâu bọ. Vì vậy, nếu giữ nguyên ca kiểm thử cũ trong thời gian dài, chúng ta không thể tìm ra lỗi mới phát sinh. Việc xem xét và thay đổi các ca kiểm thử thường xuyên là điều cần thiết.

Kiểm thử phụ thuộc vào ngữ cảnh: Nguyên tắc này đề cập tới việc tiếp cận kiểm thử theo nhiều ngữ cảnh khác nhau. Điển hình như việc kiểm thử ứng dụng Web và kiểm thử trên thiết bị di động không thể dùng chung một chiến lược kiểm thử. Mỗi môi trường kiểm thử sẽ có những đặc trưng riêng và đó là lý do tại sao cần xác định việc kiểm thử theo ngữ cảnh cho phù hợp.

Phần mềm có lỗi bằng 0: Việc không tìm thấy lỗi không có nghĩa là không tồn tại lỗi trong phần mềm. Chúng ta chỉ có thể hạn chế tối đa lỗi có thể gặp phải chứ không thể triệt tiêu toàn bộ lỗi có thể gặp phải.

Dựa theo 7 nguyên tắc trên đây giúp chúng ta có cái nhìn tổng quát về kiểm thử phần mềm cũng như đánh giá được tính hiệu quả của hoạt động kiểm thử đang triển khai.

1.3.Các kỹ thuật xác định ca kiểm thử “Đồ án: Kiểm thử ứng dụng trên nền Web bằng công cụ Selenium”

Trong quá trình kiểm thử phần mềm sẽ nảy sinh vô số trường hợp cần phải xét tới. Tuy nhiên, vì yếu tố chi phí, thời gian phát triển dự án nên người kiểm thử không thể tiến hành kiểm thử hết toàn bộ các giá trị đầu vào (Input). Lúc này, việc xác định tập các ca kiểm thử đặc trưng sẽ xây dựng sao cho có thể bao phủ được tối đa các trường hợp là điều vô cùng cần thiết. Phần này của đồ án sẽ đề cập tới một số kỹ thuật xác định ca kiểm thử nhằm giải quyết vấn đề kể trên.

1.3.1. Kỹ thuật phân vùng tương đương

  • Kỹ thuật phân vùng tương đương có đặc điểm là:
  • Chia miền dữ liệu đầu vào của một chương trình thành các vùng dữ liệu tương đương nhau.
  • Tất cả các giá trị trong một vùng tương đương sẽ cho ra kết quả đầu ra giống nhau.
  • Có thể chọn ra một giá trị đại diện trong một vùng tương đương để tiến hành kiểm thử.

Việc thiết kế ca kiểm thử bằng kỹ thuật phân lớp tương đương dựa trên nguyên tắc xác định số vùng tương đương hợp lệsố vùng tương đương không hợp lệ.

Ví dụ, trường hợp kiểm thử một ô textbox chỉ cho phép nhập vào số ký tự trong khoảng [5 – 30]. Áp dụng nguyên tắc xác định số vùng tương đương ta sẽ có các ca kiểm thử sau:

  • Nhập vào một giá trị trong vùng tương đương không hợp lệ thứ nhất: Nhập 4 ký tự.
  • Nhập vào một giá trị trong vùng tương đương hợp lệ: Nhập 6 ký tự.
  • Nhập vào một giá trị trong vùng tương đương không hợp lệ thứ hai: Nhập 31 ký tự.

Như vậy với kỹ thuật trên, kiểm thử viên đã rút ngắn được số ca kiểm thử cần sinh ra so với việc phải kiểm thử toàn bộ các giá trị đầu vào.

1.3.2. Kỹ thuật phân tích giá trị biên “Đồ án: Kiểm thử ứng dụng trên nền Web bằng công cụ Selenium”

Phân tích giá trị biên tập trung vào các giá trị tại biên của miền xác định để xây dựng ca kiểm thử. Mục đích là tìm ra lỗi có thể xảy ra ở gần các giá trị biên này. Phân tích giá trị biên chính là trường hợp đặc biệt của kỹ thuật phân vùng tương đương. Dựa trên những vùng giá trị tương đương, kiểm thử viên sẽ xác định giá trị biên giữa những vùng này và thiết kế ca kiểm thử phù hợp.

Với kỹ thuật phân tích giá trị biên, kiểm thử viên cần chú ý tới một số giá trị sau để sinh ca kiểm thử:

  • Giá trị nhỏ nhất.
  • Giá trị gần kề lớn hơn giá trị nhỏ nhất.
  • Giá trị gần kề nhỏ hơn giá trị nhỏ nhất.
  • Giá trị bình thường.
  • Giá trị gần kề nhỏ hơn giá trị lớn nhất
  • Giá trị lớn nhất.
  • Giá trị gần kề lớn hơn giá trị lớn nhất

Ví dụ: Kiểm thử một textbox nhập tuổi cho phép nhập giá trị số trong khoảng [0 – 150]. Vậy có thể sinh ra các ca kiểm thử cho trường hợp này theo kỹ thuật phân tích giá trị biên như sau:

  • Giá trị nhỏ nhất: 0
  • Giá trị gần kề lớn hơn giá trị nhỏ nhất: 1
  • Giá trị gần kề lớn hơn giá trị nhỏ nhất: -1
  • Giá trị bình thường: 70
  • Giá trị gần kề nhỏ hơn giá trị lớn nhất: 149
  • Giá trị lớn nhất: 150
  • Giá trị gần kề lớn hơn giá trị lớn nhất: 151

Như vậy, có thể thấy phân tích giá trị biên là kỹ thuật bổ sung cho kỹ thuật phân vùng tương đương, giúp kiểm thử viên sinh ca kiểm thử để kiểm tra các giá trị tại biên. “Đồ án: Kiểm thử ứng dụng trên nền Web bằng công cụ Selenium”

1.3.3. Đoán lỗi

Một kỹ thuật thiết kế ca kiểm thử khác là đoán lỗi. Kiểm thử viên phỏng đoán lỗi dựa trên trực giác và kinh nghiệm của mình, từ đó liệt kê các trường hợp có thể xảy ra lỗi và sinh ca kiểm thử. Khó có thể đưa ra một quy trình cho kỹ thuật kiểm thử đoán lỗi vì nó có tính trực giác cao và không thể dự đoán trước.

Trong một số trường hợp, kiểm thử viên có thể kết hợp với lập trình viên để tìm ra những trường hợp có thể bị bỏ sót trong quá trình viết đặc tả yêu cầu phần mềm và lập trình.

1.3.4. Kỹ thuật chuyển trạng thái

Kỹ thuật này dựa trên việc quan sát, theo dõi quá trình chuyển từ trạng thái này sang trạng thái khác khi có một hành động xảy ra trong chương trình phần mềm để phát hiện các lỗi có thể xảy ra mà các kỹ thuật trên có thể bỏ sót. Ví dụ điển hình cho kỹ thuật chuyển trạng thái là việc kiểm thử chức năng giỏ hàng trong các trang Web thương mại điện tử. Lỗi có thể xuất hiện mỗi khi thêm sản phẩm vào giỏ hàng, xóa sản phẩm khỏi giỏ hàng hay khi thanh toán các sản phẩm trong giỏ hàng đó. Công việc của kiểm thử viên là xem xét các điều kiện trạng thái, theo dõi quá trình chuyển đổi giữa các trạng thái, điều kiện nhập đầu vào và các sự kiện kích hoạt thay đổi trạng thái.

1.4. Kết luận

Chương 1 đã trình bày những khái niệm để có cái nhìn tổng quát về những vấn đề cơ bản xoay quanh phần mềm và kiểm thử phần mềm. Các vấn đề cụ thể bao gồm: “Đồ án: Kiểm thử ứng dụng trên nền Web bằng công cụ Selenium”

  • Các định nghĩa về phần mềm, kiểm thử phần mềm.
  • Vai trò của kiểm thử trong quá trình phát triển dự án phần mềm.
  • Các cấp độ trong kiểm thử phần mềm.
  • Quy trình kiểm thử phần mềm.
  • Phân loại kiểm thử phần mềm.
  • Liệt kê các mức độ nghiêm trọng của lỗi.
  • Tổng quan về ca kiểm thử.
  • Vai trò của kiểm thử tự động trong kiểm thử phần mềm hiện nay.
  • Trình bày một số nguyên tắc quan trọng trong kiểm thử phần mềm.

Liệt kê các kỹ thuật xác định ca kiểm thử.  

0 0 đánh giá
Article Rating
Theo dõi
Thông báo của
guest
0 Comments
Phản hồi nội tuyến
Xem tất cả bình luận
0
Rất thích suy nghĩ của bạn, hãy bình luận.x
()
x
Contact Me on Zalo
0972114537