测试理论基本知识培训

2020/6/1,中软测试TRB,测试培训（基础篇）,声明,本胶片大部份内容基于CemKaner/JamesBach/BretPettichord所著的软件测试经验和教训以及Ryber提供给华为的HuaweiTestDesign.ppt,Page2,测试的哲学,测试是使用猜想和反驳逻辑评估产品的一种过程很容易被证明是无效的需求规格才是可测试的,Page3,对测试人员的要求,测试人员的任务是找到并报告重要的程序问题，但是不会发现所有的程序问题通过测试不能保证质量，要提供真实的错误报告给整个项目团队促进项目质量保证优秀测试人员会进行技术性、创造性、批判性和实用性地思考对技术建模并理解因果关系的能力产生思想并看到可能性的能力评估思想并进行推断的能力吧想法付诸实施的能力,Page4,一个游戏,规则1：存在一系列的卡片规则2：每个卡片的两面都有信息，其中一面显示字母A-E，另外一面显示数字09规则3：如果一面是元音字母，另外一面必须是偶数问题：如下四张卡片，你准备翻开哪一张来验证规则3？为什么？,Page5,测试分类,测试系统的5要素关注测试员的基于人员的测试分类关注测试内容的基于覆盖率的测试分类针对风险的基于问题的测试分类关注测试方法的基于活动的测试分类关注测试是否通过基于评估的测试分类,Page6,测试系统的5要素,测试员进行测试的人，或者他所代表的角色。覆盖率测试了哪些内容。潜在的问题测试的原因，想测试什么风险。活动如何测试。比如探索式测试方法评估怎样判断测试通过还是不通过。,Page7,UCD测试站在实际用户使用系统的角度去测试，最好是实际用户和公司测试人员联合测试。但是测试的内容等还需要测试员自己去明确。测试由测试小组，可能还包括其他感兴趣的、友善的内部人员执行的内部测试测试利用不属于开发机构并且是产品的目标市场成员的测试员实施的用户测试。待测产品一般非常接近完成。结对测试两个测试人员在一起发现程序错误。在敏捷团队比较常见。,关注测试员的基于人员的测试分类,Page8,关注测试内容的基于覆盖率的测试分类,功能测试（functiontesting）测试单个功能，直到可以确信该功能没有问题规格验证关注验证在规格说明中所做的关于产品的每个事实声明，包括用户可见的功能、性能等内容。需求验证关注程序满足需求文档中的所有需求，或者证明某个需求不被满足,Page9,针对风险的基于问题的测试分类,健壮性测试（robusttesting)重点关注系统的容错处理，针对各种输入、算法、存储的约束并发测试（concurrenttesting）针对时序。多用户操作、多线程、多进程系统。长序列测试（longsequencetesting）也叫稳定性测试（durationtesting）、可靠性测试（reliabilitytesting）或者耐力测试（endurancetesting）,Page10,关注测试方法的基于活动的测试分类,回归测试（regressiontesting）包括三种：1）修改BUG之后的回归（bugfixregression);2)老程序错误回归(oldbugsregression);3)稳定性回归（stablilityregression)或者副作用回归(side-effectregression)冒烟测试（smoketesting）其目标是证明新版本不值得测试性能测试（performancetesting）关注响应时间和吞吐量注重性能对比，更快或更慢都可能预示内部出现重大的变化，可能有害负载测试(loadtesting)足够高的负载下，系统可能失效，从而暴露出被测系统的弱点,Page11,关注测试方法的基于活动的测试分类,场景测试（Scenariotesting）现实操作；复合功能；结果易验证；失败必修改安装测试包括安装和卸载探索式测试（exploratorytesting）建立在测试人员的知识持续增长的基础上，适合经验丰富的测试人员,Page12,关注测试是否通过基于评估的测试分类,一致性测试更多的针对协议针对资料的测试Oracle-basedtesting另一种一致性测试，判断的标准是通过称之为Oracle的令一个软件实体产生的,Page13,测试执行模型,IBOTestOracleDataDrivenFramework(数据逻辑分离）数据自动生成,Page14,IBO,每个输入都有明确的输出，输入和预期输出都是测试用例设计时确定当根据输入很难推导出预期输出的时候不适用了，比如一个加密算法的测试,SUT(SystemUnderTest）,Input,RealOutput,ExpectedOutput,Comprator,Page15,TestOracle,对于实现复杂的TestOracle，可以用不同语言、不同的人员开发多个Oracle，避免Oracle的实现错误导致执行结果的错误判断Oracle也可以是另一个可信赖的产品，比如开源实现、竞争对手的实现、早期的稳定版本,SUT(SystemUnderTest）,Input,RealOutput,Comprator,TestOracle1,TestOracle2,Oracle：itappearedtomeetsomerequirementtosomedegreeCopyright(c)CemKanerandJamesBach,kaner,Page16,DataDrivenFramework,通过分层设计提升测试用例的重用和扩展能力适用于自动化测试，测试输入不仅仅是数据，还包括一定行为逻辑的时候,SUT(SystemUnderTest）,TestLogic,RealOutput,Comprator,TestOracle1,TestOracle2,TestData,Page17,数据自动生成,目的是高效提升测试覆盖一定和TestOracle配套才能充分发挥其威力,SUT(SystemUnderTest）,TestLogic,RealOutput,Comprator,TestOracle1,TestOracle2,DataGenerator,Page18,黑盒测试,基本认识特性建模等价类和边界值组合策略,Page19,基本认识,黑盒测试关注有关软件的用户和环境的知识，而不是产品内部实现所有的测试都是基于模型的，这个模型体现用户是谁，用户关心什么内容，而不是产品的实现为了测试必须探索，测试过程的一个重要成果是更好、更聪明的测试人员,Page20,测试设计的四步骤,createbasetestcases:需要按照一定的覆盖策略选取用例，如节点覆盖、分支覆盖、路径覆盖Supplimentwithtestdata:输入数据的设计，涉及到两个方面的技术：单个数据的选取策略和多个数据的组合策略,Page21,特性建模,特性建模的目的澄清规格验证规格的正确性（完整、清晰无岐义）根据模型覆盖率策略推导测试用例常见的建模手段状态图节点覆盖、边覆盖、路径覆盖流程图语句覆盖（节点覆盖）、判定覆盖（边覆盖）、条件覆盖、路径覆盖判定树分支（判定）覆盖、路径覆盖判定表模型也只能表达系统的主要方面，测试执行人员仍然需要不断的探索,Page22,流程图,为了达到不同的覆盖，确定输入的A.B.C的取值，每个取值组合就是一个用例的输入,Page23,语句覆盖（节点覆盖）,保证每个语句被执行一次,Page24,判定覆盖（边覆盖）,保证每个条件判断的所有取值都被覆盖一次,Page25,判定条件覆盖,保证每个条件判断的所有取值都被覆盖一次同时满足判定覆盖的标准,Page26,路径覆盖,覆盖所有可能出现的边的组合,Page27,等价类和边界值,这是确定单个输入的选取策略等价类划分：等价类划分是基于这样一种假设，对被测单元的输入、输出进行分类，对每一个分类中的所有输入，被测单元都具有等价的行为。如果同一个等价类中的任一个数据可以测试出问题，则该等价类中的其它数据也都能测试出同样的问题。如果测试不出问题，其它数据也同样测试不出问题。所以可以在每个等价类中只选择一个值做为测试用例。,Page28,网上订书，一次只能订199本书，等价类的划分方式？,等价类,-3,17,121,Page29,等价类和边界值,等价类划分原则：1、如果输入条件规定了取值范围，则可导出一个有效等价类和两个无效等价类，如1参数92、如果输入条件规定了输入值的集合，或规定了“必须如何”的条件则可确定一个有效等价类和一个无效等价类，如“以字母开头的串”3、如果已划分的等价类中各元素在程序流程中的处理方式不同，则必须将此等价类再次进行细分,Page30,边界值,考虑取值范围199的边界值,01,99100,Page31,等价类和边界值,边界值法：边界值分析方法是等价类划分方法的一个补充，事实上，边界值分析和等价类划分常常是结合一起来使用的。边界值分析假定错误更多地存在于两个或者多个划分的边界上。相应地为边界上及其两侧的情况设计测试用例。边界值测试在软件变得复杂的时候也会变得不实用。边界值分析对于非向量类型的值（如枚举类型的值）也没有意义,Page32,完毕的测试数据,非法取值等价域还需要考虑空非数字,-3,17,121,01,99100,考虑取值范围199的边界值,Page33,基本的组合策略,确定多个输入数据的组合策略，每个数据的取值根据前面说的等价类和边界值的方法进行选取目的：用尽量少的用例达到最大的覆盖率，发现尽可能多的问题基本方法BC（BaseChoice）OA（OrthogonalArray）,Page34,BC,一元覆盖。开始于先确认一个基本测试用例，然后以基本测试用例为基础，通过更改一个参数的取值创建新的测试用例（同一时间变化一个参数的值，其他参数的取值不变）,Page35,OA,特征是所有的一元、二元（pair-wise）、三元组合在测试用例中都出现过，而且都以相同的次数出现。由于在特定的输入条件下，符合上述条件的严格正交的表未必存在，因而正交阵列用例生成策略只保证对被测系统输入域的覆盖性。考虑到组合效果以及效率因素，二元（pair-wise）组合使用范围最为广泛。因此OA策略常常单指二元组合下的OA策略。关于OA组合的开源工具很多，我们推荐大家使用PICT,Page36,PICT,基本用法是将每个域的取值写到一个TXT文件（model文件）中，交给pict执行即可输出慢二元覆盖(pair-wise)策略的组合，如上输出9个用例PICT的model文件中可以指定一些具体的取值策略，比如两个取值之间的约束关系，更具体的可以参考PICTHelpe.htm文件,Page37,考虑健壮性测试,健壮性测试就是要考虑每个输入的非法取值等价域，这些等价域对于组合策略是有影响的；一般认为多个输入的非法取值等价域是不需要组合的，因为程序每遇到一个非法取值就应该返回BC策略可以剔除存在两个及其以上非法等价域的测试用例OA策略一组用例中非法等价域只能出现一次以上这些限制都可以在PICT的model文件中明确定义，取值前加表示非法取值,Page38,FAQ,失效和缺陷的区别失效是用户看到的产品的一个错误行为，而缺陷是开发人员看到的代码错误，一个代码错误很可能对应多个失效测试人员只看到失效，切计不要被开发人员多个失效是同一个缺陷导致的话所诱惑，每个失效要独立跟踪，在开发更正之后也要为每个失效而进行独立的回归测试，,Page39,FAQ,既要使用显示规格，也要使用隐式规格说明隐式规格是一个没有经过用户确认但确是有用的信息，它的威信来自于其内容的说服力和可信性，而不是客户的批准或者是某个开发、测试人员的认可。隐式规格来源很多，比如：竞争对手的产品、相关产品、同一产品的老版本、顾客意见、GUI风格指南、测试人员自己的丰富经验，.期望开发将所有的隐式规格提前挖掘出来放入显示规格说明是不现实的，也是没有必要的当产品违背隐式规格的时候，测试报告必须详细，比如：“在windows各个软件中，ctrl+c表示拷贝，而在我们的产品中，ctrl+c确用于XXX目的，将导致用户日常工作的困惑”，而不能仅仅说“XXX是不对的，需要修改”。这些问题单是否被接受取决于隐式规格内容是否足够权威！,Page40,FAQ,用例设计的时候要避免魔鬼数字“在用户名输入框中输入1024个字符,这1024从何而来？其本意只是一个超长的用户名而已，听说测试过程必须具体化，所以就写下了自己心中的数字用例过于详细没有好处，一定要避免与测试概念无关的细化。过于细化的用例也是难以维护和重用，而且随着时间的流逝，还会给未来的测试人员带来障碍所写的测试用例要能让未来的测试人员有创造力和判断力去执行更好的一种写法”在用户名输入框中输入远远超过其最大长度的字符数量,Page41,FAQ,不管我怎么努力，总是有漏测，真是失败！必须端正认识，绝对不要有这种悲观的意识测试人员的任务是找出并报告重要的问题，而不是所有的问题。如果你真的认为已经发现了所有的问题，要么产品太简单，要么测试人员的想象力太差！承认不可能发现所有的问题