Báo cáo MÔN HỌC Nhập môn công nghệ phần mềm

Báo cáo MÔN HỌC: Nhập môn công nghệ phần mềm Báo cáo MÔN HỌC: Nhập môn công nghệ phần mềm Báo cáo MÔN HỌC: Nhập môn công nghệ phần mềm Báo cáo MÔN HỌC: Nhập môn công nghệ phần mềm

HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG

Khoa Công nghệ thông tin

Báo cáo

MÔN HỌC: Nhập môn công nghệ phần mềm

NHÓM MÔN HỌC: 11 Giảng viên: Đặng Ngọc Hùng

Nhóm sinh viên thực hiện: nhóm 23

Hà Nội năm 2022

Chương 15: Luồng công việc thực thi

1 Khái niệm và mục tiêu nghiên cứu

- Luồng công việc thực thi là quá trình chuyển đổi từ quá trình thiết kế chi tiếtthành mã nguồn ngôn ngữ lập trình Trên thực tế đối với dự án phần mềmphức tạp và có quy mô lớn, việc thực hiện cả luồng công việc thực thi vớimột cá nhân là điều rất khó và đòi hỏi sự hợp tác của nhiều lập trình viên vớinhau Sản phẩm khi đó sẽ được thực thi bởi một nhóm, làm việc đồng thờitrên các thành phần khác nhau nhỏ hơn của sản phẩm

- Mục tiêu

 Tìm hiểu luồng công việc thực thi trong kỹ thuật lập trình

 Tìm hiểu các kĩ thuật kiểm thử hộp đen (black-box), kiểm thử hộp thuỷtinh (white-box) và kiểm thử phi thực thi (non-execution-based)

 Tìm hiểu các loại tích hợp (integration testing), kiểm thử sản phẩm(product testing) và kiểm thử chấp nhận (acceptance testing)

 Đánh giá các tiêu chuẩn và các giải pháp tốt trong kỹ thuật lập trình

 Vấn đề bảo trì: việc thực thi các sản phẩm mới bằng Java vẫn phải đảmbảo việc bảo trì những sản phẩm cũ viết bằng COBOL Việc quản lý haiphân lớp lập trình viên khác nhau là không hề dễ dàng bởi vấn đề bấtđồng có thể xảy ra khi lập trình viên Java thường được trả lương cao hơn

do nhân lực lúc đầu khan hiếm

 Vấn đề chi phí: Quá trình tuyển dụng và đào tạo lập trình viên bằng ngônngữ mới sẽ tốn rất nhiều kinh phí và thời gian của công ty Mặt kháccông ty sẽ phải tốn thêm một khoản để đầu tư các thiết bị phần cứng,phần mềm phục vụ việc lập trình bằng ngôn ngữ mới

 Quá trình chuyển đổi lựa chọn ngôn ngữ lập trình mới có thể gây ra nhiềuhậu quả về tài chính cũng như nhân lực cho doanh nghiệp.

- Khi sản phẩm khó hoặc không thể được thực thi bằng ngôn ngữ lập trình sẵncó: vấn đề lựa chọn ngôn ngữ lập trình khác phù hợp hoặc mạnh mẽ hơn làđiều cần thiết để phù hợp với yêu cầu sản phẩm của khách hàng Việc thựchiện lựa chọn này ví dụ có thể đánh giá theo các cách sau:

 Đánh giá theo chi phí: Doanh nghiệp phải tính toán chi phí cần phải đầu

tư để thực hiện dự án theo từng loại ngôn ngữ khả dụng Ngôn ngữ lậptrình phù hợp nhất sẽ cho lợi nhuận cao và chi phí thực hiện nhỏ nhất

 Đánh giá theo rủi ro: Xét các rủi ro có thể gặp phải và phương hướng giảiquyết Ngôn ngữ lập trình phù hợp nhất là ngôn ngữ cho rủi ro thấp nhất

