软件测试常见的问题
1，B/S架构和C/S架构区别
B/S 只需要操作系统和浏览器就⾏，可实现跨平台，客户端零维护，个性化能⼒低，响应速度慢。
C/S 响应速度快，安全性⾼，⼀般⽤于局域⽹，因为要针对不同的操作系统需要针对性的开发，并且维护成本⾼
2，HTTP协议
超⽂本传输协议，应⽤层协议，由请求与响应组成。
常见的请求⽅式有POST/GET，常见的状态码200ok，301永久移动，302临时移动，404不到资源，500服务器内部错误。
3，POST与GET区别
1，get是不安全的，因为在传输过程中数据被放在请求的URL中；post所有操作对⽤户来说都是不可见的。
2，get传输量⼩，这主要是因为受URL长度限制；post传送的数据量较⼤，⼀般被默认为不受限制。
3，get限制form表单数据集的值必须为ASCII字符；⽽post⽀撑整个IS010646字符集。
4，get执⾏效率却⽐post⽅法好。Get是form提交默认⽅法。
4，Cookie和Session的区别与联系
1、Cookie和Session都是会话技术，Cookie是运⾏在客户端，Session是运⾏在服务器端。
2、Cookie有⼤⼩限制以及浏览器在存cookie的个数也有限制，Session是没有⼤⼩限制和服务器的内存⼤⼩有关。
3、Cookie有安全隐患，通过拦截或本地⽂件得到你的cookie后可以进⾏攻击。
4、Session是保存在服务器端上会存在⼀段时间才会消失，如果session过多会增加服务器的压⼒。
5，测试的⽬的
发现软件的缺陷与漏洞，对软件的质量进⾏评估，提升软件质量。
6，软件测试原则
1，测试显⽰软件是否存在缺陷
2，穷尽测试时不可能的
3，测试尽早介⼊
4，缺陷集性
5，杀⾍剂悖论
6，测试活动依赖于测试内容
7，没有错误是好是谬论
7，软件测试分为哪⼏个阶段？
单元测试：⽐如说对Java中的类和⽅法的测试，⼀般由软件开发⼈员实施（尽可能保证测试⽤例相对独⽴，测试过程中不要调⽤其他类的⽅法，⽽是在测试⽤例中重写模拟⽅法）
集成测试：（测试各个单元模块的接⼝）在单元测试的基础上，把软件单元按照***\*概要规格说明书\****要求，组装模块，测试看是否模块达到了规格技术指标。
系统测试：（⿊盒测试）在经过集成测试的单元模块，按照整体***\*需求规格说明书\****，进⾏⼀套有效严格的测试，保证软件的正常运⾏。（集成测试偏重于技术⾓度，系统测试偏重于业务⾓度）
回归测试：（回归测试在测试⽣命周期中是很重要的⼀部分，会进⾏多次回归测试），是指在发⽣修改之后，再重新回去测试⼀下，避免修改的内容导致了其他的错误。验证之前出现过但已修复好的缺陷不再重新出现。
冒烟测试：（是⾃由测试的⼀种）是指开发者功能完成后的完整性功能测试，发现问题后反馈给开发者进⾏修改，然后看这次修改是否真的修复解决了这bug，或者对其他模块造成了影响，这个时候就需要冒烟测试来进⾏验证，缺点就是覆盖率低。
验收测试：也叫交付测试，是针对⽤户需求、业务流程进⾏的整体测试，确认是否满⾜验收标准，由⽤户、客户看是否接受系统，可以部署上线。
Alpha测试：⽤户在开发者的场所进⾏测试，是⼀个可控的环境中测试的。
Beta测试：是⽤户在对软件产品进⾏测试，开发者不在现场，⽤户对测试过程中遇到的bug进⾏记录，开发并对它进⾏修改，再测试，直到⽤户觉得可以了，就部署上线。
8，单元测试与集成测试的侧重点
单元测试是对程序最⼩可测试的模块进⾏测试
集成测试是把各个模块连接起来时，穿越模块接⼝的数据是否会丢失。
9，系统测试范围
功能测试、⽤户体验测试、性能测试、UI测试、兼容性测试、安装测试、⽂档测试、稳定性测试等
10，a测试与ß测试的区别
a测试：公司组织的内部⼈员进⾏的测试
ß测试：公司组织的典型客户在实际⽣活中使⽤。
11，验收测试怎么做？
在UAT测试之前，我们会制定测试⽅案，选择基线⽤例，即级别⾼的⽤例，在UAT测试环境上进⾏测试，如果测试通过，验收测试就通过了。
12，⽩盒、⿊盒和灰盒测试区别
⽩盒测试：对程序的内部结构与算法进⾏的测试
⿊盒测试：不考虑程序的内部结果，只检查程序是否实现了需求的功能
灰盒测试：关注系统接⼝所实现的功能，是否和需求⼀致。
13，冒烟测试的⽬的
检查程序的基本功能是否正常
14，回归测试怎么做？
⾸先，把bug单对应的⽤例执⾏⼀遍，还要检查有数据交互的模块会不会受影响，有没有引⼊新的问题；项⽬上线前，还要把当前版本的重要功能以及冒烟测试的⽤例都回归⼀遍，确保重要功能上线后不出问题。
15，全部回归与部分回归的区别？
全量回归：对软件的新版本测试时，重复执⾏上⼀个版本测试时使⽤的测试⽤例，防⽌以前没有的问题现在出问题了
部分回归：当开发修复某个bug时，我们需要去检查该bug是否被修复，还需要检查与之相关联的模块是否受到影响。
16，需求分析的⽬的
澄清需求，提取测试点
17，测试计划的⽬的
规范软件测试内容⽅法和过程
18，什么时候开始写测试计划
需求分析之后
19，由谁来编写测试计划
测试经理或者是测试组长来编写
20，测试计划的内容
1.简介
2.参考⽂档和提交⽂件
3.进度安排
4.测试资源
5.严重程度和优先级
6.风险分析
7.测试策略
21，结束条件(项⽬上线的条件)
需求的覆盖率、⽤例的执⾏率和缺陷的遗留率达到质量⽬标。
通常来说：需求覆盖率和⽤例执⾏率需要达到100%
致命/严重的缺陷需要当天解决，轻微/⼀般遗留率不得超过30%
22，常见的测试风险
进度风险、质量风险和需求变更
23，测试⽤例的要素
⽤例编号,⽤例名称，级别，预置条件，测试步骤，期望结果
24，测试⽤例级别的划分
优先级⼀般都是和缺陷的严重程度对应的。
⼀般可以把优先级分为三种：
⾼（Highs）：保证功能性是稳定的，是按照需求的正常使⽤和实现点进⾏⽤例设计的，重要的错误和边界测试的测试⽤例的集合。
中（Mediums）：更全⾯的验证功能的各⽅⾯，包括流程中的各个节点出错情况、异常情况测试、中断、UI展⽰、⽤户体验等⽅⾯的测试⽤例设计
低（Lows）：不常被执⾏的测试⽤例。⽐如压⼒和性能测试⽤例设计，接⼝测试⽤例设计随着时间的推移已经从低级别变化到了中级别。
我们将测试⽤例分成：⾼，中和低。
25，怎样保证覆盖⽤户需求？
项⽬开始前，我们会先熟悉需求，画好流程图，保证整个流程都覆盖全⾯，⼩组之间每个⼈都要根据各⾃的流程图，各个功能点有哪些限制条件，来讲解⼀下⾃⼰对测试点的理解，防⽌之后编写测试⽤例时出现遗漏；⽤例编写完之后，再进⾏⽤例的评审，看看测试点有没有⽤遗漏，对需求理解有没有错误，测试场景是否覆盖完全。
26，写好测试⽤例的关键 /写好⽤例要关注的维度
1. 覆盖⽤户的需求；
2. 从⽤户使⽤场景出发，考虑⽤户的各种正常和异常的使⽤场景；
3. ⽤例的颗粒⼤⼩要均匀。通常，⼀个测试⽤例对应⼀个场景；
4. ⽤例各个要素要齐全，步骤应该⾜够详细，容易被其它测试⼯程师读懂，并能顺利执⾏；
5. 做好⽤例评审，及时更新测试⽤例。
27，测试⽤例的状态
No Test 未执⾏状态
Pass 通过状态前端测试和后端测试的区别
Fail 失败状态
Block 阻碍状态
Investigate 观察中状态
28，常见的测试⽤例设计⽅法
等价类划分：多⽤于输⼊框：注册/登录
边界值：多和等价类划分结合使⽤，有边界限制的：注册的密码长度（掌握上点和离点的取值）
场景法：从基本流开始，再将基本流和备选流结合起来，可以确定⽤例场景
正交表：⽤于多个下拉框之间的组合，可以通过正交助⼿⽣成测试⽤例
错误推测：错误猜测法是测试经验丰富的⼈喜欢使⽤的⼀种测试⽤例设计⽅法。⼀般这种⽅法是基于经验和直觉推测程序中可能发送的各种错误，有针对性地设计。只能作为⼀种补充
因果图：因果图法⽐较适合输条件⽐较多的情况，测试所有的输⼊条件的排列组合。所谓的原因就是输⼊，所谓的结果就是输出
29，判定表⽤在哪些时候/哪些功能
· 判定法，是⽤在不同的输⼊组合，可能会产⽣不同的输出这种情况，⽐如，⼀个有多个查询条件的查询功能，输⼊不同的查询条件组合，输出的结果是不⼀样的，这样的功能就要⽤到判定表
30，什么时候⽤到场景法
· 使⽤场景法通常是在冒烟测试中或者 ⼀些流程性⽐较强的软件/功能(⽐如安装，卸载等等)
31，测试环境怎么搭建的？
1、搭建测试环境，确定测试⽬的
测试环境尽可能的模拟真实环境
确保环境⽆毒
营造独⽴的测试环境
构建可复⽤的测试环境
2、安装依赖软件
  拿python项⽬举例
    安装python3、pymysql、redis等需要的⼯具。
    导⼊Django、pymysql、redis等需要的第三⽅模块
  拿Java项⽬举例
    安装JDK、tomcat、数据库等需要的⼯具。
