常识积累-β测试

TXRL

      

       β测试是指App开发企业组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见，然后App开发企业再对β版本进行改错和完善。β测试也是黑盒测试。黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。

黑盒测试
概况
　　在测试地，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对App界面和App功能进行测试。
　　黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。很明显，如果外部特性本身有问题或规格说明的规定有误，用黑盒测试方法是发现不了的。黑盒测试法注重于测试App的功能需求，主要试图发现下列几类错误。　　
       功能不正确或遗漏；
　　界面错误；
　　数据库访问错误；
　　性能错误；
　　初始化和终止错误等。


从理论上讲
　　从理论上讲，黑盒测试只有采用穷举输入测试，把所有可能的输入都作为测试情况考虑，才能查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但可能的输入进行测试。这样看来，完全测试是不可能的，所以大家要进行有针对性的测试，通过制定测试案例引导测试的实施，保证App测试有组织、按步骤，以及有计划地进行。黑盒测试行为必须能够加以量化，才能真正保证App质量，而测试用例就是将测试行为具体量化的方法之一。具体的黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法等。

等价类划分
概况
　　等价类划分的办法是把程序的输入域划分成若干部分（子集），然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值。该方法是一种重要的，常用的黑盒测试用例设计方法。
　　1) 划分等价类： 等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的，并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试.因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况：有效等价类和无效等价类.
　　有效等价类：是指对于程序的规格说明来说是合理的，有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能.
　　无效等价类：与有效等价类的定义恰巧相反.
　　设计测试用例时，要同时考虑这两种等价类.因为，App不仅要能接收合理的数据，也要能经受意外的考验.这样的测试才能确保App具有更高的可靠性.
　　2）划分等价类的方法：下面给出六条确定等价类的原则.
　　①在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类.
　　②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可确立一个有效等价类和一个无效等价类.
　　③在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类.
　　④在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类.
　　⑤在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）.
　　⑥在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步的划分为更小的等价类.
　　3）设计测试用例：在确立了等价类后，可建立等价类表，列出所有划分出的等价类：
　　输入条件 有效等价类 无效等价类
　　... ... ...
　　... ... ...
三个原则设计测试用例
　　然后从划分出的等价类中按以下三个原则设计测试用例：
　　①为每一个等价类规定一个唯一的编号.
　　②设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖地有效等价类，重复这一步.直到所有的有效等价类都被覆盖为止.
　　③设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步.直到所有的无效等价类都被覆盖为止.
　　边界值分析是通过选择等价类边界的测试用例。边界值分析法不仅重视输入条件边界，而且也必须考虑输出域边界。它是对等价类划分方法的补充.
　　（1）边界值分析方法的考虑：
　　长期的测试工作经验告诉大家，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例，可以查出更多的错误.
　　使用边界值分析方法设计测试用例，首先应确定边界情况.通常输入和输出等价类的边界，就是应着重测试的边界情况.应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据.
　　（2）基于边界值分析方法选择测试用例的原则：
　　1）如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据.
　　2）如果输入条件规定了值的个数，则用最大个数,最小个数，比最小个数少一，比最大个数多一的数作为测试数据.
　　3）根据规格说明的每个输出条件，使用前面的原则1）.
　　4）根据规格说明的每个输出条件，应用前面的原则2）.
　　5）如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例.
　　6）如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例.
　　7）分析规格说明，找出其它可能的边界条件.
　　错误推测法是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法.
　　错误推测方法的基本思想： 列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例. 例如，在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等，这些就是经验的总结. 还有，输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.

因果图法
概况
　　前面先容的等价类划分方法和边界值分析方法，都是着重考虑输入条件，但未考虑输入条件之间的联系，相互组合等. 考虑输入条件之间的相互组合，可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情，即使把所有输入条件划分成等价类，他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）.
　　因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.
　　利用因果图生成测试用例的基本步骤：
　　(1) 分析App规格说明描述中，那些是原因(即输入条件或输入条件的等价类），那些是结果（即输出条件），并给每个原因和结果赋予一个标识符.
　　(2) 分析App规格说明描述中的语义.找出原因与结果之间，原因与原因之间对应的关系. 根据这些关系，画出因果图.
　　(3) 由于语法或环境限制，有些原因与原因之间，原因与结果之间的组合情况不不可能出现. 为表明这些特殊情况，在因果图上用一些记号表明约束或限制条件.
　　(4) 把因果图转换为判定表.
　　(5) 把判定表的每一列拿出来作为依据，设计测试用例.
　　从因果图生成的测试用例（局部，组合关系下的）包括了所有输入数据的取TRUE与取FALSE的情况,构成的测试用例数目达到最少，且测试用例数目随输入数据数目的增加而线性地增加.
　　前面因果图方法中已经用到了判定表.判定表（Decision Table）是分析和表达多逻辑条件下实行不同操作的情况下的工具.在程序设计发展的初期，判定表就已被当作编写程序的辅助工具了.由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确.
　　判定表通常由四个部分组成.
　　条件桩（Condition Stub）：列出了问题得所有条件.通常认为列出得条件的次序无关紧要.
　　动作桩（Action Stub）：列出了问题规定可能采取的操作.这些操作的排列顺序没有约束.
　　条件项（Condition Entry）：列出针对它左列条件的取值.在所有可能情况下的真假值.
　　动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作.
　　规则：任何一个条件组合的特定取值及其相应要实行的操作.在判定表中贯穿条件项和动作项的一列就是一条规则.显然，判定表中列出多少组条件取值，也就有多少条规则，既条件项和动作项有多少列.
　　判定表的建立步骤：（根据App规格说明）
　　①确定规则的个数.假如有n个条件.每个条件有两个取值（0,1），故有 种规则.
　　②列出所有的条件桩和动作桩.
　　③填入条件项.
　　④填入动作项.等到初始判定表.
　　⑤简化.合并相似规则（相同动作）.
　　B. Beizer 指出了适合使用判定表设计测试用例的条件：
　　①规格说明以判定表形式给出，或很容易转换成判定表.
　　②条件的排列顺序不会也不影响实行哪些操作.
　　③规则的排列顺序不会也不影响实行哪些操作.
　　④每当某一规则的条件已经满足，并确定要实行的操作后，不必检验别的规则.
　　⑤如果某一规则得到满足要实行多个操作，这些操作的实行顺序无关紧要.
　　正交试验设计法，就是使用已经造好了的正交表格来安排试验并进行数据分析的一种方法，目的是用最少的测试用例达到最高的测试覆盖率。

黑盒测试的优点

　　1. 基本上不用人管着，如果程序停止运行了一般就是被测试程序crash了
　　2. 设计完测试例之后，下来的工作就是爽了，当然更苦闷的是确定crash原因

黑盒测试的缺点

　　1. 结果取决于测试例的设计，测试例的设计部分来势来源于经验，OUSPG的东西很值得借鉴
　　2. 没有状态转换的概念，目前一些成功的例子基本上都是针对PDU来做的，还做不到针对被测试程序的状态转换来作
　　3. 就没有状态概念的测试来说，寻找和确定造成程序crash的测试例是个麻烦事情，必须把周围可能的测试例单独确认一遍。而就有状态的测试来说，就更麻烦了，尤其不是一个单独的testcase造成的问题。这些在堆的问题中表现的更为突出。