(1)需求调查:全面了解系统概况、应用领域、软件开发周期、软件开发环境、开发组织、时间安排、功能需求、性能需求、质量需求及测试要求等。根据系统概况进行项目所需的人员、时间和工作量估计以及项目报价。
(2)制定初步的项目计划。
(3)测试准备:组织测试团队、培训、建立测试和管理环境等。
(4)测试设计:按照测试要求进行每个测试项的测试设计,包括测试用例的设计和测试脚本的开发等。
(5)测试实施:按照测试计划实施测试。
(6)测试评估:根据测试的结果,出具测试评估报告。
答案1:链接手机,打开settings,设置debug mode,运行APP,重复崩溃程序,在Android Studio或者iOS development tool中查看debugger error messages崩溃时的情况。如果不能重复崩溃程序,手机进入该app的文档,查看任何隐藏.log文件,留意error messages。
答案2:立刻连上adb,把日志拉出来,记录刚刚操作步骤,尽量试试能不能重现,然后把问题出现步骤以及时间点告知开发,日志发给开发。
答案3:重复操作步骤,bug重现,是必发还是偶发
答案4:(1)记录操作流程(2)记录运行环境(3)获取崩溃日志
答案5:可以用抓包工具连接手机,做一下复现操作进行抓包定位。在一个就是看看是不是没有内存了或者开发在更新代码
答案6:直接搜索Fatal或crash
答案7:回想之前的操作并且多次重复,尝试是否是因为某一个特定位问题导致APP崩溃。并且做下记录通知程序员查看代码是否有误。
答案2:bugzilla,weblssues,mantis,redmine,禅道,atlasian的Jira
白盒测试:路径覆盖、代码走查、静态分析
黑盒测试:等价类划分、边界值分析、场景法、因果图、错误推测法,正交试验
测试类型有:功能测试、性能测试、界面测试
黑盒测试:
白盒测试:
虽然我的测试技术还不是很成熟,但是我觉得我还是可以胜任软件测试这个工作的,因为软件测试不仅要求技术好,还有一定的沟通能力,耐心,细心等外在因素。综合起来看,我认为我是胜任这个工作的。
软件安全性测试包括:程序、数据库安全测试
首先,将问题提交到缺陷管理库进行备案
然后,要获取判断的依据和标准:
根据我以前的工作和学习经验,我认为做好工作首先要有一个良好的沟通,只有沟通无障碍了,才会有好的协作,才会有更好的效率,在一个就是技术一定要过关,做测试要有足够的耐心,和一个良好的工作习惯,不懂的就要问,实时与同事沟通这样的话才能做好测试工作。
这是一个比较常见的现象。测试工程师在没有找到缺陷前会绞尽脑汁的思考,但是找到一个后,会接二连三的发现很多缺陷,颇有个人成就感。其中的原因主要如下:
(1)代码复用、拷贝代码导致程序员容易犯相同的错误。类的继承导致所有的子类会包含基类的错误,反诬拷贝同一代码意味可能也复制了缺陷。
(2)程序员比较劳累是可以导致某些连续编写的功能缺陷,程序员加班是一种司空见惯的现象,因此体力不只是容易编写一些缺陷较多的程序,而这些连续潜伏缺陷恰恰是测试工程师大显身手的地方。
(3)“缺陷一个连着一个”不是一个客观规律,只是一个常见的现象。如果软件编写的比较好,这种现象就不常见了。测试人员只要严肃认真的测试程序就可以了。
软件质量测试保证与测试是根据软件开发阶段的规格说明和程序的内部而精心设计的一批测试用例(即输入数据和预期的输出结果),并根据这些测试用例去运行程序,以发现错误的过程。它是对应用程序的各个方面进行测试以检查其功能、语言有效性及外观排布。
SQA就是独立于软件开发的项目组,通过对软件开发过程的监控,来保证软件的开发流程按照指定的CMM规程(如果有相应的CMM规程),对于不符合项及时提出建议和改进方案,必要时可以向高层经理汇报以求问题的解决。通过这样的途径来预防缺陷的引入,从而减少后期软件的维护成本。
SQA主要的工作活动包括制定SQA工作计划,参与阶段产物的评审,进行过程质量、功能配置及物理配置的审计等;对项目开发过程中产生的数据进行度量等等。
在进行配置测试时,测试工程师仍然会发现一些普通的缺陷,也就是与配置环境无关的缺陷。因此,判断新发现的问题,需要在不同的配置中重新至此能够发现软件缺陷的步骤,如果软件缺陷不出现了,就可能是配置缺陷;如果在所有的配中都出现问题,就可能是普通缺陷。
需要注意的是,配置问题可以在一大类配置中出现,例如,拨号程序可能在所有的外置Modem中都存在问题,而内置的Modem不会有任何问题。
测试经验越多,测试能力越高。所以我的职业发展是需要时间积累的,一步步向着高级测试工程师奔去。而且我也有初步的职业规划,前3年积累测试经验,按如何做好测试工程师的要点去要求自己,不断更新自己改正自己,做好测试任务。
这个问题是国内测试工程师经常遇到的问题,根源就是国内软件开发文档管理不规范,对变更的管理方法就更不合理了。实际上没有任何文档的时候,测试人员是能够进行黑盒测试的,这种测试方式我们可以称之为探索测试,具体做法就是测试工程师根据自己的专业技能、领域知识等不断地深入了解测试对象、理解软件功能,进而发现缺陷。
在这种做法的基础上,把软件当成了产品说明书,测试过程中要和开发人员不断的进行交流。尤其在做项目的时候,进度压力比较大,可以作为加急测试方案。最大的风险是不知道有些特性是否被遗漏。
## 23、在搜索引擎中输入汉字就可以解析到对应的域名,请问如何使用LoadRunner进行测试 。
建立测试计划,确定测试标准和测试范围,设计典型场景的测试用例,都改常用的业务流程和不常用的业务流程等。根据测试用例,开发自动化测试脚本和场景。
(1)明确测试的目标,增强测试计划的实用性
(2)坚持“5W”规则,明确内容与过程
(3)采用评审和更新机制,保证测试计划满足实际需求
(4)分别创建测试计划与测试详细规格、测试用例
## 25、对于功能测试来说,测试最主要的方法还是等价类,边界值的测试方法。
首先,查找需求说明、网站设计等相关文档,分析测试需求;
然后,指定测试计划,确定测试范围和测试策略,一般包括以下各部分,功能性测试、界面测试、性能测试、数据库测试、安全性测试和兼容性测试。
简介自己在测试行业的时间,期间遇到的问题,解决方式,有遇到的隐藏bug最好,当然也有你在这行接触过的所有项目,主要是近期这个项目
能否满足用户的需求,用户的反馈是否良好
项目在开发过程中要用相应的配置管理工具对配置项(包括各个阶段的产物)进行变更控制,配置管理的使用取决于项目规模和复杂性及风险的水平。软件的规模越大,配置管理就越显得重要。
还有在配置管理中,有一个很重要的概念,那就是基线,是在一定阶段各个配置项的组合,一个基线就提供了一个正式的标准,随后的工作便基于此标准,并只有经过授权后才能变更这个歌标准。配置管理工具主要有CC、VSS、CVS、SVN等。
一般来说分为5个阶段:单元测试、集成测试、确认测试、系统测试、验收测试
(1)白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果;
(2)黑盒法测试用例设计的关键同样也是以较少的用例覆盖模块输出与输入接口。不可能做到完全测试,以最少的用例在合理的时间内发现最多的问题。
功能性:适应性、准确性、互操作性、依从性、安全性
可靠性:成熟型、容错性、易恢复性
可使用性:易理解性、易学习性、易操作性
效率:时间特性、资源特性
可维护性:易分析性、易变更性、稳定性、易测试性
可移植性:适应性、易安装性、遵循性、易替换性
“杀虫剂怪事”一词由BorisBeizer在其编著的《软件测试技术》第二版中提出,用于描述测试人员对统一测试对象进行的测试次数越多,发现的缺陷就会越来越少的现象,就像老用一种农药,害虫就会有免疫力,农药发挥不了效力。这种现象的根本原因就是测试人员对测试软件过于熟悉,形成思维定势。
为了克服这种现象,测试人员需要不断编写新的测试程序或者测试用例,对程序不同部分进行测试,已发现更多的缺陷。也可以引用新人来测试软件,刚刚进来的新手往往能发现一些意想不到的问题。
(1)尽可能早的找出系统中的Bug
(2)避免软件开发过程中缺陷的出现
(3)衡量软件的品质,保证系统的质量
(4)关注用户的需求,并保证系统符合用户需求
总目标:确保软件的质量
软件测试人员的职责是尽可能早的找出软件缺陷,确保得以修复。而质量保证人员(QA)主要的职责是创建或者制定标准和方法,提高促进软件测试开发能力和减少软件缺陷。测试人员的主要工作是测试,质量保证人员日常工作重要内容是检查与评审,测试工作也是测试保证人员的工作对象。软件测试和质量是相辅相成的关系,都是为了提高软件质量而工作。
测试的目的是找出软件产品中的错误,是软件尽可能的符合用户的要求。当然软件测试是不可能找出全部错误的
表面上看这体现了管理的效率和灵活性,但实际上也体现了管理者对测试的轻视。测试和测试的人有很大关系。
测试工作人员应该是勤奋并富有耐心,善于学习、思考和发现问题,细心有条理,总结问题,如果具备这样的优点,做其它工作同样也会很出色,因此这里还有一个要求,就是要喜欢测试这项工作。如果他是专职的,那么肯定更有经验和信心。
加班的话我没有太多意见,但是我还是觉得如果能够合理安排时间的话,不会有太多时候加班的
通常在产品相对比较稳定,主要功能开发完成,功能测试后期的时候,开展性能测试。
(1)测试测试(2)创建虚拟用户脚本(3)创建运行环境(4)运行测试脚本(5)监视场景(6)分析测试的结果
以上,最好是结合一个案例,根据以上流程来介绍
性能测试包含负载测试、压力测试、大数据量测试、疲劳强度测试等。
负载测试是通过逐步增加系统负载,测试系统性能的变化,并最终确定在满足性能指标的情况下,系统所能承受的最大负载量的测试,例如,访问一个页面的响应时间规定不超过1秒,负载测试就是测试在响应时间为1秒时,系统所能承受的最大并发访问用户的数量。
性能测试:指在一定的约束条件下(指定的软件、硬件、网络环境等),确定系统所能承受的最大负载压力。
需求分析+需求变更的维护工作;根据需求,得出测试需求;设计测试方案,评审测试方案;方案评审通过后,设计测试用例,再对测试用例进行评审。
性能测试例子:公司开发了一个小型项目管理系统,上线前需要做负载、压力、大数据量、强度测试等。
负载测试:逐步加压,从而得到“响应时间不超过10秒”,“服务器平均CPU利用率低于85%”等指标阈值。
压力测试:逐步加压,从而使“响应时间超过10秒”,“服务器平均CPU利用率高于90%”等指标来确定系统能承受的最大负载量。
(1)功能:需求管理;定义测试范围;定义需求树;描述需求树的功能点
(2)测试计划:定义测试目标和测试策略;分解应用程序,建立测试计划树;确定每个功能点的测试方法;将每个功能点连接到需求上,使测试计划覆盖全部的测试需求;描述手工测试的测试步骤;指明需要进行自动测试的功能点
测试执行:定义测试合集;为每个测试人员制定测试任务和测试日程安排;运行自动测试
测试跟踪:记录缺陷;查看新增缺陷,并确定哪些是需要修正的;回归测试;分析缺陷统计表,分析应用程序的开发质量
集合点:在性能测试过程中,需要模拟大量用户在同一时刻,访问系统并同时操作某一任务,可以通过配置集合点来实现,多个用户同时进行某操作
意义:集合点可以在服务器上创建密集的用户负载,使LoadRunner能够测试服务器在负载状态下的性能。
设置集合点函数:lr_rendezvous(“Meeting”);//Meeting是集合点名称
扇入:被调次数 扇出:调其它模数项目
(1)Action的作用:用Action可以对步骤集进行分组;步骤重组,然后被整体调用;拥有自己的sheet;组合有相同需求的步骤,整体操作;具有独立的对象仓库
(2)Action的种类:可复用Action;不可复用Action;外部Action
49、解释一下函数及他们的不同之处。
*lr_debug-message:发送调试信息到输出窗口或业务监控日志文件中
*lr_output_message:发送日志信息到输出窗口或业务监控日志文件中
*lr_error_message:发送错误信息到输出窗口或业务监控日志文件中
*lrd_stmt:赋予一个SQL语句用于处理
*lrd_fetch:获取结果集中的下一行数据
界面不稳定;根据需要配置它的不同的部分,过程很繁琐。
流程控制上,安全性不好界定,很容易对他人的Bug进行误操作;没有综合的评分指标,不好确认修复的优先级别。
桩模块:被测试模块调用模块。驱动模块:调用被测模块
RBI方法
重点测试“吞吐量”指标,因为RBI认定80%的系统性能瓶颈由吞吐量造成
按照网络、硬件、数据库、应用服务器、代码的顺序自上而下分析性能
工具:IBM、HP、OpenSource工具都支持。
需使用分析模块、根据Weblogic、Oracle区别有专门的工具实现RBI
就是Bugzilla的状态转换图
用户动作设计;场景设计;测试数据分析
需求和设计文档的理解程度,对系统的熟悉程度
客户端每秒从服务器接收到的数据,或系统服务器每秒能处理通过的交易数。一般随着虚拟用户数的增加,吞吐量也增加,说明网络宽带比较充足,反之,随着虚拟用户数的增加,吞吐量比较平稳,呈直线状态,则说明网络宽带成为瓶颈,限制了数据传输。
(1)在查看需求文档,从中提取性能测试需求,与用户交流,了解实际使用情况。
(2)结合业务信息设计操作场景总结出需测试的性能关键指标。执行测试用例后根据提取关键性指标来分析是否满足性能需求
(1)检查系统是否有中毒的特征;(2)检查软件/硬件的配置是否符合软件的推荐指标(3)确认当前的系统是否独立,即没有对外提供什么消耗CPU资源的服务(4)如果是C/S或者B/S结构的软件,需要检查是不是因为与服务器的连接有问题,或者访问有问题造成的(5)在系统没有任何负载的情况下,查看性能监视器,确认应用程序对CPU/内存的访问情况。
负载测试计划多少用户数量、使用什么类型的机器、以及在什么环境下进行。主要基于两个重要的文档,任务分布图和事务信息,任务分布图告诉我们在负载时间段内,某一个事务使用的用户数,高峰使用率及低峰使用率均来自该文档;事务信息告诉我们事务名及优先级,在设计场景是可以参考。
常见的方法有两种:第一种是临时让开发人员去掉验证码。第二种是让开发人员在后台预设一个固定的验证码,性能脚本中每一次都使用这个固定的验证码。
面向目标的场景设置和手动设置
(1)并发:在同一时间点,支持多个不同的操作。(2)LordRunner中提供IP伪装,集合点,配置虚拟用户的设计,以及在多台电脑上设置,可以比较好的模拟真实的并发。(3)集合点,即多个用户在某个时刻,某个特定的环境下同时进行虚拟用户的操作的。集合点失败,则集合点的操作就会取消,测试就不能进行。
公司中常用的工具有LoadRunner、Jmeter、Seagull等。
其中LR是商用收费软件,费用比较高,很多小公司很难承受。LR功能强大,支持的协议广泛,拥有强大的录制功能。
Jmeter是开源免费项目,互联网公司用的较多,支持二次开发。支持添加空间进行扩展,目前在企业中应用广泛。
Seagull,在通讯领域中协议测试用的较多,是一款免费的工具,广泛用于Sip协议、Http协议、Diameter协议的系统的性能测试。
think_time是思考时间,用户在各步骤之间停下来进行思考的时间,由于用户基于其经验水平和目标而与应用程序进行交互操作,因此技术水平更高的用户工作起来可能会比新用户要快。
通过启用思考时间,可以使Vuser在负载测试期间更准确的模拟其对应的真实世界用户。
Vuser_end中一般包含退出的过程,比如退出系统,主要在脚本执行完成或停止时运行,在设置了迭代次数时,Vuser_end和Vuser_int均只执行了一次。
覆盖图:合并两个图的内容,使用同一个x轴,合并图左y轴显示当前图的值,合并图右y轴显示被合并图的值。
关联图:当前活动图的y轴变为合并图的x轴,被合并图的y轴变成合并图的y轴。
~~
~~
使用Virtual User Generator来录制测试脚本
LoadRunner的Controller组件
*标准日志:脚本执行过程中,将函数集及信息发送到日志文件中
*扩展日志:可以将详细的脚本执行信息输出到日志文件中,可以选择三种扩展日志信息:(1)参数替换:脚本 运行过程中,可以将参数及当前参数值输出到日志文件中(2)服务器返回的数据:将服务器返回给客户端的数据输出到日志文件中(3)高级跟踪:所有的虚拟用户信息和函数调用输出到日志文件中
答案1:坚持从用户,从需求角度出发,在测试产品运行是否正常时也要评估是否满足客户需求。
答案2:*以业务需求为测试导向,站在用户分析角度分析问题和设计测试用例及计划
*强烈的责任心和一定的项目测试的规划管理能力,能对项目测试工作的进度有一定的理解和推进,不断提升测试效率。
*技术和业务需求是项目测试工作要求的一体两面,因此要不断的在项目中学习了解和应用项目中使用的技术,即加深对项目的理解,又能提升自己的技术水平。
答案3:*技术过关
*沟通与协调能力
*对需求与业务熟悉
*了解测试的基本知识,参与相关培训
答案4:除了测试技术要过关以外,重要的还是沟通协调能力,因为测试过程要与产品,开发,UI多方沟通
答案5:*分析需求业务逻辑,了解技术实现逻辑
*安排好测试计划,根据计划合理的分配完成工作
*测试用例要覆盖全,才不会漏测
*技术可以帮助测试,推进项目进度(稳定性,性能)
*沟通能力
*用户场景测试
答案6:*责任心,对自己测试过的版本负责,达到测试该版本的目的,尽可能早的暴露问题,对项目进度大有帮助
*细心,对测试过程中出现的细微异常敏感,追根究底,避免错过bug,并且尝试复现问题,帮助研发更好的定位问题;
*良好的沟通能力,提高效率;
*明确的测试计划,善于总结
*不耻下问(对于不解的点一定要问,别怕说错,以免漏写漏查)
答案1:测试需求澄清;制定测试计划,任务分工明确;制定模块测试方案;编写测试用例;测试用例评审;测试环境测试数据准备;执行测试用例;缺陷提交跟踪闭环,交付功能稳定时在此阶段可进行性能、安全、易用性、兼容性等测试;输出测试报告,用户操作手册;产品或实施团队验收、用户验收;上线交付
答案2:获取测试需求;编写测试计划;指定测试方案;设计测试用例;执行测试;提交缺陷报告;测试分析与评审;提交测试总结
答案3:*需求分析阶段:阅读需求,理解需求,分析需求点,参与需求评审会议。
*测试计划阶段:主要任务就是编写测试计划,参考软件需求规格说明书,项目总体计划,内容包括测试 范围,进度安排,人力物力分配,整体测试策略的制定。
*编写测试用例:适当的了解设计,搭建测试用例框架,根据需求和设计编写测试用例。
*测试执行阶段:搭建环境准备数据,执行冒烟测试(预测试)然后进入正式测试(系统测试、回归测试、交叉测试、自由测试),bug管理直到测试结束。
*输出测试报告:输出测试报告,确认是否可以上线。
答案4:和产品,项目经理,开发等角色一起讨论需求—>明确需求,提炼出测试功能点—>根据功能点,编写成各个具体的测试用例—>测试用例评审—>根据当前阶段的测试重点,测试策略,制定测试计划—>准备测试环境—>执行测试—>提交bug,并追踪直到形成闭环—>发出测试报告,内容包括bug数量,级别等信息。
A、等价类划分法 B、边界值分析 C、错误推测法 D、因果图
黑盒测试技术一般指设计测试案例技术,测试阶段,测试案例设计方面有常见的等价类,边界值,因果图,错误猜想,正交试验,容错,易用性,兼容性测试等;
工具有qc,数据库,ftp,fiddler,jira,jemeter等;测试阶段单元测试,集成测试,系统测试,回归测试,验收测试,上线后的试运行
答案1:使用fiddler就可以满足,要求APP运行环境与PC端在同一局域网内,PC端使用fiddler挂代理,APP运行的手机或模拟器设置代理和端口即可实现监听!
答案2:loadrunner,jmeter,postman,最简单的就是浏览器F12,如果没上面的抓包工具,就用F12吧,我在客户现场部署环境时,加上环境限制,有时没时间安装,就直接用F12,建议尝试。
答案3:burpsuit可以改参数请求
答案4:Charles,用手机跟电脑连接同一个WiFi,然后下载手机证书http协议,修改dns让手机走你电脑的网络就好了,具体的抓包自己在软件里面定义参数。
(1)测试人员尽早介入,彻底理解清楚需求,这个是写好测试用例的基础
(2)如果以前有类似的需求,可以参考类似需求的测试用例,然后还需要看类似需求的bug情况
(3)清除输入、输出的各种可能性,以及各种输入的之间的关联关系,理解清楚需求的执行逻辑,通过等价类、边界值、判定表等方法找出大部分用例
(4)找到需求相关的一些特性,补充测试用例
(5)根据自己的经验分析遗漏的测试场景
(6)多总结类似功能点的测试点,才能够写出质量越来越高的测试用例
(7)书写格式一定要清晰
主要看你解决问能力和逻辑分析能力,要知道你跟他说的bug一点高讲清楚你是怎么发现的,如何确定问题,如何解决问题,解决方案有几种,后续相关功能兼容,数据处理逻辑,你讲清楚就没问题
(1)输入条件之间的关系(组合、约束)(2)输入与输出的关系(3)输出条件的关系
基于http协议。通过工具或者代码模拟http请求的发送与接收
答案1:手机代理连接到电脑上,电脑上用抓包工具
答案2:很多应用都是用的http,可以使用bp进行代理,并在手机中设置代理IP和port,进行抓包
答案3:多种方法可以实现,由易到难排序
(1)把应用域名由https改成https请求内容(需要服务端支持http)
(2)配置抓包工具不解析https请求内容(charles里看不到请求内容,但手机网络走的PC网卡)
(3)应用源码内配置抓包证书信任
A、阅读产品规格书 B、阅读已有的bug列表 C、书写思维导图 D、阅读已有的测试用例
A、帮助测试寻找问题 B、协助问题的诊断 C、提高设计质量 D、节省测试时间
A、并发用户数 B、内存泄漏 C、系统安全性 D、功能错误
A、集成测试B、回归测试C、确认测试D、单元测试
A、正式验收测试B、白盒测试C、alpha测试D、beta测试
A、基本路径B、边界值分析C、循环覆盖D、逻辑覆盖
A、单元测试B、集成测试C、黑盒测试D、白盒测试
87、测试工程师小刘在对某软件项目进行疲劳强度测试过程中,最先发现以下哪些问题?
A、并发用户数B、内存泄漏C、系统安全性D、功能错误
A、ctrl+C B、ctrl+x C、Alt F2 kill 进程ID D、ctrl +d
系统架构方面:(1)web项目,一般都是b/s架构,基于浏览器的。
(2)app项目,则是c/s的,必须要有客户端,用户需要安装客户端
(3)web测试只要更新了服务器端,客户端就会同步更新。app项目则需要客户端和服务器端都
更新
性能方面:(1)web页面主要会关注响应时间。
(2)app还需要关心流量、电量、CPU、GPU、Memory这些。
它们服务端的性能没有区别,都是一台服务器。
A、自动化测试不一定适合所有的测试 B、自动化测试可以大幅度降低工作量
C、自动化测试不一定比人工测试更能保障系统的可靠性 D、自动化测试不能完全覆盖到所有的测试类型
A、短信内容长度为0 B、短信内容长度为1 C、短信内容长度为69 D、短信内容长度为70
A、编码规则检查 B、程序结构分析C、程序复杂度分析D、内存泄漏
A、选2至4门课 B、选2门课 C、只选1门课 D、未选课
(1)特殊值处理不当导致程序异常退出或者崩溃。
(2)类型边界溢出,导致数据独处和写入不一致
(3)取值边界外未返回正确的错误信息
(4)权限未处理,可以访问其他用户的信息
(5)逻辑校验不完整,可以利用漏洞获取非正当利益
(6)状态处理不当,导致逻辑出现错误
(7)数组类型item个数为0或者itme重复时程序异常退出
A、证明程序正确性 B、发现了程序错误C、改正了程序错误D、未发现程序错误
A、非渐增组装测试B、确认测试C、单元测试D、测试计划
97、ctrl+c可以终止死循环
功能测试:按下开机键,屏幕是否亮起。
性能测试:按下开机键,屏幕能否在规定的时间内亮起。
压力测试:连续多次按下开机键,观察屏幕是否能一直亮起,到多久时间失灵。
健壮性测试:给定一个中了病毒的手机或者是淘汰许久的老机子,按下开机键,观察屏幕是否能一直亮起,到多久时间失灵。
可靠性测试:连续按下开机键有限次数,比如1万次,记录屏幕未亮起的次数。
可用性测试:开机键按下费不费力,开机键的形状设计是否贴合手指,开机键的位置设计是否方便。
A、阅读产品规格书 B、阅读已有的bug列表 C、书写思维导图D、阅读已有的测试用例
A、驱动代码B、Stub代码 C、Mock 代码 D、GUI测试手段
A、仔细阅读,跟随每个步骤,检查每个图形,尝试每个示例B、检查文档的编写是否满足文档编写的目的
C、内容是否齐全,正确,完善D、标记是否正确
测试人员的核心竞争力在于提早发现问题,并能够发现别人无法发现的问题。
(1)早发现问题:问题发现的越早,解决的成本越低。如果一个需求在还未实现的时候就能发现需求的漏洞,那么这种问题的价值是最高的。
(2)发现别人无法实现的问题:所有人都能发现的问题,你发现了,那就证明你是可以被替代的。别人发现不了,而你可以发现,那么你就是无法替代的。
需求测试—>概要设计测试—>详细设计测试—>单元测试—>集成测试—>系统测试—>验收测试
(1)软件测试基础理论知识,如黑盒测试、白盒测试等;
(2)编程语言基础,如C/C++、java、python等
(3)自动化测试工具,如Selenium、Appium、Robotium等;
(4)计算机基础知识,如数据库、Linux、计算机网络等
(5)测试框架,如JUnit等
A、等值分析测试B、边界值分析测试C、错误推测法D、逻辑覆盖测试
A、SOW B、HLD C、LLD D、UTC
(1)计划和用例编制的先后顺序:从V模型来讲,在需求阶段就要制定系统测试计划和用例,HLD的时候做集成测试计划和用例,有些公司的具体实践不一样,但是顺序肯定是先做系统测试计划用例,再做集成。
(2)用例的粒度:系统测试用例相对很接近用户接受测试用例,集成测试用例比系统测试用例更详细,而且对于接口部分要重点写,毕竟要集成各个模块或者子系统。
(3)执行测试的顺序:先执行集成测试,待集成测试出的问题修复之后,再做系统测试。
108、怎么测试网络协议?
(1)一致性测试:检测协议实现本身与协议规范的符合程度。
(2)互操作性测试:基于某一协议检测不同协议实现间互操作互通信的能力。
(3)性能测试:检测协议实现的性能指标,比如数据传输速度,连接时间,执行速度,吞吐量,并发度。
(4)健壮性测试:检测协议是现在各种恶劣环境下运行的能力,比如注入干扰报文,通信故障,信道被切断。
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等类划分法的补充,这种情况下,其测试用例来自等价类的边界。
常见的边界值:(1)对16—bit的整数而言32767和—32768是边界
(2)屏幕上光标在最左上、最右下位置
(3)报表的第一行和最后一行
(4)数组元素的第一个和最后一个
(5)循环的第0次、第1次和倒数第2次、最后一个
测试最主要的工作,其实就是在项目上的痛点上就能体现出来。如下:
(1)保证需求传递一致性(2)保证产品于需求的一致性(3)保证数据一致性(4)保证测试效率高效性
,是指对软件中的最小可测单元进行检查和验证。对于单元测试中单元的含义,一般来说,要根据实际情况去判定其具体含义,如C语言中单元指一个函数,Java里单元只一个类,图形化的软件中可以指一个窗口或一个菜单等。总的来说,单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动,软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。
可行。单元测试可以有效地测试某个程序模块的行为,是未来重构代码的信心保证。事前可以保证质量,事后可以快速复现问题,并在修改代码后做回归自测。可行性考虑的是要用一些可行的方法做到关键的代码可测试,如通过边界条件、等价类划分、错误、因果,设计测试用例要覆盖常用的输入组合、边界条件和异常。