经历了多个项目，逼死人不偿命的进度，以及神一般存在的客户。让我从地狱升到了所谓的天堂，坑爹货啊！！
期货业务很难，再加上金融期货就更是折磨人的测试。

业务是新人一大难关，起码我是挣扎了三个多月从金融期货小白到现在忽悠新人的大白了。
起码你要分清楚什么是股指期货，什么是国债，什么是期权，这三大类是折腾死人不偿命的业务！！
不要以为你学会了业务就可以进行测试了，NO WAY！！你还要学会如何启动服务，表空间满了要去删，建立还原点等等 !!最主要的是要学会如何起交易！

在客户那你丫就是要把自己当成万能机器猫才行！客户只会给你升级好的前台，有时候你自己还要自己去升级，我嚓！最坑爹的是少了sp还要问客户要，环境一切有测试人员包办。
在环境出了问题，客户直接扔一个所谓的解决手册，我嚓，那货也是个奇葩货。90%环境问题由测试人员自己解决，一个项目就能把测试人员逼成神一样存在的人！！

应用上层的话，自己动手丰衣足食，滚犊子！我丫直接去混开发算了！本人做过最坑客户的事，就是删客户都不敢删的表里数据，结果居然还被我删对了，我嚓，我居然是第一个吃螃蟹的人，其他人都没这么做。所以他们也给我取了测试敢死队第一人的称号。这是一种极大风险的事，万一删错了整个数据库都会面临奔溃边缘。

不要以为我是瞎删数据，我删数据是有依据，例如我下T日单的数据，结果错误数据成交了。此时系统状态为操作状态，这时的数据是写进数据回写库中，不会把数据传入到结算库中，只要系统状态不为结算状态，我就可以到回写库中去删除已经成交的数据。当日无数据，然后切日到下一交易日即可。

此前如果成交错了，只能含泪回到还原点，本人当初不知道下错多少单，让我对下单恐惧加强啊！
报表查询，这也是坑我到不行的玩意，简单的增删改查谁不会。这里重点的是根据场景查询。
例如场景1：今日有平今仓，减免额度为1000，可减免5，预期剩余额度为995.做完这个场景，就需要到结算系统中去查询，查询到的数据是否剩余额度为995.
不同的场景有不同的查询条件，根据这些才能更好的利用查询来测试。
(⊙v⊙)嗯，唠叨到此为止，以后慢慢研究框架测试。

 

1. loadrunner controller 怎样设置连接测试环境的机器ip的呢？

2.loadrunner controller中的Available Graphs没有任何显示。

  这次编写测试报告比较特殊，完全是从不同项目的组去写测试报告。
 
  第一次觉得这次写报告有点无厘头，因为那个项目根本不是我负责，却硬被拉着写。废话不说了。

  首先到QC中看项目进行程度，也就是QC中用例执行程度。
 
  牛掰的是，用例执行相当恐怖，基本没有执行！这让我情何以堪，还让我写什么报告！最搞笑的是，让我来执行用例。

  这真的是我第一次遇到如此奇葩的事情啊！只能简单的了解项目情况，根据QC中缺陷来划分有缺陷模块的部分。这种情况下，我也只能这么做了。

  暂时不管那些修复未验证的缺陷，只能先确定new状态的缺陷。

  然后根据这些缺陷来执行用例，居然用了反推法来做这种事。
 
   之后等用例全部执行完毕后，就进行报告的编写。为什么要做这些前提，因为报告要体现出项目整体状态。

   比如用例一共有多，成功了多少，失败了多少用这些数据作出，让项目一目了然。

   如果你们遇到这种情况，会如何处理呢？

最近同时负责两个项目，模式-两边开发，两拨人（一拨人在公司开发，一拨人在广州现场开发）而测试就在公司，这样就造成现场的开发模块无法测试

所以就有以下安排，现场开发的模块每天晚上更新在公司的测试环境由测试人员测试，这样就必须划分公司模块与现场模块

测试方：我（总的负责-信贷，公司新人负责-小贷，现场新人-信贷）

一开始根据需求分析划分模块，根据两个需求文档分别编写模块进度，同时也要了解模块相应的开发人与开发进度，随时把握。
由于两个系统都是在现场所以公司与现场靠svn同步，每天必须更新文档来了解需求的变化，两个系统都在前期阶段，所以在测试的同时都只能根据经验来测试

