mô Hình tiến hóa

mô hình tiến hóa gồm mấy loại
nêu rõ nội dung từng loại

nhóm mình bạn nào trả lời giúp Hưng cây này cái
t viết bằng điện thoại nên lâu lắm

Sao k ai rep câu tl cho t

câu tiếp nhé
trong quy trình phần mềm bạn có nói về phương pháp kiểm thử vậy bạn hãy
trình bày các phương pháp kiểm thử phần mềm

Trả lời
Trong quy trình phần mềm có nói về kiểm thử nhé.
Các phương pháp:
- Kiểm thử tĩnh và động:
Có rất nhiều phương pháp để kiểm thử phần mềm. Đánh giá, định hướng hoặc kiểm tra được gọi là kiểm thử tĩnh, trong khi việc chạy mã lập trình thực tế trong các tình huống được gọi là kiểm thử động. Kiểm thử tĩnh thông thường có thể được bỏ qua khi thực hành nhưng kiểm thử động diễn ra khi bản thân chương trình đó đang đượcsử dụng. Kiểm thử động có thể bắt đầu trước khi chương trình đã hoàn tất 100% để kiểm thử các phần cụ thể của mã và được áp dụng cho các chức năng riêng biệt hoặc Module. Kỹ thuật điển hình cho điều này được sử dụng trong cả mạch nhánh/trình điều khiển hoặc được thực hiện trong một môi trường gỡ lỗi nhất định.
- Phương pháp tiếp cận hộp
Theo truyền thống thì các phương pháp kiểm thử phần mềm được bắt nguồn từ kiểm thử hộp trắng và hộp đen. Có hai cách tiếp cận được sử dụng để mô tả quan điểm của một kỹ sư kiểm thử khi thiết kế các Test Case.
- Kiểm thử dựa trên đặc điểm kỹ thuật nhằm mục đích để kiểm tra các chức năng của phần mềm theo các yêu cầu ứng dụng.Mức độ kiểm thử thường đòi hỏi TestCase kỹ lưỡng để được cung cấp bởi các Tester, những người mà sau đó cóthể xác minh một cách đơn giản rằng đối với một giá trị đầu vào hoặc đầu ra (hoặc cách xử lý)có thể giống hoặc không so với giá trịkỳ vọng được định vị trong một Test Case nhất định. CácTest Case được xây dựng quanh các thông số kỹ thuật và các yêu cầu đề xuất, tức là những tất cả những gì ứngdụng đó phải làm. Nó được sử dụng để mô tả mở rộng phần mềm bao gồm các thông số kỹ thuật, các yêu cầu và thiết kế được bắt nguồn trong Test Case. Các kiểm thử này có thể là chức nănghoặc phi chức năng.
- Kiểm thử trực quan
Mục đích của kiểm thử trực quan là cung cấp các nhà phát triển khả năng kiểm soát những gìđang xảy ra tại thờiđiểm phần mềm thất bại theo cách mà họ có thể nhìn thấy thông tin đượcyêu cầu rõ ràng và dễ hiểu nhất.Cốt lõi của kiểm thử trực quan là ý tưởng giúp ai đó nhận ra được một vấn đề (hoặc một kiểm thử thất bại) thay vì chỉ mô tả nó từ đó giúp cho sự rõ ràng và hiểu biết tăng lên đáng kể. Kiểm thử trực quan vì thế luôn yêu cầu phải ghi lại toàn bộ tiến trình kiểm thử – chụp lại tất cả mọi thứ xảy ra trên hệ thống ở định dạng video. Các video đầu ra được bổ sung bằng thời gian kiểm thử thực tế đầu vào thông qua hình ảnh từ webcam và âm thanh từ micro
- Kiểm thử hộp xám liên quan đến hiểu biết về cấu trúc dữ liệu bên trong và các thuật toán cho mục đích của các bài kiểm thử thiết kế. Khi thực hiện những bài kiểm thử với User hoặc mức độ hộp đen, Tester không nhất thiết phải truy cập vào mã nguồn của phần mềm.Ta có thể thao tác với dữ liệu đầu vào và định dạng đầu ra không xác định nhưhộp xám bởi vì đầuvào và đầu ra rõ ràng ở bên ngoài của "hộp đen" mà chúng được hệ thống gọi ra trong quá trình kiểm thử. Sự phân biệt này là đặc biệt quan trọng khi tiến hành kiểm thử tích hợp giữa hai Module được viết mã bởi hai nhà phát triển khác nhau, mà ở đó chỉ có các giao diện được bộc lộ ra để kiểm thử.
- Kiểm thử đơn vị
Kiểm thử đơn vị hay còn được gọi làkiểm thử thành phần, đề cập đến việc kiểm thử chứcnăng từng phần của mã, thường ở mức độ chức năng. Trong một môi trường hướng về đối tượng thì điều này thường là cấp độ lớp, và các kiểmthử đơn vị tối thiểubao gồm hàm dựngvà hàm hủy. Nhiều loại kiểm thử được viết bởi các nhà phát triển như họ làm việc trong mã (kiểu hộp trắng) đểđảm bảo rằng từng hàm riêng biệt hoạt động đúng như kỳ vọng. Một hàm có thể có nhiều kiểm thử từ đó giúp nắm bắt được các trường hợp góc hoặc các nhánh trong Code. Kiểm thử đơn vị một mình không thể đảm bảo hết được từng chức năng của từng bộ phận trong phần phềm nhưng nó được sử dụng để đảm bảo rằng các khối kiến trúc của phần mềm hoạt động độc lập với nhau.
- Kiểm thử tích hợpKiểm thử tích hợp là một hình thức kiểm thử phần mềm nhằm tìm cách xác minh các giao diện giữa các thành phần xung đột của một thiết kế. Các thành phần này có thể tích hợptheo cách lặp đi lặplại hoặc tất cả cùng nhau ("Big Bang"). Thông thường cách thức này được coi là một thực hành tốt hơn vì nó cho phép các vấn đề vềgiao diện được định vị một cách nhanh chóng và cố định hơn.
- Kiểm thử hệ thống
Kiểm thử hệ thống giúp xác minh rằngmột hệ thống đượctích hợp có đáp ứng đầy đủ các yêucầu hay không. Ngoài ra, kiểm thử phần mềm phải đảm bảo rằng các chương trình hoạt động như kỳ vọng, không còn bị phá hủy hay lỗi phần nào đó trong môi trường hoạt động của nó hoặc không gặp sự cố khi hoạt động với tiến trình khác (điều này bao gồm bộ nhớ chia sẻkhông bị hỏng, nguồn tài nguyên không bị dư thừa hay chiếm dụng quá mức và không bị đẩy ra khi hoạt động song song các tiến trình).
- Kiểm thử mức chấp nhận
Cuối cùng hệ thống được giao cho người dùng để kiểm thử mứct chấp nhận.
Nguồn : *."Exploratory Testing," Cem Kaner, Florida Institute of Technology, Quality Assurance Institute Worldwide Annual Software Testing Conference, Orlando, FL, tháng 11 năm 2006*.Tài liệu tham khảo về kiểm thử phần mềm.
*.Thảo luận, chia sẻ về kiểm thử phần mềm.

