(本文摘自:软件测试计数与管理 张大方 李玮编著 .如若侵犯了您的版权,请通知我,立即删除)
    软件测试是保证软件的关键元素,代表了规约,设计和编码的最终检查.开发人员与测试人员在工作上是一个互补的关系:开发人员是建设者的角色,视图把抽象概念实现为具体的软件;而测试人员则是破坏者的角色,视图设计和执行测试用例来"摧毁"已建立的软件."摧毁"目的是为了消除潜伏在软件中的错误,以保证质量要求.
    下面是一些知道测试工作的基本原则:
    (1) 应当尽早地和不断地进行软件测试
       不应把软件测试仅仅看作软件开发的一个独立阶段,而应当把它贯穿到软件开发的各个阶段中.坚持在软件开发的各个阶段实施技术评审,才能在开发过程中尽早发现和预防错误.开发过程每前进一步,发现和修复缺陷的平均代价要增长10倍.
    (2) 程序员应避免检查自己的程序
       程序员应避免检查测试自己编写的程序,开发小组也应尽可能避免测试自己小组开发的程序.如果条件允许,最好建立独立的软件测试机构.这点不能与程序的调试(Debuging)混淆.
    (3) 完全测试程序是不可能的
       初涉软件测试者可能认为拿到软件后就可以进行完全测试,找出所有的软件缺陷,并使软件臻于完美.这种想法从工作上来讲,固然很好,不过在测试中,是不现实的;即使最简单的程序也不见得可行,因为:输入量太多,软件实现途径太多.
    (4) 软件测试是有一定风险的行为
       如果不决定去测试所有情况,那就是选择了风险.有可能程序员恰好在这种情况下留下一个软件缺陷,而软件测试员没有对其测试,客户却会用到它,而且可能 发现缺陷.这就将成为修复代价很高的缺陷,因为它直到软件交付时才被客户发现.
       软件测试员要学会一个主要原则是:如何把软件缺陷减少到可以控制的范围,并针对软件缺陷可能带给客户的风险进行分析,寻找最合适的测试量.
    (5) 充分注意测试中的群集现象
       在被测试程序段中,若发现错误数目多,则残存错误数目也比较多.这种错误群集性现象,也为许多程序的测试实践所证实.根据这个规律,应当对错误群集的程序段进行重点测试,以提高测试投资的效益.
    (6) 严格执行测试计划,排除测试的随意性
        测试之前应仔细考虑测试的项目,对每一项测试做出周密的计划,包括被测试程序的功能,输入输出,测试内容,进度安排,资源要求,测试用例的选择,控制方式和过程等;还包括系统的组装方式,跟踪规程,调试规程,回归测试的规定以及评价标准等.对于测试计划,要明确规定,不要随意修改.
    (7) 应当对每一个测试结果进行全面检查
        有些错误的征兆输出实例结果时已明显地表现出来了,但是如果不仔细全面地检查测试结果,就会使这些错误被遗漏掉.所以必须对预期的输出结果明确定义,对全面的结果仔细分析检查,抓住征兆,发现错误.
    (8) 妥善保存测试文档等
        妥善保存测试计划,测试用例,出错统计和最终分析报告,为维护提供方便.
    (9) 软件测试的Pareto法则(8:2):

• 20%的模块产生80%的缺陷;
• 20%的缺陷消耗80%的维护费用;
• 20%的原因导致了80%的缺陷.

    (10) 并非所有的软件缺陷都能修复
       在软件测试过程中,即使拼尽权力,也不能修复所有的缺陷.这并不以为着软件测试员未达到目的,或者项目小组将发布质量欠佳的产品.测试人员应进行正确的判断,弄清什么情况下不能追求完美.项目小组需要对每一个缺陷进行取舍,根据风险决定那些需要修复,哪些不需要.
       不需要修复所有缺陷的原因如下:

