Chuong 23: SOFTWARE TESTING by tQ7Cr31i

VIEWS: 0 PAGES: 64

									Nhóm 2. Lớp 07TH1D
 Mục tiêu của chương này là mô tả quá trình
 kiểm thử phần mềm và giới thiệu những kĩ
 thuật kiểm thử.

 1) Hiểu được sự khác nhau giữa kiểm thử
 phể chuẩn(validation testing) và kiểm thử sai
 sót(defect testing).
 2) Hiểu được nguyên tắc kiểm thử hệ
 thống(system testing) và kiểm thử thành
 phần(component testing).
3) Hiểu được 3 chiến lược có thể được sử
dụng để tạo ra các ca kiểm thử hệ
thống(system test cases).
4) Hiểu được những đặc điểm thiết yếu của
các công cụ phần mềm(software tools) hỗ
trợ tự động hóa việc kiểm thử.
 Có2 hoạt động kiểm thử căn bản là:
 +Kiểm thử thành phần(kiểm từng phần của hệ
 thống)
 +Kiểm thử hệ thống(kiểm toàn bộ hệ thống)
 Mục  đích của kiểm thử thành phần?
  +Phát hiện ra sai sót ở những thành phần
  riêng lẻ của chương trình(hàm, đối tượng
  hay thành phần dùng lại).
 Mục đích của kiểm thử hệ thống?.
  +Xác địch đã đạt được các yêu cầu chức
  năng và phi chức năng, các tác nhân
  không mong đợi.
  +Phát hiện ra sai sót đã bị bỏ qua ở khâu
  kiểm thử trước đó.
 Quá trình kiểm thử phần mềm có 2 mục đích
 phân biệt:
 1) Chứng minh cho người lập trình viên và
 khách hàng thấy phần mềm đạt yêu cầu của
 nó(tài liệu của phần mềm hoặc tính năng
 phần mềm).
 2) Phát hiện lỗi, thiếu sót không đúng với
 tính năng kĩ thuật đã định trước.(lệch lạc dữ
 liệu, tính toán sai, giao tiếp không tốt với hệ
 thống khác)
 Mục  đích 1 dẫn tới công việc kiểm thử
  phê chuẩn(validation testing).Hệ thống
  được trải qua các ca kiểm thử(test cases)
  để công nhận chức năng mong đợi.
  +Kiểm thử phê chuẩn thành công khi hệ
  thống vận hành chính xác.
 Mục đích 2 dẫn tới công việc kiểm thử sai
  sót(defect testing). Hệ thống được trải
  qua các ca kiểm thử(test cases) để phát
  hiện các sai sót.
  +Kiểm thử sai sót thành công khi phát
  hiện được điểm sai khiến hệ thống vận
  hành không chính xác.
 Kết luận:
 * Kiểm thử mọi khía cạnh, mọi trường hợp
 thực thi chương trình là không thể.
 * Do đó, phải chọn ra được tập các ca kiểm
 thử(test cases) có thể.
 * Nên có chính sách giải quyết để chọn ra các
 ca kiểm thử dựa trên tổng thể, kinh nghiệm
 và đặc điểm của hệ thống đang vận hành.
 Vídụ:
 * Tất cả các câu lệnh của chương trình nên
 thực thi ít nhất 1 lần.
 * Nếu có chức năng user input thì tất cả các
 hàm nên được kiểm thử với các input hợp lệ
 và không hợp lệ.
 *Tập tất cả các hàm được truy cập qua cùng
 1 thực đơn(menu) nên được kiểm thử.
Mô hình quá
trình kiểm thử
phần mềm




 Test cases: bảng ghi chi tiết các inputs để
  kiểm tra và các outputs được người ta mong
  đợi và báo cáo những gì sẽ được kiểm thử.
 Test data: dữ liệu để kiểm thử(inputs), có
  thể được phát sinh tự động.
 Kiểm  thử hệ thống bao gồm:
  +tích hợp nhiều thành phần(components)
  để thực hiện chức năng của hệ thống.
  +kiểm tra lại hệ thống được tích hợp.
 Trong quá trình phát triển lặp, kiểm thử
  hệ thống được hiểu là kiểm thử tăng
  dần(increment) để phân phối đến khách
  hàng.
 Trong quá trình thác nước, kiểm thử hệ
  thống được hiểu là kiểm thử toàn bộ hệ
  thống.
