编写测试用例方法心得体会

第一篇：编写测试用例方法心得体会

编写测试用例方法心得体会

编写背景：

一直以来都不太想把技术方面的文章写出来给大家看，一个是怕写作功底不好误导哪些刚入门的测试同行，自己的表达能力有限，另一方面怕有的同行拿出去炒作，再者测试网站论坛上关于测试用例的资料已经实在是多。但是看到同行纷纷都在问我测试用例的问题，都很想知道我写测试用例的心得体会。我就抱着试试看的心态写写吧，希望测试的老前辈看见了，可以给我多提提建议。

编写测试用例方法心得体会

在我的个人邮箱和MSN上，通常同行都问我类似下面这样的问题：

１、一个测试用例要写到什么程度才比较好?

２、刚开始做测试的时候，你是怎么学习写测试用例的？

３、你对黑盒测试用例的编写的体会是什么？有什么好的版本或者标准吗？

对于测试用例，而我目前正在思考的问题是：怎么写出对公司有价值的测试用例，对公司来说，怎么测试才是最有价值的测试？

下面先来分析第一个问题吧：一个测试用例要写到什么程度才比较好？

这个问题，没有定语，没有说是在什么样的一个情况下，因此我这里只能就我工作中碰到的情况说说了。说起来比较长阿，大家要有耐心看才行哈。^_^ 在我测试工作中，碰上的测试类型我自己划分成这么４种： ^

对项目、产品的测试，测试的时候通常要考虑这个项目的周期和测试资源。我所在的公司，通常项目开发时间都很短４到５个月，然而测试通常都是在开发即将结束的时候才真正介入。测试就是１个人负责。因此时间和人力资源对测试来说是完成测试工作的一个风险。为此在这种情况下，我都是先熟悉系统的业务，把握重点业务和功能后，参考需求，把测试需求、测试计划和测试大纲给制定好。由于时间关系，测试用例都是先写重点的业务，也就是集成测试的测试用例。另外测试用例是根据测试大纲来的。通常都是先挑最重要的测试项和风险大的业务功能编写测试用例。由于测试用例是本人执行，所以测试用例可以写的简单些，但是一定要开发人员能够看明白。可惜我所在的公司，都没有人来看我的测试用例。测试用例对我来说是用来提示我不要忘记了要测试哪些项。一些很有价值的ｂｕｇ通常不是在写测试用例的时候发现的，而是在测试软件的过程中，我在家睡觉前的思考和回家的路上思考出来的。这就是手动测试的魅力，有些软件的缺陷是在你使用软件的一瞬间和思考的一刹那突然发现的。所以要我回答测试用例要写到什么程度才比较好，我觉的只要你所写的测试用例在你的公司能够顺利的执行，不影响你的测试执行工作就可以了。因为测试用例写的太详细，你要花费时间和人力成本，这样出来的测试用例是最好的也是最贵的，一旦需求变更，也需要修改，这时你会发现这种详细的测试用例是最不挣钱的。测试用例写的太粗，别人看不懂，不能执行，那你要花费你的时间去解释，这就加大了测试的工作量。这也不是好的方法。

第二个问题，刚开始做测试的时候，你是怎么学习写测试用例的？

我之所以选择测试这个工作是因为：我毕业后，在第一家公司做技术支持，产品的问题很多，导致技术支持工作很辛苦、很累。为了让用户买到的产品的质量是好的，我选择了做测试，到了现在的公司。我刚做测试的时候，对测试一无所知，什么测试流程阿、文档阿都不知道，公司的测试和管理也不规范。对测试，大家都认为不就是拿个鼠标点来点去，谁都可以来做。为此，我经常上网查测试的资料，看看自己到底适合不适合做测试，测试到底是什么样的一个职业，怎么去规划自己的个人发展。其实要做好测试，真是不容易。不喜欢，真是不能做这个职业。

