Waterfall model

 Waterfall model

Mô hình Waterfall là gì?

Mô hình Watefall (Waterfall model) là mô hình của quy trình phát triển phần mềm được giới thiệu lần đầu tiên bởi tiến sĩ Winston W.Royce trong một bài báo công bố năm 1970. Trong mô hình này, quá trình phát triển phần mềm được chia thành các giai đoạn khác nhau và thực hiện tuần tự, đầu ra của giai đoạn này là đầu vào của giai đoạn tiếp theo và không có sự chồng chéo. Việc tiếp cận tuần tự từ trên xuống dưới như vậy giống như dòng chảy của một thác nước nên mô hình này được đặt tên là mô hình thác nước.

Các giai đoạn của mô hình Waterfall

Step 1: Phân tích yêu cầu

Đây là pha đầu tiên trong các dự án waterfall với mục đích xác định và phân tích tất cả các nhu cầu kinh doanh, các yêu cầu từ người dùng đối với sản phẩm, các ràng buộc và rủi ro đi kèm. 

Step 2: Thiết kế hệ thống

Từ những yêu cầu được xác định trong bước 1, nhóm dự án tạo ra thiết kế cho sản phẩm để đáp ứng tất cả các yêu cầu đó, bao gồm cả thiết kế phần cứng, thiết kế phần mềm, ngôn ngữ lập trình, lưu trữ dữ liệu. Đây đồng thời cũng là phần giúp bạn xác định dự án sẽ hữu ích thế nào đối với người dùng. Nếu bước này gặp vấn đề thì rất có thể phải quay lại bước 1 để thực hiện lại.

Step 3: Xây dựng

Khi hệ thống đã được thiết kế đầy đủ và cụ thể, các module chức năng của sản phẩm sẽ được thực hiện trong giai đoạn này để đáp ứng các tiêu chuẩn đã thực hiện ở bước trước. Đây là giai đoạn mà các nhiệm vụ công việc được thảo luận ở bước 2 được tiến hành và cũng là giai đoạn mà đội ngũ lập trình sẽ là nguồn lực chủ yếu được sử dụng.

Step 4: Kiểm thử hệ thống

Ở giai đoạn này, thường sẽ là công việc của đội ngũ QA và tester nhằm tìm kiếm và báo cáo các lỗi trong hệ thống cần được xử lý. Việc này bao gồm tất cả các hoạt động kiểm thử tính năng và phi tính năng. Đây là giai đoạn cực kỳ quan trọng mà nhóm không được phép mắc sai lầm nhằm đảm bảo hệ thống được kiểm tra đầy đủ, các mục tiêu thiết kế và chức năng người dùng yêu cầu được đáp ứng và các nhu cầu kinh doanh được giải quyết.

Step 5: Triển khai hệ thống

Đây là giai đoạn mà sản phẩm được triển khai vào môi trường mà người dùng có thể bắt đầu sử dụng được. Hay nói cách khác là giai đoạn mà sản phẩm thực sự đi vào hoạt động. Trong giai đoạn này, nhóm dự án cần đảm bảo các yếu tố như: môi trường đang hoạt động, không có lỗi trên server, các tiêu chí test đã được đáp ứng hoặc kiểm tra lại môi trường sau khi ứng dụng được triển khai để đảm bảo sản phẩm không gặp vấn đề….

Step 6: Bảo trì hệ thống

Đây là giai đoạn cuối cùng của quá trình, trong đó nhóm dự án tập trung giải quyết các vấn đề của khách hàng. Trong các dự án phần mềm, đây thường là giai đoạn các bản được phát hành để cập nhật và sửa lỗi.

Ưu và nhược điểm của mô hình thác nước

Ưu điểm

Đây là mô hình đơn giản, dễ áp dụng, quy trình rõ ràng theo từng bước.

Dễ quản lý và bảo trì bởi cách tiếp cận tuyến tính và cố định theo từng bước. 

Các tiêu chí đầu vào và đầu ra được xác định rõ ràng nên dễ dàng trong công tác kiểm tra chất lượng.

Hoạt động hiệu quả trong các dự án nhỏ, với các yêu cầu rõ ràng.

Có nhiều tài liệu cung cấp cho khách hàng.

Nhược điểm

Không phải mô hình lý tưởng cho các dự án lớn và dài ngày.

Không hiệu quả đối với những dự án đối mặt với các yêu cầu không rõ ràng từ đầu.

