测试的那些事！

什么是测试？

测试就是通过人工或者自动化来验证结果和需求是否一致的过程

软件测试的目的与原则是什么？

目的：

    通过测试工作可以发现软件中的缺陷

    可以降低通产品的开发遇到的风险

    通过测试过程中得到的数据向策划者提供技术支持

原则：

缺陷集成性：2/8 软件测试中20%都是核心内容，非核心占80%，我们会集中测试20%的核心功能，发现缺陷的几率会高于80%，因此遇到的缺陷都会集中在20%模块中。

穷尽测试是不可能的：有些功能是无法将所有测试情况逻辑出来的，任何测试都是有结束的时间

测试需要尽早介入：为了更好发现和解决软件中的缺陷、

杀虫剂悖论：同样的一个测试用例是不能重复执行多次，不然软件会对它产生免疫

测试显示软件存在的缺陷

测试活动依赖于测试内容：某些测试需要依赖于特殊的环境

没有错误是好是谬论：任何软件都不可能是完美的

测试人员在测试中的任务是什么？

尽早找出系统当中的Bug

避免软件开发过程中缺陷的出现

关注用户需求，保证系统符合用户需求

请您详细描述测试的V模型？

用户需求--需求分析--概要设计--详细设计--编码，实现--单元测试--集成测试--系统测试--验收测试

Bug不能复现怎么办？

首先考虑到环境问题，看是否能够还原原来的环境

遇到问题就要提，不能放过一个Bug，提交的Bug描述中加上一句话，那就是复现的概率，20次，出现一次或者是10次，交给开发，开发会根据Bug的复现概率，调整Bug的优先级

注重细节，不要漏掉任何一个细节（尽量回想发生问题的复现步骤，不要漏掉任何一个细节，按照步骤的组合尝试复现）

与开发人员配合，让开发人员对相应的代码检查，看是否通过代码层面解决问题。

B/S和C/S架构的区别是什么？

B/S：是浏览器和服务器

C/S：是客户端和服务器

B/S的执行效率要比C/S高，C/S的安全要比B/S高，B/S升级只需要在服务器端将数据进行更新，前台只需刷新页面就可以升级，而C/S架构必须两端都要更新，B/S要比C/S开发成本要低；

测试流程是什么？

需求评审（开发人员，测试人员，产品经理，项目经理）需求确定（出一份确定好的需求文档）开发设计文档（开发人员在写代码之前就能够输出设计文档）指定测试计划--写出测试用例--发给开发人员和测试经理看一下--接到测试版本--执行测试用例--提交Bug--交给开发人员修改--回归测试

当你参加评审时买的评审的原则是什么？ 

首先要从正确性，一致性，可行性，必要性，可跟踪性，分配优先级，可测性，可修改性考虑；

正确性：每一条需求都必须准确的陈述其要开发的功能。

一致性：必须与其他软件需求或高层需求不相矛盾。

可行性：其每一项需求都必须是已系统和环境的权能和限制范围可以来实施的。

必要性：每项需求都是用来授权你编写文档的“根源”，要使每项需求都能回潮至某项客户的输入。

可测性：每项需求都能通过设计测试用例或其他的验证方法来进行测试。

可修改性：每项需求只应在SRS中出现一次，这样更改会容易保持一致性。

可跟踪性：在每项软件需求与它的根源与设计元素，源代码，测试用例之间建立起链接，而这种可跟踪

性要求每项需求都必须以一种结构化的，粒度好（fine-grained）的方式编写

分配优先级：应当对所有的需求分配优先级，如把所有需求都看作同样重要，那么项目管理者在开发或

节省预算或调度中丧失控制自由度

软件测试的需求标准是什么？

文档版本信息：包含文档版本，作者，完成日期，修改需要加上的修订记录（版本号，修订者，日期，内容）

目录结构要清晰：不同级别的标题要区分字号

产品架构：一般只有功能以及信息架构

功能：一级，二级，三级功能都要划分出来，以及产品特性（功能列表，原型界面，详细设计）

请写一下W模型图

需求分析--概要分析--详细分析--编码实现--模块集成--系统构建--系统安装

需求测试--概要测试--详细测试--单元测试--集成测试--系统测试--验收测试

W模型图

软件质量的特性是什么？

功能性：软件需求要满足用户显示或者稳式的功能

易用性：软件易于学习和上手

可靠性：软件必须实现需求当中指定的具体功能

效率性：类似于软件的功能

可维护性：需求软件具有功能将某个功能修复之后继续使用的功能