第一章软件测试基础理论
第一章 软件测试基础理论
一、案例
软件规格需求说明书：在三角形系统中输入任意的三个数，系统自动判断能否构成三角形，以及构成什么角的三角形。三角形行系统输入框格式要求：支持英文字母、汉字和一些特殊字符。输入框最长20个字符。
二、涉及到的基本概念（测试、软件测试、测试需求）
1、什么是测试
测试：就是找问题。
2、什么是软件测试
软件测试：找软件中的bug。
3、什么是软件
软件：软件由文档、数据和程序组成，所谓的软件测试就是找出文档、数据和程序中的bug。
备注：
1.文档：生成软件过程中所需要的图文资料。
2.数据：软件加工处理的原材料
3.程序：用计算机语言描述和解决问题的方法步骤。
4、什么是Bug
Bug：bug一般指的是软件中的缺陷，从侠义方面来说软件没有完成的客户需求；从广义方面说，软件测试工程师或者用户提出的可改进的细节，或与需求文档存在差异的功能实现等。
备注：
bug一般划分为一下几类
1）代码出问题：一般指的是程序中的代码出现问题，所实现功能不满足用户需求，或者导致程序报错等。
2）设计缺陷：一般指的是程序中的设计出现缺陷，主要分为一下几个方面：
1.数据库的设计缺陷，表与表之间的关联性太复杂，表的设计不满足三范式，密码明问存储。
2.系统的架构设计不满足用户的业务需求等。
3.页面设计缺陷，页面的设计不美观，页面相关业务操作不符合用户的使用习惯。
3）性能安全：使用系统的用户比较少，但是当用户的数据量过大时，就会导致系统出错、不稳定等现象。
4）配置相关：配置文件的配置信息出错。
5）安全相关：对于常见的网络安全，像sql注入，Dicos攻击，密码输入时是明文等。
6）标准化规范：没有满足需求文档中的标准规范。
7）其他划分：功能分类、页面类、性能类、易用性、兼容性等。
5、bug级别
1级bug：（致命错误）
1、常规操作引起的系统崩溃、死机、死循环报错，无法正常退出
2、功能设计与需求严重不符，基本模块缺失，测试流程无法进行
3、严重的数据计算错误
4、用户数据丢失或破坏
5、内存泄漏，系统无法登录
6、其他导致功能无法测试的问题
2级bug：（严重错误）
1、重要功能不能实现（例如：用户所要求的功能缺失，该有的页面未实现，逻辑不通，重要图表数据未开发，等）
2、错误的波及面广，影响到其他重要功能正常实现
3、非常规操作导致的程序崩溃、死机、死循环 (非常规操作：用户使用软件时不会进行的操作）
4、系统中数据保存后数据库中显示错误
5、密码明文显示
6、页面无显示白屏，无数据
7、地图数据和图表数据不一致
3级bug：（一般错误）
不影响产品的运行、不会成为故障的起因、但对产品外观和下道工序影响较大的缺陷
1、次要功能不能正常实现
2、操作界面错误（包括数据窗口内列名的定义，含义不一致）
例如：列名与列名下的内容不一致
3、查询错误、数据错误显示
4、简单的输入限制未放在前端进行控制；（格式显示，如登录和注册中的格式判断可由前端判断）
5、删除操作未给出提示
6、边界条件错误或者未做限制
7、系统未做优化，数据页面加载慢，操作卡顿之类（性能层面问题）
8、兼容性问题（分辨率，系统版本等等）
4级bug：（界面问题）
程序在一些显示上不美观，不符合用户习惯，或者是一些文字的错误
1、界面不规范
2、辅助说明描述不清楚
3、提示窗口文字未采用行业术语
4、界面存在文字错误
5、操作时未给用户提示
6、文字排列不整齐等一些小问题
5级bug：（建议性问题）
1、对于产品设计方面的意见和建议
2、对于产品界面优化方面的意见和建议
3、对于产品需要优化增强用户体验方面的意见和建议
备注：
P1： 即“马上解决”，优先级最高，应立即修复的问题，要求开发人员必须立即修改这条bug，一般是指该缺陷导致程序完全不能满足产品的需求，基本功能明显未实现或不可用，阻塞了测试流程与进度等。
P2：即“急需解决”，表示问题的修复很紧要，很急迫，关系到系统的主要功能模块能否正常使用，包括功能、数据，或者其他的一些比较着急的需求。
P3：即“高度重视”，表示有时间就要马上解决，主要是指系统实现的功能与预期结果要求较大，但不影响其他功能和主要的核心功能。
P4：即“正常处理”，按照个人计划处理就行，主要是指界面，交互和一些特别小的功能出错，但是可以跳过此类bug继续进行测试。
P5：即“低优先级”，一些可修改或不可修改，或者是还不确定能否修改成功的bug，不影响用户体验使用，不过修改了最好，一般如果要修改且时间来不及可以在后面的版本更新中再进行修改即可。
备注：严重性和优先级并不总是一一对应。有时候严重性高的软件缺陷，优先级不一定高，甚至不需要处理，而一些严重性低的缺陷却需要及时处理，具有较高的优先级，视具体情况而定。
三、软件测试流程：该过程中涉及到的相关概念
1、软件生产过程
主要过程为：项目可行性分析----》项目经济行分析----》用户需求分析----》需求评审----》概要设计----》详细设计----》编码《-----》测试----》上线
备注：
其中用户需求分析，测试，软件测试人员基本全程参与，编码和测试是相互的，这是一个比较复杂的过程。
2、用户需求【面试题】
指的是需求调研人员从用户现场调研回来的第一版需求。【面试：什么是用户需求】
3、测试需求【面试题】
对于需求规格说明书中阐述出来的需求，测试人员浏览需求规格说明书之后，存在不明白、或者有疑问、或者认为错误的需求，由项目经理或者需求调研人员向用户确认的需求成为测试需求。【面试：你是怎么理解测试需求的】，其实就是文档测试后的需求文档。
4、文档测试【面试题】
文档测试指的是校验文档的完整性、正确性、易浏览性、一致性、易理解性等。【面试：如何理解文档测试】
备注1：
1.完整性：文档中是否遗漏用户需求，对于用户需求有没有全部表述出来。
2.一致性：文档的前后描述是否一致。
3.正确性：文档中是否存在错别字、病句或者描述不清楚的句子。
4.易浏览性：检查文档的页码、目录、章节是否完整。
5.易理解性：检查文档是否有费解的地方。
备注2：
对测试文档只能进行红、绿、蓝的标注，不能在修改测试文档的内容。
1、红色：标注文档中有不明白、有疑问的、或者认为错误的。
2、绿色：对于红色标注的不懂得地方进行提问，在提问之前一定要组织好语言。
3、蓝色：和项目经理或者需求调研人员确认需求。
第一、不能直接修改测试文档的内容，只能进行标注。
第二、文档测试一定要审查每一个步骤和图形。
5、测试文档总结：
1）测试需求肯定大于需求文档规格说明书。
2）完成文档的测试，本质上就是完成需求文档规格说明书向测试需求的转化。
3）文档测试时程序测试的基础。
6、程序测试【统一解决方案是“备注”】
在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。（找程序中的错误）
备注：
程序测试四部曲：
1.先分类：将输入域分成不同的类
2.满足规则和不满足规则：将分好的类细化成满足满足给定规则的和不满足给的规则
3.测试思路：计算不同规则下的分类
4.测试用例：根据测试思路设计测试用例
7、测试思路【面试】
根据测试需求，从哪些角度来进行测试。【你是如何理解测试思路的】
8、测试用例【面试】
根据测试需求，分析出来很多种情况（测试思路），让后让软件来运行我们设计的情况，如果运行的结果与我们设计的结果相同，那么即为通过，不相同即为bug。【面试题：什么是测试用例？你是怎么理解测试用例的】
备注：
测试用例主要包括三部分：
1.用例编号：例如test1，test2；1、2；T1、T2等，不同的公司对测试用例的编号的要求也不一样。
2.输入：测试用例的输入，严格遵守软件页面的输入要求，软件页面怎么操作就怎么写，输入一般也叫做操作步骤，不同的叫法而已。
3.输出：指的软件处理后输出的结果，输出一般也叫做预期结果，如果软件输出的结果与我们设计的结果不一致，即为bug。
9、程序测试总结【面试：测试用例的注意事项有哪些】
1）测试用例的输入输出一定要看软件页面，怎么操作就怎么写，一定不能偷懒。
2）测试用例有几种情况，就要设计几种情况来覆盖。
3）每个测试用例是相互独立的，测试用例之间的步骤也是独立的，在设计测试用例的时候，不同的测试用例之间的步骤不能关联。关联导致无法高校定位和追踪bug。【面试题：为什么要保持测试用例步与步之间的独立性】
备注：
例如，在三角形系统中，输入三条正整数的边，判断构成构成什么边的三角形。
Test1：进入三角形系统中，选中输入框A，输入0，选中输入框B，输入1，选中输入框C，输入1；弹出友好信息“不构成三角形”。
Test2：进入三角形系统中，选中输入框A，输入1，选中输入框B，输入1，选中输入框C，输入2；弹出友好信息“不构成三角形”。
但是在测试的工程中，Test1的预期结果是“弹出友好信息‘构成等腰三角形’”，存在bug；Test2的预期结果是“弹出友好信细‘构成等腰三角形’“，存在bug；由于Test1和Test2都存在bug，但是Test1和Test2中的B=1是相同的结果，对于B=1这个条件，无法判断Test1出现bug是B=1引起的，还是AC引起的。
4）测试用例中需要使用数据是，一定要使用具体的数据。
5）在测试用例中，每一个输入都必须有明确的结果。