Ở các hệ thống phức tạp, có 2 giai đoạn
để kiểm thử hệ thống:
1) Kiểm thử tích hợp(integration testing):
đội ngũ kiểm thử truy cập vào mã nguồn
của hệ thống. Kiểm thử các thành phần
của hệ thống sau khi được tích hợp.
 2)Kiểm thử phát hành(Release testing):
Kiểm thử một phiên bản của toàn bộ hệ
thống để có thể phát hành cho người sử
dụng.
  +Nếu có khách hàng tham gia trong quá
  trình kiểm thử phát hành thì được gọi là
  kiểm thử chấp nhận(acceptance testing).
  Nếu phiên bản phát hành đủ tốt, họ sẽ
  chấp nhận sử dụng.
*Kết luận:
  +Ưu thế của kiểm thử tích hợp là phát
  hiện sai sót trong hệ thống.
  +Ưu thế kiểm thử phát hành là công nhận
  hệ thống đạt đầy đủ yêu cầu của nó.
 Quá trình tích hợp hệ thống gồm:
  +Xây dựng hệ thống từ các thành phần của nó.
  +Kiểm thử hệ thống hợp thành với các vấn đề
  sau khi tương tác, giao tiếp giữa các thành phần.
 Bộ khung tổng thể của hệ thống được phát triển
  trước, cách thành phần gắn vào sau, gọi là top-
  down integration.
 Tích hợp các thành phần có cấu trúc bên dưới
  trước như: dịch vụ chung, mạng, truy cập csdl.
  Sau đó gắn thêm các thành phần chức năng, gọi
  là bottom-up integration.
 Vấn   để xảy ra trong suốt quá trình kiểm thử là
  những lỗi cục bộ(localising errors). Một khi có
  output bất thường được phát hiện thì khó có
  thể xác định được lỗi xảy ra ở đâu.
 Để xác định đúng vị trí lỗi ta nên kiểm thử
  tăng dần hệ thống.
 Ta nên tích hợp 1 hệ thống nhỏ trước và kiểm
  tra lại hệ thống này.
   ABCD là các thành phần(components)
   T1,T2,T3 là các kiểm thử.
   Test sequence 2 thực hiện lại các kiểm thử(regression
    testing) T1,2,3 nếu có lỗi thì chắc chắn là do tương tác
    với C.
   Ưu tiên tích hợp trước các thành phần được sử dụng
    nhiều cho các chức năng hệ thống.
 Kết luận:
 1)Kiểm thử tích hợp top-down phát hiện lỗi tốt
 hơn trong việc phê chuẩn kiến trúc của hệ
 thống. Và có thể chứng minh được hệ thống
 họat động tốt sớm hơn trong quá trình phát
 triển phần mềm.
 2) Sự thi hành của hệ thống thì kiểm thử tích
 hợp bottom-up là tốt hơn.
 Là   quá trình kiểm thử bản phát hành của hệ
  thống, sẽ được phân phối cho khách hàng.
 Mục đích chính của quá trình là làm tăng độ
  tin tưởng của hệ thống và đã đạt yêu cầu.
 Để chứng minh hệ thống đạt yêu cầu thì cần
  phải chỉ ra nó đã đạt các chức năng, hiệu
  suất, độ tin cậy, không bị lỗi khi sử dụng.
 Là quá trình kiểm thử hộp đen(black-box), các
  kiểm thử được lấy từ bảng mô tả chức
  năng(specification) của hệ thống.
 Testers không biết sự thi hành bên trong hệ
  thống(black-box). Họat động của nó được xác
  định bởi các inputs và outputs liên quan.
 Còn được gọi là kiểm thử chức năng vì các
  testers chỉ phải kiểm thử chức năng bên
  ngoài, không kiểm thử bên trong phần mềm.
 Nếu  outputs nằm ngoài dự đoán(tập Oe) thì
  xác định vấn đề này.
 Bằng kinh nghiệm, tài liệu chọn ra các test
  cases(tập Ie) dễ làm cho hệ thống họat động
  sai.
 Mộtsố kinh nghiệm của Whittaker:
 1)Chọn những inputs bắt buộc hệ thống
 phát sinh lỗi.
 2)Thiết kế các inputs làm cho vùng đệm
 inputs đó tràn.
 3)Lặp lại cùng 1 input hay 1 dãy inputs
 nhiều lần.
 4)Bắt buộc các outputs ngoài ý muốn phát
 sinh.
 5)Bắt buộc kết quả tính toán quá lớn hay
 quá nhỏ.
 Để  công nhận hệ thống đạt đủ các chức năng
  thì nên kiểm thử dựa trên kịch bản(scenario-
  based testing) đã được thực hiện trong lúc
  phát triển test cases.
 Nên xếp lại thứ tự các kịch bản của từng
  chức năng để kiểm thử, kịch bản quan trọng
  đặt trước, kịch bản ít sử dụng hoặc ngoại lệ
  đặt sau.
 Cóthể viết trước các report để kiểm thử với report
 của hệ thống.
 Các kiểm thử hiệu suất được thiết kế để
  đảm bảo hệ thống có thể xử lý được số
  lượng load dự định của nó.
 Bao gồm việc tạo các kiểm thử mà lượng
  load tăng dần cho đến khi hiệu suất hệ thống
  không thể chấp nhận.
 Kinh nghiệm cho thấy nên thiết kế các
  kiểm thử xung quanh những giới hạn của
  hệ thống. Còn được gọi là kiểm thử nhấn
  mạnh(stress testing). Tạo ra các yêu cầu
  nằm ngoài giới hạn phần mềm
 Ví dụ hệ thống có xử lý 300 giao dịch(giao
  dịch)/1giây.
 Kiểm  thử nhấn mạnh kiểm tra thiết kế số
 lần load lớn nhất cho đến khi hệ thống
 lỗi. Kiểu kiểm thử này có 2 chức năng:
 1)Trong mọi tình huống, hệ thống không
 nên bị mất dữ liệu hoặc mất các dịch vụ
 của người sử dụng. Chỉ có thể bị lỗi nhẹ.
 2)Phát hiện được sai sót của hệ thống mà
 ở tình huống bình thường không thấy.
