-
测试角色以及工作任务分解
qiuteng258 发布于 2010-12-13 14:25:29
-
<LR性能测试实战>摘录：监控Linux/Unix系统资源（部分语言自己组织）
阅微草人 发布于 2007-11-19 10:30:40
-
关于场景测试
ice00snow 发布于 2010-08-13 12:24:16
-
如何判断是否需要对一个软件进行性能测试？（本人原创）
godn_1981 发布于 2008-05-15 21:48:49
这个问题是51testing在0425的一个有奖问答题目，下面是本人的回答，呵呵，居然获得第一名~~
回答正文：
关于性能测试的看法
关于楼主的问题：有的软件没做性能测试，客户反馈了很多性能问题；有的软件没做性能测试，客户从没抱怨性能有问题；有的软件做了性能测试，客户依然反馈了很多性能问题；有的软件做了性能测试，客户从没抱怨性能有问题……
这确实是个问题。
其实我倒觉得问题不是要不要做的问题，而是怎么做，做多少的问题！
请注意，没有任何一个软件不需要做性能测试，而是说需要程度到底有多高，这个需求程度决定了花多少精力去做，并且怎么做的问题。
就算一个只有1000行代码的小程序，你怎么能保证它不需性能测试？你怎么知道它里面就没有内存溢出？你怎么知道它有没有耗费了不必要的资源？
所以问题不是做不做的问题，而是花多少代价，怎么做的问题。
一般性能测试有几个层次，或者说两个需求。
a.为了找出性能问题
b.为了给出性能指标
c.为了给出需要的配置
而我们国内现在常做的软件无非有几种：1.单机版应用程序 2.C/S或者B/S的项目（一般是外包项目或者政府软件，银行，医疗证券类软件）
对于单机版应用程序来说，一般作性能测试是比较简单的，一般需求是两个，
第一，你要测试一下有没有内存泻漏，或者深情况下内存溢出，或者有没有申请一些没必要的资源。这个一般要用一些分析工具
第二，一般一个单机版应用程序，你总要给出，最低配置或者建议配置什么的，那么你给客户这个东西 就需要性能测试，测试一下在各种配置下面的运行情况，给出理想的建议值
对于C/S或者B/S结构的软件就比较复杂了，一般是必须要做性能测试的。这个性能测试一般从以下方面考虑：
第一，优化
这个还是去考虑性能有没有问题，这个是起码的要求。特别是B/S系统，有没有多余请求，资源有没有释放之类的问题，要先考虑的。这类的问题，一般用网络分析工具就可以搞定。
第二，时间
这个是一般性能测试的重点。一般是用性能测试工具LR或WAS之类的做，这个叫负载测试。一般你测试一个软件，总要给老大一个结论，500人并发时，响应时间大概是几秒，300人并发时，是几秒。这个是每个客户都会要的。
第三，配置
这个也是性能测试的重点。这个一般叫压力测试。譬如一般客户会向你要一个数据：我想500人同时并发，响应时间在3秒之内，那么我的服务器要求最低配置是多少？这个嘛，你就只管压吧！压垮了，升级服务器，再压，又垮了，继续升级，到客户要求的性能指标达到为止，呵呵~~~~~~~~~~~~
总结一下，不是要不要做的问题，而是怎么做，按照客户要求哪些需求，哪些指标做的问题！51testing地址：http://bbs.51testing.com/thread-113138-2-1.html
-
白盒测试中的六种覆盖方法
87117899 发布于 2007-05-15 11:08:39
摘要：白盒测试作为测试人员常用的一种测试方法，越来越受到测试工程师的重视。白盒测试并不是简单的按照代码设计用例，而是需要根据不同的测试需求，结合不同的测试对象，使用适合的方法进行测试。因为对于不同复杂度的代码逻辑，可以衍生出许多种执行路径，只有适当的测试方法，才能帮助我们从代码的迷雾森林中找到正确的方向。本文介绍六种白盒子测试方法：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。
白盒测试的概述
由于逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。由于我们经常相信某逻辑路径不可能被执行, 而事实上,它可能在正常的情况下被执行。由于代码中的笔误是随机且无法杜绝的，因此我们要进行白盒测试。
白盒测试又称结构测试,透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法，盒子指的是被测试的软件，白盒指的是盒子是可视的,你清楚盒子内部的东西以及里面是如何运作的。
白盒的测试用例需要做到：
·保证一个模块中的所有独立路径至少 被使用一次
·对所有逻辑值均需测试 true 和 false
·在上下边界及可操作范围内运行所有循环
·检查内部数据结构以确保其有效性白盒测试的目的：通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试；在程序不同地方设立检查点，检查程序的状态，以确定实际运行状态与预期状态是否一致。
白盒测试的特点：依据软件设计说明书进行测试、对程序内部细节的严密检验、针对特定条件设计测试用例、对软件的逻辑路径进行覆盖测试。
白盒测试的实施步骤：
1.测试计划阶段：根据需求说明书，制定测试进度。
2.测试设计阶段：依据程序设计说明书，按照一定规范化的方法进行软件结构划分和设计测试用例。
3.测试执行阶段：输入测试用例，得到测试结果。
4.测试总结阶段：对比测试的结果和代码的预期结果，分析错误原因，找到并解决错误。白盒测试的方法：总体上分为静态方法和动态方法两大类。
静态分析是一种不通过执行程序而进行测试的技术。静态分析的关键功能是检查软件的表示和描述是否一致,没有冲突或者没有歧义。
动态分析的主要特点是当软件系统在模拟的或真实的环境中执行之前、之中和之后 , 对软件系统行为的分析。动态分析包含了程序在受控的环境下使用特定的期望结果进行正式的运行。它显示了一个系统在检查状态下是正确还是不正确。在动态分析技术中,最重要的技术是路径和分支测试。下面要介绍的六种覆盖测试方法属于动态分析方法。
白盒测试的优缺点
1. 优点
·迫使测试人员去仔细思考软件的实现
·可以检测代码中的每条分支和路径
·揭示隐藏在代码中的错误
·对代码的测试比较彻底
·最优化2. 缺点
·昂贵
·无法检测代码中遗漏的路径和数据敏感性错误
·不验证规格的正确性六种覆盖方法
首先为了下文的举例描述方便，这里先给出一张程序流程图。（本文以1995年软件设计师考试的一道考试题目为例，图中红色字母代表程序执行路径）。
1、语句覆盖
1）主要特点：语句覆盖是最起码的结构覆盖要求，语句覆盖要求设计足够多的测试用例，使得程序中每条语句至少被执行一次。
2）用例设计：（如果此时将A路径上的语句1—〉T去掉，那么用例如下）
XY路径15050OBDE29070OBCE3）优点：可以很直观地从源代码得到测试用例，无须细分每条判定表达式。
4）缺点：由于这种测试方法仅仅针对程序逻辑中显式存在的语句，但对于隐藏的条件和可能到达的隐式逻辑分支，是无法测试的。在本例中去掉了语句1—〉T去掉，那么就少了一条测试路径。在if结构中若源代码没有给出else后面的执行分支，那么语句覆盖测试就不会考虑这种情况。但是我们不能排除这种以外的分支不会被执行，而往往这种错误会经常出现。再如，在Do-While结构中，语句覆盖执行其中某一个条件分支。那么显然，语句覆盖对于多分支的逻辑运算是无法全面反映的，它只在乎运行一次，而不考虑其他情况。
2、判定覆盖
1）主要特点：判定覆盖又称为分支覆盖，它要求设计足够多的测试用例，使得程序中每个判定至少有一次为真值，有一次为假值，即：程序中的每个分支至少执行一次。每个判断的取真、取假至少执行一次。
2）用例设计：
XY路径19090OAE25050OBDE39070OBCE3）优点：判定覆盖比语句覆盖要多几乎一倍的测试路径，当然也就具有比语句覆盖更强的测试能力。同样判定覆盖也具有和语句覆盖一样的简单性，无须细分每个判定就可以得到测试用例。
4）缺点：往往大部分的判定语句是由多个逻辑条件组合而成（如，判定语句中包含AND、OR、CASE），若仅仅判断其整个最终结果，而忽略每个条件的取值情况，必然会遗漏部分测试路径。
3、条件覆盖
1）主要特点：条件覆盖要求设计足够多的测试用例，使得判定中的每个条件获得各种可能的结果，即每个条件至少有一次为真值，有一次为假值。
2）用例设计：
XY路径19070OBC240OBD3）优点：显然条件覆盖比判定覆盖，增加了对符合判定情况的测试，增加了测试路径。
4）缺点：要达到条件覆盖，需要足够多的测试用例，但条件覆盖并不能保证判定覆盖。条件覆盖只能保证每个条件至少有一次为真，而不考虑所有的判定结果。
4、判定/条件覆盖
1）主要特点：设计足够多的测试用例，使得判定中每个条件的所有可能结果至少出现一次，每个判定本身所有可能结果也至少出现一次。
2）用例设计：
XY路径19090OAE25050OBDE39070OBCE47090OBCE3）优点：判定/条件覆盖满足判定覆盖准则和条件覆盖准则，弥补了二者的不足。
4）缺点：判定/条件覆盖准则的缺点是未考虑条件的组合情况。
5、组合覆盖
1）主要特点：要求设计足够多的测试用例，使得每个判定中条件结果的所有可能组合至少出现一次。
2）用例设计：
XY路径19090OAE29070OBCE39030OBDE47090OBCE53090OBDE67070OBDE75050OBDE3）优点：多重条件覆盖准则满足判定覆盖、条件覆盖和判定/条件覆盖准则。更改的判定/条件覆盖要求设计足够多的测试用例，使得判定中每个条件的所有可能结果至少出现一次，每个判定本身的所有可能结果也至少出现一次。并且每个条件都显示能单独影响判定结果。
4）缺点：线性地增加了测试用例的数量。
6、路径覆盖
1）主要特点：设计足够的测试用例，覆盖程序中所有可能的路径。
2）用例设计：
XY路径19090OAE25050OBDE39070OBCE47090OBCE3）优点：这种测试方法可以对程序进行彻底的测试，比前面五种的覆盖面都广。
4）缺点：由于路径覆盖需要对所有可能的路径进行测试（包括循环、条件组合、分支选择等），那么需要设计大量、复杂的测试用例，使得工作量呈指数级增长。而在有些情况下，一些执行路径是不可能被执行的，如：
If （!A）B++；
If （!A）D--；这两个语句实际只包括了2条执行路径，即A为真或假时候对B和D的处理，真或假不可能都存在，而路径覆盖测试则认为是包含了真与假的4条执行路径。这样不仅降低了测试效率，而且大量的测试结果的累积，也为排错带来麻烦。
总结
白盒测试是一种被广泛使用的逻辑测试方法，是由程序内部逻辑驱动的一种单元测试方法。只有对程序内部十分了解才能进行适度有效的白盒测试。但是贯穿在程序内部的逻辑存在着不确定性和无穷性，尤其对于大规模复杂软件。因此我们不能穷举所有的逻辑路径，即使穷举也未必会带来好运（穷举不能查出程序逻辑规则错误，不能查出数据相关错误，不能查出程序遗漏的路径）。
那么正确使用白盒测试，就要先从代码分析入手，根据不同的代码逻辑规则、语句执行情况，选用适合的覆盖方法。任何一个高效的测试用例，都是针对具体测试场景的。逻辑测试不是片面的测试正确的结果或是测试错误的结果，而是尽可能全面地覆盖每一个逻辑路径。
-
白盒测试实例1~10（转）
lc1119 发布于 2009-03-02 11:25:47
白盒测试实例之一——需求说明
三角形的问题在很多软件测试的书籍中都出现过，问题虽小，五脏俱全，是个很不错的软件测试的教学例子。本文借助这个例子结合教学经验，从更高的视角来探讨需求分析、软件设计、软件开发与软件测试之间的关系与作用。
题目：根据下面给出的三角形的需求完成程序并完成测试：
一、输入条件：
1、 条件1：a+b>c
2、 条件2：a+c>b
3、 条件3：b+c>a
4、 条件4：0<a<200
5、 条件5：0<b<200
6、 条件6：0<c<200
7、 条件7：a==b
8、 条件8：a==c
9、 条件9：b==c
10、条件10：a2+b2==c2
11、条件11：a2+ c2== b2
12、条件12：c2+b2== a2
二、输出结果：
1、不能组成三角形
2、等边三角形
3、等腰三角形
4、直角三角形
5、一般三角形
6、某些边不满足限制
白盒测试实例之二——答案
很多初学者一看到这个需求（详见白盒测试实例之一——需求说明收藏），都觉得很简单，然后立刻就开始动手写代码了，这并不是一个很好的习惯。如果你的第一直觉也是这样的，不妨耐心看到文章的最后。
大部分人的思路：
1、首先建立一个main函数， main函数第一件事是提示用户输入三角形的三边，然后获取用户的输入（假设用户的输入都是整数的情况），用C语言来写，这一步基本上不是问题（printf和scanf），但是要求用java来写的话，很多学生就马上遇到问题了，java5.0及之前的版本不容易获取用户的输入。
点评：这样的思路做出来的程序只能通过手工方式来测试所有业务逻辑，而且这个程序只能是DOS界面版本了，要是想使用图形化界面来做输入，就得全部写过代码。
2、业务处理流程的思路用流程图表示如下：
3、C语言代码：
1. #include<stdio.h>
2. void main()
3. {
4. int a, b, c;
5. printf("please enter three integer:");
6. scanf("%d%d%d", &a, &b, &c);
7. if(0<a && a<200 && 0<b && b<200 && 0<c && c<200)
8. {
9. if(a+b>c && a+c>b && c+b>a)
10. {
11. if(a==b && b==c && a==c) //这里可以省掉一个判断
12. {
13. printf("1是等边三角形");
14. }
15. else
16. {
17. if(a==b || b==c || a==c)
18. {
19. printf("2是等腰三角形");
20. }
21. else
22. {
23. if(a*a+b*b==c*c || a*a+c*c==b*b || b*b+c*c==a*a)
24. {
25. printf("3是直角三角形");
26. }
27. else
28. {
29. printf("4是一般三角形");
30. }
31. }
32. }
33. }
34. else
35. {
36. printf("5不能组成三角形");
37. }
38. }
39. else
40. {
41. printf("6某些边不满足限制");
42. }
43. }点评：这样的思路做出来的程序只能通过手工方式来测试所有业务逻辑，而且这个程序只能是DOS界面版本了，要是想使用web或图形化界面来做输入，就得全部写过代码。
相关阅读：
白盒测试实例之三——需求分析
关键字：白盒测试、需求分析
需求分析是后续工作的基石，如果分析思路有问题，后续工作可能就会走向不正确的方向，比如：代码重用性差、难于测试、难于扩展和难于维护等。反而，如果需求分析做的好，对设计、开发和测试来说，都可能是很大的帮助。
看到题目给出的条件达12个之多，粗粗一看，好像很复杂，但仔细分析之后，发现可以把它们分成4组来讨论：
1、 条件1：a+b>c； 条件2：a+c>b； 条件3：b+c>a
这三个表达式有什么特点呢？实际上它们的逻辑是一样的：两个数之和大于第三个数。那么，前面程序的写法就存在逻辑重复的地方，应该把这个逻辑提取到一个函数中。
2、 条件4：0<a<200； 条件5：0<b<200； 条件6：0<c<200
这三个表达式也是同一个逻辑：判断一个数的范围是否在（0, 200）区间内，也应该把这个逻辑提取到一个函数中，去掉重复的逻辑，提高代码的可重用性。
可重用性的好处：比如，现在用户的需求改为了三条边的取值范围要改为[100,400]，那么，按前面的思路来说，需要改3个地方，而现在只需要在一个函数里改1个地方，这就是代码重用的好处。
3、条件7：a==b； 条件8：a==c； 条件9：b==c
这三个表达式的逻辑：判断两个数是否相等。也应该把它提取到一个函数中。
我们进一步来分析一下判断是否是等边三角形或等腰三角形的条件：
（1）前面程序的判断是从最直观的方式（a==b && b==c && a==c）（实际上只需要两个表达式成立即可）三条边都相等来判定是等边三角形；（a==b || b==c || a==c）只有两条边相等来判定是等腰三角形。
（2）转变一下思路：给定三个整数，然后用一个函数来判断这三个整数有几个相等，返回相等的个数，如果返回值等于3，那么它是等边三角形，如果返回值是2，那么它是等腰三角形，否则，它是一般三角形（如果不是直角三角形的话）。
4、条件10：a2+b2==c2 条件11：a2+ c2== b2 条件12：c2+b2== a2
这三个条件的处理方式有两种：
（1）跟前面三组分析一样，把相同的逻辑提取到一个函数中，然后三次调用。
（2）根据直角三角形的特点：斜边是最长的，所以我们可以事先写一个函数来找到最长的边，然后把它赋值给c，这样处理之后，只需要一次调用判定（a2+b2==c2）的函数了。
相关阅读：
白盒测试实例之四——程序设计
关键字：白盒测试
程序设计对于软件的质量和软件实施过程的难易程度起着至关重要的作用。好的设计，即使聘用没什么经验的开发人员都很容易产生出高质量的代码出来；而差的设计，即使是经验很丰富的开发人员也很容易产生缺陷，特别是可重用性、可测试性、可维护性、可扩展性等方面的缺陷。
经过以上的分析，下面来看一下如何设计。在下图中，每个方框都使用一个函数来实现，为了跟用户界面分开，最顶上的函数不要写在main函数中。
把思路用流程图的方式表达出来，不用停留在脑袋里：
具体的函数的调用关系图：
复杂模块triangleType的流程图：
相关阅读：
白盒测试实例之五——编码
1、Triangle.h
1. /*
2. * Copyright (c) 2008, 胡添发(hutianfa@163.com)
3. *
4. * 三角形类型判断
5. *
6. */
7.
8. #include<stdio.h>
9. #include<String.h>
10.
11. /*
12. * 判断一个整数是否在(0, 200)区间内
13. * 返回值：true-否； false-是
14. */
15. bool isOutOfRange(int i);
16.
17. /*
18. * 判断三条边是否合法(即：判断三条边都在合法的范围内)
19. * 返回值：true-是； false-否
20. */
21. bool isLegal(int a, int b, int c);
22.
23. /*
24. * 判断两条边之和是否大于第三边
25. * 返回值：true-是； false-否
26. */
27. bool isSumBiger(int a, int b, int c);
28.
29. /*
30. * 判断三条边是否能够组成三角形
31. * 返回值：true-是； false-否
32. */
33. bool isTriangle(int a, int b, int c);
34.
35. /*
36. * 判断两条边是否相等
37. * 返回值：true-是； false-否
38. */
39. bool isEquals(int a, int b);
40.
41. /*
42. * 求三角形有几条边相等
43. * 返回值：相等边的数量
44. */
45. int howManyEquals(int a, int b, int c);
46.
47. /*
48. * 判断是否满足两边平方之和是否等于第三边的平方
49. *
50. */
51. bool isPowerSumEquals(int a, int b, int c);
52.
53. /*
54. * 判断第一个数是否比第二个数大
55. */
56. bool isGreaterThan(int a, int b);
57.
58. /*
59. * 判断是否是直角三角形
60. *
61. */
62. bool isRightRriangle(int a, int b, int c);
63.
64. /*
65. * 判断三角形的类型，返回值：
66. * 1、不能组成三角形
67. * 2、等边三角形
68. * 3、等腰三角形
69. * 4、直角三角形
70. * 5、一般三角形
71. * 6、某些边不满足限制
72. */
73. int triangleType(int a, int b, int c);
白盒测试实例之六——单元测试的步骤
单元测试的步骤：
1、 理解需求和设计
理解设计是很重要的，特别是要搞清楚被测试模块在整个软件中所处的位置，这对测试的内容将会有很大的影响。需要记住的一个原则就是：好的设计，各模块只负责完成自己的事情，层次与分工是很明确的。在单元测试的时候，可以不用测试不属于被测试模块所负责的功能，以减少测试用例的冗余，集成测试的时候会有机会测试到的。
举例：
1. /*
2.
3. * 判断三条边是否能够组成三角形
4.
5. * 返回值：true-是； false-否
6.
7. */
8.
9. bool isTriangle(int a, int b, int c);
测试该函数的时候，只需要测试三条边（在合法的取值范围内的整数）是否能够满足两边之和是否大于第三边的功能，而不需要测试三条边是否在合法的范围（0， 200）之间的整数，因为调用该函数之前，一定要先通过下面函数的检查，要是检查不通过，就不会执行isTriangle函数。
1. /*
2.
3. * 判断三条边是否合法(即：判断三条边都在合法的范围内)
4.
5. * 返回值：true-是； false-否
6.
7. */
8.
9. bool isLegal(int a, int b, int c);
所以，单元测试主要是关注本单元的内部逻辑，而不用关注整个业务的逻辑，因为会有别的模块去完成相关的功能。
白盒测试实例之七——单元测试的尝试
以测试isOutOfRange函数为例，首先知道该函数在整个软件架构中处于最底层（叶子），所以对它进行测试并不需要写桩模块，只需要写驱动模块。要注意的问题是：对于测试结果是否通过测试不要使用printf方式打印被测试函数的返回结果值，否则就需要人工去检查结果了。
使用边界值的方法可以得到5个测试用例，写的驱动模块代码如下：
TestTriangle.cpp：
1. /*
2. * Copyright (c) 2008, 胡添发(hutianfa@163.com)
3. *
4. * 单元测试与集成测试
5. *
6. */
7. #include "Triangle.h"
8. /*
9. * 测试isOutOfRange函数，使用边界值的方法(0,1,5,199,200)
10. *
11. */
12. void testIsOutOfRange_try()
13. {
14. if(isOutOfRange(0) == true)
15. {
16. printf("pass!\n");
17. }
18. else
19. {
20. printf("fail!\n");
21. }
22.
23. if(isOutOfRange(1) == false)
24. {
25. printf("pass!\n");
26. }
27. else
28. {
29. printf("fail!\n");
30. }
31.
32. }
33.
34.
35. void main()
36. {
37. testIsOutOfRange_try();
38. }
小知识：做单元测试的时候，一般不直接在main函数中写所有的测试代码，否则的话，main函数将会非常庞大。正确的做法：针对每个函数分别创建一个或若干个（函数比较复杂时）测试函数，测试函数的名称习惯以test开头。
写到这里发现重复的代码太多了，而且如果测试用例数量很多的话，对于测试结果的检查也将是很大的工作量。在测试有错误的时候，这样的单元测试结果也很难获得更多关于错误的信息。
解决问题的途径可以采用cppUnit单元测试框架。不过这里为了让学生能够对单元测试和单元测试框架有进一步的理解，我决定自己写一个类似cppUnit的简单的测试框架。
相关阅读：
白盒测试实例之八——构建自己的单元测试框架（上）
在上一讲“单元测试的尝试”里我们遇到了几个问题：
1、代码重复的问题太多
2、测试结果需要人工去检查
3、对测试的总体信息也无从得知
本讲将构建一个简单的单元测试框架来解决以上的问题：
1、代码重复的问题太多
这个问题很容易解决，只需要把判断预期结果和实际结果的逻辑提取到某个函数中即可。从整个代码来看，有两种类型的结果的函数：
（1）返回布尔型
（2）返回整数
因此，需要两个类型的判断预期结果和实际结果是否相符的函数：
1. /*
2. * 判断是否取值为真
3. */
4. void assertTrue(char *msg, bool actual)
5. {
6. if(actual)
7. {
8. printf(".");
9. }
10. else
11. {
12. printf("F");
13. }
14. }
15.
16. /*
17. * 判断预期结果和实际结果是否相符
18. */
19. void assertEquals(char *msg, int expect, int actual)
20. {
21. if(expect == actual)
22. {
23. printf(".");
24. }
25. else
26. {
27. printf("F");
28. }
29. }
小知识：XUnit系列的框架的习惯使用assert*的命名来定义判断函数，对于通过的测试习惯打印一个“.”号，而对于失败的测试习惯打印一个“F”。
2、测试结果需要人工去检查
对于测试结果不要使用printf方式打印被测试函数的返回结果值就可以避免这个问题。
3、对测试的总体信息也无从得知
除了问题1的解决办法里使用“.”表示测试通过和“F”表示测试失败可以提高对测试结果的信息的直观性之外，做单元测试的人还希望能够得到以下的信息：
（1）执行的测试用例总数、通过的数量和失败的数量
（2）测试执行的时间
（3）如果测试用例执行失败了，希望知道是哪个测试用例失败，从而去分析失败的原因。
白盒测试实例之九——构建自己的单元测试框架（下）
完整的源代码如下：
1、UnitTest.h
1. /*
2. * Copyright (c) 2008, 胡添发
3. *
4. * 简单的单元测试框架
5. *
6. */
7.
8. #include<stdio.h>
9. #include<string.h>
10. #include<time.h>
11. #include<stdlib.h>
12.
13. /*
14. * VC中没有sleep函数，自己写一个
15. * wait单位是毫秒
16. */
17. extern void sleep(clock_t wait);
18.
19.
20. /*
21. * 判断是否取值为真
22. */
23. void assertTrue(char *msg, bool actual);
24.
25. /*
26. * 判断预期结果和实际结果是否相符
27. */
28. void assertEquals(char *msg, int expect, int actual);
29.
30. /*
31. * 初始化测试，开始计时
32. */
33. void init();
34.
35. /*
36. * 结束测试，结束计时，打印报告
37. */
38. void end();
白盒测试实例之十——集成测试的概念
测一、桩模块和驱动模块（以C语言为例）：
很多人对桩模块和驱动模块的概念会搞不清楚，下面先介绍这两个概念：
模块结构实例图：
假设现在项目组把任务分给了7个人，每个人负责实现一个模块。你负责的是B模块，你很优秀，第一个完成了编码工作，现在需要开展单元测试工作，先分析结构图：
1、由于B模块不是最顶层模块，所以它一定不包含main函数（A模块包含main函数），也就不能独立运行。
2、B模块调用了D模块和E模块，而目前D模块和E模块都还没有开发好，那么想让B模块通过编译器的编译也是不可能的。
那么怎样才能测试B模块呢？需要做：
1、写两个模块Sd和Se分别代替D模块和E模块（函数名、返回值、传递的参数相同），这样B模块就可以通过编译了。Sd模块和Se模块就是桩模块。
2、写一个模块Da用来代替A模块，里面包含main函数，可以在main函数中调用B模块，让B模块运行起来。Da模块就是驱动模块。
知识点：
桩模块的使命除了使得程序能够编译通过之外，还需要模拟返回被代替的模块的各种可能返回值（什么时候返回什么值需要根据测试用例的情况来决定）。
驱动模块的使命就是根据测试用例的设计去调用被测试模块，并且判断被测试模块的返回值是否与测试用例的预期结果相符。
二、集成测试策略：
1、 非增式集成测试
各个单元模块经过单元测试之后，一次性组装成完整的系统。
优点：集成过程很简单。
缺点：出现集成问题时，查找问题比较麻烦，而且测试容易遗漏。
范例：
2、 增式集成测试
（1）自顶向下
A、 纵向优先
从最顶层开始测试，需要写桩模块。测试的顺序：从跟节点开始，每次顺着某枝干到该枝干的叶子节点添加一个节点到已测试好的子系统中，接着再加入另一枝干的节点，直到所有节点集成到系统中。
B、 横向优先
跟纵向优先的区别在于：每次并不是顺着枝干走到叶子，而是逐一加入它的直属子节点。
纵向优先的范例：
（2）自底向上
每次从叶子节点开始测试，测试过的节点摘掉，然后把树上的叶子节点摘下来加入到已经测试好的子系统之中。优点：不需要写桩模块，但需要写驱动模块。
范例：
相关阅读：
-
如何在 LoadRunner 脚本中做关联 (Correlation)（转）
zhong51test 发布于 2008-11-26 14:53:41
-
Loadrunner中web_reg_save_param的使用详解(转)
zhong51test 发布于 2008-11-26 15:40:31
应用范围
在使用Loadrunner进行性能测试时，经常遇到一种情况，需要通过web页面修改某事务的状态。于是需要首先读出当前的事务的状态，再进行修改，此时便可以使用到web_reg_save_param了。可以通过它先将事务的状态读出写入一个自定义的变量中，根据变量的值来决定下一步的动作。简要说明
语法：int web_reg_save_param(const char *ParamName, <list of Attributes>, LAST);参数说明:
ParamName: 存放得到的动态内容的参数名称
list of Attributes: 其它属性，包括：Notfound, LB, RB, RelFrameID, Search, ORD, SaveOffset, Convert, SaveLen。属性值不分大小写
Notfound: 当在返回信息中找不到要找的内容时应该怎么处理
Notfound=error: 当在返回信息中找不到要找的内容时，发出一个错误讯息。这是缺省值。
Notfound=warning: 当在返回信息中找不到要找的内容时，只发出警告，脚本也会继续执行下去不会中断。
LB( Left Boundary ) : 返回信息的左边界字串。该属性必须有，并且区分大小写。
RB( Right Boundary ): 返回信息的右边界字串。该属性必须有，并且区分大小写。
RelFrameID: 相对于URL而言，欲查找的网页的Frame。此属性质可以是All或是数字，该属性可有可无。
Search : 返回信息的查找范围。可以是Headers，Body，Noresource，All(缺省)。该属性质可有可无。
ORD : 说明第几次出现的左边界子串的匹配项才是需要的内容。该属性可有可无，缺省值是1。如为All，则将所有找到的内容储存起来。
SaveOffset : 当找到匹配项后，从第几个字元开始存储到参数中。该属性不能为负数，缺省值为0。
SaveLen ：当找到匹配项后，偏移量之后的几个字元存储到参数中。缺省值是-1，表示一直到结尾的整个字串都存入参数。
Convert : 可取的值有以下两种:
HTML_TO_URL : 将 HTML-encoded 资料转成 URL-encoded 资料格式
HTML_TO_TEXT : 将 HTML-encoded 资料转成纯文字资料格式实例讲解
目的：取得页面中的商品状态，如果状态是正常态就改为注销态，否则改为正常态。录制脚本使用的是URL based scrīpt
将返回的数据记录到日志
直接手工访问页面，检查URL
该页面上点击右键，选择属性
看到URL，对照录制下的脚本中有：web_url("modifyOfferingStatePage.do",
"URL={url}/web/businessAccept/order/modifyOfferingStatePage.do?offeringId=
282172&offeringSpecId=1&offeringSpecName=普通宽带（ADSL/LAN）&customerName=
{clientname}&nodeId=260000&pos1=定购管理&pos2=修改商品状态",
"Resource=0",
"RecContentType=text/html",
"Referer={url}/web/businessAccept/order/orderMenu.do",
"Snapshot=t23.inf",
"Mode=HTTP",
LAST);于是在这段代码前添加注册函数：
web_reg_save_param("oldstate",
"LB/IC=原有商品状态：</td>",
"RB/IC=</td>",
"Search=body",
"Ord=1",
"RelFrameId=1",
"SaveOffset=57",
"SaveLen=4",
LAST);
web_url("modifyOfferingStatePage.do",
"URL={url}/web/businessAccept/order/modifyOfferingStatePage.do?offeringId=
282172&offeringSpecId=1&offeringSpecName=
普通宽带（ADSL/LAN）&customerName={clientname}&nodeId=
260000&pos1=定购管理&pos2=修改商品状态",
"Resource=0",
"RecContentType=text/html",
"Referer={url}/web/businessAccept/order/orderMenu.do",
"Snapshot=t23.inf",
"Mode=HTTP",
LAST);
...............
//将得到的内容存入日志用于检查
lr_log_message("getvalue : %s",lr_eval_string ("{oldstate}"));
if ( lr_eval_string ("{oldstate}") == "正常"){
web_submit_data("modifyOfferingState.do",
"Action={url}/web/businessAccept/order/modifyOfferingState.do",
"Method=POST",
"RecContentType=text/html",
"Referer={url}/web/businessAccept/order/modifyOfferingStatePage.do?offeringId=
282172&offeringSpecId=1&offeringSpecName=普通宽带（ADSL/LAN）&customerName=
{clientname}&nodeId=260000&pos1=定购管理&pos2=修改商品状态",
"Snapshot=t24.inf",
"Mode=HTTP",
ITEMDATA,
"Name=offering.state", "Value=1", ENDITEM,
"Name=offering.recentModifyReason", "Value=修改原因", ENDITEM,
"Name=offering.customerId", "Value=281218", ENDITEM,
"Name=offering.offeringId", "Value=282172", ENDITEM,
"Name=offering.offeringSpecId", "Value=1", ENDITEM,
"Name=offering.recentMender", "Value=root", ENDITEM,
"Name=offering.recentModifyDatetime", "Value=2005-01-16", ENDITEM,
"Name=nodeId", "Value=260000", ENDITEM,
"Name=customerName", "Value={clientname}", ENDITEM,
"Name=offeringSpecName", "Value=普通宽带（ADSL/LAN）", ENDITEM,
"Name=submit.x", "Value=33", ENDITEM,
"Name=submit.y", "Value=13", ENDITEM,
LAST);
}
Else
{
web_submit_data("modifyOfferingState.do",
"Action={url}/web/businessAccept/order/modifyOfferingState.do",
"Method=POST",
"RecContentType=text/html",
"Referer={url}/web/businessAccept/order/modifyOfferingStatePage.do?offeringId=
282172&offeringSpecId=1&offeringSpecName=普通宽带（ADSL/LAN）&customerName=
{clientname}&nodeId=260000&pos1=定购管理&pos2=修改商品状态",
"Snapshot=t24.inf",
"Mode=HTTP",
ITEMDATA,
"Name=offering.state", "Value=0", ENDITEM,
"Name=offering.recentModifyReason", "Value=修改原因", ENDITEM,
"Name=offering.customerId", "Value=281218", ENDITEM,
"Name=offering.offeringId", "Value=282172", ENDITEM,
"Name=offering.offeringSpecId", "Value=1", ENDITEM,
"Name=offering.recentMender", "Value=root", ENDITEM,
"Name=offering.recentModifyDatetime", "Value=2005-01-16", ENDITEM,
"Name=nodeId", "Value=260000", ENDITEM,
"Name=customerName", "Value={clientname}", ENDITEM,
"Name=offeringSpecName", "Value=普通宽带（ADSL/LAN）", ENDITEM,
"Name=submit.x", "Value=33", ENDITEM,
"Name=submit.y", "Value=13", ENDITEM,
LAST);
}
从日志中截取的真实的返回内容为：
vuser_init.c(689): <tr bgcolor="#F6F6F6">\r\n
vuser_init.c(689): <td width="30%" height="23" align="right">\r\n
vuser_init.c(689): 原有商品状态：</td>\r\n
vuser_init.c(689): <td width="70%" height="23"> 正常 </td>\r\n
vuser_init.c(689): </tr>\r\n
vuser_init.c(689): <tr bgcolor="#F4FBFE">\r\n
vuser_init.c(689): <td width="30%" height="23" align="right">\r\n
vuser_init.c(689): 修改后的状态：</td>\r\n
vuser_init.c(689): <td width="70%" height="23">\r\n
vuser_init.c(689): \r\n
vuser_init.c(689): \r\n
vuser_init.c(689): \r\n
vuser_init.c(689): <input type="radio" name='offering.state' value='4' checked>
可以看到左边界是：原有商品状态：</td>，
右边界是：</td>，偏移量为：57（包括了空格），
长度为：4（因为一个汉字长度为2），最后存入变量的值是：正常4．经验总结
1)为了便于脚本的调试，将返回的数据都写入日志是个好办法；
2)为了验证取得的数据是否是自己期望的，可以将取得的数据写入日志中进行验证，
例：lr_log_message("getvalue : %s",lr_eval_string ("{oldstate}"));
3)因为它是一个注册函数，必须在返回信息前使用，所以注册的位置必须正确，否则很可能得到类似如下错误：
4)vuser_init.c(734): Error -27190: No match found for the requested parameter "oldstate".
Check whether the requested boundaries exist in the response data. Also,
if the data you want to save exceeds 1024 bytes,
use web_set_max_html_param_len to increase the parameter size [MsgId: MERR-27190]
5)vuser_init.c(734): Error -27187: The above "not found"
error(s) may be explained by header and body byte counts being 0 and 0,
respectively. [MsgId: MERR-27187]
6)vuser_init.c(734):
web_concurrent_end highest severity level was "ERROR" [MsgId: MMSG-27181]
7)所以使用手工方法，右键页面确定在代码中哪个位置之前注册函数至关重要
8)如果脚本中中文为乱码，可能是因为源文件的字符集和操作系统字符集不匹配。试试：
-
负载压力测试动态参数关联详解(网络转载)
zhong51test 发布于 2008-12-10 11:33:08
-
负载压力测试动态参数关联详解(网络转载)
zhong51test 发布于 2008-12-10 11:33:09
-
谈谈LoadRunner中Pacing的设置[转]
zhong51test 发布于 2009-08-13 14:02:33
-
软件企业质量保证的基石―QA、QC的良性协作（转贴）
yexu 发布于 2007-01-29 11:40:03
-
测试报告文档
nicklyl 发布于 2008-02-26 21:38:08
-
Bug生命周期
testhome 发布于 2008-10-18 20:45:44
首先测试发现Bug并提交bug（bug状态为new/Active），然后分配bug(bug状态为assigned)，开发人员接收并修改bug（bug状态为fixed/Resolved），最后测试人员验证bug(bug状态为Closed)
此时肯定有人会发现问题，这么简单的流程图是太理想化了，无法满足实际。这是当然，Bug是可以‘死而复生’的，也许在下个版本问题有再次出现，又或许从测试人员角度讲，问题验证不通过怎么办？从管理及开发角度想，这不是bug又怎么办。带着这些疑问，我们进一步完善流程图。
基本可以满足一般的使用。但是我们忽略了一点，bug是有分类的“严重程度（Severity）和优先级别（Priority）”。在实际的应用中，很多项目的bug都比较多，而此时由于bug只在非极端条件下产生或者修改需要牵动这个框架，会造成更多的潜在缺陷，在悲观点就是面对市场压力需要尽快发布的情况等。Bug是否被修改？什么时候修改？就是需要定夺的了。又想到一点，如果此项目是多个测试人员同时测试，那是否bug会提交重复呢？理清楚思路后，就可以在进一步完善我们的流程图啦！
-
操作系统监控(1)
xiaohanjiang 发布于 2010-07-19 10:18:01
-
【转】如何估算测试时间
紫梦 发布于 2010-07-12 11:02:05
-
面试题--10年金山WPS Office系统测试
bobo45123 发布于 2010-07-06 21:49:28
一、
问答题（共20分）（1）以下循环执行次数是？ （5分）
#include
main()
{
int i;
for(i=2;i==0;)printf("%d\n",i--)
printf("%d\n",i);
}
（2）一个程序，实现了图片转文本的功能，可以将任意图片转换成文本内容，并输出，请说明你的测试重点。 （5分）
（3）产品的测试通常涉及以下几个方面：单元测试、集成测试、系统测试。
请简述系统测试相关的测试点，并举实例说明。 （5分）
4-6题中，可以选择任意一题作答，共5分
（4）请简述，哪些操作系统分别支持哪些文件系统格式？
（5）给你一个软件产品，如何预估完成测试任务所需的时间？
（6）Windows XP多用户下"注销"与"切换"的区别？
二、测试设计题（共40分）
（1）请写出以下功能的测试思路及关键用例 （20分）
功能说明：下图是一个便签软件，点击+可以增加多个便签，下图是新建了两个便签。
（注意，测试不要要只局限在便签的增删）
（2）如图所示，是一个PDF书籍阅读软件。假设功能已开发完成，要进行测试，请写出测试思路。（20分）
三、分析题（共10分）
（1）请数出下图中三角形的个数，并给出简要的分析思路 （5分）
（2）一只叫小快的蜗牛从井底爬到井口，白天小快要睡觉，晚上才出来活动，每个晚上小快可以向上爬6尺，但是白天睡觉的时候会下滑5尺，井深20尺，问几天小快可以爬出来？请写出分析思路。 （5分）
四、程序题（共30分）
（1）用你熟悉的开发语言：实现输入一个仅包含英文字母和空格的字符串，找出该字符串中没有出现过的字母（不区分大小写）。请写出思路及代码（可用伪代码实现）。 （15分）
（2）用你熟悉的开发语言：实现输入一个正整数，求它是几位数。请写出思路及代码（可用伪代码实现）。 （15分）
（注意：不允许将正整数转换为字符串来用strlen处理）
-
缺陷严重级别问题说明
wfl51 发布于 2010-06-30 23:48:44
-
[转载]敏捷软件开发模型-SCRUM
chicochen 发布于 2008-07-12 17:27:45
一 什么是Scrum?
Scrum (英式橄榄球争球队), 软件开发模型是敏捷开发的一种，在最近的一两年内逐渐流行起来。
Scrum的基本假设是：
开发软件就像开发新产品，无法一开始就能定义软件产品最终的规程，过程中需要研发、创意、尝试错误，所以没有一种固定的流程可以保证专案成功。Scrum 将软件开发团队比拟成橄榄球队，有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都朝向目标有明确的推进。Scrum 开发流程通常以 30 天(或者更短的一段时间)为一个阶段，由客户提供新产品的需求规格开始，开发团队与客户于每一个阶段开始时挑选该完成的规格部分，开发团队必须尽力于 30 天后交付成果，团队每天用 15 分钟开会检查每个成员的进度与计划，了解所遭遇的困难并设法排除。
二 Scrum较传统开发模型的优点
Scrum模型的一个显著特点就是响应变化，它能够尽快地响应变化。下面的图片使用传统的软件开发模型(瀑布模型、螺旋模型或迭代模型)。随着系统因素（内部和外部因素）的复杂度增加，项目成功的可能性就迅速降低。
下图是Scrum模型和传统模型的对比：
三 Scrum模型
一) 有关Scrum的几个名词backlog: 可以预知的所有任务， 包括功能性的和非功能性的所有任务。
sprint:一次跌代开发的时间周期，一般最多以30天为一个周期.在这段时间内，开发团队需要完成一个制定的backlog,并且最终成果是一个增量的，可以交付的产品。
sprint backlog:一个sprint周期内所需要完成的任务。
scrumMaster: 负责监督整个Scrum进程，修订计划的一个团队成员。
time-box: 一个用于开会时间段。比如每个daily scrum meeting的time-box为15分钟。
sprint planning meeting: 在启动每个sprint前召开。一般为一天时间（8小时）。该会议需要制定的任务是：产品Owner和团队成员将backlog分解成小的功能模块, 决定在即将进行的sprint里需要完成多少小功能模块，确定好这个Product Backlog的任务优先级。另外，该会议还需详细地讨论如何能够按照需求完成这些小功能模块。制定的这些模块的工作量以小时计算。Daily Scrum meeting：开发团队成员召开，一般为15分钟。每个开发成员需要向ScrumMaster汇报三个项目：今天完成了什么？ 是否遇到了障碍？ 即将要做什么？通过该会议，团队成员可以相互了解项目进度。
Sprint review meeting：在每个Sprint结束后，这个Team将这个Sprint的工作成果演示给Product Owner和其他相关的人员。一般该会议为４小时。
Sprint retrospective meeting：对刚结束的Sprint进行总结。会议的参与人员为团队开发的内部人员。一般该会议为３小时。
二）实施Scrum的过程简单介绍
1) 将整个产品的backlog分解成Sprint Backlog,这个Sprint Backlog是按照目前的人力物力条件可以完成的。
2) 召开sprint planning meeting，划分，确定这个Sprint内需要完成的任务，标注任务的优先级并分配给每个成员。注意这里的任务是以小时计算的，并不是按人天计算。
3) 进入sprint开发周期，在这个周期内，每天需要召开Daily Scrum meeting。
4) 整个sprint周期结束，召开Sprint review meeting，将成果演示给Product Owner.
5) 团队成员最后召开Sprint retrospective meeting，总结问题和经验。
6) 这样周而复始，按照同样的步骤进行下一次Sprint.
整个过程如下图所示：
-
软件开发模型
jejo 发布于 2009-11-18 18:25:39
标题搜索
我的存档
数据统计
- 访问量: 22471
- 日志数: 55
- 书签数: 1
- 建立时间: 2007-08-22
- 更新时间: 2010-02-27
