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