发布新日志

  • 编写golang测试代码之一 初接触

    2018-04-12 16:01:45

    1、准备工作
    研发代码的存放位置获取,javascript/css/makefile/go语言的掌握、git命令的熟练应用等等。

    2、代码编写
    。。未完待续

  • JS测试代码编写 之一

    2017-10-30 16:22:57

           给js写测试,最近看到了一篇不错的学习文档,内容如下:

           项目里用了jamine和JsTestDriver两种js测试框架。


    http://www.cnblogs.com/Alex--Yang/p/3417163.html

  • 测试架构师应具备的能力

    2017-04-20 14:44:17

    一个测试架构师必须具备的第一大能力:
    准确的商业理解力!  最近看到一篇关于测试架构师介绍的文章,文章中的测试架构师原型来自微软,其描述的工作内容让不少国内的测试同业很是羡慕,但又觉得好像离我们中国人很远。不知我们中国的测试工程师能做吗?我的答案是Yes。  因为,我现在就在中国带领着一个测试架构师团队。了解自己所在公司测试架构师团队的运作和工作内容(后续将陆续与大家分享),虽然我们之前也从未接触过微软的测试架构师。但随着公司业务的扩大,业务的需要驱动了我们公司内部有一小部分人担当起了测试架构师的职责,其title来源也是有其偶然性。原本公司中测试工程师往上发展就是系统测试工程师,系统测试工程师再往上应该叫什么呢?最后参考软件开发的title,就开创性的在公司内部叫测试架构师。并开始从事了很多从公司层面而仅非单个测试经理层面所需要的新的测试工作职责,例如:领导负责一个产品线或一个大产品的测试技术规划,early testing,系统测试工程师的培养,与开发架构师一起设计和改进架构的设计质量,测试执行活动质量的审查保障,亲自指导重点测试方案的设计,为了不断降低公司研发成本而进行新测试技术研究实践和推广,基于风险的测试,基于模型的测试,安全性测试,兼容性自动化测试,分布式自动化测试,性能压力测试,需求测试等专项测试技术领域的研究,并支撑新领域重点市场项目活动等等。  与微软的共性是我们的测试架构师都不再亲自写自动化测试脚本,不亲自写测试工具的代码。但我们会从项目初始即项目需求和架构设计阶段就开始考虑未来的自动化测试框架,针对具体的产品特点,思考选择最合适的自动化测试语言;在架构设计中充分考虑如何支撑未来更高的自动化测试率,让架构设计调整具备高的可测试性率;由于参与早期的设计方案讨论选型,能提前识别和规划好未来产品测试组所需要提前准备的测试实现技术。并亲自带着测试工程师提前进行测试技术储备。当然我们也常常亲自去实施一些测试活动:如设计测试工具的架构(主要考虑未来扩展性和更好满足测试需求),然后交给专门的测试工具开发团队来实现;或亲自设计压力测试方案;亲自研究安全性测试策略和方案。推广方式,主要是亲自实践各种新测试技术后,再带着测试人员在实战中掌握相关的方法。  我们大部分的测试架构师都是写过自动化测试脚本或程序的,只是现在的工作由于需要我们去思考太多的东西,所以没有一丁点精力来编码。特别是负责一个产品线的测试架构师,由于负责多个产品,还要抽取产品间的共性测试技术,要建立起产品线的测试架构图,统一产品间的测试技术,统一测试方案的设计质量标准,需要具备更强的抽取共性的能力。同时,还需要能在短期内快速了解和识别影响产品成败的关键测试技术,因为并不是所有产品都是性能压力测试就是最重要的。例如:某产品线有9个产品,有的产品最需要保障的是可靠性(性能,可用性不是关键);有的产品最需要保障的却是可用性,而不是可靠性;有的产品最需要保障的是安全性,而不是性能;有的产品最需要保障的是可移植能力和可集成能力,而不是性能。那么相应的每个产品测试用例设计就会有所侧重,例如:对于重视可移植能力和可集成能力的产品,测试架构师就应该帮助测试人员系统地做好这2个领域的测试用例。  因此,测试架构师必须具备的第一个能力就是:“准确的商业理解力。”商业成功的核心竞争力是什么?测试技术和测试资源是否能真正地保障或支撑商业成功的核心竞争力?这些都是测试架构师需要准确识别的,如果测试架构师识别错误了,那么有可能在需要重点保障的领域,测试技术和测试资源投入不足,导致最后产品的商业竞争力得不到支撑,得不到质量保障。例如:某产品对外宣传是业界可靠性最高的产品,可是测试人员在测试活动中惯性地把主要精力都花在了性能测试中,对各种异常的测试验证并不是业界最丰富的。结果在与业内其他产品比较的第三方测试报告中,该产品的可靠性得分却并不是第一,虽然性能是第一,但该产品在特定的重视可靠性的市场中基本失去了商业竞争力。  某美国公司的一款产品在传统行业中主要功能基本雷同,如何才能与类似产品拉开距离,突出竞争力。后发现产品的用户在使用产品时普通操作时间都较长,因此为了缩短用户的操作时间,该公司决定在产品的可用性领域重点投入设计,核心竞争力是解决用户的可用性问题。其测试团队把大部分的测试设计精力也放在了可用性的测试活动中,构建了业界非常丰富的可用性测试用例,这些测试用例的场景超过了产品设计考虑的原有场景,并最终通过测试驱动设计,与产品设计师一起不断改进产品的可用性。最后不但提供了业界可用性最强的产品,而且其可用性功能的稳定性质量也非常高。测试活动从效率和质量角度支撑了产品的商业成功。  所以,如果你的公司正准备招募测试架构师,请第一考评他的能力应该是他的商业理解力。具有该能力的测试工程师知道如何选择:做正确的事!确保事半功倍。而不具备该能力的测试工程师可以成为系统测试工程师,由他来保障正确的把事做好!    测试架构师必须具备的第二个能力:区分测试重点和测试难点!  重点和难点两个词汇有时能代表同样的方向,有时却是相差较远的方向。  为什么我要把是否有能力区分测试重点和测试难点作为测试架构师必备的第二个基本能力。因为,我曾在某产品线对测试活动的质量进行抽查时,与每个产品的系统测试工程师进行了沟通,发现只有一名有6年经验的系统测试工程师在我的的启发下,分清了自己所负责产品的测试重点和测试难点。而其他的系统测试工程师一直都把测试难点误当成了测试重点,作为他技术攻关工作的主力方向。甚至从来没有真正思考过什么测试技术才是自己所负责产品决定成败的测试重点,只是简单地把自己在工作中碰到的所不具有的测试技术都当成测试重点,其实很多都只是测试难点。的确,在某些产品测试难点和测试重点刚好重合。虽然某些产品测试重点在技术上并不难,但是却需要我们把测试重点部分的工作质量做到最佳,时间和资源投入最多,而不要把有限的资源投入到测试难点的工作中去。我很认同华为任正非对华为工程师的要求“要做工程商人”,我们其他公司的工程师同样应该以商业目标为自己的技术工作目标,不应唯技术论,越新的技术,越难的技术就越愿意投入。测试工程师同样要心中一直有一个目标指引着自己的所有技术工作方向。这个目标就是我测试架构师日记中第一篇谈到的“准确的商业理解力”告诉你的工作目标。  由于项目中每个人的分工不同,因此不可能每个测试人员一开始就能知道自己工作的商业目标是什么,所以也不用去责怪大家。可是领导产品的测试架构师不能准确的识别或培养其他测试工程师具备识别测试重点和测试难点的能力,那么注定这个测试团队的工作不但质量保障会打折扣,而且会浪费不少组织的资源和成本。  因为资源和时间是有限的,而完美工作的追求是无限的。因此,我们如何在有限的资源和时间下,保障基本的质量目标,并尽可能提升质量目标。就需要在分清测试重点后,优先针对测试重点目标进行系统地测试技术研究,测试技术攻关,测试资源主要投入。对于非测试重点的测试难点部分就要降低优先级,放在最后考虑。  测试架构师的工作应该牢牢抓住真正的测试重点来开展,甚至在整个产品测试组都方向错误时,要能从商业角度帮助测试组改变观点。那么当从测试经理到普通工程师都误理解了测试重点时,测试架构师应该如何来启发他们呢?我这里就分享一个案例吧:  在一次到产品测试组进行测试活动质量抽检时。我们问测试经理,你们产品测试目前最大的需求是什么?他说是如何进行压力测试和性能测试,希望我们测试架构师团队能在此领域多给予支持。我心里知道:他所负责的产品特性核心不是性能和压力测试,但我没有反驳他。而是继续问他下一个问题:“你觉得会让你产品未来应用时商业失败的最大担心是什么?”他想了想说:“不能对客户的生产系统产生破坏,让客户的业务中断。”“依据我们的经验,与客户生产系统交互的模块虽然是个小模块,但是在其他产品上经常出现内存泄露的故障从而破坏了生产系统。那你针对该小模块做过哪些系统地测试?有无专门进行内存泄露的测试,因为内存泄露对客户生产系统的破坏最大。”我问到。这时此测试经理才恍然大悟,这个对生产系统质量影响最大的小模块居然没有系统地进行过深入全面的测试。我这时告诉他 “你之所以开始说性能和压力测试是你的重点需求,是因为你们组里没有在性能和压力测试方面的积累,有工作开展的难处,这是困扰你的困惑。但是你的产品形态的质量不是性能或所谓压力测试来保障的,而是需要不对生产系统产生破坏。因此,你唯一能破坏生产系统的那个小模块应该是你整个产品中质量最高的模块,也应该是测试最全面最深入的模块,你的技术力量应该主要投到这个地方”。后来,针对该小模块我们进行专项内存泄露的测试,结果发现了好几个内存泄露的大bug,这些bug每一个都是会导致客户生产系统中断的杀手。  测试架构师不是团队中专门解决测试难点的专家,而是识别测试重点,并支撑测试重点工作的专家。“区分测试重点和难点的能力”不是测试架构师独有,系统测试工程师和测试工程师一样可以具有。与第一篇“准确的商业理解力”一样,第二篇要做的是:做正确的事。    测试架构师必须具备的第三个能力:全面多样化的产品经验!  在开始描述我理想中的测试架构师必备素质第三篇前,我想先转载一篇来自互联网万欣的文章《好的架构师都是善良的独裁者——万欣》与大家分享,作为测试架构师必备素质第三篇的前言:  对于任何一个软件开发人员来说,架构师都是一个令人向往的角色。就连世界首富比尔盖茨在2000年卸任公司CEO的同时,也担任了微软公司的荣誉角色“首席软件架构师”,可见“架构师”这一称谓的吸引力。架构师是公司的“金领”,有着非常高的收入,很少需要考虑生存的问题,从而有更多的精力思考关键技术问题,形成“强者愈强”的良性循环。部分优秀的开发人员在工作了一定时间后,就要开始考虑自己的未来到底向哪个方向发展。如果开发人员的沟通能力强过技术能力,在补充一定的项目管理知识后,可以向技术管理的方向转型。如果其对技术一直很感兴趣,而沟通能力也不弱,则可以试着进一步加强技术修养,以期向架构师的方向发展,最终“修成正果”。  那么,到底什么是架构师呢?所谓的架构师,应该是一个技术企业的最高技术决策者。他主要负责公司软件产品或软件项目的技术路线与技术框架的制订。好的架构师都是善良的独裁者,具有很强的技术、良好的写作能力、良好的口头表达能力,能够在各个层次进行沟通。从开发人员到架构师的成长应该是阶梯式的,一般来讲开发人员在刚刚开始工作时只能开发简单的独立软件模块,慢慢的随着经验的增长,他开始接触一些相互之间有信息传递的模块,而后来,他会发现自己接到的开发任务已经不是一个独立的单体,这些任务由一些专门的软件部分组成,可能包含数据库,工作流引擎,消息服务等等各种功能模块,可能分布在不同的服务器上,所有的部分协同起来,完成软件功能。而这时候,体系结构的好坏将直接决定了系统的性能和可扩展性,而就在这时候,这名优秀的开发人员也开始思考架构师应该思考的问题了,或者说,他向成长为架构师的道路迈出了一大步。  什么是架构师最具价值的技能呢?就是要了解不同的知识,做一个“杂家”或者说“博学家”。当然,如果你的数据库技术非常棒,或者你在工作流引擎方面具有不可超越的专家知识,那也是很不错的。好的架构师有好多都是从专家成长过来的。但是,这不是架构师应该做的事情,架构师应该做的是了解所有的东西,既了解技术的宏观面,又了解技术的细节。真正的架构师不仅仅要了解软件,也要了解硬件,在关键的部位使用合适的硬件来取代软件,可以成倍甚至成百倍的提高整个系统的效率。下面我将会以互联网行业对的架构师的要求为例,向大家讲解作为架构师应该具备的知识。  互联网行业是当前最激动人心的行业之一,很多的创新都来自于这个行业,而每一个大型的网站如Google,Yahoo,Myspace等都需要解决一个非常复杂的问题,就是网站的分布式向外扩展(Scale Out)的问题。解决这个问题,需要最优秀的架构师对业务进行剖析,利用软硬件将网站进行重构,甚至根据业务研发相应的分布式技术,解决网站复杂的分布式计算的问题。  如果你想在这个行业中成为一名架构师的话,需要至少掌握网络知识,硬件,软件,网站优化等方方面面的知识:  网络知识  当前的软件已经绝对不是那种仅仅跑在一台单机上的孤立应用了。不仅仅是在互联网行业,任何一个行业的软件,都要求其具有网络功能。因此,网络知识是架构师必备的知识。我们所说的网络知识,不仅仅包括TCP/IP,http等互联网行业常用的软件协议,也包括网络规划,甚至更具体的说,根据网站应用所处的地理环境进行网络规划。比如人们常说:“这世界上最远的距离不是生与死的距离,而是电信到网通的距离”(笑)如果应用是建立在中国的,就要考虑电信用户和网通用户访问网站的速度应该都比较快才可以。这时候的解决方案可能有多种,比如采用CDN(Content Delivery Network内容分发网络)使得网站的内容发布到离用户最近的服务器,又可以采用把服务器放在一些所谓的双线机房中,甚至将几种方案结合起来使用。这些都统统归到网络知识中。做为公司的架构师,要对这些知识都有所了解,才有助于在遇到问题时找到最佳答案。  硬件知识  了解硬件的极限,是架构师的基本功。我见过一些人,他们的眼中软件硬件都是没有极限的,需要资源就申请,系统性能下降了就买更高级的设备。然而,硬件的性能有很大一部分取决于I/O设备。而这些I/O设备依靠的都是机械物理运动,这种运动是有极限的。因此当资源访问量增大到一定的程度时,这种物理运动将成为瓶颈。比如说,在开发网站的过程中,记录访客的状态是一件很重要的事情,一般来说可以使用HttpSession来记录。而HttpSession的存储问题将是一个很大的挑战,尤其是多机共享Session时,将HttpSession存成文件并通过多机共享或网络备份的方式来解决分布式的问题是常用的方案,然而,架构师必须考虑到这种方案是有I/O极限限制的,很难扩展到超过一定规模的大型网络。同时,架构师应该了解目前最近的硬件发展是否对软件系统会造成一定的影响,比如在多核的条件下是否对软件编程有新的要求,是否会对运行在虚拟机和非虚拟机上的程序有影响等等。  软件知识  软件知识所包含的范围就更加广泛了。对于互联网行业来讲,架构师要了解操作系统,数据库,应用服务器等各方面的知识。比如说,如果网站使用的操作系统是 Linux,就要了解这个Linux版本的性能与局限性,比如说最多可以存放的单个文件为多大。有的数据库的数据是以单个文件来存放的,虽然我们很少见到数据库中的数据多到不能再放入一条记录的情况,但是作为架构师,请时刻注意,这种可能性是有的。而且如果你有幸在一家高速成长的互联网企业中,而你所负责的应用又没有经过优化的话,可能你会很快见到这种现象。这种现象的发生可能是由于操作系统不支持大文件的原因,也可能是数据库不支持大文件。不论如何,架构师应该在这种现象发生之前就把一切都准备好。对数据库中表的拆分是架构师应该遇到的另外一个困难。一般来说增加应用服务器比较简单而增加数据库服务器则是比较复杂的问题,如果一个站点由多个数据库支持,架构师需要考虑如何在保证数据一致的情况下,让多个数据库分担压力。有些解决方案是将数据库的读写分开,使得大多数的查询sql不经过核心数据库,而只是访问数据库的副本,但事实上,这种方式也只能维护规模不大的网站。对于大型的网站来说,把业务分散到不同的数据库中,只共享必要的数据,才是合理的提高网站扩展性的解决方案。  其他知识  作为系统架构师,可能还需要对分布式系统,负载均衡,网络安全,数据监控等等各方面都有所了解。不仅仅是了解理论知识,也要对相关的产品和业界进展有一定的认识。比如说做负载均衡最好的产品是那种。目前最常用的备份策略是什么,有什么缺点。如何使用缓存,如何做好日志分析等等。  刚刚谈到的是架构师需要掌握的知识,然而,冰冻三尺非一日之寒。这个过程需要我们慢慢的积累。如果你已经进入到公司进行软件开发,请时刻关注你所开发软件的性能与可扩展性,而不仅仅局限在功能上,时刻想着任何一个简单的问题:我开发的模块如果放在多人并发的环境下会怎样,慢慢的就会有所心得。如果你还是一个在校学生,不要想着自己离架构师这个职位还很遥远。要知道,成为架构师的修炼之路是很长的,甚至可以说是终身的,因此早点进入学习状态,不断修炼自己。在学校期间学好离散数学,数据结构,操作系统,编译原理,体系结构,数据库原理等关键课程,并积极寻找机会到外面实习,增长自己的工作经验。如果有机会去到一些技术主导的公司中工作,就一定不要放弃这种机会,慢慢就会成长起来。最重要的,你会养成关注技术,勤于思考的好习惯。当有一天你发现自己对任何技术难题都可以一眼看到其本质,并能够将其分解为一个个可轻松解决的模块,你会由衷的感觉到知识给你带来的快乐,或许那一天,你已经是一个架构师了。
  • 测试架构师应该具备的三大能力

    2017-04-20 11:48:41

    软件测试架构师是一个新职位,但也是一个非常必要的职位。一个普通程序员要想修炼成为测试架构师必须具备三大能力:准确的商业理解力、区分测试重点和测试难点、全面多样化的产品经验。本篇文章向你详细介绍一个测试架构师必须具备的第一大能力:准确的商业理解力!

    一个测试架构师必须具备的第一大能力:准确的商业理解力!

    最近看到一篇关于测试架构师介绍的文章,文章中的测试架构师原型来自微软,其描述的工作内容让不少国内的测试同业很是羡慕,但又觉得好像离我们中国人很远。不知我们中国的测试工程师能做吗?我的答案是Yes。

    因为,我现在就在中国带领着一个测试架构师团队。了解自己所在公司测试架构师团队的运作和工作内容(后续将陆续与大家分享),虽然我们之前也从未接触过微软的测试架构师。但随着公司业务的扩大,业务的需要驱动了我们公司内部有一小部分人担当起了测试架构师的职责,其title来源也是有其偶然性。原本公司中测试工程师往上发展就是系统测试工程师,系统测试工程师再往上应该叫什么呢?最后参考软件开发的title,就开创性的在公司内部叫测试架构师。并开始从事了很多从公司层面而仅非单个测试经理层面所需要的新的测试工作职责,例如:领导负责一个产品线或一个大产品的测试技术规划,early testing,系统测试工程师的培养,与开发架构师一起设计和改进架构的设计质量,测试执行活动质量的审查保障,亲自指导重点测试方案的设计,为了不断降低公司研发成本而进行新测试技术研究实践和推广,基于风险的测试,基于模型的测试,安全性测试,兼容性自动化测试,分布式自动化测试,性能压力测试,需求测试等专项测试技术领域的研究,并支撑新领域重点市场项目活动等等。

    与微软的共性是我们的测试架构师都不再亲自写自动化测试脚本,不亲自写测试工具的代码。但我们会从项目初始即项目需求和架构设计阶段就开始考虑未来的自动化测试框架,针对具体的产品特点,思考选择最合适的自动化测试语言;在架构设计中充分考虑如何支撑未来更高的自动化测试率,让架构设计调整具备高的可测试性率;由于参与早期的设计方案讨论选型,能提前识别和规划好未来产品测试组所需要提前准备的测试实现技术。并亲自带着测试工程师提前进行测试技术储备。当然我们也常常亲自去实施一些测试活动:如设计测试工具的架构(主要考虑未来扩展性和更好满足测试需求),然后交给专门的测试工具开发团队来实现;或亲自设计压力测试方案;亲自研究安全性测试策略和方案。推广方式,主要是亲自实践各种新测试技术后,再带着测试人员在实战中掌握相关的方法。

    我们大部分的测试架构师都是写过自动化测试脚本或程序的,只是现在的工作由于需要我们去思考太多的东西,所以没有一丁点精力来编码。特别是负责一个产品线的测试架构师,由于负责多个产品,还要抽取产品间的共性测试技术,要建立起产品线的测试架构图,统一产品间的测试技术,统一测试方案的设计质量标准,需要具备更强的抽取共性的能力。同时,还需要能在短期内快速了解和识别影响产品成败的关键测试技术,因为并不是所有产品都是性能压力测试就是最重要的。例如:某产品线有9个产品,有的产品最需要保障的是可靠性(性能,可用性不是关键);有的产品最需要保障的却是可用性,而不是可靠性;有的产品最需要保障的是安全性,而不是性能;有的产品最需要保障的是可移植能力和可集成能力,而不是性能。那么相应的每个产品测试用例设计就会有所侧重,例如:对于重视可移植能力和可集成能力的产品,测试架构师就应该帮助测试人员系统地做好这2个领域的测试用例。

    因此,测试架构师必须具备的第一个能力就是:“准确的商业理解力。”商业成功的核心竞争力是什么?测试技术和测试资源是否能真正地保障或支撑商业成功的核心竞争力?这些都是测试架构师需要准确识别的,如果测试架构师识别错误了,那么有可能在需要重点保障的领域,测试技术和测试资源投入不足,导致最后产品的商业竞争力得不到支撑,得不到质量保障。例如:某产品对外宣传是业界可靠性最高的产品,可是测试人员在测试活动中惯性地把主要精力都花在了性能测试中,对各种异常的测试验证并不是业界最丰富的。结果在与业内其他产品比较的第三方测试报告中,该产品的可靠性得分却并不是第一,虽然性能是第一,但该产品在特定的重视可靠性的市场中基本失去了商业竞争力。

    某美国公司的一款产品在传统行业中主要功能基本雷同,如何才能与类似产品拉开距离,突出竞争力。后发现产品的用户在使用产品时普通操作时间都较长,因此为了缩短用户的操作时间,该公司决定在产品的可用性领域重点投入设计,核心竞争力是解决用户的可用性问题。其测试团队把大部分的测试设计精力也放在了可用性的测试活动中,构建了业界非常丰富的可用性测试用例,这些测试用例的场景超过了产品设计考虑的原有场景,并最终通过测试驱动设计,与产品设计师一起不断改进产品的可用性。最后不但提供了业界可用性最强的产品,而且其可用性功能的稳定性质量也非常高。测试活动从效率和质量角度支撑了产品的商业成功。

    所以,如果你的公司正准备招募测试架构师,请第一考评他的能力应该是他的商业理解力。具有该能力的测试工程师知道如何选择:做正确的事!确保事半功倍。而不具备该能力的测试工程师可以成为系统测试工程师,由他来保障正确的把事做好!


    测试架构师必须具备的第二个能力:区分测试重点和测试难点

    重点和难点两个词汇有时能代表同样的方向,有时却是相差较远的方向。

    为什么我要把是否有能力区分测试重点和测试难点作为测试架构师必备的第二个基本能力。因为,我曾在某产品线对测试活动的质量进行抽查时,与每个产品的系统测试工程师进行了沟通,发现只有一名有6年经验的系统测试工程师在我的的启发下,分清了自己所负责产品的测试重点和测试难点。而其他的系统测试工程师一直都把测试难点误当成了测试重点,作为他技术攻关工作的主力方向。甚至从来没有真正思考过什么测试技术才是自己所负责产品决定成败的测试重点,只是简单地把自己在工作中碰到的所不具有的测试技术都当成测试重点,其实很多都只是测试难点。的确,在某些产品测试难点和测试重点刚好重合。虽然某些产品测试重点在技术上并不难,但是却需要我们把测试重点部分的工作质量做到最佳,时间和资源投入最多,而不要把有限的资源投入到测试难点的工作中去。我很认同华为任正非对华为工程师的要求“要做工程商人”,我们其他公司的工程师同样应该以商业目标为自己的技术工作目标,不应唯技术论,越新的技术,越难的技术就越愿意投入。测试工程师同样要心中一直有一个目标指引着自己的所有技术工作方向。这个目标就是我测试架构师日记中第一篇谈到的“准确的商业理解力”告诉你的工作目标。

    由于项目中每个人的分工不同,因此不可能每个测试人员一开始就能知道自己工作的商业目标是什么,所以也不用去责怪大家。可是领导产品的测试架构师不能准确的识别或培养其他测试工程师具备识别测试重点和测试难点的能力,那么注定这个测试团队的工作不但质量保障会打折扣,而且会浪费不少组织的资源和成本。

    因为资源和时间是有限的,而完美工作的追求是无限的。因此,我们如何在有限的资源和时间下,保障基本的质量目标,并尽可能提升质量目标。就需要在分清测试重点后,优先针对测试重点目标进行系统地测试技术研究,测试技术攻关,测试资源主要投入。对于非测试重点的测试难点部分就要降低优先级,放在最后考虑。

    测试架构师的工作应该牢牢抓住真正的测试重点来开展,甚至在整个产品测试组都方向错误时,要能从商业角度帮助测试组改变观点。那么当从测试经理到普通工程师都误理解了测试重点时,测试架构师应该如何来启发他们呢?我这里就分享一个案例吧:

    在一次到产品测试组进行测试活动质量抽检时。我们问测试经理,你们产品测试目前最大的需求是什么?他说是如何进行压力测试和性能测试,希望我们测试架构师团队能在此领域多给予支持。我心里知道:他所负责的产品特性核心不是性能和压力测试,但我没有反驳他。而是继续问他下一个问题:“你觉得会让你产品未来应用时商业失败的最大担心是什么?”他想了想说:“不能对客户的生产系统产生破坏,让客户的业务中断。”“依据我们的经验,与客户生产系统交互的模块虽然是个小模块,但是在其他产品上经常出现内存泄露的故障从而破坏了生产系统。那你针对该小模块做过哪些系统地测试?有无专门进行内存泄露的测试,因为内存泄露对客户生产系统的破坏最大。”我问到。这时此测试经理才恍然大悟,这个对生产系统质量影响最大的小模块居然没有系统地进行过深入全面的测试。我这时告诉他 “你之所以开始说性能和压力测试是你的重点需求,是因为你们组里没有在性能和压力测试方面的积累,有工作开展的难处,这是困扰你的困惑。但是你的产品形态的质量不是性能或所谓压力测试来保障的,而是需要不对生产系统产生破坏。因此,你唯一能破坏生产系统的那个小模块应该是你整个产品中质量最高的模块,也应该是测试最全面最深入的模块,你的技术力量应该主要投到这个地方”。后来,针对该小模块我们进行专项内存泄露的测试,结果发现了好几个内存泄露的大bug,这些bug每一个都是会导致客户生产系统中断的杀手。

    测试架构师不是团队中专门解决测试难点的专家,而是识别测试重点,并支撑测试重点工作的专家。“区分测试重点和难点的能力”不是测试架构师独有,系统测试工程师和测试工程师一样可以具有。与第一篇“准确的商业理解力”一样,第二篇要做的是:做正确的事。


    测试架构师必须具备的第三个能力:全面多样化的产品经验!

    在开始描述我理想中的测试架构师必备素质第三篇前,我想先转载一篇来自互联网万欣的文章《好的架构师都是善良的独裁者——万欣》与大家分享,作为测试架构师必备素质第三篇的前言:

    对于任何一个软件开发人员来说,架构师都是一个令人向往的角色。就连世界首富比尔盖茨在2000年卸任公司CEO的同时,也担任了微软公司的荣誉角色“首席软件架构师”,可见“架构师”这一称谓的吸引力。架构师是公司的“金领”,有着非常高的收入,很少需要考虑生存的问题,从而有更多的精力思考关键技术问题,形成“强者愈强”的良性循环。部分优秀的开发人员在工作了一定时间后,就要开始考虑自己的未来到底向哪个方向发展。如果开发人员的沟通能力强过技术能力,在补充一定的项目管理知识后,可以向技术管理的方向转型。如果其对技术一直很感兴趣,而沟通能力也不弱,则可以试着进一步加强技术修养,以期向架构师的方向发展,最终“修成正果”。

    那么,到底什么是架构师呢?所谓的架构师,应该是一个技术企业的最高技术决策者。他主要负责公司软件产品或软件项目的技术路线与技术框架的制订。好的架构师都是善良的独裁者,具有很强的技术、良好的写作能力、良好的口头表达能力,能够在各个层次进行沟通。从开发人员到架构师的成长应该是阶梯式的,一般来讲开发人员在刚刚开始工作时只能开发简单的独立软件模块,慢慢的随着经验的增长,他开始接触一些相互之间有信息传递的模块,而后来,他会发现自己接到的开发任务已经不是一个独立的单体,这些任务由一些专门的软件部分组成,可能包含数据库,工作流引擎,消息服务等等各种功能模块,可能分布在不同的服务器上,所有的部分协同起来,完成软件功能。而这时候,体系结构的好坏将直接决定了系统的性能和可扩展性,而就在这时候,这名优秀的开发人员也开始思考架构师应该思考的问题了,或者说,他向成长为架构师的道路迈出了一大步。

    什么是架构师最具价值的技能呢?就是要了解不同的知识,做一个“杂家”或者说“博学家”。当然,如果你的数据库技术非常棒,或者你在工作流引擎方面具有不可超越的专家知识,那也是很不错的。好的架构师有好多都是从专家成长过来的。但是,这不是架构师应该做的事情,架构师应该做的是了解所有的东西,既了解技术的宏观面,又了解技术的细节。真正的架构师不仅仅要了解软件,也要了解硬件,在关键的部位使用合适的硬件来取代软件,可以成倍甚至成百倍的提高整个系统的效率。下面我将会以互联网行业对的架构师的要求为例,向大家讲解作为架构师应该具备的知识。

    互联网行业是当前最激动人心的行业之一,很多的创新都来自于这个行业,而每一个大型的网站如Google,Yahoo,Myspace等都需要解决一个非常复杂的问题,就是网站的分布式向外扩展(Scale Out)的问题。解决这个问题,需要最优秀的架构师对业务进行剖析,利用软硬件将网站进行重构,甚至根据业务研发相应的分布式技术,解决网站复杂的分布式计算的问题。

    如果你想在这个行业中成为一名架构师的话,需要至少掌握网络知识,硬件,软件,网站优化等方方面面的知识:

    网络知识

    当前的软件已经绝对不是那种仅仅跑在一台单机上的孤立应用了。不仅仅是在互联网行业,任何一个行业的软件,都要求其具有网络功能。因此,网络知识是架构师必备的知识。我们所说的网络知识,不仅仅包括TCP/IP,http等互联网行业常用的软件协议,也包括网络规划,甚至更具体的说,根据网站应用所处的地理环境进行网络规划。比如人们常说:“这世界上最远的距离不是生与死的距离,而是电信到网通的距离”(笑)如果应用是建立在中国的,就要考虑电信用户和网通用户访问网站的速度应该都比较快才可以。这时候的解决方案可能有多种,比如采用CDN(Content Delivery Network内容分发网络)使得网站的内容发布到离用户最近的服务器,又可以采用把服务器放在一些所谓的双线机房中,甚至将几种方案结合起来使用。这些都统统归到网络知识中。做为公司的架构师,要对这些知识都有所了解,才有助于在遇到问题时找到最佳答案。

    硬件知识

    了解硬件的极限,是架构师的基本功。我见过一些人,他们的眼中软件硬件都是没有极限的,需要资源就申请,系统性能下降了就买更高级的设备。然而,硬件的性能有很大一部分取决于I/O设备。而这些I/O设备依靠的都是机械物理运动,这种运动是有极限的。因此当资源访问量增大到一定的程度时,这种物理运动将成为瓶颈。比如说,在开发网站的过程中,记录访客的状态是一件很重要的事情,一般来说可以使用HttpSession来记录。而HttpSession的存储问题将是一个很大的挑战,尤其是多机共享Session时,将HttpSession存成文件并通过多机共享或网络备份的方式来解决分布式的问题是常用的方案,然而,架构师必须考虑到这种方案是有I/O极限限制的,很难扩展到超过一定规模的大型网络。同时,架构师应该了解目前最近的硬件发展是否对软件系统会造成一定的影响,比如在多核的条件下是否对软件编程有新的要求,是否会对运行在虚拟机和非虚拟机上的程序有影响等等。

    软件知识

    软件知识所包含的范围就更加广泛了。对于互联网行业来讲,架构师要了解操作系统,数据库,应用服务器等各方面的知识。比如说,如果网站使用的操作系统是 Linux,就要了解这个Linux版本的性能与局限性,比如说最多可以存放的单个文件为多大。有的数据库的数据是以单个文件来存放的,虽然我们很少见到数据库中的数据多到不能再放入一条记录的情况,但是作为架构师,请时刻注意,这种可能性是有的。而且如果你有幸在一家高速成长的互联网企业中,而你所负责的应用又没有经过优化的话,可能你会很快见到这种现象。这种现象的发生可能是由于操作系统不支持大文件的原因,也可能是数据库不支持大文件。不论如何,架构师应该在这种现象发生之前就把一切都准备好。对数据库中表的拆分是架构师应该遇到的另外一个困难。一般来说增加应用服务器比较简单而增加数据库服务器则是比较复杂的问题,如果一个站点由多个数据库支持,架构师需要考虑如何在保证数据一致的情况下,让多个数据库分担压力。有些解决方案是将数据库的读写分开,使得大多数的查询sql不经过核心数据库,而只是访问数据库的副本,但事实上,这种方式也只能维护规模不大的网站。对于大型的网站来说,把业务分散到不同的数据库中,只共享必要的数据,才是合理的提高网站扩展性的解决方案。

    其他知识

    作为系统架构师,可能还需要对分布式系统,负载均衡,网络安全,数据监控等等各方面都有所了解。不仅仅是了解理论知识,也要对相关的产品和业界进展有一定的认识。比如说做负载均衡最好的产品是那种。目前最常用的备份策略是什么,有什么缺点。如何使用缓存,如何做好日志分析等等。

    刚刚谈到的是架构师需要掌握的知识,然而,冰冻三尺非一日之寒。这个过程需要我们慢慢的积累。如果你已经进入到公司进行软件开发,请时刻关注你所开发软件的性能与可扩展性,而不仅仅局限在功能上,时刻想着任何一个简单的问题:我开发的模块如果放在多人并发的环境下会怎样,慢慢的就会有所心得。如果你还是一个在校学生,不要想着自己离架构师这个职位还很遥远。要知道,成为架构师的修炼之路是很长的,甚至可以说是终身的,因此早点进入学习状态,不断修炼自己。在学校期间学好离散数学,数据结构,操作系统,编译原理,体系结构,数据库原理等关键课程,并积极寻找机会到外面实习,增长自己的工作经验。如果有机会去到一些技术主导的公司中工作,就一定不要放弃这种机会,慢慢就会成长起来。最重要的,你会养成关注技术,勤于思考的好习惯。当有一天你发现自己对任何技术难题都可以一眼看到其本质,并能够将其分解为一个个可轻松解决的模块,你会由衷的感觉到知识给你带来的快乐,或许那一天,你已经是一个架构师了。

  • 重装系统后mantis的启动

    2017-03-22 11:09:41

    由于领导要求服务器上安装一个网页版的project,安装人员经过1个多月的奋战,终于搭建完毕,但要求重装服务器,服务器重装以后mantis怎么也启动不起来,一直提示“无法连接”,正在焦头烂额的时候灵机一动想起来之前的万能方法:重新启动easyphp集成的apche和mysql,重启后还是不行,一切OK,就是连接不上,最后定位出现此问题的原因应该是端口问题,端口未启动起来。后来又多次使用了万能方法顺利解决!
  • mantis的备份

    2017-03-21 15:51:39

    由于服务器上要搭建一个网页版的project,为了担心mantis的数据丢失,与相关人员商议要备份一下mantis,保证万无一失,虽然mantis安装在了D盘上。由于不知道备份那些文件,经过咨询、沟通以及自己琢磨,一开始直接把EasyPHP-5.3.9文件夹都备份了下来,后来经过研究发现,其实只备份data和share文件即可。等进行数据恢复时点直接替换mysql文件夹下的这两个文件夹即可。
  • office2010安装过程中出错的解决办法!

    2016-09-14 11:38:59

    误删除了office后重新安装一直提示出错,如下图:未命名.jpg 
    用过很多办法都不行,一开始以为是安装文件不完全,下载了好几个版本还是不能解决。后来估计是之前安装的有残留所以又用清理软件清理系统,如什么鲁大师,qq安全助手,还有windows installer cleaner什么清理过电脑之后再装问题依旧。今天终于搞定了!分享一下,其实微软提供了解决方法。微软为卸载office出现的问题提供了解决办法。我用完之后再安装就顺利完成。相当激动啊!希望能帮助有需要的人。以下是微软官网网址:
    http://support.microsoft.com/kb/290301/zh-cn#FixItForMe

    使用上面微软官网的清除工具卸载掉残留的程序后重新安就成功了! 
  • mantis excel格式问题解决方案

    2016-06-28 10:56:16

    在mantisbt目录下,文件excel_xml_export.php中,我们看到如下一行:
    <span style="font-size:18px;">header( 'Content-Disposition: attachment; filename="' . urlencode( file_clean_name( $t_export_title ) ) . '.xml"' ) ;</span>
    把 .xml 变更为 .xls ,如下:
    <span style="font-size:18px;">header( 'Content-Disposition: attachment; filename="' . urlencode( file_clean_name( $t_export_title ) ) . '.xls"' ) ;</span>
    这样就解决了xml格式问题,其实mantisbt系统设置为xml是非常正确的,因为xml是标准的文件数据交换模式,避免的系统编码的差异,但是windows下,还是变成xls算了
  • 软件验收测试应该如何实施

    2016-06-24 16:00:53

    http://www.51testing.com/zhuanti/acceptance.htm
  • 如何在mantis中增加需要统计的字段

    2016-06-24 15:29:25

    http://www.51testing.com/html/37/n-16337.html
  • mantis导出cvs格式为乱码解决方案

    2016-05-25 11:12:50

    找到Mantis根目录下csv_export.php,进行修改:
    添加函数:
    function expChangeCode($str)
    {
            return  mb_convert_encoding($str,"CP936","UTF-8");
    }

    然后修改:
    1、将echo $t_header 改成 echo expChangeCode($t_header);
    2、将echo  $t_value 改成 echo expChangeCode($t_value);如找不到此句话找下面的这句话
    将echo csv_escape_string($t_value); 修改成
      echo expChangeCode(csv_escape_string($t_value));
    3、将echo $t_function( $t_row[ $t_column ] )改成 echo expChangeCode($t_function( $t_row[ $t_column ] ));有的是 $t_row->$t_column,有的是echo $t_function( $t_row) ,这个没有关系的,只要把词句放置到expChangeCode里就行

    都改完毕后,试着导出一下cvs,你会发现,哈哈,我成功了。

  • 测试人员的核心价值2

    2016-05-06 15:59:28

    最近在Taobao QA Team博客上面看到一篇关于软件测试的核心价值文章。非常赞同文中作者的观点。最近在思考如何能实现这个核心价值也就是“能发现一般人发现不了的Bug”。围绕这个核心价值我的观点如下。也欢迎大家拍砖。

    • 1、测试用例设计能力。所有的测试类书籍都有测试用例的设计方法、各大论坛也有专门测试用例板块。可见测试用例的重要性。这里我也就不多说了。就一句话“测试用例是整个测试过程的基石”

     

    • 2、发现问题的敏锐目光。如果是白盒测试,看到同样一段代码,开发同学只想着正常数据输入,程序会得到正常输出;而测试工程师会想到正常的输入、异常的输入(根据业务而来的)。如果是黑盒功能测试,比如Web测试,同样看到一个页面,测试工程师是可以比开发工程师更快速地发现这个页面展示问题、功能问题的

     

    。如果是性能测试,当得到一个性能测试结果,比如响应时间是多少、TPS是多少,测试工程师应该清楚地发现该指标是否正常,性能是否符合要求,因为我们有对其他类似模块测试的经验,比开发对我们的整个系统、整个网站的总体情况更加熟悉(有的公司,开发工程师的负责的模块相对固定,面比较小,而测试工程师会测试整个系统,测试很多模块)。

     

    • 3、bug分析能力。一方面,是bug的定位能力,发现一个错误的现象,可以很快预测问题的原因出在哪里,可以在提bug时,建议开发工程师从哪个方面去查原因;另一方面,是指我们可以根据发现的一个bug,预测模块中类似bug的出现几率,可以有意对相应的功能进行测试,可以快速找出潜在的bug;还有一个是,分析一个项目或者某一阶段的bug数量、bug类型、bug趋势等,给开发工程师提出建议,希望他们从哪些地方可以在开发中就避免掉一些bug,也可分析出项目的整体质量情况和趋势,供项目经理、研发主管、测试主管、产品经理参考,方便他们分配人力物力、制定项目和产品的一些战略。

     

    • 4、良好的测试技术。这里并不是一定要和Java工程师比Java编程,也不是跟研发架构师比系统设计,我想说的是,我们关注测试相关的技术能力。当然具备基本的编程能力,应该是一个优秀测试工程师的必备条件。测试技术方面,我们可以做的更好,比如说,(以身边实际为例,我们做Web应用的测试,对于的开发是Java Web开发工程师,Web系统部署在Linux服务器上),Linux系统的使用可以比开发熟悉,通过写一些测试环境脚本,可以比开发更快速地部署Web 应用测试环境,可以比开发更熟悉写OracleSQL语句,可以比开发更熟悉地使用Firefox的一些插件来进行Web测试,可以比开发更熟悉自动化测试工具的使用(不少开发工程师认为自动化测试有些神秘),可以比开发了解更多的单元测试、性能测试的理论、工具盒方法,可以比开发更了解JVM机制和操作系统原理,在性能测试分析时也能比多数开发更有思路。

     

    • 5、良好的沟通能力。这个可能和人的性格也有关系,不过沟通能力在项目中确实非常重要。一般来说,测试工程师比开发工程师人数要少,一个测试工程师接触到的业务模块更多,和人员(包括:PD、Dev等)沟通的也更频繁,良好的沟通能力也会得到更多地锻炼。而且现实中确实有一部分开发同学是比较内向的性格,比较少和开发同事之间、PD同事之间沟通。如果我们沟通能力更强,无疑在项目中,也是会对项目起到积极的作用。

    当然,也不是说,在职业发展上,测试会比开发更好,其实我本身也不这样认为,但是,有一点,既然加入了测试这个行业,就应该努力做到优秀,努力提升自己的核心能力,也是会得到研发和测试团队的认可的。

    PS:通过如上几点慢慢修炼以提高自己的核心价值。

    原文链接:http://www.hiadmin.org/testing/testing-core-values/

  • 测试人员的核心价值2

    2016-05-06 15:33:15

    最近在Taobao QA Team博客上面看到一篇关于软件测试的核心价值的文章。非常赞同文中作者的观点。最近在思考如何能实现这个核心价值也就是“能发现一般人发现不了的Bug!”。围绕这个核心价值我的观点如下。也欢迎大家拍砖。

    • 1、测试用例设计能力。所有的测试类书籍都有测试用例的设计方法、各大论坛也有专门测试用例板块。可见测试用例的重要性。这里我也就不多说了。就一句话“测试用例是整个测试过程的基石”

     

    • 2、发现问题的敏锐目光。如果是白盒测试,看到同样一段代码,开发同学只想着正常数据输入,程序会得到正常输出;而测试工程师会想到正常的输入、异常的输入(根据业务而来的)。如果是黑盒功能测试,比如Web测试,同样看到一个页面,测试工程师是可以比开发工程师更快速地发现这个页面展示问题、功能问题的

     

    。如果是性能测试,当得到一个性能测试结果,比如响应时间是多少、TPS是多少,测试工程师应该清楚地发现该指标是否正常,性能是否符合要求,因为我们有对其他类似模块测试的经验,比开发对我们的整个系统、整个网站的总体情况更加熟悉(有的公司,开发工程师的负责的模块相对固定,面比较小,而测试工程师会测试整个系统,测试很多模块)。

     

    • 3、bug分析能力。一方面,是bug的定位能力,发现一个错误的现象,可以很快预测问题的原因出在哪里,可以在提bug时,建议开发工程师从哪个方面去查原因;另一方面,是指我们可以根据发现的一个bug,预测模块中类似bug的出现几率,可以有意对相应的功能进行测试,可以快速找出潜在的bug;还有一个是,分析一个项目或者某一阶段的bug数量、bug类型、bug趋势等,给开发工程师提出建议,希望他们从哪些地方可以在开发中就避免掉一些bug,也可分析出项目的整体质量情况和趋势,供项目经理、研发主管、测试主管、产品经理参考,方便他们分配人力物力、制定项目和产品的一些战略。

     

    • 4、良好的测试技术。这里并不是一定要和Java工程师比Java编程,也不是跟研发架构师比系统设计,我想说的是,我们关注测试相关的技术能力。当然具备基本的编程能力,应该是一个优秀测试工程师的必备条件。测试技术方面,我们可以做的更好,比如说,(以身边实际为例,我们做Web应用的测试,对于的开发是Java Web开发工程师,Web系统部署在Linux服务器上),Linux系统的使用可以比开发熟悉,通过写一些测试环境脚本,可以比开发更快速地部署Web 应用测试环境,可以比开发更熟悉写Oracle的SQL语句,可以比开发更熟悉地使用Firefox的一些插件来进行Web测试,可以比开发更熟悉自动化测试工具的使用(不少开发工程师认为自动化测试有些神秘),可以比开发了解更多的单元测试、性能测试的理论、工具盒方法,可以比开发更了解JVM机制和操作系统原理,在性能测试分析时也能比多数开发更有思路。

     

    • 5、良好的沟通能力。这个可能和人的性格也有关系,不过沟通能力在项目中确实非常重要。一般来说,测试工程师比开发工程师人数要少,一个测试工程师接触到的业务模块更多,和人员(包括:PD、Dev等)沟通的也更频繁,良好的沟通能力也会得到更多地锻炼。而且现实中确实有一部分开发同学是比较内向的性格,比较少和开发同事之间、PD同事之间沟通。如果我们沟通能力更强,无疑在项目中,也是会对项目起到积极的作用。

    当然,也不是说,在职业发展上,测试会比开发更好,其实我本身也不这样认为,但是,有一点,既然加入了测试这个行业,就应该努力做到优秀,努力提升自己的核心能力,也是会得到研发和测试团队的认可的。

    PS:通过如上几点慢慢修炼以提高自己的核心价值。

    原文链接:http://www.hiadmin.org/testing/testing-core-values/

  • 测试人员的核心价值2

    2016-05-06 15:30:43

    最近在Taobao QA Team博客上面看到一篇关于软件测试的核心价值的文章。非常赞同文中作者的观点。最近在思考如何能实现这个核心价值也就是“能发现一般人发现不了的Bug!”。围绕这个核心价值我的观点如下。也欢迎大家拍砖。

    • 1、测试用例设计能力。所有的测试类书籍都有测试用例的设计方法、各大论坛也有专门测试用例板块。可见测试用例的重要性。这里我也就不多说了。就一句话“测试用例是整个测试过程的基石”

     

    • 2、发现问题的敏锐目光。如果是白盒测试,看到同样一段代码,开发同学只想着正常数据输入,程序会得到正常输出;而测试工程师会想到正常的输入、异常的输入(根据业务而来的)。如果是黑盒功能测试,比如Web测试,同样看到一个页面,测试工程师是可以比开发工程师更快速地发现这个页面展示问题、功能问题的

     

    。如果是性能测试,当得到一个性能测试结果,比如响应时间是多少、TPS是多少,测试工程师应该清楚地发现该指标是否正常,性能是否符合要求,因为我们有对其他类似模块测试的经验,比开发对我们的整个系统、整个网站的总体情况更加熟悉(有的公司,开发工程师的负责的模块相对固定,面比较小,而测试工程师会测试整个系统,测试很多模块)。

     

    • 3、bug分析能力。一方面,是bug的定位能力,发现一个错误的现象,可以很快预测问题的原因出在哪里,可以在提bug时,建议开发工程师从哪个方面去查原因;另一方面,是指我们可以根据发现的一个bug,预测模块中类似bug的出现几率,可以有意对相应的功能进行测试,可以快速找出潜在的bug;还有一个是,分析一个项目或者某一阶段的bug数量、bug类型、bug趋势等,给开发工程师提出建议,希望他们从哪些地方可以在开发中就避免掉一些bug,也可分析出项目的整体质量情况和趋势,供项目经理、研发主管、测试主管、产品经理参考,方便他们分配人力物力、制定项目和产品的一些战略。

     

    • 4、良好的测试技术。这里并不是一定要和Java工程师比Java编程,也不是跟研发架构师比系统设计,我想说的是,我们关注测试相关的技术能力。当然具备基本的编程能力,应该是一个优秀测试工程师的必备条件。测试技术方面,我们可以做的更好,比如说,(以身边实际为例,我们做Web应用的测试,对于的开发是Java Web开发工程师,Web系统部署在Linux服务器上),Linux系统的使用可以比开发熟悉,通过写一些测试环境脚本,可以比开发更快速地部署Web 应用测试环境,可以比开发更熟悉写Oracle的SQL语句,可以比开发更熟悉地使用Firefox的一些插件来进行Web测试,可以比开发更熟悉自动化测试工具的使用(不少开发工程师认为自动化测试有些神秘),可以比开发了解更多的单元测试、性能测试的理论、工具盒方法,可以比开发更了解JVM机制和操作系统原理,在性能测试分析时也能比多数开发更有思路。

     

    • 5、良好的沟通能力。这个可能和人的性格也有关系,不过沟通能力在项目中确实非常重要。一般来说,测试工程师比开发工程师人数要少,一个测试工程师接触到的业务模块更多,和人员(包括:PD、Dev等)沟通的也更频繁,良好的沟通能力也会得到更多地锻炼。而且现实中确实有一部分开发同学是比较内向的性格,比较少和开发同事之间、PD同事之间沟通。如果我们沟通能力更强,无疑在项目中,也是会对项目起到积极的作用。

    当然,也不是说,在职业发展上,测试会比开发更好,其实我本身也不这样认为,但是,有一点,既然加入了测试这个行业,就应该努力做到优秀,努力提升自己的核心能力,也是会得到研发和测试团队的认可的。

    PS:通过如上几点慢慢修炼以提高自己的核心价值。

    原文链接:http://www.hiadmin.org/testing/testing-core-values/

  • 测试的核心价值和能力是什么?

    2016-05-05 15:53:07

    见:http://www.51testing.com/html/57/n-3708457.html
  • mantis优化

    2016-05-05 15:26:41

    1.如何在缺陷报告屏蔽掉“问题重现步骤“和”附注“框?
     修改Bug_report_page.php,将其中涉及此两块内容的代码屏蔽了,在前面加#既可

    2.优先级 显示为P,如何解决优化?

    把core里面colum_api.php里面的一段代码屏蔽
  • mantis时间显示错误解决办法

    2016-04-20 18:06:55


    登录mantis--》个人资料--》更改个人设置--时区,将城市选择中国任意城市(如:chongqing或者 hongkong)后更改设置即可。
  • 安全扫描工具AWVS

    2016-04-18 09:30:39

    Acunetix Web Vulnerability Scanner简称AWVS,是一个自动化的web应用安全测试工具,审计检查漏洞,如SQL注入,XSS(跨站点脚本攻击)和其他能被黑客利用的存在漏洞的网页应用。

    为什么要使用AWVS:


        在今天,网站的安全是容易被忽视的,黑客具备广泛的攻击手段,例如SQL注入,XSS,文件包含,目录遍历,参数篡改,认证攻击等,虽然你配置了正确的防火墙和WAF,但是这些安全防御软件仍然存在策略性的绕过。

        因此,需要您定期的扫描你的web应用,但是手动检测你所有的web应用  是否存在安全漏洞比较复杂和费时,所以您需要一款自动化的web漏洞扫描工具来检测您的web应用是否存在安全漏洞。

    AWVS课程简介:

    很多人以为AWVS比较简单,也仅仅有个扫描功能而已,其实AWVS有很多优秀的功能,本次全新的AWVS课程,

    希望能给大家新的一些知识。

    1.整站扫描
    2.站点爬行
    3.发现目标
    4.子域名扫描
    5.盲SQL注射
    6.HTTP编辑
    7.HTTP嗅探
    8.HTTP模糊测试
    9.认证测试
    10.网络服务扫描器
    11.网络服务编辑器
    12.AcuSensor技术代理
    13.........等等。

    AWVS教程下载地址:


    汇总:http://pan.baidu.com/s/1bnfFtyn


    1.AWVS - 简介                        

    2.AWVS - 安装                        
     
    3.AWVS - 站点扫描                     

    4.AWVS - 扫描结果分析                 

    5.AWVS - Site Crawler& HTTP Editor    

    6.AWVS - Target Finder & Subdomain Scanner 

    7.AWVS - Authentication Tester       

    8.AWVS - HTTP Sniffer                

    9.AWVS - HTTP Fuzzer       
              





     如文中未特别声明转载请注明出自: Acunetix Web Vulnerability Scanner 教程

  • mantis统计报表乱码问题配置方案

    2016-04-12 17:50:06

    第一步去下载Jpgraph:官网地址:http://jpgraph.net/download/ 请根据您的PHP版本选择下载版本;
    Jpgraph-3.0.7 
    JpGraph。专门提供图表的类库。它使得作图变成了一件非常简单的事情,你只需从数据库中取出相关数据,定义标题,图表类型,然后的事情就交给JpGraph,只需掌握为数不多的JpGraph内置函数(可以参照JpGraph附带例子学习),就可以画出非常炫目的图表!
    下载地址
    http://jpgraph.net/download/download.php?p=1
    第二步,下载完成后,这里很多人没说明,应该要将解压得到的SRC目录改名为jpgraph,并上传到 mantis 的 core 目录下面,这样就很清晰了;

    文件具体存放路径:C:\Program Files (x86)\EasyPHP-5.3.9\www\mantisbt-1.2.19\plugins\MantisGraph\core

    注:这里以C盘为例

    第三步,修改文件jpgraph文件夹下的src目录下的jpgraph_ttf.inc.php,将

    elseif( $aFF === FF_SIMSUN ) 语句

    更改为:

    elseif( $aFF === FF_SIMSUN ) {
    // Do Chinese conversion
    return $aTxt;

    }

    第四步,去后台安装 Mantis图表 1.0 插件;

    第五步,修改程序(可能和描述存在点小的差异,您可以自己找下,很简单的):

    文件mantis\plugins\MantisGraph\pages\config.php(记得本文件改完后用Ultraedit用ASC-II至UTF-8的转换功能保存为UTF-8格式文件,与总体字符集保持一致):
    $t_current_font_selected = array(

    'simsun' => 'SIMFANG.TTF',   //此处为添加处

    'arial' => false,
    //--------------------------------------
    Sans-serif:<br />
    <label><input type="radio" name="font" value="simsun"<?php echo print_font_checked( 'simsun' )?>/>宋体</label><br /> //增加这一行
            <label><input type="radio" name="font" value="arial"<?php echo print_font_checked( 'arial' )?>/>Arial</label><br />
    //---------------------------------------------------------------------
    文件mantis\plugins\MantisGraph\pages\config_edit.php:
    if ( plugin_config_get( 'font' ) != $f_font ) {
    switch ( $f_font ) {
       case 'simsun':    //增加这一行
                    case 'arial':
    //----------------------------------------------------------------------
    文件mantis\plugins\MantisGraph\core\graph_api.php:
    $t_font_map = array(
      'simsun' => FF_SIMSUN,   //增加这一行

     'arial' => FF_ARIAL,

    第六步,后台设置:

    (1)、管理--》管理插件--》点击“Mantis图表 1.0”名字进入设置界面,
    (2)、Graph library to use选择“Jpgraph”,Font选择“宋体”
    (3)、点击“更改配置”后再看看
    统计报表中内容,是否已如你所愿。

    还有点小小的插曲,如果提示什么simsun.ttc,simhei.ttf的问题,您就去下载这两个字体,并放到library/jpgraph/fonts/目录下面,就完美解决了。


  • mantis统计报表乱码问题配置方案

    2016-04-12 17:38:34


    第一步去下载Jpgraph:官网地址:http://jpgraph.net/download/ 请根据您的PHP版本选择下载版本;
    Jpgraph-3.0.7 
    JpGraph。专门提供图表的类库。它使得作图变成了一件非常简单的事情,你只需从数据库中取出相关数据,定义标题,图表类型,然后的事情就交给JpGraph,只需掌握为数不多的JpGraph内置函数(可以参照JpGraph附带例子学习),就可以画出非常炫目的图表!
    下载地址
    http://jpgraph.net/download/download.php?p=1
    第二步,下载完成后,这里很多人没说明,应该要将解压得到的SRC目录改名为jpgraph,并上传到 mantis 的 core 目录下面,这样就很清晰了;

    文件具体存放路径:C:\Program Files (x86)\EasyPHP-5.3.9\www\mantisbt-1.2.19\plugins\MantisGraph\core

    注:这里以C盘为例

    第三步,修改文件jpgraph文件夹下的src目录下的jpgraph_ttf.inc.php,将

    elseif( $aFF === FF_SIMSUN ) 语句

    更改为:

    elseif( $aFF === FF_SIMSUN ) {
    // Do Chinese conversion
    return $aTxt;

    }

    第四步,去后台安装 Mantis图表 1.0 插件;

    第五步,修改程序(可能和描述存在点小的差异,您可以自己找下,很简单的):

    文件mantis\plugins\MantisGraph\pages\config.php(记得本文件改完后用Ultraedit用ASC-II至UTF-8的转换功能保存为UTF-8格式文件,与总体字符集保持一致):
    $t_current_font_selected = array(

    'simsun' => 'SIMFANG.TTF',   //此处为添加处

    'arial' => false,
    //--------------------------------------
    Sans-serif:<br />
    <label><input type="radio" name="font" value="simsun"<?php echo print_font_checked( 'simsun' )?>/>宋体</label><br /> //增加这一行
            <label><input type="radio" name="font" value="arial"<?php echo print_font_checked( 'arial' )?>/>Arial</label><br />
    //---------------------------------------------------------------------
    文件mantis\plugins\MantisGraph\pages\config_edit.php:
    if ( plugin_config_get( 'font' ) != $f_font ) {
    switch ( $f_font ) {
       case 'simsun':    //增加这一行
                    case 'arial':
    //----------------------------------------------------------------------
    文件mantis\plugins\MantisGraph\core\graph_api.php:
    $t_font_map = array(
      'simsun' => FF_SIMSUN,   //增加这一行

     'arial' => FF_ARIAL,

    第六步,后台设置:

    (1)、管理--》管理插件--》点击“Mantis图表 1.0”名字进入设置界面,
    (2)、Graph library to use选择“Jpgraph”,Font选择“宋体”
    (3)、点击“更改配置”后再看看
    统计报表中内容,是否已如你所愿。

    还有点小小的插曲,如果提示什么simsun.ttc,simhei.ttf的问题,您就去下载这两个字体,并放到library/jpgraph/fonts/目录下面,就完美解决了。

431/3123>
Open Toolbar