现在想想自己刚开始写测试用例的时候，真是好笑。就像小孩子学习写字一样。先是在网上狂搜索了一把测试用例的模板，综合了几个，就形成了。我之所以不用公司原有的测试用例模板，是因为太不适用了。还好，公司没有严格要求必须要那个模板，只要适用就行。模板找好了，可是写就费劲了。对于刚做测试的新人，看似简单的一个填表工作，要写好真是不简单。一开始写的比较不自然，有些生搬硬套，而且还很慢。没有办法，那时候没有人指导我，全靠自己自学和领悟，所以那段日子很苦阿！多写几次后，就知道和领悟了，测试用例要根据测试大纲来写，测试大纲要根据测试计划来写。测试大纲更多的是把握住测试项的方向，而测试用例是指导怎么去执行测试。还好，我有编程的经验，所以对我熟悉软件帮了一个很大的忙。熟悉了软件的业务才能去写测试用例，才能更好的去测试。这也是我一点一点的领悟出来的。说了这么多，不知道这样的回答是否是回答了这个问题。

最后一个问题了，我尽量少写些，文字太多了大家看的也累，我写的也累。嘿嘿。^_^

你对黑盒测试用例的编写的体会是什么？有什么好的版本或者标准吗？

我的体会：

１、测试用例要根据测试大纲来编写

２、测试用例也要分测试项进行归类，这样比较好分析和阅读。如：业务流程测试、安装测试、功能测试、用户友好性测试、兼容性测试、性能测试、安全性测试等等。

３、编写测试用例要考虑各种情况，精力主要集中在软件的主要业务流程和风险高的地方。能分出测试优先级别就最好了。

４、熟悉系统，对编写测试用例很有帮助。

５、即使对测试很熟悉了，在时间非常紧的时候，编写测试用例还是很有必要和好处的。

今天就想到那么些了，以后想到了在补充上了。我把我用的模板给你们粘贴一份上来，只能给你们做些参考，具体还是要看对你所在的公司适用不适用。测试项的归类我就不列举了，因为每个公司的都不太一样。

第二篇：编写测试用例方法心得体会

由安博测试空间技术中心http://www.xiexiebang.com/提供

编写测试用例方法心得体会

编写背景：

一直以来都不太想把技术方面的文章写出来给大家看，一个是怕写作功底不好误导哪些刚入门的测试同行，自己的表达能力有限，另一方面怕有的同行拿出去炒作，再者测试网站论坛上关于测试用例的资料已经实在是多。但是看到同行纷纷都在问我测试用例的问题，都很想知道我写测试用例的心得体会。我就抱着试试看的心态写写吧，希望测试的老前辈看见了，可以给我多提提建议。

编写测试用例方法心得体会

在我的个人邮箱和MSN上，通常同行都问我类似下面这样的问题：

１、一个测试用例要写到什么程度才比较好?

２、刚开始做测试的时候，你是怎么学习写测试用例的？

３、你对黑盒测试用例的编写的体会是什么？有什么好的版本或者标准吗？

对于测试用例，而我目前正在思考的问题是：怎么写出对公司有价值的测试用例，对公司来说，怎么测试才是最有价值的测试？

下面先来分析第一个问题吧：一个测试用例要写到什么程度才比较好？

这个问题，没有定语，没有说是在什么样的一个情况下，因此我这里只能就我工作中碰到的情况说说了。说起来比较长阿，大家要有耐心看才行哈。^_^ 在我测试工作中，碰上的测试类型我自己划分成这么４种： ^

