51Testing软件测试论坛
标题: [你问我来答第8期]：软件缺陷管理交流（已结束） [打印本页]
作者: 默默巫 时间: 2011-1-11 09:56
标题: [你问我来答第8期]：软件缺陷管理交流（已结束）
本期客座专家
[attach]67819[/attach]
论坛ID：千里
姓名：罗永钦
擅长领域：测试管理、缺陷管理、热衷于研究测试度量、对项目管理也有一定经验。
现任公司：宇信易诚科技有限公司
现任职位：高级测试工程师，测试组长
工作经验：4年
项目经验：广东联通多账户系统、无线固话支撑平台、南洋保税仓系统、收入稽核保障系统、广发新网银暨手机银行。
现任51Testing论坛[软件测试新手上路]和[软件测试管理] 版版主。
各位会员可以在2月10日前以回帖的方式向客座专家提问。
（请大家围绕本期客座专家的擅长领域进行提问、探讨）
客座专家将在2月11日—2月28日为大家集中解答。
机会难得，欢迎大家踊跃提问！
作者: 千里 时间: 2011-1-11 10:01
本帖最后由 千里 于 2011-2-27 09:50 编辑
回复 5# leilei10086
| 问下如何通过缺陷的管理来输出缺陷报告从而定量定性地分析问题？ |
liuygneusoft 回复 5# leilei10086
报告中
我认为致少要含有如下信息
BUG都是什么阶段引入 的
BUG的分布密度
BUG的分类分析
BUG等级分析
一个好的测试管理工具，应该都提供相统计
通过我们的测试度量，只是我们把做实现在MY PM测试管理软件中了
同理你要是手工做，也有借鉴意义 |
/**************************************************************************************************************/
回复 13# jicheng687
罗生，您好！
我是一位即将毕业的学生，毕业后即在深圳某公司从事无线产品方面的测试工作。在大学做过一些项目，只有些许的项目经验。 不知我是不是应该先做研发几年，以后再转去作测试呢？
一毕业就做测试，会不会对未来的发展不利？
千里的回答回答：
首先恭喜你在毕业前就能找到一份软件测试工作，在就业压力较大的当今能够顺利找到一份专业相关工作实属不错。
但是有几个问题需要你自己来认真考虑：
1.你在学校做项目的时候，对程序是否有兴趣和耐心。尽管兴趣有时候是可以培养的，但如果实在不感兴趣，就不要勉强做怎么也培养不出自己兴趣来的事情。相信你会回答，有兴趣。
2.有开发基础也许更能提高对测试的理解和工作效率，但这并不是绝对必要的。开发和测试都是传承于软件工程，我们做软件测试的不能忽略对软件工程相关知识的学习。
3.一毕业就做测试对未来的发展是否不利更多取决于你的职业规划，我想你在这个时候并没有明确的职业规划。这个时候，做任何需要思考的工作都对未来有利。一般说来成功的人能把工作都做好并且把前一份工作的工作方法、思考方式甚至部分工作经验用于当前工作。
4.对于目前的工作你可能有或多或少不满意的地方，但你能否有信心找到比这更好的工作？待遇更高、前途更好、兴趣更多。
5.就你的情况来说，我的意见是这个工作值得你试一试。在尝试的过程中不断调整自己的职业规划和职业选择，我们周围有很多人一开始做测试现在还是做测试，也有很多人一开始做测试后来转做了开发，当然也有一开始做开发后来转做了测试。 |
感谢 sd土星人 的回复：
我觉得走测试这条路，不管以后是做技术还是做管理，一定的研发流程和研发技术是必须的。如果有机会做研发的话，不妨先做一段时间的研发，掌握流程和基本的技术以后转测试 是个挺不错的做法。不过研发的东西太多，要自己把握好度，自己学到什么程度 如何转，自己做好打算。
我是一毕业就做测试，在项目中也会接触到很多不同的编程的东西，这时候学习的话 虽然有点累，但针对性强，公司同事的帮助能让自己省很多麻烦。
我做测试一年，个人观点，参考下。 |
/**************************************************************************************************************/
回复 14# qinzhaohong001
| 罗老师，您好，我是计算机研究生，web自动测试用例方面有什么新的研究点？我想做这方面的研究。 |
千里 的回答：
在分工越来越细的今天，自动化测试应该也能分成多个阶段。但如何分解自动化测试流程、各阶段间如何协助呢？是我们可以思考的第一个问题。
自动化测试涉及到脚本的编辑、用例的设计、数据的准备。其中脚本的编辑需要编辑能力比较强的人才能搞定，但用例的设计和数据的准备我们做手工测试的也能够参与其中来，从而减少了自动化测试的成本。
但从web自动测试用例设计来说，个人觉得与其他用例设计没有太大区别。可以用到软件测试常见的用例设计方法，但特别推荐一下场景法用例设计方法，此方法应用范围非常广泛而且难度也是不小的。
我们也可以研究一下在需求分析阶段如何设计测试用例，通过建立use case设计test case将需求建模与用例设计结合起来，引入UML的知识将是我们研究的方向之一。
PS：在此推荐软件测试书籍《用例分析技术》，本书各大书店无售，但幸运的话可以买到二手书。 |
/**************************************************************************************************************/
回复 23# njshaoxiangdong
| 你好！不知道现在是否还允许发贴请教了？我有一个问题，就是如何提高测试组在部门中的地位，被部门经理的认可重视，以及每个月做测试方面的月报时，向领导提供哪些测试数据才能吸引领导的眼球（领导最想知道，最关心的是哪些数据呢）？ |
千里 的回答：
你的问题是很多小公司测试团队的烦恼，我觉得提高测试组在部门中的地位有两种途径：
1.部门经理对项目管理有相当的了解，知道质量以及软件测试的重要性。我的项目经理就一直和项目组申明：质量和需求是整个软件生命周期的重点。如果部门经理不能理解质量以及软件测试的重要性，则他需要重新学习，当然也可以通过引导和主动沟通的方式让其知道软件测试的重要性。
2.提升自身能力，测试工程师不可避免的要与开发交流与沟通。在测试过程中我们需要一定的开发思想，提交bug时最好能够分析一下该缺陷，与开发交流要尽可能的用软件工程术语，这些都能够给开发团队好感。当然了，与需求人员、项目经理沟通多站在对方的角度会比较好，这样至少会变得容易沟通。当然这也要求我们对需求、对项目管理有一定认识。
3.对于领导关心的，我比较喜欢这样一句话：我们一方面是为公司赚钱，另一方面还是为公司省钱。我们做测试一方面是提高软件质量，但另一方面不要加重其他同事的任务为好。
4.和领导沟通工作时多用数据说话，少于基本上完成了工作。对本模块是否没问题了，至少需要给领导如主流程准确，需求说明书已经通过测试之类的肯定回答。再则，对测试团队的表扬我一般都会谦虚的回答：这是所有同事共同努力的结果。
5.我觉得地位还体现在一个方面，测试组敢不敢向领导要求资源，比如时间不够又要保证质量，敢不敢说某些地方还存在风险。 |
/**************************************************************************************************************/
回复 24# bczy_77
QC9.0不支持IE8，我改了start_a.htm文件还是不行
文件夹, 服务端, 服务器start, htm, 文件
QC9.0安装后一直用IE6，挺好的，最近搞了个ie8，不支持了，我按网上要求改的。 |
千里 的回答：
感谢 liuygneusoft 的回复：
| QC对IE8的支持不好(我一下认为QC是一个伪BS，对浏览器的支持相当不好)，这是QC目前版本的缺陷。如果对测试管理工具没有要求的话，也可以考虑市面上同类工具，比如**，Mantis ,bugzilla,jira什么的。不过在免费测试管理软件中，**功能是最强大的，且界面也比较好。 |
/**************************************************************************************************************/
回复 31# aifeifei99
1. 测试度量如何和员工绩效挂钩？有哪几种方法？
2.如果功能测试测试结束出现系统框架造成的缺陷 如何解决？
3.按照造成缺陷的原因进行分析的时候，可以如何分类？如coding错误，ui错误，not bug等 还有什么方面，你们是怎么做的？
4.如何确定测试需求或需求覆盖的问题？ 缺陷和覆盖的如何对应？ |
千里 的回复：
1. 测试度量如何和员工绩效挂钩？有哪几种方法？
主要从三个度量指标：提交BUG的质量、BUG的提交有效率、漏出率来分析员测试人员工作的好坏。如何来得到这些度量数据，有两种方法，第一人工统计，第二测试管理软件中分析出相关数据。据了解有些测试管理工具,能出这些分析数据
补充：提交BUG的质量指的是测试人员，平均每个BUG的沟通次数；BUG的提交有效率等于项目中本人提交的有效BUG数/项目中本人提交的总BUG数；漏出率指本该发现的却被本人漏掉的BUG数/本人提交的有效BUG数。
2. 如果功能测试测试结束出现系统框架造成的缺陷 如何解决？
在这种情况下，当前只能是设计人员来修改这BUG ，主要从本次的教训中，总结一下为什么，这BUG不能尽早发现，然后下次做项目时避免再出类似问题。系统框架，一般都是和业务无业的，如果出问题，一般是出性能问题，安全问题等非功能性问题，系统架构建成后，如果能够进行评审，出这种问题的机率就小得多。
3. 按照造成缺陷的原因进行分析的时候，可以如何分类？如coding错误，ui错误，not bug等 还有什么方面，你们是怎么做的？
一般是按BUG引入的阶段分类，比如：需求分析，设计，编码，需求变更，需求新增等。然后再对各个阶段中为什么会引入这样的问题，加以分析，然后改进以防同类问题再生。也许你会按BUG的类型分类，但这分法不好，主要是不便于过程改进，用引及阶段就好得多。
4. .如何确定测试需求或需求覆盖的问题？ 缺陷和覆盖的如何对应？
对于.如何确定测试需求，首先是做功能分解，要细到每个功能点，如XXX增加，XXX删除，XXX修改，XXX查询，然后根据测试策略，决定哪些功能点要被测试。”
“缺陷和覆盖的如何对应”是指缺陷的分布吗？缺陷肯定是要和测试需求对应的（填写BUG时，就要选择对应的测试需求），且是多对一的关系，接下来，有来他们的关系，就可以做相关的统计。 |
/**************************************************************************************************************/
回复 37# 江潭素月
我来凑凑热闹
说下从事测试工作近一年来，测试工作中的问题，希望能得到千里兄的指点
一，先说下我们公司的测试流程
公司有测试人员只有2个。如果开发人员有需要测试的程序，给测试人员打个招呼，然后测试人员将源代码从服务器上迁到本机MyEclipse，然后部署运行，进行测试。如果发现有bug，提交到bug管理工具mantis中，开发人员访问mantis，修改Bug，提交代码，测试人员更新代码，复测。
不知道是否有公司是这样的测试模式，可否评价一下这样做有什么问题。
目前发现的问题就是：（1）不写测试用例，想到哪测到哪，测试很难将功能点覆盖全面（2）测试、修改Bug、复测的时间混在一块，分不清是谁的效率低。目前公司开发人员修改bug的效率就特别低，而且修改Bug引起新的Bug的产生，拖拖拉拉，测试最后不了了之，也不知道什么时候测试结束，怎么算是测试结束，也许有人会说bug都改完不就是结束了吗，但是不可能，很多Bug存在争议，测试人员认为改，开发人员认为不用改，领导也不管
二，关于什么样的问题该提交bug
网上讲测试用例时，讲到用极限值、在输入数字的地方输入字母，但是这样测出来的问题，开发人员很反感，他们不愿意修改这样的问题，只想修改正常操作出现的问题，甚至他们的主管也是这样认为，认为客户不会那样操作，让我们测试人员很苦恼。我们应该怎么界定需要提交的Bug呢，按主管说的？还是按网上讲到的方法？网上讲到的方法吧，倒是能锻炼自己，但老是看他们的白眼，认为我们是做无用的工作。 |
问题解答已经汇总在千里的个人空间：http://www.51testing.com/index.php?uid-180565-action-viewspace-itemid-228820
/**************************************************************************************************************/
回复 38# 爱吃鱼的月亮
上次问了没有人给到我满意的答案，现在继续问同样一个问题，忘理解。
作为测试部门的负责人，如何做好测试部门的发展规划？需要从哪些方面入手？ |
千里 的回复：
可以从下面几方面考虑
（1）建立完善的质量管理体系：在部门内建立起质量管理体系，不仅是要有人，更要有可实施的管理体系，比如QA质量策划过程，软件测试评审过程，总之是解决好“审”、“测”、“评”组织管理过程。
（2）团队建设：技能培训，绩效考核，开拓员工发展空间（帮助其做好职业发展规化，从一线员工中选拔测试基层管理人员）
(3) 部门发展目标：比如由原来的非赢利部门转成赢利部门，及实施办法，比如测试部门独立于开发部门，独立预算，为公司其他部门服务要是收费的；或是转型为测试外包，对外公司提供测试外包服务，对内也算一种特殊的外包
（4）部门识知管理及实现手段：主要是为了知识重用，把过去的积累，为现在所用
PS：没有得到满意的答案，我觉得可能存在三个原因的其中一个：
1.问题难度系数太高，回答的人能力不够，得不到满意的答案。
2.问题大而空，解答不是一两句话能够讲清的（说来话长）型。
3.问题提供的信息不够，同样得不到满意答案。 |
/**************************************************************************************************************/
回复 39# lqadnggw
罗先生，您好！
我是10年的毕业生，参加测试工作半年，现在在一家软件公司做ERP测试。公司只有我和另一个同事在做测试。公司的规模较小，一直以来都没有专业的测试团队，我们测试的是业务逻辑和功能方面。涉及代码的测试都是由开发人员和开发经理负责的。
我们现在的工作流程是：开发人员发布新版本----通知测试人员---测试记录bug----提交到bug管理器--开发修正BUG，返回给测试人员——回归测试——关闭。整个测试过程就是这样，bug关闭后，也就没有再管，没有对测试的结果进行分析总结。基本上我和另一个做测试的同事是没人管的，有时开例会时会叫上我们，问一些测试的情况。（平均下来一个月基本只有一次）。我们没有写测试用例，也没有测试报告、测试总结之类的文档。
我觉得这样的测试太被动了，兵来将挡水来土掩。有几个问题想咨询一下：
1.我觉得需要对这种测试流程需要改变，但不知从什么地方做起，你能给我一些意见吗？
2.公司对测试部太重视，也许是因为我们只做功能测试，怎样才能让公司重视测试？（公司规模较小，老总初次接触软件行业）
谢谢！ |
千里 的回复：
你的问题是很多在小公司测试团队里工作的烦恼，你的困境在你所在的团队可能一时半会难以解决，但也许积极面对能让你有点儿别样的收获。
1.我觉得需要对这种测试流程需要改变，但不知从什么地方做起，你能给我一些意见吗？
你觉得需要改变，说明你在测试过程中有不断的思考，这是成长的加速剂。但当不知道从什么地方做起时，建议你尊重原有的工作方法，等你具备改变的能力之时，你自然能够进行改变了。
2.公司对测试部太重视，也许是因为我们只做功能测试，怎样才能让公司重视测试？
我想反过来问几个问题：1.你们公司是做ERP测试，ERP系统除了要测试业务逻辑和功能方面，还需要做哪些方面的测试？
2.你们的开发人员进行了涉及到代码的测试，你是否知道他们从哪个角度进行的软件测试？功能性、易用性、可靠性、可维护性、可移植性、效率的哪个方面呢？
3.你能否接替开发人员进行涉及代码的测试？
4.我们没有写测试用例，也没有测试报告、测试总结之类的文档。这是一个问题，得你们两个测试员将其完善。
我认为你的工作流程基本符合小公司的现状，而且还有版本控制。其实你的主要工作是对业务逻辑和功能方面进行测试，你们公司对测试的定位也没有问题。
当然，你们公司确实也存在一些问题：
1.基本上我和另一个做测试的同事是没人管的（你们的项目经理不管你们？）这样可能导致你对需求、对系统的不熟悉，但可以把你们的困境反映出来，需要什么样的帮助罗列出来。
2.小公司不重视测试一般来说是项目组对测试的定位较低，可以通过把你在测试过程中对工作的风险，对软件质量风险以及需要的资料提出来，如果你提出的属实公司还是会重视的。比如我曾在例会上多次提出用户需求测试员看不懂，多次的反映终于得到领导的重视了。我就是通过对ERP系统的测试知道了如何做报表测试，明白了报表的生成就是一段存储过程，只要测试好了SQL存储过程就能够测试好报表。
3.我在提出要测试员接手后台测试时，项目经理回复如下：我可以让你接手这部分的测试，请问你需要多少人力？接手后能否让质量变得更有保障？同样，你编写了用例、对测试结果进行分析是件很好的事情。但你有没有时间去做？你有没有能力去做？当两个提问不再是问题时，我非常支持你做。你的领导也非常乐意你能够承担更多工作和责任的，我相信。
在小公司团队中，特别是新人。都非常的希望有一个带我们的师傅，甚至可以用渴望。 |
lqadnggw 的回复： 感谢千里对我的疑问一一进行了解答。也感谢这个论坛，在这里学到不少的东西。从一头雾水，什么都不会，到现在能安排自己的工作，从容的面对工作中出现的各种问题，很大一部分是跟这里的朋友们学习的。以后会继续努力，提高自己
做事累了的时候，会进来看看，力所能及的帮助别人，也希望在这里能得到大家的帮助。祝福论坛越办越好！ |
/**************************************************************************************************************/
回复 40# slicer115
本人工作3年，之前的公司是做金融外包的公司，现在跳槽到了一家做产品的公司，在新公司工作了将近半年了，一直有个问题困扰自己，做产品的多数都是敏捷开发敏捷测试，很多情况下需求都很模糊（因为多数情况是实施人员反馈意见，并非需求人员），这样的前提下进行开发测试，如何保证和控制质量呢？麻烦老师给些解释。QQ：215693835
以下是千里引用我和腾讯公司某测试员的聊天记录，也许可以给你一点启发。 |
千里 引用与腾讯公司某测试员的一段聊天记录：
腾讯测试员 13:37:26
一般做产品的，一般都有产品经理，他们负责规划需求。
然后就是开发，再就是测试。
腾讯测试员 13:39:20
以前在SNS的时候，我们的需求就很模糊。我们是有定期的产品评审的，每周三方花一个小时在评审产品需求。这个时候测试、开发可以提出自己的问题，产品来做解答。 然后还有就是测试用例，一般测试用例就是一份产品需求，这个时候，产品、开发参与测试用例的评审，也等于三方对需求做了一次评审了。
千里 13:41:47
就是第一次开会是三方对产品需求的评审
第二次是三方对用例的评审
第三次是测试对产品的测试了
腾讯测试员 13:42:50
还有一次是产品体验，是在开发完成开发后，踢给产品的，这时候也相当于三方对产品需求各自定义的一次碰撞。
腾讯测试员 13:44:21
产品体验属于检查开发对需求的理解是否和产品经理的理解是否一致，还有一个就是功能OK否。
需求评审需要召开会议。由产品发起
产品体验是开发提给产品的，角色就产品一个人
流程：需求评审→已评审→开发中→产品体验→测试中→OK
用例评审是测试发起的，我们这里是发邮件，当然也可以召开会议。 |
/**************************************************************************************************************/
回复 59# 819longjiayan
我想问几个问题：
1.在做提取测试功能点时，在只有需求分析文档时，我们怎样提取测试功能点，然后怎样进行根据功能点写测试用例？我正在做的这个cmmb项目时，写出的测试用例完全不能测开发出来的系统，有很大的偏差。不知道这个在前期怎么做比较好，才会减少这样的偏差，不造成测试用例不可用。
2.关于职业发展方面的问题，我想以后向测试管理方面发展，如测试组长或测试主管经理什么的，但是现在我存在一个问题，我说话什么的缺少一种气势，我想改变这种现状，不知道如何改变。我如果向测试管理方面发展，需要做学习哪些东西，需要做好哪些工作，然后我个人的素质需要达到什么要求。
请千里兄给点意见。 |
liuygneusoft 回复 59# 819longjiayan
下面是我的一点拙见
1.在做提取测试功能点时，在只有需求分析文档时，我们怎样提取测试功能点，然后怎样进行根据功能点写测试用例？我正在做的这个cmmb项目时，写出的测试用例完全不能测开发出来的系统，有很大的偏差。不知道这个在前期怎么做比较好，才会减少这样的偏差，不造成测试用例不可用。
在提取功能点时，应该是划分模块，再对各模块细分到增删改查，分好后，让项目负责人（如产品经理，研发经理，看看功能分解的合理不）这只是第一步，第二步是如何适用需求变更，当需求变更时，要有一个机制来让测试人员知道，需求发生什么变更，并修改受变更影响的用例。
2.关于职业发展方面的问题，我想以后向测试管理方面发展，如测试组长或测试主管经理什么的，但是现在我存在一个问题，我说话什么的缺少一种气势，我想改变这种现状，不知道如何改变。我如果向测试管理方面发展，需要做学习哪些东西，需要做好哪些工作，然后我个人的素质需要达到什么要求。
个人认为想做好测试经理，首先要掌握软件测试的组织管理过程，不是说知道有几个步骤，还得知道因为什么要这么做，最后多懂些软件工程，QA相关的知识，总之要掌握先进的测试理念，且上升到方法论，并在工作中能中以实施。
第二你说的缺少一种气势，我想是因为你的技术不足以服众，所以没有威望，注意我说的是技术，不是技巧。
第三：个人的品行的魅力，在工作中在以身作则，做出傍样，自认为测试经理是一个官就脱离群众是不行的。
第四还要懂得管理的艺术
举个例子，我原来做项目时，我除了制订好开发计划，跟进进度，协调各种资源外，最难的工作我来做，他们碰到什么难题，我帮他们出主意，
工作中有什么体会，收获，在周例会上我都会和他们分享，组员做得不对的，我不直接批评，都是说如果你这么做。。。。是不是更好，你现在的做法也不错，不过，将来。。。。。时，会有很大的麻烦，严重影响我们项目。。。。。我们是一个团队，我想你也不想因为个人行为，影响整个团队。因我们中间谁不经意的一个错误，严重时可能会导致之前我们加班加点的干变成白费。
现在虽然我们不在一起工作了，我们组员间一直保持联系，经常聚餐，论流做东，他们工作中碰到问题，也会来问我。 |
/**************************************************************************************************************/
回复 60# huxb_dowant
问一个问题:
如果你到一个公司做测试经理,你的下属中80%的人压根就不适合做软件测试，你会怎么处理？公司考虑所谓成本，你不能开除不合适的人。 |
liuygneusoft 回复 60# huxb_dowant
不会这么惨吧，这些人是如何招进来的？
先不追究这些不合格的是如何进公司的，这时必须要开除一些特差的，要不其他人还是老样子的混。
我原来有一个这样的经理，当时公司由我来组建一个新的研发团队，有三个人是公司其他组过来的
，另外我自己招了5个，其他组过来的，水平不行，最主要是工们态度不好，被我开了两个，开完后，告诉其他人为什么要开他们，接下来，没人敢偷懒了。技术不行，可以教，工作态度不行，只能开，当时我原想那3个都开的，其中一个拍胸脯说，让我给他机会，我给了他机会，当时，他的技术在我们组是最差的，不过一年多后，他进步是最快的，也成了我得力手下。 |
千里 回复 60# huxb_dowant
你的情况是我见到的非常惨的，不过我有一个疑问：你的下属有80%不适合做软件测试是他们对测试没兴趣还是知识结构达不到软件测试的要求？
前者毫无疑问会增加公司的成本，如果是后者可以参考liuygneusoft在61#所述。
1.培训：通过培训让下属尽快熟悉业务以及基本的测试技能。
2.让20%适合的人承担测试的核心工作，比如用例的编写、性能测试。
3.发挖对测试感兴趣的新人，着重培养。 |
/**************************************************************************************************************/
回复 73# 月亮上的小妖精
| 我想问一下，我们公司目前用Jira在作管理，但是之前没有定制过相应的工作流，现在我想把bug类和task类的工作流区分开来，问题是，如果task提交测试后，出现的当前任务的bug需要提交bug吗？如果不提交直接将task任务reopened的话，之后分析项目的bug率，以及获取buglist的时候要怎么处理这部分的bug呢？ |
千里 的回复
| 我觉得你最好把任务和BUG分开两个项目做处理，然后在BUG那个项目里面设置一个字段关联任务项目里面的ID。你如果放在一个项目里面，任务和BUG的Key是一样的，不好区分哪个是任务，哪个是BUG。 |
/**************************************************************************************************************/
回复 87# electh
罗师兄，您好，我现在从事软件测试行业刚刚四个月，每天都是跟随项目做功能测试，虽然业务上也有所了解和积累，但是自己现在越来越迷茫，不清楚未来的方向在哪里。
有人说女孩要主学业务，有人说技术过强才是硬道理，有人说管理才是生存之道，迷茫啊。
个人认为，我的塑造性很强，选定了方向就可以坚持不懈的走下去，请帮忙指指路吧。 |
ROYWONG 回复 87# electh
你的问题不好回答。令教人技术，勿叫人抉择！
“有人说女孩要主学业务，有人说技术过强才是硬道理，有人说管理才是生存之道”
业务：生存面窄。。。毕竟你不是万能的，行行业业都能清清楚楚。除非你决定了一辈子效忠你的公司！
技术：技术过强才是硬道理！ 这句话 放在什么地方都是真理！ 只是看你有没这个激情和活力。总结一个字“累”。
管理：不是管理就可以不懂技术的，只是可以不用什么都自己亲手去做而已。管理是心理的折磨！
目前国内的测试行业还很不规范。。。QC 不单单是测试软件而已，对文档，需求 都要进行审核。需求，开发，测试 三部分是平等的。 但现在有的公司甚至连需求文档都没有，售后就是需求，开发做老大的现在很是普遍。。。因此，我给你的建议是 目前，强调是目前，当下这个时刻，你应该学好你的技术，当你跟开发说话的声音逐渐加大的时候，你可以考虑转管理！ 希望你能在测试行业开阔一遍天地啊，塑造性很强的这位！呵呵。 |
liuygneusoft 回复 87# electh
刚入行，有这种困惑是正常现像，也许你可能会误认为，测试就样呀，太没技术含量了，其实不然，工作都是要从基本做起，如果只是机械式的执行测试那提升是有限的，我不知道你工作中仔细想过，软件测试的组织管理，软件测试的过程改进等，说白了， 你可以往管理上靠(就算不往这方面靠，也要有所了解呀)，当然深入学习技术也可以看你向哪方面发展，如果你想做业务专家也行，前提是你的行业一定要是大行业，比如电信，税务，银行等，这些行业，不缺技术人员，缺业务专家
当务之急是把基本功打好，比如设计用例，写高质量的BUG，学习测试的流程等。 |
/**************************************************************************************************************/
回复 91# Tinally
我是2010年的毕业生，工作已经将近8个月，感到很幸运的是找到一份很喜欢的工作，就是软件测试。而且公司的规模也很大，虽然只有短短的8个月，感到自己成长了很多！
但是现在有一个很困惑的问题是除了处理日常工作（基本都是一些bug的验证),想往技术方向上发展一下，不想一直做黑盒测试，但是现在很迷茫，希望千里大哥给点意见！
谢谢。 |
千里 的回复：
我先想问一个关于学历和能力的问题。关于这个的答案，你肯定是知道的。
首先我不知道你说的处理日常工作除了bug的验证还有什么，当然了不管是什么，你做的深度和同事的深度是否一致甚至更深？我有同事在验证bug时，经常需要找开发沟通。和开发的沟通经常用到软件工程术语，从开发那儿把数据库表全要过来研究了。
bug的验证，说实在的这个工作我没有完全明白。不知道是你的工作是别人发现的bug经过开发修复了，你去验证是否修复好了。还是你负责功能测试发现bug而且还需要验证bug是否被开发修复了这么一个完整的工作。如果你提交的bug，最后发现不是bug，你需要检讨一下。如果你提交的bug，开发还需要当面和你沟通，你需要检讨一下。检讨得多了，你的测试技术就成长了。 |
Tinally 103# 问：
谢谢千里大哥的意见！
本人自己认为是一个有目标就会坚持下去的人，当然了，做一个成功的测试人员要有足够的天分，对业务和技术的敏感度等等！
我们公司主要的项目是资金业务，8个月的时间我已经对业务做到了足够的熟悉，也自己负责过独立的项目（指的是一些新功能的验证，从项目开始提bug——开发改bug——到最后的bug验证，完完整整的一个测试流程），在这个过程是很锻炼人的，我很有体会！
但是现在让我困惑的问题是在工作过程中还是会出现一些问题，比如我验证通过的功能发到现场之后现场的测试人员还是会new bug ，我们的SE是一个很要求完美的人，这一点让她对我很不满意，其实我自己也不满意，我也不知道怎么来避免。
还有就是想有自己的一技之长，不同的公司的业务不同，所以我认为业务测试人员是很难发展的，技术方向我们公司不常用，所以提高起来似乎很难，比如说LR、QTP等。 |
千里 的回复：
| 我最近听得最多的话是：1.你为什么要做这个事情。2.你做这个事情想达到什么效果。3.你做完后有没有达到应有的效果。其实出现一些问题并不奇怪，相反还算正常。不过问题出在了哪儿呢？是业务的不熟悉，还是经验的不够？我鼓励你的是像LR、QTP这些玩意儿，有兴趣是可以了解，反正全是了解嘛。像我就了解过，不过并不懂，但对做测试还是有一定的帮助。不过你的观念需要一些改变，你把目前你的工作看得过于简单。 |
/**************************************************************************************************************/
回复 94# zhml41
| 软件缺陷管理工具有哪些呢，最近面试的时候老被问到这个问题，不是很会啊。 |
千里 的回复：
首先要搞清楚什么是缺陷管理，实际上缺陷管理就是一个bug在某个系统里面的一个处理流程，可以用OA的思想去理解。比如谁提交bug，谁又改变bug的状态，谁又关闭bug。
缺陷工具你一旦用会了一个，基本上其他的都不成问题了。最简单的有bugfree，简单又容易安装。其次还有bugzilla、mantis、JIRA是典型的缺陷管理工具。其次MY PM、TD/QC虽然是测试管理工具，但缺陷管理是其重要组成部分。 |
zhifei.xie 的答案：
1、首先缺陷的管理需要1个好的缺陷管理流程，BUG能否在预定的时间内得以修复处决于1个好的BUG管理流程
2、缺陷管理有依赖于工具的管理。工具管理有几个好处：
1）格式固定记录方便，永久保存（除非BUG管理系统崩溃了，崩溃了做了备份也无碍）
2）BUG工具管理可以方便缺陷出来流程的管理与实施（自动收发邮件功能、指派给开发人员等等
功能）
3）BUG管理工具可以自动生成缺陷分析图表（可以以图表形式显示在哪1个时间段 产生了什么严
重级别的BUG 、BUG的状态是怎样的、BUG的数目有多少、用例的执行率是多少、缺陷发现率多
少等等）
4）可以集需求管理--用例管理--BUG管理于一身（推荐QC9.0）
3、必须记录1个高质量的BUG。
什么是高质量的BUG呢，1个高质量的BUG是能够跟踪到版本号、功能模块、缺陷的重现步骤、简洁的标题、测试结果的详细说明和截图、缺陷编号 和相互关联的缺陷等这些信息。
4、以1个礼拜为周期对不同模块的缺陷数进行统计分析，供QA进行测试进度和测试效率分析提高依据。 |
/**************************************************************************************************************/
回复 95# smallfish1987
| 专家你好，我想问一下，我以前没有接触到测试需求，现在需要写一份测试需求文档，我不清楚测试需求到底是一个怎样的概念，而且也不清楚测试需求文档都应该包含哪些内容？ |
千里 的回复：
所谓的测试需求就是在项目中要测试什么，每个功能点需要从哪些方面进行测试。而测试用例是对这些功能点的具体实现，我是这么理解的。
我们在测试活动中，首先需要明确测试需求(What)，才能决定怎么测(How)，测试时间(When)，需要多少人(Who)，测试的环境是什么(Where)，测试中需要的技能、工具以及相应的背景知识，测试中可能遇到的风险等等，以上所有的内容结合起来就构成了测试计划的基本要素。而测试需求是测试计划的基础与重点。
我们公司的论坛模板中字段有：测试需求编号，测试功能点，测试功能点描述，功能点设计要求，对应的需求文档编号，需求业务规则，测试需求标识，优先级，创建日期，创建者，对应的用例编号，备注。 |
/**************************************************************************************************************/
回复 105# dandanmumu
| 专家你好，我是一名工科的女研究生，学电子的，我毕业后进了一家公司是做算法编程的，我后来发现自己对这个研发工作一点没有兴趣，我想做测试，但是同学都说测试要求学历很低，工资也没有研发高，发展不好，弄得我很困惑，我想问问专家对这个职业有何看法？ |
liuygneusoft 回复 105# dandanmumu
| 做什么工作，首先要有兴趣，如果你选择测试是被迫，那可能学不好，另外你说的测试工资低，学历要求低，并不说明测试工作没前景，只是说测试的门槛低，我认识的测试测试人员工资10K以上的占多数，他们拿高薪，一是因为他们技术好，综合能力强，当然他们的英语都不错 都在外企 另外一些在本土公司作测试主管，测试总监的工资也10K以上 我的看法是只要你在测试方面是专才，不用但心，如何成为专才呢，有机会再聊 我QQ 31931800 |
/**************************************************************************************************************/
作者: cncnily 时间: 2011-1-11 10:04
二楼
作者: 楠族开心果 时间: 2011-1-11 10:07
地板 终于看到千里的真面目了
作者: leilei10086 时间: 2011-1-11 10:58
本帖最后由 leilei10086 于 2011-1-19 17:44 编辑
问下如何通过缺陷的管理来输出缺陷报告从而定量定性地分析问题？
作者: qiguojie 时间: 2011-1-11 11:21
支持一下。
作者: hyd_bpmf 时间: 2011-1-11 11:40
支持一下
作者: ericzhou2009 时间: 2011-1-11 12:04
专家好帅哦!
作者: 愚人 时间: 2011-1-11 12:36
先占个位置……
作者: langzi1209 时间: 2011-1-11 13:09
顶老千同志兼占个位子
作者: 小北ZZ 时间: 2011-1-11 14:10
完了，沙发没了！
作者: 村上舞!舞!舞 时间: 2011-1-11 14:21
支持一下
作者: jicheng687 时间: 2011-1-11 15:28
罗生，您好！
我是一位即将毕业的学生，毕业后即在深圳某公司从事无线产品方面的测试工作。在大学做过一些项目，只有些许的项目经验。 不知我是不是应该先做研发几年，以后再转去作测试呢？
一毕业就做测试，会不会对未来的发展不利？
作者: qinzhaohong001 时间: 2011-1-11 15:59
罗老师，您好，我是计算机研究生，web自动测试用例方面有什么新的研究点？我想做这方面的研究
作者: liaoxj 时间: 2011-1-12 10:09
千里兄，不得不支持
作者: sd土星人 时间: 2011-1-12 14:18
回复 13# jicheng687
我觉得走测试这条路，不管以后是做技术还是做管理，一定的研发流程和研发技术是必须的。如果有机会做研发的话，不妨先做一段时间的研发，掌握流程和基本的技术以后转测试 是个挺不错的做法。不过研发的东西太多，要自己把握好度，自己学到什么程度 如何转，自己做好打算。
我是一毕业就做测试，在项目中也会接触到很多不同的编程的东西，这时候学习的话 虽然有点累，但针对性强，公司同事的帮助能让自己省很多麻烦。
我做测试一年，个人观点，参考下。
作者: sd土星人 时间: 2011-1-12 14:19
回复 14# qinzhaohong001
计算机研究生？！！老大，你好。web自动测试刚接触一点，用例这个没什么概念的说，同求指导
作者: sd土星人 时间: 2011-1-12 14:19
咳咳，来报到
作者: sd土星人 时间: 2011-1-12 14:20
咳咳，来报到
作者: 月上百合 时间: 2011-1-12 23:00
千里大兄弟
姐姐支持你一下。好好干
作者: 微笑流淌 时间: 2011-1-13 11:29
先支持下我们的千里版主
作者: 【稍稍】 时间: 2011-1-13 15:22
给个力，继续努力，继续奋斗....
作者: njshaoxiangdong 时间: 2011-1-13 22:40
你好！不知道现在是否还允许发贴请教了？我有一个问题，就是如何提高测试组在部门中的地位，被部门经理的认可重视，以及每个月做测试方面的月报时，向领导提供哪些测试数据才能吸引领导的眼球（领导最想知道，最关心的是哪些数据呢）？
作者: bczy_77 时间: 2011-1-14 13:21
QC9.0不支持IE8，我改了start_a.htm文件还是不行
文件夹, 服务端, 服务器start, htm, 文件
QC9.0安装后一直用IE6，挺好的，最近搞了个ie8，不支持了，我按网上要求改的
解决QC对IE7，IE8的支持现在普遍的做法是直接在服务端安装目录下搜索start_a.htm这个文件，然后在该页面搜索msie，加入ie7.0的支持|| (ua.lastIndexOf(’MSIE 7.0′) != -1)|| (ua.lastIndexOf(’MSIE 8.0′) != -1) 增加这句即可。但是现在碰到的问题是每次重启QC服务器，会发现之前的设置没有生效，这是因为我们修改的是临时文件夹下的文件配置导致的。
E:\Mercury\Quality Center\jboss\server\default\tmp\deploy\tmp3340520qcbin-exp.war\start_a.htm
E:\Mercury\Quality Center\jboss\server\default\tmp\deploy\tmp3340410sabin-exp.war\SiteAdmin.htm
请注意你的路径中的\tmp\就是指临时文件夹。
所以要一次性解决QC对ie7和ie8的支持，我们需要修改系统文件。方法如下：
1. 在服务端QC的安装目录下jboss\server\default\deploy目录下找到20qcbin.war这个war包。
2. 用winrar打开这个目录，可以看到start_a.htm这个文件。
3. 把start_a.htm这个文件copy出来修改添加|| (ua.lastIndexOf(’MSIE 7.0′) != -1)|| (ua.lastIndexOf(’MSIE 8.0′) != -1)后替换 war包中的start_a.htm文件。这里也可以直接在原文件修改。
修改配置成功后，下次重启QC服务也不会有问题。原因是重启服务器的过程中会把20qcbin.war中的内容解压出来到临时目录下的。
这里注意：改完上面的配置如果不想重启服务器，就需要把temp中的start_a.htm这个文件也增加ie7，ie8的支持。只改系统文件是需要重启QC服务的。
ps：这个方法源于在修改QC数据库的ip地址时关联想到的，修改ip地址是修改10sabin.war包中的文件。
改完后http://192.168.0.200:8080/qcbin登陆结果为
HTTP Status 404 - /qcbin
--------------------------------------------------------------------------------
type Status report
message /qcbin
description The requested resource (/qcbin) is not available.
--------------------------------------------------------------------------------
Apache Tomcat/5.5.9
麻烦给指导一下。
作者: lfei2046 时间: 2011-1-14 13:46
千里，支持下...O(∩_∩)O~
作者: msnshow 时间: 2011-1-15 10:54
支持
作者: houzeal 时间: 2011-1-15 14:52
我来捧场。。。
作者: QIYUE 时间: 2011-1-17 11:16
终于看到真人了。。。。
作者: shanglijuan1209 时间: 2011-1-18 16:33
我也来凑凑热闹····
作者: Yr-Test 时间: 2011-1-18 23:47
你好！不知道现在是否还允许发贴请教了？我有一个问题，就是如何提高测试组在部门中的地位，被部门经理的认 ...
njshaoxiangdong 发表于 2011-1-13 22:40 
测试数据领导未必会看。邻导最关心的就是发出去的产品质量如何。另一方面若要提升组的声望必须让组内的技术水平超越其它组，同时把该组的技术进行推广，分享给其它组。这样本组的在部门的地位自然就上升了。
作者: aifeifei99 时间: 2011-1-19 10:12
1. 测试度量如何和员工绩效挂钩？有哪几种方法？
2.如果功能测试测试结束出现系统框架造成的缺陷 如何解决？
3.按照造成缺陷的原因进行分析的时候，可以如何分类？如coding错误，ui错误，not bug等 还有什么方面，你们是怎么做的？
4.如何确定测试需求或需求覆盖的问题？ 缺陷和覆盖的如何对应？
作者: seeon1 时间: 2011-1-19 13:54
给老乡加油~~~
作者: liuygneusoft 时间: 2011-1-19 14:40
回复 24# bczy_77
QC对IE8的支持不好(我一下认为QC是一个伪BS，对浏览器的支持相当不好)，这是QC目前版本的缺陷。如果对测试管理工具没有要求的话，也可以考虑市面上同类工具
作者: hvein 时间: 2011-1-19 15:48
原来你就是千里啊，之前接到过宇信易诚的面试通知呢？后来接到offer了就没去！要知道应该去试试的，呵呵
作者: 小北ZZ 时间: 2011-1-19 16:33
回复 20# 月上百合
哈哈，好久不见百合呀，最近工作怎么样呀？
作者: liuygneusoft 时间: 2011-1-19 22:31
回复 5# leilei10086
报告中
我认为致少要含有如下信息
BUG都是什么阶段引入 的
BUG的分布密度
BUG的分类分析
BUG等级分析
一个好的测试管理工具，应该都提供相统计
如附件所示[attach]68009[/attach]
你可以用admin登录密码也是admin
然后进到度量分析的测试分析下面
选择项目进选**就能看到相关数据
通过我们的测试度量，只是我们把做实现在**测试管理软件中了
同理你要是手工做，也有借鉴意义
作者: 江潭素月 时间: 2011-1-20 14:18
本帖最后由 江潭素月 于 2011-1-20 14:20 编辑
我来凑凑热闹
说下从事测试工作近一年来，测试工作中的问题，希望能得到千里兄的指点
一，先说下我们公司的测试流程
公司有测试人员只有2个。如果开发人员有需要测试的程序，给测试人员打个招呼，然后测试人员将源代码从服务器上迁到本机MyEclipse，然后部署运行，进行测试。如果发现有bug，提交到bug管理工具mantis中，开发人员访问mantis，修改Bug，提交代码，测试人员更新代码，复测。
不知道是否有公司是这样的测试模式，可否评价一下这样做有什么问题。
目前发现的问题就是：（1）不写测试用例，想到哪测到哪，测试很难将功能点覆盖全面（2）测试、修改Bug、复测的时间混在一块，分不清是谁的效率低。目前公司开发人员修改bug的效率就特别低，而且修改Bug引起新的Bug的产生，拖拖拉拉，测试最后不了了之，也不知道什么时候测试结束，怎么算是测试结束，也许有人会说bug都改完不就是结束了吗，但是不可能，很多Bug存在争议，测试人员认为改，开发人员认为不用改，领导也不管
二，关于什么样的问题该提交bug
网上讲测试用例时，讲到用极限值、在输入数字的地方输入字母，但是这样测出来的问题，开发人员很反感，他们不愿意修改这样的问题，只想修改正常操作出现的问题，甚至他们的主管也是这样认为，认为客户不会那样操作，让我们测试人员很苦恼。我们应该怎么界定需要提交的Bug呢，按主管说的？还是按网上讲到的方法？网上讲到的方法吧，倒是能锻炼自己，但老是看他们的白眼，认为我们是做无用的工作
作者: 爱吃鱼的月亮 时间: 2011-1-20 16:28
上次问了没有人给到我满意的答案，现在继续问同样一个问题，忘理解。
作为测试部门的负责人，如何做好测试部门的发展规划？需要从哪些方面入手？
作者: lqadnggw 时间: 2011-1-21 10:37
回复 1# 默默巫
罗先生，您好！
我是10年的毕业生，参加测试工作半年，现在在一家软件公司做ERP测试。公司只有我和另一个同事在做测试。公司的规模较小，一直以来都没有专业的测试团队，我们测试的是业务逻辑和功能方面。涉及代码的测试都是由开发人员和开发经理负责的。
我们现在的工作流程是：开发人员发布新版本----通知测试人员---测试记录bug----提交到bug管理器--开发修正BUG，返回给测试人员——回归测试——关闭。整个测试过程就是这样，bug关闭后，也就没有再管，没有对测试的结果进行分析总结。基本上我和另一个做测试的同事是没人管的，有时开例会时会叫上我们，问一些测试的情况。（平均下来一个月基本只有一次）。我们没有写测试用例，也没有测试报告、测试总结之类的文档。
我觉得这样的测试太被动了，兵来将挡水来土掩。有几个问题想咨询一下：
1.我觉得需要对这种测试流程需要改变，但不知从什么地方做起，你能给我一些意见吗？
2.公司对测试部太重视，也许是因为我们只做功能测试，怎样才能让公司重视测试？（公司规模较小，老总初次接触软件行业）
谢谢！
作者: slicer115 时间: 2011-1-21 11:05
本人工作3年，之前的公司是做金融外包的公司，现在跳槽到了一家做产品的公司，在新公司工作了将近半年了，一直有个问题困扰自己，做产品的多数都是敏捷开发敏捷测试，很多情况下需求都很模糊（因为多数情况是实施人员反馈意见，并非需求人员），这样的前提下进行开发测试，如何保证和控制质量呢？麻烦老师给些解释。QQ：215693835
作者: 西贝 时间: 2011-1-21 14:55
好面熟呀
作者: manow111 时间: 2011-1-21 15:03
支持!文采不错哦!
作者: smile665 时间: 2011-1-22 00:31
支持千里~ 从我注册51testing 就看到千里 应该蛮牛的
作者: liuygneusoft 时间: 2011-1-22 18:11
回复 37# 江潭素月
(1)测试流程存在的风险
没有版本管理，会导致其他工作会很乱，另外会增加测试人员工作量，测试人员的工作变成没计划，没管理。比如新发现的BUG，无法去分析，是不是修改带来的，还是这BUG是原来就有，只是没测试到。为什么会增加测试人员工作量呢，开发人员只要改代码，就会提交到SVN中，频繁的这么更改，测试轮次就会乱，且容易助长发人员，自己修改后不测试，就扔到测试人员手中，在我们公司这就private build ，测试人员不能没完没了的给开发人员帮private build测试，只有特殊情况下才用，在你们这，感觉就是在做private build的测试，不是系统测试。
（2）不写测试用例，想到哪测到哪，测试很难将功能点覆盖全面
先做好测试需求分解，细化到每个功能点。可以一边测试一边补充测试用例，具做法是，每写一个BUG，就现写一个用例并与这BUG关联。另外最后是，写BUG时，BUG要和测试需求关联。
（3）测试、修改Bug、复测的时间混在一块，分不清是谁的效率低
根源还是没有版本管理，有了版本管理，从BUG的发现版本和修复版本，就可以看出来了，有了版本管理，开发人员也不可以改一个BUG就发一个新版本。发版本最多一周发一次；关于存在分歧的BUG，一定是要由开发经理来仲裁的。
另外，还可以从测试管理工具中，统计分析提交BUG曲线，和未修复的BUG曲线中，分析效率，如果说发现的BUG越来越少，但未修复的BUG越来越多，说明是开发人员修复BUG太慢。
(4) 关于什么样的问题该提交bug
我的意见是，测试时你要有测试策略，针对系统的不同阶段，要有不同的测试重点。系统功能都还没稳定时，不要去做可用性测试，这时你提交那些，可用性问题，开发人员会有情绪的。在实现要求的功能后，再考虑，非功能性需求。比如还在集成测试时，你提校验的问题，开发人员会认为你尽提些无关重要的BUG 。
我的一些笨见，详聊加我QQ 31931880
作者: 江潭素月 时间: 2011-1-25 09:11
回复 44# liuygneusoft
首先，谢谢您的指点，仔细分析了我们工作中的问题。但问题是我们该如何改进呢？
（1）没有版本控制
之前给公司提过建议，让开发人员打包，将包部署到测试环境下测试不同版本的包。但是这样会增加开发人员的工作量，所以建议没有被采纳。我用什么来说服他们呢，因为做这个工作主要是对我们测试人员有帮助的，而我们测试人员地位很低，所以这样的建议很难被采纳
（2）关于写测试用例
首先我们公司没有需求分析这回事。都是在一个系统的基础上进行修改。客户首先拿到我们已经有的系统，然后指出哪里不合适，开发人员就改，改完再让客户看，再提哪里不合适。这样，需求变更很多次，开发人员做完一部分，想给客户更新了，然后就让我们测测，我们无法预知他们什么时候要测试，要测试什么样的功能
（3）关于bug的提交
您说开始测试时，对于像可用性、易用性这样的Bug暂时不要提交。难道发现问题先记到本子上吗？我们是不管发现什么bug都提，怕以后忘记，然后把这些不重要的bug优先级设置为低
作者: marysnow 时间: 2011-1-25 09:43
支持一下千里 ！
作者: 千里 时间: 2011-1-25 13:36
原来你就是千里啊，之前接到过宇信易诚的面试通知呢？后来接到offer了就没去！要知道应该去试试的，呵呵
hvein 发表于 2011-1-19 15:48
幸好你没来，这个公司加班很严重，非常辛苦。
作者: 千里 时间: 2011-1-25 13:51
回复 45# 江潭素月
（1）没有版本控制
之前给公司提过建议，让开发人员打包，将包部署到测试环境下测试不同版本的包。但是这样会增加开发人员的工作量，所以建议没有被采纳。我用什么来说服他们呢，因为做这个工作主要是对我们测试人员有帮助的，而我们测试人员地位很低，所以这样的建议很难被采纳
--如果你了解配置管理的话，你应该会知道这是项目管理的工作，也就是说这是项目经理的活儿。不过这部分工作量确实非常大，我上一家公司也曾碰到了版本控制的麻烦，项目经理也在考虑版本管理，最终因为没人可做这部分工作而一直搁置着
（2）关于写测试用例
首先我们公司没有需求分析这回事。都是在一个系统的基础上进行修改。客户首先拿到我们已经有的系统，然后指出哪里不合适，开发人员就改，改完再让客户看，再提哪里不合适。这样，需求变更很多次，开发人员做完一部分，想给客户更新了，然后就让我们测测，我们无法预知他们什么时候要测试，要测试什么样的功能
--这部分工作首先要认可是测试员本份的工作，如果是不会做可以理解。这里提到的需求分析是将用户需求抽出成功能点，然后再将功能点具体实现为用例。当然你的问题也存在一定程度上面的需求环节不规范性，只要对客户意见和测试员bug进行了统一管理，情况会相对好一点。
（3）关于bug的提交
您说开始测试时，对于像可用性、易用性这样的Bug暂时不要提交。难道发现问题先记到本子上吗？我们是不管发现什么bug都提，怕以后忘记，然后把这些不重要的bug优先级设置为低
--这里涉及到一个缺陷不修复的问题，哪些缺陷可以不修复呢？其实还是能够找到相关答案的：1.确实不是bug的；2.修复的代价太大；3.缺陷本身并不严重，但修复需要很长时间；4.缺陷被暴露的概率非常小，就算被暴露了影响也不是致命的。
作者: 江潭素月 时间: 2011-1-25 15:01
回复 48# 千里
我们往往在这样的bug上存在争议：出现频率很高，只要运行程序就出现。但不是致命的bug，不影响功能，修改起来也很比较容易。不属于你说的那几种不修改Bug中的任何一种
例如打开一个页面时，只是在左下角报脚本错误，功能照样用。像这样的Bug，开发人员心情好就改，心情不好就不改。
我们测试人员对于这种bug是倾向于修改的
作者: 江潭素月 时间: 2011-1-25 15:03
回复 48# 千里
关于写测试用例，你说“对客户意见和测试员bug进行了统一管理，情况会好一点”，没有听明白，在我们这种情况下，该如何做测试用例的工作
作者: medoraemon 时间: 2011-1-25 16:00
你这张照片貌似还是我们一起去陈家祠的时候照的。。。哈哈。。。占个位置好好听讲
作者: 千里 时间: 2011-1-25 20:10
你这张照片貌似还是我们一起去陈家祠的时候照的。。。哈哈。。。占个位置好好听讲
medoraemon 发表于 2011-1-25 16:00
这都被你看出来了，好神奇啊。测试的眼力真是不错，佩服之。
作者: 千里 时间: 2011-1-25 20:13
回复 49# 江潭素月
对于问题较严重，开发都很随意的，领导也不管的。我的做法是把问题以邮件的形式反馈给开发并邮件抄送一份给领导。同时把要不要修改的权力交给领导并暗示他，如果是谁说的不改以后出了问题谁来承担责任。
作者: 千里 时间: 2011-1-25 20:18
回复 千里
关于写测试用例，你说“对客户意见和测试员bug进行了统一管理，情况会好一点”，没有听 ...
江潭素月 发表于 2011-1-25 15:03
你跟我上一份工作的情况相同，最明显的区别是我有一个好的项目经理。我是说客户意见也是bug，和你在实际测试过程发现的bug是相同的，可以统一管理。
我们公司也是开发更新程序，但我们建立了一个群。凡是开发有任何更新必须发群消息出来，测试员对更新情况做出记录。这样在一定程度上做到了版本控制，另外程序能不能提交给客户由测试员说了算（尽可能的）。
作者: liuygneusoft 时间: 2011-1-25 22:11
本帖最后由 liuygneusoft 于 2011-1-25 22:27 编辑
回复 45# 江潭素月
千里的回答很好，很明确，我再补充一点
（1）没有版本控制
之前给公司提过建议，让开发人员打包，将包部署到测试环境下测试不同版本的包。但是这样会增加开发人员的工作量，所以建议没有被采纳。我用什么来说服他们呢，因为做这个工作主要是对我们测试人员有帮助的，而我们测试人员地位很低，所以这样的建议很难被采纳
是如千里所说，这工是配置管理员的专职工作，当前公司没配备，那我们只能从己有人员中想办法，谁最合适呢，当然是研发经理，也不要求正经八百的做配置管理，只是控制一下，什么时候发布下一个版本到测试人员那，或是定在每周五（多长时间，可以视情况定）发布一个新版本测试，这样也促使开发人员尽量在下一版本前修改优先级高的BUG，这对开发经理的要求也不高，我原来就这么做过，我来发布版本，连测试服务环境都是我来配置，我们是分布式环境。那测试人员如何去说服呢，首先不要让人地位低，其次要和经研发经理讲清当前做法产生的严重后果，你可以发邮件建议，并抄送他的领导，我上面的改进办法也不复杂吧，只是控制一下发布时间，把时间点当成版本。
当然我这是权宜之计，不过比没有强。
心态上也不要自认为测试人员地位很低，当然要证明测试人员存在的价值，就是用业绩和专业来反映；按我的理解，测试比开发人员更操心，开发人员，只管实现自己的业务，而不用向测试人员那样，通盘考虑。开发除了复杂系统外，MIS系统都是增删改查，很简单的。
（2）关于写测试用例
首先我们公司没有需求分析这回事。都是在一个系统的基础上进行修改。客户首先拿到我们已经有的系统，然后指出哪里不合适，开发人员就改，改完再让客户看，再提哪里不合适。这样，需求变更很多次，开发人员做完一部分，想给客户更新了，然后就让我们测测，我们无法预知他们什么时候要测试，要测试什么样的功能
这时候不要再强调需求分析了，因为没有。我上一回贴说的测试需求分解，和开发的需求分析并不是一个东西，它只是定义了要测试的功能点有哪些。在没需求分析的情况下，你甚至可以，按功能菜单划化测试需求，并细化到增删改查功能点，这么做是为了好理清功能点，然后再这个测试需求分解的基本上来组纷测试，为什么我说要写用例呢，且是一边测试一边写，既然进入测试了，系统也有了，随着测试的深入，测试人员头脑中一定有业务，那为什么不一边测试一边补充呢，且有了那个测试需求分解，写用例时也能把握住，而不是随意的。这么做的好处是，可以慢慢积累用例，如中间有测试人员离职，也还有用例在.呵呵这是也是在做MYPM时加入BUG和用例关联功能的初衷。在测试期间，有空时（如，等待开发人员提交下一版本），也可以安排一定的时间写用例。
（3）关于bug的提交
您说开始测试时，对于像可用性、易用性这样的Bug暂时不要提交。难道发现问题先记到本子上吗？我们是不管发现什么bug都提，怕以后忘记，然后把这些不重要的bug优先级设置为低
关于这个，我前面没讲清，不同的时间段内，测试肯定是要有侧重点的，可用性的BUG不是说不能提，如果不经意发现的当然要提，我是想表达，不要有意去执行可用性测试，在功能没实现前。要不开发的会误认为，你发现不了什么BUG，尽提些不重要的。目标是把有限的时间，用到当前紧要的事情上。
作者: 江潭素月 时间: 2011-1-26 11:35
谢谢千里和liuygneusoft ，帮我分析了问题还提供了解决方案。我已经将问题和改进办法进行了归纳，写了2010年测试总结。再次谢谢你们
作者: liujianigali 时间: 2011-1-26 15:37
我来捧场的，千里，进步很快，我的进步比较小了，以后要以你为榜样！
作者: carolyeaph 时间: 2011-1-26 21:28
老师，你好！
请问如何保证测试达到要求的需求覆盖率？ 谢谢。
作者: 819longjiayan 时间: 2011-1-27 11:02
终于见到了千里的真面目了。支持支持。。。
我想问几个问题：
1.在做提取测试功能点时，在只有需求分析文档时，我们怎样提取测试功能点，然后怎样进行根据功能点写测试用例？我正在做的这个cmmb项目时，写出的测试用例完全不能测开发出来的系统，有很大的偏差。不知道这个在前期怎么做比较好，才会减少这样的偏差，不造成测试用例不可用。
2.关于职业发展方面的问题，我想以后向测试管理方面发展，如测试组长或测试主管经理什么的，但是现在我存在一个问题，我说话什么的缺少一种气势，我想改变这种现状，不知道如何改变。我如果向测试管理方面发展，需要做学习哪些东西，需要做好哪些工作，然后我个人的素质需要达到什么要求。
请千里兄给点意见
作者: huxb_dowant 时间: 2011-1-27 15:33
问一个问题:
如果你到一个公司做测试经理,你的下属中80%的人压根就不适合做软件测试，你会怎么处理？公司考虑所谓成本，你不能开除不合适的人。
作者: liuygneusoft 时间: 2011-1-28 11:38
回复 60# huxb_dowant
不会这么惨吧，这些人是如何招进来的？
先不追究这些不合格的是如何进公司的，这时必须要开除一些特差的，要不其他人还是老样子的混。
我原来有一个这样的经理，当时公司由我来组建一个新的研发团队，有三个人是公司其他组过来的
，另外我自己招了5个，其他组过来的，水平不行，最主要是工们态度不好，被我开了两个，开完后，告诉其他人为什么要开他们，接下来，没人敢偷懒了。技术不行，可以教，工作态度不行，只能开，当时我原想那3个都开的，其中一个拍胸脯说，让我给他机会，我给了他机会，当时，他的技术在我们组是最差的，不过一年多后，他进步是最快的，也成了我得力手下。
作者: liuygneusoft 时间: 2011-1-28 11:57
本帖最后由 liuygneusoft 于 2011-2-5 18:54 编辑
回复 59# 819longjiayan
下面是我的一点拙见
1.在做提取测试功能点时，在只有需求分析文档时，我们怎样提取测试功能点，然后怎样进行根据功能点写测试用例？我正在做的这个cmmb项目时，写出的测试用例完全不能测开发出来的系统，有很大的偏
差。不知道这个在前期怎么做比较好，才会减少这样的偏差，不造成测试用例不可用。
在提取功能点时，应该是划分模块，再对各模块细分到增删改查，分好后，让项目负责人（如产品经理，研发经理，看看功能分解的合理不）这只是第一步，第二步是如何适用需求变更，当需求变更时，要有一个机制来让测试人员知道，需求发生什么变更，并修改受变更影响的用例。
2.关于职业发展方面的问题，我想以后向测试管理方面发展，如测试组长或测试主管经理什么的，但是现在我存在一个问题，我说话什么的缺少一种气势，我想改变这种现状，不知道如何改变。我如果向测试管理方面发展，需要做学习哪些东西，需要做好哪些工作，然后我个人的素质需要达到什么要求。
个人认为想做好测试经理，首先要掌握软件测试的组织管理过程，不是说知道有几个步骤，还得知道因为什么要这么做，最后多懂些软件工程，QA相关的知识，总之要掌握先进的测试理念，且上升到方法论，并在工作中能中以实施。
第二你说的缺少一种气势，我想是因为你的技术不足以服众，所以没有威望，注意我说的是技术，不是技巧。
第三：个人的品行的魅力，在工作中在以身作则，做出傍样，自认为测试经理是一个官就脱离群众是不行的。
第四还要懂得管理的艺术
举个例子，我原来做项目时，我除了制订好开发计划，跟进进度，协调各种资源外，最难的工作我来做，他们碰到什么难题，我帮他们出主意，
工作中有什么体会，收获，在周例会上我都会和他们分享，组员做得不对的，我不直接批评，都是说如果你这么做。。。。是不是更好，你现在的做法也不错，不过，将来。。。。。时，会有很大的麻烦，严重影响我们项目。。。。。我们是一个团队，我想你也不想因为个人行为，影响整个团队。因我们中间谁不经意的一个错误，严重时可能会导致之前我们加班加点的干变成白费。
现在虽然我们不在一起工作了，我们组员间一直保持联系，经常聚餐，论流做东，他们工作中碰到问题，也会来问我。
作者: zwb131442 时间: 2011-1-28 13:47
顶
作者: 819longjiayan 时间: 2011-2-5 17:21
回复 62# liuygneusoft
非常感谢你的回复~~受益了。。
作者: xuhongningtest 时间: 2011-2-7 00:44
哈哈，今天见到罗专家如此给力，该赞一下！
顶~~~~~~~~~~~~~~
作者: xuhongningtest 时间: 2011-2-7 00:46
哇塞，罗先生如此给力！赞一个！
顶n个～～～～～～～～～～～～
作者: xuhongningtest 时间: 2011-2-7 00:47
大家新年快乐！兔年给力！
作者: chengning 时间: 2011-2-9 10:31
我承认我是来看千里的真面目的
作者: 千里 时间: 2011-2-9 13:42
问一个问题:
如果你到一个公司做测试经理,你的下属中80%的人压根就不适合做软件测试，你会怎么处理？公司考 ...
huxb_dowant 发表于 2011-1-27 15:33
你的情况是我见到的非常惨的，不过我有一个疑问：你的下属有80%不适合做软件测试是他们对测试没兴趣还是知识结构达不到软件测试的要求？
前者毫无疑问会增加公司的成本，如果是后者可以参考liuygneusoft在61#所述。
1.培训：通过培训让下属尽快熟悉业务以及基本的测试技能。
2.让20%适合的人承担测试的核心工作，比如用例的编写、性能测试。
3.发挖对测试感兴趣的新人，着重培养。
作者: 风中劲草 时间: 2011-2-9 14:42
您好，我在一家公司做测试，现在公司要求自动化测试，我只会基本的录制回放，学了QTP入门那些例子后，有什么好的书籍或者材料可以学习的吗？ 感觉QTP编程这一块的知识基本没有，有没这方面的书籍？ 看论坛看得我头晕了。。。
作者: 月亮上的小妖精 时间: 2011-2-9 17:52
回复 江潭素月
千里的回答很好，很明确，我再补充一点
（1）没有版本控制
之前给公司提过建议，让开发 ...
liuygneusoft 发表于 2011-1-25 22:11
你好，我是新手，直接由开发设计转的测试管理，关于版本控制，的确像你说的，如果不控制会无法分析是由更新版本造成的bug还是原本就有，那么如果控制版本，但是遭遇紧急bug的时候要怎么处理呢？这时肯定不可能再下一个更新版本的时候才提交的吧~麻烦指点一下~目前正好要做组工作规划由这部分~谢谢
作者: liuygneusoft 时间: 2011-2-9 19:04
回复 71# 月亮上的小妖精
如果是相当严重的BUG，不紧急发新版本，会阻塞测试进一步进行，那只能是特殊情况，特殊处理，发新版本。
作者: 月亮上的小妖精 时间: 2011-2-10 11:28
另外，我想问一下，我们公司目前用Jira在作管理，但是之前没有定制过相应的工作流，现在我想把bug类和task类的工作流区分开来，问题是，如果task提交测试后，出现的当前任务的bug需要提交bug吗？如果不提交直接将task任务reopened的话，之后分析项目的bug率，以及获取buglist的时候要怎么处理这部分的bug呢？
作者: liuygneusoft 时间: 2011-2-10 12:05
回复 73# 月亮上的小妖精
如果是新BUG就要提交，如果是原有BUG未修复好，就reopen ，在buglist中要列出reopen的BUG，同时也列出其被reopen次数 ，分析项目的BUG率时，这要看jira的实现。
作者: 千里 时间: 2011-2-10 12:56
本帖最后由 千里 于 2011-2-10 18:29 编辑
回复 默默巫
罗先生，您好！
我是10年的毕业生，参加测试工作半年，现在在一家软件公司做ERP测试。 ...
lqadnggw 发表于 2011-1-21 10:37
你的问题是很多在小公司测试团队里工作的烦恼，你的困境在你所在的团队可能一时半会难以解决，但也许积极面对能让你有点儿别样的收获。
1.我觉得需要对这种测试流程需要改变，但不知从什么地方做起，你能给我一些意见吗？
你觉得需要改变，说明你在测试过程中有不断的思考，这是成长的加速剂。但当不知道从什么地方做起时，建议你尊重原有的工作方法，等你具备改变的能力之时，你自然能够进行改变了。
2.公司对测试部太重视，也许是因为我们只做功能测试，怎样才能让公司重视测试？
我想反过来问几个问题：1.你们公司是做ERP测试，ERP系统除了要测试业务逻辑和功能方面，还需要做哪些方面的测试？
2.你们的开发人员进行了涉及到代码的测试，你是否知道他们从哪个角度进行的软件测试？功能性、易用性、可靠性、可维护性、可移植性、效率的哪个方面呢？
3.你能否接替开发人员进行涉及代码的测试？
4.我们没有写测试用例，也没有测试报告、测试总结之类的文档。这是一个问题，得你们两个测试员将其完善。
我认为你的工作流程基本符合小公司的现状，而且还有版本控制。其实你的主要工作是对业务逻辑和功能方面进行测试，你们公司对测试的定位也没有问题。
当然，你们公司确实也存在一些问题：
1.基本上我和另一个做测试的同事是没人管的（你们的项目经理不管你们？）这样可能导致你对需求、对系统的不熟悉，但可以把你们的困境反映出来，需要什么样的帮助罗列出来。
2.小公司不重视测试一般来说是项目组对测试的定位较低，可以通过把你在测试过程中对工作的风险，对软件质量风险以及需要的资料提出来，如果你提出的属实公司还是会重视的。比如我曾在例会上多次提出用户需求测试员看不懂，多次的反映终于得到领导的重视了。我就是通过对ERP系统的测试知道了如何做报表测试，明白了报表的生成就是一段存储过程，只要测试好了SQL存储过程就能够测试好报表。
3.我在提出要测试员接手后台测试时，项目经理回复如下：我可以让你接手这部分的测试，请问你需要多少人力？接手后能否让质量变得更有保障？同样，你编写了用例、对测试结果进行分析是件很好的事情。但你有没有时间去做？你有没有能力去做？当两个提问不再是问题时，我非常支持你做。你的领导也非常乐意你能够承担更多工作和责任的，我相信。
在小公司团队中，特别是新人。都非常的希望有一个带我们的师傅，甚至可以用渴望。
作者: andyyoung 时间: 2011-2-10 18:13
很不错，受用了。
作者: 愚人 时间: 2011-2-10 22:56
老千回答的好详细啊……
作者: wycmjrg 时间: 2011-2-11 13:44
罗专家啊，哈哈....
作者: yintianyouqin 时间: 2011-2-11 16:57
千里老师的回答简直是太好了。。而且千里老师好细心哦，把大家的问题都总结在了第一页中，让新来的朋友一目了然。。谢谢你了！
作者: xuhongningtest 时间: 2011-2-11 19:26
支持！
顶～～～～～～～～～～～～～～～～～···
作者: ROYWONG 时间: 2011-2-12 13:57
回复 1# 默默巫
还能提问题吗？
作者: ROYWONG 时间: 2011-2-12 14:14
本帖最后由 ROYWONG 于 2011-2-12 14:23 编辑
我想请教下大家的bug 管理流程。我知道没有最好的管理流程，只有最适合的流程。但是想看看各位都是用什么样的流程来管理bug。
先说明一下，我们公司使用的是JIRA。下图是我为bug管理制定的 提交到结束的流程。
[attach]71376[/attach] New: 测试人员创建一个log 后的状态。
Assigned: Project leader确认log 并进行分配，如认为不是bug，可以reject给测试人员，如果确认bug后，project leader需要考虑优先等级进行分配bug给开发人员.分配后的状态。
Fixed: 开发人员修复bug后返回給Porject leader确认的状态。
Confirmed: Project leader确认后，返回給reporter的状态。
Reopen: Reporter重新测試不通过后的状态。
Closed: Reporter重新测试后通過的状态。
BTW，本人新建了一个软件测试与管理的QQ群（20748921），欢迎大家一齐研究讨论。
作者: 千里 时间: 2011-2-12 14:18
另外，我想问一下，我们公司目前用Jira在作管理，但是之前没有定制过相应的工作流，现在我想把bug类和task类 ...
月亮上的小妖精 发表于 2011-2-10 11:28
我觉得你最好把任务和BUG分开两个项目做处理，然后在BUG那个项目里面设置一个字段关联任务项目里面的ID。你如果放在一个项目里面，任务和BUG的Key是一样的，不好区分哪个是任务，哪个是BUG
作者: ROYWONG 时间: 2011-2-12 14:37
回复 83# 千里
“在BUG那个项目里面设置一个字段关联任务项目里面的ID”
听上去感觉不错具体怎么弄？能详细点吗？
我目前的做法也是task 和bug 混在一个project里的，因为我是按不同的阶段分不同的project。
sit的时候一个project，uat的时候一个project，production的 时候一个project。
作者: Jackc 时间: 2011-2-14 16:47
回复 82# ROYWONG
恩，流程图不错，谢谢分享。
我帮你加了2个在软件开发过程中常见的异常流： EV Fail / Reopen
[attach]71408[/attach]
作者: xrh51testing 时间: 2011-2-15 10:41
千里分析的很好，值得学习！！
作者: electh 时间: 2011-2-15 15:48
罗师兄，您好，我现在从事软件测试行业刚刚四个月，每天都是跟随项目做功能测试，虽然业务上也有所了解和积累，但是自己现在越来越迷茫，不清楚未来的方向在哪里。
有人说女孩要主学业务，有人说技术过强才是硬道理，有人说管理才是生存之道，迷茫啊。
个人认为，我的塑造性很强，选定了方向就可以坚持不懈的走下去，请帮忙指指路吧。
作者: ROYWONG 时间: 2011-2-16 10:00
回复 87# electh
你的问题不好回答。令教人技术，勿叫人抉择！
“有人说女孩要主学业务，有人说技术过强才是硬道理，有人说管理才是生存之道”
业务：生存面窄。。。毕竟你不是万能的，行行业业都能清清楚楚。除非你决定了一辈子效忠你的公司！
技术：技术过强才是硬道理！ 这句话 放在什么地方都是真理！ 只是看你有没这个激情和活力。总结一个字“累”。
管理：不是管理就可以不懂技术的，只是可以不用什么都自己亲手去做而已。管理是心理的折磨！
目前国内的测试行业还很不规范。。。QC 不单单是测试软件而已，对文档，需求 都要进行审核。需求，开发，测试 三部分是平等的。 但现在有的公司甚至连需求文档都没有，售后就是需求，开发做老大的现在很是普遍。。。因此，我给你的建议是 目前，强调是目前，当下这个时刻，你应该学好你的技术，当你跟开发说话的声音逐渐加大的时候，你可以考虑转管理！ 希望你能在测试行业开阔一遍天地啊，塑造性很强的这位！呵呵
作者: ROYWONG 时间: 2011-2-16 10:02
回复 85# Jackc
thx 版主，我上传错了图片。。。我的流程就是和你画的一样的！ wakakaka
作者: 默默巫 时间: 2011-2-17 09:56
回复 默默巫
还能提问题吗？
ROYWONG 发表于 2011-2-12 13:57
还有问题的朋友可以继续提问的。
作者: Tinally 时间: 2011-2-18 16:02
我是2010年的毕业生，工作已经将近8个月，感到很幸运的是找到一份很喜欢的工作，就是软件测试。而且公司的规模也很大，虽然只有短短的8个月，感到自己成长了很多！
但是现在有一个很困惑的问题是除了处理日常工作（基本都是一些bug的验证),想往技术方向上发展一下，不想一直做黑盒测试，但是现在很迷茫，希望千里大哥给点意见！
谢谢
作者: 测试新新手 时间: 2011-2-18 16:21
顶千里!
作者: 千里 时间: 2011-2-19 13:30
我是2010年的毕业生，工作已经将近8个月，感到很幸运的是找到一份很喜欢的工作，就是软件测试。而且公司的规 ...
Tinally 发表于 2011-2-18 16:02
我先想问一个关于学历和能力的问题。关于这个的答案，你肯定是知道的。
首先我不知道你说的处理日常工作除了bug的验证还有什么，当然了不管是什么，你做的深度和同事的深度是否一致甚至更深？我有同事在验证bug时，经常需要找开发沟通。和开发的沟通经常用到软件工程术语，从开发那儿把数据库表全要过来研究了。
bug的验证，说实在的这个工作我没有完全明白。不知道是你的工作是别人发现的bug经过开发修复了，你去验证是否修复好了。还是你负责功能测试发现bug而且还需要验证bug是否被开发修复了这么一个完整的工作。如果你提交的bug，最后发现不是bug，你需要检讨一下。如果你提交的bug，开发还需要当面和你沟通，你需要检讨一下。检讨得多了，你的测试技术就成长了。
作者: zhml41 时间: 2011-2-19 20:09
软件缺陷管理工具有哪些呢，最近面试的时候老被问到这个问题，不是很会啊
作者: smallfish1987 时间: 2011-2-20 10:19
专家你好，我想问一下，我以前没有接触到测试需求，现在需要写一份测试需求文档，我不清楚测试需求到底是一个怎样的概念，而且也不清楚测试需求文档都应该包含哪些内容？
作者: 千里 时间: 2011-2-20 21:08
软件缺陷管理工具有哪些呢，最近面试的时候老被问到这个问题，不是很会啊
zhml41 发表于 2011-2-19 20:09
首先要搞清楚什么是缺陷管理，实际上缺陷管理就是一个bug在某个系统里面的一个处理流程，可以用OA的思想去理解。比如谁提交bug，谁又改变bug的状态，谁又关闭bug。
缺陷工具你一旦用会了一个，基本上其他的都不成问题了。最简单的有bugfree，简单又容易安装。其次还有bugzilla、mantis、JIRA是典型的缺陷管理工具。其次MYPM、TD/QC虽然是测试管理工具，但缺陷管理是其重要组成部分。
作者: 千里 时间: 2011-2-20 21:31
专家你好，我想问一下，我以前没有接触到测试需求，现在需要写一份测试需求文档，我不清楚测试需求到底是一 ...
smallfish1987 发表于 2011-2-20 10:19
所谓的测试需求就是在项目中要测试什么，每个功能点需要从哪些方面进行测试。而测试用例是对这些功能点的具体实现，我是这么理解的。
我们在测试活动中，首先需要明确测试需求(What)，才能决定怎么测(How)，测试时间(When)，需要多少人(Who)，测试的环境是什么(Where)，测试中需要的技能、工具以及相应的背景知识，测试中可能遇到的风险等等，以上所有的内容结合起来就构成了测试计划的基本要素。而测试需求是测试计划的基础与重点。
作者: xtaqvedx 时间: 2011-2-21 10:31
回复 95# smallfish1987
这个，求真相，居然看到你了，姐
作者: xtaqvedx 时间: 2011-2-21 10:35
那专家，你能发个测试需求的大致格式么
作者: liuygneusoft 时间: 2011-2-21 11:26
本帖最后由 liuygneusoft 于 2011-2-21 11:33 编辑
回复 87# electh
罗师兄，您好，我现在从事软件测试行业刚刚四个月，每天都是跟随项目做功能测试，虽然业务上也有所了解和积累，但是自己现在越来越迷茫，不清楚未来的方向在哪里。
有人说女孩要主学业务，有人说技术过强才是硬道理，有人说管理才是生存之道，迷茫啊。
个人认为，我的塑造性很强，选定了方向就可以坚持不懈的走下去，请帮忙指指路吧。
刚入行，有这种困惑是正常现像，也许你可能会误认为，测试就样呀，太没技术含量了，其实不然，工作都是要从基本做起，如果只是机械式的执行测试那提升是有限的，我不知道你工作中仔细想过，软件测试的组织管理，软件测试的过程改进等，说白了， 你可以往管理上靠(就算不往这方面靠，也要有所了解呀)，当然深入学习技术也可以看你向哪方面发展，如果你想做业务专家也行，前提是你的行业一定要是大行业，比如电信，税务，银行等，这些行业，不缺技术人员，缺业务专家
当务之急是把基本功打好，比如设计用例，写高质量的BUG，学习测试的流程等
| 欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) |
Powered by Discuz! X3.2 |