语源科技BlogJava-baijing1018

测试中Bug的分类

白静 — Tue, 11 Jul 2006 01:38:00 GMT

1. 新提交的Bug
2. 开发正在修改的Bug
3. 已经修改好并且等待测试人员验证的Bug
4. 验证通过的Bug
5. 验证没有通过的Bug
6. 设计问题
7. 测试人员报错
8. 暂时不修改的Bug

这是我总结的，还望哪位爱好者共同交流。

白静 2006-07-11 09:38 发表评论

测试大纲和测试计划

白静 — Mon, 19 Jun 2006 08:50:00 GMT

很多人都把这两者弄混在这里把这两个简单的说一下

测试大纲只是简单的描述如何开展测试，而测试计划是针对测试中的每个环节的。单元测试、集成测试、系统测试等一般都写测试计划，写的重点不同。而大纲只是简要的写一下测试策略是什么，需要做哪些测试，测试过程如何组织，测试人员包括哪些。可以说管理人员写测试大纲，而测试人员写测试计划。

白静 2006-06-19 16:50 发表评论

小谈“软件测试”

白静 — Mon, 05 Jun 2006 09:43:00 GMT

       一提起“软件测试”，总有不少人很反感，因为在他们得印象当中，做测试的就是整天没事干，专挑别人毛病的；甚至还有不少程序员就感觉“测试和开发”人员是对立的……
       其实不然，软件测试是在软件开发过程中是和开发人员相互合作，不存在对立关系的，他也是一个独立的部门。测试就是在一个程序被交付到最终用户手上之前找出程序中的错误为目的活动。
       测试是检查产品的质量，而不是检查开发人员的质量；因此，对立的关系是不存在的。
       而测试的目的，也不是简单狭义的找出Bug，进行测试又分为两种立场：从用户的角度出发，就是希望通过软件测试来充分暴露软件中存在的问题和缺陷，从而考虑是否可以接受该产品；从开发者的角度出发，就是希望通过测试来表明软件产品不存在错误，已经正确地实现了用户的需求，从而确立人们对软件质量的信心。中国软件测评中心的测试原则也是如此。
    一个软件的开发往往需要大量的人力和和时间，因此成功的测试就是要以最少的人力和时间，系统的找出软件种潜在的各种错误和缺陷，它能够证明软件的功能和性能与需求是否相符合，而实施测试所收集到的测试结果数据也为可靠性分析提供了依据。但是测试不能表明软件中不存在错误，它只能表明尽可能的找出软件中存在错误。
    在这里，附带的说一下软件质量缺陷的原因，主要是一下几方面的原因：
    1.缺乏或者没有进行沟通
    2.软件复杂度
    3.编程错误
    4.不断变更的需求
    5.时间的压力
    6.人员的自大
    7.缺乏文档的代码
    8.软件开发工具
    另外，一个好的测试的属性是指：
    1. 一个好的测试发现错误的可能性很高
    2. 一个好的测试并不冗余
    3. 一个好的测试应该是“最佳品种”
    4. 一个好的测试既不会太简单，也不会太复杂
    随着生社会的发展，用户对软件质量的要求也更高了，已不是简单的看功能的实现了，而是越来越重视软件是否经过了测试和测试的结果。能经受测试的软件，才是一个成功的软件、优秀的软件。因此，一定要重视软件测试！

白静 2006-06-05 17:43 发表评论

测试错误类型分类

白静 — Sat, 03 Jun 2006 05:35:00 GMT

根据需要把测试中出现的错误类型简单的分一下类，主要分为四类， A 类严重错误、 B 类较严重错误、 C 类一般错误、 D 类轻微错误，下面就每种情况做一下详细的介绍：

A 类严重错误：

1．由程序引起的死机、非正常退出；

2．死循环；

3．数据库发生死锁；

4．因错误操作导致的程序中断；

5．功能错误；

6．与数据库连接错误；

7．数据通讯错误；