(kiểm thử thành phần)
Component testing (kiểm thử thành phần) là
 một quá trình kiểm thử từng thành phần riêng
 biệt trong toàn hệ thống. Quá trình này diễn
 ra với mục đích tìm ra những thiếu sót, lỗi
 trong từng thành phần của toàn hệ thống.
 Như đã đề cập ở phần trước, trong suốt quá
 trình kiểm thử lỗi, người thiết kế thành phần
 nào sẽ có trách nhiệm kiểm tra lỗi thành phần
 đó.
 Có  3 loại thành phần được test trong bước
  này:
 1/ Những hàm con hoặc phương thức của
  từng đối tượng.
 2/ Các lớp đối tượng có nhiều thuộc tính và
  phương thức.
 3/ Các thành phần kết hợp với nhau tạo nên
  nhiều hàm hoặc đối tượng khác nhau. Những
  thành phần kết hợp này có giao thức được
  định nghĩa để sử dụng truy cập tất cả các
  chức năng của từng thành phần.
 _Những   hàm riêng hoặc phương thức được xem
  đơn giản nhất trong mỗi thành phần và thử
  nghiệm của bạn sẽ là tập hợp các cuộc gọi đến
  những hàm này với các thông số đầu vào khác
  nhau. Bạn có thể sử dụng những phương pháp
  tiếp cận để thiết kế những phép kiểm thử để thiết
  kế phép kiểm tra các hàm chức năng hoặc
  phương thức.
 _ Khi bạn đang thử nghiệm các lớp đối tượng,
  bạn nên thiết kế phép kiểm tra của mình phải bảo
  đảm kiểm tra đầy đủ tất cả các chức năng của đối
  tượng đó. Theo đó, việc kiểm tra lớp đối tượng
  bao gồm:
   1/ Các phép kiểm thử diễn ra trong sự độc lập với toàn bộ hoạt
    động liên kết với đối tượng.
   2/ Kiểm thử các thiết lập và truy vấn của toàn bộ thuộc tính liên
    kết với đối tượng.
   3/ Tất cả các sự kiện có thể làm thay đổi giá trị của đối tượng
    đều phải được mô phỏng.
    Xem xét cho ví dụ ở chương 14 có hình minh họa 23.6. Nó chỉ
    có 1 thuộc tính đơn để nhận dạng. Nó là 1 hằng số được thiết
    lập khi trạm thời tiết được cài đặt. Vì vậy bạn chỉ cần kiểm tra
    xem hằng số đó đã được thiết lập hay chưa. Bạn cần phải xác
    định những ca kiểm thử cho những bài báo cáo, hiệu chỉnh,
    khởi động và tắt. Thông thường các bài kiểm thử sẽ diễn ra độc
    lập giữa các phương thức, nhưng trong một số trường hợp thì
    khác. Ví dụ như khi muốn kiểm tra chức năng tắt thì trước hết ta
    phải khởi động mới kiểm tra tiếp được.
   Để kiểm tra trạng thái của trạm khí tượng, bạn sử
    dụng mô hình 14.14. Sử dụng mô hình này, bạn có
    thể xác định được trình tự thay đổi của các trạng thái
    đã được đưa vào kiểm tra và xác định được chuỗi sự
    kiện để khiến chúng có sự thay đổi trên. Về nguyên
    tắc, bạn nên kiểm tra từng quá trình thay đổi của
    từng trạng thái, nhưng trong thực tế kinh phí sẽ rất
    tốn kém. Một số ví dụ về các trình tự kiểm thử trong
    ví dụ trạm khí tượng :
     Tắt → Đợi xử lý → Tắt.
     Đợi → Hiệu chỉnh → Kiểm tra → Chuyển trạng thái
      → Đợi
     Đợi → Thu thập thông tin → Đợi → sơ lược →
      Chuyển trạng thái → Đợi
