一些问题

1、B/S架构和C/S架构区别

     Bs只要有操作系统和浏览器就可以完成，可以实现跨平台客户端零维护，但速度慢效率低。

     CS效率高速度快，多用于局域网中，因为针对不同的操作系统需要针对性的开发，且维护成本高

 

2、HTTP协议     

      HTTP（HyperText Transfer Protocol）即超文本传输协议，是一种详细规定了浏览器和万维网服务器之间互相通信的规则，它是万维网交换信息的基础，它允许将HTML（超文本标记语言）文档从Web服务器传送到Web浏览器。

1. HTTP协议（HyperText Transfer Protocol，超文本传输协议）是因特网上应用最为广泛的一种网络传输协议，所有的WWW文件都必须遵守这个标准。
2. HTTP是基于TCP/IP通信协议来传递数据（HTML 文件, 图片文件, 查询结果等）
3. HTTP协议通常承载于TCP协议之上，有时也承载于TLS或SSL协议层之上，这个时候，就成了我们常说的HTTPS。
4. HTTP是一个应用层协议，由请求和响应构成，是一个标准的客户端服务器模型。HTTP是一个无状态的协议。
5. HTTP默认的端口号为80，HTTPS的端口号为443。
6. HTTP1.0 定义了三种请求方法： GET, POST 和 HEAD方法。
7. HTTP1.1 新增了五种请求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。   

3、GET与 POST区别

    GET一般情况下用作获取数据，POST用作提交数据。 

    GET比 POST快，效率高。

    GET传输时将数据放在URL中， POST 数据不会显示在URL中，安全性相对较高。

    GET对数据类型的限制: 只允许ASCII 字符，POST对数据类型没有限制。

    GET 请求可被缓存可以被收藏为书签，POST不能被收藏为书签。

4、Cookie和Session的区别与联系

    session和cookie的作用有点类似，都是为了存储用户相关的信息。

    不同的是，cookie是存储在本地浏览器，易伪造、不安全，而session存储在服务器。存储在服务器的数据会更加的安全，不容易被窃取。

    cookie最大存储为4k而一个站点最多可以存储20个cookie，Session存储量较大但session过多时会消耗服务器资源。

   Cookie 只能保存ASCII字符串，如果是Unicode字符或者二进制数据需要先进行编码，Session能够存取很多类型的数据，包括String、Integer、List、Map等。

4、测试的目的

        1、软件测试是为了发现错误而执行程序的过程。

        2、测试是为了证明程序有错，而不是证明程序无错，发现错误不是唯一目的。

        3、一个好的测试用例在于它发现至今未发现的错误。

        4、一个成功的测试是发现了至今未发现的错误的测试。

   

5、软件测试原则

    1. 测试显示软件存在缺陷

    2. 穷尽测试是不可能的

    3. 测试尽早介入

    4. 缺陷集群性（2/8 原则）

    5. 杀虫剂悖论

    6.测试活动依赖于测试内容

    7.没有错误是好是谬论

 

6、软件测试分为哪几个阶段？

一般来说分为 5 个阶段：单元测试、集成测试、确认测试、系统测试、验收测试

 

 

7、单元测试与集成测试的侧重点

 

单元测试：是指对软件中的最小可测试单元进行检查和验证    

集成测试：是指将通过测试单元模块组装成系统或者子系统，再进行测试，重点测试不同模块的接口部分。

 

 

8、系统测试范围

 

    指的是将整个软件系统进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行测试。

 

9、a测试与ß测试的区别

α测试是指软件开发公司组织内部人员模拟各类用户对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的 用户操作方式。经过α测试调整的软件产品称为β版本。

β测试是由软件的多个用户在实际使用环境下进行的测试，这些用户返回有关错误信息给开发者。测试时，开发者通常不在测试现场。因而，β测试是在开发者无法控制的环境下进行的软件现场应用。在β测试中，由用户记下遇到的所有问题，包括真实的以及主观认定的，定期向开发者报告。β测试主要衡量产品的FLURPS，着重于产品的支持性，包括文档，客户培训和支持产品生产能力。 只有当α测试达到一定的可靠程度时，才能开始β测试。它处在整个测试的最后阶段。同时，产品的所有手册文本也应该在此阶段完全定稿。

 

