<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[Jora_Zhang的博客]]></title><description><![CDATA[]]></description><link>https://blog.youkuaiyun.com/Jora_Zhang</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; Jora_Zhang]]></copyright><item><title><![CDATA[软件测试工程师必备软技能：结构化思维]]></title><link>https://blog.youkuaiyun.com/Jora_Zhang/article/details/124684871</link><guid>https://blog.youkuaiyun.com/Jora_Zhang/article/details/124684871</guid><author>Jora_Zhang</author><pubDate>Tue, 10 May 2022 11:46:54 +0800</pubDate><description><![CDATA[今年是入测试行业的第十年，回想在这十年职业生涯中，来来往往也接触过形形色色的人。在跟不同的人一起工作的过程中，我会经常产生一些困惑，比如：


- 面对同样复杂的测试任务，有些人可以在一天之内梳理出解决方案，而有些却要墨迹很长时间？

- 有些人能够快速的描述出工作中的问题，而有些人支支吾吾一直说不清楚？

- 有些人当被问到“你这样说的依据是什么？”“有没有具体例子”时，经常被卡壳，有些人却能摆事实讲道理有条不稳的说上一二三？




不知道你有没有经历过类似的困惑。但是随着工作的深入接触，不难发现那些能]]></description><category></category></item><item><title><![CDATA[系统测试设计思维建议]]></title><link>https://blog.youkuaiyun.com/Jora_Zhang/article/details/119596363</link><guid>https://blog.youkuaiyun.com/Jora_Zhang/article/details/119596363</guid><author>Jora_Zhang</author><pubDate>Wed, 11 Aug 2021 10:11:32 +0800</pubDate><description><![CDATA[前言

进入新的部门,首先面临的是熟悉业务以及如何设计用例，如果是新人QA的话，很可能会因为面对复杂系统复杂业务而不知如何下手，鉴于一些经验总结，给出如下的一些建议，希望对新人有帮助。

1.先宏观掌控，再细节切入

刚入行的新人，往往很容易犯的一个错误是，没有宏观的去掌控全局而一头陷入功能细节。

在我们拿到一个需求的时候，我们作为QA，首先第一个是需要认真分析需求，可以从如下几个方面思考：

产生这个需求的原因
	该需求实现的功能
	新功能对现有系统的影响
由此在我们拿到需求后，我们可以引发测试思维上.]]></description><category></category></item><item><title><![CDATA[QA测试用例规范]]></title><link>https://blog.youkuaiyun.com/Jora_Zhang/article/details/104502144</link><guid>https://blog.youkuaiyun.com/Jora_Zhang/article/details/104502144</guid><author>Jora_Zhang</author><pubDate>Tue, 25 Feb 2020 18:00:53 +0800</pubDate><description><![CDATA[按版本大小灵活的设置用例

	目前针对测试用例，有不同的呈现方式，在网易使用最多的可能有以下2种：
	Xmind脑图的形式和TC形式；
	大版本用例（业务逻辑复杂，测试点多）
	一般针对大型版本，比如校招专场重构等比较复杂的版本，我们建议2种结合着看，先用Xmind把所有的逻辑和测试点罗列，然后在tc上编写具体的用例，明确冒烟的范围等，但是该种方式有一个缺点是耗时较长，建议预留一定的编写用例的...]]></description><category></category></item><item><title><![CDATA[bug常见的错误定位方法总结]]></title><link>https://blog.youkuaiyun.com/Jora_Zhang/article/details/100109141</link><guid>https://blog.youkuaiyun.com/Jora_Zhang/article/details/100109141</guid><author>Jora_Zhang</author><pubDate>Tue, 27 Aug 2019 21:44:05 +0800</pubDate><description><![CDATA[1.如何应用常用工具定位问题：

  以测试招聘系统为例，我们常常在测试过程中发现一些问题；有些问题能够一眼看出来，并且能够准确定位到，比如兼容性问题或者页面UI问题，或者数据库数据问题；

  而有些问题我们可能需要采取一些辅助的工具去摸索和定位，其中介绍一些我们工作中经常遇到的工具，来帮助我们去定位问题：

 1.谷歌F12，开发者工具

  如果一个问题原因不太能一眼看出的话...]]></description><category></category></item><item><title><![CDATA[提BUG的正确姿势]]></title><link>https://blog.youkuaiyun.com/Jora_Zhang/article/details/100109075</link><guid>https://blog.youkuaiyun.com/Jora_Zhang/article/details/100109075</guid><author>Jora_Zhang</author><pubDate>Tue, 27 Aug 2019 21:40:17 +0800</pubDate><description><![CDATA[在软件项目中经常会有各种或大或小的Bug，更甚一点出现Error。

