CHƯƠNG 1: CÁC YẾU TỐ CƠ BẢN CỦA KIỂM THỬ

Cấu trúc

1. Mô tả, với các ví dụ cách thức mà một khiếm khuyết của phần mềm có thể gây hại đối với cá nhân, tổ chức hoặc công ty.
2. Phân biệt giữa gốc rễ của 1 nguyên nhân và biểu hiện của nó.
3. Đưa ra lí do tại sao cần thiêt phải kiểm thử qua các ví dụ.
4. Mô tả lý do kiểm thử là một phần của đảm bảo chất lượng và đưa ra ví dụ cách mà kiểm thử góp phần đảm bảo chất lượng phầm phần mềm.
5. Nhớ lại thuật ngữ: “mistake”, “defect”, “fault”, “failure” và cụm từ tương ứng “error”, “bug”.
6. Giải thích nguyên tăc cơ bản trong kiểm thử.

Nội dung

1.1 Bối cảnh hệ thống phần mềm:

Nguyên tắc kiểm tra - kiểm thử phụ thuộc vào bối cảnh: kiểm thử được thực hiện khác nhau trong các bối cảnh khác nhau. Ví dụ: phần mềm quan trọng về an toàn như hệ thống ngân hàng được kiểm thử khác với các phần mềm về App trò chơi offline trên điện thoại. Ngày nay, chúng ta có thể bắt gặp phần mềm ở bất cứ nơi đâu dù khi ta làm việc ở nhà hay đi shopping. Chúng ta có thể sử dụng phần mềm để giao dịch với ngân hàng hoặc trong các sản phẩm máy giặt, oto. Tuy nhiên, hầu hết mọi người đã từng gặp những lỗi phần mềm như lỗi in hóa đơn, sự chậm trễ giao dịch trên các máy ATM hay các trang web không trả về kết quả như mong đợi. Không phải tất cả các hệ thống đều mang cùng mức độ rủi ro và không phải các vấn đề đều có cùng tác động khi chúng xảy ra. Khi thảo luận về những rủi ro, chúng ta cần cân nhắc xem chúng có khả năng xảy ra như thế nào và sẽ tác động ra sao nếu xảy ra. Một số vấn đề phần mềm có thể là khá nhỏ nhưng cũng có những vấn đề gây ra sự tốn kém về tiền bạc, thời gian, hoặc danh tiếng. Ví dụ một lỗi đánh máy trên giao diện trang web có thể là bình thường nhưng cũng có thể gây ra tác động đáng kể, tùy thuộc vào trang web và lỗi:

• Nếu trang web gia đình cá nhân của tôi tên mẹ tôi sai chính tả, mẹ tôi có thể khó chịu và tôi phải chịu đựng một số trêu chọc từ gia đình, nhưng tôi có thể sửa chữa nó một cách dễ dàng và chỉ có gia đình có thể nhìn thấy nó.
• Nếu trang web của công ty có một số lỗi chính tả trong văn bản, Các khách hàng tiềm năng có thể bỏ qua công ty vì nó có vẻ không chuyên nghiệp.
• Nếu một chương trình phần mềm tính sai số lượng thuốc trừ sâu, thì hậu quả có thể khá nghiêm trọng: giả sử một dấu thập phân được đặt sai và tỉ lệ chênh lệch nhau là 10 lần. Người nông dân hoặc người làm vườn sử dụng Thuốc trừ sâu nhiều hơn cần thiết, làm tăng chi phí, ô nhiễm môi trường. Tác động đến động vật hoang dã và nguồn cung cấp nước và có tác động đến sức khoẻ và an toàn cho Nông dân, người làm vườn, gia đình và lực lượng lao động, gia súc và vật nuôi. Hậu quả của việc mất lòng tin, chi phí pháp lý và tiền phạt để giải quyết các vấn đề về môi trường và sức khoẻ.

1.2 Nguyên nhân của các lỗi phần mềm

