在公司制度不规范的情况下，如何做好测试工作？（09-5-11）（获奖名单已公布）

archonwang

呵呵。不规范。。。。

规范需要很高的代价，从看得见的人、财、物到看不见的时间精力。

如果制度不规范。可以具备的几种选择是：
1. 选择离开到更规范些的公司任职；
2. 从现实出发：
2.1. 梳理现有流程；
2.2. 从现有流程出发，选择构建必要的流程节点
2.3. 着手基本的管理工具。很多公司可能没有，那么着手使用最基本的word、EXCEL进行管理，但是人工干预的内容很多，一个小团队维护的话比较吃力。
2.4. 确定现有的可使用的测试方法并将这些方法填充到流程上
2.5. 逐步完善流程和流程中所使用的各种方法，并形成制度


一个比较简单的案例如下：
一家公司，没有测试团队，有1～2个测试人员参与项目的测试过程。那么就从测试开始的时间计入，参与功能测试，系统测试等。每个阶段定义一条流程，将bug追踪解决确定为一独立流程，使用mantis管理工具进行支撑。在每个测试阶段里，适用的方法，例如：黑盒测试设计及执行方法，系统测试流程等归纳和总结。为配合这些流程，逐步引入缺陷管理工具，测试辅助工具（主要是测试数据生成，测试记录追踪等），任务分配系统等。在工作过程中，依托已经形成的成文形式，明确各方职责，当然，技术经理可能排除哪些规范制度尚不涉及的区域，逐步完善规范和制度，适应当前的项目及公司环境。经2年左右的发展，逐步将开发阶段的各个角色进行了专业化分离。

[ 本帖最后由 archonwang 于 2009-5-15 13:27 编辑 ]

heporen

我也迷茫中。。。。

free_xiaoyu

目前在我们公司，我就感觉到测试工作非常难做，老板根本不知道测试的作用。所以我觉得在一个小公司要做好测试很难。如果单就测试工作而言，我觉得首先还是在测试内部建立起一个测试规范来，这样会好做一些，另外就是，应在功能测试方面多做工作。首先保证软件的功能满豆用户的要求。

ganhuiping

目前就我就处在一个小公司，一个人坐在一个尴尬的位置上。有时候这个位置很冷，但是没办法还要做下去，各种所谓的规范自己也在慢慢摸索中。就我工作的这半年有很多的体会。需求应该是所有软件活动的源头吧，有的错误先天就是由需求带来的。根据需求去开发，去测试。应该是准则。在小公司各种管理体系不成熟的情况下，我想先保证软件的功能是最主要的，其他什么性能之类的几乎不涉及，也没人关心。很多所谓的规范如果拿到小公司，还得根据实际情况来改改。

huguxiang

恍恍惚惚，在这里呆了快三年了，从没有测试部门到有测试部门，现在又到没有测试部门，我从雄心壮志，到现如今的信心全无，反反复复，几多忧愁几多欢喜。测试本无罪，创造不了效益就有罪了，所以老总，经理，开发人员没有一个重视测试的，呜呼哎哉！因而，我常年生活在“三座大山”之下，做人胜于做事。

zhangzhimei1004

