51Testing软件测试论坛

标题: 测试计划（版主帮助!!!） [打印本页]

作者: navysong 时间: 2006-10-26 09:28
标题: 测试计划（版主帮助!!!）
各位大哥：
最近我有一些观念很糊涂，测试计划是不是必须依据单元测试、集成测试、系统测试、验收测试(A&B)分别制定。这几个阶段的测试依据，或许说是测试策略都不同，如果我想把这些阶段都写进一个测试计划可不可以？公司目前并无细分的条件，我是做项目开发兼职管理项目测试的，比如性能测试、安全测试、压力测试公司都不可能提供这样的条件，也没有专用的SERVER。基于这种现实情况，我是不是可以完全忽略这些方面的测试？在测试计划里阐明各测试阶段的方法、测试技术、要求，进度安排，人力资源，各阶段测试停止标准，测试产出、缺陷描述就好了。
总感觉这样的测试计划怪怪的，请各位帮忙出出主意，谢谢！真的很困惑。

作者: navysong 时间: 2006-10-26 10:10
标题: 再问一个问题
再问个问题：
Final Acceptance Test，FAT ，这个是什么类型测试？确认测试？请帮忙解释，项目建议书上的东东

作者: lonewolf 时间: 2006-10-26 11:01
标题: 回复 #1 navysong 的帖子
楼主好像考虑反了吧，测试计划是要整体计划测试阶段工作的，他包括详细的单元、集成、系统、验收测试的相关内容。当然要写进一个计划里，不赞成分开写测试计划。
还有，某些测试没有环境，就上报公司解决，不能计划一套，实际测试又一套。该测试的东西一定要测试到才可以，也就是说没有测试组的同意，软件产品就不可以对外发布。

作者: lonewolf 时间: 2006-10-26 11:05
标题: 回复 #2 navysong 的帖子
FAT是最终release前的验收测试吧。
现在有些客户是这样要求：比如他规定我们要提交1.0给他，他会组织自己公司的人进行几轮评价，最后才Release出去。FAT指的应该是那段时间吧！做外包业务的现在流行这种方法。

作者: xiaonan 时间: 2006-10-26 11:41
整体的项目的测试计划要写,每个阶段的系统测试计划、集成测试计划、单元测试计划也要写.还有测试计划只是属于管理层面的文档，一般由测试经理来制定，它主要关注的是公司内部的组织形式，测试对象，需求跟踪，测试通过和失败的标准，测试挂起和恢复的必要条件，以及测试任务的分配，是写测试方案的指导。它不应该设计技术方面的东西.技术方面的东西应该在测试方案里给予明确说明.测试计划是明确"做什么",而测试方案才是明确"怎么做"

[ 本帖最后由 xiaonan 于 2006-10-26 11:43 编辑 ]

作者: 云淡风轻 时间: 2006-10-26 12:12
楼上让我茅塞顿开～sdlkfj3

作者: navysong 时间: 2006-10-26 12:22
回复xiaonan版主
谢谢xiaonan的帮助，受教了，概念上清晰了很多。我还有点疑惑

测试计划确实是管理文档，定义做什么，但是测试计划里应该加入测试策略吧，测试策略就定义了测试的技术和工具，这又如何理解呢？如果只是编写测试计划做为管理者参考的依据，那又如何计划测试任务呢？

是不时可以这样认为，项目整体的测试计划重点是对整个项目计划测试任务上，明确计划测试的流程。
而系统测试计划、集成测试计划、单元测试计划就需要跟据具体的阶段进行撰写。比如系统测试的累积和回归测试，是不时可以根据具体条件选择需要进行的测试。在人力资源紧张、项目进度紧急的情况下进行单元测试，是否可以只进行UI测试、功能测试，不进行结构性测试，这样风险大吗？

作者: navysong 时间: 2006-10-26 12:25
标题: 回复lonewolf
谢谢你的帮助，我们公司没有专门的测试组。所以我说自己是做开发兼职带领开发人员作测试的，也是摸着石头过河，
危险！
呵呵，希望能跟大家多多学习，快快进步！

作者: swallow0918 时间: 2006-10-26 14:29