Việc kiểm thử trước khi chuyển cho khách hàng kiểm tra là vô cùng quan trọng, do đó phải được thực hiện một cách thân trọng qua các bước như sau:
1. Thực hiện phép thử hộp đen cho toàn bộ sản phẩm. Trong quá trình tích hợp các module, ta mới chỉ kiểm thử xem từng module có thỏa mãn đặc tả không và phần mềm sau từng bước lắp ghép có hoạt động tốt không. Sản phẩm sau khi được tạo ra phải được kiểm thử một cách toàn diện. Kiểm thử hộp đen có nghĩa là kiểm tra xem chương trình chạy tốt không, tính toán cho kết quả chính xác không, nghĩa là ta chỉ quan tâm đến phần bên ngoài của phần mềm. Phần cấu trúc bên trong bị hộp đen (black-box) che khuất. (Hộp đen ở đây được dùng với ý nghĩa là không chú ý đến bên trong).
2. Cần kiểm thử tính ổn định (robustness) của sản phẩm một cách toàn cục. Tính ổn định của các module và từng phần của phần mềm đã được kiểm thử trong quá trình tích hợp. Khi quá trình tích hợp kết thúc thì phải kiểm thử tính ổn định của phần mềm một cách toàn cục. Cần có các trường hợp mẫu khác nhau để thử tính ổn định. Đặc biệt chú ý các kiểm thử cực điểm (stress testing) , tức là kiểm thử được thực hiện khi phần mềm hoạt động ở mức tối đa, ví dụ tất cả các màn hình làm việc (terminal) đều được sử dụng, hay như với phần mềm điều khiển máy rút tiền thì tất cả các máy rút tiền đều được khách hàng sử dụng... Hay kiểm thử dung lượng (volume testing), ví dụ phần mềm có khả năng xử lý tệp dữ liệu đầu vào lớn không...
3. Nhóm SQA cần kiểm tra xem phần mềm đã thỏa mãn tất cả các ràng buộc nêu ra trong bản đặc tả hay chưa. Ví dụ, nếu bản đặc tả nói rằng khi chương trình đang làm việc ở mức tối đa (working under full load) thì 95% các yêu cầu truy xuất thông tin được trả lời trong vòng 3 giây chẳng hạn, thì nhóm SQA phải kiểm thử xem có đúng như vậy không. Ngoài ra, cần kiểm tra những ràng buộc về khả năng lưu trữ dữ liệu và tính bảo mật (storage constraints and security constraints).
4. Nhóm SQA cần xem xét lại tất cả tài liệu và chương trình cần chuyển giao cho khách hàng, có đối chiếu với bản kế hoạch quản lý dự án phần mềm. Kiểm tra các tài liệu có phù hợp với phần mềm không. Ví dụ xem lại tài liệu sử dụng và thử dùng nó để thao tác phần mềm xem phần mềm hoạt động đúng như tài liệu mô tả không.
như này mới đúng mà bạn

hỏi về phương pháp kiểm thử mà
thì phải nêu ra phương pháp là gì
đâu phải các bước đâu