Moon's Blog

4 cấp độ test như sau:

+ Acceptance Test

+ System Test

+ Integration Test

+ Unit Test

1) Unit Test – Kiểm thử mức đơn vị

Một Unit là một thành phần PM nhỏ nhất mà ta có thể kiểm thử được.

Ví dụ: các hàm (Function), thủ tục (Procedure), lớp (Class), hoặc các phương thức (Method)

Vì Unit được chọn để kiểm tra thường có kích thước nhỏ và chức năng hoạt động đơn giản, chúng ta không khó khăn gì trong việc tổ chức, kiểm thử, ghi nhận và phân tích kết quả kiểm thử. Nếu phát hiện lỗi, việc xác định nguyên nhân và khắc phục cũng tương đối dễ dàng vì chỉ khoanh vùng trong một đơn thể Unit đang kiểm tra. Một nguyên lý đúc kết từ thực tiễn: thời gian tốn cho Unit Test sẽ được đền bù bằng việc tiết kiệm rất nhiều thời gian và chi phí cho việc kiểm thử và sửa lỗi ở các mức kiểm thử sau đó.

Unit Test thường do lập trình viên thực hiện. Công đoạn này cần được thực hiện càng sớm càng tốt trong giai đoạn viết code và xuyên suốt chu kỳ PTPM. Thông thường, Unit Test đòi hỏi kiểm thử viên có kiến thức về thiết kế và code của chương trình. Mục đích của Unit Test là bảo đảm thông tin được xử lý và xuất (khỏi Unit) là chính xác, trong mối tương quan với dữ liệu nhập và chức năng của Unit. Điều này thường đòi hỏi tất cả các nhánh bên trong Unit đều phải được kiểm tra để phát hiện nhánh phát sinh lỗi. Một nhánh thường là một chuỗi các lệnh được thực thi trong một Unit, ví dụ: chuỗi các lệnh sau điều kiện If và nằm giữa then ... else là một nhánh. Thực tế việc chọn lựa các nhánh để đơn giản hóa việc kiểm thử và quét hết Unit đòi hỏi phải có kỹ thuật, đôi khi phải dùng thuật toán để chọn lựa.

Conga he các much kiểm thử khác, Unit Test cũng đòi hỏi phải chuẩn bị trước các tình huống (test case) hoặc kịch bản (script), trong đó chỉ định rõ dữ liệu vào, các bước thực hiện và dữ liệu mong chờ sẽ xuất ra. Các test case và script này nên được giữ lại để tái sử dụng.



2) Itergration Test – Kiểm thư tích hợp

Integration test kết hợp các thành phần của một ứng dụng và kiểm thử như một ứng dụng đã hoàn thành. Trong khi Unit Test kiểm tra các thành phần và Unit riêng lẻ thì Intgration Test kết hợp chúng lại với nhau và kiểm tra sự giao tiếp giữa chúng.

Integration Test có 2 mục tiêu chính:

• Phát hiện lỗi giao tiếp xảy ra giữa các Unit.
• Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ (subsystem) và cuối cùng là nguyên hệ thống hoàn chỉnh (system) chuẩn bị cho kiểm thử ở mức hệ thống (System Test).

Trong Unit Test, lập trình viên cố gắng phát hiện lỗi liên quan đến chức năng và cấu trúc nội tại của Unit. Có một số phép kiểm thử đơn giản trên giao tiếp giữa Unit với các thành phần liên quan khác, tuy nhiên mọi giao tiếp liên quan đến Unit thật sự được kiểm tra đầy đủ khi các Unit tích hợp với nhau trong khi thực hiện Integration Test.

Trừ một số ít ngoại lệ, Integration Test chỉ nên thực hiện trên những Unit đã được kiểm tra cẩn thận trước đó bằng Unit Test, và tất cả các lỗi mức Unit đã được sửa chữa. Một số người hiểu sai rằng Unit một khi đã qua giai đoạn Unit Test với các giao tiếp giả lập thì không cần phải thực hiện Integration Test nữa. Thực tế việc tích hợp giữa các Unit dẫn đến những tình huống hoàn toàn khác.
Một chiến lược cần quan tâm trong Integration Test là nên tích hợp dần từng Unit. Một Unit tại một thời điểm được tích hợp vào một nhóm các Unit khác đã tích hợp trước đó và đã hoàn tất (passed) các đợt Integration Test trước đó. Lúc này, ta chỉ cần kiểm thử giao tiếp của Unit mới thêm vào với hệ thống các Unit đã tích hợp trước đó, điều này làm cho số lượng kiểm thử sẽ giảm đi rất nhiều, sai sót sẽ giảm đáng kể.

