2023年6月21日发(作者：)

测试⾯试问题总汇给你⼀个全新的软件，你就是负责⼈，你怎么去开展测试⼯作参考回答：第⼀步：需求分析：我会对这个全新的软件需求进⾏全⾯分析，主要的分析点有：1.软件的版本需求合理性，是否可测试；2.项⽬⼈员配置（遇到什么问题找谁，有多少⼈投⼊测试，测试环境，硬件，软件）；3.要测试的软件的主流程，异常流程，测试重点；4。项⽬整体规划（发布时间第⼆步：指定测试策略、测试计划和bug定义标准，这⼀步主要是针对需求，在已有的和可协调到的资源上做出具体的，可执⾏的计划，这个阶段的输出是测试计划。测试计划中明确包含测试范围，测试策略，⽐如功能测试，性能测试，⾃动化测试，可⽤性测试，云测，mokey等第三步：按计划执⾏，编写测试⽤例，（编写测试⽤例的⽅法：等价类，边界值，错误猜测法，因果图，正交分解法等等）（编写测试⽤例需要注意的点，⽤例区分等级，特殊场景考虑：为空（接⼝空、数据空）、加载超时、⽹络异常、重复提交、异常中断、缓存冲突、系统兼容、流程迂回、流程中断；如果是PC，要注意浏览器（IE，chrome,⽕狐，苹果的），操作系统（xp,win7,win8,win10,linux,mac）的兼容,如果是⼿机，注意⼿机的品牌，操作系统，android版本，⼿机屏幕尺⼨，⼿机⽹络等等场景），写完⽤例，如果有条件，就要评审测试⽤例第四步：执⾏⽤例，补充场景，记录bug，回归bug（注意开发提测的需求需要冒烟测试通过）第五步：功能合⼊，回归测试（各个功能点测试通过之后，再合⼊）第六步：提交验收（回归测试通过之后，提交给验收⼈员进⾏验收）第七步：发布上线（全新的软件，先是⼩范围内测，观察线上数据（如：crash,⽤户反馈，运营数据等）如果有产品认为严重的问题，则需要修复后重发，符合预期才能扩⼤发布）如果你发现了bug但是开发不认为是bug，怎么办⾸先找证据⽀持我说这个是bug，（⽐如需求⽂档这么写的，竞品这么做的等等），如果找不到⾜够的证据⽀持你的观点，那就将问题升级到⼩组内讨论，⼀级⼀级的上升，直到PM或者项⽬经理拍板定义你觉得bug需要修改，很紧急，但是开发没时间，怎么办这个你需要先把这个问题说清楚，问题影响范围有多⼤，然后给PM或者项⽬经理还有拉上开发⼀起评审，说明这个问题遗留的风险，如果PM和项⽬经理接受这个风险，那就可以发布，否则必须修改了才能发布即使他们接受了，发布之后，也要注意线上的表现，并知会出来如果线上这个问题表现超过预期，那么就要要求发布hotfix

