软件测试基础

目录

1. 测试用例:

2. 用例设计

3. 单元测试

4. 自动化测试

1. 测试用例:

• 功能测试场景,
• 显式功能性需求用例,
• 非功能性需求(隐式功能性需求)如安全,性能,兼容性等

“好的”测试用例:

• 整体完备性,
• 等价类划分的准确性,
• 等价类集合的完备性(边界值及条件正确识别完全)

2. 用例设计

用例设计1:

• 找全有效等价类,无效等价类, 对应的边界(条件)值, 错误推断法(经验及需求理解);
• 建立缺陷知识库(checklist)帮助补充和优化用例设计;
• 边界值分析法对等价类划分法补充,经常结合使用

用例设计2:

• (深入理解尽早介入)业务需求——软件功能需求点——测试需求点——测试用例

用例设计3:

• 必须要深入理解被测软件的架构设计(如数据库连接方式,读写分离,消息中间件配置,缓存系统层级分布,第三方系统的集成等),
• 设计与实现细节,深入理解软件内部的处理逻辑,但仍根据原始需求设计测试用例;
• 需引入需求覆盖率和代码覆盖率来衡量测试执行的完备性,找出漏测点

3. 单元测试

1. 单元测试对函数或类(最小可测试单元)的测试,都以自动化方式执行,回归场景下可提升效率

2. 代码逻辑正确:

• 代码分类正确(哪几种正常输入),
• 无遗漏(是否需要特殊处理的多种边界输入),
• 每个代码分类的处理逻辑必须正确(各种非法输入可能性多大,如何处理)

3. 底层或核心模块采用单元测试

4. 单元测试框架类型与开发语言直接相关

5. 单元测试框架、桩代码/Mock代码的选型由开发和测试架构师共同完成

6. 引入计算代码覆盖率工具,如JaCoCo, JS的Istanbul

7.对单元测试的执行,代码覆盖率的统计和持续集成的流水线集成,以“单元测试通过率”和“代码覆盖率”为标准决定提交的代码是否被接受

8. 真正项目中全面的单元测试还有些困难

4. 自动化测试

1. 大量时间开发代码去测试代码,维护成本随被测对象改变而升高

2. 优点:

• 省时;
• 提升回归效率;
• 更好利用无人值守时间频繁测试;
• 高效实现手工无法完成的工作如7X24持续稳定性测试和高并发压测;
• 每次执行的一致性和可重复性

3.缺点:

• 不能取代手工,只频率高、机械化的重复步骤;
• 不智能仅预定义的步骤和测试结果;
• 开发工作量大(5次手工测试);
• 发现缺陷少仅回归范围的缺陷;
• 依赖自动化测试用例的设计和实现质量(是否稳定);
• 初期开发效率低且后期全面需要重构;
• 需要业务和技术专家结合;
• 必须编程能力

4. 场景:

• 需求稳定;
• 软件产品比软件项目更适合(周期长);
• 看具体情况定(20%精力覆盖80%回归);
• 在多平台上重复运行测试;
• 手工无法实现或成本较高;
• 被测软件的开发较为规范且系统可测性的场景(如登录开发提供绕过图片验证码的方法否则影响稳定性);
• 测试具备编程能力(不要精力偏移)

5. 单元测试自动化广义:

• 测试用例框架代码的自动生成(TestNG);
• 部分测试输入数据的自动生成(根据不同变量类型自动生成测试输入数据)、
• 桩代码的自动生成(函数A内部调用尚未实现的B,为测试A模拟B,为B生成可编程的桩代码;并实现抽桩,如集成测试不需要桩代码)
• 被测代码的自动静态分析(Sonar和Coverity代码的静态扫描)
• 测试覆盖率的自动统计与分析(如代码行或分支覆盖率,衡量测试充分性和完整性)
• 单元测试用例的自动执行(CI/CD流水线脚本自动触发单元测试)

6. 代码级集成测试

• 传统软件企业“单体”应用(现在不会),
• 关注软件模块间接口调用和数据传递,不允许使用桩代码

7. web service测试

主要指SOAP API和REST API两类API测试(工具SoapUI或Postman)

参考: https://blog.csdn.net/wumingxiaoyao/article/details/117899913

https://blog.csdn.net/sweetgirl520/article/details/78181055          

IBM Developer      

基于代码的API测试用例:

• 准备测试数据
• 准备调用参数并发起API调用
• 验证返回结果

API自动化测试框架REST Assured,发起Restful API调用并验证返回结果

参考: https://blog.csdn.net/qq_36792120/article/details/125089383

REST Assured

GitHub - rest-assured/rest-assured: Java DSL for easy testing of REST services

web service测试自动化

• 测试脚手架代码自动生成(组织测试用例方式,测试数据驱动的实现等)
• 部分测试输入数据的自动生成(API参数及API调用的有效负载,数据生成遵循边界值原则)
• 响应验证的自动化(自动比较两次相同API调用的返回结果,并识别出有差异的字段值,可通过规则配置去掉时间戳,会话ID等动态值)
• 基SoapUI或Postman的脚本自动生成(初步验证的测试用例(json文件)转换成主流代码级API测试框架下的测试用例代码,Postman已实现代码转换工具或开发一个工具)

8. GUI测试自动化技术

• WEB浏览器的GUI自动化测试: Selenium, UFT
• 移动端原生应用GUI自动化测试: Appium, 对iOS集成了XCUITest,对Android环境集成UIAutomator和Espresso

9.测试覆盖率

需求覆盖率统计方法比较重量级(传统瀑布模型下);

代码覆盖率指至少执行了一次的条目数占整个条目数的百分比

• 行覆盖率(语句覆盖率),要求最低,结合判定或条件覆盖率
• 函数覆盖率(方法覆盖率)
• 判定覆盖率(分支覆盖率),度量每个判断分支是否测试到了
• 条件覆盖率,每个条件的可能取值至少满足一次,每个条件的结果是否测试到了
• 条件/判断覆盖率(Condition/Decision Coverage),同时满足两个
• 修改条件/判断覆盖率(MC/DC),要求最高,与安全相关的应用中,每个条件都要可以独立影响判断结果的成立与否(如if(a or b) and c then ,a为true,b为true,c为true,则b改为false不影响结果,每个变量出现至少两次)

目前多在单元测试,集成测试统计代码覆盖率,找出潜在遗漏测试用例,针对性补充,识别出由于需求变更造成的不可用的废弃代码;

高的代码覆盖率不一定保证软件的质量(对还没代码实现的部分),低一定不能保证质量;

代码覆盖率报告(JaCoCo)包含每个java文件的行数,方法数,类数等信息,针对性用例设计;

代码覆盖率工具的实现技术

JaCoCo: 使用字节码即时注入,采用ASM技术(Java字节码操纵框架,能用来动态生成类或增强既有类的功能); 借助java代理,利用在main()方法之前执行的拦截器方法premain()来插入探针(probe),在JVM的启动参数中添加“-javaagent”,并指定用户实现字节码注入的代理程序

Cobertura: 使用字节码离线注入,在测试开始之前先对文件进行插桩,并提前生成插过桩的Class文件;在测试前就通过ASM将探针插入Class文件,运行中不需要额外处理

参考 测试工程师 全栈技术进阶与实践