Có 4 loại kiểm thử trong Integration Test:

• Kiểm thử cấu trúc (Structure Test): Tương tự White Box Test (kiểm thử nhằm bảo đảm các thành phần bên trong của một chương trình chạy đúng), chú trọng đến hoạt động của các thành phần cấu trúc nội tại của chương trình chẳng hạn các lệnh và nhánh bên trong.
• Kiểm thử chức năng (Functional Test): Tương tự Black Box Test (kiểm thử chỉ chú trọng đến chức năng của chương trình, không quan tâm đến cấu trúc bên trong), chỉ khảo sát chức năng của chương trình theo yêu cầu kỹ thuật.
• Kiểm thử hiệu năng (Performance Test): kiểm thử việc vận hành của hệ thống.
• Kiểm thử khả năng chịu tải (Stress Test): kiểm thử các giới hạn của hệ thống.



3) System Test – Kiểm thử mức hệ thống

Mục đích System Test là kiểm thử thiết kế và toàn bộ hệ thống (sau khi tích hợp) có thỏa mãn yêu cầu đặt ra hay không.

System Test bắt đầu khi tất cả các bộ phận của PM đã được tích hợp thành công. Thông thường loại kiểm thử này tốn rất nhiều công sức và thời gian. Trong nhiều trường hợp, việc kiểm thử đòi hỏi một số thiết bị phụ trợ, phần mềm hoặc phần cứng đặc thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân bố, hoặc hệ thống nhúng. Ở mức độ hệ thống, người kiểm thử cũng tìm kiếm các lỗi, nhưng trọng tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầu khác liên quan đến chất lượng của toàn hệ thống.

Điểm khác nhau then chốt giữa Integration Test và System Test là System Test chú trọng các hành vi và lỗi trên toàn hệ thống, còn Integration Test chú trọng sự giao tiếp giữa các đơn thể hoặc đối tượng khi chúng làm việc cùng nhau. Thông thường ta phải thực hiện Unit Test và Integration Test để bảo đảm mọi Unit và sự tương tác giữa chúng hoạt động chính xác trước khi thực hiện System Test.

Sau khi hoàn thành Integration Test, một hệ thống PM đã được hình thành cùng với các thành phần đã được kiểm tra đầy đủ. Tại thời điểm này, lập trình viên hoặc kiểm thử viên (Tester) bắt đầu kiểm thử PM như một hệ thống hoàn chỉnh. Việc lập kế hoạch cho System Test nên bắt đầu từ giai đoạn hình thành và phân tích các yêu cầu. Phần sau ta sẽ nói rõ hơn về một quy trình System Test cơ bản và điển hình.

System Test kiểm thử cả các hành vi chức năng của phần mềm lẫn các yêu cầu về chất lượng như độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật. Mức kiểm thử này đặc biệt thích hợp cho việc phát hiện lỗi giao tiếp với PM hoặc phần cứng bên ngoài, chẳng hạn các lỗi "tắc nghẽn" (deadlock) hoặc chiếm dụng bộ nhớ. Sau giai đoạn System Test, PM thường đã sẵn sàng cho khách hàng hoặc người dùng cuối cùng kiểm thử để chấp nhận (Acceptance Test) hoặc dùng thử (Alpha/Beta Test).

Đòi hỏi nhiều công sức, thời gian và tính chính xác, khách quan, System Test thường được thực hiện bởi một nhóm kiểm thử viên hoàn toàn độc lập với nhóm phát triển dự án. Bản thân System Test lại gồm nhiều loại kiểm thử khác nhau (xem hình 3), phổ biến nhất gồm:

• Kiểm thử chức năng (Functional Test): bảo đảm các hành vi của hệ thống thỏa mãn đúng yêu cầu thiết kế.
• Kiểm thử khả năng vận hành (Performance Test): bảo đảm tối ưu việc phân bổ tài nguyên hệ thống (ví dụ bộ nhớ) nhằm đạt các chỉ tiêu như thời gian xử lý hay đáp ứng câu truy vấn...
• Kiểm thử khả năng chịu tải (Stress Test hay Load Test): bảo đảm hệ thống vận hành đúng dưới áp lực cao (ví dụ nhiều người truy xuất cùng lúc). Stress Test tập trung vào các trạng thái tới hạn, các "điểm chết", các tình huống bất thường như đang giao dịch thì ngắt kết nối (xuất hiện nhiều trong test thiết bị như POS, ATM...)...
• Kiểm thử cấu hình (Configuration Test)
• Kiểm thử khả năng bảo mật (Security Test): bảo đảm tính toàn vẹn, bảo mật của dữ liệu và của hệ thống.
• Kiểm thử khả năng phục hồi (Recovery Test): bảo đảm hệ thống có khả năng khôi phục trạng thái ổn định trước đó trong tình huống mất tài nguyên hoặc dữ liệu; đặc biệt quan trọng đối với các hệ thống giao dịch như ngân hàng trực tuyến...

Nhìn từ quan điểm người dùng, các cấp độ kiểm thử trên rất quan trọng: bảo đảm hệ thống đủ khả năng làm việc trong môi trường thực.

Lưu ý không nhất thiết phải thực hiện tất cả các loại kiểm thử nêu trên. Tùy yêu cầu và đặc trưng của từng hệ thống, tuỳ khả năng và thời gian cho phép của dự án, khi lập kế hoạch, người Quản lý dự án sẽ quyết định áp dụng những loại kiểm thử nào.



4) Acceptance Test – Kiểm thử chấp nhận sản phẩm

Thông thường, sau giai đoạn System Test là Acceptance Test, được khách hàng thực hiện (hoặc ủy quyền cho một nhóm thứ ba thực hiện). Mục đích của Acceptance Test là để chứng minh PM thỏa mãn tất cả yêu cầu của khách hàng và khách hàng chấp nhận sản phẩm (và trả tiền thanh toán hợp đồng).

Acceptance Test có ý nghĩa hết sức quan trọng, mặc dù trong hầu hết mọi trường hợp, các phép kiểm thử của System Test và Accepatnce Test gần như tương tự, nhưng bản chất và cách thức thực hiện lại rất khác biệt.

Đối với những sản phẩm dành bán rộng rãi trên thị trường cho nhiều người sử dụng, thông thường sẽ thông qua hai loại kiểm thử gọi là Alpha Test và Beta Test. Với Alpha Test, người dùng (user) kiểm thử PM ngay tại nơi PTPM, lập trình viên sẽ ghi nhận các lỗi hoặc phản hồi, và lên kế hoạch sửa chữa. Với Beta Test, PM sẽ được gửi tới cho người dùng (user) để kiểm thử ngay trong môi trường thực, lỗi hoặc phản hồi cũng sẽ gửi ngược lại cho lập trình viên để sửa chữa.
Thực tế cho thấy, nếu khách hàng không quan tâm và không tham gia vào quá trình PTPM thì kết quả Acceptance Test sẽ sai lệch rất lớn, mặc dù PM đã trải qua tất cả các kiểm thử trước đó. Sự sai lệch này liên quan đến việc hiểu sai yêu cầu cũng như sự mong chờ của khách hàng. Ví dụ đôi khi một PM xuất sắc vượt qua các phép kiểm thử về chức năng thực hiện bởi nhóm thực hiện dự án, nhưng khách hàng khi kiểm thử sau cùng vẫn thất vọng vì bố cục màn hình nghèo nàn, thao tác không tự nhiên, không theo tập quán sử dụng của khách hàng v.v...

Gắn liền với giai đoạn Acceptance Test thường là một nhóm những dịch vụ và tài liệu đi kèm, phổ biến như hướng dẫn cài đặt, sử dụng v.v... Tất cả tài liệu đi kèm phải được cập nhật và kiểm thử chặt chẽ.

