迅速找出重要程序问题
本帖最后由 wzb022 于 2011-7-13 10:19 编辑本人测试新手，最近看到网上一篇《迅速找出重要程序问题》，感觉有所收获。但同时也有自己的疑问和感想，具体如下：
* 首先测试经过变更的部分，然后测试没有变化的部分。修改和更新都意味着新的风险。
(如果现在比较忙，没有时间去测新变更的部分，怎么办？)
* 首先测试核心功能，然后测试辅助功能，测试产品所完成的关键和常用功能，测试完成产品基本任务的功能。
(如何去确定核心功能？通过阅读需求和找开发人员确认？)
* 首先测试能力，然后测试可靠性。先测试每个功能是否完全能用，然后再深入检查任何一个功能在很多不同条件下表现如何。
(通常我们都是这样做的。先测试软件是否满足功能性的需求，然后再进一步测试尽可能多的场景（随机测试），最后是性能方面的需求。)
* 首先测试常见情况，然后测试少见情况。使用常用的数据和使用场景。
(尽量站在用户角度去考虑所有可能的使用场景。包括使用客户提供的数据等)
* 首先测试影响大的问题，然后测试影响小的问题。测试在出现失效的情况下会产生大量破坏的产品部件。
(有可能出现一大片小问题其实只是由一个大的问题所引发的，这就需要测试人员勤于思考，进行深入地研究，发现问题的根源所在)
* 首先测试最需要的部分，然后测试没有要求的部分。测试对团队其他人有重要意义的任何部分的任何问题。
(对于需求中明确定义的内容必须进行严格的测试。在测完需求中明确定义的部分后，如果有充足的时间可以进行相应的ad hoc测试)
页:
[1]
