第一篇：编写测试用例和测试计划
第六章 编写测试用例和测试计划
主要内容：软件测试计划；软件测试方案；软件风险分析
1.软件测试计划
1.1 软件测试计划的简介
1测试计划概念：测试计划在测试中处于中心位置，它阐述了测试准备工作和执行测试的必要条件，同时也形成了测试过程质量保证的基础。
2测试计划的作用：组织和管理测试；使测试工作和整个开发工作整合起来；资源和变更事先最为一个可控制的风险。
1.2 如何编写软件测试计划
1认识测试项目不仅仅只有单一测试计划
2避免不分析直接进行测试阶段日程安排
3避免测试任务的安排超前于开发任务
4避免有些系统测试类型无法按期进入测试
5不正确的变更测试计划
6测试计划里明确更新周期和暂停测试原则
7测试计划不是一成不变的1.3 测试计划包括：简介，目的，范围，测试策略，进度，缺陷的严重程度的定义，风
险分析。
2.软件测试方案
2.1 软件测试方案的概念
软件测试方案描述测试的特征，测试的方法，测试环境的规划，测试工具的设计和选择，测试用例的设计方法，测试代码的设计方案。即包括以下几点：
明确测试策略（黑盒，白盒，灰盒等）
细化测试特征
测试用例的规划
测试环境的规划
自动化测试框架的设计
测试工具的设计和选择
2.2 软件测试计划于软件测试方案的区别
测试计划是组织管理层面的文档。测试方案是技术层面的文档。
测试方案需要在测试计划的指导下进行，测试计划提出“做什么”，测试方案明确“怎么做”
回报的对象不同，测试计划向领导汇报，测试方案是组员共享该文档
3.软件测试的风险
软件需求风险
人员的风险
测试环境的风险
测试工程师对产品的业务不熟悉
补充：
回归测试：把以前检查过的已经修复好的缺陷，拿来另测看有无带来新的缺陷 反侧：把开发人员已经处理的缺陷拿来测，看是否修复
第二篇：测试用例的编写总结
在网上看到这篇文章很好，和大家分享一下：
在我的个人邮箱和MSN上，通常同行都问我类似下面这样的问题：
１、一个测试用例要写到什么程度才比较好?
２、刚开始做测试的时候，你是怎么学习写测试用例的？
３、你对黑盒测试用例的编写的体会是什么？有什么好的版本或者标准吗？
对于测试用例，而我目前正在思考的问题是：怎么写出对公司有价值的测试用例，对公司来说，怎么测试才是最有价值的测试？
下面先来分析第一个问题吧：一个测试用例要写到什么程度才比较好？
这个问题，没有定语，没有说是在什么样的一个情况下，因此我这里只能就我工作中碰到的情况说说了。说起来比较长阿，大家要有耐心看才行哈。^_^
在我测试工作中，碰上的测试类型我自己划分成这么４种：项目的测试，产品的测试，产品个性化的测试，第三方验收测试。项目的测试指的是我所测试的软件是一个项目，是某一个具体用户使用的。产品的测试指的是我所测试的软件是一个通用产品，是供很多用户使用的。产品个性化测试指的是我所测试的软件是某一用户在使用产品时，提出了特殊的功能，针对这些新功能，对产品针对用户进行了个别修改。第三方验收测试大家都应该很熟悉了，这里就不需要做解释了。
对项目、产品的测试，测试的时候通常要考虑这个项目的周期和测试资源。我所在的公司，通常项目开发时间都很短４到５个月，然而测试通常都是在开发即将结束的时候才真正介入。测试就是１个人负责。因此时间和人力资源对测试来说是完成测试工作的一个风险。为此在这种情况下，我都是先熟悉系统的业务，把握重点业务和功能后，参考需求，把测试需求、测试计划和测试大纲给制定好。由于时间关系，测试用例都是先写重点的业务，也就是集成测试的测试用例。另外测试用例是根据测试大纲来的。通常都是先挑最重要的测试项和风险大的业务功能编写测试用例。
由于测试用例是本人执行，所以测试用例可以写的简单些，但是一定要开发人员能够看明白。可惜我所在的公司，都没有人来看我的测试用例。测试用例对我来说是用来提示我不要忘记了要测试哪些项。一些很有价值的bug通常不是在写测试用例的时候发现的，而是在测试软件的过程中，我在家睡觉前的思考和回家的路上思考出来的。这就是手动测试的魅力，有些软件的缺陷是在你使用软件的一瞬间和思考的一刹那突然发现的。所以要我回答测试用例要写到什么程度才比较好，我觉的只要你所写的测试用例在你的公司能够顺利的执行，不影响你的测试执行工作就可以了。因为测试用例写的太详细，你要花费时间和人力成本，这样出来的测试用例是最好的也是最贵的，一旦需求变更，也需要修改，这时你会发现这种详细的测试用例是最不挣钱的。测试用例写的太粗，别人看不懂，不能执行，那你要花费你的时间去解释，这就加大了测试的工作量。这也不是好的方法。
第二个问题，刚开始做测试的时候，你是怎么学习写测试用例的？
我之所以选择测试这个工作是因为：我毕业后，在第一家公司做技术支持，产品的问题很多，导致技术支持工作很辛苦、很累。为了让用户买到的产品的质量是好的，我选择了做测试，到了现在的公司。我刚做测试的时候，对测试一无所知，什么测试流程阿、文档阿都不知道，公司的测试和管理也不规范。对测试，大家都认为不就是拿个鼠标点来点去，谁都可以来做。为此，我经常上网查测试的资料，看看自己到底适合不适合做测试，测试到底是什么样的一个职业，怎么去规划自己的个人发展。其实要做好测试，真是不容易。不喜欢，真是不能做这个职业。
现在想想自己刚开始写测试用例的时候，真是好笑。就像小孩子学习写字一样。先是在网上狂搜索了一把测试用例的模板，综合了几个，就形成了。我之所以不用公司原有的测试用例模板，是因为太不适用了。还好，公司没有严格要求必须要那个模板，只要适用就行。模板找好了，可是写就费劲了。对于刚做测试的新人，看似简单的一个填表工作，要写好真是不简单。一开始写的比较不自然，有些生搬硬套，而且还很慢。没有办法，那时候没有人指导我，全靠自己自学和领悟，所以那段日子很苦阿！多写几次后，就知道和领悟了，测试用例要根据测试大纲来写，测试大纲要根据测试计划来写。测试大纲更多的是把握住测试项的方向，而测试用例是指导怎么去执行测试。还好，我有编程的经验，所以对我熟悉软件帮了一个很大的忙。熟悉了软件的业务才能去写测试用例，才能更好的去测试。这也是我一点一点的领悟出来的。说了这么多，不知道这样的回答是否是回答了这个问题。
最后一个问题了，我尽量少写些，文字太多了大家看的也累，我写的也累。嘿嘿。^_^
你对黑盒测试用例的编写的体会是什么？有什么好的版本或者标准吗？
我的体会：
１、测试用例要根据测试大纲来编写
２、测试用例也要分测试项进行归类，这样比较好分析和阅读。如：业务流程测试、安装测试、功能测试、用户友好性测试、兼容性测试、性能测试、安全性测试等等。
３、编写测试用例要考虑各种情况，精力主要集中在软件的主要业务流程和风险高的地方。能分出测试优先级别就最好了。
４、熟悉系统，对编写测试用例很有帮助。
５、即使对测试很熟悉了，在时间非常紧的时候，编写测试用例还是很有必要和好处的。
第三篇：编写测试用例方法心得体会
由安博测试空间技术中心http://www.xiexiebang.com/提供
编写测试用例方法心得体会
编写背景：
一直以来都不太想把技术方面的文章写出来给大家看，一个是怕写作功底不好误导哪些刚入门的测试同行，自己的表达能力有限，另一方面怕有的同行拿出去炒作，再者测试网站论坛上关于测试用例的资料已经实在是多。但是看到同行纷纷都在问我测试用例的问题，都很想知道我写测试用例的心得体会。我就抱着试试看的心态写写吧，希望测试的老前辈看见了，可以给我多提提建议。
编写测试用例方法心得体会
在我的个人邮箱和MSN上，通常同行都问我类似下面这样的问题：
１、一个测试用例要写到什么程度才比较好?
２、刚开始做测试的时候，你是怎么学习写测试用例的？
３、你对黑盒测试用例的编写的体会是什么？有什么好的版本或者标准吗？
对于测试用例，而我目前正在思考的问题是：怎么写出对公司有价值的测试用例，对公司来说，怎么测试才是最有价值的测试？
下面先来分析第一个问题吧：一个测试用例要写到什么程度才比较好？
这个问题，没有定语，没有说是在什么样的一个情况下，因此我这里只能就我工作中碰到的情况说说了。说起来比较长阿，大家要有耐心看才行哈。^_^ 在我测试工作中，碰上的测试类型我自己划分成这么４种： ^
对项目、产品的测试，测试的时候通常要考虑这个项目的周期和测试资源。我所在的公司，通常项目开发时间都很短４到５个月，然而测试通常都是在开发即将结束的时候才真正介入。测试就是１个人负责。因此时间和人力资源对测试来说是完成测试工作的一个风险。为此在这种情况下，我都是先熟悉系统的业务，把握重点业务和功能后，参考需求，把测试需求、测试计划和测试大纲给制定好。由于时间关系，测试用例都是先写重点的业务，也就是集成测试的测试用例。另外测试用例是根据测试大纲来的。通常都是先挑最重要的测试项和风险大的业务功能编写测试用例。由于测试用例是本人执行，所以测试用例可以写的简单些，但是一定要开发人员能够看明白。可惜我所在的公司，都没有人来看我的测试用例。测试用例对我来说是用来提示我不要忘记了要测试哪些项。一些很有价值的ｂｕｇ通常不是在写测试用例的时候发现的，而是在测试软件的过程中，我在家睡觉前的思考和回家的路上思考出来的。这就是手动测试的魅力，有些软件的缺陷是在你使用软件的一瞬间和思考的一刹那突然发现的。所以要我回答测试用例要写到什么程度才比较好，我觉的只要你所写的测试用例在你的公司能够顺利的执行，不影响你的测试执行工作就可以了。因为测试用例写的太详细，你要花费时间和人力成本，这样出来的测试用例是最好的也是最贵的，一旦需求变更，也需要修改，这时你会发现这种详细的测试用例是最不挣钱的。测试用例写的太粗，别人看不懂，不能执行，那你要花费你的时间去解释，这就加大了测试的工作量。这也不是好的方法。
第二个问题，刚开始做测试的时候，你是怎么学习写测试用例的？
我之所以选择测试这个工作是因为：我毕业后，在第一家公司做技术支持，产品的问题很多，导致技术支持工作很辛苦、很累。为了让用户买到的产品的质量是好的，我选择了做测试，到了现在的公司。我刚做测试的时候，对测试一无所知，什么测试流程阿、文档阿都不知道，公司的测试和管理也不规范。对测试，大家都认为不就是拿个鼠标点来点去，谁都可以来做。为此，我经常上网查测试的资料，看看自己到底适合不适合做测试，测试到底是什么样的一个职业，怎么去规划自己的个人发展。其实要做好测试，真是不容易。不喜欢，真是不能做这个职业。
现在想想自己刚开始写测试用例的时候，真是好笑。就像小孩子学习写字一样。先是在网上狂搜索了一把测试用例的模板，综合了几个，就形成了。我之所以不用公司原有的测试用例模板，是因为太不适用了。还好，公司没有严格要求必须要那个模板，只要适用就行。模板找好了，可是写就费劲了。对于刚做测试的新人，看似简单的一个填表工作，要写好真是不简单。一开始写的比较不自然，有些生搬硬套，而且还很慢。没有办法，那时候没有人指导我，全靠自己自学和领悟，所以那段日子很苦阿！多写几次后，就知道和领悟了，测试用例要根据测试大纲来写，测试大纲要根据测试计划来写。测试大纲更多的是把握住测试项的方向，而测试用例是指导怎么去执行测试。还好，我有编程的经验，所以对我熟悉软件帮了一个很大的忙。熟悉了软件的业务才能去写测试用例，才能更好的去测试。这也是我一点一点的领悟出来的。说了这么多，不知道这样的回答是否是回答了这个问题。
最后一个问题了，我尽量少写些，文字太多了大家看的也累，我写的也累。嘿嘿。^_^ 你对黑盒测试用例的编写的体会是什么？有什么好的版本或者标准吗？ 我的体会：
１、测试用例要根据测试大纲来编写
２、测试用例也要分测试项进行归类，这样比较好分析和阅读。如：业务流程测试、安装测试、功能测试、用户友好性测试、兼容性测试、性能测试、安全性测试等等。
３、编写测试用例要考虑各种情况，精力主要集中在软件的主要业务流程和风险高的地方。能分出测试优先级别就最好了。
４、熟悉系统，对编写测试用例很有帮助。
５、即使对测试很熟悉了，在时间非常紧的时候，编写测试用例还是很有必要和好处的。
今天就想到那么些了，以后想到了在补充上了。我把我用的模板给你们粘贴一份上来，只能给你们做些参考，具体还是要看对你所在的公司适用不适用。测试项的归类我就不列举了，因为每个公司的都不太一样。
北京测试空间科技发展有限公司是注册于北京市海淀区高新技术园的软件企业，目前主要业务范围包括软件测试管理 工具研发、软件测试项目外包和软件测试专业技术人才培养及派遣。在软件测试管理工具研发领域已成功开发具有
自主知识产权的STMP管理软件。在软件测试项目外包领域已建立广泛的业务渠道，服务客户包括北大软件工程中心、东软股份、海辉高科、用友软件、莱博智科技、电子部5所、11所，航天704所、中国金融认证管理中心、国安创想、清华同方、中软融鑫、长峰科技等100余家企业，项目覆盖行业包括军工、航天、金融、通信等领域。由安博测试空间技术中心http://www.xiexiebang.com/提供 地址：北京市海淀区学院路40号大唐电信测试空间楼 联系电话：010-62303223 62303260 62303230
第四篇：编写测试用例方法心得体会
编写测试用例方法心得体会
编写背景：
一直以来都不太想把技术方面的文章写出来给大家看，一个是怕写作功底不好误导哪些刚入门的测试同行，自己的表达能力有限，另一方面怕有的同行拿出去炒作，再者测试网站论坛上关于测试用例的资料已经实在是多。但是看到同行纷纷都在问我测试用例的问题，都很想知道我写测试用例的心得体会。我就抱着试试看的心态写写吧，希望测试的老前辈看见了，可以给我多提提建议。
编写测试用例方法心得体会
在我的个人邮箱和MSN上，通常同行都问我类似下面这样的问题：
１、一个测试用例要写到什么程度才比较好?
２、刚开始做测试的时候，你是怎么学习写测试用例的？
３、你对黑盒测试用例的编写的体会是什么？有什么好的版本或者标准吗？
对于测试用例，而我目前正在思考的问题是：怎么写出对公司有价值的测试用例，对公司来说，怎么测试才是最有价值的测试？
下面先来分析第一个问题吧：一个测试用例要写到什么程度才比较好？
这个问题，没有定语，没有说是在什么样的一个情况下，因此我这里只能就我工作中碰到的情况说说了。说起来比较长阿，大家要有耐心看才行哈。^_^ 在我测试工作中，碰上的测试类型我自己划分成这么４种： ^
对项目、产品的测试，测试的时候通常要考虑这个项目的周期和测试资源。我所在的公司，通常项目开发时间都很短４到５个月，然而测试通常都是在开发即将结束的时候才真正介入。测试就是１个人负责。因此时间和人力资源对测试来说是完成测试工作的一个风险。为此在这种情况下，我都是先熟悉系统的业务，把握重点业务和功能后，参考需求，把测试需求、测试计划和测试大纲给制定好。由于时间关系，测试用例都是先写重点的业务，也就是集成测试的测试用例。另外测试用例是根据测试大纲来的。通常都是先挑最重要的测试项和风险大的业务功能编写测试用例。由于测试用例是本人执行，所以测试用例可以写的简单些，但是一定要开发人员能够看明白。可惜我所在的公司，都没有人来看我的测试用例。测试用例对我来说是用来提示我不要忘记了要测试哪些项。一些很有价值的ｂｕｇ通常不是在写测试用例的时候发现的，而是在测试软件的过程中，我在家睡觉前的思考和回家的路上思考出来的。这就是手动测试的魅力，有些软件的缺陷是在你使用软件的一瞬间和思考的一刹那突然发现的。所以要我回答测试用例要写到什么程度才比较好，我觉的只要你所写的测试用例在你的公司能够顺利的执行，不影响你的测试执行工作就可以了。因为测试用例写的太详细，你要花费时间和人力成本，这样出来的测试用例是最好的也是最贵的，一旦需求变更，也需要修改，这时你会发现这种详细的测试用例是最不挣钱的。测试用例写的太粗，别人看不懂，不能执行，那你要花费你的时间去解释，这就加大了测试的工作量。这也不是好的方法。
第二个问题，刚开始做测试的时候，你是怎么学习写测试用例的？
我之所以选择测试这个工作是因为：我毕业后，在第一家公司做技术支持，产品的问题很多，导致技术支持工作很辛苦、很累。为了让用户买到的产品的质量是好的，我选择了做测试，到了现在的公司。我刚做测试的时候，对测试一无所知，什么测试流程阿、文档阿都不知道，公司的测试和管理也不规范。对测试，大家都认为不就是拿个鼠标点来点去，谁都可以来做。为此，我经常上网查测试的资料，看看自己到底适合不适合做测试，测试到底是什么样的一个职业，怎么去规划自己的个人发展。其实要做好测试，真是不容易。不喜欢，真是不能做这个职业。
现在想想自己刚开始写测试用例的时候，真是好笑。就像小孩子学习写字一样。先是在网上狂搜索了一把测试用例的模板，综合了几个，就形成了。我之所以不用公司原有的测试用例模板，是因为太不适用了。还好，公司没有严格要求必须要那个模板，只要适用就行。模板找好了，可是写就费劲了。对于刚做测试的新人，看似简单的一个填表工作，要写好真是不简单。一开始写的比较不自然，有些生搬硬套，而且还很慢。没有办法，那时候没有人指导我，全靠自己自学和领悟，所以那段日子很苦阿！多写几次后，就知道和领悟了，测试用例要根据测试大纲来写，测试大纲要根据测试计划来写。测试大纲更多的是把握住测试项的方向，而测试用例是指导怎么去执行测试。还好，我有编程的经验，所以对我熟悉软件帮了一个很大的忙。熟悉了软件的业务才能去写测试用例，才能更好的去测试。这也是我一点一点的领悟出来的。说了这么多，不知道这样的回答是否是回答了这个问题。
最后一个问题了，我尽量少写些，文字太多了大家看的也累，我写的也累。嘿嘿。^_^
你对黑盒测试用例的编写的体会是什么？有什么好的版本或者标准吗？
我的体会：
１、测试用例要根据测试大纲来编写
２、测试用例也要分测试项进行归类，这样比较好分析和阅读。如：业务流程测试、安装测试、功能测试、用户友好性测试、兼容性测试、性能测试、安全性测试等等。
３、编写测试用例要考虑各种情况，精力主要集中在软件的主要业务流程和风险高的地方。能分出测试优先级别就最好了。
４、熟悉系统，对编写测试用例很有帮助。
５、即使对测试很熟悉了，在时间非常紧的时候，编写测试用例还是很有必要和好处的。
今天就想到那么些了，以后想到了在补充上了。我把我用的模板给你们粘贴一份上来，只能给你们做些参考，具体还是要看对你所在的公司适用不适用。测试项的归类我就不列举了，因为每个公司的都不太一样。
第五篇：做好测试计划和测试用例工作的关键
做好测试计划和测试用例的工作的关键
做好测试计划和测试用例的工作的关键（转）
对于目前大部分公司存在的状况，很多测试计划文档只是一种形式而已
所以我的理解是：怎样让测试计划对整个测试工作真正具有指导作用
这里把测试计划和测试方案分开来讲（计划对应于管理层面的问题，方案对应于技术方面的问题）
测试计划中最重要的内容包括： 进度安排；人力、物力资源分配（包括组织结构等）、风险假设和规避措施。（其他像软件版本号之类的，只要是个人都会写，这里不列了）写好测试计划的关键在于：充分了解你的团队的整体实力和团队中每个成员的特点充分理解为当前软件制订的整个研发活动过程
带过项目的人都知道：在实际项目中，往往进度才是第一位的，但是对进度的把握和估算却是极其困难的。只有做到这两点才有可能对进度有比较准确的把握，对人员有一个合理的分配。否则所谓的进度，所谓的资源分配，都是拍脑袋得出的结果，风险假设更是无从谈起，这样的测试计划文档只能流于形式也就不足为奇了。
写好测试方案的关键在于：有一个合理的测试计划熟悉相关业务深入体会用户的实际需求
这个不想多解释了，不难理解。
至于测试用例，看到上面不少朋友认为关键在于理解用户需求。
其实理解用户实际需求是一切的根本，并且对于有些测试（比如像单元测试）对应的测试用例通常和用户需求之间的关系可能并不直接或是十分密切。
当然，如果有一份好的需求和设计文档的话，什么事情都解决了。可是现实往往是不存在这样的文档的。
所以我的看法是：对业务理解的深入程度经验有自己的文档
前两条不解释了。自己的文档包括两方面：一个是常用的特殊测试数据，比如一些特殊字符，极限长度的输入等等。这个在项目时间紧迫的时候是非常有帮助的（有的时候甚至可以当成check list）。另一个就是自己测试模块对应的相关需求和设计文档。服务器上的标准文档拖到本地来并且记得及时更新。然后在测试过程中，需要什么内容文档上没有，最直接的方法是和开发人员沟通。（其实我很反对这么做。你想，按开发人员自己说的标准
去测他们自己开发的模块能测出因为需求或者设计错误导致的问题么„„应该是和客户和designer去沟通，可惜一般没有这条件-_-）任何标准文档上缺少的内容，只要是和你有关的，一定要记得做记录。当然你有时间有精力把整个系统的需求和设计文档都捣鼓出来最好，不过通常是没这可能性的。
补充说明：lz最后提到的“完全凭借自己的经验在执行测试活动”不如说是完全凭借自己的感觉在执行测试活动。
项目需要的用例详尽程度可以商量，但是必须要有。如果进度很紧，可以用一部分用例加上check list进行测试活动（比如很多日本外包项目的UI测试，相当一部分可以用check list来代替具体的用例，效果并不差)
完整的大纲应该是：
目录
测试计划标识符
目录表
参考文献
词汇表
介绍
测试项
软件风险问题
待测特征
不予测试的特征
方法
测试项通过/失败准则
挂起准则和恢复需求
测试交付物
测试任务
环境需求
职责
人员安排与培训需求
进度表
计划风险与应急措施
审批
点击咨询 