对项目、产品的测试，测试的时候通常要考虑这个项目的周期和测试资源。我所在的公司，通常项目开发时间都很短４到５个月，然而测试通常都是在开发即将结束的时候才真正介入。测试就是１个人负责。因此时间和人力资源对测试来说是完成测试工作的一个风险。为此在这种情况下，我都是先熟悉系统的业务，把握重点业务和功能后，参考需求，把测试需求、测试计划和测试大纲给制定好。由于时间关系，测试用例都是先写重点的业务，也就是集成测试的测试用例。另外测试用例是根据测试大纲来的。通常都是先挑最重要的测试项和风险大的业务功能编写测试用例。由于测试用例是本人执行，所以测试用例可以写的简单些，但是一定要开发人员能够看明白。可惜我所在的公司，都没有人来看我的测试用例。测试用例对我来说是用来提示我不要忘记了要测试哪些项。一些很有价值的ｂｕｇ通常不是在写测试用例的时候发现的，而是在测试软件的过程中，我在家睡觉前的思考和回家的路上思考出来的。这就是手动测试的魅力，有些软件的缺陷是在你使用软件的一瞬间和思考的一刹那突然发现的。所以要我回答测试用例要写到什么程度才比较好，我觉的只要你所写的测试用例在你的公司能够顺利的执行，不影响你的测试执行工作就可以了。因为测试用例写的太详细，你要花费时间和人力成本，这样出来的测试用例是最好的也是最贵的，一旦需求变更，也需要修改，这时你会发现这种详细的测试用例是最不挣钱的。测试用例写的太粗，别人看不懂，不能执行，那你要花费你的时间去解释，这就加大了测试的工作量。这也不是好的方法。

第二个问题，刚开始做测试的时候，你是怎么学习写测试用例的？

我之所以选择测试这个工作是因为：我毕业后，在第一家公司做技术支持，产品的问题很多，导致技术支持工作很辛苦、很累。为了让用户买到的产品的质量是好的，我选择了做测试，到了现在的公司。我刚做测试的时候，对测试一无所知，什么测试流程阿、文档阿都不知道，公司的测试和管理也不规范。对测试，大家都认为不就是拿个鼠标点来点去，谁都可以来做。为此，我经常上网查测试的资料，看看自己到底适合不适合做测试，测试到底是什么样的一个职业，怎么去规划自己的个人发展。其实要做好测试，真是不容易。不喜欢，真是不能做这个职业。

现在想想自己刚开始写测试用例的时候，真是好笑。就像小孩子学习写字一样。先是在网上狂搜索了一把测试用例的模板，综合了几个，就形成了。我之所以不用公司原有的测试用例模板，是因为太不适用了。还好，公司没有严格要求必须要那个模板，只要适用就行。模板找好了，可是写就费劲了。对于刚做测试的新人，看似简单的一个填表工作，要写好真是不简单。一开始写的比较不自然，有些生搬硬套，而且还很慢。没有办法，那时候没有人指导我，全靠自己自学和领悟，所以那段日子很苦阿！多写几次后，就知道和领悟了，测试用例要根据测试大纲来写，测试大纲要根据测试计划来写。测试大纲更多的是把握住测试项的方向，而测试用例是指导怎么去执行测试。还好，我有编程的经验，所以对我熟悉软件帮了一个很大的忙。熟悉了软件的业务才能去写测试用例，才能更好的去测试。这也是我一点一点的领悟出来的。说了这么多，不知道这样的回答是否是回答了这个问题。

最后一个问题了，我尽量少写些，文字太多了大家看的也累，我写的也累。嘿嘿。^_^ 你对黑盒测试用例的编写的体会是什么？有什么好的版本或者标准吗？ 我的体会：

１、测试用例要根据测试大纲来编写

２、测试用例也要分测试项进行归类，这样比较好分析和阅读。如：业务流程测试、安装测试、功能测试、用户友好性测试、兼容性测试、性能测试、安全性测试等等。

３、编写测试用例要考虑各种情况，精力主要集中在软件的主要业务流程和风险高的地方。能分出测试优先级别就最好了。

４、熟悉系统，对编写测试用例很有帮助。

５、即使对测试很熟悉了，在时间非常紧的时候，编写测试用例还是很有必要和好处的。

今天就想到那么些了，以后想到了在补充上了。我把我用的模板给你们粘贴一份上来，只能给你们做些参考，具体还是要看对你所在的公司适用不适用。测试项的归类我就不列举了，因为每个公司的都不太一样。

北京测试空间科技发展有限公司是注册于北京市海淀区高新技术园的软件企业，目前主要业务范围包括软件测试管理 工具研发、软件测试项目外包和软件测试专业技术人才培养及派遣。在软件测试管理工具研发领域已成功开发具有