每天都换版，但是换版没有目的的话，测试就很难掌握情况，换版是为了检验缺陷是否修复，新功能是否放到测试环境，起码你不可能在开发环境去测试，那样没有意义。同时在发现缺陷时，开发首先会在本地重现问题，如果没有这问题，那么就是测试环境换版出了问题，没有执行SQL造成模块无法进行

同样在指导新人的时候，首先让她们知道系统是干什么的，如何去看需求，系统有几大模块组成，在编写测试用例的同时，她们也进行操作。但是在这过程中往往会发现测试进度的延期：1 对系统不熟悉 2 与开发沟通少，缺陷没有及时修复（开发会负责多系统的开发）3 编写案例时间多（并不是写的越详细越好，点到为止）

与现场也需要做好沟通，避免与现场的测试人员写同样的案例模块，以及测试同样的模块，这样只会重复劳动。

暂时就总结到这，以后会补充

字段超过预期长度，系统报平台异常--其实指向那条语句，异常抛出

有时候报平台异常，是值没有塞进。比如客户有客户号，到客户查询中报平台异常-原因是客户号的值没有在数据库或者页面显示

当一个浏览器同时开两个登陆页面，会造成数据无法查询。-解决的方法只打开一个，或者浏览器设置下。

在登陆页面出现操作员表读取错误，原因是数据库链接满了，释放链接即可。

合作额度的没有减少，需要两个业务相互查看，单从页面上。没有减少是代码写入不完成，功能没有实现。

审批页面弹出一串提示：大体意思：没有拒绝流程，1是流程没有发布 2是节点错误需要根据流程图修改

最常见的小bug是字典未翻译以及申请页面有值到审批页面没有值出现，以及字段长度不够无法输入。

tab页与tab页面之间切换容易造成信息丢失，代码问题

页面没有分页，导致进入页面速度减慢。xml中修改页面显示数量

同个页面增加5条数据之后点保存，系统不动。代码问题

关于百分比，有些在100%以内，有些在100%以上，当100%以上超出，系统抛出异常。修改限制即可。

某些字段代码中删除，做业务时会抛出被删除字段名称

页面假死状态-应该是与核心通讯超时了.页面一直等待后台,造成假死现象，需要优化

某一功能数据调用另一个业务，适当加提示会减轻不必要的麻烦。比如贷前合作项目查询，担保协议与其他合作项目同时显示，担保协议合作项目不能查询对应的贷款合同，此时可以在点击页面确定时可做提示：此合作项目不支持。或者直接不显示担保协议的合作项目，因为贷前检查的合作项目与贷款申请中单独的合作项目TAB有关。

 

客户最常测出的问题：1 字典未翻译 2 起始日期与终止日期的联动性，比如有起始日期手动输入，其中终止日期是根据输入几年联动。

   今年想换个新环境，身体原因也是导致自己有换公司的想法，不知能否如愿？

     广州出差已经1个月，每天工作12个小时以上的强度，让我累的两眼冒星。但是收入与辛苦是成正比的，项目7月底会上线，项目紧张地进行。自己从头到尾就测试项目，很多东西请教开发与自己摸索，形成了自己的测试套路。短短1个月自己就发现500以上的缺陷。我相信bug还会有很多，系统接近完美才是我想要的结果。

     加油，呵呵

上周周五，测试了开发做的上传功能，在给我测试之前，开发的已经测试了。只是想看看我还能不能测试出其他问题！
给的条件很简单，做下异常测试，当然还强调了下，就给了个网页让我测试。
一时间我头脑里能想到的用例不是很多:
1上传错误文件名称 提示0Byte            