Khó thích ứng với thay đổi bao gồm yêu cầu, kế hoạch, phạm vi dự án…

Độ trực quan thấp và giá trị chuyển giao chậm khi đến cuối chu trình người dùng mới nhìn thấy và sử dụng sản phẩm.

Read More

V model

 

V model

Vmodel là sự mở rộng của mô hình thác nước. Không giống như mô hình thác nước. Ở V model, tương ứng với một giai đoạn kiểm thử là một giai đoạn phát triển phần mềm, thử nghiệm trong mô hình chữ V được thực hiện song song với chu kì phát triển phần mềm.

Mô hình chữ V được ra đời nhằm khắc phục nhược điểm của mô hình thác nước chỉ diễn ra khi mã nguồn đã được triển khai xong. Điều đó sẽ rất bất lợi, nhất là khi tham gia các dự án lớn với hệ thống phức tạp. Việc bỏ lỡ một chi tiết nào đó sẽ khiến cho công sức của toàn team có thể bị đổ sông đổ biển. 

Nguyên lý hoạt động của V-Model

Vì là một biến thể của mô hình thác nước nên mô hình chữ V cũng có cách thức hoạt động tương tự. Điều đó có nghĩa là các giai đoạn sẽ được hoàn thiện rồi mới sang công đoạn kế tiếp. Các hoạt động sẽ được diễn ra đồng thời, không có pha rời rạc. Thay vào đấy, kiểm thử sẽ được bắt đầu ngay từ giai đoạn lấy yêu cầu để đảm bảo tìm ra tất cả lỗi có thể phát sinh.

Step 1: BRS

BRS là viết tắt của Business requirement Specification hay còn được hiểu là các yêu cầu kỹ thuật của công việc. Ở giai đoạn này, chuyên viên kiểm thử sẽ tìm hiểu tài liệu một cách kỹ lưỡng để biết được mục đích ra đời của phần mềm, các tiêu chuẩn để đánh giá về chất lượng… Hoàn thành bước này, chúng ta sẽ đến với một bước được gọi là Acceptance test.

Step 2: SRS

SRS là viết tắt của System requirement Specification. Dịch ra tiếng việt có nghĩa là phân tích yêu cầu hệ thống. Vì vậy, bản chất của step 2 chính là phân tích tính chất của công việc. Đi kèm với đó sẽ là quá trình System Testing.

Trong giai đoạn này, chúng ta sẽ cần xác minh các yêu cầu và xác nhận đầu ra cần có, các tài liệu cũng như UAT test case. Đặc biệt nhấn mạnh vào chức năng hoạt động của hệ thống.

Step 3: HLD

Đến với bước 3 – High Level Design hay còn được gọi là HLD. Giai đoạn này được thực hiện dựa trên kỹ thuật hệ thống và thiết kế. Mục đích chính là cung cấp các giải pháp giúp xử lý tổng quan về hệ thống sản phẩm cũng như các dịch vụ. Ở bước này, chúng ta sẽ phải thực hiện Integration Test.

Hoạt động xác minh ở đây bao gồm các đánh giá thiết kế còn xác nhận thì thiên về Test plan, test case và các ma trận truy vết. Đầu ra sau khi kết thúc step 3 gồm có System test cases, Feasibility reports, System test plan, các mô đun và tài liệu yêu cầu phần cứng liên quan…

Step 4: LLD

Ở bước tiếp theo, LLD – Low Level Design, phần mềm sẽ được xác định các yếu tố logic, các sơ đồ với mọi phương thức hay các mối liên quan. Trong quá trình đó, sẽ có nhiều mâu thuẫn phát sinh gây ảnh hưởng đến chất lượng sản phẩm. Và tất nhiên, nhiệm vụ của các chuyên viên kiểm thử chính là xác định lỗi để khắc phục kịp thời. 

Khi thực hiện thành công bước này, chúng ta sẽ đến với công đoạn test Component Test. Các hoạt động xác minh, xác nhận cũng được thực hiện song song. Trong đó, chuyên viên kiểm thử sẽ đánh giá các thiết kế để xác nhận với các trường hợp kiểm tra đơn vị. Đầu ra đạt được sẽ gồm các đơn vị kiểm tra đơn vị đã được kiểm thử. 

Step 5: Coding

