0.测试理论

测试理论  day1

计算机常用操作--------------------------------------

1. Windows环境的文件共享、远程访问
    1、新建一个文件夹，设为共享
    2、win键/开始→输入"\\192.168.0.161"
    3、复制到本地

2. SVN的服务端的安装与使用
    1、创建仓库与文件夹
    2、创建用户与设置密码

    Windows查看端口是否被占用： netstat -ano | findstr 8443

3. SVN客户端的安装与使用
    1、检出：checkout 
    2、更新：SVN update    
    3、上传文件：Add → SVN commit
    4、删除文件：delete → SVN commit
    5、修改文件：get lock，修改文件后上传，release lock
    6、解决冲突：选中冲突文件，右键编辑冲突edit conflicts，
            合并后保存，点击Mark as resolved，再commit
    7、清理： clean up
    8、查看服务器内容：repo-browser
    9、修改服务器地址：relocate
    注：操作前首先更新到与服务器版本一致

web基础---------------------------------------------------

4. B/S、C/S架构区别是什么？  需要重点关注什么？
    浏览器/服务器、客户机/服务器。
    B/S架构重点考虑系统在不同的浏览器中的兼容性问题(浏览器的内核不同)，
    C/S架构考虑系统在不同平台的安装、卸载、升级。
        机型、品牌、型号、分辨率、尺寸、系统版本、处理器

    补：常用的浏览器：Chrome、Firefox、360、IE
        常用的服务器：Apache、Tomcat、Nginx、weblogic
        常用的数据库：Oracle、DB2、Mysql、SQLserver、

    注：web项目后端是放在什么容器里面？其实就是问的服务器

5. HTTP协议是什么？
    是一个应用层协议，由请求和响应构成，是一个标准的客户端服务器模型。

6. 请求报文由请求行、请求头、请求体组成
    请求行：请求方式 、请求URL、请求协议及版本
    请求头：Accept：客户端可接受的响应数据类型
            Referer：请求来源，请求从哪个URL来的
            content-type  
    请求体：请求参数   

7. get、post请求的区别：
    1、get一般是从服务器获取数据，post一般是提交数据
    2、get是把请求参数放在请求URL里面传送，post是把请求参数放在请求体中传送
    3、get请求URL长度是有限制的，post没有长度限制

8. cookie、session区别：
    1、cookie存放在客户端浏览器上，session存放在服务器上
    2、cookie大小限制在4k，session默认的超时时间是30分钟
    3、cookie容易被劫持，session在访问较多时影响服务器性能
    4、敏感数据保存在session中，比如用户登录等重要信息

9. 常用的http状态码
    200 OK                        //客户端请求成功
    400 Bad Request               //客户端请求有语法错误，不能被服务器所理解
    401 Unauthorized              //请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用 
    403 Forbidden                 //服务器收到请求，但是拒绝提供服务
    404 Not Found                 //请求资源不存在，eg：输入了错误的URL
    500 Internal Server Error     //服务器发生不可预期的错误
    503 Server Unavailable        //服务器当前不能处理客户端的请求，一段时间后可能恢复正常

10. TCP、UDP区别：
    1、tcp传输数据前要先建立连接，udp是无连接传送；
    2、tcp传输数据是无差错、不丢失、不重复，比较可靠，
        udp尽力交付，不保证可靠交付；
    3、tcp连接是一对一，udp支持一对一，一对多，多对一，多对多。

11. HTTPS和HTTP的区别主要如下：
　　1、https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
　　2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
　　3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
　　4、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

软件研发流程-------------------------------------------------------------

12. 软件的研发流程（软件的生命周期）
    计划 → 需求分析 → 设计 → 编码 → 测试 → 运维

13. 需求规格说明书，又叫需求说明书，也称SRS，即需求文档

14. 项目团队有哪些成员？
    项目经理、产品经理、UI设计师、架构师、开发、测试、运维、DBA、（实施）