Nếu ai đó gây ra lỗi hay sai sót trong việc sử dụng phần mềm, điều này có thể dẫn đến phần mềm hoạt động không như mong đợi. Tuy nhiên, người thiết kế và xây dựng phần mềm cũng có thể gây ra lỗi phần mềm trong quá trình thiết kế và xây dựng. Đây chính là lỗi do bản thân của phần mềm gây ra. Chúng được gọi là “defects” hoặc đôi khi là “bugs” hay “faults”. Không phải tất cả các khiếm khuyết phần mềm đều gây ra lỗi đôi khi một số tồn tại mà chúng ta không bao giờ biết. Bất kì con người nào gồm cả lập trình viên và kiểm thử đều có thể gây ra lỗi. Những lỗi này có thể gây khiếm khuyết trong mã phần mềm hoặc chương trình, hoặc trong tài liệu. Nếu các khiếm khuyết được thực thi, hệ thống có thể bị lỗi. Vậy nếu các lỗi hoạt động sẽ ảnh hưởng đến các sản phẩm mà chúng ta phụ trách. Lỗi có thể xuất hiện khi chúng ta thiếu kinh nghiệp, thông tin không đúng, các vấn đề kỹ thuật, quy trình nghiệp vụ phức tạp, thay đổi công nghệ hay phải tương tác giữa nhiều hệ thống, hay chúng ta bất cẩn , mệt mỏi, chịu áp lực trong một thời gian dài. Tất cả các yếu tố đó ảnh hưởng đến khả năng ra quyết định của bộ não. Thất bại cũng có thể gây ra trong các điều kiện môi trường: sự bùng phát bức xạ, từ trường, trường điện tử, ô nhiễm có thể gây lỗi trong phần cứng hay phần mềm. Thậm chí thất bại có thể do chính một người nào đó cố tình gây ra. Khi chúng ta xem xét các lỗi phát sinh, chúng ta có thể xét các khiếm khuyết từ:

• Lỗi đặt tả, thiết kế, triển khai các phần mềm, hệ thống.
• Lỗi sử dụng hệ thống.
• Điều kiện môi trường.
• Thiệt hại do cố ý. Lỗi có thể phát sinh trong các giai đoạn khác nhau:
• Lỗi ở bước mã hóa thành phần mềm( code) lỗi này có thể được phát hiện và loại bỏ trong quy trình kiểm thử.
• Lỗi ở bước thiết kế ở lỗi này sẽ khó có thể phát hiện trong kiểm thử trừ khi được kiểm tra so với yêu cầu ban đầu. Lỗi này sẽ khó loại bỏ vì phải thay đổi thiết kế và code.
• Lỗi khi đưa ra các yêu cầu và sản phẩm được xây dựng dựa trên các yêu cầu đó. Lỗi này thường khi sản phẩm đến tay người dùng họ mới nhận ra và báo lại, để sửa các lỗi như vậy thường rất tốn kém về chi phí, thời gian. Trên thực tế, lỗi này không hề hiếm gặp. Về chi phí để sửa chữa lỗi của phần mềm, chi phí để tìm và sửa chữa các khiếm khuyết sẽ tăng lên đáng kể trong vòng đời sản phẩm. Như ở các giai đoạn phát sinh khiếm khuyết trên. Ở giai đoạn thiết kế, nếu lỗi được phát hiện và sửa chữa ngay giai đoạn đó thì chi phí sẽ giảm đáng kể so với việc lỗi này bị phát hiện và phải sửa chữa trong giai đoạn sản phẩm đã hoàn thiện.Vậy nên thậm chí nếu giai đoạn đưa yêu cầu bị sai, người dùng không thể sử dụng thì chương trình đó có thể bị gỡ bỏ hoàn toàn.

1.3 Vai trò của kiểm thử trong phát triển, bảo trì và vận hành phần mềm

Như trên chúng ta có thể thấy lỗi phần mềm có thể hình thành ở bất cứ giai đoạn nào của dự án và thiệt hại do nó gây ra có thể vô cùng nghiêm trọng. Việc duy trì kiểm thử trong quá trình phát triển phần mềm là rất cần thiêt để xác định các khiếm khuyết, để loại bỏ chúng nhằm giảm thiểu sự cố khi vận hành và gia tăng chất lượng hệ thống. Kiểm thử có thể bao gồm cả việc tìm kiếm những lỗi có thể xảy ra khi người dùng nhập dữ liệu, hay tìm kiếm các khiếm khuyết tiềm tàng có thể bị lợi dụng để tấn công, thực hiện các bài kiểm tra giúp cải tiến chất lượng sản phẩm… Chúng ta cũng có thể được yêu cầu kiểm thử phần mềm để đáp ứng theo hợp đồng hay các yêu cầu pháp lý hoặc các tiêu chuẩn cụ thể của lĩnh vực. Các tiêu chuẩn này có thể quy định loại kỹ thuật nào có thể sử dụng để kiểm thử hay phần trăm mã lỗi dùng để kiểm thử.

