资源子库 培训PPT 《移动应用测试工程师》-回归测试用户体验测试.pptxVIP

回归测试用户体验测试01 回归测试02 用户体验测试03冒烟测试目录 / CONTENTS第一章回归测试回归测试的定义回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误的一种测试方法。 1、回归测试是指重复以前的全部或部分的相同功能测试 2、新加入测试的模块，可能对其他模块产生副作用，因此要进行某些程度的回归测试 3、回归测试的重心，是以关键性模块为核心回归测试的意义 在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁在极端编程方法中，更是要求每天都进行若干次回归测试；通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的做回归测试的测试用例的选择第一部分：对于一个软件开发项目来说，项目的测试组在实施测试的过程中会将所开发的测试用例保存到“测试用例库”中，并对其进行维护和管理。当得到一个软件的基线版本时，用于基线版本测试的所有测试用例就形成了基线测试用例库。在需要进行回归测试的时候，就可以根据所选择的回归测试策略，从基线测试用例库中提取合适的测试用例组成回归测试包，通过运行回归测试包来实现回归测试。保存在基线测试用例库中的测试用例可能是自动测试脚本，也有可能是测试用例的手工实现过程。做回归测试的测试用例的选择第二部分：测试用例的维护是一个不间断的过程，通常可以将软件开发的基线作为基准，维护的主要内容包括下述几个方面：删除过时的测试用例改进不受控制的测试用例删除冗余的测试用例增添新的测试用例做回归测试的测试用例的选择第三部分：选择回归测试应该兼顾效率和有效性两个方面，常用的选择回归测试的方式包括两方面：再测试全部用例基于风险选择测试回归测试的基本过程重点测试软件中被修改的部分。从原基线测试用例库中，排除所有不再适用的测试用例，确定那些对新的软件版本依然有效的测试用例，其结果是建立一个新的基线测试用例库。依据一定的策略从测试用例库中选择测试用例测试被修改的软件。如果必要，生成新的测试用例集，用于测试无法充分测试到的软件部分。用新软件测试用例集执行修改后的软件。第二章用户体验测试用户体验测试的定义以主观的普通消费者的角度去感知产品或服务的舒适、有用、易用、友好亲切程度。通过不同个体、独立空间和非经验的统计复用方式去有效评价产品的体验特性提出修改意见提升产品的潜在客户满意度。用户体验测试的关注点是否有空数据界面设计，引导用户去执行操作。是否滥用用户引导。是否有不可点击的效果，如：你的按钮此时处于不可用状态，那么一定要灰掉，或者拿掉按钮，否则会给用户误导菜单层次是否太深交互流程分支是否太多相关的选项是否离得很远用户体验测试的关注点一次是否载入太多的数据界面中按钮可点击范围是否适中标签页是否跟内容没有从属关系，当切换标签的时候，内容跟着切换操作应该有主次从属关系是否定义Back的逻辑。涉及软硬件交互时，Back键应具体定义是否有横屏模式的设计，应用一般需要支持横屏模式，即自适应设计?第三章冒烟测试冒烟测试的由来冒烟测试这个名称的来历，最初是从电路板测试得来的。因为当电路板做好以后，首先会加电测试，如果板子没有冒烟再进行其它测试，否则就必须重新来过。如下图：冒烟测试的定义在软件研发中，冒烟测试其实是微软首先提出来的一个概念，和微软一直提倡的每日build（构建版本）有很密切的联系。具体说，冒烟测试就是在每日build（构建版本）建立后，对系统的基本功能进行简单的测试。这种测试强调程序的主要功能进行的验证，而不会对具体功能进行更深入的测试。冒烟测试的误区（一）：冒烟测试为一个测试阶段有些团队在定制流程时会有一个阶段叫冒烟测试，但是就算不通过也会继续做后面其它部分的测试。我们反过头来看当时微软提出来的这个概念，它的重点其实在于 daily build ，也就是说冒烟测试是随着每一次构建而走的，它应该是一个开关而不是一个研发流程中的测试阶段。过，你可以继续后面的测试。不过，直接返工等待下一次的构建。冒烟测试的误区（二）：冒烟测试需要把此次需求的主流程都走一遍一些团队通常为了督促开发人员提高研发质量而把冒烟通过率作为一个衡量指标。冒烟测试主要是测试系统的主流程是否可用，如果这次的需求不涉及到太多主流程上面的更改，那真的有必要把这些案例都加入到冒烟测试中么？冒烟测试和回归测试的区别冒烟测试就是完成一个新版本的开发后，对该版本最基本的功能进行测试，保证基本的功能和流程能走通。如果不通过，则打回开发那边重新开发；如果通过测试，才会进行下一步的测试(功能测试，集成测试，系统测试等等)。冒烟测试优点是节省测试时间，防止build失败。缺点是覆盖率还是比较低。回归测试有两层理解：一是，当你修复一个bug后，把之前的测试用例再次应用到修复后的版本上进行测试。二是，当一个新版本开发好后，而且冒烟测试