如果时间紧促,怎样完成测试

gucciyoung

如题

skinapi

提到完成测试，就涉及到测试结束标准的设定，这样就需要考虑2种情况了：
1、按照原有测试结束标准完成
2、调整测试结束标准按照新的标准完成

时间紧迫的情况下考虑：
1、能否延长时间
2、能否增加人手，比如找开发人员帮忙
3、能否加班
4、能否减少测试工作内容

另外需要把时间紧迫对测试造成的影响反馈给项目经理

red-hat

还可以考虑确定测试的重要级别优先级：哪些是必须要测试的？哪些是要优先测试的

sundyhui0322

经常会遇到由于RD release 版本的delay导致测试schedule的压缩，当人手已经分配好不能增加，schedule也没有太多的可增长性的情况下，多数就是来压缩测试，精确的说应该是精捡测试。功能当然要都测到（因为有时候RD在解决bug的同时会关闭一些功能或子功能块，但当他们把bug修正好后，只做了对bug的验证却忘记重新打开关闭的功能块等，从而导致不应该有的新问题的出现），但要分轻重。一般RD修正软件版本多数都是修正bug或完善功能。那么我们就要把更多的注意力放置于bug修复的验证和相关影响的验证上，完善功能的话就要针对被完善功能的测试及完善此功能可能对其他功能或父功能的影响上作验证。
这就涉及到一个重要的问题，对test case的选择。当然重点地测试部分，一般case都要执行到，但对其他不是本次测试的重点地部分怎样选择case，是一个难题。一般我们做test procedure时（有的公司譬如我我以前的公司，当初是没有单独的case库的，一个案子的case和测试规程都是写在test plan中，当然啦，case定义比较模糊，对于测试执行者的指导性很少，测试的主观性比较强）case的执行顺序未必是验证点地优先级顺序，往往都是是基于效率上安排测试顺序的。所以对于测试执行者来说恐怕很难确定究竟哪些case需要执行，哪些本次测试可以忽略。对于这样的问题，我认为可以从两方面着手。一是测试规程的设计阶段，最好就明确出case的重要级别，这样在我们做回归验证是就有了重点。另外一方面，若我们没有定义case的重要级别，那么在时间紧促，且此功能不是验证重点地时候，那么一般我们要把此功能在正常的输入下跑一边确保基本功能的正确性，另外针对此功能易出错的方面做个验证。

另外，说一些边外话，case的维护很重要，往往在我们设计时不能很准确的确定case的重要级别，往往都是通过一次次测试中发现归纳而来，同样异常出错的处理上也多数都是通过测试总结出来，少数是由经验积累而提前做好设计的。所以我们要边测试边跟新你的case库，或许公司没有一个很完善的case库，但作为测试执行者或者设计者来说，自己都要总结一个case库(或者叫做知识库)。一个好的测试者要善于总结，这样才能设计出更简洁完善的case，才能在测试过程中更快更准的发现bug。

[ 本帖最后由 sundyhui0322 于 2008-6-29 13:18 编辑 ]