bài 2. quy trình phát triển phần mềm

Ưu điểm: Đây là một mô hình tương đối tổng quát Mọi thứ được xác định cận thận và chặt chẽ  Khi bàn giao cho các tester , phần mềm đã khá hoàn chỉnh, và sẽ không thay đổi gì cho đến

BÀI 2 QUY TRÌNH PHÁT TRIỂN

 Tài liệu thiết kế phần mềm

 Tài liệu kiểm thử

 Test plan

 Test case list

 Bug report Test tool

2.1.1 THÀNH PHẦN CỦA PHẦN MỀM

Các thành phần tạo nên một sản phẩm phần mềm:

 Help files

 User's manual

 Samples and examples

 Labels and stickers

 Product support info

 Icons and art

2.1.2 NHÂN LỰC CỦA DỰ ÁN

 Tuy thuộc vào công ty, dự án thành phần này còn thay đổi

 Cơ bản, gồm các thành phần:

Project managers, program managers, hoặc producers

Architects or system engineers

Programmers, developers, or coders

Testers hoặc Quality Assurance

Technical writers, user assistance, user education, manual writers, or illustrators

Configuration management or builder

BIG - BANG

Tuân theo học thuyết tạo ra vũ trụ từ vụ nổ Big – bang Tất cả nỗ lực dành cho việc viết code

CODE – AND – FIX

Ý tưởng:

CODE – AND – FIX

 Ý tưởng:

 Áp dụng:

 Với các dự án nhỏ

 Khi sản phẩm được tung ra thị trường trong một thời gian ngắn

 Ưu: - Nhanh, tốn ít chi phí

 Nhược:

 Chưa kịp test xong version cũ đã lại update version mới

 Một số đặc trưng bị bỏ qua => rủi ro

Không được phép back up (giai

đoạn trước hoàn thành mới

được phép tiến hành tiếp giai

đoạn sau)

Ưu điểm:

Đây là một mô hình tương đối tổng quát

Mọi thứ được xác định cận thận và chặt chẽ

 Khi bàn giao cho các tester , phần mềm đã khá

hoàn chỉnh, và sẽ không thay đổi gì cho đến khi

kiểm thử xong => thuận lợi cho các tester lập kế hoạch, và thực hiện test.

Nhược điểm:

 Trong thời đại ngày nay, mọi thứ đều thay đổi rất

nhanh => Nếu quá cận trọng, đôi khi phần mềm

sẽ không theo kịp sự thay đổi

Khi bàn giao cho các tester , phần mềm đã khá

hoàn chỉnh => nếu có một lỗi xuất hiện từ rất

sớm, nhưng đến giai đoạn cuối này mới phát hiện

=> chi phí để fix lỗi là rất lớn

Chú ý:

Trong thực tế: các dạng biến thể của waterfall được

áp dụng (một số quy tắc được nới lỏng)

 Không có sự chồng chéo các giai đoạn

 Có thể back up được

cho đến khi thu được sản

phẩm cuối cùng

 Mỗi lần lặp của Spiral gồm 6 bước:

1 Determine objectives, alternatives, and constraints.

2. dentify and resolve risks

3 Evaluate alternatives.

4. Develop and test the current level

5. Plan the next level

6 Decide on the approach for the next level.

Ưu điểm:

 Mô hình dễ hiểu và dễ thực hiện

 Có rất nhiều dự án đã thành công với mô hình này

TỔNG KẾT

như thế nào, cái gì bên trong chúng và quy trình

được sử dụng để liên kết chúng với nhau

khác nữa và biến thể của chúng Mỗi công ty, mỗi

dự án và mỗi đội sẽ chọn mô hình phù hợp với họ

Công việc của tester là kiểm tra phần mềm để nó

2.2.1 PHƯƠNG CHÂM CỦA VIỆC

KIỂM THỬ

Chân lý của quá trình kiểm thử phần mềm (ST): (“rules of

the road” hay “facts of life”)