Khi đã có đủ các yêu cầu triển khai sản phẩm rồi, vậy thì đây sẽ là lúc bắt đầu phát triển phần mềm. Mỗi thành viên trong nhóm sẽ được phân công với những nhiệm vụ cụ thể. Họ sẽ sử dụng các ngôn ngữ lập trình và các thuật toán để code phần mềm. Cuối step 5, chúng ta sẽ đến với một công đoạn test được gọi là Unit Test.

Ở bước quan trọng này, người ta sẽ xác minh các mã và kiểm tra các trường hợp test. Hoạt động xác nhận sẽ xoay quanh việc tạo các trường hợp kiểm tra chức năng. Sau đấy, xác nhận lại về các trường hợp kiểm tra chức năng. Đầu ra nhận được sẽ gồm danh sách các trường hợp thử nghiệm hay những vấn đề cần kiểm tra lại.

Step 6: Code/Testing

Bước này thực chất là để review lại Low Level Design ở Step 4. Sau khi việc thiết kế phần mềm với các yêu cầu cụ thể được hoàn tất thì các chuyên viên kiểm thử sẽ kiểm tra lại tính tối ưu của các đoạn Code. Lúc này việc Unit Test sẽ được thực hiện lại để đảm bảo chất lượng của phần mềm đáp ứng với các yêu cầu đã được đặt ra.

Ưu nhược điểm của mô hình chữ V

Về ưu điểm: 

V Model có cơ chế hoạt động đơn giản, dễ sử dụng. 

Lên kế hoạch cụ thể cho việc triển khai dự án, test phần mềm. 

Giúp tester dễ dàng phát hiện defect ngay từ những bước đầu tiên, tránh việc “sai cả dây”.

Tiết kiệm kha khá thời gian khi kiểm tra kỹ lưỡng ở từng giai đoạn phát triển phần mềm. Mang đến nhiều cơ hội thành công hơn cho các dự án đang được triển khai.

Về nhược điểm: 

Mô hình chữ V vẫn khá cứng nhắc khi yêu cầu công đoạn kiểm tra xác nhận ở từng bước. 

Nếu sử dụng với các dự án đơn giản thì sẽ gây tốn kém về thời gian cũng như nhân lực cho các công đoạn xác minh. 

Nếu xuất hiện sự thay đổi về kỹ thuật ở giữa chừng, tester sẽ phải thực hiện lại, chuẩn bị tài liệu mới, gây tốn kém về thời gian, chi phí.

Không thể sử dụng để vừa phát triển song song với vừa bán sản phẩm.

Sản phẩm của dự án sẽ không có nguyên mẫu ban đầu. Thay vào đó, sản phẩm chỉ xuất hiện khi tất cả các bước hoàn thành xong.

Khi nào sử dụng mô hình chữ V?

Dựa vào những ưu nhược điểm kể trên, chúng ta có thể biết được khi nào nên dùng mô hình chữ V để mang đến hiệu quả cao nhất. Cụ thể nên dùng V Model cho các trường hợp như sau: 

Dự án có kích thước nhỏ và trung bình khi có yêu cầu rõ ràng, cụ thể, không thay đổi. 

Tem có đội ngũ kỹ thuật tốt với nguồn tài nguyên phong phú, sẵn có. Từ đấy có thể đảm bảo được các yêu cầu. 

Nên sử dụng mô hình chữ V cho các dự án mà khách hàng có sự tự tin cao trong yêu cầu thiết kế. Hiểu một cách đơn giản là không có nhiều thay đổi hay dao động trong quá trình phát triển phần mềm. 

Trên đây là những thông tin cơ bản về mô hình chữ V hay còn gọi là mô hình xác minh hay mô hình xác thực. Đây là một kỹ thuật kiểm thử rất phù hợp cho các dự án có yêu cầu cụ thể, ít thay đổi. Vì vậy, có thể là một công cụ đắc lực cho việc phát triển, hoàn thiện phần mềm trước khi đến tay khách hàng.

Read More

7 Nguyên tắc cơ bản của Kiểm thử Phần mềm

 #1: 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

#2: Kiểm thử toàn bộ là không khả thi

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ể.

Do đó, việc chúng ta có thể làm là chọn thực thi những loại kiểm thử quan trọng nhất dựa trên phân tích rủi ro cũng như tầm quan trọng và độ ưu tiên của việc kiểm thử. Nghĩa là phải lên kế hoạch kiểm thử, thiết kế trường hợp kiểm thử sao cho có độ bao phủ nhiều nhất và giảm thiểu rủi ro sót lỗi khi đến tay người dùng