压⼒测试，负载测试和性能测试关系？压⼒测试stresstest：是在⼀定的负荷条件下，长时间连续运⾏系统给系统性能造成的影响。负载测试Loadtest：在⼀定的⼯作负荷下，给系统造成的负荷及系统响应的时间。软件测试风险分析测试计划都包括什么？1. 概述 1.1 编写⽬的 1.2 项⽬背景 1.3 项⽬质量⽬标 1.4 预期读者 1.5 参考资料2. 测试环境 2.1 系统架构 2.2 软硬件环境要求 2.3 测试环境部署图3. 测试规划 3.1 测试范围 3.2 测试⼯具 3.3 ⼈员、⾓⾊及职责4. 测试策略 4.1 系统框测试 4.2 业务流程测试 4.3 功能点测试 4.4 UI界⾯测试 4.5 性能测试 4.6 兼容性测试 4.7 安全测试5. 测试进度安排6. ⼯作汇报web测试和⼿机测试有什么区别WEB测试和App测试从流程上来说，没有区别。都需要经历测试计划⽅案，⽤例设计，测试执⾏，缺陷管理，测试报告等相关活动。从技术上来说，WEB测试和APP测试其测试类型也基本相似，都需要进⾏功能测试、性能测试、安全性测试、GUI测试等测试类型。他们的主要区别在于具体测试的细节和⽅法有区别，⽐如：性能测试，在WEB测试只需要测试响应时间这个要素，在App测试中还需要考虑流量测试和耗电量测试。兼容性测试：在WEB端是兼容浏览器，在App端兼容的是⼿机设备。⽽且相对应的兼容性测试⼯具也不相同，WEB因为是测试兼容浏览器，所以需要使⽤不同的浏览器进⾏兼容性测试（常见的是兼容IE6，IE8，chrome，firefox）如果是⼿机端，那么就需要兼容不同品牌，不同分辨率，不同android版本甚⾄不同操作系统的兼容。（常见的兼容⽅式是兼容市场占⽤率前N位的⼿机即可），有时候也可以使⽤到兼容性测试⼯具，但WEB兼容性⼯具多⽤IETester等⼯具，⽽App兼容性测试会使⽤Testin这样的商业⼯具也可以做测试。安装测试：WEB测试基本上没有客户端层⾯的安装测试，但是App测试是存在客户端层⾯的安装测试，那么就具备相关的测试点。还有，App测试基于⼿机设备，还有⼀些⼿机设备的专项测试。如交叉事件测试，操作类型测试，⽹络测试（弱⽹测试，⽹络切换）交叉事件测试：就是在操作某个软件的时候，来电话、来短信，电量不⾜提⽰等外部事件。操作类型测试：如横屏测试，⼿势测试⽹络测试：包含弱⽹和⽹络切换测试。需要测试弱⽹所造成的⽤户体验，重点要考虑回退和刷新是否会造成⼆次提交。弱⽹络的模拟，据说可以⽤360wifi实现设置。从系统架构的层⾯，WEB测试只要更新了服务器端，客户端就会同步会更新。⽽且客户端是可以保证每⼀个⽤户的客户端完全⼀致的。但是APP端是不能够保证完全⼀致的，除⾮⽤户更新客户端。如果是APP下修改了服务器端，意味着客户端⽤户所使⽤的核⼼版本都需要进⾏回归测试⼀遍。还有升级测试：升级测试的提醒机制，升级取消是否会影响原有功能的使⽤，升级后⽤户数据是否被清除了。selenium 和 Appium 是怎么联系的?有什么关系?⼀ 、 selenium是专门做web端的⾃动化测试⼯具Selenium与其他测试⼯具相⽐，最⼤好处是：Selenium 测试直接在浏览器中运⾏，就像真实⽤户所做的⼀样。Selenium 测试可以在 Windows、Linux 和 Macintosh上的 InternetExplorer、Chrome和 Firefox 中运⾏。其他测试⼯具都不能覆盖如此多的平台。使⽤ Selenium 和在浏览器中运⾏测试还有很多其他好处。下⾯是主要的两⼤好处：通过编写模仿⽤户操作的 Selenium 测试脚本，可以从终端⽤户的⾓度来测试应⽤程序。通过在不同浏览器中运⾏测试，更容易发现浏览器的不兼容性。Selenium 的核⼼，也称browser bot，是⽤ JavaScript 编写的。这使得测试脚本可以在受⽀持的浏览器中运⾏。browser bot负责执⾏从测试脚本接收到的命令，测试脚本要么是⽤ HTML 的表布局编写的，要么是使⽤⼀种受⽀持的编程语⾔编写的。⼆ 、appium是⼿机app端的⾃动化，它继承了webdriver(也就是selenium 2)不过appium仍然需要通过selenium最后做测试⼯具，但是appium起到了⼀个连接⼿机端⾮常好的桥梁⼯作！可以连接到电脑上⾮常⽅便的调⽤selenium⼯具来做测试。Selenium 1.0版包括三个部分，分别是Selenium IDE（插件，⽤于录屏，并转化代码）、Selenium Grid（扩展⼯具集）和SeleniumRC（Remote Controller），其中最主要部分为Selenium RC。但是Selenium与WebDriver合并后，Selenium2.0就等价为WebDriver了，所以学习Selenium2.0的话，相当于主要学习WebDriver API了。3.0版本直到2016年才发布，该版本彻底移出了Selenium RC，对开发环境也有了限制（例如只⽀持jvav8以上版本，对不同的浏览器也有最低版本要求）。相对⽽⾔，2.0版的通⽤性更⾼。阶段评审与同⾏评审的区别？同⾏评审⽬的：发现⼩规模⼯作产品的错误，只要是找错误；阶段评审⽬的：评审模块 阶段作品的正确性 可⾏性 及完整性同⾏评审⼈数：3-7⼈ ⼈员必须经过同⾏评审会议的培训，由SQA指导阶段评审⼈数：5⼈左右 评审⼈必须是专家 具有系统评审资格同⾏评审内容：内容⼩ ⼀般⽂档 < 40页， 代码 < 500⾏阶段评审内容： 内容多，主要看重点同⾏评审时间：⼀⼩部分⼯作产品完成阶段评审时间： 通常是设置在关键路径的时间点上验收测试包括？功能测试、易⽤性测试、兼容性测试、安装测试、⽂档测试等等兼容性测试是指软件可以在不同的平台下运⾏，包括软件环境（⽐如LINUX的各个版本等）、硬件环境（⽐如android的各款⼿机等）。安装测试，也叫部署测试，确保软件安装后可以正常使⽤，包括不同的安装⽅式、不同平台下的安装等。⽂档测试只要是测试⽂档，⽂档也是软件交付的产品之⼀，包括⽤户⼿册、使⽤说明等等。⾮正式验收包括Alpha 测试、Beta 测试。Alpha 测试⼀般是在开发者所提供的场所进⾏测试，由⽤户来执⾏。Beta 测试完全脱离开发者的环境，完全交给⽤户进⾏测试。测试策略有哪些？设计系统测试需要参考的项⽬⽂档软件测试计划软件需求规范迭代计划⽂档测试Namaste,guys ~此博客Val主要分享关于⽂档测试的概念。⼀、⽂档测试的内容：1、⽂档的完整性：主要是测试⽂档内容的全⾯性与完整性，从总体上把握⽂档的质量。例如⽤户⼿册应该包括软件的所有功能模块。2、描述与软件实际情况的⼀致性：主要测试软件⽂档与软件实际的⼀致程度。例如⽤户⼿册基本完整后，我们还要注意⽤户⼿册与实际功能描述是否⼀致。因为⽂档往往跟不上软件版本的更新速度。3、易理解性：主要是检查⽂档对关键、重要的操作有⽆图⽂说明，⽂字、图表是否易于理解。对于关键、重要的操作仅仅只有⽂字说明肯定是不够的，应该附有图表使说明更为直观和明了。4、⽂档中提供操作的实例：这项检查内容主要针对⽤户⼿册。对主要功能和关键操作提供的应⽤实例是否丰富，提供的实例描述是否详细。只有简单的图⽂说明，⽽⽆实例的⽤户⼿册看起来就像是软件界⾯的简单拷贝，对于⽤户来说，实际上没有什么帮助。5、印刷与包装质量：主要是检查软件⽂档的商品化程度。有些⽤户⼿册是简单打印、装订⽽成，过于粗糙，不易于⽤户保存。优秀的⽂档例如⽤户⼿册和技术⽩⽪书，应提供商品化包装，并且印刷精美。⼆、软件⽂档测试对象与⽬的1、⽂档测试对象主要如下：包装⽂字和图形；市场宣传材料、⼴告以及其它插页；授权、注册登记表；最终⽤户许可协议；安装和设置向导；⽤户⼿册；联机帮助；样例、⽰范例⼦和模板；2、⽂档测试的⽬的：提⾼易⽤性和可靠性，降低⽀持费⽤，因为⽤户通过⽂档就可以⾃⼰解决问题。因此⽂档测试的检查内容主要如下：读者对象——主要是⽂档的内容是否能让该级别的读者理解；术语——主要是检查术语是否适合读者；内容和主题——检查主题是否合适、是否丢失、格式是否规范等；图标和屏幕抓图——检查图表的准确度和精确度；样例和⽰例——是否与软件功能⼀致；拼写和语法；⽂档的关联性——是否与其它相关⽂档的内容⼀致，例如与⼴告信息是否⼀致；⽂档测试是相当重要的⼀项测试⼯作，不但要给予充分的重视，更要要认真的完成，象做功能测试⼀样来对待⽂档测试。三、做好⽂档测试需要注意：仔细阅读，跟随每个步骤，检查每个图形，尝试每个⽰例；检查⽂档的编写是否满⾜⽂档编写的⽬的；内容是否齐全、正确、完善；软件的缺陷等级应如何划分？致命的：致命的错误，造成系统或应⽤程序崩溃、死机、系统悬挂，或造成数据丢失、主要功能完全丧失等。严重的：严重错误，指功能或特性没有实现，主要功能部分丧失，次要功能完全丧失，或致命的错误声明。⼀般的：不太严重的错误，这样的软件缺陷虽然不影响系统的基本使⽤，但没有很好地实现功能，没有达到预期效果。如次要功能丧失，提⽰信息不太准确，或⽤户界⾯差，操作时间长等。微⼩的：⼀些⼩问题，对功能⼏乎没有影响，产品及属性仍可使⽤，如有个别错别字、⽂字排列不整齐等。测试过程中输出的⽂档测试计划，测试⽂档，测试⽤例，测试⽇志，bug报告，测试总结报告软件质量评估指标1、功能性的质量指标　　功能的正确性：系统功能和⽤户的实际需求、已定义的产品规范⼀致。　　功能的准确性：系统产⽣的结果在精度允许的误差范围内。　　功能的完整性：所有功能及其定义清楚、可⽤。　　2、可⽤性的质量指标　　可操作性：容易使⽤和操作，包括理解⽤户界⾯、适应⼀些特殊⽤户的可选项等。　　通⽤性：数据显⽰、⽹络通信接⼝和⽤户界⾯等都遵守已有的软件标准。　　⼀致性：在软件开发整个⽣命周期内建⽴和使⽤相同的标准，保证全局变量、数据类型、出错处理的命名和使⽤⼀致。　　3、可靠性的质量指标　　⾃我恢复能⼒：当系统的某个功能失效发⽣时，系统在当前环境下能实现故障⾃动转移，重新⾃动配置、继续执⾏的能⼒，软件系统具有⾃我检测、容错、备份等机制，尽量做到独⽴于硬件的编码、硬件设备之间的通信协议⼀致等。　　健壮性：各种恶劣环境（⼤数据量、⼤⽤户量）下系统能正常⼯作。　　分布性：软件系统的某些⼦功能或⼦系统被定位于不同的处理主机、存储设备。　　4、性能的质量指标　　有效性：系统在通信、处理、存储等⽅⾯占有很少资源或者对所使⽤的资源进⾏了优化。　　完整性：系统具有良好的安全管理，能防⽌不安全存取系统、防⽌数据丢失病毒⼊侵等。　　易存取性：对系统的存取权限设置清楚，存取操作⽅便，存取操作有记录。　　5、可维护性的质量指标　　模块化：指讲⼀个复杂的软件系统分解为分别命名并具备最⼩耦合性、很强凝聚性、结构化的组件。　　灵活性：容易为系统增加⼀个新功能或者新的数据⽽不需要进⾏⼤量的代码修改或者设计修改。　　可测试性：测试软件组件或者集成产品时查找缺陷的简易程度。　　可追溯性：对⼀个特殊需求容易找出相应的代码，反之，也可以根据代码找出特定的需求。　　兼容性：软件、硬件、通信系统之间协调及兼容其他系统的能⼒。　　可解释性：相关⽂档齐全、符合标准、逻辑清晰、描述准确、⽤词恰当，容易理解和定位。　　6、可移植性质量指标　　适应性：系统不依赖于环境，即系统不做修改或作很少的修改即可运⾏在其他环境下。　　易安装性：与在指定的环境下安装软件所需努⼒有关的软件属性。如在线更新、安装包⾃动⽣成等。　　可重⽤性：⼀个软件组件除了在最初开发的系统之外应⽤于其他系统的能⼒。　　互操作性：软件系统与其他系统交换数据和服务的难易程度。　　可替换性：与软件在该环境中⽤来替代指定的其他软件的机会和努⼒有关的软件属性。测试⽤例的维护、软件产品的版本是随着软件的升级⽽不断变化的，⽽每⼀次版本的变化都会对测试⽤例集产⽣影响，所以测试⽤例集也需要不断地变更和维护，使之与产品的变化保持⼀致。以下原因可能导致测试⽤例变更：1）软件需求变更：软件需求变更可能导致软件功能的增加、删除、修改等变化，应遵循需求变更控制管理⽅法，同样变更的测试⽤例也需要执⾏变更管理流程。2）测试需求的遗漏和误解：由于测试需求分析不到位，可能导致测试需求遗漏或者误解，相应的测试⽤⼒也要进⾏变更。特别是对于软件隐性需求，在测试需求分析阶段容易遗漏，⽽在测试执⾏过程中被发现，这时需要补充测试⽤例。3）测试⽤例遗漏：在测试过程中，发现测试⽤例未覆盖全部需求，需要补充相应的测试⽤例。4）软件发布后，⽤户反馈的缺陷：表明测试不全⾯，存在尚未发现的缺陷，需要补充或者修改测试⽤例。对于提供软件服务的产品，其多个版本常常共存，⽽对应的测试⽤例也是共存的，⽽且测试⽤例需要专⼈定期维护，并遵循以下原则：1）及时删除过时的测试⽤例需求变更可能导致原有部分测试⽤例不再适合新的需求要求。例如，删除了某个功能，那么针对该功能的测试⽤例也不再需要。所以随着需求的每⼀次变更，都要删除那些不再使⽤的测试⽤例。2）及时删除冗余的测试⽤例在设计测试⽤例时，可能存在两个或者多个⽤例测试相同内容，降低回归测试效率，所以要定期整理测试⽤例集，及时删除冗余的测试⽤例。3）增加新的测试⽤例由于需求变更、⽤例遗漏或者版本发布后发现缺陷等原因，原有的测试⽤例集没有完全覆盖软件需求，需要增加新的测试⽤例。4）改进测试⽤例随着开发⼯作进⾏，测试⽤例不断增加，某些⽤例随着系统输⼊和当前状态的变化⽽变得不再适⽤，这些⽤例难以重⽤，影响回归测试的效率，需要进⾏改进，使之可重⽤可控制。总之，测试⽤例的维护是⼀个长期的过程，也是⼀个不断改进和完善的过程。

