• 软件测试技术
  • 软件测试博客
  • 软件测试视频
  • 开源软件测试技术
  • 软件测试论坛
  • 软件测试沙龙
  • 软件测试资料下载
  • 软件测试杂志
  • 软件测试人才招聘
    暂时没有公告

字号: | 推荐给好友 上一篇 | 下一篇

改进自动化测试套件的可维护性(四)

发布: 2010-6-22 10:47 | 作者: 不详 | 来源: 领测测试网采编 | 查看: 10次 | 进入软件测试论坛讨论

领测软件测试网

  Even though we all agreed on this in principle, we had examples of disorganized or poorly thought out test matrices, etc. If you do a poor job of design, no one will be able to understand or maintain what you’ve done.

  虽然我们原则上都同意以上观点,但是我们还是能举出组织不好或思考不周的测试矩阵。如果你的设计工作做的不好,那么没有人会理解并维护你做的东西。

  21. There can be multiple interfaces to enter data into a data file that drives data-driven testing. You might pick one, or you might provide different interfaces for testers with different needs and skill sets. (Consensus)

  有多个接口可以把数据输入到数据文件中,以驱动数据驱动测试。你可以选择一个,或者为不同需要和技术的测试者提供不同的接口。(一致同意)

  Framework-driven approach

  框架驱动方法

  For a while, the framework discussion turned into an extended discussion of the design of a procedural language, and of good implementation practices when using a procedural language. We grew tired of this, felt that other people had tackled this class of problem before, and we edited out most of this discussion from our agreements list. I’ve skipped most of the remaining points along these lines. Here are a few framework-specific suggestionss:

  在一段时间里,对框架的讨论变成了讨论设计过程语言以及良好实现过程语言的延伸。我们对此变得厌倦了,觉得已经有人在以前解决了这类问题,并且我们已经从我们的协议列表中删去了这个议题。我省略了沿着这条思路下去的多数要点。以下是一些针对框架的建议:

  22. The degree to which you can develop a framework depends on the size / sophistication of your staff. (Consensus).

  是否开发框架取决于你的员工的数量和熟练程度。(一致同意)

  23. When you are creating a framework, be conscious of what level you are creating functions at. For example, you could think in terms of operating at one of three levels:

  当创建一个框架时,要注意你在哪个级别上创建函数。例如,你可以考虑下面三种级别之一:

  menu/command level, executing simple commands; 菜单/命令级,执行简单命令

  object level, performing actions on specific things; 对象级,对具体事物实行操作

  task level, taking care of specific, commonly-repeated tasks. 任务级,负责具体的经常反复执行的任务

  You might find it productive to work primarily at one level, adding test cases for other levels only when you clearly need them.

  你会发现主要在一个级别上工作是高效的。所以,只有当你明确了需要在其它级别上添加测试用例后,才可以这么做。

  There are plenty of other ways to define and split levels. Analyze the task in whatever way is appropriate. The issue here is that you want to avoid randomly shifting from creating very simple tests to remarkably long, complex ones. (Consensus)

文章来源于领测软件测试网 https://www.ltesting.net/


关于领测软件测试网 | 领测软件测试网合作伙伴 | 广告服务 | 投稿指南 | 联系我们 | 网站地图 | 友情链接
版权所有(C) 2003-2010 TestAge(领测软件测试网)|领测国际科技(北京)有限公司|软件测试工程师培训网 All Rights Reserved
北京市海淀区中关村南大街9号北京理工科技大厦1402室 京ICP备2023014753号-2
技术支持和业务联系:info@testage.com.cn 电话:010-51297073

软件测试 | 领测国际ISTQBISTQB官网TMMiTMMi认证国际软件测试工程师认证领测软件测试网