#3: Kiểm thử càng sớm càng tốt

Hoạt động kiểm thử được triển khai sớm chừng nào thì tốt chừng ấy. Chẳng hạn, chúng ta có thể bắt đầu hoạt động kiểm thử ngay từ khi sản phẩm bắt đầu hình thành chẳng hạn như giai đoan lấy yêu cầu khách hàng hay thiết kế tài liệu sản phẩm.

Thông thường, thời gian cho kiểm thử thường bị co lại khi sản phẩm gần ra thị trường. Do đó, việc kiểm thử sớm trong giai đoạn đầu sẽ giúp chúng ta có thời gian để tiến hành kiểm thử trong từng giai đoạn một cách đầy đủ.

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.

#4: Lỗi phân bố tập trung

Trong quá trình kiểm thử, chúng ta sẽ có thể dễ dàng quan sát thấy đa phần những lỗi tìm được thường chỉ liên quan đến một vài tính năng 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 tìm thấy trong 20% tính năng của hệ thống.

Điều này cũng có nghĩa là khi tìm lỗi, chúng ta nên tập trung vào những module, thành phần chức năng chính của hệ thống. Một lỗi trên những module chính này có giá trị gấp nhiều lần lỗi tìm được trên những module phụ khác.

#5: Nghịch lý thuốc trừ sau (pesticide paradox)

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. Tuy nhiên, các trường hợp kiểm thử trong regression test cũng cần phải được cập nhật để phản ánh sự thay đổi tương ứng của hệ thống.

#6: Kiểm thử phần mềm phụ thuộc vào ngữ cảnh

Tuy vào loại cũng như bản chất của ứng dụng mà chúng ta sẽ áp dụng những phương thức, kỹ thuật, cũng như loại kiểm thử khác nhau.

Chẳng hạn như phần mềm trong các thiết bị y khoa cần sẽ được kiểm thử kỹ lưỡng hơn một trò chơi điện tử. Quan trọng hơn, việc kiểm thử trên loại thiết bị này đòi hỏi phải dựa trên đánh giá rủi ro, đáp ứng những qui định nghiêm ngặt trong y khoa cũng như một bộ kiểm thử đặc thù. Tương tự, một website “lớn” cần phải được một cách đầy đủ từ hiệu năng đến tính năng nhằm đảm bảo server không bị ảnh hưởng khi có nhiều người truy cập vào hệ thống

#7: 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.

Read More

Các trường hợp kiểm thử cho Textbox/TextArea

1. Kiểm tra các ký tự alpha hoặc ký tự chữ và số.
2. Kiểm tra xem bảng chữ cái có được chấp nhận cả chữ hoa và chữ thường không.
3. Kiểm tra điều kiện bắt buộc đối với hộp văn bản nếu được đưa ra.
4. Kiểm tra xem hộp văn bản có trống hay không theo mặc định.
5. Kiểm tra giới hạn ký tự Max-Min của text box.
6. Chỉ kiểm tra các ký tự số.
7. Kiểm tra bằng cách nhập "thẻ HTML" và nhấp vào nút lưu.
8. Kiểm tra bằng cách nhập “Java Script” và nhấp vào nút lưu.
9. Kiểm tra bằng cách nhập “dấu cách” vào tiền tố và hậu tố của ký tự đã nhập - cắt bớt khoảng trắng.
10. Kiểm tra sao chép và dán văn bản dài từ word hoặc notepad.
11. Kiểm tra chiều cao và căn chỉnh của các text box giống nhau trên toàn bộ trang web.
12. Kiểm tra kéo và thả hình ảnh trong text box.

Read More

Kiểm thử cho trường ngày tháng năm sinh

