关于测试用例的一些想法
“测试用例”软件测试人员必备技能之一。目前国内应该没有几家公司能够规范的按照软件工程的流程来生产软件产品。
对于“测试用例”部分我常常遇到的窘境：
1、项目时间紧，没有“详细设计”甚至“概要设计”阶段。
2、软件界面，小功能点变化大，往往反复维护用例。
3、人员配备不足，人员素质参差不齐。
4、测试时真正按照执行用例的少。
我常常想“要是没有测试用例多好啊”，我自己也知道很愚昧的想法。
想了一个办法，针对中小企业，测试制度不健全、人员、时间不充裕的情况。减少“测试用例”编写、维护，同时保证产品质量。
前提：
测试组中一定要有业务高手。
测试组一定要参与到需求中。
方法：
测试组人员要对常规测试方法了如指掌，常规窗体，控件，界面测试不写用例。
只写主要业务流程的测试用例（主要业务流程一般不会变）。
大家觉得怎么样，提提意见。 每次开需求讨论会我们测试人员都必须要参加！
对整个系统、对每个功能点要做到比开发人员更熟悉！ 对测试经验较少的人员，不可能一下做到对常规测试方法了如指掌，最好能有一个测试检查对照单．
回复 3# 的帖子
要看分工了，可以让新人作一些简单的界面测试，如看错字，界面是否统一之类的。 拖拉机：你们是所有测试人员都参加还是相关的测试人员参加。
如果中途有人员变更咋办？
我很头疼这事 我觉得应该是适人而用，对于新人应该让多学多问！
回复 6# 的帖子
是啊，应该这样，但是有时候会担心质量出问题，毕竟新手的能力有限，需要付出代价。 如果经常有人员变更就需要有测试用例的指导，否则项目的质量就无从谈起。如果时间比较紧，所有功能模块的用例不可能完全写好，这样我认为是可以先只写项目主要的业务流程的。但就有这样的问题，一个项目经过几个版本下来，主要的流程基本没变，因此经过多个版本的磨练，按照测试用例来测试的话紧本上是找不到问题的。所以测试前还需要把握每一版本每一轮的测试重点，重点测试新加的功能和改动过的地方。如果时间紧完成不了案例，可以针对项目先编写测试需求点，将所有测试点都要覆盖。这样，测试的步骤就可以靠测试人员来发挥了。
另外，楼主说的“测试组人员要对常规测试方法了如指掌，常规窗体，控件，界面测试不写用例”想法是可以，但关键是怎么实现。给个建议，平时可以在测试没那么忙时总结一下测试经验，如总结一下UI测试的指导书，通过长期的积累，就可以做到不写案例，测试人员都指导该如何去测试了。
都只是个人意见，欢迎交流。。
回复 8# 的帖子
我也是才有这个想法，没有付诸实践，毕竟更改测试流程需要谨慎。但是目前我公司的情况来看，按照软件工程那么干，根本不现实。只能出此下策。还请大家多多指导我。项目紧，没有详细设计阶段，如何去保证测试用例？
页:
[1]