首先，制度是人定的，各个公司的情况不一样，制度也会不一样，同时，制度也是根据经验慢慢摸索出来的；其次，就算制度规范了，执行力度不够，最后的结果的也不一定满意。所以对一个制度不规范的公司，如何做好测试工作，个人认为有几下几点：
1）需求：要主动参加开发部关于需求讨论的会议，对需求真正的了解；当需求有变更时，要做好变更记录；需求定了，设计说明书完成后，就可以编写相关的测试用例了（能写多少就写多少）；
2）单元测试：当开发人员开始编写代码时，和项目经理商量让开发组同事做一些单元测试（如果单元测试做好了，对软件质量会有很大的提高；以前不做单元测试，现在开始做，一点一点完善。）；
3）测试：当开发人员完成一个功能后，就要主动去测试（制度不规范，开发人员未必会主动提交给测试人员），一直到项目完全完成后，进行完整的系统测试。项目的每一个功能都要认真去测，写了测试用例的就按照测试用例执行，没有测试用例的可以先测试然后再写测试用例（为以后项目做准备）。对于有特殊要求的测试比如性能测试也要做一点；
4）提交Bug：提交Bug时，主题一定要明确，要做到一目了然；Bug等级和优先权一定要设置好，不同时期开发人员会解决不同类型的Bug，且Bug的优先权是不同的；在描述中一定要写清楚详细的Bug重现过程（每个项目时间都很紧，开发人员没时间仔细琢磨Bug到底是什么意思或者按照描述重现不出Bug）；能准确定位问题更好（不过，需要对代码十分了解）；
5）提交测试报告、分类统计Bug数量：测试完成后，要做一个测试报告，根据测试项目的过程，写一个测试报告，格式不重要，提交给项目经理；最整个项目在测试过程中出现的Bug进行分类统计，然后把统计表发给开发人员以及项目经理，这样开发人员对以后编码也是一个帮助。
当然，对公司所处行业的行业知识也要有一定的了解，这可以帮帮我们能已更接近用户的角色来使用软件。

maguschen

首先，也是最重要的一点：不要尝试自己建立一套所谓规范的制度，并且让其他人以此作为标准来执行。

公司制度不规范，其主要原因，个人认为，是“制度”不被重视，所以就不能被规范。遇到这种情况，个人认为可以做以下的事情。

1. 首先做好自己的本职工作，提高自己的业务水平，博得同事和上司的认可与信任
2. 有空的时候研究一下自己所在部门的情况，然后根据现实，尝试给领导提出一些制定规范或者改善流程的建议。需要注意：
    a. 一定是在富余时间做这件事情，老板最初请咱的目的就是干好本职工作
    b. 一定要根据实际情况提出建议，而不是照搬书上或者某些人的成功经验
    c. 一定要给你的领导提，不要自己跳出来搞，没有领导的支持，是不可能成功的
3. 如果建议得到接纳，并且在实际工作中看到积极的效果，可以持续进行第二条……

每个人都有冲动的时候，总会想自己搞个什么流程出来优化优化；说实在话，出来混的，没有谁比谁聪明多少，你想到的东西，部门里面其他人肯定也想到了；之所以没有实施，里面肯定有原因；所以我们有什么想法，最好通过老板来推动，自己单干，会死的很惨。

cagemm

多和研发人员沟通、交流；
对测试过程进行详细记录，根据日常工作出现的问题总结，分析工作中的难点，并做出解决方案；
最终还是要形成明确的规章制度，按制度行事，工作效率和工作质量会提高很多。

kuailederen

有几个公司是规范的呢？也就是流程复杂些而已。
我们所谓的不规范，基本是没有具体需求或者需求不详细，没有完整的测试流程，一般是系统做好了才去测试，没有科学的采集测试数据和分析数据从而为测试服务等等等的情况。
      我们都知道目前被普遍认可的质量管理体系cmmi，它是这样说1级的：没有任何质量管理过程，项目的成功完全依靠个人的能力。
  那么好，我觉得在一个测试不规范的项目中，个人能力也会起到关键的作用。因为他的经验和能力可以拟补很多项目中的不足。
   下面是我的观点： 抓住几个重要的环节即可。
   1.第一个环节是需求。
   有简单的需求，你需要尽量的细化。如果没有需求呢，你也要根据已经做成的系统来理解需求，一切凭的都是经验。这里所说的需求，不是让你写测试需求文档，是让你去认真的思考测试点。
   2.写好测试策略和测试方案。
    测试策略是分析出本次测试包含的质量因素和测试的内容，以及测试重点；在测试方案中提出测试的具体方法和测试建议等。只要做好这两点，那么后面的测试就非常的简单，也基本不会出现意外。一个人的水平就体现在他做这些工作和实际测试的偏离度。所以你要根据自己的经验去做这些。我以前做的这些，经常就是在测试前期就制定测试方法，写出在那个功能模块中要怎样测试就会出现问题，很准的，也很有成就感。
    3.写好测试用例。
  可以说一个测试人员的价值就体现在测试用例上。无论你以前做的工作有多好，而只有测试用例才是看得见的，才是离你的目的最接近的。把你对系统的理解，对系统的分析，把你的测试思想和技能全都体现在用例里，因为只有它才能发现缺陷。

    总之一句话，经验和个人能力和以拟补一些流程和管理上的不足。
  一个测试人员的能力，我认为应该体现在这里：对问题的预知，解决问题的方法，定位问题的效率和准确。