1. Xác minh xem trường ngày sinh có được enabled hay không.
2. Kiểm tra xem người dùng có thể nhấp vào trường ngày hay không.
3. Kiểm tra xem trường đó là bộ chọn ngày hay trường ngày bình thường.
4. Kiểm tra xem bộ chọn ngày có được mở hay không khi người dùng nhấp vào trường ngày sinh (đối với bộ chọn ngày)
5. Kiểm tra xem người dùng có thể chọn ngày từ bộ chọn ngày hay không.
6. Xác minh chức năng chọn ngày (tiếp theo, trước đó, ngày tháng năm) người dùng có thể thay đổi và chọn ngày cho phù hợp hay không.
7. Kiểm tra xem khi người dùng nhập ngày theo cách thủ công.
8. Xác minh trường ngày sinh khi người dùng nhập ngày ở định dạng hợp lệ DD/MM/YYYY.
9. Kiểm tra xem khi người dùng nhập ngày ở định dạng MM/DD/YYYY không hợp lệ.
10. Xác minh xem thông báo cảnh báo có hiển thị hay không khi người dùng nhập ngày ở định dạng không hợp lệ.
11. Xác minh xem thông báo cảnh báo có hiển thị theo yêu cầu hay không khi người dùng nhập ngày ở định dạng không hợp lệ.
12. Kiểm tra xem khi người dùng nhập ngày trong tương lai.
13. Kiểm tra xem khi người dùng nhập ngày là 00/00/0000.
14. Xác minh phạm vi (Tối đa và Tối thiểu ) Ngày. Nếu yêu cầu là có.
15. Kiểm tra xem khi người dùng dán ngày hợp lệ vào trường ngày.
16. Kiểm tra xem khi người dùng dán ngày ở định dạng không hợp lệ.
17. Kiểm tra xem khi người dùng cố gắng nhập bảng chữ cái vào trường ngày sinh.
18. Kiểm tra xem khi người dùng thay đổi ngày máy và cố gắng thêm ngày sinh.

1. Xác minh các điều kiện Người lớn và Trẻ vị thành niên nếu có yêu cầu.

Read More

Các trường hợp kiểm thử cho Tooltip

• Kiểm tra chiều cao và chiều rộng của tooltip theo yêu cầu.
• Kiểm tra xem có hiển thị đúng văn bản tooltip hay không.
• Kiểm tra văn bản hoàn chỉnh sẽ được hiển thị bằng cách di chuột qua các phần tử.
• Tooltip sẽ không được hiển thị khi người dùng xóa con trỏ chuột khỏi phần tử.
• Kiểm tra khi di chuột xem màu phần tử có bị thay đổi hay không.
• Kiểm tra xem con trỏ chuột có thay đổi hay không khi di chuột qua tooltip.
• Kiểm tra xem có nội dung nào bị cắt bớt khi tooltip có nhiều nội dung hơn không.
• Kiểm tra xem văn bản tooltip có cung cấp thông tin phù hợp cho người dùng không.
• Kiểm tra xem có bất kỳ lỗi chính tả nào trong văn bảntooltip không.
• Kiểm tra xem các biểu tượng có hiển thị bên trong văn bản tooltip  không.

Read More

Các trường hợp kiểm thử cho URL

• Xác minh bằng cách nhấp vào trường URL đầu vào mà người dùng có thể truy cập vào trường này.
• Xác minh người dùng có thể nhập URL vào trường này.
• Xác minh người dùng có thể dán URL bằng bàn phím vào trường URL.
• Kiểm tra bằng cách dán URL vào trường với sự trợ giúp của chuột. Có thể nhấp chuột phải và dán văn bản với tùy chọn dán.
• Dán URL và nhấn phím enter trên bàn phím, quá trình tạo kết quả sẽ được bắt đầu.
• Kiểm tra bằng cách thêm một URL hợp lệ với https://. ví dụ: https://abc.com
• Kiểm tra bằng cách thêm một URL hợp lệ với http://. (vấn đề chuyển hướng là do server của domain)
• Xác minh bằng cách thêm tất cả các tiện ích mở rộng như .in, .be, .xyz, .top, v.v.
• Kiểm tra bằng cách thêm khoảng trắng vào đầu URL.
• Kiểm tra bằng cách thêm khoảng trắng vào cuối URL. Thì Khoảng cách đó nên được tự cắt bớt.
• Kiểm tra bằng cách chỉ thêm tên miền không có http hoặc https://
• Kiểm tra bằng cách không nhập URL vào trường và xác nhận. Một thông báo lỗi thích hợp sẽ được hiển thị. Không tìm thấy URL nào!
• Xác minh bằng cách thêm địa chỉ IP của trang web và xác nhận.
• Kiểm tra bằng cách thêm một URL hợp lệ không có phần mở rộng.
• Kiểm tra bằng cách chỉ thêm tên của trang web mà không thêm dấu chấm vào trường URL.
• Kiểm tra bằng cách chỉ thêm phần mở rộng. https://www.com
• Kiểm tra bằng cách thêm các URL có độ dài tối đa.
• Kiểm tra bằng cách thêm các URL có độ dài tối thiểu.
• Xác minh hành vi của ứng dụng bằng cách nhập URL được mã hóa.
• Xác minh URL chứa Tham số.
• Xác minh bằng cách thêm và xóa dấu gạch chéo /.
• Xác minh một URL chứa bất kỳ ký tự đặc biệt nào. ví dụ #, @, $
• Xác minh khi nhấp vào xác nhận, có hiển thị thông báo lỗi cho việc nhập trống hay không.
• Xác minh khi nhấp vào xác nhận, có hiển thị thông báo lỗi cho việc thêm dấu cách vào trường URL hay không.
  
  
  
  
  

