第三部分 敏捷测试象限
6. 测试的目的
敏捷测试的象限
支持团队的测试:帮助开发开发产品
象限一:TDD/TD测试。使用和应用相同的编码。一般内部质量由程序员定义、参与测试。CI环境。
象限二:测试每个产品的细节,自动化测试运行于业务逻辑层。自动化持续集成、构建、测试过程。快速测试,反馈BUG。功能环境
支持产品的测试:确认产品满足需求,改进产品。测试
象限三:评价产品满足客户需求、竞争力,改进产品。仿真最终用户测试。
象限四:性能安全开发的每一步都应考虑,不要留到最后。
知道一个产品何时完成:通过卡片养成习惯。
管理技术债务:快速迭代产品伴随而来的是代码库越来越难维护,问题越来越多;
运行单元测试的自动化和集成是最小化技术债务的必需品;
上下文环境的测试:上下文环境指导测试工作;
7. 支持团队面向技术的测试
第一象限的测试
敏捷测试的基础:TDD、支持基础设施(保证代码质量,更多时间用于复杂场景测试)
为什么:效率更高、让测试人员的工作更容易、设计时谨记测试(层次架构和可测性)、及时反馈;
面向技术的测试何时停止: 面向技术只测单维度。 面向产品测复杂场景。
如果团队不做测试:带领大家进行敏捷开发;“寻求帮助”模式;
相关工具:IDE,构建MAVEN,持续构建Jenkins,单测XUnit。仿制对象或测试桩MOCK。
8. 支持面向业务的测试
第二象限测试:在编码开始前写完测试。外部质量。测试内容包含:前后置条件、对其它功能的影响、与关联系统的集成。
通过面向业务测试驱动开发: 需求和想法都存在PRD、测试中。团队基于产品沟通。
需求困境:需求=Story(客户团队)+测试实例(测试团队)+沟通(开发同事参与编写会)
共同语言、激发需求、使用正确方式提问、使用示例、多重观点、与客户交流、增进清晰度、满足条件、涟漪效应;
小增量
如何知道我们完成了:考虑和降低风险,可测性和自动化;
9. 面向业务的测试工具包
1. 激发示例和story:作为一名{角色},我需要{功能},才能{业务价值}。
描述预期行为:核对表(模板:如报表、关联系统、DB)、思维导图、电子表单(金融域:复杂运算用例)、模型图、流程图、
模型:尽量模拟用户真实数据
功能修改模型:打印原功能->勾画改动点->扫描上传
wiki:促进讨论,记录沟通、决策
2. 沟通工具:电话、 视频、Webex、在线白板、邮件、桌面VNC
3. 自动化工具
单测BDD工具:easyb和jbehave
API功能测试:Fitness
Web服务测试:soapUI
GUI测试工具:录制回话Watair,selenium,
4. 编写测试的策略
构建高层次测试--->详细测试
1. 增量构建:先写一个简单的,基本流测试。每个测试只针对一种业务规则或条件。
2. 确保构建、测试通过。(一个测试通过后面的测试通过的可能性更大)
3. 合适的测试设计模式
4. 基于时间、活动和事件模式????
5. 关键词和数据驱动
5. 可测试性:如果有不可测的模块,向开发寻求帮助
6. 测试管理:也要有版本控制。
10. 评价产品的面向业务测试
评价产品:尽量重现最终用户的实际体验。对于迭代中的变化,抓住一切机会展示,不要等到迭代后。
1. 场景测试:
真实生活中的领域知识非常关键。
肥皂剧测试:真实的数据和流程,有乐趣。(也可找客户提供Data)
定义场景、工作流工具:数据流,工作流图。
2. 探索式测试:
有时,动手做的意义远大于思考。
1. 可能的错误
2. 模拟软件运行方式
3. 测试时了解到的内容:考虑客户需求、团队常见错误、产品好坏评价。
3. 可用性测试
1. 用户需求和角色:角色类型划分,衍生不同的场景。(用户量少不用做可用性测试。)
2. 导航测试:链接、Tab
3. 研究竞争对手软件:花时间去使用、研究对手软件。
4. GUI背后
1. API测试:
检查输入参数个数、边界、可选。打乱接口调用顺序。输出结果边界。有返回值时校验,void时查看日志、DB、关联系统。(理解所有参数、方法。)
2. Web服务测试:强调接口有效性。了解客户期望质量,探索式测试。
5. 文档测试
1. 用户文档:连接、文字清晰、一致、简明、弹窗多个、阻止弹窗。
2. 测试报告:要获取正确的数据。
6. 探索式测试辅助工具
测试设置:有时可能会花一天去重现错误,基于会话的测试使用自动化设置好测试数据、场景(只要修改参数即可)。工具Watir、Selenium IDE
生成测试数据:perlclip用不同类型的输入数据测试文本框。如需要输入200个字符。
监控:日志、错误。linux的tail -f工具。
模拟器、仿真器:模拟未完成、复杂关联系统。仿真手机等昂贵设备(可下载的仿真器)。
11. 利用面向技术的测试评价产品
性能相关:包括配置、兼容、ility(如交互性、可靠性、安全性、扩展性等)、内存、恢复、数据转换。(最好有核对表。)
1. 谁来做?
安全性:寻求安全组。 数据转换:数据库组。 恢复测试、故障转移:产品支持小组。
2. 何时做
编写性能测试Story。
一早设计性能测试。
建立性能测试基线。
安全性:
静态代码分析:找出潜在漏洞。(firebug)
动态分析:SQL注入或跨站点攻击。(fuzzing)
可维护性:
成功是0,失败必须是负数。
每个类或模块职责单一。
所有函数必须是单入口单出口???
页面上的两个域不能同名。
兼容性:
OS、浏览器。包括不同版本和类型。
可靠性:
首次失败时间、平均失败时间。
可伸缩性:
系统能否处理不断增长的用户需求。网络、数据库瓶颈?
可安装性、交互性。研究并提出测试策略以评估质量级别。
性能测试务必定义期望值。
性能测试工具:
施压工具:如JunitPerf,httpPerf,jmeter
瓶颈分析:JProfiler,查看瓶颈、内存泄露。
JConsole:分析DB的使用。
PerMon:监控CPU、内存、交换、磁盘IO、硬件资源。
网络:NetScout。
性能基准:
TPS、事务最大处理时间、繁忙连接最大值、最大处理时间和用户数对比图、达到最大处理时间8秒时的用户数。
12. 测试象限总结
安全性:
静态代码分析:找出潜在漏洞。(firebug)
动态分析:SQL注入或跨站点攻击。(fuzzing)
可维护性:
成功是0,失败必须是负数。
每个类或模块职责单一。
所有函数必须是单入口单出口???
页面上的两个域不能同名。
兼容性:
OS、浏览器。包括不同版本和类型。
可靠性:
首次失败时间、平均失败时间。
可伸缩性:
系统能否处理不断增长的用户需求。网络、数据库瓶颈?
可安装性、交互性。研究并提出测试策略以评估质量级别。
性能测试务必定义期望值。
性能测试工具:
施压工具:如JunitPerf,httpPerf,jmeter
瓶颈分析:JProfiler,查看瓶颈、内存泄露。
JConsole:分析DB的使用。
PerMon:监控CPU、内存、交换、磁盘IO、硬件资源。
网络:NetScout。
性能基准:
TPS、事务最大处理时间、繁忙连接最大值、最大处理时间和用户数对比图、达到最大处理时间8秒时的用户数。