软件测试（黑盒测试）个人总结
软件测试理论个人总结与整理
正文
我是软件工程专业的学生，关于软测的理论知识，是在学校没有开设软件测试课程的情况下，从师兄提供的一些机构教学视频上进行学习的（其实那些机构的课程还是挺系统的），当然也会常看博客园和CSDN等网站的一些测试大佬的经验总结，在黑盒测试/功能测试方面，我将学到的东西总结为以下几点。
①首先，一些常见的关于软件的英文，需要熟悉一下。
【软件——Software】【硬件——hardware】【程序——program 】【文档——document 】 【缺陷——Defect （BUG）】 【Configuration-配置】【Adapter-适配器】
【Urgent--Veryhigh--high--medium--Low——对应BUG的严重程度与优先级（紧急——非常高——高——中等——低）】
【new-open-fixed-close—对应一个BUG的周期分别是（“测试员”新发现BUG—“测试或开发经理确认是BUG”打开状态—“开发已修复”已修复状态—“测试员返测后”关闭状态）】
【基本输入输出系统——BIOS（Basic input/output system）】 【操作系统——OS（Operrating System）】 【Address-地址】【Default-默认】
还有一些零碎的计算机知识，比如OS的主要功能、软硬件的分类、单机与网络软件的分类、C/S与B/S结构的分布式软件大概的运作流程、数制（十进制、二进制、八进制、十六进制）的相互转换与相关知识等等，这些知识与计算机有关，但不属于软件测试的基础理论，故在此就不详细作出总结了。
②第二，先从最简单的缺陷报告（BUG报告、管理）讲起，现在游戏公司一般使用“禅道”或者“Tapd”等工具系统性地管理与跟踪BUG，比如说禅道，就有着界面简洁明了、简单易用的特点。
缺陷报告的组成要素，即相当于一份总结文档，缺陷报告（或者说是一条禅道）需要有以下11点要素：
（1）缺陷编号：（个人理解：是一个自己发现BUG的顺序编号，比如发现了三个不同的BUG，提交的时候分别是1号BUG，2号BUG，3号BUG，这个建立禅道的时候就会自动生成，如果是用Excel做的BugList，则需要自己编上号）
（2）缺陷标题：（个人理解：简单扼要地形容并表达出自己发现的BUG，至少需要带有部分导致BUG发生的必然条件，以及BUG的出现所造成的具体表现等信息）
（3）缺陷发现者：（个人理解：这个认为比较简单了，就是自己发现的BUG写上自己的名字，比如我的名字Tzh（英文缩写），一般在BUG管理系统上直接选中就可以）
（4）发现缺陷的日期：（个人理解：就是写上发现BUG当天的日期，有需要可以加上当时是几时几分，这个在禅道上也是自动生成的）
（5）缺陷所属的模块：（个人理解：就是自己发现的BUG属于该系统的哪一个功能模块，比如我发现了用户充值点券后，用户的钱扣了，商品却没有发放，这时应该属于充值点券模块的BUG，或者是后台SDK的接口模块）
（6）发现缺陷的版本：（个人理解：就是测出一个BUG后，记录下当时所在的软件版本，比如我此时此刻测出一个BUG，是在1.26版本测试出来的，应该记录好）
（7）指派给谁处理：（个人理解：我觉得这里应该看各公司的内部运作是如何的，有可能直接给开发人员，也有可能给测试或者开发经理，再由他们分配给相应的开发人员，当然，如果用BUG管理工具，相应模块的开发人员应该可以接到自己开发的模块出现BUG的信息通知）
（8）缺陷的状态：（个人理解：这个上面的英语单词有讲到，就是new-open-fixed-close，这个状态理应是随时更新的，测试人员发现BUG后，标注New，测试或者开发经理确认是BUG后，标注Open，开发人员收到该BUG并修复好后，标注Fixed，测试人员返测没问题后，标注Close，当然可能不同公司使用的名词不一样，但应大同小异）
（9）缺陷的严重程度：（个人理解：这个上面的英语单词同样有讲到，就是Urgent--Veryhigh--high--medium--Low，当然可能不同公司使用的名词不一样，但应大同小异，此处视频老师有讲到，每个公司都应有自己的BUG等级定义手册，并以此为标准）
（10）缺陷的优先级：（个人理解：分级同上，Urgent--Veryhigh--high--medium--Low，不同公司使用的名词和等级可能不一样，这里视频老师也注重给我讲了一个知识点，就是“严重程度”与“优先级”的判定方法，比如有可能medium级别严重程度的BUG，但该BUG是比较表层的错误，开发人员应能很快处理好，故优先级是Urgent）
（11）缺陷描述：（个人理解：就是发现BUG的那条测试用例的步骤，记录下来，方便开发人员重现BUG，最好记录下BUG的必现步骤）
以上。
❤补充一点，缺陷报告的用途（作用、意义）：1.记录BUG整个生命周期，随时可找出来参考 2.对BUG进行分类 3.方便跟踪BUG 4.方便项目组对BUG进行分析统计
③第三，是黑盒测试的重中之重，测试用例（如何使用黑盒测试方法与思路进行编写用例）。
首先讲的是，一个完整的测试用例应该由什么组成。根据老师的教学与本人其他方式的补充学习，个人觉得应该由以下模块组成。
（1）用例编号（2）测试模块分层（3）测试目的（Why）（4）用例描述（5）预期结果（6）实际结果（7）是否通过（8）备注（9）证迹（有些公司会让你证明你有测试过，比如截图）
一份测试用例可以是一份Excel表格，或者一个XMind导图等等，但都需要由以上模块组成，每个模块需要如何填写，就是字面意思，这里就不累赘了，重要的是要做到用例少冗余，通过给功能模块分层，从重要核心模块开始设计用例，使每一个执行步骤和预期结果都条理清晰，另外测试点覆盖要全面。
补充：编写用例的依据就是公司产品或功能的需求文档、软件本身、以及自身的黑盒测试技术与思路、经验。
下面是软件测试（黑盒、白盒、灰盒）中的黑盒测试常用方法论。
先数数有几种方法：等价类划分！边界值划分！因果图！判定表！场景法！测试大纲法！目前应用较多的是这六种。
（1）等价类划分【重要程度：五颗星（五颗星满）】
首先该方法的应用场合：狭义上说，需要输入数据的文本框，都可以用到等价类划分，广义上说，其他大多数的黑盒测试方法都用到了等价类划分的思想。
使用该方法的目的：是为了从无限多的数据中选取少数具有代表性的数据进行测试，保证其效率和准确率。
举例：有一个文本框，需要要求合法输入是0-100的整数，手工测试是不可能将这个文本框测100次的，所以可以选取其中一到两个，比如需要取4个值进行测试，那便分成4个均匀的范围，1~25中取10，26~50中取45，51~75中取66，76~100中取81，最后得出四条用例，就是测试输入10、45、66、100这四个有效等价类；另外无效等价类也可以用相同思想取范围之外的值，比如负数、大于100的数、字符、拼音、英文等等，又可以得出用例，最后补充上下面的边界值测试就能确保这个文本框的输入范围限制是否正确了。
使用方法：1.分析需求，划出有效等价类与无效等价类，（按照我的理解，实际工作中这步应该一般与边界值一起划分好），然后从有效等价类和无效等价类中都选取一定数量的数据出来进行测试和分析，记录其结果。
（2）边界值划分【重要程度：四颗星】
首先该方法的应用场合：也是需要输入数据的地方，在游戏中就是各种特定的时间点、属性值、技能效果或领取次数等地方。
使用该方法的目的：可以测出开发中最容易出错的边界极限情况，按照我的编程水平举例，比如：文本框==a，定义了if（a>=0&&a<100）,则报错误提示，那这里如果输入100也会报错了，因为代码中没有写a<=100,而是写成了a<100，这与需求就不符合了，边界值100就出错了。
使用方法：划分出有效等价类以及无效等价类的边界值，一般拿边界值还有其左右的两个次边界值出来进行测试，比如：0-100的有效等价类，我测试-1/0/1/2/99/100/101/，这几个边界值。
（3）因果图【重要程度：三颗星】
应用场合：一个界面中有多个控件，不同的控件输入组合就会产生不同的输出结果的组合（控件数量不能太多，如果太多控件组合需要用正交排列法）
使用目的：为了弄清楚这些控件，用怎样的输入组合，会产生对应怎样的输出结果，因此称因果图。
使用方法：根据9种图形关系，来实际画出界面控件与控件间的逻辑关系。
控件中的基本关系（输入与输出的基本关系）有：
第一种——
（图片上的Tzh仅作为原创标注）
关系含义：若a出现，则相当于b出现；若a不出现，则相当于b不出现。（我们以1作为出现，0作为不出现，则有：若a=1，则b=1；若a=0，则b=0）
补充，a相当于输入，b相当于输出，比如：按下充值50元按钮，与提示请投入50元人民币，就是a与b的恒等关系，做了这个操作，就会有这个结果。
第二种——
关系含义：若a出现，则b不出现；反之亦然（若a=1，则b=0） 比如，按下了使用微信支付，就不会出现支付宝支付的提示，反之亦然
第三种——
关系含义：几个输入中，只要有一个出现，结果就会出现，若全部都不出现，结果则不出现（a=1或b=1或c=1，则d=1,；若a=b=c=0，则b=0）
第四种
关系含义：若几个输入全部出现，结果才会出现；若几个输入中有一个不出现，则结果不出现。（若a=b=c=1，则b=1,；若a=0或b=0或c=0，则b=0）
★下面五种是限制关系（只能单独限制输入，或者单独限制输出）：
第五种——
关系含义：表示a、b、c三个不可能同时成立，他们互相排斥，最多只能有一个成立。
比如，一个软件让你选择身份：1.学生 2.教室 3.游客 ，你只能选择一种，不能同时选两种。选择了其中一种，其他种类就会置灰无法选择。
第六种——
关系含义：表示a、b、c中至少有一个成立（可以三个都成立），不能全部都不成立。
第七种——
（比较重要的一种关系）
关系含义：a、b、c中有且仅有一个成立（唯一与互斥很相似，但是唯一关系一般有默认值，互斥一般没有）
第八种——
关系含义：a要求b，即a出现时，b必须出现。
第九种——
关系含义：a屏蔽b，即a出现时，b必定不出现。
以上就是因果图法9种图形。
★此外，还有一套因果七步法，即使用七个步骤，运用因果图与判定表生成测试用例的方法。如下：
第一步：将界面所有的输入（也称原因、可能性）找出来，并列出来。
比如有三个按钮a、b、c，那么输入情况有可能是单独a、单独b、单独c、a+b、a+c、b+c、a+b+c几种，这就是所有输入情况（用户所有有可能的操作），然后根据需求划分他们之间的关系（哪些能组合，哪些不能）。
第二步：将所有的输出（结果）找出来，并列出来。
即所有有可能发生的输出都列出来。
第三步：在第一步的基础上，找到所有输入之间的限制关系与组合关系（决定测试用例的数量）。
第四步：在第二步的基础上，找到所有输出之间的限制关系与组合关系。
第五步：找到输入与输出之间的关系与组合关系（怎么样的输入产生怎么样的输出）。
第六步：根据画出的因果图，写出一个判定表。
第七步：判定表中的每一种情况都生成一条测试用例。
看起来挺复杂，其实用于游戏测试中，就是把客户端与用户的所有交互情况都要测试一遍，玩家每一个可能的点击、跳转、返回、选择、选中、移动操作等等都要生成一条相应的用例，对所有情况进行测试。
（4）判定表【重要程度：四颗星】
个人理解：判定表其实就是因果图的后续，两者密不可分，就是用因果图方法分析后，将控件的输入输出组合总结成表格，列出所有有可能发生的情况，然后根据此表生成测试用例。
（5）正交排列法【重要程序：三颗星】
应用场合：在一个界面中，有多个控件，每个控件中又有多个取值，此时控件组合数量庞大，不可能穷举测试。
使用目的：正交排列法正是为此而用的，在庞大的组合数量中选取少数最优的数据进行测试，提高测试效率。
首先，此方法是借鉴正交表的一种方法，而正交表是数学家固定的，我们只能借鉴。
正交表：
是以该种形式表示的一种数学表格，以下来解释一下这些数字的意义，比如L9（三的四次方），代表有四个控件，每个控件有三个取值，需要测试9次。
1.n是表的行数，也就是需要测试组合的次数。
2.k是表的列数，也就是控件的个数（因子数）
3.m是每个控件的取值个数（状态数）
使用方法：分析需求，将需要测试的控件与取值个数列出来，然后根据控件与取值的个数，选择一个合适的正交表。
正交表有9种，需要用到时上网查找即可，或者自己用文档记录好，用的时候拿出来。下面贴出L9（三的四次方）的正交表出来。
表中的1/2/3值就是控件的3个取值，表头的1/2/3/4列就表示4个控件，只需要将控件及其取值放到正交表中即可得出测试用例。
此外，需要注意的是很多时候软件中的控件和取值并没有这么规范（4个控件都是3个取值），当不符合正交表时，选取最接近的正交表，采取1.少数服从多数原则 或者 2.取最大值为底原则，做出自己加工过的正交表（以公平、均匀的思想）。
（6）场景法【重要程度：五颗星】
该方法是游戏测试的主要应用方法。
应用场合：1.界面没有太多填写项，主要通过鼠标的点击、双击或者拖拽等完成操作（移动端通过触摸）。
2.将自己当做最终的用户，思考在使用该软件时可能会遇到哪些场景。
使用目的：测试软件的主要业务流程、主要功能的正确性与错误处理能力。
核心概念：1.基本流（正确流程）：模拟用户正确的操作流程，直达目的（验证软件的业务流程和主要功能实现）
2.备选流（错误流程）：模拟用户的错误操作流程（验证软件的错误处理能力）
总结：1.场景法是基于等价类划分的一种测试方法（基本流-有效，备选流-无效），在技术层面。
2.场景法的应用是基于对软件业务（需求）的深入理解，在业务层面。
使用方法：（1）根据说明，描述出程序的基本流与各项备选流。
（2）根据基本流和各项备选流生成不同的场景。
（3）对每一个场景生成相应的测试用例。
PS：一条基本流中，每一个操作都有可能有一条备选流，要把它们仔细列出来进行测试。
（7）测试大纲法【重要程度：四颗星】
应用场合：在一个程序中涉及多个窗口，并且每个窗口有多个操作，窗口与窗口之间有一定联系，为了直观地弄清楚它们之间的联系，使用测试大纲法。
使用方法：（1）列出所有窗口，以及窗口中包含的操作（按钮、选项）
（2）找出窗口之间的联系，例如先后顺序，点击哪个按钮跳转到哪个窗口，然后根据之编写测试用例。
④除此以外，还有一些测试的流程说明，如下：
（1）单元测试：
1.依据单独模块的详细设计文档（需求）来测试
2.以功能测试为主，保证单一模块的功能质量
（2）集成测试：
1.拿到开发给过来的新版本后，先做“冒烟测试”，即用较少时间与人员，测试新版本中主要功能是否基本实现，判断是否有值得测试的价值。
2.冒烟合格后，进行测试人员返测，即将之前发现的BUG都重新测试一次。
3.进行“回归测试”，即对前面版本执行过的测试用例再重新执行一次，测试一次。
4.最后才是针对新版的添加的功能，进行编写测试用例，执行测试。
（3）系统测试：
1.对整个软件进行全面的测试
2.在系统测试前，一般有“确认测试”，即再次冒烟测试，与检查各类文档是否齐全。
（4）验收测试：是用户接受度测试，用户体验测试，
1.alpha测试：最终用户在开发环境中，对软件进行测试。
2.beta测试：由最终用户在实际环境中使用（公测）
以下附上开发与测试的W关系模型：
结言
写这篇博客是比较随性的，旨在记录自己对部分测试技能的掌握情况，并将其整理成文字，感谢观看，谢谢。