B 类较严重错误：

1．程序错误；

2．程序接口错误；

3．数据库的表、业务规则、缺省性、未加完整性等约束条件；

C 类一般错误：

1．操作界面错误（包括数据窗口内列名定义、含义是否一致）；

2．打印格或内容错误；

3．简单的限制未放在前台控制；

4．删除操作未给出提示；

5．数据库表中有过多的空字段

D 类轻微错误：

1．界面不规范；

2．辅助说明描述不规范；

3．输入、输出不规范；

4．长操作未给出用户提示；

5．提示窗口文字未采用行业术语；

6．可输入区域和只读区域没有给出明显的区分标志；

软件合格标准

A 类严重错误	B 类较严重错误	C 类一般错误	D 类轻微错误
无	无

白静 2006-06-03 13:35 发表评论

第二轮测试圆满结束

白静 — Fri, 02 Jun 2006 08:42:00 GMT

        软件测试的本质以及最好的测试方式就是以最真实的方式模拟各种真实用户（包括专业用户、无聊用户、黑客、甚至变态用户）对软件进行操作和使用，从中查找出软件的缺陷，并促使其按缺陷严重性和优先级的最优组合方式被修正。
        针对我们公司所接受测试的系统，我做一下简单的总结。
        本次测试根据系统情况主要采用黑盒测试，共测试了系统的2大部分功能，包含23个功能模块，目前已测试了两轮，下面就两轮的结果做一下分析：
         第一轮测试使用测试用例一共286个，未通过用例28个，未通过比例为9.8%；随没有发现严重错误和较严重错误，发现一般错误24个，轻微错误80个；有些功能没有满足功能需求，没有达到期待的结果；
        第二轮测试使用测试用例一共317个，未通过用例4个，未通过比例为1.3%；没有发现严重错误和较严重错误，发现一般错误4个，轻微错误31个；
         两轮测试综合比较：第一轮发现的错误，经过维护，在第二轮测试中已明显降低，未通过用例个数由28个降为4个，一般错误已由24个降为4个，轻微错误由80个降为31个。说明第一轮测试后的维护是很有效的，希望第三轮的测试会更加精彩！

白静 2006-06-02 16:42 发表评论

测试的原则

白静 — Thu, 01 Jun 2006 03:36:00 GMT

软件测试的原则

软件测试从不同的角度出发会派生出两种不同的测试原则，从用户的角度出发，就是希望通过软件测试能充分暴露软件中存在的问题和缺陷，从而考虑是否可以接受该产品，从开发者的角度出发，就是希望测试能表明软件产品不存在错误，已经正确地实现了用户的需求，确立人们对软件质量的信心。中国软件评测中心的测试原则就是从用户和开发者的角度出发进行软件产品测试的，通过我们的测试，可以为用户提供放心的产品，并对优秀的产品进行认证。为了达到上述的原则，那么需要注意以下几点：
1．应当把“尽早和不断的测试”作为开发者的座右铭
2．程序员应该避免检查自己的程序，测试工作应该由独立的专业的软件测试机构来完成。
3．设计测试用例时应该考虑到合法的输入和不合法的输入以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。
4．一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。
5．对测试错误结果一定要有一个确认的过程，一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。
6．制定严格的测试计划，并把测试时间安排的尽量宽松，不要希望在极短的时间内完成一个高水平的测试。
7．回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多的错误出现的现象并不少见。
8．妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。

白静 2006-06-01 11:36 发表评论

随笔

白静 — Thu, 01 Jun 2006 02:41:00 GMT

一直没有发文章，很抱歉，但从今天起，我会把自己所知道的和想知道都发在上面，关于技术的，关于工作的，关于疑问，关于了解的……都会一一发在上面的，或许我现在的水平不高，但我相信，经过我的努力，和在这里的成长发展，我会有一个质的飞跃的！
我相信：有信心就有成功！有梦想就有舞台！

白静 2006-06-01 10:41 发表评论