自主知识产权的STMP管理软件。在软件测试项目外包领域已建立广泛的业务渠道，服务客户包括北大软件工程中心、东软股份、海辉高科、用友软件、莱博智科技、电子部5所、11所，航天704所、中国金融认证管理中心、国安创想、清华同方、中软融鑫、长峰科技等100余家企业，项目覆盖行业包括军工、航天、金融、通信等领域。由安博测试空间技术中心http://www.xiexiebang.com/提供 地址：北京市海淀区学院路40号大唐电信测试空间楼 联系电话：010-62303223 62303260 62303230

第三篇：编写测试用例的一点体会

编写测试用例的一点体会

一是测试用例对需求覆盖的完整性；二是测试用例的有效性；三测试用例的可理解性四是测试用例的清晰性；五是测试用例的可维护性。

测试用例是基于需求的，为了测试程序是否满足需求，个人觉得要想写好测试用例必须对于需求做到完全理解，并能从全局上把握住需求。一个好的方法就是用mm图把需求分解了。把基本路径分解出来，将需求归类。理顺了需求，用例写起来就顺手的多。在编写用例的过程中进行等价类的划分，最后用判定表进行评判，补充缺少的用例，剔除冗余的用例。做到对需求的100%覆盖。也就是说拿到需求文档必须进行必要的分析，不能上来就盲目的写用例，新人尤其应该注意。测试用例编写完成后必须明确哪些是核心功能的用例！

（测试用例的有效性）测试用例应该包含清晰的输入数据以及预期输出，没有测试数据的用例更多的是具有指导意义，执行过程中更多的是靠个人根据指导的自由发挥。但是看看我们的基线库更多的是这样指导意义的用例。（但是输入数据又涉及到了维护的问题，以及环境或者业务发生变更后引起的有效性问题）。对于预期的结果不能仅仅是页面上或者界面上的可见结果，如果和数据库发生了交互，必须包含数据库里准确的验证结果。用例基于数据驱动。

（测试用例的可理解性）测试用例步骤必须描述清晰，不能出现模棱两可以及重复的话语，测试用例应该按照增删改的顺序进行安排，这样执行的时候效率比较高，避免不必要的重复测试，用例写完不是就ok了，我们最好通读2遍，进行修改，让单条用例流畅。

（测试用例的清晰性）测试用例的验证点必须明确清晰重点突出，按照最新的用例标准，一个用例进行一个功能点的验证，一个萝卜一个坑。对于流程性的用例也是建议按照流程顺序进行用例安排，从第一个验证点到最后一个验证点，组成流程的开始到结束，方便测试执行。测试用例包含前置条件的必须将前置条件描述清楚，包括入口等。

（测试用例的可维护性）我们的用例主要是基于web的，用例存在一定的变数。

因此在测试用例因为业务需求发生变更的时候，请及时修改，维护测试用例，做到测试用例的实时性与有效性，同时也方便后来的新人同学及时学习，不会产生误解与费解。

Ross Collard在”Use Case Testing”一文中说：“测试用例的前10%到15%可以发现75%到90%的重要缺陷”。如果你在项目或者日常结束后，仔细的分析过我们的bug列表，那么你会觉的这句话非常适用。合理提高我们的测试效率就是在编写测试用例时进行测试用例优先级的划分。

1．用于冒烟测试的用例为最高优先级

2．把基本路径以及各模块主功能的测试标注为高优先级别

3．把你所有错误和边界值或确认测试标注为中优先级别

4．把可用性测试以及入口默认值校验等标注为低优先级别。

5．将功能测试用例分为严重和不严重两类，对于不严重的功能测试用例降级为低优先级用例。

几点建议：

1．你是否感觉测试的时候思维很混乱，或者总感觉有些功能没有测到，而一些功能已经测过好几遍？请明确你的需求，是否做到覆盖100%。你的用例优先级是否设置的合理。

2．在测试时间紧迫的情况下，你不知道要测什么，或者要先测试那些功能？那么你需要调整自己用例的优先级，顺带回去好好整理整理需求。

