对软件测试的理解
测试的目的:尽可能多的发现缺陷,比如功能的错误,性能低下,易用性差。
测试的思路:先假设程序存在什么缺陷,然后执行程序来发现缺陷。
测试类型:白盒测试,黑盒测试。
白盒测试:看得见的程序内部结构,测试源程序的逻辑结构和实现细节。白盒测试必须由开发人员独立执行,因为测试人员无法理解代码内部逻辑。
黑盒测试:看不见的程序内部结构,按照规格来测试程序是否符合要求。黑盒测试必须由独立测试小组执行,因为开发人员难以做到客观公正。
主要发现以下问题:是否有不正确或遗漏了的功能;在接口上,能否正确的接收输入,能否输出正确的结果; ·是否有数据结构错误或外部信息访问错误;性能上是否能够满足要求;是否有初始化或终止性错误; 黑盒测试需要在所有可能的输入条件和输出条件中确定测试数据,以检查程序是否都能产生正确的输出;有时测试数据量太大,是不现实的。
如:测试一个模块时,白盒测试:要对所有代码进行单步跟踪测试,关注的是程序的内部细节。黑盒测试:只需测试模块的接口是否要求,关注的是程序的外部实现。
α测试和β测试 :在软件交付使用之后,用户将如何实际使用程序,对于开发者来说是不知道的。通常在软件发布上市之前需要进行α测试和β测试。 α测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的测试。α测试必须是开发人员和测试小组共同参与完成。
α测试:公司内部对软件的测试。
α测试的目的是评价软件产品的FLURPS(功能、局域化、可使用性、可靠性、性能和支持)。尤其注重产品的界面和特色。 α测试可以从软件产品编码结束之时开始,或者在模块(子系统)测试完成之后开始,也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。
β测试:产品正式发布之前,公司外部邀请用户进行测试。
α、β、λ常用来表示软件测试过程中的三个阶段,α是第一阶段,一般只供内部测试使用;β是第二个阶段,已经消除了软件中大部分的不完善之处,但仍有可能还存在缺陷和漏洞,一般只提供给特定的用户群来测试使用;λ是第三个阶段,此时产品已经相当成熟,只需在个别地方再做进一步的优化处理即可上市发行。
封测 的意思就是 游戏制作 刚刚完成,需要在技术上对游戏进行测试,这个阶段的测试是纯技术的,和游戏的故事情节、人设一点都没有关系,整个游戏基本处于雏形阶段,所以除了有关技术人员以外,别人是接触不到游戏的。
内测 在这三个阶段的测试中,是时间最长的,少则几周,多则数月,这个阶段的测试至关重要,也是对游戏最全面的测试,所有的关于游戏的技术问题,以及关于游戏的故事、人设、风格、人物、服饰、语言、动作、主支线任务的合理性等等诸多方面进行测试和评估,乃至最后的修改。即使是内测,也是很少很少一部分人可以参与,大部分是游戏制作人员,运营代理商和与制作及运营游戏的商家,及一部分普通玩家。
到了 公测 阶段,就会有相当一部分玩家参与进来,这个时候游戏已经基本定型,也就是处于正式推出的最后阶段的测试。实际上就是听取玩家的意见和反馈,以便为今后纠正错误做统计和准备,纠正错误的方式一般采取出补丁的方式。
测试内容:
1、功能测试:检查软件的功能是否符合要求。枚举方法:构造合理的输入,看是否有期望的输出。边界值方法:采用定义域的边界值进行测试。
2、容错性测试:检查软件在异常情况下的反应,容错性好的软件会确保系统不发生难以预料的崩溃。方法:构造一些不合理的数据看系统的反应(错误的数据类型或定义域外的值)。
3、性能与效率测试:测试软件的速度与对资源的利用率。极限测试:持续不停地给服务器发送请求看是否会死掉,给程序输入特别大的数据看是否能吃得消。获取测试的绝对值(如数据的传输率):记录运行环境对软件的影响。获取测试的相对值(如该软件和其他软件相比快多少倍):确保被测试的几个软件具有相同的软件和硬件环境中。
4、易用性测试:用户不用看用户手册,即具有好的易用性。
5、文档测试:检查文档的正确性,完备性,可理解性。
上述内容参考该篇内容
测试手机:
1、电话。
是否可以正常接受电话。
是否可以删除通话记录。
是否可以拉黑。
输入错误位数号码是否有提示。
2、短信。
是否可以正常接收短信。
是否可以删除短信记录。
是否可以拉黑。
接收短信是否有提示,发送短信是否有成功提示。
发送内容为空时是否有提示。
输入错误位数号码是否有提示。
3、联系人。
是否有电话本功能。
是否可以新建删除更新联系人信息。
是否可以将联系人设成常用联系人或黑名单。
联系人输入信息为空是否有提示。
删除联系人是否有提示。
更新时是否有提示确认更新。
测试题:
1、在游戏或软件开发完成的初期,由游戏公司或软件公司发送限定的激活码或账号给玩家,由玩家测试并向游戏公司反馈使用情况和存在的问题,以促进游戏的进一步完善的环节称为内侧。
2、单元测试能发现约80%的软件缺陷。
3、JUnit主要用来完成什么:单元测试。JUnit是一个Java语言的单元测试框架。Junit测试是程序员测试,即所谓白盒测试。
4、测试驱动开发,英文全称Test-Driven Development,简称TDD,是一种不同于传统软件开发流程的新型的开发方法。它要求在编写某个功能的代码之前先编写测试代码,然后只编写使测试通过的功能代码,通过测试来推动整个开发的进行。这有助于编写简洁可用和高质量的代码,并加速开发过程。测试驱动开发可以和结对编程结合使用。
测试驱动开发适合使用CMM/CMMI方法?CMM/CMMI方法这两种方法属于测试驱动开发的方式。
CMM是指“能力成熟度模型”,它是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。CMM的核心是把软件开发视为一个过程,并根据这一原则对软件开发和维护进行过程监控和研究,以使其更加科学化、标准化、使企业能够更好地实现商业目标。
CMMI能力成熟度模型集成将各种能力成熟度模型,整合到同一架构中去,由此建立起包括软件工程、系统工程和软件采购等在内的诸模型的集成,以解决除软件开发以外的软件系统工程和软件采购工作中的迫切需求。
5、下图用基本路径法测试需要覆盖几条路径?
6、桩函数,也叫stub函数,存根函数。用一个桩函数替换一些接口函数,用于测试当前函数的特性。
在单元测试中被其它模块调用,
在自顶向下的集成过程中尤其有效
譬如说,要测试一个函数 f()
void f()
{
var = g(...);
}
f()函数中调用了函数 g(),但是在测试f()的时候g()函数可能还没有写出来 。
这时可以写一个g()的 存根(stub)函数,来模拟g()函数,例如让它仅仅返回一个值.这样的话就可以完成对函数f()的测试了.
7、软件测试计划评审会需要哪些人员参加。
软件测试计划评审会需要有 项目经理、客户(可选)、配置管理员、测试经理、开发组长,SQA 负责人等人的参加。
SQA-Software Quality Assurance)
8、黑盒测试方法 、白盒测试方法:
白盒测试的测试方法有代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、域测试、符号测试、路径覆盖和程序变异
具体的黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法、场景法等。
白盒测试法的覆盖标准有 逻辑覆盖 、循环覆盖和基本 路径测试 。其中逻辑覆盖包括 语句覆盖 、 判定覆盖 、 条件覆盖 、判定/条件覆盖、 条件组合覆盖 和 路径覆盖 。边界值法既可以用于黑盒测试用例,也可以用于白盒测试用例。边界值分析的基本思想是使用在最小值、略高于最小值、正常值、略低于最大值和最大值处取输入变量值,记为:min、min+、nom、max-、max考虑到健壮性测试,还可以加一个略大于最大值max+,以及一个略小于最小值min-的值。
用边界值分析法,假定1<X<10,那么X在测试中应该取的边界值是X=1,X=2,X=9,X=10
白盒测试分为:
1.语句覆盖:可执行语句至少被执行一次;
2.判断覆盖:每个判断的取真分支和取假分支至少经历一次;
3.条件覆盖:每个条件的取值至少满足一次;
4.判断条件覆盖:判断和条件都满足;
5.条件组合覆盖:每个条件的所有可能都至少出现一次,并且判定结果至少出现一次 ;
他与条件覆盖的区别:他不是简单要求每个条件出现“真”和“假”两种结果,而是要求这些结果所有可能至少出现一次;
6.路径测试:执行所有可能的执行路径;
7.基本路径测试:路径测试执行了每个路径,每个判定的结果肯定经历过一次
判定覆盖是每个判定的真假一次,就会导致所有的结果路径会实现;
条件覆盖是每个判定里的条件各取一次,不一定会产生所有的结果;
9、测试方法可以分成哪几种?
软件测试可以是人工测试:如个人复查,抽查和会审等
也可以是机器自动测试,又有不同的分类:
按照否关软件内部结构具体实现角度划
A.白盒测试B.黑盒测试 C.灰盒测试
按照软件发程按阶段划
A.单元测试 B.集测试 C.确认测试 D.系统测试 E.验收测试
灰盒测试,是介于白盒测试与黑盒测试之间的一种测试,灰盒测试多用于集成测试阶段,不仅关注输出、输入的正确性,同时也关注程序内部的情况。灰盒测试不像白盒那样详细、完整,但又比黑盒测试更关注程序的内部逻辑,常常是通过一些表征性的现象、事件、标志来判断内部的运行状态
10、代码评审员一般由测试员担任?错!一般都是开发人员评审
11、测试的关键问题是: 如何选择测试用例
12、系统测试将软件,硬件,网络等其他因素结合,对整个软件进行测试.白盒测试等不是系统测试的内容。
13、V模型大体可以划分为以下几个不同的阶段步骤:需求分析、概要设计、详细设计、软件编码、单元测试、集成测试、系统测试、验收测试。
需求分析 验收测试
概要设计 系统测试
详细设计 集成测试
编码 单元测试
V
集成测试计划在需求分析阶段 末(mo) 提交
14、负载测试是验证要检验的系统的能力最高能达到什么程度
15、测试人员要坚持原则,缺陷未修复完坚决不予通过。请判断这句话的正确与否。错!!!!!!!!!!!!
缺陷分两种:
1、完全影响软件的正常运行或者影响客户的正常体验。
这种当然不能予以通过
2、不影响产品运行及客户正常体验且此软件急于使用。
以公司利益为出发,应予以通过。但在时间不紧急的情况下应不予通过。
一个好的测试人员应该有很好的情况分析能力,并且要有担当
16、 软件测试的目的是为了发现错误而执行程序的过程,并不涉及改正错误。
程序调试的基本步骤有:错误定位、修改设计和代码,以排除错误、进行回归测试,防止引进新的错误。程序调试通常称为Debug,即排错。
软件测试的基本准则有:所有测试都应追溯到需求、严格执行测试计划,排除测试的随意性、充分注意测试中的群集现象、程序员应避免检查
自己的程序、穷举测试不可能、妥善保存测试计划等文件。
17、
条件覆盖CC(Condition Coverage),设计足够多的测试用例,运行被测程序,使得每一判定语句中每个逻辑条件的可能取值至少满足一次。
条件覆盖率的公式:条件覆盖率=被评价到的条件取值的数量/条件取值的总数X100%[1]
条件覆盖的缺点:只考虑到每个判定语句中的每个表达式,没有考虑到各个条件分支(或者涉及不到全部分支),即不能够满足判定覆盖.
条件组合覆盖,也称多条件覆盖MCC (Multiple Condition Coverage),设计足够多的测试用例,使得每个判定中条件的各种可能组合都
至少出现一次(以数轴形式划分区域,提取交集,建立最少的测试用例)。这种方法包含了“分支覆盖”和“条件覆盖”的各种要求。满足条件组合
覆盖一定满足判定覆盖、条件覆盖、判定条件覆盖。条件组合覆盖率的公式:条件组合覆盖率=被评价到的条件取值组合的数量/条件取值组合的
总数条件组合覆盖的缺点:判定语句较多时,条件组合值比较多。
语句覆盖 SC(Statement Coverage),就是设计若干个测试用例,运行被测程序,使得程序中每一可执行语句至少执行一次。这里的“若干个”
,意味着使用测试用例越少越好。语句覆盖在测试中主要发现缺陷或错误语句。
判定条件覆盖CDC(Condition/ Decision Coverage),设计足够多的测试用例,使得判定中的每个条件的所有可能(真/假)至少出现一次,
并且每个判定本身的判定结果也至少出现一次。[1] 判定条件覆盖率的公式:条件判定覆盖率=被评价到的条件取值和判定分支的数量/(条件取值
总数+判定分支总数).判定条件覆盖的缺点:没有考虑单个判定对整体结果的影响,无法发现逻辑错误。
18、
软件验收测试分为三类:
正式验收测试;
非正式验收测试。其中包括α测试(由用户、测试人员、开发人员共同参与的内部测试。)
和β测试(内测后的公测,即完全交给最终用户测试。)
19、
LoadRunner,是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题,
可适用于各种体系架构的自动负载测试,能预测系统行为并评估系统性能。
其测试组件有
1.VuGen Load Generator(虚拟用户生成器)用于捕获最终用户业务流程和创建自动性能测试脚本 (也称为虚拟用户脚本)。
2.Controller (控制器)用于组织、驱动、管理和监控负载测试。
3.Analysis (分析器)有助于您查看、分析和比较性能结果。
包括A脚本编辑工具 C测试执行工具 D结果分析工具
20、 系统集成测试主要包括以下过程:1. 构建的确认过程。 2. 补丁的确认过程。 3. 系统集成测试测试组提交过程。
4. 测试用例设计过程。 5. 测试代码编写过程。 6. Bug的报告过程。 7. 每周/每两周的构建过程。 8. 点对点的测试过程。
9. 组内培训过程。
21、
系统测试的16个测试策略:
功能测试、性能测试、压力测试、容量测试、安全性测试、GUI测试、可用性测试、安装测试、配置测试、异常测试,备份测试、健壮性测试、
文档测试、在线帮助测试、网络测试、稳定性测试。
22、α测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的受控测试,
α测试不能由程序员或测试员完成。α测试发现的错误,可以在测试现场立刻反馈给开发人员,由开发人员及时分析和处理。
目的是评价软件产品的功能、可使用性、可靠性、性能和支持。
尤其注重产品的界面和特色。Alpha测试可以从软件产品编码结束之后开始,或在模块(子系统)测试完成后开始,
也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。
alpha 测试需要用户参加
alpha 测试是验收测试的一种
23、 软件测试用例包括 输入数据和预期输出结果
24、项目立项前测试人员不需要提交任何工件。工件是加工过程中的生产对象。项目立项前,测试人员是不需要提供任何工件的。
25、自底向上集成需要测试员编写驱动程序。自底向上测试是从“原子”模块(即软件结构最低层的模块)开始组装测试,因测试到较高层模块时,所需的下层模块功能均已具备,所以不再需要桩模块。
自底向上集成方法不用桩模块,测试用例的设计亦相对简单,但缺点是程序最后一个模块加入时才具有整体形象,需要开发驱动模块。
26、
针对手机应用软件的系统测试,我们通常从如下几个角度开展:功能模块测试,交叉事件测试,压力测试,容量测试,兼容性测试,易用性/用户体验测试等.
对手机可以施加的压力测试类型主要有:存储压力、边界压力、 响应能力压力、网络流量压力, 无并发压力
并发压力是针对服务器的,因为每次并发是一个客户端
27、测试设计员的职责有: 设计测试用例, 设计测试过程、脚本。
测试设计人员主要负责设计测试用例以及设计测试过程。 制定测试计划是测试经理来做的;评估测试活动是测试经理组织开发人员来进行的。
28、LoadRunner-负载压力测试:预测系统性能。
JMeter+Badboy:基于JAVA的压力测试工具,Badboy用来进行脚本的录制
功能测试:通过自动录制、检测和回放用户的应用操作。将输出记录同预先给定的记录比较。
Junit:白盒测试工具:针对代码测试
测试管理工具:对测试需求、计划、用例、实施进行管理
测试辅助工具:本身不执行,可以生成测试数据,为测试提供数据准备
负载压力测试:LoadRunner:预测系统行为和性能的工业标准级负载测试工具。模拟上千万用户同时实施并发操作,来实时监控可能发生的问题。
功能测试: QTP(quicktest professional):自动测试工具
白盒测试:C++ TEST(做C和C++的白盒测试)、JUnit(Java白盒测试)
缺陷管理工具:Mantis、BugFree、QC、TD
用例管理工具:TestLink、QC
测试辅助工具:SVN
28、【软件需求】是软件开发之前做好的,软件开发是根据这个做的,那么软件测试自然也需要参考该文件 【迭代计划】是软件的某个周期的计划,自然也需要参考 【可行性】是软件开发前做好,用于证明该计划可行的,没有必要参考。可行性研究报告,在软件开发前做好了,在开发前项目经理已召开进行评估,通过后才开始开发此软件,所以在测试过程中,不再需要参考次报告
参考链接:https://blog.csdn.net/melody_day/article/details/60472607