(二)软件测试每周一问最佳答案精选

在测试工作中，有一种直接拿到软件就测试的做法，它已经被大家认为是无效的测试，那么怎么分配时间来完成测试用例的编写，并且还要在有限的时间里？欢迎大家进行讨论与交流！参与讨论请点击》》

 

会员huior：

注：1 每个阶段需要的时间因人而异

既然是软件测试论坛，这里说的管理路线大概是软件测试的管理吧。
判断是不是适合走管理路线，实际就是设计一个针对个人能力的测试项，好了，回到我们大家都熟悉的问题了
现在开始对这个测试项一步步拆分测试观点吧。

从大类分，第一类测试项是管理者需要的通用能力
这里面可以分成很多小类，很难写全，管理学毕竟是一门学问，只能随便列几个
  1、 是否善于带领团队
      a、是否善于利用团队里不同能力和性格的人合理分工，人尽其用
      b、是否能产生凝聚力让大家力量往一处使
      c、能否协调好上下关系，既不能让上层无休止的压任务而不吭声
         也不能放任属下消极工作带来的效率低下。
      d、是否有较强责任感，管理者不能像普通员工一样，任务来了就做
         做完了等下一个任务，这样的管理者的手下就更加会混事了。
      e、是否能尽量不在工作中掺杂个人感情。

  2、 是否善于制定和展开计划
      a、拿到一个项目首先就是制定计划，计划的制定并不是写几条就可以的
         一般需要有一定经验，同时利用线表日报等工具辅助完成，
         善于统计和整理也非常重要
      b、计划展开过程中要能根据实际情况提前调整计划，把握好进度

  3、 是否能培养人才
      a、能带一个团队打好仗还不是最好的管理者，能把手下带出一帮精兵强将
         才是更加珍贵的管理者，他们堪称是公司的发动机。     
      b、建立完善的交流培训机制，使得新人培养和老员工交流都体制化

  4、 当然了必不可少的必须善于人际关系处理。

第二类测试项是软件测试管理者特殊的能力
  1、 是否有足够的软件测试经验，接到一个项目知道如何展开，熟知测试与bug的生命周期，熟悉统计数据的制作和分析，能从 统计数据中看出目前项目状况问题所在，知道哪里有问题需要改进。

  2、 是否有较强学习能力一直能保持先进性，作为管理者，个人以为不提倡去一线继续作技术，但是一定要保持关注测试 领域技术动态知道同行们都在做什么，怎么做，这样自己虽然未必会做，但是可以带领团队技术骨干去做。另外较强
学习能力还在于领导者虽然未必去执行测试，但是一定要能透彻理解要测试的东西。

啊诺~~~这个问题其实非常不好回答，实际情况往往很复杂……
就我个人经验写一点感受吧~~当然了，诸如要写清楚现象，尽量详细报告等是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必须修之类的话不必出自测试人员之口，正如汽车发动机只需要考虑转呀转，具体哪个路口该拐弯也让发动机来考虑就不必了。