10、验收测试怎么做？

 

软件开发人员和QA（质量保证）人员也应该参加。由用户参加设计测试用例，使用用户界面输入测试数据，并分析测试的输出结果。一般使用实际数据进行测试。

 

11、白盒、黑盒和灰盒测试区别

 

 

黑盒测试:软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试

灰盒测试:灰箱测试就像黑箱测试一样是通过用户界面测试，但是测试人员已经有所了解该软件或某种软件功能的源代码程序具体是怎样设计的。甚至于还读过部分源代码。 因此测试人员可以有的放矢地进行某种确定的条件/功能的测试。这样做的意义在于:如果你知道产品内部的设计和对产品有透过用户界面的深入了解，你就能够更 有效和深入地从用户界面来测试它的各项性能。

白盒测试:软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试

12、冒烟测试的目的

    针对每个版本或每次需求变更后，在正式测试前，对产品或系统的一次简单的验证性测试，为正式测试前，验证是否产品或系统的主要需求或预置条件是否存在bug或已经实现。

13、回归测试怎么做？

测试的重点：bug修改，关联功能，新增加功能，修改功能，上一轮测试bug多的功能。（测试人员要了解开发在这一轮修改了哪些bug，要注意关注我们的bug管理工具上的变化。）

如何做好回归：1.变换测试人员，回归比较繁琐，可以通过测试人员的轮流进行减轻一个人做回归的厌倦，

2.使用自动化。

 

14、全部回归与部分回归的区别？

     全量回归：对软件的新版本测试时，重复执行上一个版本的测试时使用的测试用例，防止以前没有的问题现在出现问题了。

      部分回归：当开发修复某个bug时，我们需要去检查该bug是否被修复，还需要检查与之相关联的模块是否受到影响。

15、需求分析的目的

    需求分析是软件计划阶段的重要活动，也是软件生存周期中的一个重要环节，该阶段是分析系统在功能上需要“实现什么”，而不是考虑如何去“实现”。需求分析的目标是把用户对待开发软件提出的“要求”或“需要”进行分析与整理，确认后形成描述完整、清晰与规范的文档，确定软件需要实现哪些功能，完成哪些工作。此外，软件的一些非功能性需求(如软件性能、可靠性、响应时间、可扩展性等)，软件设计的约束条件，运行时与其他软件的关系等也是软件需求分析的目标。

16、测试计划的目的

     编写软件测试计划的目的是指导测试组成员进行工作和让测试组以外的项目成员了解测试工作的。

17、什么时候开始写测试计划

    对于测试来说，有一个测试计划很重要，可以指导和督促测试任务的实施，是在对你所要测试的对象有了一定了解之后测试进行之前。

18、由谁来编写测试计划

      一般是由测试经理或者测试组长来编写

19、测试计划的内容

    测试目的和测试项目简介、测试参考文档和测试提交文档、术语和定义、测试策略、确定测试内容、资源、测试进度、测试员的职责与任务分配、项目通过或失败的标准、暂停和重新启动测试的标准、风险和问题等。

20、结束条件(项目上线的条件)

软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求。
(2) 在验收测试中发现的错误已经得到修改，各级缺陷修复率达到标准
(3) 所有测试项没有残余紧急、严重级别错误。
(4) 需求分析文档、设计文档和编码实现一致。
(5) 验收测试工件齐全（测试计划、测试用例、测试日志、测试通知单、测试分析报告，待验收的软件安装程序。）

(1) 紧急、严重级别错误修复率应达到100%;
(2) 普通级别错误修复率应达到95%以上;
(3) 优化级别错误修复率应达到60%以上;
注：项目紧急时，普通级别错误修复率达60% 以上；优化级别错误修复率达20% 即可。

 

21、常见的测试风险

1.需求风险

a. 需求变更：需求变更导致开发、测试部分工作失效，维护成本增加

2. 缺陷风险

a.偶现缺陷，较难重现，容易被遗漏；

b.缺陷跟踪不够积极主动，没有做好缺陷记录和跟踪，导致上线遗漏

3. 代码质量风险

a.人员经验不够丰富

b. 人员对业务理解不够

c.系统架构设计不足，导致扩展性不足，性能兼容差等问题

4. 测试环境风险

测试环境同线上环境配置并别较大，测试环境问题在线上重不了

