第三部分 敏捷测试象限
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. 测试管理：也要有版本控制。
五、评价产品的面向业务测试
评价产品：尽量重现最终用户的实际体验。对于迭代中的变化，抓住一切机会展示，不要等到迭代后。
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工具。
模拟器、仿真器：模拟未完成、复杂关联系统。仿真手机等昂贵设备（可下载的仿真器）。
六、利用面向技术的测试评价产品
性能相关：包括配置、兼容、ility(如交互性、可靠性、安全性、扩展性等)、内存、恢复、数据转换。（最好有核对表。）
1. 谁来做？
安全性：寻求安全组。 数据转换：数据库组。 恢复测试、故障转移：产品支持小组。
2. 何时做
编写性能测试Story。
一早设计性能测试。
建立性能测试基线。
安全性：
静态代码分析：找出潜在漏洞。（firebug）
动态分析：SQL注入或跨站点攻击。（fuzzing）
可维护性：
成功是0，失败必须是负数。
每个类或模块职责单一。
所有函数必须是单入口单出口？？？
页面上的两个域不能同名。
兼容性：
OS、浏览器。包括不同版本和类型。
可靠性：
首次失败时间、平均失败时间。
可伸缩性：
系统能否处理不断增长的用户需求。网络、数据库瓶颈？
可安装性、交互性。研究并提出测试策略以评估质量级别。
性能测试务必定义期望值。
性能测试工具：
施压工具：如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秒时的用户数。