1 Tester đảm bảo 1 chương trình là hoàn hảo là điều không thể thực hiện được Vì:

 Số lượng các dữ liệu có thể là input là rất lớn

 Số lượng các dữ liệu có thể là output cũng vô cùng lớn

 Số lượng các “lối đi” (path) trong phần mềm là rất lớn

 Đặc tả phần mềm có tính chất chủ quan Bạn có thể nói rằng lỗi

là những khuyết điểm dưới con mắt của độc giả.

2.2.1 PHƯƠNG CHÂM CỦA VIỆC

KIỂM THỬ

 Chân lý của quá trình kiểm thử phần mềm:

2 Testing là 1 bài kiểm tra phụ thuộc vào sự rủi ro

 Nếu không kiểm tra hết các trường hợp => sẽ đến lúc

khách hàng phát hiện ra những lỗi bị bỏ quên => chi phí

để khắc phục là rất lớn

 Do vấn đề về thời gian, kinh phí và tính khả thi => không

thể test được hết các trường hợp => rủi ro

 Lựa chọn những trường hợp test ít rủi ro nhất => đâu là

vấn đề quan trọng?

2.2.1 PHƯƠNG CHÂM CỦA VIỆC

KIỂM THỬ

 Chân lý của quá trình kiểm thử phần mềm:

2 Testing là 1 bài kiểm tra phụ thuộc vào sự rủi ro

 Nếu cố kiểm tra mọi thứ => chi phí quá lớn

 Nếu cắt giảm công việc kiểm thử => bỏ quên

nhiều lỗi

 Vậy, phải lựa chọn được các trường hợp kiểm

thử tối ưu => đảm bảo không phải kiểm thử

quá nhiều hay quá ít => optimal amount of testing

2.2.1 PHƯƠNG CHÂM CỦA VIỆC

KIỂM THỬ

 Chân lý của quá trình kiểm thử phần mềm:

3 Testing không thể tìm thấy những lỗi không tồn tại?

 Các hình thức của lỗi:

 đang tồn tại (live bug)

 đã được sửa (dead bug)

 hoặc còn đang tiềm ẩn (nest)

 Nếu bạn đã cố gắng kiểm tra nhưng không tìm thấy lỗi => không có nghĩa là phần mềm không có lỗi => kết luận: lỗi chưa được phát hiện

2.2.1 PHƯƠNG CHÂM CỦA VIỆC

KIỂM THỬ

 Chân lý của quá trình kiểm thử phần mềm:

4 Một số lỗi được phát hiện, tự đó tester suy luận ra một số lỗi

khác:

 Lập trình viên cũng có lúc làm việc tốt, cũng có lúc không

được minh mẫn

 Lập trình viên cũng mắc lỗi theo thói quen

 Tester phát hiện ra 1 số lỗi, tưởng rằng chúng không có

quan hệ với nhau => nhưng chúng lại đều xuất phát từ cùng 1 lỗi rất nguy hiểm

2.2.1 PHƯƠNG CHÂM CỦA VIỆC

KIỂM THỬ

5 The Pesticide Paradox: Thuật ngữ này dùng để mô tả việc

tìm lỗi phần mềm giống như việc dùng thuốc trừ sâu

(Pesticide) diệt côn trùng

2.2.1 PHƯƠNG CHÂM CỦA VIỆC

KIỂM THỬ

 Chân lý của quá trình kiểm thử phần mềm:

6 Không phải tất cả các lỗi mà bạn phát hiện sẽ được sửa

 không có nghĩa rằng: bạn đã làm sai, hay bạn sẽ giao cho khách hàng 1 sản phẩm kém chất lượng => lựa chọn sửa những lỗi chứa nhiều rủi ro nhất

 Một số lý do khiến lỗi không được fix:

 Không đủ thời gian

 Không hẳn là lỗi

 Có quá nhiều rủi ro khi sửa lỗi

 Không đáng để phải sửa

2.2.1 PHƯƠNG CHÂM CỦA VIỆC

KIỂM THỬ

Chân lý của quá trình kiểm thử phần mềm:

6 Không phải tất cả các lỗi mà bạn phát hiện sẽ được sửa

 Những người đưa ra quyết định lỗi nào được fix:

2.2.1 PHƯƠNG CHÂM CỦA VIỆC

KIỂM THỬ

Chân lý của quá trình kiểm thử phần mềm:

7 Một “vấn đề” tồn tại nhưng không ai phát hiện, hoặc

không được chú ý tới:

 Có được gọi là lỗi không?

 Duyệt theo 5 quy tắc phát hiện lỗi

 Latent bug

2.2.1 PHƯƠNG CHÂM CỦA VIỆC

KIỂM THỬ

 Chân lý của quá trình kiểm thử phần mềm:

8. Xây dựng spec là công việc không bao giờ kết thúc

 Mọi thứ luôn thay đổi mau lẹ => Spec cũng phải biến đổi

linh hoạt

 Ví dụ:

 Các feature thay đổi liên tục, không trong kế hoạch =>

bạn đã test xong, và sẵn sàng báo cáo lỗi, những feature lại thay đổi hoàn toàn

 Cần có kỹ thuật kiểm thử linh hoạt

2.2.1 PHƯƠNG CHÂM CỦA VIỆC

KIỂM THỬ

 Chân lý của quá trình kiểm thử phần mềm:

9 Tester không phải là thành viên được coder chờ đợi trong một dự án

 Nhiệm vụ của 1 tester là gì?

 Tester phê bình công việc của đồng nghiệp, công khai những vấn

đề tìm thấy, cố gắng chiến thắng trong các cuộc tranh luận

 Tester cần giữ thái độ hòa bình với đồng nghiệp:

 Phát hiện lỗi thật sớm

 Giữ thái độ hăng hái nhiệt tình

 Đừng chỉ báo cáo những thông tin xấu

2.2.1 PHƯƠNG CHÂM CỦA VIỆC

KIỂM THỬ

Chân lý của quá trình kiểm thử phần mềm:

10 ST là một công việc đòi hỏi tính kỷ luật cao

 Tester trở thành lực lượng lòng cốt, những thành viên

sống còn trong nhiệm vụ xây dựng các phần mềm có chất lượng cao

 Tester trở thành một nghề nghiệp được nhiều người lựa

chọn và cần phải được đào tạo

 Tester làm việc có kỷ luật và thúc đẩy sự tiến bộ.

2.2.2 CÁC ĐỊNH NGHĨA VÀ THUẬT

NGỮ CỦA ST

Phân biệt các thuật ngữ:

1 Precision (tập chung) và accuracy (chính xác)

2 Verification (sự kiểm tra) và Validation (sự xác nhận)

3 Quality (chất lượng) và reliability (sự tin cậy)

4 Testing (Kiểm thử) và quality assurance (đảm bảo chất

lượng) (QA)

2.2.2 CÁC ĐỊNH NGHĨA VÀ THUẬT

NGỮ CỦA ST

1. Precision (tập chung) và accuracy (chính xác):

Hình trên mô tả sự khác nhau giữa 2 thuật ngữ

2.2.2 CÁC ĐỊNH NGHĨA VÀ THUẬT

NGỮ CỦA ST

2. Verification (sự kiểm tra) và Validation (sự xác

nhận):

 Vào 4/1990, Kính thiên văn không gian Hubble được

đưa vào quỹ đạo quanh trái đất

 Verification: kiểm tra bản đặc tả đã chính xác chưa

 Validation: Cần thực hiện việc xác nhận lại sản phẩm

cuối cùng so với bản đặc tả

2.2.2 CÁC ĐỊNH NGHĨA VÀ THUẬT

NGỮ CỦA ST

3 Quality (chất lượng) và reliability (sự tin cậy):

 Dường như 2 khái niệm này là tương tự nhau: 1 sản phẩm

 Sản phẩm Quality và Reliability thì phải thực hiện verification

và validation trong suốt quá trình phát triển sản phẩm

