After a product has been successful

After a product has been successfully maintained for many years, it eventually may lose
its usefulness and be superseded by a totally different product, in much the same way that
electronic valves were replaced by transistors. Alternatively, a product still may be useful,
but the cost of porting it to new hardware or running it under a new operating system may
be more than the cost of constructing a new product, using the old one as a prototype. So,
fi nally, the software product is decommissioned and removed from service. Only at that
point, when the software has been irrevocably discarded, is it time to stop testing.
Now that all the necessary background material has been covered, objects can be examined in greater detail. This is the subject of Chapter 7 .
Chapter
Review
A key theme of this chapter is that testing must be carried out in parallel with all activities of the
software process. The chapter begins with a description of quality issues (Section 6.1). Next, nonexecution-based testing is described (Section 6.2), with a careful discussion of walkthroughs and
inspections. This is followed by a defi nition of execution-based testing (Sections 6.3 and 6.4) and
a discussion of behavioral properties of a product that must be tested, including utility, reliability,
robustness, performance, and correctness (Sections 6.4.1 through 6.4.5). In Section 6.5, correctness proving is introduced and an example of such a proof is given in Section 6.5.1. The role of
correctness proofs in software engineering then is analyzed (Sections 6.5.2 and 6.5.3). Another
important issue is that systematic execution-based testing must be performed by the independent
SQA group and not by the programmer (Section 6.6). Finally, the issue of when testing can fi nally
stop is discussed in Section 6.7.
sch76183_ch06_154-182.indd 176 04/06/10 1:28 PM
Chapter 6 Testing 177
For
Further
Reading
The attitude of software producers to the testing process has changed over the years, from viewing testing as a means of showing that a product runs correctly to the modern attitude that testing
should be used to prevent requirements, analysis, design, and implementation faults. This progression
is described in [Gelperin and Hetzel, 1988]. The nature of software testing and the reasons why it is
so hard are discussed in [Whittaker, 2000]. The pervasiveness of faults is described in [Lieberman and
Fry, 2001]. Ways to reduce the number of faults appear in [Boehm and Basili, 2001].
Whittaker and Voas [2000] present an interesting theory of reliability. Having an effective requirements workfl ow can have a positive impact on software quality; this is shown in [Damian and Chisan,
2006]. The quality of open-source software is reviewed in [Aberdour, 2007].
A standard technique of correctness proving uses the so-called Hoare logic, as described in [Hoare,
1969]. An alternative approach to ensuring that products satisfy their specifi cations is to construct the
product stepwise, checking that each step preserves correctness. This is described in [Dijkstra, 1968]
and [Wirth, 1971]. An important article regarding acceptance of correctness proofs by the software
engineering community is [DeMillo, Lipton, and Perlis, 1979]. Interesting views on correctness proving are given in [Hinchey et al., 2008].
The IEEEStandard for Software Reviews [IEEE 1028, 1997] is an excellent source of information
on non-execution-based testing. Experiments evaluating inspections of a large-scale software product
are described in [Perry et al., 2002]. Vitharana and Ramamurthy [2003] suggest that inspections should
be anonymous and computer mediated. The impact of group process support on inspections is presented
in [Tyran and George, 2002]. The selection of inspection team members is discussed in [Miller and Yin,
2004]. A review of inspections is given in [Parnas and Lawford, 2003], and the state of the practice is described in [Ciolkowski, Laitenberger, and Biffl , 2003]. Object-oriented code inspections are discussed
in [Dunsmore, Roper, and Wood, 2003]. The cost-effectiveness of inspections is presented in [Freimut,
Briand, and Vollei, 2005]. Tailoring inspections to an organization’s needs is described in [Denger and
Shull, 2007]. Design and code reviews conducted over the Internet are presented in [Meyer, 2008]. An
experiment to test the value of the checklists is described in [Hatton, 2008].
The classic work on execution-based testing is [Myers, 1979], a work that has had a signifi cant
impact on the fi eld of testing. [DeMillo, Lipton, and Sayward, 1978] remains an excellent source of
information on selection of test data. [Beizer, 1990] is a compendium on testing, a true handbook on
the subject. [Ammann and Offutt, 2008] is strongly recommended as an introduction to testing.
Turning specifi cally to the object-oriented paradigm, [Kung, Hsia, and Gao, 1998] is a book on
object-oriented testing, and so is [Sykes and McGregor, 2000].
The proceedings of the IEEE International Symposium on Software Testing and Analysis cover
a similar broad spectrum of testing issues. The April 2005 ofIEEE Transactions on Software Engineering contains a variety of papers from the 2004 Symposium. Two articles of particular interest are
[Ostrand, Weyuker, and Bell, 2005], which describes a method for predicting the location and number
of faults in large software products, and [Fu, Milanova, Ryder, Wonnacott, 2005] on the robustness
testing of Java server applications. The July–August 2006 issue ofIEEE Software contains a wide
variety of papers on testing.