yanning0509

进软件测试公司实习也快两个月了，可是基本上人家也不安排你事情做，就给你公司的软件让你随便玩，总感觉很闲，学不到东西，别人都忙的紧，也没任务给你，感觉自己无法进步，我想问一下各位前辈，你们刚进公司时也是如此吗？有没有经验可传授一下

Fin

答：首先，这家公司没有测试的历史背景，公司项目的规模等。最大的困难应该是领导的重视与否。然后要理解公司对测试这个职业的认识达到了什么样的程度。还有开发项目经理是否愿意去让他的产品去给别人评价，检测。此时，沟通成本变的异常的庞大。
那么如何做呢？要明确每一个角色的关注点。不防也可以把他们定做成一个过程划分，
针对不同角色进行沟通时明确他们的需求。下面是说明：
        角色：                老板
        入口准则：        利润（只要让他看到利润，入口准则就成立）
        输入：                成本（老板决定投入的成本）
        出口准则：        测试工作的开展给公司带来的利润评审通过
        输出：                测试工作的开展给公司带来的利润
老板要的是利润，只有看到了利润，老板就可以继续支持下去。既然是以测试人员被招聘入公司，就说明多少有做测试的意向。但老板要的不是沟通与说服，一切由数字说话，不是去翻阅测试的历史，而是要自己亲自实践给公司带来的实际利润做统计数字来说话。
        角色：                开发项目经理
        入口准则：        帮助，捷径或者说为了项目/产品更早的被发布
        输入：                允许测试工作进行
        出口准则：        测试工作的进行确实给项目/产品带来捷径的评审通过。
        输出：                测试工作的进行确实给项目/产品带来捷径
对于开发项目经理来说，这一关是最不好通过的。因为测试其实是否定其产品的完美性的工作。项目经理多少都会对项目/产品一种保护反映。让其认识到测试对他是一种帮助，而并不是敌对角色，是站在一条战线上的。
下面是针对工作的开展计划，作为有且只有唯一的测试人员，我们必须承担起多人的角色。测试经理，测试人员，SQA等。要做的工作也是普通测试人员的N倍（但付出总有回报）。主要在于角色间的转换。首先我们要站在测试经理的角色上，依据公司的规模和项目/产品的大小，选择测试模型。划分测试阶段，参与需求设计评审，评审基线定位，编写测试计划，设计，根据设计写测试用例，测试执行（测试员角色）等工作展开。提交BUG并进行回归测试。测试工作完成后，要转换角色到SQA 进行测试统计阶段，这步非常重要，是提交给BOSS和开发经理看，用来确认你工作的有效性，和测试的重要性，也为下一步展开更规范性测试的可行性的进一步保障。主要有分析缺陷指数：
        分析指标
1．        反映产品质量的指标
缺陷密度=缺陷数量/软件规模（千行代码数）
潜在缺陷概数=（100%-发布前缺陷的缺陷去除率）*缺陷密度
2．        反映产品可靠性的指标
平均实效时间=软件持续运行时间/缺陷数量
3．        反映缺陷发现及修复效率的指标
缺陷检出率=某阶段发现的缺陷/属于该阶段的全部缺陷*100%
发布前缺陷去除率=发布前发现的缺陷/（发布前发现的缺陷+软件运行前三个月）*100%
缺陷修正率=修复过程中未引发其他问题的缺陷数/被修复缺陷的总数*100%
4．        反映缺陷修复成本的指标
平均修复时间=∑缺陷修复时间/缺陷数量
平均修复成本=开发人员的平均人力成本*平均修复时间
相对返回成本=返工的工作量/项目总工作量*100%
        汇总统计