2023年6月21日发(作者：)

测试⾯试问题总汇给你⼀个全新的软件，你就是负责⼈，你怎么去开展测试⼯作参考回答：第⼀步：需求分析：我会对这个全新的软件需求进⾏全⾯分析，主要的分析点有：1.软件的版本需求合理性，是否可测试；2.项⽬⼈员配置（遇到什么问题找谁，有多少⼈投⼊测试，测试环境，硬件，软件）；3.要测试的软件的主流程，异常流程，测试重点；4。项⽬整体规划（发布时间第⼆步：指定测试策略、测试计划和bug定义标准，这⼀步主要是针对需求，在已有的和可协调到的资源上做出具体的，可执⾏的计划，这个阶段的输出是测试计划。测试计划中明确包含测试范围，测试策略，⽐如功能测试，性能测试，⾃动化测试，可⽤性测试，云测，mokey等第三步：按计划执⾏，编写测试⽤例，（编写测试⽤例的⽅法：等价类，边界值，错误猜测法，因果图，正交分解法等等）（编写测试⽤例需要注意的点，⽤例区分等级，特殊场景考虑：为空（接⼝空、数据空）、加载超时、⽹络异常、重复提交、异常中断、缓存冲突、系统兼容、流程迂回、流程中断；如果是PC，要注意浏览器（IE，chrome,⽕狐，苹果的），操作系统（xp,win7,win8,win10,linux,mac）的兼容,如果是⼿机，注意⼿机的品牌，操作系统，android版本，⼿机屏幕尺⼨，⼿机⽹络等等场景），写完⽤例，如果有条件，就要评审测试⽤例第四步：执⾏⽤例，补充场景，记录bug，回归bug（注意开发提测的需求需要冒烟测试通过）第五步：功能合⼊，回归测试（各个功能点测试通过之后，再合⼊）第六步：提交验收（回归测试通过之后，提交给验收⼈员进⾏验收）第七步：发布上线（全新的软件，先是⼩范围内测，观察线上数据（如：crash,⽤户反馈，运营数据等）如果有产品认为严重的问题，则需要修复后重发，符合预期才能扩⼤发布）如果你发现了bug但是开发不认为是bug，怎么办⾸先找证据⽀持我说这个是bug，（⽐如需求⽂档这么写的，竞品这么做的等等），如果找不到⾜够的证据⽀持你的观点，那就将问题升级到⼩组内讨论，⼀级⼀级的上升，直到PM或者项⽬经理拍板定义你觉得bug需要修改，很紧急，但是开发没时间，怎么办这个你需要先把这个问题说清楚，问题影响范围有多⼤，然后给PM或者项⽬经理还有拉上开发⼀起评审，说明这个问题遗留的风险，如果PM和项⽬经理接受这个风险，那就可以发布，否则必须修改了才能发布即使他们接受了，发布之后，也要注意线上的表现，并知会出来如果线上这个问题表现超过预期，那么就要要求发布hotfix

