精华内容
下载资源
问答
  • 常见bug调试方法

    千次阅读 2016-06-03 09:45:01
    常见bug调试方法 此处为大量Copy!不喜请喷! The software doesn't do something that the product specification says it should do. The software does something that the product specification ...

    常见bug调试方法


    此处为大量Copy!不喜请喷!


    The software doesn't do something that the product specification says it should do.
    The software does something that the product specification says it shouldn't do.
    The software does something that the product specification doesn't mention.
    The software doesn't do something that the product specification doesn't mention but should.
    The software is difficult to understand, hard to use, slow, or in the software tester's eyes will be viewed by the end user as just plain not right.

    我不是英文教师,请大家自行切换多语言阅读模式。
    也还有有人粗暴的定义 ”Bug就是错误“,除了世界上第一只Bug是飞进去的那只虫子外,其他Bug毋庸置疑那都是程序员们自己生下来的!程序员们自己犯的错误!如果说一个软件作品(请尊重你自己的作品,不要喊他们”产品”或者”项目”)是程序员们自己的孩子,那么Bug就是这个孩子的生的病,有病得治,药不能停!生病有各种治疗方法,物疗,理疗,化疗,心理疗……那么“治疗”Bug也是有多中方法的!下面博主会一一列举!惩治这些个Bug之前,博主要先阿拉巴拉一番,遇到Bug也是一件比较哔了狗了的事情,你要知道任何人都会生病,没有例外!所有任何代码都有Bug这是定理,我们首先要从心态上端正Bug这件事情,我们可以理解为缺憾也是一种美,就像阿雨说的“没有皱纹的祖母是可怕的,没有白发的老者是让人遗憾的。没有废墟的人生太累了,没有废墟的大地太挤了,掩盖废墟的举动太伪诈了。”Debug是为了证明程序有错,而不是证明程序无错误;所以我们要做到临Bug而不惧者,圣人之勇也!所以我们要做到战略上藐视它,战术上重视它!你要心理默念Bug其实挺(T)美(M)的(D)!anyway 无Bug不生活!!

     

    抽刀断Bug


    断点,(我求你们不要想到张敬轩,阿轩他容易么,小受又怎么了?你们这帮人真是的!!),我要说的断点是BreakPoint!基本上不是残废的IDE都具有断点调试功能吧!尤其是XCode,我们家的IDE断点调试功能可是强中又是强中手!在这之前大家可以先了解一下哈子是断点?它怎么实现的?工作原理怎么样的?博主就献丑说说自己的理解吧,断点,顾名思义就是从前有一个点,后来它断了,谢谢,我的故事讲完了。哎哟还不服,这些基础常识的东西自己不会查?你还真的脸皮厚上天了去了,还要博主给你查哟,自己查去!

    普通操作

    如图3

    基本的断点操作如下

    图4

     

    点击那个黑列列就创建了一个断点,再次点击就临时取消这个断点(但是不删除),长按那个断点拖出去就删除了(mac os的系统工程师就是稀饭拖动的快感),当然也可以右键那个创建的断点,会弹出相应地菜单。
    当然也还可以监视某个变量!
    图5

    在对象视图中,右键某个对象,点击“Watch ‘XXX’”就完成XXX对象的监视了。

    这里我监视了lab这个UILabel的变量,每当这个变量进行更新它的信息就会被打印到控制台。
    好吧!我们最基本的创建断点的工作已经学会了,Xcode舒服在什么地方呢?就是不分Debug模式和Run模式的,可以说是无缝切换的,你只要没有创建断点,那么就是Run的正常模式,如果创建了断点并且运行到断点处,就自动进入Debug模式咯,不像某EC开头的IDE,控制面板就像开飞机的一样,几万个按钮以为很强大,其实只用了Run和Stop,还有什么Debug模式,App模式……,果然Xcode的优越感在对比中更加强烈了,舒服到极点呀,就像夏天的海风拂过菊花,嗯是的 就是那种感觉!
    我们创建好了断点,运行到断点就自动停下来了,像这样:
    图6

    这些Debug的最基本操作技能是每一个入门的IOS开发者都要掌握的,应该当成一种本能,就像狗爱吃翔一样(噢 对不起 博主不是歧视狗的意思,博主也养过狗,很二逼但是从不吃翔!真的据我所知它从来不吃翔的,这里只是比喻只是比喻)。

     

    全局断点(Global BreakPoint)

    有时候在程序出错的时候不能能准确定位到奔溃的那一行代码,而是直接跑到main循环或者Appdelegate里面, 或者会给你这样的提示:

    EXEC_BAD_ACCESS:

    是不是有种想哭的冲动?尼玛~至少给我一些堆栈信息也好呀~……这个时候你千万不要砸鼠标和键盘哦,一切都是主机在运行,你砸鼠标和键盘有什么用呢?应该是踢主机呀~~,现在有了全局断点,娘亲再也不担心你砸鼠标了,你只需要这样:
    图7

    在Debug导航面板进行上图的操作,你就建立了全局断点,这样只要遇到错误,debug程序就会自动定位到栈底的信息,也就是你最先出错的代码的那一行,这样你就可以快乐的debug拉~~

     

    条件断点(Condational Breakpoints)


    从前有一个游戏,叫做撸啊撸,有些玩家他们知道怎么操作,会放技能会走路,但是他们不知道买装备,玩了一局下来,鞋子小刀都没有买。我为什么讲这个故事呢?因为很多小朋友学东西和玩游戏一样,看完前面的几种调试技能,就以为自己已经屌爆无敌了,其实他们不过是出门不带装备的玩家,如果只是使用了以上的调试技能只能说是低玩,在高大的逼优鸡面前根本就是会被瞬秒的那种,所以学会装备自己才是王道!条件断点,就是学会有的放矢!

    我们来看一段代码
    图8

    你是不是想问博主为何那么风骚,竟然上了Swift了!!我此刻只想吟一首湿:别人笑我太淫荡,我家住在黄鹤楼。
    反正这个年代大家都是吃饱了撑着的,博主也是,所以就学学Swift咯。
    我们如果在一个循环里面使用了断点,如果这个循环执行了100万次,那你的断点要执行那么多次,你不觉得蛋蛋都凉了的忧伤么?所以我们这么做:
    图9

    这样只有遍历到c==“H”的时候 断点才会被触发。

    图10

    是不是很棒呢!
    有些童鞋的钛合金狗眼已经看到了编辑断点那里有一个Action的东西,那是什么呢?
    这个是非常强大的,可以在你断点的位置,执行各种操作,比如执行脚本命令,控制台命令(可以制定调试信息自定义保存)、打印信息等,
    博主最喜欢的就是这个Log message啦,简单粗暴!根本就不需要print啊NSLog嘛,直接在断点的Action打印就好了(其实这个是Xcode和调试器结合的高能产物,下面再介绍)。具体可以这样:
    图11

    其实刚刚博主撒谎了,博主最喜欢的Action并不是Log Message,而是Sound,顾名思义嘛,断点射在Bug上,这样遇到断点就会发出声音,听到我自己设置的声音,我就知道是什么Bug了,听声识Bug,呵呵,EXEC_BAD_ACCESS的错误我设置成了波多野老师的声音,unrecognized selector send to instancd的错误我设置成了苍老师的…… 不要问我系统怎么没有吉泽明步的声音,我根本就不知道谁是吉泽明步。

    当然还有更加强大的条件断点就是这货啦
    图12

    添加之后在 Symbol 一栏输入 viewDidLoad。
    这样一来,在程序中所有的 viewDidLoad 方法被调用时都会触发断点。
    图13


    当然,我们也可以仅仅为特定的某个类的方法添加断点。在 Symbol 一栏输入 [ClassName viewDidLoad] (Objective-C) 或 ClassName.viewDidLoad (Swift) 即可。
    比如:unrecognized selector sent to instance 0xaxxxx 这种错误,这个instance可以这样快速定位
    图14

     

     

    打印的艺术

    尽管ARC已经让内存管理变得简单、省时和高效,但是在object的life-cycles中跟踪一些重要事件依然十分重要。毕竟ARC并没有完全排除内存泄露的可能性,或者试图访问一个被release的对象。为了这个目的,我们可以很艺术地偷窥对象正在做些什么,想想就好有快感。

    NSLog

    小伙伴们第一节课学习ViewController的生命周期的时候,老师肯定很猥琐的教了大家,在viewController的每个生命周期的方法中使用了NSLog来偷窥!没错,这样其实就是最简单爆炸的跟踪生命周期的方法了,不过系统自己的NSLog真心有点羸弱,输出的信息太少,根本就不能满足我们的欲望,这里我教大家强化你的Log!!
    可以用下面的这段宏

    //A better version of NSLog
    #define NSLog(format, ...) do { \
    fprintf(stderr, "<%s : %d> %s\n", \
    [[[NSString stringWithUTF8String:__FILE__] lastPathComponent] UTF8String], \
    __LINE__, __func__); \
    (NSLog)((format), ##__VA_ARGS__); \
    fprintf(stderr, "-------\n"); \
    } while (0)

     

    关于宏的威力 大家可以乱入我的博文《 IOS中的预编译指令的初步探究》
    这样打印出来的东西才像话嘛(其实NSLog的打印是非常低效的,甚至比print低100倍,感兴趣自己翻翻苹果手册咯)。 
    使用objc语言(强类型)并且用NSLog打印的时候,常常搞不清楚NSLog(@“%?”,xxx) xxx这种类型该是什么什么类型输出,应该是%d呢还是%@亦或是%f???傻傻分不清楚~,所以玩转NSLog你应该要知道以下这几个全局方法!
    图17

    开启僵尸对象(Enable NSZombie Objects)

    Xcode可以把那些已经release掉得对象,变成“僵尸”,当我们访问一个Zombie对象时,Xcode可以告诉我们正在访问的对象是一个不应该存在的对象了。因为Xcode知道这个对象是什么,所以可以让我们知道这个对象在哪里,以及这是什么时候发生的。
    所以Zombies是你的好基友!他可以让你输出的信息更具体!!
    具体这样做:
    图15


    自己再试试输出Object的信息咯,是不是很棒呢?
    僵尸只能用在模拟器和OC语言哦~

     

    进击的码农

    如果说你已经把打印的艺术运用的风生水起了,并且断点的使用可以信手拈来随心所欲,那么你已经在与逼优鸡的对峙中,稳操大部分胜券了,你已经是一个孤高冷艳的程序员了,俯视一切低能的逼优鸡了!但是!面对更强大的敌人——你那秃顶1000°近视牙齿夹着韭菜的有着十年对战逼优鸡的同事面前、以及笑里藏刀眼睛有眼屎但是能用眼神杀死你的面试官…… 对于他们,你还是太弱,你的技能的磨练还太少!所以你必须要进击!!比逼优鸡还要强大的敌人出现了!我们需要更强大的武器。

    Console(lldb 命令)

    我们的目标是要武装到鼻毛!console窗口大家知道就是哪个黑乎乎好多字会滚出来,尤其是被逼优鸡干到的时候,那么同学们有没有遇到这种console呢
    图16


    我们家的编译器历史 敬请乱入 《IOS中的预编译指令的初步探究》 ,没错我们现在正在使用着世界上最好的c、c++、oc、swift的编译器——LLVM,lldb就是这个世界上最好的LLVM的调试器!不要害羞,因为我们是最优秀的!所以肯定要用最好的!千万别客气哟,随便用,就像自己家一样啊,啊 哈哈 吃吃吃 别只顾着吃饭,多夹菜……哎~博主好客的职业病又犯了~,什么?你不知道在哪里用lldb?
    首先!你得先crash或者把程序断下来!直到你看到图16的(lldb)字样出现,你就可以敲命令了~~
    每次你想查看变量,常量,你要重新写NSLog去打印,然后重新编译,去执行,重头开始?太累了,有了lldb你只要这样
    图18

    是不是方便到爆炸?
    当你有一个switch语句,你为了测试每一个case,你都要制造假条件去测试;有一个if…else…语句,你为了测试不同的情况,你要硬编码写了不同的情况,编译好几次为了测试每种情况……,我想你应该知道为什么自己的头发那么稀疏了。
    以上的这些情况,只需一次编译,使用lldb的thread命令,伪造返回值,欺骗寄存器,就可以随心所欲的做完所有测试了。
    是不是牛逼到爆炸?
    lldb真的很强大,博主没有骗你,这篇博文到此的所有调试技巧lldb都可以实现,各种断点,各种打印,调用python插件,运行中断,操作硬件底层,控制程序运行线程……lldb都可以做到!仿佛lldb就是另一个强大的世界!!!
    是不是强大到爆炸?
    其实如果你不想贪多嚼不烂的话,你只要精通这个调试工具,基本前面的调试技能你可以不用学了,在这里博主也是不才,lldb的强大不是博主随便说几句就可以表达的出来的, 
    更多地需要大家事必躬亲,才能真正体会到那种美好,那种畅快无比的调试体验!
    这里博主无私地掏出任意门,这里有很好的文章!可以让你好好的回味,呵呵
    《The LLDB Debugger》
    《About LLDB and Xcode》
    《LLDB调试命令初探》
    《与调试器共舞 - LLDB 的华尔兹》

     

    Profile(instruments)

     

    图19


    这个东西怎么翻译呢?我们就叫检查器吧!!也许已经学习了IOS开发大半年的你,从来都没注意到或者使用这个工具,但是博主很负责任的告诉你现在市面上任何一款出色的APP都会使用instruments来让代码更加健壮!难道instrument是春药?怎么会使代码健壮呢?
    这个健壮不是那个健壮~哎~~ 我才18岁能不能清纯一点呀

    instrument里面包含了很多工具,内存溢出分析,性能分析,各种分析…… 如果细说的话,这个真的可以为每个工具开一篇博客,但是博主是一个懂得授人以鱼不如授人以渔的道理的老司机!所以博主当然不会全部说一遍!我们就来领着大家看看专用debug的内存溢出分析工具的使用吧!
    图20


    在使用leaks之前大家可以试试这个“Analyze”
    图21


    analyze可以快速的发现你的代码中release的问题,以及继承过程中的父类方法缺失等等问题!一般一个优秀的IOS开发工程师No Warning、Pass Analyze是最基本的操守!我知道你已经对于你自己的项目的上百个warning已经麻木了,但博主我负责人地告诉你,这样不好!,因为有一首云南民歌《老司机带带我》听得博主神清气爽!

    坚守作为IOS开发者的贞操!跟着我高喊口号!

    No Warning!Pass Analyze!

    我们继续回来使用leaks!如果analyze都通过了,那么就可以使用leaks工具,发现千年老妖级别的侧漏了!
    图22


    如果提示某一个对象有侧漏的风险,你还可以这样弹出侧边的拓展细节
    图23


    直接点击方法就可以直接进入代码部分了!!
    是不是很简单粗暴呢!当然还很多其他工具,不过叫做篇幅的东西总是限制人,诶 真蛋疼~真的还想多说点的 
    想要更多了解instrument 大家可以看看这篇文章!
    《How to Use Instruments in Xcode》

     

    Xcode视图调试

    有时候有些逼优鸡隐藏的比较深,代码几乎都翻了个遍,还是没找到问题出在哪,博主可以理解那种风中凌乱,蛋碎一地的赶脚,因为无数个日夜博主就是深陷当中无法自拔,后来干脆直接重新新建一个工程!还是不行!!我去,直到有一天博主早上起来,看到镜子中自己帅气的脸庞,我才突然顿悟,原来长得帅可以那样快速的找到bug!最终锁定是可爱又可恨的xib和storyboard出了问题!!某个constraint或者view的嵌套逻辑又或者团队协作Git冲突等等问题,导致io -v什么的错误,这种情况去检查视图文件,可能xcode崩溃打不开那个xib或者storyboard,你直接使用文本工具打开这个xml类型的标记文件,你差点吐血,几万行的记录狗眼都看瞎了……。

    但是这个历史要被终结!!因为我们强大的xcode的视图调试功能!!

    以下内容,完全copy,如有不适,坚持看完!请叫我快乐的搬运工!
    抄袭自《View Debugging in Xcode 6》
    苹果在Xcode 6中做了不少明显的改善和优化,视图调试就是其中之一。通常,App用户界面的行为不会符合开发者期望的那样,比如或者不展示视图,或者没有正确地展示。本文讲解如何使用Xcode的新的视图调试功能来简化开发者对问题界面的确认和修复。

    1.Demo 工程

    开始之初先从github(https://github.com/tutsplus/ViewDebugging)上下载示例工程并打开ViewDebugging.xcodeproj。该工程包含一个简单的包含少数视图控制器的可点击的应用程序、应用程序委托以及一个storyboard。该app是为iPhone而设计,但受益于iOS 8的自适应布局,所以界面展示在任何设备上都没有问题。

    您刚刚下载的应用程序示例工程是一个简单的to-do list应用程序,包含可查看其他信息的简单屏幕,比如该示例工程中的项目数,用户头像以及@***的推特操作。点击Xcode左上角的运行按钮将展示在iOS模拟器中运行的应用程序。
    图24


    很快会注意到用户界面中存在问题-表视图中没有展示任何数据。在工程导航面板中打开FirstViewController.swift并找到以下代码:

    var mockNotesDataSource: [String] = ["Do some laundry", "Finish homework", "Walk the dog", "Learn about view debugging"]
    {
    didSet
    {
    self.tableView.reloadData()
    }
    }

     

    可以看到mockNotesDataSource变量是表视图的数据源。使用Swift的属性观察者功能,在数据源发生改变时,表视图会自动重新加载。通过查看以上代码片段,你会发现应该应用中应该有4个项目需要展示,但现在不展示数据就说明某些地方出现了差错。

    启用视图调试

    问题似乎与用户界面有关。运行app过程中,按下底部的Debug View Hierarchy 按钮,或者从菜单中选择Debug > View Debugging > Capture View Hierarchy 来启动视图调试。

    图25


    启动视图调试后,Xcode会对应用程序的视图层次拍一个快照并展示三维原型视图来探究用户界面的层级。该三维视图除了展示app的视图层次外,还展示每个视图的位置、顺序和视图尺寸,以及视图间的交互方式。

    示例工程在Xcode中的三维视图展示正常,但表视图单元格似乎有点太宽了。
    图26


    暂停应用程序调试并在左侧选中Main.Storyboard来修复问题。点击表视图并选中Editor > Resolve Auto Layout Issues > Reset to Suggested Constraints.
    图27


    编译并再次运行应用程序以确定用户界面展示正常。点击Debug View Hierarchy按钮更进一步了解视图调试的功能。

    视图调试功能

    点击并拖拽三维渲染图的任意一边,可旋转或者倾斜用户界面,向左或者向右倾斜可选中某个表视图。

    选中后,Xcode会高亮该视图,并在会在右边展示Object 和Size检查器。查看在跳转栏顶部并确认UITableView是右边最后一个项目。
    图28

    Object 和 Size检查器包括大量有用的信息。过去开发者需要依赖日志语句或者断点来检查视图的配置。

    打开右边的Size inspector(规格检查器),下方是Auto Layout,可以看到视图上已经应用了正确的约束。在Object inspector中,我们可以检查所选视图的属性。
    图29

    在Xcode的调试区有9个视图调试过程中要用到的按钮和滑块儿。
    图30


    从左到右控件排序:

    调整视图间距:调整不同视图间的间距。

    展示被剪切的内容:当前展示视图中被剪切的部分。

    展示约束:展示选中视图的约束。

    重置查看区域:将3D渲染透视图恢复至默认状态。

    调整查看模式:选择性地展示3D渲染透视图,比如仅展示内容,仅展示框架以及同时展示内容和框架。

    缩小:缩小3D渲染透视图

    恢复:将3D渲染透视图恢复至默认尺寸。

    放大:放大3D渲染透视图

    调整可视视图范围:隐藏视图或展示视图,一步步解析3D渲染视图,向左或者向右滑动滑块儿有相反的效果。

    建议花一点时间上手操作下这些空间,并理解各自的用处。

    视图层排序

    再次编译和运行应用程序,并点击用户界面底部的"More"标签。第一眼看去界面看起来还OK,但是它没有按照开发者的定义准确执行,图片上的模糊效果没有展示出来。我们可以通过调试视图层次来更好地确定问题所在。

    向左或者向右拖拽视图来查看具体情况,接着将view spacing slider向右拖动。
    图31


    这样一来,不同视图间的间距变大了,层次也更加清晰,我们看到在图片"下方"还隐藏着另一个视图,选中隐藏的视图,它就是"丢失"的视觉效果视图。
    图32


    打开Main.storyboard 并选中Second View Controller Scene。在左侧的文档概览面板中,展开Second View Controller的视图对象以查看子视图的排序。

    Xcode在文档概览中按照递升顺序堆叠视图,换句话说,列表顶层的视图是视图层次的基础。

    修复问题很简单。运行时,Blur Effect View隐藏在Sky Image之下,因为它是视图层次的第一个视图。在文档概览中点击并拖拽 Blur Effect View,结果会如下图展示一样:
    图33


    再次运行应用程序就能看到模糊效果了。应用程序的用户界面看起来符合设计的初衷。我们还可以查看iOS模拟器的其他调试功能,看看还完善了其他什么地方或功能。

    5.iOS模拟器调试功能

    编译并运行应用程序,选中模拟器,从 Debug菜单中选择Color Blended Layers选项。
    图34


    然后会看到app的用户界面被红色和绿色覆盖,显示了哪些图层可以被叠加覆盖,以及哪些图层是透明的。混合层属于计算密集型视图,所以推荐尽可能地使用不透明的图层。
    图35


    苹果在其文档(iOS Simulator User Guide)中对此进行了注明,并在表视图处理上使用了不透明图层。滚动视图时会有些表现不大好的地方,一个重要的原因就是使用了混合图层,而如果内容背景是不透明层,那么页面滚动效果就会非常流畅和平稳。

    对于这款应用程序来说,假使用户有数百个项目要展示,可能会出现滚动性能不一致的情况。表视图单元格当前使用的是混合层。由于视图控制器的视图背景是白色,所以不管表视图单元格使用的是混合层或者不透明层,终端用户不会觉察到有什么不一样。

    打开Main.storyboard并选中To Do list Scene中的表视图单元格属性。在属性检查器(Attributes Inspector)中,向下滚动Drawing分区并勾选Opaque。
    图36


    在启用Color Blended Layers的状态下编译并运行应用程序。由于表视图单元格现在使用了不透明层,所以会用绿色覆盖,以指示它们是不透明的。

    除了标记图层外,还有其他一些有用的功能可帮开发者在iOS模拟器中调试应用。以下是其中一些比较有用的:

    Toggle Slow Animations in Frontmost App: 选中模拟器,打开Debug菜单选中Toggle Slow Animations in Frontmost App,该功能可以降低app中动画的运行速度,适合调试包含复杂动画的应用程序。也可是使用快捷键Command-T来操作。
    Color Copied Images:该选项可以给绘制时被Core Animation复制的图片添加蓝绿色叠加层。
    Color Misaligned Images:如果图片边界没有与目标像素完美对齐,该功能可为图片叠加上一层品红色。如果图片使用确定的比例大小绘制,那么该功能会为图片添加一层黄色叠加。
    Color Off Screen Rendered:.该选项为离屏渲染内容添加一个黄色的叠加层。
    很多开发者会忽略接入电话时应用状态栏的设计问题,你可以通过触发通话中状态栏来简单测试。在iOS模拟器中,从Hardware菜单中选中Toggle In-Call Status Bar。

    想查看app如何响应事件,可按下Command-T来启用slow animations,并按下Command-Y来展示电话接入时的状态栏。倘若你的应用程序使用了导航栏,那么操作系统会为你兼顾到这一块儿。
    图37


    除了给视图着色外,还要记住iOS模拟器也可以调试Core Location问题。你可以在特定经纬度模拟设备,

    如果你的应用程序使用iCloud来管理数据,你也可以手动触发同步事件。

    本文中使用的demo app非常简单,使用文中提到的技术可以帮你在未来节省不少时间。视图调试可以帮你修正很多用户界面中出现的问题。

    除了Xcode和InterfaceBuilder之外,使用iOS模拟器的调试功能可以提升应用性能和识别开发过程中的瓶颈。苹果的人机交互指南(中文版 英文版)强调了积极响应对app的重要性,能让用户觉得应用易于使用和操作。苹果对InterfaceBuilder的提升让视图调试变得前所未有的简单。

    结语

    展开全文
  • 软件调试方法及调试原则

    万次阅读 2018-11-16 09:08:37
    软件调试是在进行了成功的测试之后才开始的工作,它与软件测试不同,调试的任务是进一步诊断和改正程序中潜在的错误。   注: 以问题为中心 以错误为导向   调试活动由两部分组成: u 确定程序中可疑错误...

    调试(Debug)

     

    软件调试是在进行了成功的测试之后才开始的工作,它与软件测试不同,调试的任务是进一步诊断和改正程序中潜在的错误。

     

    注:

    以问题为中心

    以错误为导向

     

    调试活动由两部分组成:

    u  确定程序中可疑错误的确切性质和位置

    u  对程序(设计,编码)进行修改,排除这个错误

     

    注:

    测试和调试密不可分

    测试是为了发现问题

    调试时为了解决问题

     

    调试工作是一个具有很强技巧性的工作

     

    软件运行失效或出现问题,往往只是潜在错误的外部表现,而外部表现与内在原因之间常常没有明显的联系,如果要找出真正的原因,排除潜在的错误,不是一件易事。

    可以说,调试是通过现象,找出原因的一个思维分析的过程。

    调试步骤:

    (1)      从错误的外部表现形式入手,确定程序中出错位置

    (2)      研究有关部分的程序,找出错误的内在原因

    (3)      修改设计代码,以排除这个错误

    (4)      重复进行暴露了这个错误的原始测试或某些有关测试。

     

    注:

    由外而内

    由现象到本质

    由结果到原因

     

    从技术角度来看查找错误的难度在于:

    u  现象与原因所处的位置可能相距甚远

    u  当其他错误得到纠正时,这一错误所表现出的现象可能会暂时消失,但并为实际排除

    u  现象实际上是由一些非错误原因(例如,舍入不精确)引起的

    u  现象可能是由于一些不容易发现的人为错误引起的

    u  错误是由于时序问题引起的,与处理过程无关

    u  现象是由于难于精确再现的输入状态(例如,实时应用中输入顺序不确定)引起

    u  现象可能是周期出现的,在软,硬件结合的嵌入式系统中常常遇到

     

     

    几种主要的调试方法

     

    调试的关键在于推断程序内部的错误位置及原因,可以采用以下方法:

    1.强行排错:

    这种调试方法目前使用较多,效率较低,它不需要过多的思考,比较省脑筋。例如:

    u  通过内存全部打印来调试,在这大量的数据中寻找出错的位置。

    u  在程序特定位置设置打印语句,把打印语句插在出错的源程序的各个关键变量改变部位,重要分支部位,子程序调用部位,跟踪程序的执行,监视重要变量的变化

    u  自动调用工具,利用某些程序语言的调试功能或专门的交互式调试工具,分析程序的动态过程,而不必修改程序。

     

    应用以上任一种方法之前,都应当对错误的征兆进行全面彻底的分析,得出对出错位置及错误性质的推测,再使用一种适当的调试方法来检验推测的正确性。

     

    2.回溯法调试:

    这是在小程序中常用的一种有效的调试方法,一旦发现了错误,人们先分析错误的征兆,确定最先发现“症状“的位置

    然后,人工沿程序的控制流程,向回追踪源程序代码,直到找到错误根源或确定错误产生的范围,

    例如,程序中发现错误处是某个打印语句,通过输出值可推断程序在这一点上变量的值,再从这一点出发,回溯程序的执行过程,反复思考:“如果程序在这一点上的状态(变量的值)是这样,那么程序在上一点的状态一定是这样···“直到找到错误所在。

     

     

     

    3.归纳法调试:

    归纳法是一种从特殊推断一般的系统化思考方法,归纳法调试的基本思想是:从一些线索(错误征兆)着手,通过分析它们之间的关系来找出错误

     

    u  收集有关的数据,列出所有已知的测试用例和程序执行结果,看哪些输入数据的运行结果是正确的,哪些输入数据的运行经过是有错误的

    u  组织数据

    由于归纳法是从特殊到一般的推断过程,所以需要组织整理数据,以发现规律

     

    常以3W1H形式组织可用的数据

    “What“列出一般现象

    “Where“说明发现现象的地点

    “When“列出现象发生时所有已知情况

    “How“说明现象的范围和量级

    “Yes“描述出现错误的3W1H;

    “No“作为比较,描述了没有错误的3W1H,通过分析找出矛盾来

     

    u  提出假设

    分析线索之间的关系,利用在线索结构中观察到的矛盾现象,设计一个或多个关于出错原因的假设,如果一个假设也提不出来,归纳过程就需要收集更多的数据,此时,应当再设计与执行一些测试用例,以获得更多的数据。

     

    u  证明假设

    把假设与原始线索或数据进行比较,若它能完全解释一切现象,则假设得到证明,否则,认为假设不合理,或不完全,或是存在多个错误,以致只能消除部分错误

     

     

    4.演绎法调试:

    演绎法是一种从一般原理或前提出发,经过排除和精华的过程来推导出结论的思考方法,演绎法排错是测试人员首先根据已有的测试用例,设想及枚举出所有可能出错的原因作为假设,然后再用原始测试数据或新的测试,从中逐个排除不可能正确的假设,最后,再用测试数据验证余下的假设确是出错的原因。

     

    u  列举所有可能出错原因的假设,把所有可能的错误原因列成表,通过它们,可以组织,分析现有数据

    u  利用已有的测试数据,排除不正确的假设

    仔细分析已有的数据,寻找矛盾,力求排除前一步列出所有原因,如果所有原因都被排除了,则需要补充一些数据(测试用例),以建立新的假设。

     

    u  改进余下的假设

    利用已知的线索,进一步改进余下的假设,使之更具体化,以便可以精确地确定出错位置

     

    u  证明余下的假设

     

     

    调试原则

    n  在调试方面,许多原则本质上是心理学方面的问题,调试由两部分组成,调试原则也分成两组。

    n  确定错误的性质和位置的原则

    u  用头脑去分析思考与错误征兆有关的信息

    u  避开死胡同

    u  只把调试工具当做辅助手段来使用,利用调试工具,可以帮助思考,但不能代替思考

    u  避免用试探法,最多只能把它当做最后手段

     

    n  修改错误的原则

     

    u  在出现错误的地方,很有可能还有别的错误

    u  修改错误的一个常见失误是只修改了这个错误的征兆或这个错误的表现,而没有修改错误的本身。

    u  当心修正一个错误的同时有可能会引入新的错误

    u  修改错误的过程将迫使人们暂时回到程序设计阶段

    u  修改源代码程序,不要改变目标代码
     

    展开全文
  • 本文只是选取主流评估方法进行简述,每一种方法在实际操作过程中若干条计数规则,在此并未阐述,并不能作为评估工作的实施指南。实际使用方法时,需以各方法发布机构发布的官方文档为准。 一、 功能点 FPA 方法 .....

    前言

    本文的目标读者是从事软件行业想快速了解软件开发过程工作量评估的人员。软件工作量评估方法很多,如代码行法、类比法、WBS、故事点、用例点、NESMA、FPA、cosmic、COCOMOⅡ等。本文只是选取主流评估方法进行简述,每一种方法在实际操作过程中有若干条计数规则,在此并未阐述,并不能作为评估工作的实施指南。实际使用方法时,需以各方法发布机构发布的官方文档为准。

    一、 功能点 FPA 方法

    (一) 简介

    FPA 是从用户角度出发度量软件规模的一种方法。它从用户的角度出发,将系统分为数据功能和事物功能两大类,分别根据具体的规则来计算功能点,最后结合系统的特征因子来调整功能点数, 从而得到最终的系统规模。

    FPA 较适用于商业数据处理、管理信息系统的估算,因为它能更好地反映系统需求上的复杂度和数量。从满足客户需求的角度讲,FPA 具有阶段性,对用户早期参与项目管理、项目经理制定项目计划更有意义。

    (二) 重要概念

    功能点估算法是从用户视角出发,对软件的规模从逻辑设计的角度进行度量的标准方法。

    在功能点估算的过程中,以下概念应贯穿始终:

    1、 用户视角

    用户视角(User View)是指功能点被用户所认可,由用户需求书面正式描述,且独立于所采用的开发技术。

    2、 穿越系统边界

    穿越系统边界(Application Boundary)是指数据或控制信息由系统内发送到系统外,或由系统外发送到系统内。
    是否穿越系统边界是 FPA 重要的判断标准。

    3、 IPO 的异同

    输入(Input)、处理过程(Process)和输出(Output)的同与不同亦是FPA 重要的判断标准。

    (三) FPA 估算方法基本步骤

    在这里插入图片描述

    1、 收集可得的文档

    文档可以包括需求、数据/对象模型、类图、数据流图、用例、过程描述、报表显示、界面显示、用户手册,以及其它软件开发文档。

    2、 确定计数范围和边界并识别功能用户需求

    计数范围和边界需识别计数目的。不同的计数目的决定了计数范围和软件边界的划分。实际使用过程中通常为系统的管理边界, 特殊系统会以架构为边界。

    3、 度量数据功能

    数据功能的计算工序(Counting Procedures)包括以下活动:

    在这里插入图片描述

    FPA 将数据功能分为两类,分别为内部逻辑文件(ILF)和外部接口文件(EIF)。

    1) 识别内部逻辑文件 ILF

    内部逻辑文件(Internal Logical File,简称ILF)是在系统边界内部维护的一组用户可识别的逻辑上相关的数据或控制信息。ILF 的首要目的是保存由被度量系统的一个或多个基本流程维护的数据。

    2) 识别外部接口文件EIF

    外部接口文件(External Interface File,简称 EIF)是用户可识别的、逻辑相关的数据组或控制信息组,其由被度量应用所引用,但在另一应用边界内维护。EIF 的主要目的是保存由被度量应用的一个或多个基本过程引用的数据。这意味着一个应用的 EIF 必定是另一个应用的ILF。

    3) 识别数据功能 DET

    数据元素类型(Data Element Types,简称DETs)是指在一个ILF 或EIF 内,用户可认知的、唯一的、非重复的字段。如客户姓名、年龄、地址、联系方式等。

    4) 识别数据功能 RET

    记录元素类型(Record Element Types,简称 RETs)是指在一个ILF 或EIF 内,用户可认知的数据元素子集。如客户的家庭信息为客户信息的 RET 。

    5) 确定ILF 或EIF 的贡献度

    根据每一个已确认的 ILF 和EIF 的复杂度(DETs 和RETs 数量),对其进行分类,并赋予未调节功能点数值(Unadjusted Function Points,简称UFP)的过程,即为确定其贡献度。

    在这里插入图片描述

    6) 确定ILF 或EIF 的贡献度值

    对用户而言,ILF 与EIF 的业务意义是完全不同。因此,对于贡献度相同的 ILF 和EIF,其未调节功能点值是不同的。

    在这里插入图片描述

    4、 度量事物功能

    事物功能的计算工序(Counting Procedures)包括以下活动:

    在这里插入图片描述

    FPA 将事物功能分为三类,外部输入(EI)、外部输出(EO)和外部查询(EQ)。

    1) 识别外部输入(EI):是处理来自系统边界外部的数据或控制信息的一个基本过程。其首要目的(Primary Intent,简称 PI) 是维护一个或多个ILFs 或者去改变系统行为。

    2) 识别外部输出(EO):是发送数据或控制信息到系统边界外部的一个基本过程。其首要目的(PI)是通过处理逻辑呈现信息给用户,并非或者另外检索数据或控制信息。

    3) 识别外部查询(EQ):是发送数据或控制信息到系统边界外部的一个基本过程。其首要目的(PI)是通过从一个 ILF 或EIF 检索数据或控制信息,呈现信息给用户。

    4) 基本过程

    把功能用户需求组合或分解为最小活动单元,满足以下条件:

    1. 对用户有意义,构成一个完整的事务;

    2. 自包含;

    3. 使应用的业务保持持续状态,

    例 :功能用户需求要求提供维护员工信息的功能。该需求被分解为较小的工作单元,如添加员工信息、修改员工信息、删除员工信息和查询员工信息。

    5) 识别事物功能 DET

    数据元素类型(Data Element Types,简称DET)是指在一个EI、EO 或EQ 内,用户可认知的、唯一的、非重复的字段。

    6) 识别事物功能 FTR

    引用文件类型(File Types Referenced,简称FTR)是指一个交易功能读取或维护的一个ILF,或者一个交易功能所读取的一个
    EIF。

    7) 确定EI、EO 和EQ 的贡献度

    根据每一个已确认的 EI、EO 和EQ 的复杂度(FTRs 和DETs 数量),对其进行分类,并赋予未调节功能点数值(Unadjusted Function Points)的过程,即为确定其贡献度。

    在这里插入图片描述

    在这里插入图片描述

    8) 确定EI、EO 和EQ 的贡献度

    我们应注意到,贡献度相同的 EI、EQ,其未调节功能点值是相同的;与EI、EQ 贡献度相同的 EO,其未调节功能点值略高。

    在这里插入图片描述

    5、 计算功能规模

    1) 计算未调整功能点数

    UFP= ILFs+EIFs+EIs+EOs+EQs

    2) 确定系统调节因子

    在实际软件项目开发过程中因技术因素和环境因素会对软件项目工作量有不同程度的影响。可根据组织级基准库设定相关调整因子(System Adjustment Factor,简称SAF)。如应用类型、质量特征、开发语言、团队背景、评估时点等。

    计算调整后的功能点数  AFP=UFP*SAF

    3) 确定生产率PDR

    可根据系统特点测算组织级系统基准生产率。

    4)测算工作量

    工作量  AE=AFP*PDR

    6、 报告功能点计数结果

    将功能点计数过程和工作量计数结果编写报告呈现给读者。

    二、 COSMIC 方法

    (一) 简介

    COSMIC 是通用软件度量国际联盟的简写(Common Software Measurement International Consortium,COSMIC),它成立于1998 年,是一个由全球软件度量专家组成的非盈利自愿性组织,致力于软件规模度量方法的研究与推广。2002 年 1 月COSMIC 所推出的全功能点规模度量方法成为了 ISO 的标准,最新标准为 ISO/IEC 19761:2011“软件工程—COSMIC—功能规模度量方法”。

    COSMIC 方法包含了一组应用模型、原则、规则和过程度量给定软件的功能性用户需求的方法。其结果是一个数字化的“量化数值”,根据 COSMIC 方法得到的软件功能规模。它适用于以下领域的软件功能度量:

    业务应用软件,这类软件通常用于支持业务管理。如银行、保险、电信等。 
    
    实时软件。用于过程控制和自动数据获取软件。如嵌入式程序、中间件。
    
    平台软件,如可复用的构建及设备驱动程序等。
    

    功能规模是通过“数据移动(Data movement)”的个数来度量。

    (二) 原理

    功能规模是通过“数据移动(Data movement)”的个数来度量。

    (三) 度量过程

    COSMIC 方法的度量分为三个阶段:

    1、 度量策略阶段

    确定度量目的 
    
    确定度量范围 
    
    确定功能用户 
    
    确定需求描述详细程度
    

    2、 映射阶段

    识别功能处理 
    
    识别兴趣对象与数据组(兴趣对象指软件要处理的数据对象,如客户;数据组是一组兴趣对象属性的组 合,如客户姓名、年龄,联系方式等)
    
    识别数据属性
    
    识别数据移动(输入、输出、读、写)
    

    3、 度量阶段

    新增需求计数
    
    变更需求计数
    
    本地化规则计数(定制规则)
    
    生成度量报告 
    

    (四) 数据移动种类

    4 种类型的数据移动:输入(Entry)、输出(eXit)、读(Read) 和写(Write)。

    输入(E),是从用户穿越被度量系统的范围传输数据到系统内部,这里提到的用户既包括系统的使用人员,也包括其他软件或者硬件系统。
    
    输出(X),是一个数据组从一个功能处理通过范围移动到需要它的用户。
    
    读(R),是从永久性的存储设备读取数据。
    
    写(W),是存储数据到永久性的存储设备。
    

    (五) 示例

    用户借阅图书,图书管理员需录入借阅人信息并保存到数据库中,同时提供查询登记列表功能。此时录入借阅人信息为一个输入
    CFP,提示信息为一个输出 CFP,保存录入信息为一个写CFP,查询登记列表功能查询条件输入为一个输入CFP 和从数据库读取登记信息为一个读CFP。然后汇总计算出总功能点数为 5 个 FP。

    原则:每一个功能必须有一个输入,一个输出或一个写,即至少2 个CFP

    (六) 工作量测算

    参考FPA 方法和用例点方法工作量测算方法,设定相关技术调整因子和环境调整因子以及生产率,测算软件工作量。

    使用COSMIC 方法要求度量者对软件系统的实现非常清楚,了解系统的内部结构,并对系统能够明确划分出应用层级,以及层级之间的数据处理和数据移动。

    三、用例点方法

    用例点方法(use case point method,UCP),是由Gustav Karner在1993年针对FPA(function point access)方法而提出的一种改进方法,是在面向对象开发方法中基于用例估算软件项目规模及工作量的一种方法。UCP的基本思想是利用已经识别出的用例和执行者,根据他们的复杂度分类计算用例点。

    用例模型(Use-Case Model)是系统功能及系统环境的模型, 它可以作为客户和开发人员之间的契约。用例贯穿整个系统开发的一条主线。同一个用例模型即为需求工作流程的结果,可当做分析设计工作流以及测试工作流程的输入使用。

    UCP 估算是以用例模型为基础,通过计算用例点和项目生产率的取值,计算用例点和工作量的换算,得到项目开发所需的以人小时数为单位的工作量。UCP 算法受到 FPA 和MKⅡ方法的启发,在对Use Case 的分析的基础上进行加权调整得出的一种改进方法。

    UCP 估算方法的基本步骤如下:

    1) 对每个角色进行加权,计算未调整的角色的权值UAW;

    2) 计算未调整的用例权值UUCW;

    3) 计算未调整的用例点 UUCP;

    4) 计算计数和环境因子 TEF;

    5) 计算调整的用例点UCP;

    6) 根据规模和工时的转换因子来计算工作量。

    (一) 估算用角色值UAW

    首先将软件需求用Use Case 方式表达,其次利用参与者的数量乘以相应的权值来计算 UAW。

    在这里插入图片描述
    (二) 估算用例权值 UUCW

    利用Use Case 的数量乘以相应的权值来计算 UUCW。

    在这里插入图片描述

    (三) 估算未调整的用例点 UUCP

    估算未调整的用例点(UUCP),将角色权值和用例权值相加即为未调整的用例点数:

    UUCP=UAW+UUCW

    (四) 估算技术和环境因子 TEF

    UCP 估算方法中有 21 个适用性因子,其中包括开发系统的技术复杂度和开发环境,即分为 13 个技术复杂度和 8 个环境复杂度因子。

    1、技术复杂度因子 TCF:其中权重为该复杂度对系统的影响权值,value 为影响等级 0-5 之间的值来确定。0 表示技术因子与本项目无关;3 表示技术因子对本项目的影响一般;5 表示改技术因子对本项目有很强的影响。
    在这里插入图片描述

    在这里插入图片描述

    2、环境复杂度因子:其中权重为该复杂度对系统的影响权值,value 为影响等级 0-5 之间的值来确定。0 表示项目组成员都不具备该因素;3 表示环境因子对本项目的影响程度为中;5 表示本项目组成员都具有该因素。

    在这里插入图片描述

    在这里插入图片描述

    (五) 估算UCP

    以上UUCP、TCF、ECF 三个参数每个参数都是独立定义和计算。经过技术因子和环境因子对UUCP 调整后得到UCP 完整公式为:

    UCP=UUCPTCFECF

    (六) 估算工作量

    项目工作量估算也就是 UCP 的值乘以相对应的生产率PF。

    工作量  AE=UCP*PF

    展开全文
  • 几个主要软件调试方法及调试原则

    万次阅读 2014-07-31 17:40:11
    软件调试是在进行了成功的测试之后才开始的工作,它与软件测试不同,调试的任务是进一步诊断和改正程序中潜在的错误。   调试活动由两部分组成: u 确定程序中可疑错误的确切性质和位置 u 对程序(设计,编码...

    调试(Debug)

     

    软件调试是在进行了成功的测试之后才开始的工作,它与软件测试不同,调试的任务是进一步诊断和改正程序中潜在的错误。

     

    调试活动由两部分组成:

    u  确定程序中可疑错误的确切性质和位置

    u  对程序(设计,编码)进行修改,排除这个错误

     

    调试工作是一个具有很强技巧性的工作

     

    软件运行失效或出现问题,往往只是潜在错误的外部表现,而外部表现与内在原因之间常常没有明显的联系,如果要找出真正的原因,排除潜在的错误,不是一件易事。

     

    可以说,调试是通过现象,找出原因的一个思维分析的过程。

     

    调试步骤:

    (1)      从错误的外部表现形式入手,确定程序中出错位置

    (2)      研究有关部分的程序,找出错误的内在原因

    (3)      修改设计代码,以排除这个错误

    (4)      重复进行暴露了这个错误的原始测试或某些有关测试。

     

     

    从技术角度来看查找错误的难度在于:

     

    u  现象与原因所处的位置可能相距甚远

    u  当其他错误得到纠正时,这一错误所表现出的现象可能会暂时消失,但并为实际排除

    u  现象实际上是由一些非错误原因(例如,舍入不精确)引起的

    u  现象可能是由于一些不容易发现的人为错误引起的

    u  错误是由于时序问题引起的,与处理过程无关

    u  现象是由于难于精确再现的输入状态(例如,实时应用中输入顺序不确定)引起

    u  现象可能是周期出现的,在软,硬件结合的嵌入式系统中常常遇到

     

     

    几种主要的调试方法

     

    调试的关键在于推断程序内部的错误位置及原因,可以采用以下方法:

     

    强行排错

     

    这种调试方法目前使用较多,效率较低,它不需要过多的思考,比较省脑筋。例如:

    通过内存全部打印来调试,在这大量的数据中寻找出错的位置。

    u  在程序特定位置设置打印语句,把打印语句插在出错的源程序的各个关键变量改变部位,重要分支部位,子程序调用部位,跟踪程序的执行,监视重要变量的变化

    自动调用工具,利用某些程序语言的调试功能或专门的交互式调试工具,分析程序的动态过程,而不必修改程序。

     

    应用以上任一种方法之前,都应当对错误的征兆进行全面彻底的分析,得出对出错位置及错误性质的推测,再使用一种适当的调试方法来检验推测的正确性。

     

    回溯法调试

     

    这是在小程序中常用的一种有效的调试方法,一旦发现了错误,人们先分析错误的征兆,确定最先发现“症状“的位置

    然后,人工沿程序的控制流程,向回追踪源程序代码,直到找到错误根源或确定错误产生的范围,

    例如,程序中发现错误处是某个打印语句,通过输出值可推断程序在这一点上变量的值,再从这一点出发,回溯程序的执行过程,反复思考:“如果程序在这一点上的状态(变量的值)是这样,那么程序在上一点的状态一定是这样···“直到找到错误所在。

     

     

     

    归纳法调试

     

    归纳法是一种从特殊推断一般的系统化思考方法,归纳法调试的基本思想是:从一些线索(错误征兆)着手,通过分析它们之间的关系来找出错误

     

    u  收集有关的数据,列出所有已知的测试用例和程序执行结果,看哪些输入数据的运行结果是正确的,哪些输入数据的运行经过是有错误的

    u  组织数据

    由于归纳法是从特殊到一般的推断过程,所以需要组织整理数据,以发现规律

     

    常以3W1H形式组织可用的数据

    “What“列出一般现象

    “Where“说明发现现象的地点

    “When“列出现象发生时所有已知情况

    “How“说明现象的范围和量级


    “Yes“描述出现错误的3W1H;

    “No“作为比较,描述了没有错误的3W1H,通过分析找出矛盾来

     

    提出假设

    分析线索之间的关系,利用在线索结构中观察到的矛盾现象,设计一个或多个关于出错原因的假设,如果一个假设也提不出来,归纳过程就需要收集更多的数据,此时,应当再设计与执行一些测试用例,以获得更多的数据。

     

    证明假设

    把假设与原始线索或数据进行比较,若它能完全解释一切现象,则假设得到证明,否则,认为假设不合理,或不完全,或是存在多个错误,以致只能消除部分错误

     

     

    演绎法调试

     

    演绎法是一种从一般原理或前提出发,经过排除和精华的过程来推导出结论的思考方法,演绎法排错是测试人员首先根据已有的测试用例,设想及枚举出所有可能出错的原因作为假设,然后再用原始测试数据或新的测试,从中逐个排除不可能正确的假设,最后,再用测试数据验证余下的假设确是出错的原因。

     

    列举所有可能出错原因的假设,把所有可能的错误原因列成表,通过它们,可以组织,分析现有数据

    利用已有的测试数据,排除不正确的假设

    仔细分析已有的数据,寻找矛盾,力求排除前一步列出所有原因,如果所有原因都被排除了,则需要补充一些数据(测试用例),以建立新的假设。

     

    改进余下的假设

    利用已知的线索,进一步改进余下的假设,使之更具体化,以便可以精确地确定出错位置

     

    证明余下的假设

     

     

    调试原则

    n  在调试方面,许多原则本质上是心理学方面的问题,调试由两部分组成,调试原则也分成两组。

    确定错误的性质和位置的原则

    u  用头脑去分析思考与错误征兆有关的信息

    u  避开死胡同

    u  只把调试工具当做辅助手段来使用,利用调试工具,可以帮助思考,但不能代替思考

    u  避免用试探法,最多只能把它当做最后手段

     

    修改错误的原则

     

    u  在出现错误的地方,很有可能还有别的错误

    修改错误的一个常见失误是只修改了这个错误的征兆或这个错误的表现,而没有修改错误的本身。

    u  当心修正一个错误的同时有可能会引入新的错误

    u  修改错误的过程将迫使人们暂时回到程序设计阶段

    u  修改源代码程序,不要改变目标代码

    展开全文
  • camera常见问题和调试方法

    千次阅读 2013-07-30 11:10:40
    如果你碰到类似的问题,如果你认真阅读下面的资料,相信大部分的问题你可以在短时间内解决的同时伴随着Debug能力的提高,当然如果你们觉得哪一条写的不够清楚的地方,也请随时反馈给我们,我们将
  • ShellCode的调试方法常见问题的解决方法   ShellCode的调试方法,我这里总结了四种方法,其实原理都一样,就是通过几种指令的组合,把EIP改为shellcode的地址,然后跳到shellcode去执行,再调试shellcode。代码...
  • 如何在较短时间内熟悉软件测试的基础知识、并掌握一定的软件测试基本方法,读书就是一个比较好的办法。  因此小编整理了几本软件测试方面的书籍,本文首先介绍了软件测试书籍三步曲,分别是基础知识类、进阶类以及...
  • 进入移动互联网时代,移动广告给广告主带来丰厚流量收益的同时,广告作弊相关灰色产业链的潜在威胁也给业界人士敲响了警钟:据世界广告主联合会(WFA)...一、常见的作弊行为 1、机器行为:IP重复刷量、换不同IP重...
  • 程序调试中的常见问题及解决方法

    千次阅读 2017-09-09 08:55:33
    程序调试中的常见问题及解决方法 【转载文章真麻烦_(:з」∠)_】
  • 浅谈《软件工程》常用的几种软件开发方法

    千次阅读 热门讨论 2020-10-06 21:27:12
    目前常用的开发方法有四种,分别是结构化方法、原型法和面向对象方法。接下来我们会一一叙述这些软件开发方法的实现过程和其中的特点以及优缺点。 结构化方法 结构化方法:结构化方法是应用最为广泛的一种开发...
  • 五、单片机硬件调试常见的案例(杂记) 一、硬件调试的四个目标 1、元器件焊接正确(错焊、漏焊、虚焊);多练,能事半功倍; 2、电路的框架连接正否正确;(跳线,挑线); 3、各处的电压是否正确;(器件的...
  • 软件测试常见面试题及答案

    千次阅读 2018-01-08 14:23:59
    软件测试方法有哪些分类?各什么特点?设计测试用例的主要方法有哪些软件测试方法分类 1)白盒、黑盒、灰盒 2)单元测试、集成测试、系统测试、验收测试、回归测试、Alpha 测试、Beta 测试 3)静态测试和动态...
  • 软件中会使用各种手段防止Craker调试程序,为此我们必须了解常见的反调试技术的原理及规避方法。   调试器:OllyDbg 环境:win7 64位真机     首先我们打开这个程序,是可以正常打开的 ...
  • 软件调试的一些心得

    千次阅读 2017-07-17 19:57:21
    软件编程过程中调试是经常遇到的事,在调试的过程中也包含了很大的学问在里面,下面是自己实际应用和查找资料总结的一些,与大家进行分享;先介绍一些笨且常用的一些方法: <1> 通过内存全部打印来调试,在这大量的...
  • 软件测试方法

    万次阅读 2016-04-03 22:15:17
     软件测试方法 1. 软件测试方法包括:白盒测试(White Box Testing)、黑盒测试(Black Box Testing)、灰盒测试、静态测试、动态测试。 2. 白盒测试:是一种测试用例设计方法,在这里盒子指的是被测试的...
  • GNS3常见BUG解决方法

    千次阅读 2020-04-03 22:22:55
    BUG1:无法连接到 http: / / 192.168.44.1:3080. 快速检查是否允许 ghs3进入您的防病毒和防火墙,需要重置软件打不开cloud解决方法:1:电脑管理员运行cmd输入netshwinsockreset回车,然后重启电脑!!!!!2:重启...
  • 常见软件测试类型分类

    万次阅读 2018-09-20 09:48:05
    软件测试类型 1)回归测试 回归测试: (regression testing): 回归测试两类:用例回归和错误回归;用例回归是过一段时间以后再回头对以前使用过的用例在重新进行测试,看看会重新发现问题。错误回归,就是在新...
  • VC 调试中一些常见的错误信息及解决方法: 1、调试时出现 LIBCD.lib(crt0.obj) : error LNK2001: unresolved external symbol _main 错误 原因:需要 MFC 支持的程序需要用 win32 Application 来生成,如果用 win...
  • 几种常见软件过程模型的比较

    千次阅读 2018-09-08 17:32:22
    瀑布模型(经典生命周期)提出了软件开发的系统化的、顺序的方法。其流 程从用户需求规格说明开始,通过策划、建模、构建和部署的过程,最终提供一 个完整的软件并提供持续的技术支持。 优点: 1. 强调开发的阶段...
  • 的时候仍然会存在有些元件找不到的情况,只要添加该元件相应的库即可,例如 Altium Designer error: 1.Net TDO has only one pin (Pin U3-39) 解决:放置网络标号的时候需要在导线上出现红色的X字,才算成功添加,...
  • 软件工程:软件工程过程与方法

    万次阅读 2016-06-23 17:29:48
    随着软件规模的日益庞大,用户需求的不确定以及快速变更,使得软件开发已经不能停留在小作坊式的个人英雄时代,它已经发展为如今的依赖团队合作的行为,常规的管理方法已经无法满足软件开发的实际需求。而软件工程...
  • STM32调试过程中常见的问题及解决方法 一、 在“Debug选项卡”下设置好仿真器的类型后,下载程序时却提示“No ULINK Device found.”    解决办法: Keil MDK默认使用ULINK仿真器下载程序,在“Project -...
  • 软件工程常见的名词解释

    千次阅读 2018-02-22 15:52:35
    软件工程:将系统的、规范的、可量化的方法应用于软件的开发、运行和维护的过程及上述方法的研究。设计模式:是指以设计复用为目的,采用一种良好定义的、正规的、一致的方式记录的软件设计经验。交互图:描述对象...
  • 软件测试总结——常见的面试问题(一)

    万次阅读 多人点赞 2019-10-12 18:40:58
    1.软件测试级别? 单元测试:单元测试是对软件组成单元进行测试。其目的是检验软件基本组成单位的正确性。测试的对象是软件设计的最小单位:模块。Findyou又称为模块测试,一个单元测试是用于判断某个特定条件...
  • 第3部分 软件研发工作总结VC++集成开发环境中Linux下Pclint工程的配置方法常见错误修改 【文章摘要】 Pclint是一种C/C++软件代码静态分析工具。它是一种更加严格的编译器,能够发现普通编译器所不能发现的代码中...
  • 面试常见问题——软件工程(一)

    千次阅读 多人点赞 2016-10-09 16:42:13
    5、人认为软件开发时,一个错误发现得越晚,为改正它所付出的代价越大。提出你的观点并解释原因。从项目经理出发,如何管理软件项目 6、数据流图的作用和基本成分 7、软件工程定义,与软件工程方法学的关系 8、...
  • (二)您所熟悉的测试用例设计方法有哪些?请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。(三)我现在个程序,发现在Windows上运行得很慢,怎么判别是程序存在问题还是软硬件系统存在问题?...
  • 常见问题一: 统一性不要在软件中使用中英文混合的提示,比如对于用户的操作提示,不要一会用“error”一会用“错误”;一会用“succeed”另一会用“成功”总之要统一。某局长使用心得:删除的时候提示Error,幸亏我...
  • 常见加壳软件 及脱壳工具

    千次阅读 2019-04-20 18:01:20
    常见的程序制作语言: Borland Delphi 6.0 - 7.0 Microsoft Visual C++ 6.0 Microsoft Visual Basic 5.0 / 6.0 还有汇编、易语言等。 很多软件都通过加壳保护来提高软件的破解难度,下面我们简单的介绍一下加壳...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 169,539
精华内容 67,815
关键字:

常见的软件调试方法有哪些