Read More

Stress Test, Performance Test, Load Test

Stress Test, Performance Test, LoadTest

Stress Test là gì?

Stress test là quá trình xác định khả năng duy trì một mức độ hiệu quả nhất định trong các điều kiện không thuận lợi của máy tính, mạng, chương trình hoặc thiết bị. Nói dễ hiểu hơn thì stress test giúp kiểm tra tính ổn định của hệ thống.

Stress Test là gì

Quá trình này có thể bao gồm các bài kiểm tra định lượng được thực hiện trong phòng thí nghiệm, chẳng hạn như đo tần số lỗi hoặc sự cố hệ thống. Thuật ngữ này cũng đề cập đến đánh giá định tính các yếu tố như tính khả dụng hoặc khả năng chống lại các cuộc tấn công từ chối dịch vụ (DoS). Stress test thường được thực hiện cùng với quá trình kiểm tra hiệu suất tổng quát hơn.

Khi tiến hành stress test, một môi trường bất lợi được cố tình tạo ra và duy trì. Các hành động liên quan có thể bao gồm:

• Chạy một số ứng dụng sử dụng nhiều tài nguyên trong máy tính cùng một lúc
• Cố gắng hack vào máy tính và sử dụng nó như một zombie để phát tán thư rác
• Làm tràn ngập một máy chủ bằng các e-mail vô dụng
• Thực hiện nhiều nỗ lực đồng thời để truy cập vào một trang web
• Cố gắng lây nhiễm virus, Trojan, phần mềm gián điệp hoặc phần mềm độc hại khác vào hệ thống.

Tình trạng bất lợi được làm cho xấu dần đi cho đến khi mức hiệu suất giảm xuống dưới một ngưỡng tối thiểu nhất định hoặc hệ thống hoàn toàn ngưng hoạt động. Để có được kết quả hữu ích nhất, các yếu tố riêng lẻ sẽ được lần lượt thay đổi từng cái một. Điều này giúp có thể dễ dàng xác định các điểm yếu và lỗ hổng cụ thể.

Ví dụ,Một máy tính có thể có nhiều bộ nhớ nhưng khả năng bảo mật lại không tương xứng. Một hệ thống như vậy có thể chạy nhiều ứng dụng đồng thời mà không gặp sự cố, nhưng dễ dàng gặp sự cố khi bị tấn công bởi tin tặc.

Stress test có thể tốn thời gian và khá tẻ nhạt. Tuy nhiên, một số người làm nhiệm vụ stress test thích nhìn một hệ thống bị “sụp đổ” dưới các cuộc tấn công ngày càng dữ dội hoặc khi thay đổi những yếu tố khác nhau. Stress test có thể cung cấp một phương tiện để đo lường sự suy thoái, khả năng duy trì chức năng hạn chế của một hệ thống, ngay cả khi một phần lớn của nó đã bị xâm phạm.

Khi quá trình kiểm tra đã gây ra lỗi trên hệ thống, yếu tố cuối cùng của stress test là xác định mức độ hay tốc độ mà một hệ thống có thể phục hồi sau một sự kiện bất lợi.

Khi nào sử dụng Stress Test?

Stress Test trên web hay ứng dụng là điều rất quan trọng với những trang web hay ứng dụng về những sự kiện lớn như bán vé cho một buổi hòa nhạc nổi tiếng với nhu cầu cao của người dân. Vì vậy, điều quan trọng là kiểm tra thường xuyên với khả năng chịu tải của hệ thống. Điều này cũng giúp bạn chuẩn bị cho các tình huống bất ngờ, dành nhiều thời gian hơn và nguồn lực để khắc phục bất kỳ sự cố nào.

Performance Test là gì?