3．在编写测试用例的时候优先去学习，老人们优秀的做法。在学习别人优秀成果的基础上，编写自己的用例。

构造朴实的测试用例

测试用例这种东西对于刚入行的人来说是一种诱惑，初入测试的人急于掌握这门学问，所以一开始就会问测试用例怎么写，问的同时或许还包含了一些期望。其实测试用例就是一个测试矩阵，任何人没有必要注重形式问题，如果你现在或者未来的公司有套非常完善的文档管理体系，那么你可以参考标准模版，如果没有你们大可跟我一样使用下面的格式：

-----------

-ID-ACT-DATA-EXPECTED-ACTUAL-T/F-DATE

-----------

我认为没有什么问题，ID代表标号（如果你愿意可以用这个ID对应需求文档的ID或者使用详细设计的文档的ID，间接连接需求），ACT代表一种动作，因为测试动作非常复杂，如果手动执行或者自动执行，或者或者是一种异常状态都可以占用此位置，但是注意不能使用性能、数据或者安全测试替代，为什么请各位自己考虑。DATA代表数据，很多的测试类书籍中虽然没有直接讲明测试数据的划分，但是通常我们引用三种数据“正常”、“异常”、“错误”，分别对应关键字“PASS”、“ERROR”、“FAIL”，对于数据的划分我以前曾经说过这里不再细谈，为什么会在一个文档中体现着点，主要是为了以后数据程序化作接口，一个不能将手动测试转为自动测试的人员注定是平庸的。EXPECTED、ACTUAL分别代表期望和实际，我们做这一行的经常对这两种值的差异感到困惑，是不是“正常”、“异常”、“错误”就看个人的经验了。T/F的引入是因为有这样的一种情况介入，如果EXPECTED、ACTUAL是不同的，但是我们还是要给个T，因为对于单项的是否通过测试人员有着使用权，但决定权在于市场或者高层决策。DATE是一种好习惯，通常记为发现“PASS”、“ERROR”、“FAIL”的时间，很多人会忽略这个值，当然对于我们来说没什么损失，对于QA团队来说，仅仅提供给他们T/F是不够的。

我觉得这就是一种构造朴实的测试用例的方式，不要过于在意一份文档的表现形式，如果你有很多的时间，如果你一年才写一个这样的文档，那么你可以从互联网上下在很多的资源把这份文档修饰的像APPLE一样。

入行的人员会更进一步的发挥测试偏执狂的能力，这时候他们急需一种数量，例如：我们一个动态库的测试用例就有3000多个厉害吧？厉害，我当然说你厉害，你难道不厉害吗？我记得有个500强的面试题就是你能为LOGIN动作写多少的测试用例？我想了半天我说就三个，或者四个，在听到了一声深深叹息后，我惶恐的说大概我能写5个吧？！当然我自己也没底，我就能写出三个。LOGIN/PASS、LOGIN/ERROR、LOGIN/FAIL，所有的测试用例就是他们的衍生，一种本源的问题。我们继续讨论3000多个测试用例的事

情，有人明眼就会说：这家伙肯定是微软的，没错，除了这种大公司有了充足的资源和技术支持，哪家公司能跟他们一样呢？当然了，写3000个我想入行久了谁都可以，并且跟你对系统的熟悉程度，工作经验有莫大的关系，但是这里我又想说说关于构造朴实的测试用例的问题了。

单元测试、集成测试这些说明的是测试范围，功能测试、性能测试这些说明的是测试的手段，也可以这样说某个功能测试包含了若干个功能测试也内隐含了若干个单元测试的联动，当你开始测试的时候，实际上最终是对代码设定路径的一种验算，如果我们都生活在单线程、无UI的年代你可以更清楚的看到

“PASS”、“ERROR”、“FAIL”三种状态，可我们已经错过了这个年代，我们有了包装的UI，有了封装的API，有了各种各样的MESSAGE，所以你就要承受更多ERROR的打击。这个时候有人就会通过增加测试用例的数量来回避这些陷阱，出发点是好的做法是累死人的，如果你愿意你可以为机器码写1亿个测试用例，如果你还是很偏执，你可以为门电路写上1万亿个测试用例，你有命执行吗？