• 没有足够的时间.在任何一个项目中,通常是软件功能多或者交付产品时间短,而代码编写人员和软件测试人员少,而且在项目进度中没有为软件测试和修改缺陷留出足够的时间.
• 修复风险太大.这种情形很常见.软件本身不脆弱的,难以理清头绪.修复一个软件缺陷可能 导致其它缺陷出现.在紧迫的产品发布进度压力下,修改软件将冒很大的风险.
• 不值得修复.不常出现的软件缺陷和在不常用功能中出现的缺陷可能 放过,可能躲过和用户有办法预防或避免的软件缺陷通常不用修复.这些都可以归结为商业风险决策.决策过程通常由软件测试员,项目管理员,开发人员和营销人员共同参与.

    (11) Bug的80%原则
       一般情况下,在分析,设计,实验阶段的复审和测试工作能够发现和避免80%的Bug,而系统的软件测试能够找出其余Bug中80%,最后约5%的bug只有在用户长期的使用过程中才能发现.因此测试只能保证尽可能发现错误,不可能保证风险所有错误.
    (12) 软件测试在项目小组中的处事原则
       软件测试员的任务是检查和指正同事的工作,挑毛病,公布发现的问题,这项工作是不受欢迎的.下面是保证小组开发人员和睦相处的建议:

• 尽早找出软件缺陷
• 控制情绪.诚然,软件测试员真心喜爱自己的工作,当发现严重的软件缺陷时会很兴奋;但是如果兴冲冲地闯进开发人员的房间并当着其它同事的面告诉程序中存在的严重的缺陷时,他会很反感的.可以通过邮件或管理软件的方法通知开发人员.
• 不要总报告坏消息.
  

      

   
 

 最近在测试一系统的时候,录制脚本没有错误,回放的时候总是出现如下错误:
 Action.c(52): Error -26612: HTTP Status-Code=500 (Internal Server Error) for "http://10.140.99.65:8081/sfxt/zhengChangSF.do"          [MsgId: MERR-26612]
Action.c(52): web_submit_form("zhengChangSF.do") highest severity level was "ERROR", 1617 body bytes, 182 header bytes          [MsgId: MMSG-26388]
  郁闷的是这段程序原先曾经回放成功过,因为是新手,老是不知道原因在哪里.按照LR帮助文档中的错误代码找原因,发现根本没有他们说的情况;上网查找,关于这个错误代码的帖子还不少,不过问题的根本也没有一样的;请教了51testing的高手,也提出了一些方法,结果都不行.郁闷!
  只好自己慢慢找原因,费了老半天,最后从服务器的日志上,才发现是因为程序一词汇表空指针问题没有处理好.
  那个程序不是我开发的.
  虽然这不是大问题,但是对于我这测试新手来说,无疑是一个进步和收获!关键是它让我明白找错误原因一定要纵观全局,不能仅看表面.要从操作和程序本身去找问题的根本原因.
  解决了,就是进步!

 最近比较郁闷.上周领导要求去测试一个公司同事以前开发的系统,这个系统总是在运行一段时间后,就非常慢,不过只要重启Tomcat就可以了,不需要启动服务器.(我们小公司,不规范,以前没有经过性能测试,所以才这样,不要笑话!)
 结果没有找到原因.
 现在,公司就我一个人做测试,还没有正规学习培训,全在这里闭门造车,很无助啊!
 唉......

  打开LR 9 的web server ，报1080端口被占用，解决如下：

  修改%Lr9_Home%\WebTours的xitami.cfg 的portbase=1000为2000或者其他。

  实际HTTP端口为portbase+80，在这个配置之前有解释为什么这样的，自己看看就明白！

 

 本人，目前为软件测试菜鸟一个。

 不过我想在此浪费一些空间，记录下我的“成长”足迹，假如有一天，我的技术增长了。也许我会更改我的空间的名字，但是现在，就这样了。

 目前的文章，都是我在测试里摸爬滚打所遇到的，我想或许会有朋友遇到和我一样的问题。说不定对别人有些 帮助，如果能达到这样的目的，本人再高兴不过。