如何开展有效的白盒测试
一、
这两天,时常被问到如何开展有效的白盒测试的问题,我很乐意和我的朋友交流,并提出了自己的看法。现在共享出来,如果有不妥之处,请指正
二、
过去众多国内企业的测试,那是--“昨夜西风凋碧树,独上高楼,望尽天涯路”
“衣带渐宽终不悔,为伊消得人憔悴”,“众里寻他千百度,蓦然回首, 那人却在灯火阑珊处”。
“独上高楼,望尽天涯路”
早期,一般企业,为了生存和发展,忍辱负重,披荆斩棘,承受一切流言碎语,需要承接项目。只要项目有了,财源就有了,公司就能存活了。随着,矛盾也产生了——企业抱怨:客户怎么那么多问题,老是改,改的大家都乱糟糟的。客户眉毛也挑起来:怎么能这样子呢,明显不是最初的要求么,如果在不安装要求来,就不在与他们合作了……
诸如此类,云云而生。
想存活的,想发展的,就要逐步的化解这一矛盾,逐步完善自我,走出这一困境。一部分走出来,成佛了。一部分坠落马下,音信全无。一部分依山傍水,寻了个好婆家。
都是为了活着。测试,尤为重要,为的是寻得出路,为的是找出一些根本问题。只要客户验证,没有问题,就万事大吉,至于使用时候出现问题,那是维护时候的事,不可扯的太远。项目经理,如实地教导。
“衣带渐宽终不悔,为伊消得人憔悴”
同样给测试也带来了飞速的跨越。千百次的回眸,不一定,能找出一个Bug来。一个不上心的操作,却能击中系统命门。
三、
1.
v
v
v
v
v
v
v
v
v
v
2.
v
n 如何在纷乱的测试内容之间提炼测试的目标,是制定软件测试计划时首先需要明确的问题
n 测试目标必须是明确的,可以量化和度量的,而不是模棱两可的宏观描述
n 测试目标应该相对集中,避免罗列出一系列目标,从而轻重不分或平均用力
n 根据对用户需求文档和设计规格文档的分析,确定被测软件的质量要求和测试需要达到的目标
n 软件测试计划的价值取决于它对帮助管理测试项目,并且找出软件潜在的缺陷上所起的作用。软件测试计划中的测试范围必须高度覆盖功能需求,测试方法必须切实可行,测试工具并且具有较高的实用性,便于使用,生成的测试结果直观、准确
v
n “What(做什么)”:测试的范围和内容
n “Why(为什么做)”:测试的目的
n “When(何时做)”:开始和结束日期
n “Where(在哪里)”:测试文档和软件的存放位置
n “How(如何做)”:测试的方法和工具
v
n 测试计划写作完成后,如果没有经过评审,直接发送给测试团队,测试计划内容的可能不准确或遗漏测试内容,或者软件需求变更引起测试范围的增减,而测试计划的内容没有及时更新,误导测试执行人员
n 测试计划包含多方面的内容,编写人员可能受自身测试经验和对软件需求的理解所限,而且软件开发是一个渐进的过程,所以最初创建的测试计划可能是不完善的、需要更新的
n 需要采取相应的评审机制对测试计划的完整性、正确性、可行性进行评估。例如,在创建完测试计划后,提交到由项目经理、开发经理、测试经理、市场经理等组成的评审委员会审阅,根据审阅意见和建议进行修正和更新
v
n 编写软件测试计划要避免一种不良倾向是测试计划的“大而全”,无所不包,篇幅冗长,长篇大论,重点不突出,既浪费写作时间,也浪费测试人员的阅读时间。“大而全”的一个常见表现就是测试计划文档包含详细的测试技术指标、测试步骤和测试用例。
n 最好的方法是把详细的测试技术指标包含到独立创建的测试详细规格文档,把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方法和资源配置,而测试详细规格、测试用例是完成测试任务的具体战术。
3.
参看之前发布的信息
确保代码质量,必须严格实施。
4.
Ø
硬件和软件搭配,统筹研发部和相关部门,根据测试计划统筹实施。
Ø
用例文档,阶段文档,等关键的文档必须有本可寻。
Ø
这个根据计划,根据公司情况,可以启用一些比较流行的缺陷跟踪系统。
这个网上很多。
Ø
用例文档和用例代码
Ø
上述管理实施后,人员只要根据计划走就行,不存在任何人离职,使得项目有滞后的情况。对于新人,也有章可查,可以很快熟悉项目测试进展。
5.
自动化测试工具,是一种手段,一种方式。上面的每个阶段,都可以有工具来进行实施。尤其代码规范检查,代码用例管理,缺陷管理等。
推荐实施自动化测试工具,如C++Test,Jtest,Dotest等都是很不错的工具
转载自:http://blog.sina.com.cn/s/articlelist_1154237180_1_1.html