PART2 敏捷测试象限

一、四象限

面向业务、面向技术和支持团队、评价产品。

支持团队面向技术的测试(自动化):单测、组件测试。

       支持团队面向业务的测试(自动+手工):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工具。

模拟器、仿真器:模拟未完成、复杂关联系统。仿真手机等昂贵设备(可下载的仿真器)。


六、利用面向技术的测试评价产品

性能相关:包括配置、兼容、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秒时的用户数。

你可能感兴趣的:(___,敏捷测试)