1测试理论1.1测试基础1.1.1什么是软件测试为了发现程序中的错误而执行程序的过程1.1.2软件测试的目的首先测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的分布特征可以帮助项目管理者发现当前所采用的软件过程的缺陷以便改进。同时这种分析也能帮助我们设计出有针对性地检测方法改善测试的有效性。其次没有发现错误的测试也是有价值的完整的测试是评定测试质量的一种方法。详细而严谨的可靠性增长模型可以证明这一点。测试的目的是按照用户所需软件的质量检查开发软件过程出现的bug,使得开发人员及时修改可以避免在开发结束的时候发现软件存在质量问题避免公司不必要的损失。赢得用户对公司产品的认可。测试的目的是以最少人力、物力和时间找出软件中潜在各种错误和缺陷通过修正种错误和缺陷提高软件质量回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。测试的附带收获是它能够证明软件的功能和性能与需求说明相符合。实施测试收集到的测试结果数据为可靠性分析提供了依据。测试不能表明软件中不存在错误它只能说明软件中存在错误。1.1.3软件测试的目标发现尽可能多的错误测试是一个为了寻找错误而运行程序的过程。一个好的测试案例是指尽可能找到迄今为止尚未发现的错误的用例。一个成功的测试是指揭示了迄今为止尚未发现的错误的测试。1.1.4软件测试的原则1)应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。2)测试用例应由测试输入数据和对应的预期输出结果这两部分组成。3)程序员应避免检查自己的程序。4)在设计测试用例时应包括合理的输入条件和不合理的输入条件。5)软件测试的原则旨在确保测试活动的有效性、全面性和及时性以提高软件质量降低风险。遵循这些原则有助于提高测试效率减少软件缺陷提升用户满意度。6)充分注意测试中的群集现象。经验表明测试后程序中残存的错误数目与该程序中已发现的错误数目成正比。7)严格执行测试计划排除测试的随意性。8)应当对每一个测试结果做全面检查。9)妥善保存测试计划测试用例出错统计和最终分析报告为维护提供方便。1.1.5测试的工作流程测试的功能点都是来自于需求文档从产品的需求文档中提炼出来的等产品完成需求文档并完成需求文档的评审会就开始测试用例的编写工作一般项目半个月迭代一次的话设计测试的时间一般是3天就要完成我们设计测试用例的时间还是比较充足案例设计一般都会和产品的开发并行。在案例完成编写之后大家会开会一起来评审你的案例。在评审的过程中大家会提出一些问题会后要把这些遗漏的测试点补充上但是这时并不是大功告成哦。痛苦的案例执行才刚刚开始哈哈哈在这个里我为什么用痛苦来形容呢大家也知道开发一般只是把功能开发好自己可能都没有自测过就发给测试这时候测试发现和自己想象中的APP差距太大有的时候会发现一眼都能看到的问题为什么还要等着测试来发现小编遇到这样的问题也表示无奈。但是只能硬着头皮测下去。在测试的过程中每天在下班的时候还需要发测试日报告诉项目中的成员现在案例执行的情况当然了测试完成之后发测试报告也是必须的了算是对这次项目跌代测试完成的一个交代。1.1.6测试工程师的职责测试经理1、制定测试计划。2、确保测试过程正常进行。测试工程师1、编写测试用例2、搭建测试环境3、执行测试1.1.7软件都有多少种分类根据功能的不同电脑软件可以粗略地分成四个层次最贴近电脑硬件的是一些小巧的软件。它们实现一些最基本的功能通常“固化”在只读存储器芯片中因此称为固件。系统软件包括操作系统和编译器软件等。系统软件和硬件一起提供一个“平台”。它们管理和优化电脑硬件资源的使用。支持软件。包括图形用户界面、软件开发工具、软件评测工具、数据库管理系统、中间件等。应用软件种类最多包括办公软件、电子商务软件、通信软件、行业软件游戏软件等等。1.1.8软件的分类1.1.9测试的主要方面A、功能测试a、链接测试b、表单测试c、Cookies测试d、设计语言测试e、数据库测试B、性能测试a、连接速度测试b、负载测试c、压力测试C、接口测试a、服务器接口b、外部接口c、错误处理D、可用性测试:a、导航测试b、图形测试c、内容测试d、整体界面测试E、兼容性测试a、平台测试b、浏览器测试c、视频测试d、Modem/连接速率测试f、打印机测试g、组合测试F、安全测试a、目录设置b、登录c、Sessiond、日志文件e、加密f、安全漏洞G、代码合法性测试a、程序代码合法性检查b、显示代码合法性检查H、文档测试1.1.10软件测试的对象软件测试并不等于程序测试。软件测试应贯穿于软件定义与开发的整个期间。需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序都应成为软件测试的对象1.1.11什么是“测试案例”测试案例是一份文档它描述了一个输入、反应、或者是与其相应的预期的响应以便来判断应用软件的工作是否正常。测试案例应当包括测试标识、测试案例的名称、目标、测试条件/设置、输入数据要求、步骤、以及预期的结果。注开发一个应用软件的测试案例的过程需要全面、深入地考虑该软件的操作所以有助于发现在其需求或设计里面的问题。因此如果有可能在开发周期中应当尽早准备测试案例。1.1.12怎么编写案例案例的编写与测试阶段的定义有很大的关系。系统测试和unit测试的案例可能不同。总体而言测试案例根据系统的需求而定。1.1.13软件测试的两种方法黑盒测试和白盒测试黑盒这种方法是把测试对象看做一个黑盒子测试人员完全不考虑程序内部的逻辑结构和内部特性只依据程序的需求规格说明书检查程序的功能是否符合它的功能说明。黑盒测试又叫做功能测试或数据驱动测试。白盒此方法把测试对象看做一个透明的盒子它允许测试人员利用程序内部的逻辑结构及有关信息设计或选择测试用例对程序所有逻辑路径进行测试。通过在不同点检查程序的状态确定实际的状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。1.1.14测试结束的标准是什么1.用例全部执行。2.覆盖率达到标准。3.缺陷率达到标准。4.其他指标达到质量标准1.1.15软件的生命周期软件生命周期是指一个计算机软件从功能确定、设计到开发成功投入使用并在使用中不断地修改、增补和完善直到停止该软件的使用的全过程从酝酿到废弃的过程1.1.16什么是软件的生命周期生命周期从收到应用软件开始算起到该软件不再使用为止。它有如下各方面的内容初始构思、需求分析、功能设计、内部设计、文档计划、测试计划、文档准备、集成、测试、维护、升级、再测试、逐步淘汰(phase-out)、等等。1.1.17软件测试按过程分为三个步骤单元测试单元测试又称模块测试是针对软件设计的最小单位─程序模块进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。集成测试在运行可能是不完整的应用中保证软件单元被结合后能正常操作的测试执行的阶段系统测试当应用作为整体运行时的测试执行阶段1.1.18面向对象的设计如何影响测试好的面向对象的工程设计使得从代码追溯内部设计、再到功能测试最后追溯到需求成为一件容易的事。因为它对黑盒测试的影响很少(不需要了解应用软件的内部设计)而白盒测试只需针对该应用软件的对象。如果该应用软件设计得好就可简化测试设计。1.1.19软件带来错误的原因很多。主要的原因有哪些1)交流不够、交流上有误解或者根本不进行交流2)软件复杂性3)程序设计错误4)需求变化5)时间压力6)代码文档贫乏7)软件开发工具1.1.20做好软件测试的一些关键点1.测试人员必须经过测试基础知识和理论的相关培训。2.测试人员必须熟悉系统功能和业务。3.测试必须事先要有计划而且测试方案要和整个项目计划协调好4.必须事先编写测试用例测试执行阶段必须根据测试用例进行5.易用性功能分支边界性能等功能性和非功能性需要都要进行测试6.对于复杂的流程一定要进行流程分支组合条件分析再进行等价类划分准备相关测试数据7.测试设计的一个重要内容是要准备好具体的测试数据清楚这个测试数据是测哪个场景或分支的8.个人任务平均每三个测试用例至少应该发现一个BUG否则只能说明测试用例质量不好9.除了每日构建的冒烟测试可以考虑测试自动化外其它暂时都不要考虑去进行自动化。1.1.21软件测试的步骤是什么1)测试过程按4个步骤进行即单元测试UnitTesting、集成测试IntegratedTesting、确认测试ValidationTesting和系统测试SystemTesting及发版测试。2)开始是单元测试集中对用源代码实现的每一个程序单元进行测试检查各个程序模块是否正确地实现了规定的功能。3)集成测试把已测试过的模块组装起来主要对与设计相关的软件体系结构的构造进行测试。4)确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求以及软件配置是否完全、正确。1.1.22如何录制测试脚本1)新建一个脚本Web/HTML协议2)点击录制按钮在弹出的对话框的URL中输入”about:blank”。3)在打开的浏览器中进行正常操作流程后结束录制。4)调试脚本并保存。可能要注意到字符集的关联。5)设置测试场景6)针对性能设置测试场景主要判断在正常情况下系统的平均事务响应时间是否达标7)针对压力负载设置测试场景主要判断在长时间处于满负荷或者超出系统承载能力的条件下系统是否会崩溃1.1.23应该考虑进行如何测试的测试方法黑盒测试(Blackboxtesting)──不考虑内部设计和代码根据需求和功能进行测试。白盒测试(Whiteboxtesting)──根据应用软件的代码的内部逻辑按照代码的语句、分支、路径和条件进行测试。功能测试functionaltesting——对一个应用软件的功能模块进行黑盒测试。这种测试应当由测试人员进行。但这并不意味着程序员在推出软件之前不进行代码检查。这一原则适用于所有的测试阶段。系统测试──针对全部需求说明进行黑盒测试包括系统中所有的部件。回归测试(regressiontesting)──每当软件经过了整理、修改、或者其环境发生变化都重复进行测试。很难说需要进行多少次回归测试特别是是到了开发周期的最后阶段。进行此种测试特别适于使用自动测试工具。负荷试验(loadtesting)──在大负荷条件下对应用软件进行测试。例如测试一个网站在不同负荷情况下的状况以确定在什么情况下系统响应速度下降或是出现故障。压力测试(stresstesting)──经常可以与“负荷测试”或“性能测试”相互代替。这种测试是用来检查系统在下列条件下的情况在非正常的巨大负荷下、某些动作和输入大量重复、输入大数、对数据库进行非常复杂的查询等等。性能测试(performancetesting)──经常可以与“压力测试”或“负荷测试”相互代替。理想的“性能测试”(也包括其他任何类型的测试)都应在质量保障和测试计划的文档终予以规定。可用性测试(usabilitytesting)──是专为“对用户友好”的特性进行测试。这是一种主观的感觉取决于最终用户或顾客。可以进行用户会见、检查、对用户会议录像、或者使用其他技术。程序员和测试人员通常不参加可用性测试。安装/卸载测试(install/uninstalltesting)──对安装/卸载进行测试(包括全部、部分、升级操作)。安全测试(securitytesting)──测试系统在应付非授权的内部/外部访问、故意的损坏时的防护情况。这需要精密复杂的测试技术。兼容性测试(compatabilitytesting)──测试在特殊的硬件/软件/操作系统/网络环境下的软件表现。α测试(alphatesting)──在开发一个应用软件即将完成时所进行的测试。此时还允许有较小的设计修改。通常由最终用户或其他人进行这种测试而不是由程序员和测试人员来进行。β测试(betatesting)──当开发和测试已基本完成需要在正式发行之前最后寻找毛病而进行的测试。通常由最终用户或其他人进行这种测试而不是由程序员和测试人员来进行。1.1.24怎样估计测试工作量效率假设即测试队伍的工作效率。对于功能测试这主要依赖于应用的复杂度窗口的个数每个窗口中的动作数目。对容量测试主要依赖于建立测试所需数据的工作量大小。测试假设为了验证一个测试需求所需测试动作数目。应用的维数应用的复杂度指标。例如要加入一个记录测试需求的维数就是这个记录中域的数目。所处测试周期的阶段有些阶段主要工作都在设计有些阶段主要是测试执行。1.1.25测试设计的问题1)不做测试设计测试过程也是胡乱建立的。2)测试设计不详细不是基于可量度的测试策略例如测试计划覆盖一个集合或者测试需求的一个子集。3)测试过程没有采用最好的技术来检验WindowsC/S结构的测试需求4)测试用例的选择规则5)选择与测试需求的实质部分最相关的测试用例。6)选择的测试用例应该不容易受应用程序的改变的影响。1.1.26当测试过程发生错误时有哪几种解决办法1)跳转到别的测试过程2)调用一个能够清除错误的过程3)退出过程启动另一个4)退出过程和应用程序重新启动启动Windows在失败的地方重新开始测试1.1.27测试执行的问题测试执行的问题1)自动化测试没有有效的利用使得手工测试太多。2)测试结果的捕获没有系统性而且没有查看或调查3)缺陷报告必须用手工加入缺陷跟踪系统错误分类1、测试用例失败正常错误2、脚本命令失败当测试过程不能执行录制过程中的某个功能时会产生这种错误如鼠标单击按钮或选择菜单项等。它也能指示是缺陷还是测试过程的设计问题。3、致命错误导致测试停止这种情况最好重起Windows。具体步骤1)建立测试系统2)准备测试过程3)运行初始化过程4)执行测试5)从终止的测试恢复6)验证预期结果7)调查突发结果8)记录缺陷日记1.1.28测试评估的目标1)量化测试进程2)生成缺陷和测试覆盖率的总结报告1.测试评估的问题3)没有把测试覆盖率作为报告测试进程的根据使得不知测试是否结束4)没有做缺陷评估缺陷评估是量度软件可行性的重要指标5)不使用专门的软件工具进行数据输入任务和相应的评估活动使得这些任务变得繁重累人。1.1.29如何提高测试提高测试需要从几个方面着手其实只是自己的一些感觉不一定就需要按部就班需要找自己适合的点。制定完备的测试计划清楚的认识测试计划测试计划是一个文档能够保证整个研发过程中顺利执行的一个指导性文档它描述了几个方面的问题。1)描述了项目的的2)描述了项目的开发周期3)描述了在测试中遇到的技术4)描述了测试案例的设计周期5)描述测试案例的执行周期6)描述了测试过程中用到的工具或者技术7)描述了测试过程中用到的资源情况8)描述了测试过程中可能遇到的风险以及规避方法9提高案例设计水平1.1.30C/S模式的优点和缺点C/S模式的优点1)由于客户端实现与服务器的直接相连没有中间环节因此响应速度快。2)操作界面漂亮、形式多样可以充分满足客户自身的个性化要求。3)C/S结构的管理信息系统具有较强的事务处理能力能实现复杂的业务流程。C/S模式的缺点1)需要专门的客户端安装程序分布功能弱针对点多面广且不具备网络条件的用户群体不能够实现快速部署安装和配置。2)兼容性差对于不同的开发工具具有较大的局限性。若采用不同工具需要重新改写程序。3)开发成本较高需要具有一定专业水准的技术人员才能完成。1.1.31B/S模式的优点和缺点B/S模式的优点1)具有分布性特点可以随时随地进行查询、浏览等业务处理。2)业务扩展简单方便通过增加网页即可增加服务器功能。3)维护简单方便只需要改变网页即可实现所有用户的同步更新。4)开发简单共享性强。B/S模式的缺点1)个性化特点明显降低无法实现具有个性化的功能要求。2)操作是以鼠标为最基本的操作方式无法满足快速操作的要求。3)页面动态刷新响应速度明显降低。4)无法实现分页显示给数据库访问造成较大的压力。5)功能弱化难以实现传统模式下的特殊功能要求。1.1.32测试结束的标准是什么?1)第一类标准测试超过了预定时间则停止测试。2)第二类标准执行了所有的测试用例但并没有发现故障则停止测试。3)第三类标准使用特定的测试用例设计方案作为判断测试停止的基础。4)第四类标准正面指出停止测试的具体要求即停止测试的标准可定义为查出某一预订数目的故障。5)第五类标准根据单位时间内查出故障的数量决定是否停止测试。1.1.33怎么才能够全面的测试到每一个点测试的全面性主要需要在设计测试计划的时候考虑从测试策略产品需求等等多个角度考虑从而定义全部的测试点1.1.34开发与测试的关系开发和测试是一个有机的整体在产品的发布之前开发和测试是循环进行的测出的缺陷要经开发人员修改后继续测试。在开发的同时测试经理开始编写测试用例测试文档要参考开发文档所以开发和测试是不可分割的少了任何一个都不能开发出产品。从角色方面看像理论和实验的关系开发人员通过自己的想象创造出一套思想之后测试人员再对它进行检验、证伪开发人员再修改的过程从而不断丰富产品。从方法方面看是演绎和归纳的关系一个要掌握大量的技术一个要不断的从实例中学习。因这两方面的不同所以开发和测试看上去做的工作很不一样。开发与测试是相辅相承、密不可分的开发人员开发出新的产品后要通过测试判断产品是否完全满足用户的需求。如果发现缺陷提交给开发人员进行修复然后再转交测试人员进行回归测试直到产品符合需求规格说明。一个符合用户需求的产品是开发和测试共同努力的成果。1.1.35怎么和开发沟通测试和开发沟通大部分都在讨论bug测试说是bug但是开发认为这个不是bug对于测试来说就很头痛了明明是问题但是为什么开发不主动修改呢这时候测试应该去需求文档中找出有关这个功能的描述或者去询问产品经理总之不要正面冲突要拿出证据来说服开发。1.1.36测试过程1)制定系统测试计划2)编写系统测试用例3)执行系统测试用例4)跟踪管理缺陷5)总结测试1.1.37测试出口准则1)所有的缺陷已经解决2)项目规定测试阶段时间结束3)执行完成测试计划中的系统测试内容修正了所发现的错误未修正的错误被项目经理允许留到下一版本4)高级经理和项目经理均同意结束测试5)测试结果经过了专门的评审1.1.38测试完成标准1)系统功能与用户需求说明书一致2)功能性测试用例通过率达到100%3)非功能性测试用例通过率达到95%4)一、二级错误修复率应达到100%。5)三、四级错误修复率应达到80%以上。6)五级错误修复率应达到60%以上。1.1.39测试活动中统计了哪些数据工作量bug数量1.1.40如何选择用户测试的工作产品在用户有需求得到签字确认之后我们选择用户测试的工作产品。我们几乎所有的项目都进行了测试我们是在项目立项公告中得知需要对工作产品进行测试。1.1.41测试环境描述在哪儿测试环境在测试计划里面进行描述测试计划是由测试经理编写我们在测试计划中了解到自己是此次项目组的测试工程师。1.1.42进行测试时产生了哪些文档或记录测试的整个过程有系统测试计划、系统测试用例、系统测试报告、缺陷报告、产品发布说明在执行测试的过程中只有缺陷报告这个还是用在缺陷管理工具中进行的最后在工具中导出缺陷报告1.1.43测试人员需要何时参加需求分析如果条件允许原则上来说是越早介入需求分析越好因为测试人员对需求理解越深刻对测试工作的开展越有利可以尽早的确定测试思路减少与开发人员的交互减少对需求理解上的偏差1.1.44产品测试完以后由谁来发布这个不定开发发布还是技术支持发布都有可能1.1.45软件测试与调试的关系1)测试条件已知规程可定义结果可预知2)测试可以计划过程可控3)测试是检验调试是推理过程4)测试表明程序失败调试表明正确5)测试可不了解设计细节6)测试由非设计人员完成7)测试有理论依据8)测试可自动化1.1.46质量的八大特性是什么各种特性的定义1功能性软件所实现的功能达到它的设计规范和满足用户需求的程度2性能在规定条件下,实现软件功能所需的响应时间和计算机资源(CPU、内存、磁盘空间和数据吞吐量)的使用程度3可靠性在满足一定条件的应用环境中软件能够正常维持其工作的能力在出现一些错误操作时软件可以具有容错性如果软件意外退出重新启动后可以恢复最近的软件数据4安全性为了防止意外或人为的破坏软件应具备的自身保护能力5使用性用户在理解、学习和操作软件的过程中的付出的努力的难易程度6维护性软件在运行维护过程中如果出现了运行故障或者扩展新功能和性能软件系统是否具有可分析性和良好的扩展性重新设计后的软件的稳定性和可测试性7移植性软件从现有运行平台向另一个运行平台过度的适应程度和平台可替换性8重用性整个软件或其中一部分能作为软件包而被再利用的程度1.1.47什么是软件的“质量”高质量的软件是适当的、无错误的能在预算内按时交货满足需求/或期望并且是可维护的。所以质量是一个主观的术语。它取决于谁是客户以及客户对项目计划的影响。对一个软件开发项目来说“客户”的范围很广包括最终用户、客户所接受的测试者、与客户合同有关的官员、客户管理、开发机构的管理者/会计/测试人员/销售人员、未来的软件维护工程师、股票持有者、杂志专栏记者等等。每一类客户对“质量”都有自己的倾向性–比如会计部门判断质量会从其收益来考虑而最终用户则重视友好的用户界面和没有错误。1.1.48软件质量应该从哪些方面来评价可靠性、安全性、性能、易用性、外观、稳定性1.1.49什么是“软件质量保障”软件质量保障涉及到整个软件开发过程包括监视和改善过程、确保任何经过认可的标准和步骤都被遵循、并且保证问题被发现和被处理。从本质上说软件质量保障是“预防”。1.1.50为什么软件会有毛病1.交流错误或者没有进行交流2.软件的复杂性编程错误3.需求变更客户恐怕不明白改变需求的影响也许是知道但依然需要变更──会导致重新设计、重订工程进度表、对其他项目的影响、已完成的工作需要重做或者放弃、对硬件需求的影响等等。如果在项目中出现许多小的改变或一个大的改变在项目各部分中出现已知或未知的相关的问题可能会相互影响并导致出现问题。而且不断地变更也会增加软件的复杂性可能会导致错误的出现。这样就会影响技术人员的积极性。在一些快速变化的商业环境里持续变更需求的影响是致命的。在这种情况下管理者必须知道它的危险性。质量保障和测试工程师必须与此相适应并安排持续的广泛的测试以克服不可避免产生的问题。4.时间压力因为有许多猜测成分软件开发项目的进度很难安排得理想。当最后期限快到的时候压力逐渐增大错误随之产生5.自负心理、代码文档质量差、软件开发工具1.1.51什么是UMLUnifiedModelingLanguage它是一种用于描述构造软件系统以及商业建模的语言。简单的理解就是它可以以一种直观的方式表示出一个系统的各项内容1.1.52什么是CMMCMMCapabilityMaturityModel即“能力成熟度模型”。它是一个分5级的、可以描述结构完善程度的模型用它来说明所交付的软件的效能。1.1.53.比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系黑盒测试把测试对象当成一个黑盒子测试人员完全不考虑逻辑结构和内部特性只依据程式的需求说明书来检查程式的功能是否满足它的功能说明。白盒测试把测试对象当成一个透明的盒子允许测试人员利用程序内部逻辑结构及相关信息设计或选择测试用例对程式所有逻辑路径进行测试。单元测试白盒测试的一种对软件设计中的单元模块进行测试。集成测试在单元测试的基础上对单元模块之间的连接和组装进行测试。系统测试在所有都考虑的情况下对系统进行测试。验收测试第三方进行的确认软件满足需求的测试。1.1.54比较负载测试、压力测试容量测试和强度测试区别负载测试在一定的工作负荷下系统的负荷及响应时间。通过逐步增加系统负载最终确定在满足性能指标的情况下系统能承受的最大负载量的测试。强度测试又称疲劳强度测试在系统稳定运行的情况下能够支持的最大并发用户数持续执行一段时间业务通过综合分析确定系统处理最大工作量强度性能的过程。一定负荷条件下在较长时间跨度内的系统连续运行给系统性能所造成的影响。容量测试容量测试目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值如最大并发用户数、数据库记录数等系统在其极限值状态下没有出现任何软件故障或还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。容量测试的目的是使系统承受超额的数据容量来发现它是否能够正确处理。容量测试是面向数据的并且目的是显示系统可以处理目标内确定的数据容量。压力测试通过逐步增加系统负载最终确定在什么负载条件下系统性能将处于崩溃状态以此获得系统能提供的最大服务级别的测试。1.1.55测试执行过程的三个阶段1初测期测试主要功能和关键的执行路径排除主要障碍。2细测期依据测试计划和测试大纲、测试用例逐一测试大大小小的功能、方方面面的特性、性能、用户界面、兼容性、可用性等等预期可发现大量不同性质、不同严重程度的错误和问题。3回归测试期系统已达到稳定在一轮测试中发现的错误已十分有限复查已知错误的纠正情况确认未引发任何新的错误时终结回归测试。1.1.56什么是验证、评价、预排、检查验证(verification)涉及了回顾和会议以评估文档、计划、代码、需求和说明书。可以通过检查表、调查表、排练、和检查会来进行。评价(validation)则指在检察完成之后的实际测试。术语“IV”和“V”分别代表验证和评价。预排是一个非正式的会议用来进行评估和信息交流。通常不需要或者只需很少一点准备。检查比预排更正式一点通常有3-8个人参加会议包括一个仲裁者(moderator)、读者(可以是作者或者任何评论者)、一个记录员作记录。典型的检查对象是一个文件例如需求说明或者测试计划目的在于发现问题和查找遗漏而不是去对任何东西进行实际的修改。会议的参加者应当有准备应当通读文件大多数的问题会在准备的过程中被发现。检查会的结果应写成书面报告。对检查会进行全面准备是困难而艰苦的工作但它是保证质量最有用的方法。在检查过程中最有经验的雇员的作用就向‘大哥哥’一样他们的技能也许不大显眼但对任何软件开发机构是最重要的这是因为预防错误要比发现错误在费用方面更加有效。1.1.57什么是兼容性测试兼容性测试侧重哪些方面兼容测试主要是检查软件在不同的硬件平台、软件平台上是否可以正常的运行即是通常说的软件的可移植性。兼容的类型如果细分的话有平台的兼容网络兼容数据库兼容以及数据格式的兼容。兼容测试的重点是对兼容环境的分析。通常是在运行软件的环境不是很确定的情况下才需要做兼容。根据软件运行的需要或者根据需求文档一般都能够得出用户会在什么环境下使用该软件把这些环境整理成表单就得出做兼容测试的兼容环境了。兼容和配置测试的区别在于做配置测试通常不是CleanOS下做测试而兼容测试多是在CleanOS的环境下做的。1.1.58我现在有个程序发现在Windows上运行得很慢怎么判别是程序存在问题还是软硬件系统存在问题1、检查系统是否有中毒的特征2、检查软件/硬件的配置是否符合软件的推荐标准3、确认当前的系统是否是独立即没有对外提供什么消耗CPU资源的服务4、如果是C/S或者B/S结构的软件需要检查是不是因为与服务器的连接有问题或者访问有问题造成的5、在系统没有任何负载的情况下查看性能监视器确认应用程序对CPU/内存的访问情况。1.1.59测试的策略有哪些黑盒/白盒静态/动态手工/自动冒烟测试回归测试公测Beta测试的策略1.1.60正交表测试用例设计方法的特点是什么用最少的实验覆盖最多的操作测试用例设计很少效率高但是很复杂对于基本的验证功能以及二次集成引起的缺陷一般都能找出来但是更深的缺陷更复杂的缺陷还是无能为力的具体的环境下正交表一般都很难做的。大多数只在系统测试的时候使用此方法。1.1.61描述使用bugzilla缺陷管理工具对软件缺陷BUG跟踪的管理的流程就是Bugzilla的状态转换图。1.1.62你觉得bugzilla在使用的过程中有什么问题界面不稳定根据需要配置它的不同的部分过程很烦琐。流程控制上安全性不好界定很容易对他人的Bug进行误操作没有综合的评分指标不好确认修复的优先级别。1.1.63描述测试用例设计的完整过程需求分析需求变更的维护工作根据需求得出测试需求设计测试方案评审测试方案方案评审通过后设计测试用例再对测试用例进行评审1.1.64单元测试的策略有哪些逻辑覆盖、循环覆盖、同行评审、桌前检查、代码走查、代码评审、景泰数据流分析1.1.65使用QTP做功能测试录制脚本的时候要验证多个用户的登录情况/查询情况如何操作分析用户登录的基本情况得出一组数据通过性测试/失败性测试的都有根据TC来设计这些数据然后录制登录的脚本将关键的数据参数化修改脚本对代码进行加强调试脚本。1.1.66QTP中的Action有什么作用有几种Action的作用用Action可以对步骤集进行分组步骤重组然后被整体调用拥有自己的sheet组合有相同需求的步骤整体操作具有独立的对象仓库Action的种类可复用Action不可复用Action外部Action1.1.67TestDirector有些什么功能如何对软件测试过程进行管理需求管理:定义测试范围定义需求树描述需求树的功能点测试计划:定义测试目标和测试策略。分解应用程序建立测试计划树。确定每个功能点的测试方法。将每个功能点连接到需求上使测试计划覆盖全部的测试需求。描述手工测试的测试步骤指明需要进行自动测试的功能点测试执行:定义测试集合。为每个测试人员制定测试任务和测试日程安排。运行自动测试。缺陷跟踪:记录缺陷查看新增缺陷并确定哪些是需要修正的相关技术人员修改缺陷回归测试分析缺陷统计图表分析应用程序的开发质量。1.1.68你所熟悉的软件测试类型都有哪些请试着分别比较这些不同的测试类型的区别与联系如功能测试、性能测试……CompatibilityTesting兼容性测试也称“Configurationtesting配置测试”测试软件是否和系统的其它与之交互的元素之间兼容如浏览器、操作系统、硬件等。验证测试对象在不同的软件和硬件配置中的运行情况。Functionaltesting(功能测试)也称为behavioraltesting行为测试根据产品特征、操作描述和用户方案测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本以保证目标用户的体验将足够好就像应用程序是专门为该市场开发的一样。Performancetesting性能测试评价一个产品或组件与性能需求是否符合的测试。包括负载测试、强度测试、数据库容量测试、基准测试等类型。1.1.69软件缺陷或者叫Bug记录都包含了哪些内容如何提交高质量的软件缺陷Bug记录参考答案5C标准1.1.70软件的评审一般由哪些人参加其目的是什么在正式的会议上将软件项目的成果包括各阶段的文档、产生的代码等提交给用户、客户或有关部门人员对软件产品进行评审和批准。其目的是找出可能影响软件产品质量、开发过程、维护工作的适用性和环境方面的设计缺陷并采取补救措施以及找出在性能、安全性和经济方面的可能的改进。人员用户、客户或有关部门开发人员测试人员需求分析师都可以就看处于评审那个阶段1.1.71测试活动中如果发现需求文档不完善或者不准确怎么处理测试需求分析发现需求文档不完善或者不准确应该立即和相关人员进行协调交流。1.1.72阶段评审与项目评审有什么区别阶段评审对项目各阶段评审对阶段成果和工作项目评审对项目总体评审对工作和产品1.1.73阐述工作版本的定义参考答案构造号BUILD1.1.74什么是桩模块什么是驱动模块参考答案桩模块被测模块调用模块驱动模块:调用被测模块1.1.75什么是扇入什么是扇出参考答案扇入被调次数扇出调其它模块数目1.1.76你认为做好测试计划工作的关键是什么参考答案软件测试计划就是在软件测试工作正式实施之前明确测试的对象并且通过对资源、时间、风险、测试范围和预算等方面的综合分析和规划保证有效的实施软件测试做好测试计划工作的关键目的管理规范1.明确测试的目标增强测试计划的实用性编写软件测试计划的重要目的就是使测试过程能够发现更多的软件缺陷因此软件测试计划的价值取决于它对帮助管理测试项目并且找出软件潜在的缺陷。因此软件测试计划中的测试范围必须高度覆盖功能需求测试方法必须切实可行测试工具并且具有较高的实用性便于使用生成的测试结果直观、准确2坚持“5W”规则明确内容与过程“5W”规则指的是“What做什么”、“Why为什么做”、“When何时做”、“Where在哪里”、“How如何做”。利用“5W”规则创建软件测试计划可以帮助测试团队理解测试的目的Why明确测试的范围和内容What确定测试的开始和结束日期When指出测试的方法和工具How给出测试文档和软件的存放位置Where。3采用评审和更新机制保证测试计划满足实际需求测试计划写作完成后如果没有经过评审直接发送给测试团队测试计划内容的可能不准确或遗漏测试内容或者软件需求变更引起测试范围的增减而测试计划的内容没有及时更新误导测试执行人员。4.分别创建测试计划与测试详细规格、测试用例应把详细的测试技术指标包含到独立创建的测试详细规格文档把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系测试计划主要从宏观上规划测试活动的范围、方法和资源配置而测试详细规格、测试用例是完成测试任务的具体战术。1.1.77你觉得对于测试有哪些基本素质要求1细心只有细心才能保证不遗漏测试点并及时发现问题。2善于怀疑在测试的过程中总会遇到开发会说这个功能肯定没有问题这个时候就要小心开发给你埋下的坑了。3要有追根究底的精神我们有的时候发现一些不好复现的bug对于这样的bug一定要有不找出问题不罢休的精神。4考虑问题要周到需要测试结合需求业务流程和不同手机的兼容等多个方面来考虑问题。5要有良好的沟通能力不要让开发说服你这个问题修补修改如果你认为这个问题比较严重需要说服开发来修改他/她认为不用修改的问题。1.1.78一套完整的测试应该由哪些阶段组成测试计划、测试设计与开发、测试实施、测试评审与测试结论1.1.79软件测试的流程是什么需求调查:全面了解您的系统概况、应用领域、软件开发周期、软件开发环境、开发组织、时间安排、功能需求、性能需求、质量需求及测试要求等根据系统概况进行项目所需的人员、时间和工作量估计及项目报价。制定初步的项目计划:在与您充分共同和协商的基础上制定我们的测试计划。测试准备:组织测试团队、培训、建立测试和管理环境等。测试设计:按照测试要求进行每个测试项的测试设计包括测试用例的设计及测试脚本的开发等。测试实施:按照测试计划进行实施测试。测试评估:根据测试的结果出具测试评估报告。1.1.80说说你对SQA的职责和工作活动(如软件度量)的理解SQA就是独立于软件开发的项目组通过对软件开发过程的监控来保证软件的开发流程按照指定的CMM规程如果有相应的CMM规程对于不符合项及时提出建议和改进方案必要是可以要高层经理汇报以求问题的解决。通过这样的途径来预防缺陷的引入从而减少后期软件的维护成本。主要的工作活动包括制定SQA工作计划参与阶段产物的评审进行过程质量、功能配置及物理配置的审计等;对项目开发过程中产生的数据进行度量等等1.1.81单元测试的主要内容模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试1.1.82集成测试也叫组装测试或者联合测试请简述集成测试的主要内容1在把各个模块连接起来的时候穿越模块接口的数据是否会丢失2一个模块的功能是否会对另一个模块的功能产生不利的影响3各个子功能组合起来能否达到预期要求的父功能4全局数据结构是否有问题5单个模块的误差累积起来是否会放大从而达到不能接受的程度。1.1.83简述集成测试与系统测试关系1集成测试的主要依据概要设计说明书系统测试的主要依据是需求设计说明书2集成测试是系统模块的测试系统测试是对整个系统的测试包括相关的软硬件平台、网络以及相关外设的测试。感谢每一个认真阅读我文章的人作为一位过来人也是希望大家少走一些弯路如果你不想再体验一次学习时找不到资料没人解答问题坚持几天便放弃的感受的话在这里我给大家分享一些自动化测试的学习资源希望能给你前进的路上带来帮助。软件测试面试文档我们学习必然是为了找到高薪的工作下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料并且有字节大佬给出了权威的解答刷完这一套面试资料相信大家都能找到满意的工作。视频文档获取方式这份文档和视频资料对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴我走过了最艰难的路程希望也能帮助到你以上均可以分享点下方小卡片即可自行领取。