个人觉得时间紧的话重心就放在主要功能上，保证软件能用。

首先驳斥他“保证软件的质量”的说法，测试在项目中的作用是质量控制，而不是质量保证，那是项目经理该做的事情。
事已至此，时间紧迫，缺乏文档，没有用例，当务之急，要了解整个项目的背景和需求，确定用户的使用场景，以一个用户的身份去使用软件，在操作软件的过程中补充用例。
优先使用那些用户经常使用和较为重要的功能，确保在大多数场景下，软件可以正常运行。

“保证软件质量”这句是不是面试官使诈，真不好说，看这人心里是不是有些...
阴暗= =
我觉得应该从这几方面入手：
1.业务范围。包含任务的边界，就是这个软件能够控制的业务，还有一部分业务是不由它控制的。比方说商品支付，在支付操作之前都是你们软件能控制的业务，而支付这个过程需要支付宝/网银来完成，这就不是你能控制的了。弄清楚这些边界，不做无用功。
2.了解使用的用户人群，用户/管理员/运营人员，优先测试用户人群使用的功能；兼容性要照顾到，如果时间紧急，看情况砍掉部分测试。
3.保证基本功能的正确；还要保证容错能力，容错能力有些情况不是软件能控制的，就需要一些使用规则用户帮助之类的能让用户避免或动手解决。
4.参考之前公司同类项目的测试用例和bug，写个测试用例大纲，覆盖所有功能点。
5.一个人的测试，你要和产品和开发做好沟通工作。我最喜欢用的一个经验是，不懂的地方让开发和产品各给我讲一遍，把两者提供的信息综合起来，事半功倍。领导会主动指导你，这时候，虚心听取指点。
说得不是很经典，希望对你有帮助~~

很经典

【首先驳斥他“保证软件的质量”的说法，测试在项目中的作用是质量控制，而不是质量保证】说的好

一看就知道是小公司!俺深有同感! 因为俺就在小公司做这样的事情,啥都没有,规章制度,测试流程,测试规范,测试资源. 虽然啥都没有!,但是我还是在尽力从测试的角度保证部分软件质量...哎...

很想知道，你怎么回答的，呵呵

或许人家公司就是要一个能解决问题的人，而不是驳斥他的人呢？就算时间充足你也无法保证质量，一般这种情况下，我会分业务流程来测试，先测试主要业务流程，再测试次要的流程，脚本辅助测试没有一些明显的错误。

我就直接回答他“我根本没办法保证”，然后就再补充了一些～所以最后面试以失败告终～

厉害！真的是一个小公司，是刚开始弄测试的，所以想招一些有经验的人进来～

呵呵，保证软件质量不是一定是100%，相对而言，50%比30%好。

谢谢～
你总结得真好！受教了～

谢谢～ 要是当时我可以像你这样回答的话，估计现在也不用继续找工作了～

{首先驳斥他“保证软件的质量”的说法，测试在项目中的作用是质量控制，而不是质量保证，那是项目经理该做的事情。}
前半句话说的很好，但后半句不赞同，没有谁该做谁不该做的，只要是测试的工作就和测试有关，除非你不做测试。
其实在很多东西都不成熟的情况下是常有的事，这就看你从什么角度出发，以什么为重点，个人经验：首先，不管什么软件，都有一个版本，即使在不成熟的东西都有版本，把版本控制好是最根本；其次，多找问题，我说的多找问题并不是软件中的问题，而是不成熟文档的问题，这就要看你能想到多少了；最后，在问题都得以解决，版本控制好，那么软件的质量就会被控制好。最后一句话：没有完美（无BUG）的软件，就同人一样，但有控制好的软件！

测试方法摆在那 测试理论摆在那 还有个测试员  该用的都已经有了

看到大家的评论。。学到好多啊。。

很详尽了

嘿嘿

呃，有胆识，有魄力。

在没搞清楚质量定义之前,没法保证!