Kết quả (Việt) 1:

Sau khi một sản phẩm đã được duy trì thành công trong nhiều năm, nó cuối cùng có thể mấttính hữu dụng của nó và được thay thế bởi một sản phẩm hoàn toàn khác nhau, trong nhiều giống cách đóVan điện tử được thay thế bằng bóng bán dẫn. Ngoài ra, một sản phẩm vẫn có thể hữu ích,nhưng chi phí porting nó vào phần cứng mới hoặc sử dụng nó theo một hệ điều hành mới có thểlà nhiều hơn chi phí xây dựng một sản phẩm mới, bằng cách sử dụng một tuổi như một mẫu thử nghiệm. Vì vậy,Fi nally, sản phẩm phần mềm được cho ngừng hoạt động và rút khỏi phục vụ. Chỉ lúc đóđiểm, khi các phần mềm đã không bị loại bỏ, đó thời gian để ngừng thử nghiệm. Bây giờ mà tất cả các tài liệu cần thiết nền đã được bao phủ, các đối tượng có thể được kiểm tra chi tiết hơn. Đây là chủ đề của chương 7. ChươngĐánh giáMột chủ đề quan trọng của chương này là rằng thử nghiệm phải được tiến hành song song với tất cả các hoạt động của cácquy trình phần mềm. Chương bắt đầu với một mô tả của vấn đề chất lượng (phần 6.1). Tiếp theo, nonexecution dựa trên thử nghiệm là miêu tả (phần 6.2), với một cuộc thảo luận cẩn thận của walkthroughs vàkiểm tra. Điều này được theo sau bởi một nition defi thực hiện dựa trên thử nghiệm (phần 6.3 và 6.4) vàmột cuộc thảo luận về các tính chất hành vi của một sản phẩm mà phải được kiểm tra, bao gồm cả Tiện ích, độ tin cậy,mạnh mẽ, hiệu suất, và đúng đắn (phần 6.4.1 thông qua 6.4.5). Trong phần 6.5, chứng minh tính đúng đắn được giới thiệu và một ví dụ về một chứng minh được đưa ra trong phần 6.5.1. Vai trò củađúng đắn chứng minh trong công nghệ phần mềm sau đó là phân tích (phần 6.5.2 và 6.5.3). Khácvấn đề quan trọng là rằng hệ thống dựa trên thực hiện kiểm tra phải được thực hiện bởi độcSQA nhóm và chứ không phải bởi các lập trình viên (phần 6.6). Cuối cùng, vấn đề khi thử nghiệm có thể fi nallydừng được thảo luận trong phần 6.7.sch76183_ch06_154-182.indd 176 04/06/10 1:28 PMChương 6 thử nghiệm 177 ChoXem thêmĐọcThái độ của nhà sản xuất phần mềm cho quá trình thử nghiệm đã thay đổi trong những năm qua, xem thử nghiệm như là một phương tiện Hiển thị rằng một sản phẩm chạy một cách chính xác để Thái độ hiện đại là thử nghiệmnên được sử dụng để ngăn chặn yêu cầu, phân tích, thiết kế và thực hiện lỗi. Tiến trình nàyđược mô tả trong [Gelperin và Hetzel, 1988]. Bản chất của kiểm thử phần mềm và lý do tại sao nó làkhó khăn như vậy được thảo luận trong [Whittaker, 2000]. Pervasiveness của lỗi được mô tả trong [Lieberman vàFry, 2001]. Cách để giảm số lỗi xuất hiện trong [Boehm và Basili, 2001]. Whittaker và Voas [2000] trình bày một lý thuyết thú vị về độ tin cậy. Có một hiệu quả yêu cầu workfl ow có thể có một tác động tích cực trên phần mềm chất lượng; Điều này hiển thị trong [Damian và Chisan,Năm 2006]. chất lượng của phần mềm mã nguồn mở được xem xét trong [Aberdour, 2007]. Một kỹ thuật tiêu chuẩn của tính chính xác minh sử dụng cái gọi là lý Hoare, như mô tả trong [Hoare,1969]. một cách tiếp cận khác để đảm bảo rằng sản phẩm đáp ứng của cation thuật là để xây dựng cácsản phẩm stepwise, kiểm tra rằng mỗi bước duy trì đúng đắn. Điều này được mô tả trong [Dijkstra, 1968]và [Wirth, 1971]. Một bài báo quan trọng liên quan đến sự chấp nhận của chứng minh tính đúng đắn của phần mềmkỹ thuật cộng đồng là [DeMillo, Lipton, và Perlis, 1979]. Các quan điểm thú vị về tính chính xác minh được đưa ra trong [Hinchey et al., 2008]. IEEEStandard để đánh giá phần mềm [IEEE 1028, 1997] là một nguồn tuyệt vời của thông tintrên không-thực hiện dựa trên thử nghiệm. Thí nghiệm đánh giá kiểm tra một sản phẩm phần mềm quy mô lớnđược mô tả trong [Perry et al., 2002]. Vitharana và Hanh [2003] đề nghị rằng nên kiểm trađược ẩn danh và máy tính trung gian. Tác động của nhóm hỗ trợ quá trình trên kiểm tra trình bàytại [Tyran và George, 2002]. Việc lựa chọn thành viên trong đội kiểm tra được thảo luận trong [Miller và âmNăm 2004]. một bài đánh giá kiểm tra được đưa ra trong [Parnas và Lawford, 2003], và nhà nước của các thực hành được mô tả trong [Ciolkowski, Laitenberger, và Biffl, 2003]. Kiểm tra mã đối tượng theo định hướng được thảo luận[Dunsmore, Roper, và gỗ, 2003]. Tiết kiệm chi phí kiểm tra được trình bày trong [Freimut,Briand, và Vollei, 2005]. May các kiểm tra với nhu cầu của tổ chức được mô tả trong [Denger vàShull, 2007]. Đánh giá thiết kế và mã thực hiện qua Internet được trình bày trong [Meyer, 2008]. MộtCác thử nghiệm để kiểm tra giá trị của các danh sách kiểm tra được mô tả trong [Hatton, 2008]. Các tác phẩm cổ điển về thực hiện dựa trên thử nghiệm là [Myers, 1979], một tác phẩm đã có một không thể signifitác động đến eld fi của thử nghiệm. [DeMillo, Lipton, và Sayward, 1978] vẫn là một nguồn tuyệt vời củathông tin về các lựa chọn của dữ liệu thử nghiệm. [Beizer, 1990] là một bản trích yếu về kiểm thử, một cẩm nang thực sự trênCác chủ đề. [Ammann và Offutt, 2008] khuyến khích mạnh mẽ như là một giới thiệu về thử nghiệm. Chuyển mạng cally để các đối tượng theo định hướng mô hình, [Kung, Hsia, và cao, 1998] là một cuốn sách trênhướng đối tượng thử nghiệm, và như vậy là [Sykes và McGregor, 2000]. Các thủ tục tố tụng của hội nghị chuyên đề quốc tế IEEE về kiểm thử phần mềm và phân tích bao gồmmột phổ rộng tương tự như kiểm tra vấn đề. Tháng 4 năm 2005 ofIEEE giao dịch trên công nghệ phần mềm có chứa một loạt các giấy tờ từ hội nghị chuyên đề năm 2004. Hai bài báo quan tâm đặc biệt là[Ostrand, Weyuker, và chuông, 2005], đó mô tả một phương pháp để dự đoán vị trí và sốlỗi trong các sản phẩm phần mềm lớn, và [Fu, Milanova, Ryder, Wonnacott, 2005] trên mạnh mẽthử nghiệm Java máy chủ ứng dụng. Tháng bảy-tháng tám 2006 vấn đề ofIEEE phần mềm chứa một rộngloạt các bài báo về thử nghiệm.