2 没上传，点击【开始上传】 提示0个
3 单个上传过的文件再上传会提示文件不允许 且显示错误原因信息
4 多个上传三个相同文件，上传成功
5 三个上传其中文件错误，提示错误文件大小0
6 复制正确路径 点击上传，上传成功
7 复制错误路径，提示文件0K
测试了下就给了他这几种结果，然后今天他告诉我，像我这样子给他一种感觉不负责了，当然他没有直说，直说间接地说可能他没有像领导的安排，也说了我的这种态度像他自己以前的态度，当然他没有恶意，他能提出来我要感谢他。
因为他从我身上看到他以前的样子，他也感觉为什么自己没有什么进步。
同样从他那里我也得到了信息，他认为的测试是能为他解决问题的，而不是给他表面的结果。
同样在前段时间跟一个在校学生交流测试，给她简单做了下软件测试，她也自学了下，感觉测试没有技术含量，不知道为什么我那时有点沉默，开发的也认为是这样，有点迷茫，在寻找自我的价值，难道在他们眼里测试是个可有可无的工作，测试只会搞表面，测试只会写写报告，那就完事了？？还是我不够努力，知识不够含量，偏要搞自动化测试才算有技术含量，哎！心有点凉。。。

    今天和家里通了电话，说出了自己的想法，没想到家里人那么赞成我的想法。对于此次计划，实施起来并非容易，这次自己创建的是虚拟服务，以人性化为宗旨。

    与我同交流的都是像我这个年纪的，个人认为创业没有年龄的限制，只有你做了没？做了失败了，亏了，又何妨。我从来没觉得自己会在绝路中，失败了，也就损失金钱。我所创建的理念是低成本，适合与个人和小型工作室。

    这次的计划的灵感，是在看动画片的时候产生。互联网上，你啥都能买到，不管是实物还是虚拟的，虚拟也无非类似与充值。但是却没有人性化的娱乐，也就是人与人的交流，服务与被服务的理念。

    计划也准备得差不多，但是需要合作人，单靠一个人的力量是不行的，不崇拜个人主义，这也是第一个难槛。但是我相信我会有办法解决的，我已经比别人走在了前面。

    年轻人晚上想想有千万条路，第二天早上就复原了继续以前的日子。而我晚上想想，第二天就编写计划，与人交流。慢慢编制自己的天罗地网。

    我们有梦想，就要去实现，不要怕吃苦，也不要怕失败，因为我明白现在只是刚刚开始，中期会有更困难的过程需要去解决。一个项目开发出来不难，难就难在长期经营。

   最近不知道受什么启发，突然间想如果自己创业了，是否能成功？我最喜欢的人是马云，他的商业模式很精湛。别人说他是疯子，他知道自己理智。

   很多时候，我看他的传记，心情没有澎湃，而是看到他的商业经营与头脑，对互联网为发展的把握。同时也激起我对创业的渴望。

   有一句话，估计很多人都听过，创意人人有，但是成功的案例却不多。我也有自己的创意，也有很多的顾虑。有时候想想失败也没什么，又不是一条绝路。如今的我为了那个创业开始写计划书，写调查表，以及业务详细说明。如果我说不想赚钱那是假的，人人都想赚钱。而我的概念中只有一个想法：今年只赚一块钱！！

   我有稳定的工作，我何必自讨苦吃，但是与生俱来不安的情绪控制着自己的思维。有时候想也许来赌一把吧！！不试过一次，就不知道自己的定位在哪里。有些人做事情喜欢谨慎，但是往往谨慎过头就把思维给搅乱。

   空有想法，不去实践，即使你说的条条是道，也不见得对人会有帮助。人在年少轻狂的日子里总会做出在成年人眼里不太现实的东西，但是一旦成功了，就是一生的骄傲！！

    最近碰到有在校学生，问我软件测试难吗？通常我都说入门不难，精通难。但是他们说入门的门槛都找不到！表示迷茫状态。。。。

    经过几天的思考，联想以前自己的经历，当时我接触软件测试也是在学校里，当时是学校请公司的人来帮我们培训，同样别人也不是老师，但是却能把我们领进门。除了看书，确实还需要有人带一下，才能找到门槛。

    自学自然是不错，但是摸索的时间会很久，没有针对性地学习。如果找到带领人，在他的指点下，或许会有针对性地成长。

    前些天，有几天在校学生问我，他们的问题我全给回答了，在这过程中，发现他们不是没看书，不是没上论坛逛，但是他们就是迷茫。其实只有有人愿意来帮他们一下，他们就能找到方向，所以我通常晚上来回答他们的问题，我不敢承认自己能有多强，起码我是在尽自己的力量来解除他们的迷茫。由此我在考虑，是不是能开设个网络学堂，让他们能有所收获，如果真可以我第一个冲进去，(*^__^*) 嘻嘻…… 设想也不错吧。

      兴趣与网游，不得不说中国的网游利润确实很大，从虚拟平台到玩家的呼应度。自己玩网游也只是半年，从刚开始纯玩，到现在想做一份调查。游戏测试，与游戏玩家其实都是差不多，不同的是角度的问题。

     或许以后会有那种想法，网游时代不在乎抄袭，只在乎玩家的数量。腾讯的炫舞，与劲舞团有什么区别？没什么区别，除了一次一次更新的衣服装备，偶尔模式的改变，几乎是没什么创新可言。

     但是却吸引大批的玩家，不惜重金在里面。炫舞的模式很有特色，不过与劲舞团没什么分别。

     有人说没劲舞好玩，有人说炫舞好玩，这些就是玩家的意见，他们关注的可玩性，舞蹈类游戏一般女生居多，所以在炫舞上装备尽显华丽。而男生则将游戏性放在技术类以及舞团上，从中就能看到对比性。做过调查，腾讯自然知道什么是能吸引人的，什么是充斥玩家的眼球。

     盈利模式也十分明显，话说回来，在现实中我还真遇到挺N的人，本身是房地产老板居然投资搞动漫，一个部门也就6个人，招来的人也是临时的，老板啥也不懂就说搞动漫，忙死的就是那帮人，设备都没齐全，果然很佩服他的胆识。