Section I: Listening Comprehension (100 câu hỏi, khoảng 45 phút làm bài)
Bạn sẽ xem một ảnh chụp và được yêu cầu lựa chọn trả lời mô tả đúng những gì đang diễn ra trong hình. Các lựa chọn trả lời sẽ được đọc cho bạn; chúng sẽ không được in trong quyển đề thi.

Các câu hỏi đặt ra sẽ hỏi về người (people) hoặc vật (things). Để làm tốt phần này , ngay khi bạn nhìn thấy bức tranh bạn cần phải trả lời ngay các câu hỏi sau:
Photos for People:

Who are they?
Where are they?
What are they doing?
What do thay look like?

Photos for things

What are they?
Where are they?
What was done to them
What do they look like

Đây là phần bạn rất dễ bị " lừa" khi nghe. Các câu miêu tả sẽ hoặc là có nội dung sát với bức tranh nhưng không chính xác hoặc các câu đó phát âm tương tự nên bạn rất dễ bị nhầm. Hãy tỉnh táo khi nghe phần này nhé!
Part 2- Question and Response- 30câu (3 lựa chọn)
Bạn sẽ nghe một câu hỏi và được yêu cầu chọn câu trả lời đúng cho câu hỏi. Cả câu hỏi lẫn các lựa chọn trả lời đều sẽ được đọc nhưng không được in trong quyển đề thi.

Vấn đề đặt ra là nếu bạn sao nhãng không nghe được câu hỏi thì những đoạn phía sau thật là vô nghĩa. Khi bạn đã tập trung và nghe rõ được câu hỏi , hãy định hình ngay trong đầu xem nó đang đề cập đến cái gì. Điều này bạn có thể làm được nhờ bắt được một số key word như:

• Identifying Time: When , How long, What time, Yet, still, late , early , morning,... , at 6.am,... today , this week,... yesterday, tomorrow...
  
• Identifying People: Who , Whom , Whose, Who's , Name, An Occupation title
  
• Identifying a suggestion : Why don't we... , Why don't you..., Let's..., What about...
  
• Identifying a choice : What , which, or , prefer , rather ....
  
• Identifying a reason: Why ..., Why didn't..., Excuse , reason...
  
• Identifying a location : What , where , how far, next to, beside, left, right, near , far ,at , ..., name of place....
  
• Identifying an opinion : What , how , think , believe , your opinion, like
  

Part 3- Short Conversations- 30câu (4 lựa chọn)

Bạn sẽ được nghe đoạn hội thoại sau đó trả lời câu hỏi, phần này lại khoai hơn phần trước một tí. Để làm tốt được phần này bạn phải nhanh chóng đọc câu hỏi của đoạn hội thoại đó và chú ý nghe nội dung từ đầu đến cuối cố gắng không bỏ sót chữ nào vì bạn không thể tưởng tượng được đâu chính những từ bị phát âm lướt qua lại là đáp án cho câu trả lời đấy. Phần này đòi hỏi cả tư duy logic để phán đoán câu trả lời

Phần này cũng tương tự phần trên , sau khi bạn đọc câu hỏi để biết được hỏi về cái gì , bạn hãy chú ý lúc nghe thấy các từ key word như trên
Part 4- Short Talks- 20câu (4 lựa chọn)
Phần này gồm 20 câu hỏi cho khoảng 7 đến 9 đoạn, mỗi đoạn văn sẽ có tối thiểu 2 câu hỏi, phần này là phần khó nhất trong bài nghe, nhưng lại là phần ít lừa đảo và đánh đố nhất, nó chỉ đòi hỏi bạn khả năng ghi nhận thông tin nhanh thôi. Để làm tốt phần này bạn cần phải đọc lướt nhanh các câu hỏi (như nói ở trên kia) …. Bạn cũng cần phải luyện nghe đoạn văn thường xuyên để quen với các ghi nhận các thông tin chính, vì các câu hỏi trong đề thi thường tậ trung hỏi các vấn đề chính, với cả nghe thường xuyên bạn đỡ bị căng thẳng hơn, không bị bỏ sót thông tin hơn.

Thông thường, khi một động từ không có dạng thức tính từ tương ứng với nó thì phân từ 1 (V-ing) hoặc phân từ 2 (P2) của động từ đó được sử dụng làm tính từ. Đôi khi người học tiếng Anh không biết nên dùng tính từ ở dạng thức nào: V-ing hay Verb-ed hay Verb-en.:

Tính từ dạng V-ing thường được dùng khi danh từ mà nó bổ nghĩa thực hiện hoặc chịu trách nhiệm về hành động. Động từ thường là nội động từ (không có tân ngữ) và thời của động từ là thời tiếp diễn
•The crying baby woke Mr.Binion. (The baby was crying)
•The blooming flowers in the meadow created a rainbow of colors. (The flowers were blooming)
•The purring kitten snuggled close to the fireplace. (The kitten was purring)

Phân từ 2 (V-ed) được dùng làm tính từ khi danh từ mà nó bổ nghĩa là đối tượng nhận sự tác động của hành động. Câu có tính từ ở dạng P2 thường có nguồn gốc từ những câu bị động.

•The sorted mail was delivered to the offices before noon. (The mail had been sorted).
•Frozen food is often easier to prepare than fresh food. (The food had been frozen)
•The imprisoned men were unhappy with their living conditions. (The men had been imprisoned)

Lưu ý: Một số các động từ như to interest, to bore, to excite, to frighten khi sử dụng làm tính từ thường khó xác định nên dùng loại nào (phân từ 1 hay phân từ 2). Nguyên tắc áp dụng cũng giống như đã nêu trên: Nếu chủ ngữ gây ra hành động thì dùng P1, nếu chủ ngữ nhận tác động của hành động thì dùng P2. Xét thêm các ví dụ sau:

•The boring professor put the students to sleep.
•The boring lecture put the students to sleep.
•The bored students went to sleep during the boring lecture.
•The child saw a frightening movie.
•The frightened child began to cry.

1. EXPECT: chúng ta sử dụng động từ này khi muốn thể hiện sự tin tưởng rằng một điều gì đó sẽ xảy ra trong tương lai.

- She expected him to arrive on the next train. (Cô ấy trông mong anh ấy về trong chuyến tàu sắp tới).

2. HOPE: nghĩa là hi vọng. · He hopes that his favorite TV program would not be cancelled. (Anh ấy hi vọng chương trình TV yêu thích của mình sẽ không bị hoãn).

3. ANTICIPATE: động từ này mang nghĩa “đưa ra quyết định, hành động và tin rằng một hành động, sự kiện khác nào đó sẽ xảy ra”. ·

- He anticipated the fall in the stock market by selling all his shares. (Anh ấy tin rằng giá cổ phiếu sẽ giảm mạnh nên đã bán hết lượng cổ phiếu đang nắm giữ).

4. LOOK FORWARD TO: cụm động từ này mang nghĩa “hân hoan đợi chờ một điều nào đó sẽ xảy ra trong tương lai”.

- He was looking forward to a long holiday once the contract was signed. (Anh ấy háo hức chờ đợi đến kì nghỉ sau khi hợp đồng được kí kết).

Look forward to thường được dùng trong phần cuối khi viết thư từ - thể hiện sự mong chờ phía bên kia phúc đáp lại.

- I look forward to hearing from you again. (Tôi rất mong sớm nhận được hồi âm của anh/chị).

I am looking forward to getting information from you soon.

1. Think Of và Think About
Think of có nghĩa là tưởng tượng.
Think about là xem xét,suy nghĩ

ON TIME/IN TIME
ON TIME=đúng giờ, không chậm trễ.Ta dùng on time để nói rằng một việc nào đó xảy ra đúng thời gian như đã định.
ví dụ:

-The 11.45 train left on time
-Chuyến tàu 11h45 đã khởi hành đúng giờ(=nó rời nhà ga luc11h45)
-I'll meet you at 7.30.Ok but please be on time 
-Tôi  sẽ gặp anh vào 7h30.Hay lắm nhưng nhớ đúng giờ nhé.
(=đừng tới muộn,hãy có mặt ở đó vào 7h30) 

IN TIME=vừa đúng giờ,(làm gì đó)
ví dụ:

-will you be home in time forr dinner?(=soon enoughfor dinner)
-Bạn sẽ đến nhà kịp buổi tối chứ?(=vừa kịp buổi tối)
-I've send jill her birthday prresent.I hope arrives in time (for her birthday).
(=soon enough for her birthday)

in time to do something