压⼒测试，负载测试和性能测试关系？压⼒测试stresstest：是在⼀定的负荷条件下，长时间连续运⾏系统给系统性能造成的影响。负载测试Loadtest：在⼀定的⼯作负荷下，给系统造成的负荷及系统响应的时间。软件测试风险分析测试计划都包括什么？1. 概述 1.1 编写⽬的 1.2 项⽬背景 1.3 项⽬质量⽬标 1.4 预期读者 1.5 参考资料2. 测试环境 2.1 系统架构 2.2 软硬件环境要求 2.3 测试环境部署图3. 测试规划 3.1 测试范围 3.2 测试⼯具 3.3 ⼈员、⾓⾊及职责4. 测试策略 4.1 系统框测试 4.2 业务流程测试 4.3 功能点测试 4.4 UI界⾯测试 4.5 性能测试 4.6 兼容性测试 4.7 安全测试5. 测试进度安排6. ⼯作汇报web测试和⼿机测试有什么区别WEB测试和App测试从流程上来说，没有区别。都需要经历测试计划⽅案，⽤例设计，测试执⾏，缺陷管理，测试报告等相关活动。从技术上来说，WEB测试和APP测试其测试类型也基本相似，都需要进⾏功能测试、性能测试、安全性测试、GUI测试等测试类型。他们的主要区别在于具体测试的细节和⽅法有区别，⽐如：性能测试，在WEB测试只需要测试响应时间这个要素，在App测试中还需要考虑流量测试和耗电量测试。兼容性测试：在WEB端是兼容浏览器，在App端兼容的是⼿机设备。⽽且相对应的兼容性测试⼯具也不相同，WEB因为是测试兼容浏览器，所以需要使⽤不同的浏览器进⾏兼容性测试（常见的是兼容IE6，IE8，chrome，firefox）如果是⼿机端，那么就需要兼容不同品牌，不同分辨率，不同android版本甚⾄不同操作系统的兼容。（常见的兼容⽅式是兼容市场占⽤率前N位的⼿机即可），有时候也可以使⽤到兼容性测试⼯具，但WEB兼容性⼯具多⽤IETester等⼯具，⽽App兼容性测试会使⽤Testin这样的商业⼯具也可以做测试。安装测试：WEB测试基本上没有客户端层⾯的安装测试，但是App测试是存在客户端层⾯的安装测试，那么就具备相关的测试点。还有，App测试基于⼿机设备，还有⼀些⼿机设备的专项测试。如交叉事件测试，操作类型测试，⽹络测试（弱⽹测试，⽹络切换）交叉事件测试：就是在操作某个软件的时候，来电话、来短信，电量不⾜提⽰等外部事件。操作类型测试：如横屏测试，⼿势测试⽹络测试：包含弱⽹和⽹络切换测试。需要测试弱⽹所造成的⽤户体验，重点要考虑回退和刷新是否会造成⼆次提交。弱⽹络的模拟，据说可以⽤360wifi实现设置。从系统架构的层⾯，WEB测试只要更新了服务器端，客户端就会同步会更新。⽽且客户端是可以保证每⼀个⽤户的客户端完全⼀致的。但是APP端是不能够保证完全⼀致的，除⾮⽤户更新客户端。如果是APP下修改了服务器端，意味着客户端⽤户所使⽤的核⼼版本都需要进⾏回归测试⼀遍。还有升级测试：升级测试的提醒机制，升级取消是否会影响原有功能的使⽤，升级后⽤户数据是否被清除了。selenium 和 Appium 是怎么联系的?有什么关系?⼀ 、 selenium是专门做web端的⾃动化测试⼯具Selenium与其他测试⼯具相⽐，最⼤好处是：Selenium 测试直接在浏览器中运⾏，就像真实⽤户所做的⼀样。Selenium 测试可以在 Windows、Linux 和 Macintosh上的 InternetExplorer、Chrome和 Firefox 中运⾏。其他测试⼯具都不能覆盖如此多的平台。使⽤ Selenium 和在浏览器中运⾏测试还有很多其他好处。下⾯是主要的两⼤好处：通过编写模仿⽤户操作的 Selenium 测试脚本，可以从终端⽤户的⾓度来测试应⽤程序。通过在不同浏览器中运⾏测试，更容易发现浏览器的不兼容性。Selenium 的核⼼，也称browser bot，是⽤ JavaScript 编写的。这使得测试脚本可以在受⽀持的浏览器中运⾏。browser bot负责执⾏从测试脚本接收到的命令，测试脚本要么是⽤ HTML 的表布局编写的，要么是使⽤⼀种受⽀持的编程语⾔编写的。⼆ 、appium是⼿机app端的⾃动化，它继承了webdriver(也就是selenium 2)不过appium仍然需要通过selenium最后做测试⼯具，但是appium起到了⼀个连接⼿机端⾮常好的桥梁⼯作！可以连接到电脑上⾮常⽅便的调⽤selenium⼯具来做测试。Selenium 1.0版包括三个部分，分别是Selenium IDE（插件，⽤于录屏，并转化代码）、Selenium Grid（扩展⼯具集）和SeleniumRC（Remote Controller），其中最主要部分为Selenium RC。但是Selenium与WebDriver合并后，Selenium2.0就等价为WebDriver了，所以学习Selenium2.0的话，相当于主要学习WebDriver API了。3.0版本直到2016年才发布，该版本彻底移出了Selenium RC，对开发环境也有了限制（例如只⽀持jvav8以上版本，对不同的浏览器也有最低版本要求）。相对⽽⾔，2.0版的通⽤性更⾼。阶段评审与同⾏评审的区别？同⾏评审⽬的：发现⼩规模⼯作产品的错误，只要是找错误；阶段评审⽬的：评审模块 阶段作品的正确性 可⾏性 及完整性同⾏评审⼈数：3-7⼈ ⼈员必须经过同⾏评审会议的培训，由SQA指导阶段评审⼈数：5⼈左右 评审⼈必须是专家 具有系统评审资格同⾏评审内容：内容⼩ ⼀般⽂档 < 40页， 代码 < 500⾏阶段评审内容： 内容多，主要看重点同⾏评审时间：⼀⼩部分⼯作产品完成阶段评审时间： 通常是设置在关键路径的时间点上验收测试包括？功能测试、易⽤性测试、兼容性测试、安装测试、⽂档测试等等兼容性测试是指软件可以在不同的平台下运⾏，包括软件环境（⽐如LINUX的各个版本等）、硬件环境（⽐如android的各款⼿机等）。安装测试，也叫部署测试，确保软件安装后可以正常使⽤，包括不同的安装⽅式、不同平台下的安装等。⽂档测试只要是测试⽂档，⽂档也是软件交付的产品之⼀，包括⽤户⼿册、使⽤说明等等。⾮正式验收包括Alpha 测试、Beta 测试。Alpha 测试⼀般是在开发者所提供的场所进⾏测试，由⽤户来执⾏。Beta 测试完全脱离开发者的环境，完全交给⽤户进⾏测试。测试策略有哪些？设计系统测试需要参考的项⽬⽂档软件测试计划软件需求规范迭代计划⽂档测试Namaste,guys ~此博客Val主要分享关于⽂档测试的概念。⼀、⽂档测试的内容：1、⽂档的完整性：主要是测试⽂档内容的全⾯性与完整性，从总体上把握⽂档的质量。例如⽤户⼿册应该包括软件的所有功能模块。2、描述与软件实际情况的⼀致性：主要测试软件⽂档与软件实际的⼀致程度。例如⽤户⼿册基本完整后，我们还要注意⽤户⼿册与实际功能描述是否⼀致。因为⽂档往往跟不上软件版本的更新速度。3、易理解性：主要是检查⽂档对关键、重要的操作有⽆图⽂说明，⽂字、图表是否易于理解。对于关键、重要的操作仅仅只有⽂字说明肯定是不够的，应该附有图表使说明更为直观和明了。4、⽂档中提供操作的实例：这项检查内容主要针对⽤户⼿册。对主要功能和关键操作提供的应⽤实例是否丰富，提供的实例描述是否详细。只有简单的图⽂说明，⽽⽆实例的⽤户⼿册看起来就像是软件界⾯的简单拷贝，对于⽤户来说，实际上没有什么帮助。5、印刷与包装质量：主要是检查软件⽂档的商品化程度。有些⽤户⼿册是简单打印、装订⽽成，过于粗糙，不易于⽤户保存。优秀的⽂档例如⽤户⼿册和技术⽩⽪书，应提供商品化包装，并且印刷精美。⼆、软件⽂档测试对象与⽬的1、⽂档测试对象主要如下：包装⽂字和图形；市场宣传材料、⼴告以及其它插页；授权、注册登记表；最终⽤户许可协议；安装和设置向导；⽤户⼿册；联机帮助；样例、⽰范例⼦和模板；2、⽂档测试的⽬的：提⾼易⽤性和可靠性，降低⽀持费⽤，因为⽤户通过⽂档就可以⾃⼰解决问题。因此⽂档测试的检查内容主要如下：读者对象——主要是⽂档的内容是否能让该级别的读者理解；术语——主要是检查术语是否适合读者；内容和主题——检查主题是否合适、是否丢失、格式是否规范等；图标和屏幕抓图——检查图表的准确度和精确度；样例和⽰例——是否与软件功能⼀致；拼写和语法；⽂档的关联性——是否与其它相关⽂档的内容⼀致，例如与⼴告信息是否⼀致；⽂档测试是相当重要的⼀项测试⼯作，不但要给予充分的重视，更要要认真的完成，象做功能测试⼀样来对待⽂档测试。三、做好⽂档测试需要注意：仔细阅读，跟随每个步骤，检查每个图形，尝试每个⽰例；检查⽂档的编写是否满⾜⽂档编写的⽬的；内容是否齐全、正确、完善；软件的缺陷等级应如何划分？致命的：致命的错误，造成系统或应⽤程序崩溃、死机、系统悬挂，或造成数据丢失、主要功能完全丧失等。严重的：严重错误，指功能或特性没有实现，主要功能部分丧失，次要功能完全丧失，或致命的错误声明。⼀般的：不太严重的错误，这样的软件缺陷虽然不影响系统的基本使⽤，但没有很好地实现功能，没有达到预期效果。如次要功能丧失，提⽰信息不太准确，或⽤户界⾯差，操作时间长等。微⼩的：⼀些⼩问题，对功能⼏乎没有影响，产品及属性仍可使⽤，如有个别错别字、⽂字排列不整齐等。测试过程中输出的⽂档测试计划，测试⽂档，测试⽤例，测试⽇志，bug报告，测试总结报告软件质量评估指标1、功能性的质量指标　　功能的正确性：系统功能和⽤户的实际需求、已定义的产品规范⼀致。　　功能的准确性：系统产⽣的结果在精度允许的误差范围内。　　功能的完整性：所有功能及其定义清楚、可⽤。　　2、可⽤性的质量指标　　可操作性：容易使⽤和操作，包括理解⽤户界⾯、适应⼀些特殊⽤户的可选项等。　　通⽤性：数据显⽰、⽹络通信接⼝和⽤户界⾯等都遵守已有的软件标准。　　⼀致性：在软件开发整个⽣命周期内建⽴和使⽤相同的标准，保证全局变量、数据类型、出错处理的命名和使⽤⼀致。　　3、可靠性的质量指标　　⾃我恢复能⼒：当系统的某个功能失效发⽣时，系统在当前环境下能实现故障⾃动转移，重新⾃动配置、继续执⾏的能⼒，软件系统具有⾃我检测、容错、备份等机制，尽量做到独⽴于硬件的编码、硬件设备之间的通信协议⼀致等。　　健壮性：各种恶劣环境（⼤数据量、⼤⽤户量）下系统能正常⼯作。　　分布性：软件系统的某些⼦功能或⼦系统被定位于不同的处理主机、存储设备。　　4、性能的质量指标　　有效性：系统在通信、处理、存储等⽅⾯占有很少资源或者对所使⽤的资源进⾏了优化。　　完整性：系统具有良好的安全管理，能防⽌不安全存取系统、防⽌数据丢失病毒⼊侵等。　　易存取性：对系统的存取权限设置清楚，存取操作⽅便，存取操作有记录。　　5、可维护性的质量指标　　模块化：指讲⼀个复杂的软件系统分解为分别命名并具备最⼩耦合性、很强凝聚性、结构化的组件。　　灵活性：容易为系统增加⼀个新功能或者新的数据⽽不需要进⾏⼤量的代码修改或者设计修改。　　可测试性：测试软件组件或者集成产品时查找缺陷的简易程度。　　可追溯性：对⼀个特殊需求容易找出相应的代码，反之，也可以根据代码找出特定的需求。　　兼容性：软件、硬件、通信系统之间协调及兼容其他系统的能⼒。　　可解释性：相关⽂档齐全、符合标准、逻辑清晰、描述准确、⽤词恰当，容易理解和定位。　　6、可移植性质量指标　　适应性：系统不依赖于环境，即系统不做修改或作很少的修改即可运⾏在其他环境下。　　易安装性：与在指定的环境下安装软件所需努⼒有关的软件属性。如在线更新、安装包⾃动⽣成等。　　可重⽤性：⼀个软件组件除了在最初开发的系统之外应⽤于其他系统的能⼒。　　互操作性：软件系统与其他系统交换数据和服务的难易程度。　　可替换性：与软件在该环境中⽤来替代指定的其他软件的机会和努⼒有关的软件属性。测试⽤例的维护、软件产品的版本是随着软件的升级⽽不断变化的，⽽每⼀次版本的变化都会对测试⽤例集产⽣影响，所以测试⽤例集也需要不断地变更和维护，使之与产品的变化保持⼀致。以下原因可能导致测试⽤例变更：1）软件需求变更：软件需求变更可能导致软件功能的增加、删除、修改等变化，应遵循需求变更控制管理⽅法，同样变更的测试⽤例也需要执⾏变更管理流程。2）测试需求的遗漏和误解：由于测试需求分析不到位，可能导致测试需求遗漏或者误解，相应的测试⽤⼒也要进⾏变更。特别是对于软件隐性需求，在测试需求分析阶段容易遗漏，⽽在测试执⾏过程中被发现，这时需要补充测试⽤例。3）测试⽤例遗漏：在测试过程中，发现测试⽤例未覆盖全部需求，需要补充相应的测试⽤例。4）软件发布后，⽤户反馈的缺陷：表明测试不全⾯，存在尚未发现的缺陷，需要补充或者修改测试⽤例。对于提供软件服务的产品，其多个版本常常共存，⽽对应的测试⽤例也是共存的，⽽且测试⽤例需要专⼈定期维护，并遵循以下原则：1）及时删除过时的测试⽤例需求变更可能导致原有部分测试⽤例不再适合新的需求要求。例如，删除了某个功能，那么针对该功能的测试⽤例也不再需要。所以随着需求的每⼀次变更，都要删除那些不再使⽤的测试⽤例。2）及时删除冗余的测试⽤例在设计测试⽤例时，可能存在两个或者多个⽤例测试相同内容，降低回归测试效率，所以要定期整理测试⽤例集，及时删除冗余的测试⽤例。3）增加新的测试⽤例由于需求变更、⽤例遗漏或者版本发布后发现缺陷等原因，原有的测试⽤例集没有完全覆盖软件需求，需要增加新的测试⽤例。4）改进测试⽤例随着开发⼯作进⾏，测试⽤例不断增加，某些⽤例随着系统输⼊和当前状态的变化⽽变得不再适⽤，这些⽤例难以重⽤，影响回归测试的效率，需要进⾏改进，使之可重⽤可控制。总之，测试⽤例的维护是⼀个长期的过程，也是⼀个不断改进和完善的过程。