给你一个全新的软件，你就是负责人，你怎么去开展测试工作
参考回答：
第一步：需求分析：我会对这个全新的软件需求进行全面分析，主要的分析点有：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
压力测试，负载测试和性能测试关系？
链接：http://www.51testing.com/html/06/n-3721106.html
性能测试是动力，负载测试载重，压力测试强度
压力测试stresstest：是在一定的负荷条件下，长时间连续运行系统给系统性能造成的影响。
负载测试Loadtest：在一定的工作负荷下，给系统造成的负荷及系统响应的时间。
软件测试风险分析
测试计划都包括什么？
- 概述 1.1 编写目的 1.2 项目背景 1.3 项目质量目标 1.4 预期读者 1.5 参考资料
- 测试环境 2.1 系统架构 2.2 软硬件环境要求 2.3 测试环境部署图
- 测试规划 3.1 测试范围 3.2 测试工具 3.3 人员、角色及职责
- 测试策略 4.1 系统框测试 4.2 业务流程测试 4.3 功能点测试 4.4 UI界面测试 4.5 性能测试 4.6 兼容性测试 4.7 安全测试
- 测试进度安排
- 工作汇报
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上的 Internet Explorer、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（扩展工具集）和Selenium RC（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 测试完全脱离开发者的环境，完全交给用户进行测试。
测试策略有哪些？
链接：https://blog.csdn.net/hongfuqiang/article/details/78786187
设计系统测试需要参考的项目文档
软件测试计划
软件需求规范
迭代计划
文档测试
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）改进测试用例
随着开发工作进行，测试用例不断增加，某些用例随着系统输入和当前状态的变化而变得不再适用，这些用例难以重用，影响回归测试的效率，需要进行改进，使之可重用可控制。
总之，测试用例的维护是一个长期的过程，也是一个不断改进和完善的过程。