•  Nếu sử dụng tính thừa kế, thì điều này sẽ làm cho việc
   thiết kế các bài kiểm tra lớp đối tượng trở nên khó
   khăn hơn. Nơi mà một lớp được cung cấp các hoạt
   động được thừa kế bởi một số các lớp con khác, thì
   khi kiểm tra đến lớp đó ta phải kiểm tra toàn bộ các lớp
   mà nó đã thừa kế. Nguyên nhân của việc kiểm tra tất
   cả các lớp mà nó thừa kế là vì khi di truyền các
   phương thức thì trong một số trường hợp giả định nó
   sẽ làm thay đổi các họat động cũng như phương thức
   của các lớp khác.
 Tương tự khi một lớp thừa kế bị ghi đè bởi một phương
  thức hay thuộc tính khác thì nó phải được kiểm tra lại.
_  Khái niệm về lớp tương đương, được đề
 cập trong phần 23.3.2, cũng có thể áp dụng
 trong các lớp đối tượng. Các bài kiểm thử rơi
 trúng vào cùng lớp tương đương có thể sử
 dụng cùng một thuộc tính của đối tượng. Vì
 vậy, các lớp tương đương phải được xác
 định từ những bước khởi tạo, truy nhập, và
 câp nhật trong tất cả các thuộc tính của lớp
 đối tượng.