1、题目中缺少两个关键属性：项目的规模（包括需求变更规模）和测试资源

2、浅析项目规模和测试资源的影响
    这个题目最大的争议点就是在这里，如果这两个属性可以确定，相信大家的思路会清晰很多。下面偶只分两类进行简单的分析：
    A、项目规模大（需求变更规模大），测试资源少：按照CMMI 5中测试用例的编写标准来说，限定6个月的时间。测试团队需要完成测试策略/计划的拟定和评审、测试用例的设计/评审/修改、变更需求的评审/修改、新需求测试用例的设计/评审/修改...
      显而易见，剩余还有多少时间完成测试执行的跟踪和改进？即使前期能勉强跟进，偶相信在后期也只能疲于奔命，敷衍了事，什么“测试驱动开发”也只是梦中花而已。
       国内很多企业都是这样的情况，相信N多测试同仁对此是深有体会。
    B、项目规模小（需求变更规模小），测试资源多：人多好办事，只要Test Manger不是个草包，将测试工作进行有条理的细分，责任到人，在测试准备阶段选择有利于修改的测试流程（包括简易需求和测试资源变更流程以及便于变更的测试用例模板等等），在测试执行阶段，注意需求收集已经各部门以及客户之间的信息交流，还是很容易搞定的。

3、浅析正方观点的风险：
    A、如正方所说：“先把大概的用例写出来，测试的过程中，不停的添加用例。最后测试完了，用例也出来了。。”。
       什么叫大概的用例?
      用例最基本的要求就是任何测试人员都可以操作,敢问你如果写出这样缺斤少两的用例，当你临时有其他更重要的任务，然后把这块测试工作交付给其他人来做，能够保证别人肯定能看明白？
    B、又如正方提出的：用例是用来保障测试的质量，以及对测试执行的指引。
       测试用例是唯一的保障产品/测试质量的手段？没有测试用例就无法指导和跟踪测试执行了？
       当然不是，这里偶引用一个只有部分公司在用的一个概念“测试规程（test procedure）”。它是个提供详细的测试用例执行指令的文档。测试规程更注重测试的流程、方法等比较泛的内容，以方便对测试用列的编写有一个整体的概念和把握。不同的公司规范、要求和详尽程度可能不同。
       测试规程与测试用例的区别：理想化的测试用例确实需要很多测试数据集合，但是现实中对某一软件进行测试时，由于涉及的面太广，无法一一列举出所有数据，所以要根据公司的规范来做相应的调整。所以，测试规程的文档编辑量较轻，但是只适合熟练的测试人员执行，而测试用例的执行者可以使任何人。
       楼上很多同仁谈到的根据实际情况写简化用列的做法实际就是将设计测试用例变为设计测试规程，然后以测试规程来指导测试执行，提供测试质量（比如测试覆盖率）的评估。但是楼上的同仁没有对简化测试用例提出标准？如果一个测试团队里有3、4个简化标准，大家的测试用例简化的“度”都不一致，岂不乱套？
    C、2A中描述的项目情况，仍采用设计常规的测试用例的方法，那么只能有两种结果：a、披着“测试用例”的外套，却是到处缺胳膊少腿，敷衍了事，难以达到测试用例的覆盖标准；b、忙于测试用例的编写，无法在测试执行中完成测试的跟踪与改进，每天都疲于奔命，最终完成N个项目后，测试团队的水平仍然停滞不前，经常受到项目组的“鄙视”。