3 Ngôn ngữ lập trình thế hệ thứ 4

- Thế hệ thứ nhất: Ở thời kì sơ khai của lập trình phần mềm, chưa hề có kháiniệm trình biên dịch hay thông dịch, phần mềm được viết bằng mã nhị phân,hoặc bảng mạch và switch

- Thế hệ thứ 2: hợp ngữ ra đời khiến và hoạt động bằng cách dịch hợp ngữsang mã máy Việc lập trình và bảo trì trở nên dễ dàng hơn tuy nhiên độ dài

mã chương trình vẫn tương tự mã máy

- Thế hệ thứ 3: ý tưởng của ngôn ngữ lập trình thế hệ thứ 3 là các loại ngônngữ bậc cao như C, C++, Pascal hoặc Java khiến cho việc lập trình trở nên

dễ dàng hơn khi mỗi dòng mã có thể biên dịch và thực thi thay cho 5-10dòng mã máy Tuy nhiên việc bảo trì các phần mềm viết bằng hợp ngữ thờiđiểm này lại tốn ít chi phí hơn

- Thế hệ thứ 4: ý tưởng của ngôn ngữ lập trình thứ 4 có từ những cuối năm

1970 Mục tiêu của việc thiết kế ngôn ngữ thế hệ thứ 4 (4GL) này là mỗidòng mã sẽ tương đương với 30-50 dòng mã máy Vì thế giúp rút ngắn quátrình phát triển sản phẩm và khiến việc bảo trì dễ dàng hơn

1 Các quy chuẩn phổ biến khi lập trình

1.1.Sử dụng tên biến thích hợp và có nghĩa

- Việc đặt tên biến thích hợp và có nghĩa là vô cùng quan trọng với việc bảotrì phần mềm do thành phần mã được viết ra bởi một lập trình viên sẽ có thểbảo trì bởi nhiều hơn 1 người, việc bảo trì sẽ dàng và tiết kiệm chi phí hơnnếu các tên biến được đặt theo đúng quy chuẩn ngay từ khi thực thi

- Các quy chuẩn đặt tên biến:

 Đặt tên biến thích hợp: chọn duy nhất một tên biến có nghĩa hay vì nhiềutên biến đều cùng chỉ một đối tượng Ví dụ không nên dùng cả tên biến là

average và medium trong cùng một chương trình bởi chúng có nghĩa

gần tương đương

 Đồng bộ thứ tự cách đặt tên biến: nếu đã chọn một thứ tự cho các thànhphần trong tên biến, thì các tên biến tương tự cũng phải tuân theo thứ tự

đó Ví dụ: “frequencyMax” thì không nên dùng cách đặt tên

“minFrequency” cho giá trị min Thay vì đó hãy đồng bộ thành

 Mã tự chú thích: là cách viết mã có tính mô tả cao và có thể hiểu mộtcách dễ dàng mà không cần chú thích Tuy nhiên lập trình viên có thểviết cách này khá hiếm

- Các vấn đề gặp phải khi không chú thích mã:

 Với các lập trình viên thiếu kinh nghiệm việc viết mã không đảm bảochất lượng là hoàn toàn có thể xảy ra, điều này khiến việc thực thi và bảotrì trở nên khó khăn hơn

 Với đoạn mã không có chú thích nếu giả dụ có thay đổi nhân sự thì nhân

sự mới sẽ gặp khó khăn khi làm việc với đoạn mã có sẵn

1.3.Sử dụng tham số

- Tại sao nên sử dụng tham số để gán giá trị hằng số:

 Sử dụng tham số khiến hằng số trở nên có ý nghĩa thay vì những con sốkhông rõ ràng

 Tránh việc vô tình thay đổi giá trị biến khiến sinh ra lỗi trong phần mềmhoặc cho kết quả không chính xác

 Việc thay đổi giá trị hằng số sẽ dễ dàng hơn vì dùng tham số tương quanthay vì cố định

