一．软件测试
　　软件测试和软件开发一样，是一个典型的系统工程。它包括了持续集成（CI）、持续测试（CT）、持续交付（CD）和持续部署（CD）等诸多方面，每个方面又都包括各子内容。通过这些系统工程，团队可以保持在短周期内生产出有价值的软件，并且保证能够可靠地在任何时间内发布软件。
　　1.软件测试技巧
　　软件测试虽然辛苦，但是掌握了一定的技巧之后将使你事半功倍。比如，如下的一些方法。
　　1）边界测试，测试用户输入框中数值的最大数和最小数，以及为空时的情况。
　　2）非法测试，例如在输入数字的地方输入字母、特殊字符等。
　　3）跟踪测试，跟踪一条数据的流程，保证数据的正确性。
　　4）在开始测试时应保证数据的正确性，然后在从系统中找出各种BUG。
　　5）接口测试，程序往往在接口的地方很容易发生错误，要在此模块测试勿掉以轻心。
　　6）代码重用测试，在开发过程中有些模块功能几乎相同，程序员在重用代码时可能忘记在原有代码上修改或修改不全面，而造成的错误。也就是功能相同的模块部分。
　　7）突发事件测试，服务器上可能发生意外情况的测试，比如断电、断网、磁盘故障等。
　　8）在程序员修复Bug的地方再找一找，往往程序员只修复报告出来的缺陷而不去考虑别的功能在修改时可能会重新造成错误。
　　9）文字测试，如果在系统中有用词不当的地方，这是不应该的。
　　10）系统兼容测试，例如有些系统在Chrome、Firefox等浏览器下运行良好，但在IE、搜狗、360等浏览器下却出现其他问题，你很有可能发现BUG。
　　11）用户易用性测试，往往用户的需求是不断变化的，而其中一部份变化的原因，是用户操作上不方便引起的。
　　2.如何设计测试用例
　　个人理解大概从3个方面去考虑：
　　1.表单，也就是最基础的功能；比如，这个功能是拿来做什么用的，“更多搜索”模块怎么用、怎么测。
　　2.逻辑方面；比如，当在云基础设施管理平台上，创建一个vmdk卷。实际上是通过VMware vmdk driver机制将卷创建在Vcenter那边的，挂载给VMware虚拟机，也同样是在VC环境上。
　　3.业务流程；比如，当用户使用iso来安装自定义的镜像，操作的一个业务流程是什么。
　　3.一个好的测试用例具备的特点
　　1.易用性：对于一个即熟悉测试工作，又熟悉被测系统的QA测试人员，应当可以花费很少的时间就可以理解测试用例表达的测试思路，并可以很快的执行完这个测试用例。对于不熟悉测试工作，不熟悉被测应用的人来说，也完全可以参照着该测试用例执行下去。
　　2.易维护性：当开发过程中的某些因素影响了测试需求，测试用例的作者或其他测试设计人员，应该可以花费很少的时间就完成定位并维护所有相关测试用例的工作。
　　3.可重用性：一个好的测试用例要保证可以随着版本的变化始终保持可用状态，不能因为版本的变更，导致测试用例无效或者冗余。
　　二．测试用例设计方法
　　1.等价类划分法

　　穷举测试是不可能的，因此等价类划分法因运而生。它是指在每一个等价类中取一个数据作为代表性的测试数据取得较好的测试结果。等价类划分可有两种不同的情况：有效等价类和无效等价类。
　　在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。如：输入值是学生成绩，范围是0～100；

　　等价类划分法

　　1）有效等价类
　　是指对于程序来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。
　　2）无效等价类
　　与有效等价类的定义恰巧相反。无效等价类是对程序无意义、不合法的输入，输入无效等价类后，程序应该给出错误提示。对于某一个测试场景，无效等价类至少应有一个，也可能有多个。比如一个程序规定了只允许输入数字，那么无效等价类，可以输入为空、中文、字母、特殊字符、数字长度/大小越界等多种类。
　　设计测试用例时，要同时考虑这两种等价类。因为软件不仅要能接收合理的数据，也要能经受意外的考验，给出相应的提示信息，这样的测试才能确保软件具有更高的可靠性。
　　2.边界值分析法

　　使用边界值分析方法设计测试用例应先确定边界情况，然后选取正好等于、大于或小于边界的值作为测试数据。

