求解，软件测试通过的标准是？
如题，有说标准是缺陷密度值达到客户要求。觉得有些许官方。 不如说说你的看法，然后大家来补充，怎么样？ 本人总结软件测试通过标准：1、软件功能是否符合产品需求？
这个需要和提交需求人员进行详细交流，现在的功能是什么样子，你们想要什么样子。
2、在符合产品要求的基础上，目前软件在稳定性和异常处理上有没有严重缺陷。
这个需要测试和研发人员交流清楚
3、项目经理对于现在功能是否认可。
也就是说测试不会说明确的给出，这个软件功能测试是否通过。一般会强调软件功能测试完成，存在哪些问题，分别的交流结果是什么？最终结论是否可以发布。 个人理解 软件测试通过 应该等于 项目或产品通过吧，因为测试贯穿于整个项目过程中；
如果是，应该分 对内与对外吧；
对内，即公司内部；
1、实现客户需求；
2、不存在已知Bug；
3、通过了项目经理、产品经理以及需求人员的确认与验收，即内测通过；
对外，即发布后，客户方；
1、客户在试用期内，试用通过；
2、客户验收通过，即公测通过； 回复 2# 愚人
晚辈想听听 版主 的见解！！ 回复 5# Charles_H
你总结的挺好 回复 5# Charles_H
个人愚见：
测试通过没有统一的标准，依赖于对用户需求的满足和成本
对用户的需求在测试环境体现在哪？测试用例，所以测试通过的标准之一肯定跟用例相关
修复bug是需要成本的，怎样在满足用户需求的情况下，降低成本，或者说去掉不必要的成本？
遗留bug数量和bug的严重程度，所以通过测试的标准跟遗留的bug相关
从上面两个角度和自己公司产品本身特点来商定通过标准 回复 7# 愚人
较正规的公司企业，的确可以这样做，但有的公司测试流程并不正规，没有测试用例；
或者测试用例编写后基本不用，都是给客户看的； 这样的公司，测试就是模糊不清，
有时候，自己也不知道测试什么时候结束，什么情况才算测试通过……
我想很多测试人员存在这样的问题！！ 回复 8# Charles_H
当所在公司的流程不是很规范时，可以推行规范流程，同时在项目执行中，先和项目负责人，沟通测试范围、测试思路，所谓测试通过，也就是沟通后的范围被测试通过。举例：当项目负责人给出的时间是非常紧迫的，无法做到全面地测试，那么就沟通下是否能接受只进行主流程测试，主流程测试又是那些，如果项目负责人接受，则进行主流程测试，结果也只是主流程测试通过。
如果确认不了范围，那么则可以反之在报告中告知那些功能是测试通过的。
很多小公司无法一步到位，或者是以项目为主，都建议确认测试范围。用例是对外的，对内的用例最好也要有。 回复 8# Charles_H
没有需求可以怪公司不正规，没有测试用例，该测试人去反思，不管公司有没有要求…… 各个公司根据业务的不同有不同的标准吧。
有的公司以运营的业务，可以进行一步步地进行灰度发布，如，内测版，β版，最终发布；
有的公司以外包交付业务，客户方应该有验收标准，如果自己的测试标准稍高于客户方的验收标准，通常来说交付是顺利的，同时成本也不会上升很多。（但真实情况是有需求在前期不清，评审流于形式，会导致后期交付期反复较多，周期延长）
1、经过评审后的测试用例全部执行完毕；
2、经过几轮后发现的bug数量呈线性向下走势；
3、严重bug（1级），重要bug（2级）全部修复，一般bug（3级）《bug总数的2%，轻微bug（4级）《bug总数的4%；（bug等级可由公司测试部或项目组内部讨论决定）
4、通过项目组的联合测试，α测试；
5、测试计划中要求的内容全部完成，测试报告供项目经理做出外发评估依据。 各个部门各司其职，如果你是初级的，只管把需求看好，把功能测试，至于软件通过不通过，自有产品来把关。当然想要路走的更远，还是要有产品的观念和思想。 都讲的很好，说出了我们的心声，我们就属于那种不正规，测试用例属于应付的公司 个人觉得测试人员职责有两个 1.验证问题。2.质量把控；
通过不通过看各个公司的制度吧；测试人员角度概括来说就是：实现了需求文档的所有功能点，并且没有发现bug。
某些公司是硬性在提交的测试内容内要求不能有几个某个级别的bug 才算通过；
而大多数公司需求文档不全。只能验证大致功能使用，即不报错即可。 还是从几个维度去度量：
1.用例，也可以认为是测试的范围或者是待测的功能点
2.缺陷，缺陷的修复情况，遗留的缺陷分布。
3.时间，很明显，项目到上线时间了，你的测试理应也结束了。
页:
[1]