1.4.Sắp xếp bố cục mã nguồn hợp lý

- Với sự ra đời của các IDE hiện đại có chức năng định dạng được tích hợpsẵn thì việc sắp xếp bố cục mã nguồn càng dễ dàng hơn Tuy nhiên ta vẫnnên xem xét các tiêu chí để sắp xếp:

 Thụt lùi đầu dòng và sử dụng ngoặc

 Nên viết mỗi câu lệnh trên một dòng

 Sử dụng dòng trống để phân cách các đoạn mã

1.5.Câu lệnh điều kiện lồng nhau

- Ta đánh giá cách sử dụng các câu lệnh điều kiện if lồng nhau qua các trườnghợp sau đây:

 TH1 (Figure 15.3): bố cục mã trong sơ đồ 15.3 sắp xếp rất rối và thiếu

 TH2 (Figure 15.4): Cấu trúc bố cục mã dễ đọc hơn tuy việc lồng nhiềucâu điều kiện if else khiến việc kiểm tra tính đúng đắn của đoạn mã trởnên khó khăn

 TH3 (Figure 15.5): Sử dụng phương pháp đơn giản hóa điều kiện if-ifphức tạp bằng toán tử &&

 Sử dụng câu lệnh lặp lồng nhau sao cho bố cục hợp lí và có thể đơn giảnhoá bằng các toán tử nếu có thể, không nên dùng quá 3 câu điều kiện iflồng nhau.

5 Vấn đề quy chuẩn lập trình

- Quy chuẩn lập trình có thể vừa có lợi vừa gây khó khăn Theo định nghĩa từtrước với các module thực hiện nhiều và đa dạng các hoạt động không liênquan đến nhau, thường đặt ra những luật như “mỗi module phải được viếttrong khoảng 35-50 dòng câu lệnh thực thi” Hay nói một cách khác rõ rànghơn là “lập trình viên phải báo với quản lý nếu muốn xây dựng một module

ít hơn 35 hoặc nhiều hơn 50 dòng lệnh thực thi” Những quy chuẩn áp đặtnhư vậy thường bị bỏ qua

- Khác với với những quy chuẩn chung và phổ biến như với câu lệnh điềukiện if không nên được đặt lồng nhau quá 3 lần Lập trình viên thườngkhông tuân thủ theo những quy chuẩn lập trình mà họ không hiểu tại sao lạiđược áp dụng Hơn thế nữa, việc áp đặt các quy chuẩn lập trình có thể gây ra

sự mâu thuẫn nội bộ giữa quản lý và lập trình viên

- Quy chuẩn lập trình có thể được đặt ra bởi đơn vị quản lý chất lượng phầnmềm Việc sử dụng các quy chuẩn lập trình khiến giai đoạn bảo trì dễ dànghơn Tuy nhiên việc áp dụng nó cũng khiến công đoạn lập trình trở nên khókhăn hơn với những quy chuẩn quá ngặt nghèo và phức tạp sẽ khiến hiệusuất và tiến độ làm việc của dự án bị chậm lại

- Thay vì đó nếu có thể áp dụng quy chuẩn lập trình vào hệ thống kiểm tra tựđộng mà máy tính có thể kiểm tra như: kiểm tra lệnh if, số dòng, hay mãlệnh sử dụng, … sẽ nâng cao chất lượng phần mềm đáng kể

6 Tái sử dụng các đoạn mã

- Việc tái sử dụng (reuse) là tương đối quan trọng trong ngành lập trình phầnmềm Thời gian và chi phí có thể được tiết kiệm được đáng kể nếu có thể ápdụng việc tái sử dụng lên các tiêu chí dự án như: yêu cầu chức, kế hoạch,thiết kế, và các đoạn mã