我通常不愿意写太多的测试用例，很多人认为我工作态度有问题，我认为这更能说明我的态度：我愿意朴实的构造我的测试用例，但是我有原则来保证我的测试用例：

1、接到任务不急于作而在于多思考，首先在纸上构造一个大致的业务流图

2、流图构造好，快速剔除公用的测试用例

3、构造测试用例先写符合主路径的三种“PASS”、“ERROR”、“FAIL”

4、精化测试用例努力为ERROR多构造1-7种假设

5、执行测试用例强化FAIL的标准化失败输出，但是对应减少PASS测试用例

6、进一步精化测试用例，使“PASS”、“ERROR”、“FAIL”所占的比例分别为%20、%70、%10如果我还是测试，我将继续我的朴实理论，多出来的安全时间我可以看看蓝天享受享受生活！

测试用例编写的“侯式标准”

作为软件测试人员，执行测试用例是我们进行测试工作的主要手段，测试用例设计的好坏，直接影响着测试工作的质量。一个“好”的测试用例能保证测试的质量，规范测试的进程，进而提高我们的测试效率。那什么样的用例才是好的测试用例？这已经是一个老生常谈的问题，大家见仁见智，众说云云，不一而足。

而我的TL–候风的一句话，让我对用例的有了新的认识。他是这样说的：一个好的测试用例，就是在保证测试质量的前提下，做到以下几点：当一个不熟悉业务的人，看到你的用例后，要知道用例的测试目的什么，知道你要做什么，怎么做，为什么这样做，取得了什么什么成果。

做什么？

做任何事情，都要有的放矢。我们在编写一个测试用例的时候，应该知道我们要的是什么，这也是编写一个用例最基本的前提。

怎么做？

即具体的如何设计用例。就是要明确用例的执行过程，这样在测试的时候才能有章可循，摸着石头过河

为什么这样做？

这要求用例编写者要明确设计用例时用到的方法（如边界值，等价类等等），以及用这种方法的好处。取得了什么成果？

这要求用例编写者明确通过这个测试用例,我们将取得什么效果。比如一个采用边界值设计的用例，取得的效果是在极端的数据下，软件是否能够正常执行功能。

标准规范中包含的主要元素如下：

1测试名称(Test Name)：测试用例编号和测试用例名称。

2创建日期(Creation Date)：测试用例创建时间，系统自动产生。

3设计人员(Designer)：测试用例设计人员

4状态(Status)：测试用例状态

5描述（Descrīption）：测试用例详细描述

6步骤名称（Step Name）：测试步骤名称

7步骤描述（Step Descrīption）：测试步骤详细描述。

8预期结果（Expected Result）：测试预期结果

要是按照“候风标准”（暂且这样命名，还没申请侯哥批准），我们要对上面的标准进行规范的优化以及内容的明确

1测试名称

A）用例根据各用例的功能来命名，尽量做到简洁明了。

B）一级目录使用各项目的顶级菜单名称来命名，如功能、业务、查询三大类；

C）二级目录使用顶级菜单下的二级菜单名称类命名，用户可根据名字判别该用例是测试哪个模块的。2 描述（Descrīption）：测试用例详细描述

要用通俗易懂而又简洁的语言描述描述用例的设计目的，让其他人能够明白我们在什么步骤描述

步骤描述要详细而不臃肿，条理而不凌乱。

同时，在规范上要增加以下几项

1测试目的（Purpose）：编写这个测试用例的目的2测试方法选择依据（Foundation）：即用这样方法的好处

3测试取得的成果（Achievement）：通过执行用例取得的成果

4用例执行的前提条件（Precondition）：执行用例的需要满足的前提

这样，一个完整的用例包含的元素如下：

1测试名称(Test Name)测试目的（Purpose）测试方法选择依据（Foundation）用例执行的前提条件（Precondition）

5创建日期(Creation Date)

6设计人员(Designer)

7状态(Status)

8描述（Descrīption）

9步骤名称（Step Name）