原帖由 navysong 于 2006-10-26 12:22 发表
回复xiaonan版主
谢谢xiaonan的帮助，受教了，概念上清晰了很多。我还有点疑惑

测试计划确实是管理文档，定义做什么，但是测试计划里应该加入测试策略吧，测试策略就定义了测试的技术和工具，这又如何理解 ...

"测试策略"在测试方案中注明。测试计划是管理层对测试进度等的总体把握，侧重于“这个测试能做什么”。而在测试方案中才具体说明测试如何进行，使用什么技术和工具等。但现在很少有公司能做到测试计划和测试方案分开来写的，基本就定义为一个文档来维护。所以对于还不是很完善的测试组人员来说，可以把测试计划和测试方案合并一起写。

作者: navysong 时间: 2006-10-26 14:57

原帖由 swallow0918 于 2006-10-26 14:29 发表

"测试策略"在测试方案中注明。测试计划是管理层对测试进度等的总体把握，侧重于“这个测试能做什么”。而在测试方案中才具体说明测试如何进行，使用什么技术和工具等。但现在很少有公司能做到测试 ...

明白了，前些时间看了一些其他人写的测试计划模版，大体都是把测试计划与测试方案放在一起写。现在感觉写测试计划更困难了，写出来别人还以为你花了一个周，
甚至一个月写的测试计划就只是个改改格式的文档而已，虽然我主要是做开发的，但现在我更加佩服各位了。对测试有了些了解，更知道做测试的辛苦与挑战，希望我
也能在测试这块有所发展！

请问有没有纯粹意义上的测试计划模版，不包含测试方案、技术什么的，我参考一下。谢谢！

作者: xiaonan 时间: 2006-10-26 15:09
单元测试主要测试单元内部的数据结构,逻辑控制,异常处理等.它不需要关心整个单元的功能有没有实现,而是确认内部逻辑是否符合详细设计书的要求.

作者: navysong 时间: 2006-10-26 15:29

原帖由 xiaonan 于 2006-10-26 15:09 发表
单元测试主要测试单元内部的数据结构,逻辑控制,异常处理等.它不需要关心整个单元的功能有没有实现,而是确认内部逻辑是否符合详细设计书的要求.

非常感谢，我一直搞不清楚异常处理、日志记录应放于那个测试阶段，现在清晰了很多，但这样单元测试是不是只能用结构性即白盒测试的方法了呢？

作者: xiaonan 时间: 2006-10-26 15:49
对,一般单元测试都用白盒测试法来测.

作者: navysong 时间: 2006-10-26 16:29

原帖由 xiaonan 于 2006-10-26 15:49 发表
对,一般单元测试都用白盒测试法来测.

谢谢指教。我已决定单元测试用灰盒了，因为人力资源与进度的问题，再加上全是项目组自己测试，其他同仁可能没有能力做好白盒测试，前段时间我
学习了NUnit，写了些断言跟MOck对象来测试，想用Nunit做项目的单元测试，可是其他同仁都说太难，他们听都没听明白，我只能退而求其次了。

出于这样的情况，（我们的项目基于C\S架构的Windows Form 开发，使用.Net 平台，C#，ADO2.0）想再问一下，如何写Test case 最大限度的完成单元的数据结构、逻辑测试等的覆盖，是否不采用白盒测试，不编写驱动类进行测试就没法完成，甚至无法进行单元测试？
问这么多，希望没有麻烦到你。

作者: xiaonan 时间: 2006-10-26 16:35
如果没深入到单元函数的语句,路径,判断等覆盖率,怎么能保证单元测试的效果呢?

作者: navysong 时间: 2006-10-26 17:21

原帖由 xiaonan 于 2006-10-26 16:35 发表
如果没深入到单元函数的语句,路径,判断等覆盖率,怎么能保证单元测试的效果呢?