- Đặc biệt tái sử dụng các đoạn mã trong quá trình thực thi là vô cùng cầnthiết và quan trọng.

 driver: là một đoạn mã phục vụ mục đích kiểm thử gọi một thành phần

mã một hoặc nhiều lần, nếu có thể kiểm tra kết quả đầu ra

- Xét sơ đồ tích hợp sau đây:

 Nếu muốn kiểm thử thành phần mã a ta cần phải gộp và kiểm thử cả 3thành phần mã b, c, d như một stub

 Nếu muốn kiểm thử thành phần mã h ta cần có một driver gọi nó

 Tương tự nếu muốn kiểm thử thành phần mã d ta cần một driver và 2stubs

 Điều này khiến quá trình thực thi trở nên khó khăn khi quá trình thựchiện sẽ tốn rất nhiều công sức thiết lập stubs và drivers Chưa kể, nếu quátrình thực thi hoàn thành trước khi quá trình tích hợp, việc phát hiện vàđịnh vị lỗi gần như không thể thực hiện với các dự án lớn

 Đòi hỏi cần phải có sự kết hợp giữa kiểm thử đơn vị và tích hợp

1.2.Tích hợp Top-Down

- Trong tích hợp top-down, nếu thành phần phía bên trên giao tiếp và gọithành phần bên dưới thì thành phần bên trên phải được thực thi và tích hợptrước thành phần bên dưới

- Ưu điểm của tích hợp top-down:

 Hỗ trợ cô lập và tìm lỗi: do các thành thành phần sẽ được thực thi và tíchhợp theo thứ tự từ trên xuống, khi thêm một thành phần hoặc liên kết mộtthành phần khác vào bộ khung sẵn có, nếu có lỗi xảy ra ta có thể xác địnhngay lỗi có thể xảy ra ở thành phần liên kết với nó hoặc chính nó

 Có thể phát hiện lỗ hổng thiết kế sớm hơn: thứ tự sắp xếp thành thànhphần để kiểm thử và tích hợp sẽ chắc chắn rằng các thành phần logic sẽluôn luôn hoạt động ổn định

- Nhược điểm của tích hợp top-down:

 Có khả năng các thành phần được tái sử dụng sẽ không được kiểm thửtương đối như nhau nếu được giả sử là thành phần không sinh lỗi và sẽ bị

bỏ qua Nhưng trên thực tế có thể xảy ra các trường hợp phát sinh các lỗikhông ngờ đến

 Dễ gặp rủi ro khi các thành thành phần điều hành tái sử dụng mà khôngđược kiểm thử kỹ lưỡng Lý do là các thành thành phần điều hành thường

ở tầng dưới của kiến trúc tích hợp top-down và số lần được kiểm thử sẽ íthơn so với tầng trên

1.3.Tích hợp Bottom-up

- Trong tích hợp bottom-up, nếu thành phần bên trên giao tiếp với và gọithành phần bên dưới thì thành phần bên dưới sẽ được thực thi và tích hợptrước thành phần bên trên

- Tích hợp bottom-up:

 Ưu điểm: những thành thành phần điều hành (operational artifacts) sẽđược kiểm thử một cách toàn diện qua các driver kiểm thử Vì thế giảibài toán của tích hợp top-down bởi cơ chế bắt lỗi dễ dàng

 Nhược điểm: các thành phần logic (logic artifacts) sẽ là các thành phầnđược tích hợp cuối cùng Do đó nếu có phát hiện lỗi thiết kế nghiêmtrọng nào đó trong giai đoạn cuối của dự án sẽ khiến quy trình làm việc

bị thay đổi hoặc cần trả một chi phí lớn cho việc tái thiết kế lại một phầnlớn của sản phẩm

1.4.Tích hợp Sandwich

- Xét lược đồ 15.7 trên hình, ta thấy 6 thành phần logic (tô màu xám) đượctích hợp theo kiểu top-down, còn 7 thành phần điều hành (tô màu hồng)được tích hợp theo kiểu bottom-up

