如何在有限的时间内编写完整有效的测试用例

楼主的问题看来只有一句话，但实际包含了很多方面的问题，不同的人文环境、公司文化、公司资质等因素都会产生不同的结果。
分析这个问题，我想先从两个方面回答：
1.如何在有限的时间内完成测试用例
2.如何编写完整有效的测试用例
有限的时间顾名思义工时不足。那么凡事都是有果必有因，解决问题就要先找到其原因，并加以解决，问题就会迎刃而解。
在软件行业中，时间是一个非常重要的概念，时间有限也是经常提到的一个词，归其产生原因不外乎以下几点：
1.项目经理缺乏项目管理经验，对项目工期估计不准确，导致工时吃紧，时间有限。
2.项目开发人员（包括测试小组人员）缺乏实际工作经验或者说知识匮乏，相比之下不能在相等的时间内完成自己的任务，导致时间有限。
3.项目开发周期已经确定，但由于客户的临时需求变更导致的工作量增大，无法继续在规定的时间内完成任务，导致时间有限。
4.社会关系导致的公司内部人员拉帮结派，出现的争功躲弊的人群在有权利条件的基础上为夺取管理阶层对自己的好感，谎报项目的开发周期，致使承诺的工时远远低于实际工时，导致时间有限。
5.其他原因（事假、病假、人员变动、突发事件等）而导致的项目人力资源不足，时间有限。
用CMMI的理念讲以上这些原因就是风险，针对这些风险，就要采用风险识别，风险评估，风险减缓，风险跟踪将问题扼杀在萌芽中。
第一，根据风险检查表，识别出项目的风险（时间不足）
第二，估计风险严重性、风险可能性、风险系数（以上列举的5条分别进行评估）
第三，对于风险系数超过“容许值”的每一个风险，都应采取减缓措施（量化风险的严重性，定义容许值）
第四，跟踪风险减缓过程，记录风险的状态
第五，制定风险解决方案
1.项目经理需提高系统分析能力，增加自身技能水平，提高预测准确度。必要时可以更换。
2.提高工作人员自身技能水平，评估其工作能力，定期考核，安排适当人群执行适当工作。公司提拔的不算。
3.严格控制需求变更，制定需求变更管理，需求发生变更要经过会议评审，必要时员工需加班工作。
4.社会关系复杂，如果想被提拔，升职或加薪那就乖乖的加班工作。
5.减少工作对单人的依赖，保证每份任务必须由两人或两人以上负责，突发事件另作处理。
虽然回答没有针对如何在有限时间内编写测试用例，但以上答案完全可以解决这个问题了。
回答了第一个问题，下面回答第二个问题。说一下怎么样设计完整有效的测试用例
第一，覆盖率100%，保证完整性
第二，对测试环境，用户环境，模拟用户环境，及之间的差别进行描述。
第三，设计场景测试法虚拟业务流程
第四，建立测试公共数据，并根据系统内部关系组织数据的关联性
第五，其他人可以看懂你的用例，并且是可以执行的
第六，如果有标准的用例模板，可以使用用例模板
现在将这两个问题合二为一，不同的问题可以根据给出的答案互相结合找出解决问题的办法。
但是根据我的经验，一般编写测试用例的时间都是很充足的，除非是某些项目为了应付监理公司，临时对项目的相关资料进行补充的时候才会出现这种情况。

============================================================================

aCuZ n@UMp0在测试工作中，“直接拿到软件就测试”的做法曾经很普遍，现今这种情况应该很少了，它只属于那个特定的时期。在回答这个问题之前，我觉得有必要展现这种特殊的情况所处的背景。

._~/U#@gk0×它发生在那个软件开发不规范的年代，软件开发还处于原始的状态；51Testing软件测试网f?A P"okb

×由于不规范，所以不能指望它有完整的开发及测试文档。