1．缺陷发生的日期统计（缺陷发现趋势图）
2．缺陷性质统计（缺陷变更，需求变更）
3．缺陷状态分布（关闭，修复中，挂起等）
4．缺陷按子系统（模块）分类统计
5．缺陷引发原因分类统计
6．缺陷来源统计（缺陷提交人或提交方）
//----------------------------------------分割线-----------------------------------------------//

    以上是我在上学的时候回答的这个问题的答案，现在翻出来看看，确实挺幼稚，可笑的回答。学生时代是没有经历过真的困难，基本上想象工作是简单容易的，把自己当作救世主的心态走进了社会后，碰了钉子后都不知道自己是错在哪里，反省了好长时间，真的把事情看得太简单了。
    “在公司制度不规范的情况下，如何做好测试的工作？” 这个话题锁定的范围太广了，有技术范畴的、有管理范畴的、也有心态范畴的。真的这几个方面缺一不可，但完全做好了也未必能做好测试工作。这是我现在的理解程度，可能以后会是别的思想。楼上长辈们，高手们都谈了技术，管理范畴的，我想谈一下心态篇的东西，共同学习，共同进步。
     我们都知道需求很重要，有一个项目的需求要确定，老板要我们去做，我们在甲方这里，想了一切可能碰到的困难，下定决心，一定吃掉这个任务，去了2个月了，完全傻眼了不是甲方不和你谈需求，也不是公司不想做这个单子，不确定需求还好说，我们可以帮忙引导，关键是客户没时间和我们谈需求，好容易做了N天的DEMO(这DEMO完全是我们在幻想纪元带回来的，需求就告诉你：“一个女人，美国人，长头发，没了”，然后我们就在地球上一个一个去抓，抓回来不是，放了再去抓。。。。。地球外面的根本不敢考虑。。。)就这样硬是把公司的5个弟兄培养成前台美工了。。将近2个月，终于有一天，晚上6点到7点半我们正式沟通了,甲方说OK ，效果不错，我们还没来得及高兴，又遭到一个雷劈，最后拍板的老板不是他。这项目要不要做还是两回事呢。真的，当时死的心都有，可是金融危机的今天，又有啥办法呢？就这样，继续，把5%的希望转化成100%的成果。我们继续一步一个脚印的走着，仔细站在客户角度思考着，9600转速的大脑硬盘不停的转动着（自己都能听见噪音）。。不抛弃不放弃。。。

     公司的制度体系不完全这个是很正常的，没有哪家公司说他们制度体系很完美。但有一些硬性指标需要我们必须自觉遵守自己公司的风格和规范，若没有的话可以建议，但不要强制自己使用（导致脱离了团队就不好了）自己的规范。 为什么要说建议呢？是因为很可能我们考虑到的因素很片面，很有可能给自己公司带来成本利润的流失或者和某些内部规范冲突也是有可能的。如果你是你们公司的CEO 那就当我没说哈哈，把这段当作UFO谢谢 。。
     若有什么意见和个人建议，记得要在项目还没开始时提出，千万不要等到进行中了，才去说不应该这样做。千万不可硬着性子我行我素。虚心问个“为什么”要注意态度和语气。。
     规范的意见和建议最好在总结的时候提出，总结是个好习惯，也是大家心平气和的时候，可以很理智的听你的意见和建议。
     还有很多就不在这里叨叨了。。

wangz

小公司成立阶段根部不适合做 测试 ，哪怕是功能测试

