此文系51Testing软件测试网原创，转载请注明出处！
本周问题：测试工程师如何规划自己的职业生涯？（08-03-14）
目前，不少测试工程师职业发展方向很迷茫。软件测试工程师的职业发展路线是什么？是走技术路线、还是管理路线、或者其他？若您选择其中一条路线，您是如何来储备自己的能力，如何达到自己的职业发展目标？欢迎大家各抒己见！参与讨论请点击》》
一、黑盒测试如何保证需求的覆盖度？（08-02-22）
会员shenlake：
主要要做好测试需求分析
测试需求分析分两步：
1 测试需求的获取
需求的来源：显式需求（1）原始需求说明书（2）产品规格书（3）软件需求文档（4）有无继承性文档（5）经验库（6）通用的协议规范
隐式需求：用户的主观感受，市场的主流观点，专业人士的评价分析
2 需求的分析 ，产生测试需求文档
将不同的需求来源划分成一个个需求点，针对每一点进行测试分析，（1）界定测试范围（2）利用各种测试设计的方法产生测试点
更多精彩回答请点击》》
二、测试过程中如何应对频繁的版本变更？（08-02-29）
会员huior：
在软件开发过程不规范的项目组中，这种情况是非常常见的。2001年，我接触过的一个公司，它刚刚成立软件测试部，当时的测试部遇到的情况和上面讲的几乎如出一辙，搞得测试员叫苦不迭，开发部的程序员也天天抱怨头疼。
具体到当前这个项目遇到的情况，从上面的问题分析，我认为主要原因是：开发部提供的测试版本太过随意，导致质量太差。要解决它，我认为有以下几个关键点：
×在项目开始时，最好能先开发一个原型出来，原型基本上要确定整体界面的风格、统一的操作习惯等，以后的开发要以原型为基础进行；
×开发部使用版本控制工具，比如CVS、VSS等，并且要保证每天定时Check-in和Check-out，避免积累大量代码，同时要强调在Check-out和Check-in的时候要注明缘由，是为了修改某个bug还是增加新功能等；
×每日构建（Daily Build）：每日构建要形成制度，构建过程最好能自动进行，如果因为是第一次这样做，没有经验，遇到技术问题，在这种情况下，建议由测试部指派一名测试员加入到开发部，协助开发部进行人工构建，每日能集成一个能运行起来的完整的软件系统；
×强化冒烟测试（Smoke testing）：加入开发部的测试员在构建后，集成了一个完整的软件系统，要及时对每一个build进行验证（Build VerificationTest），也可以称之为“冒烟测试”，对软件的基本功能点进行验证；
×强化测试的准入条件：软件测试启动是有条件的，并不是说开发部拿个软件过来，开发部就要测试，比如要启动测试活动，必须要有需求规格说明书、设计书、单元测试报告、冒烟测试报告等，这是前提。满足不了这个前提条件，测试活动不会启动。当然这个制度需要公司管理高层的认可，在项目启动时要和项目经理协调好的；
×强化BUG管理：测试组要使用BUG管理工具，例如bugzilla、JiRA等，要保证 bug、版本、以及人员的对应关系，同时分析在不同的版本、不同的时间段、不同的模块中BUG的走势，确定“危险模块”为重点测试对象，预测未来的BUG走势和工作量等。
×积极的态度：无论是开发部还是测试部，在这个困难的过程中都要有积极的态度，遇到问题要及时沟通，以最高效的方式解决问题。
要从根本上根治这种矛盾，需要一套完整的、规范的开发过程。以上的措施只是一部分，只能在最短的时间内缓解矛盾。
更多精彩回答请点击》》
三、如何量化评估被测试软件的质量？（08-03-07）
会员charles：
1、软件需求规格说明书的功能点尽可能的量化；
2、测试用例设计要通过评审，要求需求覆盖率达100％；
3、查看缺陷分别按时间的趋势图、按模块的饼状分布图，按时间的趋势图是否是下降的趋势，按模块的分布图可以发现缺陷集中的相关模块；
4、完成系统的性能、安全、易用性等其他隐式需求的测试；
5、测试用例的执行覆盖率要达到100％；
6、程序代码语句覆盖率不低于80％；
7、缺陷修复率情况：
1) 致命、严重的缺陷修复率要达到100％以上；
2) 一般不太严重的缺陷修复率要达到80％以上；
3) 易用性不影响系统应用的缺陷修复率达到60％以上；
8、系统通过需求人员的确认测试，系统满足需求规格说明书的说明。
更多精彩回答请点击》》