_ Nhiều phần trong hệ thống có những phương
  thức rất phức tạp hoặc những đối tượng kết hợp
  với nhau tạo ra nhiều mối ảnh hưởng liên tiếp.
  Như đã được đề cập ở chương 19, những chức
  năng được bao bọc bởi những kỹ thuật lập trình,
  và mình chỉ tiếp cận với những chức năng đó
  hoàn toàn thông qua những giao diện đã được
  xác định trước. Việc kiểm tra những thành phần
  kết hợp này liên quan chính thống với việc kiểm
  tra thành phần giao diện ứng xử theo đặc điểm
  kỹ thuật của chúng.
   _ Bước kiểm tra giao diện này là đặc biệt quan trọng
    trong hướng đối tượng và trong các bước thiết kế
    các thành phần cơ bản khác. Những thành phần và
    đối tượng được định nghĩa trước trong giao diện của
    chúng và có thể sử dụng lại để kết hợp tạo nên các
    thành phần khác trong hệ thống. Lỗi giao diện trong
    những thành phần kết hợp thì không thể phát hiện
    bằng cách kiểm thử các đối tượng riêng biệt hoặc
    các thành phần riêng biệt. Những lỗi có trong những
    thành phần kết hợp có thể sẽ phát sinh do tính thừa
    kế giữa các phần đã kết hợp với nhau.
   _ Có nhiều loại giao diện trong các thành phần chương
    trình nên kết quả sẽ tạo ra nhiều loại lỗi giao diện phát
    sinh, một số loại giao diện:
   1/ Giao diện hằng số
   2/ Giao diện chia sẻ bộ nhớ
   3/ Giao diện thủ tục
   4/ Giao diện gửi thông điệp.

   _ Những lỗi giao diện thường được coi như là những lỗi
    phức tạp nhất của hệ thống. Thường rơi vào 3 trường hợp:
   1/ Lạm dụng giao diện( interface misuse)
   2/ Gọi sai giao diện( interface misunderstanding).
   3/ Timing errors.
   _ Việc kiểm thử những thiếu sót trong giao diện là khó vì
    những lỗi giao diện này thường lộ ra trong những điều
    kiện khác thường. Ví dụ, một đối tượng sử dụng hàng đợi
    queue với cấu trúc dữ liệu đã thiết kế sẵn. Mà một đối
    tượng khác gọi đến và sử dụng queue này nhưng không
    kiểm tra xem queue có rỗng không mà đưa dữ liệu vào sẽ
    dẫn đến lỗi. Lỗi này chỉ được phát hiện khi ta đem so kết
    quả kiểm thử với kết quả chứa trong queue.
   _Những sự cố khác sẽ nảy sinh bởi sự ảnh hưởng lẫn
    nhau giữa các bộ phận và đối tượng. Những lỗi của một
    đối tượng có thể phát hiện khi một đối tượng khác xử lý
    sai. Ví dụ như khi một đối tượng cần xử lý thông tin và gọi
    cho một đối tượng khác có chức năng xử lý thông tin đó
    và trả về kết quả sai.
 Mục đích của quy trình thiết kế kiểm thử là tạo ra
  1 bộ các ca kiểm thử hiệu quả trong việc phê
  chuẩn và kiểm thử sai sót.
 Những phương pháp tiếp cận để thiết kế kiểm
  thử:
1.Kiểm thử dựa trên yêu cầu-Requirements-based
  testing
2.Kiểm thử phân vùng-Patition testing.
3.Kiểm thử cấu trúc-Structural testing.
_ Nguyên tắc kiểm thử chung của các yêu cầu kĩ
thuật là yêu cầu đó phải khả thi trong việc kiểm
thử.
_ Kiểm thử dựa trên yêu cầu là một kỹ thuật kiểm
thử phê chuẩn. Xem xét mỗi yêu cầu và tạo ra
kiểm thử cho yêu cầu đó.
_ Xem xét yêu cầu trong ví dụ LIBSYS.
              LIBSYS requirements