首先针对该bug我们需要尝试如何定位相关的问题，具体可参看：。

当我们定位出来后，又如何清晰无异议的提出Bug呢？是不是经常遇到别人给你说某某地方有个Bug，然后就没有然后了...你是什么反应？或者一个功能表面上看起来都是正常的，但他说结果错了，然后呢，然后也没然后了，你去看了一下，好像都正常，没有报错什么的，这时候你是什么反...]]></description><category></category></item><item><title><![CDATA[脱离方法论，让合作更高效TIPS]]></title><link>https://blog.youkuaiyun.com/Jora_Zhang/article/details/90769571</link><guid>https://blog.youkuaiyun.com/Jora_Zhang/article/details/90769571</guid><author>Jora_Zhang</author><pubDate>Tue, 04 Jun 2019 15:21:46 +0800</pubDate><description><![CDATA[前言

 想分享的初衷是源于在看到所在团队一年半的迭代进程中走过不少弯路，也进行过不断摸索以及推动；

 项目管理是一个不断PDCA的过程，真正找到适合团队的路需要不断的尝试，创新和实践。

 分享一些给我们带来高效合作的tips，希望对其他的团队也有一些帮助和借鉴。



选择好一款适合的项目管理工具


Case1：jira看板（BUG看板&amp;早会看板&amp;需求...]]></description><category></category></item><item><title><![CDATA[色界-私人定制]]></title><link>https://blog.youkuaiyun.com/Jora_Zhang/article/details/80915963</link><guid>https://blog.youkuaiyun.com/Jora_Zhang/article/details/80915963</guid><author>Jora_Zhang</author><pubDate>Wed, 04 Jul 2018 17:25:39 +0800</pubDate><description><![CDATA[色界-私人定制

初次交锋

因工作需要，在一年前我进行了一次转岗，进入了一个新的初创团队，当时领导希望我做的是QA&amp;项目管理的角色（代号XJ），因为是做公司内部系统，当时整个团队氛围较为松散，流程也非常的凌乱。

同时，新进来的还有如下几位，组成了代号为“ZP”的项目组：

YY：产品经理，同时也是我的直线领导

LL：后端开发负责人

ZZ：前端开发负责人