- Việc áp dụng kiến trúc kiểu này bởi là khi nếu dùng duy nhất kiến trúc down hoặc bottom-up đều sẽ không phù hợp với sản phẩm, giải pháp đưa ra

top-là phải phân vùng chúng Hai phần được kiểm thử một cách riêng biệt theokiến trúc tích hợp của chúng, và khi ghép lại các giao thức giữa 2 nhóm sẽđược kiểm thử từng phần đầy đủ

1.5.Quá trình tích hợp của hướng đối tượng

- Sản phẩm thiết kế theo hướng đối tượng có thể được tích hợp theo cả bằngcách top-down hoặc bottom-up

 Tích hợp theo top-down: các stub sẽ được sử dụng cho mỗi phương phápgiống với các module

 Tích hợp theo bottom-up: các đối tượng độc lập sẽ được thực thi và tíchhợp đầu tiên, sau đó đến các đối tượng mà chúng giao tiếp gọi các đốitượng khác, cứ tích hợp như vậy cho đến khi sản phẩm hoàn chỉnh

 Tích hợp theo sandwich: tích hợp sandwich cũng có thể sử dụng tuỳ theotừng thuộc tính từng thành phần, hay tuỳ theo thuộc tính của ngôn ngữ

lập trình Có nhiều biến thể của tích hợp sandwich có thể được sử dụngtrong chương trình hướng đối tượng.

đi sự đồng bộ và thông báo cho các bên liên quan, khiến cho việc tích hợpgặp vấn đề và tốn thêm thời gian và chi phí để giải quyết

- Để giải quyết vấn đề không tương thích như trên, cả quá trình tích hợp phảiđược vận hành bởi nhóm SQA (quản lý chất lượng phần mềm) Nhiệm vụcủa nhóm SQA là đảm bảo quá trình tích hợp phải diễn ra thuận lợi và hoànthành đồng thời quyết định xem thành thành phần nào được tích hợp theokiểu nào và phụ trách phân chia công việc tích hợp cho mỗi lập trình viên

Nhóm SQA phải lên kế hoạch kiểm thử tích hợp trong kế hoạch quản

lý dự án phần mềm, đồng thời có trách nghiệm thực thi kế hoạch đó Kếtthúc giai đoạn tích hợp, tất cả những thành thành phần đã được kiểm thửđược tích hợp thành một sản phẩm hoàn chỉnh

8 Luồng công việc thực thi

- Nhiệm vụ của luồng công việc thực thi là triển khai đối tượng sản phẩmphần mềm bằng ngôn ngữ lập trình được chọn Chính xác hơn là, một sảnphẩm phần mềm lớn sẽ được phân mảnh ra thành các hệ thống nhỏ hơn, sau

đó được thực thi song song bởi các nhóm Các hệ thống nhỏ hơn bao gồmnhững thành phần hoặc các thành phần mã

- Sau khi các thành phần mã đã được viết, lập trình viên sẽ kiểm thử thànhphần đó, khái niệm đó gọi là kiểm thử đơn vị (unit testing) Sau khi đã kiểmthử xong, lập trình viên chuyển thành phần mã xuống đơn vị quản lý chấtlượng phần mềm để kiểm thử sâu hơn Giai đoạn kiểm thử sau đó được thựchiện trong luồng công việc kiểm thử

9 Luồng công việc kiểm thử trong thực thi

- Trong luồng công việc thực thi, nhiều loại kiểm thử sẽ được thực hiện:

 Kiểm thử đơn vị

 Tích hợp

 Kiểm thử sản phẩm

 Kiểm thử chấp nhận

- Các thành phần mã sẽ được kiểm thử bằng 2 loại kiểm thử:

 Kiểm thử không hợp cách (informal unit testing): thực hiện bởi lập trìnhviên khi viết thành phần mã

 Kiểm thử hợp cách (methodical unit testing): thực hiện bởi đơn vị quản

