Đang chuẩn bị liên kết để tải về tài liệu:
Software Engineering For Students: A Programming Approach Part 30

Software Engineering For Students: A Programming Approach Part 30. This fully revised version of Doug Bell's Software Engineering: A Programming Approach continues to use the successful formula of the previous editions. The author's approach is to present the main principles, techniques and tools used in software engineering, one by one, chapter by chapter. This book is a unique introduction to software engineering for all students of computer science and its related disciplines. It is also ideal for practitioners wishing to remain current with new developments in the area | 268 Chapter 19 Testing We begin this chapter by discussing the general problem of testing - and discover that there is a significant problem. We consider approaches called black box and white box testing. There are a whole number of associated testing techniques which we outline. The problems of testing large pieces of software that consist of many components are severe - particularly if all the components are combined at one and the same time. 19.2 The nature of errors It would be convenient to know how errors arise because then we could try to avoid them during all the stages of development. Similarly it would be useful to know the most commonly occurring faults because then we could look for them during verification. Regrettably the data is inconclusive and it is only possible to make vague statements about these things. Specifications are a common source of faults. A software system has an overall specification derived from requirements analysis. In addition each component of the software ideally has an individual specification that is derived from architectural design. The specification for a component can be ambiguous unclear incomplete faulty. Any such problems should of course be detected and remedied by verification of the specification prior to development of the component but of course this verification cannot and will not be totally effective. So there are often problems with a component specification. This is not all - there are other problems with specifications. During programming the developer of a component may misunderstand the component specification. The next type of error is where a component contain faults so that it does not meet its specification. This may be due to two kinds of problem 1. errors in the logic of the code - an error of commission 2. code that fails to meet all aspects of the specification - an error of omission. This second type of error is where the programmer has failed to appreciate and correctly understand all the detail