对于一个测试周期短的项目，该如何保证软件质量？

nod

公司的项目大多是周期短的项目，在这种情况，过多的考虑用什么测试工具和做完备的测试计划来保证软件的质量显然是不太可能的，那该从何处着手才能尽可能做到既保证质量有保证效率？
1。加强对测试人员的培训
2。将测试流程做细
3。制定详细的文档

请高人畅言

迎风

泛泛的说偶认为起码应该：

1、在时间有限的情况下，更加合理分配测试资源，包括物件与人件；
2、在过程规范的情况下，更加精简与优化流程中的部分节点，提高工作流效率；
3、在条件成熟的情况下，引入半自动化的测试框架与工具，降低测试执行成本，提高类用例或脚本在测试中的复用率；
4、在人员到位的情况下，及时加强对其的培训与执行优化，提高实施过程质量；
5、在资金充足的情况下，可能的话考虑部分测试件外包，但产品核心必须掌握在自己公司的控制下。

个人愚见，就先说这么些吧，其它的慢慢再想，大家一起集思广益、畅所欲言吧，呵呵～

TestTip

迎风说得很好。





－－－－－－－－－－－－－－
《我在微软做软件测试》在我的个人网站www.TestTip.com

flytigerboy

迎风兄，要是在时间有限，过程不规范，条件不成熟，人员不充足，资金也不够充裕的情况下，要怎么办啊？

skinapi

迎风说的很不错，我再补充一点自己的看法：
对于测试周期短、测试压力大的项目，沟通和交流更显的重要，可以考虑每天下班前测试组进行总结交流，以便问题尽快解决。

skinapi

Originally posted by flytigerboy at 2005-10-31 09:07 AM:
迎风兄，要是在时间有限，过程不规范，条件不成熟，人员不充足，资金也不够充裕的情况下，要怎么办啊？

测试的效果本身就依赖于时间、过程、资金和人员等条件，测试组所要做的只能是在这些条件的前提下去尽量测试的更好一些。
1、时间有限、人员不足，那可以采用基于风险的测试，也就是低优先级的测试用例放弃执行；
2、过程不规范，可以通过人与人之间更多更深入的交流来让测试更顺利；
3、这种情况下肯定是存在较大的测试风险的，需要让管理层明确这些风险，再就是尽量去减小这些风险了。

xyj0323

那就不要考虑什么文档啊，流程啊，让所有的人都行动起来，加班加点！

[ 本帖最后由 xyj0323 于 2005-11-29 23:35 编辑 ]

black_tulip

恕我直言，其实迎风什么也没说。

1、在时间有限的情况下，更加合理分配测试资源，包括物件与人件；

// 什么叫更加合理？怎样更加合理？大家没上过问题解决的培训课吗？这样模糊的词是不允许出现在问题定义、描述和解决方案中的。大家想想新闻联播里是不是经常听到这样的话。

2、在过程规范的情况下，更加精简与优化流程中的部分节点，提高工作流效率；

// 同上。更加精简、优化，这样的词对是对的，可等于什么也没说。

3、在条件成熟的情况下，引入半自动化的测试框架与工具，降低测试执行成本，提高类用例或脚本在测试中的复用率；

// 楼主的情况就是条件不成熟。因为周期短。

4、在人员到位的情况下，及时加强对其的培训与执行优化，提高实施过程质量；

// 同上，楼主的情况就是到位的人力资源紧。因为周期短，没有哪个老板会配足人手。

5、在资金充足的情况下，可能的话考虑部分测试件外包，但产品核心必须掌握在自己公司的控制下。

// 这个就看老板愿不愿意花钱了。

skinapi

black_tulip说话还是一贯的直接，呵呵。不过迎风的确只是说了大致的方向，而没有涉及具体的思路，比如时间有限的情况下，我们该如何合理分配测试资源，大家可以更深入的探讨一下，希望能弄出一些对实际工作更有借鉴价值的东西出来。

atce

4。测试人员尽早介入。
5。测试文档可重复利用。
6。测试覆盖优先级评估
7。缺陷管理及因果分析
。。。

black_tulip

对于一个测试周期短的项目，该如何保证软件质量？

// 个人认为对于测试周期短的项目，想保证质量只有依赖开发人的水平/经验和测试人的水平/经验了。

迎风

谢谢楼上朋友的观点，其实我也只是一个刚从事测试工作1年左右的新人，而且其中还涉及到需求、设计、编码与技术支持等，所以自己很多思想都暂时只停留在理论阶段，缺少真正实践的融会贯通。不过这些理论既然是前人智慧与总结的结晶，虽然自己并没有全部实践过，但经过认真思考和理解后也可能为将来项目中有效的过程实施提供更好的思路，我想，不同的项目中还是都可以充分借鉴并尽可能本地化以提高所在环境的能力成熟度，不是吗？呵呵～

这一段是年终时间，公司进行的项目进入冲刺的阶段，因此非常忙，来51大多数场合都是在旁听与思考大家的交流，自己也比较少发言了，真不好意思。今天既然看到大家的发言，那我也来补充说几句，希望和能同行前辈朋友们在交流中多多得到进步，谢谢～

