敏捷测试的四象限---学习笔记
1）强调：整体 团队运作方式
迭代 而非小型瀑布（持续集成、增量）
持续反馈（自动化、迭代、TDD/ATDD、测试去掉数据库）
沟通（尤其是面对面的沟通）
重构（持续改进，保持简单，消除技术债务）
自动化（没有自动化回归，持续、快速迭代不可能）
做正确的事情 而非正确地做事情
2）限制：
必需要有良好的基础平台
小规模、高素质的团队
适合应用类（故事分解容易）同质型特性的应用业务系统开发
3）其他：
敏捷没有完整的解决方案。强调最佳实践，举例基本都属小而精的例子，主要体现在理念。
更重要的是靠“自组织”的使用者自己去摸索。
朱少民的有句话还是对的，敏捷下的测试团队有更多接近开发团队的特质。
一、四象限
面向业务、面向技术和支持团队、评价产品。
支持团队面向技术的测试（自动化）：单测、组件测试。
支持团队面向业务的测试（自动+手工）：story测试、功能测试、实例、原型、仿真??
评价产品面向业务的测试（手工）：探索式、场景、可用性、UAT、beta/alpha
评价产品面向技术的测试（工具）：性能压力、安全、非功能性测试
支持团队的测试：帮助用户开发产品。
象限一：TDD/TD测试。使用和应用相同的编码。一般内部质量由程序员定义、参与测试。CI环境。
象限二：测试每个story的细节，自动化测试运行于业务逻辑层。自动化持续集成、构建、测试过程。快速测
试，反馈BUG。功能环境
支持产品的测试：确认产品满足需求，改进产品。测试
象限三：评价产品满足客户需求、竞争力，改进产品。仿真最终用户测试。
象限四：性能安全开发的每一步都应考虑，不要留到最后。
知道一个story何时完成：通过卡片养成习惯。
二、支持团队面向技术的测试
目的：快速发现问题，尽量开发之前或当时。（测试先于开发，驱动设计，设计遵循测试）
测试原因：
1. 持续构建使重构时有稳定保障。
2. 降低单元级错误，更多时间用于复杂场景测试。
快速测试反馈原则：
1. 代码结构：a. 横向MVC，纵向功能域划分 2. 组件+适配器端口模式
2. 单测10分钟内执行完：a. 持续构建有一Job。b.慢的测试一个Job。
3. 使用仿制对象，而不直接从数据库取数据。并行运行测试。
测试何时停止：面向技术只测单维度。 面向产品测复杂场景。
如果团队不做测试
1. 增量功能采用新架构。
2. 卡片标记改进任务。
3. “寻求帮助”模式：找最赞同自己的开发实践，或找最资深的开发实践。
4. 管理人员：向业务解释解释优先会让他们获得商业价值。为团队提供培训、工具、技术支持。
5. 将问题引入到团队中：建议TDD，但允许开发人员提出自己的解决方式。
相关工具：IDE，构建MAVEN，持续构建Jenkins，单测XUnit。仿制对象或测试桩MOCK。
三、支持团队面向业务的测试
需求和想法都存在story卡片、测试中。团队基于story沟通。
需求=Story（客户团队）+测试实例（测试团队）+沟通（开发同事参与编写会）
第二象限测试：在编码开始前写完测试。外部质量。测试内容包含：前后置条件、对其它功能的影响、与关
联系统的集成。
快速测试：寻求帮助，让开发和业务都懂的语言，让他们帮忙写测试案例。如Fit，Fitness（功能测试工
具）。图表、流程图、Excel、原型等。
激发需求提问：a. 这个story解决了什么问题?现在方案不能解决吗？业务价值是什么？b.最终用户是谁，
用户能得到什么价值？ c.如何判断已完成？
d.最坏结果（风险）是什么？最好结果（基本路径测试）是什么？
多重观点：
考虑非功能性需求：系统需要运行多久？宕机怎么办？如果用中间件，有没有大数据消息丢失问题？固定
长度？传输中断会怎么样？会通知谁？
需求梳理：UI书面原型，Oz测试向导。（如截图或手工绘制，现场扮演计算机：客户提问输入，测试回答
输出，开发人员观察记录等）
附、面向业务的测试工具包
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. 测试管理：也要有版本控制。
四、评价产品的面向业务测试（平时经常说的功能测试）
评价产品：尽量重现最终用户的实际体验。对于迭代中的变化，抓住一切机会展示，不要等到迭代后。
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工具。
模拟器、仿真器：模拟未完成、复杂关联系统。仿真手机等昂贵设备（可下载的仿真器）。
五、利用面向技术的测试评价产品（平时经常说的性能测试及安全测试等专项测试）
0）概述：范围及其他
性能相关：包括配置、兼容、ility(如交互性、可靠性、安全性、扩展性等)、内存、恢复、数据转换。（最好
有核对表。）
1. 谁来做？
安全性：寻求安全组。 数据转换：数据库组。恢复测试、故障转移：产品支持小组。
2. 何时做
编写性能测试Story。
一早设计性能测试。
建立性能测试基线。
1）安全性：
静态代码分析：找出潜在漏洞。（firebug）
动态分析：SQL注入或跨站点攻击。（fuzzing）
2）可维护性：
成功是0，失败必须是负数。
每个类或模块职责单一。
所有函数必须是单入口单出口？？？
页面上的两个域不能同名。
3）兼容性：
OS、浏览器。包括不同版本和类型。
可靠性：
首次失败时间、平均失败时间。
4）可伸缩性：
系统能否处理不断增长的用户需求。网络、数据库瓶颈？
可安装性、交互性。研究并提出测试策略以评估质量级别。
5）性能测试：
性能测试务必定义期望值。
性能测试工具：
施压工具：如JunitPerf，httpPerf，jmeter
瓶颈分析：JProfiler，查看瓶颈、内存泄露。
JConsole：分析DB的使用。
PerMon：监控CPU、内存、交换、磁盘IO、硬件资源。
网络：NetScout。
性能基准：
TPS、事务最大处理时间、繁忙连接最大值、最大处理时间和用户数对比图、达到最大处理时间8秒时的用户数。
六、小结
敏捷宣言四大核心价值观，敏捷软件测试实际也是这个意思：
个体和交互胜过流程和工具；
可用的软件胜过完备的文档；·
客户协作胜过合同协商；
响应变化胜过遵循计划。
充分沟通，持续反馈，团结协作，积极应对。
安全性：
静态代码分析：找出潜在漏洞。（firebug）
动态分析：SQL注入或跨站点攻击。（fuzzing）
可维护性：
成功是0，失败必须是负数。
每个类或模块职责单一。
所有函数必须是单入口单出口？？？
页面上的两个域不能同名。
兼容性：
OS、浏览器。包括不同版本和类型。
可靠性：
首次失败时间、平均失败时间。
可伸缩性：
系统能否处理不断增长的用户需求。网络、数据库瓶颈？
可安装性、交互性。研究并提出测试策略以评估质量级别。
性能测试务必定义期望值。
性能测试工具：
施压工具：如JunitPerf，httpPerf，jmeter
瓶颈分析：JProfiler，查看瓶颈、内存泄露。
JConsole：分析DB的使用。
PerMon：监控CPU、内存、交换、磁盘IO、硬件资源。
网络：NetScout。
性能基准：
TPS、事务最大处理时间、繁忙连接最大值、最大处理时间和用户数对比图、达到最大处理时间8秒时的用户数。
:handshake赞一个，写的不错，了解了
页:
[1]