15. 测试流程：需求分析（根据原型图和SRS提取测试点）→编写用例→用例评审→用例执行→提交缺陷→回归测试→产品上线
                测试计划（测试负责人编写）

16. 如果项目既没有原型图，也没有需求文档，应该如何开展测试？ 
        1、结合同类型产品及相关经验理解产品需求  
        2、随时与产品经理、开发人员等保持沟通，有疑问的地方找产品经理确认

软件测试基础---------------------------------------------------------

17. 什么是软件测试？
    站在用户的角度，模拟各种正常的和异常的场景来使用软件，以发现错误，并对软件质量进行评估。

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

19. 软件测试分类
    按照开发阶段划分：单元测试、集成测试、系统测试、验收测试。
     按照测试技术划分：白盒测试、灰盒测试、黑盒测试。
     其他分类：冒烟测试、回归测试

20. 软件测试风险
    包括进度风险、质量风险、人员风险、需求变更、成本风险等

21. 如何成为优秀的软件测试工程师
    专业技能：
    计算机相关知识，能够熟练使用各种常用的管理工具，如：SVN，禅道等
    开发语言：python、shell、java等
    数据库：Oracle,MySQL，数据库知识
    操作系统,如 Window系统，Linux 等
    网络基本知识，熟悉常见的网络协议，如 http协议
    能够独立完成测试环境的搭建（至少能根据安装手册搭建测试环境）
    软件测试理论知识：软件测试流程，测试方法,测试理论有较深的理解。
    能编写各类测试文档，具备进行需求分析，需求讲解，能独立设计测试用例，执行测试，跟踪缺陷的修复，提交完整的缺陷报告单, 编写测试报告的能力。
    掌握性能测试，自动化测试和接口测试的方法，流程以及相关工具的使用。

    职业素养：
    1、良好的沟通表达能力；
    2、能很好地与领导，同事相处；
    3、强烈的责任感，团队意识，抗压能力，工作要细心，耐心。

22.软件测试工程师的日常工作内容
    参与需求分析
    编写和执行测试用例
    搭建测试环境
    提交问题单
    维护测试用例，测试脚本
    回归测试
    编写测试报告，日报，周报
    完成测试相关的其它任务
=====================================================================================

测试理论day2

软件测试类型----------------------------------------------------------------------------------

1. 软件测试有哪些类型？
    按照开发阶段划分：单元测试（UT）、集成测试（SIT）、系统测试（ST）、验收测试（UAT）。
     按照测试技术划分：白盒测试、灰盒测试、黑盒测试。
     其他分类：冒烟测试、回归测试、敏捷测试（了解）

2. 什么是单元测试？
    单元测试是指对软件中的最小可测试单元进行检查和验证。是开发写完代码后，写来测试自己代码的代码。

3. 什么是集成测试？
    在单元测试的基础上，将所有模块按照设计要求（如根据结构图〕组装成为子系统或系统，进行集成测试。
    集成测试主要关注模块与模块之间的接口。

4. 什么是系统测试？
    将集成后的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试，
    系统测试是针对整个产品系统进行的测试。

5. 系统测试范围/策略/类型
    功能测试、用户体验测试、性能测试、UI测试、兼容性测试、安装测试、文档测试、稳定性测试等

6. 什么是验收测试？
    确定产品是否能够满足合同或用户所规定需求的测试。
    非正式的验收测试：α测试（内测），β测试（公测）
    正式验收测试：制定测试方案，选择基线用例（即级别高的用例）进行测试。

7. 冒烟测试是什么？
    测试人员搭建好环境，首先要对系统的基本功能进行测试，保证主要流程的能正常使用，这叫冒烟测试。

8. 回归测试是什么？（实际项目中，一般做的都是部分回归）
    对软件的新版本测试时，重复执行上一个版本测试时使用的测试用例，防止出现“以前应用没有的问题现在出问题了”，这是全量回归；
    测试中发现某个模块存在缺陷，开发修复后，测试人员重新验证该缺陷是否被修复，以及验证相关联的模块是否受影响，这叫部分回归。

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