4、偶的观点：敏捷性测试团队才是王道，项目不同测试流程不同。针对这个项目，选择测试规程代替测试用例是明智之举。下面偶只针对与设计测试规程有关的部分提出一个简单的方案。
    A、前提：测试团队组成基本由熟练测试人员组成（就软件黑盒测试来说，加入团队半年以上的就可以叫做熟练了）。统一规范的测试流程（相信这个只要是稍微正规点的公司都有）PS：此流程只适用于2B的情况，并且可以进行裁减。有些公司是将标准流程做成checklist形式，方便项目组选择。
    B、策划：测试负责人根据项目实际情况在测试准备阶段裁减出适用于该项目的测试流程，并进行评审。其中有两点必须说明：测试执行依据采用测试用例还是测试规程或者两者皆用；测试用例（测试规程）设计的标准。
    C、变更：满足以上两个条件，如若遇到实际需求被迫变更，则修改相应测试规程，并评审即可。修改测试规程和修改测试用例在工作量上存在很大的区别，偶举一个例子：
       为了简单，用例和规程的格式就忽略了，只写具体输入步骤一部分，书写格式也比较随意。
       原需求：编辑框A中允许输入最多20个中文
       规程的输入步骤：
       只输入0~20个中文,点击确定，检查结果。备注：其中0、20必须测试
       输入21个中文，检查结果
       输入非中文字符，检查结果。备注：包括英文/特殊符号...
      混合输入中文与非中文字符，检查结果。备注：中文字符在第一位的情况必须测试
       ...
      测试用例的输入步骤：
       不输入任何字符，点击确定，检查结果
       输入10个中文字符，点击确定，检查结果
       输入20个中文字符 ，点击确定，检查结果
       输入21个中文字符，点击确定，检查结果。
       ....（不写了，N多）
       假如修改需求：编辑框A中允许输入最多20个中文或数字
       规程的输入步骤：
       输入0~21个中文或数字，点击确定，检查结果。备注：数字/中文混合输入、0/20/21位字符输入必须测试。
       ....
      假如换成测试用例，那就只有....慢慢写了~
   D、跟踪/评估：其实从4C中的例子可以看出，测试规程是可以对测试质量进行跟踪和评估的。当然还有其他很多测试质量评估方法，比如缺陷分析技术，详细信息请看http://bbs.51testing.com/thread-117496-1-2.html

小结：综上所说的问题可以使用测试规程代替测试用例来解决。

又到一年毕业时，很多打算从事软件测试行业的应届毕业生心中难免有些疑问。我们收集整理了一些关于软件测试的相关问题，做一个详细的解答。希望能给将要从事软件测试行业的毕业生以帮助和启迪，并预祝大家能找到称心的工作，在软件测试行业中施展自己的才华。

其一：到底到哪里找工作较好？

答：软件测试的话，首选上海，北京，广州。因为3个地方的IT企业最多，工作机会也越多，竞争虽大，但能强迫你去学习新的知识，不被淘汰。当然你如果能出国边工作边学习那是最好的，在国内首选这3个地方。

其二：怎么样在有限的时间里，从哪些方面把软件测试的知识给补下。

答：如果没有接受过正规培训，又想速成，个人建议在工作中独立接手一个大型的项目，具体看你做什么测试，边测试，边学习，这样会有很大的进步，毕竟学习的根本还是要把它用于实践，所以说在工作中能用到的知识是最有用。

其三：怎么样去更好地面试软件测试的职位，有哪些方法和经验请指点。

答：除了必要的面试技巧外，还要熟练掌握软件测试的流程，要知道每个步骤该做什么，怎么做，面试的时候要冷静，刚开始工作时不要太计较薪金，福利，我认为工作的前2年，尤其是测试，更应该注重学习环境和公司的品牌价值。

其四：软件测试的考官，一般都是从哪些方面来考核我们。