2.2.2 CÁC ĐỊNH NGHĨA VÀ THUẬT

NGỮ CỦA ST

4 Testing (Kiểm thử) và quality assurance (đảm bảo

chất lượng) (QA):

 Mục đích của testing là tìm ra lỗi, tìm thấy chúng sớm nhất

có thể, và đảm bảo rằng chúng đã được sửa.

 Trách nhiệm chính của người QA là tạo và bắt phần mềm

phải tuân theo các chuẩn để cải tiến quy trình phát triển phần mềm và ngăn chặn các lỗi xuất hiện bất cứ lúc nào

 2 khái niệm này có sự chồng chéo

Validation Verification

Integration Testing

System Testing

Delivery production deployment

User Acceptance Testing

Maintenance and enhancement

2.2.3 MÔ HÌNH CHỮ V

Unit test planning

Integration test planning

System test planning UAT planning

2.3 QUÁ TRÌNH NGHIÊN CỨU ĐẶC TẢ

PHẦN MỀM

 2.3.1 Kiểm tra đặc tả ở mức cao

 2.3.2 Kiểm tra đặc tả ở mức thấp

2.3.1 KIỂM TRA BẢN ĐẶC TẢ Ở

MỨC CAO

 Bước đầu là xem xét spec ở mức cao

 => nghiên cứu chi tiết từng vấn đề

 => để hiểu rõ hơn về phần mềm và chức năng của

nó

 => yêu cầu sửa những điểm chưa hợp lý

 => phục vụ cho quá trình kiểm thử

a) Nếu bạn là một khách hàng:

của phần mềm

cho quá trình test

2.3.1 KIỂM TRA BẢN ĐẶC TẢ Ở

MỨC CAO

b) Nghiên cứu về những Standard và Guideline

 Thời kỳ đầu của Microsoft Windows và Apple Macintosh:

 => xây dựng lên các standard và guideline

 Standard là chuẩn đã được thông qua => bắt buộc phải

tuân theo

 Guideline là những hướng dẫn, không bắt buộc, nhưng

cũng nên tuân theo

2.3.1 KIỂM TRA BẢN ĐẶC TẢ Ở

MỨC CAO

b) Nghiên cứu về những Standard và Guideline

 Khi xây dựng một phần mềm, một số Standard và Guideline sẽ

được lựa chọn:

 Các thuật ngữ và các quy ước của các tổ chức (Corporate

Terminology and Conventions)

 Nhu cầu của ngành công nghiệp (Industry Requirements)

 Chuẩn về chính quyền (Government Standards)

 Giao diện đồ họa người dùng (Graphical User Interface – GUI)

 Tiêu chuẩn về sự bảo mật (Security Standards)

2.3.1 KIỂM TRA BẢN ĐẶC TẢ Ở

MỨC CAO

b) Nghiên cứu về những Standard và Guideline

 Lựa chọn các standard và guideline là công việc của các

người quản lý hoặc người viết bản đặc tả

 Tester phải hiểu về các standard và guideline này, và xác

minh lại xem nó được áp dụng trên phần mềm như thế nào (coi chúng như 1 phần của bản đặc tả)

2.3.1 KIỂM TRA BẢN ĐẶC TẢ Ở

MỨC CAO

c) Kiểm tra những phần mềm tương tự

 Cách thức tốt nhất để tìm hiểu cái mà phần mềm của bạn cần đạt đến là nghiên cứu những phần mềm tương tự

 Một số điểm cần xem xét trên các phần mềm cạnh tranh:

 Tỷ lệ (scale): feature, code

 Sự phức tạp (complexity)

 Khả năng kiểm thử (testability): thời gian, chuyên môn, tài nguyên

 Chất lượng / tính tin cậy (quality / reliability)

 Bảo mật (security)

2.3.1 KIỂM TRA BẢN ĐẶC TẢ Ở

MỨC CAO

c) Kiểm tra những phần mềm tương tự

 Những kinh nghiệm trên các phần mềm tương tự => rất có