3、拉取代码
  需要知道SVN地址或者Git地址
4、修改配置⽂件
  修改数据库、redis等配置⽂件的配置信息，修改成测试环境的配置信息
5、编译、打包（python不需要编译直接可以运⾏，如果是Java、c、 c++需要编译）
6、导⼊基础数据
  建表、导⼊管理员账号之类的信息，即把sql在测试数据库执⾏⼀次
7、启动程序。
32，偶然性问题的处理
1. 发现bug之后，我们会先截图，如果确定是偶然性的问题，会将⽇志和截图⼀起提单给开发定位；
2. 如果缺陷在当前版本⽆法复现，且缺陷的影响程度⽐较低，可以提交问题单进⾏跟踪，跟踪三个版本，如果后三个版本都⽆法复现，
就可以关闭该缺陷；
3. 如果是很严重的Bug，⽐如导致系统崩溃等，并且，实在没有再次出现，除了要及时反馈给上级之外，最后还要写到测试报告中，说
明出现了什么现象，但⽆法再现！
33，当我们认为某个地⽅是bug，但开发认为不是bug，怎么处理？
1. 先跟开发沟通，确认系统的实际结果是不是和需求有不⼀致的地⽅；有些地⽅可能需求没提及，但是⽤户体检不好，我们也可以认为
是bug。
2. 如果开发以不影响⽤户使⽤为理由，拒绝修改，我们可以和产品经理，测试经理等⼈员进⾏讨论，确定是否要修改，如果⼤家都⼀致
认为不⽤改，就不改。
34，产品在上线后⽤户发现bug，这时测试⼈员应做哪些⼯作？
1. 测试⼈员复现问题后，提交问题单进⾏跟踪；
2. 评估该问题的严重程度，以及修复问题时的影响范围，回归测试需要测试哪些功能；
3. 问题修复后，先在测试环境上回归，通过后再在⽣产环境上打补丁，然后再进⾏回归测试；
4. 总结经验，分析问题发⽣的原因，避免下次出现同样问题。
35，⼆⼋定理
80%的缺陷出现在 20%的模块。
36，如何跟踪缺陷
当发现缺陷后，我们要在禅道上提交问题单给开发，并每隔⼀段时间(间隔⼀个⼩时，或两个⼩时都可以)去检查缺陷是否被处理，如果没及时处理，就要提⽰开发，让开发及时修复问题，问题修复后，要及时进⾏回归测试。
37，缺陷的状态
激活，确认，已解决，关闭
38，缺陷的等级
致命，严重,⼀般，轻微
39，缺陷单应该包含这些要素
缺陷标题，缺陷描述，重现步骤，预期结果，实际结果，缺陷优先级，缺陷严重程度，附件
40，测试报告的主要内容
⼈⼒投⼊，⽤例统计，问题单分类统计，遗留bug情况，测试风险，测试对象评估，测试结论
41，如何定位bug：
1. 检查测试环境配置是否有问题，测试数据是否有问题
2. ⽤fiddler抓包，分析请求和响应数据是否存在问题
3. 查看应⽤服务器的⽇志
4. 然后再查看数据库的数据是否存在问题
42，开发没时间修复，如何推进bug的修复：
1. 和开发说明该问题的严重性，会怎样影响产品的正常使⽤，如何还是坚持不改，就上报领导，让领导辅助推进；
2. 确认问题的严重程度，如果影响不⼤，不是⾮要改的bug，并且修复风险⽐较⼤，和领导商量后，如果认为暂时可以不⽤修复，也可
以不修复。
43，软件测试流程
⽴项(确定项⽬)--编写需求(需求⼈员)--需求评审(编写需求⼈员发起)--开发编写概要和详细设计(编码并⾃测[开发环境])
测试：测试⽤例-测试⽤例评审(测试⼈员发起)--部署环境--冒烟测试(通过)--提交bug--回归测试(测试报告)--验收测试--上线
44，项⽬介绍
我们⼀般在项⽬进⾏开⽴项会【产品经理 项⽬经理 开发⼈员 测试⼈员】的时候进⾏参与，
讨论需求并提出建议，在⽴项会中制定需求⽂档，由ui设计原型图，开发根据需求⽂档进⾏编码，
我们测试会根据需求⽂档进⾏编写 测试计划，根据模块的（颗粒度）划分并编写测试⽤例以及对⽤例的评审，
开发结束侯测试对主要功能进⾏冒烟测试，执⾏测试⽤例，提交bug 开发进⾏修改，修改成功后关闭bug，
进⾏回归测试，在上线前进⾏测试总结。
45，对⼀⽀圆珠笔进⾏测试，要从哪些⽅⾯进⾏测试？

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。