答：这个就广了，看你面试什么职位了，测试也分好几种，比如你面试测试经理，测试工程师，白盒测试工程师，自动化工程师等，每个职业面试的范围和侧重点是不一样。就拿我去面试别人的经验来看，首先当流程过关以后，对于面试经理的人我会着重问他关于测试管理，风险控制的问题，还会涉及到他以前的项目管理。白盒测试我会问他关于测试代码的问题，自动化我会问他QTP和LR的设置和代码，会让他具体做一下，看下结果。最普通的测试工程师，我会着重问用力的写作方法，和测试流程的问题。

       有个测试同仁让我帮她看看她的简历，看完简历后我的直觉就是“这位测试同仁两年的测试白干了”。简历是一块敲门石，但这块敲门石是什么材质的，恐怕人见人智，然而什么样的简历才能是一块金质敲门石呢，下面是我的一个些个人见解，希望能给正在或正准备寻找更好发展机会的测试同仁们有所帮助。
　
　　针对在测试行业中已经有所感悟的人－凸现项目经验优势：l         在公司允许的范围内，把你参与的项目做一个简单的介绍。比如你参与的项目的体系结构，实现技术等等。这些东西能在一定程度上体现你对测试项目了解的程度，熟知程度，从而也能体现出你的经验到底有哪些。比如，我们可以在我们的项目介绍中告诉对方我们采用的4层架构：数据库，中间件，webservice，客户端，采用的c/s模式等等，如果你觉得可以，我们列举我们的数据库采用的是什么，中间件采用的是什么等等，在简单描述了项目之后，你可以非常坦诚的告诉你所求职的公司，在这个项目中你主要负责的部分，比如主要负责哪个层次的测试，主要负责的是测试执行还是测试涉及等等。
　
      对测试能力的描述。这一块很多人喜欢一概罗列，其实在我看来这是个大忌。一概罗列通常并不能体现出一个人的能力，有些人走得是测试管理路线，他擅场的一定是流程流程方面的掌控能力，有些人是走性能测试路线，他擅场的一定是具体的某个或者某些工具的使用。千万不要把自己描述成一个无所不能的，这在我看来，往往是一个无所特长的人。
　
         如果可以，请加入一些测试方面的独特见地。我非常不喜欢的就是一旦问什么，都是书上的一套东西搬出来了，其实书本与现实有时有很大的差别，适时的表现出自己的独特见地，能证明你是一个活学活用的人，这样的人在任何一个单位都非常的吃香。
　
　　针对测试新人，切记“诚实的原则”：l         有些人可能没有吸引人眼球的学历，毕业院校，但请你大方的写出来，大胆的告诉你求职的公司，只有你认可自己，才能希望别人认可你，如果你加入这家公司，你也可以硬气的工作。学历，毕业院校可能成为你面试过程中的一点障碍，可是学历，毕业院校只能证明你的过去，并不能代表你的未来。现在大部分公司更认可一个人的能力，学历，毕业院校只是你一点出彩的地方而已。

        有些人明明对测试这个行业并不熟悉，却喜欢在简历中吹嘘自己的精通这，精通那，其实即使你获得了面试的机会，但面试的过程中，我自信你一定洋相百出，最终的结果依然是淘汰。所以，请你大大方方的告诉你求职的公司，你是一个新人，你现在的测试能力到底在一个什么样的程度，很多公司需要自己培养适合自己的测试工程师，你的坦诚能为你收获更多。

   今天逛了一天的网，总算逛到了一些感觉被人废弃的网站，例如测试联盟（网站要改版）逗留了半天，个人感觉其实内容不错的，可惜的是由于改版的关系，站内的网友不是很多。发出的帖子也是有系统来解答。论坛上的讨论都已经是2年前的了，感觉好可惜怎么改版到现在还没好呢？

   在测试联盟的首页吸引我的是各种自动化的技术，而且有实例的FLASH，只可惜太少了。有价值的东西满多的，但是个人觉得还是太少，可能是管理员没有更新的缘故吧，技术的知识没有跟上前沿。

   其中一个板块是印象最深的，是关于软考的，如果那个板块再日益更新对于要参加软考的人，意义更大。本人呢今年9月也要去参加软考，是关于四级软件测试工程师的考试。

   说到这，我突然有个想法为什么51testing中没有关于软考的模块呢？大家可以互相讨论嘛，不知道将来能否有这个模块，个人觉得这个意义不错。

   也对想要软件测试考证的网友，添加信心同时资料具备！虽然在网上关于软件测试考试的资料很少，但是每天一点的资料上传与讨论，总会形成大海！

   希望这个模块能开出来，方便与对测试考试一点头绪的网友们，共同进步！呵呵