ích cho quá trình kiểm tra bản đặc tả

 Đánh giá độ bảo mật của các phần mềm tương tự => so sánh

=> đựa ra mức độ bảo mật phù hợp

2.3.1 KIỂM TRA BẢN ĐẶC TẢ Ở

MỨC CAO

a) Danh mục những thuộc tính của bản đặc tả

b) Những thuật ngữ của bản đặc tả

2.3.2 KIỂM TRA BẢN ĐẶC TẢ Ở

MỨC THẤP

a) Danh mục những thuộc tính của bản đặc tả:

 Hoàn thiện (complete):

 Chính xác (accurate):

 Rõ ràng, chính xác, không mập mờ và trong sáng (Precise,

Unambiguous, and Clear):

b) Những thuật ngữ của bản đặc tả

 Luôn luôn, mọi thứ, tất cả, không một ai, không bao

giờ (Always, every, all, none, never)

 Tất nhiên, bởi vậy, chắc hẳn rồi, hiển nhiên, rõ ràng

(Certainly, Therefore, Clearly, Obviously, Evidently)

 Vân vân, và cứ tiếp tục ở phía trước, và cứ tiếp tục

như vậy, ví dụ (Etc., And So Forth, And So On, Such

As)

2.3.2 KIỂM TRA BẢN ĐẶC TẢ Ở

MỨC THẤP

b) Những thuật ngữ của bản đặc tả

 Tốt, nhanh, rẻ, hiệu quả, nhỏ gọn, ổn định (Good,

Fast, Cheap, Efficient, Small, Stable)

 Danh hiệu, quy trình, loại bỏ, bỏ qua, loại trừ

(Handled, Processed, Rejected, Skipped, Eliminated)

 Nếu … thì … nhưng không có trường hợp còn lại (If…

Then…but missing Else)

2.3.2 KIỂM TRA BẢN ĐẶC TẢ Ở

MỨC THẤP

TỔNG KẾT

 Đây là cuốn sách giới thiệu những người muốn nhanh chóng có thể kiểm thử được một bản đặc tả Những nội dung được mô tả

ở phần này sẽ là cánh tay đắc lực trợ giúp tìm ra những khuyết

điểm trong những bản đặc tả mà bạn phải kiểm thử.

 Dạng của bản đặc tả có thể rất rộng Bạn nên áp dụng những

kỹ thuật trong chương này, kiểm tra một sơ đồ mức cao, phân

tích những cú pháp câu Bạn sẽ tìm thấy lỗi.

Bạn muốn tìm hiểu nhiều kỹ thuật mở rộng: www.mfagan.com.

BÀI 2 CÂU HỎI

1. Tên một số nhiệm vụ sẽ được thực thi trước

khi lập trình viên viết các dòng code đầu tiên với từng mô hình?

2. Bạn sẽ gặp phải những khó khăn nào nếu bạn

muốn xây dựng một bản đặc tả chính thức và

chốt lại bản đặc tả đó (formal, locked-down

specification)?

BÀI 2 CÂU HỎI

3. Đâu là feature tốt nhất của mô hình big – bang?

4. Khi sử dụng mô hình code – and – fix, phần

mềm như thế nào là đủ để giao tới tay khách hàng?

5. Tại sao mô hình waterfall khó sử dụng?

6. Tại sao các tester thích mô hình spiral hơn các

mô hình khác?

BÀI 2 CÂU HỎI

7. Bắt đầu với Windows Calculator Hãy gõ vào 5,000 – 5

= (dấu phẩy là rất quan trọng) Và nhìn kết quả Đây có phải là lỗi không? Tại sao có và tại sao không?

8 Có thể tồn tại một sản phẩm có quality nhưng lại không

có reliability? Hãy lấy ví dụ?

9 Hãy giải thích một tester nên lo ngại điều gì với dòng đặc tả như sau: Phần mềm sẽ cho phép trên 100 triệu kết nối đồng thời, mặc dù bình thường sẽ không có

nhiều hơn 1 triệu kết nối.