网友总结的面试问题

bobli · 发表于 2004-10-21 22:12:13

测试工作面试常被问到的问题，请大家一起来解答

  1，软件测试活动的生命周期是什么？
  2，请画出软件测试活动的流程图？
  3，针对缺陷采取怎样管理措施？
  4，什么是测试评估？测试评估的范围是什么？
  5，如果能够执行完美的黑盒测试，还需要进行白盒测试吗？为什么？
  6，测试结束的标准是什么？
  7，软件验收测试除了alpha,beta测试以外,还有哪一种?

ok · 发表于 2004-10-26 15:49:14

6，测试结束的标准，就我们公司现在的情况，我觉得整个系统能走下去，这是最基本的，当然还有其它的，日后再　补充

andyhegang · 发表于 2004-10-27 17:28:24

有答案吗？

bobli · 发表于 2004-10-27 18:47:58

大家一起来总结学习

badgirl_liu · 发表于 2004-10-28 12:52:45

有答案吗

wangnan · 发表于 2004-10-28 15:11:00

我个人认为，
测试的生命周期与项目的开发周期是相一致的。
测试是一个过程，它也是需要进行开发的。
设计工作不仅是开发过程中的精髓，
同样也是测试过程中的生命主体。
对于开发过程
需求的作用是为了清晰目标；
设计的作用是规划怎样达到目标的方法；
编码的作用是根据方法来实现目标；
测试的作用是验证是否达到了预期的目标；
维护的作用是为下次的软件升级提供依据。
而对于测试过程也同样如此
测试需求为测试工作限定了可执行的标准和范围；
测试设计为测试工作提供了可靠的方法，
因此它是测试工作中的重中之中，
用例的准备是根据测试设计而进行的测试编码过程
执行用例是为了得到有用的数据，
从而将其转变成有效的方法和措施来加强软件质量
因此我个人觉得无论是开发还是测试，
思想都是统一的。
总之系统的开发是为给用户创造价值，为了服务用户；
系统的测试是为了减小用户的使用风险，
同样也可以给用户减少损失创造价值服务了用户。
欢迎大家共同探讨！

hotbadcat · 发表于 2004-11-5 12:26:33

答案啊！高手们，举手之劳，帮帮忙！

Grield_Cat · 发表于 2004-11-10 15:59:37

是啊是啊……高手们，答案啊！

beiyue · 发表于 2004-11-11 11:05:17

cat_zhang · 发表于 2004-11-14 15:52:56

我想第6条是否可以说1.在该软件发布时所交付的软件中所携带的确BUG是否对软件的影为最小影响,2.是否满足了客户的需求

siaccp · 发表于 2004-12-12 21:09:48

第七题目的答案有吗?我不懂!麻烦班主您告诉我好吗?我正想从事这门软件测试的工作.麻烦您了

mouse1x · 发表于 2004-12-23 12:25:03

首先偶不是高手，是新手。不知道对不对，试着答一下，不当之处还请各位指点：
1：风险评估、测试计划、测试设计、测试开发、测试执行和测试评估；
2：多个被测模块-〉分别进行单元测试---〉通过后连同设计信息进行集成测试--————〉连同需求分析进行确认测试————〉综合其他因素进行系统测试---〉交付软件；
3：通过软件测试和软件项目评审来发现软件缺陷，然后对缺陷分类、隔离、最后解决；
4：我觉的应该是针对测试执行后的结果分析吧！范围应该是分5级的：灾难性的、很严重的、严重的、中等的、普通的、轻微的；
5：需要进行的，因为对于不满足要求或发现的问题的最终所在时可能百盒测试能给出准确的定位。
6：我觉得测试结束的标准就是一个软件满足了用户要求的所有功能。
7：软件配置复查和有效性测试。

[ Last edited by mouse1x on 2004-12-23 at 12:26 ]

jojoo · 发表于 2004-12-23 17:11:15

好，谢谢！

christine1230 · 发表于 2004-12-29 20:51:41