5. 测试技术风险

a. 人员能力不足

b. 人员技术能力差，效率低，该用自动化替代的工作，没有时间和能力

6. 研发流程风险

必须经过测试无问题后再提交线上等

22、测试用例的要素

1.用例编号  2.用例类型  3.测试项目  4.用例标题  5.重要级别  6.预置条件  7.测试输入  8.操作步骤  9.预期结果   10、实际结果

23、测试用例级别的划分

优先级一般都是和缺陷的严重程度对应的。

一般可以把优先级分为三种：

高（Highs）：保证功能性是稳定的，是按照需求的正常使用和实现点进行用例设计的，重要的错误和边界测试的测试用例的集合。

中（Mediums）：更全面的验证功能的各方面，包括流程中的各个节点出错情况、异常情况测试、中断、UI展示、用户体验等方面的测试用例设计

低（Lows）：不常被执行的测试用例。比如压力和性能测试用例设计，接口测试用例设计随着时间的推移已经从低级别变化到了中级别。

 

24、怎样保证覆盖用户需求？

当测试用例设计完成后，要组织测试用例的评审，这样可以吸取别人的意见，减少遗漏，补全测试用例。

测试用例执行100%覆盖。
在测试执行过程中，要继续对测试用例补充完善，确保提高测试覆盖率。

五、通过技术手段监控覆盖率
可以使用jacoco进行代码覆盖率的验证，也就是说我们在做功能测试过程中，通过jacoco我们能拿到我们测试的功能点覆盖到了代码的那些分支，是否覆盖全了，
覆盖了具体百分之多少，然后再重新弥补测试用例设计的不足，保障测试覆盖率。

25、写好测试用例的关键 /写好用例要关注的维度

做好测试用例工作的关du键是要充分考虑测试计划zhi的实用性，坚持5W1H的原则，dao采用评审和更新机制以及测试策略。要充分考虑测试计划的实用性，即测试计划与实际之间的接近程度和可操作性。要坚持“5W1H”的原则，明确测试内容与过程。采用评审和更新机制，确保测试计划满足实际需求。因为软件项目是一个渐进的过程，中间不可避免地会发生需求变化，为满足需求变化，测试计划也需要及时地进行变更。测试策略要作为测试的重点进行描述。测试策略是测试计划中的重要组成部分，测试计划是从宏观上说明一个项目的测试需求、测试方法、测试人员安排等因素。

26、测试用例的状态

   通过，失败，未执行，无效，阻塞，不适用

28、常见的测试用例设计方法

等价类划分，边界值，错误推测，因果图，场景法，正交表

应用的场景
    等价类划分
        多用于输入框：注册/登录
    边界值（掌握上点和离点的取值）
        多和等价类划分结合使用，有边界限制的:注册的密码长度，，
    场景法    
        从基本流开始，再将基本流和备选流结合起来，可以确定用例场景   银行取钱
    正交表    
        用于多个下拉框之间的组合，可以通过正交助手生成测试用例
    错误推测
        错误猜测法是测试经验丰富的人喜欢使用的一种测试用例设计方法。
        一般这种方法是基于经验和直觉推测程序中可能发送的各种错误，有针对性地设计。只能作为一种补充
    因果图
        因果图法比较适合输条件比较多的情况，测试所有的输入条件的排列组合。所谓的原因就是输入，所谓的结果就是输出
        自动贩卖机  

 

29判定表用在哪些时候/哪些功能

   判定表方法是黑盒测试方法的一种，主要用于输入和输出比较多，功能逻辑比zhuan较复杂的情况，通过画出判定表缕清需求中的功能逻辑，

 

30、什么时候用到场景法

案例1：ATM取款

   步骤1：熟悉需求，整理业务过程，列出基本流和备选流。

    基本流：成功取款的流程

  识别卡-->输入正确密码-->选“取款”功能-->选择正确的取款金额-->点击“确定”，给出提示，出钞，更新账户和ATM余额

   备选流：取款失败的各个场景

      1）识别卡失败

      2）输入错误密码：

       3次以内--给出提示，重新输入

       3次--锁卡并吞卡

      3）账户余额不足

      4）每次取款上限5000元

      5）每天取款上限20000元

      6）ATM机余额不足

 步骤2：生成场景，填写《场景表》

 步骤3：根据场景，设计测试用例。

   说明：场景和用例不一定是1:1的比例

    有可能1个场景需要多条用例

    也有可能1条用例能测试多个场景

 

