Kiểm thử phần mềm là quá trình vận hành một chương trình nhằm tìm ra lỗi của nó. Để phần mềm hoạt động trơn tru, nó cần phải sạch lỗi. Và nếu kiểm thử phần mềm được thực hiện thành công, việc này sẽ khiến các lỗi không còn xuất hiện. Tuy nhiên, để tiết kiệm thời gian và công sức truy tìm các lỗi, có 7 nguyên tắc kiểm thử quan trọng mà bạn cần tuân theo.
I. 7 Nguyên Tắc Kiểm Thử Phần Mềm
Dưới đây là 7 nguyên tắc Kiểm thử phần mềm đó:
- Kiểm thử chứng minh sự hiện diện của lỗi
- Kiểm thử toàn bộ là không khả thi
- Kiểm thử càng sớm càng tốt
- Lỗi thường phân bổ tập trung
- Nghịch lý thuốc trừ sâu
- Kiểm thử phụ thuộc vào ngữ cảnh
- Quan niệm sai lầm về việc “hết lỗi”
Hãy cùng Techacademy tìm hiểu kỹ hơn 7 nguyên tắc kiểm thử này nhé:
+ Kiểm thử phần mềm chứng minh sự hiện diện của lỗi
Bằng việc kiểm thử, chúng ta có thể làm giảm lượng bugs lúc áp dụng nhiều cách kiểm thử lên phần mềm. Tuy nhiên lúc được đưa lên môi trường thật, người sử dụng cuối hoàn toàn có thể thấy nhiều lỗi khác không tìm thấy trong quá trình kiểm thử. Kiểm thử chứng minh được sản phẩm có lỗi nhưng không thể chứng minh rằng sản phẩm không còn lỗi.
Điều này có nghĩa là, sẽ luôn có lỗi không được phát hiện trong phần mềm, ngay cả khi không tìm thấy lỗi, cũng không đồng nghĩa rằng phần mềm đúng hoàn toàn.
+ Kiểm thử toàn bộ là không khả thi
Đúng vậy, rất khó để kiểm tra hầu hết các module cũng như những tính năng, kết hợp với đầu vào và đầu ra trong suốt quá trình kiểm tra. Các sản phẩm phần mềm hiện nay cực kỳ đa dạng và phức tạp, được phát triển trên nhiều nền tảng, thêm vào đó, ngày càng có nhiều công nghệ mới, khả năng kết nối dữ liệu lớn… khiến việc kiểm thử toàn bộ gần như là không thể.
Thay vì cố gắng kiểm thử toàn bộ, hãy xác định mức độ quan trọng và độ ưu tiên của các module để kiểm thử những phần cần thiết hoặc gặp nhiều nguy cơ hơn.
+ Kiểm thử càng sớm càng tốt
Nguyên tắc kiểm thử sớm có nghĩa là việc kiểm thử cần được thực hiện càng sớm càng tốt trong vòng đời phát triển phần mềm. Vậy ở bước nào thì được coi là sớm? Nguyên tắc này cho thấy ta cần phát hiện bug ngay từ các bước đầu tiên như nghiên cứu yêu cầu [requirement] hay design.
Phát hiện lỗi càng muộn, chi phí bỏ ra để xử lý càng cao. Vì vậy, việcthay đổi yêu cầu không đúng từ sớm sẽ khiến tốn ít chi phí để thay đổi tính năng hơn.
+ Lỗi thường được phân bố tập trung
Nguyên lý về phân bố lỗi chỉ ra rằng, chỉ một số ít module chứa phần lớn số lỗi phát hiện được. Những module này thường là những thành phần, chức năng chính của hệ thống. Điều này cũng đúng theo nguyên lý Pareto: 80 – 20: 80% số lỗi tìm thấy ở chỉ 20% module. Bằng kinh nghiệm, các QA/ Tester có thể xác định được những module có tính rủi ro và nhiều lỗi như vậy, giúp tập trung tìm kiếm lỗi nhanh và hiệu quả hơn.
Tuy nhiên, cách tiếp cận này cũng ẩn chứa vấn đề: nếu thực hiện kiểm thử tương tự lặp đi lặp lại, dễ thấy rằng những test case cũ sẽ khó tìm thêm được bug mới.
+ Nghịch lý thuốc trừ sâu
Trong trồng trọt, nếu người nông dân sử dụng lặp lại một liều trừ sâu, các loại sâu bệnh sẽ dần dần thích nghi và trở nên “nhờn” với loại thuốc trừ sâu đó. Tương tự với kiểm thử phần mềm, khi lặp đi lặp lại một test case, thì xác suất tìm được lỗi là rất thấp. Nguyên nhân là hệ thống hoàn thiện hơn, lỗi tìm thấy đã được sửa theo test case cũ. Để xử lý hiệu ứng “thuốc trừ sâu” này, test case cần được thường xuyên xem lại và chỉnh sửa, thêm nhiều test case mới để tìm lỗi mới [regression test].
Thêm vào đó, QA/ Tester cũng không nên phụ thuộc quá nhiều vào các kỹ thuật test sẵn có. Bạn cần liên tục cải tiến các phương pháp có sẵn để làm việc kiểm thử hiệu quả hơn.
+ Kiểm thử phụ thuộc vào ngữ cảnh
Kiểm thử phụ thuộc vào ngữ cảnh, nói một cách đơn giản, là việc kiểm thử một trang thương mại điện tử sẽ phải khác cách test một ứng dụng đọc tin tức. Tất cả các phần mềm đều được phát triển theo cách khác nhau. Và việc áp dụng chung một “cách giải” là sai lầm. Bạn cần sử dụng cách tiếp cận khác nhau, phương thức, kỹ thuật test khác nhau, loại test phụ thuộc vào loại phần mềm/ ứng dụng/ website.
+ Quan niệm sai lầm về việc “hết lỗi”
Một phần mềm sạch bug 99% vẫn có thể không sử dụng được. Đây là trường hợp phần mềm được kiểm thử bằng một requirement sai. Kiểm thử không chỉ để tìm ra lỗi, mà còn để kiểm tra xem phần mềm có đáp ứng được đúng nhu cầu hay không. Chính vì vậy, việc Không còn lỗi hay Hết lỗi là quan niệm sai lầm.
Quan điểm: “Nguyên tắc kiểm thử chỉ là để tham khảo, không có tính ứng dụng thực tế”?
Đây là quan điểm cực kỳ sai lầm. Các nguyên tắc kiểm thử giúp tạo ra một chiến lược kiểm thử rõ ràng và tạo ra những trường hợp kiểm thử sát sao, dễ bắt được bug. Những tester dày dạn kinh nghiệm áp dụng những nguyên tắc kiểm thử nhuần nhuyễn đến độ họ không nghĩ rằng họ đang áp dụng chúng. Vì vậy, việc nguyên tắc kiểm thử không có tính ứng dụng thực tế là sai lầm.
II. Quy Trình Kiểm Thử Phần Mềm
Kiểm thử phần mềm [software testing] là hoạt động nhằm tìm kiếm, phát hiện các lỗi của phần mềm
Kiểm thử phần mềm bảo đảm sản phẩm phần mềm đáp ứng chính xác, đầy đủ và đúng theo yêu cầu của khách hàng, yêu cầu của sản phẩm đề đã đặt ra.
Kiểm thử phần mềm cho bạn cơ hội dùng khả năng sáng tạo, phân tích để tìm ra những thứ mà người khác không thấy được. Bạn phải có cách nghĩ khác về những việc và các tình huống mà người khác ko nghĩ ra vì trường hợp các bug dễ nhìn thấy thì nó đã không tồn tại.
Kiểm thử thực chất là 1 quy trình hơn là một hoạt động đơn lẻ. Quá trình này bắt đầu từ việc lập kế hoạch kiểm thử, sau đó là thiết kế các trường hợp kiểm thử, chuẩn bị cho việc thực thi và đánh giá kết quả thực thi cho đến lúc kết thúc hoạt động kiểm thử.
Về cơ bản thì gồm các bước sau đây:
- Lập kế hoạch và kiểm soát việc kiểm thử
- Phân tích yêu cầu và Thiết kế testcase
- Thực thi – Chạy test
- Đánh giá tiêu chí dừng test và làm Báo cáo
- Đóng hoạt động kiểm thử
+ Lập kế hoạch và kiểm soát việc kiểm thử
Lập kế hoạch kiểm thử theo các bước quan trong sau:
– Xác định scope, risk và mục đích của hoạt động kiểm thử
– Xác định các tiếp cận kiểm thử
– Xác định quy định kiểm thử hoặc chiến lượng kiểm thử
– Xác định yêu cầu về nguồn nhân lực như con người, môi trường kiểm thử, thiết bị,…
– Lên lịch trình cho việc phân tích kiểm thử và thiết kế các trường hợp kiểm thử, thực thi kiểm thử và đánh giá kết quả kiểm thử.
– Xác định các tiêu chí kết thúc việc kiểm thử
+ Phân tích yêu cầu và Thiết kế testcase
Hoạt động phân tích và thiết kế kiểm thử có các nhiệm vụ chủ yếu sau đây:
- Rà soát các yêu cầu cần thiết trước khi tiến hành kiểm thử như tài liệu đặc tả, tài liệu thiết kế, tài liệu giao diện, v.v
- Xác định các điều kiện kiểm thử
- Thiết kế test case
- Đánh giá tính khả thi trong việc kiểm thử của yêu cầu cũng như của hệ thống.
- Chuẩn bị môi trường test cũng như xác định các yêu cầu về cơ sở hạ tầng và các công cụ kiểm thử tương ứng.
+ Thực thi – Chạy test
Hoạt động chạy test có nhiệm vụ chủ yếu sau đây:
- Sử dụng các kĩ thuật kiểm thử và tạo các dữ liệu kiểm thử để phát triển và đưa ra độ ưu tiên các trường hợp kiểm thử
- Tạo test suites từ các trường hợp kiểm thử để thực hiện kiểm thử hiệu quả.
- Thực hiện và xác minh môi trường
- Hoạt động chạy test có nhiệm vụ chủ yếu sau đây:
- Thực thi test suites và trường hợp kiểm thử riêng lẻ theo các phương thức kiểm thử
- Chạy lại các case bị failed trước đó để xác nhận là case đó đã được sửa
- So sánh kết quả ghi nhận được khi thực thi với kết quả mong đợi
- Đánh giá kết quả kiểm thử [Passed/Failed] cho các trường hợp kiểm thử
- Viết báo cáo lỗi cho những trường hợp kết quả ghi nhận được và kết quả mong đợi không giống nhau
+ Đánh giá tiêu chí dừng test và làm Báo cáo
Dựa trên đánh giá rủi ro của dự án, chúng ta sẽ thiết lập các tiêu chí cho từng hoạt động kiểm thử tương ứng để từ đó có thể xác định được liệu kiểm thử đã đủ hay chư.Những tiêu chí này khác nhau tùy từng dự án và được gọi tiêu chí kết thúc kiểm thử [exit criteria]. Các tiêu chí này bao gồm:
- Số lượng test case tối đa được thực thi Passed
- Tỷ lệ lỗi giảm xuống dưới mức nhất định
- Khi đến deadline
- Đóng hoạt động kiểm thử
Các hoạt động kiểm thử thường chỉ được kết thúc khi các phần mềm được bàn giao cho khách hàng. Ngoài ra, hoạt động kiểm thử có thể kết thức trong các trường hợp sau:
- Khi tất cả các thông tin đã được thu thập đầy đủ cho hoạt động kiểm thử
- Khi 1 dự án bị hủy bỏ
- Khi các mục tiêu chính đã hoàn thành
- Khi việc bảo trì hoặc cập nhật đã hoàn thành.
III. Các Loại Kiểm Thử Phần Mềm
“Kiểm thử”- chỉ 2 từ nhưng nó thực ra rất rộng lớn và phức tạp. Tùy theo nhu cầu và mục đích cụ thể, chúng ta sẽ có những loại kiểm thử khác nhau. Trong bài viết này các bạn sẽ hiểu được các loại kiểm thử phần mềm, mục đích sử dụng của từng loại cũng như giá trị của chúng.
+ Kiểm thử cài đặt [Installation testing]
Kiểm thử cài đặt, như tên gọi của nó, thường sẽ xoay quanh việc cài đặt, tháo gỡ các ứng dụng trên các môi trường khác nhau.
Kiểm thử cài đặt đóng vai trò vô cùng quan trọng. Vì sao? Vì nếu sản phẩm của bạn cần phải cài đặt để có thể hoạt động và giả sử người dùng không thể cài đặt [hay có lỗi ở phần cài đặt] thì hậu quả là….chẳng ai sử dụng được sản phẩm của bạn.
Khi nào sử dụng kiểm thử cài đặt?
Bạn nên bắt đầu hoạt động kiểm thử cài đặt càng sớm càng tốt và trường hợp sản phẩm của bạn cần phải cài đặt thì bạn nên tập trung nhiều vào phần này.
Các câu hỏi trong lúc kiểm thử cài đặt:
- Ứng dụng có thể cài đặt thành công trên [bạn điền môi trường test của bạn như PC [Windows, Linux], Mobile [Android, iOS]]?
- Các bước cài đặt/tháo dỡ có dễ dàng tường minh hay không?
- Sản phẩm có thể cài đặt tháo dỡ thành công trên [bạn điền môi trường test của bạn như PC [Windows, Linux], Mobile [Android, iOS]]?
- Sản phẩm có thể cài đặt trên những thư mục khác nhau không?
- Sản phẩm sau khi tháo gỡ còn sót file hoặc folder nào không?
- Sản phẩnm có thể cài đặt từ CD/DVD?
- Người dùng có thể cập nhật, nâng cấp ứng dụng đã cài đặt?
+ Kiểm thử “khói” [Smoke test]
Thuật ngữ smoke test được bắt đầu trong ngành điện tử, phần cứng. Đây là hoạt động kiểm thử đầu tiên cần phải thực hiện lúc kỹ sư bật công tắc hay cắm nguồn điện để xem….có “khói bốc lên cao hay không”. Nếu không có khói [nghĩa là sản phẩm ok để test tiếp], nếu có khói [sản phẩm đã chết] thì buộc phải sửa ngay tức khắc.
Tương tự, trong phát triển phần mềm thì smoke test là loại test nhằm đánh giá xem sản phẩm, build được xây dựng bởi dev có lỗi gì nghiêm trọng hay không để có thể tiếp tục các hoạt động khác.
Loại kiểm thử này chỉ nhằm mục đích đánh giá sơ khởi xem build nhận được có ok để test tiếp hay không. Lí do ta phải sử dụng smoke test là việc phát hiện sớm những lỗi quan trọng sẽ giúp tránh lãng phí khi chúng ta dành thời gian cho những hoạt đông kiểm thử khác.
Smoke test [một số nơi có thể gọi là sanity test, build validation test, build acceptance test] thường là một bộ kiểm thử đơn giản và chứa một số các test case cơ bản đi qua những tính năng quan trọng nhất của sản phẩm. Khi bạn làm việc với sản phẩm bạn sẽ phải biết được những tính năng nào là quan trọng nhất [nghĩa là những tính năng này là giá trị gốc, là sống còn đối với sản phẩm hoặc công ty]. Nếu bạn vẫn chưa biết thì tốt nhất là tìm hiểu hoặc hỏi ngay.
Khi nào nên sử dụng kiểm thử “khói”?
Khi dev giao build cho đội test thì việc trước tiên là thực thi bộ smoke test này. Bộ smoke test thường nhỏ nên bạn sẽ thường mất khoảng 1-2 giờ để thực thi. Nếu build fail, bạn báo ngay cho sếp, developer hoặc các bên liên quan để đánh giá tình hình. Trả build về và không nên test tiếp những tính năng khác.
+ Kiểm thử tương thích [Compatability test]
Đây là kiểu kiểm thử nhằm mục đích đánh giá sự tương thích giữa ứng dụng với các môi trường, nền tảng khác nhau. Loại kiểm thử này quan trọng vì ngày nay ngày càng xuất hiện nhiều nền tảng công nghệ, hệ điều hành, trình duyệt khác nhau và người dùng luôn mong đợi sản phẩm của họ phải hoạt động tốt trên các môi trường khác nhau này.
Các hoạt động kiểm thử tương thích thường áp dụng cho:
- Các trình duyệt web khác nhau như Chrome, FireFox, Safari và các version khác nhau của từng loại
- Các hệ điều hành khác nhau như Windows, Linux, Mac OS và các version khác nhau của từng loại
- Các nền tảng khác nhau như PC, Mobile, Desktop, Laptop
Dĩ nhiên, tùy theo đặc thù của ứng dụng mà có những loại kiểm thử tương thích cụ thể như kiểm thử tương thích cho các mạng viễn thông khác nhau, kiểm thử tương thích cho các ngôn ngữ chuyển đổi, kiểm thử tương thích cho loại người dùng khác nhau, v.v. Lời khuyên là bạn hãy tìm hiểu về người dùng cuối của sản phẩm như thị hiếu, thói quen, môi trường để từ đó xác định loại kiểm thử tương thích tương ứng.
Tuy nhiên, kiểm thử tương thích cũng có những khó khăn riêng của nó trong đó nổi bật là 2 khó khăn sau:
- Chuẩn bị cho môi trường test: Việc phải kiểm thử trên nhiều môi trường test khác nhau sẽ khiến việc chuẩn bị, setup gặp nhiều khó khăn về mặt chi phí, thời gian, kỹ thuật. Giải pháp là có thể sử dụng máy ảo để hỗ trợ việc chuẩn bị môi trường nhanh hơn hoặc các dịch vụ cung cấp các browser có sẵn.
- Độ bao phủ kiểm thử rất rất lớn. Giả sử bạn có 500 test case cần phải thực thi và bạn phải chạy 500 test case này trên các trình duyệt Chrome, FireFox, Safari, IE và mỗi trình duyệt lại có những version khác nhau. Bạn tự nhân và có thể thấy khối lượng test case cần phải chạy là “khổng lồ”. Giải pháp là giảm số lượng môi trường test hoặc tăng nguồn nhân lực hoặc cũng có thể tự động hóa bộ kiểm thử để giảm thời gian thực thi.
+ Kiểm thử hồi quy [Regression test]
Đây có thể được coi là loại test phổ biến nhất và hầu hết tester đều biết qua loại test này.
Kiểm thử hồi qui nhằm mục đích kiểm tra xem những thay đổi trong một build ở một tính năng [như thêm mới tính năng, thay đổi một tính năng, sửa lỗi] không làm ảnh hưởng đến những tính năng khác hay tạo thêm lỗi mới.
Loại kiểm thử này quan trọng và gần như là không thể thiếu trong hoạt động kiểm thử vì chúng ta không thể [hoặc khó] đoán được liệu những thay đổi dù là nhỏ nhất có thể ảnh hưởng đến những module khác hay không. Dĩ nhiên một số thay đổi có thể đoán được, một số thay đổi thì không. Do đó việc chạy hồi qui được coi là giải pháp an toàn nhất.
Kiểm thử hồi qui được thực thi như sau:
Giả sử bạn có 1000 test case cho toàn bộ sản phẩm của bạn, sau khi developer đưa ra 1 build mới, bạn phải thực thi toàn bộ 1000 test case này trên buiild mới và cứ mỗi lần ra build mới bạn sẽ phải thực thi lại 1000 test case này.
Những khó khăn thường gặp phải đối với loại kiểm thử này? Do phải thực thi với số lượng lớn test case sau mỗi đợt build nên kiểm thử hồi qui thường tốn kém [thời gian, nhân lực] và “boring”. Giải pháp cho vấn đề này thường thì kiểm thử hồi qui được tự động hóa để tăng độ bao phủ hay có thể giảm số lượng trường hợp kiểm thử [chỉ chọn những trường hợp quan trọng] hoặc có thể tăng nhân lực. Còn tùy những điều kiện khác nhau sẽ quyết định giải pháp nào là phù hợp.
+ Kiểm thử nghiệm thu [Acceptance test]
Kiểm thử nghiệm thu là loại kiểm thử được thực hiện bởi khách hàng hay chủ sản phẩm để đánh giá chất lượng của sản phẩm liệu xem có chấp nhận sản phẩm hay không. Loại kiểm thử này thường thấy ở các dự án outsource.
Bộ kiểm thử nghiệm thu thường chứa những test case cơ bản quan trọng của sản phẩm và thường được thực thi độc lập bởi khách hàng hoặc một bên thứ 3. Trong thực tế, một số dự án thì kiểm thử nghiệm thu cũng thường được sử dụng như là kiểm thử smoke test để đánh giá build từ developer để xem có chấp nhận để có thể test tiếp hay không.
+ Kiểm thử hiệu năng
Kiểm thử hiệu năng là một loại hình kiểm thử nhằm đánh giá khả năng hoạt động của hệ thống cũng như độ ổn định của hệ thống. Có 2 loại test cơ bản trong kiểm thử hiệu năng:
- Stress test: Là một dạng của kiểm thử hiệu năng trong đó hệ thống được đẩy lên ngưỡng cao nhất đến khi nào hệ thống “die” thì thôi. Mục đích là tìm được ngưỡng của hệ thống.
- Load test: Kiểm thử chịu tải là loại kiểm thử nhằm đánh giá xem liệu hệ thống có thể hoat động khi hoạt động dưới 1 lượng tải nhất định [thường là lượng user truy cập]
Loại test này cực kỳ quan trọng vì nó giúp chúng ta đánh giá được khả năng chịu tải của hệ thống của mình tới đâu để có kế hoạch nâng cấp, sửa chữa kịp thời.
Loại kiểm thử này thường được áp dụng trên những hệ thống đòi hỏi load dữ liệu lớn hay số lượng truy cập lớn mà việc tải chậm, chập chờn hoặc ngưng trệ có thể ảnh hưởng đến sự sống còn của sản phẩm. Loại test này thường được áp dụng cho các website hoặc ứng dụng thương mại điện tử, tin tức, v.v
Một số tool hỗ trợ cho loại test này như LoadUI, JMeter, LoadComplete.
IV. Trắc Nghiệm Kiểm Thử Phần Mềm Có Đáp Án
Câu 1: Quá trình lập kế hoạch kiểm thử diễn ra theo trình tự như thế nào?
Chọn một câu trả lời
A] Lập bản kế hoạch chính rồi thực thi các bản kế hoạch chi tiết đồng thời Sai
B] Lập bản kế hoạch chi tiết rồi đến bản kế hoạch chính Sai
C] Lập bản kế hoạch chính, các bản kế hoạch chi tiết lần lượt được thiết kế theo trình tự thời gian phát triển của dự án Đúng
D] Lập đồng thời cả hai loại bản kế hoạch là bản kế hoạch chính và bản kế hoạch chi tiết Sai.
Đáp án đúng là: C] “Lập bản kế hoạch chính, các bản kế hoạch chi tiết lần lượt được thiết kế theo trình tự thời gian phát triển của dự án.”.Vì: Khi lập bản kế hoạch kiểm thử thì lập bản kế hoạch chính, các bản kế hoạch kiểm thử chi tiết lần lượt được thiết kế theo trình tự thời gian phát triển của dự án.
Tham khảo: giáo trình “Kiểm thử và bảo đảm chất lượng phần mềm”, chương 7, mục “Kiểm thử phần mềm trong công nghiệp”
Câu 2: Chỉ số trưởng thành phần mềm SMI là viết tắt của từ tiếng Anh nào sau đây?
Chọn một câu trả lời
A] Software Multirity Index Đúng
B] Save Multirity Index Sai
C] Software Maturity Index Sai
D] Software Manyfacture Iterface Sai
Đáp án đúng là: A] “Software Multirity Index”.Vì: Chỉ số chất lượng bảo trì hay chỉ số trưởng thành phần mềm SMI [Software Muturity Index – IEEE standard 982.1-1988]: cho biết tính ổn định của sản phẩm phần mềm đã được phát triển.
Tham khảo: giáo trình “Giáo trình công nghệ phần mềm” , Chương 4 mục “Đảm bảo, kiểm thử và bảo trì phần mềm
Câu 3: Số lõi tiềm tàng trong công thức tính DRE là …?
Chọn một câu trả lời
A] Toàn bộ lỗi phát hiện trong một tháng Sai
B] Toàn bộ lỗi phát hiện trong một ngày Sai
C] Số lỗi đã khử được và số lỗi tìm được sau này Đúng
D] Toàn bộ lỗi phát hiện trong một giờ Sai
Đáp án đúng là: C] Số lỗi đã khử được và số lỗi tìm được sau này”.Vì: Công thức tính Defect Removal Effectiveness có mẫu số là số lỗi tiềm tàng chính là toàn bộ lỗi phát hiện = Số lỗi đã khử được + Số lỗi tìm được sau này [do khách hàng báo lại, do tình cờ…].
Tham khảo: giáo trình “Giáo trình công nghệ phần mềm” , Chương 4 mục “Đảm bảo, kiểm thử và bảo trì phần mềm”
Câu 4: DSQI có giá trị nằm trong miền nào sau đây?
Chọn một câu trả lời
A] -1 đến 1 Sai
B] 0 đến 1 Đúng
C] 0 đến 2 Sai
D] -1 đến 0 Sai
Đáp án đúng là: B] “0 đến 1”.Vì: Chỉ số chất lượng về cấu trúc của thiết kế [Design Structured Quanlity Index – DSQI – IEEE Standard 982.1 – 1988]. Có giá trị nằm trong miền từ 0 đến 1
Tham khảo: giáo trình “Kiểm thử và bảo đảm chất lượng phần mềm”, Chương 9 mục “Quản lý chất lượng phần mềm”
Câu 5: Lý thuyết của Halstead để đo độ đo nào sau đây?
Chọn một câu trả lời
A] Chỉ số chất lượng cấu trúc Sai
B] Độ hoàn hảo của phần mềm Sai
C] Khối lượng chương trình Đúng
D] Mật độ lỗi Sai
Đáp án đúng là: C“Khối lượng chương trình”.Vì: Để đo khối lượng chương trình thì có nhiều chỉ số và nhiều cách đo. Tuy nhiên, ở đây giới thiệu cách đo của Halstead để đo khối lượng của chương trình hay khối lượng mã nguồn và đo mức của ngôn ngữ.
Tham khảo: giáo trình “Giáo trình công nghệ phần mềm” , Chương 4 mục “Đảm bảo, kiểm thử và bảo trì phần mềm
V. Các Công Cụ Kiểm Thử Phần Mềm Phổ Biến
Trong thời kỳ kết nối hiện nay, phần mềm trở nên cần thiết và phổ biến. Do vậy nên nhu cầu kiểm thử phần mềm cũng tăng theo. Dưới đây là 5 công cụ kiểm thử phần mềm hiệu quả đều chạy trên Cloud. Các công cụ này áp dụng cho những dự án lập trình web, mobile trên các platform khác nhau.
+ Công cụ kiểm thử phần mềm LoadStorm
Công cụ đầu tiên nên dùng để kiểm thử phần mềm trên website và mobile là LoadStorm. Nhìn chung LoadStorm là công cụ có khả năng chịu tải vô cùng tốt. Bạn đọc có thể kiểm tra hiệu năng của app thông qua lượng traffic và user. Điểm đặc trưng ở công cụ này là nó có thể thiết lập hàng trăm nghìn, thậm chí hàng triệu user để khai thác lỗ hổng trong ứng dụng.
Mặt khác, tester có thể dễ dàng điều chỉnh kịch bản test khi sử dụng công cụ này. Sau khi tiến hành pentest, bạn sẽ nhìn thấy một bản báo cáo chi tiết.
+ Công cụ SOASTA CloudTest
CloudTest giúp bạn kiểm tra các website và ứng dụng trên di động 1 cách linh hoạt, nhanh chóng. SOASTA CloudTest có thể kiểm tra khả năng chịu tải của các ứng dụng theo vị trí địa lý khác nhau, đặc biệt 2 khâu integration và phân tích thời gian thực giữa các monitoring, test design, reporting đều được tiến hành một cách liền mạch.
+ Công cụ Nessus
Nessus là công cụ chuyên sử dụng để pentest hệ thống, rà quét lỗ hổng bảo mật, và mã độc. Công cụ này cho phép bạn dùng thử miễn phí. Điểm khác biệt ở công cụ này so với các công cụ pentest khác là Nessus chứa các plugin về bảo mật hàng đầu thế giới, có thể rà quét lỗ hổng trong windoes, linux một cách toàn diện.
Công cụ này cũng cho phép quét những lỗ hổng tồn tại bên trong ứng dụng web, trình duyệt, phần mềm và các thiết bị mạng nội bộ. Sau khi rà quét xong nó sẽ báo cáo chi tiết về lỗ hổng, mức độ nguy hiểm và phương án phòng tránh, xử lý mã độc. Đây là một trong những công cụ kiểm thử phần mềm hàng đầu được mọi người tin dùng.
+ Công cụ BlazeMeter
BlazeMeter là công cụ cho phép bạn có thể test các hạng mục như: end-to-end load; performance và load testing, cho phép testing trên apps, mobiles, website, và APIs. BlazeMeter có khả năng giả lập lượng user khá lớn gần 1 triệu người. Khi tiến hành testing, bạn sẽ thấy công cụ này sẽ report trong thời gian thực cùng với sự chính xác cao của phần đo hiệu năng.
+ Công cụ App Thwack
App Thwack là công cụ chuyên dùng cho hệ điều hành iOS, Android và webapp trên thiết bị cụ thể. App Thwack dễ dàng tương thích với các nền tảng tự động hóa như: Calabash,Robotium, UI tự động hóa,…Ngoài ra những chức năng cơ bản như hỗ trợ báo cáo, hỗ trợ các nền tảng, dễ dàng sử dụng, dễ dàng cấu hình… cũng là những tính năng tối thiểu của công cụ để kiểm thử phần mềm này.
VI. Vai Trò Của Kiểm Thử Phần Mềm
Thời gian gần đây, ngành công nghệ thông tin, công nghệ phần mềm có vẻ vẫn đang đứng top các ngành, nghề có sức hút lớn, đặc biệt trong bối cảnh khủng hoảng mọi mặt về kinh tế, xã hội do đại dịch Covid gây ra. Vậy điều gì ấn tượng nhất ngay khi bạn nhắc tới ngành này, có phải là hình ảnh các anh kĩ sư máy tính, các lập trình viên thông minh cùng những dòng code phức tạp, khó hiểu.
Bên cạnh đó, tham gia vào việc đảm bảo chất lượng của các sản phẩm phần mềm, đứng song song vị trí với các lập trình viên là sự tham gia kiểm tra, thử nghiệm gọi tắt là kiểm thử phần mềm của các nhà Kiểm thử viên hay còn gọi là Tester. Trong bài viết lần này, hãy cùng mình tìm hiểu kĩ hơn về công việc của một Kiểm thử viên nhé.
Vai trò của Kiểm thử phần mềm
Công việc kiểm thử phần mềm là kiểm tra, kiếm tìm các lỗi của phần mềm, ứng dụng hoặc xác minh, thẩm định liệu phần mềm đó đã đáp ứng được các yêu cầu kỹ thuật và yêu cầu nghiệp vụ hay không.
Kiểm thử phần mềm thể hiện được những “trách nhiệm” cao cả dưới đây:
Thứ nhất, trách nhiệm hiệu quả về chi phí. Kiểm thử phần mềm giúp nhanh chóng phát hiện các lỗi của phần mềm, giúp giảm giá thành sửa chữa.
Thứ hai, trách nhiệm bảo mật. Sản phẩm được phát hiện và sửa lỗi giúp loại bỏ những rủi ro và các vấn đề sớm, làm tăng độ tin cậy cho sản phẩm. Đối với ngành công nghệ phần mềm, vấn đề bảo mật là yếu tố cực kỳ nhạy cảm, nó liên quan trực tiếp đến việc sở hữu, sử dụng của người dùng. Vì vậy, việc kiểm thử phần mềm giúp hoàn thiện nhất sản phẩm phần mềm, hạn chế những lỗ hổng bảo mật đáng tiếc, tăng độ tin tưởng cho người sử dụng.
Thứ ba, trách nhiệm về chất lượng sản phẩm. Ngoài vấn đề bảo mật như trên, sản phẩm phần mềm được kiểm tra sẽ đảm bảo được độ tin cậy, hiệu suất hoạt động cao, bảo đảm được các yêu cầu, tính năng cần thiết của nó. Sản phẩm đưa đến tay khách hàng phải là một sản phẩm đạt đủ các yêu cầu của khách hàng về hình thức, giao diện, cấu trúc, tính năng,…và đảm bảo không còn bất cứ lỗi nào trên sản phẩm.
Thứ tư, trách nhiệm với niềm tin của khách hàng. Một sản phẩm càng chỉn chu, càng hoàn thiện, chất lượng càng cao sẽ tạo ra những trải nghiệm người dùng tốt nhất, từ đó càng tạo được niềm tin và uy tín với khách hàng và đối tác.
Như vậy, Kiểm thử phần mềm là hoạt động không thể tách rời trong quá trình phát triển phần mềm.