9. 敏捷测试是什么？（了解）
    敏捷测试是相对敏捷开发而言的，敏捷开发的最大特点是高度迭代，有周期性，
    并且能够及时、持续地响应客户的频繁反馈。
    敏捷测试的特点：
        1、强调从客户的角度，即从使用系统的用户角度来测试系统。
        2、重点关注持续迭代地测试新开发的功能，而不再强调传统测试过程中严格的测试阶段。
        3、开发一个模块就测试一个模块，不需要等到系统所有模块都开发完成再测试。

软件质量-------------------------------------------------------------------------------------------

10. 什么是质量？
    实体特性满足需求的程度，评价质量的好坏，是从所有角度综合评价的。

11. 从哪些方面测试一个软件？

    功能：产品各功能满足用户需求

    安全性：软件系统是否保护用户隐私，存在安全漏洞等。敏感信息是否在前端加密、在网络传送过程中加密，
            是否存在SQL注入漏洞。

    用户体验：系统界面布局、排版是否合理，外观好不好看，文字是否显示清晰，提示是否友好，操作是否简便。

    兼容性：系统能否在各种环境下正常使用，不同浏览器、操作系统等

    性能：系统响应流畅，及时。

    可靠性：系统能否长时间稳定运行；发生突发状况时，是否有恢复手段。
    

12. 公交卡乘地铁场景：
    功能：合法、进站余额不足、进出站刷卡异常、出站余额不足、余额显示异常、多次进出站、
            挂失后使用、注销后使用
    安全性：有害物质、边角有毛刺、
    用户体验：外观好看、便携
    兼容性：能刷公交地铁、不同闸机识别、外地识别
    性能：刷卡响应快
    可靠性：耐高温、耐严寒、防水、使用寿命

13. 练习：杯子怎么测？

需求分析---------------------------------------------------------------------------------

14.什么是需求说明书（需求规格说明书、SRS）？
    软件需求规格说明书能够使用户和研发团队对该软件的初始规定有一个共同的理解，是项目研发工作的基础。

15. 什么是需求分析？
    根据需求文档（需求说明书、原型图、高保图psd），提取测试点

16. 什么是提取测试点
    提取测试点是通过对需求的细化和分解，形成可测试的内容。
    测试内容应全部覆盖系统的业务流程，以及功能和非功能方面的需求。

17. 实际工作中，有些项目有需求文档，有些项目没有需求文档。分别怎么做？
    1、如果有需求文档，可根据需求文档，按层次整理出系统所有的单个功能，包括需要输入什么参数、
        每个参数有什么约束条件，以及各个功能之间数据流向，得到系统测试项；

    2、如果没有需求文档，只有软件产品本身，则需要对产品本身进行功能分解，同样要按层次整理出系统所有的单个功能，
        包括需要输入什么参数、每个参数有什么约束条件，以及各个功能之间数据流向，得到系统测试项。

18. 为什么要有测试点评审？
    完整性审查：应保证测试需求能充分覆盖软件需求的各种特征，重点关注功能要求、数据定义、接口定义、系统约束等方面，
        同时还应关注是否覆盖开发人员遗漏的、系统隐含的需求；
    准确性审查：应保证所描述的内容能够得到相关各方的一致理解，各项测试需求之间没有矛盾和冲突，
        各项测试需求在详尽程度上保持一致，每一项测试需求都可以作为测试用例设计的依据。 

测试计划（注意与测试方案的区别）-------------------------------------------------------------

19.测试计划是什么，由哪几部分组成？
    在对软件进行测试之前，由测试负责人编写的描述测试目的、范围、方法和软件测试的重点等的文档，
    包括被测试项目的背景、测试范围和测试策略、测试环境、测试开始和结束条件、进度安排，测试组织，
    以及与测试有关的风险等方面的内容。

