Separately query the database to check that the zero balance has been posted.
Exit the program with File->Exit.
Design 2
Setup： initialize the balance with a positive value.
Procedure：
Start the program on that account.
Withdraw all the money from the account using the 'all' button.
It's an error if the transaction happens without a confirmation popup.
Immediately thereafter：
-- Expect a $0 balance to be displayed.
-- Independently query the database to check that the zero balance has been posted.
The first design style has these advantages：
The test will always be run the same way. You are more likely to be able to reproduce the bug. So will the programmer.
It details all the important expected results to check. Imprecise expected results make failures harder to notice. For example， a tester using the second style would find it easier to overlook a spelling error in the confirmation popup， or even that it was the wrong popup.e
Unlike the second style， you always know exactly what you've tested. In the second style， you couldn't be sure that you'd ever gotten to the Withdraw dialog via the toolbar. Maybe the menu was always used. Maybe the toolbar button doesn’t work at all.
By spelling out all inputs， the first style prevents testers from carelessly overusing simple values. For example， a tester might always test accounts with $100， rather than using a variety of small and large balances. （Either style should include explicit tests for boundary and special values.）x
However， there are also some disadvantages：
The first style is more expensive to create.o
The inevitable minor changes to the user interface will break it， so it's more expensive to maintain.
Because each run of the test is exactly the same， there's no chance that a variation in procedure will stumble across a bug.
It's hard for testers to follow a procedure exactly. When one makes a mistake -- pushes the wrong button， for example -- will she really start over？
Detail in the expected results is less problematic than in the test procedure， but too much detail can focus the tester's attention too much on checking against the script he's following. That might encourage another classic mistake： not noticing and exploring "irrelevant" oddities. Good testers are masters at noticing "something funny" and acting on it.
【New Words】
skimp
节约使用
elaborate
精心制作，详细阐述
omission
冗长
initialize
初始化
popup
弹出
procedure 程序，手续
confirmation 证实，确认，批准
script
手稿，原本，剧本
5.3 Software Maintenance
The term "software maintenance" is used to describe the software engineering activities that occur following delivery of a software product to the customer. The maintenance phase of the software life cycle is the time period in which a software product performs useful work. Typically， the development cycle for a software product spans 1 or 2 years， while tile maintenance phase spans 5 to 10 years.
Maintenance activities involve making enhancements to software products， adapting products to new environments， and correcting problems. Software product enhancement may involve providing new functional capabilities， improving user displays and modes of interaction， upgrading external documents and internal documentation， or upgrading the performance characteristics of a system. Adaptation of software to a new environment may involve moving the software to a different machine， or for instance， modifying the software to accommodate a new telecommunications protocol or an additional disk drives. Problem correction involves modification and revalidation of software to correct errors. Some errors require immediate attention， some can be corrected on a scheduled， periodic basis， and others are known but never corrected.
It is well established that maintenance activities consume a large portion of the total life-cycle budget. It is not uncommon for software maintenance to account for 70 percent of total software life cycle costs （with development requiring 30 percent）. As a general rule of thumb， the distribution of effort for software maintenance includes 60 percent of the maintenance budget for enhancement， and 20 percent each for adaptation and correction.
If maintenance consumes 70 percent of the total life cycle effort devoted to a particular software product， and if 60 percent of maintenance goes to enhancing the product， then 42 percent of the total life cycle effort for that product is dedicated to product enhancement. Given this perspective， it is apparent that the product delivered to the customer at the end of the development cycle is only the initial version of the system. Some authors have suggested that the appropriate life-cycle model for software is development→evolution→evolution→evolution…
This perspective makes it apparent that the primary goal of software development should be production of maintainable software systems. Maintainability， like all high-level quality attributes， can be expressed in terms of attributes that are built into the product. The primary product attributes that contribute to software maintainability are clarity， modularity， and good internal documentation of the source code， as well as appropriate supporting documents.
It should also be observed that software maintenance is a microcosm of the software development cycle. Enhancement and adaptation of software reinitiate development in the analysis phase， while correction of a software problem may reinitiate the development cycle in the analysis phase， the design phase， or the implementation phase. Thus， all of the tools and techniques used to develop software are potentially useful for software maintenance.