+ Người dùng có thể tìm thấy các thiết lập gốc trong database
và chọn một phần nhỏ trong đó.
+ Hệ thống sẽ cung cấp góc nhìn thích hợp cho người dùng để
đọc những tài liệu trong kho dữ liệu
+ Mỗi yêu cầu sẽ được cấp một định dạng (Order_ID) mà người
dùng có thể sao chép vào khu dữ liệu.
               LIBSYS Test
_ Khởi đầu việc tìm kiếm của người dùng là xác định xem
  phần đó có tồn tại hay không trong tập hợp cơ sở dữ
  liệu bao gồm một cơ sở dữ liệu.
_ Khởi nguồn việc tìm kiếm của người dùng là xác định
  xem phần đó có tồn tại hay không trong tập hợp cơ sở
  dữ liệu bao gồm hai cơ sở dữ liệu.
_ Bắt đầu việc tìm kiếm của người dùng là xác định xem
  phần đó có tồn tại hay không trong tập hợp cơ sở dữ
  liệu bao gồm hơn hai cơ sở dữ liệu.
_ Chọn một cơ sở dữ liệu và một cuộc tìm kiếm của người
  dùng và xác định chúng có tồn tại hay không.
_ Chọn nhiều hơn một cơ sở dữ liệu và nhiều cuộc tìm
  kiếm hơn của người dùng và xác định chúng có tồn tại
  hay không.
   _ Bạn có thể thấy việc kiểm thử yêu cầu không có
    nghĩa là chỉ viết một ca kiểm thử cho yêu cầu đó mà
    bạn phải nhiều ca kiểm thử cho một yêu cầu mới có
    thể khái quát được yêu cầu đó.
   _ Kiểm thử yêu cầu trong hệ thống LIBSYS có thể
    được phát triển bằng phương pháp như vậy. Ở yêu
    cầu thứ 2, bạn sẽ viết kiểm thử để phân phối tài liệu
    cho hết các kiểu mà hệ thống xử lý và bảo đảm chúng
    phải được hiển thị. Yêu cầu thứ ba thì đơn giản hơn.
    Để kiểm thử yêu cầu này, bạn có thể mô phỏng đặt
    yêu cầu và xem chúng có được hệ thống nhận dạng
    và có hiện diện trong bản xác nhận của người dùng và
    có tồn tại duy nhất không.
 Còn  được gọi là kiểm thử hộp trắng.
 Nguồn gốc của các ca kiểm thử là dựa theo
  cấu trúc của chương trình. Hiểu biết chương
  trình thì có thể xác định được các ca kiểm
  thử.
 Mục đích là kiểm thử tất cả các câu lệnh của
  chương trình.
                Dữ liệu
                kiểm thử