Kết quả (Việt) 2:

Sau khi một sản phẩm đã được duy trì thành công trong nhiều năm, cuối cùng nó có thể mất đi
tính hữu dụng của nó và được thay thế bởi một sản phẩm hoàn toàn khác nhau, trong nhiều cách mà
van điện tử được thay thế bởi bóng bán dẫn. Ngoài ra, sản phẩm vẫn có thể hữu ích,
nhưng chi phí của porting nó vào phần cứng mới hoặc chạy nó dưới một hệ điều hành mới có thể
được nhiều hơn chi phí xây dựng một sản phẩm mới, sử dụng một trong những cũ như là một nguyên mẫu. Vì vậy,
fi nally, các sản phẩm phần mềm được cho ngừng hoạt động và gỡ bỏ khỏi dịch vụ. Chỉ lúc đó
điểm, khi các phần mềm đã được loại bỏ không thể hủy bỏ, nó là thời gian để ngừng thử nghiệm.
Bây giờ tất cả các vật liệu nền cần thiết đã được bảo hiểm, đối tượng có thể được xem xét chi tiết hơn. Đây là chủ đề của Chương 7.
Chương
xét
Một chủ đề chính của chương này là khảo nghiệm phải được tiến hành song song với các hoạt động của
quá trình phần mềm. Chương này bắt đầu với một mô tả về vấn đề chất lượng (Phần 6.1). Tiếp theo, kiểm tra nonexecution dựa trên được mô tả (Phần 6.2), với một cuộc thảo luận cẩn thận walkthroughs và
kiểm tra. Tiếp theo là một Định nghĩa Defi thử nghiệm thực hiện dựa trên (mục 6.3 và 6.4) và
thảo luận về tính chất hành vi của một sản phẩm đó phải được kiểm tra, bao gồm tiện ích, độ tin cậy,
vững mạnh, hiệu suất và tính đúng đắn (mục 6.4.1 qua 6.4 0,5). Trong Phần 6.5, minh tính đúng đắn được giới thiệu và một ví dụ về một bằng chứng như vậy được đưa ra trong mục 6.5.1. Vai trò của
các chứng minh tính đúng đắn trong công nghệ phần mềm sau đó được phân tích (mục 6.5.2 và 6.5.3). Một
vấn đề quan trọng là kiểm tra thực hiện dựa trên hệ thống phải được thực hiện bởi tổ chức độc lập
nhóm SQA và không phải bởi các lập trình viên (Phần 6.6). Cuối cùng, vấn đề khi thử nghiệm có thể fi nally
dừng được thảo luận trong Phần 6.7.
sch76183_ch06_154-182.indd 176 04/06/10 13:28
Chương 6 Testing 177
Để
thêm
Đọc
Thái độ của nhà sản xuất phần mềm để quá trình thử nghiệm đã thay đổi trong những năm qua, từ thử nghiệm xem như một phương tiện để thể hiện rằng một sản phẩm chạy một cách chính xác với thái độ hiện đại mà thử nghiệm
nên được sử dụng để ngăn chặn các yêu cầu, phân tích, thiết kế, và các lỗi thực hiện. Tiến triển này
được mô tả trong [Gelperin và Hetzel, 1988]. Bản chất của kiểm thử phần mềm và các lý do tại sao nó được
khó khăn như vậy sẽ được thảo luận trong [Whittaker, 2000]. Sự thâm nhập của lỗi được mô tả trong [Lieberman và
Fry, 2001]. Cách để giảm số lượng các lỗi xuất hiện trong [Boehm và Basili, 2001].
Whittaker và Voas [2000] trình bày một giả thuyết thú vị về độ tin cậy. Có một yêu cầu hiệu quả workfl ow có thể có một tác động tích cực đến chất lượng phần mềm; điều này được thể hiện trong [Damian và Chisan,
2006]. Chất lượng của phần mềm mã nguồn mở được xem xét trong [Aberdour, 2007].
Một kỹ thuật tiêu chuẩn về tính đúng đắn minh sử dụng cái gọi là Hoare logic, như được mô tả trong [Hoare,
1969]. Một phương pháp khác để đảm bảo rằng các sản phẩm đáp ứng các cation specifi của họ là xây dựng các
sản phẩm theo từng bước, kiểm tra rằng mỗi bước bảo tính đúng đắn. Điều này được mô tả trong [Dijkstra, 1968]
và [Wirth, 1971]. Một bài báo quan trọng liên quan đến việc chấp nhận các chứng minh tính đúng đắn của các phần mềm
cộng đồng kỹ thuật là [DeMillo, Lipton, và Perlis, 1979]. Quan điểm thú vị về tính đúng đắn minh được đưa ra trong [Hinchey et al., 2008].
Các IEEEStandard cho Phần mềm Nhận xét ​​[IEEE 1028, 1997] là một nguồn tuyệt vời của thông tin
về kiểm tra không thực hiện dựa trên. Các thí nghiệm đánh giá kiểm tra của một sản phẩm phần mềm có quy mô lớn
được mô tả trong [Perry et al., 2002]. Vitharana và Ramamurthy [2003] cho thấy rằng việc kiểm tra nên
được ẩn danh và máy tính trung gian. Tác động của quá trình hỗ trợ nhóm về thanh tra được trình bày
trong [Tyran và George, 2002]. Việc lựa chọn các thành viên đoàn kiểm tra được thảo luận trong [Miller và Yin,
2004]. Một đánh giá của thanh tra được đưa ra trong [Parnas và Lawford, 2003], và nhà nước của các thực hành được mô tả trong [Ciolkowski, Laitenberger, và Biffl, 2003]. Kiểm tra mã hướng đối tượng sẽ được thảo luận
trong [Dunsmore, Roper, và Wood, 2003]. Các chi phí-hiệu quả của việc kiểm tra được trình bày trong [Freimut,
Briand, và Vollei, 2005]. May kiểm tra nhu cầu của một tổ chức được mô tả trong [Denger và
Shull, 2007]. Thiết kế và mã đánh giá được tiến hành qua Internet được trình bày trong [Meyer, 2008]. Một
thí nghiệm để kiểm tra giá trị của danh mục kiểm tra được mô tả trong [Hatton, 2008].
Các tác phẩm kinh điển về thử nghiệm thực hiện dựa trên là [Myers, 1979], một công việc mà đã có một cant signifi
tác động trên các lĩnh fi của thử nghiệm. [DeMillo, Lipton, và Sayward, 1978] vẫn là một nguồn tuyệt vời của
thông tin về lựa chọn của dữ liệu thử nghiệm. [Beizer, 1990] là một bản tóm vào thử nghiệm, một cuốn sổ tay thực về
chủ đề này. [Ammann và Offutt, 2008] được khuyến khích mạnh mẽ như một giới thiệu thử nghiệm.
Chuyển Cally specifi cho các mô hình hướng đối tượng, [Kung, Hsia, và Gao, 1998] là một cuốn sách về
thử nghiệm hướng đối tượng, và như vậy là [Sykes và McGregor, 2000].
Các thủ tục tố tụng của Hội thảo quốc tế IEEE về kiểm thử phần mềm và phân tích bao gồm
một phổ rộng các vấn đề tương tự như thử nghiệm. Các tháng 4 năm 2005 ofIEEE Transactions on Kỹ thuật Phần mềm có chứa một loạt các giấy tờ từ các Hội nghị chuyên đề năm 2004. Hai bài viết quan tâm đặc biệt là
[Ostrand, Weyuker, và Bell, 2005], trong đó mô tả một phương pháp để dự đoán vị trí và số
lỗi trong các sản phẩm phần mềm lớn, và [Fu, Milanova, Ryder, Wonnacott, 2005] về sự vững mạnh
thử nghiệm của các ứng dụng máy chủ Java. Các vấn đề Tháng Bảy-Tháng tám 2006 ofIEEE Phần mềm có chứa một rộng
nhiều loại giấy tờ về thử nghiệm.