本周问题：怎样有效降低测试的轮次？（08-08-18）
在日常的测试工作当中，一个版本的发布常需要经过五轮或者六轮的测试，导致测试人员身心疲惫，工作积极性不同程度的下降。
为了改变这种现状，我们在项目管理或执行当中应该注意那些方面呢？期待各位同行的建议。
欢迎大家畅所欲言，参与讨论请点击：http://bbs.51testing.com/thread-123987-1-1.html
一、从哪些方面判断自己是否适合走测试管理路线？（08-03-21）
会员cityyard：
既然是软件测试论坛，这里说的管理路线大概是软件测试的管理吧。
判断是不是适合走管理路线，实际就是设计一个针对个人能力的测试项，好了，回到我们大家都熟悉的问题了
现在开始对这个测试项一步步拆分测试观点吧。
从大类分，第一类测试项是管理者需要的通用能力
这里面可以分成很多小类，很难写全，管理学毕竟是一门学问，只能随便列几个
1、 是否善于带领团队
a、是否善于利用团队里不同能力和性格的人合理分工，人尽其用
b、是否能产生凝聚力让大家力量往一处使
c、能否协调好上下关系，既不能让上层无休止的压任务而不吭声也不能放任属下消极工作带来的效率低下。
d、是否有较强责任感，管理者不能像普通员工一样，任务来了就做 做完了等下一个任务，这样的管理者的手下就更加会混事了。
e、是否能尽量不在工作中掺杂个人感情。
2、 是否善于制定和展开计划
a、拿到一个项目首先就是制定计划，计划的制定并不是写几条就可以的一般需要有一定经验，同时利用线表日报等工具辅助完成，善于统计和整理也非常重要
b、计划展开过程中要能根据实际情况提前调整计划，把握好进度
3、 是否能培养人才
a、能带一个团队打好仗还不是最好的管理者，能把手下带出一帮精兵强将才是更加珍贵的管理者，他们堪称是公司的发动机。
b、建立完善的交流培训机制，使得新人培养和老员工交流都体制化
4、 当然了必不可少的必须善于人际关系处理。
第二类测试项是软件测试管理者特殊的能力
1、 是否有足够的软件测试经验，接到一个项目知道如何展开，熟知测试与bug的生命周期，熟悉统计数据的制作和分析，能从统计数据中看出目前项目状况问题所在，知道哪里有问题需要改进。
2、 是否有较强学习能力一直能保持先进性，作为管理者，个人以为不提倡去一线继续作技术，但是一定要保持关注测试领域技术动态知道同行们都在做什么，怎么做，这样自己虽然未必会做，但是可以带领团队技术骨干去做。另外较强学习能力还在于领导者虽然未必去执行测试，但是一定要能透彻理解要测试的东西。
二、测试人员如何说服他人认可你提交的缺陷是需要修改的？（08-03-28）
会员cityyard：
这个问题其实非常不好回答，实际情况往往很复杂……
就我个人经验写一点感受吧~~当然了，诸如要写清楚现象，尽量详细报告等是QA人员应有素质，这里篇幅原因暂且搁置不谈。
首先，开发方必须提供完整详细的式样书和制限事项。式样书是测试人员测试的基础，测试人员如果按照式样书测试得到了不一样的或者奇怪的结果，那么必然是 bug无疑，没有任何可以争论的余地；如果测试人员执行了式样书上没有写的动作，得到了一个奇怪的结果，那么首先去制限事项里面找，如果制限事项写了，那么意味着开发者知道这个问题并且还在开发中，那么OK暂时放过（注意是暂时），如果制限事项也没写，那么再看这个动作是不是用户可能做出来的动作，举个例子如果一个软件的某个命令完全封装在内部，调用时一定会以普通用户身份执行，那么测试人员使用root测试出来的问题就是无效的（注意，当然封装的命令可能因为封装错误用root执行了，但那是另一个bug）；如果测试人员的动作虽然式样书没有，但是却是用户可以做出来的，那么抱歉，这个问题必须修改，而且还要围绕这个被式样书遗漏的问题进行拓展。
其次，测试开始前由开发方review测试方的测试计划，并针对测试方对式样书的疑问答疑。这一点有两个好处，一个是开发方可以尽早指出哪里测试不合理，哪里测试薄弱，另外也可以减少以后因为双方理解上的差异带来的时间浪费。虽然这会占用一点开发人员的时间，但是磨刀不误砍柴工。
第三，建立完备的版本管理系统，这个系统如何建立前面的每周一问已经详细讨论过了，目前要补充的就是，版本管理中必须把式样书和制限事项一起加进去，开发者发布了0_0_1版，其中制限事项是文件数目不能超过1M个，0_0_2版开发者取消了这个制限，那么必须在发布作这个版本的同时写明这一点，测试人员才能据此测试。严格的版本管理可以有效减少纠纷，如果测试人员使用0_0_1版测试1M+1个文件失败，那么是无效测试，如果使用的0_0_2版，那么就是bug必须修复，无可争论。
有了上面三条，大部分问题差不多能解决了，但是还是不行，差在哪里？主要还有两个问题，一个是测试方可能指出一些跟个人喜好相关的地方，比如测试方可能指出GUI一个警告信息窗的字体太暗而且不显眼，不容易被注意到，这类问题无法用上面三条来解决，因为是否容易被看到本身就不好界定；另一个问题就是（尤其是到了测试后期），测试人员连续跑了好几天测试忽然程序死了，再来一次又没事了，告诉开发人员这个现象，开发人员也解决不了，因为很难再现，如果是测试环境问题还好，如果真的是软件缺陷那被用户遇上就很严重，但是这种问题无论是让QA无休止的尝试再现还是让开发者没头没脑的调查都很难说得过去。于是我们加上一条：
第四，仲裁机制。QA和开发者并不直接对话去讨论一个问题是否要修改，我们首先对开发者实行残酷的有罪推定，也就是QA报告的问题开发者都必须修改，如果开发者认为无需修改必须给出理由和证据，围绕这个理由是否成立，QA和开发者双方展开讨论，这个讨论必须每一步都使用缺陷管理工具记录下来。最终要改还是不要改由一个仲裁机构来决定，当然了这个仲裁机构其实就是更上层的管理者，他们手里是日程计划，市场需求，对手状况等，他们根据这些更高层信息决定一个问题是否值得去修。
写到这里细心的读者已经发现，题目问的是怎样去说服，我却大谈测试管理方法。其实我个人觉得，建立一个宏观的良好机制比起一个测试者去唇枪舌剑的和开发人员辩论更加有效，我们追求的是什么，不就是效率么。因此我个人以为真正的测试人员职责就是报告缺陷，至于这个缺陷是否应该被修复先用机制套，套不上再来仲裁，仲裁过程QA leader全程参与，测试人员要做的只是在仲裁过程中客观的回答每一个问到自己的问题，至于什么我认为这个bug必须修之类的话不必出自测试人员之口，正如汽车发动机只需要考虑转呀转，具体哪个路口该拐弯也让发动机来考虑就不必了。
三、如何在有限的时间内编写完整有效的测试用例？（08-04-07）
会员duola1119：
楼主的问题看来只有一句话，但实际包含了很多方面的问题，不同的人文环境、公司文化、公司资质等因素都会产生不同的结果。
分析这个问题，我想先从两个方面回答：
1.如何在有限的时间内完成测试用例
2.如何编写完整有效的测试用例
有限的时间顾名思义工时不足。那么凡事都是有果必有因，解决问题就要先找到其原因，并加以解决，问题就会迎刃而解。
在软件行业中，时间是一个非常重要的概念，时间有限也是经常提到的一个词，归其产生原因不外乎以下几点：
1.项目经理缺乏项目管理经验，对项目工期估计不准确，导致工时吃紧，时间有限。
2.项目开发人员（包括测试小组人员）缺乏实际工作经验或者说知识匮乏，相比之下不能在相等的时间内完成自己的任务，导致时间有限。
3.项目开发周期已经确定，但由于客户的临时需求变更导致的工作量增大，无法继续在规定的时间内完成任务，导致时间有限。
4.社会关系导致的公司内部人员拉帮结派，出现的争功躲弊的人群在有权利条件的基础上为夺取管理阶层对自己的好感，谎报项目的开发周期，致使承诺的工时远远低于实际工时，导致时间有限。
5.其他原因（事假、病假、人员变动、突发事件等）而导致的项目人力资源不足，时间有限。
用CMMI的理念讲以上这些原因就是风险，针对这些风险，就要采用风险识别，风险评估，风险减缓，风险跟踪将问题扼杀在萌芽中。
第一，根据风险检查表，识别出项目的风险（时间不足）
第二，估计风险严重性、风险可能性、风险系数（以上列举的5条分别进行评估）
第三，对于风险系数超过“容许值”的每一个风险，都应采取减缓措施（量化风险的严重性，定义容许值）
第四，跟踪风险减缓过程，记录风险的状态
第五，制定风险解决方案
1.项目经理需提高系统分析能力，增加自身技能水平，提高预测准确度。必要时可以更换。
2.提高工作人员自身技能水平，评估其工作能力，定期考核，安排适当人群执行适当工作。公司提拔的不算。
3.严格控制需求变更，制定需求变更管理，需求发生变更要经过会议评审，必要时员工需加班工作。
4.社会关系复杂，如果想被提拔，升职或加薪那就乖乖的加班工作。
5.减少工作对单人的依赖，保证每份任务必须由两人或两人以上负责，突发事件另作处理。
虽然回答没有针对如何在有限时间内编写测试用例，但以上答案完全可以解决这个问题了。
回答了第一个问题，下面回答第二个问题。说一下怎么样设计完整有效的测试用例
第一，覆盖率100%，保证完整性
第二，对测试环境，用户环境，模拟用户环境，及之间的差别进行描述。
第三，设计场景测试法虚拟业务流程
第四，建立测试公共数据，并根据系统内部关系组织数据的关联性
第五，其他人可以看懂你的用例，并且是可以执行的
第六，如果有标准的用例模板，可以使用用例模板
现在将这两个问题合二为一，不同的问题可以根据给出的答案互相结合找出解决问题的办法。
但是根据我的经验，一般编写测试用例的时间都是很充足的，除非是某些项目为了应付监理公司，临时对项目的相关资料进行补充的时候才会出现这种情况。
