Life is short, you need Python

08 2011 档案

摘要:1.ISO9000和CMMI的区别宏观上来说,就是文化的差异。美国搞TQM,并由戴明老人家在日本弘扬光大,日本产品推向全球的同时也把TQM推向了全世界,英国坐不住了,作为工业革命的领头人怎么能在新世纪用别人的标准来指导自己呢?于是给IEEE提议,说得建一个标准,于是ISO就诞生了,这是一套标准。美国的大型项目主要都是来自于军方,军方在外包过程中发现承包方往往水平和能力参差不齐,所以决心建立一套评估体系来界定承包方的差别,委托某某大学的某某学院纠集一帮人把CMM搞出来了,虽然CMM是用于评估但里面的内容完全可以视为最佳实践的集合,比如某项活动它会指出要达到什么目标、推荐什么方式。后来大家觉得CM 阅读全文
posted @ 2011-08-26 15:40 runfox545 阅读(355) 评论(0) 推荐(0) 编辑
摘要:扁鹊云游各国,为君侯看病,也为百姓除疾,名扬天下。他的技术十分全面,无所不通。在邯郸听说当地尊重妇女,便做了带下医(妇科医生)。在洛阳,因为那里很尊重老人,他就做了专治老年病的医生。秦国人最爱儿童,他又在那里做了儿科大夫,不论在哪里,都是声名大振。! R) s) n+ c; ~4 S: Y6 z, S 根据典记,魏文王曾求教于名医扁鹊[1]:“你们家兄弟三人,都精于医术,谁是医术最好的呢?”扁鹊:“大哥最好,二哥差些,我是三人中最差的一个。”3 j4 M3 K% B4 f+ U( L# N& s7 z( k 魏王不解地说:“请你介绍的详细些。”# gL8 ?9 t$ {/ B( j* 阅读全文
posted @ 2011-08-26 15:26 runfox545 阅读(302) 评论(0) 推荐(0) 编辑
摘要:【login.bat】mysql -h localhost -u root -p123456 < mysql.sql >mysql.out【mysql.sql】#select "display all databases";#select "============================";show databases;select " ";#select "select database";#select "============================";us 阅读全文
posted @ 2011-08-22 16:52 runfox545 阅读(3755) 评论(0) 推荐(0) 编辑
摘要:1元=100分=10分*10分=0.1元*0.1元=0.01元=1分 阅读全文
posted @ 2011-08-22 10:41 runfox545 阅读(968) 评论(0) 推荐(0) 编辑
摘要:什么时候需要回归测试?当发现并修改缺陷后,或者在软件中添加新功能后,重新测试,用来检查被发现的缺陷是否被改正,并且所作的修改没有引发新的问题当一个新的模块被当作集成测试的一部分加进来的时候,软件就发生了改变,这些改变可能使原本工作正常的功能产生错误回归测试可以通过人工重新执行测试用例,也可以使用自动化的捕获回放工具来进行回归测试方式再测试全部用例:选择基线测试用例库中的全部测试用例组成回归测试包,测试成本最高基于风险选择测试:可以基于一定的风险标准来从基线测试用例库中选择回归测试包首先运行最重要的、关键的和可疑的测试,测试从主要特征到次要特征。回归测试方式基于操作剖面选择测试重新测试修改的部分 阅读全文
posted @ 2011-08-16 13:59 runfox545 阅读(378) 评论(0) 推荐(0) 编辑
摘要:系统测试根据软件需求规范的要求进行系统测试,确认系统满足需求的要求系统测试人员相当于用户代言人在需求分析阶段要确定软件的可测性,保证有效完成系统测试工作 在需求分析阶段要确定软件的可测性,保证有效完成系统测试工作。要对软件需求规范中的要求形成确认标准,并且在其形成之初进行评审,保证可测试性。对于一些不能由测试确认的需求,要在需求规范中说明,如果可能尽量明确其他的确认方式。系统测试主要内容所有功能需求得到满足所有性能需求得到满足其他需求(例如安全性、容错性、兼容性等)得到满足 阅读全文
posted @ 2011-08-16 13:47 runfox545 阅读(242) 评论(0) 推荐(0) 编辑
摘要:集成测试通过测试发现与模块接口有关的问题目标是把通过了单元测试的模块拿来,构造一个在设计中所描述的程序结构应当避免一次性的集成(除非软件规模很小),而采用增量集成 自顶向下集成:模块集成的顺序是首先集成主模块,然后按照控制层次结构向下进行集成,隶属于主模块的模块按照深度优先或广度优先的方式集成到整个结构中去。自底向上集成:从原子模块开始来进行构造和测试,因为模块是自底向上集成的,进行时要求所有隶属于某个给定层次的模块总是存在的,也不再有使用稳定桩的必要。集成测试的过程明确测试目标和完成准则,并确定关键部分。确定阶段和进度安排。测试和修正协调的策划。清理系统结构。确定集成测试方法的组合策略。描述 阅读全文
posted @ 2011-08-16 11:18 runfox545 阅读(361) 评论(0) 推荐(0) 编辑
摘要:单元测试完成对最小的软件设计单元—模块的验证工作目标是确保模块被正确地编码使用过程设计描述作为指南,对重要的控制路径进行测试以发现模块内的错误通常情况下是面向白盒的对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试,及早地发现和解决不易显现的错误 因为一个软件模块本身不一定是一个单独的程序,所以必须为每个单元测试开发驱动器或/和稳定的桩(stub)。在大多数应用中,一个驱动只是一个接收测试数据,并把数据传送给要测试的模块,然后打印相关结果的“主程序”。子程序桩的功能是替代那些被本模块调用的模块。根据模块间关系的不同需要有不同的桩和驱动器,可以根据桩的类型开发一些通用结构的桩和驱动器,以减 阅读全文
posted @ 2011-08-15 14:53 runfox545 阅读(273) 评论(0) 推荐(0) 编辑
摘要:测试覆盖率 有多少需求、代码已经被测试了缺陷发现率 缺陷是何时被发现,并且有多少缺陷已经被发现。缺陷可以根据严重性来分类。需记录以下值: 缺陷数目 缺陷的严重性测试成功率 有多少测试已经通过了,并且有多少是运行正常的?需记录以下值: 已通过的测试用例的数目 可利用的测试用例的数目 阅读全文
posted @ 2011-08-15 10:44 runfox545 阅读(281) 评论(0) 推荐(0) 编辑
摘要:Bug的80-20原则在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的Bug而系统测试又能找出其余Bug中的80%最后的5%的Bug可能只 有在用户的大范围、长时间使用后才会曝露出来因为测试只能够保证尽可能多地发现错误,无法保证能够发现所有的错误。80/20原则1.80%的工程量用在20%的需求上2.80%的开发成本花费在20%的部件上3.80%的错误是由20%的部件引起的4.80%的延期或返工是由20%的变更造成的5.80%的系统资源是由20%的部件消耗的6.80%的进度是由20%的人完成的 阅读全文
posted @ 2011-08-15 10:37 runfox545 阅读(1258) 评论(0) 推荐(0) 编辑
摘要:木桶原理:软件质量的关键因素是分析、设计和实现,测试应该是融于其中的补充检查手段,其他管理、支持、甚至 文化因素也会影响最终软件的质量测试是提高软件质量的必要条件,最直接、最快捷的手段,但决不是一种根本手段如果将提高软件质量的砝码全部押在测试上,那将是一个恐怖而漫长的灾难。 阅读全文
posted @ 2011-08-15 10:35 runfox545 阅读(1041) 评论(0) 推荐(0) 编辑
摘要:等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图(逻辑模型). 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况. 利用因果图生成测试用例的基本步骤: (1) 分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件. 阅读全文
posted @ 2011-08-04 15:34 runfox545 阅读(1728) 评论(0) 推荐(0) 编辑
摘要:错误推测法: 基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法. 错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例. 阅读全文
posted @ 2011-08-04 15:32 runfox545 阅读(720) 评论(0) 推荐(0) 编辑
摘要:边界值分析方法是对等价类划分方法的补充. (1)边界值分析方法的考虑: 长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误. 使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据 (2)基于边界值分析方法选择测试用例的原则: 1)如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据. 阅读全文
posted @ 2011-08-04 15:31 runfox545 阅读(4014) 评论(0) 推荐(0) 编辑
摘要:等价类划分: 是把所有可能的输入数据,即程序的输入域划分成若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计方法. 1) 划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类. 有效等价类:是指对于程序的规格说明来说是合理的,有 阅读全文
posted @ 2011-08-04 15:20 runfox545 阅读(3965) 评论(0) 推荐(0) 编辑
摘要:测试用例设计方法等价类划分方法边界值分析方法错误推测方法因果图方法测试用例的几条基本准则测试用例的代表性测试结果的可判定性测试结果的可再现性测试用例的代表性,能够代表各种合理和不合理的、合法的和非法的、边界和越界的。以及极限的输人数据、操作和环境设置等。测试结果的可判定性,即测试执行结果的正确性是可判定的或可评估的。测试结果的可再现性,即对同样的测试用例,系统的执行结果应当是相同的。测试人员拿到用例,可独自执行该用例,而不需要编写者的帮助。不会因为执行该测试用例而影响其它测试用例的执行,比如执行某些用例后,会对应用系统产生影响,用例中应说明如何将应用系统恢复到最初状态,而不影响后续测试的进行什 阅读全文
posted @ 2011-08-04 15:13 runfox545 阅读(375) 评论(0) 推荐(0) 编辑
摘要:功能性测试 性能性测试 压力测试 容量测试 异常测试 备份测试 安装测试 配置测试 GUI(界面)测试 文档测试 健壮性测试 稳定性测试 可用性测试 在线帮助测试 网络测试 安全性测试 阅读全文
posted @ 2011-08-04 14:56 runfox545 阅读(223) 评论(0) 推荐(0) 编辑
摘要:静态测试方法:对被测程序进行特性分析的一些方法的总称动态测试方法:真正运行被测试的程序,通过输入测试用例,对其运行情况(输入/输出的对应关系)进行分析黑盒测试:功能测试、数据驱动测试或基于规格说明的测试,是一种从用户观点出发的测试白盒测试:又称结构测试、逻辑驱动测试或基于程序的测试回归测试:主要应用于增量开发中模拟用户操作测试方法:是基于对用户如何使用被测试软件的了解来开发测试的方法黑盒测试黑盒测试又称功能测试或数据驱动测试,是针对软件的功能需求/实现进行测试。在已知软件应具有的功能的条件下,通过测试来检测每个功能是否符合需求,不考虑程序内部的逻辑结构。“黑盒”法是穷举输入测试,只有把所有可能 阅读全文
posted @ 2011-08-04 14:19 runfox545 阅读(516) 评论(1) 推荐(0) 编辑
摘要:分析测试用例覆盖分析代码覆盖分析缺陷分析是否达到测试停止、成功标准写测试分析报告 阅读全文
posted @ 2011-08-04 14:17 runfox545 阅读(241) 评论(0) 推荐(0) 编辑
摘要:测试计划Testing plan,描述了要进行的测试活动的范围、方法、资源和进度的文档。它确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。测试计划可以有效预防计划的风险,保障计划的顺利实施。应包括以下几个方面测试目标测试的范围测试的项目采用的测试手段需要的工具、资源交付物 — Artifacts也可概况为:时间进度和人员安排、风险管理测试范围的确定、测试数据的生成测试工具、方法的选择和工具开发测试完成标准影响资源分配的特殊考虑等测试计划编写6要素?(5W1H)why——为什么要进行这些测试;what—测试哪些方面,不同阶段的工作内容;when—测试不同阶段的起止时间;where—. 阅读全文
posted @ 2011-08-04 14:12 runfox545 阅读(273) 评论(0) 推荐(0) 编辑
摘要:制定测试计划 ->测试方案设计 ->测试开发(用例设计) ->测试执行 ->测试评估测试评估在实际工作中很容易忽略 阅读全文
posted @ 2011-08-04 13:59 runfox545 阅读(267) 评论(0) 推荐(0) 编辑
摘要:目前的软件测试仍然是发现一个缺陷,解决一个缺陷随着测试工作的进展,隐藏的缺陷将逐渐减少采用任何测试方法都只能发现某些缺陷不存在一个理想的测试方法能够发现所有的缺陷不存在没有缺陷的软件,即使经过了周密的测试、运行的考验和维护的修补。 阅读全文
posted @ 2011-08-04 11:17 runfox545 阅读(1232) 评论(0) 推荐(0) 编辑
摘要:1. 程序测试:发现程序中的缺陷由指定输入 ->程序 ->输出 ->比较期望输入 ->判定结果2. 软件测试:发现程序及前期设计开发的缺陷根据需求规格说明+设计规格说明+程序实现->判定结果 阅读全文
posted @ 2011-08-03 17:30 runfox545 阅读(234) 评论(0) 推荐(0) 编辑
摘要:软件测试项目评审:需求分析 ->需求评审 ->概要设计 ->设计评审 ->详细设计 ->设计抽查 ->编码 ->代码评审 ->单元测试 ->集成测试 ->确认测试 ->测试评审 阅读全文
posted @ 2011-08-03 17:09 runfox545 阅读(222) 评论(0) 推荐(0) 编辑
摘要:提高产品的质量。提高产品的商誉,获得更多的销售机会和市场份额。降低客户的售后支持成本以及产品维护成本。 阅读全文
posted @ 2011-08-03 17:05 runfox545 阅读(164) 评论(0) 推荐(0) 编辑
摘要:在测试工作开始前,不应设想程序中没有缺陷或找不出缺陷(软件心理学)测试以前应预知测试的结果数据尽可能避免测试自己写的程序,坚持独立测试原则,必要的情况下建立独立测试机构测试用例应兼顾有效输入和无效输入不仅要检验程序是否做了应该做的事,还应检验是否做了不应该做的事测试的充分性测试的有效性保留一切测试用例任何已测程序的变更都应重新测试(回归测试)################################################################Good-enough: 一种权衡投入/产出比的原则保证测试的覆盖程度,但穷举测试是不可能的所有的测试都应追溯到用户需求越早测试 阅读全文
posted @ 2011-08-03 17:03 runfox545 阅读(313) 评论(0) 推荐(0) 编辑
摘要:SVN中冲突的解决本人使用SVN的时间不是很长,在使用之前也仅仅是粗浅的了解过这个软件。从今年的8月份开始,由于一个项目使用Eclipse 3.1,跨地域的开发,为了适应不同的开发人员处于不同的地理位置,因此我们使用SVN作为团队开发的管理工具。开始使用时,仅仅是边学边用,遇到不懂的地方再去查找资料。今天由于有点时间,先把合并过程遇到的冲突问题详细了解一下。 可以使用svnstatus -u命令来查看一下某个问题是否会有冲突发生。在使用svn update 的时候,会出现如下一些信息:$ svn updateU INSTALLG READMEC bar.cUpdated to revision 阅读全文
posted @ 2011-08-01 11:17 runfox545 阅读(367) 评论(0) 推荐(0) 编辑

白月黑羽 Python教程 白月黑羽Python
点击右上角即可分享
微信分享提示