Các kiểm thử     Lấy



               Code thành   Các output
               phần         kiểm thử
 Điều kiện trước thỏa, phần tử khóa trong mảng.
 Điều kiện trước thỏa, phần tử khóa không trong
  mảng.
 Điều kiện trước không thỏa, phần tử khóa trong
  mảng
 Điều kiện trước không thỏa, phần tử khóa không
  trong mảng
 Mảng đầu vào có 1 giá trị.
 Mảng đầu vào có những giá trị chẵn.
 Mảng đầu vào có những giá trị lẻ.
 Mục   đích kiểm thử đường đi là để chắc rằng
  mỗi hướng đi của chương trình được thực
  thi ít nhất 1 lần
 Điểm bắt đầu của kiểm thử đường đi nằm ở
  biểu đồ dòng chương trình. Nodes đại diện
  cho mỗi dòng lệnh của chương trình. Các
  cung đại diện cho dòng điều khiển
 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 14
 1, 2, 3, 4, 5, 14
 1, 2, 3, 4, 5, 6, 7, 11, 12, 5, …
 1, 2, 3, 4, 6, 7, 2, 11, 13, 5, …
 Các ca kiểm thử nên lấy từ kết quả của
  những đường đi trên.
 Phân tích động chương trình có thể được sử
  dùng để kiểm tra những đường đi trên.
 Kiểm thử phần mềm là giai đoạn khó nhọc và
  tốn nhiều tiền trong tiến trình làm phần mềm.
 Vì vậy, những công cụ test được phát triển,
  những công cụ này đưa ra một phạm vi thuận
  lợi để có thể giảm bớt chi phí test một cách
  đáng kể.
 Những hệ thống như JUnit hỗ trợ sự thực
  hiện tự động của quá trình test.
 Một chu trình kiểm thử phần mềm là sự tổng hợp
  những công cụ để hỗ trợ quá trình kiểm thử,
 để hỗ trợ quá trình kiểm thử, một chu trình kiểm
  thử có thể bao gồm nhiều công cụ để mô phỏng
  những phần khác nhau của hệ thống và phát sinh ra
  những dữ liệu để kiểm thử hệ thống.
 Test manager: quản lý sự vận hành của
  chương trình test, theo dõi dữ liệu, những kết
  quả và những điều kiện thuận lợi mà chương
  trình được kiểm thử.
 Test data generator: phát sinh ra những dữ
  liệu thực nghiệm cho chương trình để test.
  điều này có thể được thực hiện bằng việc lựa
  chọn dữ liệu từ cơ sở dữ liệu hay bằng cách
  sử dụng mẫu để phát sinh dữ liệu ngẫu nhiên
  phù hợp.
 Oracle: phát sinh ra những dự đoán của
  những kết quả kiểm thử được mong đợi.
  Oracle có thể là những phiên bản chương
  trình trước đây hay hệ thống đầu tiên.
 File comparator: so sánh kết quả của quá
  trình test với kết quả test trước đó và rút ra
  báo cáo về sự khác nhau giữa chúng.
 Report generator: cung cấp báo cáo định
  nghĩa và phương tiện phát sinh cho kết quả
  test.
   Dynamic analyser: thêm mã vào một chương
    trình để đếm số lần mỗi câu lệnh được thực thi.
    sau khi test, một cấu hình thực thi được phát sinh
    chỉ ra mỗi câu lệnh trong chương trình được thực
    thi có thường hay không.
   Simulator: nhiều chưong trình mô phỏng khác
    nhau được cung cấp. Mục tiêu những trình mô
    phỏng là mô phỏng bộ máy mà chương trình thực
    thi. Những trình mô phỏng giao diện người dùng
    là những chương trình hướng kịch bản có mổ
    phỏng giao tiếp với người dùng. Sử dụng trình
    mổ phỏng cho nhập xuất(I/O) đồng nghĩa với việc
    các giao dịch bị lập lại.
 Khi sử dụng cho hệ thống test lớn, những
  công cụ này phải được cấu hình phù hợp cho
  hệ thống đặc biệt được test.
 Test chỉ có thể hiển thị những lỗi hiện tại trong
  chương trình. nó không thể chứng minh rằng
  không còn những lỗi, thiếu sót còn lại.
 Những người phát triển thành phần chịu trách
  nhiệm về test thành phần, test hệ thống là
  trách nhiệm của một đội riêng biệt.
 Sự thử hợp nhất là những sự thử tăng dần
  của hệ thống, sự thử phiên bản bao gồm
  kiểm tra một hệ thống được gửi tới khách
  hàng.
 Sử dụng kinh nghiệm và hướng dẫn để chọn
  trường hợp kiểm thử mà có hiệu quả trong
  việc tìm ra những khuyết điểm trong những
  hệ thống khác.
 Test giao diện được thiết kết để tìm ra những
  khuyết điểm trong giao diện của những thành
  phần phức.
 Phân chia tương đương là cách tìm ra những
  trường hợp test.
 Test cấu trúc dựa trên phân tích một chương
  trình và thu được những test từ sự phân tích
  này.
 Test automation giảm bớt chi phí Test bằng
  việc hỗ trợ quá trình test với một phạm vi của
  những công cụ phần mềm.

								
To top