测试结果量化，对于测试经理来说，是一个考验，一个比较大的挑战，做不好，会死的很惨，因为我这里的测试经理对的是多头人员：部门主任、测试人员、项目经理、开发人员。 首先也要说明一点，测试量化应该是与开发考核相辅相成的，也就是说，需要比较好的实现测试量化的制度，在开发考核的制度方面也应该建立的相对的完善。开发考核和测试量化考核都应该是建立在事实数据基础上，而不应该以主观评定——当然，评价因
测试技术包含哪些，大家列出来看看。 周一开古~（结果估计大家想都想不到）^_^
说明：此插件提供了soapui生成excel的报告的功能。报告信息包括运行时间，总共能点数，通过和失败功能点数。每一个测试功能点通过与非的信息，如果未通过则伴有详细的错误信息。 一、安装方法（推荐）jxl-2.6.2.jar 复制到\jre\lib\ext\"SoapuiTK.jar 复制到\jre\lib\ext\"PetercoolLogtool.groovy 复制到\bi
转眼，出来找工作已经一个月了，不知不觉地过了一个月，知道家里人来催，喊回家过年了，才恍然醒悟，居然直到现在还没找到工作的我，如何回去?来回的车费，现在的我仍旧没有那个能力去自我担负，在这边一个多月的消费也完全不是自己所付，难道我要一无所成的回去吗。不想也不愿意，可是不清楚自己到底哪里做错了，
目前流行的界面风格有三种方式：多窗体、单窗体以及资源管理器风格，无论那种风格，以下规则是应该被重视的。 1 ：易用性 ： 按钮名称应该易懂，用词准确，屏弃没楞两可的字眼，要与同一界面上的其它按钮易于区分，能望文知意最好。理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作。 易用性细则： 1):完成相同或相近功能的按钮用Frame框起来，常用按钮要支持快捷方式。 2):完成同一
dsfsdfsdf
- - 就是这么纠结
粗俗的文字，粗俗的语言，用于应对这个粗俗的世界。2010年，我依旧单纯的活着。 软件还是那个软件，工作还是那个工作，测试还是那个测试，加班还是加班，唯一不变的是对加班的执着，对自由的向往。 如果上帝给我一个愿望，我愿意：让2010年不在加班。
2010-02-03
1、查询所有需求项-- This query shows all requirements in all folders.SELECT REQ.RQ_REQ_ID AS 'Requirement ID', REQ.RQ_USER_01 AS 'Req ID Project', -- this has the original REQ ID from pr
Requirement (REQ)Req ID (RQ_REQ_ID)Name (RQ_REQ_NAME)Description (RQ_REQ_COMMENT)Requirement Type (RQ_TYPE_ID)Is Folder (RQ_IS_FOLDER) – beware. This contains incorrect data (folders with value “
