软件测试基础理论全集

1，B/S和C/S架构的区别？
从测试的角度来讲。B/S架构需要重点考虑系统在不同的浏览器中的兼容性问题；C/S 架构需要考虑系统在不同平台的安装、卸载、升级。
B/S 即Browser/Server(浏览器/服务器)结构,指浏览器和服务端，在客户机端不用装专门的软件，只要一个浏览器即可。
C/S 即Client/Server(客户机/服务器)结构,指客户机和服务端，在客户机端必须装客户端软件后才能访问服务器。

2，对HTTP协议怎么理解的？
http协议是应用层的一个数据传输协议，由请求和响应构成，主要的请求方式有get和post两种，get请求的请求数据在请求头，post请求的请求数据在请求体，响应的数据也包含响应头和响应体。

3，常见的http状态码？
200 请求成功 用于get/post请求
301 永久移动
302 临时移动
404 服务器无法找到资源，网页丢失
500 服务器内部错误

4，http请求头包含哪些信息？
content-type （作用：定义网络文件的类型和网页的编码 ）
accept （作用：发送端（客户端）希望接受的数据类型）

5，get和post的区别？
get 请求数据参数放在请求头传送，请求地址长度有限制，一般用在获取数据。
post请求数据参数放在请求体传送，请求地址没有长度限制，一般用在提交数据。

6，什么是软件测试？
软件测试就是使用软件，站在用户的角度，模拟各种正常的和异常的场景来使用软件

7，回归测试怎么做？
首先，把bug单对应的用例执行一遍，还要检查有数据交互的模块会不会受影响，有没有引入新的问题；
项目上线前，还要把当前版本的重要功能以及冒烟测试的用例都回归一遍，确保重要功能上线后不出问题。

8，验收测试怎么做？
1）非正式的验收测试：
а测试，软件开发公司组织内部人员模拟各类用户行为对即将上市的产品进行测试。
ß测试，软件开发公司组织各方面的的典型客户在日常工作中实际使用，并要求用户报告异常情况、提出改进意见，然后公司再进行完善。
2）正式的验收测试：
在UAT测试之前，我们会制定测试方案，选择基线用例，即级别高的用例，在UAT测试环境上进行测试，如果测试通过，验收测试就通过了。

9，黑盒测试，白盒测试和灰盒测试的区别？
黑盒测试(Black box)把软件看成一个黑盒子，在完全不考虑程序内部逻辑的情况下，检查程序是否满足用户需求。
白盒测试(White box) 对程序内部结构和算法进行测试。必须先全面熟悉程序内部逻辑结构，然后编写程序，对所有逻辑路径进行测试的一种方法。
灰盒测试(Gray box)关注系统接口所实现的功能，是否和需求一致。

10，冒烟测试不通过，怎么处理？
当开发写完代码，编译好后，会提交到测试部进行测试时。测试人员搭建好环境，首先要对系统的基本功能进行测试，保证主要流程的能正常使用，这叫冒烟测试。如果冒烟测试不通过，就打回给开发人员修改。

11，测试一个软件，应该从那些角度考虑？
功能，安全性，用户体验，兼容性，性能，可靠性

12，怎么做测试需求分析？
1）澄清需求（小组讨论/开会：讨论需求是否正确，是否合理，是否有异议，是否有遗漏）
参与人员：测试，开发，BA，测试经理
2）提取测试点

13，测试计划的内容有哪些？
被测试项目的背景、测试范围和测试策略、测试环境、测试开始和结束条件、进度安排，测试组织，以及与测试有关的风险等方面的内容

14，软件测试结束的标准是什么？
需求覆盖率、用例执行率、缺陷遗留率达到预定质量目标。一般来说，需求覆盖率100%；用例执行率要达到100%；致命、严重级别的缺陷必须当天解决，一般、轻微级别的缺陷，遗留率是30%以下。

15，测试用例设计方法有哪些？
等价类
边界值
错误推测方法
判定表
场景法

16，怎样才能写好测试用例？
覆盖用户的需求；
从用户使用场景出发，考虑用户的各种正常和异常的使用场景；
用例的颗粒大小要均匀。通常，一个测试用例对应一个场景；
用例各个要素要齐全，步骤应该足够详细，容易被其它测试工程师读懂，并能顺利执行；
做好用例评审，及时更新测试用例。

17，用例评审有哪些人参与？
测试人员，开发，产品经理（BA）

18，用例的执行结果有哪些？
当用例还尚未被执行时，是No Test未执行状态
当执行结果与预期结果相符时，是Pass通过状态
当执行结果与预期结果不符时，是Fail失败状态
当因为软件有缺陷而妨碍了用例步骤的执行，且该缺陷并不是我们的测试点，则用例是Block阻碍状态。
当用例正在执行中，但是需要耗较多时间去观察其结果，是Investigate观察中状态。

19，测试用例由哪些要素组成？
用例编号(ID)
用例标题
用例级别
用例的预置条件
用例的测试步骤
用例的预期结果

20，用例的优先级怎么确定？
依据用户使用该场景的频率，和该功能对系统的影响程度来确定

21，怎么保证覆盖用户需求？
项目开始前，我们会先熟悉需求，画好流程图，保证整个流程都覆盖全面，
小组之间每个人都要根据各自的流程图，各个功能点有哪些限制条件，来讲解一下自己对测试点的理解，防止之后编写测试用例时出现遗漏；
用例编写完之后，再进行用例的评审，看看测试点有没有遗漏，对需求理解有没有错误，测试场景是否覆盖完全。