lý chất lượng phần mềm Kiểm thử hợp cách có 2 loại: kiểm thử thực thi

và kiểm thử không thực thi

10 Lựa chọn Test Case

 Việc lựa chọn test case rất quan trọng trong quá trình kiểm thử Bởi vì sẽ có

vô vàn khả năng xảy ra và việc test hết tất cả các khả năng là vô cùng lãngphí Điều cần làm là cần xây dựng các test case một cách có hệ thống

1 Kiểm thử dựa trên đặc điểm và kiểm thử đoạn mã

- Dữ liệu cho việc kiểm thử có thể được xây dựng bằng 2 cách:

 Kiểm thử đặc điểm: với cách tiếp cận này, thành phần sẽ bị bỏ qua, phầnquan tâm duy nhất để tạo test case là tài liệu đặc tả Còn được gọi là kiểmthử hộp đen (black-box), kiểm thử hành vi (behavioral), kiểm thử hướng

dữ liệu (data-driven), kiểm thử hàm (functional), kiểm thử hướng vào ra(input/output driven)

 Kiểm thử mã: chỉ kiểm thử thành phần và phần tài liệu đặc tả sẽ bị bỏ quakhi lựa chọn test case Còn được gọi là kiểm thử hộp thuỷ tinh, kiểm thửhộp trắng, kiểm thử có cấu trúc, kiểm thử hướng logic

2. Tính khả thi của kiểm thử đặc điểm

- Ta xét: Các đặc tả cho dữ liệu một trạng thái của sản phẩm có các loại phiếugiảm giá và các mẫu mã sản phẩm Giả sử sản phẩm có 5 mẫu mã khác nhau

và có 7 loại phiếu giảm giá khác nhau cần được áp dụng Kiểm thử tất cả các

tổ hợp giữa các mẫu mã sản phẩm và phiếu giảm giá ta được 35 test cases

Sẽ là vô nghĩa nếu coi loại mẫu mã và phiếu giảm giá được tính toán và xử

lý ở trong 2 thành phần riêng biệt và nên được kiểm thử riêng biệt Trongkiểm thử hộp đen, sản phẩm được coi như một hộp đen - có nghĩa là cấu trúcbên trong của nó hoàn toàn không được xét

- Với số lượng sản phẩm và số các loại phiếu giảm giá càng nhiều thì số lượngkết quả giá sản phẩm tính ra càng vô cùng lớn Tương tự với nếu xét nhiềunhân tố hơn thì sẽ có vô số test case và rất tốn thời gian để có thể kiểm thửđược hết số lượng test case đó

 Vì vậy kiểm thử đặc điểm đầy đủ là không khả thi trên thực tế bởi sốlượng test case khả thi là vô cùng lớn Vì vậy kiểm thử mã được đưa vàoxem xét.

3. Tính khả thi của kiểm thử mã

- Hình thức phổ biến nhất của kiểm thử mã là kiểm thử tất cả các trường hợp(các đường đi) trong đoạn mã Để xem xét tính khả thi của kĩ thuật kiểm thửnày, xem xét một biểu đồ hoạt động sau:

- Mặc dù biểu đồ hoạt động trông có vẻ đơn giản, tuy nhiên xét kỹ hơn nó cóhơn 10^12 đường đi Có 5 đường đi khả thi trong nhóm 6 hộp được tô màuxám và sau đó được lặp 18 lần, ta tính được tổng số đường đi khả thi trongbiểu đồ hoạt động như sau:

=> Với một lần lặp đã có số đường đi rất lớn, nếu xét những thànhphần có độ phức tạp và quy mô lớn hơn thì việc kiểm thử mã cũnghoàn toàn không khả thi giống như kiểm thử đặc điểm

- Kiểm thử đòi hỏi việc kiểm thử tất cả các đường đi khả thi Tuy nhiên cókhả năng xảy ra khi kiểm thử tất cả các đường đi vẫn không thể phát hiệnđược lỗi Ta xét ví dụ sau:

- Đoạn mã này có nhiệm vụ kiểm tra tính tương đương của 3 số dựa trên mộtlogic sai: nếu trung bình của 3 số bằng số đầu tiên thì 3 số đó bằng nhau.Dựa trên 2 test case cho sẵn thì đoạn mã này sẽ được cho là chạy đúng Tuynhiên nếu dùng một test case khác chưa được xét là x = 2 y = 1, z = 3 thìđoạn mã sẽ có lỗ hổng và sai lệch.

- Ví dụ trên cho ta thấy rằng xem xét tất cả các đường đi trong phần mềm làkhông tin cậy, bởi vì phần mềm có thể tồn tại những đường đi gây sai lệchchưa được xét Tuy vậy, kiểm thử hướng đường đi là hoàn toàn hợp lệ

bởi vì nó vốn dĩ không loại trừ việc chọn dữ liệu kiểm thử có thể phát hiệnlỗi

 Bởi vì sự đa dạng tổ hợp dữ liệu, cả kiểm thử mã đầy đủ và kiểm thử đặcđiểm đầy đủ đều không khả thi Cần có một phương pháp để có thể pháthiện lỗi nhiều nhất có thể, mặc dù có thể không đảm bảo việc phát hiệntất cả các lỗi Một phương pháp hợp lý đó là sử dụng kiểm thử hộp đensau đó tạo thêm các test case bằng phương pháp hộp thuỷ tinh

11 Kĩ thuật kiểm thử hộp đen

 Kiểm thử hộp đen đầy đủ có thể yêu cầu hàng tỷ test case Vì vậy phươngthức yêu cầu đặt ra là để tạo một tập hợp các test case nhỏ, tối ưu hoá khảnăng phát hiện lỗi trong khi giảm khả năng lãng phí test case khi phát hiệnlỗi giống nhau, mỗi test case cần độc lập về khả năng phát hiện lỗi

1 Kiểm thử tương đương và phân tích giá trị giới hạn

- Giả sử một cơ sở dữ liệu chứa thông tin về các sản phẩm và có thể chứa cácbản ghi từ 1-16383 Khoảng từ 1-16383 được gọi là lớp tương đương bởi vìnếu test case một sản phẩm trong khoảng 1-16383 vẫn có thể hoạt động tốt,thì test case những sản phẩm có khoảng xung quanh sẽ tương tự Để chuẩnxác hơn, ta sẽ chia số lượng bản ghi thành 3 lớp tương đương

 Nhỏ hơn 1 bản ghi

 Từ 1 đến 16383 bản ghi

 Lớn hơn 16383 bản ghi

- Kiểm thử cơ sở dữ liệu sử dụng kĩ thuật lớp tương đương sẽ yêu cầu mỗi testcase từ mỗi lớp tương đương sẽ được chọn.

- Để tối đa hoá khả năng tìm được lỗi nên sử dụng kĩ thuật phân tích giá trịgiới hạn Trong khoảng từ (R1, R2) được liệt kê từ đầu ra hoặc đầu vào đặcđiểm, có 5 test cases nên được chọn, các giá trị nhỏ hơn R1, bằng R1, lớnhơn R1 và nhỏ hơn R2, bằng R2, lớn hơn R2 Khi chỉ ra một đơn vị thuộcmột tập, thì 2 lớp tương đương nên được xét là lớp chứa đơn vị đó và lớpkhông chứa đơn vị đó

 Việc sử dụng lớp tương đương cùng với phân tích giá trị giới hạn nhằmkiểm thử các đặc điểm đầu vào và đặc điểm đầu ra của một phương thứccho việc sinh các tập dữ liệu test nhỏ với mục tiêu tìm ra nhiều nhiều lỗinhất có thể nếu các cách chọn test cases mạnh mẽ hơn không được ápdụng