-`;U%V3Vl}-h3u0在以上的前提条件下，要在有限的时间内编写有效且完整的测试用例，的确不是一般人可以做到的，对测试人员有特定的要求。

×业务专家型：对软件的业务流程、最终客户的主要使用角色及使用功能都非常熟悉

×精通黑盒测试用例的编写方法

有了符合以上要求的测试人员后，需要特别指定本次测试的主要目的。

1k3{v"uW&G&D0×由于现状的制约，本次测试的主要目的可以定位成：在有限的时间内，站在用户的角度，按照软件最终验收的标准，验证软件的主要功能是否正常；

-@dl!N erLB0×在此基础之上，思考最终用户最有可能的失误或者异常操作，验证在这些条件下，软件是否能够正确处理。

X~Ci9Mj0在测试目的的指引下，然后再确定测试环境以及测试类型的取舍。如

×按照用户最流行的软硬件环境配置，搭建测试环境，配置测试和兼容性测试及其他无关的测试都可以暂时取消；

3G.xM7I3AQ6X0×明确功能测试是重点，压力测试次之。

(b&Er+t(E,m&v0走到这一步，测试人员已经明确了测试的主要目的和要进行哪些测试，就可以按照以下原则来设计测试用例了

×根据验收测试的标准，针对不同类型的软件，按照等价类划分、因果图、场景法等，设计有效测试用例；建议在设计测试数据时，如果有条件，可以多参考最终用户以前的历史数据，把有效的业务流程、有效的场景100%覆盖；

X/m%U&z v ^!E0×上面的完成后，再最大可能的增加一些异常的测试用例，努力覆盖到用户最可能失误的操作或者异常的操作数据或者流程。

基于以上的原则，可以在有限的时间内，编写出“相对”完整且有效的测试用例，而不是“绝对”的

`R^ T*q4F0==============================================================51Testing软件测试网4qA_L3Q

这个话题要拆分开来分析。
一、编写完整的测试用例
二、有效的测试用例
三、在有限的时间内
第一、个人认为，没有一个测试人员可以做到百分之百“完整”！何为“完整”？是测试路径覆盖率100%么？不是！即便覆盖了测试需求的全部功能，又如何保证100%的测试需求不变更、亦或满足了客户的需求呢？测试是保证软件产品的质量。而最“完整”的质量保障或者说测试覆盖，其实应该是满足了客户的当前需求。说白了，其他不是客户想要的质量，可以弱化点，要切入要点进行测试，从而在要害关卡编写测试用例。
第二、何为“有效”？是测试方法正确还是测试策略高深？不是！
1、是基本的测试规则。如同游戏一般需要定义规则，测试需要用标准规范来约束。没有良好的测试规则，恐怕难以称之为“有效”。我以为，从分析测试需求起，就可以同步建立测试模型/模式，开发有他们自己的模型/模式，测试当然也可以使用。譬如用UML来画流程图、活动图，理清测试步骤。或者用RUP的迭代测试，是否会比普通的模型要好些呢？
2、测试用例的根本是设计如何测试，不是测试什么。很多人仅简单把测试操作步骤记录在案，以为就是测试用例，那就错了。测试用例必须应用用例设计思路，保证其有效的结构性，可读性，渗透性。
3、依然是需求变更。倘若测试组无法从项目组及时获取到变更的信息，更有甚至连开发组织也没有对变更做出响应，那么用例肯定是无效的了。
4、测试用例必须进行交流评审。在开发组、测试组和项目总体组负责人员和相关分管岗位人员开会讨论后，最终拍板定案。
第三、时间限制。“有限时间内”这一说法，其实又得看具体情况。一周可以算有限时间，一天亦可以做有限时间结点。具体情况具体分析。通常的做法是：
1、测试管理。我们必须从测试管理机制上考虑，努力改善测试的环境，调整项目的管理流程，为有效的测试争取出时间。
2、工作效率。通过建立测试用例库来节省编写测试用例时间。现在都提倡复用的思想，不是仅代码可以复用、构件可以复用，公用测试用例的复用，可以极大程度，提高测试执行的效率。若把测试用例集应用于自动化工具中，这才是真正的会用工具，减少人工劳动力。
3、明确测试范围，严格按测试计划工作，利用有限的资源做有限的事情，使价值最大化。
4、规避风险。类似需求变更等是最大的风险，当然会影响工作效率，应该趁早定义清楚。

综上，要在有限的时间内编写完整有效的测试用例，所涉及到整个软件开发测试过程的方方面面，不是一两个知识点或者有些经验就可以定义的。而关键还是要明确需求，尽量减少需求变更，否则后续编写的用例，也只是做无功用罢了。

个人拙见，请指正。

相关阅读:

用户菜单

我的栏目

标题搜索

日历

我的存档

数据统计

RSS订阅