虽然产品已经运行了2年，但...]]></description><category></category></item><item><title><![CDATA[初识互联网敏捷的三大支柱]]></title><link>https://blog.youkuaiyun.com/Jora_Zhang/article/details/80388819</link><guid>https://blog.youkuaiyun.com/Jora_Zhang/article/details/80388819</guid><author>Jora_Zhang</author><pubDate>Mon, 21 May 2018 10:29:36 +0800</pubDate><description><![CDATA[我们真的在敏捷吗？“敏捷”这个词在互联网行业并不陌生，早在我刚入行的第二年，我就有幸加入一家以敏捷开发著称的公司，并且在那里得到了较早的一些敏捷的熏陶，比如每天开站会，脑暴，迭代计划会，项目回顾会等等；那时候并没有系统的去学习如何敏捷以及什么是敏捷，只是针对如雷贯耳的敏捷，每天，每周，每个季度在执行一些相关的活动。     来到xx以后，我以一个QA人员的身份投入到项目测试里面，随着时间和经验的增...]]></description><category></category></item><item><title><![CDATA[以项目管理的角色去推进过程质量]]></title><link>https://blog.youkuaiyun.com/Jora_Zhang/article/details/78674774</link><guid>https://blog.youkuaiyun.com/Jora_Zhang/article/details/78674774</guid><author>Jora_Zhang</author><pubDate>Thu, 30 Nov 2017 12:32:02 +0800</pubDate><description><![CDATA[ 一枚测试人员的苦恼：

    在刚进入新的团队，我有幸第一次与团队成员参与了某个系统的测试，但是在产品提测的时候，我作为测试人员感觉有点头疼不已，因为过程质量不容乐观，整个过程中major的bug率占比较高，经常在提测阶段出现一轮所有用例没有测完就直接被Block的情况；其次，不断的回归以及代码的变动，让我们感觉有些力不从心，从时间上来说，哪怕进行了2*12天/人的测试回归，直至上线，仍然有很...]]></description><category></category></item><item><title><![CDATA[兼容性常用的思考方向]]></title><link>https://blog.youkuaiyun.com/Jora_Zhang/article/details/78192092</link><guid>https://blog.youkuaiyun.com/Jora_Zhang/article/details/78192092</guid><author>Jora_Zhang</author><pubDate>Tue, 10 Oct 2017 14:19:06 +0800</pubDate><description><![CDATA[列了下常用的兼容性的测试方向：]]></description><category></category></item><item><title><![CDATA[接口测试的常用策略以及方法]]></title><link>https://blog.youkuaiyun.com/Jora_Zhang/article/details/78191994</link><guid>https://blog.youkuaiyun.com/Jora_Zhang/article/details/78191994</guid><author>Jora_Zhang</author><pubDate>Tue, 10 Oct 2017 14:13:51 +0800</pubDate><description><![CDATA[总结下接口测试常会涉及考虑到的方向以及常用的方法，如图：]]></description><category></category></item><item><title><![CDATA[JACOCO的xx系统实践]]></title><link>https://blog.youkuaiyun.com/Jora_Zhang/article/details/78185508</link><guid>https://blog.youkuaiyun.com/Jora_Zhang/article/details/78185508</guid><author>Jora_Zhang</author><pubDate>Mon, 09 Oct 2017 18:43:25 +0800</pubDate><description><![CDATA[原理篇
  本次尝试的初衷在于想将代码覆盖率很好的用于手工项目实践（对用例执行的一个查漏补缺以及在手工测试结束后能够通过覆盖率增加代码上线信心）；并且如果以后针该项目进行自动化接口测试，可以进行统计自动化覆盖率；鉴于项目内大部分同学还是学习的jacoco，所以本次参考了王女士的jacoco＋jenkins方面的实践，做了一些学习。
首次去看jacoco的原理还是比较复杂的，但是基本上原理的核心]]></description><category></category></item><item><title><![CDATA[XX系统功能用例整体设计思路]]></title><link>https://blog.youkuaiyun.com/Jora_Zhang/article/details/68064306</link><guid>https://blog.youkuaiyun.com/Jora_Zhang/article/details/68064306</guid><author>Jora_Zhang</author><pubDate>Wed, 29 Mar 2017 14:10:44 +0800</pubDate><description><![CDATA[进入新的部门,首先面临的是熟悉业务以及如何设计用例，如果是新人的话，因为可能会涉及到思考的角度比较多会遇到不知道如何下手开始写用例的情况，鉴于一些经验总结，可以在写用例的时候整体设计参考如下：
系统切入点
目的：将大的功能模块切小的完整的功能模块，将不好把控的全局模块一部分一部分去吞掉。
思考的角度：从需求入手，以一个大的功能点或者流程线方式入手
方法：比如Web组件，一个登录或者一个注册]]></description><category></category></item><item><title><![CDATA[我所理解的"测试"工作]]></title><link>https://blog.youkuaiyun.com/Jora_Zhang/article/details/62884198</link><guid>https://blog.youkuaiyun.com/Jora_Zhang/article/details/62884198</guid><author>Jora_Zhang</author><pubDate>Fri, 17 Mar 2017 11:19:03 +0800</pubDate><description><![CDATA[写在前沿
         入行第5年了，最近发现自己心态上起了一些微妙的变化，如果在头三年，别人问我，软件测试到底是干啥的，我肯定会回答，就是测软件上bug的，当然，你的bug测得越多越好，甚至，你在测试时候如果没有发现Bug，你会莫名的感觉焦灼甚至有点心慌，妈呀，我是不是漏测了？那时候以为，发现bug的数量和质量或许体现了测试工程师存在于这个行业的最大价值和意义。
       直到，我经]]></description><category></category></item></channel></rss>