31、测试环境怎么搭建的？

   测试环境=软件+硬件+网络+数据准备+测试工具

32、偶然性问题的处理

　一、一定要提交!!

　　1. 记得有这么个缺陷，以后再遇到的时候可能就会了解发生的原因。

　　2. 尽力去查找出错的原因，比如有什么特别的操作，或者一些操作环境等。

　　3. 程序员对程序比测试人员熟悉的多，也许你提交了，即使无法重新，程序员也会了解问题所在。

　　4. 无法重现的问题再次出现后，可以直接叫程序员来看看问题。

　　5. 对于测试人员来说，没有操作错误这条.既然遇到，就是问题。即使真的操作错了，也要推到程序员那里，既然测试人员犯错误，用户也可能会犯同样的错误。错误发生的时候，Tester最大。

　　二、程序不是测试人员写的，出问题也不是测试人员的原因。

　　至于无法重现，可能的原因很多，因为测试人员看到的只是程序的外部，无法深入程序内部，所以把责任推给测试人员是不对的。

　　测试人员的任务只是尽力重现问题，而不是必须重现!!

　　三、下次再遇到的时候，拉他们来看就可以了。

　　因为问题如果无论如何无法重现，程序员确实也没有什么好的解决方法。

　　而且此类问题即使程序员说修改了，测试员也没有好的方法去验证是不是。 : )

　　四、你可以告诉程序员，测试过程是没有错误的。

　　测试人员只是检查程序中可能存在的问题，虽然测试人员使用一定的手段方法努力去覆盖所有的情况，但这些都是理论的推测。在实际中，可能因为人员、环境、配置等种种原因出现各种各样的问题，在测试人员这里发现问题是公司内部的事情，程序发到外面可就是公司的形象问题了。

　　需要让程序员理解，测试人员是帮助他们的，不是害他们的。

　　客户那里发现问题比测试员发现问题结果要严重的多。

　　五、测试部门是独立与开发部门的呀，真的打交道，也是经理对经理。

　　在我们这里，工作上面的事情，和程序员相互只能商议解决，并没有谁高谁低。

　　问题无法重现，也要提出，程序员那里可以回复无法再现。问题放在那里，等到再次出现的时候，就立刻叫程序员过来查看。

　　实在没有再次出现，最后可以写到报告中，说出现了什么现象，但无法再现(比较严重的问题才如此处理，小问题经理之间商量商量可能就算了)。

　　至于测试人员必须重现bug，你杀了我好了，我每次测试项目都有无法重现的问题，很多我能找到大概的原因，有些根本无法重现(仅仅出现一次)。

　　这种事情是无法避免的，并不能说测试人员无法重现问题，就是工作不到位(哼，程序有bug，是否可以说程序员工作不到位的呀)。

　　六、测试部门要独立，最好不受开发的制约。其实真正要重视，就应该有否决的权利。

　　我们公司就是项目承包，要拿最后的项目尾款，就要测试部签字通过，这样就避免了很多的问题。

　　其实只要自己尽到心就可以了，管别人怎么说呢。

　　七、我们使用的状态有：

　　程序员处理的状态(由测试员提交的Action)：等待处理的，再次出现的。

　　测试员处理的状态(由程序员提交的Action)：已经修改的，暂不修改的，系统限制的，使用错误的，无法再现的。测试员可以修改记录。

　　经理处理的状态(由测试员提交Action)：管理员处理的。经理还可以删除记录。

　　按照比较标准的说法，其实对于缺陷还应该有“等待确认的”、“已经确认的”和“重复提交的”的状态，我们为了省事，统一使用了“等待处理的”。

　　最后结项的时候，缺陷的状态对我们来说有两种，“已经关闭的”(由测试员或经理确认)和“暂不修改的”(比如下一个版本处理等)。

　　呵呵，状态多，有些烦琐，特别是程序员很多的时候都不清楚应该回复什么状态，但我个人觉得对测试人员来说，这些状态比较清晰明了，容易处理。