Performance Test là một loaị kiểm thử để xác định tốc độ của máy tính, tốc độ mạng hoặc thiết bị. Nó kiểm thử hiệu suất của các thành phần của một hệ thống bằng cách truyền các tham số khác nhau trong những kịch bản test khác nhau.

Khi nào sử dụng Performance Test?

Performance Test được thực hiện để kiểm tra hiệu suất của máy chủ trang web, cơ sở dữ liệu và mạng. Nếu bạn đang áp dụng phương pháp thác nước, thì điều quan trọng là bạn phải kiểm tra từng lần phát hành phiên bản mới. Tuy nhiên, nếu bạn đang sử dụng cách tiếp cận phát triển phần mềm nhanh, thì bạn cần kiểm thử ứng dụng liên tục.

Load Test là gì?

Load Test là quá trình mô phỏng độ chịu tải thực tế của bất kỳ ứng dụng hoặc trang web nào. Nó kiểm thử cách ứng dụng hoạt động trong điều kiện hoạt động bình thường và hoạt động hiệu suất cao. Loại kiểm thử này được áp dụng cho những dự án gần đi đến giai đoạn hoàn thành.

Khi nào sử dụng Load Test?

Load Test được thực hiện để xác định hệ thống có thể quản lý, xử lý lệnh của bao nhiêu người dùng. Bạn cũng có thể kiểm tra các tình huống khác nhau cho phép bạn tập trung vào các phần khác nhau của hệ thống. Giống như trang chủ hoặc trang web thanh toán của bạn để thử nghiệm mức tải của web. Nó cũng giúp bạn xác định cách xây dựng và duy trì trong hệ thống.

So sánh Performance Test, Load Test và Stress Test

PERFORMANCE TEST	LOAD TEST	STRESS TEST
Bao gồm cả Load Test và Stress Test	Là một loại của Performance Test	Là một loại của Performance Test
Giúp tạo ra thiết lập chuẩn và tiêu chuẩn cho ứng dụng	Giúp nhận ra giới hạn của hệ thống, thiết lập SLA của ứng dụng và kiểm tra hệ thống có khả năng chịu tải như thế nào	Kiểm tra xem hệ thống hoạt động như thế nào khi quá tải và cách hệ thống phục hồi khi xảy ra lỗi
Mục đích của Performance Test là tạo ra hướng dẫn về cách hệ thống hoạt động khi ở điều kiện bình thường	Tạo ra những kịch bản khi hệ thống hoạt động quá tải	Stress Test nhằm đảm bảo rằng khi hoạt động trong điều kiện tải cao trong một khoảng thời gian cố định sẽ không bị crash
Việc sử dụng tài nguyên, khả năng đáp ứng và độ tin cậy của sản phẩm được kiểm tra ở phương pháp kiểm thử này	Các thuộc tính được kiểm tra trong một bài kiểm tra tải là hiệu suất hoạt động lúc cao điểm, số lượng máy chủ và thời gian phản hồi.	Loại kiểm thử này kiểm tra thời gian phản hồi ổn định, v.v.
Trong Performance Test, giới hạn tải bao gồm cả dưới và trên ngưỡng nghỉ.	Trong Load Test giới hạn tải là ngưỡng ngắt.	Trong Stress Test giới hạn tải là trên ngưỡng nghỉ.
Ví dụ: Kiểm tra nhiều người dùng cùng một thời điểm, kết nối HTTP hoặc kiểm tra thời gian phản hồi thích hợp.	Ví dụ : Kiểm tra trình xử lý từ bằng cách thay đổi một phần lớn data, kiểm tra máy in bằng cách truyền dữ liệu nặng. Kiểm tra máy chủ mail với hàng ngàn người dùng đồng thời.	Ví dụ : Đột nhiên tắt và khởi động lại các port của một mạng lưới lớn.
Tại sao thực hiện Performance Test?	Tại sao thực hiện Load Test?	Tại sao thực hiện Stress Test?
Để kiểm tra xem ứng dụng đang hoạt động chính xác hay không	Tìm ra lỗi mà không thể tìm ra với bất kỳ phương pháp thử nghiệm khác. Chẳng hạn như rò rỉ bộ nhớ, lỗi quản lý bộ nhớ, tràn bộ đệm, v.v …	Nó giúp các đơn vị kiểm tra hệ thống khi xảy ra lỗi.
Để phù hợp với nhu cầu hoạt động của doanh nghiệp	Để phù hợp với nhu cầu hoạt động của doanh nghiệp	Để đảm bảo rằng hệ thống có sao lưu dữ liệu trước khi xảy ra lỗi hay không
Tìm, phân tích và khắc phục các vấn đề về hiệu suất	Để xác định độ ổn định của một ứng dụng	Để kiểm tra xem bất kì trục trắc nào làm ảnh hưởng xấu đến an ninh hệ thống hay không
Xác định tất cả phần cứng để đưa ra dự kiến tải phù hợp.	Để kiểm tra xem cơ sở hạ tầng hiện tại có đủ để chạy ứng dụng hay không.
Thực hiện kế hoạch về nhu cầu đáp ứng năng lực trong tương lai của ứng dụng	Số lượng người dùng đồng thời mà một ứng dụng có thể hỗ trợ và khả năng mở rộng để cho phép nhiều người dùng truy cập vào nó

