-
搜索引擎评测
2011-03-24 10:10:37
我们先分析一下几个重要评测要素的能力缺陷：一：查全率
既然是搜索引擎，首先比搜索范围是天经地义的事，如果这条不及格，后边的评测好象也不用参加了。由于收录网页的数量都是各搜索引擎自己宣布的，未可全信，而同一个关键词的搜索结果却是显而易见的，所以一般的评测都以这个为准。
但以这个为准还是有很多毛病，多数象样一点的搜索引擎我都可以找出一批关键词来证明它的搜索结果是最全的。因为网页索引数量虽然有大小，但robot和spider程序不同，索引范围和索引标准也不尽相同，在最大的搜索引擎上搜不到的有可能在小得多的搜索引擎上搜到。
有的搜索引擎支持“的，about，了，of，啊，么”等虚词助词搜索，有的不支持，这又如何来比？哪次评测提到过？
关键词除了内容难选择，在长短上也不好定。有的搜索引擎完全不支持单个汉字搜索，怎么算它？一般都只比较单关键词搜索，而多关键词的搜索呢？长句的搜索呢？甚至有搜索引擎能支持任意文章或片段作为关键词，这样比较出来的结果跟单关键词搜索出来的可是不一样的，更别提没法比的功能了。象excite这样语义搜索的引擎，还有支持模糊搜索的引擎，别的搜索引擎搜索结果极少甚至为零的关键词它们可以搜出一大堆结果，这又如何比较？
最后一点，搜索引擎是可以针对特定的关键词进行结果优化的，评测的公正性谁来保证？如果其中某个被评测搜索引擎事先知道所用的关键词，那么只要轻松优化一下，冠军就非它莫属了。二：搜索速度
比完了查全率，就该比搜索速度了，如果有搜索引擎索引的网页虽多，但是搜索一次要五、六秒或更长，直接请它出局吧，没有比下去的意义了。
速度的问题首先还是在关键词，单关键词搜索快的不一定多关键词搜索快。
然后是访问量的问题，对一个日访问量一亿以上的搜索引擎和一个日访问量几万的搜索引擎作同样的测试本身已是不公平。
还有网页索引数量的问题，一个搜索引擎索引了10亿的网页，另一个搜索引擎索引了一千万的网页，让它们对同一个关键词在各自的数据库里搜索比搜索速度，这样的结果如何让人信服？
除了事先优化的问题外，有的搜索引擎本就具有记忆搜索结果加速调用的能力，一个关键词哪怕第一词搜索花了10秒，第二次搜索也许就2秒了，第三次，第四次，到你去测试的时候已经永远是0.0001秒了。这样，如果你选常见词测试，它快得惊人，如果来个偏僻词，也许老半天出不来，到底该选什么关键词？常用和偏僻各占多少？这真是一笔糊涂帐。
搜索引擎不是放在实验室的本地机上测试用的，而是给普通网友用的，所以这搜索时间应该还包括搜索界面和搜索结果的传输过程在内。一个搜索引擎搜索时间花了0.0001秒，但是传输结果网页花了3秒，另一个搜索花了0.5秒，但是传输网页结果花了一秒，你说哪个搜索引擎算快？真正用的时候，你选那个3.0001秒以后看到搜索结果的还是1.5秒以后看到搜索结果的？三：查准率
这个相当重要，搜到的东西即使又多又快，但你想要的那条结果不知道要翻多少页才能找到，那这搜索结果要来何用？这样的搜索引擎只有在查稀罕东西时才有用，但是要查稀罕东西应该去元搜索引擎呀，干吗要用它？查准率的评价标准很难定，得看你查什么，你要查一个特定的网站和找一群相似网站根本就是两回事。查准率的关键还是在于要搜什么和选择什么关键词，评测人可以随意定夺的，然后影响到评测结果的可靠性。
四：死链接
普通搜索引擎总有些搜索结果是点不进去的，少到百分之一二，多到百分之八九，这个也常被用作评测条件之一。但是象google使用了网页快照功能，几乎不存在死链接问题，就算搜索结果中的那个网站已关闭，你还是可以看到google自己储存的网页。这种死链接怎么计算？
五：用户负担
还没见过国内搜索引擎评测有谁用过这一项，但它是评价搜索引擎优劣的重要因素，包括很多方面。搜索引擎是给人用的，一定要让人用得舒服方便快捷，任何妨碍和延迟用户到达最终搜索结果的都算用户负担。
首先是搜索界面，一个只有搜索框的纯粹搜索引擎界面跟一个带有广告和大量网页内容的门户相比，它们带给用户的搜索负担是高下立判的。其次是搜索结果描述，搜索结果网页的文字描述是长还是短，网页文字描述采用索引带关键词的部分还是索引网页的开始几行还是索引网页的主要内容，关键词是否高亮显示又采用什么颜色，是否显示网页地址，还有搜索结果页面的布局，这些对于用户的搜索负担区别大大的有。
再者就是对用户操作步骤的影响，是否可以用鼠标启动搜索，搜索结果每页显示数量是否只有10条，翻页的便捷与否，搜索框是两个还是一个，放在上边还是下边，一次搜索后关键词是否还在搜索框中显示，这些每一条都会影响搜索效率。
六：其它还有
是否支持本目录下搜索，
internet索引数据库更新时间长短，
搜索引擎的稳定性，
对高级搜索的支持能力强弱等也应该加以评测 -
搜索引擎测试的难点
2011-03-24 09:34:53
衡量搜索引擎系统功能质量方面有2大指标，查询率、查准率。性能方面从吞吐率、响应时间、系统资源消耗等多方面综合考虑。
搜索引擎应用参与运作的角色划分：分发请求/合并查询结果的merger，以及查询服务的searcher。
搜索引擎系统部署可以划分为：
1) 1个Merger带N个searcher，searcher上数据一样 (分布式单个集群多台机器) ，N>=1且为整数。
2) 1个机器同时充当Merger以及searcher (单机版)。
3) 为避免2)单点故障，几台机器同时为merger/searcher，机器的数据一样。
4) M个分布式单个集群多台机器组成1个大型的分布式多集群多机器的复杂环境。
实践中3)、4) 2种部署模式都是存在的。
大数据量、高吞吐率的都采用4)，避免单点故障
小型的数据采用3)，节约成本。
单机上搜索引擎的模块划分一般有：
● 索引模块：为海量数据（数据库导出的文件数据）建立索引文件（依照一定数据结构格式保存为二进制文件）
● 查询模块：接收http请求，查询本机硬盘上的索引文件，返回文档ID以及第二次查询时返回具体的内容
● 即时更新模块：加入新的数据，可以从0开始重新建索引，也可以在原有基础上增加索引。
● 分布式模块：merger/searcher多台机器的网络通信。
● CACHE模块：这里可以做查询请求的缓存，也可以做查询结果的缓存，但缓存后者的话，将极大消耗系统内存。
● 其他管理模块
● 外部接口
基于如上复杂的系统架构，尤其是4)模式，我们在测试当中也碰到相当多棘手的技术问题：
1) 海量数据是否都按预期的分词算法建立索引了呢？
2) 机器分词的效果与手工分词相差有多大呢？
3) 海量查询的返回结果是否多查了？
4) 海量查询的返回结果是否漏查了？
5) 海量查询的返回结果的加亮、标注如期加了？
6) 海量查询的返回结果中相关性分数计算是否正确？
7) 海量查询的返回结果积分计算是否正确了呢？
8) 海量查询的返回结果积分相同时，排序的先后依据唯一么？
9) 加入即时更新模块后，每次查询结果都不同，新建的索引内容是否都反馈到查询结果里面了呢？
10) 海量数据时CACHE是否预期CACHE该cache的内容？
11) 海量数据时CACHE是否依照一定的过时算法令cache的内容失效呢？
12) 应用程序在32位LINUX操作系统和64位的LINUX的索引、查询结果是否依然一样？
13) 应用程序在不同的OS上索引、查询结果是否依然一样？
我们在实践中，针对查询结果正确性有3类方法处理以上问题：
第一类，基于人工肉眼对比，极度耗费脑细胞。
1) 少量数据单机测试准确性
2) 少量数据1个集群，搭建1merger 1searcher测试准确性
3) 少量数据1个集群，搭建1merger多searcher测试准确性
4) 少量数据多个集群，搭建1merger多searcher测试准确性
第二类，经过人工对比确认基本功能无大问题后，开发linux shell脚本或者loadrunner脚本比较部署方式不同但测试返回结果理当相同的。这个方法也帮我们发现了一些BUG
第三类方法，直接测试大量数据多个集群，搭建1merger多searcher测试准确性。
这个时候采用loadrunner施加高峰压力，抽样检查查询请求的正确性。
对于分词结果、相关性的结果，有人可能建立另外按照同样的算法以及输出格式，由2个不同的开发工程师实现，再对比同样的数据分词、相关性是否相同。在项目开发时间从容的情况下，可以考虑这么做的，但现实中有几个项目时间从裕？呵呵，我没有这么好运气遇上。
-
搜索引擎的主要指标
2011-03-24 09:34:16
搜索引擎的主要指标有响应时间、召回率、准确率、相关度等。这些指标决定了搜索引擎的技术指标。搜索引擎的技术指标决定了搜索引擎的评价指标。好的搜索引擎应该是具有较快的反应速度和高召回率、准确率的，当然这些都需要搜索引擎技术指标来保障。
召回率：一次搜索结果中符合用户要求的数目与用户查询相关信息的总数之比
准确率：一次搜索结果中符合用户要求的数目与该次搜索结果总数之比
相关度：用户查询与搜索结果之间相似度的一种度量
精确度：对搜索结果的排序分级能力和对垃圾网页的抗干扰能力 -
搜索引擎测试方法【转】
2011-03-24 09:31:33
搜索引擎的测试也分为功能与性能测试，我在下面依次来分享：首先，我们把整个测试计划分为线下测试与线上测试。线下与线上测试都要分功能测试与性能测试，先说现线下的测试。
一、线下功能测试分为两个部分，一部分为搜索引擎本身的功能测试，一部分为嵌套在前台应用中的功能测试：
1、搜索引擎本身的功能测试，主要就是按照用例，通过不同的搜索关键字、属性的组合（按照搜索引擎的规则）来直接访问搜索引擎，查看返回的数据、参数是不 是符合原先预计的结果。可以编写脚本来批量执行，判断每一个搜索的返回结果数与内容，相对应的参数是否一致。也可以手工执行，使用浏览器或者命令行（如 curl）来做，用肉眼来观察结果。
2、嵌套前台应用的功能测试，只要就是按照用例通过前台的操作，来测试搜索引擎的相关的功能，测试搜索引擎与前台的接口是否正确应用，至于如何测试，这个地球人都知道了，我就不在这里多说了。
二、线下性能测试也分为两个部分，一部分为直接对搜索引擎进行加压的性能测试，另一部分为通过前台应用进行加压的性能测试：
1、直接对搜索引擎进行加压，可以测试出搜索引擎本身最真实的性能状况。可以把搜索引擎的有效负荷，最大承受的压力测试出来。具体的方法是，使用工具如 loadrunner使用一个web_url直接加压，加压的内容其实就是你在功能测试中，直接测试搜索引擎时使用的那些搜索关键字、属性的组合（按照搜 索引擎的规则），具体的规则可以通过log来查看，也可以询问开发人员。需要注意的是，数据准备一定要海量，至少10万条以上的搜索数据（注意，就是你访 问搜索引擎的那些关键字组合，至于被搜索的数据，越大越好，最少多大，看你实际需要了）。当一切都准备完毕后，就可以启动工具来进行加压了。
2、通过前台应用进行加压，主要的压力都集中在前台应用上面，对于搜索引擎本身的压力并不会很大，但是这种测试也是必须的，因为你的搜索引擎是离不开前台应用的，这种测试可以模拟最真实的终端用户使用。所以不要怕麻烦，这个才是最后真正有意义的测试结果。
三、线上的功能测试，其实就是功能回归了，使用预发布环境（一套独立的缩小的线上的架构）来跑回归，手工或者自动化随便，这是不能缺少的。
四、线上的性能测试，这个也是使用预发布环境（记得一定要和线上一样哦，只不过是缩小的），分流线上的一部分压力到这里，观察线上与预发布环境中的各服务 器的情况，如果是第一次发布，线上没有流量，那么就自己来模拟，或者靠运营来宣传了（有点想网络游戏的公测）。记录下服务器的各性能指标，如 load，cpu，队列，最大并发连接数，log等等。
特别需要注意的是，不同层次服务器之间的数据传输方式，正确率以及配置，多试试不同的配置，寻找性能最优点。
-
软件测试BUG中的小概率事件
2009-07-17 10:22:37
对于用户而言，一个产品的好坏不仅仅决定于其产品的功能，而更加在于产品的可靠性及稳定性。小概率BUG则是影响产品可靠性及稳定性的主要因素。而小概率BUG的产生，一般是由于积累操作或多任务并发所引起。哪么在成本及时间等影响产品发布的条件允许的情况下，小概率BUG在产品上遗留的越少，那么产品的质量也就更好，用户对产品的体验值可能就越高。
但实际情况要解决小概率BUG并不乐观。由于小概率BUG发生的概率较小，因此不论是对于开发人员还是测试人员而言，要解决或验证小概率BUG都是一件让人头痛不已的事情。
哪么作为测试人员的我们如何把握住这仅有的一次或两次机会，以提供更多的小概率BUG信息给开发人员呢？
小概率BUG的多发地带：
1． 临界测试
2． 中断测试
3． 多任务测试
4． 积累测试
小概率BUG信息的提供：
1． 若被测终端提供LOG接口，在测试过程中一定要打开LOG跟踪工具。在BUG发生时提示LOG或图像。
2． 若发生小概率BUG，我们应该多做测试或者询问其它同事是否发生类似问题，争取找出其发生的规律。
3． 若发生的小概率BUG引发系统崩溃或主要功能无效，应及时通知开发人员。
4． 在提交小概率BUG时，一定要详细记录BUG发生的环境，测试步骤及时间点等因素。
小概率BUG的验证：
1． 小概率BUG的验证应当由发现此BUG的测试人员来进行。
2． 若小概率BUG相对轻微，在产品经理确认不必修改时，可以将其关闭或保留。
3． 若小概率BUG在验证时再次发生，应及时通知开发人员。
4． 小概率BUG连续验证3轮之后没有发生（每轮验证根据BUG的复杂度可分为20-50次），可将其关闭。
5． 对于特别严重，而开发人员又束手无策的小概率BUG，在条件允许的情况下，可让开发人员发布T版本来进行测试。
6． 对于特别严重的，而开发人员又未确认修改的小概率BUG，可在风险中提出此小概率BUG风险。
-
教你如何学会复杂千变的搜索功能用例编写
2009-07-16 16:13:12
当大家面对比如这样的高级页面搜索的时候，是不是感觉很难“下口”，同时又怕自己的测试用例写的不能很好或者完全的覆盖掉程序路径。那么。现在我给大家一个小小的方法。希望能多少对大家的用例编写能力有帮助。
前提：1.仅供学习参考用，不能将他们用作商业用途，否则将追究法律责任。
2.对黑盒测试方法有一定认识，特别是等价类和边界值比较了解。
3.具体下拉的内容不要太多关注多少，要关心的是设计思想。
废话说完，下面开始咯：1. 进行单个测试。比如
和
具体设计方法就 运用黑盒测试中的等价类和边界值就OK。
当然你觉得麻烦。不妨这样做。
用列表的方式把需要测试注意的内容列出来。（日本人喜欢这样的方法。很多日式式样书都是这样的），当然，具体的就要看公司的用例要求能不能允许了。
搞完了单体测试，那么下面就是大家认为比较难把握的复合测试了。因为涉及到的条件会非常的多，所以大家很想找到一个更加合适的方法去设计。
下面提供思路：
1.2vs2，3vs3，4vs4或者更多的去这样设计。（最笨的。这样你就不知道你到底覆盖了多少，而又还有那些没有覆盖到，这就不好以后回归的时候补充你的用例了）
2.用判定表做，然后用正交测试。（比较浪费时间，但是效率比1好，如果你的测试时间充分，那么就当是锻炼技术和你的耐心吧！所以建议可以使用，只是建议）
3.你SQL相对比较好或者开发给你足够的支持那么你直接去验证SQL语句对不对就OK了瑟。比如排序字段加域名的组合。那你看SQL是不是ORDER BY 排序字段名就OK了瑟。因为单体测试已经通过，那么现在的工作其实就是验证你的程序员是不是按照需求在后面加了相关的SQL组合查询语句。再比如状态+域名+开始时间。思路一样，留个空间给大家思考这又怎么去验证吧！！
总结之。测试并不比开发容易，有时候为了BUG的深层挖掘，常常是想很多办法才发现1个BUG。（曾经我就为1BUG找了3天才挖掘到。。）
至于工具在这个例子中的运用，我想QTP的参数化就可以帮助你解决了。那具体的过程就不废话了。赶快动手试下你现在准备测试的程序吧！！！应该会给你提供帮助的。。。。 -
软件测试中有关测试用例评审检查单的介绍
2009-07-16 15:21:10
序号 主要检查项
1 《需求规格说明书》是否评审并建立了基线？
2 是否按照测试计划时间完成用例编写？
3 需求新增和变更是否进行了对应的调整？
4 用例是否按照公司定义的模板进行编写？
5 测试用例是否覆盖了《需求规格说明书》？
6 用例编号是否和需求进行对应？
7 非功能测试需求或不可测试需求是否在用例中列出并说明？
8 用例设计是否包含了正面、反面的用例？
9 每个测试用例是否清楚的填写了测试特性、步骤、预期结果？
10 步骤/输入数据部分是否清晰，是否具备可操作性？
11 测试用例是否包含测试数据、测试数据的生成办法或者输入的相关描述？
12 测试用例是否包含边界值、等价类分析、因果图、错误推测、等测试用例设计方法？是否针对需求不同部分设计使用不同设计方法？
13 重点需求用例设计至少要有三种设计方法？
14 每个测试用例是否都阐述预期结果和评估该结果的方法？
15 需要进行打印、表格、导入、导出、接口是否存在打印位置、表格名称、指定数据库表名或文件位置；表格和数据格式是否有说明或附件？
16 用例覆盖率是否达到相应质量指标?
17 用例预期缺陷率是否达到相应质量指标? -
执行测试时应注意的问题
2009-07-15 14:34:48
测试环境搭建之后，根据定义的测试用例执行顺序，逐个执行测试用例。在测试执行中需要注意以下几个问题：
全方位的观察测试用例执行结果：测试执行过程中，当测试的实际输出结果与测试用例中的预期输出结果一致的时候，是否可以认为测试用例执行成功了？答案是否定的，即便实际测试结果与测试的预期结果一致，也要查看软件产品的操作日志、系统运行日志和系统资源使用情况，来判断测试用例是否执行成功了。全方位观察软件产品的输出可以发现很多隐蔽的问题。以前，我在测试嵌入式系统软件的时候，执行某测试用例后，测试用例的实际输出与预期输出完全一致，不过在查询 CPU 占用率地时候，发现 CPU 占用率高达 90 ％，后来经过分析，软件运行的时候启动了若干个 1ms 的定时器，大量的消耗的 CPU 资源，后来通过把定时器调整到 10ms ， CPU 的占用率降为 7 ％。如果观察点单一，这个严重消耗资源的问题就无从发现了。
加强测试过程记录：测试执行过程中，一定要加强测试过程记录。如果测试执行步骤与测试用例中描述的有差异，一定要记录下来，作为日后更新测试用例的依据；如果软件产品提供了日志功能，比如有软件运行日志、用户操作日志，一定在每个测试用例执行后记录相关的日志文件，作为测试过程记录，一旦日后发现问题，开发人员可以通过这些测试记录方便的定位问题。而不用测试人员重新搭建测试环境，为开发人员重现问题。
及时确认发现的问题：测试执行过程中，如果确认发现了软件的缺陷，那么可以毫不犹豫的提交问题报告单。如果发现了可疑问题，又无法定位是否为软件缺陷，那么一定要保留现场，然后知会相关开发人员到现场定位问题。如果开发人员在短时间内可以确认是否为软件缺陷，测试人员给予配合；如果开发人员定位问题需要花费很长的时间，测试人员千万不要因此耽误自己宝贵的测试执行时间，可以让开发人员记录重新问题的测试环境配置，然后，回到自己的开发环境上重现问题，继续定位问题。
与开发人员良好的沟通：测试执行过程中，当你提交了问题报告单，可能被开发人员无情驳回，拒绝修改。这时候，只能对开发人员晓之以理，做到有理、有据，有说服力。首先，要定义软件缺陷的标准原则，这个原则应该是开发人员和测试人员都认可的，如果没有共同认可的原则，那么开发人员与测试人员对问题的争执就不可避免了。此外，测试人员打算说服开发人员之前，考虑是否能够先说服自己，在保证可以说服自己的前提下，再开始与开发人员交流。
及时更新测试用例
测试执行过程中，应该注意及时更新测试用例。往往在测试执行过程中，才发现遗漏了一些测试用例，这时候应该及时的补充；往往也会发现有些测试用例在具体的执行过程中根本无法操作，这时候应该删除这部分用例；也会发现若干个冗余的测试用例完全可以由某一个测试用例替代，那么删除冗余的测试用例。
总之，测试执行的过程中及时地更新测试用例是很好的习惯。不要打算在测试执行结束后，统一更新测试用例，如果这样，往往会遗漏很多本应该更新的测试用例。
提交一份优秀的问题报告单
软件测试提交的问题报告单和测试日报一样，都是软件测试人员的工作输出，是测试人员绩效的集中体现。因此，提交一份优秀的问题报告单是很重要的。软件测试报告单最关键的域就是 “ 问题描述 ” ，这是开发人员重现问题，定位问题的依据。问题描述应该包括以下几部分内容：软件配置、硬件配置、测试用例输入、操作步骤、输出、当时输出设备的相关输出信息和相关的日志等。
软件配置： 包括操作系统类型版本和补丁版本、当前被测试软件的版本和补丁版本、相关支撑软件，比如数据库软件的版本和补丁版本等。
硬件配置： 计算机的配置情况，主要包括 CPU 、内存和硬盘的相关参数，其它硬件参数根据测试用例的实际情况添加。如果测试中使用网络，那么网络的组网情况，网络的容量、流量等情况。硬件配置情况与被测试产品类型密切相关，需要根据当时的情况，准确翔实的记录硬件配置情况。
测试用例输入 \ 操作步骤 \ 输出： 这部分内容可以根据测试用例的描述和测试用例的实际执行情况如实填写。
输出设备的相关输出信息： 输出设备包括计算机显示器、打印机、磁带等等输出设备，如果是显示器可以采用抓屏的方式获取当时的截图，其他的输出设备可以采用其它方法获取相关的输出，在问题报告单中提供描述。
日志信息： 规范的软件产品都会提供软件的运行日志和用户、管理员的操作日志，测试人员应该把测试用例执行后的软件产品运行日志和操作日志作为附件，提交到问题报告单中。
根据被测试软件产品的不同，需要在 “ 问题描述 ” 中增加相应的描述内容，这需要具体问题具体分析。
测试结果分析
软件测试执行结束后，测试活动还没有结束。测试结果分析是必不可少的重要环节， “ 编筐编篓，全在收口 ” ，测试结果的分析对下一轮测试工作的开展有很大的借鉴意义。前面的 “ 测试准备工作 ” 中，建议测试人员走读缺陷跟踪库，查阅其他测试人员发现的软件缺陷。测试结束后，也应该分析自己发现的软件缺陷，对发现的缺陷分类，你会发现自己提交的问题只有固定的几个类别；然后，再把一起完成测试执行工作的其他测试人员发现的问题也汇总起来，你会发现，你所提交问题的类别与他们有差异。这很正常，人的思维是有局限性，在测试的过程中，每个测试人员都有自己思考问题的盲区和测试执行的盲区，有效的自我分析和分析其他测试人员，你会发现自己的盲区，有针对性的分析盲区，必定会在下一轮测试用避免盲区。 -
猴子测试
2009-07-15 12:21:46
尽管我们的项目组使用笨猴子来寻找操作系统的bug，我们也同样找到了不少应用程序的bug。笨猴子在四种情况下对于测试产品周期内的程序非常有用：
在产品周期的早期阶段，笨猴子会找到很多很好的bug，为你节省不少的时间。笨猴子不需要知道程序的任何用户交互方面的知识。昨天编译的版本的界面是否改变或者缺少了一半，对它来说都是无所谓的。猴子会测试任何它找到的东西。因此，一旦新版本出来你就可以开始笨猴子测试。在你还在为新的界面改变而调整你的正式的自动化测试包时，笨猴子已经开始探索程序并且很可能已经找到bug了。
笨猴子能运行很长时间的测试。除非找到了引起程序崩溃的bug，你想让他们运行多长时间他们就会运行多长时间，把内存和资源使用推到极限。如果你的程序有资源泄漏或者内存问题，笨猴子会帮你找到它。
在产品周期的后半段，当你在想你已经找到了所有的可恶的bug，笨猴子测试能帮助你提高你的信心。运行笨猴子几天的时间而没有引起错误能让你从另外一个角度来判断程序的稳定性。
笨猴子测试能显示传统测试覆盖的漏洞。用覆盖率分析工具运行几个小时的笨猴子测试，然后与那些非猴子测试进行比较。如果猴子测试测试到的一个函数是没有被你的传统测试所覆盖的，那么你需要重新检查你的测试计划和用例。如果你有程序的状态表，让猴子读入这个状态表，并核对每个测试到的状态。如果它找到一个新的状态是没有在你的状态表中定义的，那么猴子就找到了一个崭新的未被测试的、可能充满了bug的程序区域 – 就像在β象限仪的中心地带发现了一个蛀洞一样！至少有一个商业工具（Rational的TestFactory）使用笨猴子方法来探索应用程序并创建自动化测试来最大化覆盖率，同时最小化测试时间。
（你也许会对笨猴子能达到的测试覆盖率感到惊讶。在一个微软内部的应用程序，复杂度类似于写字板，我们在不到15分钟的笨猴子测试中就得到了65%的代码函数覆盖率。）
笨猴子测试的成本
相对聪明猴子和大部分传统的自动化和手工测试，笨猴子是非常“便宜的”。一个笨猴子可以测试几乎所有的应用程序。因此你可以把它调整到很多不相关的项目中。
如果笨猴子能知道一些关于你的程序的信息，则会得到更佳的效果。如果你能告诉猴子什么地方是程序窗体值得注意和测试的地方，则猴子会少浪费很多时间。但是给予笨猴子太多的知识则会带来更高的成本。我们的目标是花少于30分钟的时间来教会笨猴子学习一个新的程序。
一旦你给了笨猴子探索程序需要的最基本的信息后，把它安置在一台残旧的、运行速度慢的、被放在实验室或办公室角落的、没人会用来做测试的计算机上。让它开始在调试器模式下运行程序并每天检查一下它的进展情况。如果猴子发现了bug，那么这些是你的项目组报告的bug中最低成本的。 [Page]
像其他软件测试工具一样，一个好的笨猴子需要一定的代价来开发。但是不像很多测试工具，
一个普通的笨猴子或“初学者”都能有很多发现bug的机会，只要你以合适的目的，在适当的时间运行它。随着猴子显示出它的价值，你可以添加更多的功能特性，给它更多的技巧。如果你在Windows平台上使用Rational Visual Test，你就可以开始尝试使用笨猴子，使用基于我们微软内部的一个简化的测试猴子。
（“Freddie”笨猴子是一个在Thomas R.Arnold的《Visual Test 6 Bible》这本书附带的光盘上的程序。这本书的第14章详细描述了猴子测试，并教你怎样给Freddie添加更多的功能特性。）
请做出明智的选择
猴子测试绝对不应该只是你唯一的测试方法。猴子不了解你的程序，出于无知它们会漏掉很多bug。对于嵌入式系统，在简单环境下运行的软件，或者是很难实现自动化的项目，猴子都不会有什么大的作用。
除非你已经有一个自动化的可读入的模型或状态表，否则聪明猴子的开发成本会非常的高。但是对于项目的关键部分，有一个简单的小的状态表，则会比较有效。对于压力测试和负载测试也很有用。在正确的地方使用的话，聪明猴子会找到很多有意义的bug。
能理解操作系统的笨猴子可以在各种程序中使用，可以测试很多基本的东西。给你的猴子一些适当的教育，就能有效地提高猴子发现bug的机会。笨猴子不会找到很多的bug，但是它们找到的bug是程序崩溃，程序不响应等严重类型的，都是你最不想它们出现在产品中的bug。 -
BVT测试（冒烟测试）
2009-07-14 17:02:00
BVT测试介绍：
BVT测试也称为"冒烟测试".版本验证测试 （BVT） 通常由一组广泛的测试组成，这些测试用于验证特定版本的总体质量。BVT 通常根据设定的计划自动运行，经常在夜间进行。也可以手动运行，例如自动运行失败后。如果 BVT 中的所有测试均已通过，则认为该版本成功。就是拿到一个软件，首先不急于完全测试，而是在很短的时候内把软件的基本功能走一遍，看有没有什么大的问题，如果存在大的问题，就没有必要再进一步测试了。可以节约时间，提高测试效率。冒烟测试，也有称作烟雾测试（smoke Test）：一种用于验证系统基本功能的实现并达到一定程度的稳定性的测试。这种测试经常用作进入下一个等级的测试的入口准则的一部分。关于冒烟测试，应该是微软首先提出来的一个概念，和微软一直提倡的每日build有很密切的联系。具体说冒烟测试就是在每日build建立后对系统的基本功能进行简单的测试，这种测试强调功能的覆盖率，而不对功能的正确性进行验证。从这一点看和所谓的“接受性（验收）测试（Acceptance Test）”非常相似。不同之处就在于他们执行的频率和被测的版本不同。至于冒烟测试这个名称的来历，大概是从电路板测试得来的。因为当电路板做好以后，首先会加电测试，如果板子没有冒烟在进行其它测试，否则就必须重新来过。类似的如果冒烟测试没有通过，那么这个build也会返回给开发队伍进行修正，测试人员测试的版本必须首先通过冒烟测试的考验。冒烟测试应该是对整个系统流程从输入到输出的完整测试。测试不必是面面俱到的，但是应该能够发现系统中较大的问题。冒烟测试应该是足够充分的，通过了冒烟测试的build就可以认为是经过充分测试、足够稳定的。不进行冒烟测试的build是没有太大价值的。冒烟测试就像一个哨兵，在阻止着产品质量恶化和集成问题的产生，不进行冒烟测试，每日构造可能会变成浪费时间的练习。冒烟测试必须随着系统的扩充而扩充。最初，冒烟测试可能是非常简单的，比如验证系统是否会打印“Hello World”，随着系统功能的扩充，冒烟测试需要越来越充分。最初的冒烟测试也许只需要几秒钟来执行，逐渐地，测试可能会花费30分钟，1小时，甚至更长。
BVT测试培训内容：
单元测试，使用白盒测试，设计用例是针对详细设计文档产生的。
集成测试，设计用例是针对概要设计说明书产生的。
系统测试，设计用例是针对软件需求规格说明书产生的。
验收测试，测试用例正常情况下应该由客户给出，由客户进行验证，以便下结论是否可交付。
BVT测试的特点：主要是针对主体功能及各入口点，时间短，测试用例也只有正面的，负责人一般式项目经理或者技术经理。
何时应该进行BVT测试：从上面的BVT测试介绍中可以看出来，bvt测试当然是测试的次数越多越好，但是针对现实情况，测试部要求在送测之前，程序在vss上打了基线，然后项目经理或者技术经理从vss上拿下最新的版本，然后做bvt测试，如果测试通过，则才可以填写送测单，并将bvt测试情况写在其中，如果vbt测试没通过，则需要修改bug，然后重新打基线，从新做BVT测试。BVT通过的要求并不是说所有的bug全部都改掉，而是没有重大的 bug，允许有小bug的存在。
BVT测试，以及测试用例的编写，都是需要时间成本的，故在最初制作项目计划时，就应该识别该任务，并充分考虑其工作量。
BVT测试用例，应该随着系统的不断扩展而不断扩展，它不应该是一成不变的。
BVT测试应该包含的内容：
1、业务流的测试，保证正常业务链路的通畅。
2、工作流的测试，主要是测试流程流转是否正常，至于流程步骤的表单内容是否正确则不关注。
3、关键功能的测试，至少要保证系统运转所需的启动数据，以及一些开关控制正常。
4、重要基本功能的测试，比如对核心业务有影响的一些增删改等。
BVT测试的过程：
1、各单元测试通过
2、打版本
3、拿最新版本
4、根据部署文档部署，尽量与用户环境一致
5、执行BVT测试用例
6、BVT测试结束后，如果成功，则填写送测单，并在送测单种写明bvt测试结果；如果不成功，则修改bug，重新进行BVT测试。 -
c/s和b/s的区别及实例说明
2009-07-14 15:37:10
B/S结构，即Browser/Server(浏览器/服务器) 结构，是随着Internet技术的兴起，对C/S结构的一种变化或者改进的结构。在这种结构下，用户界面完全通过WWW浏览器实现，一部分事务逻辑在前端实现，但是主要事务逻辑在服务器端实现，形成所谓3-tier结构。B/S结构，主要是利用了不断成熟的WWW浏览器技术，结合浏览器的多种 scrīpt语言(VBscrīpt、Javascrīpt…)和ActiveX技术，用通用浏览器就实现了原来需要复杂专用软件才能实现的强大功能，并节约了开发成本，是一种全新的软件系统构造技术。随着Windows 98/Windows 2000将浏览器技术植入操作系统内部，这种结构更成为当今应用软件的首选体系结构。显然B/S结构应用程序相对于传统的C/S结构应用程序将是巨大的进步。
C/S 与 B/S 区别：
Client/Server一般是建立在局域网的基础上的。Browser/Server是建立在广域网的基础上的。
１．硬件环境不同:
C/S 一般建立在专用的网络上，小范围里的网络环境，局域网之间再通过专门服务器提供连接和数据交换服务。
B/S 建立在广域网之上的，不必是专门的网络硬件环境,例与电话上网，租用设备。 信息自己管理。 有比C/S更强的适应范围，一般只要有操作系统和浏览器就行。
２．对安全要求不同
C/S 一般面向相对固定的用户群，对信息安全的控制能力很强。 一般高度机密的信息系统采用C/S 结构适宜。 可以通过B/S发布部分可公开信息。
B/S 建立在广域网之上，对安全的控制能力相对弱，面向是不可知的用户群。
３．对程序架构不同
C/S 程序可以更加注重流程，可以对权限多层次校验，对系统运行速度可以较少考虑。
B/S 对安全以及访问速度的多重的考虑，建立在需要更加优化的基础之上。 比C/S有更高的要求 B/S结构的程序架构是发展的趋势，从MS的。Net系列的BizTalk 2000 Exchange 2000等，全面支持网络的构件搭建的系统。
SUN 和IBM推的JavaBean 构件技术等,使 B/S更加成熟。
４．软件重用不同
C/S 程序可以不可避免的整体性考虑，构件的重用性不如在B/S要求下的构件的重用性好。
B/S 对的多重结构,要求构件相对独立的功能。 能够相对较好的重用。就入买来的餐桌可以再利用,而不是做在墙上的石头桌子。
５．系统维护不同
系统维护是软件生存周期中,开销大，-------重要。
C/S 程序由于整体性，必须整体考察，处理出现的问题以及系统升级。 升级难。 可能是再做一个全新的系统。
B/S 构件组成,方面构件个别的更换,实现系统的无缝升级。 系统维护开销减到最小。用户从网上自己下载安装就可以实现升级。
６．处理问题不同
C/S 程序可以处理用户面固定，并且在相同区域，安全要求高需求，与操作系统相关。 应该都是相同的系统。
B/S 建立在广域网上，面向不同的用户群，分散地域，这是C/S无法作到的。 与操作系统平台关系最小。
７．用户接口不同
C/S 多是建立的Window平台上,表现方法有限,对程序员普遍要求较高。
B/S 建立在浏览器上，有更加丰富和生动的表现方式与用户交流。 并且大部分难度减低,减低开发成本。
８．信息流不同
C/S 程序一般是典型的中央集权的机械式处理，交互性相对低。
B/S 信息流向可变化，B-B B-C B-G等信息、流向的变化，更象交易中心。
比如一些聊天软件，是c/s结构的因为满足这种软件的可维护和升级性，满足不同的人群的个性和喜好，自己制定自己的界面，安装自己喜欢的插件，但在b/s结构上实现这一点比较困难，并且可扩展性也不好。
比如说很多人每天上新浪网，只要安装了浏览器就可以了，并不需要了解新浪的服务器用的是什么操作系统，而事实上大部分网站确实没有使用windows操作系统，但用户的电脑本身安装的大部分是windows操作系统。
软件系统的改进和升级越来越频繁，B/S架构的产品明显体现的更方便的特性。无论用户的规模有多大，有多少分支机构都不会增加任何维护升级的工作量，所有的操作只需要针对服务器进行，如果是异地只需要把服务器连接上网即可立即进行维护和升级，这对人力、时间、费用的节省是相当惊人的。
一个稍微大一点单位来说，系统管理人员如果需要在几百甚至几千部电脑之间来回奔跑，效率和工作量是可想而知的，但B/S架构的软件只需要管理服务器就行了，所有的客户端只是浏览器，根本不需要做任何的维护。所以客户机越来越"瘦"而服务器越来越"胖"是将来软件的主流发展方向，这使得升级和维护越来越容易而使用越来越简单。 -
历史数据迁移的软件测试
2009-07-14 15:34:06
历史数据迁移，说白了就是数据库数据迁移，比如：把一个ACCESS数据迁移到ORACLE数据库，或者是其它数据库之间的数据迁移。
有的人可能会想，既然是数据库数据迁移，不需要做测试需求的确认了，检查一下数据就可以了；有的人由于没有做过这类测试、第一次碰到，傻眼了这可怎么测试啊，书籍上说的黑盒测试技巧里并没有历史数据迁移的测试方法，该怎么办。
我第一次接到这个测试任务时，感觉很特殊，因为实在少见，怎么做呢？
首先，在做历史数据迁移测试之前，也需要做测试需求的确认，主要是弄清楚用户为什么要做这个历史数据的迁移。
我记得，当时这个案例的用户是因为它的一个系统，之前的老系统是在ACCESS数据库中存储的，后来有了新系统、新系统的数据是在ORACLE里，为了把数据统一，就需要把老数据导入到新系统的数据库ORACLE里，便于新系统能查看到即可。
从这个需求，得出如下测试需求点：
1、 ACCESS数据库里有很多张表，要和用户确认要迁移的是那几张表？弄清楚老库中的老表对应要迁移到新库中的那几张新表？
2、 迁移的表中，那些数据字段需要迁移，那些数据字段不需要迁移？
3、 老表迁移到新表中，新表中有些必填字段在老表中没有的，用什么数据填写？
4、 老表迁移到新表中，老表数据在新表中没有对应字段存储，怎么处理？
5、 老库老表数据与新库新表重复，数据怎么处理？
6、 老表要迁移的数据记录条数是多少？
和用户弄清楚这些疑问点后，还需要和开发确认疑问点：
1、 老库中老表的表关系迁移到新系统新表中的表关系是怎样的？
2、 确认用开发编写的数据迁移程序迁移完后的数据检查方法？
确认上面的疑问点后就开始做工期时间计划安排、编写测试计划和测试用例。
其次，要注意数据迁移后，新系统对老数据功能的使用。
记得当时在确定了测试需求点后，在编写测试用例时，我重点使用了一下新系统、确认新系统会用到老表数据的业务都有哪些？把这部分业务也作为测试用例点进行测试。也许有的人会想，只要后台把数据库表正确迁移完毕，前台应用程序应该是没有问题的，不需要检查的。这是一种偷懒怀着侥幸心理的想法。回到之前的用户需求，用户为什么要数据迁移，目的就是为了能在新系统使用这些数据，因此在数据迁移完毕后，还要重点的检查老数据在新系统中的使用。
就在这个数据迁移测试的过程中，我跟我们的部门经理说，用户肯定会有其它的需求、迁移这些数据肯定要做一些业务处理、新系统程序可能会有改动。结果在迁移数据做完后，用户真的提出了新的需求，被我说中了。^_^。为了让这些老数据在新系统能很好的完成新业务处理，要对老数据进行特殊标识后才进入新系统、同时新系统针对这部分数据相应要增加功能。这就是用户需求没有摸透、没有看清楚需求背后的真正需求，导致迁移程序需要再次进行修改。
有些人，在测试数据库迁移时，一开始想到的理论知识就是：测试数据的完整性、可靠性、有效性；有的人就会问，数据的完整性、可靠性、有效性的测试用例怎么写啊？说实话，我也没有写过数据的完整性、可靠性、有效性的测试用例，我只会根据用户给的需求、整理并发掘测试需求，根据需求形成测试用例。也许数据的完整迁移测试点就属于数据完整性测试用例吧；数据迁移完后新系统对迁移数据可正常使用并处理业务，就属于数据的可靠性、有效性测试用例吧。
不管怎样，在测试的过程中，一定要弄明白用户的真正需求，才不会走弯路，虽然只是个数据迁移，但不只是简单的数据迁移，背后有着很多不为人知的故事！！！！！^_^ -
报表测试
2009-07-14 15:30:06
目的：
高效、高质量完成报表的测试工作
内容：
1、测试准备工作：
● 数据准备
● 保证足够多的有效数据
● 清楚报表中涉及到的算法、公式
● 清楚业务功能接口
2、报表测试点总结
● 基本测试点：界面、控件、格式、布局、明显的数据错误、js报错、报表标题，报表整体风格，翻页，友好性等
● 有效数据准确性验证：数据的来源、数据的对应关系、数据的格式、数据的排序、明细与合计的一致性
● 报表查询：覆盖所有的查询条件，输出结果准确
● 数据可控性测试验证
● 汇总，明细表数据间的关联以及多张报表之间的比较
● 性能测试：查询多少量的数据需要花费多少时间，需要明确定义，尽量达到最大的效率；生成报表时用类似进度条表现进度,避免用户盲目的等待；性能测试需要特定的测试环境来支持，包括软件、硬件、测试工具等。
● 日期字段：关系到结算，查询，统计等
● 权限控制和安全性测试：报表查看权限
● 报表的辅助功能：Excel导出、打印等
● 样式统一：控件的显示隐藏、查询条件的保存、单位的统一等
3、报表测试注意点
见《报表测试注意点》
4、测试步骤（流程）
● 测试前的评审工作：自己认为，测前组织测试评审或者测试交流，对测试的深入，覆盖面，效率都有很大的帮助，对接口，取值，数据的来龙去脉等重点或主要功能的讲解要详细，最好是开发人员有自测报告文档的输出（除简单测试点外，其他要尽可能详细）。在交流前自己要先大概了解报表的功能，这样效果会更好
● 代码走读或者查询日志：熟悉程序逻辑结构，熟悉报表结构的情况下可以发现业务功能的逻辑bug，或者设计不合理的地方
● 测试数据：自己首先添加简单的数据，验证报表统计数据的正确性。然后，再添加数据模拟业务的所有流程产生的数据，验证所有业务流程下数据的正确。这样一步步地深入，可以使得测试思路清晰，容易定位报表设计的业务。（正式数据最好）
● 测试中借助数据库做数据的验证测试
结论：上面只是自己的一些总结，请大家查漏补缺，完成一份较好的报表测试文档，对报表测试有所帮助。大家也可以说一下自己对报表测试的心得，也好彼此交流学习一下。 -
溢出测试
2009-07-14 15:27:14
一．定义
这里所说的“溢出”含义大于我们传统程序含义的溢出，是指允许输入字段长度要大于目标处理字段长度导致bug，经常看到指以下三种：程序处理长度溢出，数据库截断或异常问题，两个接口之间长度不一致导致问题；
测试方法：在允许输入接口输入最大数字或字符进行提交，看处理和数据库是否正常
二．实际使用例子与意义
1． 发现程序溢出的问题
主要用于发现程序可以处理的字节长度小于输入字节长度，导致程序在处理时候返回数据异常或程序出错的bug，比如：
我以前做一个项目中的一个通过id搜索字条功能，可输入12位，所以输入12个9后页面没有返回正常搜索而是出现异常返回信息；经确认发现是处理长度只有4个字节
2． 发现数据库截断或异常问题
主要用于发现程序输入超长字符串后提交，因数据库目标字段小于输入允许长度导致：输入字段在数据库被截断或数据提交异常的bug，比如：
在**项目的新增服务中服务说明这一输入栏，前台提示允许输入2000中文字，但输入2000个后页面提交，页面返回null，经确认原来数据库中字段允许长度只有500个字
3． 发现输入接口小于输出接口的问题
主要用于发现程序在接口相互传递数据时候，传出数据接口传出数据最大长度大于传入数据可处理最大长度导致处理异常的bug，比如：
在**项目的与**外部接口时候，我在前台的佣金项输入最大允许输入项n个9，提交服务后**接口处理这一环节出错预扣佣金失败；经确认发现原来**代扣接口最大处理金额是m(n个9远大于m)，远远小于我们允许输入金额，所以在处理时候出错拉。 -
搜索引擎测试方法
2009-07-13 11:05:59
搜索引擎的测试也分为功能与性能测试，我在下面依次来分享：
首先，我们把整个测试计划分为线下测试与线上测试。线下与线上测试都要分功能测试与性能测试，先说现线下的测试。
一、线下功能测试分为两个部分，一部分为搜索引擎本身的功能测试，一部分为嵌套在前台应用中的功能测试：
1、搜索引擎本身的功能测试，主要就是按照用例，通过不同的搜索关键字、属性的组合（按照搜索引擎的规则）来直接访问搜索引擎，查看返回的数据、参数是不是符合原先预计的结果。可以编写脚本来批量执行，判断每一个搜索的返回结果数与内容，相对应的参数是否一致。也可以手工执行，使用浏览器或者命令行（如 curl）来做，用肉眼来观察结果。
2、嵌套前台应用的功能测试，只要就是按照用例通过前台的操作，来测试搜索引擎的相关的功能，测试搜索引擎与前台的接口是否正确应用，至于如何测试，这个地球人都知道了，我就不在这里多说了。
二、线下性能测试也分为两个部分，一部分为直接对搜索引擎进行加压的性能测试，另一部分为通过前台应用进行加压的性能测试：
1、直接对搜索引擎进行加压，可以测试出搜索引擎本身最真实的性能状况。可以把搜索引擎的有效负荷，最大承受的压力测试出来。具体的方法是，使用工具如 loadrunner使用一个web_url直接加压，加压的内容其实就是你在功能测试中，直接测试搜索引擎时使用的那些搜索关键字、属性的组合（按照搜索引擎的规则），具体的规则可以通过log来查看，也可以询问开发人员。需要注意的是，数据准备一定要海量，至少10万条以上的搜索数据（注意，就是你访问搜索引擎的那些关键字组合，至于被搜索的数据，越大越好，最少多大，看你实际需要了）。当一切都准备完毕后，就可以启动工具来进行加压了。
2、通过前台应用进行加压，主要的压力都集中在前台应用上面，对于搜索引擎本身的压力并不会很大，但是这种测试也是必须的，因为你的搜索引擎是离不开前台应用的，这种测试可以模拟最真实的终端用户使用。所以不要怕麻烦，这个才是最后真正有意义的测试结果。
三、线上的功能测试，其实就是功能回归了，使用预发布环境（一套独立的缩小的线上的架构）来跑回归，手工或者自动化随便，这是不能缺少的。
四、线上的性能测试，这个也是使用预发布环境（记得一定要和线上一样哦，只不过是缩小的），分流线上的一部分压力到这里，观察线上与预发布环境中的各服务器的情况，如果是第一次发布，线上没有流量，那么就自己来模拟，或者靠运营来宣传了（有点想网络游戏的公测）。记录下服务器的各性能指标，如 load，cpu，队列，最大并发连接数，log等等。
特别需要注意的是，不同层次服务器之间的数据传输方式，正确率以及配置，多试试不同的配置，寻找性能最优点。 -
软件过程模型
2009-07-08 16:08:05
软件过程模型
所谓软件过程模型就是一种开发策略，这种策略针对软件工程的各个阶段提供了一套范形，使工程的进展达到预期的目的。对一个软件的开发无论其大小，我们都需要选择一个合适的软件过程模型，这种选择基于项目和应用的性质、采用的方法、需要的控制，以及要交付的产品的特点。一个错误模型的选择，将迷失我们的开发方向。对于下面的模型，希望能够给开发者们一个参考和一点启示。
一、 线性顺序过程模型：
它有时也称为传统生存周期模型或瀑布模型。它提出了软件开发的系统化的、顺序的方法。其流程从系统开始，随后是需求分析、设计、编码、测试、支持。这种模型是最早也是应用最广泛的软件过程模型(虽然这种模型会引起“堵赛状态”)。
缺点：
1、实际的项目大部分情况难以按照该模型给出的顺序进行，而且这种模型的迭代是间接的，这很容易由微小的变化而造成大的混乱。
2、 经常情况下客户难以表达真正的需求，而这种模型却要求如此，这种模型是不欢迎具有二义性问题存在的。
3、 客户要等到开发周期的晚期才能看到程序运行的测试版本，而在这时发现大的错误时，可能引起客户的惊慌，而后果也可能是灾难性的。
4、采用这种线性模型，会经常在过程的开始和结束时碰到等待其他成员完成其所依赖的任务才能进行下去，有可能花在等待的时间比开发的时间要长。我们称之为“堵赛状态”。
优点：
1、它提供了一个摸板，这个摸板使得分析、设计、编码、测试和支持的方法可以在该摸板下有一个共同的指导。
2、虽然有不少缺陷但比在软件开发中随意的状态要好得多。
二、 原型实现过程模型：
从需求收集开始，开发者和客户在一起定义软件的总体目标，标识已知的需求并且规划出需要进一步定义的区域。然后是“快速设计”，它集中于软件中那些对客户可见的部分的表示，这将导致原型的创建，并由客户评估并进一步精化待开发软件的需求。逐步调整原型使其满足客户的需求，这个过程是迭代的。其流程从听取客户意见开始、随后是建造/修改原型、客户测试运行原型、然后回头往复循环直到客户对原型满意为止。由于这种模型可以让客户快速的感受到实际的系统（虽然这个系统不带有任何质量的保证），所以客户和开发者都比较喜欢这种过程模型（对于那些仅仅用来演示软件功能的公司而言或从来不考虑软件质量和不害怕长期维护的公司而言）。
缺点：
1、没有考虑软件的整体质量和长期的可维护性。
2、大部分情况是不合适的操作算法被采用目的为了演示功能，不合适的开发工具被采用仅仅为了它的方便，还有不合适的操作系统被选择等等。
3、由于达不到质量要求产品可能被抛弃，而采用新的模型重新设计。
优点：
1、如果客户和开发者达成一致协议：原型被建造仅为了定义需求，之后就被抛弃或者部分抛弃， 那么这种模型很合适了。
2、迷惑客户抢占市场，这是一个首选的模型。
三、 快速应用(RAD) 过程模型：
这是一个增量型的软件开发过程模型，强调极短的开发周期，它是线性模型的一个“高速”变种，通过使用构件的建造方法赢得了快速开发。如果需求理解的好而且约束了项目的范围，利用这种模型可以很快的创建出功能完善的“信息系统”。其流程从业务建模开始，随后是数据建模、过程建模、应用生成、测试及反复。RAD过程强调的是复用，复用已有的或开发可复用的构件。实际上RAD采用第四代技术。
缺点：
1、只能用于信息系统。
2、对于较大的项目需要足够的人力资源去建造足够的RAD组。
3、开发者和客户必须在很短的时间完成一系列的需求分析， 任何一方配合不当都会导致RAD项目失败。
4、这种模型对模块化要求比较高，如果有哪一功能不能被模块化，那么建造RAD所需要的构件就会有问题。
5、技术风险很高的情况下不适合这种模型。
优点：
1、开发速度快，质量有保证。
2、对信息系统特别有效。
四、 增量过程模型：
这种模型融合了线性顺序模型的基本成份和原型实现模型的迭代特征。增量模型采用随着日程时间的进展而交错的线性序列。每一个线性序列产生软件的一个可发布的“增量”。当使用增量模型时，第一个增量往往是核心的产品，也就是说第一个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估，都做为下一个增量发布的新特征和功能。这个过程在每一个增量发布后不断从复，直到产生了最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。
缺点：
1、至始至终开发者和客户纠缠在一起，直到完全版本出来。
优点：
1、人员分配灵活，刚开始不用投入大量人力资源，当核心产品很受欢迎时，可增加人力实现下一个增量。
2、当配备的人员不能在设定的期限内完成产品时，它提供了一种先推出核心产品的途径，这样就可以先发布部分功能给客户，对客户起到镇静剂的作用。
3、具有一定的市场。
五、 螺旋过程模型：
这是一个演化软件过程模型，它将原型实现的迭代特征和线性顺序模型中控制的和系统化的方面结合起来。使得软件的增量版本的快速开发成为可能。在螺旋模型中，软件开发是一系列的增量发布。在每一个迭代中，被开发系统的更加完善的版本逐步产生。螺旋模型被划分为若干框架活动，也称为任务区域。典型地，有3到6个任务区域：
1、客户交流：建立开发者和客户之间有效通信所需要的任务。
2、计划：定义资源、进度、及其它相关项目信息所需要的任务。
3、风险分析：评估技术的及管理的风险所需要的任务。
4、工程：建立应用的一个或多个表示说需要的任务。
5、构造及发布：构造、测试、安装和提供用户支持所需要的任务。
6、客户评估：基于对在工程阶段产生的或在安装阶段实现的软件表示的评估，获得客户反馈所需要的任务。
这是一个相对较新的模型，它的功效还需要经历若干年的使用方能确定下来。
缺点：
1、需要相当的风险分析评估的专门技术，且成功依赖于这种技术。
2、很明显一个大的没有被发现的风险问题，将会导致问题的发生，可能导致演化的方法失去控制。
3、这种模型相对比较新，应用不广泛，其功效需要进一步的验证。
优点：
1、对于大型系统及软件的开发，这种模型是一个很好的方法。开发者和客户能够较好地对待和理解每一个演化级别上的风险。
六、 WINWIN螺旋过程模型：
螺旋模型提出了强调客户交流的一个框架活动。该活动的目标是从客户处诱导项目需求。在理想情况下，开发者简单地询问客户需要什么,而客户提供足够的细节进行下去。不幸的是这种情形很少发生。在现实中，客户和开发者进入一个谈判过程，客户被要求在成本和应市之间的约束下平衡功能、性能、和其它产品或系统特征。最好的谈判追求“双赢”结果，也就是说通过谈判客户获得大部份系统的功能，而开发者则获得现实的和可达到的预算和时限。对客户的交流定义了下面的活动：
1、系统或子系统的关键“风险承担者”的标识。
2、风险承担者的“赢条件”的确定。
3、风险承担者的赢条件谈判，以将它们协调为一组满足各方考虑的双赢条件。
缺点：
1、需要额外的谈判技巧。
优点：
1、客户和开发者达到一种平衡。
七、 并发任务过程模型：
这种模型关注于多个任务的并发执行，表示为一系列的主要技术活动、任务及它们的相关状态。并发过程模型是由客户要求、管理决策、评审结果驱动的。该模型不是将软件工程活动限定为一个顺序的事件序列，而是定义了一个活动网络。网络上的每一个活动均可于其它活动同时发生。这种模型可以提供一个项目的当前状态的准确视图。
缺点：暂时无
优点：
1、可用于所有类型的软件开发，而对于客户/服务器结构更加有效。
2、可以随时查阅到开发的状态。
八、 基于构件的开发过程模型：
面向对象的技术为软件工程的基于构件的过程模型提供了技术框架。面向对象模型强调了类的创建、类的封装了的数据、操纵该数据的算法。一般来讲经过合适的设计和实现，面向对象的类可以在不同的应用及基于计算机的系统的体系结构中复用。基于构件的开发模型融合了螺旋模型的许多特征，它本质上是演化形的，要求软件创建的迭代方法。然而基于构件的开发模型是利用预先包装好的软件构件（有时成为类）来构造应用。
开发活动从候选类的标识开始，这一步是通过检查将被应用系统操纵的数据及用于实现该操纵的算法来完成的。相关的数据和算法被封装成一个类。
缺点：
1、过分依赖于构件，构件库的质量影响着产品质量。
优点：
1、构件可复用。提高了开发效率。
2、采用了面向对象的技术。
九、 形式化方法模型：
形式化方法模型包含了一组活动，他们导致了计算机软件的数学规约。形式化方法使得软件工程师们能够通过应用一个严格的数学符号体系来规约、开发、和验证基于计算机的系统。 这种方法的一个变种，称为净室软件工程，已经被一些组织所采用。在开发中使用形式化方法时，它们提供了一种机制，能够消除使用其它软件过程模型难以克服的很多问题。二义性、不完整性、不一致性能被更容易地发现和纠正，而不是通过专门的评审，是通过对应用的数学分析。 形式化方法提供了可以产生无缺陷软件的承诺。
缺点：
1、开发费用昂贵（对开发人员需要多方面的培训），而且需要的时间较长。
2、不能将这种模型作为对客户通信的机制，因为客户对这些数学语言一无所知。
3、目前还不流行。
优点：
1、形式化规约可直接作为程序验证的基础，可以尽早的发现和纠正错误（包括那些其它情况下不能发现的错误）。
2、开发出来的软件具有很高的安全性和健壮性，特别适合安全部门或者软件错误会造成经济损失的开发者。
3、具有开发无缺陷软件的承诺。
十、 第四代技术(4GT)过程模型：
一系列的软件工具的使用，是第四代技术的特点。这些工具有一个共同的特点：能够使软件工程师们在较高级别上规约软件的某些特征，然后根据开发者的规约自动生成源代码。我们知道，软件在越高的级别上被规约，就越能被快速的建造出程序。软件工程的
4GT模型集中于规约软件的能力：使用特殊的语言形式或一种采用客户可以理解的术语描述待解决问题的图形符号体系。和其它模型一样，4GT也是从需求收集这一步开始的，要将一个4GT实现变成最终产品，开发者还必须进行彻底的测试、开发有意义的文档，并且同样要完成其它模型中同样要求的所有集成活动。总而言之，4GT已经成为软件工程的一个重要方法。特别是和基于构件的开发模型结合起来时，4GT模型可能成为当前软件开发的主流模型！
缺点：
1、用工具生成的源代码可能是“低效”的。
2、生成的大型软件的可维护性目前还令人怀疑。
3、在某些情况下可能需要更多的时间。
优点：
1、缩短了软件开发时间，提高了建造软件的效率。
2、对很多不同的应用领域提供了一种可行性途径和解决方案
总结：
过程模型总分为五大类：
1.惯例过程模型。
2.瀑布模型(又叫作生命周期模型)。
3.增量过程模型: 包括 增量模型、RAD模型。
4.演化过程模型: 包括 原型开发模型、螺旋模型、协同开发模型。
5.专用过程模型: 包括 基于构件的开发模型、形式化方法模型、面向方面的软件开发模型。
(参考文献:软件工程-实践者的研究方法 (美)Poger S.Pressman ) -
RAD开发
2009-07-08 16:01:34
RAD环境
计算机编程开发环境：
RAD=rapid application develop(快速应用开发)，
常用的RAD工具有：delphi等。
RAD不仅是一种需求抽取方法，它还是是软件开发为一体的方法。 RAD目的是快速发布系统方案，而技术上的优美相对发布的速度来说是次要的。
按照Wood and Silver (1995) 的观点， RAD组合了5个方面的技术：
1、进化原型
2、CASE工具（可进行正向工程和反向工程）
3、拥有能使用先进工具的专门人员（一个RAD开发小组）
4、交互式JAD
5、时间表
RAD存在的问题：
1、不一致的GUI设计
2、不是通用的解决方案
3、文档不足
4、难以维护和扩展软件快速应用(RAD) 过程模型：
这是一个增量型的软件开发过程模型，强调极短的开发周期，它是线性模型的一个“高速”变种，通过使用构件的建造方法赢得了快速开发。如果需求理解的好而且约束了项目的范围，利用这种模型可以很快的创建出功能完善的“信息系统”。其流程从业务建模开始，随后是数据建模、过程建模、应用生成、测试及反复。RAD过程强调的是复用，复用已有的或开发可复用的构件。实际上RAD采用第四代技术。
缺点：
1、只能用于信息系统。
2、对于较大的项目需要足够的人力资源去建造足够的RAD组。
3、开发者和客户必须在很短的时间完成一系列的需求分析， 任何一方配合不当都会导致RAD项目失败。
4、这种模型对模块化要求比较高，如果有哪一功能不能被模块化，那么建造RAD所需要的构件就会有问题。
5、技术风险很高的情况下不适合这种模型。
优点：
1、开发速度快，质量有保证。
2、对信息系统特别有效。 -
单元测试中常用的几种纠错技术
2009-07-06 17:25:08
纠错先要查错。查错的工作量通常占整个纠错的十分之九以上。所谓纠错的技术，主要是指查明程序错误时可能采用的工具和手段。这些手段如果运用得当，就能明显的提高查错的效率。
1、插入打印语句
在程序中插入暂时性的打印语句，是一种十分常见的查错技术。这类打印语句的作用主要是显示程序的中间结果或有关变量的内容。插入打印适用于任何高级语言书写的程序。但其输出与程序的原输出夹杂在一起，需要注意分辩。此外，纠错结束后必须记住将它们删除。
2、设置断点
查错的基本技术之一，就是在程序的可疑区设置断点。每当程序执行到设置的断点时，就会暂停执行，以便纠错者观察变量内容和分析程序的运行状况。
3、掩蔽部分程序
对可疑程序进行检查时，常常要让程序反复执行。如果整个程序较长，可疑区仅占其中的一小部分，则每次运行整个程序，必将浪费许多时间和精力。在这种情况下，明智的作法是把不需要检查的程序掩蔽起来，只让可疑的部分程序反复运行。
掩蔽无关程序可使用下述方法：
（1）在要掩蔽的语句行加上注释符，使解释或编译程序把它们当作注释行，不予处理。
（2）把要掩蔽的程序段置入一个“常假”的选择结构中，使它总没有机会执行。
（3）用GOTO语句跳越要掩蔽的程序段
无论使用哪一种掩蔽方法，纠错结束后都应撤销掩蔽，使程序复原。
4、蛮力纠错技术（Dubugging by Brute Force）
某些系统或调试程序能提供一种“转储”命令（DUMP），用来打印出内存可疑区或输出文件的全部内容，供纠错者分析使用。这种作法的优点是信息齐全，只要有耐心，总可以找出问题。但输出的数据量大，从中寻找错误的迹象好比大海捞针，效率很低。如果说前3种技术都重视分析与错误有关的信息，DUMP命令却不论数据与错误有无关联，一律拿出来“曝光”。所以有些文献称之为蛮力纠错，仅在程序很小或其他纠错手段未能奏效时才使用这种方法。 -
文档测试
2009-07-06 17:14:25
产品说明书属性检查清单
1.完整：是否有遗漏和丢失？完全吗？单独使用是否包含全部内容？
2. 准确：既定解决方案正确吗？目标明确吗？有没有错误？
3. 精确：不含糊，清晰。描述是否一清二楚？还是自说自话？容易看懂和理解吗？
4. 一致：产品功能描述是否自相矛盾？与其他功能有没有冲突 ?
5. 贴切：描述功能的陈述是否必要 ? 有没有多余信息 ? 功能是否满足的客户要求 ?
6. 合理：在特定的预算和进度下，以现有人力，物力和资源能否实现 ?
7. 代码无关：是否坚持定义产品，而不是定义其所信赖的软件设计，架构和代码 ?
8. 可测试性：特性能否测试 ? 测试员建立验证操作的测试程序是否提供足够的信息 ?
产品说明书用语检查清单
说明：对问题的描述通常表现为粉饰没有仔细考虑的功能 ---- 可归结于前文所述的属性。从产品说明书上找出这样的用语，仔细审视它们在文中是怎样使用的。产品说明书可能会为其掩饰和开脱 , 也可能含糊其词 ---- 无论是哪一种情况都可视为软件缺陷
9. 总是，每一种，所有，没有，从不。如果看到此类绝对或肯定的，切实认定的叙述，软件测试员就可以着手设计针锋相对的案例
10. 当然，因此，明显，显然，必然。这些话意图诱使接受假定情况，不要中了圈套。
11. 某些，有时，常常，通常，惯常，经常，大多，几乎。这些话太过模糊， " 有时 " 发生作用的功能无法测试。
12. 等等，诸如此类，依此类推。以这样的词结束的功能清单无法测试，功能清单要绝对或者解释明确，以免让人迷惑，不知如何推论。
13. 良好，迅速，廉价，高效，小，稳定。这些是不确定的说法，不可测试。如果在产品说明书中出现，就必须进一步指明含义。
14. 已处理，已拒绝，已忽略，已消除。这些廉洁可能会隐藏大量需要说明的功能。
15. 如果 ... 那么 ...( 没有否则 ) 。找出有 " 如果 ... 那么 ..." 而缺少配套的 " 否则 " 结构的陈述，想一想 " 如果 " 没有发生会怎样。
简明性、明确性：在软件开发各个阶段所编写的各种文档的语言表达清晰、准确、简练，适合各种文档的特定读者即提供的用户手册要对系统中每部分的在各个阶段的功能有明确。
描述，对于工作流程也有明确叙述，让用户很清楚的知道自己处于流程中的什么位置，在做什么，接下来该做什么或者应该怎么做。
内容完整性：按照软件开发流程编制相应的文档，提供用户操作手册及在线帮助。
用户操作手册要全面、细致的每个模块操作步骤以及每步所要达到的目标。
在线帮助要详细列出用户在工作中可能遇到的问题，并针对每个问题提出详细的解决方案，要充分起到“实时”给予帮助的目的。
准确规范性、可读性：用户手册、用户操作手册以及在线帮助要做到用语规范，准确，可读性，符合客户要求的编写规范标准，使用户操作起来简单明了，例如在某环节出现了问题，用户能够利用在线帮助很快且顺利的找到相应的帮助文档，最终达到解决的目的 。
可追踪性：指在不同文档的相关内容之间或则同一文档某一内容在本文档中的涉及范围可追踪性。
自说明性：各个阶段中的文档能独立、清楚的表达出对应于该文档所处的阶段而开发出的软件产品所具有的功能。 -
安装测试
2009-07-06 16:47:41
软件测试之可安装性和可恢复性测试
软件产品的日益丰富，可获得软件的途径也多种多样，软件的安装方式也发生了很大
的变化。有系统软件的安装、应用软件的安装、服务器的安装、客户端的安装、还有产品
的升级安装等。
安装测试时要注意以下几点：
· 是否需要专业人员安装。需要专业人员安装的软件通常只有Readme文档，或者
安装说明书相对简单，依赖安装人员的专业水平。测试的工作最相对较小。而
需普通用户自行安装的软件则必须提供安装说明书，并必须以其为基础展开安
装测试。
软件的安装说明书有无对安装环境做限制和要求。至少在标准配置和最低配置两
种环境下安装。曾经有过这样的例子，某客户端产品进行安装测试时十分顺利，
在准备发布之前的一次演示中，按安装说明书进行安装时意外发现无法通过，提
示没有安装J“a程序。让主管经理们对测试结果产生了很大的疑问。真正的原因
就是测试人员的测试用机都按习惯在装操作系统时默认安装了Java程序，造成了
测试上的疏漏。
· 安装过程是否简单，容易掌握。软件的安装说明书与实际安装步骤是否一致。对
一般用户而言，长长的安装文档，复杂的操作步骤往往造成畏惧心理。如果实际
步骤与安装说明荐有出入，就容易让用户缺乏信心．增加技术支持的成本。
· 安装过程是否有明显的、合理的提示信息。相应的信息是否合理、合法；插入碟
片，选择、更改目录，安装的进程和步骤等均应有明显的、台理的指示。用户许
可协议的条款要保证其合理、合法。
· 安装过程中是否会出现不可预见的或不可修复的错误。安装过程中(特别足系统
软件)对硬件的识别能力；检查系统安装是否会破坏其他文件或配置：检查系统
安装是否可以中止并恢复原状。
· 安装程序是否占用系统资源与原系统冲突，是否会影响原系统的安全性。检查系
统是否能够安装所有需要的文件／数据并进行必要的系统设置。
· 软件安装的完整性和灵活性。大型的应用程序会提供多种安装模式(最大、晟小、
自定义等)，每种模式是否能够正确的执行，安装完毕后是否可以进行合理的调整。
· 软件使用的许可号码或注册号码的验证。
· 升级安装后原有应用程序是否可正常运行。
· 卸载测试也是安装测试的一部分。卸载后，文件、目录、快捷方式等是否清除；
卸载后，占用的系统资源是否全部释放；卸载后，是否影响其他软件的使用。
标题搜索
我的存档
数据统计
- 访问量: 16234
- 日志数: 66
- 建立时间: 2008-04-17
- 更新时间: 2013-02-20