22，抓包工具的作用？
1）统计web前端单功能的响应时间
2）检查敏感信息是否加密

23，软件测试流程是怎样的？(软件测试生命周期是什么)
需求分析–需求评审–测试计划–测试用例–用例评审–搭建测试环境—测试执行–回归测试–测试报告

我们这个项目是两个人负责测试的，按模块进行分工，我负责xxx模块。
项目启动后，我们会到服务器上下载相关的需求文档，熟悉项目的流程，进行需求澄清，提取测试点；
然后编写测试用例，再进行组内的评审，修改，定稿；等开发转测后，我们从svn上获取安装包，搭建测试环境；
之后我们开始进行冒烟测试，冒烟通过后，我们就进入SIT测试，之后进行UAT用户验收测试，验收通过后，编写测试报告。
产品发布上线，我们也要参与项目上线的基本功能验证。

24，开发认为不是bug,你认为是bug，怎么处理？
先跟开发沟通，确认系统的实际结果是不是和需求有不一致的地方；
有些地方可能需求没提及，但是用户体检不好，我们也可以认为是bug。
如果开发以不影响用户使用为理由，拒绝修改，我们可以和产品经理，测试经理等人员进行讨论，
确定是否要修改，如果大家都一致认为不用改，就不改。

25，偶然性问题怎么处理？
1、在测试执行过程中，一旦系统出现异常信息，我们第一时间要做的是截图，保留证据；
2、确定是偶然性的bug之后，收集相关的日志，连同截图一起提单给开发定位；
3、如果没有日志记录，缺陷在当前版本无法复现，且缺陷的影响程度比较低，
可以提交问题单进行跟踪，跟踪三个版本，如果后三个版本都无法复现，就可以关闭该缺陷；
4、如果这些不可复现的Bug是很严重的Bug，比如导致系统崩溃等，并且，实在没有再次出现，
除了要及时反馈给上级之外，最后还要写到测试报告中，说明出现了什么现象，但无法再现！

26，缺陷怎么跟踪？
当发现缺陷后，我们要在禅道上提交问题单给开发，并每隔一段时间(间隔一个小时，或两个小时都可以)去检查缺陷是否被处理，
如果没及时处理，就要提示开发，让开发及时修复问题，问题修复后，要及时进行回归测试。

27，缺陷包含哪些要素？
缺陷标题，严重级别，问题所属模块，复现步骤，预期结果，实际结果，有关的日志和截图。

28，缺陷等级有哪些，怎么划分？
4–致命 软件无法运行，或者软件的主要功能丧失，比如：系统无法注册，频繁闪退。
3–严重 –软件的次要功能丧失，或者主要功能在一些特定情况下会出错 ，比如，金额计算错误
2–一般 –软件在某些情况下会出错，但是造成的后果影响不大，比如：关键字输入%进行搜索，能把系统所有数据都搜索出来。
1–轻微 在某些情况下会出错，但是造成的后果影响很小，比如：表格显示错位。

29，产品上线后，用户发现了bug，应该怎么处理？
测试人员复现问题后，提交问题单进行跟踪；
评估该问题的严重程度，以及修复问题时的影响范围，回归测试需要测试哪些功能；
问题修复后，先在测试环境上回归，通过后再在生产环境上打补丁，然后再进行回归测试；
总结经验，分析问题发生的原因，避免下次出现同样问题。

30，缺陷有哪些状态？
激活 测试中新报告的软件缺陷，等待分派 或 回归测试没通过，也可以设置为 激活 状态
确认 已确认的缺陷，等待开发人员修改
已解决 已经被开发人员修改的缺陷，等待测试人员校验
关闭 已经被测试人员确认得到正确修复，可以关闭

31，测试环境怎么搭建？
搭建环境前，开发都会给到我们一份系统发布手册，我们会根据这个手册来搭建。
比如，我这个xx系统，是搭建在Linux系统下的，web服务器用的是Tomcat8，MySQL版本是5.7，程序是JAVA编写的，
首先我们向开发拿到编译好的安装包，
然后用xshell(或CRT)远程连接Linux系统，把tomcat服务器停掉，把程序包放到webapps目录下，
然后再启动tomcat服务器就可以了

32，什么是软件测试？
在规定的条件下对程序进行操作，以发现程序的错误，并对软件质量进行评估。

33，为什么要开展软件测试？
发现软件缺陷与错误，对软件质量进行度量和评估，以提高软件的质量。

34，测试计划工作的目的是什么？
编写测试计划，能够更有效的量化自己的工作量，明确每个时间点需要完成什么，是测试能够更有序的进行。

35，软件测试的原则？
所有的软件测试都应追溯到用户需求。
应当尽早地和不断地进行软件测试。
完全测试是不可能的，测试需要终止。
充分注意测试中的群集现象。
程序员应避免检查自己的程序。
尽量避免测试的随意性。

36，测试报告内容？
数据统计、遗留bug情况、测试风险、测试对象评估、测试结论

37，系统测试包含哪些测试类型？
功能测试、用户体验测试、性能测试、UI测试、兼容性测试、安装测试、文档测试、稳定性测试等