(事项)?:我们编写测试用例,有如下的好处:便于团队交流:假如说一个测试团队有10个成员,大家测试的时候都各自为政,没有统一的标准,测试的效率无疑会大打折扣;如果大家都遵循统一的用例规范去写,就会解决这一问题。便于重复测试:大家知道,软件在实际开发过程中是会有不同版本的,,那么如果不写测试用例的话,,?测试用例就像一个备忘录一样,便于重复测试。便于跟踪统计:这一点是针对测试经理或是项目经理来说的,项目负责人通过看测试用例的执行情况,就能了解到项目目前的概况,比如已经执行了哪些测试,还有哪些测试没有执行,测试没有通过的地方主要集中在哪些模块等。便于用户自测:尤其是项目软件,有的时候用户希望自己测试一下软件产品,但是用户大都是非专业人士,他需要根据你写好的用例来更好的检验产品的质量说了这么多编写测试用例的优点,那它有没有缺点呢?有一个明显的缺点就是需要花费大量的时间,通常编写测试用例的时间比实际执行测试的时间还要长,?一个良好的需求应当具有一下特点:完整性:每一项需求都必须将所要实现的功能描述清楚,以使开发人员获得设计和实现这些功能所需的所有必要信息。正确性:每一项需求都必须准确地陈述其要开发的功能。一致性:一致性是指与其它软件需求或高层(系统,业务)需求不相矛盾。可行性:每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。无二义性:对所有需求说明的读者都只能有一个明确统一的解释,由于自然语言极易导致二义性,所以尽量把每项需求用简洁明了的用户性的语言表达出来。健壮性:需求的说明中是否对可能出现的异常进行了分析,并且对这些异常进行了容错处理。必要性:“必要性”可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入,如UseCase或别的来源。可测试性:每项需求都能通过设计测试用例或其它的验证方法来进行测试。可修改性:每项需求只应在SRS中出现一次。这样更改时易于保持一致性。另外,使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。可跟踪性:应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链,这种可跟踪性要求每项需求以一种结构化的,粒度好(fine-grained)的方式编写并单独标明,而不是大段大段的叙述。?软件本地化测试的目的:软件本地化测试的测试策略:。,作为对比测试。。。。四款主流测试工具的测试流程主流测试工具的测试流程========winrunner1启动时选择要加载的插件2进行一些设置(如录制模式等)3识别应用程序的GUI,即创建map(就是学习被测试软件的界面)4建立测试脚本(录制及编写)5对脚本除错及调试(保证能够运行完)6插入各种检查点(图片,文字,控件等)7在新版应用程序中执行测试脚本8分析结果,回报缺陷=========quicktestpro========1准备录制打开你要对其进行测试的应用程序,并检查QuickTest中的各项设置是否适合当前的要求。2进行录制打开QuickTest的录制功能,按测试用例中的描述,操作被测试应用程序。3编辑测试脚本通过加入检测点、参数化测试,以及添加分支、循环等控制语句,来增强测试脚本的功能,使将来的回归测试真正能够自动化。4调试脚本调试脚本,检查脚本是否存在错误。5在回归测试中运行测试在对应用程序的回归测试中,通过QuickTest回放对应用程序的操作,检验软件正确性,实现测试的自动化进行。6分析结果,报告问题查看QuickTest记录的运行结果,记录问题,报告测试结果。====TestDirect============安装好后,先进入站点管理1创建域及工程2添加用户3编辑licenses及本服务器4编辑数据库--TD1选择新建的工程进行定制(列表,用户,组,版本等)2在require中增加需求3把需求转化为plan4在testlab中由计划新建测试具体用例与执行5发现bug,在defect中提交bug(每一部分都可以相对独立地使用)======loadrunner1制定负载测试计划(分析应用程序,确定测试目标,计划怎样执行LoadRunner)2开发测试脚本(录制基本的用户脚本,完善测试脚本)3创建运行场景(选择场景类型为ManualScena
软件测试面试题集合整理 来自淘豆网m.daumloan.com转载请标明出处.