20. 测试计划与测试方案的区别？（了解）
    1.测试计划是一个偏管理性质的文档，而测试方案是一个偏技术类型的文档；
    2.测试计划通俗来讲就是解决【谁来做？】【做什么？】的问题，而测试方案是解决【怎么做？】的问题；
    3.测试计划主要包含测试的目的与范围、角色与职责、资源及安排、风险与应对、测试标准等相关信息，
        而测试方案主要包含测试方法、测试环境与测试工具等内容。

21. 测试结束的条件(项目上线的条件)
     需求覆盖率、用例执行率、缺陷遗留率达到预定质量目标。

     测试用例对需求的覆盖率达到100%；原则上，用例执行率要达到100%，但是如果时间紧，就执行优先级高的，
     低级别的用例就在下个版本执行；致命、严重级别的缺陷必须当天解决，一般、轻微级别的缺陷，遗留率是10%以下。

==============================================================================

用例设计-------------------------------------------------------------------------

1. 什么是测试用例，由哪几部分组成？
    测试用例描述输入、动作、和预期结果的测试文档，其目的是确定应用程序的某个特性是否正常的工作。
    由用例编号、用例名称、用例等级、前置条件、操作步骤、预期结果组成。

2. 编写用例的关键点
    1.熟悉业务，了解系统；
    2.充分考虑用户的各种正常和异常的使用场景，覆盖用户的需求；
    3.用例的颗粒大小要均匀。通常，一个测试用例对应一个场景；
    4.用例各个要素要齐全，步骤应该足够详细，容易被其它测试工程师读懂，并能顺利执行；
    5.做好用例评审，及时更新测试用例。

3. 为什么要评审用例？评审用例有哪些成员参加？
    由于测试人员很可能对需求理解有误，场景考虑不全等原因，导致测试用例无法全面覆盖用户需求，场景缺失等，
    所以，测试用例编写完成后，都要经过严格的评审才能进行执行。
    用例评审一般是测试、产品参加，开发不忙的时候也会一起。

4. 用例状态有哪些？
    No Test未执行、Pass通过、Fail失败、Block阻碍、Investigate观察中

5. 测试过程中项目紧急，测试环境有问题，数据提供不了(构造不了数据)，你该怎么办？
    从生产环境上把数据导到测试环境上测试；
    如果生产环境的数据包含了用户的个人信息，需要进行脱敏处理，就是导入到测试环境上之后再把用户的信息修改下，再测试。

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

7. 练习：手机短信功能用例编写

黑盒用例设计方法-----------------------------------------------------------------------------------

8. 什么是黑盒测试？
    黑盒测试又称功能测试、数据驱动测试或基于规格说明书的测试，是一种从用户观点出发的测试。
     把系统看成一个黑匣，不考虑内部结构和处理过程的情况下验证系统是否达到用户需求。

9. 常用的黑盒测试方法有哪些？
    等价划分法、边界值分析法、判定表、错误推测法、场景法(也叫流程分析法)

10. 等价类划分法是什么？举例说明

11. 边界值分析法是什么，举例说明

12. 练习：使用等价类/边界值设计用例：手机号注册

13. 错误推测法是什么？

14. 防抖和节流 （了解）

15. 判定表是什么？

16. 场景法是什么，举例说明

17. 对于软件系统，若出现需求不明确或不合理的地方，作为测试，应该如何处理？

18. 项目一需求分析

==============================================================================

测试执行----------------------------------------------------------------------------------

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

    停止tomcat服务器的方法：
    ps -ef | grep tomcat -- 查询出tomcat的进程ID，然后，使用命令 kill -9 tomcat的进程ID
    启动tomcat服务器的方法：
    进入tomcat的bin目录，执行命令 ./catalina.sh start 

2. 搭建环境注意事项
     测试用例执行过程前，成功搭建测试环境是第一步。
     一般来说，软件产品提交测试后，开发人员应该提交一份被测试软件产品的详细安装指导书。
     如果开发人员拒绝提供相关的安装指导书，搭建测试中遇到问题的时候，测试人员可以要求开发人员协助，
     这时候，一定要把开发人员解决问题的方法记录下来，避免同样的问题再次请教开发人员，
     这样会招致开发人员的反感，也降低了开发人员对测试人员的认可程度。