2. Kiểm thử chức năng

- Một dạng kiểm thử khác của kiểm thử hộp đen là xây dựng dữ liệu test dựatrên chức năng của đoạn mã Trong kiểm thử chức năng, mỗi đơn vị củachức năng hoặc hàm được triển khai ở trong thành phần sẽ được định danh.Một ví dụ điển hình của quản lý nhà kho sẽ có những hàm như:

 get_next_database_record

 determine_whether_quantity_on_hand_is_below_the_reorder_point

- Sau khi xác định được tất cả các hàm của thành phần, dữ liệu test sẽ đượcxây dựng dựa trên các hàm khác nhau Từ đây, nếu các thành thành phầnbao gồm các hàm gọi các hàm con, kết nối bởi cấu trúc điều khiển của lậptrình cấu trúc, khi đó kiểm thử chức năng sẽ được thực hiện đệ quy

- Trên thực tế, các hàm cha không được xây dựng theo một cấu trúc từ cáchàm con Thay vì đó, các hàm con thường được đan xen vào nhau theo mộtcách nào đó Để có thể tìm được các lỗi và lỗ hổng trong trường hợp này,phân tích chức năng cần được thực hiện theo một chu trình khá phức tạp

- Một nhân tố làm tăng tính phức tạp đó là các chức năng thường xuyên khôngtrùng hợp với các ranh giới thành phần Vì thế sự phân biệt giữa kiểm thửđơn vị và tích hợp trở nên một cách thiếu quan trọng hơn: một đoạn mãkhông thể kiểm thử đồng thời nếu không kiểm thử một đoạn mã khác chứachức năng mà nó sử dụng Vấn đề này cũng có thể xảy ra trong mô hìnhhướng đối tượng khi một phương thức của một đối tượng gọi một phươngthức của đối tượng khác

 Các quan hệ ngẫu nhiên giữa các thành phần theo cách nhìn của kiểm thửchức năng có thể tạo ra những hậu quả không chấp nhận được cho việcquản lý Ví dụ như việc quản lý cột mốc dự án hoặc deadline có thể trở

thành một thứ khó xác định được, trở thành chướng ngại cho việc xácđịnh trạng thái của sản phẩm theo kế hoạch quản lý dự án phần mềm.

12 Case study Tổ chức MSG: Các test case kiểm thử hộp đen

Test cases kiểm thử hộp đen cho case study Tổ chức MSG:

- Biểu đồ 15.13 và 15.14 minh hoạ các test cases kiểm thử hộp đen cho casestudy tổ chức MSG Đầu tiên xem xét các test cases nhận được từ các lớptương đương và phân tích giá trị giới hạn Test case đầu tiên trong biểu đồ15.13 kiểm tra xem sản phẩm có phát hiện lỗi nếu biến itemName (tên) củamột khoản đầu tư không bắt đầu bằng một chữ cái 5 test cases tiếp theo kiểmtra xem biến itemName có giá trị độ dài từ 1 – 25 kí tự hay không Các testcases tương tự còn lại kiểm tra các mô tả đặc điểm khác

- Với kiểm thử hàm, có 10 hàm được liệt kê ở trong tài liệu đặc tả, như đượcminh hoạ ở biểu đồ 15.14 Có tổng cộng 11 test cases liên quan đến việc sửdụng các hàm này

- Nên biết rằng các test cases ở đây có thể được phát triển ngay khi giai đoạnphân tích hoàn thành Lý do mà nó được đề cập ở nội dung luồng thực thi là

nó có liên quan đến chủ đề lựa chọn test case Cấu tạo chính của mọi kế hoạchkiểm thử nên là một quy định rằng kiểm thử hộp đen nên được thực hiện ngaykhi quá trình phân tích đã được phê duyệt, nhằm thuận tiện cho nhóm SQAtrong luồng công việc thực thi