我明白你的意思，也是我测试计划一直难以下手的原因，在国内很多项目开发模式都有这样的问题，质量难以保证。理想的想法是要保证在每个测试阶段达到预期的效果。单元测试的覆盖率，理应判断到一个方法、一个判断、一个分支去。
但是如果现实情况不允许，比如你有的测试人员全都没有经验，而又必须进行单元测试，那能否有一些折中的办法呢？
我觉得追求严格、完美的模式是一种严肃认真的工作态度，非常好！但也需要变通，所以我一直在思考能否在少进行白盒测试情况下达到期望的效果。
或许这有些困难，但却是现实的要求，除非不进行单元测试。

作者: xiaonan 时间: 2006-10-26 17:36
呵呵,对,楼主对现实的测试环境还是比较了解的.现在能真正做完全做规范的公司可能并不是很多.还是要根据自己公司的情况,来制定符合自己公司能力的流程才是最好的.当然好的流程,是我们努力的方向

作者: navysong 时间: 2006-10-26 17:43

原帖由 xiaonan 于 2006-10-26 17:36 发表
呵呵,对,楼主对现实的测试环境还是比较了解的.现在能真正做完全做规范的公司可能并不是很多.还是要根据自己公司的情况,来制定符合自己公司能力的流程才是最好的.当然好的流程,是我们努力的方向

恩，今天谢谢你的帮助，受益很多，在公司没有交流的对象，以后多来向大家学习！
我对测试越来越感兴趣，不知道像我这样做开发的，朝测试发展会怎样？项目组还让我搞QA，真是为难呢！
xiaonan 版主，向你这样的测试功底，需要多长的积累呀？

作者: xiaonan 时间: 2006-10-26 18:05
开发转测试,应该说有一点优势,但还需对测试的理论,技术,流程等方面多一些了解.还有QA和测试是两个概念.QA是从流程上保证软件的质量.而测试是从技术上保证软件的质量.我也还需要很多的积累,也在不断学习的过程中

作者: AlexanderIII 时间: 2006-10-26 19:27
这个贴子不错,挺一挺

作者: navysong 时间: 2006-10-27 09:17

原帖由 xiaonan 于 2006-10-26 18:05 发表
开发转测试,应该说有一点优势,但还需对测试的理论,技术,流程等方面多一些了解.还有QA和测试是两个概念.QA是从流程上保证软件的质量.而测试是从技术上保证软件的质量.我也还需要很多的积累,也在不断学习的过程中

呵呵，大家都需要一起努力，不掌握新技术就要被新技术淘汰。我们项目组目前差很多人，所以要我
身兼几职。QA和Test，个人认为QA注重过程，不应注重形式，什么CMMI，真正有这个流程保证的有几个，最后产出只是一个文档，并没有
产生整个流程的反应。Test应该关注工艺。好像论坛上有人说QA是动口，Test是动手，我觉得比较贴切。

顺便说一下，开发一些简单的测试工具，应该从哪些方面入手？因为使用过Nunit以后，我就感觉如果把断言封装起来，用GUI形式来写断言，效率更高。

作者: Joan2005 时间: 2007-4-3 16:44
这样的帖子要收藏

作者: 摆饐ＰǎＳe 时间: 2007-4-5 11:31
虽然我没有丰富的测试经验，但是好帖要帮忙顶顶的。。

LZ加油！~~

作者: madduck 时间: 2007-4-7 01:10

原帖由 lonewolf 于 2006-10-26 11:01 发表
楼主好像考虑反了吧，测试计划是要整体计划测试阶段工作的，他包括详细的单元、集成、系统、验收测试的相关内容。当然要写进一个计划里，不赞成分开写测试计划。
还有，某些测试没有环境，就上报公司解决，不能 ...

“测试计划是要整体计划测试阶段工作的”。那测试计划应该是在哪个阶段开始写的呢，要有哪些资料呢？我也是很迷糊呀。

[ 本帖最后由 madduck 于 2007-4-7 01:12 编辑 ]

作者: 厍仕杰 时间: 2007-4-9 17:11
测试计划在项目需求来了后就开始编写基本是与开发同步的
在开发末期所有的测试计划和书表以及用例全部设计完成
当然也分什么样子的项目不同而然资料的话你可以在BBS里面搜索

作者: dbq231 时间: 2007-4-10 11:21
有事没事顶一下

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)