　　八、一个叫doer_ljy(可战)的网友回复了一些内容，我个人认为不很妥当，就回复了一些内容，绿颜色的是doer_ljy(可战)的内容：

　　关于“无法重现”我看是有这么个问题存在。

 

33、当我们认为某个地方是bug，但开发认为不是bug，怎么处理？

      1.首先我会从自身去经过多次的测试发现BUG出现的次数和频率 记录复现BUG的方式  然后发送给开发人员
2.再根据需求文档来确认是否为BUG
3.如果开发不认为是BUG的将复现BUG的记录和需求文档找产品经理和项目经理来确定是否BUG
4.如果项目经理和产品经理都不认为是BUG  我会将BUG记录在测试文档中  方便在下次评审会上将问题再次抛出

34、产品在上线后用户发现bug，这时测试人员应做哪些工作？

首先要做的是重现这个问题并反馈给研发人员，尽快出patch或者解决方案。

当BUG解决且上线没有问题之后，我们再看后续的处理。

追查原因及处理方法：这个BUG出现的原因是什么。这有分为几种情况：

1）测试环境无法重现：可能是线上的环境造成的BUG或者是测试环境无法模拟的情况。

解决方法：尽量完善测试方法、尽量模拟测试环境、增加线上测试。

2）漏测：

a.测试用例裁剪过度：错误预估优先级或者时间过于紧迫裁剪了用例

解决方法：在后续版本或者其他项目启动时重新评估测试时间，要求专家介入对优先级进行评估，避免此类事件再次发生。

b.测试用例执行期间遗漏：由于测试人员疏忽造成测试用例执行遗漏。

解决方法：调查该名测试人员的整个测试过程的工作情况，并随机抽测其他模块，对该名测试人员进行综合评估，给出结论，是因为偷懒漏测，还是因为负责模块过多漏测，还是有其他原因，对该名测试人员发出警告，对相关测试主管，项目经理，产品经理发出警告。

c.测试用例覆盖不全：由于用例评审的不严格造成的；中途需求变更造成的；由于某些其他因素造成的。

35、二八定理

    80%的缺陷出现在20%的代码中；80%的BUG发现在20%的时间中；80%的花费在20%的错误代码上。

36、如何跟踪缺陷

   1.过程描述
测试人员按照测试用例依次进行，并针对缺陷整个生命周期进行跟踪
2.角色的定义
测试人员:负责具体测试执行及跟踪人员
测试组长:负责测试执行机跟踪包括bug单的一次审阅
项目经理:对测试人员的bug进行审核及分配
开发人员:对分配到个人的bug进行解决
3.状态的定义
新建，确认，解决，重新验证，关闭，重新打开

37、缺陷的状态

  一个Bug由测试人员发现并提交,我们将状态标注为新建;开发人员接收了该
Bug,将Bug的状态修改为已分配(Assigned),表示已经认可;开发人员解决了该
Bug后,就将Bug的状态修改为解决,并发给测试人员回归测试;测试人员对Bug
进行回归测试，如果确实已经解决,就将Bug的状态修改为关闭,否则的话则发给
开发人员重新修改。还要说明的是,Bug是可以“死而复生”的,以前版本已经关闭
的Bug,如果新版本中重新出现,我们就需要将其状态修改为重新打开。

38、缺陷的等级

1.轻微缺陷
轻微缺陷是指对产品外观和下道工序可能会有轻微影响的缺陷
2.一般缺陷
一般缺陷是指不影响产品的运转和运行、不会成为故障起因，但对产品外观和下道工序影响较大的缺陷
3.严重缺陷
严重缺陷是指可以引起易于纠正的异常情况、可能引起易于修复的故障或对产品外观造成难以接受的缺陷。
4.致命缺陷
致命缺陷是指会造成安全问题的各类缺陷

39、缺陷单应该包含这些要素

所属产品，所属模块，当前指派（重要），bug类型，操作系统，重现步骤(重要)，验证程度(重要),优先级(重要)，附件等

40、测试报告的主要内容

测试目标，测试的范围，测试环境，测试结果分析(多少轮测试，测试多少，失败多少，成功占比)，遗留缺陷，测试结论（本次测试涉及xxx个功能点，发现xx个缺陷，其中，xx个已修复，xx个遗留。）测试过程完整有效，系统测试通过