10步骤描述（Step Descrīption）

11预期结果（Expected Result）测试取得的成果（Achievement）

.综上所述，测试用例的“侯式标准”的精髓，就是把自己的思维过程尽可能的展现到用例中，做到即使一个完全不懂业务的人，看到我们的用例后，也能知道业务的需求和流程，知道测试的过程，能够无障碍的执行我们的用例。

以上是我学习用例编写过程中的一些体会，不足之处请大家批评指正。让我们一起交流分享，共同进步成长。

第四篇：编写测试用例和测试计划

第六章 编写测试用例和测试计划

主要内容：软件测试计划；软件测试方案；软件风险分析

1.软件测试计划

1.1 软件测试计划的简介

1测试计划概念：测试计划在测试中处于中心位置，它阐述了测试准备工作和执行测试的必要条件，同时也形成了测试过程质量保证的基础。

2测试计划的作用：组织和管理测试；使测试工作和整个开发工作整合起来；资源和变更事先最为一个可控制的风险。

1.2 如何编写软件测试计划

1认识测试项目不仅仅只有单一测试计划

2避免不分析直接进行测试阶段日程安排

3避免测试任务的安排超前于开发任务

4避免有些系统测试类型无法按期进入测试

5不正确的变更测试计划

6测试计划里明确更新周期和暂停测试原则

7测试计划不是一成不变的1.3 测试计划包括：简介，目的，范围，测试策略，进度，缺陷的严重程度的定义，风

险分析。

2.软件测试方案

2.1 软件测试方案的概念

软件测试方案描述测试的特征，测试的方法，测试环境的规划，测试工具的设计和选择，测试用例的设计方法，测试代码的设计方案。即包括以下几点：

 明确测试策略（黑盒，白盒，灰盒等）

 细化测试特征

 测试用例的规划

 测试环境的规划

 自动化测试框架的设计

 测试工具的设计和选择

2.2 软件测试计划于软件测试方案的区别

 测试计划是组织管理层面的文档。测试方案是技术层面的文档。

 测试方案需要在测试计划的指导下进行，测试计划提出“做什么”，测试方案明确“怎么做”

 回报的对象不同，测试计划向领导汇报，测试方案是组员共享该文档

3.软件测试的风险

 软件需求风险

 人员的风险

 测试环境的风险

 测试工程师对产品的业务不熟悉

补充：

回归测试：把以前检查过的已经修复好的缺陷，拿来另测看有无带来新的缺陷 反侧：把开发人员已经处理的缺陷拿来测，看是否修复

第五篇：测试用例的编写总结

在网上看到这篇文章很好，和大家分享一下：

在我的个人邮箱和MSN上，通常同行都问我类似下面这样的问题：

１、一个测试用例要写到什么程度才比较好?

２、刚开始做测试的时候，你是怎么学习写测试用例的？

３、你对黑盒测试用例的编写的体会是什么？有什么好的版本或者标准吗？

对于测试用例，而我目前正在思考的问题是：怎么写出对公司有价值的测试用例，对公司来说，怎么测试才是最有价值的测试？

下面先来分析第一个问题吧：一个测试用例要写到什么程度才比较好？

这个问题，没有定语，没有说是在什么样的一个情况下，因此我这里只能就我工作中碰到的情况说说了。说起来比较长阿，大家要有耐心看才行哈。^_^

在我测试工作中，碰上的测试类型我自己划分成这么４种：项目的测试，产品的测试，产品个性化的测试，第三方验收测试。项目的测试指的是我所测试的软件是一个项目，是某一个具体用户使用的。产品的测试指的是我所测试的软件是一个通用产品，是供很多用户使用的。产品个性化测试指的是我所测试的软件是某一用户在使用产品时，提出了特殊的功能，针对这些新功能，对产品针对用户进行了个别修改。第三方验收测试大家都应该很熟悉了，这里就不需要做解释了。

