用户47134860
常用的软件测试方法和工具
开源测试管理工具：Bugfree、Bugzilla、TestLink、mantis 开源功能自动化测试工具：Watir、Selenium、MaxQ、WebInject 开源性能自动化测试工具：Jmeter、OpenSTA、DBMonster、TPTEST、Web Application Load Simulator [TestDirector]：企业级测试管理工具，也是业界第一个基于Web的测试管理系统。
[Quality Center]：基于Web的测试管理工具，可以组织和管理应用程序测试流程的所有阶段，包括指定测试需求、计划测试、执行测试和跟踪缺陷。
[QuickTest Professional]：用于创建功能和回归测试。
[LoadRunner]：预测系统行为和性能的负载测试工具。
[其他工具与自动化测试框架]：Rational Functional Tester、Borland Silk系列工具、WinRunner、Robot等。
国内免费软件测试工具有：AutoRunner和TestCenter。
为什么敏捷方法能在软件开发中行之有效
以下是为什么敏捷方法行之有效的原因：1. 敏捷方法和传统的计划驱动方法的两个主要区别(1)预测性计划（Predictive Planning）和自适应计划（Adaptive Planning）计划驱动方法首先计划要做的工作（plan your work），然后着手工作以完成计划（work your plan）。
这是一种带有预测性质的方法，其衡量项目成功的标准则是我们是否按计划、按时、按预算完成了工作。
这种方法在很多领域里是适用的。
但是对于软件开发而言，如果我们的需求没有办法做到不变更的话，我们就无法保证我们的计划以及其后的工作是不会变更的。
软件开发项目的需求很少是一成不变的。
因此，敏捷方法引入了自适应计划的概念，既然我们无法保证需求不变更，那么就让我们随时准备接受变更，接受挑战吧。
自适应计划将计划驱动的流程缩短为以数周为单位的循环周期，在每一个周期中，我们根据当前的情况不断地调整计划以及计划的执行过程，同时不断地产生能够工作的代码，并且不断地将代码部署到应用环境中去。
当然要实现这个目标我们需要一些具体方法的支持，如：自测试代码（Self-Testing Code），持续集成（Continuous Integration），重构（Refactoring），和简洁设计（Simple Design）等等这些技术层面上的方法。
Martin Fowler 指出，一些公司和项目之所以受困于敏捷方法，原因之一是他们忽略了这些技术层面的方法，而仅仅实施了项目管理层面的方法。
(2)以流程为本（Process First）和以人为本（People First）在传统的方法论中，我们总是需要事先定义好工作的方法和流程，然后“工人们”被要求遵照这些方法和流程来工作。
在软件开发领域，很多人把软件开发过程等同于软件本身，也就是说，软件开发的过程也如同软件程序般象机器一样运行，组件之间环环相扣，严密地协同工作。
问题是软件开发的核心是人，人相对于机器零件和流水线而言，是相对不可预测的和不那么精密的。
所以敏捷方法反其道而行之，提倡将“首先定义流程，然后要求软件开发人员遵照流程工作”变为“让参与软件开发的人员自己来定义和选择适合他们的流程”。
简单来说就是以人为本，不把人当螺丝钉，发挥人的主观能动性，当然前提是需要团队成员有较高的平均素质。
在软件测试技术中,最基本的四种方法是什么
捷开发是一种以人为核心、迭代、循序渐进的开发方法。
在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。
换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
软件测试中如何保证软件质量
由此看来每一个阶段的质量都起着决定性的作用。
以上提及的四个阶段的质量将引出以下几个软件质量保证的关键要素。
完备的需求分析 需求分析的目的是让项目组明白要做什么，是决定所开发出来的软件应当是“长什么样的”，显然完备的需求分析是高质量软件的前提。
如果所开发出来的软件与用户所希望的并不一致，那不可能让用户说“这个软件的质量很好” 。
如果方向不对，软件开发得再“好”也没有意义。
需求分析失误所带来的开发成本是高昂的，这一点在《软件工程》这类书籍中都会提及，因此，整个行业对于需求分析的重要性都具有足够的认识。
当然，知道其重要性与如何获得完备的需求分析又是两回事，至于如何做好需求分析请读者参考相关书籍。
需求分析如果出现失误的话有一个特点—— 它一定会暴露！只不过存在是暴露在软件开发过程中还是在用户手中之别。
因此，需求分析所造成的问题尽管严重，但它能被发现进而能得到项目组的重视，从而也一定能被修复，只是不同阶段发现这类问题所花费的成本将有所不同。
设计 设计阶段是通过设计方法找出软件实现更好的方法，注意这里是“更好”两个字，而不是强调最好。
不良设计并不会象需求分析失误那样很容易暴露出其本质，相反，它所暴露出的更多是表象，比如逻辑复杂、维护时举步为艰等等。
如果参与者不具备一定的洞察力以发现隐藏在现象背后的不良设计本质，则很有可能身受其害却不能自拔，还以为“本来就有那么复杂”。
项目的开发是一个逐步演进的过程，项目组成员对于需求的理解也是逐步加深的，一开始合适的设计到后面看来很有可能就不够全面或显得力不从心，如果仍沿用以前的设计则自然将暴露出它的不足，进而会出现需要更高的维护成本。
重构思想的提出，就是用于帮助项目演进设计的，当然，在运用重构方法时，应尽可能保证项目有足够的单元测试用例，以预防重构时又引入新的缺陷。
重构不只是一个词，其核心应当是一个方法论，一个用于优化设计的方法论。
编程好习惯 设计阶段输出的结果就是蓝图，但好的蓝图并不能保证最后的质量一定就好。
拿造房子打个比方，图纸设计得再好，如果建造时用的材料不过关，那最终的房子一定好不了。
那软件开发中的“建筑材料”又是什么呢？就是程序员所编写的代码。
如何保证其质量呢？这需要通过良好的编程习惯去保证。
在现实的项目中，设计有可能与编码会有一定的揉合，即通过进行一定的编码来辅助设计。
这种实践方式并不影响这里将设计与编码分为两个质量保证关键要素。
验证 验证很容易让人想到质量保证的常用方法之一，即测试。
但验证应当包含更多的内涵，比如求证软件需求是用户所希望的就是其中的一种。
对于验证的理解仍需要拿房屋的建造作为一个比方，以便加深理解。
在房屋的建造过程中，当建筑材料到了工地以后，需要对其进行检验，以保证它的质量是合格的，否则不能用于建造。
对应于软件开发，这个阶段就是单元测试。
当软件工程师编写了代码以后如何保证代码的行为是其所希望的呢？那只能通过单元测试去验证。
房子建造好了以后，还得对房子进行整体的验收以确保其最终是合格的。
比如抽查墙壁所使用的水泥与沙的配比是合适的。
虽然水泥和沙在进入工地时都经过了质检且是合格的，但在建造的过程中需要按一定的比例混合它们以作建筑粘合剂，而混合比例将确定粘合强度。
在软件开发过程中，软件集成测试就如同房子在建造好了以后的验收。
从上面的比方能得出几个结论。
第一，在软件开发过程中单元测试是必不可少的。
它的缺少如同将没有检验过的建筑材料用于建造一样。
第二，单元测试应当在集成测试之前完成。
有的项目在一开始时并没有单元测试流程，但后来发现需要增加这个环节，于是出现了集成测试完成了以后，再进行单元测试这种情形。
这种情形还是有点怪怪的，这如同房子已造好了，再将墙打掉去检查里面的砖是否是好的一样。
“将墙打掉检查砖”这种行为的勇气虽然可佳，但是如果尽早地在项目中部署单元测试就能避免这种怪现象的发生。
集成（包括开发集成和系统集成）测试在软件行业被广泛采用以保证软件质量，但单元测试对于软件质量保证的重要性在整个行业还缺乏广泛的、深刻的认识，其更多地被当作是负担而不是一种有效的质量保证手段。
如何用软件测试显示器的显示性能
无论是台式机还是笔记本，显示器或笔记本屏幕的显示效果对用户的体验有直接的影响，也备受消费者的关注。
要了解显示器的参数并不困难，但要全面知道显示器的显示性能则需要借助售价数万或数十万的专业设备来完成。
但是这对于普通用户来说并不现实。
其实除了专业仪器，借助一些相对专业的屏幕显示效果测试软件，也可以比较清晰的了解显示性能。
那么用软件如何测试显示器的显示性能呢，接下来就教给大家一些方法。
坏点、漏光测试 在购买显示器时，最怕就是屏幕上出现坏点。
在液晶面板中，一个像素点对应一个发光点。
每个发光点都有独立的晶体管控制其电流的强弱，如果控制该点的晶体管损坏了，我们就会在屏幕上看到某个像素点显示不正常。
坏点（包括亮点和暗点）的出现是无法避免的，但是会影响用户体验。
对坏点进行测试，只需让显示器显示各种纯色的图片，就能看出屏幕上是否有像素点显示不正常。
除了坏点之外，漏光也是比较常见的，表现为四周或某个角落有光晕，在显示比较暗的画面时，表现得非常明显。
一般来说漏光显现比较常见，但严重的漏光会影响使用体验，令人无法忍受。
漏光检测更为简单，只需要显示全黑图片，然后上下左右45度角看显示器四周显示区是否明显的发白、偏色、缝隙处是否有光线透出就可以了。
测试软件介绍： Display-Test：这是一款小巧的免费测试软件，体积虽小但功能却不简单，不仅有坏点测试，还有各种颜色填充、渐变测试，可以检测出显示设备的色彩还原能力。
比较有意思的是，在进行测试时，软件居然会显示画面的处理时间，可以反映显卡的性能，当然这个只能作为参考，准确性不太高。
Display-Test软件界面 灰阶测试 一般来说，普通用户在检查显示设备时，对于坏点、漏光、色彩还原的关注更多，灰阶这个重要指标反而容易被忽略。
液晶屏幕上人们肉眼所见的一个点，即一个像素，它是由红、绿、蓝（RGB）三个子像素组成的。
每一个子像素，其背后的光源都可以显现出不同的亮度级别。
而灰阶代表了由最暗到最亮之间不同亮度的层次级别。
这中间层级越多，所能够呈现的画面效果也就越细腻。
也就是说，显示设备的屏幕灰阶表现越好，暗部的细节就表现越突出，这样在玩游戏或者看高清电影的时候就会感觉非常好。
对于灰阶测试，将显示器亮度和对比度都调到最大之后，打开显示设备的灰阶测试图，用户可以从中辨别被测试显示器的灰阶层次显示能力。
如果能看清的灰阶越多，就说明显示灰阶表现越好。
测试软件介绍： DisplayX：这是一款很常见的测试软件，全中文界面、无需安装，简单易用。
在灰阶测试方面，软件提供了2个测试图。
其中一个是256级灰阶图，灰阶间过渡的界限越清晰，说明显示器的层次感越强；另一个是八色测试图，颜色之间过渡越平滑，说明灰阶还原能力越好。
除了灰阶测试功能之外，这款软件还能对色彩、对比度、响应时间等进行测试。
比较贴心的是，在测试时，每个画面的顶部都有文字说明，即便你是初次使用，也没问题。
256级灰阶测试画面 TFTTest：这款软件来自于俄罗斯，功能全面，测试项目除了针对性很强之外，还加入了一些特色功能，让测试变得更为直观。
例如在灰阶测试中，第一幅测试图分为4个灰阶过渡的测试带，邻近灰阶块分别相隔为10%、6%~7%、5%、4%，从而让用户分辨出显示器的灰阶控制能力。
第二幅测试图灰阶的间隔更小，其最大的间隔单位才4%，而最小为1%，提供最精细的灰阶层次测试。
此环节测试的设计针对性很强，非常人性化。
鲁大师：一款大家很熟悉的软件了，在硬件测试中也有显示器检测这一项。
其功能很简单，但这是少数能给出显示器性能究竟是怎样的测试软件。
整个测试程序其实就是进行灰阶测试，首先画面会变成全白，只要你用鼠标点击从左到右你能看清的最后一行字，画面就会自动切换，最后程序就会给出一个评估的结果。
从我们实际测试的结果来看，鲁大师给出的屏幕判断结果也不是特别准确，给出的仍然是一个参考值，不过其具备的灰阶测试画面等还是有利用的价值。
鲁大师提供了两个显示器测试工具 色彩偏差测试 一台显示设备效果的好坏很大程度上取决于其色彩表现如何，如果偏色，那肯定不是好产品。
要准确测出屏幕色彩还原性能怎样得动用专业设备，但消费者不可能有这些设备。
其实只要一些简单的方法，你就能通过了解到屏幕是否有色彩偏差。
上面介绍的这些软件都提供了RGB三色色彩还原测试，画面会分别显示红色、蓝色、绿色，我们也可以在显示设备上播放一些图片。
通过在这个测试，就可以看出对原图片色彩还原是否准确，画面明暗交界处的过渡是否自然，从而分辨出显示器的色彩还原能力究竟怎样。
当然播放高清影片也是必不可少的，是否有拖影、对于明暗细节表现否清晰、场景色彩还原是否准确，都是考察显示器性能的重要指标。
软件开发方法之敏捷开发,你用了么
展开全部 1）敏捷开发的过程有着更强的适应性而不是预设性，从敏捷宣言的第四条响应变化高于预设计划便可以看出来。
因为软件开发过程的本身的不可预见性，很多用户在项目开始时不可能对于这个项目有着一个完整而明确的预期。
很多对软件的预期都在后期的修改和完善过程中产生。
因此高适应性显然更加符合软件工程开发的实际。
而敏捷开发实现其适应性的方式主要在于，第一，缩短把项目提交给用户的周期；第二，增加用户，业务人员，开发人员这三者之间的交流；第三，通过减少重构的成本以增加软件的适应性。
（2）敏捷开发的过程中，更加的注重人的因素。
在传统软件工程中，个人的因素很少的被考虑到分工中，每个个体都是只是整个代码开发机器的一个小小的螺丝钉，个人的意志和创造力很大程度上的被抹去为了更好的为集体服务。
而在敏捷开发过程中，每个个人的潜力被充分的考虑，应用什么技术很大程度上直接由在第一线开发的技术人员决定；每个人的特点和创造力都可以充分地发挥，这样开发出来的软件更加的具有生命力，因为他融入了开发者的心血和创意，开发者不再是进行机械的乏味的堆砌，而是创造属于自己的艺术品，这样的条件下产生的代码必然在质量上更占优势。
（3）在敏捷开发的过程中，整个项目是测试驱动的而不是文档驱动的。
不仅每个模块有着自己的相应的测试单元，开发人员在开发自己的模块的过程中必须保证自己所开发的模块可以通过这一单元的测试，并且集成测试贯穿了整个开发过程的始终。
集成测试每天会进行十几次甚至几十次，而不是像传统方法一样只有当各个模块的编码都结束了之后再进行联合调试。
这样，在软件开发的进程中每一点改动所引起的问题都容嘉容易暴露出来，使得更加容易在错误刚刚产生的时候发现问题从而解决问题。
这样就避免了在最后整个系统完成时错误隐藏的太深给调试造成极大的困难。
...
敏捷开发到底是什么意思
展开全部 过去的软件如word之类的迭代都以年为周期的，自然无法应对快速变化的市场需求。
因此，需要更加敏捷的方式，应对快速发展的互联网世界的发展。
敏捷开发最重要的特点是：以用户需求为中心，快速灵活，团队合作度高。
敏捷开发有很多方法，例如XP、精益开发。
其中以scrum最为普遍。
Scrum本义为带球过人，双方队员比赛前要摆开阵势，计划好进攻路线，而在软件开发中，团队领导人要做好迭代计划，排列优先级，规定必须完成的任务。
scrum3.0中有6个角色，3个工具，4个会议。
scrum3.0中的6个角色利益相关者（Stakeholders）：运营、市场、销售等，他们负责向产品经理提出产品需求。
业务所有者（Business Owner）：通常是产品经理，他负责对利益相关者提出的需求进行拆解以及进行优先级排序，并负责后期的产品评审，同时负责预测一个sprint周期的时间。
团队队长（Team Captain）：通常是我们的开发经理，负责安排一个sprint内的工作安排，通过合理安排让scrum团队的效率以及价值最大化。
行业专家（Subject Matter Experts）：行业专家拥有Scrum团队需要的，但团队中没有的知识和专业技能。
协调人/教练（Facilitator/Coach）:scrum制度的落实者，让scrum在团队中流畅的运作，消除他们的障碍，提高Scrum和敏捷的使用。
变更代理 （Change Agent）:Scrum的咨询顾问，将Scrum引入团队中，并帮助教练理解如何最好地支持和与Scrum团队合作。
3个工具：交付清单、工作清单、正在进行的工作。
4个会议：计划会议、产品评审、进度回顾、团队回顾。
因此，scrum3.0既有计划会议、产品评审、进度和产品回顾会议，也有迭代期内的灵活应变过程，是一种轻重结合的比较好的敏捷方法。
随着各种敏捷团队在国内成熟，很多应用于敏捷的工具也层出不穷。
在工具集中挑选适合的工具使用，可以提高工作效率。
以日事清团队为例： 在日事清软件中，利益相关者如销售、市场、运营等，在与用户平日的接触中积累的功能、缺陷、创意上的建议，并收集于计划看板的【BUG看板】、【建议看板】。
接下来，业务所有者（BO）需要维护精细的需求池，这个职责通常由产品经理担任，他需要非常明白产品的定位和发展，将需求池中的任务按照优先级排序，并拆解为一个个小的用户故事。
然后设置具体的实施时间和项目名称，将可交付成果和待办清单，记录于road map中。
之后，我们的scrum团队会创建一个计划为【产品开发】，产品经理（业务所有者）以及开发经理（团队负责人）会从【roadmap】中提取功能形成work backlog，复制到【产品开发】的【规划池】中，work backlog中还包含一些开发团队必须做的工作，会直接记录在【规划池】中。
正式开始开启sprint (sprint：整个开发过程中若干个短的迭代周期组成)的第一件事，就是召开sprint计划会议。
sprint会议上会确定本次sprint周期的目标是什么，我们需要完成哪些功能。
在会议中，开发经理（团队负责人）需要将【规划池】中的功能拖动到【开发中】，从【开发中】到【测试中】就是日事清所实践的正在进行的工作（WIP）。
会议上会评估每个功能所需的工时以及功能的负责人，我们为确定好的功能添加时间以及任务成员。
通常计划会议会开比较长的时间，它是之后迭代开始运作最关键的会议。
为使得这个会议得到很好地传达，可以通过日事清的日程应用创建好会议任务，并下发给团队成员。
sprint计划会议的开启，意味着第一个sprint开始了：从开发到测试，形成的工作成果都发布到beta版本中。
执行sprint的过程中也有很多问题被发现，需要解决，应此需每日召开约15分钟的站立会。
在每日站立会上，每个团队成员需要回答三个问题： ● 昨天做了什么工作？ ● 今天要做什么？ ● 完成目标是否存在什么问题？ 当测试人员完成了本个周期内的所有功能的测试工作时，预示着本个sprint结束。
在迭代结束前，产品负责人需要进行产品评审，产品会对测试中的功能进行验收。
将达到了产品目标的成果拖动到【待发布】中。
最后整个团队还需要进行一次回顾总结会议，回顾这次迭代有哪些做的好，哪些做的不好，有什么计划。
团队成员需轮流发言，完成自评和他评，分析和总结上一个迭代中遇到的问题，并列出下次的可执行任务，便于改进整个团队的效能。
至此，一个sprint周期完成，以此开始下一个sprint，不断循环往复。
转载请注明出处51数据库 » 在敏捷方法中软件测试