如果时间有限，当然要更加合理的分配用于实施测试过程的资源了，这个是最大的方向。那什么叫合理呢？我想，不同公司不同项目不同开发模式都应该是不同的，不能一概而论，否则就只能说个大体的方向了。以我所在的项目为例，测试其实是中期才介入到开发过程中的，而开发模式属于螺旋式开发（先开发出原型与基类，然后逐步演化），但整体过程并不十分规范。因此，要有效的实施测试，在计划阶段首先就应该尽可能的量化好所有的测试工作项，包括用例设计、用例执行、用例回归与有效性分析等关键过程，量化的粒度取决于公司的原始积累与当前的过程能力成熟度。比方说，在白盒测试中，如果能量化到每N行代码需要有N个用例（或N个测试套件）来驱动基于业务逻辑的充分覆盖（自动化覆盖除外，因为用有效的工具可以实现，但这通常仅局限于语法层面）；在黑盒测试中，通过不同的策略大致对已经划分好的功能模块量化出N组用例集（或称用例框架，其中包含N项子用例，当然这是在测试详细设计时才进行的，量化阶段只要有个大致的参考数据就行了），那这些将很好的为测试计划中资源的分配调度提供依据。当然，在这之前作为测试管理者也应该对所有物件与人件进行规划——物件方面：有多少设备可以共享使用？有多少只能独占使用？有多少场景需要独立的测试环境？一个独立的测试环境中能分配多少有效的资源（比如IP、端口、内存空间、队列堆栈等等）？人件方面：有多少人可以用于测试设计与测试执行？成员因为能力的不同单位时间内设计/执行的用例数也不同，那具体的参考数据是多少（比如单位是“用例/小时”或“用例/天”）？

人件资源量化数据最后再结合上前面总用例的量化数据以及物件资源分配的规划情况，那应该可以估出一个测试过程大致的实施时间，包括计划、设计、执行、回归与有效性分析，这个工作如果能进行的越合理、越充分，那在时间有限的情况下实施的测试其有效性就越高，同时内部风险也越能得到控制。

PS：不好意思，中午休息时间已过，要上班赶项目了，先聊到这吧，以后有空回来再继续补充，希望大家也能多多交流相互的想法与经验，先闪了^^

[ 本帖最后由 迎风 于 2005-11-30 13:49 编辑 ]

black_tulip

还是这样的回答，不知道对于提问者有帮助不。这里很多的回答往往让提问者乍一看觉得有道理有道理，转身想想我怎么按照那道理去做呢？不知道。还是等于没说，其实也不能说没作用，至少玩转了一通理论，面试时往往有用。

“尽可能的量化好” “如果能量化到” “如果能进行的越合理、越充分” 这样的话当然没错，可是我从中还是得不到指导。

既然是周期短，时间紧，我的建议还是不要去想什么流程了，螺旋、瀑布只能让你更加delay。也不要去考虑用例、回归什么的了，还白盒，哪有时间。

楼主已经说了，他们的情况“过多的考虑用什么测试工具和做完备的测试计划来保证软件的质量显然是不太可能的”，所以，质量就只能依赖经验了。

迎风

嗯，也是，如果时间与资源紧到根本无法驱动一次过程相对完整的测试的话，那就干脆忽略所有关键过程，什么计划、设计、分析统统PASS，呵呵，人一到位，简单培训后就直接进行烟雾（即席）测试，然后根据整个项目阶段部署进行按需回归，最后相关领导决策后发布Release版本。不过要能在这种状况下还能保证测试有效性，那么两个前提缺一不可：1、非常有经验的测试人员，经验包括测试专业与被测业务经验；2、有一套轻量级但却流程完整的BUG跟踪工具。

如果连这两个基本的要求都达不到，我只能说：大家尽人事，听天命了……不知大家还有没有什么其他更实质性与可操作性的建议或想法，呵呵～

[ 本帖最后由 迎风 于 2005-12-1 10:57 编辑 ]

xinwuhan2006

谢谢大家的发言，学习了很多！

屠晓蕊

项目周期正常是30、40天，现在我们最多只有6天的时间，而且业务复杂且需求含有大量的术语，请求高人指点，谢谢

jiangfengyu

还是这样的回答，不知道对于提问者有帮助不。这里很多的回答往往让提问者乍一看觉得有道理有道理，转身想想 ...
black_tulip 发表于 2005-12-1 10:09

赞~~比如我遇到的情况，今天还在测试这个项目，明天领导给你说，有个东东开发提测了，给你一周时间搞定。连个系统都没接触过呢，就要开始测试，哪儿有时间找测试资源之类，就自己一个人，只能够尽量熟悉系统，保证系统可用，如果有时间，就继续补充自身认为有风险的测试……实在是纠结~

PS:听领导讲话就是，觉得很有道理，转过头去想想，还是没有个方向。。继续纠结自己去摸索。。

XuMeilingGoOn

挺好,谢谢分享哈