对项目、产品的测试，测试的时候通常要考虑这个项目的周期和测试资源。我所在的公司，通常项目开发时间都很短４到５个月，然而测试通常都是在开发即将结束的时候才真正介入。测试就是１个人负责。因此时间和人力资源对测试来说是完成测试工作的一个风险。为此在这种情况下，我都是先熟悉系统的业务，把握重点业务和功能后，参考需求，把测试需求、测试计划和测试大纲给制定好。由于时间关系，测试用例都是先写重点的业务，也就是集成测试的测试用例。另外测试用例是根据测试大纲来的。通常都是先挑最重要的测试项和风险大的业务功能编写测试用例。

由于测试用例是本人执行，所以测试用例可以写的简单些，但是一定要开发人员能够看明白。可惜我所在的公司，都没有人来看我的测试用例。测试用例对我来说是用来提示我不要忘记了要测试哪些项。一些很有价值的bug通常不是在写测试用例的时候发现的，而是在测试软件的过程中，我在家睡觉前的思考和回家的路上思考出来的。这就是手动测试的魅力，有些软件的缺陷是在你使用软件的一瞬间和思考的一刹那突然发现的。所以要我回答测试用例要写到什么程度才比较好，我觉的只要你所写的测试用例在你的公司能够顺利的执行，不影响你的测试执行工作就可以了。因为测试用例写的太详细，你要花费时间和人力成本，这样出来的测试用例是最好的也是最贵的，一旦需求变更，也需要修改，这时你会发现这种详细的测试用例是最不挣钱的。测试用例写的太粗，别人看不懂，不能执行，那你要花费你的时间去解释，这就加大了测试的工作量。这也不是好的方法。

第二个问题，刚开始做测试的时候，你是怎么学习写测试用例的？

我之所以选择测试这个工作是因为：我毕业后，在第一家公司做技术支持，产品的问题很多，导致技术支持工作很辛苦、很累。为了让用户买到的产品的质量是好的，我选择了做测试，到了现在的公司。我刚做测试的时候，对测试一无所知，什么测试流程阿、文档阿都不知道，公司的测试和管理也不规范。对测试，大家都认为不就是拿个鼠标点来点去，谁都可以来做。为此，我经常上网查测试的资料，看看自己到底适合不适合做测试，测试到底是什么样的一个职业，怎么去规划自己的个人发展。其实要做好测试，真是不容易。不喜欢，真是不能做这个职业。

现在想想自己刚开始写测试用例的时候，真是好笑。就像小孩子学习写字一样。先是在网上狂搜索了一把测试用例的模板，综合了几个，就形成了。我之所以不用公司原有的测试用例模板，是因为太不适用了。还好，公司没有严格要求必须要那个模板，只要适用就行。模板找好了，可是写就费劲了。对于刚做测试的新人，看似简单的一个填表工作，要写好真是不简单。一开始写的比较不自然，有些生搬硬套，而且还很慢。没有办法，那时候没有人指导我，全靠自己自学和领悟，所以那段日子很苦阿！多写几次后，就知道和领悟了，测试用例要根据测试大纲来写，测试大纲要根据测试计划来写。测试大纲更多的是把握住测试项的方向，而测试用例是指导怎么去执行测试。还好，我有编程的经验，所以对我熟悉软件帮了一个很大的忙。熟悉了软件的业务才能去写测试用例，才能更好的去测试。这也是我一点一点的领悟出来的。说了这么多，不知道这样的回答是否是回答了这个问题。

最后一个问题了，我尽量少写些，文字太多了大家看的也累，我写的也累。嘿嘿。^_^

你对黑盒测试用例的编写的体会是什么？有什么好的版本或者标准吗？

我的体会：

１、测试用例要根据测试大纲来编写

２、测试用例也要分测试项进行归类，这样比较好分析和阅读。如：业务流程测试、安装测试、功能测试、用户友好性测试、兼容性测试、性能测试、安全性测试等等。

３、编写测试用例要考虑各种情况，精力主要集中在软件的主要业务流程和风险高的地方。能分出测试优先级别就最好了。

４、熟悉系统，对编写测试用例很有帮助。

５、即使对测试很熟悉了，在时间非常紧的时候，编写测试用例还是很有必要和好处的。