Read More

4 giá trị cốt lõi và 12 quy tắc của Agile

 

4 giá trị cốt lõi và 12 quy tắc của Agile

Trong khi Agile manifesto nói đến 4 giá trị cốt lõi của Agile, thì Agile Principles đề cập đến các định hướng, giúp cho team triển khai dễ hàng hơn hơn khi áp dụng Agile trong công việc. Vậy thì 4 giá trị cốt lõi và 12 quy tắc của Agile là gì? chúng ta cùng đi tìm hiểu

Bốn Giá Trị Cốt Lõi

1. Individuals and Interactions Over Processes and Tools

    Cá nhân và tương tác hơn là quy trình và công cụ

2. Working Software Over Comprehensive Documentation

    Phần mềm hoạt động tốt hơn là tài liệu đầy đủ

3. Customer Collaboration Over Contract Negotiation

    Hợp tác với khách hàng hơn là đàm phán hợp đồng

4. Responding to Change Over Following a Plan

    Ứng phó, phản hồi với các thay đổi hơn là làm theo kế hoạch

Mười Hai Quy Tắc Agile

1. Customer satisfaction through early and continuous software delivery

    Ưu tiên sự hài lòng của khách hàng thông qua việc trao đổi và bàn giao liên tục Khách hàng sẽ cảm thấy hài lòng khi họ nhận được sản phẩm làm việc đều đặn thay vì chờ đợi thời gian kéo dài giữa các lần releases

2. Accommodate changing requirements throughout the development process

    Chào đón việc thay đổi trong suốt quá trình phát triển Tránh sự chậm trễ khi có yêu cầu thay đổi requirement

3. Frequent delivery of working software

    Delivery sản phẩm thường xuyên Chuyển giao phần mềm sử dụng được định kỳ, từ một vài tuần đến một vài tháng, với một thời gian ngắn hơn.

4. Business people and developers must work together daily throughout the project.

    Khách hàng và đội phát triển phải làm việc cùng nhau hàng ngày trong suốt dự án.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

    Xây dựng các dự án xoay quanh các cá nhân có động lực. Tạo cho họ một môi trường và hỗ trợ họ những thứ cần thiết và tin tưởng họ để công việc được hoàn thành.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

    Phương pháp hiệu quả nhất là truyền tải thông tin đến vào bên trong đội phát triển là hội thoại mặt-đối-mặt.

7. Working software is the primary measure of progress.

    Phần mềm làm việc là thước đo của quá trình.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

    Các quy trình Agile thúc đẩy sự phát triển bền vững. Các nhà tài trợ cho dự án, các nhà phát triển và người dùng cuối có thể duy trì một tốc độ vô hạn định.

9. Continuous attention totechnical excellence and good design enhances agility.

    Forcus liên tục đến kỹ thuật xuất sắc và sự thiết kế tốt giúp nâng cao tính linh hoạt.

10. Simplicity–the art of maximizing the amount of work not done–is essential.

    Tính đơn giản – nghệ thuật tối đa hoá khối lượng công vệc chưa hoàn thành – là điều thiết yếu.

11. Self-organizing teams encourage great architectures, requirements, and designs

    Các thành viên trong nhóm có kỹ năng và động lực, có quyền ra quyết định cần trao đổi thường xuyên với các thành viên khác trong nhóm và chia sẻ ý tưởng để cung cấp được sản phẩm chất lượng.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

    Ở thời điểm kết thúc sprint, Team nên xem lại làm thế nào để hiệu quả hơn, sau đó đồng thuận Tự cải thiện bản thân, cải tiến quy trình, kỹ thuật của mình sao cho phù hợp

Read More