怎么没人介绍哈网游测试呢5555555555555

baitest · 发表于 2005-1-19 17:15:32

1。软件测试的生命周期和开发的生命周期相同；
2。流程图：测试计划---审查---通过---实施---审查---通过---bug管理等---审查确认----修改完善----回归测试----确认---发布等，其中包括检查点的走查等；
3。针对缺陷应当采取对缺陷的确认、审查、修改和再确认、审查、修改，直到缺陷排除。
4。测试评估是软件质量管理的范畴，包括测试计划的制定、审查，缺陷得审查、确认。主要是对软件测试各个阶段的有效的管理和文档的审查，已确定软件测试是否按照测试的计划、流程进行，并满足软件设计的要求和计划。
5。黑盒侧外不测内，即使黑盒测试完美，但也不能保证软件在设计阶段的代码符合设计的要求和规范，因为测试有静态和动态测试。往往在软件运行一段时间后，问题才暴露出来，这时再去做白盒测试，恐怕代价会无限大的。
6。测试结束的标准应当是测试计划、软件设计要求和用户的最终验收通过为准。
7。除了基本的测试外，应还有生命周期测试。

YNGXLI · 发表于 2005-5-4 08:37:58

This can be difficult to determine when to stop testing. Many modern software application are so complex, and run such an interdependent environment, that complete testing can never be done. Common factors in deciding when to stop are:
1. Deadlines (release deadlines, testing deadlines, etc.)
2. Test cases completed with certain percentage passed
3. Test budget depleted
4. Coverage of code/functionality/requirements reaches a specified point
5. Bug rate fails below a certain level
6. Beta or alpha testing period ends

YNGXLI · 发表于 2005-5-4 08:57:49

I have a similar question: What should be done after a bug is found?

An reference answer:
The bug needs to be communicated and assigned to developers that can fix it. After the problem is resolved, fixes should be re-tested, and determinations made regarding requirments for regression testing to check that fixes didn't create problems elsewhere. If a problem-tracking system is in place, it should encapsulate these processes. The following are items to consider in the tracking process:
1. Complete information such that developers can understand the bug, get an idea of it's severity, and reproduce it if necessary.
2. Bug identifier (number, ID, etc.)
3. Current bug status (e.g. 'Released for Retest', 'New', etc.)
4. The application name or identifier and version
5. The function, module, feature, object, screen, etc. where the bug occurred
6. Environment specifics, system, platform, relevant hardware specifics
7. Test case name/number/identifier
8. One-line bug description
9. Full bug description
10. Description of steps needed to reproduce the bug if not covered by a test case or if the developer doesn't have easy access to the test case/test script/test tool
11. Names and/or descriptions of file/data/messages/etc. used in test
12. File excerpts/error messages/log file excerpts/screen shots/test tool logs that would be helpful in finding the cause of the problem
13. Severity estimate (a 5-level range such as 1-5 or 'critical'-to-'low' is common)
14. Was the bug reproducible?
15. Tester name
16. Test date
17. Bug reporting date
18. Name of developer/group/organizaiton the problem is assigned to
19. Description of problem cause
20. Description of fix
21. Code section/file/module/class/method that was fixed
22. Date of fix
23. Application version that contains the fix
24. Tester responsible for retest
25. Retest date
26. Retest results
27. Regression testing requirements
28. Tester responsible for regression tests
29. Regression testing results

A reporting or tracking process should enable notification of appropriate personnel at various stages. For instance, testers need to know when retesting is needed, developers need to know when bugs are found and how to get the needed information, and reporting/summary capabilities are needed for managers.

YNGXLI · 发表于 2005-5-4 09:03:33

- Logic errors and incorrect assumptions most likely to be made when coding for 'special cases'. Need to ensure these execution paths are tested.
- May find assumptions about execution paths incorrect, and so make design errors. White box testing can find these errors.
- Typographical errors are random. Just as likely to be on an obscure logical path as on a mainstream path.