敏捷测试的四象限---学习笔记

转载自:https://blog.csdn.net/hgstclyh/article/details/71125017

根据《敏捷软件测试》的学习笔记整理,部分文字复制自网络。

作者:(美国)克里斯平(Lisa Crispin) (美国)格雷戈里(Janet Gregory) 译者:孙伟峰 崔康
出版社: 清华大学出版社    出版时间: 2010年10月1日   ISBN: 9787302236535

  零、个人阅读后对敏捷软件测试的一点感想

 1)强调:
     整体    团队运作方式
     迭代    而非小型瀑布(持续集成、增量)
     持续反馈(自动化、迭代、TDD/ATDD、测试去掉数据库) 
     沟通(尤其是面对面的沟通)
     重构(持续改进,保持简单,消除技术债务)
     自动化(没有自动化回归,持续、快速迭代不可能)
     做正确的事情      而非  正确地做事情


2)限制:       
必需要有良好的基础平台
小规模、高素质的团队
适合应用类(故事分解容易)同质型特性的应用业务系统开发

        3)其他:

          敏捷没有完整的解决方案。强调最佳实践,举例基本都属小而精的例子,主要体现在理念。

          更重要的是靠“自组织”的使用者自己去摸索。

          朱少民的有句话还是对的,敏捷下的测试团队有更多接近开发团队的特质。

一、四象限

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

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

       支持团队面向业务的测试(自动+手工):story测试、功能测试、实例、原型、仿真??

评价产品面向业务的测试(手工):探索式、场景、可用性、UAT、beta/alpha

评价产品面向技术的测试(工具):性能压力、安全、非功能性测试

支持团队的测试:帮助用户开发产品。

象限一:TDD/TD测试。使用和应用相同的编码。一般内部质量由程序员定义、参与测试。CI环境。

象限二:测试每个story的细节,自动化测试运行于业务逻辑层。自动化持续集成、构建、测试过程。快速测试,反馈BUG。功能环境

支持产品的测试:确认产品满足需求,改进产品。测试

象限三:评价产品满足客户需求、竞争力,改进产品。仿真最终用户测试。

象限四:性能安全开发的每一步都应考虑,不要留到最后。

知道一个story何时完成:通过卡片养成习惯。

敏捷测试的四象限---学习笔记_第1张图片

二、支持团队面向技术的测试

目的:快速发现问题,尽量开发之前或当时。(测试先于开发,驱动设计,设计遵循测试)

测试原因:

 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秒时的用户数。
--------------------- 
作者:Leo笑 
来源:CSDN 
原文:https://blog.csdn.net/hgstclyh/article/details/71125017 
版权声明:本文为博主原创文章,转载请附上博文链接!

你可能感兴趣的:(测试技术)