3. 偶然性问题的处理
    1、在测试执行过程中，一旦系统出现异常信息，我们第一时间要做的是截图，保存证据；
    2、确定是偶然性的bug之后，收集相关的日志，连同截图一起提单给开发定位； 
    3、如果缺陷在当前版本无法复现，提交问题单后进行跟踪，跟踪三个版本，如果后三个版本都无法复现，就可以关闭该缺陷。

4. 为什么测试用例要执行全部执行
    编写用例时，考虑了测试覆盖率的问题，每条用例都对应一个功能点，如果少执行一条，就会有一个功能点没有测试到。
    我们执行测试前要认为待测软件的所有功能点都是未实现的，每个功能点都要测试一遍，才能保证待测软件满足用户需求。
    如果时间很紧，项目赶着上线，可以先执行优先级高的用例，优先级低一些的可以延后执行（比如留到下个版本执行）。

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

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

7. 禅道的使用：
    1.创建产品，创建项目，项目里面关联产品
    2.编写用例、上传用例、下载用例
    3.提bug、跟踪bug

缺陷相关-------------------------------------------------------------------------------

8. 缺陷有哪几种状态
    禅道（自定义）： 激活 → 已确认 → 已解决 → 关闭
    其他管理工具  ： 待修复 → 已修复 → 关闭 --- 已拒绝

9. 缺陷的等级：致命、严重、一般、轻微

10. 缺陷分类：
    功能、性能、UI、兼容性、安全性、建议、其他

11. bug单一般由哪几部分组成：
        缺陷名称、严重程度（优先级）、缺陷类型、缺陷描述（操作步骤及结果）、责任人、附件
        自动生成：缺陷编号、缺陷状态

12. 如何跟踪缺陷/Bug的生命周期是什么？
    当发现缺陷后，我们要在禅道上提交问题单给开发，并每隔一段时间(间隔一个小时，或两个小时都可以)去检查缺陷是否被处理，
    如果没及时处理，就要提示开发，让开发及时修复问题，问题修复后，要及时进行回归测试，
    如果回归通过，就关闭缺陷，如果不通过，就返回给开发继续修改。

13. 为什么说并非所有的bug都需要修复？
    1.级别是一般，或轻微的缺陷，没有足够的时间解决
    2.不算真正的软件缺陷(非问题)
    3.修复的风险太大，不值得修复

测试报告---------------------------------------------------------------------

14. 测试报告里面有哪些内容？
    人力投入、用例统计、问题单分类统计、遗留bug情况、测试风险、测试对象评估、测试结论

15. 为什么要做测试结果分析？
    测试执行结束后，分析测试结果对下一轮测试工作的开展有很大的借鉴意义。
    因为通过对问题单的分析、总结不仅能发现不同人提交问题的类别与差异，
    还能发现自身思维的局限性，避免下轮测试进入自我盲区。

项目总结-----------------------------------------------------------------

16. 如何定位bug？
    参考答案：
    1、检查测试环境配置是否有问题，测试数据是否有问题
    2、用fiddler抓包，分析请求和响应数据是否存在问题
    3、查看应用服务器的日志
    4、然后再查看数据库的数据是否存在问题

17. 开发没时间修复bug，如何推进开发修复？
    1、和开发说明该问题的严重性，会怎样影响产品的正常使用，如何还是坚持不改，就上报领导，让领导辅助推进；
    2、确认问题的严重程度，如果影响不大，不是非要改的bug，并且修复风险比较大，
        和领导商量后，如果认为暂时可以不用修复，也可以不修复。

18. 产品上线后需要测试做什么吗？
    自研：选择凌晨（晚上 10 以后）进行上线，测试需要再一次验证新上线的功能
    项目外包：交由实施去部署上线 ，我们只需要在测试环境上进行测试验证。
           客户上线后有问题，实施接触记录交由测试，测试在测试环境进行验证。。。。。。

19. 简单描述一下你做过的项目？