A. 如何进行软件功能测试
我是做软件测试工作的,仁者见仁智者见智,水平有限,就你提出的问题作一个简单的回答吧,一是期望对你的问题有所帮助,二也是对我自己的提高。
1、我对你的第一个问题表示质疑,你认为测试是保证软件质量吗?能保证吗?
测试只能提高软件质量,做不到保证,bug是永远存在的,测试工作可以让这
量减少、降低严重问题的存在;软件过程才可能保证它的质量,不是软件测
试,所以这一点我要明确出来。一个软件的质量好坏不依赖于测试者,测试
再高明,软件设计本身的水平面要品质不高,巧妇也有无米之炊的无奈。
2、测试的原本目标就是发现缺陷,挑毛病,工作性质和开发人员相反,但目标
是一致的,都是为了使软件更完美、更稳定。
3、盖房子的时候,先打地基,地基如果有毛病(如不够深、不平),那以后房
盖起来了住个几年,你会发现楼上的梁会发裂,渗水,然后越来越让人担
忧。这时你要修复怎么办,再怎么补都不放心,因为地基有缺陷啊!这个道
和第三个问题是一模一样的,修复的代价太大太大了!在测试中有一个规
则,问题越早解决代价越小,单元测试发现的问题解决只要1块钱,等到集成
测试再解决,要10块钱,你认为比例有多大?需求分析系统设计是源头,重
中之重,这个比例我认为要在上面我举例中增加80%,就是说它会导致你在编
码阶段多付出8块钱。前期可能不觉得,越到后期将发现非常头痛,这也是我
的经验之谈,没有太多的科学性哦。
4、对于测试员,首先是效率减低;对于项目而言,成本增加了。瞧病就错了
诊,影响大么?将导致后面的百分之八十的事情白做了,百分之二在长远
目标中有后期帮助,同时证明另外百分之八十步入歧途。这就要在测试设计
的时候要仔细全面,但是这种事情多少都避免不了,早一点发现并改变,也
是很重要的,另外多布置一些小结会议,有利到测试的工作方向和目标。
usfo,希望我的回答对你稍有帮助哦。
B. 软件怎么测试
在测试工作中,需要接触到各种类型的测试工具。一般来说,有以下一些类型的工具:
测试管理工具:可以帮助完成测试计划、跟踪测试运行结果等的工具。这类工具还包括有助于需求、设计、编码测试及缺陷跟踪的工具;
静态分析工具:分析代码而不执行代码。这种工具检测某些缺陷比用其它方法更有效,开销也更小。这种工具一般可以度量代码的各种指标,如McCabe测定复杂度,Logiscope度量代码和规范的复合度等等;
覆盖率工具:这种工具评估通过一系列测试后,软件被执行的程度。这种工具大量的被应用于单元测试中,如PureCoverage、TrueCoverage、Logiscope等;
动态分析工具:这种工具评估正在运行的系统。例如,检查系统运行过程中的内存使用情况,是否有内存越界、内存泄露等等,这类工具有Purify、BoundChecker等;
测试执行工具:这类工具可使测试能够自动化进行,并且各个层次(单元测试、集成测试、系统测试)的执行工具都有。例如系统测试阶段有功能测试自动化工具,如Robot、Winrunner、SilkTest等;还有性能测试工具,如Loadrunner、SilKPerformer等。
白盒测试工具主要有:
内存资源泄漏检查:Numega中的bouncechecker,Rational的Purify
代码覆盖率检查:Numega中的truecoverage,Rational的Purecoverage,Telelogic公司的logiscope, Macabe公司的Macabe
代码性能检查:Numega中的truetime,Rational的Quantify
代码静态度量分析质量检查工具:logiscope和Macabe
黑盒测试工具主要有:
客户端功能测试:MI公司的winrunner,compuware的qarun,Rational的robot
服务器端压力性能测试: MI公司的winload,compuware的qaload,Rational的SQA load等等
Web测试工具:MI公司的Astra系列,rsw公司的e-test suite
测试管理工具:rational的test manager,compuware的qadirector等
缺陷跟踪工具:trackrecord,Testtrack
单元测试工具:
C. 如何做软件测试
软件测试说白了,就是找出软件的不足。软件测试分为黑合和白盒。也有分为黑盒、灰盒、白盒。黑盒主要指功能测试,以手动测试为主,自动化测试做为次要测试。黑盒测试对技术要求相对于白盒来讲不是很高。白盒测试以针对源代码为主,对技术及开发经测试要求高。灰盒测试是黑盒与白盒组成的综合测试,对工作能力及经验要求很高。一般用做系统测试。你的提问范围太大。希望我的回答对你有帮助。建议先从功能测试入手。白盒和灰盒测试一般都要求有开发经验。
D. 如何测试app软件测试在手机中的使用情况
手机app测试主要有以下:
1.安全测试
1)软件权限
-扣费风险:包括发送短信、拨打电话、连接网络等 -隐私泄露风险:包括访问手机信息、访问联系人信息等 -新增风险项
2)开发者官方权限列表信息比对分析 2.安装、运行、卸载测试
验证App是否能正确安装、运行、卸载,以及操作过程和操作前后对系统资源的使用情况,主要包括:
1)检测软件是否能正确安装、运行、卸载; 2)安装、卸载、更新错误报告; 3)其他辅助信息: -位置和文件夹是否合理; -组件是否正确注册或删除;
-评估操作前后,CPU、Memory(内存占用)、Storage(磁盘占用)等系统资源的使用情况。 3.UI测试
测试用户界面(如菜单、对话框、窗口和其它可视控件)布局、风格是否满足客户要求,文字是否正确,页面是否美观,文字,图片组合是否完美,操作是否友好等。
UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。 4.功能测试
根据软件说明或用户需求验证App的各个功能实现,采用如下方法实现并评估功能测试过程:
1)采用时间、地点、对象、行为和背景五元素或业务分析等方法分析、提炼App的用户使用场景,对比说明或需求,整理出内在、外在及非功能直接相关的需求,构建测试点,并明确测试标准(若用户需求中无明确标准遵循,则需要参考行业或相关国际标准或规则)。 2)根据被测功能点的特性列举出相应类型的测试用例对其进行覆盖,如:涉及输入的地方需要考虑等价、边界、负面、异常或非法、场景回滚、关联测试等测试类型对其进行覆盖。 3)在测试实现的各个阶段跟踪测试实现与需求输入的覆盖情况,及时修正业务或需求理解错误。 5.性能测试
评估App的时间和空间特性
1)极限测试:在各种边界压力情况下(如电池、存储、网速等),验证App是否能正确响应。
2)响应能力测试:测试App中的各类操作是否满足用户响应时间要求 3)压力测试:反复/长期操作下,系统资源是否占用异常; 4)性能评估:评估典型用户应用场景下,系统资源的使用情况。
5)Benchmark测试(基线测试):与竞争产品的Benchmarking,产品演变对比测试等。 6.中断测试
针对智能终端应用的服务等级划分方式及实时特性所提出的测试方法,如:App在前/后台运行状态时与来电、文件下载、音乐收听等关键运用的交互情况测试等。 7.兼容测试
主要测试内部和外部兼容性,包括:
与本地及主流App是否兼容; 检验在各种网络连接下(WiFi、GSM、GPRS、EDGE、WCDMA、CDMA1x、CDMA2000、HSPDA等),App的数据和运用是否正确;
与各种设备是否兼容(若有跨系统支持则需要检验是否在各系统下,各种行为是否一致)。
8.安全测试
安全测试显得尤为重要,粗心、不谨慎的数据存储或传输方式使得非法、恶意目的有可乘之机。
智能终端安全涉及各信息交互、存储接点,借鉴于网络传输和相关安全测试经验,App安全测试大概划分为以下几类:
1)从数据的本地存储到数据的传输、处理以及远程访问等各个环节,基于相应的安全标准/行业标准评估App的安全特性;
2)借鉴在Web App和网络安全测试的一些成功经验在智能终端App测试中进行裁减或适配;
3)检测App的用户授权级别,数据泄漏,非法授权访问等;
4)对App的输入有效性校验、认证、授权、敏感数据存储、数据加密等方面进行检测,以期发现潜在的安全问题;
5)基于各种通信协议或相应的行业安全标准检视App是否满足相应的要求
E. 软件测试的测试流程是怎样的
需求:阅读需求,理解需求,与客户、开发、架构多方交流,深入了解需求。--testing team
2.测试计划: 根据需求估算测试所需资源(人力、设备等)、所需时间、功能点划分、如何合理分配安排资源等。---testing leader or testing manager
3.用例设计:根据测试计划、任务分配、功能点划分,设计合理的测试用例。---testing leader, senior tester
4.执行测试:根据测试用例的详细步骤,执行测试用例。--every tester(主要是初级测试人员)
5.执行结果记录和bug记录:对每个case记录测试的结果,有bug的在测试管理工具中编写bug记录。--every tester(主要是初级测试人员)
6.defect tracking:追踪leader分配给你追踪的bug.直到 bug fixed。--every tester
7.测试报告:通过不断测试、追踪,直到被测软件达到测试需求要求,并没有重大bug.
8.用户体验、软件发布等……
F. 怎么搞测试软件啊从哪弄
你首先得了解软件测试的基本概念才行,然后在逐步学习一些软件测试知识,建议你看下《软件测试的艺术》这本书吧。
G. 怎么软件测试啊
软件测试方法
软件测试的基本方法
单元测试的基本方法
综合测试的基本方法
确认测试的基本方法
系统测试的基本方法
软件测试的基本方法
软件测试的方法和技术是多种多样的。
对于软件测试技术,可以从不同的角度加以分类:
从是否需要执行被测软件的角度,可分为静态测试和动态测试。
从测试是否针对系统的内部结构和具体实现算法的角度来看,可分为白盒测试和黑盒测试;
1、黑盒测试
黑盒测试也称功能测试或数据驱动测试,它是在已知产品所应具有的功能,通过测试来检测每个功能是否都能正常使用,在测试时,把程序看作一个不能打开的黑盆子,在完全不考虑程序内部结构和内部特性的情况下,测试者在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数锯而产生正确的输出信息,并且保持外部信息(如数据库或文件)的完整性。黑盒测试方法主要有等价类划分、边值分析、因果图、错误推测等,主要用于软件确认测试。 “黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试,只有把所有可能的输入都作为测试情况使用,才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个,人们不仅要测试所有合法的输入,而且还要对那些不合法但是可能的输入进行测试。
2、白盒测试
白盒测试也称结构测试或逻辑驱动测试,它是知道产品内部工作过程,可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行,按照程序内部的结构测试程序,检验程序中的每条通路是否都有能按预定要求正确工作,而不顾它的功能,白盒测试的主要方法有逻辑驱动、基路测试等,主要用于软件验证。
“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。在使用这一方案时,测试者必须检查程序的内部结构,从检查程序的逻辑着手,得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一,穷举路径测试决不能查出程序违反了设计规范,即程序本身是个错误的程序。第二,穷举路径测试不可能查出程序中因遗漏路径而出错。第三,穷举路径测试可能发现不了一些与数据相关的错误。
3.ALAC(Act-like-a-customer)测试
ALAC测试是一种基于客户使用产品的知识开发出来的测试方法。ALAC测试是基于复杂的软件产品有许多错误的原则。最大的受益者是用户,缺陷查找和改正将针对哪些客户最容易遇到的错误。
单元测试的基本方法
单元测试的对象是软件设计的最小单位模块。单元测试的依据是详细设描述,单元测试应对模块内所有重要的控制路径设计测试用例,以便发现模块内部的错误。单元测试多采用白盒测试技术,系统内多个模块可以并行地进行测试。
单元测试任务
单元测试任务包括:1 模块接口测试;2 模块局部数据结构测试;3 模块边界条件测试;4 模块中所有独立执行通路测试;5 模块的各条错误处理通路测试。
模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下,其他测试才有意义。测试接口正确与否应该考虑下列因素:
1 输入的实际参数与形式参数的个数是否相同;
2 输入的实际参数与形式参数的属性是否匹配;
3 输入的实际参数与形式参数的量纲是否一致;
4 调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同;
5 调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配;
6调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致;
7 调用预定义函数时所用参数的个数、属性和次序是否正确;
8 是否存在与当前入口点无关的参数引用;
9 是否修改了只读型参数;
10 对全程变量的定义各模块是否一致;
11是否把某些约束作为参数传递。
如果模块内包括外部输入输出,还应该考虑下列因素:
1 文件属性是否正确;
2 OPEN/CLOSE语句是否正确;
3 格式说明与输入输出语句是否匹配;
4缓冲区大小与记录长度是否匹配;
5文件使用前是否已经打开;
6是否处理了文件尾;
7是否处理了输入/输出错误;
8输出信息中是否有文字性错误;
检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确。局部数据结构往往是错误的根源,应仔细设计测试用例,力求发现下面几类错误:
1 不合适或不相容的类型说明;
2变量无初值;
3变量初始化或省缺值有错;
4不正确的变量名(拼错或不正确地截断);
5出现上溢、下溢和地址异常。
除了局部数据结构外,如果可能,单元测试时还应该查清全局数据(例如FORTRAN的公用区)对模块的影响。
在模块中应对每一条独立执行路径进行测试,单元测试的基本任务是保证模块中每条语句至少执行一次。此时设计测试用例是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。此时基本路径测试和循环测试是最常用且最有效的测试技术。计算中常见的错误包括:
1 误解或用错了算符优先级;
2混合类型运算;
3变量初值错;
4精度不够;
5表达式符号错。
比较判断与控制流常常紧密相关,测试用例还应致力于发现下列错误:
1不同数据类型的对象之间进行比较;
2错误地使用逻辑运算符或优先级;
3因计算机表示的局限性,期望理论上相等而实际上不相等的两个量相等;
4比较运算或变量出错;
5循环终止条件或不可能出现;
6迭代发散时不能退出;
7错误地修改了循环变量。
一个好的设计应能预见各种出错条件,并预设各种出错处理通路,出错处理通路同样需要认真测试,测试应着重检查下列问题:
1输出的出错信息难以理解;
2记录的错误与实际遇到的错误不相符;
3在程序自定义的出错处理段运行之前,系统已介入;
4异常处理不当;
5错误陈述中未能提供足够的定位出错信息。
边界条件测试是单元测试中最后,也是最重要的一项任务。众的周知,软件经常在边界上失效,采用边界值分析技术,针对边界值及其左、右设计测试用例,很有可能发现新的错误。
单元测试过程
一般认为单元测试应紧接在编码之后,当源程序编制完成并通过复审和编译检查,便可开始单元测试。测试用例的设计应与复审工作相结合,根据设计信息选取测试数据,将增大发现上述各类错误的可能性。在确定测试用例的同时,应给出期望结果。
应为测试模块开发一个驱动模块(driver)和(或)若干个桩模块(stub),下图显示了一般单元测试的环境。驱动模块在大多数场合称为“主程序”,它接收测试数据并将这些数据传递到被测试模块,被测试模块被调用后,“主程序”打印“进入-退出”消息。
驱动模块和桩模块是测试使用的软件,而不是软件产品的组成部分,但它需要一定的开发费用。若驱动和桩模块比较简单,实际开销相对低些。遗憾的是,仅用简单的驱动模块和桩模块不能完成某些模块的测试任务,这些模块的单元测试只能采用下面讨论的综合测试方法。
提高模块的内聚度可简化单元测试,如果每个模块只能完成一个,所需测试用例数目将显着减少,模块中的错误也更容易发现。
H. 如何进行软件测试
测试里面的知识学习可以分为以下三个阶段来进行(这个阶段只是自己的一种个人见解):第一个阶段我们必须要让做测试的人明白测试在整个软件工程里面的重要性,了解测试的相关基础知识,并且在了解这些知识的过程中逐渐挖掘出他对测试的兴趣。兴趣爱好是很好的从事一项工作的一个重要条件。让一个对测试丝毫不懂而且不感兴趣的人去直接去做测试,你不觉得是在耽误别人的青春吗? 第二个阶段我们必须对测试的流程的管理工作通过实际的软件测试有个非常明确的认识。因为很多时候工作都是在团队相互协调的情况下进行的,所以对于整个软件开发流程以及开发流程当中的测试流程都需要很熟悉,这样才可以更好的配合工作。当我们这些都很熟悉并且在工作当中应用很流畅的时候,我们就可以对测试工具进行相对应的学习。诚然,现在很多公司在招聘测试人员的时候总是要求了解自动化测试工具,实际上据了解,很多公司并不能真正用自动化测试。所以不要一进门就想着学习自动化测试工具,很多知识在你了解了其他知识之后学习效果跟用途可能会更好。在了解测试相关流程的同时我们必须扩充我们的其他相关知识,包括对我们的产品的客户的需求的了解要比开发人员了解更全面,更深入。这样才能保证我们的流程,我们的测试按照客观的正确的方向前进,而不至于被开发人员的思想所牵引。呵呵。我喜欢做事主动而不是被动的去执行。 到第三个阶段我们可以跟区分专业一样走自己喜欢的途径:一方面可以继续深入提高自己的测试的专业技能并且能够真正从事自动化测试,成为技术领域里面的专家。另一方面我们可以慢慢趋于测试管理方面。从一个初级测试工程师晋升到一个高级测试工程师比较快,但是从一个初级测试工程师发展到一个Team Leader所需要的时间相对比较长。而从一个高级测试工程师发展到一个资深测试工程师花费时间更长一点,到达资深测试工程师之后就可以很容易做到测试主管了,以后可以发展到PM。当然从初级测试人员到高级、资深测试人员并不是表述为“曲线发展过程”的,很多时候行业经验、行业知识的累积等都很重要。而这点只有深入发展的人才会发现其重要性的。很多随着时间的推移和经验的增长,一些沉淀下来的东西不是表现在字面上,别人就可以理解并领悟的。所以要有信心的同时我们做事还必须有耐心,罗马非一日建成。相信明天就要紧紧把握今天。
I. 如何去测试一个B/S软件
由于你们只做功能测试,作为过来人,有两点建议:
1、需要业务上的各个流程搞通,要非常精通业务,能够想到各个细枝末节,包括转牛角尖的地方(就是特殊环节)。
2、程序设计流程,需要你们与开发人员沟通,也需要很精通,这个可以参考设计人员的程序设计资料。
先精通业务,后搞通程序设计流程
J. 新完成的软件该怎么测试
不一定需要工具。
简单来说,
1、根据时间安排和你们这个软件的具体需求制定一个合适的测试计划,测试计划要做以下事情:
a) 制定测试策略。要进行哪些测试(功能、性能、安全等等), 这个你需要多查查资料;
b) 确定测试进度安排,分配好测试资源(人员、机器的安排等等);
c) 定义输入输出标准(软件达到什么程度可以交付测试,测试进行到什么程度可以结束测试);
2、测试计划在完成后要进行评审,包括项目组所有成员,最好叫上你们老师一起,修改不合适的地方,最后把计划确定下来。确定后就好办了,后期照着执行就行。
3、写好测试用例,用例的设计方法网上都有,主要是用例要能覆盖所有的功能点,步骤和结果要清晰、明确。
4、测试用例完成后也要进行评审。
5、执行测试用例,找到的BUG看来是你们自己修改。BUG修复后还要进行回归测试,确认bug已经修复。
6、最后BUG修改的差不多,达到通过标准(在测试计划中定义的)后,就算是OK了。
对于你们来说其他的可以先不考虑,最主要的是写好测试用例,用例能覆盖所有的功能点。最后有个规范、完整的测试用例文档,和软件一起交付就还算过得去了。