　　3.因果图法/判定表
　　前面介绍的等价类划分法和边界值分析法都是着重考虑输入条件，但未考虑输入条件之间的联系、相互组合等。考虑输入条件之间的相互组合，可能会产生一些新的情况。但要检查输入条件的组合不是一件容易的事情，即使把所有输入条件划分成等价类，他们之间的组合情况也相当多。因此必须考虑采用一种适合于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例。这就需要利用因果图。它适合于检查程序输入条件的各种组合情况。
　　判定表法（判定表驱动分析方法）是分析和表达多逻辑条件下执行不同操作的情况下的工具。在程序设计发展的初期，判定表就已被当作编写程序的辅助工具了。由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确。因果图方法最终生成的就是判定表。
　　比如，针对登录云平台界面上的账号、密码两个输入框，进行各种条件组合测试。
　　注意：
　　因果图的使用和分析比较复杂，使用因果图可能会消耗很多的时间，因此正确的策略是先考虑其他的测试用例设计方法，最后再使用因果图和判定表，尽量的减少工作的时间并提高效率。此方法一般很少使用。

　　4.场景设计法
　　现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中，有利于设计测试用例，同时使测试用例更容易理解和执行。

　　5.错误猜测法
　　错误猜测法就是根据经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法。
　　例如，在云硬盘的挂载使用中，为了验证云硬盘的挂载-卸载-重新挂载对数据完整性的保护这一场景测试。因而，可以将一个数据卷挂载到VM上，写入文件，然后umount、卸载，重新挂载给另一个VM来验证软件是否存在缺陷等。
　　6.正交表
　　由于因果图/判定表设计测试用例的固有弊端；以及为了解决穷举测试的弊端，因此需要使用正交表设计方法：即从大量的测试数据中挑选出适量的、有代表性的测试数据，从而合理地做出测试设计。各列中出现最大数字相同的正交表称为相同水平正交表。如L4(23)、L8(27)、L12(211)等各列中最大数字为2，称为两水平正交表。此设计方法适用于各种组合场景的测试，比如“更多搜索”。
　　正交表的构成
　　1.行数(Runs)：正交表中的行的个数，即试验的次数，也是我们通过正交实验法设计的测试用例的个数。
　　2.因素数(Factors) ：正交表中列的个数，即我们要测试的功能点。
　　3.水平数(Levels)：任何单个因素能够取得的值的最大个数。即测试功能点的输入条件个数。
　　正交表的两个特点：
　　正交表必须满足这两个特点，有一条不满足，就不是正交表。
　　1）每列中不同数字出现的次数相等。例如，在两水平正交表中，任何一列都有数码“0”与“1”，且任何一列中它们出现的次数是相等的。这一特点表明每个因素的每个水平与其它因素的每个水平参与试验的几率是完全相同的，从而保证了在各个水平中最大限度地排除了其它因素水平的干扰，能有效地比较试验结果并找出最优的试验条件。
　　2）在任意两列其横向组成的数字对中，每种数字对出现的次数相等。例如，在两水平正交表中，任何两列（同一横行内）有序对子共有4种：（1，1）、（1，2）、（2，1）、（2，2）。每种对数出现次数相等。在三水平情况下，任何两列（同一横行内）有序对共有9种，1.1、1.2、1.3、2.1、2.2、2.3、3.1、3.2、3.3，且每对出现数也均相等。这个特点保证了试验点均匀地分散在因素与水平的完全组合之中，因此具有很强的代表性。
　　以上两点充分的体现了正交表的两大优越性，即“均匀分散性，整齐可比性”。通俗的说，每个因素的每个水平与另一个因素的水平各碰一次，这就是正交性。
　　如何选择正交表
　　- 考虑因素（变量）的个数；
　　- 考虑因素水平（变量的取值）的个数；
　　- 考虑正交表的行数；
　　- 取行数最少的一个；
　　设计测试用例时的三种情况
　　- 因素数（变量）、水平数（变量值）相符；
　　- 因素数不相同；
　　- 水平数不相同；
　　正交表的形式：

　　这是云平台中的一个“更多搜索”模块（由于某些原因，只能贴设计表）。我们可以看到要测试的控件有6个：状态、开始时间、结束时间、所属主机、所属租户、IP，也就是说要考虑的因素有6个；而每个因素的选项（水平数）有2个：填与不填。
　　选择正交表时分析一下：
　　1、表中的因素数>=6；
　　2、表中至少有6个因素数的水平数>=2；
　　3、行数取最少的一个。
　　从正交表公式中开始查找，结果为：
　　L4（26）：表示需做>=4次实验，可测试6个因素，每个因素均为2水平。
　　变量映射：