41、如何定位bug：

1、发现bug，首先要查看bug的详细信息，根据描述初步分析是哪个模块哪段代码的问题

　　2、检查引发bug的测试环境、测试代码段和测试数据，排除测试人员的误操作导致的程序异常

　　3、确认测试代码、测试环境和数据都正确后，再进一步分析bug根源。这里就需要看具体的测试业务了，可借助相关的工具进行分析，比如firebug插件等

　　4、如果产品或业务有相关的日志记录，可通过分析日志来确认bug

　　5、当测试人员经过一系列的分析，可以基本确认bug产生的原因后，就可以直接找开发提bug了（注意沟通技巧）

　　6、如果各方面都分析完还不能确认bug的原因，可以找开发一起定位（注意保留bug现场或者可以复现bug场景）

　　7、确认bug后，提单给开发进行bug跟踪。

　　　 问题单上要描述清楚以下信息： 

　　　 具体的测试时间、测试环境、测试场景、测试的具体业务和功能、使用的测试代码和测试数据、测试执行步骤、测试结果、bug现象（最好截图）、日志记录、预期结果、bug确认相关人员等

　　8、跟踪bug，等开发人员修复bug后进行回归测试。（关注bug是否完全修复、有没有对其他功能造成影响、有没有引入新的问题）

42.开发没时间修复，如何推进bug的修复：

1、 开发与测试对bug的定义理解不一致产生的问题，例如暴力操作、非常规操作出现的问题、问题路径深、服务器返回的数据不规范、竞品同样有的问题、个别机型问题等情况，开发可能会不愿意修改。
​
2、 工作流程方面的原因，例如开发有更高优先级的任务没有时间修改、上线时间紧急，来不及修改、开发不关注名下的bug、开发认为目前的实现比产品需求好等情况
​
3、 当然还有个人能力原因，例如找不到好的解决方案、影响范围大、找不到bug原因，没有解决方案、技术实现难，不知道怎么修改等等原因
​
4、 另外还有一些不可抗力的客观因素，例如系统问题，第三方应用问题等等

43.软件测试流程

1.需求分析
2.制订测试用例
3.评审测试用例
4.执行测试
5.提交Bug并推动Bug解决
6.回归测试
7.编写并提交测试报告

44.项目介绍

​1、对项目进行基本介绍

2、说明自己负责测试的模块

3、针对部分模块展开进行说明

 

一. 对项目进行基本介绍
以下就以一个简单的项目进行介绍说明：

最近测试的Tpshop项目是一个B/S架构的Web项目。Tpshop是一个 B2C的电商平台系统，运营模式类似于天猫，京东这些B2C类型网站。
项目系统由前台和后台两部分构成。前台面向购物用户，包括会员、商品展示、购物车、订单、支付、用户中心等系统模块。后台面向经营商家，包括商品管理，会员管理，订单处理等系统模块。
这一部分对项目的基本介绍重点要概况说明项目的基本功能和组成部分。

 

二. 说明自己负责测试的模块
这一步，我们需要向别人说明项目中的哪些模块是自己负责测试的，比如：

我在项目中主要负责前后台会员管理、及前台购物车，订单，支付及后台订单处理相关模块测试。
这一部分需要挑选自己比较熟悉的业务功能模块，因为后续面试的问题可能就出自这些模块。

 

三. 针对部分模块展开进行说明
最后挑选一些有代表性的模块展开说明：

购物车
）购物车基本功能：
添加；删除；跳转详情；编辑商品数量；金额显示
）购物车和其他关联：
用户模块（未登录用户可以添加商品，登录后合并商品到购物车）
商品模块 （商品价格；商品库存）
订单 （订单生成，购物车内对应商品清除）
优惠活动（优惠券）
订单处理
我们项目后台订单处理主体流程是：
 商家确认订单--发货--判断用户是否是线下支付--如果线下支付，就先确认收款，再进行收货；如果是线上支付，直接进入收货---订单处理结束---后续有售后和评价相关流程。
其他：
 商家除了确认用订单，还可以对订单进行取消操作。
7天）。

收货异常或其他情况下还可以进行退款操作。
这里需要注意的是说明的模块或者业务一定要描述的清晰有条理。

45.对一支圆珠笔进行测试，要从哪些方面进行测试？三角形测试用例设计