因为功能测试成本低，人员要求也低，相对地位低，公司流程又不成熟，需求每天提，每天都有很严重的东西要修改，要上线 ，要加班，你没有时间写用例，学习计划。可能你想找个人学习(我是说测试)的机会都没！因为测试的可能就你一个人，或者一个从来没做过测试的人。

想对来说，如果有能力请一个成本较高的测试人员的小公司有很少。及时请过来，很少会一个测试人员而该流程。因为小公司工作的人，没有那个意识，认识不到。

ps，所以建议在小公司工作的人，如果能力特别优秀的可以继续，如果刚刚踏入门槛的，奉劝你们千万别，因为你要提高的太多了，而都不是一家小公司能给你的，除非你想锻炼的是心态，要提高的是素质！

奉劝想做测试的还是要去大公司，从底层做起也是能学到很多比较前进的测试技术和流程规范的！

鹭岛

1.前期定义好测试的内容，范围，尺度，并写好计划
2.按计划执行测试（手工测试，小公司不太可能有中大型项目，功能自动化不太现实，性能的倒还有时候会用到），利用管理工具TD来管理测试中出现的BUG。
最好熟悉下CMMI 最低2级的标准来执行！

kuangquanshui

努力吧  朋友们  一起都会好起来的  面包会有的

测试新新手

这个帖子开的很好啊,很赞!
我目前基本也是处于测试的初级阶段,因为单位里以前没有专门的测试人员，所以我就被指派从开发转成测试了,
我觉得是不是先应该
1.先从文档的规范做起,需求报告,设计报告,测试报告,代码青单,上机报告等文档必须要都有.
2.然后再开始细化测试上面的一些规范,比如怎么写测试案例,怎么写测试计划.
目前非常困惑我的就是，要不要用自动测试工具,用什么测试工具?(目前还停留在手工测试阶段,程序用的语言是C和JAVA)
希望有经验的前辈们指点一下小弟吧,十万分的感谢!!!
最后,希望大家多交流交流,共同提高!

msnshow

先根据自己的经验写好测试的流程与规范，在以后的项目中进行实施并完善

最主要的是，流程与规范制定出来了，大家都认可，就必须在以后的工作中落实

yujiaoyang

在公司体制不完善的情况下，我想我们首先还是得做好自己的本职工作。
       首先得完成自己的工作任务，只有你得到了认可，那么你说出来的话才会得到重视；只有你完成了自己的工作任务，那么你才会有更多的时间来考虑如何让公司的测试规范起来，不然即使你提出了很好的建议，估计也派不上用场。
       其次，在我们还没有能力让公司规范化的情况下，我们应该保持自己的差异化（至少保留着自己的规范化思想），千万不要让不规范的思想先同化了你，不然让谁来规范你们的公司呢（呵呵）？

longhu123

我现在也是在一家不正规的公司做，公司根本就不信任我们刚来的，虽然有经验，但是还是得不到认可！
有些郁闷。
不正规的地方他们还是接纳他们测试员的意见。我们的只能做参考。
反正很郁闷！

jiepeach

努力做好测试工作，让老板认识到测试的重要性，说一下我目前的做法：
1、制定测试流程。目前我的测试流程是这样的：获取需求、分析需求（让每个测试者清楚的认识到要测什么）、设计测试方案（告诉测试者如何测试）、执行测试、跟踪问题
2、尽量早的加入测试队伍中。业务人员、开发人员、测试人员一起讨论业务需求（用户需求）、开发人员根据业务需求设计demo然后开发人员、测试人员、业务人员再次讨论需求。需求确认以后开发人员着手设计开发、测试人员准备测试
3、与开发人员交流沟通。遇到一个模块不知道如何测试时，先向开发人员详细咨询模块的实现方式，将设计的测试案例主动找开发人员帮你看看，没有人会拒绝你的虚心请教。

hongyan

这个问题很头痛啊.提出了一些自己的见解,但是不了了之,最常听到的一句话就是:"以前就是这样的,那样做肯定没用".听到这样的话很心寒啊,一个小兵又能做什么呢,