常见的SQA的架构 我们持续演化,对于将软件 QA 浓缩到所有开发任务完成后的测试阶段的方法,它们的问题在于:会给团队带来巨大成本并将整个项目置于高风险之中。在测试阶段,开发人员竭尽全力确保他们的代码具有极少的缺陷。然后测试人员努力揭示软件中每个可能的缺陷,而经理和客户希望他们拥有适合向市场发布的软件。 仓促的开发可能会为团队节省片刻的时间,但是,如果有一些重大开发问题没有从一开始就考虑到,最终可能导致需要投入更多的时间。结果是浪费了大量团队资源来修复和重新设计代码,而不是将这些资源投入到更有用的事情上。软件团队人员内心里对整个始末一目了然,但面对着唠叨的客户、严格的销售团队,以及一些自我感觉编写了无缺陷的软件的开发人员,软件团队确实很难将 QA 撇在一边而只顾着完成代码。 有几种实践方法,包括需求审核、代码审核和演练、基于会议的测试、基于风险的测试等. 在开始每个新开发阶段之前审核软件需求,这样做能够最大限度地减少缺陷并满足客户的需求。在实现之前审核需求,这样做有助于考虑潜在的变化,克服在项目的整个寿命中可能发生的误解。团队必须与客户一起反复检查所有应实现的业务领域细节。需求审核也可以使用原型和领域模型来完成。当开发团队在开始实际实现之前完成这个小任务时,他们的项目或开发迭代会获得良好的开局。通过确保在实现之前所有利益相关者都达成共识,并且每位团队成员都意见一致,客户和管理人员可确信开发人员将在开发周期结束时交付正确的成果。 而“代码审核和演练”听起来像很简单,但代码审核是软件开发中最有效的实践之一。它对减少缺陷数量以及增强代码和软件设计的质量具有直接影响。这消除了在未来的版本中执行重大的代码重构和清理的需求。
第三个实践是“基于会议的测试”,表示将测试负载分解为会议,每个会议有一个任务(一种希望从测试会议获得的明确规定的结果)。每个会议有一个既定的时间范围(从 20 到 40 分钟),测试人员在执行测试会议期间不应中断。
另一种则是“基于风险的测试”,因为在开发流程中进行了一些更改,开发团队通常拥有同一个软件的许多常用版本。一种重要的 QA 实践是在每个主要版本之后彻底测试软件。另一方面,在每个版本中都对整个软件运行全面的回归测试既耗时又很难实现。但是,仅测试更改的功能或笨拙地删减测试案例套件是不安全的。一段代码可能解决了一个缺陷,但也可能破坏了代码中的其他内容。
我们期望是
保证质量,预防胜于检查:
衡量软件质量的常用指标软件开发实践过程中常用的几个衡量软件质量的指标,包括源代码行数、代码段/模块/时间段内的平均Bug数、代码覆盖率、设计/开发约束等 源代码行数(SLOC) 计算源代码行数也许是最简单的办法。它主要体现了软件的规模,并为项目的发展和规划提供了有用的信息。比如,如果我们每月计算一次源代码行数,那么就可以绘制一个项目成长图。当然,这种方式并太不可靠,原因是重构和设计阶段等因素会对此产生影响,但是至少可以为项目描绘一个趋势。首先,使用代码行数之和无法有效评估一个项目的实际进度,因为它更注重行为而不是结果。最终产品在多大程度上依赖于代码的性能和质量,这也是代码行数无法说明的。因此,聚焦于此实际上是非常有限的工作效率测量方式。SLOC无法表明要解决的问题的复杂性,也不能以可维护性、灵活性、扩展性等等因素来说明最终产品的质量。说到质量,它反而可能起到负面作用。通过重构、使用设计模式会减少代码行数,同时提升代码质量。代码量大,可能意味着有更多不必要的代码、更高不必要的复杂性、更加僵化难懂。 代码段/模块/时间段内的Bug数 缺陷跟踪对于更好的测试和维护是必不可少的。通过缺陷跟踪,我们可以利用报告工具(如Mantis)计算出每个代码段、模块或者特定时间段内的bug数量。凭借这些数据,我们可以尽早的查出和解决缺陷起因。Bug数量可能会作为衡量开发人员效率的指标之一,但是必须非常谨慎。如果把这项指标看得太重,那么开发人员和测试人员可能会成为敌人。在一个高效率的公司,所有的员工必须团结协作。为了更好地实现评估,bug可以被分为低、中、高等,因为这些缺陷的重要性和解决成本不是相同的。 代码覆盖率 代码覆盖率反映了程序当中源代码被测试的程度。有许多自动化工具可以完成该功能,比如Cobertura。代码覆盖率不能完全代表单元测试的整体质量,但是可以反映出测试覆盖率的问题。它可以和其他测试指标一起作为软件质量的指标。同时,单元测试代码、集成测试场景和结果应该经常地被审查。 有效的代码度量模型应具备以下特征:
设计/开发约束 在软件开发过程中,存在许多设计约束和准则,其中包括:
研发流程整个研发做到了类似于火车发车的发布过程:
所有的项目生命周期都有相应的平台工具支持,如下图: 质量保证手段有了高效稳定的流程,剩下的事情就是如何保证产品在快节奏的持续交付下的保持很高的质量。质量保障上面手机淘宝研发团队做了几方面事情: 1. 流程方面 1)创建了提测单、集成单、发布单等流程。建立了标准,并依托平台自动检查,提高了交付的质量。 2)建立持续集成体系,不但能提早发现更多的问题,而且提升了测试人员拿到的包的质量。 3)建立线上线下监控分析体系。 2. 包稳定性方面: 1)bundle阶段根据项目进度自己控制提测包的频率,集成阶段每日验证DailyBuild即可,所以解决了之前测试同学不断安装新版本的包的问题。 2)研发阶段的包内部支持环境切换,这实现了只构建一次,环境根据配置切换的梦想。测试时手机上只需要安装一次包即可完成多种环境下的测试。 3. 自动化测试与测试工具方面 1)引入多种静态扫描引擎,并定制多种规则:适配规则、Crash规则、框架约定规则、安全规则等,并且不断地将测试阶段、线上问题等总结抽象成新的扫描规则补充进入扫描引擎。 2)在测试阶段包种插入相应的测试SDK,并且这种SDK不会侵入应用代码,所以只需要在发布的时候去掉测试SDK即可。测试SDK可以在测试人员(包括外包适配测试人员)正常使用过程中自动检测并上报问题,这样就可以在同一的平台上看到研发过程中的质量情况并进行修复。 3)自动化平台方面也在根据测试经验不断的进化,在整个研发过程中自动化测试一直在执行,不仅可以提高产品稳定性,也可以发现性能、电量等非功能问题。 4)mock工具、验证平台等辅助测试工具也提升了测试人员的效率。 4. 线上线下监控分析 1)线下质量数据、线上业务问题、舆情反馈等信息统一汇集到平台上进行统一的分析告警,不仅能快速的发现问题,而且能通过数据分析能够帮助快速定位和解决问题。 2)根据平台中的数据,可以用经验推动流程的优化、补充测试用例、添加扫描规则、增加自动化场景、催生新的测试工具等,这样可以使经验形成闭环,使质量保障工作更加高效。 在敏捷开发过程下质量保证对于目前的开发架构来说,一个用户故事,涉及这四个点,可以从这四个点入手来进行质量保证。如何做呢?单元测试就开发人员处理了;代码审查,测试人员可以参与和监督,其实就是要保证:将开发任务与提交到Git的代码进行关联。这样一来,当测试人员检查开发任务的时候,就可以找到改变过的代码。我曾经试过从这些代码里面查看逻辑,找到分支场景,补充到测试用例里面。 Scrum中测试人员价值应当体现在:
敏捷中的QA日常活动从迭代到发布,敏捷测试的生命周期各个阶段QA的活动主要有:测试分析,测试自动化策略分析、框架构建等,故事测试,迭代计划会议和客户演示,测试自动化的维护和执行等。如下图示: QA通常不是仅仅工作在某个迭代,而是并行的同时工作在多个迭代:要对当前迭代的故事进行验收测试、探索性测试,和开发人员结对实现测试自动化;还要和业务人员结对分析下一个迭代的故事,编写验收标准和测试用例。 在单个迭代内部,伴随着故事生命周期,QA的活动有哪些呢?用户故事生命周期包括以下几个阶段:故事分析、故事计划、故事开发、故事验收、故事测试/探索性测试、系统测试和客户演示。QA参与故事的整个生命周期,在每个阶段都会发挥作用。
正如前面提到的,在每个阶段,QA除了要独立进行测试,通常还需要跟不同的角色结对,包括业务分析人员、开发人员、以及客户。
敏捷QA的这些日常活动,的确反映出敏捷QA的日常工作内容和方式都跟传统开发模式下的测试人员有很多不同。 敏捷QA与传统测试人员有何不同。我们分别从团队构成、测试阶段、工作方式、关注点、业务知识来源以及发布计划制定几个方面,来看看敏捷QA与传统测试人员有哪些不同:
从上表的对比可以看到,敏捷QA是特殊的,主要体现在:
这些特殊性对敏捷QA也提出了更高的要求,需要做到:
敏捷软件测试的七个关键成功要素包括使用团队整体参与的方法、采用敏捷测试思维、自动化回归测试、提供并获取反馈、构建核心实践的基础、与客户合作、保持大局观等。 1. 使用团队整体参与的方法 当整个开发团队负责测试和质量问题,你会拥有很多不同的技能集合和经验等级来处理测试可能发生的问题。测试自动化对于技能高超的开发人员来说不是大问题。当测试置于团队的优先权,任何人都参与测试任务,团队才会设计可测试的代码。使测试人员真正成为开发团队的一部分意味着向他们提供支持和训练他们适应敏捷开发的快节奏。他们需要时间掌握新技能以便与开发和客户团队紧密协作。 如果你管理一个敏捷团队,帮助团队使用团队整体参与的方法。记住质量,而不是速度,才是敏捷开发的目的。团队需要测试人员帮助客户理清需求,转化为指导开发的测试,提供发布优秀产品的唯一观点。确保测试人员能够把技能和长处转移到团队其他成员身上。确保他们不是局限于一种角色,如只做手动测试。确保当他们需要帮助时(可能需要极大的勇气),团队成员能够提供。反过来也是如此。测试人员应该随时准备帮助那些需要他们帮助的队友。 如果你是敏捷团队中的测试人员,并且计划会议和设计讨论没有邀请你,或者业务用户正在独自定义故事和需求,那你应该站出来和团队的其他成员交流。和开发人员一起参与会议,并提议尝试“三方协作”,即测试人员、开发人员和业务专家。谨慎地提供反馈并帮助客户提供例子。让你的问题成为团队的问题,让他们的问题成为你的问题。请你的同事采用团队整体参与的方法。 2. 采用敏捷测试思维 我们提醒敏捷测试人员丢掉一直以来的“质量警察”思维。现在你在敏捷团队中,开发人员参与测试,测试人员可以做任何事情以帮助团队生产最优秀的产品。敏捷测试态度是前瞻性的、创造性的、欢迎新思想、乐于承担任何任务。敏捷测试人员不断磨练自己的技能,随时准备协作,相信直觉,希望帮助团队和业务成功。我们并不是说你应该披上超级测试王的斗篷,去保护世界免受缺陷的危害。在敏捷团队中不存在狂妄自大。团队成员分享你对质量的追求。关注团队目标,帮助每一个更好地工作。使用敏捷准则和价值观指导你。不断尝试最简单的方法来满足测试需要。勇敢地寻求帮助和实验新想法。关注于产生价值。尽可能多的直接交流。灵活地应对变化。记住敏捷开发以人为中心,我们应该享受工作。当对此怀疑时,回顾敏捷价值和准则来决定该怎么做。 敏捷测试思维的一个重要部分是不断想办法改进工作。成功的敏捷测试人员持续地磨练技能。读好书、博客和文章以获得新想法和技能。参加本地的用户组会议。加入邮件列表讨论以获得问题或者新想法的反馈。如果你的公司没有付钱让你参加一个很好的会议,那么把你的经验写成报告在免费的会上作交换。对测试和敏捷开发社区进行反馈也会对你有益。实验新的实践、工具和技术。鼓励团队尝试新方法。短期迭代非常适合这种实验。你可能会失败,但是很快你可以尝试其他的。如果你管理敏捷测试人员或者敏捷团队,给他们时间去学习并提供所需的培训支持。移除障碍使他们更好地工作。当你面对影响测试的问题时,让团队都知道这些问题。通过头脑风暴的方式克服这些障碍。回顾会议可以讨论这些问题并想办法解决。维护一个阻碍事项列表,并在每个迭代中解决一到两个。使用可视化的大图片或者虚拟方式,确保所有人都知道发生的问题并可以跟踪编码和测试的进度。 3.自动化回归测试 敏捷团队没有测试自动化会成功吗?可能吧,但是我们所知道的成功团队都依赖自动化回归测试。如果你花费全部时间用在手动回归测试上,绝没有时间用于重要的探索性测试(会发现隐藏在代码中的危险行为)。敏捷开发利用测试来指导开发。为了编写代码使测试通过,你需要快速、简单地运行测试。没有短期反馈周期和安全的回归测试,团队将很快陷入技术债务,缺陷不断增加,速度越来越慢。 自动化回归测试是团队的工作。整个团队应该选择每种测试适合的工具。提前考虑测试将帮助开发人员为了便于测试自动化来设计代码。使用敏捷测试象限和测试自动化金字塔来帮助你自动化各种类型的测试。记住从简单入手。你会惊讶地发现一些基本的自动化冒烟测试或者自动化单元测试会发生很大作用。测试自动化是团队的工作。开始时很艰苦,需要克服很大的痛苦。如果你管理开发或者测试团队,确保在时间、培训和激励上提供了足够的支持。如果你是没有自动化测试的团队的测试人员,开发人员疯狂地编写代码以至于不会停下来考虑测试,那么你会面临很大的挑战。尝试从管理层和团队成员中获取支持以开始小规模的自动化工作。 4.提供并获取反馈 反馈是敏捷的核心价值。敏捷的短期迭代可以提供持续的反馈以帮助团队运转正常。测试人员通过自动化测试结果、探索性测试的发现和系统实际用户的观察结果的形式帮助提供反馈。敏捷方法允许团队获取有关构建中软件的反馈。这是关键。故事代表了测试人员和分析人员向开发人员提供反馈的工作单元。迭代发布有助于团队外部的反馈。大多数敏捷实践都创建了反馈循环使团队应用。测试人员也需要反馈。你怎么知道从客户手里拿到了预期行为的正确例子?你怎么知道编写的测试用例正确地反映了这些例子?开发人员通过查看你收集的例子和你创建的测试能够理解应该编写什么代码吗?一个最有价值的技能是学习如何寻求自己工作的反馈。询问开发人员是否得到了足够的信息以理解需求并且是否能够指导编码。询问客户是否理解质量标准。花时间参与迭代计划会议和回顾会议以讨论这些问题并提出改进方案。 5.构建核心实践的基础
每一个开发团队都需要代码管理和持续集成。如果不知道自己在测什么,就无法有效地测试,如果无法配置代码你根本无法测试。所有团队成员需要至少每天一次导入自己的工作。每一次集成必须通过自动化构建验证,其中包括提供软件状态快速反馈的测试。实现持续集成过程应该是软件开发团队中优先级最高的事情。如果团队没有每日构建验证的版本,停止手里的工作,开始构建。就是这么重要。一开始并不要求太高。如果你有很大的系统需要集成,肯定会更具挑战性。通常来说没有那么困难,市面上存在很多优秀的工具,开源的、商业的。
没有可控的测试环境就无法有效地测试。你需要知道部署了什么版本,使用的数据库模式是什么,其他人是不是正在更新,其他进程是否运行在那台机器上。硬件总是越来越便宜,开源软件越来越多。团队必须投资以有效地执行自动化和手动探索性测试。如果测试环境出现问题,赶紧说出来,让全队一起解决。
即使优秀的软件开发团队在感觉到时间压力之后,也会忽视重构或者快速解决问题修补缺陷。随着代码越来越混乱和难以维护,更多的缺陷出现,很快团队的速度就慢了下来,因为要解决缺陷才能添加新的功能。团队必须不断地评估技术债务的数量,并努力减少和避免。大家经常说:“我们的管理层不会给我们时间做这些,没有时间重构,日程很紧”。但是,我们可以很容易举一个业务用例来显示增长的技术债务如何耗费公司的成本。衡量代码和缺陷率哪些会导致技术负债变为对底线的影响存在很多办法。仅仅指出不断下降的速度就足够了。业务需要软件开发团队保持持续的生产力。他们不得不减少期望功能的范围以保证足够的时间来进行良好的、测试规范的代码设计和优秀实践,如持续小规模重构。自动化回归测试的良好覆盖率是最小化技术债务的关键。如果缺少,那就在每个迭代中拿出时间来构建自动化测试,规划一个“重构迭代”以升级或添加必要的工具,编写测试并进行重构。在每个迭代中花时间通过测试指导代码,重构必要的代码,添加丢失的自动化测试。对这件工作要重视。长期来看,团队能够变得更快。
敏捷团队能够生产高质量代码的一个原因是他们小规模地工作。故事代表了几天的工作量,每个故事被分解成小增量,按步构建。测试可以针对一小块,并且随着功能聚集再增量测试。如果团队成员喜欢一次开发一大块功能,鼓励他们采用步骤式的方法。提出问题:“这个故事的核心业务价值是什么?这块代码的最基本路径是什么?下一步干什么?”建议大家编写任务卡片以编码和测试小增量,记录设计概念和确认测试和测试自动化策略。
对敏捷思想不熟悉的人经常会问敏捷测试人员:“在所有故事完成并且可以测试的时候你会怎么做?”经验丰富的敏捷实践者会说:“测试人员必须贯穿整个迭代,整个开发过策划那个。否则就会失败”。测试人员基于客户提供的例子编写测试,以帮助开发人员理解故事并开始编程。测试和例子提供了一种通用语言使所有人都参与到软件理解中。测试人员和开发人员在编码时紧密合作,他们也会与客户紧密合作。开发人员向测试人员展示他们编写的功能,测试人员向开发人员展示他们发现的异常行为。测试人员随着编码进展编写更多测试,开发人员是其通过测试,测试人员进行更多探索性测试以了解是否生产了正确的价值。每一个敏捷迭代包含了若干持续、快速、增量的测试——代码—— 测试——代码——测试迭代。当这种合作和反馈周期被打断,并且测试与开发分离时,糟糕的事情会发生。如果故事是在编码之后的迭代中被发现的,开发人员不得不停止新的故事,回忆代码是如何实现上个迭代的故事的,修补它,并且等待其他人测试。在软件开发中没有什么几个事实,但是我们确定缺陷发现的越早,修补的成本越低。当编码一直由测试指导,编码的同时进行测试,我们更有可能达到客户预期的行为,提供客户所需的价值。测试是团队的职责。如果团队没有这种观念,让所有人想一想对质量的关注、对发布优秀产品的期待和采取哪些措施来确保团队实现目标。
单个敏捷开发实践如持续集成能够发挥作用,但是多个敏捷实践的组合比各个部分相加要大。测试驱动设计、共有代码所有权和持续集成一起促进快速反馈、持续改进代码设计和快速产生业务价值。自动化测试很好,但是使用自动化测试驱动开发,随后是探索性测试以发现缺陷或者弱点,分多层次更好。某些实践单独操作并不好。没有自动化测试,重构是不可能的。通过迷你瀑布型的方式发布小版本会丢失敏捷开发的所有优势。如果你的现场客户没有做决定的授权,那么他对团队的价值有限。敏捷实践是互补的。花时间理解各个实践的目的,想想如何利用全部优势,针对什么对团队有用做出深思熟虑的决定。 6.与客户合作 测试人员对敏捷团队的最大贡献之一是帮助客户理清需求并设定优先级,通过预期行为和用户场景的具体例子描绘需求,并把这些例子转换为可执行的测试。测试人员使用业务的领域语言和开发团队的技术语言。我们担任优秀的辅助者和翻译。千万不要阻碍开发人员和客户之间的直接沟通。鼓励尽可能多地直接交流。使用“三方协作”方法。当需求丢失或者被误解,客户、开发人员和测试人员需要一起解决问题。请客户经常在白板或者其他虚拟工具前讨论问题。如果客户发布于不用的地区、国家,那就使用任何能找到的工具来加强沟通和协作。电视会议、即时消息和 wiki不能完美的替代面对面的交流,但是也比发邮件或者什么都不做要好。 7.保持大局观 我们发现测试人员有大局观,通常从客户的角度看问题。开发人员通常关注于实现当前的故事,虽然他们使用测试来指导,但是不得不关注于需求的技术实现。大局观对团队贡献巨大。测试驱动开发,如果完成得很好,单独的代码没有缺陷。如果新的功能导致一些应用明显不相关的部分崩溃怎么办?一些人不得不考虑这种对较大系统的影响并引起团队注意。如果我们忽略了一些可能惹恼客户的细节怎么办?新的UI可能没什么缺陷,但是如果背景颜色使文本难以阅读怎么办?这都是最终用户会注意到的问题。使用敏捷测试象限作为纲领来帮助规划测试覆盖所有范围。使用测试金字塔思想确保测试自动化的良好投资回报率。通过测试指导开发有助于确保你没有丢失重要的事情,但并不完美。使用探索性测试了解系统应该如何工作,测试应该指向哪个方向。让你的测试环境尽可能与生产环境类似,使用反映现实世界的数据。勤于重新构建一个生产环境类似的场景,如负载测试所需。团队的每一个人都很容易只关注手边的一个任务或者故事。这是一次只做一块功能的缺点。帮助你的团队后退一步,评估当前的故事如何负责业务的大局。不断问自己如何才能更好的产生真正的价值。 互联网产品下质量保障质量保障的核心目标是质量 & 效率并重,对于互联网产品来说诠释如下: 质量i.不仅仅是功能可用性层面,需要关注用户体验。 ii.不仅仅是上线前的质量保证,需要延伸至把关上线中、线上的质量。 iii.不仅仅只停留在好坏的感性模糊认识,需要将质量概念量化、可视化。 iv.不仅仅光靠抽样个例,需要大数据统计做强有力的支撑。 v.不仅仅只局限自身产品的质量,也需要关心竞品。 效率i.加快产品迭代,唯快不破。 ii.提高问题暴露,定位以及解决速度,快中求稳。 对产品建立质量标准,将其度量化并形成稳定的、可衡量的产品质量benchmark,对于产品可以列出数据完整性、安全性、传输速度、在线消费体验等最核心的质量维度。线下以此作为发版标准,驱动产品质量迭代越来越接近目标;线上以此作为监控范围,对线上质量问题主动防御,加快应对。 “以质量为中心,以数据为驱动”为宗旨贯穿整个流程,将各种测试工具和方法融入进来,构筑一套全流程质量保障体系,如下图所示:
二、测试技术线下集成持续化、测试服务化,以应用质量(QPS、SLA、性能)、业务指标、过程质量(代码覆盖率,千行 bug 率)一系列发版标准为目标,将自动化测试、性能、单测、异常等工具集成入构建—部署—quickcheck—slowcheck—release 的流程中,快速发现问题并解决,迭代质量。线下需要更多精力关注在异常和性能测试中,这些往往是线上问题多发区。 上线过程中灰度控制,把产品发布过程划分为多个级别,每个级别限制一定的流量和用户范围,并在每个级别对产品进行部署和验证的迭代过程。一方面逐步放量,小心验证,降低上线带来的风险;另一方面开展用户测试,让用户参与产品测试,加强与用户互动。让用户参与 beta 环境分为两种情形:被动命中(将同一特征的用户强制划分至小流量环境中)和主动邀请(邀请粉丝或有偿用户)。对服务器来说架构能够支持逐步放开流量,对客户端发版来说有一个平台支持哪些版本哪些用户能升级到beta版本,并且在小流量阶段要密切关注监控和用户反馈,将问题及时扼杀在萌牙阶段,不带到全量阶段。 线上监控 & 定位,从基础拓扑(网络、单机、数据库等底层服务)、服务稳定性(接口成功率、5XX、4XX非预期返回码的占比等服务器可用性层面)和业务质量(上传、下载的成功率等用户功能层面的易用性)三个核心要素延展开全方位细粒度的监控覆盖,并从质量标准、质量防线和质量闭环三个维度进行质量建设:首先对产品建立一套完善的产品质量标准体系,并将其度量化,固定成 benchmark。紧紧围绕质量数据,组建从用户(舆情热点)、端(产品体验)、服务器(稳定性)到基础网络(SLA)的层层实时防护网,最后通过上线管理—报警中心—智能定位—故障通报的质量闭环环节落地,不断迭代优化,能够快到线上问题快速预警、定位及解决。 三、专项质量保障(1)多副本分布式存储:旁路测试 & 线上数据检查,以数据完整 & 安全为使命 考虑灾备冗余、成本因素,云存储都会使用多个机房,跨机房的传输相比单机房的数据流动本身即增大了延迟,不同机房网络属性、机器性能等差异更对服务质量的保障提出了挑战。单一的机器性能测试已经不满足需求,需要引入旁路测试:复制线上的部署拓扑,进行等比例缩放,仿真线上的数据,在测试环境里重放,观察复杂部署和网络环境下服务的稳定性,辅佐一定的异常流量,评估系统的容错性以及灾难发生时预案是否能生效等。为更进一步保障数据的安全,对线上每日新增的数据较验各个副本的一致性及完整性。 (2)多机房 & P2P 流量架构:流量 diff 系统 & 实网系统 & 众测测速,传输速度体验 下载由源站IDC、CDN和P2P三部分承担,用户端、网络端、服务器云端的每一个环节都会影响速度。服务端的流量调度是根据用户地点、运营商网络、请求入口、文件所在机房、资源热度等多重属性对用户分配多个可带优先级的下载域名,让客户端充分并发及容错。多重维度的组合注定了调度策略的复杂性以及验证的难度,流量 diff 系统应运而生:在线下构造两套流量系统,一套线上代码环境,一套测试代码环境。通过回放线下真实流量,diff 前后调度是否符合预期,是否带来了非预期的变化。 三、最终 从质量标准、质量防线和质量闭环三个维度进行质量建设。首先对产品建立一套完善的产品质量标准体系,并将其度量化,固定成 benchmark。紧紧围绕质量数据,组建从用户(舆情热点)、端(产品体验)、服务器(稳定性)到基础网络(SLA)的实时防线,最后通过“上线管理—报警中心—智能定位—故障通报”的质量闭环环节落地,不断迭代优化。 文化价值驱动质量产品也是创造它们的文化产物。麻省理工学院马丁信托创业中心的总经理Bill Aulet,同时也是麻省理工斯隆商学院的资深讲师,提醒我们:文化会吞噬策略,并且,我质疑流程也一样会被文化所吞噬。当组织文化与流程改变的精神相冲突时,例如当命令式与控制式的文化试图通过自管理,敏捷团队来达到生产率的目的,每一次冲突都会是文化获胜。文化通过组织的价值观、标准、信念和习惯表现出了自己,这些表现形式进而通过规范团队行动的方式产品质量产生影响。我的这一观点并非来自某个组织的报告说明,而是通过组织在每一个级别上的行为所得出的。首先,组织的价值观通常能够帮助团队排列出优先级最高的任务。
团队任何时候都需要团队,需要这样的团队成员: 1.具有创新精神的测试人员 2.有测试欲望并能够持之以恒的测试人员 3.富有经验的软件测试人员 4.具有远见性的测试人员 ---------------------------------------------------------------------------------------出处:http://www.cnblogs.com/wintersun/p/5297352.html |
|