网站上的一些好文（前辈们经验之谈），在这转一下
产品发布前的故事http://www.51testing.com/?action_viewnews_itemid_19087.html
编写测试用例方法心得体会
http://www.51testing.com/?action_viewnews_itemid_18664.html
测试人员能力的基本要求
http://www.51testing.com/?action_viewnews_itemid_18406.html
测试管理之责任
http://www.51testing.com/?action_viewnews_itemid_18681.html
有时候，优秀的开发人员是被优秀的测试人员调教出来的
http://www.51testing.com/?action_viewnews_itemid_18662.html
产品发布前的故事
产品发布前的故事不想说什么规则、流程，因为相对来说我们公司的流程还是可以的，但是总有那么多事情无法避免。对于在发布产品之前的忙碌，我希望用文字描述出来一些场景，来借鉴、备忘、总结，一切都为了将来做的更好。
项目背景：
我们这个项目周期比较长，我是半途加入的，至今即将2年了，而这之前都已经启动了快1年了。运行组织结构是开发、测试、需求三权分立，微软好像也是这样。需求给出定义，开发做出东西，测试检查质量。如果发现需求没有的则提交需求bug促使需求新建或变更原有内容，互相促进。总的来说运转还不错，当然过程中也有很多问题，解决了不少，但总还是有问题的。这里就不多说了，毕竟要说产品发布前的故事嘛 ：）
我们定下了最近的一个日期发布产品（具体日期不便透露），所以大家都比较忙碌、紧张，作为测试部分的一员，我们已经好几周晚上和周六加班了。下面就这里开始故事。
故事一,突然增加的需求。
大约还有1个月的时候，市场部突然提出此次发布的版本一定要有用户认证功能，主要是收集用户信息。似乎时间还够，但实际上对我们来说是不够的。首先我们要保证当前每周2个版本功能稳定，其次需求要重新根据要求制定详细到出错的每个提示。再有需要与其他部门配合（提供服务器数据库） 事实上因为拖延，该项需求负责人弄出的需求内容还不如开发与测试提出的疑问多，这就半个月过去了；与其他部门的配合工作也没有个总协调人来跟进，互相之前都在假设别人的工作做好的前提下进行的；除了在线认证还有离线认证，这部分的接口人和工作流程还没有确定。等等一系列问题需要解决，作为具体测试，坚决把所有可能出现的问题（包括需求没有明确的）一一提出来，这时候是没有测试用例的，你对界面规范、用户操作的习惯、当前功能的目的等等的理解就是你工作的保证。
最终结果还好，虽然还有一些不如人意的地方（有时候为了向市场或开发的部分妥协，如果坚持可能会付出更大代价），总算这个功能稳定了下来，出现的bug数量大约70多个。
故事二,与其他部门产品的矛盾。
因为公司的其他产品是依赖我们这个产品的，就是说如果我们的卖不掉，其他的跟进产品也无法生存，有时候我们的产品甚至是搭送的。 这次因为我们最新版本做出了一些标准化的东西，另一个部门解析我们文件的产品就需要我们进行保护，即我们的软件输出的文件只有他们部门的产品解析，但这样一来我们的文件就不是那么标准了。另外因为我们这次新增加的一个功能可能绕过另外一个部门的产品，这就会影响他们的销售。
可能还有一些，这些矛盾可能影响产品的发展策略，影响产品的功能变更，虽然测试可以不用管这些，但是从公司、产品、项目角度来看，值得我们思考的问题。
故事三,没有得到通知的功能变更。
上周五是计划确定版本的日子，一段时间以来各个功能都比较稳定。大家思维估计都僵硬了，简单看过基本功能后，我用了一下别组的功能，非常简单的一个操作，忽然发现多了个提示信息，与功能对应不上，马上咨询别组的负责人，她说不知道，然后找开发、需求，转了一圈原来是之前要做，但是没说这时候做，开发把这个做完认为没什么大问题就把代码放进来了，结果出问题。
测试任何东西都不要依据以前的测试结果来判断当前的状况，但是可以作为参考。不要认为任何稳定的东西就不会出错，因为我们不确定这其中发生了什么。
故事四,即将定版本时发现加密方案要改变。
接上面的，几个问题改好后，连续给了几个版本，整个产品功能表现出了一片稳定的态势，到晚上7点多的时候我们已经认为就是这个版本了，都开始谈论下周可以轻松过了，至少不用加班了。忽然接到一个邮件说，为了加强加密能力，加密锁方案变更，所有我们正在用的加密锁全部要升级。一片绝倒，早干什么去了？
抱怨是没用的，这样版本确定就拖延到了周一（7月30日），天晓得周一会发生什么。开发负责人又保证说只改这个地方对功能影响不大，保证周一没问题，我看肯定是有问题才对，因为每次他进行保证后都会出问题，这都成规律了，呵呵。
对测试来说，这些突发事情很难预测，也希望做项目的朋友能对各个方面进行考虑。发布产品并不只是发布程序软件那么简单，还包括很多东西，一切都在公司发展策略这个大棋盘上。
故事五，重新来过后出现了一些新问题？
周一的早上，我们更新了所有加密锁，如愿拿到了新版本。在冒烟测试的时候发现了很多新问题，原因是加密方案改了，但是某个解释程序挂接的还是之前的版本。开发负责人的保证果然让版本出现了问题，呵呵。一直到现在还在等待版本中......
系列故事会待续发展，直到产品发布。希望这些能给大家一点提示，一点体会，哪怕是一个新方法。
编写测试用例方法心得体会
最后一个问题了，我尽量少写些，文字太多了大家看的也累，我写的也累。嘿嘿。^_^
你对黑盒测试用例的编写的体会是什么？有什么好的版本或者标准吗？
我的体会：
１、测试用例要根据测试大纲来编写
２、测试用例也要分测试项进行归类，这样比较好分析和阅读。如：业务流程测试、安装测试、功能测试、用户友好性测试、兼容性测试、性能测试、安全性测试等等。
３、编写测试用例要考虑各种情况，精力主要集中在软件的主要业务流程和风险高的地方。能分出测试优先级别就最好了。
４、熟悉系统，对编写测试用例很有帮助。
５、即使对测试很熟悉了，在时间非常紧的时候，编写测试用例还是很有必要和好处的。
今天就想到那么些了，以后想到了在补充上了。我把我用的模板给你们粘贴一份上来，只能给你们做些参考，具体还是要看对你所在的公司适用不适用。测试项的归类我就不列举了，因为每个公司的都不太一样。
在我的个人邮箱和MSN上，通常同行都问我类似下面这样的问题：
１、一个测试用例要写到什么程度才比较好?
２、刚开始做测试的时候，你是怎么学习写测试用例的？
３、你对黑盒测试用例的编写的体会是什么？有什么好的版本或者标准吗？
对于测试用例，而我目前正在思考的问题是：怎么写出对公司有价值的测试用例，对公司来说，怎么测试才是最有价值的测试？
下面先来分析第一个问题吧：一个测试用例要写到什么程度才比较好？
这个问题，没有定语，没有说是在什么样的一个情况下，因此我这里只能就我工作中碰到的情况说说了。说起来比较长阿，大家要有耐心看才行哈。^_^
在我测试工作中，碰上的测试类型我自己划分成这么４种：项目的测试，产品的测试，产品个性化的测试，第三方验收测试。项目的测试指的是我所测试的软件是一个项目，是某一个具体用户使用的。产品的测试指的是我所测试的软件是一个通用产品，是供很多用户使用的。产品个性化测试指的是我所测试的软件是某一用户在使用产品时，提出了特殊的功能，针对这些新功能，对产品针对用户进行了个别修改。第三方验收测试大家都应该很熟悉了，这里就不需要做解释了。
对项目、产品的测试，测试的时候通常要考虑这个项目的周期和测试资源。我所在的公司，通常项目开发时间都很短４到５个月，然而测试通常都是在开发即将结束的时候才真正介入。测试就是１个人负责。因此时间和人力资源对测试来说是完成测试工作的一个风险。为此在这种情况下，我都是先熟悉系统的业务，把握重点业务和功能后，参考需求，把测试需求、测试计划和测试大纲给制定好。由于时间关系，测试用例都是先写重点的业务，也就是集成测试的测试用例。另外测试用例是根据测试大纲来的。通常都是先挑最重要的测试项和风险大的业务功能编写测试用例。
由于测试用例是本人执行，所以测试用例可以写的简单些，但是一定要开发人员能够看明白。可惜我所在的公司，都没有人来看我的测试用例。测试用例对我来说是用来提示我不要忘记了要测试哪些项。一些很有价值的ｂｕｇ通常不是在写测试用例的时候发现的，而是在测试软件的过程中，我在家睡觉前的思考和回家的路上思考出来的。这就是手动测试的魅力，有些软件的缺陷是在你使用软件的一瞬间和思考的一刹那突然发现的。所以要我回答测试用例要写到什么程度才比较好，我觉的只要你所写的测试用例在你的公司能够顺利的执行，不影响你的测试执行工作就可以了。因为测试用例写的太详细，你要花费时间和人力成本，这样出来的测试用例是最好的也是最贵的，一旦需求变更，也需要修改，这时你会发现这种详细的测试用例是最不挣钱的。测试用例写的太粗，别人看不懂，不能执行，那你要花费你的时间去解释，这就加大了测试的工作量。这也不是好的方法。
第二个问题，刚开始做测试的时候，你是怎么学习写测试用例的？
我之所以选择测试这个工作是因为：我毕业后，在第一家公司做技术支持，产品的问题很多，导致技术支持工作很辛苦、很累。为了让用户买到的产品的质量是好的，我选择了做测试，到了现在的公司。我刚做测试的时候，对测试一无所知，什么测试流程阿、文档阿都不知道，公司的测试和管理也不规范。对测试，大家都认为不就是拿个鼠标点来点去，谁都可以来做。为此，我经常上网查测试的资料，看看自己到底适合不适合做测试，测试到底是什么样的一个职业，怎么去规划自己的个人发展。其实要做好测试，真是不容易。不喜欢，真是不能做这个职业。
现在想想自己刚开始写测试用例的时候，真是好笑。就像小孩子学习写字一样。先是在网上狂搜索了一把测试用例的模板，综合了几个，就形成了。我之所以不用公司原有的测试用例模板，是因为太不适用了。还好，公司没有严格要求必须要那个模板，只要适用就行。模板找好了，可是写就费劲了。对于刚做测试的新人，看似简单的一个填表工作，要写好真是不简单。一开始写的比较不自然，有些生搬硬套，而且还很慢。没有办法，那时候没有人指导我，全靠自己自学和领悟，所以那段日子很苦阿！多写几次后，就知道和领悟了，测试用例要根据测试大纲来写，测试大纲要根据测试计划来写。测试大纲更多的是把握住测试项的方向，而测试用例是指导怎么去执行测试。还好，我有编程的经验，所以对我熟悉软件帮了一个很大的忙。熟悉了软件的业务才能去写测试用例，才能更好的去测试。这也是我一点一点的领悟出来的。说了这么多，不知道这样的回答是否是回答了这个问题。
最后一个问题了，我尽量少写些，文字太多了大家看的也累，我写的也累。嘿嘿。
你对黑盒测试用例的编写的体会是什么？有什么好的版本或者标准吗？
我的体会：
１、测试用例要根据测试大纲来编写
２、测试用例也要分测试项进行归类，这样比较好分析和阅读。如：业务流程测试、安装测试、功能测试、用户友好性测试、兼容性测试、性能测试、安全性测试等等。
３、编写测试用例要考虑各种情况，精力主要集中在软件的主要业务流程和风险高的地方。能分出测试优先级别就最好了。
４、熟悉系统，对编写测试用例很有帮助。
５、即使对测试很熟悉了，在时间非常紧的时候，编写测试用例还是很有必要和好处的。
今天就想到那么些了，以后想到了在补充上了。我把我用的模板给你们粘贴一份上来，只能给你们做些参考，具体还是要看对你所在的公司适用不适用。测试项的归类我就不列举了，因为每个公司的都不太一样。 测试人员能力的基本要求
今天在测试群中看到有关能力的交流，大有裨益。
有些人片面的认为对测试人员而言，提高能力就是能写代码，而静光关于能力的深刻理解得到了大家的赞同。
下面原文引用：
写代码，更多只算技术，未必是能力。
不要老想着写代码，如果一定要算能力，那也是很基本的能力。其它的能力实际上很多，你对计算机软硬件的了解，组成原理、电路逻辑等等各方面的知识，把这些知识归纳整理，在你平常的工作中应用出来，这就是能力。又比如，领导让你完成某个任务，你如何其了解领导真实的意图，了解任务相关的各种信息，找出其中的关键，再完成任务，这也是能力。
或者说，能力是多方面的，会写代码不代表能力就高，不会写代码不代表能力就低。只能说，对于你自己而言，你会写代码的时候，能力高于你不会写代码的时候。
看到网上很多关于测试人员应具备的素质的文章，在这里想谈谈对测试人员能力的个人看法。
正如静光所言，能力是多方面的，我们对一个人能力的评价也应该是综合评价。
能力包括基本能力、工作能力和专业技能等。
基本能力包括沟通表达能力（归纳总结能力）、文档写作能力、学习能力等；工作能力包括工作主动性、责任心、质量意识等，工作能力为以基本能力为基础，运用基本能力去解决工作上各种事情的能力；而我们经常谈到的代码编写、自动化/性能测试工具的掌握，则属于专业技能等。因此专业技能并不能代表个人的综合能力。只有把专业技能和基本技能都掌握好并运用到工作中，才能较好的提高我们的工作能力，体现出良好的综合能力。这3方面能力的关系如同木桶原理，哪方面低了这个桶的容水量都会大大折扣。在当今盛行自动化测试工具、性能测试工具学习之风，在提高专业能力的同时，请不用忽略了其它两方面的能力。
再谈谈沟通表达能力中的归纳和总结能力，我觉得这个很重要。很多人在描述事情的时候讲了一大堆都没讲到点子上，流水帐式的，听者听得一塌糊涂，根本不知道在讲什么。同样论坛上很多人在提问题的时候也是如此。这就是缺乏归纳总结能力的问题所在。能否用提炼过的、总结性的文字描述你的问题，简单扼要，抓住重点，这也是一种能力。
另外，工作能力中的质量意识经常被忽略，但我绝对这一点对测试人员非常重要。试想一下，作为一个与质量相关的测试人员，如果对自己的产出物质量要求不高，编写的文档很多错别字，提交的缺陷描述缺少了必要的步骤描述，工作任务马虎应付得过且过，对自己没有高的质量要求又如何去要求开发人员产出高质量的代码？
测试管理之责任
一个我的大学同学开始做测试管理工作了，开始带徒弟了，在管理上出现了一些问题，想知道我是怎么处理的，我觉的很有必要记录和大家分享，因此就写了。
我思考整理了一下我这个同学遇见的问题：
1.多次沟通，开发人员不承认 BUG
2.开发组不会修改 BUG
3.测试人员发现 BUG 非常少，工作效率低
我是这样回答她的：
问题一：多次沟通，开发人员不承认 BUG
对策：在测试环境再现 BUG ，把问题统计、记录成文档，直接书面提交领导，面对面的和领导以及开发负责人沟通，解决还是不解决，要解决，什么时候解决，说清楚，不解决，发布了，不要说是测试的不负责任，没有报告，不要到了后面不认账。
问题二：开发组不会修改 BUG
对策 1 ：帮助开发人员分析查找 BUG 出现的根本原因，找到后，共同协商想办法解决；这一方法只对开发和测试人员能有效沟通，测试人员能力和开发人员能力相当的情况才适用。
对策 2 ：通过网络资源寻找解决办法；再不行就把问题反馈给上一级领导或其它同事，共同寻求解决办法。
问题三：测试人员发现 BUG 非常少，工作效率低
对策：测试负责人应分析测试人员发现 BUG 少，工作效率低的原因，而不是指责测试人员，造成沟通上的不愉快；更不是测试负责人把测试任务一分，测试文档模板给了、测试文档编写例子给了、所测试的软件业务也讲解了就行了；这样就去埋怨测试新人发现这么少 BUG ；更不是期望测试新人按照参考给的例子照葫芦画瓢就行。
在这第三个问题里，让我思考很多：
面对测试管理上出现的问题，测试负责人第一时间应该更多的是问问自己：我哪个地方做错了呢？为什么会出现这样的现象呢？而不是第一时间去指责当事人和向她们发火，这是不协调的管理行为。
每个人都是从公司的新人走向老员工，都是从一个应届毕业生走向一个社会。测试新人，她们需要正确的指导。
在分配任务之前，作为师傅，首先应该了解自己带的徒弟能做什么、适合做什么、有哪些测试特长；做到恰当的分配工作。
在工作分配时，还要让徒弟能明白你让她做什么，要的东西是什么，她是否能真正明白；做到有效的沟通。
在工作过程中，多提醒徒弟，碰到问题，先思考，想出自己的方法或想不出方法都要积极的问师傅，师傅再回答问题的过程中，要引导徒弟的思维方式，培养她独立思考、解决问题的方法和思路。
在工作过程中，要时常检查、关心徒弟工作的情况，发现问题，及时进行指正，这样可以避免能否顺利完成工作的风险。
刚毕业的学生思维单纯、要教会她们为人处事，要教会她们怎么去学习，没有了师傅，自己怎么能更好的生存。
我做测试新人的时候，在领导面前，被指责得哭过一回，我至今仍然记得；我很辛苦、很认真的工作、但由于没有和领导有效的沟通，以至文档写的不好，影响产品评审。也就是在没有好师傅指导的环境里工作了两年，经历了很多事情，让我明白了好师傅应该怎么做，做一个好师傅有多么的困难。
我也知道，作为新人，面对恶劣的社会竞争，要学会生存，工作上不但要认真、要努力、而且还要积极的发问；环境很重要，人本身的心态和责任心更重要。
有时候，优秀的开发人员是被优秀的测试人员调教出来的
7月，北京的天气非常的闷热。就在这个闷热的天气，公司走了两个优秀的开发人员，高兴的是，公司把我现在所跟的这个测试项目的开发人员给留住了。经过这么长时间的测试工作，让我体会到：有时候，优秀的开发人员是被优秀的测试人员调教出来的。
记得刚到我现在的这个公司，试用期过后，我就开始测试A软件，这个软件的开发人员编写程序很细心，也很有责任感，心态态度也很好。因为，我在测试他的程序的时候，他设计的界面都很好，考虑到了用户使用起来怎么样会方便，当我发现他的程序的问题的时候，我告诉他，他第一反应是看我怎么操作出现这样的问题的，然后他回去分析程序，用程序进行跟踪，我也帮他分析，我俩配合沟通都非常的好。每次我发现的问题，他认同的会很快的改过来，他不认同的问题会向我讲解他的理由，理由非常的充分，让我很服他不修正问题的原因。我们的关系处的非常好，不像其它同行所说的测试人员是开发人员的敌人。这样一直配合到我们把A软件正式发布了。
在这期间他还帮我写些小工具，方便我测试的时候好建造数据。一年半过去了，前不久，他在做其它用户的个性化程序，他都习惯性的先给我看看，看我能否给他找出问题，让我很高兴的发现，他的程序我无法在发现问题了，我只能提一些他有时忘记的用户操作的友好性问题。嘿嘿，他现在写程序的时候已经习惯注意到我测试时经常会发现他那些问题，他经常容易忽略那些问题。因此当他提交给我测试的时候，同样是在一段时间内，同样是个小功能的程序，但是我想尽我浑身招数我都找不到程序的一个bug了，当时，心里既是开心也是心酸，原因是：我不能在测试他的程序了，因为他对我太熟悉了，已经把我测试他程序中发现的问题在他写程序的时候就解决了。他已经在我这里顺利毕业了。以后有机会做白盒测试，兴许可以发现问题。^_^ 写到这里我还在回味着我曾经发现他的那些bug我们一起分析解决的场景。
然而，测试职业的工作不可能总是碰上这么好沟通和上进的开发人员，在工作的过程中，还是会碰上不是这一类的开发人员，那是2004年的7月底，我出差去现场测试B软件了，当时见到项目组新成员，彼此都不了解，第一次见面时，其中一个开发人员见我个子很矮，比较显小，就问我：你是从北京来的？，我说：是的。接着问：你来公司多长时间了？我说：快一年了。在接着问：你来这里是测试B软件的那个功能模块啊？我说：测试B软件的所有功能。他无语。当时给我感觉很是不好。在后来的工作中，我发现他工作很不负责任，自己写的程序不自测，问题很多；写程序不按照用户的需求写、不考虑用户使用怎么方便。所以那段时间，我让他改bug简直是要和他吵架，我可不喜欢和人吵架了，因为我从来没有赢过。嘿嘿，现在想想，当时是平生第一次碰上这样的人，这样的事情。没有经验，没有很好的做好调教这种类型的开发人员的工作，主要还是没有找到很好的方法。后来这个开发人员由于工作不负责任、不好好的干活，公司就让他离开了。当时我心里在偷偷的乐啊，以后不用测试他的程序了。那时候，测试他程序的日子里有时候好怀念测试A软件的日子。
现在测试的这个C软件有两个开发人员，嘿嘿，C1开发人员非常的优秀，沟通非常的好，和A软件的那个开发人员他俩不分上下。只不过他们的性格还是有些不太一样。然而C2开发人员心态就不太好、也没有很好的责任心。当我发现他负责领域的程序出现问题的时候，我告诉他，他第一反应就是没有问题啊，然后我复现给他，然后他分析是不是他的，而不是去找程序是怎么出错的，甚至让我在写bug的时候帮他定位问题出现在那里。在测试人员紧缺和时间有限的情况下，在我看不到原代码的情况下，我怎么去定位问题出现在那个地方。我们之间沟通的时间都花费在了谈论这个bug是谁的问题，这个bug要不要改，就这样花费在了这些没有价值的地方。还好，有了上一次的教训，这次面对C2的开发人员，我心态好好多，已经能平静和正常的对待这样的现象。
现在经过请教有经验的人，思考采用的方法是：
1、把这种情况反馈给项目经理，尤其在出现争论是否是bug的时候，如果出现分歧可以让项目经理来做判断，或者找他们部长之间进行讨论，不要和他直接产生冲突，因为我们是直接面对的，冲突对日常工作不好。
2、关于他的态度我可以和他说，我们的目的是修改程序，并不是确定谁有责任的事情，告诉他，是不是他的责任，我并不关心，我只关心程序是否好用。让他感觉我们之间并没有什么利益性质的冲突。
如果有那个同行看了这篇文章后有更好的方法，可以给我回信咯。嘿嘿，小女子在这里先谢谢了。
休息一下，现在来谈谈最后关于上面这些事情我发出的感慨吧：
优秀的开发人员，当他在发现问题的时候，他会和测试人员一起探讨问题是怎么发生的，甚至测试人员也会问开发人员为什么会出现，这样可以积累双方的经验。下次当他们在进行新产品的研发和测试的时候，开发人员就会知道测试人员会发现怎样的bug，他提交程序前就会给提前改了。那样测试人员可以用更多的时间去考虑那些没有被发现的bug。这样给公司节约不少成本和风险，对开发和测试本身来说都留下了更多的时间去探索更深层的东西。
碰到不开窍的开发人员，测试就要花费很多成本在沟通上和重复验证老bug是否解决上。测试的价值就不能更进一步发挥，时间长了，测试会处于一种疲惫状态，发现的效率会降低，这样对开发和测试都不好。解决方法：只能从人力资源下手了，招人的时候要严格的考核这个人是否真正的符合这个岗位，不然的话，给公司和个人的成本损失太严重了。然而在实际工作中，对于一个开发人员的责任心往往很难一下子就了解，只有在项目中工作中逐渐的发现。
最后我告诉自己：有度量去容忍那些不能改变的事，有勇气去改变那些可能改变的事，用智慧去区别上述两类事情。
页:
[1]
