软件测试理论个人总结与整理
前言
循例先说一声大家好，本人第一次在博客园发表随笔，仅当作个人的能力提升日记来记录。事情是这样的，我有几个大学同学都在从事“软件测试”这份工作，恰巧本人目前打算转行，便与其中一名比较要好的同学进行了沟通，本来我就是意向于转型互联网行业的，当然，互联网行业范围很广，我是软件工程专业毕业的，更想从事其中的编程工作，特别是游戏开发，无奈毕业后的一年间，我从事了一份专业不对口的工作，虽然在那份工作上有所提升，但终究不是我想要的行业，而在期间我居然没有夯实过自己的编程水平，导致现在已经忘记了学校的非常多的知识，真的深刻表示非常后悔，在与同学交谈以后，我从中简单地了解到了一些关于软件测试的内容，此时，我再三纠结着，必须规划自己的未来，决定往软件测试行业发展，同学也向我伸出援手，将他之前校外培训的一些视频与PPT等资料文档完整地发送给我。
凭之，我开始了新一轮的自我培训（此前，离职上一份工作后，我重新学习完大学时期学过的c语言程序设计），在软件测试方面，平时看视频学到有不懂的地方我也会问下他，他也乐意给我解答，在磕磕碰碰间，我也基本学习完了软件测试的理论基础（主要是黑盒测试），所以有了现在的个人知识整理，我想这会是我进入互联网行业的第一步，因为首先我的目标是想成为一名游戏测试工程师，进入游戏行业，不仅是我自身喜欢的行业，而且能通过游戏公司慢慢摸索到游戏行业的具体结构和产品发展流程，当然，编程能力在我能力范围之内也一定会恶补加强。
正文
虽然与视频中发出声音的老师素未谋面，但看了他的这么多教学录像，可以判断到是一位经验非常丰富的软件测试工程师，一开始讲，可能他的课上有很多非计算机专业的学生，所以讲了一些很基础的东西，下面，我也是按照同学给我的视频教学顺序来总结和回忆，当然，里面有本人个人理解和本人从其他渠道获得补充的知识。
①首先，让我记忆业内的一些专业名词的英文单词，毕竟计算机行业的专业名词很多都会用英文显示，比较常见的单词应该不用再去找翻译软件翻译了。
【软件——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报告、管理）讲起，这里他没有讲出一些游戏测试公司常用的BUG管理工具，但是我从同学那里了解到，现在游戏公司一般使用“禅道”“Tapd”等工具管理与跟踪BUG，我得知后也是马上去网上自行搜索这些工具，尝试了简单的使用，发现的确很方便，我个人认为这些面向普通客户的软件一般使用难度不大。
回到视频方面，总结老师说的内容，就是缺陷报告的组成要素，即相当于一份总结文档，缺陷报告需要有以下11点要素：
（1）缺陷编号：（个人理解：是一个自己发现BUG的顺序编号，比如发现了三个不同的BUG，提交的时候分别是1号BUG，2号BUG，3号BUG）
（2）缺陷标题：（个人理解：简单扼要地形容并表达出自己发现的BUG）
（3）缺陷发现者：（个人理解：这个认为比较简单了，就是自己发现的BUG写上自己的名字，比如我的名字Tzh（英文缩写））
（4）发现缺陷的日期：（个人理解：就是写上发现BUG当天的日期，有需要可以加上当时是几时几分）
（5）缺陷所属的模块：（个人理解：就是自己发现的BUG属于该软件或游戏的哪一个功能模块，比如我发现了用户充值点券后，用户的钱扣了，商品却没有发放，这时应该属于充值点券模块的BUG）
（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）
以上。
补充一点，老师也有讲到的，缺陷报告的用途（作用、意义）：1.记录BUG 2.对BUG进行分类 3.跟踪BUG 4.方便项目组对BUG进行分析统计
③第三，也是本次教学的重中之重，测试用例（如何使用黑盒测试方法与思路进行编写用例）。
首先讲的是，一个完整的测试用例应该由什么组成。根据视频老师的教学与本人其他方式的补充学习，个人觉得应该由以下模块组成。
（1）用例编号（2）测试模块（3）测试目的（4）用例描述（5）预期结果（6）实际结果（7）是否通过（8）证迹（视频老师讲到，有些公司会让你证明你有测试过，比如截图）
其实一份测试用例就是一份Excel表格，大概需要由以上模块组成，每个模块需要如何填写，就是字面意思，这里就不累赘了。
补充：编写用例的依据就是公司产品的需求文档、软件本身、以及自身的黑盒测试技术与思路。
下面就讲到软件测试中（黑盒、白盒、灰盒）的黑盒测试！
先数数有几种测试理论方法：等价类划分！边界值划分！因果图！判定表！场景法！测试大纲法！目前应用较多的是这六种。
（1）等价类划分【重要程度：五颗星（五颗星满）】
首先该方法的应用场合：狭义上说，需要输入数据的文本框，都可以用到等价类划分，广义上说，其他一些黑盒测试方法都用到了等价类划分的思想。
使用该方法的目的：是为了从无限多的数据中选取少数具有代表性的数据进行测试。
举例：有一个文本框，需要要求合法输入是0-100的整数，你手工测试总不可能就这个文本框测100次吧，可以选取其中一到两个，比如54,72出来测试，当然，其中一个原因也是因为从开发角度想，0-100的文本框定义一般不会出现其中个别数出错，其他数正确的情况的，后面补充测边界值就能确保这个文本框的有效等价类是否有BUG了。
使用方法：1.分析需求，划出有效等价类与无效等价类，（按照我的理解，实际工作中这步应该一般与边界值一起划分好），然后从有效等价类和无效等价类中都选取一定数量的数字出来进行测试。
（2）边界值划分【重要程度：四颗星】
首先该方法的应用场合：也是需要输入数据的地方。
使用该方法的目的：可以测出开发中最容易出错的边界地方，按照我的编程水平举例，比如：文本框==a，定义了if（a>=0&&a<100）,则报错误提示，那这里如果输入100也会报错了，因为代码中没有写a<=100,而是写成了a<100，这与需求就不符合了，边界值100就出错了。
使用方法：划分出有效等价类以及无效等价类的边界值，一般拿边界值还有其左右的两个次边界值出来进行测试，比如：0-100的有效等价类，我测试0/1/2/99/100/101（很多文本框测试-1没有意义，所以我选取了0/1/2，有时间可以多测几个），六个边界值。
（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关系模型：
结言
本人学习软件测试的时间不算长，以上文章内容是100%手打的总结与个人理解，没有一个字是我复制过来的，如果有不正确的地方，请各位多多指点。（参考资料：同学给我的视频教学，自己的笔记，上网查的资料）
写这篇博客是很随性的，旨在记录自己的学习是否有掌握到核心内容，是否有理论基础支持本人从事 软件测试/游戏测试 这个职位，当然，我到现在都未有相关实践经验，仍然在简历的投放搏斗中，我自己都很期待自己接下来的故事。
虽然不知道有多少人能一字不漏地看完我的随笔，但是很感谢看到这篇文章的人，谢谢。