测试过程介绍优秀PPT.ppt
测试过程介绍你现在浏览的是第一页，共28页本次交流的主要内容本次交流的目的测试的分类测试的阶段华为的测试流程一些值得借鉴的地方软件部对测试的一些建议测试部对软件部的一些建议的收集你现在浏览的是第二页，共28页本次交流的目的通过对测试方法的简单回顾和对华为公司测试过程的分析和借鉴,希望在以后对测试方法或者过程的优化改进中有所帮助.你现在浏览的是第三页，共28页测试的分类两种常用的测试方法 黑盒测试 白盒测试你现在浏览的是第四页，共28页黑盒测试的测试用例设计黑盒测试的测试用例设计 等价类划分 边界值分析 错误推测法 因果图你现在浏览的是第五页，共28页等价类划分等价类划分等价类划分是一种典型的黑盒测试方法，使用这一方法时，完全不考虑程序的内部结构，只依据程序的规格说明来设计测试用例。等价类划分方法把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据做为测试用例。你现在浏览的是第六页，共28页使用这一方法设计测试用例要经历划分等价类（列出等价类表）和选取测试用例两步。划分等价类等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。测试某等价类的代表值就等价于对这一类其它值的测试。你现在浏览的是第七页，共28页等价类的划分有两种不同的情况：有效等价类：是指对于程序的规格说明来说，是合理的，有意义的输入数据构成的集合。无效等价类：是指对于程序的规格说明来说，是不合理的，无意义的输入数据构成的集合。在设计测试用例时，要同时考虑有效等价类和无效等价类的设计。你现在浏览的是第八页，共28页例如，在程序的规格说明中，对输入条件有一句话：“项数可以从1到999”则有效等价类是“1项数999”两个无效等价类是“项数1”或“项数999”。在数轴上表示成:你现在浏览的是第九页，共28页边界值分析边界值分析边界值分析也是一种黑盒测试方法，是对等价类划分方法的补充。人们从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。你现在浏览的是第十页，共28页比如，在做三角形计算时，要输入三角形的三个边长：A、B和C。我们应注意到这三个数值应当满足 A0、B0、C0、ABC、ACB、BCA，才能构成三角形。但如果把六个不等式中的任何一个大于号“”错写成大于等于号“”，那就不能构成三角形。问题恰出现在容易被疏忽的边界附近。你现在浏览的是第十一页，共28页这里所说的边界是指，相当于输入等价类和输出等价类而言，稍高于其边界值及稍低于其边界值的一些特定情况。使用边界值分析方法设计测试用例，首先应确定边界情况。应当选取正好等于，刚刚大于，或刚刚小于边界的值做为测试数据，而不是选取等价类中的典型值或任意值做为测试数据。你现在浏览的是第十二页，共28页错误推测法错误推测法人们也可以靠经验和直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的例子。这就是错误推测法。错误推测法的基本想法是：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。你现在浏览的是第十三页，共28页因果图因果图因果图的适用范围如果在测试时必须考虑输入条件的各种组合，可使用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来设计测试用例，这就需要利用因果图。因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。此方法比较复杂,有兴趣的可以研究一下.你现在浏览的是第十四页，共28页黑盒测试总结黑盒测试总结一般不会单独采用一种方法来设计用例,会综合几种方法,多方面,多角度的设计用例,以达到测试的全面性和系统性.你现在浏览的是第十五页，共28页白盒测试的测试用例设计白盒测试的测试用例设计 语句覆盖语句覆盖就是设计若干个测试用例，运行被测程序，使得每一可执行语句至少执行每一可执行语句至少执行一次一次。判定覆盖判定覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判断的取真分支程序中每个判断的取真分支和取假分支至少经历一次和取假分支至少经历一次 条件覆盖条件覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判每个判断的每个条件的可能取值至少执行一次断的每个条件的可能取值至少执行一次 路径覆盖路径测试就是设计足够的测试用例，覆盖程序中所有可能的路径覆盖程序中所有可能的路径你现在浏览的是第十六页，共28页测试的阶段V模型介绍你现在浏览的是第十七页，共28页华为的测试流程你现在浏览的是第十八页，共28页测试部的前期工作需求阶段:测试部会在开发人员写需求分析的时候就派人跟踪此项目,在这个阶段完成系统测试用例的设计,通过此工作来验证需求的可测试性和合理性.概要设计阶段:此阶段测试部会完成集成测试用例的设计和用例的写作你现在浏览的是第十九页，共28页系统测试介绍测试策略定义测试那些用例.定义重点测试的模块.定义预测试通过的条件.测试风险,以及规避措施等.测试计划定义测试时间测试人员,测试环境,测试仪表,测试版本等测试报告对整个系统做出一个评价.分模块进行评价.给出下一轮测试的测试建议和测试重点.你现在浏览的是第二十页，共28页值得借鉴的地方(1)测试用例库测试简单,方便,提高测试效率.方便制定测试策略.完成测试经验的积累和共享.自动测试能够完成大部分机械性的操作,节省人力,提高开发效率.测试人员可以设计出更加优秀的测试用例.你现在浏览的是第二十一页，共28页值得借鉴的地方(2)测试策略和计划在测试之前根据实际情况,制定测试内容,测试计划,对测试有着很强的指导意义.为以后测试的改进做好准备.带分析的测试报告你现在浏览的是第二十二页，共28页值得借鉴的地方(3)测试方法:为了保证测试的质量和投入,测试部一般会对版本进行预测试,预测试通过之后会按测试计划来进行测试,如果预测试不通过会打回到开发,此种情况会影响开发团队的考核.一旦通过预测试,则需要完成整个测试计划,这样可以减少测试版本,缩短开发周期.系统测试过程一般测试三轮,第一轮为全局测试,第二轮为重点模块测试,第三轮为回归测试,主要针对第二轮的问题单进行测试和开局的模拟验证,如果不能达到发布条件则需要进行下一轮测试.你现在浏览的是第二十三页，共28页系统测试的依据任何事情都要有个评判的依据,对于目前我们的手机项目来说,测试的依据就是开发人员提供的“规格书”,凡是和规格书不一致的地方都可以认为是问题.当然也不排除规格书有误的地方,这些也需要提出来要求开发人员改正,以保证资料的正确性和权威性.你现在浏览的是第二十四页，共28页对测试人员的要求需要了解代码.需要经常和开发人员进行交流,提升自己对系统的理解能力。能够大致评估开发人员修改带来的影响.能够清晰的描述问题,并进行初步定位,给出参考意见.多从用户的实际使用角度来设计用例.能够考虑各种异常情况.你现在浏览的是第二十五页，共28页软件部对测试部的一些建议1.问题单描述不清楚，不规范，不容易看懂.2.重现条件需要写清楚.3.对于A类bug如果自己不能确认的需要和开发人员确认.4.极限操作要在合理的范围之内.你现在浏览的是第二十六页，共28页测试部对软件部的一些意见征集1.2.3.你现在浏览的是第二十七页，共28页谢谢大家!你现在浏览的是第二十八页，共28页
