精华内容
下载资源
问答
  • 我回答当然会呀,自己的代码怎么不测呢。现在想想我好像误会他的意思了,他应该是想问我关于单元测试,集成测试以及背后相关的知识,然而当时说到测试,我也只知道 Junit。那么今天就说说开发过程中涉及到的测试...

    记得以前面试的时候,面试官问我,平常开发过程中自己会不会测试?我回答当然会呀,自己写的代码怎么不测呢。现在想想我好像误会他的意思了,他应该是想问我关于单元测试,集成测试以及背后相关的知识,然而当时说到测试,我也只知道 Junit。那么今天就说说开发过程中涉及到的测试以及相关的技术栈。


    虽然测试分为单元测试,集成测试,系统测试等等,但是作为开发,我们可能不需要做这么多的测试(有时甚至不做……)接下来就说说和开发息息相关的单元测试以及集成测试。


    单元测试就是模块测试,我的理解一个模块就是一个类,主要是指我们的 Service 模块,因为一个项目中大部分的业务逻辑都在 Service 层。我们专注测试 Service 中的方法即可。集成测试也就是多个模块的联合测试,Service 之间,Service 和 Dao 这种多个模块之间的综合测试。


    说了测试的分类,那我们该怎么测试呢?我们常使用的就是 Junit 框架,说到测试,我之前一直没搞清楚,直到现在才有点头绪,不知道你们会不会遇到这种问题,在测试中若是涉及到 find 方法还好,但是涉及到修改数据的操作,我们的测试 case 是不能重复执行的,因为会报错,这真的很尴尬,一方面是数据不正确,一方面是数据库产生了大量了垃圾数据。


    怎么避免这种情况呢?分不同的情况,若是测试的项目比较简单(表的数量不多)我们可以配置一个 test 的 profile,在文件中配置 H2 内存数据库,这样就不会影响到正常的数据库,但是 H2 相关的配置还挺烦,还要自己建表,插入相关的数据。


    怎么才能在单元测试中,不需要依赖数据库,又可以保证 test case 可以重复的执行呢?这里就要说 Mock 模式了,mock 翻译过来就是 “假的”,这个假指的是测试模块以外的模块都用假的实例来代替,这样既能保证测试能正常执行不影响数据库,也可以验证业务逻辑是否正确(这里我先入为主的认为单元测试主要就是测试 Service 层多样的业务逻辑)。


    而 Java 中应用 Mock 模式测试最好的框架就是 Mockito,虽然也有其它 Mock 模式的测试框架,但不在我们考虑范围之内哈。我自己在项目中也使用 Mockito 框架,本来很不习惯这种什么都是 Mock 的形式,但是现在感觉,嗯,真香!所以要赶紧分享给你们。


    Mockito 的优点,就是与 Junit 结合的很好,使用超方便,测试代码简洁,可读性非常好(熟悉写法之后才能感觉出来),同时也是最受欢迎的 Java 测试框架。


    说一说我的感触,使用 Mockito 框架写 test case 时,一定要搞清楚什么需要假,什么需要真,不然你会发疯的,有一种都是 fake 的感觉。下面就看看怎么 quick start 吧!我这里使用的 Spring Boot2,Junit5,Mockito3,IDEA2019.3.4,Maven 的组合形式,一切都是新鲜的,最后会给出 Demo 项目,你也可以拿去练练手哦。


    下面直接看个例子,这个例子我是故意这样写的,用来表示业务逻辑复杂,至少需要 3 个 case 才能百分百覆盖方法。分别是 username 不为空,username 为 “Kris”,username 为空。


    待测方法:

    @Service
    public class UserServiceImpl implements UserService{
    
        @Autowired
        private UserDao userDao;
    
        @Override
        public User save(User user) {
            if(!user.getUsername().isEmpty()) {
                if(user.getUsername().equals("Kris")){
                    user.setAge(18);
                    return userDao.save(user);
                }
                return userDao.save(user);
            } else {
                return null;
            }
        }
    }
    

    标准的测试案例应该如下,这三个 test case 就可以将 save 方法百分百覆盖,我们可以使用 run with coverage 去执行测试模块,可以看到覆盖率。

    @ExtendWith(MockitoExtension.class)
    class UserServiceTest {
    
        @InjectMocks
        UserServiceImpl userService;
    
        @Mock
        UserDao userDao;
    
        @Test
        void save() {
            Mockito.when(userDao.save(Mockito.any())).thenReturn(new User("test",12));
            User user = userService.save(new User("test",12));
            assertEquals("test",user.getUsername());
        }
    
        @Test
        void save1() {
            Mockito.when(userDao.save(Mockito.any())).thenReturn(new User("Kris",12));
            User user = userService.save(new User("Kris",3));
            assertEquals(12,user.getAge());
        }
    
        @Test
        void save3() {
            User user = userService.save(new User("",12));
            assertNull(user);
        }
    }
    
    

    下面就说说为什么这样写以及可能遇到的坑!


    首先我自己就遇到一个大坑,我本地使用的是 IDEA,怎么都不能 run 测试案例,原因是在 IDEA2016.2 开始自动引入 Junit5 的 jar 包,然而这个自动引入依赖做的并不好,我的理解就是有 bug,人家 Junit5 一直在升级,需要你画蛇添足的自动引入嘛!不需要啊亲。我本地使用的 IDEA 是 2017.1 版本,Junit5 给的参考文档说最好用 2017.3 及之后的版本,搞了半天我本地还是不能 run test case, 气死人啊,不得已我升级了 IDEA,现在版本是最新的 2019.3.4 了,没问题了。


    下面就是代码层面的坑了:

    第一,不要忘记加 @ExtendWith(MockitoExtension.class) 这个注解 Junit5 才有,就是添加 Mock 执行的环境,初始化 Mock 实例以及严格绑定 stubbings(等下仔细介绍这个)。

    第二,我们这里测试的 UserService 接口中的所有方法,注意注入待测试对象时要注入实现类 UserServiceImpl,因为我们要正经测试的是这个模块。若是有依赖其它的 Service,可以直接 @Mock 接口。

    第三,待测试类中若是依赖了其它的对象,需要使用 @Mock 引入相关模块,但是待测试类本身要使用 @InjectMocks 注解,如上 UserServiceImpl。

    第四,形如
    Mockito.when(userDao.save(Mockito.any())).thenReturn(new User("test",12));
    就是一个 stubbing(存根),我的理解是在测试过程中会遇到 userDao.save(User user) 方法,为了作假就提前设置好,类似于我把这个 stub 先存下来,反正你会遇上的,而且 Mockito3 中要求,写的 stub 必须要使用到,不然就会报 UnnecessaryStubbingException 异常,这个异常经常出现,所以说 stub 多一个不行,少一个也不行!注意看 save3 这个 caes 就没有 stub, 因为不能写,一写就报错。

    第五,stub 中会定义具体的返回值,所以说,虚拟方法最终的返回值是由 thenReturn() 自定义的,和传入的参数没有关系。而且在 when() 中 Mock 的方法的参数,必须使用 Mockito.any 或类似的 Mockito.anyLong() 这种形式,不能写具体的值!既然方法都是假的,参数没有必要给真的,给了就报错,作假就要做全套嘛。

    第六,最后就是测试的方法若是需要参数,一定不能参入 Mockito.any 这种虚假参数,随便你写什么,看着不要报空指针异常就行,因为你测试的就是这个方法,你还用虚拟参数,那你真的是假到家了,这里一定要想搞清楚,你到底测试的是哪个方法,你又想 Mock 哪个方法,建议和第五点一起看。

    刚刚说了 stub 多了也会报错,这是因为在 Mockito3 中设置了严格的 stub,不允许你多写,但是,你可以在方法或是类上使用注解 @MockitoSettings(strictness = Strictness.LENIENT) 这样就对 stub 宽容了,多了也没关系,默认的值是 Strictness.STRICT_STUBS,我倒是建议不要改默认值,代码还简洁一点。

    对了,怕你们没明白,再说一遍,Mock 是一种测试的模式,我们说 Mock 模式的测试,就是怎么在测试中做假但是又可以真正测到自己想测的模块,而 Mockito 是 Mock 模式的一种实现,是一个测试的技术框架。

    在测试中,一个常见的异常就是空指针,这个比较简单发现,可能是没有 @Mock 某些依赖对象,或是没有为待测方法参数赋值,或是 thanReturn() 中定义的返回值缺少属性。

    一个完美的测试案例应该是一行代码都不能少的那种,也不要多写,也不要多赋值,需要什么就添加什么。上面总结的几点都是我在写测试案例时的最佳实践,希望可以帮到你们,若是还有其它的问题,可以私信我,一起学习。

    关注公众号,后台回复【测试】,即可获得完整 Demo
    在这里插入图片描述

    展开全文
  • ---------------------测试用例编号...集成测试用例:产品编号-IT-集成测试项名-集成测试子项名-数据资料库 单元测试用例:产品编号-UT-单元测试项名-单元测试子项名-影片库   ---------------------测试项目  ...

    ---------------------测试用例编号
     规则:编号具有唯一性、易识别性,由数字和字符组合成的字符串
     约定:
    系统测试用例:产品编号-ST-系统测试项名-系统测试子项名-数据库
    集成测试用例:产品编号-IT-集成测试项名-集成测试子项名-数据资料库
    单元测试用例:产品编号-UT-单元测试项名-单元测试子项名-影片库

     


    ---------------------测试项目
     规则:当前测试用例所属测试大类、被测需求、被测模块、被测单元等
     


    ---------------------测试标题
    规则:测试用例的概括简单的描述用例的出发点、关注点,原则上不能重复。
    ---------------------重要级别
    规则
    高:保证系统基本功能、核心业务、重要特性、实际使用频率高的测试用例;
    中:重要程度介于高和低之间的测试用例;
    低:实际使用频率不高、对系统业务功能影响不大的模块或功能的测试用例。

     


    ---------------------预置条件
    规则:执行当前测试用例需要的前提条件,是后续步骤的先决条件
    输入
    规则:用例执行过程中需要加工的外部信息,输入、文件、数据库等

     

    ---------------------操作步骤
    规则:执行当前测试用例需要经过的操作步骤,保证操作步骤的完整性。

     


    ----------------------预期输出
    规则:当前测试用例的预期输出结果,包括返回值的内容、界面的响应结果、输出结果的规则符合度等

    展开全文
  • ????一、软件测试基础知识 ...如何写测试用例 设计测试用例的方法(黑盒白盒具体) 如何测试脚本 什么样的项目适合自动化测试 5.怎么测试网络协议 6.web测试 7.app测试(和web测试的区别) 8.游戏测...

    🌟一、软件测试基础知识
    1.二八定律、软件质量的六个特征、软件测试的W模型和V模型
    2.单元测试、集成测试、系统测试、验收测试、回归测试
    3.黑盒与白盒的测试方法
    4.测试项目具体工作
    什么样的测试用例是好的测试用例
    如何写测试用例
    设计测试用例的方法(黑盒白盒具体)
    如何写测试脚本
    什么样的项目适合自动化测试
    5.怎么测试网络协议
    6.web测试
    7.app测试(和web测试的区别)
    8.游戏测试
    9.系统有大量并发如何测试、一般物品的测试
    10.如何提交一个高质量的bug?(bug相关)
    11.用户界面登陆过程都需要做哪些分析?即使视频测试
    12.设计模式

    🌟二、计算机网络
    添加链接描述
    +cookie

    🌟三、操作系统
    1.线程和进程的区别
    2.死锁
    3.页面置换算法
    4.多线程和并发的区别
    5.进程的状态转换图

    🌟四、linux
    1.查看端口号、进程的指令是?动态查看日志的指令?怎么判断一个端口存不存在,磁盘满了怎么处理,删除一个目录下的txt文件,你还熟悉其他什么linux指令?

    🌟五、数据库
    1.索引
    2.连接
    3.基本操作

    🌟六、c++
    1.多态的实现
    2.虚函数和纯虚函数
    3.构造函数和析构函数
    4.深copy浅copy
    5.关键字 static final

    展开全文
  • 软件测试基础知识

    2019-03-13 10:36:07
    1.4测试用例怎么写 1.5bug的严重程度和优先级 1.6敏捷测试 1.7测试驱动开发(TDD) 2.测试方法 2.1单元测试、集成测试、系统测试、回归测试、验收测试 单元测试 集成测试 系统测试 回归测试 验收测试 ...

    目录

    1.软件测试基础

    1.1什么是软件测试

    1.2软件测试目的  

    1.3软件测试流程

    1.4测试用例怎么写

    1.5bug的严重程度和优先级

    1.6敏捷测试

    1.7测试驱动开发(TDD)

    2.测试方法

    2.1单元测试、集成测试、系统测试、回归测试、验收测试

    单元测试

    集成测试

    系统测试

    回归测试

    验收测试

    冒烟测试

    2.2黑盒测试、白盒测试、灰盒测试

    黑盒测试

    白盒测试

    灰盒测试

    2.3静态测试、动态测试

    静态测试

    动态测试

    2.4手工测试与自动化测试

    2.5功能测试和非功能测试

    2.5.1功能测试

    2.5.2非功能测试

    3.web测试

    4.app测试

    4.1app 性能测试的指标

    4.2测试工具

    功能测试自动化

    性能测试

    专项测试

    4.3  Android测试 与 iOS测试



    1.软件测试基础

    1.1什么是软件测试

    首先要明确测试的定义,所谓测试,就是以检验产品是否满足需求为目标。

    软件测试:在规定的条件下对程序进行操作,以发现错误,对软件质量进行评估。

    1.2软件测试目的  

    软件测试员的目标是尽可能早地找出软件缺陷,并确保其得以修复。

    按照软件质量国家标准 GB-T8566–2001G,软件质量可以用下列特征来评价:
    a.功能特征:与一组功能及其指定性质有关的一组属性,这里的功能是满足明确或隐含的需 求的那些功能。
    b.可靠特征:在规定的一段时间和条件下,与软件维持其性能水平的能力有关的一组属性。
    c.易用特征:由一组规定或潜在的用户为使用软件所需作的努力和所作的评价有关的一组属性。
    d.效率特征:与在规定条件下软件的性能水平与所使用资源量之间关系有关的一组属性。
    e.可维护特征:与进行指定的修改所需的努力有关的一组属性。
    f.可移植特征:与软件从一个环境转移到另一个环境的能力有关的一组属性。

    系统测试结束标准:

    被测对象基本满足需求规格及范围
    未发现严重级别的缺陷,且一般性缺陷数小于10个
    已拒绝、已挂起的缺陷均已正确处理
    系统测试报告已出

    1.3软件测试流程

    测试最规范的过程如下:需求测试->概要设计测试->详细设计测试->单元测试->集成测试->系统测试->验收测试(来自 W 模型)

    详细的描述一个测试活动完整的过程

    1. 项目经理通过和客户的交流,完成需求文档,由开发人员和测试人员共同完成需求文档的评审,评审的内容包括:需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员,测试人员以及客户的意见,完成项目计划。
    2. 开发人员根据需求文档完成需求分析文档,测试人员进行评审,评审的主要内容包括是否有遗漏或双方理解不同的地方。测试人员完成测试计划文档,测试计划包括的内容上面有描述。
    3. 测试人员根据修改好的需求分析文档开始写测试用例,同时开发人员完成概要设计文档,详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。
    4. 测试用例完成后,测试和开发需要进行评审。
    5. 测试人员搭建环境
    6. 开发人员提交第一个版本,可能存在未完成功能,需要说明。测试人员进行测试,发现BUG后提交到bug管理系统。
    7. 开发提交第二个版本,包括Bug Fix以及增加了部分功能,测试人员进行测试。
    8. 重复上面的工作,一般是3-4个版本后BUG数量减少,达到出货的要求。
    9. 执行自动化测试,编写脚本,执行,分析,报告;进行性能测试,压力测试等其他测试,执行,分析,调优,报告。
    10. 编写测试报告
    11. 如果有客户反馈的问题,需要测试人员协助重现并重新测试

    1.4测试用例怎么写

    用例编号、用例类型、用例标题(名称)、前置条件、操作步骤、测试数据、预期结果、实际结果

    1.5bug的严重程度和优先级

    Bug 的 priority()和 severity()是两个重要属性,通常人员在提交bug 的时候,只定义severity,而将 priority 交给 leader 定义,通常 bug 管理中,severity 分为四个等级 blocker、critical、major、minor/trivial,而 priority 分为五个等级 immediate、urgent、high、normal、low。

    Severity(严重程度)

    1、blocker:即系统无法执行,崩溃,或严重资源不足,应用模块无法启动或异常退出,无法测试,造成系统不稳定。

    • 严重花屏
    • 内存泄漏
    •  用户数据丢失或破坏
    • 系统崩溃/死机/冻结
    • 模块无法启动或异常退出
    • 严重的数值计算错误
    • 功能设计与需求严重不符
    • 其它导致无法测试的错误, 如服务器500错误

    2、critical:即映像系统功能或操作,主要功能存在严重缺陷,但不会映像到系统稳定性。

    •  功能未实现
    • 功能错误
    • 系统刷新错误
    • 数据通讯错误
    • 轻微的数值计算错误
    •  影响功能及界面的错误字或拼写错误
    • 安全性问题

    3、major:即界面、性能缺陷、兼容性

    • 操作界面错误(包括数据窗口内列名定义、含义是否一致)
    • 边界条件下错误
    • 提示信息错误(包括未给出信息、信息提示错误等)
    • 长时间操作无进度提示
    •  系统未优化(性能问题)
    • 光标跳转设置不好,鼠标(光标)定位错误
    •  兼容性问题

    4、minor/trivial:即易用性及建议性问题。

    • 界面格式等不规范
    •  辅助说明描述不清楚
    • 操作时未给用户提示
    •  可输入区域和只读区域没有明显的区分标志
    • 个别不影响产品理解的错别字
    •  文字排列不整齐等一些小问题

    Priority(优先级)

    1. immediate:即马上解决,表示问题必须马上解决,否则系统根本无法达到预定的需求。
    2. urgent:急需解决,表示问题的修复很紧要,很急迫,关系到系统的主要功能模块能否正常。
    3. high:高度重视,有时间要马上解决,否则系统偏离需求较大或预定功能不能正常实现。
    4. Normal即“正常处理”,进入个人计划解决,表示问题不影响需求的实现,但是影响其他使用方面,比如页面调用出错,调用了错误的等。
    5. low:在系统发布前解决,或确认可以不用解决。

    1.6敏捷测试

    强调从使用系统的用户(客户)角度出发来测试系统。重点关注持续迭代地测试新开发的功能,而不再强调传统测试过程中严格的测试阶段。同时需要及早介入测试 ,不间断测试,具备条件即测试,持续进行回归测试保证之前测试过内容的正确性。

    敏捷宣言:

        个体与交互 重于 过程和工具 
        可用的软件 重于 完备的文档 
        客户协作 重于 合同谈判 
        响应变化 重于 遵循计划 
        在每对比较中,后者并非全无价值,但我们更看重前者

    传统测试与敏捷测试对比:

    敏捷测试就是符合敏捷宣言思想,遵守敏捷开发原则,在敏捷开发环境下能够很好地和其整体开发流程融合的一系列的测试实践,这些实践具有鲜明的敏捷开发的特征,如TDD、ATDD、结对编程、持续测试等。和传统测试的区分,可以概括如下:

    1)传统测试更强调测试的独立性,将“开发人员”和“测试人员”角色分得比较清楚。而敏捷测试可以有专职的测试人员,也可以是全民测试,即在敏捷测试中,可以没有“测试人员”角色,强调整个团队对测试负责。

    2)传统测试更具有阶段性,从需求评审、设计评审、单元测试到集成测试、系统测试等,从测试计划、测试设计再到测试执行、测试报告等,但敏捷测试更强调持续测试、持续的质量反馈,阶段性比较模糊。

    3)传统测试强调测试的计划性,认为没有良好的测试计划和不按计划执行,测试就难以控制和管理,而敏捷测试更强调测试的速度和适应性,侧重计划的不断调整以适应需求的变化。

    4)传统测试强调测试是由“验证”和“确认”两种活动构成的,而敏捷测试没有这种区分,始终以用户需求为中心,每时每刻不离用户需求,将验证和确认统一起来。

    5)传统测试强调任何发现的缺陷要记录下来,以便进行缺陷根本原因分析,达到缺陷预防的目的,并强调缺陷跟踪和处理的流程,区分测试人员和开发人员的各自不同的责任。而敏捷测试强调面对面的沟通、协作,强调团队的责任,不太关注对缺陷的记录与跟踪。

    6)传统测试更关注缺陷,围绕缺陷开展一系列的活动,如缺陷跟踪、缺陷度量、缺陷分析、缺陷报告质量检查等,而敏捷测试更关注产品本身,关注可以交付的客户价值。在快速交付的敏捷开发模式下,缺陷修复的成本很低。

    7)传统测试鼓励自动化测试,但自动化测试的成功与否对测试没有致命的影响,但敏捷测试的基础就是自动化测试,敏捷测试是具有良好的自动化测试框架支撑的快速测试。

    测试驱动开发(TDD)

    测试驱动开发,英文全称是Test-Driven Development,简称为TDD,它是一种不同于传统软件开发流程的新型的开发方法。它要求在编写某个功能的代码之前先编写好测试代码,然后只编写使测试通过的功能代码,通过测试来推动整个开发的进行。这有助于编写简洁可用和高质量的代码,并加速开发过程。

    简单来说,测试驱动开发是针对一些小功能点甚至小到一个方法的敏捷开发实践。传统的开发模式是开发人员编写完业务代码后再开始编写单元测试脚本来验证上一步的业务功能代码,而测试驱动开发的中心思想却是先根据需求文档来编写测试代码(即先编写单元测试脚本),并思考怎样对这些要实现的业务功能作验证,等编写了足够的单元测试脚本后,再继续编写业务功能代码,通过测试后,再继续迭代以上的过程一直到编写完成所有的业务需求功能模块。

    测试驱动开发与传统开发的区别

    传统开发模式下编写的单元测试脚本其实还是为了验证功能,仍属于测试的一种形式。而测试驱动开发已经不再是一种简单的测试行为了,准确地说,它是一种设计行为。测试驱动开发类似于是对一段代码的用法而编写的设计规格说明,可以从编写代码的内聚性、可测性、可复用性以及缺陷密度、接口的简易水平看出。在测试驱动开发中,以需求的剖析、用户业务功能的理解都是层层递进的,是可以逐步细化到代码级别的,而这样的过程也恰恰提高了测试的覆盖率,同时能从根本上解决一些因业务逻辑设计错误而导致的后期大量的缺陷修复工作。

    测试驱动开发的优缺点

    测试驱动开发最大的优点就是重构了,不断迭代,不断地对现有代码进行重构,不断优化代码的内部结构,最终实现对整体代码的改进。以此不断减少一些设计冗余、代码冗余、接口复杂度等等。
    另外,对于一些前期需求不明确,甚至需求信息量特别少,且后期又会有大量业务功能修改时,传统的开发模式需要加班加点以此赶工开发,测试,缺陷修复,人工、时间成本且不说,最重要的产品质量也无法得到保证。当然 ,这种模式下也最适合采用原型法、敏捷开发模式了,毕竟拥抱变化是敏捷的宗旨 。而测试驱动开发也是敏捷开发模式的基础,这样无论是来自客户的紧急需求还是项目团队的一次技术改革,都可以通过重构设计、增加测试脚本来实现了。

    2.测试方法

    在这里插入图片描述

    2.1单元测试、集成测试、系统测试、回归测试、验收测试

    单元测试

    一般由开发小组采用白盒方式来测试,主要测试单元是否符合“设计”。单元测试是对软件基本组成单元(软件设计的最小单位)进行正确性检验的测试工作,如函数、过程(function,procedure)或一个类的方法(method)。

    集成测试

    集成测试是在单元测试的基础上,将所有模块按照概要设计要求组装成为子系统或系统,验证组装后功能以及模块间接口是否正确的测试工作。集成测试也叫组装测试、联合测试、子系统测试或部件测试。应当避免一次性的集成(除非软件规模很小),而采用增量集成:

    自顶向下集成

    在这里插入图片描述

    从主控制模块开始,沿着程序的控制层次向下移动,逐渐把各个模块结合起来,就是自顶向下的集成。在把附属于主控制模块的那些模块组装到程序结构中去时,可以使用深度优先的策略或者使用宽度优先的策略。所谓深度优先,就是先组装在软件结构的一条主控制通路上的所有模块;宽度优先就是沿软件结构水平地移动,把处于同一个控制层次上的所有模块组装起来。

    自底向上集成

    在这里插入图片描述

    用下述步骤可以实现自底向上的结合策略:

    1. 把低层模块组合成实现某个特定的软件子功能的族;
    2. 写一个驱动程序(用于测试的控制程序),协调测试数据的输入和输出;
    3. 对由模块组成的子功能族进行测试;
    4. 去掉驱动程序,沿软件结构自下向上移动,把子功能族组合起来形成更大的子功能族。
    5. 不断重复2~4步,直到构造起完整的软件结构为止。

    系统测试

    在集成测试完成之后,将已集成好的的软件系统,与计算机硬件环境、外部设置、输入数据、其他依赖软件、用户等结合在一起,进行的一系列测试活动。系统测试是针对整个产品系统进行的测试。

    目的:

    • 确保系统测试的活动是按计划进行的;
    • 验证被测产品与用户需求是否相符,即是否符合需求规格说明书中的各项描述;
    • 检查所有显性与隐性需求均被正确实现;
    • 检查并确保最终系统可以交付验收测试。

    测试依据:需求规格说明书(SRS)&其他用户文档资料

    测试对象:整个被测系统或产品

    集成测试与系统测试:

    集成测试:完成单元测试后,各模块联调测试;集中在各模块的接口是否一致、各模块间的数据流和控制流是否按照设计实现其功能、以及结果的正确性验证等等;可以是整个产品的集成测试,也可以是大模块的集成测试;集成测试主要是针对程序内部结构进行测试,特别是对程序之间的接口进行测试。集成测试对测试人员的编写脚本能力要求比较高。测试方法一般选用黑盒测试和白盒测试相结合。

    系统测试 :针对整个产品的全面测试,既包含各模块的验证性测试(验证前两个阶段测试的正确性)和功能性(产品提交个用户的功能)测试,又包括对整个产品的健壮性、安全性、可维护性及各种性能参数的测试。系统测试测试软件《需求规格说明书》中提到的功能是否有遗漏, 是否正确的实现。做系统测试要严格按照《需求规格说明书》,以它为标准。测试方法一般都使 用黑盒测试法。

    回归测试

    回归测试是指在发生修改之后重新测试先前的测试用例以保证修改的正确性。理论上,软件产生新版本,都需要进行回归测试,验证以前发现和修复的错误是否在新软件版本上再次出现。根据修复好了的缺陷再重新进行测试。回归测试的目的在于验证以前出现过但已经修复好的缺陷不再重新出现。一般指对某已知修正的缺陷再次围绕它原来出现时的步骤重新测试。

    按照常规的做法,当一个缺陷修复完毕后,通常会对修复后的代码进行两种形式的测试。首先是确认测试,以验证该修复程序实际上已经修复了缺陷,二是回归测试,以确保修复部分本身没有破坏已有的功能。需要注意的是,当新的功能添加到现有的应用程序时也适用这一相同的原理。

    自动化回归测试:

      在可能情况下,回归测试必须自动化。用相同的变量和条件一遍又一遍的运行相同的测试,不会产生任何新的缺陷。重复的工作会造成执行测试者的丧失兴趣和注意力不集中,可能在执行回归测试的过程中错失发现潜在缺陷的机会。此外自动化回归测试的另一个优点是,可以添加多个测试用例到该回归测试包而不对花费时间产生太大影响。自动回归测试包可以连夜执行或与手动测试并行运行,并能释放资源。

    验收测试

    验收测试是指系统开发生命周期方法论的一个阶段,这时相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一 项确定产品是否能够满足合同或用户所规定需求的测试。验收测试包括 Alpha 测试和 Beta 测试。
    Alpha 测试

    是由用户在开发者的场所来进行的,在一个受控的环境中进行,也可以是公司内部的用户在模拟实际操作环境下进行的测试;

    环境是受开发方控制的,用户的数量相对比较少,时间比较集中;

    α测试先于β测试执行。
    Beta 测试

    由软件的最终用户在一个或多个用户场所来进行的,开发者通常不在现场,用户记录测试中遇到的问题并报告给开发者,开发者对系统进行最后的修改,并开始准备发布最终的软件;

    环境是不受开发方控制的, 用户数量相对比较多,时间不集中。

    冒烟测试

    冒烟测试就是在每日build(构建版本)建立后,对系统的基本功能(主流程)进行简单的测试。这种测试强调程序的主要功能进行的验证,而不会对具体功能进行更深入的测试。

    2.2黑盒测试、白盒测试、灰盒测试

    黑盒测试

    把测试对象看做一个黑盒子,测试人员完全不考虑程序内部的逻辑结构和内部特性,只依据程序的需求规格说明书,检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。

    测试方法:

    1.等价类划分 等价类划分是将系统的输入域划分为若干部分,然后从每个部分选取少量代表性数据进行测试。等价类可以划分为有效等价类和无效等价类,设计测试用例的时候要考虑这两种等价类。
    2.边界值分析法 边界值分析法是对等价类划分的一种补充,因为大多数错误都在输入输出的边界上。边界值 分析就是假定大多数错误出现在输入条件的边界上,如果边界附件取值不会导致程序出错,那么 其他取值出错的可能性也就很小。
    边界值分析法是通过优先选择不同等价类间的边界值覆盖有效等价类和无效等价类来更有 效的进行测试,因此该方法要和等价类划分法结合使用。
    3.正交试验法 正交是从大量的试验点中挑选出适量的、有代表性的点。正交试验设计是研究多因素多水平的一种设计方法,他是一种基于正交表的高效率、快速、经济的试验设计方法。
    4.状态迁移法状态迁移法是对一个状态在给定的条件内能够产生需要的状态变化,有没有出现不可达的状态和非法的状态,状态迁移法是设计足够的用例达到对系统状态的覆盖、状态、条件组合、状态迁移路径的覆盖。
    5.流程分析法流程分析法主要针对测试场景类型属于流程测试场景的测试项下的测试子项进行设计,这是从白盒测试中路径覆盖分析法借鉴过来的一种很重要的方法。
    6.输入域测试法输入域测试法是针对输入会有各种各样的输入值的一个测试,他主要考虑 极端测试、中间范围测试,特殊值测试 。
    7.输出域分析法 输出域分析法是对输出域进行等价类和边界值分析,确定是要覆盖的输出域样点,反推得到应该输入的输入值,从而构造出测试用例,他的目的是为了达到输出域的等价类和边界值覆盖。
    8.判定表分析法 判定表是分析和表达多种输入条件下系统执行不同动作的工具,他可以把复杂的逻辑关系和多种条件组合的情况表达的即具体又明确;
    9.因果图法 因果图是用于描述系统输入输出之间的因果关系、约束关系。因果图的绘制过程是对被测系 统的外部特征的建模过程,根据输入输出间的因果图可以得到判定表,从而规划出测试用例。
    10.错误猜测法 错误猜测法主要是针对系统对于错误操作时对于操作的处理法的猜测法,从而设计测试用例
    11.异常分析法 异常分析法是针对系统有可能存在的异常操作,软硬件缺陷引起的故障进行分析,分析发生 错误时系统对于错误的处理能力和恢复能力依此设计测试用例。

    白盒测试

    可以访问程序员的代码,并通过检查代码的线索来协助测试——可以看到盒子里面。

    • 保证一个模块中的所有独立路径至少被测试一次;
    • 所有逻辑值均需要测试真(true)和假(false);两种情况;
    • 检查程序的内部数据结构,保 证其结构的有效性;
    • 在上下边界及可操作范围内运行所有循环。

    常用白盒测试方法有逻辑覆盖法,程序插桩技术,基本路径法,符号测试,错误驱动测试

    静态白盒测试:不用运行程序的测试,包括代码检查、静态结构分析、代码质量度量、文档测试等等,它可以由人工进行,充分发挥人的逻辑思维优势,也可以借助软件工具(Fxcop)自动进 行。

    动态白盒测试:需要执行代码,通过运行程序找到问题,包括功能确认与接口测试、覆盖率分析、 性能分析、内存分析等。

    白盒测试中的逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。六种覆盖标准发现错误的能力呈由弱到强的变化:
    1.语句覆盖每条语句至少执行一次。
    2.判定覆盖每个判定的每个分支至少执行一次。
    3.条件覆盖每个判定的每个条件应取到各种可能的值。
    4.判定/条件覆盖同时满足判定覆盖条件覆盖。
    5.条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
    6.路径覆盖使程序中每一条可能的路径至少执行一次。

    灰盒测试

    介于白盒测试与黑盒测试之间的,可以这样理解,灰盒测试关注输出对于输入的正确性,同时也关注内部表现,但这种关注不象白盒那样详细、完整,只是通过一些表征性的现象、事件、标志来判断内部的运行状态,有时候输出是正确的,但内部其实已经错误了,这种情况非常多,如果每次都通过白盒测试来操作,效率会很低,因此需要采取这样的一种灰盒的方法。

    2.3静态测试、动态测试

    静态测试

    静态测试是不运行程序本身而寻找程序代码中可能存在的错误或评估程序代码的过程。  

    动态测试

    动态测试是实际运行被测程序,输入相应的测试实例,检查运行结果与预期结果的差异,判定执行结果是否符合要求,从而检验程序的正确性、可靠性和有效性,并分析系统运行效率和健壮性等性能。

    2.4手工测试与自动化测试

      优点 缺点
    手工测试 1、测试人员具有经验和对错误的猜测能力。
    2、测试人员具有审美能力和心理体验。
    3、测试人员具有是非判断和逻辑推理能力。
    1、重复的手工回归测试,代价昂贵、容易出错。
    2、依赖于软件测试人员的能力。
    自动化测试 1、对程序的回归测试更方便。这可能是自动化测试最主要的任务,特别是在程序修改比较频繁时,效果是非常明显的。由于回归测试的动作和用例是完全设计好的,测试期望的结果 也是完全可以预料的,将回归测试自动运行,可以极大提高测试效率,缩短回归测试时间。
    2、可以运行更多更繁琐的测试。自动化的一个明显的好处是可以在较少的时间内运行更多的测试。
    3、可以执行一些手工测试困难或不可能进行的测试。比如,对于大量用户的测试,不可能同时让足够多的测试人员同时进行测试,但是却可以通过自动化测试模拟同时有许多用户,从而达到测试的目的。
    4、更好地利用资源。将繁琐的任务自动化,可以提高准确性和测试人员的积极性,将测试技术人员解脱出来投入更多精力设计更好的测试用例。有些测试不适合于自动测试,仅适合于手工测试,将可自动测试的测试自动化后,可以让测试人员专注于手工测试部分,提高手工测试的效率。
    5、测试具有一致性和可重复性。由于测试是自动执行的,每次测试的结果和执行的内容的一致性是可以得到保障的,从而达到测试的可重复的效果。
    6、测试的复用性。由于自动测试通常采用脚本技术,这样就有可能只需要做少量的甚至不做修改,实现在不同的测试过程中使用相同的用例。
    7、增加软件信任度。由于测试是自动执行的,所以不存在执行过程中的疏忽和错误, 完全取决于测试的设计质量。一旦软件通过了强有力的自动测试后,软件的信任度自然会增加。
    1、不能取代手工测试
    2、手工测试比自动测试发现的缺陷更多
    3、对测试质量的依赖性极大
    4、测试自动化不能提高有效性
    5、测试自动化可能会制约软件开发。由于自动测试比手动测试更脆弱,所以维护会受 到限制,从而制约软件的开发。
    6、工具本身并无想像

     

     

     

     

     

     

     

     

     

     

     

     

    2.5功能测试和非功能测试

    2.5.1功能测试

    目的:检查产品的功能是否满足用户需求

    工作内容

    • 业务流是否正确实现
    • 功能点是否正确实现
    • 输入输出是否正确实现

    测试工具:QTP(使用 B/S和C/S软件),LoadRunner(C/S软件),Selenium, IBM  Rational Robot

    工作原理:模拟用户操作

    功能测试一般包含哪些测试类型:即黑盒测试方法。

    常见的功能测试用例的设计方法:等价类划分法、边界值分析法、因果图法、正交实验法、判定表法、错误推测法

    2.5.2非功能测试

    性能测试

    目的:验证产品是否满足用户指定性能需求

    测试点:响应时间和资源性能(CPU,I/O,内存,信道,传输速度,响应时间)

    备注:

    • 内存和硬盘的区别

      • 内存临时存储,电脑关机,信息就消失,内存容量小但速度快

      • 硬盘是靠执行存储,断电后也可保存数据,硬盘存储量大但速度慢

    • 信道与宽带有关,与访问人数有关

    • 吞吐量,每个时间单元的处理数据

    • 测试方法:压力测试、负载测试、容量测试等        

    • 高级录制可以获取到每个控件的name值,但普通录制只能定位鼠标移动到的位置

    测试工具:LoadRunner,Webload ,Jmeter,Silk Performance

    工作原理:(B或者C端通过传送协议与Server进行通信)录制时需要选择对应协议。

    安全测试

    目的:验证产品在系统的内部的安全保护机制和系统外对入侵的防护能力

    测试点:

    • 内部包括身份验证,权限,数据的完整一致,数据的保密性(DB中有些数据加密保存)

    • 外部,病毒木马,未授权攻击,传输数据安全(传输过程中密码加密,通过HTTP协议传输)

    测试工具:MBSA,IBM Rational Appscan,X-scan

    工作原理:监控服务器或客户端哪些端口应该被禁止

    功能性的安全问题主要有:

    • 没有口令可成功登录到系统中?

    • 各级用户权限划分是否合理

    • 系统错误与文件访问是否被默认记录

    • 系统配置数据默认保存是临时还是永久性

    • 系统发生故障时是否可以正常恢复

    兼容性测试

    ①web兼容性测试

    主要考量:

    • 浏览器的兼容性
    • 操作系统的兼容性(核心:window,max,iphone)

    测试方法:

    • 人工测试:测试工程师测试主流浏览器和常用操作系统测试主流程和主界面,看看主流程和主页面是否有问题
    • 第三方工具测试:部分情况下,部分浏览器可以依赖第三方工具辅助测试

    ②app兼容性测试

    方向:

    • 硬件设备兼容(手机)
    • 手机操作系统版本兼容性

    测试方法:

    • 人工测试:测试工程师测试主流手机设备对主流程和主功能进行验证测试
    • 第三方测试工具:三方主要以云平台为主

    安装测试

    目的:产品的安装过程和结果进行测试

    工作内容:根据软件的测试特性列表,软件安装,配置文档,设计安装过程的测试用例

    产品安装前的准备工作有:

    • 检查所安装文档是否齐全
    • 检查安装软件的程序文档是否齐全
    • 检查被测软件的安装文件是否齐全
    • 检查软件的文件格式与安装指导中要求的文件格式是否符合

    安装过程中需要的检查工作

    • 所有的预置数据是否齐全
    • 软件环境配置是否合理
    • 硬件环境配置是否合理
    • 安装的过程测试
    • 安装文档的测试

    安装后要做的检查工作:

    • 安装日志的检查
    • 安装完成后,要进行程序的运行联接验证
    • 软件的卸载测试
    • 是否存在临时目录,垃圾文件,是否清除掉了冷补丁
    • 安装软件中的升级测试
    • 软件通过重新安装来升级,考虑到版本兼容性测试
    • 软件在线升级

    安装时异常终止包括:进程终止(操作系统未关闭)断电,断网

    测试对象:安装文件、安装系统、安装文档、配置项

    GUI测试

    即用户界面测试,接口测试。GUI测试无法脱离功能测试而独立存在,否则只能测试外观,布局,而无法测试行为产生的结果

    测试点:

    • 对界面元素进行测试,检查产品界面是否与SRS设计一致(包括布局,外观,配色,元素行为,元素功能)

    • 验证界面元素的交互是否正确。包括:整体界面,独立元素组合,独立元素

    测试想法:先找整体界面,再测组合元素和独立元素(据对用户的影响严重程度来排列定义优先级)

    工具:所有做功能测试的工具都可以做GUI测试

    易用性测试

    目的:检查产品是否符合实际应用情况,是否符合用户使用习惯及特殊要求,操作方式是否合理。同时交互信息是否通俗易懂,是否符合行业规则等等。

    测试点:

    • 过分复杂的功能或指令,提示信息出现错误码

    • 安装过程复杂且耗时

    • 系统错误信息过于简单

    • 语法、语义、格式定义不一致

    容错性测试(又称健壮性测试)

    目的:检查系统容错能力,检查软件在异常条件下自身是否具有防护性措施,确保系统无论接收何种条件触发也不会发生意外事故 。

    测试点:

    • 输入错误或无效的数据类型

    • 输入定义域外的数值

    • 对关键进程或线程杀死,然后观察系统行为;

    • 网络不稳定或DB异常情况下,检查系统响应

    • 手动将系统的正常进程关闭或断开 ,检查系统响应

    文档测试

    并非单纯地指文档测试。需要对一组测试文档进行完整性、正确性、一致性的校验。

    测试点:

    • 仔细阅读每个步骤,检查每个图片,并重现每个文档中的示例。

    • 检查文档的编写是否满足项目要求的文档目的。

    • 检查文档内容是否完善、标记是否正确。

    备份测试

    目的:通过检查软件的备份策略来解决相应的数据丢失风险问题。

    备份策略包括

    • 本地备份

    • 实时备份

    • 本地异步备份

    • 异地异步备份

    • 恢复策略

    配置测试

    包括软件配置和硬件配置。

    通过对被测系统软件与硬件环境的修改,分析每个环境组合对系统性能影响的程度,最后确定系统各项资源的最优分配原则。

    配置测试属于性能测试的一个细分类。

    多语种测试

    又称本地化测试,是指为各个地方开发产品的测试,如英文版,中文版等等,包括程序是否能够正常运行,界面是否符合当地习俗,快捷键是否正常起作用等等,特别测试在A语言环境下运行B语言软件(比如在英文win98下试图运行中文版的程序),出现现象是否正常。

    本地化测试还要考虑:

    • 当语言从A翻译到B,字符长度变化是否影响页面效果。比如中文软件中有个按键叫“看广告”,翻译到英文版本中为 “View advertisement”可能影响页面的美观程度
    • 要考虑同一单词在各个国家的不同意思,比如football在英文中为足球,而美国人使用中可能理解为美式橄榄球。
    • 要考虑各个国家的民族习惯,比如龙个美国中被理解邪恶的象征,但翻译到中国,中国人认为为吉祥的象征

    分辨率测试

    测试在不同分辨率下,界面的美观程度,分为800*600,1024*768,1152*864,1280*768,1280*1024,1200*1600大小字体下测试。一个好的软件要有一个极佳的分辨率,而在其他分辨率下也都能可以运行。

    发布测试

    主要在产品发布前对一些附带产品,比如说明书,广告稿等进行测试
        1.说明书测试
            主要为语言检查,功能检查,图片检查
            语言检查:检查说明书语言是否正确,用词是否易于理解;
            功能检查:功能是否描述完全,或者描述了并没有的功能等;
            图片检查::检查图片是否正确
        2.宣传材料测试
            主要测试产品中的附带的宣传材料中的语言,描述功能,图片
        3.帮助文件测试
            帮助文件是否正确,易懂,是否人性化。最好能够提供检索功能
        4.广告用语
            产品出公司前的广告材料文字,功能,图片,人性化的检查

    3.web测试

    4.app测试

    4.1app 性能测试的指标

    (1)内存

    内存消耗测试节点的设计目标是为了让应用不占用过多的系统资源,且及时释放内存,保障整个系统的稳定性。当然关于内存测试,在这里我们需要引入几个概念:空闲状态、 中等规格、满规格。
    空闲状态指打开应用后,点击 home 键让应用后台运行,此时应用处于的状态叫做空闲;
    中等规格和满规格指的是对应用的操作时间的间隔长短不一,中等规格时间较长,满规格时间较短。
    内存测试中存在很多测试子项,清单如下:
    ●空闲状态下的应用内存消耗;
    ●中等规格状态下的应用内存消耗; ●满规格状态下的应用内存消耗;
    ●应用内存峰值;
    ●应用内存泄露;
    ●应用是否常驻内存;
    ●压力测试后的内存使用。

    内存:使用adb shell脚本进行测试,查看Log数据。adb shell dump meminfo

    (2)CPU

    使用 Android 提供的 view plaincopy 在 CODE 上查看代码片派生到我的代码片 adbshell dumpsys CPUinfo |grep packagename >/address/CPU.txt 来获取; 使用 top 命令 view plaincopy 在 CODE 上查看代码片派生到我的代码片 adbshell top |grep packagename>/address/CPU.txt 来获取。

    CPU:使用adb shell脚本进行测试,查看Log数据。adb shell top

    注意:程序持续运行及操作过程中,内存不能一直增加,不然系统会自动kill掉该进程。

    (3)流量

    网络流量测试是针对大部分应用而言的,可能还有部分应用会关注网速、弱网之类的测试。
    流量测试包括以下测试项:
    应用首次启动流量提示;
    应用后台连续运行2小时的流量值;
    应用高负荷运行的流量峰值。

    流量监控:可以借用网易的开源工具:Emmagee

    (4)电量

    • 测试手机安装目标 APK 前后待机功耗无明显差异
    • 常见使用场景中能够正常进入待机,待机电流在正常范围内
    • 长时间连续使用应用无异常耗电现象

    电量监控:和竞品做对比测试,同一机型的测试机在不同时间,不同网络条件,不同功能使用的情况下分别测试电量使用情况。

    (5)启动速度

    第一类:首次启动 --应用首次启动所花费的时间;
    第二类:非首次启动 --应用非首次启动所花费的时间;
    第三类:应用界面切换–应用界面内切换所花费的时间。

    (6)滑动速度、界面切换速度
    (7)与服务器交互的网络速度

    编写测试代码(Android Instrumentation),打桩到源码中,运行后通过log数据进行分析。

    预期标准指定原则:

    1. 分析竞争对手的产品,所有指标要强于竞品

    2. 产品经理给出的预期性能指标数据

    3. 符合业内行业标准

    站在管理员的角度考虑需要关注的性能点

    (1)、 响应时间

    (2)、 服务器资源使用情况是否合理

    (3)、 应用服务器和数据库资源使用是否合理

    (4)、 系统能否实现扩展

    (5)、 系统最多支持多少用户访问、系统最大业务处理量是多少

    (6)、 系统性能可能存在的瓶颈在哪里

    (7)、 更换那些设备可以提高性能

    (8)、 系统能否支持7×24小时的业务访问

    站在测试工程师角度考虑

    (1)、连接超时

           这个是App关闭的首要问题,而在移动应用中网络错误数据比例报错中最高的就是连接超时错误。

    (2)、崩溃

           APP的崩溃,就是用户的崩溃。当用户使用你的App出现闪退或崩溃时,他们很有可能跑去App Store赠送你一个“一星”差评。

    (3)、系统交互(电话短信干扰,低电量提醒,push提醒,usb数据线插拔提醒,充电提醒等)

           在APP使用过程中,可能会遇到各种中断场景,那么一旦发生这些场景,APP就卡死或者闪退,想必也没有多少用户愿意持续使用你的APP。

    (4)、弱网下的运行情况

          电梯里、地铁上,网络信号差时,APP页面的菊花转不停,界面卡死,同时错误提示一堆,这样的情况怎能不让用户抓狂。

    (5) 、CPU使用问题

            CPU频率设置过高时会导致过热,过热导致耗电更严重, CPU频率设置过低导致手机滞后,应用处理缓慢同样会导致耗电。更多时候,用户解决CPU超载问题只能关闭甚至卸载App,App就被Kill了!

    4.2测试工具

    功能测试自动化

    a) 轻量接口自动化测试:jmeter

    b) APP UI 层面的自动化

    android:UI Automator Viewer,Android Junit,Instrumentation,UIAutomator

    iOS:基于 Instrument 的 iOS UI 自动化,

    性能测试

    a) Web 前端性能测试

    网络抓包工具:Wireshark
    网页文件大小
    webpagetest
    pagespeed insight
    chrome adb

    b) APP 端性能测试

    Android 内存占用分析:MAT
    iOS 内存问题分析:ARC 模式
    Android WebView 性能分析:
    iOS WebView 性能分析

    c) 后台服务性能测试负载,压力,耐久性可拓展性,基准

    工具:apacheAB,Jmeter,LoadRunner,

    专项测试

    a) 兼容性测试

    手工测试:操作系统,分辨率,rom,网络类型
    云平台:testin,脚本编写,Android。

    b) 流量测试

    Android 自带的流量管理,
    iOS 自带的 Network
    tcpdump 抓包
    WiFi 代理抓包:Fiddler
    流量节省方法:压缩数据,json 优于 xml;WebP 优于传统的 JPG,PNG;控制访问的频次; 只获取必要的数据;缓存;

    c) 电量测试

    基于测试设备的方法,购买电量表进行测试。
    GSam Battery Monitoe Pro
    iOS 基于 Instrument Energy 工具

    d) 弱网络测试

    手机自带的网络状况模拟工具
    基于代理的弱网络的模拟:
    工具:windows:Network Delay Simulator
               Mac:Network Link Conditioner

    web测试和app测试对比:

      系统架构方面 性能方面 兼容方面
    web测试

    1.一般都是 b/s 架构,基于浏览器的

    2.只要更新了服务器端,客户端就会同步会更新

    web 页面主要会关注响应时间和资源性能(CPU,I/O,内存,信道,传输速度)

    1.web 是基于浏览器的,所以更倾向于浏览器和电脑硬件,电脑系统的方向的兼容

    2.web测试是基于浏览器的所以不必考虑安装卸载

    app测试

    1.一般是 c/s 的,必须要有客户端,用户需要安装客户端

    2.需要客户端和服务器都更新

    app 则还需要关心流量、电量、CPU、GPU、Memory 这些。 它们服务端的性能没区别,都是一台服务器。

    1.app测试则要看屏幕尺寸,系统兼容、机型兼容、屏幕分辨率兼容、网络兼容、其它(如设备、存储、第三方应用等兼容)

    2.app是客户端的,则必须测试安装、更新、卸载。除了常规的安装、更新、卸载还要考虑到异常场景。包括安装时的中断、弱网、安装后删除安装文件

    3. APP还有一些专项测试:如网络、适配性

     

    4.3  Android测试 与 iOS测试

    Android手机如何截取崩溃log

    1、下载ADB工具包

    2、测试手机连接到电脑端(手机助手根据手机型号选择)

    3、打开测试手机中的开发者模式

    4、打开DOS窗口

    5、进入到 adb所在目录

    6、输入命令:adb logcat -v time > D:\\logcat.log(>后代表日志存放目录)

    7、执行命令后开始操作应用

    8、Ctrl在+C结束命令

    9、进入日志存放目录中查看

    IOS应用闪退时如何截取Log

    1. 安装iTools

    2. 测试手机连接到电脑端

    3. 在iTools界面,点击进入崩溃日志模块

    4. 导出崩溃日志

    需要注意的是,Android端的Log可以通过设置Time来找到截取的对应日志内容,但IOS中日志信息较多的情况下,可以在崩溃日志模块中点击修改时间字段并记录好Crash的时间,二者结合很容易找出Crash的日志片断。

    展开全文
  • 写测试用例 首先我们先直接编一个测试用例,这个时候,yapi的优势就出来了,我们直接把研发的接口生成我们的测试集合就好,不用我们在一次接口信息,方便~~~ 对执行环境,请求header,请求参数,进行设置,运行 ...
  • 目录 请你分别介绍一下单元测试、集成测试...请你说一下如何写测试用例 请问你觉得测试项目具体工作是什么? 请问如果想进行bug的测评,怎么去评测bug? 请你说一说测试用例的边界 请你说一下软件质量的六个特..
  • 1、最佳测试方案:(写代码之前,先思考怎么写) 1、在Excel/数据库中准备好测试数据(把测试用例写到EXCEL里面去) 2、用代码读取测试数据(编写一个excel读取和存储测试数据的类,从EXCEL中获取必要的测试数据)...
  • 做自动化测试的同学,最后总会把自己的自动化测试用例接入到Jenkins中,实现持续化集成的工作,达到无人职守的去运行自动化测试用例。通常我们都是使用公司提供的Jenkins平台来接入代码的,可是如果我们自己想搭建...
  • IDEA 集成Junit插件

    2009-12-09 21:04:06
    由于最近要开发新项目来,用开发工具是IDEA,但不知道,怎么集成junit做测试,再网上好久,也没找到!就直接导入jar包,直接写测试用例了,感觉还是麻烦!后来找到来方法,记录一下,跟大家分享一下:    ...
  • 做自动化测试不是把框架和测试用例实现了就没有然后了。完的目的是运行到项目上去,这个项目上,怎么来运用啊?我做这个的目的就是回归和冒烟。假设现在要做回归,回归根据开发转测试版本的...
  • 接口自动化框架搭建(六)--jenkins集成 ...怎么好的接口自动化脚本放到jenkins集成? 目的明确:接口自动化脚本其实只要运行那个运行所有测试用例的python文件,所以我们在jenkins上只要做...
  • 2021-03-22

    2021-03-22 17:46:03
    今天的测试用例题目的不怎么好 回去研究 言归正传 测试分为单元测试 集成测试 系统测试 验收测试 其中有关于测试人员的主要是集成测试和系统测试 单元测试更多是程序员自己测试 验收主要是客户自己弄 单元测试又称...
  • 2 登录界面写测试用例 3 用python做过什么,详细介绍,花了多长时间 4 list和tuple的区别,工作中什么时候用list,什么时候用tuple 5 get和post的区别 6 log in用get还是post 7 python垃圾回收机制 8 持续集成 二面 ...
  • 软件测试经典面试题 (超实用)

    热门讨论 2012-02-16 13:48:08
    33、集成测试也叫组装测试或者联合测试,请简述集成测试的主要内容? 10 34、简述集成测试与系统测试关系? 10 35、软件测试的文档测试应当贯穿于软件生命周期的全过程,其中用户文档是文档测试的重点。那么软件系统...
  • 5.(这题出的有问题哦,详细的5步骤为~~)通过画因果图来写测试用例的步骤为: (1)分析软件规格说明描述中,哪些是原因(即输入条件或输入条件的等价类),哪些是结果(即输出条件),并给每个原因和结果赋予一个...
  • 4. 编写测试用例方法有哪些:因果图,场景法、等价类划分法、边界值分析法、错误推测法、判定表驱动法、正交实验法、功能图法、大纲法 5. 测试的六条基本法则是什么:一功(功能)二可(可靠性)三效(效率)四易...
  • 接口自动化用例完了,那么怎么集成到Jenkins上面呢? 下面我来说明一下: 以Jenkins部署在mac为例 1:首先将你的接口自动化用例和环境配置导出来。 将导出来的这两个json文件,放在mac的某个目录下 2:在...
  • 但对于迭代较快的业务逻辑以及生存时间不长的活动页面之类的就别花时间写测试用例了,维护测试用例的时间大了去了,成本太高。 <h2>Node.js模块的测试 对于Node.js的模块,测试算是比较方便的&#...
  • 今天开博了……

    2009-12-24 12:03:24
    申了好久的号,今天才开... 今天开始写测试用例了,尴尬的是我居然搞不清楚这个应该算做什么测试用例,是单元的还是集成的,还是系统的?不过无所谓了,好像上级也不怎么在意对于测试用例的区分,甚至于测试用例的格...
  • 在GitHub上协作开发,写测试用例那是必须的,至于执行测试用例, GitHub 的 MarketPlace 上有很多工具可以配合使用;使用 Travis 等工具我们可以很轻松的实现CI/CD(持续集成、持续部署);我们的问题是该怎么做呢? ...
  • 工作随想

    千次阅读 2006-05-17 23:27:00
    今天开始项目的集成测试用例,我发现公司研发在测试方面是一团糟,都知道集成测试要来测接口,但没有一个人知道怎么测,大多人是把系统测试那一套拿来充事,光测个前后台接口,还要把不相干的模块起起来,鼠标...
  • TDD是什么TDD就是测试驱动开发,以测试用例为主导,去开发项目,业务代码该怎么写还是怎么写,在实现UI之前,可以先实现Test用例,通过test来实现对业务场景的模拟,最终让你的代码更稳定。大叔认为tdd的作用代码更...
  • Mock 七宗罪

    2017-04-10 12:15:37
    没有 Mock 的话怎么保障测试用例专注于单个方法的功能验证? 消除单元情结,消除之后单元测试和集成测试的分界线是什么呢? 数据库相关的层如何测试? 如何应用内存数据库达到测试实际数据库的目的? 如果确实出现 ...
  • 相比Swagger要一堆注解,Spring RestDocs需要写测试用例,才能生成API文档。JApiDocs 具有无痛集成的特点,你只需花几分钟就能知道它怎么用了。 快速开始 maven <dependency> <groupId>io....
  • 相比Swagger要一堆注解,Spring RestDocs需要写测试用例,才能生成API文档。Eolinker 具有无痛集成的特点,你只需花几分钟就能知道它怎么用了。 快速开始 产品支持几种创建API文档的方式: 1.手动创建文

空空如也

空空如也

1 2 3
收藏数 43
精华内容 17
关键字:

集成测试用例怎么写