　　测试用例如下：
　　1：填写状态、填写开始时间、填写结束时间、填写所属主机、填写所属租户、填写IP
　　2：填写状态、不填开始时间、不填结束时间、不填所属主机、不填所属租户、不填IP
　　3：不填状态、填写开始时间、不填结束时间、填写所属主机、不填所属租户、填写IP
　　4：不填状态、不填开始时间、填写结束时间、不填所属主机、填写所属租户、不填IP
　　增补测试用例：
　　5：不填状态、不填开始时间、不填结束时间、不填所属主机、不填所属租户、不填IP
　　测试用例减少数：64-5=59
　　7.基于需求的测试方法
　　即根据客户需求、业务和逻辑设计需求、场景和功能需求（比如平台可用性测试、故障HA测试、后端/前端性能测试）等进行相关的测试。要求测试人员全面清晰地掌握用户需求；明确测试的目标和任务；设计基于需求的测试用例；建立测试报告通报制度（建立测试报告审批通报制度对于提升软件质量具有明显作用。作为一名优秀的测试工程师，应将已经发现的缺陷或错误进行分析汇总，用统计数字、图表等方式说明缺陷或错误的根源，及时将测试工作报告提交上级主管领导审议，并通知研发设计人员，使设计人员做到对缺陷心中有数、控制有道，以防患于未然）

　　基于需求的测试方法五项最佳实践
　　1）转变“编码后进行测试”的传统观念。在软件编码开始之前的设计阶段就根据需求文档和设计文档开发出90%以上的测试用例，尽早发现和排除绝大部分的缺陷。即转入测试驱动开发的最佳实践（TDD）。
　　2）根据各项应用功能的优先级、重要性制订不同等级的测试方案、测试用例。重要模块和次要模块投入的测试资源。
　　3）尽早测试，频繁测试。测试进行得越早，缺陷发现越早，修复缺陷的代价越小；测试进行得越晚，缺陷发现越迟，修复缺陷的代价越大。
　　4）摒弃“经验至上”的想法。设计系统、严谨、合理的测试用例才能使测试达到实效。
　　5）加强对测试过程的监控跟踪。当用户需求发生变更时，软件需求文档和设计文档都随之发生变更，相应测试用例也应发生变更。保证测试用例和用户需求的双向统一。
　　8.综合策略
　　使用各种测试方法的综合策略：
　　1）在任何情况下都必须使用边界值分析方法，经验表明用这种方法设计出测试用例发现程序错误的能力最强。
　　2）必要时用等价类划分方法补充一些测试用例。
　　3）用错误猜测法再追加一些测试用例。
　　4）对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到，应当再补充足够的测试用例。
　　5）如果程序的功能中含有输入条件的组合情况，则选用因果图法或正交表。
　　界面测试总结（如何针对文本框进行测试）
　　a、输入正常的字母或数字；
　　b、输入已存在的名称；
　　c、输入超长字符；例如在“名称”框中输入超过允许边界个数的字符，检查程序能否正确处理；
　　d、输入默认值，空白，空格，特殊符号；
　　e、若只允许输入字母，尝试输入数字；反之，尝试输入字母；
　　f、利用复制，粘贴等操作强制输入程序不允许的输入数据；
　　g、输入特殊字符集；
　　h、输入超过文本框长度的字符或文本，检查所输入的内容是否正常显示；
　　i、输入不符合格式的数据，检查程序是否正常校验（判断）；
　　例如，程序要求输入年月日格式为yy/mm/dd，实际输入yyyy/mm/dd，则程序应该给出错误提示。
　　为测试用例设置优先级需要采取两个原则：
　　1）将使用频率比较高的测试场景设置为高优先级的；
　　2）根据测试场景失败后对系统、用户的影响大小设置其优先级；
　　这样将两者相加就得到了每个测试用例的优先级了。根据优先级的排序就可以更有针对性的进行测试用例的详细设计了。此时，还需要为每个测试用例设计相关的测试数据。对测试数据的设置有两个要求：
　　1）正常数据
　　2）非法数据
　　应当优先考虑正常数据，而且正常数据的设计必须是有实际意义的。然后再考虑设计非法数据。这两种数据中都应该包含边界数据，因为边界数据往往是容易出错的地方。
　　当我们设计完测试数据后，就可以开始对测试用例进行详细设计了。在具体的测试步骤中，需要包含的主要内容是：操作步骤，测试数据以及期望结果。当我们完成了这些工作，一个完整的测试用例就写完了。
　　当然，除了以上讲到的软件测试用例设计方法（黑盒测试）之外，还有诸如包括语句覆盖、判定覆盖（也称为分支覆盖）、条件覆盖、判定/条件覆盖、条件组合覆盖、基本路径分析法等在内的白盒测试方法。这里就不一一列举了。