04软件测试与改错课案.ppt

6. 软件系统的主要测试内容及技术 6.9 安装 / 反安装测试 安装 / 反安装测试的目的：避免“大风浪都挺过来了，却在阴沟里翻了船” 目前市面上有非常流行的、专门制作安装/反安装程序的一些工具，如Install Shelled。制作安装/反安装程序不再是件难事，关键是不要麻痹大意。主要测试工作： （1）至少在标准配置和最低配置两种环境下测试； （2）如果有安装界面，应当尝试各种选项，如选择“全部”、“部分”、“升级”等。 7. 改错的方法 7.1 要有勇气改错 改错是个大悲大喜的过程，一天之内可以让人在悲伤的低谷和喜悦的颠峰之间跌荡起伏。如果改过了成千上万个程序错误，那么少男少女们不必经历失恋的挫折也能变得成熟起来。 软件中的错误通常只有开发者自己才能找出并改掉。如果因畏惧而拖延，会让你终日心情不定，食无味，睡不香。所以长痛不如短痛，要集中精力对付错误。 东北有个林场工人，工作勤奋，一人能干几个人的活。前三十年是伐树劳模，受到周总理的接见。忽有一天醒悟过来，觉得自己太对不起森林，决心补救错误。后三十年成了植树劳模，受到朱总理的接见。若能以此大勇来改错，正是无往而不胜也。我们软件开发人员应当向这位可敬的林场工人学习。 7. 改错的方法 7.2 对症下药 改错的第一步是找出错误的根源，如同医生治病，必须先找出病因才能“对症下药”。改错过程很像侦破案件，有些坏事发生了，而仅有的信息就是它的确发生了。我们必须从结果出发，逆向思考。一旦找到了根源，我们就知道如何改正了。 有人问阿凡提：“我肚子痛，应该用什么药？” 阿凡提说：“应该用眼药水，因为你眼睛不好，吃了脏东西才肚子痛。” 根据软件错误的症状推断出根源并不是件容易的事，因为： （1）症状和根源可能相隔很远。也就是说，症状可能在某一个程序单元中出现，而根源实际上在很远的另一个地方。高度耦合的程序结构加剧了这种情况。 （2）症状可能在另一个错误被纠正后暂时性消失。 （3）症状可能并不是由某个程序错误直接引发的，如误差累积。 （4）症状可能是由不太容易跟踪的人工错误引起的。 （5）症状可能时隐时现，如内存泄漏。 （6）很难重新产生完全一样的输入条件，难以恢复“错误的现场”。 （7）症状可能分布在许多不同的任务中，难以跟踪。 人们把寻找错误根源的过程称为调试（debugging）。 7. 改错的方法 7.3 硬件的调试方法 硬件调试据说继承了中医的“望闻听切”诊断方法： （1）望，即用眼睛查看哪些地方是否有破损。 （2）闻，即用鼻子闻哪些地方是否有烧焦的味道。 （3）听，即用耳朵听哪些地方是否有异常的噪声。 （4）切，即用手触摸哪些地方是否异常发烫。 据有经验的电器修理工说，“望闻听切”这4招能解决大部分问题。 通常软件改错要比硬件改错的代价低，因为后者经常抛弃原来的东西。 7.4 软件的调试方法 软件调试的基本方法是“粗分细找”。对于隐藏得很深的Bug，我们应该运用归纳、推理、“二分”等方法先“快速、粗略”地确定错误根源的范围，然后再用调试工具仔细地跟踪此范围的源代码。如果没有调试工具，那么只好用“土办法”：在程序中插入打印语句如printf，观看屏幕的输出。 有些时候，世界上最好的调试工具恐怕是那些有经验的人。我们经常会长时间地追踪某个Bug，苦恼万分。恰好有高手路过，被他一语“道破天机”，顿时沮丧的阴云就被驱散。 改错的最大忌讳是“急躁蛮干”。人们常说“急中生智”，我不信。我认为大多数人着急了就会蛮干，早把“智”丢到脑后。不仅人如此，动物也如此。 蜜蜂和麻雀撞玻璃的故事…… 7. 改错的方法 7.5 改错时的注意事项 （1）找到错误的代码时，不要急于修改，先思考一下：修改此代码会不会引发其它问题？如果没有问题，可以放心修改。如果有问题，那么可能要改动程序结构，而不止一行代码。 （2）有些时候，软件中可能潜伏同一类型的许多错误（例如由不良的编程习惯引起的）。好不容易逮住一个，应当乘胜追击，全部歼灭。 （3）在改错之后一定要马上进行回归测试，以免引入新的错误。改了一个程序错误固然是喜事，但要防止乐极生悲。更加严格的要求是：不论原先程序是否绝对正确，只要对此程序作过改动（哪怕是微不足道的），都要进行回归测试。 （4）上述事情做完后，应当好好反思：我为什么会犯这样的错误？怎么能够防止下次不犯相似的错误？最好能写下心得体会，与他人共享经验教训。 8. 小结 优秀的程序员敢于声称自己编写的代码没有错误，这种自信让人羡慕不已。一个错误自身也许很微小，但是程序存在错误这件事很严重。能否做好测试工作，态度是很关键的。 测试的真正动机是为了让软件赚更多的钱，所以人们在执行测试之前至少要搞清楚两个问题：（1）要测试什么东西？（2）怎样有效地测试？ 程序员应该