1.功能测试：
圆珠笔按下是否能正常书写。
​
2.性能测试：
笔芯弹出弹回的快慢。
​
3.负载测试：
连续按，看弹簧能经受多少次伸缩。
​
4.兼容性测试：
看是否可以使用其他笔芯。
​
5.强度测试：
用力过度会有什么影响
​
6.可恢复性测试：
长时间按住弹簧，松开后看弹簧是否可以恢复
​
7.界面测试：
笔的外观，舒适度
​
8.安全性测试：
是否会对使用者造成伤害
​
三角形
​

46.在项目中发现哪些经典bug？什么原因导致的？

​    测试中测到一个印象比较深刻的bug,问题出现在web端的电商平台，展示商品的时候每点击一个商品相应的url=~/productid.html,如果知道productid可以直接在url输入跳转到商品详情，相应的下单的时候会生成一个ordid,订单详情页url=~/ordid.html,于是随意更改了几个ordid试了试，发现可以浏览订单编号存在的别人的订单详情，没有做权限过滤故提交这个bug。

         开发解决方案：在访问订单数据前获取登陆用户信息做权限处理。

47.一个项目完成时，有多个重要的缺陷没有被修复，但是项目负责人说可以不修改，你认为测试是不通过的，请简述你的理由。

​测试是对软件的质量进行把关，如果一个项目仍然有很多的缺陷未被修复，那么从质量的角度上我们会认为这个软件的质量不达标，一般来说缺陷的遗留，是不允许严重致命bug的遗留，轻微和一般的bug遗留率不超过30%。

48.在需求文档不太详细的情况下，如何开展测试？

 1. 解决用户问题或达到用户目标需要具备的条件或能力
 2. 遵守合同、协议、规范或其他要求

49.如何尽快找到软件中的bug?

1.尽快熟悉软件的需求和业务，只有熟悉了产品的业务流程、你才能迅速找出软件中存在的一些重要的缺陷
2.把自己当成用户，把自己当成是用户去使用该系统，比如在使用该系统过程中是这样操作的吗？
3.善于怀疑，不要开发人员的能力
4.不要让程序开发人员的观点：“用户不会进行这样的操作”而说服自己
5.使用完整的流程去测试软件系统，有些子流程在单独测试时没有问题，但按流程走的时候问题就可能出来了。

50.什么是bug？

和预期不一致的软件行为。
​
一个软件行为既可能是bug也可能不是bug，那是因为预期的主体千姿百态。
​
和测试员预期不一致的软件行为。
和程序员预期不一致的软件行为。
和文档预期不一致的软件行为。
和管理者预期不一致的软件行为。
和客户预期不一致的软件行为

51.ATM机吞卡的吞卡现象是不是BUG?

不是
是特意设置的安全措施
防止有人马虎，操作后忘记取走银行卡而被人冒领卡中的钱款
所以特意设置了倒计时，限时内没有取走银行卡就会吞卡

52.如何减少非问题单的提交？

​熟悉项目需求，充分了解各个功能模块的功能、参数、约束条件，弄清存在数据交互的模块之间的数据来源、数据流向
跟产品确认问题是否属于非问题单

53.有个程序，在windows上运行很慢，怎么判断是程序存在问题，还是软硬件系统存在问题？

1、检查系统是否有中度的特征，如：浏览器窗口连续打开，系统中文件图标改成统一图标，CPU使用率保存90%以上等
2、检查软件/硬件的配置是否符合软件的推荐标准
3、确认当前的系统是否是独立，即没有对外提供什么消耗CPU资源的服务，如：虚拟机运行
4、如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的；
5、在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况，

54.你们发现bug会怎么处理。

1、出现bug后，首先截图，查看日志，把对应日志保留下来

2、尝试重现这个bug ，思考这个bug可能产生的原因， 然后每个原因逐步验证，如果重现不出来，可以找开发帮忙 ， 这个步骤是为了准确找到重现bug 的步骤， 开发修改的时候就容易多了，不然又会和开发来来回回扯皮

3、如果实在重现不出来， 还是要提交bug 的， bug单一定要写清楚bug出现的环境， 版本、步骤， 错误截图， 对应的日志， 尽可能多的提供出现bug时的信息， 方便开发定位