1.4 Kiểm thử và chất lượng

Kiểm thử giúp ta có thể đo lường về chất lượng của phần mềm về số lượng khiếm khuyết được tìm thấy, chạy thử, và bảo đảm hệ thống bằng các bài kiểm thử. Chúng ta có thể cùng lúc kiểm thử chức năng. Kiểm tra có thể giúp tự tin khi phát hiện rất ít hoặc không có lỗi khi phần mềm được kiểm tra nghiêm ngặt. Một bài kiểm tra sơ sài có thể không phát hiện được khiếm khuyết chương trình nên chúng ta cần xây dựng một bài kiểm tra được thiết kế tốt để có thể khẳng định chất lượng của phần mềm. Hệ thống được giao cho khách hàng phải đáp ứng một số đặc điểm kỹ thuật: xác nhận ( hệ thống đúng với đặc tả), xác minh ( hệ thống đúng với yêu cầu của khách hàng, trong thực tế hệ thống phù hợp với nghiệp vụ của khách hàng). Thuật ngữ ISTQB định nghĩa không chỉ gồm các đặc tả nhu cầu của người dùng. Điều quan trọng là đội dự án, khách hàng và các bên liên quan đạt được sự đồng thuận. Chúng ta cần tìm hiểu những gì khách hàng mong đợi về chất lượng. Những gì mà người phát triển và kiểm thử coi là chất lượng như: đáp ứng các đặc tả, ít lỗi chưa chắc là mong muốn của khách hàng nếu như nó không đáp ứng được các nghiệp vụ mà họ mong đợi. Hơn nữa, khách hàng có thể thấy rằng họ tiêu quá nhiều tiền mà phần mềm không đáp ứng kỳ vọng của họ. Khi phát hiện ra sự cố, chúng ta cần cố gắng tìm hiểu nguyên nhân gốc rễ của vấn đề. Ví dụ khi máy in không in ra giấy, các nhân viên bảo trì IT cùng hợp tác kiểm tra vấn đề bằng cách xem xét các nguyên nhân của sự cố. Sau đó, họ nhóm các nguyên nhân thành các lớp và xem xét liệu đó có phải là nguyên nhân gốc rễ của vấn đề hay không, Một số nguyên nhân vấn đề:

• Máy in hết mực
• Phần mềm điều khiển có vấn đề
• Phòng máy in quá nóng Đây là những nguyên nhân trực tiếp khiến máy in không in được. Nhưng nếu nhìn sâu vào các nguyên nhân này ta sẽ thấy gốc rễ vấn đề:
• Không có quy trình đầy đủ nên để máy in hết mực mà không ai biết
• Một số nhân viên không được đào tạo đầy đủ nên không biết cách đổ mực
• Hay không có quy trình kiểm soát kho hàng nên để hết vật tư ( hộp mực)

1.5 Bao nhiêu kiểm thử là đủ ?

Nguyên tắc là chúng ta không thể thử mọi trường hợp nên thay vì kiểm tra hết các trường hợp thì chúng ta tập trung vào các trường hợp theo việc phân chia mức độ rủi ro và ưu tiên. Chúng ta thấy rằng kiểm thử phát hiện ra lỗi và nâng cao chất lượng sản phẩm nhưng chúng ta cũng không thể thực hiện quá nhiều kiểm thử. Bởi áp lực đối với dự án. Quyết định có bao nhiêu bài kiểm tra là đủ cần phải tính đến mức rủi ro, bao gồm các rủi ro kỹ thuật và kinh doanh liên quan đến sản phẩm và dự án, những hạn chế như thời gian và ngân sách. Chúng ta tiến hành đánh giá rủi ro để quyết định kiểm thử bao nhiêu. Ngoài ra, kiểm tra phải cung cấp đầy đủ thông tin cho các bên liên quan để đưa ra những quyết định sáng suốt về việc phát hành phần mềm hoặc hệ thống. Vì giới hạn trong ngân sách, thời gian, và trong kiểm thử chúng ta cần phải quyết định chúng ta sẽ làm thế nào và kiểm thử bao nhiêu là đủ